Lab summary questions

1. Considering malware analysis as a whole, how important is it to a general aspiring analyst to complete this chapter’s exercises?

2. What did doing the lab exercises teach that was not gained from reading the chapter?

Challenges encountered in the labs

Lab Walkthrough (includes answers!)

The goal of each of these labs is to unpack the code for further analysis so that other static techniques can be used. Try to avoid using automated unpackers and use the skills taught in this chapter. Each lab is a packed version of a previous lab.

18.1

I opened the file in OllyDbg and Ida, and just tried OllyDump’s “Find OEP by section hop (trace over)” option. You can verify that the program is progressing by clicking in the registers window. If the registers update when you click, you know the plugin is working.

After waiting about a minute, OllyDbg broke due to a conditional breakpoint: “EIP outside the range 407000…409FFF (i.e. a hop outside of that section). The code points directly to what looks like a function now located at 40154F.

I used OllyDbg to dump the process (** plugins -> OllyDump -> Dump debugged process **) (no changes to the dump options screen) and loaded the new exe into Ida, and it appears to be a good-looking, unpacked sample.

18.2

Upon first opening this sample with Ida, we get a warning that said

Truncated section " at file offsets 0x1000..0x2000 
Will read 0x290 bytes

which I don’t understand, but that’s okay for now.

Furthermore, when opening the file with OllyDbg, we get this message:

Stepping through the code a few times yields a pretty obfuscated seeming loop pattern. I’m not sure what it’s doing or how it’s doing it, but the classic approach is to let Olly do that for you. So I did, and it broke here.

This looks like data. Or perhaps it’s just in the data section of the executable. These are just bytes; let’s get Olly to interpret it as code: right click in the disassembly window -> analysis -> analyse code and boom, there we are. A function.

I dumped the program (default options) and opened the new executable in Ida, and it revealed something that looked similar to a ch7 sample analyzed earlier. Specifically the second lab.

18.3

I ran this file in OllyDbg and observed a pattern: it’s unpacking some code into another section, and then calling it, and that code unpacks some code into another section and then calls it, and etc. I bet this will mess with the Find OEP by Section Hop functionality– at least the “step over” part, since calls don’t return to the right place (as that’s how it transfers execution– by pushing a new variable onto the stack and then calling a ‘ret’ (I believe)).

Sections: 40Axxx, 407xxx, and some kernel calls. Arriving in these sections triggers OllyDump’s plugin to stop execution.

And, after attempting to find the OEP by section hop, I discovered it does indeed render the technique much less helpful. I sort of stumbled through and kept trying it and it would run to the next point in the code that was out of the current section. Theoretically, I can keep doing this until I finally hit a breakpoint that doesn’t look like unpacking code, but I don’t know if this is the most helpful strategy. I continued trying to resume the code for a while (i.e. using OllyDump’s trace into feature and then OllyDbg’s execute until user code feature), and it beame clear to me that this strategy isn’t very feasible.

I was hesitant to try the other “find section hop by jumping over” as I believe this code transfers execution by modifying where “ret” transfers execution to. In other words, we may have calls that never return to the instruction immediately after the call. Either way, I tried it, and it took me to a section that looks like data. I got Olly to treat it as code and disassemble it in the same way I did for the previous problem.

As it turns out, this was indeed the entry point– 0x401577. I am wondering if using a combination of section jumps with trace over and with trace into is a viable strategy.

Interestingly, after exporting the file with the EIP at this location, the imports section is still destroyed according to Ida, and furthermore, Ida’s disassembly code differs slightly (but makes more sense) than Olly’s.

In either case, after looking around this file with Ida, it appears to look much more like non-unpacking code, which further confirms my suspicion that this is the payload we’re after.

After reading the book answers…

The book acknowledges a pushf and a pusha at the very, very beginning of the file. It suggests that a packer will likely have corresponding popa and popf instructions at the end of the unpacking loop, and suggests putting a breakpoint on access of that pushed memory. I tried this, and it worked great.