My Ultim anti-cheat idea
•
19 Nov 2011, 19:13
•
Journals
In order to cheat, cheat user need "offsets".
But if you build code that compil game code just before the game start, creating a new cgame DLL, cheaters will got it in the ass.
i'am sure there are already many app which modify offest DLL, this is not a hard think to do.
This system will be more reliable than any tzac or punkbuster.
no lags in game.
Cheaters will be sent to old and ugly aimbot/wallhack which are very obvious(graphic based, no DLL hooking).
Watch out, i'am pretty good.
But if you build code that compil game code just before the game start, creating a new cgame DLL, cheaters will got it in the ass.
i'am sure there are already many app which modify offest DLL, this is not a hard think to do.
This system will be more reliable than any tzac or punkbuster.
no lags in game.
Cheaters will be sent to old and ugly aimbot/wallhack which are very obvious(graphic based, no DLL hooking).
Watch out, i'am pretty good.
Also, recompiling the game code for every game would cause time spent in loading screen to increase drastically, we're talking about at least five times longer loads.
E: Also, mere recompiling won't change the offsets, you also need to actually change something within the code. This would lead to different problems, such as people being able to use whatever cgame DLLs they want to since there would be no way to detect whether it's one created by the "anticheat" or one tailored by the player.
So i'am not sure about the possibilty of "on the fly method".
If they could find them that easy, then they will do it now.
Compiling a code take at most 5 seconds, not more.
And i'am sure they are still app to modify DLL offsets without re-compiling sources.
Edit: "such as people being able to use whatever cgame DLLs they want to since there would be no way to detect whether it's one created by the "anticheat" or one tailored by the player. "
nah, it wont happen. there are checksums to check if the dll are the same, and when they are not then the good is downloaded.
You can't tell an "anticheat"-modified DLL from a user-modified DLL judging by just the checksums.
And i'am telling you there is yet a system in ET that make you cant use a pk3 or a DLL if chechsums are differement from the ones who are on server side.
And, that still leaves in the option that the user just sends a faked checksum to the server, similar to cheats that allow you to use an "unpure" client (ie. stuff that bypasses ETPro's integrity failure -message, and lets you use whatever .pk3 files you want to).
And still, finding the checksums "on the fly" would be possible. I can't remember the name cheatcoders used for that method, but in essence you just sort of debug the client on the fly to find the proper functions to hook, instead of using preset offsets.
E: The reason you don't see this technique used in most free cheats is that it's simply more complex to do than just using preset offsets.
Sure, they will stil be able to load fake DLL, then a system to check the good one is loaded will be needed. You are right on this.
But finding offsets on the fly isnt that easy, that why there are still so many people cracking programs, looking for offset manually, using debuger.
They will bother that much if automatically finding them was that easy to do.
and many fonctions have the same prototype(same arguments).
Write instructions to some memory address, jump to that address. Don't need a VM for that?
Every time the code is loaded into memory it is mutated a little differently and a unique encryptor/decryptor is created (i called this a virtual machine) - the code needs to be run through the decryptor in order to spit bytes out that the machine can understand. Though if the polymorphic code doesn't encrypt it isn't necessary, though some kind of 'vm' is needed to take the machine bytes and morph them (add junk bytes, mutate code) but it still can be read by the machine so a decompiler isn't necessary though code execution is probably not as fast or optimised anymore.
The decryptor you're talking about might just as well be the x86 instruction set. Mind you, there's a lot of ways to write the same thing in assembly. Yes you need some kind of engine that generates the instructions, but calling this thing a VM is quite a stretch.
"Encryption is the most common method to hide code. With encryption, the main body of the code (also called its payload) is encrypted and will appear meaningless. For the code to function as before, a decryption function is added to the code. When the code is executed this function reads the payload and decrypts it before executing it in turn." (wiki)
You have a bunch of instructions I that you want to make unreadable to a third party (e.g. naive antivirus which looks for patterns in files). You put these instructions into a blob B, and you encrypt this blob with some key K.
Now, the entry point to your program is a decryption engine that decrypts your blob B to some location L in memory. Then, you re-encrypt your blob B from your in-memory image at L with a new key K2 and store this in the binary file again. Finally, you jump the progam counter to L, which obviously causes the instructions I to be executed.
The result of this is
1. A rewritten binary file, now encrypted with the key K2
2. The instructions I that are executed post-decryption are the same
3. The memory from L to L+sizeof(B) is the same
which means that the memory map looks the same, but the BINARY FILE differs.
And before you say that the example in the article has the dummy operations on C to mess with the memory map, if you look closely this doesn't change the encrypted instructions, it just makes the decryption loop harder to detect by an AV.
My points earlier (maybe not clear) was that
1. You don't need a VM for this,
2. Encryption/decryption completely misses the goal of moving the offsets around
Now, if you instead add dummy operations (NOP, writes to dead variables, unneeded reads, etc) to random places in between the original instructions, you can change the offsets required by cheats to read/write. This would only require you to do a linear traversal of the instructions once every time you start the program, and then you jump to the start of your altered memory and you're golden. No need for anything like a VM..
"Technically, polymorphic means self changing. However, it can mean different things based on its context.
In an object-oriented sense, polymorphism is when a function call is decided during run time, not compile time. This makes the code self-changing because the same piece of code can call different functions (same variable, different objects).
In encryption terms, it means code that is different every time it is run, often relating to a virtual machine. This can be a result of a random seed being used to encrypt and decrypt certain pieces of code."
"...Though for hacks and viruses, what most people consider polymorphic is editing assembly at runtime."
Wait, now you're talking about self-modifying code (http://en.wikipedia.org/wiki/Self-modifying_code) (editing the assembly currently being run on runtime) as opposed to polymorphic code (http://en.wikipedia.org/wiki/Polymorphic_code)
This is, of course, not our context
This is what I described in the previous post.
Source? If this is a good definition of polymorphism in this sense, then we actually agree.