We here at ∇ Widening love a good challenge. We spend our days untangling the complexities of cyber threats, so a little reverse engineering puzzle every now and then is a welcome test of our skills. That’s why we threw out an open invitation to the cyber-security community: send us your toughest reverse engineering challenge.
Color us intrigued when a user named jonathan.e submitted his entry exactly 24 hours later the release of our website, even if we did not promote it. The file arrived with a cryptic message: “May the odds be ever in your favor.” Attached was…well, it certainly looked like a file. A .exe file, to be precise with the name message.exe (SHA256: ff0f4157e58285c3aaf37529a422d3c35d80ec7087090327b51ef146110d80ec).
Our team eagerly fired up their analysis tools including PE-Info just to take a look quickly, and then we moved to IDA Pro. The header and a couple of informations (such as some specific sections such as text) all indicated a Windows PE (Portable Executable) file, the kind you’d normally expect to be a program. But when we dove deeper, things went sideways. The internal structure was scrambled, the code nonsensical. “It was like staring into a bowl of digital alphabet soup” one could comment.
For starters, let’s dissect this “program” a bit further. A typical PE file, like the one jonathan.e sent, is like a well-organized toolbox. It’s divided into sections, each with a specific purpose. There’s the MS-DOS stub, a legacy holdover that helps the program launch even on older systems. Then there’s the section for code (text), where the actual instructions for the program reside. We also have sections for data (initialized variables), resources (icons, dialog boxes), and more.
The problem with jonathan.e’s file is that everything’s a mess. The code section is gibberish, the data section nonsensical. It’s like someone took the toolbox and jumbled all the tools together. But here’s the thing that keeps us intrigued: the PE header itself seems legitimate. There are no weird fields that contain and the various programs that do parse the Windows PE file format do not show any symptoms of something illegal.
The header contains information like the program’s entry point, the address where execution should begin, the architecture supported. This dedicated section, typically starting right after the MS-DOS Stub, holds the core information about the program, including its entry point, section table, and various flags. This tells us one thing. There might still be a program in there somewhere, hidden beneath the layers of obfuscation. The sections are apparently normal and all the sections .
This is where the real reverse engineering fun begins. We’re employing various techniques to try and untangle the mess. (Note: for people that work already in reverse engineering, you can skip this part because it is written for newbie people.) Disassemblers are helping us convert the scrambled code back into a (hopefully) readable format. Debuggers are standing by, ready to step through the program line by line, if we can even get it to run.
This isn’t always a straightforward process, but it allows us to see the raw instructions the program is trying to execute. However, assembly language is still very low-level and difficult to understand. That’s where decompilers come in. These tools attempt to reverse engineer the assembly code back into a higher-level programming language, like C or C++. While decompilation isn’t perfect, it can provide valuable clues about the program’s true functionality.
Before unleashing jonathan.e’s creation, we need to get it inside the sandbox. This transfer can’t be a casual copy-and-paste job. We need to ensure the process is secure and doesn’t introduce any vulnerabilities. Popular sandbox solutions often come equipped with built-in file transfer functionalities.
Once the file resides within the sandbox, it’s time for the main event. We’ll utilize the sandbox’s built-in process monitoring capabilities. Imagine a digital magnifying glass, allowing us to observe the program’s every action within the isolated environment. As jonathan.e’s file launches and executes, we’ll be watching with hawk-like focus.
The true test lies in how the program interacts with the sandboxed system. Here’s where we become digital detectives, looking for any signs of malicious intent. Is the program attempting to access sensitive areas of the sandbox, like system folders or user files? Does it exhibit a sudden urge to establish network connections, potentially trying to phone home to a malicious server? Is it meddling with system settings in an unauthorized way? Any of these actions would raise a red flag, prompting us to dig deeper into the program’s functionality.
Even if the program manages to evade detection during its execution, we have another trick up our sleeve: memory forensics. This technique involves creating a snapshot of the sandbox’s memory after the program has run its course. Think of it as a digital crime scene investigation. We’ll employ specialized forensic tools to analyze this memory dump, searching for any remnants of the program’s activity. These tools can potentially reveal traces the program might have tried to hide, such as loaded libraries with suspicious functionalities, function calls made within the system, or even network connections the program attempted to establish.
Static analysis can identify suspicious code patterns, while dynamic analysis in a sandbox helps unveil a program’s true nature. Memory forensics provides a final layer of investigation, even if the program attempts to vanish without a trace.
However, it’s crucial to remember that this is just a simulation. Real-world attackers are constantly evolving their tactics, and there’s no guaranteed foolproof method. By staying vigilant and continuously improving our analysis techniques, we can stay ahead of the curve and protect critical systems from the shadows.
One thing’s for sure: this isn’t just about winning a challenge anymore. It’s about understanding the intent behind it. Is this a playful exercise, or a potential security threat disguised as a game? We’ll keep you updated on our progress :)
∇ Widening is a boutique Italian cybersecurity firm with deep expertise in software analysis. We work in the context of MATE attack and defence. We have plenty of experience in terms of building, and disrupting software protections to achieve client needs.
We use reverse engineering, software attacks, and static analysis to uncover the inner workings of any software, from desktop applications to malicious software.