#Run bochs in debug pro
#Run bochs in debug code

I curated a library of function opcodes in an IDAPython script as shown in Figure 4.

#Run bochs in debug code

I compiled this and then used IDAPython code similar to Figure 3 to extract the function opcode bytes. Figure 2 shows some of these stand-ins.įigure 2: Simple implementations of common functions I built simple C implementations of selected functions and compiled them into one binary. I needed opcodes for a few common functions to inject into my IDBs and emulate in Bochs. I knew I could stub out a few function calls in the malware to run all of the relevant logic in Bochs. I had the intermediate payload stage and wanted to unpack next-stage payloads without managing a multi-process debugging scenario with anti-analysis. The code in Figure 1 executes in a remote thread within a hollowed-out iexplore.exe process the malware uses anti-analysis tactics as well. Figure 1 shows this unusual call site.įigure 1: Call site for intermediate payload My sample (MD5 hash 37F7F1F691D42DCAD6AE740E6D9CAB63 which is available on VirusTotal) was an EVILNEST variant that populates the stack with configuration data before calling an intermediate payload. I’ll also show how I copied a tricky call sequence from one IDB to another IDB so I could keep the unpacking process all in a single Bochs debug session. I’ll demonstrate using this on an EVILNEST sample to unpack and dump next-stage payloads from emulated memory. In this post I’ll discuss the particulars of statically linking stand-ins for common functions into an IDB to get more mileage out of Bochs. What if I could bring my own imported functions to Bochs like flare-emu does? I’ve devised such a technique, and I call it code grafting. Tom Bennett’s flare-emu ships with emulated versions of these, but for off-the-cuff analysis (especially when I don’t know if there will be a payoff), I prefer interactively examining registers and memory to adjust my tactics ad hoc. This precludes emulating routines that call imported string functions or memory allocators. Execution is constrained to opcodes found in the IDB.

Alas, where there is no OS, there can be no loader or dynamic imports. Bochs emulates the opcodes directly from your IDB in a Bochs VM with no OS.īochs IDB mode eliminates distractions like switching VMs, debugger setup, neutralizing anti-analysis measures, and navigating the program counter to the logic of interest.

I use IDA Pro’s Bochs integration in IDB mode to sidestep tedious debugging scenarios and get quick results. While the fastest way to analyze or unpack malware is often to run it, malware won’t always successfully execute in a VM.

#Run bochs in debug pro

This blog post continues the FLARE script series with a discussion of patching IDA Pro database files (IDBs) to interactively emulate code.