Defeating Hackshield
Disabling Hackshield is pretty easy and means basically hooking/patching the functions "StartServiceW" of the Hackshield class which is an export of EhSvc.dll.
Either its wrapper inside of Engine.dll, or directly in EhSvc.dll. Just do nothing and return - that's all.
However, after doing that MakeGUIDAckMsg() and MakeAckMsg(), both exports of EhSvc.dll will stop working and therefore we can't authenticate with the gameserver anymore.
To solve that issue one way would be to patch all "has hackshield been started" checks in side of those Make..Msg() functions,it will work fine, however it has one big downside. To understand it , we have to look at how these functions "generate" the authentication answers.
1.) MakeGUIDAckMsg()
In short this functions reads the GUID of EhSvc.dll (16 bytes) directly from that file on your harddisk, encrypts it and sends it to the server.
Okay, that shouldn't be a big deal, we just have to make sure that these 16 bytes remain intact and we are safe.
2.)MakeAckMsg()
This function is a bit more complicated, it does:
-generate a file checksum of RagII.exe
-generate a file checksum of EhSvc.dll and EGRNAP.dll
-generate a file checksum of v3warpns.v3d and v3warpds.v3d
-generate a proccess memory checksum of up to 32 function addresses in proccess-memory
It's important to know that the RagII.exe checksum is calculated "dynamicly" as i name it, that means:
the gameserver sends hackshield a start-offset and a size for a part of RagII.exe.
These values will be random, so the checksum will always be different.
The other checksums are static, so they will always be the same.
The memory checksum is the most annoying part of that authentication, that's because the function addresses are given by the server (they can be random), making it very powerfull.
As we don't know which memory locations might be requested, we can't be sure our modifications will be detected or not.
Back to topic : that's the downside i've talked of earlier: just forcing the auth-answers to be enabled will enable the game-server to detect any modifications to the checked files and any memory locations.
Of course we can redirect the file checks to backuped files in another location pretty easily, but the memory scans are very hard to fool (as RagII.exe,Engine.dll,etc are packed with TheMida file-data will NOT match memory-data on run-time)
To come by that issue, i've re-written both MakeGUIDAckMsg() and MakeAckMsg() , put them inside my hack and redirected all calls to the originals functions to my Make..Msg() functions.
At proccess startup, i take a snapshot of the important memory locations (RagII.exe, Engine.dll, etc). Now if the server requests MakeAckMsg() data, i use the snapshots instead of the current memory data. >> Hackshield is fully bypassed!
Remarks
- currently only the OEP of RagII.exe is checked by the memory check, this is pretty weak (its always the same check - same checksum returned)
- in future grav could use these memory checks to fights bots somehow,
HOWEVER:
-> bots that work together with the original client can be easily implemented without detailed knowlegde of hackshield
-> these challenges are only used once at connect, never during gameplay > weak
-> stand-alone bots are affected by this memory checks, however the only challenge is knowlede of the unpacked .exe/.dll data (and only if they'll start to make memory checks being random, which is not the case atm)
So be careful, if the memory location you are patching is inside the memory of the game's .exe file, the authentication message (if the game is using them), will detect your hack, or at least be able to do so in future, if the game server gets updated to check that location.
DeadlyData