DIMVA CTF: starts Wed 17 July 18:00 GMT

Question

DIMVA Capture The Flag starts Wednesday 17 July at 18:00 GMT and lasts 44 hours. Some highlights from the rules:

• This is a level-based CTF, there is no attack and defense and it has challenges of different levels so anybody can enjoy playing it.
• The CTF is designed to be played individually. Nevertheless we know we cannot avoid teams playing too.
• Sharing solutions between different users is not allowed and will result in disqualification, play as a team then.

Join the #dimvactf IRC channel on hackint for realtime communication.

If you want to play as a team, you can join team Sec.SE (see the meta post for more information). We meet in the CTF team chatroom.

If you prefer to play alone (which is necessary to win any prize), do not join the room.

Answer 1

Crypto 100

We have some plaintext files (quote?.txt) and what is presumably the associated ciphertext, plus empty.png and flag.png, in the form of PNG image. A quick look at the PNG files (e.g. conversion to PBM) shows that they are all grayscale and have identical grayscale values. The next obvious thing to try is the alpha channels.

for x in *.png; do pngtopnm -alpha <$x >${x%.*}.alpha; done

The alpha channels consist of bytes \xff and \xfb (except empty.png which is all zero), with the trailing bytes being \xff. Let's pack them into 8-bit bytes. I initially chose \xff to be the 0, but it turns out to be 1.

for x in *.alpha; do perl -we '
    scalar <> for 1..3;
    $line = <>;
    while ($line =~ s/^(........)//) {
        $_=$1; y/\xff\xfb/10/;
        $buf .= chr(oct("0b$_"))
    }
    $buf =~ s/\0+$//; print $buf
' <$x >${x%.*}.enc; done

The resulting quote?.enc files are identical to the corresponding plaintext files quote?.txt (except for some trailing \xff padding). In flag.enc, we see (encoded in UTF-8)

Here's your flag, enjoy :-): ⓒ⓪ⓕⓕⓔⓔ⑦⑤②ⓑ③②⑦⑧⑤ⓕ③①ⓓⓒ⑤⑦ⓕ①ⓔ⑨ⓒ③ⓕ⑧⓪ⓔ

For the Unicode-challenged, these are enclosed alphanumerics, U+2460 through U+24FF. The flag is c0ffee752b32785f31dc57f1e9c3f80e.

There was no cryptography here, only steganography.

Answer 2

Misc 200

We have an XDP file which encodes a PDF file. At the bottom of the PDF file is a comment with the password of the PDF file. p____h provided a decompressed version. There's a string in there that looks like a flag, but this isn't it. There's also some Javascript code, encoded with hexadecimal escapes. Here it is after some light reformatting.

var resp = app.response({cQuestion:"Enter password", cTitle:"Password",});
if (resp == this.saveXML()) {
    var s = "c0ffeed5838de68871c45374f04c865a";
    var t = "" + this.resolveNode("/flagKey");
    var n = "c0ffee";
    var baz = 0;
    for (var i=6; i<s.length; i+=2) {
        baz = parseInt(s.substr(i,2),16) ^ t.charCodeAt(i/2-3);
        a = baz.toString(16);
        if (a.length == 1) {
            n += "0" + a
        } else {
            n += a
        }
    }
    this.rawValue = n
} else {
    app.alert("Incorrect password")
}

flagKey is CXrgfTA4sBXz9SBehVirA4A61zOgkXbm. Executing this JavaScript code (minus password check) with t set to the flagKey field of the XFA data yields c0ffee96dbff81ee25856707b214fc63, which is still not the flag. (Or is flagKey encoded in Base64? That produces c0ffeedcf96d9bb849744687056cd8df which isn't correct either.)

After the contest ended, with HamZa, we realized that this.resolveNode("/flagKey") returns null (which makes sense: there's no node called /flagKey). With t="null", we get the correct flag value: c0ffeebbf6e18a8871c45374f04c865a.

Running the code in Acrobat Reader (which I didn't want to bother installing for the contest) also works, if you change the code to omit the password check.