Jump to content
Double Fine Action Forums


  • Content Count

  • Joined

  • Last visited

About Netrix

  • Rank
  1. It can still be accessed here: https://bitbucket.org/tjablin/dfhack/src/default/ His version is mostly good except that it does two rounds of decryption when it should only be one due to a bug in the game that caused tjablin's .lua file to be double-encrypted. When I have a chance, I'll post my version which does one round of decryption and is optimized (at least partially) for speed and works on Windows as well. While I tried bruteforcing and used dictionary attacks with it, its most useful function would be to quickly try various passphrases (and variations of them) to see if they are correct without having to open the game to try it manually.
  2. Since any in-game script would be incredibly slow and useless for brute forcing, I'm using a C program that uses the same decryption process as the game that I've highly optimized. I can try about 6 million passwords per second, but if the password has special characters, has 8 or more characters, or is more than 3 words in length, it is practically impossible to brute force with current technology. Maybe some day in the future when we have quantum computing it will be possible to break the encryption, but it doesn't look like it will be any time soon. I've been busy recently but maybe at some point I'll package what I have so other people can play with it. I've just tried brute forcing and various guesses that other people have made.
  3. You are talking about this line: "THE FIVE BOXING WIZARDS JUMP QUICKLY" It doesn't work as the password.
  4. I was going through all of my old folders to organize my data and I came across the files related to this. For brute forcing, I did only try single words with symbols and numbers. I didn't get around to trying proper sentences from the game's strings. There are quite a bit of strings within the game files though so I don't know how long it will take to try up to even just 3 word sentences. I'll at least make an attempt though I do agree that this is almost certainly not the intended way to solve it.
  5. Well, we have the cipher replicated, and I made the changes necessary to filter out all false positives (as long as the result is a compiled LUA file). tjablin, if you give me the rights on your Bitbucket project, I'll push my changes so that it will work on Windows as well and provide the ability to encipher the same way the game does. My username on Bitbucket is mrnetrix. For anyone who just wants to try the compiled Windows version, you can get it here: http://www.mediafire.com/download/k3an8tsjuvk7l3u/dfcipher.zip I didn't include the encrypted SecretRoom.lua in case that's not allowed since it is technically copyrighted material. Anyone that owns the game can easily copy over the file from "...\SteamApps\common\HacknSlash\Data\Content\Secret\Rooms\SecretRoom.lua" and run the tool on it.
  6. (Double-posting so subscribers will be notified, as there is new information.) I've prepared my version of your code; I just ran out of time. It does seem like your ciphertext got double encoded by accident. There's a global variable that's supposed to prevent that, but there's a bug where the game saves the enciphered version of the book and doesn't save the global variable that prevents it from being enciphered multiple times, so it gets enciphered when already enciphered. I've managed to get the ciphertext for PrincessChambers.lua directly from the game, and it was encoded twice, but after entering the key in the game to decipher the book, the beam wouldn't turn off, meaning I got the progression blocker I mentioned earlier. So I went to a state before initially entering the DRMRoof, entered it again for the 'first' time again, dumped the PrincessChambers.lua ciphertext, and it was indeed encoded only once. It is exactly the same as the result of deciphering your enc.lua with one pass. So I would suggest doing only one pass from now on, though technically there is no guarantee that SecretRoom.lua is only encoded once. However, since it's pretty obvious that we are meant to decipher the book on the pedestal, and that only does one pass of deciphering, it's a very safe assumption. It would probably be a good idea to try using the strings from the game again, using only one pass. Also, if brute forcing watch out for false positives. One example is 'hq8'. The result of deciphering with that key (and many others) passes the validation checks, but the length is usually nowhere near the original size, which is why I said a better check would limit the valid size to between the ciphertext length minus header and that minus the block size. Unfortunately, entering a false positive key to decipher SecretRoom.lua on the pedestal results in the game replacing SecretRoom.lua with garbage data, as it thinks it was successfully deciphered. The "SecretRoom.lua has been modified" message shows as well. Lucky that we can go back in time...
  7. Yeah, I should be able to do that tonight. That's what I was going to try next, but you beat me to it. I considered the key valid if both rounds of deciphering succeeded without any of the existing validity checks failing. Actually, I assumed your ciphertext was correct. When enciphering, I also used two passes so that it takes two passes to decipher. I could dump mine to be sure though. I don't think it would be double encoded unless it's supposed to. Otherwise, the deciphering should fail by putting in the correct key after leaving and entering (unless they try multiple passes just in case), which would be quite a nasty progression blocker. Also, two passes would make sense because quite a few keys result in false positives on the first round according to the "<=" check you mentioned, and it's pretty much guaranteed that the second pass will fail after a false positive first pass. A better check would have been to check if it's also greater than the original size minus the block size, but that's unnecessary with two passes. It's definitely worth verifying. For sure, the padding must be zeroed out. If it isn't, the last block of the resulting ciphertext doesn't match the original ciphertext when reversing the process. I think it's worth reversing the encipher process just to make sure that there isn't any funny business going on, but I don't expect it to provide us with anything we don't have at this point.
  8. Very nice. Your code works great after some modifications (to make it work on Windows). For funsies, I was able to use your code to try some brute force, of course to no avail. I was mostly curious how fast it would run. After setting all available optimization settings, over the night, I was able to try 148,897,650 combinations of letters (upper and lower), numbers, and a few punctuation characters. Sadly, all this indicates is that the password is at least 5 characters in length, and/or contains non-alphanumeric characters that aren't '!', '.', '?', ' '. In addition, I tried some simple dictionary attacks, which I tried each word in a variety of arrangements, such as 'word', 'Word', and 'WORD', so whatever the key is, it's not just a simple word. I was also able to do the reverse and encipher the plain text princess chambers LUA with the "With this incantation..." key, and it resulted in the original ciphertext. At least your code basically proves that we aren't meant to break the encryption itself, as was mentioned earlier. We are simply meant to find the key the normal way, probably through clues somewhere in the game. tl;dr It appears your code is a perfect replication of the decryption method that the game uses, and as a bonus, can be reversed to encipher like the game. However, it's AES-256, so game over, man.
  • Create New...