• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
rpiller

Online game file check for tampering and up to date

52 posts in this topic

So making an online game. I've created a launcher/updater program that does the auto updating of game files.

My next question is about making sure the client has the most recent updated and/or not tampered with files before they play. I have an idea on this but curious about what others think.

My idea is after the client logs in, hash codes of each major file is sent to the server in one message. The server will then check these against a table of hash/filenames of the most recent update. Does that seem good enough? I suppose I should send these encrypted as well. Any other ideas around this that I haven't thought of? I'm sure there are some. :)
0

Share this post


Link to post
Share on other sites
Strictly speaking, it is not possible to prevent tampering by a determined cheater.
You have to design your game rules to be enforced by the server based on packets received by the client, and you have to assume that the client might be a clone written by Chinese gold farmers, or vindictive, snotty 14-year-olds.
Checking files as you load/use them is a good idea anyway, because it will detect people who are out of date, have broken hard disks, etc.
The typical way this is done is to send a manifest of all files (file name + hash) as one of the files, and provide the hash of the manifest itself from the server. If the manifest hash mis-matches, a new manifest is downloaded. Then, each file is checked against the manifest, and if there's a mis-match, the proper version is downloaded.
Exactly how and where this is all done varies. There are many ways to skin this particular cat.
0

Share this post


Link to post
Share on other sites
As hplus0603 said, make your server the authority.

In addition to hashing the entire thing, I'd hash each file differently at different levels (i.e. hash each GB of a file and the whole file). It is fairly trivial to make a modified file hash into the correct value, but if you have multiple hashes per file it becomes much more difficult.
0

Share this post


Link to post
Share on other sites
[quote name='turch' timestamp='1327945150' post='4907711']
It is fairly trivial to make a modified file hash into the correct value, but if you have multiple hashes per file it becomes much more difficult.
[/quote]

But that doesn't matter, because the attacker will just intercept the network send request, and make it send the hash value you want to get, no matter what was actually calculated. The only reason to hash sub-sets of a file is if you want to patch only a part of a file, that that, in turn, requires some good way of identifying subsets of files that doesn't change each time you patch the file.
0

Share this post


Link to post
Share on other sites
[quote name='hplus0603' timestamp='1327961019' post='4907783']
[quote name='turch' timestamp='1327945150' post='4907711']
It is fairly trivial to make a modified file hash into the correct value, but if you have multiple hashes per file it becomes much more difficult.
[/quote]

But that doesn't matter, because the attacker will just intercept the network send request, and make it send the hash value you want to get, no matter what was actually calculated. The only reason to hash sub-sets of a file is if you want to patch only a part of a file, that that, in turn, requires some good way of identifying subsets of files that doesn't change each time you patch the file.
[/quote]

True, but its a little bit of extra annoyance to an attacker for about 10 minutes of extra coding. IMO worth it.
-2

Share this post


Link to post
Share on other sites
[quote name='turch' timestamp='1327961887' post='4907789']
True, but its a little bit of extra annoyance to an attacker for about 10 minutes of extra coding. IMO worth it.[/quote]
That particular rabbit hole goes a long way down.

You are trading days of development, weeks of QA, not insignificant server load, and potentially thousands of customer support calls, all to delay a script-kiddie by 10 minutes.

And of course, the script kiddie isn't working on salary or a clock, and it only takes a single enterprising individual to provide a crack for every single one of your customers...
0

Share this post


Link to post
Share on other sites
Since any of the programs (including the file validator) could be reverse engineered and tampered with (like automaticly sending the right values even when every file no longer matches the checksum/whaterver).the first thing to force a real validation on is the validator itself.

There has been discussion on these forums before and I thought that a mechanism that reloads every login (every time executable run) a new validator (recompiled daily+ with different code scrambled to result in different binary hash/checksums/exe/ size) or a .dll component so the program does not have to restart would force the hacker to constantly rebuild their hack (and redistribute it to those not cappble of doing the work themselves -- and in that case have them be personalized PER USER so that one hack doesnt work for any other user). If automated mighteven be able to be done constantly while the game runs (dll unload and reload).

Once the validator is safe the rest of the programs/files can be checked (and they too can be replaced every day/periodicly in a 'unique' hash/checksum form.)

