Hacker News new | ask | show | jobs
by jimaek 4510 days ago
From reddit comments:

As someone who reverse engineers things for fun, and can read the C "pseudocode" generated via decompilation pretty easily, I am going to have to disagree with the assumptions made in this post.

First, there's no proof this is from Steam, I've poked around a few of the DLLs since I saw this and am unable to find anything even remotely close to what this does.

Second, this method does NOT send anything to Valve. This method grabs the DNS cache, yes. And it MD5s the entries, then it stores it. This method itself does nothing more with the hashes. For all we know VAC could be doing a LOCAL scan of the list, and comparing it to an internal list of "known" cheat subscription servers.

Until someone posts details of exactly where in Steam this is (What DLL is all that's required to verify), and the calling method that supposedly sends this information to Valve, I would take this with a very massive grain of salt.

So yeah, no proof it sends anything. It could be a local check.

4 comments

>I've poked around a few of the DLLs since I saw this and am unable to find anything even remotely close to what this does.

This is part of the Valve anticheat system. I believe that the idea is that this sort of code is downloaded on the fly by the game client to make it harder to reverse engineer by game cheaters. What you have to do is to find some way of dumping the code that VAC pulls from the steam servers, and of course Valve tries to make that difficult for legit reasons (regardless of whether this particular snippet of code is legit).

I suppose it would just be the matter of intercepting the network traffic going between the PC running steam and the internet and see what goes through the pipe?

Do you have a link to that reddit comment thread?

EDIT: here it is: http://www.reddit.com/r/GlobalOffensive/comments/1y0kc1/vac_...

The listing of decompiled code (in image form, for your pleasure) is here: http://i.imgur.com/z9dppCk.png

IMHO the fact that they seem to store the hashes in a lookup table hints that it's meant for local use, what's the point of doing that if you just want to upload it on the net? I guess they could do both though.

That's actually sensible, but if Steam encrypt their communications, you will just get random data.

You could still infer things from the timings, but again, it is not always practical.

VAC streams the DLLs from their server at runtime, so they never actually sit on the disk. There's also a number of DLLs which are loaded and unloaded as necessary, to make it harder for attackers to dump the whole thing. I suspect that there are blackhat forums where people have discussed how to dump parts of VAC.
Generally any VAC update is met with a full dump fairly quickly on most sites.
Cheating seems to involve more effort than just playing, getting better at the game.
Reverse engineering is usually more interesting than the game.
agreed, I don't see any transmission code...

btw, help me understand the use of the DnsFree variable... why is it often exor'd with 0x23dc67e8? is that the addr of a routine and exor is faster than adding? thank you.

As it tests if it it's equal to 0x23dc67e8 after XOR, I'm guessing this is a protection against some patching or similar.

It get's XOR'd once after the GetProcAddress, then XOR'd back before the STDCALL invocation.

This is done for both the GetProcAddress calls, so I'm going to just guess that this is some anti-patching anti-cheat shenanigans.

That's just in-memory obfuscation. The value is xored with 0x23dc67e8 when set and the variable xored again whenever is used. Its first use is to check that the symbol was resolved correctly, that implies testing for NULL/0. The compiling-decompiling process made it so that it is actually just comparing the variable to the mask.