> You could also use the fact that NT has support for portable
executers, map the dll, exe or sys that exports you desired function
and then use IMAGE_EXPORT_DIRECTORY to get the address of the function
Well, if the function is NOT exported (as the OP wrote),
then it’s not in the export directory.
L.
> I need to get the address of an unexported(not undocumented!) native
api: ZwWriteProcessMemory. Is there any good way to address the issue?
Usually this is impelemented through a disasembling ntdll.dll to find an
index in the SDT array and finding a pointer to NtWriteProcessMemory from an
SDT entry. Be careful - Nt(*) functions don’t change the previous mode, you
should pass parameters according to current mode!
–
Slava Imameyev, xxxxx@hotmail.com
wrote in message news:xxxxx@ntfsd…
> hi,all.
> I need to get the address of an unexported(not undocumented!) native
> api: ZwWriteProcessMemory. Is there any good way to address the issue?
>
> Appreciate your reply!
>
>Well, once the OP says it is *unexported*, it somehow implies that he >wants to call it from the kernel mode - although this function is exported >by ntdll.dll, it is not exported by ntoskrnl.exe.
Therefore, as far as drivers are concerned, this function is unexported…
This function is exported by neither ntdll nor ntoskrnl, as best as I can tell, at least on XP SP2 (x86-FRE) and 6001-x64-CHK. Nor is it a public symbol in either. Nor is it in Nebbett. Is he talking about Nt/ZwWriteVirtualMemory, did the name change, or is this an internal SSDT name, or other?
I’m confused.
mm
>You could also use the fact that NT has support for portable executers, map the
dll, exe or sys that exports you desired function and then use
IMAGE_EXPORT_DIRECTORY to get the address of the function
If you don’t mind, could you please explain how, in your opinion, IMAGE_EXPORT_DIRECTORY is related to the topic we are discussing, i.e. calling a function that is *not* exported by ntoskrnl.exe …
Anton Bassov
> This function is exported by neither ntdll nor ntoskrnl,
… and it is not exported by any Win32 DLL either…
It is obvious that the OP meant ZwWriteVirtualMemory() here -after all, WriteProcessMemory() is just a Win32 wrapper around ZwWriteVirtualMemory(), so that the OP combined these two into one (nonexistent) name. Therefore, my post referred to ZwWriteVirtualMemory()…
Anton Bassov
well, thanks for all of your sincere replies.
in the first place, it’s very likely that i fail to clarify my purpose. Some malicious codes inject dll to another system process ,like explorer.exe or svchost.exe, and what i want to do is to monitor these
bahviors. In kernel mode, there’s a common way i.e call backs provided by microsoft, however ,this way yields lots of false alarms(many normal processes also injects dlls to another process).
So i trly to hook sys call, which is said to be effective.
If win32 has WriteProcessMemroy, i assume ZwWriteProcessMemory also exists in kernel mode.
I would do the following:
Enumerate system modules with: ZwQuerySystemInformation, subfunction SystemModuleInformation(11). You will get an array of loaded modules of type SYSTEM_MODULE_INFORMATION. Look at the Nebbett book for a description of this structure.
In this list look for “NTDLL.DLL”. To locate the name use the fields ImageName + ModuleNameOffset.
Once located the module, get its base address.
Then analyzing the PE header, locate the export table. Look for the function name you are interested in.
Using the information on the export table, calculate the address of the function within the module.
Disassemble the NTDLL code at that address. You will see an immediate load opcode. Get the operand of this instruction. This is the ID of the function.
Then locate the entry on the SSDT corresponding to that ID. That would be the address you want.
-----Mensaje original-----
De: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] En nombre de bladliu@126.com
Enviado el: mi?rcoles, 17 de octubre de 2007 7:56
Para: Windows File Systems Devs Interest List
Asunto: RE:[ntfsd] Re[2]: Get unexported native api address
well, thanks for all of your sincere replies.
in the first place, it’s very likely that i fail to clarify my purpose. Some malicious codes inject dll to another system process ,like explorer.exe or svchost.exe, and what i want to do is to monitor these
bahviors. In kernel mode, there’s a common way i.e call backs provided by microsoft, however ,this way yields lots of false alarms(many normal processes also injects dlls to another process).
So i trly to hook sys call, which is said to be effective.
If win32 has WriteProcessMemroy, i assume ZwWriteProcessMemory also exists in kernel mode.
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@pandasecurity.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> If win32 has WriteProcessMemroy, i assume ZwWriteProcessMemory also exists in
kernel mode.
Totally baseless assumption - there is no correspondence between Win32 calls and kernel exports whatsoever…
There is (some) correspondence between Zw… and Nt… exports in ntdll.dll and their kernel-mode counterparts, but it has nothing to do with Win32 wrapper. Furthermore, there are *PLENTY* of ntdll.dll’s Zw/Nt exports that haven’t got their counterparts is the kernel mode, because, despite being implemented by the kernel, these exports are of no use to drivers ( all virtual memory function are typical examples of those services). Actual services that correspond to these exports are exposed to the user-mode code via SSDT. Some services that are exposed to the user-mode code via SSDT are also exported in either Zw or Nt form by ntoskrnl.exe, so that drivers can make use of them. There also some services (namely, Rtl… ones) that are exported by both ntoskrnl.exe and ntdll.dll, but their implementations are totally unrelated, i.e. a call to the user-mode Rtl… function does not result in user/kernel mode transition, although ntoskrnl.exe may expose exactly the same function to drivers…
Anton Bassov