Partial file replacement (mainly the game exe runtime) would be done constantly (every login - ive seen multimeg files dl in seconds for exist mmorpgs... so not to horrible a delay) to have something different to check (that too would be a per user variant that would make each one (at that point in time ) unique and force older copies to be invalid)
That would block direct substitution by the hacker and force more complicated insertion of hacked logic into the main process)

Next would be a communication encryption scheme -- part of the main exe (matched on a per user randomized system that is complement component on the server side) The serever would know instantly if the encryptor failed. Use could be rotated with random 'checks' against any/all files to look for tampering (even in the middle of playing) . That would deny communication intercepts/insertions as the encoding would constantly change thru too many different methods to cheat on them in a timely fashion (realtime games the data is irerlevant in mere seconds often)

With small .dll modules constantly shifting each with different encoding scemes and cyphers the data load (renewal overhead) across the connection might be fairly minimal. The server could have a dictionary of thousands of encryption substitutions (matching parts for client/server sides) and more could be programaticly generated for freshness constantly. The hacker could never keep up. Modules would be algorythmic variants as well as cypher data so that the hacker could never predict what might be loaded 'on the fly' and too difficult for automatic code breaking/adapter building for his hack. Turn them over constantly and use more than one at once and anything outside of the games iown exe cant keep up with the changes.


It eventually comes down to 'making it much harder' and if the hacker cannot automate his hack reenginerring system and it takes too long to redo it by hand (and cant redistribute to script kiddees if he CAN somehow break it) then the hacker will spend all their time rehacking and have no time to cheat (and the greater number who are reliant on getting hack from others are totally screwed)

Add a server side system to report incidents when the system detects a hack attempt and identifies repeaters (more than just the odd mistake such a complex system might cause -- a pattern of trying to hack) for human review and banning the perp (with evidence)

ALL or part of a system like this would make the hackers work significantly harder and past a certain point unrewarding for most but the dedicated/fanatics.


Hmm this sounds like an interesting project to actually do for a demo -- who knows if its good enough sell it to the MMORPG companies for a cool million...

----------------------------

This all of course is in ADDITION TOO easy server side validation.

-----

!!!!! I now just remembered that much of this what looks like OVERKILL was actually origianlly to figure out how to offload servers logic with PEER (P2P) execution of some of the servers load ---- like heavyweight AI (one of my interests) which can take ALOT of CPU processing and making use of the numerous user's client machines could significantly increase the games AI resources.

Think sanitized/genericised/encrypted (all in-memory) process jobs that constantly shift amongs the peers (so a user never knows what it is his machine is working on minute to minute and even if he did it wouldnt be there for long). The above security stuff would make it safe to run on the peers without compromising the game data. Of course you would have to VET the available peers as some are just not reliable or are underpowered or try to hack. Some reward would be made to players willing to have some of their computer resources used to help the server.

-----
0

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1327970123' post='4907827']
[quote name='turch' timestamp='1327961887' post='4907789']
True, but its a little bit of extra annoyance to an attacker for about 10 minutes of extra coding. IMO worth it.[/quote]
That particular rabbit hole goes a long way down.

You are trading days of development, weeks of QA, not insignificant server load, and potentially thousands of customer support calls, all to delay a script-kiddie by 10 minutes.

And of course, the script kiddie isn't working on salary or a clock, and it only takes a single enterprising individual to provide a crack for every single one of your customers...
[/quote]

But if you're hashing at all, you're already way down the rabbit hole. If you're only trying to make sure files are up to date, there is no point in hashing, it would be way simpler to send file size info + each file's version number.
0

Share this post


Link to post
Share on other sites
@turch: Hashing helps for users who have hard disks that don't read back whatever you initially wrote. Such things exist -- I'd expect 1 out of every 10,000 users to be affected by this.

