I am an arrogant and stubborn person, and being arrogant and stubborn at the wrong time can cost alot…
You might think that finally, this is one blog entry that doesn’t concerns computing. Then you are wrong. I am not going to talk about how I pay the price for being arrogant, instead, I am going to ellaborate on how GameGuard made the mistake, and pay the price.
Let me first explain how GameGuard blocks SendInput. GameGuard use hooking technic, in both usermode and kernelmode. GameGuard detour hook SendInput in usermode, and SSDT hook NtUserSendInput in kernelmode.
MSBot mainly bypass the usermode hook, by using Windows’ NCI ( Native Call Interface ), thus bypassing GameGuard’s usermode detour hook in user32.dll. The kernel-mode hook is somewhat tricky, TiMBuS (Author of MSBot) found out that in GameGuard’s kernel-mode hooks, GameGuard allows maplestory to call NtUserSendInput. Se he injected MSBot’s code in MapleStory.exe’s address space, and viola! It works!
Things are not so good after GameGuard rev8960+, they patched MSBot, by not allowing Maple to pass in its NtUserSendInput hook.
GameGuard prevent their SSDT hook from being unhooked, by repeatly checking that the hook is still there, and overwrite it again if changed. If they detect some entries changed, they will
Common sense tells us that we will get a reboot… Nice huh?
Recently, I was reverse engineering GameGuard’s core — dump_wmimmc.sys… and I came across this: ( I commented it.. )
This is the first time I seen them thinking for us… Probe if their hook function exist before overwriting to prevent a BSOD… ( Or they are thinking for their customer service I guess… )
Alt_KeSDTST2 is loaded on DriverEntry, with the address of KeServiceDescriptorTableShadow->ServiceTable. It is never again loaded with new value, because GameGuard strongly believes in what it believes.. ( -_-” Duh! ) I have adviced it many times to update their SSDT Service Table pointer to my dummy ServiceTable! ( LoL
) But GameGuard is arrogant and stubborn! It refuse to listen to me!
Their arrogance and stubborn comes with a price, I can misuse it to bypass their hooks…
Here’s my plan:
Note: Click to enlarge
If GameGuard is so arrogant on the address of ServiceTable base address, we can change it, without them knowing.
So this is what I will do:
1. Allocate KeServiceDescriptorTable->TableSize*sizeof( PVOID ) byte of memory
2. Copy KeServiceDescriptorTable->ServiceTable into the memory
3. Set KeServiceDescriptorTable->ServiceTable to point to the memory.
4. Wait for GameGuard to load, they will hook the memory allocated instead of the real SSDT
5. Restore KeServiceDescriptorTable->ServiceTable with the original address.
6. Do the same to KeServiceDescriptorTableShadow….
And viola! MSBot works again on rev896!!
You might think that finally, this is one blog entry that doesn’t concerns computing. Then you are wrong. I am not going to talk about how I pay the price for being arrogant, instead, I am going to ellaborate on how GameGuard made the mistake, and pay the price.
Let me first explain how GameGuard blocks SendInput. GameGuard use hooking technic, in both usermode and kernelmode. GameGuard detour hook SendInput in usermode, and SSDT hook NtUserSendInput in kernelmode.
MSBot mainly bypass the usermode hook, by using Windows’ NCI ( Native Call Interface ), thus bypassing GameGuard’s usermode detour hook in user32.dll. The kernel-mode hook is somewhat tricky, TiMBuS (Author of MSBot) found out that in GameGuard’s kernel-mode hooks, GameGuard allows maplestory to call NtUserSendInput. Se he injected MSBot’s code in MapleStory.exe’s address space, and viola! It works!
Things are not so good after GameGuard rev8960+, they patched MSBot, by not allowing Maple to pass in its NtUserSendInput hook.
GameGuard prevent their SSDT hook from being unhooked, by repeatly checking that the hook is still there, and overwrite it again if changed. If they detect some entries changed, they will
mov al, 0FEh
out 64h, al
Common sense tells us that we will get a reboot… Nice huh?
Recently, I was reverse engineering GameGuard’s core — dump_wmimmc.sys… and I came across this: ( I commented it.. )
This is the first time I seen them thinking for us… Probe if their hook function exist before overwriting to prevent a BSOD… ( Or they are thinking for their customer service I guess… )
Alt_KeSDTST2 is loaded on DriverEntry, with the address of KeServiceDescriptorTableShadow->ServiceTable. It is never again loaded with new value, because GameGuard strongly believes in what it believes.. ( -_-” Duh! ) I have adviced it many times to update their SSDT Service Table pointer to my dummy ServiceTable! ( LoL
) But GameGuard is arrogant and stubborn! It refuse to listen to me!Their arrogance and stubborn comes with a price, I can misuse it to bypass their hooks…
Here’s my plan:
Note: Click to enlarge
If GameGuard is so arrogant on the address of ServiceTable base address, we can change it, without them knowing.
So this is what I will do:
1. Allocate KeServiceDescriptorTable->TableSize*sizeof( PVOID ) byte of memory
2. Copy KeServiceDescriptorTable->ServiceTable into the memory
3. Set KeServiceDescriptorTable->ServiceTable to point to the memory.
4. Wait for GameGuard to load, they will hook the memory allocated instead of the real SSDT
5. Restore KeServiceDescriptorTable->ServiceTable with the original address.
6. Do the same to KeServiceDescriptorTableShadow….
And viola! MSBot works again on rev896!!
0 comentarios:
Publicar un comentario