Cheat Engine

[linden]

I did the following things in attempt to hide all the patches I've made to ntoskrnl.exe's memory image...
1. created a dummy file of ntoskrnl.exe containing all the patches I've done to its memory image. (with all the relocs fixed, so if it is mapped to the same address as kernel base, it will look exactly like the patched kernel memory image)
2. fixed checksum field of the dummy file.
3. fixed checksum of ntoskrnl.exe's memory image to match that of the dummy file
4. hooked NtCreateFile, so if GG or any enemy process trys to open ntoskrnl.exe, I swap the file name so it reads my dummy file instead of the original. (this hook is also reflected in the dummy file)

I was able to successfully fool SVV (System Virginity Verifier by Joanna Rutkowska). But GG complains that my ntoskrnl.exe (the dummy file) file is not correct...(but the game still runs though...)

Anybody with any idea about what it's detecting or looking for
I think I've made everything to look consistent, how does it know that my file is incorrect...

Ntoskrnl.exe gets patched from time to time by windows update... so I don't suppose they'll keep a white list of checksums to compair against...

BTW, I also tried hooking MJ_READ in FSD... but GG seem to use memory mapped file for reading, now having hard time messing with PAGING_IO

[Dark Byte]

it could be nprotect keeps a list of the first few bytes of some functions for every version of windows they know.
Also, windows updates usually don't edit the kernel too much (since then the symbolfiles would need to be updated, and they still work), and if they do, they only change the first 2 bytes with a shortjump to the nops in front that in turn jump to the new code (hotpatching)

[linden]

Oh, fuck...
If they really keep a list of first few bytes from some functions, it'd be really a pain in the ass to bypass

Maybe I must try memory cloaking and page fault handler hooking...

Anyway, think I should do more research on what they are looking for...