Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Encoding saved Files

Author
Message
Commander in Chief
18
Years of Service
User Offline
Joined: 15th Apr 2006
Location: Carbondale, PA, USA
Posted: 5th May 2007 06:56
Now everyone that's saved something with DBP knows that you can "create" your own filetype. Now I wonder how to encode it..

I have seen several examples of encoded files with just tons of boxes and weird characters. Has anyone accomplished this in an easy-to-use way? It is just annoying when you open up your new file in notepad and there you have it, all the editable data they could get. They can change highscores and such.

Any ideas?

---PARANOID PRODUCTIONS---
TDK
Retired Moderator
22
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 5th May 2007 07:11
Each character on the keyboard has an ASCII code. If your data is stored in variables ready to write out, you could pass it to a function which applied a formula to the characters before writing it out.

When you load each piece of data back in, you pass it to another function which applies the same formula in reverse.

For example, say you wanted to write out the name ABBA. The capital letter A is 65 in ASCII. If you subtract 15 from it, it becomes character 50. B is 66 and so on - replacing all the letters of ABBA with the character 15 less than what it was.

You then write out the amended string.

When you load it back in, you get the ASCII value of each character and ADD 15.

This is a very simple example - obviously you could use something a lot more complicated than subtracting and adding the number 15.

TDK_Man

Commander in Chief
18
Years of Service
User Offline
Joined: 15th Apr 2006
Location: Carbondale, PA, USA
Posted: 5th May 2007 07:13
Could someone do an example? Or maybe atleast show what command I would use to load ASCII and such. I am not very good at DBP.

---PARANOID PRODUCTIONS---
Veron
18
Years of Service
User Offline
Joined: 22nd Nov 2006
Location:
Posted: 5th May 2007 08:49
When you write to your savefile, use the command WRITE BYTE, instead of WRITE STRING. Below is a quick example of using the WRITE BYTE command to encrypt something that you're saving to a file.



Open the MyData.dat file and the contents of it should be encrypted.


Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 5th May 2007 13:30
Yeah but then anyone can decode it when they open it heh. I like TDK's idea, I never thought about that

TDK
Retired Moderator
22
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 5th May 2007 14:34
Here's a quick example I just knocked together. It's still very simple, but a little harder to crack than just adding or subtracting 15 to the ASCII value.

I guess however that it's not really necessary to be crack-proof - just to stop Joe Bloggs from opening it up and changing anything.

What it does is add 15 to the value similar to the original idea, but also adds 1 to the first character, 2 to the second character, 3 to the third and so on. Not impossible, but a little harder to figure out...



Just call the Encode function in a loop with each piece of information you want to write, inside the Open To Write/Close File block.

Call the Decode function in a loop with each piece of information you want to write, inside the Open To Read/Close File block.

If all your data is of type string then the functions will work with 'numbers' too - ie a hiscore table. (Numeric variables can be converted to strings with STR$).

TDK_Man

zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 5th May 2007 15:39 Edited at: 5th May 2007 15:43
Another thing you can do is pad your data with "non actual data bytes" in another part of your file have an encoded checksum(basically a result of the formula apllied to the padded bytes)

Let's stick with ASCII and 65 = A but your -15 in your encoding so A=50.

Now lets for simplicity sake saye the "actual game data" is "ABBA", "ACCA", "ADDA", "ABBA". Here's the save data:

ABBAACCAADDAABBA

in ASCII decimal with encoding it would be...
50515150505252505053535050515150

Now what if we padded specific locations as we wrote out the data, and then at the end of the file simply added them up and have the result. If someone changed the data, the sum would fail. Of course you can use a more complex formula than just addition.
For our purposes thougH, lets say that every 3 decimal numbers get added to get our padded data. the final decimal will be the result of adding the padded numbers.

so our data looks like this (padded #'s & checksum in bold):
5051015175051005275251225075051035311505100516515110101

the 101 at the end of the file is a result of adding the padded values.

10+7+10+7+12+7+10+11+10+6+11=101

Now if someone changes the padded values, or the actual data, the checksum at the end won't add up, or the padded values will be wrong, or both; when the save file is loaded back in and checked.

Of course you could convert the values to HEX and deal with the acutal bytes than decimal.

Code Dragon
18
Years of Service
User Offline
Joined: 21st Aug 2006
Location: Everywhere
Posted: 5th May 2007 20:19
Yeah, but then anyone could go in and change the checksum.

A good trick is to reverse the strings with the secret reverse$ command before encruyption.

"Once there was a polygon mesh who was very sad because he was only Gouraud shaded."
vibe runner
18
Years of Service
User Offline
Joined: 7th Aug 2006
Location: The Future
Posted: 5th May 2007 20:52
I enjoyed encoding my own encryption, and if you want I can dig it out and paste it here, but Gamecrypt is probably the easiest and best way to go, in my opinion.
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 6th May 2007 03:52
Another good method is renaming the text files to executables, something not obvious, like update.exe. It'll still contain the data, but will take a cracker with patience to figure out the data is in the executable.

zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 6th May 2007 05:32
@Code dragon,

You wouldn't know how the checksum is derived or where it actually is to change it. You know now (on that one example), because I described and discloses that method.

But the checksum could be at any location in the file, and it doesn't even have to be in contiguous spots. The data doesn't have to be padded the exact way I just explained, nor does the checksum have to be a result of adding all of the padded bytes.

I was explaining the method. Of course you would know where to look on that one. But you would have no idea which were the padded bytes or where the actual checksum locations were unless I told you!

Code Dragon
18
Years of Service
User Offline
Joined: 21st Aug 2006
Location: Everywhere
Posted: 6th May 2007 15:59
Oh, I see. So if they didn't know where the checksum was they couldn't crack it.

Another good idea is to save it in the windows folder. Name it win32xcvr.exe or something else important looking.

"Once there was a polygon mesh who was very sad because he was only Gouraud shaded."
Commander in Chief
18
Years of Service
User Offline
Joined: 15th Apr 2006
Location: Carbondale, PA, USA
Posted: 7th May 2007 03:14
Well, I got GameCrypt and it ROCKS! Sometimes the help files arent very good at describing how to do something *sigh*. Oh well. It works very well, though.

---PARANOID PRODUCTIONS---
RUCCUS
19
Years of Service
User Offline
Joined: 11th Dec 2004
Location: Canada
Posted: 7th May 2007 18:58
Quote: "Another good idea is to save it in the windows folder. Name it win32xcvr.exe or something else important looking."


Thatll fire off most firewall systems.

Commander in Chief
18
Years of Service
User Offline
Joined: 15th Apr 2006
Location: Carbondale, PA, USA
Posted: 7th May 2007 23:54
Heheheh...

---PARANOID PRODUCTIONS---

Login to post a reply

Server time is: 2024-11-25 17:37:05
Your offset time is: 2024-11-25 17:37:05