I’ve recently analyzed a malware sample that parsed and modified raw network packet data. That means I had to deal with many register relative offsets in IDA Pro. The most practical way for this is to define and apply structs.
While IDA’s type libraries contain some of the packet structures (i.e., ETHERNET_FRAME, IP, TCP, and UDP_HEADER), other protocols (i.e., ARP) are missing. Additionally, I did not find structures encompassing multiple communication layers – for example ETHERNET_FRAME, IP, and TCP grouped in one structure.
While teaching malware analysis courses I often get asked for good reverse engineering and malware analysis resources. This is a small collection of websites and documents that I regularly use and that I recommend to new and experienced reverse engineers.
@mkhdznfq published an interesting write-up of this year’s FLARE On challenge number eight at https://mokhdzanifaeq.github.io/2017/10/17/flareon-2017/. He used Frida to instrument the challenge’s Android app. This allowed him to easily obtain the required data without the need for deep static analysis or setting up a debugging environment. I decided to try the tool to aid in reverse engineering. While most of the tutorials I’ve discovered focus on using Frida on Android in this post, I will cover some of my first experiences with Frida for instrumenting Windows PE files.
As an optimization, compilers inline functions. In general, this makes reverse engineering a disassembled program more cumbersome. And often times its confusing to novice reverse engineers. Frequently, compilers inline the functions memset and memcpy. Due to this IDA Pro may produce multiple stack variables when in reality there should only be one. In this post I am going to share a script that will help you to automatically modify stack variable sizes and definitions for a function’s stack frame. This will make the disassembled code easier to understand. Moreover, it can improve code decompilation.
When performing basic static analysis of malware, the file’s strings can provide helpful indicators, including filenames, registry keys, and URLs. The strings can additionally hint at a program’s capabilities and its intended use. Identifying unique strings in malware is also a great way to pivot to related samples. Searching private and public databases for unique strings may lead you to existing analysis results and (leaked) source code. In this blog post I define the term unique string, explain how to leverage unique strings, look at common issues when dealing with unique strings, and provide a solution to automatically extract them.
The FireEye Labs Obfuscated String Solver (FLOSS) automatically extracts obfuscated strings from Windows executables and shellcode. The tool integrates with various reverse engineering tools including IDA Pro, radare2, and x64dbg. In this post, I will show how to leverage strings that FLOSS decoded when reverse engineering malware using IDA Pro and debugging it using x64dbg. Continue reading “Integrating FLOSS deobfuscated strings into IDA Pro and x64dbg”
Reverse engineering and tool development expert David Zimmer (dzzie, http://sandsprite.com) recently released remote_lookup, “a small tool which can scan a 32bit process and build an export name/address map which can be queried”. The tool is available on FireEye’s GitHub page at https://github.com/fireeye/remote_lookup.
remote_lookup can significantly speed up the analysis of malware that obfuscates its access to Windows API functions. David covers common malware techniques for such obfuscations in the blog post available at https://www.fireeye.com/blog/threat-research/2017/06/remote-symbol-resolution.html. The post also talks about the motivation of remote_lookup, common analysis techniques (and their shortcomings), the tool’s functionalities and how it can accelerate reverse engineering of obfuscated malware. I highly recommend reading his post – especially if you are going to continue reading this tutorial.
Highlighting important and suspicious instructions helps me tremendously to understand and quickly navigate a disassembled binary. Every time I browse a freshly opened binary in IDA Pro I feel that something is missing. Reversing without colors is less fun!
Look at the two screenshots below. I’m having a much easier time navigating the highlighted disassembly on the right.
When triaging malicious executable files I always try the FireEye Labs Obfuscated String Solver (FLOSS) to quickly decode obfuscated strings. In short, FLOSS uses heuristics to identify decoding routine candidates and emulates them using vivisect’s disassembly and emulation modules.
While vivisect is an awesome tool, it sometimes is not as robust as IDA Pro in parsing and disassembling binaries. In addition, IDA Pro provides the Fast Library Identification and Recognition Technology (FLIRT) that helps to distinguish standard library functions and functions written by the program’s author.
One of IDA Pro’s most important features is that it allows us to interactively modify the disassembly – hence, the I in IDA. This includes renaming of function names, variable names, and names of addresses. IDA Pro refers to these names as identifiers and enforces a certain naming scheme on them. After working with IDA Pro for a couple of weeks most people develop a good understanding of valid names and what to avoid when renaming identifiers. However, I wanted to know how IDA Pro checks identifiers and describe my findings in this blog post. In addition to this, I discuss the character encoding used for comments in IDA Pro. Adding comments to a disassembled program is another useful feature many reverse engineers take advantage of. While users normally don’t have to worry about the comment encoding this information can be handy in certain situations – especially when dealing with comments in IDAPython scripts.