small problem with ImpRec

[Hero]

Hi all
When I were unpacking an application,I find out an strange problem.
My ImpRec gets every imprt correctly,and I can repair my dump with 'add new section' checked with no problem.
But I need to rebuild my current FirstThunks,so I uncheck 'add new section' and set RVA equal to RVA that I found my IAT in it(for example my RVA to 'Get Import' is 57000,I set RVA to fix dump 57000).
When I try to fix dump in his case,ImpRec corrupts my FirstThunks,so PE becomes invalid.
Am I doing something wrong?

Regards

[hobferret]

Hero, use add new section, it always works

[Hero]

Originally Posted by hobferret

Hero, use add new section, it always works

yea,it works even in my case too,but it works obviously by chance... :P
you know has happned?
right now,I have an IAT that ImpRec finds it.Assume it starts at address 0x57000.My program refers to this IAT(name this 1st IAT).
If you use 'Add new section',Imprec creates new section and generates new IAT for example at address 0xD7000(name this 2nd IAT).
1st IAT and 2nd IAT seems to be same and your program will work,because every API has been loaded for 2nd IAT,and base address of loaded DLL are normally the same,hence every FirstThunk in 2nd IAT will be equal to adress in 1st IAT that is stored statically.
But because you are using 1st IAT's static address,if DLLs load in any other address rather than their normal base address,your program will crash.
That's why you need use currect IAT(1st one) while repairing your IAT.

I wish I were able to explain what happens,My english is not very well.... :P

Regards

[TQN]

No, not IAT, it is IDT: Import Directory Table. ImpREC GUI/document make user confusing about them. The IAT in dump file is always the IAT in the fixed files. ImpREC will only fix the IDT + name table + original table...
I alway use PEView to view the IAT/IDT struct before and after dumping PE file.
The option of ImpREC change the way of IAT/IDT in the fixed file.

[Hero]

So in my case it has done something wrong....
In my test,it made a 2nd IAT in exchange of using current one.

Regards

[TQN]

Can you upload the dumped.exe and dumped_.exe ?

[Hero]

Originally Posted by TQN

Can you upload the dumped.exe and dumped_.exe ?

Here you are:
http://rapidshare.com/files/128085736/Dump.rar.html
The IAT that I use to scan in Imprec is placed in 0x97d000 but Imprec makes new IAT starting 0xd5e000(Oh, Better I say,I mean FirstThunks).

Regards

[Nacho_dj]

Hello Hero:

What I find in your fixed dump is that the Original First Thunk and the First Thunk are in the .mackT section.

Original First Thunk begins at the offset: 0x95E000
First Thunk begins at the offset: 0x95EA90

They are pointed by the Import Table, beginning at the offset 0x95F520.

You could compare at these offsets that the values of either Thunk are the same in the dumped fixed file.

However, when you execute your target, in memory the Original First Thunk will get the handles of the functions in the places of the pointers to the names of functions, loaded by the system, becoming in that way the IAT. So in memory, content of Original First Thunk won't be the same than First Thunk.

Forget the previous Import Table of dumped at offset 0x595F84. It won't be used any more, since the tool has changed in Data Directories the Import Table Relative Virtual Address to 0x95F520.

But it is a right Import Table. Is there any issue for running the target?

Cheers

Nacho_dj

[Hero]

Hi Nacho
There is no problem in running dumped_fixed.exe on my computer,and this,itself is a problem...
I assume that addresses you told me are RVA-Base,if so yes,FirstThunk of App is at address 0x95EA90,But FirstThink should be 0x57d000, not 0x95EA90.
I were about to rebuild FirsthThunks at 0x57d000, but ImpRec create new IAT and i got FirsthThunks at 0x95EA90.
I didn't notice this at first too,But if you decompile dumped_fixed.exe,you will see that there is no reference to FirstThunks at address 0x95EA90.

Regards

[Nacho_dj]

OK, I am checking for instance the line at VA 0x9535F6. There you can find a call to CloseHandle function. In the dumped_fixed, do not why, it has not been fixed to the new Import Table by ImpRec, so it is calling to a non-sense address, and it is the old IAT. However, you are getting a working exe because at that address there is in your file the hardcoded handle (originated by the dump) of the function, so it works. If you test this executable in another machine, probably it won't work, as handles shouldn't be the same in different OS/kernel versions.

So, you should check that ImpRec has the options configured properly to fix all references to the new IAT...

Cheers

Nacho_dj