Thought I'd share this. I had the idea of saving game status using primes. I have this game where the played level number is saved in a cfg (or ini) file. The task is to convert a level number, say 1 - 10, to a coded number and save it. Then, at next app launch, read the number and decode it.

The coding thing goes as follows. Numbers 1 to 10 correspond to 51st to 60th prime numbers. F.i. if I code number 3, I pick the 53rd prime number. Then I repeatedly multiply the number with random numbers below the 51st prime number until I get an integer overflow. The previous product before the overflow is my coded number.

To decode it, I factorize the number and check which is the highest prime factor. I compare it with primes #51 - #60.

This system could hold more than one number. Say primes #31 to #40 would mean level number, #41 to #50 bonus status, #51 to #60 would mean lives left. Multiply them together, then repeatedly multiply with random numbers below the 31st prime. And after factorizing, you will find your three primes telling you the status of the game.

Of course this is not fool proof. I just happen to like primes and it was fun to implement a class for this. And I needed an easy way to store game status in a text file like a cfg file, to be able to edit the status by hand for testing purposes. I could easily switch to a binary file, when creating a release version of the game, just to make it a bit harder to crack, but I guess I won't bother.

This might be a typical WRIS thing of mine.

I think you should make it pick numbers from 1 to the 31th prime * 2 - 1

It could make the encryption faster because overflow would be reached faster ^^

Good job reinventing the wheel Personally I'm also fascinated by this sort of principles. But the math involved is like voodoo to me. IIRC prime factorization is a very slow procedure. (Dividing by ten numbers isn't )
Some (noobish ideas):
- You can code an 'unlimited' string of numbers that need to be factorized by using sort of a 'protocol'. (F.i. "prime #1" means end of number.) Takes a bit more work to get a better range, but you get the idea. (As a kid I made a 'secret code language' using this idea.)
- You can mix-up the primes used, kind of like a key. Using higher primes to confuse is trivial. If you want to want to use lower primes, be sure to exclude them from the random factorization.

In my game I just gave each level a random name and stored that in plain text in the config file and cross-checked against an array in code.

Just rot13. That'll stop 80% of 'em.

@OnlineCop

Now that you've made public how the encryption works, it's become useless (which is a bad think since it means your encryption relies on not knowing the algorithm used).

But it gives more value to the gaming. They still have to figure out how to do the factorising. And they still have to figure out what primes correspond to what thing. If they succeed, I guess I've made them even more happy.

Ok, if I rot13 it: fgnghf = 244863114

Um, I guess I could as well just use that name from the start and not perform the actual rot13 thing at any point.

Special Christmas cookies to the first one to figure out which level number is hidden in the number above.

The highest prime factor of that number is 137, which is the 33rd prime number. So I guess it codes the 3rd level :p

Open Mathematica and type FactorInteger[n] . With such small numbers the result is instantaneous.

Even better would be to use rot26. Wouldn't that stop like 160% of them or something?

Or:

$ factor 244863114
244863114: 2 3 37 83 97 137

Installed by default on every GNU/Linux operating system .

See, even if I told you this much, no one has figured out the right answer. Just in case someone would like to figure it out, I won't reveal it yet. But the real situation is of course that you know what level you are on when you quit the game. And you want to cheat by creating the secret number corresponding to a higher level and writing it by hand in the settings.ini file.

So if you find the number 244863114 in the file, you have solved level 8 in the game. What number could you write there so that the program believes you have solved level 9 and lets you play level 10?

139 because you have 13 * 10 + 9.

Edit:

A serious reply. The drawbacks are:

1. There's no validation. I can pick any large number and if it has some expected prime numbers as a factor, then it's valid.

   
   

2. I can play the same level many times and get different values for the same level. I just keep factoring that number until I find the common factor.

Now of course #2 is made more difficult without prior knowledge, but if you are looking for patterns in a number, it would make sense to look at its factors.

How about something simple like add a mod 7 check digit to the end to decrease the chance of stumbling across a random prime then? e.g. 179 becomes 1794.

In a real world situation I wouldn't have only the number for level 8, but also the number for previous levels.

I think that once the player know that the factors store the information, it would not be hard to work out which factors are important -- but I don't think anyone would get that far in the first place unless it was really important for some reason. Playing the game itself is probably easier and more fun than trying to decode the save files.

Very true.

If you re-encode each variable at each save, that might be a pretty good deterrent for the average cheater. (Given that the stored variables change a lot.) To crack that, you'd have to fill in a random number, until it is valid, and then see which value in-game has changed.

No, you'd stop 60% from being stopped; thus only stopping 40%.

My point. If that is true, I've provided some fun. If the decoding is more fun than the game itself, I've provided some fun.

The third option is that neither is fun.

Here are possible numbers for previous levels:

1  52405870
2  715183693
3  33987587
4  166937969
5  48161165
6  28905073
7  81948229
8  94781258
9  99191095
10 47991559

Here's another list:

1  30965590
2  22503131
3  778272953
4  51739793
5  25087921
6  41662858
7  55675786
8  282614834
9  231828509
10 77419357

Guess it's obvious now - if anyone bothers at all. The game I used this in is my SantaHack entry, found in the Depot forum.

But if 139 is one prime factor that has to be there, you have one chance of 139 to pick right.

I take it no one's solved this one yet?

If you're looking to provide some real fun, you should consider making your save states as easily editable as possible--perhaps including a custom editor, allowing players to create save states as they see fit.

It shows that my system works. There's not enough fun involved to solve it. And still I believe it's not too hard for you to solve, say you get thrilled by the game but can finish only so many levels. If that's what it gets to make you solve my codec, then you are happy and I am happy.

Editing with Notepad is the way to go. If I provide a GUI inside the game for this, I kind of give it away that it is meant to be hacked.

What are we supposed to be solving? It's obvious that the highest prime factor starts at 101 for level one, and then increases for every level.

Um... yes, simple as that.

If you really want to make you stuff secure join GIMPS and starting looking for new Mersenne prime's and make sure to not tell them if you find a Mersenne prime.

If by a large miracle you find one, use that and any other one in that form of encryption that uses two primes to encrpyt everything.

Not sure if that's even legal :/ (if not I don't recommend it as I don't want to be prosecuted).

It'd work but it's probably the most inpractical advice can get though.

I don't even remember why I came up with this idea. Probably because of the beauty^[1] of the primes. But I guess I thought something like this:

Hard code a table with pre-chosen random numbers corresponding to the levels. Use the table when reading the cfg file at start and writing the file at end. To avoid people from figuring out the correlation, add more randomness to the saved number so that each quitting of the game saves a different number, even if player is on same level.

The opposite seems ideal: don't print out different values, if the state hasn't changed. Or you should encode the names of variables too... Or all saved numbers must share a common extra encoding, that the program checks for (f.i. all saved numbers must have same lowest prime(s)).