Decypher passwords from passcodes (spoiler)

[Randolph Cherrypepper]

So there's enough source code available to figure out how to backwards engineer the passcode integer from any .dec file.

The passcode is an integer, but Decypher.exe wants a string. I have tried so many things to figure out how to turn a given password into a passcode: CRC-8, CRC-16, CCIT-16, XMODEM-16, MD5, SHA1, and probably more. I know only the first 7 letters of the password are used, but order matters and letter substitutions don't work (so if it is a hash, it's a pretty sophisticated one, unlike XOR or CRC-1 where order wouldn't matter). The only references in the .cs files is GetPassCodeFromString(), which is not defined anywhere that I've found.

Slightly exasperated, I tried something desperate to see if I could get around the password using Decypher.exe.

Here comes the black text.

David Leatrou's password dleatrou somehow turns into the passcode 43007. So I tried to bypass the password and decode using Decypher.exe Personal_Notes.dec 43007. No dice. That's decimal; the hexadecimal value is a7ff, so I tried Decypher.exe Personal_Notes.dec a7ff. No go. However, there is a standard representation for hex.

Decypher.exe Personal_Notes.dec 0xa7ff and the decoding process went through.

So if you can figure out how to determine the passcode given a .dec file (which you can do easily by decoding the E in ENCODE of the header), you can use that passcode directly into Decypher.exe. Yay.

[Randolph Cherrypepper]

Worked for Personal_Note.dec and C_EXE_contact.dec, both with unique passwords/passcodes. Did not work with CSEC_encode_1.dec, so I wonder if that file is a red herring that is corrupted or has some special blocking code built in.

[Randolph Cherrypepper]

CSEC_encode_1.dec isn't corrupted. Decode the header to find its origin, hack that system, and you find a few files with passwords. One works. So there's just something funky about that file where you cannot use the hexadecimal passcode directly.

[upc]

Alright, so did you get past the mission?

[cataclysm]

it feels like you found a round-about way to use Decypher and actually maniged to be a hacker in a skiddy game, now i wonder would you be able to actually decode the things you were never meant to...

[Randolph Cherrypepper]

Yeah I got past whatever missions I was doing. Actually for a few of these files, I decoded them using Decypher.exe before the password was given as part of the mission steps.

However I'm also finding more and more of these .dec files that eventually decode but their hex passcodes don't work. I still haven't figured out the pattern why sometimes it works and sometimes it doesn't.

Btw I think part of HackNet is hacking the game itself, metagaming. It looks like some encoded files don't have proper headers (e.g. missing filename component entirely), so I don't think they'd ever decode in game, but so far they can be decoded by hand and it tends to be flavor text.

[Jerry Cheng]

I guess this is totally random? for me GetPassCodeFromString("dleatrou") yields 23048.

[Randolph Cherrypepper]

I'm surprised anyone found this thread after this long. After a major patch, one of the codes changed. Prior to that patch, there were different codes for Linux and Windows (making the save files incompatible which was a pain due to steam cloud). It's possible the code has been changed with future patches, the different platforms still have different codes, or both.

[BMO-TP]

Just started the game recently, hope I'm not too late to jump in this discussion :) It's worth noting the /1822 step means passcodes 0-1821, 1822-3643, and so on are all equal. In all, there are only 35 unique passcode ranges. This explains why your hex passwords were working for some but not others. I had a crazy theory that passcodes were based on length, because the T2 dec file could be decrypted with "t2" and "12", and dleatrou files could be decrypted with either "dleatrou" or "12345678". Sadly, disproven later on :P

[Randolph Cherrypepper]

I haven't loaded the game in awhile. I can't find the source code with a quick and dirty internet search, so it's hard for me to judge. With that in mind:

It sounds like you're saying there are only 35 passcodes in each bin, e.g. 0-1821 has 35 valid codes. I would think modulus 1822 (% 1822) would imply the result you're talking about. I'm not sure why division would limit it that way.

[BMO-TP]

