RENotes

This is a placeholder page for analysis of TF2 and SRCDS

Contents 1 Decomposition of TF2 2 Decomposition of SRCDS 3 Disassembler / Debugger Notes and Resources 4 Debugger Evasion Links 5 Hooking TF2 6 Random Notes 6.1 Darkstorm - Publicly Available Cheat 6.2 Client Side 6.2.1 FCVAR flags 6.2.2 Good source for cheat info 6.2.3 What is VAC2? 6.2.4 Ways to Hide from VAC 6.2.4.1 Module Unlinking 6.2.4.2 Removing the PE Header 6.3 Server Side

Decomposition of TF2

I think inetmsghandler.h in /public contains all the info that could be in a packet. But it doesn't really go in to packet construction. I think that must be handled somewhere else, and may not be included in the source distribution.

Decomposition of SRCDS

Disassembler / Debugger Notes and Resources

Debugger Evasion Links

http://www.teamfurry.com/wordpress/2007/02/25/avoiding-debugger-detection/

Hooking TF2

Turns out Valve is really, really open source minded with their resume writing code. w00t. We like this, but it also makes it super easy to hook it. Here I followed a tutorial written over at the somethingawful forums (back in 2008 - and you can't even go directly to it, thanks google cache) and combined that with Valve's SDK wiki and got a TF2 hook up and running. I've run through steps 1, 2, & 3. All work perfectly. Now what to do....

Unfortunately, it looks like Valve doesn't provide header files for all of the source so we'll probably have to do some additional debugging/reversing to get everything we want.

You can find the seperate parts of the tutorial on the following pages, as well as the assembler source for the dll injector:

tf2 hooking part 1

tf2 hooking part 2

tf2 hooking part 3

TF2Hook.asm

Random Notes

Darkstorm - Publicly Available Cheat

Using the Darkstorm cheat source I was able to get the following cheats working:

• Speedhack (max 7 out of 25 before the timeskew got so bad locally that my server would try to kick me)
• Auto pistol (like a pistol chain gun)
• Constant Crits - this one should be renamed to burst crits. It works by only attempting to shoot when there's a chance for a crit. Works best with soldier
• No spread - two settings here, 1 shoots blanks...go figure. 2 works reasonably well
• All the ESP hacks work for players and buildings
• Wall Hacks work
• Duck jump works
• Bunny hop works
• Duck shoot works
• No sniper scope works
• Radar works
• Still no joy on the AIM bot. It's not detecting any of the entities as players to target. Been launching bots on cp_well and trying to target them. No love. Gonna try a couple more things, but might have to bag the AIM bot.

Found the line that's causing the aimbot to die:

QAngle qPlayerAngle( 0, gPlayers[iIndex].BaseEnt( )->EyeAngles( ).y, 0 );

Client Side

FCVAR flags

FCVAR_CHEAT, recommended by developer wiki to be added to any new console commands added to your mod (unless it's a legitimate console command to be executed by the player). The game server's setting 'sv_cheats' decides if cheats are enabled or not.

If a client connects to a server where 'sv_cheats 1' then any command with FCVAR_CHEAT enabled cannot be executed.

Good source for cheat info

There's some good stuff about creating your own hooks here: http://forum.gamedeception.net/forumdisplay.php?f=266

There are so many forums out there dedicated to cheats and hacks. Their job is made easier with access to the SDK. One of the only stopping points for them are functions that aren't declared virtual, thereby not allowing them to be called by any inherited classes (i.e. dll hooks). This is really just a speedbump however, it doesn't truly stop someone from calling a function that they want to call.

How they go about getting over the speedbump: The general rule is to open up hl2.exe in IDA and look for the address of the function they wish to call, then just call the offset address directly. Apparently 'networked vars' (networkvar.h - http://developer.valvesoftware.com/wiki/Networking_Entities) contains a wealth of info. Need to take a peek at that file. According to one poster, what you can't find in there you can find by downloading the Linux binary. Lots of debug info is left in that file compared to the windows one.

Found a couple more good utilities on that site:

1. A start on hooking Direct X 10 http://www.gamedeception.net/
2. A true C++ based dll injector (loader and unloader) http://www.gamedeception.net/
3. A C++ utility that will scan memory for certain strings and extract an offset to reference in your code. Very handy because it even detects masked function signatures (TODO: see how that works) http://forum.gamedeception.net/showthread.php?t=11293

What is VAC2?

Since Valve is so open with their source they need a way to provide some sort of security for their source games. Enter VAC2 (Valve Anti-Cheat). VAC2 implies there was a VAC1, but from everything I read it was really just there to give you a warm fuzzy secure blanket feeling rather than securing anything. Apparently VAC2 isn't far off from it.

What are the challenges that VAC2 faces? First and foremost, the technical aspects of detecting a cheater isn't easy. Then, also in order to do its job effectively it needs to run in ring0 and/or scan your entire address space. Will that ever happen? Nope. Why not? Two reasons, cash and privacy. Ring0 code aint cheap. period. Ethics, Remember a little game called WoW? Ever heard of Warden? While Warden doesn't run in ring0, it does hide (really well) what it's doing from the user. In addition it scans your entire memory space for malicious code and suspect text (grabbing the titlebar of each open window). These activities brought about a slew of blog postings and remarks from privacy experts (EFF) about how WoW could be reading your emails and stealing your passwords.

How does VAC2 work? The VAC2 dll is loaded into the steam.exe process space. VAC2 sits there and looks for loaded modules in the hl2.exe process space, takes a hash of the module in memory and checks that against a signature file for known malicious hashes. That's right, signature based detection...solution: keep your cheats private.

Ways to Hide from VAC

As it turns out, hiding from VAC is much like hiding a userland rootkit. Cheaters are hackers. And some of them are good. One of these game hackers proposed the following to defeat VAC:

• Hook ReadProcessMemory (in steam.exe), and read the memory it wants to, with my detours removed (Does it use this for ALL memory checks?) Manually map all my DLLs (I'll have 2: one in hl.exe and one in steam.exe to disable VAC), strip the PE header, strip IAT names, stripping reloc section
• Enclose my dlls with 2 guard pages, and when it hits one of the pages, I remove all my detours and then encode my DLL. Then when it hits the second page, I decode my dll again and detour all functions again (This is optional, and purely as practice because it can't detect my dll since it will be just for me)
• Don't hook anything using IAT hooking or by hooking GPA, because that could be detected (I will just hook with my own detour class, since it won't see my detours anyway because I hooked ReadProcessMemory) (And I'm not even sure whether it checks this, but I want to be safe anyway)

Everyone else on the forum agreed...overkill, but that's the level of sophistication these games are up against when it comes to protecting the quality of the game. There are a few more ways you can defeat VAC: module unlinking and removing the PE header.

Module Unlinking

Removing the PE Header

Server Side

Last year around August there was a (unverified) bug where a client could crash the server by entering '_resetgamestats' into the development console.