Thanks all the useful comments, it is working now with the prototype. Without the prototype the upper DWORD part of the 64 bit address was cleared out.
I never understood the why of ObReferenceObject calls, I recelty put up with C++ and python where I learnt about reference counting of objects and even though kernel driver development is not object oriented, all starts to makes sense now.
Saved the day!
- március 27. 16:18 napon xxxxx@gmail.com írta:
PsGetProcessImageFileName is present in NTOSKRNL.LIB. So you just need the prototype.
NTSYSAPI PUCHAR NTAPI PsGetProcessImageFileName(In PEPROCESS Process);
But be careful, the returned pointer is the address of a UCHAR[15] array that belongs to the _EPROCESS structure.
kd> dt nt!_EPROCESS
+0x000 Pcb : _KPROCESS
…
+0x450 ImageFileName : [15] UChar
…This is confirmed by the disassembly:
kd> uf nt!PsGetProcessImageFileName
nt!PsGetProcessImageFileName:
fffff803b6969b30 488d8150040000 lea rax,[rcx+450h] // 0x450 is ImageFileName's offset fffff803b6969b37 c3 retSo the access should be read-only and the EPROCESS object should be referenced before it is used and dereferenced after it is used. Of course when you deal with an undocumented function, everything may vanish at any time.
You can monitor process creation/termination with PsSetCreateProcessNotifyRoutineEx and get much more reliable informations.
NTDEV is sponsored by OSR
Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:
></http:></http:></http:>