Nope, there are just 35 unique passcodes in the range of 0-65535!

To give a more real example:

given encoded character 171939 and passcode 10875 you get 'F'
for the same character and passcode 10000 you still get 'F'
and again with passcode 11000, still 'F'
You keep getting F all the way down to passcode 9811 and all the way up to passcode 11632

In effect, anything encoded by a passcode between 9811 and 11632 shares passwords. Looking at it from the other side, any password that hashes into a passcode between 9811 and 11632 can unlock this file.

[Randolph Cherrypepper]

I think I get what you're saying. Yeah that sounds a lot like modulus arithmetic.

[Keyser]

It's pretty crazy. For the file with the six-letter password DANGER only the third letter matters at all. You can decrypt it with daNger or even xxNxxx. For the eight-letter passwords dleatrou and beepbeep in fact only the first, third and seventh letter seem to matter.

When giving the hash as a password like you described in the first post, only the first and third position seem to matter, so 0xa7ff is the same as 0xa800 (btw, I think you calculated ushort.maxvalue/2 as 32768, when it should be 32767 I think) which is the same as 0_a___. The CSEC_encode_1.dec unlocks with 0_f___ or any permutation thereof. I'm not sure why, since it should be 0xec2a.... So if the algorithm takes 2 positions and one of them can be 0-F but we know that there are only 35 distinct bins, the other must be a binary switch. As a very interesting aside, it turns out you can decrypt files that don't actually require a password with the password F_0___ or any permutation thereof!

EDIT: For CSEC_encode_1.dec 0-9 in the first position works, A-F don't. For files without password protection actually 0-9 in the first position don't work, but A-F do, so maybe the binary switch is just that: either integer or char...

The GetPassCodeFromString() behaves weirdly, so I wonder if the devs will release the source as some point as an Easter Egg :) would be interesting...

[Tzwcard]

I checked the code and GetPassCodeFromString() should behaves as below:

private static ushort GetPassCodeFromString(string code)
{
return (ushort)code.GetHashCode();
}
I don't know how the game keep the hash always the same but as I know string.GetHashCode() is not a stable solution for generating a unique hash value.

And yeah you can just decode the passcode from encoded "ENCODED" string (or only 'E') and use that to decode the whole chunk of data.

[Smiertzlen]

I have my doubt about that. If it were the GetHashCode(), Why are only certain parts of the password actually doing something?
I checked the numerical equivalent variants for two Passwords:


beepbeep: F_e___e_ , 0_0___4_ , 9_9___3_ and dleatrou: F_e___o_ , 0_2___7_ , 0_6___3_ , 0_9___5_ and 0_9___8_

Especially the last two of the second and the last of the first one are of interest. If it it true, that actually modular arithmetic is used. this would be a nice point to start some further analysis.
I haven't checked the letter variant yet, but I think I will see what I can do.


At this point, it seems that the first letter determines between two different algorithms, which can result in the same number. That is because it just differentiates between number or letter. Also even if no password is used, the ushort passcode is not 0 but in fact 5886. I checked the DECE_TestBould_pdb.dec. The actual calculated number is 158485, but in the file, 'E' is encoded to 164371. So mybe there is something there. Also something which would stand against the GetHashCode() function.

[Column01]

Sorry to revive this dead conversation but I recently undertook the task of reverse engineering the algorithm and writing a script to crack even password protected files. It is really easy to do it requiring no user input other than the encrypted file. You can also encode files (no password protection available at the time of posting), I've used it to drop a calling card on a few computers.
Here[github.com] is the link to my python script!

I also found the source code for the game, and the passcode is generated using the GetHashCode() function as said above (tested using a C# program to generate a password given the password string, and I was able to decrypt all of the files I saw in game that were password protected using the number from that function converted to hexidecimal). It is done this way due to the calculation that the algorithm uses to encrypt the files in the first place (if the output from the Hash Code was different every time, you could never decrypt the file as the password offset would be wrong and spit out garbage.)