Semi-automatic import recovery
Pawel (morel) <idleloopgmailcom> Monday, October 15 2007 17:39.11 CDT


New (only?) method to automate import recovery process:
http://www.idleloop.org/?p=8

Comments
sovietskicpu Posted: Monday, October 15 2007 18:15.13 CDT
hi morel, as you referenced the AV industry with their claims about generic decryptors. You are totally wrong in that point, because analyzed files have to be worked out in a safe environement with no escape issues and the method you presented, can be applied only for reversing purposes.

And off course Generic decryptors exist for real in avs with correct implementation of CPU emulation (NOD32 ?!)

morel Posted: Monday, October 15 2007 18:27.07 CDT
hi,

I don't claim that this technique should be used in AV engines, I see no reason to do so. It might be applicable with f.e. OllyBone, to partially recover packed files. See BlackHat presentation by Offensive Computing, they missed the import part..
By "unpacker" I mean a tool that, among many other things, can detect OEP. In this sense, it's impossible to create *generic* unpacker. AV scanners implement emulators, that's true.

jms Posted: Tuesday, October 16 2007 12:06.56 CDT
Well what I always wanted was even a known packer, have a method to unpack (using the signature) and do the import fixing, etc. on the fly. As opposed to having to run detector -> debugger -> imprec -> etc

neox Posted: Tuesday, October 16 2007 13:49.39 CDT
Hello,

I'm afraid such technique is already talked in great detail by E Labir in a paper published at CodeBreakers-Journal, Vol. 1, No. 2 (2004)

for those who do not have account there, here is the pdf
http://www.plunder.com/unpacking-by-code-injection-E-Labir-download-89472.htm

neox

morel Posted: Tuesday, October 16 2007 14:42.29 CDT
I wasn't aware of this work..
E. Labir's method is similiar, but requires manual log analysis and leads nowhere in case when packer calls many fake APIs inside redirection code.
Method with magic cookie will fail when API is fully emulated, as it sometimes is with GetProcAddress and in case when there is only *one* redirection procedure and APIs are distinguished based on return address left on stack by "call redirect" (technique used in SafeCast). Calls to IAT entries, from addresses unknown to the protector code aren't recognized and redirection fails.
The other story is, that such protecting technique can lead to unstable behaviour if code was selfmodyfing at the beginning :).