Page 1 of 1
Can i hook system process, it's pid is 4
Posted: Thu Jun 12, 2014 3:31 pm
by Fengyun
Hi, I want to monitor share file access, how can i hook the "system" process, it's pid is 4
Re: Can i hook system process, it's pid is 4
Posted: Thu Jun 12, 2014 4:00 pm
by madshi
Fengyun wrote:Hi, I want to monitor share file access, how can i hook the "system" process, it's pid is 4
Hooking the "system" process is currently not really supported, because it's a "native" process and as such follows slightly different rules. E.g. it doesn't have kernel32.dll loaded by default etc...
Re: Can i hook system process, it's pid is 4
Posted: Thu Jun 12, 2014 4:06 pm
by Fengyun
Thank you！but "Process Monitor" hooked system read share file, is "Prcess Monitor" tool Hooked system call table in kernel mode？
Re: Can i hook system process, it's pid is 4
Posted: Thu Jun 12, 2014 10:11 pm
by madshi
I'm not 100% sure what the Process Monitor does, but I think it's very likely using a little driver to do such things. In driver land it's relatively easy to install a mini filter to get notified about all file system accesses.
Re: Can i hook system process, it's pid is 4
Posted: Sun Jun 15, 2014 3:32 am
by iconic
@Fengyun,
As Madshi already correctly mentioned, SYSTEM Process (process id 4) is a "special" native process and it doesn't load kernel32.dll so it's nothing like a typical Win32 process, it's not even similar in functionality to the SMSS process (also native and doesn't load kernel32.dll). It's literally the kernel and all loaded drivers wrapped into a pseudo virtual process, a "container" process best describes it. If you're a kernel mode programmer you can verify this by calling PsLookupProcessByProcessId() on process id 4. If you compare the returned EPROCESS address to that of the "global" kernel variable PsInitialSystemProcess, which also is a pointer to SYSTEM's EPROCESS block, the addresses will definitely match... so again this isn't a typical process suitable for injection and/or hooking.
Furthermore, if you open a tool like Process Explorer and examine the thread start addresses of running threads in the system process you'll see that it doesn't deal with addresses < 0x80000000, consider it a virtual container process for the kernel. It's the best description I can give. You can manipulate some aspects of the ring 3 virtual memory for SYSTEM but if I am not mistaken it only needs to load ntdll.dll last I checked and since it's always the first process to run those calls aren't needed after the OS is booted, the thread context switches to kernel land and that's where it does its processing. By the way, back in the Windows 2000 days SYSTEM had the process id of 8, not 4. Figured that would be an interesting fact if you're the nostalgic type.
--Iconic