RTFM (50 points)
As is the case with all CCTF editions, there’s a quasi-challenge that points people in the direction of the manual, and which is supposed to give an initial feel for how the search for a so-called flag goes. The accepted solution was one of the example flags shown in the manual.
Author: SI
unk (80 points)
A real, entry-level challenge. A file (named “unk”) was presented. It appears to be a damaged Microsoft Word document. A Word document is actually a Zip archive containing things like XML and thumbnail image files. Different Zip implementations work differently on damaged archives; e.g. GNU Zip was able extract the damaged Zip archive to a sufficient extent. The flag was in the thumbnail image. — Sometimes thumbnails are not in sync with the working text of the document, and may contain sensitive data: snapshots of rendered text that was deleted.
Author: SI
CryptoFriend (80 points)
Another entry-level challenge. A file was presented under the name “a_friend.zip”. This was also an invalid Zip archive.
tl;dr: the file turned out to be a concatenation of a Zip archive and a PNG image, where the latter contained the flag. But on to the goose chase leading to this discovery:
E.g. FreeBSD’s Zip implementation extracted a single “a friend.docx” file. This file was a valid Word document which read “i hid my location, come help me”. OK, let’s do this.
No, the thumbnail didn’t contain a flag. According to metadata in the document, the document was prepared by Kevin Chung on 2017-09-11. Let’s find this guy. Searching the internet for his contact information, cryptocurrency addresses, etc, but most importantly, flags, it came to light that he’s behind CTFd, the web application powering the CCTF contest’s portal — the plot thickened. He also runs a blog. One of his blog posts, dated closest to 2017-09-11, really contains a string of the form “FLAG{…}”. Tough luck: wrong answer. In fact, Kevin Chung appeared the same way in the “unk” challenge. So this was a witch hunt.
One other thing was eye-poking: potentially subliminal data in the Word document’s XML attributes, e.g. “paraId=”3B2827CE”” — is there real content embedded in these IDs, or is this totally random crap?
The “a_friend.zip” file was actually ~19MiB in size, while the extracted “a friend.docx” was only ~24KiB, so it makes more sense that the flag was to be hidden outside the latter. Inspecting the file (using tools like: strings, hd, etc), one could stumble upon the following:
• There was EXIF data containing latitude–longitude coordinates. However, those pointed to Andromeda, so this lead had to be scrapped as well.
• There was an EXIF user comment with a code of some sort: “FM0 FC000000000:zzzzzz1 f144 078043881a29e1e816c14c0 bac 87152…”. Well, whatever.
Upon further inspection, it was then apparent that the EXIF structure was actually part of a PNG image that appeared without compression in the “a_friend.zip” file.
Author: SI
Vault (100 points)
Given some smart contract — the source code and a deployed instance, displayed by the etherscan.io service —, the task was to determine the correct call to the contract that would exfiltrate the 0.1337 ETH (of the Ropsten test network kind) from the contract.
In the constructor, the `pin` variable was initialized with the value of `block.timestamp % 10000`, and then never changed. And there was the fund retrieval function taking a single number argument, which would compare the number against the `pin` variable. The latter just signifies that we were looking for the value of `block.timestamp` at the time of construction.
There were multiple techniques to tackle this problem:
• A hacky approach was to try to call the contract with every possible value from 0 to 9999, and see which worked — after all, this was on Ropsten, a gas giant.
• There are many tools to interact with deployed contracts, including to read values of global variables. The `pin` variable was private, so if a particular tool didn’t permit reading the value directly, it was conceivable to trick the tool into thinking that the contract’s source code / ABI was slightly different: where the `pin` variable wasn’t private.
• The smart solution was to note the date and time when the contract was created (corresponding to when the block, that included the creating transaction, was mined), and convert it to seconds-since-the-Epoch.
Author: SI
Leave A Comment