2

I have rebuilt the iat table of a UPX packed to the point where there are no invalid thunks (All "Yes"), I then fix the dump though when I open the final fixed executable in impRec I get invalid thunks which I originally sorted alongside some new invalid thunks. I'm getting the same results with multiple versions of UPX, this is the final hurdle for me in fully unpacking the packed executables, where am I going wrong.

2
  • 1
    Does the rebuilt file run properly without crashing ? Also if you have already fixed the IAT, why are you reopening it in ImpRec ? – 0xec Sep 5 '14 at 18:52
  • I'm reopening it just to verify if all the imports were resolved correctly after I fixed the dump with all resolved imports. – user28130 Sep 5 '14 at 19:03
2

Try using Scylla for import reconstruction as ImpRec is outdated (The last update is from 2011, and form a third-party) and known for having problems nowadays.

1

upx - d didnt work ? for some, when rebuilding the import can be a forwarded import, which sometimes doesnt resolve correctly, this happened a lot in cracks made on vista and higher (typically the SetLastError api)

3
  • I'm using windows and unpacking some unpackmes. I understand what you mean about forward imports not resolving correctly but I managed to resolve all import thunks correctly using ImpRec though when I fix the dump and open the unpacked executable in ImpRec I get unresolved pointers and errors that I supposedly fixed before when I was rebuilding the dump. – user28130 Sep 5 '14 at 18:51
  • hmm, are you sure you're rebuilding the right iat? as imprec sort of autoscans, so it might see the packer iat first, then the real one... – evlncrn8 Sep 5 '14 at 20:07
  • I open it up once I am at the oep and have made changes to resolve pointers, this seems to work though confused as to why unpacked executable when opened in ImpRec later shows invalid thunks. – user28130 Sep 6 '14 at 0:52
1

Import REConstructor rebuilds the Import Table, not the Import Address Table.

If you want to verify that Import REConstructor worked correctly, you'd be better off examining the resulting EXE with an Import Table tool such as Dependency Walker. There's no point in examining the resulting EXE (once it's loaded) with Import REConstructor because its displayed output is based on the runtime Import Address Table, which was never rebuilt.

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.