UnityHacks

I’ve looked at many P2Cs(pay-to-cheat) in the past and unity is one I’ve come back to revisit to see if they have fixed stupid design concepts that could see them detected in an instance and seems like nope. If Valve actually actively looked for what I’m about to go through in this post they would be detected maybe we should let them know 😉

Man-in-the-Middle

This concept that is utilized by unityhacks is a way of them somewhat securing their cheat loader from detection. It is basically injecting their loader code into another 32bit process and then doing the loading from there.

Unityhacks accesses the following Internet addresses:

http://authv2.unityhacks.com/v3/auth.php
http://authv2.unityhacks.com/v3/product.php

there is also one for handshake but I will not get into this area much so I’m just going over it briefly. Once the user has been authenticated the server will stream a PE image which is the loader code and the hack itself.

Obviously we can discover what is being written into the target process by hooking NtWriteVirtualMemory and even if direct systemcalls were done there are still ways of dumping the written buffer.

Now ignore the .dll extension these aren’t exactly valid PE images rather raw WPM dumps of what has happened between the loader “UnityHacks.exe” and the middle man “dummy.exe”

The first few files you see there all contain names of the imports the incoming mapped PE image will use, this is standard manual map stuff nothing interesting here

MSVCP120.dll
IPHLPAPI.DLL
WS2_32.dll
SETUPAPI.dll

What makes them more silly is the fact that they stream in the PE image header like I mean even if they didn’t you can reconstruct the sections .text .data .reloc etc when its been mapped however this just makes our lives easier. Looking at the PE image header we can see at a first glance they are using VMProtect indicated by the ‘vmp0’ section header name.

Strings of the PE Image indicate references to a hardware id function. and you can see they have some web address there of google which my guess is used for testing net connectivity.

Now this PE image is mapped into the dummy process along with a few other things. One is a segment which contains the Loaders folder path + some data about your hardware id.

The actual hack is also mapped into the MIM process however it is encrypted I mean you can kindof guess it by the filesize just look at dump_9.dll’s filesize 😛

Oh yeah there is also another module which gets mapped which they inject into Steam this is just a guess but I think it has something to do with altering vac3 and basic housekeeping functions

Hack Loader

Now when you run Steam the middle man process maps the Steam module into steam and waits for CSGO.exe

Once counter-strike global offensive is running it will begin to map itself into csgo. Once again PE header of the image is there they map the sections along with your hwid segment which has the path to the loader. The ascii path is plaintext they don’t do any xor or any other method of hiding it.

Cracking the file open in IDA we notice a few things. :0 Looks like the addresses are fixed to that instance of injection (they are based around 0x30000000). My guess is the server or the loader relocates the addresses on each run it can be fixed easily though.

Some strings are encrypted “sub_314770” using key e3ab54f47028db88209bbfce1af2bfa4 however we can see either they got lazy or forgot to encrypt these

Conclusion

A simple signature search for “\Unityhacks\” in the csgo address space will be enough to detect this cheat. Emulating the hwid function and cracking this cheat is also feasible some have done it in the past eg. CaptionJack @ r3cheats just takes a little time to write a emulator which maps the required sections and patches the image for run.

If you want a copy of the dumped files + hack image for analysis purposes pm me I will not post public links nor will I post a working crack.