Challenge - Twelve steps of christmas

On the ninth day of Christmas my true love sent to me...

nineties style xls,
eighties style compression,
seventies style crypto,
and the rest has been said previously.

5862be5b-7fa7-4ef4-b792-fa63b1e385b7.xls

Hints: Wait, Bread is on the Nice list? Better check that comment again..

Solution

The given Excel file was write-protected, but that wasn't really a problem as no writes were necessary. The only inconvenience was “Breads” cell that held critical data couldn't be viewed to the full extent because of the protection. We approched from two sides, Bruteforcing the password with a VBA macro found on the Internet, and extracting the file and finding the cell contents in a hex editor.

The contents where some bad puns and a LZW compressed bitmap header as ASCII. The contents of the image were nowhere to be found.

Not a loaf of bread which is mildly disappointing 

1f 9d 8c 42 9a 38 41 24 01 80 41 83 8a 0e f2 39 78 42 80 c1 86 06 03 00 00 01 60 c0 41 62 87 0a 1e dc c8 71 23 

Why was the loaf of bread upset? His plan were always going a rye 
How does bread win over friends? You can crust me
Why does bread hate hot weather? It just feels too toasty

In the extracted excel document we also found some hexadecimal strings in the Ole10Native blob. From the file magic 1F 9D, yet another LZW archive. So we put all those stringss together, removed the newlines and created a file from it. Indeed it was an archive. Once extracted we got a file with binary content and the string “Salted__” prepended. Apparently encrypted by OpenSSL.

Next we tried to get into this file, but soon realised that the BMP header was still missing its data. Maybe it would give us the password to the encrypted file? After messing around with the header and random binary chunks in the file, we realised that the headers bfSize field indicated 1214542 bytes of total file size. We saw a very similar number earlier! It was around the size of the encrypted file, 1214560 bytes. Coincidence? Without much hope, the bitmap header was prepended and our “frankenfile” opened it in an image viewer. Surprisingly, it was (kind of) valid AND meaningful. How could an encrypted file also have meaningful content when viewed as image?

It turns out, the file was EBC encrypted, which much like a substitution cipher doesn’t really alter entropy. So when inspected it carries an imprint of the original data. In comparison, a ROT13’ed text also keeps the texts properties, like its distribution of characters. Ultimately, its fail.

Reading the QR code was still difficult. No reader would accept it as is, neither with quick and dirty repairs like color replacement, bumping the contrast, edge detection + fill. Finally, a manually reconstructed QR worked and we got the flag:

HV20{U>watchout,U>!X,U>!ECB,Im_telln_U_Y.HV2020_is_comin_2_town}

Next Post Previous Post