Who even knows what’s going on at Valve anymore…
The latest VAC module family (20151204-172540) has seemingly been rolled back. I’m not sure exactly when that happened, because this is the first live dump I’ve done since that module was released. I did end up looking into the updates/changes but didn’t bother posting them here because they were so predictable it wasn’t worth the time. But since we’re on the topic anyway, it basically added further support for scanning x64 process/modules to the 20151123-182038 (originally 20150609-214236)¬†family. It might have been cool/interesting, if it wasn’t so predictable…
Cerberus now has built-in support for ImGui and ChaiScript. Still very much a work in progress, but the end goal is to make it possible to write full plugins¬†purely as scripts.
I’ve finally finished my move to the USA and have internet connectivity again. Seems in my absence there has been another minor update to what was originally (since my notes started anyway) the¬†20150609-214236 family. You may also recall the previous update to this family.
Not sure what’s changed yet. I will probably look into it, although VAC is getting boring so maybe not (depends if I can find something else that interests me, and right now I can’t). At any rate, if I don’t do it in the next few days it will probably be a while because my holidays end this week.
Tiny but interesting update to the¬†20151117-153712 family which removes the 64-bit module enumeration functionality¬†and adds an extra check to scan 1 so it only attempts to return module info for 32-bit processes.
I’m not sure why the module enumeration code was removed. It was only run if a certain flag was set, and that flag was never set during any of the calls in this module as far as I can tell. The rest of the function still¬†remains, including another unused branch, so it’s not just the optimizer stripping dead code…
Another pretty simple update, this time for the 20150609-214236 family. The most interesting change is that the module now uses the new 64-bit capable process info class which I first described here. Basically that means more scanning is now possible against native 64-bit processes (scans 1, 2, and 4 specifically are using this process info class). This support however does not yet extend to things like the PeFile class, and there are other areas too which are limited (e.g. always assuming a pointer is 32-bits), so there’s still work to be done before VAC’s 32-bit and 64-bit detection capabilities are equivalent. The process information class has also been updated to provide some bools which indicate whether the caller (i.e. Steam/SteamService) is running under WoW64 and whether the target (i.e. the thing being scanned) is not running under WoW64. These flags are now reported back in the first scan (which you will remember is responsible for reporting information about the modules loaded in a process). There’s a few¬†minor changes, like to the¬†first scan so that it now reports back the starting address for the module enumeration, and to the process info class so that it only performs module enumeration if a certain flag is set¬†(whilst this does affect the functionality of two scans, it’s limited to flags which appear to be unimportant¬†except perhaps for easily identifying modules which have been unlinked from the PEB). All the process information class changes can also be found in the other¬†recent VAC update. Lastly, there is some extra error checking and reporting in the function which opens files by VSN/FileId. Not sure why… Perhaps failure to open a file by VSN/FileId causes a VAC authentication error, and they want more information to diagnose those cases? That’s purely speculation though.
Pretty simple update for the¬†20151021-211850 family. Replaces the broken 2nd scan with a new and completely different one. The new scan returns¬†very basic information about a file (a copy of the path, whether it can be successfully opened and parsed as a PE file, the file size, and its VSN and file index), and also the VSNs and file indexes of each parent directory in the path (up to a maximum of 16).
After noticing¬†the first new module I decided to do a full dump, and it turns out there’s another updated module. This time it’s an update for the¬†20151021-211850 family. I haven’t looked closely yet, but it appears that¬†the update is targeting scan 2, which makes sense because as I remarked in my earlier post that scan was broken anyway. As with the other update, I’ll take a closer look on the weekend.
Update for the¬†20150609-214236 family described here. At first glance it appears that the x64 support from the¬†20151001-202837 family has been ported across to scans 1, 2 and 4. I’m not sure what else (if anything) has been changed yet, but it doesn’t appear to be much. I’ll probably take a closer look on the weekend.
Just a simple update for the 20151001-202837 family.¬†It seems Valve finally noticed the bug causing threads to hang. However instead¬†of narrowing down the scope of their NtQueryObject calls or even simply removing the file handle name query, they’ve removed the entire function containing the handle enumeration logic. Disappointing, so hopefully once they sort out their bugs they’ll re-add it.