It turns out I had actually fully unpacked pespin (or at least emulated all that could be), and the stolen functions I was emulating were from the original binary ;-|
But I implemented a quick hack before then to emulate stolen bytes. I simply record %esp and %ebp after an indirect call has been made. I assume that all calls to stolen functions are indirect. I emulate up until the point the stolen function tries to jump back to the original win32 function. At this point, I assume the nearest symbol is the original function. I restore esp and ebp to what they were at the last indirect call, and then call the emulation code for that particular function. The reason why I restore esp/ebp is that my emulated win32 functions use them for arguments and also to obtain the return address. Also, they are the only registers which arent rewritten by win32 functions.
There is a simple way to make the analysis fail, but I won’t say for now.
pespin also steals the code at the entry point.
I forgot to mention, that in tracer mode I was also able to unpack yoda’s protector 1.02. I can’t do 1.03 as it has a number of win32 functions I don’t emulate; such as window handling.
[edit: added a couple hours later]
I added some extra code to check that an address belongs to a stolen function. I disassemble the original function (from disk) up until the first branch instruction. If the address being jumped too is between the start of the function and the first branch instruction, the address is part of the stolen function. This method is alot safer than taking simply the nearest symbol without any further checks. Of course, if alot of code is stolen it wont work.. I’ll wait until I see some malware do that before tackling the issue (I haven’t emulated enough samples obviously)