Jump to content
Double Fine Action Forums


DFA Backers
  • Content Count

  • Joined

  • Last visited

About DRayX

  • Rank
    Action Newbie
  1. Dude, those are the right keys, just use the client key and iv to decrypt the request and the server ones for the response, works like a champ. Looks like dumped packets for an http request and response, haven't figured out for what yet though. Looks like it is requesting Vote-from-cbd.txt from hacksnslashthegame.com, but that doesn't seem to exist. If anyone else wants to decrypt these, simply use: openssl aes-256-cbc -d -K f6f1534ed93084efe97a1428ec1af9f61fd8e6158aa8f6136ddfa8e6f27ea8ac -iv 21329ea59191682cc3562c52315550c9 -in or openssl aes-256-cbc -d -K c53bacff1cd31e3e70ed83d9506c9f9e6a9f35689499c25fa1f8bd896770e0ba -iv 600470c838b93c56f1d6c62b66ef1caa -in BTW, it is an http request for http://hacknslashthegame.com/download/a-note-from-cbd.txt Actually, it is for hacksnslashthegame.com/download/a-note-from-cbd.txt, but that doesn't exist
  2. Interestingly, my incantation under wine was the same. I suspect that whatever it is looking at to decide the incantation is always the same under wine. Olly has a few problems under wine, but it does work.
  3. Can you edit this so that you don't have a giant line in a code block? It is really weirding out the page. Also, I wrote a little python script using tlslite (pure python tls implementation) and got the following using the TLS 1.0 PRF (the only one it has): cmac: 398e7548bd39cde1f4ebd862a37f3688230d9536 smac: cf9f5dc2799c50cf3df019adaa1c303ef754705e ckey: f6f1534ed93084efe97a1428ec1af9f61fd8e6158aa8f6136ddfa8e6f27ea8ac skey: c53bacff1cd31e3e70ed83d9506c9f9e6a9f35689499c25fa1f8bd896770e0ba civ: 21329ea59191682cc3562c52315550c9 siv: 600470c838b93c56f1d6c62b66ef1caa Which is identical to the ones you had at least confirming that the library works. If it is using TLS 1.0, these should be the correct keys, if not, I either need to actually build that snippet of c code (I don't feel like messing with makefiles right now), or write a pure python implementation of P_SHA256 (also, ugh).
  4. You are probably right, I just connected with my browser, and it used TLS v1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA, and I know chrome supports TLS 1.2, so it looks like the server is set to 1.0 (which is strange since Apache 2.2 supports TLS 1.2).
  5. Ok, looking through the various specs, I agree that we can't assume the TLS version (it really should have been specified in the trace thing). I'm still guessing it is 1.2, but I could be wrong.
  6. I don't think there is anything we can do with the verify_data since it is based on a hash of all communications so far, and we don't have most of the information (source).
  7. I updated my post to actually do the key expansion as well. I'm 100% sure this is sha256 for the PRF as TLS_RSA_WITH_AES_256_CBC_SHA was defined in rfc5246 and there is a note that all cipher suites defined in that rfc use P_SHA256 (plus I looked through the source code for the jdk, wpa_supplicant, and polarssl, and they all use P_SHA256). BTW, what application are you using to getnerate the keys from the random + premaster? I couldn't find anything that does it out of the box.
  8. No, the premaster is supposed to be 48 bytes. You use those three things plus a PRF to generate a master secret which is split into the mac, key, and iv. Ok, I read through JDK 7s implementation of TLS, and found that the PRF is definitely P_SHA256. I found code for this in wpa_suppicant (doxygen here). The following blob of c code should give us the master secret: char random[64]; char master[48]; char keyblock[256]; memcpy(random, client_random, 32); memcpy(random + 32, server_random, 32); tls_prf_sha256(premaster, 48, "master secret", random, 64, master, 48); memcpy(random, server_random, 32); memcpy(random + 32, client_random, 32); tls_prf_sha256(master, 48, "key expansion", random, 64, keyblock, 256); char *cmac = keyblock; char *smac = keyblock + 20; char *ckey = keyblock + 40; char *ckey = keyblock + 72; char *civ = keyblock + 104; char *siv = keyblock + 120; Edit added the code to actually create the key block.
  9. That doesn't really mean anything since OpenSSL is likely not starting the handshake with the same parameters (I think it uses TLS 1.0 instead of 1.2 by default). If you look through you dump it is almost certainly using a different cipher suite (especially since I thought TLS_RSA_WITH_AES_256_CBC_SHA was defined in 1.2). On another note, I'm still reading through the RFC, but there is a note at the top that all the cipher suites defined in TLS 1.2 use P_SHA256 as the PRF, but I can't find a definition of that anywhere.
  10. Ya, there is definitely enough information there to get the master secret, and then decrypt the traffic. The only problem is that I can’t find what the PRF for TLS_RSA_WITH_AES_256_CBC_SHA is. Does anybody happen to know it or able to find it somewhere? Edit: The TLS_RSA_WITH_AES_256_CBC_SHA basically tells us that we are using TLS (rfc5246), RSA for the key exchange (not important since the premaster is unencrypted and we don't have the server private key anyway), aes-256-cbc for the actual encryption and sha for hashing. The only part I can't remember is how you take the client_random, server_random, and premaster to create the master secret.
  11. Unpacking the exe reveals a lot more information and makes it possible to actually debug it for real. I'm still trying to figure out a way that I can have a single bash script that would run the app and input the correct code for your system automatically. This is what I've got so far: #!/bin/sh wget -q http://www.hacknslashthegame.com/download/HacknSlashAnnounce.zip.jpg unzip -qq HacknSlashAnnounce.zip.jpg Outdoors.mp4 2> /dev/null MP4Box -quiet -dump-item 1 Outdoors.mp4 openssl aes-256-cbc -d -pass 'pass:THE FIVE BOXING WIZARDS JUMP QUICKLY' -in crackme.enc -out crackme.exe upx -qqq -d crackme.exe echo ${THE_ANSWER} | env WINEDEBUG=-all wine crackme.exe You can also easily get the entire incantation by running strings -n 1500 crackme.exe after the exe has been unpacked. The packages you will need to run all of this are gpac (for MP4Box), openssl (for openssl), upx-ucl (for upx), wine (for wine), and binutils (for strings).
  12. I felt like finding the incantation on the stack was too easy, so I unpacked the binary and found the entire incantation. It looks like everyones string is some substring of this. Still not sure how it determines what substring though. There are also a bunch of misspellings as well .
  13. Oh man, I totally didn't even think to look at the forum. I finally finished the puzzle, it was really fun, reminded me of the good old days when my hat was a darker shade of grey. I'll post my process here just in case anybody is curious: - Went to http://www.hacknslashthegame.com/ and download the .zip.jpg from http://www.hacknslashthegame.com/download/HacknSlashAnnounce.zip.jpg - Opened it with 7-zip and extracted the 3 files. - Looked at the text file and noticed that lines seemed to repeat every 34 characters, except some words had weird offsets so I wrote a simpl (and super hacky) python scrip to grab out the interesting parts: with open('WorldTablet.txt', 'rb') as f: text = f.read().decode('cp1252') s = '' for a, b in [(text[i:i+30], text[i+34:i+64]) for i in range(0, len(text), 68)]: if a != b: for i in range(30): if a[i] != b[i]: c = a if a[i] != ' ' else b s += (' ' if len(s) != 0 else '') + c[i:c.find(' ', i)] break print(s) - Got the message "the embedded application is enciphered with the incantation presented by the first observed glyphs" - Figured I had to decode the glyphs which I assumed were a simple substitution cypher. I guessed that the original jpeg was a rosetta stone panagram. Based on frequency, the dots were clearly spaces, so it clearly wasn't "quick brown fox". Instead of actually figuring it out, I just Googled for English panagrams and "The five boxing wizards jump quickly" was the only one that fit. - I then used ffmpeg to dump every frame from the video file using: ffmpeg -i Outside.mp4 Outside%d.png and went through all 400 some odd frames and found the 84 that actually had text in them. - Proceeded to decode the video message to get "most of the time we only see the things that we expect to often secrets are in plain sight but remain invisible to us size up the medium you are observing and you may find it supports modes of expression you do not expect images can contain words words can produce images something that appears to be a recording of life may actually be a container filled with the sequences of images and channels of audio that you expect but that container may hold" (I could actually read this stuff without the reference by the end). - The first part of this I guessed had something to do with text file. I turned on line wrap mode in my editor (as a programmer, this is a feature I NEVER use linewrap), and realized that if I resized it to 64 characters (nice number there), you could actually look at the image as a cross-eyed stereogram and the words would actually stand out (cool idea, but the python script gave less of a headache). - The second part, was clearly talking about the mp4 container used for the video. It made it fairly apparent that there was something else multiplexed into the file. I ran: MP4Box -info Outdoors.mp4 and got the following (and a bunch more that I cut out for brevity): Root Meta type: "mp21" - 1 resource item(s) Item #1 - ID 1 - Name: crackme.enc - MimeType: application/octet-stream - It was clear that there was a file called crackme.enc in the mp4 as a resource file. I again used MP4Box to extract the resource with: MP4Box -dump-item 1 Outdoors.mp4 - I guessed that the .enc in crackme.enc was either for encoded or encrypted, so I ran hexdump -C crackme.enc | less to look at the contents of the file. I immediately noticed that it started with "Salted__" which is the magic number header for AES encrypted files produced with OpenSSL. - The message from the text file seemed to indicate that "enciphered" file was decoded using the "first observed runes" the first runes I saw (or anybody saw for that matter) were the ones in the rosetta stone image, so I guessed that the pass phrase for the encrypted data was either "the five boxing wizards jump quickly" or "THE FIVE BOXING WIZARDS JUMP QUICKLY", I just needed to figure out what AES mode to use. Looking at the original post, I saw "TLS_RSA_WITH_AES_256_CBC_SHA" so I guessed aes-256-cbc. - Ran openssl aes-256-cbc -d -in crackme.enc -out crackme.bin and tried both passwords, and low and behold, the capital one worked. - Took a look at crackme.bin with: hexdump -C crackme.bin | less and saw that it started with 4d 5a (MZ) the magic number for an exe. At this point I switched to Windows (why was your little puzzle not an elf? srsly) - Copied crackme.bin over to my Windows box and ran it. Obviously needed some sort of password, but had no idea what. Opened it up with ollydbg and searched for all referenced string, but I couldn't find anything with "INCANTATION" in it, so I just ran the program and got a warning that the code section was encrypted and thought "oh great, this is gunna suck", but it was actually super easy. I just typed in some text, and let the program finish, and low and behold, right there on the stack was the value "AND TRUTH. AND WITH THE POWERS I HAVE OVER HIDDEN BUT NOT INACCESSIBLE TRUTHS.". I'm assuming that they loaded the string from the binary to compare it, and didn't explicitly 0 the memory when they were done (not sure if this was accidental or intentional). - Ran it again with this as the incantation, and got the code. At this point, I think I have gotten essentially everything figured out. There may be some real way you are supposed to figure out the code for the exe, but I like using debuggers, and find that a totally acceptable approach. I also didn't end up using the song for anything, but looking at it there are a couple of interesting things which may have helped. The genre of the song is aes-256-cbc, a really clear hint to the encryption to use (more so than the string on the website). There is also a comment on the track of "passwords read like incantations when spoken in all capital letters" which would have helped make the leap from the invocation comment to the aes password, and would have made it clear that I needed all caps. There are also a few "encrypted_payload"s on the blog post that may or may not actually mean anything, I might try to decrypt them tomorrow. I was really hoping for a demo when I saw "embedded application", but no such luck. Overall, a very fun little puzzle, although more interesting exe hacking would have made it better; I love spending weekends reading x86 assembly, and it has been so long since I have had reason to, the days of making no-cd cracks for myself so that I didn't have to change discs all the time are long gone thanks to Steam.
  • Create New...