@wodinoneeye: All your fancy mechanisms don't mean nothing. Your server will receive packets from the greater internet, and has to make decisions based on those packets. I can form packets any way I want. Perhaps I patch your client. Perhaps I write my own client. Perhaps I point my Windows box at a Linux box for its gateway, and modify the packets in flight. Perhaps I run your game in a virtual machine inside my Windows box and use the virtual network redirect to patch the packet stream. There is no way you can detect this and separate "touched" packets from "untouched" packets, because I can just inspect your client and inspect your packet stream and figure out how to generate correct packets. And once one person has figured this out, every person can download it on the internet.
The *only* defense against cheating is to not trust the client, and enforce all game state and rules on the server.
This is assuming your game is popular enough that anyone cares to cheat, of course. If you have no players, you have no cheater problem :-)
0

Share this post


Link to post
Share on other sites
So for file validation this looks like the way to go. Step 1 is to make sure users are all running the correct version. I get the server side ruling all, but if someone goes into the character models file and replaces it with a model that has giant arrows pointing in all 6 directions and your game is a FPS how would you avoid that? It clearly gives him an advantage because he can see you coming from anywhere. Hash checks would stop that for the people who don't know how to redirect network traffic but know how to model and replace a file, but even server side validation can't detect that's happening if they are able to intercept the network traffic and send the right hash code. Is there really any way to handle that? My game won't have that specific problem but I know I've seen cheats like that in counter-strike before.

Like some are saying you could make it harder on a hacker by doing all sorts of crazy stuff, but it does add time to your development and will introduce bugs.
0

Share this post


Link to post
Share on other sites
Well, this is the hard part.
As long as the client knows that a model is behind a wall, but does not draw it because there is a wall there, its "easy" to add a wallhack - simply because the client *knows* something is there

The server could do Line of sight check, and decide not to send models that are behind walls, for example, which would make wallhacks like that impossible. There are other concerns, here, because in modern high end games you might see shadows/hear sound from specifict positions as well.

If you look at the big fps games out there, none of them has managed to solve this problem yet. But if you are not making a game for the big players out there, this might not be an issue to you at all. Its quite possible that noone will make cheats for your game anyway.

For mmo's this is "simpler" since they have rpg systems that decide the outcome of combat, which hopefully is calculated by your server.

To reiterate what has been said in this thread many times already: To prevent cheating, the server needs to do the calculations. (and even then it can be tricked: speedhacks etc)
0

Share this post


Link to post
Share on other sites
[quote name='rpiller' timestamp='1328047229' post='4908173']
but even server side validation can't detect that's happening if they are able to intercept the network traffic and send the right hash code. Is there really any way to handle that? My game won't have that specific problem but I know I've seen cheats like that in counter-strike before.[/quote]

Hacks like that don't touch the game at all. They sit between DX/OGL API and driver and manipulate the command stream sent to GPU.


How to fix the problem? Just like everyone else did. Go to gated and monitored platforms, where you have 24/7 admins banning people. Console + online service. Not necessarily the best option, let alone most accessible one, but something that works.

Alternate solution: don't use competitive modes, use co-op. Won't fix the problem, but will affect the incentives since it's no longer a zero sum game.
0

Share this post


Link to post
Share on other sites
[quote][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left] if someone goes into the character models file and replaces it with a model that has giant arrows pointing in all 6 directions and your game is a FPS how would you avoid that?[/quote][/left][/size][/font][/color]

You fix it through design, not through technical counter-measures.
Design the game so cheating doesn't give you an edge. Co-op is great for this!
Design the game so that cheaters end up match-making to other cheaters.
Have a premium service where you have admins on all the time, and can request random screen shots from clients (like punkbuster) -- doesn't mean clients can't fake out screen shots, but it's harder to do well.
I really like it if you can design so griefers play other griefers, cheaters play other cheaters, and friendly noobs play other friendly noobs...
0

Share this post


