Pair Reverse Engineering
sp <foobarcom> Thursday, December 13 2007 13:28.03 CST


Two days ago I had the pleasant experience to participate in some kind of informal reverse engineering session with three other guys. Between dinner and way too long after midnight we debugged a popular piece of malware that is floating around the internet right now. The first guy already reverse-engineered an earlier version of the malware. He was the guy in charge who did most of the debugging. The second guy was the author of a program that monitors and logs the behaviour of processes, especially malware processes. The goal of the session was to find out why the malware sample worked perfectly in VMWare (after we patched out the VMWare check, at least) but crashed as soon as second guys monitoring tool was active. The third guy was very familiar with the malware too but on a higher level (behaviour, network activity, how it spreads, its historic development and usage, ...). I was the fourth guy. Without a direct interest in the malware or the malware monitoring tool I just wanted to see what goes wrong. Furthermore I was the guy for snarky comments from the background like "see, I told you take a VMWare snapshot before stepping over that call".

Anyway, so much for the introduction. This was not the first time I debugged binaries with someone else, but in the past I always had the keyboard. This time I staid in the background and observed what happened. Primarily a software developer and only a hobbyist reverse engineer, I compared what I saw to pair programming where two people sit in front of the same computer and write code together. While I believe that pair programming is at least moderately useful, I got the impression that there are serious problems with pair reverse engineering (or quad reverse engineering).


Continue reading "Pair Reverse Engineering"

Comments
Posted: Wednesday, December 31 1969 18:00.00 CST