Introduction To Control Flow FlatteningControl Flow Flattening is a code obfuscation technique used to make code harder to reverse engineer. It involves transforming the control flow of a program to make it more difficult to understand and analyse. CFF removes structured code flow and is very effective at hindering static analysis efforts, while maintaining the original behaviour of a protected binary. CFF typically has the following characteristics: Has >= 1 state variable(s) Control flow decisions are made based on the state variable(s) State variable(s) are set to a new value, and the code flow is then “rerouted” to the intended block For the scope of this article, we shall be looking at a trivial example of a CFF-obfuscated calculator binary.

This posts contains potentially helpful malware analysis techniques and know-hows and would hopefully be updated constantly 🤞. PE ExtractionTo extract PE files from memory, several methods can be used: Use Process Hacker to dump memory region into file for analysis in IDA. Use pd64 to dump modules from a running process. This is helpful for modules that are decrypted and loaded during run-time by launchers. Should output a perfectly debuggable DLL for analysis.

We are given a PCAP to start off with this challenge. PCAP AnalysisLooking at the TCP streams, a command injection seems to be going on. We can then see a binary named induct being requested and downloaded onto the machine. We can extract the binary out for analysis. Binary AnalysisThe binary is a golang binary and luckily for us, the symbols are not stripped. Looking at main_main, we can see that it creates a new IRC client, attempting to connect to wizardcult.

Binary AnalysisThe binary provided has a ton of invalid instructions like: 1 2 xor eax,eax div eax or 1 2 xor eax,eax mov eax,[eax] This led me to believe that SEH was in place. After digging for some time, I could not find the SEH handler for any of the exceptions triggered. Turns out, the exception handler is registered during runtime, via the WinAPI AddRtlVectoredExceptionHandler. We can set a breakpoint for the API in x32dbg using the command bp AddRtlVectoredExceptionHandler.

We are given a huge HTML file with lots of Javascript in it. On first glance, there seems to be a lot of redundant code. Filtering the JavascriptUpon looking through the Javascript, it seems that removing the miscellaneous functions within the Add function would help to clean up some stuff. Through discussions with a friend, he told me that we could actually use vim to remove all defined functions within Add through the usage of macros.

Upon running the binary, it shows an error. Upon closing the window, nothing appears to happen. However, the application continues to run in the background. Binary AnalysisAfter some trial and error, I managed to find out where the error window was created and shown. After which, there is a huge mov operation to load shellcode into memory. Nearing the end, there are calls to VirtualAllocExNumA and memmove to load the shellcode into memory.