When manually unpacking a program and ending up at the OEP, then why do we have to rebuild the import table? I understand that when packing, the import table is destroyed for compression/stealth, but if we're already at the OEP, it must mean the program is ready to roll because the unpacking stub has repaired the import table already? Otherwise it would just crash at the first external call.
Add a comment
|
2 Answers
if we're already at the OEP, it must mean the program is ready to roll because the unpacking stub has repaired the import table already
No, by the time the OEP is reached, the unpacking stub has populated the Import Address Table; it hasn't repaired the Import Table. You need to reconstruct the Import Table so that when you run the unpacked program, the Windows loader will populate the Import Address Table at runtime (with the correct function addresses at runtime) based on the data in the Import Table.
(Note that there are always exceptions, but this is typically true for most packers.)
answered Nov 24, 2014 at 15:11
The unpacking stub may just load the imports instead of repairing the import table. If you want to save the executable to be able to run it later, you won't have the unpacking stub in your saved executable, so noone loads the imports for you unless you repair and the import table as well.
answered Nov 24, 2014 at 15:11
-
Thanks for the helpful answer. I decided to accept Jason's answer instead because it made me realize the difference between the two but I'll upvote this when I have enough rep.– ltnaishaNov 24, 2014 at 15:25
-
No worries, Jason's answer is better than mine and provides much more detail. That's why i made mine a comment at first. Nov 24, 2014 at 15:43