Link to post
Share on other sites
[quote name='hplus0603' timestamp='1328154781' post='4908612']
[quote]
[left][color=#282828][font=helvetica,arial,verdana,tahoma,sans-serif][size=3]if someone goes into the character models file and replaces it with a model that has giant arrows pointing in all 6 directions and your game is a FPS how would you avoid that?[/quote][/size][/font][/color][/left]


You fix it through design, not through technical counter-measures.
Design the game so cheating doesn't give you an edge. Co-op is great for this!
Design the game so that cheaters end up match-making to other cheaters.
Have a premium service where you have admins on all the time, and can request random screen shots from clients (like punkbuster) -- doesn't mean clients can't fake out screen shots, but it's harder to do well.
I really like it if you can design so griefers play other griefers, cheaters play other cheaters, and friendly noobs play other friendly noobs...
[/quote]

Heh and you call MY stuff 'fancy mechanisms'. Changing the whole game from something you might want it to be to be something else....
0

Share this post


Link to post
Share on other sites
[quote name='hplus0603' timestamp='1328030195' post='4908075']


@wodinoneeye: All your fancy mechanisms don't mean nothing. Your server will receive packets from the greater internet, and has to make decisions based on those packets. I can form packets any way I want. Perhaps I patch your client. Perhaps I write my own client. Perhaps I point my Windows box at a Linux box for its gateway, and modify the packets in flight. Perhaps I run your game in a virtual machine inside my Windows box and use the virtual network redirect to patch the packet stream. There is no way you can detect this and separate "touched" packets from "untouched" packets, because I can just inspect your client and inspect your packet stream and figure out how to generate correct packets. And once one person has figured this out, every person can download it on the internet.
The *only* defense against cheating is to not trust the client, and enforce all game state and rules on the server.
This is assuming your game is popular enough that anyone cares to cheat, of course. If you have no players, you have no cheater problem :-)
[/quote]


The problem is that for it to work most of the mechanism has to be done to protect the next part that covers all the holes (it IS a complex solution).

You can 'touch' the packet traffic anyway you want, but if you dont know what to properly send (to read them to modify) then you are stopped.

For the full solution, the essence is that the client code and the transmitted data formats keeps changing faster than the hacker can keep up with the changes -- cant hand change the hack and any automated hack patcher would not get done before the encryption was changing again (whether they intercept packets or mutate the client or whatever).

(Did I not mention that the scrambler methods are sent as a blocks of machine code and is inserted into the executable ??? -- its not some ordinal to a method dictionary already in the client -- client is patched constantly with code snippets that are constantly regenerated/randomized on the server -- its a moving target)

I recall one issue that might be the deal breaker -- read/write/execute permissions on program segments might not be workable (especially if they crank up security to nazi levels on the newer OSs) That self modifying code issue might be simply solvable with reloading DLLs (that would also give the hacker a leg-up on auto hacking it though)

In a 'Just Make it Harder' partial solution -- having the right parts of the game executable customized automaticly 'on the fly' prevents static cheats from propagating (distribution to scriptkiddees). The wouldbe cheaters would be required to have have a complex hacker rig to break this system.

Simply reloading a modified client every time you start the game would go a long way (with sufficient differeneces in data transfer encodings each rebuild) . Just change the data chunk identification to different ordinals (simultaneously on client & server) would do alot to obfuscate data and break hacks.

Constant on-the-fly Spot Checks on chunks of the game executable (back to the server) would force a more complex hacked solution -- which would require the hacker to service spot checks requests with data from a well maintaining a 'pristine' (possibly constantly patched) executabe image as well as his hacked one actually running.

This again is still ALREADY with proper server side validation, but many cheats like aim-bots arent stopped by those.

YES much of this is overkill (its only for a game after all) and was really extended for Peer to Peer processing (which if also for a game lead to 'who cares' )
0

Share this post


Link to post
Share on other sites
[quote name='rpiller' timestamp='1328047229' post='4908173']
So for file validation this looks like the way to go. Step 1 is to make sure users are all running the correct version. I get the server side ruling all, but if someone goes into the character models file and replaces it with a model that has giant arrows pointing in all 6 directions and your game is a FPS how would you avoid that? It clearly gives him an advantage because he can see you coming from anywhere. Hash checks would stop that for the people who don't know how to redirect network traffic but know how to model and replace a file, but even server side validation can't detect that's happening if they are able to intercept the network traffic and send the right hash code. Is there really any way to handle that? My game won't have that specific problem but I know I've seen cheats like that in counter-strike before.

Like some are saying you could make it harder on a hacker by doing all sorts of crazy stuff, but it does add time to your development and will introduce bugs.
[/quote]


You could do PART of my grand scheme and maintain some in-memory data (cypher block) that also is queried along with your file hashes etc, --- to make what the hacker has to send back that much more complex a response to (they have to now emulate it all in their interceptor while a kosher installation just does it directly within the game executable) -- just to make it ALOT harder.

