Bypassing GameGuard SSDT hook's

To bypass SSDT hook, you do it by allocating a section of memory to the size of KeServiceDescriptorTable->TableSize*4. TableSize returns the number of entries and you multiply that by four because each entry is 4 bytes long. So anyway, once you've got your memory allocated you copy the original table into the new table and then change the tables base address to that of the new address. And you do the same for the shadow table.

[Only registered and activated users can see links. Click Here To Register...]

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?.

Ok thats what i got soo far:

 ULONG size;



unsigned realTable;



NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)



{



DbgPrint("Driver Loaded!");



PVOID *faekTable; size = KeServiceDescriptorTable->TableSize*4;



realTable = (unsigned)KeServiceDescriptorTable->ServiceTable;



faekTable = ExAllocatePoolWithTag(0, size, 0x31323334);



memcpy(faekTable, KeServiceDescriptorTable->ServiceTable, size);



(unsigned)KeServiceDescriptorTable->ServiceTable = (unsigned)&faekTable; //Found GG //Sleep(20000); (unsigned)KeServiceDescriptorTable->ServiceTable = realTable;



return STATUS_SUCCESS;



} 

Author: c0lo

thanks

Using this method, GameGuard will still have KeStackAttachProcess, KeAttachProcess and KiInsertQueueApc hooked. Fighting dump_wmimmc.sys into ring 0 is a waste of time, IMHO... or if you want to go the 'hardcore route'. Best to either kill GameGuard before it loads, and/or emulate the CSAuth2 C->S query/replies.

is it working for cabal nprotect game guard?

waw it just much more to learn

I tried a such a route at first some years ago.
It's a waste of time really as it's unnecessary.
You can disable all GG protections pretty easy if you RE GameGuard.des, and the GameLib part located in your game client.
I can disable GG with just one or two patches in both of these modules, but you will have to find out how your self (I down want to help them further harden it and find new methods).
Furthermore, this is just one part of driver. It would be better to load no driver at all, etc.

You just have to RE it down until you find vulnerabilities you can exploit.
IMHO you'd be better just keep breaking it down rather then trying odd bypass things. You'd have to have multiple patches and components. And all the things to try to maintain and update.

As a matter of fact (if you approve my other post) nProtect no longer hooks the SSDT.
It does direct kernel patches only now.
At least what I observed with rev 1896.

Incidentally what complete bullshit. GG makes these horrible root kit hacks into our OS and attaches it's self to all running applications on your machine.
Who as not had a crash occasionally after playing some GG protected game?
If the game crashes the damn global R3 hook DLL dosen't unload. Weird shit happens like you can't right click, applications
crash when you try to exit them, or maybe get a BOD ("Blue screen Of Death") from the shit driver, etc.
If you have the wrong name for a .sys driver it will even just reboot your system with out notice.
When you install a game there is no mention of this.
But Microsoft has no problem with code signing this crap (along with similar HackSheild, etc).
Just maybe no one has brought the issue to MS, yet or publicized it enough so they cancel their certificate et al.