Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

The new iPad version of Uplink appears to be using some newer saving mechanic than the PC/Mac version. Macs and PCs use the REDSHIRT format, but the iPad appears to instead be using SAV62 at the start of saves, instead of REDSHRT2 or something. Also, the iPad version is partially in plain text, and the rest is encoded. And if you modify any of the plain text, the save file corrupts when you try it in uplink (crashes the game). However, if you take a iPad save and put it on the PC, it runs perfectly and then saves a REDSHIRT version of the file.

Does anyone know how to decrypt this kind of encryption?

share|improve this question

closed as off topic by B-Con, Ilmari Karonen, CodesInChaos, mikeazo Jul 20 '12 at 18:17

Questions on Cryptography Stack Exchange are expected to relate to cryptography within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Also, it appears the encryption is like a decrypted REDSHIRT file (when I decoded it with this(mario-konrad.ch/wiki/doku.php?id=software:redshirt:start) anyway. –  Psp4804 Jul 19 '12 at 4:38
    
I took a look at an iPad Uplink save file ([NAME].usr). Its contents do not look by any means encrypted. If you cannot parse the save file directly, you might want to convert it into a Mac/PC save file (by replacing SAV62 with REDSHRT2 and XORing every byte afterward with 0x80 - assuming I understood the format correctly). –  Chris Smith Jul 19 '12 at 7:53
    
@ChrisSmith So I should convert it to Desktop by replacing Sav62 with Redshrt in the file (not putting it through the desktop program)? Then run the parsing script on it? –  Psp4804 Jul 19 '12 at 14:55
    
Also, it may be good to mention: Nobody has made a REDSHIRT2 decompiler it looks like. I'm using a redshirt decompiler on a PC file (redshirt2) to get a partially plaintext and partially random characters and stuff. That might be the issue with that. –  Psp4804 Jul 19 '12 at 15:05
    
Do you have the specifications for the REDSHIRT and REDSHIRT2 ciphers? A quick search led me to believe that one of the two is a simple XOR cipher, and I assume that so is the other. –  Chris Smith Jul 19 '12 at 15:16
show 3 more comments

1 Answer 1

I don't think this question is on topic for the Cryptography Stack Exchange, but, just for the sake of anyone who finds it on Google, let me give what I think is the answer.

I don't have Uplink for iPad (nor, in fact, an iPad at all), but I do have it for Windows, so I went and took a look at my save file. After stripping off the REDSHRT2 prefix and XORing every byte with 0x80 (which is what's supposed to do the trick for plain old REDSHIRT encoding), a hex dump of the output looks like this:

0000000: 8099 f313 630f 668b 0fb8 c492 3e98 3bd1  ....c.f.....>.;.
0000010: 80b9 2b9e 6953 4156 3632 0001 0000 0001  ..+.iSAV62......
0000020: 0000 0016 0000 0020 0000 0007 0000 0001  ....... ........
... some lines omitted for brevity ...
0000170: 0010 0000 0042 656e 6a61 6d69 6e20 486f  .....Benjamin Ho
0000180: 7765 6c6c 000a 0000 0053 6561 6e20 4d65  well.....Sean Me
0000190: 6164 0002 0000 0020 0001 0000 0000 0001  ad..... ........
...

The rest of the output looks like plain ASCII text interspersed with binary data containing lots of null bytes, just about what you'd expect from a binary save-game format. So it looks like the SAV62 is in fact the internal header for the unencrypted save file format, and you don't need to do anything to decrypt your files any further.

(I'm not sure what the 21 bytes before the SAV62 header are about, but I suspect they're some kind of checksum. The first byte after REDSHRT2 is null in all the save files I have, which would leave 20 bytes = 160 bits for the checksum. That's about right for, say, an SHA-1 hash, but they don't seem to actually match the SHA-1 hash of the remaining data.)

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.