hello,
I've played DayZ few years ago on Console (PS4), and last year I've also acquired it on PC and I haven't played as much as I did on console. Before, and actually at this very moment, the Game itself is full of cheaters - and you don't need to be even well-informed to call it out, people literally find your loot in the middle of nowhere in a matter of a day or so, depending on how active a cheat-group really is. And literally, all Official Servers have cheater-groups dominating the server and all resources.
Cheating in PC Games is not something new, it's not only DayZ that suffers this issue, however, as a Software Developer I understand that the number of developers working actively on cheats should not be great - however, the mass they reach could be close to thousands for a title like DayZ. What I noticed within every single different game I've played on PC is, when a new, major patch is released, there is a window of a day or two until all cheaters are back onboard - although, this vary from titles. Cheats on DayZ depend on a bypass over BattlEye, which most "cheat-developers" already have, so that's no protection - it's OK to catch the enthusiastic trying to learn how to create a working cheat program, but will not catch the one who sell cheats; In order that, BattlEye is really nothing they are concerned of.
Could you please, idk, humor me for a minute (maybe a Software Developer within the Studio to reply) - I will start with some statements, and please correct me if I am wrong, and last I will ask you a question that I hope you can provide me an answer.
#1. Exploiting 'Memory Read' would be done by first identifying structures and base memory address of well-know controlling entities / classes of the underlying engine;
#2. 'Memory Addresses' and the composition of an executable memory is done at linking time, which is something that can be overridden by whoever is compiling the executable, in this case, DayZ executable;
#3. Exploiting 'Network Packets' would also be possible when the attacker has already the list of Op-Codes and packet structure between server and client, which is another possible method of 'reading' the data a client is receiving;
Questions:
- Why can't you implement an automated process that, with a custom developed application you could generate a random linker memory map and have the memory allocations "randomized" - this application would in fact produce the linker target file but on each run, it would produce a file with randomized memory layout? - This would create a new memory map which then you'd use to compile the executable and produce something with different positions; You could even go one step further and checkout or you main branch code-base and also add randomized members into well-know structures and fill them with dummy data, this could potentially also add a new layer that cheaters now would need to find out the base addresses and also figure out which members are the correct ones; This takes care of 'Memory Read' attack vector.
- Why can't you implement an automated process that, in a similar fashion, also randomly modifies the Op-Code structure - you don't need to redefine packets, maybe switch the packet identifier and perhaps add dummy data to packets, which should be ignored when processing the packet. This way, each build would have complete different network-packet structures, you'd need to change the interceptor methods as well to be inline on both server / client executables; This takes care of 'Network Packets' attack vector.
- Why can't you implement an automated process that, as soon the those process ran and generated a new executable with a total different memory space and different network packet structure, you would send this file (the new executable) over Steam as a patch, that clients must now download. Server would need to also have validations in place, but if the network packet structure is also modified, well.. client would need to be on the latest build or else you could disconnect the client due incorrect packet structure;
We know that, Official Servers have a window for restart - let's say, this is each 3 hours. Case we consider a two restart window, let's make this a 6 hours window, you'd run your process in this window and by the time the window limit reaches, you update your server executables (send over the new exe file when the server is offline), publish the patch into Steam (which now allows every client to download a new executable to be used) and then you get your servers online again. This would also mean, each 6 hours, cheat producers would need to acquire the new executable from Steam, reverse the memory addresses, which I don't think they can "automate", then reverse all network packet structure, which again I don't think they can "automate" - they will have a window of 6 hours to do this job before it's all modified again, and they would also need to distribute that code to other cheaters - which would only be able to use that version for a few hours... considering cheat developers can actually do all their work this quick. And maybe, they can.. however, they would need to be working 24/7 - and your Studio would only really need to create the application to randomize and have an automated process behind to coordinate deployment.
Wouldn't you agree that, such method would make cheat developers stop creating cheats for your Game since it's too time consuming? - To your Lead Developer, do you see a flaw with anything I've said or anything that is "impossible" to do?
Also, I understand that could be somewhat a small "inconvenience" to players to download a small patch each 6 hours, but really.. as a player (and maybe some players will read this thread), would you even mind about it? - Last, Console binaries would not be affected by this process, since they really don't have the same issue we encounter while playing the PC version.
