ronfist, I do not repeat what I read I speak from expierence. Back in the old days I use to crack software. I have been in software development for over 25 years, yes a freaking long time. I do know what I am talking about, anything and I will repeat ANYTHING you do with software will be broken. There are software/hardware solutions that are safe, but as for just software, you don't stand a chance. Anything new or unique is just a challange for the real hackers and just more fun. You will not stop them in the long run, you can only hope to keep the honest folks honest.
theTroll
Making sure that client is not hacked?
Well then try break my idea :) I want to see if someone can come up with a way to crack it.
I've been cracking software too (mostly games), an idea like that doesnt just pop up in ur head everyday...
It's probably even possible to protect 3rd party libs with it, altho I'd have to think more about that. And if so it wont be a cross-platform method.
http://www.gamedev.net/community/forums/topic.asp?whichpage=2&pagesize=25&topic_id=389856
U even replied to it, its at the last page of the thread.
I've been cracking software too (mostly games), an idea like that doesnt just pop up in ur head everyday...
It's probably even possible to protect 3rd party libs with it, altho I'd have to think more about that. And if so it wont be a cross-platform method.
http://www.gamedev.net/community/forums/topic.asp?whichpage=2&pagesize=25&topic_id=389856
U even replied to it, its at the last page of the thread.
It is still only a matter of time. It is get cracked just like everything else. As long as you can read the asembly you can crack the code.
theTroll
theTroll
Quote:Been done & defeated already.
Original post by Anonymous Poster
I just had an idea that Ive never heard of before (but may have been done).
...snip...
It only does what most other methods do -- just make it more dificult to hack.
Maybe a daily patch system (changing the response validation code calculation method constantly) would also make the hacking alot harder.
Quote:
Original post by TheTroll
It is still only a matter of time. It is get cracked just like everything else. As long as you can read the asembly you can crack the code.
theTroll
U crack software, I crack software and we both can't find a way to break it. Why is it so hard to admit it's perfect? [smile]
Don't just say "they will find a way", that smells to me like u just wanna increase your postcount.
Quote:
Original post by Anonymous Poster
I just had an idea that Ive never heard of before (but may have been done).
You have a chunk of code that calculated checksums, but it will do a subrange of the code block of the program/dlls. The subrange is different each time (random from server) and calculates to a different value each time (potential,ly a very large number ( a 32k code chunk has something like ((32k X 32k) / 2) options to be requested. The client would return a value that would be checked against a master value on the server (its effectively a block key cypher).
I suppose the hacker could maintain a second set of files (the original ones and calculate the correct return value...... ) Maybe a time limit on the return being sent would prevent fast enough file reading (forcing the hacker to keep all of the original unmodified program/dll in memory to be able to respond.
So dont rush out an patent it because it isnt a perfect solution.
It only does what most other methods do -- just make it more dificult to hack.
Maybe a daily patch system (changing the response validation code calculation method constantly) would also make the hacking alot harder.
Thats basicly a crappyfied version of my idea, with the exception that urs can still be cracked.
There is no certain way of stopping a cracker once they decide to break your game. There are only ways of slowing them down. There is a good article (albeit about piracy) on GamaSutra that talks about Spyro: Year of the Dragon (you need to be a member to read this).
Basically it talks about ways that the crackers were slowed down with releasing a working crack for the game while it was in initial release. Although not entirely about client->server games, you can certainly take some of the elements as a basis to build on when building in copy/crack-protection measures.
Basically it talks about ways that the crackers were slowed down with releasing a working crack for the game while it was in initial release. Although not entirely about client->server games, you can certainly take some of the elements as a basis to build on when building in copy/crack-protection measures.
man look at the date of that article...
October 17 , 2001
If im right this is not an online game? My method will only work with online games. (thats why im posting on this subsection of the forum "network programming")
Of course my apps protected with this will be cracked, it's as easy to crack as any other application.
The idea is not to stop someone from cracking it, the idea is to stop someone from playing the game with a cracked client.
October 17 , 2001
If im right this is not an online game? My method will only work with online games. (thats why im posting on this subsection of the forum "network programming")
Of course my apps protected with this will be cracked, it's as easy to crack as any other application.
The idea is not to stop someone from cracking it, the idea is to stop someone from playing the game with a cracked client.
From my other post (sorry for cross posting, but its relevant here too):
One idea that I had on the theory of copy protections is running code from the server. The client is given a specific (perhaps randomly selected) copy protection algorithm to run. They then run this and send back whatever data the algoritm requires to the server.
The strengths of this:
1) It basically limits games for those who use hacked software, as in, if the hack cannot produce the required output for the code then it cannot be trusted by the server.
2) By doing this, those that use the hacked software frequently, will also frequently have problems in playing the game, leading them to either become disallusioned with the crackers (and purchase the software/stop hacking it), or lead them to hating the game and giving up on it (and we didn't want cheaters there anyway).
3) The added strength to this is that you can provide checks for known hacks AFTER the game has been released.
Weaknesses:
Obviously any program that allows code from a remote source to be run on it has the potential of being compromized, though I believe there is less of this kind of issue than a standard Microsoft vulnerability, unless of course the crackers take control of your server.. and THAT would be bad for business.
I am sure there are more weaknesses, but I cannot see them at the moment. This also has many strengths with the ability to break the game even after the game has been successfully cracked.
Comments and ideas? I am sure this could be made better than my current ramblings suggest.
One idea that I had on the theory of copy protections is running code from the server. The client is given a specific (perhaps randomly selected) copy protection algorithm to run. They then run this and send back whatever data the algoritm requires to the server.
The strengths of this:
1) It basically limits games for those who use hacked software, as in, if the hack cannot produce the required output for the code then it cannot be trusted by the server.
2) By doing this, those that use the hacked software frequently, will also frequently have problems in playing the game, leading them to either become disallusioned with the crackers (and purchase the software/stop hacking it), or lead them to hating the game and giving up on it (and we didn't want cheaters there anyway).
3) The added strength to this is that you can provide checks for known hacks AFTER the game has been released.
Weaknesses:
Obviously any program that allows code from a remote source to be run on it has the potential of being compromized, though I believe there is less of this kind of issue than a standard Microsoft vulnerability, unless of course the crackers take control of your server.. and THAT would be bad for business.
I am sure there are more weaknesses, but I cannot see them at the moment. This also has many strengths with the ability to break the game even after the game has been successfully cracked.
Comments and ideas? I am sure this could be made better than my current ramblings suggest.
ronkfist: What stops someone just following what the assembly is doing, seeing what bytes it writes (what instructions), and from there working out what the code does?
If that code is just crack protection, what stops a hacker editing the code to remove that check, or just sending the correct checksum back to the server?
Anonymous Poster: Again, a hacker can just bypass that check and do a checksum on the original data. Reading data from a hard disk can take up to a couple of hundred miliseconds (depending on the size of the file, if the drive needs to seek, etc etc). Lag in games can be as high as 1000ms, so you wouldn't be able to reliably check that the client isn't reading from disk.
If that code is just crack protection, what stops a hacker editing the code to remove that check, or just sending the correct checksum back to the server?
Anonymous Poster: Again, a hacker can just bypass that check and do a checksum on the original data. Reading data from a hard disk can take up to a couple of hundred miliseconds (depending on the size of the file, if the drive needs to seek, etc etc). Lag in games can be as high as 1000ms, so you wouldn't be able to reliably check that the client isn't reading from disk.
Quote:
Original post by Evil Steve
ronkfist: What stops someone just following what the assembly is doing, seeing what bytes it writes (what instructions), and from there working out what the code does?
If that code is just crack protection, what stops a hacker editing the code to remove that check, or just sending the correct checksum back to the server?
Because you didnt read the post where I explained the idea?
- There's no way a human being can crack a binary in 30 seconds(just loading it up in your favourite disassembler takes usually a minute or 2). A cracker would have to write a program to do it for him, which is simply too difficult if you do well.
- Debugging on the fly is impossible. It would cause you to disconnect and next login ud have to crack different binary.
Theoretically it is possible to break it, but in practice it is next to impossible.
And even if they do, it would be easy to just implement new levels of security as someone mentioned in the other thread.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement