simple encryption or just useless
Author
Ok, I asked people about simple encryption before and they just said they changed the ASCII of the letters and the such. But see......ok.......if I include a password file as part of my project (MSVC++ (5 if you really wanna know)) can people get into it (if for some crazy reason theyd want to). If so how exacly can I simply encrupt it.
The one thing I read about incription used some methods I can''t do yet, including turning letter/numbers into bit code which I never saw in any of my C++ tuts/books. But what can I do for atleast decent protection here. I mean if I haveto I''ll make a 250 char long password, but how safe would even that be?
one thing you could do is this
when you are writing your file out (in binary) write it out byte by byte or some other fixed amount. Then right before you write it out like add, subtract, multiply, or divide the byte by a certain number. You can do this multiple times per byte mixing the math operations. Then you write the byte out.
Now when you need to read the file back in you need to do the opposite math operations in reverse order to get the byte back to the original value.
"I pity the fool, thug, or soul who tries to take over the world, then goes home crying to his momma."
- Mr. T
when you are writing your file out (in binary) write it out byte by byte or some other fixed amount. Then right before you write it out like add, subtract, multiply, or divide the byte by a certain number. You can do this multiple times per byte mixing the math operations. Then you write the byte out.
Now when you need to read the file back in you need to do the opposite math operations in reverse order to get the byte back to the original value.
"I pity the fool, thug, or soul who tries to take over the world, then goes home crying to his momma."
- Mr. T
no matter what you do, someone can break your encryption if they want to bad enough (and have the skills to do so)... if you hard code a password into your program, for example, there are ways to find out what it is (i don''t know how to do this, but i read about it)... so, the only reason to encrypt your data is to keep schmuckos and wannabes from editing it; there is someone out there, somewhere, who can crack your encryption... just hope that guy doesn''t like your game 
--- krez (krezisback@aol.com)
--- krez (krezisback@aol.com)
That''s not true. There are many forms of encryption that are virtually unbreakable, and one form of encryption that actually is 100% mathematically unbreakable. If you really wanted to secure something, you could use something like RSA or PGP and if you implement it properly your game would be safe for a few billion years (or until someone invents quantum computers).
RSA is really slow, though.
The method''s of choice for password encryption (which is usually one way) is DES or MD5. That''s what linux uses for it''s password file. Best thing, you can get libraries that do these for free! Just do a websearch for something like "Open Source DES"
Also, there''s an open sourced encryption algorithm called ''blowfish'' that''s pretty darn good.
The method''s of choice for password encryption (which is usually one way) is DES or MD5. That''s what linux uses for it''s password file. Best thing, you can get libraries that do these for free! Just do a websearch for something like "Open Source DES"
Also, there''s an open sourced encryption algorithm called ''blowfish'' that''s pretty darn good.
There is no way to encrypt your game-data in a way that is even remotely secure (given a cracker that knows what he''s doing). After all, your game has to be able to decrypt the data. ''All'' the cracker has to do is use a system-debugger or similar tool to examine what your program does when it loads data.
If you don''t want people to be able to directly edit game-data, then implement some simple encryption (or perhaps better: compression) scheme to prevent the casual user from changing anything. Just don''t spend too much energy and time on implementing the protection. There''s no way you''ll be able to stop the people who know what they''re doing, anyway.
If you don''t want people to be able to directly edit game-data, then implement some simple encryption (or perhaps better: compression) scheme to prevent the casual user from changing anything. Just don''t spend too much energy and time on implementing the protection. There''s no way you''ll be able to stop the people who know what they''re doing, anyway.
The way I''ve encrypted my data is pretty simple.
Basically, when I go to encrypt my data, I 1st set a random seed value. I write that seed value at a certian place in the file I''m encrypting (the location changes as to where in the file it goes). I then add a random value to every byte I write to the file. At the end of the file I put a somewhat home-made checksum, so if any data changes, the checksum will fail. When I open the file, I check the checksum, and if it passes, I then read out the Random Seed, re-set the same random seed, then read out every byte, and subtract the random value from it, and, volia! I get my original values.
It''s not perfect, but, for someone to break it, it would take a good bit of work, and, if someone goes to that much trouble to hack my game, well, that''d actually make me proud
Basically, when I go to encrypt my data, I 1st set a random seed value. I write that seed value at a certian place in the file I''m encrypting (the location changes as to where in the file it goes). I then add a random value to every byte I write to the file. At the end of the file I put a somewhat home-made checksum, so if any data changes, the checksum will fail. When I open the file, I check the checksum, and if it passes, I then read out the Random Seed, re-set the same random seed, then read out every byte, and subtract the random value from it, and, volia! I get my original values.
It''s not perfect, but, for someone to break it, it would take a good bit of work, and, if someone goes to that much trouble to hack my game, well, that''d actually make me proud
I bet if you put a parity shift into your byte-stream you will confuse the majority of skript-kiddies who don''t understand what parity is used for, much less how to decode it.
I won''t even speculate on how to implement it so as not to give anything away.
---------
-WarMage
...because when you''re funk, everything is drunny...
I won''t even speculate on how to implement it so as not to give anything away.
---------
-WarMage
...because when you''re funk, everything is drunny...
Author
But, how do I get information into bits is my major question, cuz I know like the algorythm stuff (that is I''ve seen it) like regrouping the bits and dividing and the such.
But as it goes.....I have no clue on howto get my info into bits.
But as it goes.....I have no clue on howto get my info into bits.
Encryption that runs entirely on a user''s machine is useless imo. Who cares if they mess with the files? It may allow them to enjoy or benefit from your product more by doing so. You''ll never stop anyone who wants to break the encryption, since your executable is on their HD, and using a disassembler you get some very nicely output assembly code to browse. Using a program such as W32DASM or SoftIce you can easily monitor, alter, and therefore crack any program you want to. I suck at assembly and I can even mess around with programs using the disassebly and a hex editor (it''s a lot of fun, everyone should try it sometime ).
[Resist Windows XP''s Invasive Production Activation Technology!]
). [Resist Windows XP''s Invasive Production Activation Technology!]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