EVERY packet sent back to the server might have a mini payload (even just a few bytes of overhead) with some different data pulled from that cypher block (offset+databytes from cypher) do this enough and the delays (intercept+digest+hack+send) involved might make their hacked game unplayable...

The cypher block would be partially based on the client version (or the executables bytes itself) and partially on some 'on the fly' data (user specific random) sent from the server periodicly (with the corresponding data on the server session maintained to be checked against)
0

Share this post


Link to post
Share on other sites
[quote name='wodinoneeye' timestamp='1328271695' post='4909127']
The wouldbe cheaters would be required to have have a complex hacker rig to break this system.[/quote]
Lol @ 'complicated hacker rig'. Your typical hacking rig is GDB, Wireshark and Vim, plus a few more specific pieces depending on the exact task at hand - but it's all free and open-source software that is probably sitting on your hard drive as we speak...
0

Share this post


Link to post
Share on other sites
[quote name='wodinoneeye' timestamp='1328273191' post='4909132']

You could do PART of my grand scheme and maintain some in-memory data (cypher block) that also is queried along with your file hashes etc, --- to make what the hacker has to send back that much more complex a response to (they have to now emulate it all in their interceptor while a kosher installation just does it directly within the game executable) -- just to make it ALOT harder.[/quote]

So you would suggest using [url="http://xkcd.com/538/"]4096-bit RSA[/url]?

Meanwhile, hackers prefer to do something like this:[quote]Congratulations,

youre luky winner of Diabl0 III Beta. Login to ur accout here to get it: http://diablo-tree-really-legit-beta.cheap-hosting.com/urawinner/diable3.asp[/quote]
And it works.
0

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1328274346' post='4909138']
[quote name='wodinoneeye' timestamp='1328271695' post='4909127']
The wouldbe cheaters would be required to have have a complex hacker rig to break this system.[/quote]
Lol @ 'complicated hacker rig'. Your typical hacking rig is GDB, Wireshark and Vim, plus a few more specific pieces depending on the exact task at hand - but it's all free and open-source software that is probably sitting on your hard drive as we speak...
[/quote]

Ive said it several times 'you want to make it harder'.... How many ordinary users know how to set those things up let alone make them work in an automated fashion for even the simplest parts of my solution (changing things frequently enough that the hackers have to constantly rebuild their hack mechanisms)

When some would-be cheater can just download something provided by the experts, install it and run the provided hacks, its easy and THEY are the majority of the cheaters.
Now harden the system and suddenly only the experts (what percentage do you think theyare??) can do it (and they cant distribute it fast enough to the script kiddees ) Some 'experts' might take it on as a constant challenge but even they likely will give up and move on to some other less bothersome cheat-easy game.

Suddenly cheaters are hardly there and THAT is the goal.
-2

Share this post


Link to post
Share on other sites
You are not the first GDNet'er to go down this particular rabbit hole, by the way. [url="http://www.gamedev.net/blog/73/entry-932029-anti-hacking-idea/"]Ysaneya beat you to it by 6 years[/url], and the debate there would be well worth your time to read.

[quote name='wodinoneeye' timestamp='1328304241' post='4909320']
How many ordinary users know how to set those things up let alone make them work in an automated fashion for even the simplest parts of my solution (changing things frequently enough that the hackers have to constantly rebuild their hack mechanisms)[/quote]
You are suggesting that your software will download a small module each time, and this module will perform the checks and authenticate the results with the server, right? That way you can change the module regularly, to outdate older hacks.

So my hack would also download the module, and run it, just like your software does, and let it authenticate with your server. How will that work with a patched executable? Because I will be running your module in a sandbox, and giving it the original executable to work with, instead of my patched one.

This method of hacking is completely impossible to defend against (well, excepting TPM, but nobody wants that), because it works by showing the security/DRM checker exactly what it wants to see - and there is no way to detect this kind of spoofing (again, except for TPM).
0

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1328337384' post='4909443']
You are not the first GDNet'er to go down this particular rabbit hole, by the way. [url="http://www.gamedev.net/blog/73/entry-932029-anti-hacking-idea/"]Ysaneya beat you to it by 6 years[/url], and the debate there would be well worth your time to read.

[quote name='wodinoneeye' timestamp='1328304241' post='4909320']
How many ordinary users know how to set those things up let alone make them work in an automated fashion for even the simplest parts of my solution (changing things frequently enough that the hackers have to constantly rebuild their hack mechanisms)[/quote]
You are suggesting that your software will download a small module each time, and this module will perform the checks and authenticate the results with the server, right? That way you can change the module regularly, to outdate older hacks.

So my hack would also download the module, and run it, just like your software does, and let it authenticate with your server. How will that work with a patched executable? Because I will be running your module in a sandbox, and giving it the original executable to work with, instead of my patched one.

This method of hacking is completely impossible to defend against (well, excepting TPM, but nobody wants that), because it works by showing the security/DRM checker exactly what it wants to see - and there is no way to detect this kind of spoofing (again, except for TPM).
[/quote]

Yes one or more modules (binary code snippets) would get downloaded via the normal message transfer between server and client, would insert into the game executable and be run as part of the clients packet decryption scheme (actually I would see a window FIFO buffer list of these modules and the window would slide over as new modules are added/confirmed - but thats to cover the chicken/egg issue and also makes it a little more complex/obscufated - different packets call for use of packet selected modules or even cascade thru more than one)

Those encryption modules when executing reference bytes (via offsets) of the actual FULL game executable binary (not just the small encryption modules) as a cypher -- so they cannot run outside independantly without being mutated to fulfill the same functionality/results.
.
I have already figured in that your hack would attempt to use a reference image ('pristine') it maintains in sync -- of course the hack would now have to activate thru that image in order to execute the EXACT encryption scheme (your hack has to how to get in and out of this while executing - the cypher would be wrong now in this case). You HAD to change some of the adjacent code somehow to implement any hack functionality (ie - code to pull out the decrypted inbound packets and later insert outbound ones).

