[Stylo]

Well.. i've tried to access the eprocess on my windows 7 x64 machine and when i tried to print the process id i got bsod.
that's the code sample from the driver

Code: Select all

EPROCESS eProcess;
INT iProcess;

eProcess = PsGetCurrentProcess();
iProcess = (INT)eProcess; // that's how i access to eprocess (works on win xp)
DbgPrint("Process Id: %d\r\n", *(INT*)(iProcess + 0x188)); // 0x188 = process id offset on eprocess structure for windows 7 x64

In which method are you using to access the EPROCESS?

[0x16/7ton]

In case of processID,is safer to use this document function :

Code: Select all

HANDLE PsGetProcessId(
  _In_  PEPROCESS Process
);

http://msdn.microsoft.com/en-us/library ... s.85).aspx
Directly access to EPROCESS it is not good solution i think...

[r2nwcnydc]

You are casting the pointer to an INT then using the value as a pointer again. On 32 bit this fine, because the pointer is 32 bits long (same as an INT), but on 64 bit it is not. You lose the upper 32 bits of the pointer, and you may even convert the upper 32 bits to 0xffffffff when you convert back to a 64-bit pointer. The below code should work (I have NOT tested it, though).

Code: Select all

PEPROCESS eProcess;
INT* iProcess;

eProcess = PsGetCurrentProcess();
iProcess = (INT*)eProcess; // that's how i access to eprocess (works on win xp)
DbgPrint("Process Id: %d\r\n", *(iProcess + 0x62)); // 0x62 = (0x188/sizeof(INT)) = process id offset on eprocess structure for windows 7 x64

[EP_X0FF]

@Stylo

1. IDK why from all methods available you decided to use most hardcore, bugged and not portable.
Just a coupe of methods:
a) PsGetProcessId (already mentioned). Even no need type casts.
b) ObReferenceObjectByPointer, ZwQueryInformationProcess (double overhead as you want _current_ process id).
c) Your hardcore method

2. Your offset is incorrect. For all Windows 7 x64 it is:

Code: Select all

+0x180 UniqueProcessId  : Ptr64 

[Stylo]

Yeah but what if i want to access other fields than process id (like ActiveProcessLinks or token)?

[EP_X0FF]

Yeah but what if i want to access other fields than process id (like ActiveProcessLinks or token)?

And why do you need this?

[Stylo]

Hiding process for example..
just trying to mess around in kernel mode

[EP_X0FF]

Hiding process will lead to delayed BSOD on x64. Overall: if the field cannot be accessed anyhow through kernel mode API, only the way to read/change it - offsets.

[Stylo]

Hiding process will lead to delayed BSOD on x64.

Really?? How come?!
what will happen if i redirect the Flink / Blink fields at ActiveProcessLinks that should cause BSOD?

Overall: if the field cannot be accessed anyhow through kernel mode API, only the way to read/change it - offsets.

I'm trying to access it through it's offset but getting BSOD..

[Vrtule]

Really?? How come?!
what will happen if i redirect the Flink / Blink fields at ActiveProcessLinks that should cause BSOD?

I think this list of EPROCESS structures is guarded by Kernel Patch Protection (Patchguard).

Of course, you can read/write some EPROCESS members directly AFAIK. But keep in mind that offsets of the fields can change with new version of Windows or with a new Service Pack. This applies to other kernel data structures as well. For example, there was a quite major change in Object Type structures between Vista and Vista SP1 because of introduction of OB Filtering Model.

And do not cast pointers to ints, use (U)LONG_PTR if you need to treat them as unmbers.