Hi all, in my driver, I use ZwMapViewOfSection to map view ntkrnlpa.exe to get the export function address, and after that , call ZumUnmapViewOfSection to unmap the view, the call ZwClose to close the section and file handle.
But when I call ZwQuerySytemInformation to get the SystemModuleList information , I found that there is a module where its ImageName is \SystemRoot\System32\ntkrnlpa.exe, and its Image Base is 0x00400000.
My problem is why after I call ZwUnmapViewOfSection, the module still exist in the SystemModuleList??
Why are you doing this instead of using MmGetSystemRoutineAddress?
S
-----Original Message-----
From: xxxxx@gmail.com
Sent: Sunday, August 28, 2011 21:50
To: Windows System Software Devs Interest List
Subject: [ntdev] ZwMapViewOfSection and ZwUnmapViewOfSection problem
Hi all, in my driver, I use ZwMapViewOfSection to map view ntkrnlpa.exe to get the export function address, and after that , call ZumUnmapViewOfSection to unmap the view, the call ZwClose to close the section and file handle.
But when I call ZwQuerySytemInformation to get the SystemModuleList information , I found that there is a module where its ImageName is \SystemRoot\System32\ntkrnlpa.exe, and its Image Base is 0x00400000.
My problem is why after I call ZwUnmapViewOfSection, the module still exist in the SystemModuleList??
Because the SSDT table may be modified by some anti-virus or other software, so the value MmGetSystemRoutineAddress returned maybe the modified address. So I map view of the original ntkrnlpa.exe PE file to parse the export entry to get the address or the original opcode of the function.
> Because the SSDT table may be modified by some anti-virus or other software,
so the value MmGetSystemRoutineAddress returned maybe the modified address.
This statement makes no sense - all kernel exports, apart the Zwxxx ones, are invoked directly without going via SSDT anyway. Apparently, you meant that the export section of ntoskrnl.exe may get hacked, right?
In such case you are out of luck anyway…
So I map view of the original ntkrnlpa.exe PE file to parse the export entry to get the address
or the original opcode of the function.
Well, if system has been already compromised making it check its own integrity does not seem to make
much sense, don’t you think…
.
Anton Bassov
yes, i mean the export section of ntoskrnl.exe may be hacked…
If the system PE file on the disk has been compromised, then mapview of the
“bad” file also have no sense, but it semms that this situation is too less.
On Mon, Aug 29, 2011 at 7:31 PM, wrote:
> > Because the SSDT table may be modified by some anti-virus or other > software, > > so the value MmGetSystemRoutineAddress returned maybe the modified > address. > > This statement makes no sense - all kernel exports, apart the Zwxxx ones, > are invoked directly without going via SSDT anyway. Apparently, you meant > that the export section of ntoskrnl.exe may get hacked, right? > In such case you are out of luck anyway… > > > > So I map view of the original ntkrnlpa.exe PE file to parse the export > entry to get the address > > or the original opcode of the function. > > Well, if system has been already compromised making it check its own > integrity does not seem to make > much sense, don’t you think… > . > Anton Bassov > > — > NTDEV is sponsored by OSR > > 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 >
> yes, i mean the export section of ntoskrnl.exe may be hacked…
… then SSDT is more than likely to be hacked as well. Therefore, you may never have a chance to call ZwMapViewOfSection successfully on compromised system, in the first place…
yes, i mean the export section of ntoskrnl.exe may be hacked…
If the system PE file on the disk has been compromised, then mapview of the
“bad” file also have no sense, but it semms that this situation is too less.
On Mon, Aug 29, 2011 at 7:31 PM, wrote:
> Because the SSDT table may be modified by some anti-virus or other software, > so the value MmGetSystemRoutineAddress returned maybe the modified address.
This statement makes no sense - all kernel exports, apart the Zwxxx ones, are invoked directly without going via SSDT anyway. Apparently, you meant that the export section of ntoskrnl.exe may get hacked, right? In such case you are out of luck anyway…
> So I map view of the original ntkrnlpa.exe PE file to parse the export entry to get the address > or the original opcode of the function.
Well, if system has been already compromised making it check its own integrity does not seem to make much sense, don’t you think… . Anton Bassov
If malware is running in kernel mode then you have already lost.
S
From: Cnbragon
Sent: Monday, August 29, 2011 5:12
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ZwMapViewOfSection and ZwUnmapViewOfSection problem
yes, i mean the export section of ntoskrnl.exe may be hacked…
If the system PE file on the disk has been compromised, then mapview of the “bad” file also have no sense, but it semms that this situation is too less.
On Mon, Aug 29, 2011 at 7:31 PM, > wrote: > Because the SSDT table may be modified by some anti-virus or other software, > so the value MmGetSystemRoutineAddress returned maybe the modified address.
This statement makes no sense - all kernel exports, apart the Zwxxx ones, are invoked directly without going via SSDT anyway. Apparently, you meant that the export section of ntoskrnl.exe may get hacked, right? In such case you are out of luck anyway…
> So I map view of the original ntkrnlpa.exe PE file to parse the export entry to get the address > or the original opcode of the function.
Well, if system has been already compromised making it check its own integrity does not seem to make much sense, don’t you think… . Anton Bassov
Hi all, in my driver, I use ZwMapViewOfSection to map view ntkrnlpa.exe to get the export function address, and after that , call ZumUnmapViewOfSection to unmap the view, the call ZwClose to close the section and file handle.
But when I call ZwQuerySytemInformation to get the SystemModuleList information , I found that there is a module where its ImageName is \SystemRoot\System32\ntkrnlpa.exe, and its Image Base is 0x00400000.
My problem is why after I call ZwUnmapViewOfSection, the module still exist in the SystemModuleList??
That’s not a surprise, is it? ntkrnlpa.exe is the DLL that contains the
kernel. Every process loads it. Just because you have unmapped your
section doesn’t mean it’s not still in use.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
If you recall the way that the windows memory manager works, you will quickly realize your problem. Notwithstanding the serious fundamental issues that others have pointed out, mapping a view of a file that is already mapped into an address space read only will never give you a fresh copy from disk. You might have a chance if you read the file data, but as others have pointed out, if the system is compromised in the way that you are trying to protect against, then most likely the malware author will have considered this too and simply return what he wants for this too; and if not, then anti-virus software will likely have already done what can be done, so what do you think you can gain?
“Cnbragon” wrote in message news:xxxxx@ntdev… yes, i mean the export section of ntoskrnl.exe may be hacked… If the system PE file on the disk has been compromised, then mapview of the “bad” file also have no sense, but it semms that this situation is too less.
On Mon, Aug 29, 2011 at 7:31 PM, wrote:
> Because the SSDT table may be modified by some anti-virus or other software, > so the value MmGetSystemRoutineAddress returned maybe the modified address.
This statement makes no sense - all kernel exports, apart the Zwxxx ones, are invoked directly without going via SSDT anyway. Apparently, you meant that the export section of ntoskrnl.exe may get hacked, right? In such case you are out of luck anyway…
> So I map view of the original ntkrnlpa.exe PE file to parse the export entry to get the address > or the original opcode of the function.
Well, if system has been already compromised making it check its own integrity does not seem to make much sense, don’t you think… . Anton Bassov
> Because the SSDT table may be modified by some anti-virus or other software, so the value
MmGetSystemRoutineAddress returned maybe the modified address.
And oh how bad! this evil anti-virus just prevented your malware from running :-)))))
Any decorator-style stuff in Windows (hooks, filter device objects and such) just plain ARE NOT DESIGNED to allow somebody to access the raw un-decorated stuff below.
>If the system PE file on the disk has been compromised, then mapview of the “bad” file also have no sense
If you really want to read some small part of the file, without incurring the heavy overhead of Mm’s mapping, then just plain open it noncached and read your chunk of data to nonpaged memory. Plain and simple.
Mm’s mappings are for other scenarios, where you have highly random access, and non-self-contained data structures - i.e. data structures having offsets of another data structures.
TrueType font file is yes, a perfect thing for memory mapping, or, say, the static description of unmovable objects in the game’s world.
> If you really want to read some small part of the file, without incurring the heavy overhead of Mm’s
mapping, then just plain open it noncached and read your chunk of data to nonpaged memory.
Plain and simple.
Don’t forget that, as far as memory layout is concerned, mapping a PE file as executable image is different from reading it from the disk (as well as mapping it as a raw data ) - unlike raw data on the disk, sections of executable image are aligned on page boundary, and all offsets, RVAs, etc that are specified in PE file are based upon the assumption that file has been mapped as executable image.
Therefore, you will have to do some extra work, and I am not sure the implied benefits (if any) are worth the whole trouble…
And this is what the linker assumes when it specifies section offsets and RVAs in PE file…
Therefore, you will have to do some extra work if you simply read data ( or map PE file as a raw data,rather than executable image) before you can actually make use of PE data…
And I debuged the NtMapViewOfSection implementation of XP SP3, it is nearly
the same as the wrk.
So I confirm that it is the prolem.
On Thu, Sep 1, 2011 at 3:44 PM, wrote:
> Finally, I found that the problem lies in the function > MiMapViewOfImageSection > > the source code from WRK is as followes: > > if ((NtGlobalFlag & FLG_ENABLE_KDEBUG_SYMBOL_LOAD) && > (ReturnedStatus != STATUS_IMAGE_NOT_AT_BASE) && > (ControlArea->u.Flags.DebugSymbolsLoaded == 0)) { > > if (MiCacheImageSymbols (StartingAddress)) { > > MiSetControlAreaSymbolsLoaded (ControlArea); > > MiLoadUserSymbols (ControlArea, StartingAddress, Process); > } > > In the function MiLoadUserSymbols, the StartingAddress will be inserted > into MmLoadedUserImageList > > But NtUnmapViewOfSection doesn’t remove the entry from > MmLoadedUserImageList. > > So ZwQuerySystemInformation(SystemModuleInformation) will walk through > PsLoadedModuleList & MmLoadedUserImageList and get two ntkrnlpa.exe > ImageName. > > I don’t know if it is a bug or not. >