Practice makes perfect. Begin with code assemblies that other programmers have analyzed. That way, you can compare your work against what other people have found. Analyze different types of code with different attack vectors to begin to see the various types of tricks that can be played. I often find an interesting malware program described on an antivirus site, and then I use a search engine to see if I can locate a copy of the actual malware program. Usually, the antivirus site has enough information about the program to give me an idea of what to begin looking for.
Develop an analysis rhythm that works for you. For me, I start code behavior analysis before the disassembly. Here are my steps:
Execute the program on a test machine and monitor the system using Filemon, Regmon, Port Explorer, and a network sniffer.
Run the Strings.exe program against it.
Record what I find.
Disassemble the program using IDA Pro.
Look for what APIs are present.
Print out the API routines found.
Print out a logic map of what jumps go where.
Read the auto-comments that IDA Pro inserted.
Start methodically stepping through the code.
Using this procedure, I’ve been fairly successful at analyzing malicious code. Where I personally bow out in code analysis is when the code is encrypted, polymorphic, or uses antidebugging techniques. I rely on my professional friends in the antivirus industry for their expertise.
Code disassembly is either something you love or you find boring. For those willing to exert the effort, the payoff can be tremendously exciting. For instance, days before the MS-Blaster worm went off infecting Windows machines around the world, I found an early copy of it on a client’s computer. The early version in my possession has significantly more functionality than the version reported in the wild. My copy has all sorts of stealth techniques and search capabilities. Although maybe it’s a geek thing, I enjoy knowing that I have an early prototype of the worm that most people don’t have.
I’ve also used disassembly to track hackers and to trace them back to their country of origin, and even to their hacker group. Different country’s coders often program in different ways, and I can often spot the difference in coding. Sometimes it is because programmers from the same country learn programming from the same university, and other times it is because they belong to the same malware-writing clubs.
For many honeypot administrators, capturing unique malware and recording brand-new hacker techniques is the best part of the experience. The honeypot is a means to an end.