OR
You are running your Sandbox image with those new modules MUTATED to carry out those bothersome executable cypher fetches and the exactly the original algorithm (your solution needs to mutated its code to indirectly fetch EXACTLY the required cypher data from your pristine client image. CAN you make a PROGRAM that reengineers those modules ???

Like I said -- several components all have to work in concert for the whole to function securely and that includes measures that make 'sandbox' execution extrememly difficult. The server side that parallels all this can have whatever code solution it needs for the new modules to encrpt/decrypt there (part of the rebuilding there builds it to match correctly but only sends the client part to the client (and to your hack will get).

So you cannot just run the sent code snippets directly in your sandbox without changing them to run outside their intended context - they continually check that context in scrambled ways (any hack PROGRAM has to deal with lots of new variants constantly) . You HAVE TO programatically auto-mutate them and THAT is what Im betting on cannot be done by a program -- could be done manually by hand (the constant changing modules keep the scheme well ahead of that - it has to be done in a timely fashion).

The reengineering process -- disassemble, figure out EXACTLY what the code does, rebuilt it to work outside of context (emulate the cypher fetches which are random per packet), each module WOULD have different algorythms of how it mutates that key data. The rebuilt (hacked) code has to be inserted back into its place (the same binary slot - same size of code -- BTW I would pack the snippets into the module buffer - and THEY lots of mem space offsets built into it to foil your attempts to reengineer/rebuild)

I think I mentioned these modules are changed on-the-fly not just once on startup for the full solution. Even if its locked in and only changed with a executable DL once each time the game is played it would still be still designed with many countermeasures to prevent them running in a sandbox without your hack being required to be reengineered&rebuilt.

Another test is the server would expect an immediate response validation once the new module installation is achieved and if this takes too long (your whole hack rebuild/restart will take some time) the server can detect THAT and if it happens too often your user is put on an 'investigate for hack' list for human investigation.

Im not saying this whole scheme (or parts of it) doesnt require some clever programming and some added overhead on client and server.
Having the server side component match the functionality of the client (using a per client unique client executable as its cypher) adds to server side complexity.

And as I said before some existing or future OS might make the tricks that would need to be done impossible (ie - segment rwx permisssions).

------------------------------------------------------------------------------

OK assume we ONLY do some simplest countermeasures - daily rebuild of the client -- that client has the critical internal workings forced in different positions in the binary each rebuild and some of the encrypt/decrypt modules are programatically mutated/substituted each day. It should (of course) be built with minimum clues inside the binary itself. The client binary will now change frequently as run on the players machine. What does your hack rig have to do to try to realign itself and function when the client program binary changes like this ??? Can it do it ALL programatically (hands off) - 'automagically'???

Do you think an 'automagical' solution -- selfinstall/autorun -- can be created for brainless script kiddees thats it is NOT too much a 'complex rig' for them ??

Even YOU providing a 'hack of the day' DL: to match the ever changing client binaries adds extra work for any other cheaters you distribute a solution to.

Cutting out 99+% of the cheaters - isnt that a pretty good partial solution ???
0

Share this post


Link to post
Share on other sites
[quote name='wodinoneeye' timestamp='1328358903' post='4909495']
So you cannot just run the sent code snippets directly in your sandbox without changing them to run outside their intended context - they continually check that context in scrambled ways (any hack PROGRAM has to deal with lots of new variants constantly).[/quote]
Think about what '[i]intended context[/i]' actually means: it means that the program's address space must contain the correct data at correct offsets, and any files on the hard drive must have the correct name and contents.

How do we make sure that the sandbox's address space holds the correct data/offsets? We load a vanilla (unpatched) copy of the program into it. How do we make sure the files have the right names/contents? We hook the low-level file API to return the original (unpatched) data files.

So as far as all your modules are concerned, they *are* running in their intended context. They never see the patches and hack mechanisms, because those are all in the address space of the patched executable, rather than the vanilla copy in the sandbox.

Unless you have a [url="http://en.wikipedia.org/wiki/Trusted_Platform_Module"]TPM to guarantee that your program is the only such code executing on the system[/url], there is no way to ensure that you aren't being sandboxed.


[quote name='wodinoneeye' timestamp='1328358903' post='4909495']
OK assume we ONLY do some simplest countermeasures - daily rebuild of the client -- that client has the critical internal workings forced in different positions in the binary each rebuild and some of the encrypt/decrypt modules are programatically mutated/substituted each day.[/quote]
This might be a much more effective solution (provided you completely change your network protocols every time). However, it's also a maintenance, QA and financial nightmare - you make your users download a multi-megabyte executable every day, you risk introducing subtle bugs in each rebuild, and you need to dedicate significant manpower to scrambling your executable in imaginative ways (if you are scrambling automatically, much easier to automatically account for).
0

Share this post


Link to post
Share on other sites
[quote]Yes one or more modules (binary code snippets) would get downloaded via the normal message transfer between server and client, would insert into the game executable and be run as part of the clients packet decryption scheme (actually I would see a window FIFO buffer list of these modules and the window would slide over as new modules are added/confirmed - but thats to cover the chicken/egg issue and also makes it a little more complex/obscufated - different packets call for use of packet selected modules or even cascade thru more than one)[/quote]

There are two problems with this approach:
- having code like that would make every malware scanner on the planet light up like a christmas tree
- how do you do QA? Adding dynamic checksum is tricky enough, modifying raw binaries is just suicide.

As for defeating such a system, it's somewhat trivial.

Intercept code loading mechanism and inject memory access hooks. To keep QA managable, these modules will need to be based on some abstractions. Patching assembly directly, especially on a daily basis is suicide. These checks will also be auto-generated, unless you want to have a human in charge, greatly increasing risk of failure, so there will be abstractions and simplifications.

Once patched, make a diff between clean and modified image. At best, it will be a few bytes. Injecting code only requires patching some jump, after which I'm free to roam around a DLL or arbitrary code, something such code in unaware of.

If memory access hooks run across this patched section, they feed in correct bytes.

Another way, via sandboxing/VM or some other, perhaps memory page hook (trickier) trick doesn't require injecting anything. To mask patched bytes, I monitor read access to that part of memory. When it happens, I perform a check of IP register. If that IP is close to that of patch, then the code is being executed. If it's not, it's the DRM and I feed it correct bytes. This might be doable via debugger techniques, but I'm not sure of the performance impact.

-----

But here's an important question. The above would give me several hours of entertainment. How many hours would your game provide? Is there even incentive for me to crack it?
0

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1328367206' post='4909524']

[quote name='wodinoneeye' timestamp='1328358903' post='4909495']
So you cannot just run the sent code snippets directly in your sandbox without changing them to run outside their intended context - they continually check that context in scrambled ways (any hack PROGRAM has to deal with lots of new variants constantly).[/quote]

Think about what '[i]intended context[/i]' actually means: it means that the program's address space must contain the correct data at correct offsets, and any files on the hard drive must have the correct name and contents.
How do we make sure that the sandbox's address space holds the correct data/offsets? We load a vanilla (unpatched) copy of the program into it. How do we make sure the files have the right names/contents? We hook the low-level file API to return the original (unpatched) data files.
So as far as all your modules are concerned, they *are* running in their intended context. They never see the patches and hack mechanisms, because those are all in the address space of the patched executable, rather than the vanilla copy in the sandbox.
Unless you have a [url="http://en.wikipedia.org/wiki/Trusted_Platform_Module"]TPM to guarantee that your program is the only such code executing on the system[/url], there is no way to ensure that you aren't being sandboxed.
[/quote]

"We load a vanilla (unpatched) copy of the program into it"

where you insert and execute the new snippets so they can carry out the same operations on the same data (cypher of very same exe binary)

Except that binary is a running entity and you have to tap into it to extract the DECODED packets now in memory buffers -- to do something with the data and create your modified outbound packets which will be injected into the sandbox's outbuffers to be re-ENCODED properly. While it is executing those very same snippets can be checking every single byte (or rather a random sampling) of the executable segments in memory and forwarding them to the server..

How are you going to hide you taps into that program ?? You will have to have them somewhere inserted into that 'sandbox' binary.

The sampling checks send their results back to the server for validation against ITS cypher image and it will eventually turn up any differences.

Thats what I meant by 'intended context' -- the executable binary itself is part of that checked context and if any part of it changes or shifts in position BOOM!!


Some of those snippets may echo a response immediately back to the server. I would assume your sandbox rig will stop outgoing packets because you want to modify them and replace them with your own (probably back thru those snippets that do both DECODEING and ENCODING in constantly changing ways. With the snippets constantly changing in your sandbox do you know which packets to block and which to let thru ??
If it was all static the expert hacker could figure it out and build a static hack for it. But can an automated hacking program do that ??


Maybe you can tell me that when a program runs its memory space s get scrambled and my testing offsets wont work (binary executable segments I thought are locked down in their relative content and tests of exact offsets (byte contents) in those segments should be recreateable.



I still think my strongest argument is that you wont be able to automate your hacking system to adapt to constant changes in the game executable.
0

Share this post


Link to post
Share on other sites
[quote name='wodinoneeye' timestamp='1328460951' post='4909856']
I still think my strongest argument is that you wont be able to automate your hacking system to adapt to constant changes in the game executable.
[/quote]

[url="http://linux.die.net/man/2/mprotect"]mprotect()[/url].

I will patch the executable, then watch access to memory pages. When I detect a read, I'll attempt to determine whether it's legitimate code or DRM, perhaps by examining the stack traces of active threads or thread that triggered the fault. Depending on that, I'll feed either patched or original image.

It's not trivial, but it is transparent and oblivious to changes in DRM.

Methods like this are not necessarily trivial, nor will I claim it's a 5 minute solution. It merely serves to show that anything clientside can be defeated.

Such method doesn't cover anything, it cannot cover for certain types of changes, but it will render external validation universally useless.

[quote]How are you going to hide you taps into that program ?? You will have to have them somewhere inserted into that 'sandbox' binary.[/quote]

All I need is a single jmp instruction to be inserted somewhere by overwriting code at that position (moving rewritten parts at jmp address). Such insertion is hidden by method noted above, meaning the DRM process will not know a change was made and process image will appear intact.


Which brings us back at the beginning. Instead of spending so much time trying to make sure client is intact, just validate the *results* of client on server. Then instead of worrying about how client did something, you measure whether they are misbehaving. Of course, mismatched results could be caused by flaky hardware or other bugs.
0

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0