I'm trying to learn how to decrypt an ini file. I'm using Blowfish although other prefer ini++. The encrypting works but the decrypting doesn't. When decrypting, Do I need to -add- the key I used to encrypt to decrypt or -remove- it? And do I need two events- one to add or remove the key and the other to decrypt?
I don't know if I'm using it right but every time I "add a key" before every Blowfish action, and then "remove key" once the saving or loading is done. Using some long winded name key. It's probably not a very secure method since I haven't read up on Blowfish or anything but it works. I think.
Heh, anything on a 4th gen programming language shouldn't be secure anyway. No matter how secure BF makes your files, a determined hacker could just access the file from the memory or take the file in that short moment when it's decrypted. It's like putting a heavy, fireproof lock on a wooden door.
Edited by Muz
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
It's like putting those "spoiler" tags - leaving it out in the open as INIs will make it too tempting to hack.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
the only way is to make a hash of all the info and stick it at the end. when loading the file check all the information against that hash. if its not the same somethings been changed in the file and its "corrupt". hashes of long strings of characters are impossible to hack since hashes dont use a salt or a key, you can only brute force them.
if the data is fine then the program can update the information as it pleases and make a new hash everytime something changes. not sure if theres a hash extension in mmf though
That's if you're cracking the encryption. You could just set a program to copy the program to memory when it detects a change, i.e. when the file is decrypted. Then you get an easy unencrypted file, unless MMF or the extension has some protection against that
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
thats why you use a password muz. the program has an internal key that is added to the information when its hashed and checked.
they wouldnt even need a program to change the data. they ould just need to hash their own data and add it. thats where the internal key comes in. its something complex that is added to the data that only the programmer could possibly know. its a string thats hardcoded into the program. it would take a lot of digging in memory to figure it out.
Ini++'s built in compression makes the files obscure enough imo. Yeah people could open them if they have MMF2, but i think if people are willing to put that much effort into hacking your game, let them.
lol, cecil, i mean you're going to unencrypt it at one time or another, otherwise it's just pointless to leave it encrypted and not access it. You guys are always thinking of the hardest way to crack it. I say just wait for the victim to open the door, doesn't matter how complex the lock is or how much brute force it can handle, once the door is left open by sloppy klik coders, it's easy to just take a snapshot and leave. I'll try and prove my theory sometime in the future, once I do the millions of other things I need to do first
That's kinda why something like INI++'s built in encryption would be safer.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
i never said anything about leaving it encrypted and never accessing it. think of it as an airlock. there are TWO doors. one is always locked. whether your coming in or going out.
when you load you take all the data in the file excluding the md5 sum. load it. add a key to the end whilst simultaneously md5 hash all of it. load the md5 from the file. check both of them. if they match. the file is good. if not, something was changed without the programs knowledge.
when you save. take all the data from the game/app. save it to the file. take all the data again, add the key and simultaneously md5 hash it. add that hash to the file.
the key is only ever added to the data during the hash, never passed from program to file. and it is only ever in memory in combination with all the data as it is passed to the md5 function. for a split second and gone as the function exits. a cracker would be hard set to get a snapshot AT ALL let alone filter through all the ram during that snapshot and find what they want when they dont even know what it is.
Oh great just as you guys post this thread the encryption setup in my game decided to go nuts. Might switch over to Ini++, gave it a try before and the one-step save all global values function is ace.
Advertisement
Post Reply
Edited by Muz
