MzBot

1. When it all started
Oct/Nov 2006, when my final year examination is over ( In which I slacked and scored only 73% ), I am really have an amount of time for me to spend on hacking.
One of my friend, tsj4j ( Spencer Thang, from RI ), came and ask me for a simple Autoclicker for use in Trickster Online, which also use the nProtect GameGuard. So I just use the same simple method of bypassing the usermode hook, and inject into the game process.
However, he later reported back to me that it doesn’t work!
I instructed him to briefly debug the Autoclicker, it ended up that the loophole of allowing the game process to bypass the SSDT hook is patched.
That inspired me to screw their hook.

2. November holiday, when I am bored
I went back to Taiwan on Mid November…
That was when I thought of the SSDT relocation, which is documented in both my blog ( See the MSBot case ) and in Dual’s blog.

3. Ideas put in action
At the end of the November, I wrote the driver and tested it out. ( The command line debugging utility for MzBot.sys, TiMBuS seen it before. )
The GUI is done on the 1st of December.
That night, my mom went to hospital to look after my grandpa ( who died just recently.. T_T ), so I can sleep anytime I want…
Around the midnight, I thought I want to leave something for the iNCA people, just in case it leaked out, so I wrote and embedded a letter to iNCA in MzBot. ( You all should try to get it out? )
I don’t really treat MzBot as an important project, neither would it be public, that’s why I didn’t really give it a proper protection, I only packed it with ASPR, and added a small anti-unpack ( Still can’t fool SunBeam.. )

4. Sigh…
Around the end of Feb 2007, many people in MSS requested me for MzBot, so I made a version that expires on 15 Feb, and gave it out, by sending it to them individually.
Then, somebody gave it to BrandonMS ( Thanks to SunBeam for notifying me. ), that’s how it all got leaked…

Appedix 1: Regarding the Autopotting:
The autopotting is working on my computer, so I don’t see why it isn’t working on yours…
There’s a way to make MzBot bypass MSBot or MSPro, but it is private. I only told 1 person about it, so if you are the person, you should know better than to leak.

Cont: Detour hooking without GetProcAddress() and VirtualProtect()?

It was quite some time since I last blog, since I am really quite busy. Not only did I finished my kernelmode unhooker, I also finished my usermode unhooker.

A few days ago, Uligor suggested that npggnt.des calls GetProcAddress() and VirtualProtect() by directly importing ntdll’s function — NtProtectVirtualMemory() and LdrGetProcedureAddress(). I thought, “Hey how stupid of me to not to think of that?”. The usual kernel32.dll that we import our kernel subsystem functions from, actually re-directs our request to ntdll, and GameGuard is a public software, they are expecting people to attack them for certain. Thus they should be ready for it.

However, things are not like what me and Uligor imagined. I thought in order to defeat npggnt.des, I have to know it well, so I unpacked it, and analysed it.

* Note: Click to enlarge

I viewed the IAT with LordPE, there is no sight of ntdll. This is weird, so I disassemble npggnt.des, so to see wassup in there. I also noticed that npggnt.des have 3 exports.

After some disassembly, this is what I think they are doing:
1. Inject npggnt.des
2. GameMon calls CreateRemoteThread to call the 3rd export in every running process.
3. The 3rd export hook the functions, and mean while set up a “Hook Table”.
4. It start a thread and return.
5. The thread constantly check for modification to their hook, and overwrite if found.
6. Also check for modification in npggnt.des’s first 0×9000 bytes, if found, notify GameMon through filemapping, and GameMon will close the game.

I guess I am lazy this time, so I just give their “CRC” routine and Hook check routine a “Tick ZF”… And GameGuard’s usermode hook == GameOver.

But how do they do the hooking without calling the functions mentioned in the blog entry topic? I guess I hooked the function incorrectly or they overwrited my hook, LoL!

( Note: I didn’t release where to “Tick ZF” as it is too “anti-leaking” to be left public. )

Arrogant and stubborn — Priceless. MSBot working on GameGuard rev896.

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

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!!

Detour hooking without GetProcAddress() and VirtualProtect()?

MapleStory is one of my favourite online game. I don’t really play it, I hack it.

Life ain’t good for us game hackers. The game company implemented an Anti-cheating system, called nProtect GameGuard. A nasty fellow, I have been fighting with this anti-cheating software for quite sometime already. It’s a war between us the hackers and the game company.

I decided to deal with GameGuard’s detour hooking mechanism in usermode. They overwrite the first 5 byte of a function with a jmp, and possibly a few byte after that also to prevent us from detouring the hook. Not only do they just overwrite and leave it, like normal rootkit/softwares, they repeatly overwrite it so we cannot patch their hook back, attituded huh?

I thought that is smart ( but offensive, imagine the CPU cycles it would take to do such a thing. ), but I am sure that we hackers are smarter, I guess they will have to use GetProcAddress() to retrieve the addy to the function that they are hooking, and then use VirtualProtect so that they can overwrite the bytes. So I happily set off writing a detour hook that detour GetProcAddress and VirtualProtect….

As a surprise for me, without callling those functions, they are able to access kernel32.dll and user32.dll’ memory, and change them! It’s late now, and I guess I will have to stop here and continue my war against GameGuard, tomorrow perhaps. I am sure I will have pretty much fun with it! ( I will post how they do it, possibly in the next entry! )