So while testing some things against a BattlEye protected again I noticed recently there was an update that prevents LoadLibrary from being utilized even after unloading the Anti-cheat.

First of all I thought, maybe Mr Bastian isn’t unloading the minifilter hook or it’s the PsSetLoadImageNotifyRoutine catching the LoadLibrary call but that didn’t really make sense.

Checking the system for any hooks and routinues installed returned nothing, so how is he still blocking the LoadLibrary call even after the BEDaisy driver is unloaded and BEClient.dll gone from the game’s module list.

So let me explain whats going on here:

He is overwritting one of NTDLLs core structued used by the Windows Loader:

1

ntdll!LdrSystemDllInitBlock

If you compare the original loaded bytes to the ones that are present in any game BattlEye runs on you will notice that there is an line patch present.

Original:

1

5000000000000000

Modified/Patched:

1

500000000000E7 F9

This stops any DLL if it has runtime checks enabled (CRT) and/or manifest resource causing an Access is Denied Error.

They are protecting their game executable code from being touched, on top of that they are doing something which will catch any allocated memory marked as ReadWriteExecute with an exact detail of what instruction and/or process wrote or caused the detection which is surprisingly good for a ring3 anticheat.

I will be doing more research into this, for now here is my post on UnknownCheats about it:

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)

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’

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.

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.

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

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.

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