Here are some considerations about malware unpacking, on how some people approach a target. The idea of this post was born after reading this thread at RCE forums.
When you have to deal with a packed malware there are, fundamentally, two different approaches depending on what you want to do. If you want to write an unpacker you have to study all the packer’s code, otherwise if you simply need to unpack it in a reasonable time you don’t have to step the packer line by line.
Suppose you want to dump the malware without stepping everything. In this case you should use some strategical breakpoint and a little bit of brain, especially when you are in front of a function with a lot of nasty cycles. Just for a simple example take the malware linked in the forum’s thread. The code used to decrypt part of the original code could be a painful for many people just because with a step-by-step approach you’ll pass over the same instructions again and again.
What to do now? Think a bit and use all the tools you have. A tool able to show the diagram of a function could come in handy. I usually prefer to use old tools because I feel more comfortable with them and … most of the time because it’s just a matter of laziness. There are some exceptions and Wingraph package is one. This tool gives you the opportunity to understand the flow of a function very quickly. I admit I often use it. To see Wingraph in action you can use IDA or OllyGraph, an Ollydbg plugin written by Joe Stewart.
Going back to the malware, the image on the left shows the function used to decrypt some code, the function is located at the end of the packer. There are a lot of jumps, how can you quit from it easily? Look at the picture, there are two possible exits, one represented by the box at the bottom and the other by the box at the top on left. The bottom box contains:
004584D3 POPAD
004584D4 POPFD
004584D5 JMP 0041080E
while the other box’s instructions are:
004581F6 push 0
004581F8 retn
Well, from the two options I’ll try with the first one but if you have some doubts you can put a breakpoint on both. In this case the debugger will break on the first option giving you the opportunity to pass over this function, far better than a step-by-step approach.
