Solution to ElizeVC (Part II): Reconstructing the original binary This is the second part of the solution to ElizeVC, one of my challenges for this years MRMCDCTF. In the first part I explained how to get the flag without actually attacking the crypter. Here I will focus on how to defeat the protector and reconstruct the original binary (at least the interesting parts) from the encrypted file. The Protection The protector encrypts every function on its own (as opposed to, for example, the complete .

Solution to ElizeVC (very hard) from MRMCDCTF 2019 ElizeVC was the hardest challenge I had written for this year’s MRMCDCTF. Protections The binary of this challenge is protected with various methods: crypter/protector: The binary is encrypted on a per-function basis. Each protected function is encrypted with 128-bit XTEA in Counter Mode, with different keys and IVs for every function. Whenever a protected function is entered, the uncrypter is called, which decrypts the function in place.

Solution to Carbonara (medium - hard) from MRMCDCTF 2019 Carbonara is another one of my challenges for MRMCDCTF 2019. Just like KonradVC, it employs an anti-reversing trick, but of a completely different kind: the code is chopped into small pieces, each one instruction long. These pieces are saved in random order, and connected by jmps. The resulting code executes the instructions in the right order, but looks like a total mess.

Solution to KonradVC (medium - hard) from MRMCDCTF 2019 KonradVC is the second Windows challenge I wrote for the 2019 MRMCDCTF. Even though it’s a Windows challenge, it runs fine under Wine. KonradVC was intended to be harder than Slicer, the other Windows challenge. It employs a very simple crypter to make analysis of the actual challenge code more difficult. When loading it in Ghidra, the first thing we notice is that there seem to be only two functions: entry and FUN_00406039.

Solution to Misguided (easy - medium) from MRMCDCTF 2019 Misguided is another Linux binary reversing challenge I had written for MRMCDCTF 2019. This one employs some simple obfuscation: Some entries in the symbol table are mixed up. When opening the file in Ghidra (like we have done with Cereal or Slicer before), at first, everything seems normal. This changes once we take at look at main, which decompiles to this:

Solution to Hopping machine (medium) from MRMCDCTF 2019 Hopping machine is completely different from the other reversing challenges I wrote for this CTF. In some ways it’s an extension of an older challenge (Friendly Machine) I had written for MRMCDCTF 2017. What makes it different? First, it’s written entirely in python. And second, the complete source code is provided with the challenge. It therefore requires a different approach than the binary reversing challenges.

Solution to Slicer (easy) from MRMCDCTF 2019 Slicer is one of the Windows challenges I have written for MRMCDCTF 2019. It’s another easy challenge, but this time the binary is an .exe (PE32) executable. The challenge was also tested under wine (4.0), so if you want to try out some of the tricks for debugging wine applications, this would be a good opportunity. But for this text, I will stick to Ghidra .

Solution to Cereal (easy) from MRMCDCTF 2019 Cereal is another reversing challenge I have written for this years MRMCD CTF. But unlike Sitting duck, this reversing challenge actually involves reversing! At first look the binary is similar to Sitting duck: It’s a 64 bit ELF executable, and it asks us for the password/flag when started. But simply trying strings will bring up nothing useful, so we have to actually analyse what the program does internally to find the flag.

Solution to Sitting duck (very easy) from MRMCDCTF 2019 Sitting duck was by far the easiest challenge I have written for the MRMCD 2019 CTF. It was targeted mostly at total CTF newbies that had absolutely no previous experience with reversing challenges. The challenge gives you a binary file and the hint that it is solvable with very little experience. When executing the file, it asks us for the flag.

In this post I will explain how to use /proc/kcore to read the physical memory (RAM) of a Linux system from userland. I’m also exploring how and why a previous tool for this task (getkcore from volatility) fails under newer (past 4.8) kernels. In parallel I present a simple demonstrational tool to dump the physical memory of a x86-64 system under more recent Linux version. But first, lets have a look at two virtual files on a Linux system: /proc/kcore and /proc/iomem.