[lorddoskias]

In some case I got BSoD due to read-only memory writing (tried to unhook Avast :D ).
I guess maybe Avast protects its hooks...

Is there a mean to not crash the system with that? maybe with a try ... catch ?

Disable Write protection from cr0?

[Tigzy]

Yes, that's true! ;)

[Tigzy]

Hello again

Replacing inline hooks works very well, except for one weird case... :cry:
I got the NtResumeThread API hooked by a malware.

With windbg, I disass the function before and after the hook:

Before:

Code: Select all

kd> u !NtResumeThread 805cad00
nt!NtResumeThread:
805cac22 6a20            push    20h
805cac24 6800a04d80      push    offset nt!ObWatchHandles+0x7b4 (804da000)
805cac29 e8e2d2f6ff      call    nt!_SEH_prolog (80537f10)
805cac2e 33db            xor     ebx,ebx
805cac30 895dfc          mov     dword ptr [ebp-4],ebx
...

After:

Code: Select all

kd> u !NtResumeThread 805cb000
nt!NtResumeThread:
805cac22 cc              int     3
805cac23 206800          and     byte ptr [eax],ch
805cac26 a04d80e8e2      mov     al,byte ptr ds:[E2E8804Dh]
805cac2b d2f6            sal     dh,cl
805cac2d ff33            push    dword ptr [ebx]
805cac2f db895dfc64a1    fisttp  dword ptr [ecx-5E9B03A3h]

We can see only a kernel trap with the 0xCC instruction.
All right, All I need to do is getting the first byte in ntoskrnl.exe and overwrite the memory.
So I do.

Here's what I get from ntoskrn at the offset getted from the API:
On the left the byte in memory, on the right the byte found in the file on the disk

Restore Inline : NtResumeThread
NtOsKrnl.exe : 0x804d7000 --> 0x806cfdff
Attempt to restore NtResumeThread : 0x805cac22
0xcc -> 0xff
0x20 -> 0x8b
0x68 -> 0xd
0x0 -> 0x80
0xa0 -> 0x79
0x4d -> 0x5b
0x80 -> 0x0
0xe8 -> 0x89
0xe2 -> 0x81
0xd2 -> 0x80
0xf6 -> 0x0
0xff -> 0x0
0x33 -> 0x0
0xdb -> 0xa1
0x89 -> 0x80
0x5d -> 0x79
0xfc -> 0x5b
0x64 -> 0x0
0xa1 -> 0x39
0x24 -> 0xb0
0x1 -> 0x80
0x0 -> 0x0
0x0 -> 0x0
0x89 -> 0x0
0x45 -> 0xf
0xd0 -> 0x84
0x8a -> 0x48
0x80 -> 0x27
0x40 -> 0x2
0x1 -> 0x0
0x0 -> 0xc6
0x0 -> 0x40

We got nothing corresponding to the disass....
Well, I say I must have a bug in my program? (even if it works with any other API), so I decided to search for the bytes in the whole file => No patterns found :o
WTF? So where does that code comes from? Is it overwrited at kernel boot? Anyone got a tip?


EDIT:

sh*t, forgot why I told.
I just realised the kernel was not only in ntoskrnl.exe, but also in ntkrnlpa.exe :D
By switching of file, I found my correct bytes

What the difference between those 2 files? They are loaded into the same module in the kernel right?

[rkhunter]

I just realised the kernel was not only in ntoskrnl.exe, but also in ntkrnlpa.exe :D
By switching of file, I found my correct bytes

What the difference between those 2 files? They are loaded into the same module in the kernel right?

ntkrnlpa.exe is a special PAE (Physical Address Extension) version of usual ntoskrnl.exe. ntldr loaded one of them, in case of boot switches and hardware configuration.

[Tigzy]

Ok, so the kernel image is only one of them?
If I need to restore some code, I simply have to get the kernel module actual filename?

[rkhunter]

Ok, so the kernel image is only one of them?

Yes, one of them will be started by loader.

If I need to restore some code, I simply have to get the kernel module actual filename?

Yes.

[Tigzy]

Ok, that should do the trick! ;)

[Tigzy]

By the way, on my code above I wrote a big mistake.
The file must be opened with "rb" (for read binary) instead of just read.

This is why I can't see most of the ntoskrnl exports. You were right rkhunter.