Home » Stars! Clones, Extensions, Modding » Stars! Extensions » Stars! decryption
Stars! decryption |
Fri, 09 March 2018 11:34 |
|
ricks03 | | | Messages: 222
Registered: January 2012 Location: NC | |
|
It's been a long time that the decryption code has been a tightly-guarded secret in the Stars! community. If there's anyone still out there, can someone send it to me or point me to a reference? Given that Stars Autohost protects turn file downloads with a password, others can't get to turns to use the tools on them anyway, so I don't see how there's wide-ranging ability for abuse that doesn't already exist.
I want to develop tools that provide dynamic data to players within a hosted game, but I really would like to be able to do that with password-protected files.
(really, all code that teases data out of Stars! is useful to me. I'm a terrible programmer, so all the examples I can get are helpful).
Rick
[Updated on: Fri, 09 March 2018 11:36]
https://www.irelandbybicycle.com
http://totalhost.sinister.net:999
https://github.com/ricks03/TotalHostReport message to a moderator
|
|
| | | | |
Re: Stars! decryption |
Sat, 10 March 2018 05:19 |
|
platon79 | | Chief Warrant Officer 3 | Messages: 185
Registered: February 2004 Location: Norway | |
|
I'll try to explain a bit more how things work. The files are encrypted with the encryption algorithm. We have the way to decrypt this. Additionally, the passwords go through a hash-function. Because of the nature of hash-functions, it's usually extremely difficult to know the input of the hash-function given the output, and therefore we have to try different values (brute-force it). This is also why bitcoins takes so much computing power, because all the miners try to find input-values that will match a given hash-value. It's far easier in stars however, as we are talking about much smaller values. And it is in the nature of hash functions that multiple input values can give the same output value, and we only need one that mathces. Try to create a race in stars with password aaaaa, and you will see that you can also enter aaba when you enter your password, and stars will accept it just fine since those 2 values produce the same hash-value.
I have a tool in the github java project that guesses password, and it is fast if the password is only 4-5 characters. 6 characters and more takes much more time.
However, the stars hash-function is not that advanced, and raptor mentioned in the thread "Should Stars! files structures be publically available?" that "This algorithm can be easily broken, however, by going backwards and attempting to divide by all char values with no remainder, then subtracting a another char value, and keep doing that until your left with only an ascii char left. This would be orders of magnitude faster than brute-forcing because the hash is not one-way. The only thing you have to watch out for is the integer overflow, which seems to happen after only 6 or 7 characters in a password." Haven't tried this myself, but if the password-extractor doesn't give you the answer in a meaningful time, you could try to incorporate this in the algorithm.
Report message to a moderator
|
|
|
Re: Stars! decryption |
Sat, 10 March 2018 11:42 |
|
ricks03 | | | Messages: 222
Registered: January 2012 Location: NC | |
|
Right. Note I get how hashing and encryption works in general.
Your response however still leaves me thinking about a different solution. If the stars files are encrypted "with the encryption algorithm" that we have a way to decrypt, they can be decrypted. Got it, so we decrypt it, and now we have a decrypted file with an encrypted password stored within.
If I understand correctly from what you said, if the passwords are hashed separately, but not used as part of the base encryption (say, as an encryption key), then they're just stored in the (now decrypted) file.
So why go to the effort of decrypting them? I mean, I don't care about what the password is, I just want Stars! (and tools) to be able to read the file. Just overwrite the encrypted password data with the data for a known (or, really, blank) password.
[Updated on: Sat, 10 March 2018 11:43]
https://www.irelandbybicycle.com
http://totalhost.sinister.net:999
https://github.com/ricks03/TotalHostReport message to a moderator
|
|
| | | | | |
Re: Stars! decryption |
Sun, 18 March 2018 11:01 |
|
ricks03 | | | Messages: 222
Registered: January 2012 Location: NC | |
|
ricks03 wrote on Mon, 12 March 2018 21:34I believe the .xy file includes other data besides the coordinates (tho I can't find the article now). However, the password is probably stored in the .hst file.
From https://wiki.starsautohost.org/wiki/Technical_Information:
game.xy
is actually a game configuration file, with very basic information:
game settings: universe size, planets density, players number (note: there is no details on specific players and their races), distance between players start locations, game options (like public players scores, galaxy clumping and others) and winning conditions
planet locations and their names (note: there is no planet stats, like minerals concentrations)
But yup, no password info!
[Updated on: Sun, 18 March 2018 11:01]
https://www.irelandbybicycle.com
http://totalhost.sinister.net:999
https://github.com/ricks03/TotalHostReport message to a moderator
|
|
|
Re: Stars! decryption |
Tue, 31 July 2018 00:49 |
|
ricks03 | | | Messages: 222
Registered: January 2012 Location: NC | |
|
OK. So the password is stored in the .m file, in the player block (Block #6), in bytes 12-15. Perhaps everyone else knows this (the player block(s) also exist in the .hst file)
Here's my understanding. Stars file data is stored in blocks. Each block consists of the block type and block size, followed by data that's encrypted (which really isn't "encrypted") using a random seed (which isn't really "random").
If I use the Decryptor class from the stars-4x Github repository: https://github.com/stars-4x/starsapi I can determine the random numbers and decrypt the Player block in the .m file.
I created a game with 2 players, and then I made a copy of it. In one copy, I just saved and submitted, and generated turn 2401. In the other copy, I set the player password in 2400, and generated turn 2401. Bytes 12-15 are all 0s in a non-passworded .m file, and not all 0s in a passworded file. Everything else is the same. I don't know what the password is, but I figure I can just change those values to 0, and reencrypt and write it back out, permitting replacing the password with null (That will take me a while, working from a language I don't know, dealing with binary data which I don't understand, but I'll get there).
What I think is interesting / questionable in my theory is that when I look at the two almost identical .m files from 2401, I would expect only the player block part of the data to be different, but the entire file is different after the FileHeaderBlock (block 8, the first block) and the Block ID and size for Block 6 (the second block).
Or is another level of encryption added on the .m file when a password is set?
If that's the case, it clearly doesn't apply to the .HST file (since the host obviously doesn't need everyone's password). So that password data is likely accessible/changeable in the .HST file, just pull it apart, write the .HST file back out, and generate new turns to generate new, clean, password-less .m files?
Insights appreciated.
Rick
https://www.irelandbybicycle.com
http://totalhost.sinister.net:999
https://github.com/ricks03/TotalHostReport message to a moderator
|
|
| |
Re: Stars! decryption |
Tue, 31 July 2018 18:00 |
|
ricks03 | | | Messages: 222
Registered: January 2012 Location: NC | |
|
raptor wrote on Tue, 31 July 2018 13:08It shows that the header block is not encrypted and that a salt is pulled out from it. This salt is used to encrypt/decrypt the rest of the blocks and is different for every file (I think) - which is why there will always be differences.
Since the password is in the PlayerBlock, it is also encrypted with the salt and will be different between files at the byte level.
Yes, I know the FileHeaderBlock is not encrypted, and that the password, as part of the PlayerBlock, will be encrypted. The salt is pulled from the FileHeaderBlock, and then randomness is initialized with is a combination of the Game ID (which is vaguely unique), the turn, the player #, and the shareware state.
Thanks for the idea. Digging into this, the seed does look to be different between the two different 2401 files. That's awesome. It must be a (more) true random number assigned when the turn is created, which explains the difference in the files, and gives me hope that this will work on .m files as well as .hst files.
https://www.irelandbybicycle.com
http://totalhost.sinister.net:999
https://github.com/ricks03/TotalHostReport message to a moderator
|
|
|
Re: Stars! decryption |
Thu, 09 August 2018 18:19 |
|
ricks03 | | | Messages: 222
Registered: January 2012 Location: NC | |
|
I can now reset the password on any .m file or within a .hst file, as long as the file only includes one turns worth of data.
It's trivial with raptor's files (if you actually know Java). Decrypt the file, replace 4 bytes, reencrypt the file. Anyone writing a utility that creates / rewrites Stars! files can in moments create a utility to reset Player passwords.
Re: processing .m files (and .hst files) with more than one turn.
A .m file with more than one turn is (effectively) each turn appended to the last (block structure 8,6,[n],0,8,6,[n].0,8,6,[n],0. etc.]
Anyone know if the encryption seed should be reset on each turn's worth of data?
I suspect the fMulti value (also in the FileHeaderBlock) might well come into play as well. The value for fMulti is either 0 (one turn) or 1 (more than one turn).
[Updated on: Sat, 11 August 2018 15:17]
https://www.irelandbybicycle.com
http://totalhost.sinister.net:999
https://github.com/ricks03/TotalHostReport message to a moderator
|
|
| | |
Re: Stars! decryption |
Sun, 12 August 2018 00:59 |
|
ricks03 | | | Messages: 222
Registered: January 2012 Location: NC | |
|
Yeah, it's one reason I built my TotalHost site. But playing a year-long game with people I don't know, who could drop out at at a critical game screwing up point with no way to replace them, has made me only play with friends I've known for a while (burned more than once, badly enough it's made me eschew the general Stars! community even tho it was two decades ago).
Right now I can reset any password. Even for files with multiple turns, I can set it to AI, resolve that, and then change back to not AI and reset the password. Once I figure out how to deal with files including multiple turns, I can build that functionality into TotalHost, and give the game creator the ability to reset passwords (while at the same time notifying all the players what's going on).
Mind you, I'm working on a tool that's likely never going to be used, but everyone needs more hobbies, right? It gives me something to develop my coding skills.
I sent you a PM, can I put code up on the github site?
https://www.irelandbybicycle.com
http://totalhost.sinister.net:999
https://github.com/ricks03/TotalHostReport message to a moderator
|
|
|
Goto Forum:
Current Time: Sat Apr 20 05:36:12 EDT 2024
|