Valve Anti-Cheat Untrusted Bans (VAC) CSGO

Untrusted Bans

So recently I’ve seen people suprized at how they are getting ‘untrusted bans’ on cheating forums. Some even confused at what that term even means.

Even though Valve hasn’t given us a definition of what it means previously it was understood that an ‘untrusted ban’ was the serversided anticheat ban given to players who send incorrect data to the game server in Valve’s official matchmaking. Most prominently player view angles which are stored in the Euler format (X,Y,Z) (Pitch, Yaw, Roll) if sent incorrectly to the game server instantly will flag your account as ‘untrusted’.

Heres some MSPaint diagram I drew showing you what I mean by invalid viewangles and how this is a big no no when the server receives them.

Now without going way off topic let me just point out whats going on, obviously the game character can not be upside down in CSGO there is no possible way for this to happen therefore if the Valve Offical Matchmaking Server receives 180 for the roll angle for example in this case they will instantly flag your account for a ban.

Untrusted bans however have evolved from that, people are getting untrusted bans with correct viewangles and you see the same sort of replies people make on forums online. “You forgot to clamp your angles properly”, “You must of wrote wrong viewangles” when in fact it could be something else causing these types of bans.

Now disclaimer I present to you my take on things this isn’t necessarily why it happens but I believe strongly it’s very likely to be the case based on research I’ve done on the Valve Anti-cheat system.

LoadLibrary

When you load an internal hack into a game (in this case csgo) usually the easiest way to do so is to call a function exported by KERNEL32 called LoadLibrary. LoadLibrary comes in many variants and since it’s the easiest to use one can quickly whip up an injector for their hack or copy paste one from the Internet and make it work.

Now lets talk about VAC3, one of the process scanning modules that resides in VAC returns all loaded modules in CSGO (or the target process) at the time of the scan.

It returns:

  • ModuleBase
  • MD5 Hash
  • VolumeSerialNumber (the module is stored on)
  • Some other attributes also present in structure ‘BY_HANDLE_FILE_INFORMATION’

It also has the ability to do deeper scans on individual modules, one of the more interesting scan flags returned is the fact if the module mapped in memory is present in the module list (PEB). Some people using LoadLibrary think it’s smart to unlink their hack module from the PEB which makes it appear even more suspicious as they can easily tell and do log this when scans are run.

(Here is a zip file containing said module and a IDA idb file which has fixed imports and decoded strings)

Scan Function is @ 0x10002f07

https://cra0.net/rel/vac_module_7_ScanMemory_38KB.zip

 

So where am I going with this you may be wondering? Well 2017.05.02 there was a CSGO update which bought some sneaky changes to game integrity.

http://blog.counter-strike.net/index.php/2017/05/18665/

At first it appeared they did this to stop anti-virus vendors from incorrectly flagging CSGO’s DLL libraries as malware (false positives). However if you think about this was a pretty strategic move on Valve’s part to help them isolate potential cheat specific DLLs.

Since VAC is constantly collecting data from you and I they have a massive sample size of loaded DLLs that could be present in CSGO besides their own signed modules which you can not alter. For example they can easily rule out their official DLL libraries from foreign ones.

There are a ton of legitmate applications which load libraries into other windows applications such as teamviewer ‘tv_w32.dll’ however Valve eventually collects enough data to determine that your hack dll you load everytime CSGO runs is in fact be a cheat and will deem your client as ‘untrusted’

Conclusion?

Write your own manual mapper, and don’t copy paste assembly stubs (they are signatured)

Posted in Main | Tagged , , , , , , , , , | Leave a comment

VAC3 Updates

I haven’t posted anything here in a while and well this just happened yesterday.

VAC ban wave

They are indeed doing something to the timestamps of the modules because

Same module, which enumerates drivers that is 100% identical has different timestamps.

100% match

Valve what are you up to now…  🙄

Posted in Main | Tagged , | Leave a comment

Valve Anti-cheat (VAC) in 2017

Lets first talk about Valve’s roadmap for Counter-Strike Global Offensive, mentioned briefly by Valve’s Gabe Newell in a reddit AMA he said the following:

As far as a roadmap is concerned, our priorities for 2017 are to replace the UI with Panorama, to make CS:GO available in more territories where a lot of Counter-Strike fans don’t have easy access to it (like China), and anti-cheat. Of course, we’re also planning on continuing to ship bug fixes and new features throughout the year, as in the past.

So clearly they are or from what Gabe has said looking at improving the game’s anti-cheat. Hard to believe as they haven’t exactly done anything significant in the past year or so but who knows we shall see what happens.

Today another post came out from the Valve Anti-cheat’s official reddit account.

A user asked about why they don’t add automated detection for spinbotters and send them to Overwatch they mentioned that heuristics can be very dangerous as cheat developers could probe the system to determine the edges of the detection approach and that it opens up a lot of room for false positives. I personally agree with them but seriously they could do something if they really wanted to that would be adequate. Their focus however seems more on machine learning and this is reflected actually by the current deployment of VAC modules.

Looking at a very recent dump of the modules we can see that their timestamps date back to last year.

