It's a dirty hack of the likes a graphics driver should never do
Yup agreed. In this case I can imagine the process being like the following.
Valve and AMD will work together. While an argument might be made by some that VAC shouldnt have gotten angry, the reality is this isnt a chicken or egg problem. AMD touched the naughty bits and VAC did what it was supposed to.
To handle the actual bans first, its important to know what is likely going to happen. In most cases these are finger printed in some way.
Some valve SDE is going to boot up CS2 in debug mode. and run the AMD implimentation. Debug mode isnt a game mode in this context. It is a compile of the game with debugging options enabled that they will be allowed to poke prob and see things that are usually removed in production.
When they do this, VAC will ban the debug instance, but will spit out some error info. Maybe something like
Faulting executable : cs2.exe
At memory address: 0x0000088712
Stack trace: 0x-7A, 0x067
Faulting Module: AMD_driverinjection.dll
From here they will look at the memory snapshot of the debug build and figure out what the driver is manipulating. Once they figure it out they will move on to step two, but it will end the same way. The reversal of the bans.
To do that isn't going to be rocket science. Instead they will create a rule like
Code:
{
// Random definition file for closed source ban engine
memaddress= 0x0000088712
exe=cs2.exe
cause=AMD_driverinjection.dll
checksum=madeupnumbertoconfirmexeisntnamedsomethingrandom
getmemAddress_function = called_address
if {
%exe% fault =1 & %memaddress%=%called_address
do {
check %checksum% & cause contains *AMD_*
}
then {
(no ban) or (reverse ban)
}
else{
banned
}
}
}
The actual thumbprint used will very greatly based on step two. Valve and AMD will need to chat.
Either:
Valve denies the modification outright and AMD needs to find a different way or a different implementation.
or
Valve concedes because nothing malicious is happening and allows it with guidance to AMD to change there hooking procedure so it touches a select part of the files or memory heap.
They decide that but Valve is definitely going to be the boss here. For AMD users, it should also be mentioned that this is the VAC system responding to a modification to CS2 that has not been ok'd. This feature may not affect any other games even if they are protected by VAC. That doesnt mean it wont, but contextually its important to understand that each game is different, and as such allowances in one may not be allowed in another. That also works in reverse, and in other games outside the steam eco system, such as DRM with another studio or engine. This has really /always/ been the case though.
With that said, GPU drivers have access and push buttons in kernel space (yes thats not just a linux thing) and touching things in kernel space (even in the linux world) is something that most companies, developers and security people consider big no no's. While drivers work at the kernel level for performance, and because of the hardware access, doing things that manipulate user space (like a video game) are generally frowned upon.
Driver improvement, DO generally happen at such a low level, by handeling calls to the GPU. The driver will look to see who the caller is (the game executable) and may handle the request different because of oddities observed. Thats normal. BUT that is generally a 1 way street. In this case it seems like AMDs driver reached out of kernel space into user space and modified bits in memory. This triggers VAC and this is poor practice.
This is also heavily watered down. Kernel, user space and driver relations are a very complex topic and so is security so writing 3 paragraphs is more then a consolidation.
hit markers? 
