Doing it the hard way...

The other week I took a moment to play Gh0st Network CTF at RVASec 2017. I decided to write about solving that problem the hard way. The problem was as follows:

da Vinci Crypto, LLC 400
There is a hi-tech cryptex at the organizer's table that might have some valuable information, but we do not know the pin to open it. The manufacturer provided us with a page that simulates (https://metactf.com/metactf2017/cryptex.html) the lock by generating random pins, and it checks whether or not the code is correct. Their simulator has more rings than ours, but they said that the pin to the cryptex we have is the first 5 digits of the cryptex on the webpage. Can you reverse engineer the page and unlock the cryptex? (To make sure that everyone gets a chance, you may not spend more than a minute with the lock if there are people waiting for it.)


The solution:

The long story short, looking at the code there's a function validate_lock() that takes a number and checks for quite a few constraints...

Having a limited time and only a laptop with me (no fancy GPUs), I wrote a  for-loop in JS to solve the combination for the lock. I figured that I should start from the end of the key space, and reducing the search space as much as possible, trying to skip unnecessary computations. Here's a glorified for-loop in JavaScript.

    if (n%109==59){
        if (n%83==70){
            if (n%71==45){
                if (n%59==15) {
                    if (n%41==14) {
                        if (n%13==6) {
                            if (n%11==1) {
                                if (n%7==4) {
                                    document.write("hit:" +n + "<br>\n");

After running it for a bit, it came back with the solution...


P.S. The solution for the real cryptex is right on the picture... look at the very bottom... 79145...


Fun with Symantec Endpoint Protection Local Quarantine Files

I've spent some time lately tearing apart the SEP Local Quarantine files, luckily they seem to be much less complicated than the SEP Central Quarantine files, but they seem to use the same basics in terms of structures used to store data and indicate field sizes. The big problem is that once you lift VBN files from the original device, Symantec's QExtract tool is basically useless, and there is no way SEP will extract it on another machine.

Many forensic blogs suggest doing XOR to obtain the binary, but in most cases the binaries are also split into 4k chunks with data structures starting with 0x09 followed by 4 bytes indicating the size of the chunk. I think Hexacorn blog(1) was the frst to point out the existence of such "chunk separators", but Shane King(2) was the one that figured out that the 4 bytes there stand for the size of the chunk.  Having a file peppered with such chunks might ruin your day if you are going to do anything serious with the extracted file. Since, I didn't want to limit the extraction to just PE binaries, I had to try to figure out some of these structures across a set of samples that I had available.

The other day, I was almost done with the extraction piece, when one of the more anomalous .VBN files turned out to contain two payloads. Luckily, it turned out to be the exactly the same binary as the first one, well at least the size and MD5 did match.

So the code is available on github:

And you can either use it in CRITs or just import it into your little script, and save the payload the way you like.

(1) http://www.hexacorn.com/blog/2012/09/21/dexray-decrypting-vbn-files-part-2/
(2) http://dofir.net/post/81425257003/a-study-of-symantecs-vbn-file-format


Lately, I was able to get my hands on a used/refurbished WZR-1750DHP. Amazon marketplace had it in virtually new condition for under $90. 512MB of memory and dual core SoC made me think that it could be worth it. 

The original Buffalo firmware, while nice, was a major PITA straight from the 90s; almost any config change required a reboot. Turns out that Buffalo has WZR-1750DHPD, which essentially is the same thing with a nicely done DD-WRT firmware. It turns out that it's relatively easy to flash the Buffalo-supported DD-WRT firmware onto WZR-1750DHP. 

After loading Buffalo-supported version, the router turns into a far superior device than almost anything I had before. The only con is lack of the external antennas for extended range.


Some thoughts on coding in Python

I've been working on improving my Central Quarantine extractor script lately. One of the snags I hit was a stupid bug in zipfile module in Python 2.x-3.4.

It has to do with archive names not matching between two different places. When such mismatch occurs zipfile simply raises an exception and refuses to extract the files.

This mismatch thing is actually a feature in Zip format that allows the files to be effortlessly renamed without any need to re-pack the various files stored inside the ZIP file.

Since I was making sure that my code runs fine on both Python 2.7.6 and 3.4 the only point of contention was the bastardized zipfile module. The one from 2.7.6 would error out with Python 3.4 and the one from 3.4 would do the same whe running on 2.7.6...  I've added a conditional importing, but I've not tested it with other versions of Python...

After jumping through the hoops to ensure that my code runs properly on Python 3.4, I feel much better now that it also works perfectly well with 2.7.6.


It seems that I'm breaking out of a coding coma lately. I've started fixing stuff in Kludge, and it is fun. The downside is that it is really time consuming, as nothing comes easy when one needs to dig into the details.


CTF write-ups

I hope you'll enjoy the write-ups as much as I've enjoyed solving the challenges.

Crypto 1
Points: 25
Instructions: I read about this once... -- Submit in all lowercase no spaces
Category: Crypto/Stego
File: f3d0c9e33f9479a5109445d6c00f12559ea21e75


$ file ./f3d0c9e33f9479a5109445d6c00f12559ea21e75.txt
./f3d0c9e33f9479a5109445d6c00f12559ea21e75.txt: gzip compressed data, from Unix, last modified: Fri Mar 23 13:06:29 2012

$ cat ./f3d0c9e33f9479a5109445d6c00f12559ea21e75.txt | tar -tzvf -
-rw-r--r-- jdm/jdm          76 2012-03-23 13:04 86d13ae80f15bda5818552afb669f86bb02af9a0

$ cat ./f3d0c9e33f9479a5109445d6c00f12559ea21e75.txt | tar -zxvf -

$ cat 86d13ae80f15bda5818552afb669f86bb02af9a0

Running it through Caesar cipher with offset of 7 it turns it into the following question:

Quick googling session reveals the answer.

Flag: pontifex

Crypto 2
Points: 75
Instructions: We got the password hashes from a system but don't know what to do with them. -- Crack the passwords and concatenate them alphabetically for the key. Submit in all uppercase, no spaces.
Category: Crypto/Stego
File: 2d2cda7a3f0b8f0b292c646f94bf9836073e94db


$ file ./2d2cda7a3f0b8f0b292c646f94bf9836073e94db.txt
./2d2cda7a3f0b8f0b292c646f94bf9836073e94db.txt: gzip compressed data, from Unix, last modified: Sat May  5 17:07:27 2012

$ cat 2d2cda7a3f0b8f0b292c646f94bf9836073e94db.txt | tar -zxvf -

$ file 10896c1cb3d61b1c2d65690dc7c0d05e
10896c1cb3d61b1c2d65690dc7c0d05e: ASCII text

$ cat 10896c1cb3d61b1c2d65690dc7c0d05e
Derp McDerp:1005:E94FB3E8775E0FE98B0EA5A7DF135B03:8EECDD4B8B43677BB162A15DBCB2C231:::

Using invaluable http://www.objectif-securite.ch/en/products.php we can crack the lm hashes in seconds:

Hash: E94FB3E8775E0FE98B0EA5A7DF135B03
Password: DERPDERP
Hash: AA1AB12D9BE8C0D126F8092A33DAAF05
Hash: 6F87CD328120CC55FF17365FAF1FFE89
Password: ABCD1234
Hash: 59FA69C37A475354FF7447F7A53FE0E0
Password: ZERGSTORM45


Crypto 3
Points: 175
Instructions: Crack the cipher, get the key ------------ The key to the cipher is the answer. Submit the key in all lower case, no spaces
Category: Crypto/Stego
File: 17ca6426ac08cef3641a5695667c921af89edb82

$ file ./17ca6426ac08cef3641a5695667c921af89edb82./17ca6426ac08cef3641a5695667c921af89edb82: BinHex binary text, version 4.0

$ cat 17ca6426ac08cef3641a5695667c921af89edb82 | hexbin -l
This file is in "hqx" format.
name="809f9232ac55c50317c93753b6099a1d", type=    , author=    , 1 excess bytes ignored
data=2442, rsrc=0

$ hexbin -s 17ca6426ac08cef3641a5695667c921af89edb82 -u

$ cat 809f9232ac55c50317c93753b6099a1d.text | xxd -r -p

Plugging that into http://smurfoncrack.com/pygenere/pygenere.php and expanding the length of codewords to try to 20 yelds just slightly misspelled answer"INDECIPHERLBLECIPHER"

With the proper key it decodes to:

Flag: indecipherablecipher

Crypto 4
Points: 300
Instructions: Decrypt for the key ---------------------------- answer format is strupr(full unencrypted string)
Category: Crypto/Stego
File: 13930c973e7169c84c9c88211cbc5e54f32153cb

A TIFF file presents the following ciphertext: RUCIQPQMMRNZEVONDT
running foremost against it reveals an jpg image with the following enigma key:

One can decode using the enigma machinesimulator: http://startpad.googlecode.com/hg/labs/js/enigma/enigma-sim.html , then
after plugging the ciphertext into the enigma machine with the following settings:

Rotors: I-IV-III
Rotor Start: AAA
Rings: NRT
Plugboard: AH CK

the key is revealed.


Forensics 1
Points: 50
Instructions: Eye Heart FS! -- Submit they key as instructed
Category: Forensics
File: dc7f2a9830f5e8dad51c6f6dbc6edc8b3a7bc22f

hints.txt is inside the provided tar.gz file, after untaring/gunzipping it lists the following clue:

Answer these three questions and concatenate the answers for the key.
How large (in bytes) would a DOS3.3 "nibbled" image be?
What is the minimum journal size (in blocks) for a reiserfs disk?
What partition type (in hex) would a FAT16B partition have?

Quick google search for these items reveals that the mac specific DOS3.3 image was 232960 in length, ReiserFS' minimum journal size is 513 blocks. Finally, the hex code for Big FAT16 is 0x06

Flag: 2329605130x06

Forensics 2
Points: 99
Instructions: Ugh -- this is exactly why interns shouldn't do forensics. What a newb. -- Submit the key as found.
Category: Forensics
File: 94996036b13962bf8baaa324d998ed9476f620e3

$ file 94996036b13962bf8baaa324d998ed9476f620e3 
94996036b13962bf8baaa324d998ed9476f620e3: bzip2 compressed data, block size = 900k

$ cat 94996036b13962bf8baaa324d998ed9476f620e3 | tar xjvf -

$ file dd_rtfm 
dd_rtfm: data

When revieved through the "hexdump -C" or "strings" you can clearly see that the strings don't read quite right, it seems that the endianness is flipped.

to reverse that and get the key in a single liner we can do:

$ dd if=dd_rtfm conv=swab | strings | grep n00b

Flag: Silly n00b -- arguments are for l337!

Forensics 3
Points: 200
Instructions: You know that guy? The one who always hides his screen when you walk by? You're never quite sure what he's up to? Yeah -- you know him. Well we need to know what he's up to. We're moving his desk to the basement, and you remember what happened last time... We managed to get a memory dump and a file we think he was working with from his system, but we don't know what to do with it. -- Submit the key in ALL CAPS
Category: Forensics
File: 5748b64df3c691d1766e793e8dcf23b05383899d

Packet 1
Points: 25
Instructions: Who would cross the Bridge of Death must answer me these questions three, ere the other side he see. What should the Checksum always be for IPXWAN___ How many reserved bits in the TCP header, and what must it always be___ The code for a Point to Point Protocol Discard Request --------------------- Find the answer to these three questions, concat them for the first half of the answer, append with the color it creates (answers123Color)
Category: Packet
File: (none)
Flag: FF6011Orange

Packet 2
Points: 150
Instructions: What an odd way to send a secret message... ------------------------ answer format is md5(key including all spaces)
Category: Packet
File: 1c1d8c9c1f7cb39c6eb16efea9c0542447c2934d

Binhex decodes a pcap file, following the udp session reveals a sound file that transcribes into:
4d 61 63 68 30 4d 34 6e 20 73 41 89 35 20 3030 6f 48 20 59 33 61 68
which in ascii is: "Mach0M4n sAy5 00oH Y3ah"
The flag is md5 of that string (sans quotes).

Flag: c37947e01c8b338081e76a62ca5da88b

Potpourri 1
Points: 75
Instructions: LRN2 READ! -- Submit in all uppercase no spaces.
Category: Potpourri
File: b002d66a78882969f9d8eee555582509f01df944

Binhex decodes a zip file with an image of message written in Braile, which decodes into a question along the lines of  (the decode might be not exact):
"On November 2 1988 what worm was unleashed?"


Potpourri 2
Points: 125
Instructions: The PDF spec is so error tolerant, even the monkey from the infinite monkey theorem couldn't reproduce it! -- Submit the key as found
Category: Potpourri
File: cc7931560f8fc6d8df26f058afc6b8b03e31ae60

After decompressing a pdf with hamlet is revealed. One could search for the original pdf and diff it. The result of diff would indicate an object 368 being added. I've used my custom version of pdf-parser to dump the media files for me. Object 368 is an jpg image containing the key.

Flag: Z0MG you found 4n0th3r k3y!1!one1

Potpourri 3

Plugging the following into the sudoku solver


into http://www.sudokuwiki.org/sudoku.htm and clicking on "Solution Count" button gives the flag.

Flag: 471852693358769214296341875813596742647213958925478361162984537789135426534627189

Reversing 1
Points: 25
Instructions: Do you believe in magic? What tasty hex number was originally used to mark newly allocated (freed) memory prior to initialization? -- Submit the key as hex, all uppercase (so 0x[UPPERCASE])
Category: Reversing
File: (none)


Reversing 3
Points: 175
Instructions: Blast from the not-so-distant past... in more ways than one. -- Submit the key as found
Category: Reversing
File: ad32c019ae35816ce196db2042d572e41875cd44

Another pdf challenge, the pdf is wrapped in a C64 disk image among other things. The pdf contains a javascript, which won't run unless it detects AdobeReader version 5, and then it pops up a question for the code. It turns out that there is a common multiplier to the algorithm used, once one extracts the code and runs it in a debugger or modifies the pdf. It's pretty easy to derive the multiplier by plugging 1, then 10. The result has to be rounded up with no decimal places. 

Flag: 996638400


Some thoughts about NAS devices

Today I'm going to share some thoughts about various NAS devices I've considered for my home environment.

Number one objective is to have a power efficient device, since these things will most of the time sit there and contribute to your monthly electricity bill.

Couple of years ago I've decided to try Thecus N2100, it seemed nice and hackable and it had two GigE ports, but it had a really IO subsystem making it really slow. I was hoping that the bugs could be worked out, but it didn't happen. So, I've popped two WD green drives (1TB), replaced the internal fan with a quieter one, upgraded the memory to 512MB. The transfers are still really slow and the included version of BusyBox is pretty outdated and buggy. If you have filenames with some bad characters in them, or lots of files in the folders some services such as the Mediabolic media server would just crash. It's real legacy hardware now, the CPU on the unit is plagued with some serious bugs and the original kernel seems to be much better than most other available. I've tried different things with it, but I wanted to keep it fairly stock, so adding the extra modules was the way to go. But eventually I got tired of it, and I've decided to retire it, after running it for a few months 24/7. I needed a device with an ftp server, and enough storage to be able to serve some content through DLNA and DAAP (iTunes-like).

One of the days I was looking for Raspberry Pi (still waiting for my order to arrive) specs and I've noticed a pink Pogoplug on sale for $25. Once I found out that it has a SATA port on the inside, I thought that I could use this thing to replace functionality of my other NAS. In a way this would be a downgrade, from two SATA ports to one, but on the other hand 4 USB ports and  less power hungry device with support for optware seems like a perfect match. Not to mention the initial investment part. So, I've chopped off a little sliver of the back cover to run the 90-degrees-angled SATA to e-sata cable, and it's almost ready. All I need now is a decent e-SATA drive dock or an enclosure and it's ready.

One of the big selling points for me was the 5GB of free cloud storage, that shows up up in the management screen as another drive. I'm trying to keep my ISP costs down, so my link is seriously limited in upstream bandwidth, so I was able to use that to host my pictures for my family members.

Another great feature is the built-in DLNA media server. It's been pretty stable, one of short comings was that it wouldn't index my small 80GB drive for the movies, but then luckily I was able to find the 5GB of the ShmooCon 2012 videos by browsing through folders.

It goes without saying that the thing allows one to turn on the built in ssh server, and mount optware from the USB drive

My final solution to the problem became much simpler than ones listed the above, and it entails a relatively beefy broadband router with an USB port, a  few tiny 32GB flash drives, an USB hub, and OpenWRT. It is still having some little issues that I'll have to take time to iron out, but at least it serves a multitude of tasks. So, I have there an VPN server, an ftp server, a samba share, DLNA media server, DAAP (iTunes compatible) server, and I couldn't be happier with it. It allows me to use Wake-on-LAN to turn on my beefier media server based on HP N40L microserver and OpenMediaVault when needed, where I have much more space for my git repositories, family albums, as well as vacation pictures and videos.