1

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.

4

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.)

  • I understand the real distinction between IT and IAT now, thanks. – ltnaisha Nov 24 '14 at 15:23
3

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.

  • 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. – ltnaisha Nov 24 '14 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. – Guntram Blohm supports Monica Nov 24 '14 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.