HackShield Analysis

On domingo, 12 de septiembre de 2010 0 comentarios

HackShield overview

AhnLab HackShield For Online Game has numerous industry leading security features like Executable File Encryption, but lacks the 'hardware' banning system of industry rival PunkBuster. HackShield runs as a rootkit and installs its device driver when the game utilizing HackShield is installed. On later operating systems such as Windows 7, it blocks the use of compatibility mode and other features as part of anti-cheat detection.

  • Detect and terminate running hacking tools
  • Prevent packets modification
  • Memory modification prevention, anti-hooking, anti auto mouse/clicks etc.

Image

Real-time decryption of the executable program
HackShield provides real-time decryption of the encrypted program. It directly load into memory encrypted executable file and decrypt them.

Image

Linked server to prevent hacking
HackShield is sensitive to operating conditions. The game client may “ask” the server a special question and if you come out the incorrect answer protected program will be terminated.

Image

Signature based detection of hacking tools
HackShield uses anti-virus technology for blocking known hacking tools or possible hacking tools, or just any other app that looks like hacking tools.

Image

Memory modification and auto mouse/click tools
HackShield prevent any memory manipulation and can block auto click utilities, even if it only additional buttons and scripts that comes with some mouse
HackShield block the access at the kernel level

Image

Image


Block hooking and messages sending

Image

Checksum checking

Image

Preventing speed hack
Calculating time differences between client and server clock

Image

Debugging block

Image

Data encryption

Image

Signatures base updating

Image



Hack Shield Components

Hack Shield consists of:
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
V3Pro32s.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
”Function list”
AhnBootInformation
AhnCheckBootSector
AhnCheckDefaultExtensions
AhnCheckFile
AhnCheckMemory
AhnCheckProcess
AhnGetBootRepairStatus
AhnGetDefaultExtensions
AhnGetEngineDate
AhnGetEngineDateString
AhnGetEngineDateValue
AhnGetExtRepairStatus
AhnGetRepairStatus
AhnGetVersion
AhnGetVirusFileCureData
AhnGetVirusName
AhnGetVirusName32
AhnGetVirusNameStr
AhnGetVirusNameStr32
AhnInitVaccineEngine
AhnRepairBootSector
AhnRepairFile
AhnRepairMemory
AhnSetDefaultOption
AhnSetExtensions
Ctl3dAutoSubclass(x)
DllEntryPoint
DllMain(x,x,x)
PV3CALGetInfoAddr
V3CALGetInfo
V3CALGetShowInfo
V3CALGetTotalInfoCount
_AhnGetFileEntry

3N.mhe
  • The Heuristic engine file
  • Contains the patterns used to search for known hacks
psapi.dll
Process Status API
The process status application programming interface (PSAPI) is a helper library that makes it easier for you to obtain information about processes and device drivers.
The process status API (PSAPI) provides sets of functions for retrieving the following information:
  • Process Information
  • Module Information
  • Device Driver Information
  • Process Memory Usage Information
  • Working Set Information
  • Memory-Mapped File Information
The following topics list the PSAPI functions and structures:
”Function list”
EmptyWorkingSet
EnumDeviceDrivers
EnumPageFiles
EnumProcesses
EnumProcessModules
EnumProcessModulesEx
GetDeviceDriverBaseName
GetDeviceDriverFileName
GetMappedFileName
GetModuleBaseName
GetModuleFileNameEx
GetModuleInformation
GetPerformanceInfo
GetProcessImageFileName
GetProcessMemoryInfo
GetWsChanges
GetWsChangesEx
InitializeProcessForWsWatch
QueryWorkingSet
QueryWorkingSetEx

V3Warp(d)(n)s.v3d
  • The anti-hacking engine pattern file
  • Not to sure exactly what this does, but it reads the 3N.mhe file
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:

Image

Here is a graphical chart explaining how Hack Shield is started:

Image

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):
Syntax « c » : [ Download ] [ Hide ] [ Expand ]
 ////// 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());
//////

This is just pseudo code, but hopefully you get the idea. The hard part is finding the address of the function. There are some function addresses included for Combat Arms, but that's just Combat Arms. 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.
Credits: Dwar; part 2-3 of this tutorial was written by Th4natoS (ThaNatoS)

0 comentarios:

Publicar un comentario