Home › Forum › MultiPlayer Game Hacks & Cheats › Combat Arms Hacks & Cheats › Combat Arms Hack Coding / Programming / Source Code › Hacksheild Analysis
Hacksheild Analysis
Hacksheild Analysis
Thanks to: Th4nat0s, DeadlyData, Micheal87, & lolz2much
This is some basic information about HShield, the way it works, etc. Of course you need to be much more specific to actually do something with this, and I think it might be a little dated, but HS should still be structured the same way. Unfortunately I wasn't able to find Th4nat0s' Hacksheild Analysis, that one is most recent, so if anyone can find it plz tell me or add it to this thread.
Thanks to headsup for finding the damned thing!
Hack Shield Analysis
Hi there, and welcome to my ultimate information dump on Hack Shield, one of the best Anti-Cheat services ever made. Today you will essentially learn what Hack Shield is made of, how Hack Shield works, and you will even learn some new bypassing ideas.
Index
Hack Shield Components
Hack Shield consists of:
1) EhSvc.dll:
2) V3Pro32s.dll:
3) 3N.mhe:
4) psapi.dll:
5) V3Warp(d)(n)s.v3d:
6) EagleNT.sys:
2. Hack Shield Flow
Here is a graphical chart explaining how all the components work together:
[IMG]http://i254.photobucke*****m/albums/hh113/McElf223/structure.jpg[/IMG]
Here is a graphical chart explaining how Hack Shield is started:
[IMG]http://i254.photobucke*****m/albums/hh113/McElf223/hs_pc.jpg[/IMG]
**If I were you I would pay attention to those function names!
3. Bypassing Theory
So, we got some nice information about Hack Shield. How do we bypass it? I will tell you right now, I'm going to show you some very unconventional and new ideas. Say goodbye to your petty API and ASM bypasses, and say hello to your new best friend: detouring. Before we continue, you should have a strong foundation in detouring. If you don't, I recommend watching this.
So what functions do we detour? In reality, you are going to be detouring CallBack. The CallBack function in Hack Shield collects data from the Hack Shield service. The data is usually errors or "Hack Detected" type messages. The goal of course is to stop it from getting the Hack Detected messages, or stop it from alerting the game client that there is a "Hack Detected" message. The first goal is to find the actual name of the function. The next step is to rebuild the params of the function. The next step is to find the address of this function. Then finally you detour it. Here is my example (not working probably):
This is just pseudo code, but hopefully you get the idea. The hard part is finding the address of the function. I have my way of getting it, but I'm leaving it up to you to figure out how to get the address. I don't want to completely hand feed you a working bypass. There are a couple ways to get it.
As a conclusion, I just want to say that you need to use your imagination! Find different functions. Find different ways to bypass. Rip Hack Shield apart. Keep in mind that you can gain access to hooked functions by stopping the Hack Shield anti-hack service.
Originally Posted by DeadlyData
Originally Posted by Micheal87
This is some basic information about HShield, the way it works, etc. Of course you need to be much more specific to actually do something with this, and I think it might be a little dated, but HS should still be structured the same way. Unfortunately I wasn't able to find Th4nat0s' Hacksheild Analysis, that one is most recent, so if anyone can find it plz tell me or add it to this thread.
Thanks to headsup for finding the damned thing!
Hack Shield Analysis
Hi there, and welcome to my ultimate information dump on Hack Shield, one of the best Anti-Cheat services ever made. Today you will essentially learn what Hack Shield is made of, how Hack Shield works, and you will even learn some new bypassing ideas.
Index
- Hack Shield Components
- Hack Shield Flow
- Bypassing Theory
Hack Shield Components
Hack Shield consists of:
1) EhSvc.dll:
- EhSvc is the Hack Shield interface dll
- It communicates between the game client and Hack Shield
- It communicates with the Hack Shield driver (EagleNT.sys)
- It initiates the hack tool detection engine
- This is usually the only file needed to create a workable bypass
Code:
0x10000000 0 (0x0) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 1 0x1000af00 0x0000af00 1 (0x1) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 10 0x1000ca80 0x0000ca80 10 (0xa) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 12 0x1000ca40 0x0000ca40 12 (0xc) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 13 0x1000ad60 0x0000ad60 13 (0xd) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 14 0x1000c760 0x0000c760 14 (0xe) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 15 0x10009c70 0x00009c70 15 (0xf) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 16 0x1000c7c0 0x0000c7c0 16 (0x10) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 17 0x1000aba0 0x0000aba0 17 (0x11) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 18 0x1000ca60 0x0000ca60 18 (0x12) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 19 0x1000c500 0x0000c500 19 (0x13) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 2 0x1000c980 0x0000c980 2 (0x2) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 20 0x1000cd70 0x0000cd70 20 (0x14) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 21 0x1000d080 0x0000d080 21 (0x15) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 22 0x1000ce70 0x0000ce70 22 (0x16) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 23 0x1000b5f0 0x0000b5f0 23 (0x17) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 24 0x1000b090 0x0000b090 24 (0x18) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 25 0x1000d0b0 0x0000d0b0 25 (0x19) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 26 0x1000ce90 0x0000ce90 26 (0x1a) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 3 0x1000a930 0x0000a930 3 (0x3) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 4 0x1000c630 0x0000c630 4 (0x4) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 5 0x1000a960 0x0000a960 5 (0x5) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 6 0x10008dc0 0x00008dc0 6 (0x6) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 7 0x1000a980 0x0000a980 7 (0x7) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 8 0x1000ca20 0x0000ca20 8 (0x8) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll 9 0x1000ac80 0x0000ac80 9 (0x9) EHSvc.dll C:\Nexon\Combat Arms\HShield\EHSvc.dll
- This is the hacking tool detection interface dll
- This starts the hacking tool detection engine
- This is helps the scanning of known hack signatures
- A very important file. This could interrupt the Hack Shield driver if correctly intercepted
Code:
addies for various functions of above dll _AhnGetFileEntry 0x1000bb9c 0x0000bb9c 30 (0x1e) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnBootInformation 0x1000b16f 0x0000b16f 1 (0x1) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnCheckBootSector 0x1000b177 0x0000b177 2 (0x2) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnCheckDefaultExtensions 0x1000124a 0x0000124a 3 (0x3) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnCheckFile 0x1000ba5e 0x0000ba5e 4 (0x4) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnCheckMemory 0x1000b160 0x0000b160 5 (0x5) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnCheckProcess 0x1000b79d 0x0000b79d 6 (0x6) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetBootRepairStatus 0x1000b5b9 0x0000b5b9 7 (0x7) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetDefaultExtensions 0x1000126b 0x0000126b 8 (0x8) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetEngineDate 0x100013fd 0x000013fd 9 (0x9) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetEngineDateString 0x1000145c 0x0000145c 10 (0xa) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetEngineDateValue 0x10001449 0x00001449 11 (0xb) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetExtRepairStatus 0x1000b287 0x0000b287 12 (0xc) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetRepairStatus 0x1000b1b4 0x0000b1b4 13 (0xd) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetVersion 0x100014f7 0x000014f7 14 (0xe) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetVirusFileCureData 0x1000120b 0x0000120b 15 (0xf) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetVirusName 0x100010d1 0x000010d1 16 (0x10) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetVirusName32 0x1000108c 0x0000108c 17 (0x11) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetVirusNameStr 0x1000116c 0x0000116c 18 (0x12) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnGetVirusNameStr32 0x100010ab 0x000010ab 19 (0x13) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnInitVaccineEngine 0x1000b600 0x0000b600 20 (0x14) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnRepairBootSector 0x1000b17e 0x0000b17e 21 (0x15) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnRepairFile 0x1000eea0 0x0000eea0 22 (0x16) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnRepairMemory 0x1000b167 0x0000b167 23 (0x17) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnSetDefaultOption 0x1000ba89 0x0000ba89 24 (0x18) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll AhnSetExtensions 0x10001295 0x00001295 25 (0x19) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll PV3CALGetInfoAddr 0x1000a0fe 0x0000a0fe 26 (0x1a) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll V3CALGetInfo 0x1000a0c2 0x0000a0c2 27 (0x1b) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll V3CALGetShowInfo 0x1000a080 0x0000a080 28 (0x1c) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll V3CALGetTotalInfoCount 0x1000a0b9 0x0000a0b9 29 (0x1d) v3pro32s.dll C:\Nexon\Combat Arms\HShield\v3pro32s.dll
3) 3N.mhe:
- The Heuristic engine file
- Contains the patterns used to search for known hacks
4) psapi.dll:
- The process status helper dll
- Helps scan process signatures and control process functions
Code:
EmptyWorkingSet 0x76a61e20 0x00001e20 1 (0x1) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll EnumDeviceDrivers 0x76a615a3 0x000015a3 2 (0x2) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll EnumPageFilesA 0x76a63b3c 0x00003b3c 3 (0x3) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll EnumPageFilesW 0x76a639cd 0x000039cd 4 (0x4) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll EnumProcesses 0x76a634a9 0x000034a9 6 (0x6) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll EnumProcessModules 0x76a61a8a 0x00001a8a 5 (0x5) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetDeviceDriverBaseNameA 0x76a61748 0x00001748 7 (0x7) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetDeviceDriverBaseNameW 0x76a61823 0x00001823 8 (0x8) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetDeviceDriverFileNameA 0x76a616cd 0x000016cd 9 (0x9) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetDeviceDriverFileNameW 0x76a617c7 0x000017c7 10 (0xa) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetMappedFileNameA 0x76a61945 0x00001945 11 (0xb) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetMappedFileNameW 0x76a6187f 0x0000187f 12 (0xc) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetModuleBaseNameA 0x76a61d2f 0x00001d2f 13 (0xd) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetModuleBaseNameW 0x76a61cb2 0x00001cb2 14 (0xe) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetModuleFileNameExA 0x76a61c4a 0x00001c4a 15 (0xf) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetModuleFileNameExW 0x76a61bcd 0x00001bcd 16 (0x10) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetModuleInformation 0x76a61d97 0x00001d97 17 (0x11) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetPerformanceInfo 0x76a6382d 0x0000382d 18 (0x12) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetProcessImageFileNameA 0x76a637a9 0x000037a9 19 (0x13) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetProcessImageFileNameW 0x76a6371b 0x0000371b 20 (0x14) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetProcessMemoryInfo 0x76a635c2 0x000035c2 21 (0x15) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll GetWsChanges 0x76a636e1 0x000036e1 22 (0x16) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll InitializeProcessForWsWatch 0x76a6369d 0x0000369d 23 (0x17) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll QueryWorkingSet 0x76a61e8b 0x00001e8b 24 (0x18) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll QueryWorkingSetEx 0x76a61ec7 0x00001ec7 25 (0x19) psapi.dll C:\Nexon\Combat Arms\HShield\psapi.dll
- The anti-hacking engine pattern file
- Not to sure exactly what this does, but it reads the 3N.mhe file
6) EagleNT.sys:
- The Hack Shield kernel driver
- Performs anti-hacking functions, protects the game client's process, and hooks certain API's, rendering them useless
- If successfully uninitiated, it could enable the use of many API's and functions such as Read/WriteProcessMemory.
2. Hack Shield Flow
Here is a graphical chart explaining how all the components work together:
[IMG]http://i254.photobucke*****m/albums/hh113/McElf223/structure.jpg[/IMG]
Here is a graphical chart explaining how Hack Shield is started:
[IMG]http://i254.photobucke*****m/albums/hh113/McElf223/hs_pc.jpg[/IMG]
**If I were you I would pay attention to those function names!
3. Bypassing Theory
So, we got some nice information about Hack Shield. How do we bypass it? I will tell you right now, I'm going to show you some very unconventional and new ideas. Say goodbye to your petty API and ASM bypasses, and say hello to your new best friend: detouring. Before we continue, you should have a strong foundation in detouring. If you don't, I recommend watching this.
So what functions do we detour? In reality, you are going to be detouring CallBack. The CallBack function in Hack Shield collects data from the Hack Shield service. The data is usually errors or "Hack Detected" type messages. The goal of course is to stop it from getting the Hack Detected messages, or stop it from alerting the game client that there is a "Hack Detected" message. The first goal is to find the actual name of the function. The next step is to rebuild the params of the function. The next step is to find the address of this function. Then finally you detour it. Here is my example (not working probably):
Code:
////// Declares //////
#define CallBackAddy 0x0000001
typedef int ( *PFN_AhnEH_Callback)( long lCode, long lParamSize, void* pParam ); //the name of the function actually is PFN_AhnEH_Callback
PFN_AhnEH_Callback pAhnEH_Callback; //Defining our function
//////
////// Our new function //////
int _CallBackThread()
{
DWORD dwCode = YOUR_CODE_TO_PASS;
int myReturn = pAhnEH_Callback(dwCode, 0, NULL);
return myReturn;
}
//////
////// Our Detour //////
pAhnEH_Callback = (PFN_AhnEH_Callback)DetourFunction( (PBYTE)( Ehsvc + CallBackAddy ), (PBYTE)_CallBackThread());
//////
As a conclusion, I just want to say that you need to use your imagination! Find different functions. Find different ways to bypass. Rip Hack Shield apart. Keep in mind that you can gain access to hooked functions by stopping the Hack Shield anti-hack service.
Originally Posted by DeadlyData
Reason for writing this/Why I bypass it the way I do:
First my reason for writing this is the anti-cheat is really shitty and so far there has been no real documentation on it released online that I've found, besides my own.
Secondly the reason I bypass it the way I do, Is it's the easiest way I or any one else with less experience can.
A couple days to a week or so ago I hardly understood what a hook or detour would really do nor did I understand how system drivers worked... I've always been more of a web based person as far as security.
Any way to continue for some of you guys, I'm sure you could simply unload the driver and recreate the heart beat of the anti-cheat so that hack shield is just simply no longer resident on your system.
That how ever isn't my way around it I've found several and will explain the ways I've taken so far below.
How hack shield works(From my view):
So far the way I see hack shield works(And try not to bash me if I say something incorrectly just correct it)...
Your game client will load upon your game client loading it will load a external library which is usually hack shield's interface dll "EhSvc.dll".
From this point I wasn't able to do much analysis my self on account of "EhSvc.dll" was packed with themida in my game target.
From here though "EhSvc.dll" will continue by loading several other things one of those things being the system driver "EagleNT.sys".
EagleNT.sys creates several SSDT hooks preventing a user from using things like WriteProcessMemory() or ReadProcessMemory() on the target game it's protecting.
How ever there are memory searching utilities out there like cheat engine that are open source and people decide to modify these using different calls to avoid the hooks.
When using one of these you will how ever still get detected if you manage to get around the SSDT hooks.
The detection is passed either from the driver or the dll into the game's main exe from there the game will give you the message like "Illegal Memory Access Detected".
So bassicly it's a system driver and a dll interacting with each other thats pretty much how it works to sum it up things are also passed and controlled by the game as far as detection goes though.
Bypassing it(My way):
Since things are just passed through the games exe I usually just unpack the games exe(Usually hack shield targets come packed with "UPX" - Of all things).
Open the games unpacked exe in IDA find the string which I received - E.X. "Illegal Memory Access Detected".
And head above the the string to the main jump that pretty much goes through all of the different detection messages.
It's usually always a JG once this is nopped it no longer shows the detection messages nor attempts to close your game if detected...
More in depth with the method below.
Bypassing (More In depth/Tutorial):
Start by going through the string table in IDA until you see the "detected" string that was in the message box.
From there double click on it...
Then go to the reference of it (The push of the offset):
Go to the reference of the push... which is a jmp.
Go to the reference of that jmp which is another jmp just a jump if greater...
And last the reference to that JG(Jump if greater) is where you set your 2 byte nop... bypassing the detection completely.
Yeah it's completely played out this way for every game it's in... so this will work on most games using hack shield.
Hope this helps some of you guys...
First my reason for writing this is the anti-cheat is really shitty and so far there has been no real documentation on it released online that I've found, besides my own.
Secondly the reason I bypass it the way I do, Is it's the easiest way I or any one else with less experience can.
A couple days to a week or so ago I hardly understood what a hook or detour would really do nor did I understand how system drivers worked... I've always been more of a web based person as far as security.
Any way to continue for some of you guys, I'm sure you could simply unload the driver and recreate the heart beat of the anti-cheat so that hack shield is just simply no longer resident on your system.
That how ever isn't my way around it I've found several and will explain the ways I've taken so far below.
How hack shield works(From my view):
So far the way I see hack shield works(And try not to bash me if I say something incorrectly just correct it)...
Your game client will load upon your game client loading it will load a external library which is usually hack shield's interface dll "EhSvc.dll".
From this point I wasn't able to do much analysis my self on account of "EhSvc.dll" was packed with themida in my game target.
From here though "EhSvc.dll" will continue by loading several other things one of those things being the system driver "EagleNT.sys".
EagleNT.sys creates several SSDT hooks preventing a user from using things like WriteProcessMemory() or ReadProcessMemory() on the target game it's protecting.
How ever there are memory searching utilities out there like cheat engine that are open source and people decide to modify these using different calls to avoid the hooks.
When using one of these you will how ever still get detected if you manage to get around the SSDT hooks.
The detection is passed either from the driver or the dll into the game's main exe from there the game will give you the message like "Illegal Memory Access Detected".
So bassicly it's a system driver and a dll interacting with each other thats pretty much how it works to sum it up things are also passed and controlled by the game as far as detection goes though.
Bypassing it(My way):
Since things are just passed through the games exe I usually just unpack the games exe(Usually hack shield targets come packed with "UPX" - Of all things).
Open the games unpacked exe in IDA find the string which I received - E.X. "Illegal Memory Access Detected".
And head above the the string to the main jump that pretty much goes through all of the different detection messages.
It's usually always a JG once this is nopped it no longer shows the detection messages nor attempts to close your game if detected...
More in depth with the method below.
Bypassing (More In depth/Tutorial):
Start by going through the string table in IDA until you see the "detected" string that was in the message box.
From there double click on it...
Then go to the reference of it (The push of the offset):
Go to the reference of the push... which is a jmp.
Go to the reference of that jmp which is another jmp just a jump if greater...
And last the reference to that JG(Jump if greater) is where you set your 2 byte nop... bypassing the detection completely.
Yeah it's completely played out this way for every game it's in... so this will work on most games using hack shield.
Hope this helps some of you guys...
Originally Posted by Micheal87
Instead of just dumping reversed funcstions here I've decided to write a bit about Hackshields in general here. A fancy pdf might follow.
Let's start with the files that come along with hackshield, these are:
- EhSvc.dll
the main Hackshield file, contains the HackShield class used by Engine.dll,
does the basic functions like loading/unloading its kernel mode driver, file integrity scanning,
memory integrity scanning. the checksum generated by the integrity scans are used to authenticate with the game-server
- v3warpns.v3d and v3warpds.v3d
contain each a kernel mode driver (.sys file) in encrypted from, one v3d contains a win9x driver the other a winNT driver.
once the driver has been loaded it will protect the ro process from being accessed (read/write) by every non-kernel mode programm
(example: taskmanager)
- v3pro32s.dll
i didn't look at it yet, but i suspect it to be the loader for the .sys driver files (.v3d files)
maybe not written by Hackshield creators
- EGRNAP.dll and EGRNAPX2.dll
ahhnlab "anti-virus" scanning libs, probably used to scann for programms like packet sniffers, memory editors etc
- Hshield.log
produced by EhSvc.dll, its encrypted with an evolving XOR key, i've reversed that algo, its included in my hackshield emu source & there's a ready to use decryption tool in SagaTools, however it doesn't contain much useful info (basically logs detections/checksum errors for gravity/hackshield to investigate)
- psapi.dll
a proccess helper library by Microsoft, nothing special
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)
Let's start with the files that come along with hackshield, these are:
- EhSvc.dll
the main Hackshield file, contains the HackShield class used by Engine.dll,
does the basic functions like loading/unloading its kernel mode driver, file integrity scanning,
memory integrity scanning. the checksum generated by the integrity scans are used to authenticate with the game-server
- v3warpns.v3d and v3warpds.v3d
contain each a kernel mode driver (.sys file) in encrypted from, one v3d contains a win9x driver the other a winNT driver.
once the driver has been loaded it will protect the ro process from being accessed (read/write) by every non-kernel mode programm
(example: taskmanager)
- v3pro32s.dll
i didn't look at it yet, but i suspect it to be the loader for the .sys driver files (.v3d files)
maybe not written by Hackshield creators
- EGRNAP.dll and EGRNAPX2.dll
ahhnlab "anti-virus" scanning libs, probably used to scann for programms like packet sniffers, memory editors etc
- Hshield.log
produced by EhSvc.dll, its encrypted with an evolving XOR key, i've reversed that algo, its included in my hackshield emu source & there's a ready to use decryption tool in SagaTools, however it doesn't contain much useful info (basically logs detections/checksum errors for gravity/hackshield to investigate)
- psapi.dll
a proccess helper library by Microsoft, nothing special
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)
Similar Threads
- 20Last post
- 26Last post
- 25Last post
