Disk and memory PE headers comparision

[rabbitstack]

I apologize if this is a bit off-topic. I'm trying to port some of the pe-sieve implant detection techniques to Fibratus. I'm already using a PE parser package that does all the heavy lifting of dissecting the PE structure from the on-disk image file. As usual, ReadProcessMemory is used to fetch the in-memory PE layout from the image base address. However, when it comes to comparing the PE headers, I'm hitting the wall. It turns out, only the few first fields of the DOS header are identical in both on-disk and memory PEs, while the rest of the headers differ. I know I'm missing something obvious. Could you please elaborate on how exactly pe-sieve "normalizes" the PE buffers to make possible headers comparison?
Thanks

[hasherezade]

hi @rabbitstack !
You can see details of it in the HeadersScanner class:
https://github.com/hasherezade/pe-sieve/blob/master/scanners/headers_scanner.cpp

[hasherezade]

@rabbitstack - did you observe the same behavior in case of other applications too? which ones are affected?
Unfortunately I don't have an access to a machine with Windows 11 right now, so I cannot test it...
But hopefully seeing the output from PE-sieve would give me some more hints. I need to see all the paths that it scanned.
By seeing the headers I am starting to suspect that the image path is different here than the path of the actual mapped executable.

[rabbitstack]

Hi @hasherezade ,

I believe I've found the root cause for this funny behavior. Your assumption was correct when you stated a different image could end up mapping into the process address space. So, basically, the local PE was parsed from the C:\Windows\notepad.exe, while spinning up the process for this image would in reality load the C:\Program Files\WindowsApps\Microsoft.WindowsNotepad_11.2306.15.0_x64__8wekyb3d8bbwe\Notepad\Notepad.exe executable image.

Thank you for your time and patience.

Kind regards.

[hasherezade]

hi @rabbitstack !
I am glad it got solved! Yes, sometimes Windows does this implicit path redirection. Another thing you need to be careful about it FS redirection between System32 and SysWow64 paths. If not disabled, it causes an implicit conversion of System32 paths to SysWow64 when the path is requested by a 32-bit application. So you may again read a different version of the same executable. Just something to keep in mind.

If everything is clarified now, feel free to mark this question as answered.

[rabbitstack]

Thanks for the clarification and the heads-up about path redirection. I don't seem to be able to mark the reply as answered. Apparently, only discussions pertaining to the Q/A category can be marked as answered. I'm willing to close this discussion as resolved if this sounds right to you.

[hasherezade]

yeah, closing the discussion is fine :)