Now at first I thought they were faking these timestamps but it seems they are in fact using dated modules. Comparing the timestamps to ones that I’ve dumped on those exact days we can see there are no differences in function calls or anything really.

So for now we can predict that they are working more on a server-sided heuristics approach to detecting cheaters (like mentioned in the reddit post) instead of focusing more on detecting cheats themselves.

We shall see what happens..  😮

Posted in Main | Tagged , , , , , , , , , , | Leave a comment

A New Year!

It’s been a while since I posted, now we are well into our second month of the year and here I’m posting for the first time here since last year.  😐

I’ve published some source code for some game data extraction tools I had made in the past on github if people are interested in the FoxEngine or Halo Online you can find them here: https://github.com/cra0kalo?tab=repositories

 

 

Posted in Main | Tagged , , , , , , | Leave a comment

Some VAC3 Modules

Meh nothing new but here have some modules.

http://cra0.net/some_vac_modules.zip

Posted in Main | Leave a comment

Project7-net Dump/Crack/Leak

Absolutely disgusting,

I can’t even be bothered with explaining more info here:

https://cra0vision.net/forum/threads/project-7-free-weekend.434/

Posted in Misc | Tagged , , , , , | Leave a comment

VAC3 Changes

I’m going to refrain from posting public information about VAC from this post forward. They seem to have noticed we are using the .text section of the modules to keep track of modules and the timestamps to determine if any updates occurred.

The .rdata seems to be merged now with the code section (.text) so we can’t really use section hashes anymore.

debug_in_text_vac3

No doubt that someone new is working with the VAC team and they have read my posts or they have just picked back up from the inactivity as evident of the recent major banwaves hitting p2cs.

If we look at the pdb paths of the modules we can see that they are not like the old ones which accidentally shipped a while back

E:\p4\s3dev2\src\vac2\vac3\Release\vac3_memoryscan\win32\vac3_memoryscan.pdb
E:\p4\s3dev2\src\vac2\vac3\Release\vac3_primitives\win32\vac3_primitives.pdb
E:\p4\s3dev2\src\vac2\vac3\Release\vac3_verifyclient\win32\vac3_verifyclient.pdb
E:\p4\s3dev2\src\vac2\vac3\release\vac3_processhandle\win32\vac3_processhandle.pdb

The path has changed and I know this doesn’t exactly prove anything but It’s just something I’ve picked up.

 

 

Posted in Main | Leave a comment

VAC Banwave (13/09/2016)

A few days ago there was a massive VAC ban wave. Some of the major P2C providers got hit:

  • Interwebz
  • UnityHacks
  • Aimware

banwave_13

Other providers got hit but I’m not aware of who they are. News sites are reporting this to be the largest ban wave of the year. Firstly I’m going to start by saying this is not a server side detection as a big post on reddit and various other sites have threads titled “untrusted ban wave”. Untrusted though yes mostly is a ban that occurs when the server side anti-cheat detects an anomaly or something that shouldn’t be set on your client however it can also occur when the clientside VAC scanner detects an injection occurring. These bans are delayed as far as I know as when I was using the public Xenos injector I received an untrusted ban which later showed up on my profile as a VAC ban.

untrusted

So moving on this ban wave was in fact a normal VAC ban wave.

The morning I woke up to the ban news I did another VAC module dump and clearly you can see they updated their modules. The 60kb module is responsible for scanning processes. The 61kb is an updated version which fixes an issue for windows10 (how02 found this). My guess is this VAC wave was targeting P2C loaders and processes that spawn before injection into the game. Remember VAC now can start when you login to Steam so running a potentially flagged loader even before the game is launched can see you VAC banned if you join a VAC secured server.

Lets see what the next wave brings us 🙂

Posted in Main | Tagged , , , , , | Leave a comment

Updated VAC3 Modules

As mentioned in the previous post Valve has changed the way they do import hiding. Previously there would be a bunch of string objects usually for each module that is being imported so “kernel32.dll” -> “GetProcAddress”,”ReadProcessMemory”, “OutputDebugStringA” etc and these would all be passed through a function which has an initial xor key of 0x55.

Now however they changed the operation and they are using IceKey encryption to decode the strings which get decoded in one big block.

Runfunc is what is called to run a vac module for a specific scan.

The inputPacket now contains a key they use to decode the strings. The decryption routine now looks like this:

Once the input packet is decrypted a 4byte key is then used to decrypt the string block with size of 0xA80.

 

 

There you have it nothing so difficult but I guess they don’t want people who have no idea what they are doing to be able to analyze the modules effectively. That being said though you can just hook GetProcAddress and everything is revealed anyway 😛

¯\_(ツ)_/¯

 

Posted in Main | Tagged , , , , , , , , , , , | Leave a comment

VAC3 Updates

VAC3_ATTRACT2

Valve pushed an update for VAC3 a few days ago or it could of been a week I’m not sure I didn’t actually check the modules for a week.

Heres a log of the modules I dumped today and their time stamp dates.

We can see they all seem to be updated at the same date. I will leave discussion to the thread on unknowncheats but at a first look we can see they seem to of changed the import resolver function which decodes the import strings.

UnknownCheats Thread

 

Posted in Main | Tagged , , , | Leave a comment