in win2K,XP,2K3,vista,win7?I call ObReferenceObjectByHandle(hSection…) to get SectionObject.And then,I use section->segment->control area->FileObject,to find the FileObject.
In win8 x86,it’s OK.But in win8 X64,I get the SectionObject is a valid address,but the Segment field is a invalid address(dt _SECTION_OBJECT 0x???,the 0x28 offset is _SEGMENT,the value is 0x0000000000cb0000).
what’s the trick in it?
thanks~
>in win2K,XP,2K3,vista,win7?I call ObReferenceObjectByHandle(hSection…) to
get SectionObject.And then,I use section->segment->control
area->FileObject,to find the FileObject.
In win8 x86,it’s OK.But in win8 X64,I get the SectionObject is a valid
address,but the Segment field is a invalid address(dt _SECTION_OBJECT
>0x???,the 0x28 offset is _SEGMENT,the value is
0x0000000000cb0000).
what’s the trick in it?
The trick is that you do not own these structures, they are undocumented and
subject to change.
In my symbol store, I got symbols for over 600 different editions of NT
kernel. Do you think that you can support them all ?
Try to explain what you are doing and why you need. Then maybe someone in
the group can propose a supported solution.
//Daniel
Daniel,this solution can work.I get these structures in all version,in fact,it is just only 4 version in X64,just one version in X86.
you got 600 different editions of NT kernel?not these structures?
And?my question is just in a real machine!When I got _SECTION_OBJECT,I dt _SECTION_OBJECT (address) in windbg.So,different editions of these structurs are not the key.
This is not a shippable solution.
You must fix your code to not grovel into these structures.
- S (Msft)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Monday, February 25, 2013 11:27 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] get SectionObject by ObReferenceObjectByHandle in win8 X64
Daniel,this solution can work.I get these structures in all version,in fact,it is just only 4 version in X64,just one version in X86.
you got 600 different editions of NT kernel?not these structures?
And?my question is just in a real machine!When I got _SECTION_OBJECT,I dt _SECTION_OBJECT (address) in windbg.So,different editions of these structurs are not the key.
NTDEV is sponsored by OSR
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>Daniel,this solution can work.
Possibly so, if you try hard enough at some point something should work. But
instead, focus on solutions that work all of the time.
I get these structures in all version,in fact,it is just only 4 version in
X64,just one version in X86.
you got 600 different editions of NT kernel?
Yes, 600 and who knows there exist many more. This was just to say: what
about the many service packs ? what about a visit to Windows update that
changes ntoskrnl.exe ? How can you guarantee your hardcoded hacking to work
? You cannot, you are focusing on a solution that works only some of the
time and mess up terribly most of the time.
In the future, you might have to get back here every week to ask us what
happened.
not these structures?
I did not check them. Who knows how many different version of the structure
that you are using exist ?
And?my question is just in a real machine!When I got _SECTION_OBJECT,I dt
_SECTION_OBJECT (address) in windbg.
So,different editions of these structurs are not the key.
Not sure what you are hinting at. Again: you are using undocumented and
unsupported solutions. Try to explain what you are doing and what is the
overall purpose of it and maybe someone can guide you with a supported
solution.
//Daniel
Mr. Stone, you DO realize that the format of the structures is subject to change even in a SERVICE PACK, right? It’s not academic, I’ve seen it happen. You don’t own the structure you’re manipulating. You don’t have access to the appropriate locks or full knowledge of how/when/where this structure is used. To manipulate, even to just read, such a structure in a real, shipping, application rises to the level of professional malpractice.
A quick story:
One of the angriest I’ve ever seen one of the Windows kernel guys get was when he was trying to help solve a series of crashes that appeared (frequently, I guess) in the field on ONE particular version of Windows. The problem appeared to be in code that he owned, and he was under the gun. They soon discovered that on every system that had the problem, one particular piece of 3rd party (i.e. non-Microsoft) kernel mode software was running. A week or so of debugging later, they discovered that this piece of software was manipulating an internal, undocumented, kernel structure. “What does he think he’s doing with MY data structures! Those are PRIVATE structures!” I heard him tell. They actually contacted the developer who owned the errant software, and helped him fix it.
My point here is don’t think you can properly estimate the impact of stupid actions like manipulating private structures. You really can’t. Your actions can cause grief for customers, and for developers, that you certainly cannot anticipate.
You THINK you know, but in fact you almost certainly do not. And there’s know way for you to accurately gauge the risk involved with what you are doing.
Peter
OSR
thanks peter!
I have two solutions for my project: Get FileObject from a section handle!
1.just read undocumented structure:
get object from handle,and read
_SECTION_OBJECT–>_SEGMENT–>_CONTROL_AREA–>the FileObject pointer
These structures can change in different windows version(including Service Pack),I have handle it in all version(including all Service pack version) by dt in windbg.
In win8 X64,these structure is the same as win 7 X64.But,in _SECTION_OBJECT,the 0x28 offset is _SEGMENT pointer,the pointer is just example for 0x484,not a valid pointer(I guess this is a handle?)
2.I call ZwMapViewOfSection by the section handle.
And,I get the file contents from offset 0;My file’s header is a fixed tag.
This solution can work in all version windows,but it need IO.I want to decease the cost,So,I choose the solution 1.
Hi Peter - Isn’t this the major problem with the Windows OS model? The system has to trust software from a large number of developers when even if they were all of the highest integrity someone somewhere is going to make a mistake. Even Microsoft’s own driver developers are presumably not above this.
When I write app code I rarely even trust myself, and do a lot of parameter checking on functions that only I will call. But it is indeed ad-hoc, the thing I don’t test often brings me down.
In addition to simple errors we see frequent posts here from people who are determined to do things that are fundamentally flawed. Reading these (though I’m not actively developing drivers at the moment) keeps me alert to the myriad ways things can go wrong, and consequently I am not surprised by the random misbehaviour of all my Windows installations here (not running any of my drivers I hasten to add!).
It’s probably unfair to choose examples, but the recent thread “How to throttle CPU speed” shows that even well intentioned people are determined to distribute dangerous drivers - they sometimes (as in this case) claim that their unsupported solutions have been tested on every relevant version of Windows (including future updates apparently).
No doubt it’s too late to retrofit any safer driver solution to Windows. A hardware interface that allows people to write drivers that support new hardware should be in untrusted space - a bit like UMDF, and I am not sure it is sensible to allow anyone to mess in the works of OS, e.g. the file system, or CPU management, no matter how wonderful their improvement to Windows may be.
Of course, I realise the power of Windows was that it did allow all sorts of user tweaking, which helped a lot during the last couple of decades of development, but that is getting harder as signature requirements and DRM and so on stick tape over many of the holes into the kernel, but those holes still exist, and drive people to more and more bizarre means to achieve perceived aims. And sticky tape will never make WIndows secure.
So until a solution emerges where the OS is certified impregnable by the manufacturer while being capable of supporting diverse needs, we are stuck with an unreliable, insecure OS on which to base virtually our entire civilisation!
Mike
----- Original Message -----
From: xxxxx@osr.com
To: Windows System Software Devs Interest List
Sent: Tuesday, February 26, 2013 2:08 PM
Subject: RE:[ntdev] get SectionObject by ObReferenceObjectByHandle in win8 X64
Mr. Stone, you DO realize that the format of the structures is subject to change even in a SERVICE PACK, right? It’s not academic, I’ve seen it happen. You don’t own the structure you’re manipulating. You don’t have access to the appropriate locks or full knowledge of how/when/where this structure is used. To manipulate, even to just read, such a structure in a real, shipping, application rises to the level of professional malpractice.
A quick story:
One of the angriest I’ve ever seen one of the Windows kernel guys get was when he was trying to help solve a series of crashes that appeared (frequently, I guess) in the field on ONE particular version of Windows. The problem appeared to be in code that he owned, and he was under the gun. They soon discovered that on every system that had the problem, one particular piece of 3rd party (i.e. non-Microsoft) kernel mode software was running. A week or so of debugging later, they discovered that this piece of software was manipulating an internal, undocumented, kernel structure. “What does he think he’s doing with MY data structures! Those are PRIVATE structures!” I heard him tell. They actually contacted the developer who owned the errant software, and helped him fix it.
My point here is don’t think you can properly estimate the impact of stupid actions like manipulating private structures. You really can’t. Your actions can cause grief for customers, and for developers, that you certainly cannot anticipate.
You THINK you know, but in fact you almost certainly do not. And there’s know way for you to accurately gauge the risk involved with what you are doing.
Peter
OSR
NTDEV is sponsored by OSR
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>I have two solutions for my project: Get FileObject from a section handle!
What problem are you trying to solve?
2.I call ZwMapViewOfSection by the section handle.
Why do you think its performance would be a problem for you?
Weeeeelllll… I agree that it would certainly be nice if a driver could only access resources that are provided to it by the OS, yes. Ignoring issues of performance and implementation, it would sure be wonderful if we had a world where drivers lived in a tightly sealed container.
So, yes… I agree Mr. Kemp. And I agree it’s probably “too late to retrofit any safer driver solution to Windows” – at least, too late for a comprehensively safe solution.
This solution would require a *very* different operating system and driver DDI, wouldn’t it. I mean, really, really, different. All DMA would have to be virtualized. Structures could only be accessed via methods. Memory would have to be made specifically available to drivers for their access, page by page.
You could even force interrupt and DPC processing down to levels where it could be preempted. Even then, you’d have to deal with problems of drivers not handling their devices properly, causing interrupt storms or whatever.
So, yes… in an ideal world it’d be nice. You’d have an OS that has correctness as a central basis for its design. There IS research and prototyping work being done in this area today. But this sure wasn’t the world, the architecture, or the philosophy when Windows NT started to be designed back in 1988 (and before that).
So… do we simply give up? Well, exactly as you imply, yes… sort of. As long as you have drivers that can deref bad pointers, randomly change data structures they do not own, and write to memory that is not theirs, you have a driver model that inherently contributes to OS instability. So, whether or not the OS support functions that drivers call validate parameters or not is really academic. One deref of a NULL pointer, and it’s game over.
Is all lost? What do we have instead? Here comes the “preaching to the choir” section…
For one, we have the poor, lonley, under-used and under-appreciated Check Build of Windows. THAT does *a lot* more parameter validation than the free build of Windows. I’d like it to do even more, as a policy… but it’s hard to get the devs to add stuff to the Checked Build when so few people actually use it.
We also have Driver Verifier and KMDF Verifier. And, of course we have KMDF and UMDF. Driver Verifier, plus KMDF are without a doubt the two greatest contributions to driver reliability in Windows ever introduced.
We also need to mention PreFast and SDV for static analysis. These tools are improving with each release, to the point where – if people would just use them and actually understand what they’re trying to convey – they would help eliminate lots and lots of driver errors.
Peter
OSR
>For one, we have the poor, lonley, under-used and under-appreciated Check Build
of Windows.
A good step for MS would be requiring the drivers to pass WHC (WHQL) tests under checked build.
WHC already requires DRiverVerifier and SDV.
Also, although the steps are done in the right direction, only allow signed binaries to run with high privileges (this includes making changes to Windows directory). Not Microsoft - GTFO from Windows.
AWEsome idea.
WHCK folks… are you listening by any chance?
Peter
OSR
Mike Kemp wrote:
Hi Peter - Isn’t this the major problem with the Windows OS model? The
system has to trust software from a large number of developers when
even if they were all of the highest integrity someone somewhere is
going to make a mistake. Even Microsoft’s own driver developers are
presumably not above this.
When you develop an operating system, you have to make that choice. Do
you “trust” or do you “trust but verify”? At the time Windows was
designed, a quarter of a century ago, processors were two orders of
magnitude slower than they are today. It’s expensive to validate
parameters, especially in the kernel where you’re running at a higher
priority. So, they made the quite reasonable decision to “trust”.
Heck, those early versions of Windows even trusted user-mode
parameters. It wasn’t until perhaps the mid-1990s that Windows really
started validation user-mode APIs.
If you were starting over today, you’d probably do parameter validation
and use a managed code environment in the kernel. It would be a lot
safer, but the performance wouldn’t be as good.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Clark, can you please tell us what problem you’re trying to solve?
I’m just curious when/why you need get process’ FO.
Looking at my source I realize that I also read process’ FO from CLIENT_AREA
struct (shame on me!), BUT starting with Vista+ I use CreateInfo->FileObject
(Vista SP1+) if present, otherwise I call PsReferenceProcessFilePointer
(Vista+) or I access directly to undocumented structure for XP/Srv2k3.
Ugh, I hope I never have the misfortune to run your software.
That being said, one of your core problems seems that you don’t realize SECTION_OBJECT and SEGMENT_OBJECT are not the actual OS structures, they’re junk in the public symbols based on Win2K.
The real types are SECTION (not in the public PDB) and SEGMENT (in the public PDB). By luck, SECTION_OBJECT and SECTION have had a similar header, such that SectionObject->Segment happened to match Section->Segment. But SEGMENT and SEGMENT_OBJECT have almost nothing in common these days.
Either way, why not just PsReferenceProcessFilePointer which calls MmGetFileObjectForSection, which does all of this for you? Keeping in mind that this an undocumented API and is subject to change at any time, I’d much rather be using an undocumented API than what you’re doing.
Why have the FO though? Can I assume you just want the file object to get the name? Have you looked into SeLocateProcessImageName?
–
Best regards,
Alex Ionescu
>
The real types are SECTION (not in the public PDB) and SEGMENT (in the public PDB).
By luck, SECTION_OBJECT and SECTION have had a similar header,
such that SectionObject->Segment happened to match Section->Segment.
But SEGMENT and SEGMENT_OBJECT have almost nothing in common these days.
Always wondered about that little bit of misinformation. Not the only
place where the symbols are misleading or erroneous, however.
thanks~Alex Ionescu!because if I get the FO,I can issue my FSCTL to the FO.
what your mention is undocumented API,yes,it’s better than mine!
I want to get the FO,not for the name,just for the FO
but,I can’t find MmGetFileObjectForSection in WDK header files.Is it exported by ntosknernel?
thanks your idea,I will study it according to your hints.
Alex Ionescu,MmGetFileObjectForSection is not an exported func from ntoskrnl~~~
how can I get the func pointer?
I disasm the MmGetFileObjectForSection,ok…in win8 x64,the Segment offset is 0x20.
Yes,this is a ugly solution,but it at least works.
I will develop other solution for it.
thanks your hints,all of you~