VAC Module Overview (2/2)

The time has finally arrived to round out my VAC3 module overview (previous installments here and here). Same conditions as before still apply.

I’ve been a bit lazier with this one than in previous installments because I’ve been so busy recently and I haven’t really had any good chunks of time on the weekend to work on this. I haven’t finished reversing every single corner case of the modules before posting like I did for the last two posts, however given that this is only an overview anyway it doesn’t matter. So, my apologies if this post reads like it was rushed, but that’s because it was. :)

20150326-201829: Three scans. The first simply checks whether a file specified in the scan parameters exists and is accessible. The second retrieves events from the Steam service process monitor (which uses ETW to track process starts/stops). The third retrieves information on a specific PID from the process monitor (it gets the path, which is then used to look up the VSN and file index), along with some PE header metadata of steamservice.dll, and the full data and vtable of the process monitor provider. I may go into further detail about the Steam service process monitor component in the future, but in the meantime curious parties can get started by looking for the string “Steam_{E9FD3C51-9B58-4DA0-962C-734882B19273}_Pid:%000008X” in steamservice.dll.

20150422-164633: Two scans. The first returns information on processes which have an open handle to a process (i.e. the game). This is similar in concept to the system profiler component which the 20140422-222301 module returns the data for, however it is different in implementation. Along with the actual data being returned being different, the key differences are the fact that it utilizes manual syscalls (including using native x64 code on x64 processors instead of using the OS thunking), presumably to bypass usermode API hooks, and also that it runs in Steam instead of the game which means that in most cases it is running at a higher privilege level. The second scan appears to be detecting modified cvars for the purposes of cheating. Interestingly, while this scan appears to be specific to Dota 2 (it’s the only game I found with an engine.dll which contained the necessary code for the scan to actually work) I was unable to trigger it even during a Dota 2 game, so it may be inactive at the moment.

20150609-214236: Four scans. The first returns information about the modules loaded in a process (path, name, flags indicating various properties of the file, vsn and file index, hash, base address, name and path hash, mapping size, etc.). The second returns information about a specific module or file (or memory region in the case of a manually mapped module), including path, various PE file characteristics (headers, timestamp, checksum, pdb path, icon hash, section hashes, etc), VSN and file index, etc. It also returns strings found in the file/region, and finally it also does some “sig scanning” via function and/or string hashing and flags any matches, as well as containing some additional even more targeted checks for specific cheats. This is definitely the scan to look into if you want to know how VAC operates, because my guess is that this is how they catch the majority of cheats. Please note that I’ve been intentionally vague about the details of this particular scan so as not to allow my work to be leveraged by cheaters without them doing their own research, contact me directly if you have a question or want more details and can prove to me you’re not just after copy-pasta for your payhack. Scan three is very similar to scan one, however instead of returning information about modules it returns information about all the currently running processes. It appears to be inactive at the moment though because I have never seen it called and can’t think of any reasonable way to trigger it. Scan four is one I am not yet sure about. I’ve never seen it called, and reversing it statically is not making a whole lot of sense as it is doing a bunch of PE file format manipulations that don’t appear to be generally applicable, so my current suspicion is that it is targeting a specific cheat, but I still need to look deeper to confirm this.

What’s next? Finishing reversing the final corner cases and minor details/nuances of the modules so I can round off my private notes and counterpart test implementations (I like to re-implement all the scans so I can ensure my understanding is correct), especially the ones that I haven’t been able to trigger because those are obviously harder to verify (though I think I can simply spoof input data for all of them). Following that will be another long break (likely a very long one this time because I am in the process of moving overseas), and then probably some further analysis of the ‘supplementary’ VAC components (specifically the process monitor in SteamService, and the stack tracing in GameOverlayRenderer), and then finally an analysis of VAC2. I’ve also become more interested in DRM recently so who knows, maybe I’ll decide to look at CEG instead.

4 thoughts on “VAC Module Overview (2/2)

  1. Pingback: New VAC module family 20151117-153712 | The Raptor Factor

  2. Pingback: VAC module family 20151117-153712 overview | The Raptor Factor

  3. Pingback: New VAC module family 20151204-172540 | The Raptor Factor

Leave a Reply

Your email address will not be published. Required fields are marked *