   File validity test - quick sanity check
  Hi all,Was hoping someone could give me a quick sanity check on a method for determining the validity of a exe. I have a UDP client/server (actually with a reliability and sequencing layer, but vanilla as far as this discussion goes), and I want the server to check for modification of the client.I''m thinking that the server could send a random string to the client, which the client uses as salt to construct an MD5 hash from it''s own executable and send the result back, which is checked by the server.I can see one possible attack as keeping a copy of the unmodified exe and having the hacked client use this copy instead of itself when generating it''s hash; apart from that, should this provide a reasonable amount of security? Is there anything else I could do to this end?Many thanks for any help you can offer.   www.coldcity.comcode, pics, life 
quote:Original post by IainC  I''m thinking that the server could send a random string to the client, which the client uses as salt to construct an MD5 hash from it''s own executable and send the result back, which is checked by the server.How does that provide any security at all? The hacked file only needs a little routine that uses the value from the original file instead of the actual one. You have no control over what it chooses to send back to you. Maybe it makes it harder to hack but the algorithm you describe would probably be picked apart in an hour by a cracker. [ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost  Asking Questions | Organising code files | My stuff | Tiny XML | STLPort] ;  Use my method instead. Choose a random string, embed it in an exe, and have the server send the client the exe.The exe will check the client's program for hackery, and if all's good it connects to the server and sends the proper string.This way you can actually stay one step ahead of the crackers for once. As soon as a crack is released, you can grab yourself a copy, make a new exe file that detects the crack and have the protection implemented in seconds.Now, the crackers could find out where you embed the string in the exe and just send that to the server. The beauty of it is, though, that you can change the method the exe uses of storing the string extremely easily.Just an idea I've been playing around with.EDIT: I should add that you'll want to make damn sure your server doesn't get compromised, or the exe file can be replaced with something evil. That wouldn't be good for anyone playing your game.   [edited by - glassJAw on January 29, 2004 11:08:20 PM];  @Kylotan - I did point that out in the original post. You have the guide to asking questions in your sig (although the link is broken) - surely what I said is more likely to get help than a "how should I secure my client" post?Anyway, this way of course provides more security than just requiring the client to send an MD5 of itself with no salt, that would be the same every time and hence even more trivially spoofable.@glassJAw - That is a nice idea; thanks man, I'll have a think about this and see if I can find a weakness.   www.coldcity.comcode, pics, life   [edited by - IainC on January 30, 2004 4:34:43 AM];  Sounds like a great first line of defence; dead easy to implement, risk free (as opposed to sending an exe) and will stop the less knowledgable crackers.It won''t stop the more dedicated crackers, but I see no reason why you shouldn''t implement it. The way I see it, securing the client isn''t a one-stop-shop, it''s a gallery of defences. This is one.;  You could as well have a fixed load point (linker''s /BASE) for the client exe and supporting dlls and the server asks the client to return a byte buffer from a random address pointer within its address space (crypted). ;  A knowledgeable cracker *WILL* crack this system, or the EXE system, or the read-memory-address system, or any other system.Once the knowledgeable cracker has cracked it, he''ll put up a program which lets anyone apply the crack on his own, so "casual crackers" have the same technology. (Compare script kiddies -- they don''t know what they''re actually doing; they just run pre-canned scripts coming from gurus)Even the Xbox "built into hardware" encryption is cracked.The only way to secure an online game is to make it so that it doesn''t matter if the client is cracked, all the decisions are on the server. Only send data to the client that you want the user to know, and accept user INPUT, not STATE, from the client. ;  Just to give my 2 bits,I come from the dark side. I was a hacker starting at 12 years old. I was cracking games, messing with memory addresses, hacking up save games. Don''t ever kid yourself that you will be safe from hackers. I was never the best at it I was just /mediocre/average but there was nothing I couldn''t do with a little help from other people.That was 20 years ago. Today I respect hackers. Not in a way that I think what they are doing is a good thing. Oldschool people had respect for the products they were hacking, now  adays alot of "hackers" just are out to destroy your product or make you look bad.With that in mind I cross over to the dark side now and again every time a new MMRPG is released and watch the guys devour the datastreams and poorly coded EXE''s. Take shadow bane as an example. 2 months into retail and the servers were hacked so full of holes that players ran around unchecked in god mode slaughtering other players and even teleporting peopel at random to teh bottom of the ocean. Nice huh?Learn from those experiences and don''t ever think that any kind of encryption or client side file will ever be sacred. I can personally assure you it wont.The way I have worked around it is to make the client simply the 3D portal to the entity manipulation that is being done by the servers. The client is 100% simply a dumb client. It only renders visual depictions of numerical entities. When the client detects a keypress to turn left it sends a signal to the server saying I am pressing asci character 212 and the server says ahh, thats nice, I''ll adjust your heading/speed x,y,z so many degrees and distributes that adjustment to all pertinent clients. When a client loots a corpse it sends a signal to the server saying "I am interacting with entity 1829304" The server says "Hmm ok." It checks the clients location in relation to the loc of the entity in question, checks the entity DB and decides if it''s avail to open and if everything is 100% it sends an "open item" signal to the client in question followed by a datastream containing the contents of that item. As an example the Client sees a signal to "open a 20 slot item window" and does so and then propagates that window with the following x items in the datastream. Now your average hacker would say" Ok now I mess with the incoming datastream to tell my client I have a holy bastard sword of total anhilation". Great, they do a memhack and sure enough, the holy bastard sword of whatever appears in their item window BUT.The minute they try and loot it the client simply sends a message to the server.."I am picking up item at location x,y in the conatiner window" The server doenst care what the memlocs are on the client side. It knows the order it sent the datastream in and simple checks it''s container Database and says "Ahh yes, item x,y is broken rusty dagger." The server then puts the real item (the broken rusty dagger) into the first available inventory slot in the clients inv DB and sends a message to the client "You have looted a broken rusty dagger."The hacker is ticked and hacks his inventory memlocs to say the broken rusty dagger is now the afore mentioned holy sword etc etc and tries to equip it. The server sees a request from the client to equip item at inv location x,y. The server checks the characters inventory DB and says "Ahh yes item at loc x,y = broken rusty dagger. The client recieves the message that he has succesfully equiped the broken rusty dagger.My goal for my databases is to make the client in no way able to directly interact with any of them. all clients are able to do is send requests to the landblock server they are currently on to interact with entity x,y,z and the server then midiates with the databases so that, in theory, the databases are unhackable. I''ve designed every one of my engines on this premise. When a client casts a spell, sure he can hack himself locally to say he is casting "Gerards mystic touch" for a complete heal on every player in a 100 foot radius.. but all the server sees is the clients request to cast spell# 613 in the clients spellbook. The server checks that spell and sends it to the combat server who then casts novice heal self I on the caster and laughs as the casters group lambastes him for not healing them The system isnt perfect but it was the best I could design to minimize the hacking. Hackers WILL get your datastream decoded. The best I can do is simply make that datastream useless to them as far as manipulation goes.Best of luck. Sorry for the long post. Hope it was helpfull.Mark  Aakrana: The Forgotten LandsIf you have C++ experience and wish toassist in the alpha development of our networktransport using very easy middleware, please contact me.;  Hi all,Many thanks for the informative replies, esp. from Slyxsith.I know that ultimately whatever I do it''s not going to make it hackerproof; the best I can hope for is a decent first line of defence.I''ll probably go with my original idea as my initial first line.Cheers guys  www.coldcity.comcode, pics, life ;  Slyxsith,Your approach is exactly the same as what I already do; although I do allow the client to do predictive movement to minimise lag, with the server correcting the position/speed/heading if necessary.Thanks again,I. 