Guest article: solving a flare-on challenge with esReven

This guest blog is brought to you by Xusheng. He is a software developer at Vector35 and works on Binary Ninja.

In this blog post, I will share how I used esReven to solve the final challenge in last year's ninth flare-on challenge. Flare-on challenge is a reverse-engineering CTF hosted by the FLARE team. It typically runs in six weeks and the last few challenges can be quite hard.

The solution using esReven is quite unexpected and even amusing. It requires no conventional reverse engineering at all. If you are interested, please read on!

First Impression

The challenge file 11.exe is 9.1 MB in size. Running the file in a Windows VM yields nothing – it runs for a few seconds and then exits, without asking for a password or flag.

I opened the binary in Binary Ninja (obviously!) and it did not take me too long until I realized the file is generated by PyInstaller. After all, the existence of string _MEIPASS2 in the binary and the python37.dll at the end of the binary is the most obvious sign.

Files like this can be unpacked by the tool pyinstxtractor. The output consists of lots of files but most of them are unrelated since they are just the Python interpreter. Among them, I found 11.pyc, which is a compiled Python Bytecode file. It can be then de-compiled to its source code using uncompyle6.

from pytransform import pyarmor
pyarmor(__name__, __file__, b'PYARMOR\x00\x00\x03\x07\x00B\r\r\n\t0\xe0\x02\x01\x00\x00\x00\x01\x00\x00\x00@\x00\x00\x00a\x02
\x00\x00\x0b\x00\x00x\xa7\xf5\x80\x15\x8c\x1f\x90\xbb\x16Xu\x86\x9d\xbb\xbd\x8d\x00\x00\x00\x00\x00\x00\x00\x0054$

... omited for simplicity ...

C\xa91#y\xd9u\xf1\xd1BC\xcc}\xe8;?\x12S\x16', 2)

Well, the script is not very large but it is protected by PyArmor. I tried to break PyArmor by searching for existing tools and researching by myself, but none of them worked. I also notice that there is a commercial variant of the PyArmor, so, likely, the challenge is not trying to break the protector – maybe I can treat it as a block box and somehow still solve it. Flare-on challenges are versatile so I decided to look closer at the binary and see what it does during its execution.

Network Traffic

I noticed that the file is trying to resolve www.evil.flare-on.com, which failed. I edited the host file and pointed it to my local host, and filed up a dummy Python server to dump whatever it sends. It sends the following request:

POST / HTTP/1.1
Host: www.evil.flare-on.com
User-Agent: python-requests/2.28.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 79
Content-Type: application/x-www-form-urlencoded

flag=%2FB3EPupkU5y2GEHyayw%2FLP25gd6OdCVVYehe%2BHqnyhwkEZP2aCxijmJkBcb5FA%3D%3D

Seeing the flag=xxxx proves my direction is correct. The string after that seems like a certain ciphertext, although I was unable to decipher it. I guess that the string is generated by the above Python script, and as long as I backtrace how it is generated, I should be able to figure out how the script works and solve the challenge.

esReven Rules!

That is the point at which I decided to run the executable in esReven, because it provides unrivaled strength in dynamic code analysis. Technically I can use a regular debugger as well. However, since the file involves a Python interpreter and the code is heavily obfuscated, it is all too easy to get lost and earn nothing.

On first approach, I simply recorded the execution of that binary in esReven. After that, and before I even look for the above string and study how it is generated, I simply tried searching for @flare-on.com in the string history. Of course, I can do so because I have prior knowledge of what I am looking for, and I know that my flag ends with this string.

Editor's note: the string history database is produced after the recording, by analyzing all memory accesses that occur during a trace and logging what looks like strings. Therefore, if a string is read or written in clear-text at one point during a trace, it will appear in this database, event if it gets erased later on.

Hold tight – the flag string is found in cleartext directly: [email protected]!

Here is what it looks like in esReven's GUI:

When I first saw this, I really could not believe my eyes. It was only until after I validated the flag on the CTF website that I knew for sure this was the real deal (and not some bait).

After the CTF was over, I checked the official solution and my guess was correct: the flag string first exists in cleartext form in memory. After that it is encrypted using RC4, then encoded in base64, and that becomes the string in the HTTP request we saw above. So even if the PyArmor protection is very strong and there is no direct way to de-obfuscate the script, the cleartext cannot hide from esReven's eyes!

Great, this is also my first time completing the flare-on challenge.

A note on binary recording in esReven

Since this blog post is not an esReven user manual, I will not cover all the steps to do the record/replay. However, there is one feature of esReven that is worth noting: binary recording.

Typically, when we do a manual recording in esReven, we need to start the recording and then launch the target from the UI (e.g., by double-clicking it). This adds a considerable amount of useless instructions in the trace. With binary recording, esReven is responsible for launching the target and starting the recording precisely at the moment when the target is launched, and stopping the recording when the target exits, or otherwise crashes. This can drastically shorten the trace and the time to replay the scenario, which I think is the most important thing to get a good esReven recording.

While writing this blog post, I redid the recording in esReven 2023.01, which is available since January 2023. Back in October 2022 when I solved the challenge during the CTF, I used REVEN 2.11 Professional edition, which does not have the binary recording feature.

Editor's note: the various editions that existed up until REVEN 2.11 (Professional and Enterprise) have been merged into a single offering. All features are now available starting esReven 2023.01.

Here is a table comparing the two methods:

|           Item           | Binary recording | Manual recording |
|--------------------------|------------------|------------------|
| Scenario Size            | 91.7 GB          | 510 GB           |
| Replay Time              | 1.5 hours        | ~12 hours        |
| # of instructions before |                  |                  |
| the string is spotted    | 1.5 billions     | 8.1 billions     |

For this scenario, we can see that I successfully recorded much fewer instructions using the binary recording feature. And this brings drastic improvements to the scenario size and replay time, which both affect the usability of esReven.

Want to try the product?

We provide an extensive set of online demos, which constitute a good first step with tutorials available in most, even if they are based on the previous REVEN version for the time being.

Want to try the new esReven? Contact us!