CCTF4 Hacktivity Writeups 3. (Final)

Foxy challenge

The data given was printable ASCII, which implied a fair chance that it was encrypted (or obfuscated) with a cipher that always outputs such characters. Two obvious suggestions come to mind: base64 and rot13. However, the ciphertext didn’t exactly look like any mainstream base64 output, nor the rot13 of anything reasonable; what other similar ciphers (or encodings) are there?

The key giveaway was the hint of “!47 -> 42”. The main part of the solution was to take the rot42 of the reverse rot47 of the data. This produced what looked like base64 output. It was the base64 of the flag.

Author: Mr. SI

Ethereum VM bytecode challenge

The task was to uncover the flag from a thing that looked like 0x6080… To those familiar with Ethereum smart contract programming, this thing is obviously Ethereum VM bytecode; for others, as a starting point: the problem said “sometimes the code is 404”.

Decompiling the bytecode using an Ethereum VM decompiler <https://ethervm.io/decompile>, we could discover the following:

1. The constructor is uninteresting, it just sets up the contract’s long-term code.
2. The reverse engineered long-term code contains:
function getflag() {
storage[0x01] = 0x0b47326dc54f49d6f674;
}
which looks like a giveaway.

But actually “0x0b47326dc54f49d6f674” wasn’t accepted as the flag. Unfortunately, the bytes therein don’t appear to encode anything sensible either. However:

3. The rest of the long-term code is also not really interesting: it has methods to plainly store and retrieve data.
4. There was no inclination about any deployments of this smart contract.

So one ought to have been baffled: the flag must really be somehow in that outstanding constant. It turns out that the number 0x0b47326dc54f49d6f674 was indeed the flag, but the system accepted it only in decimal format.

Author: Mr. SI

Leave a Reply

Your email address will not be published. Required fields are marked *

2 × four =