ImpRec module User32.dll overwritting buffer overflow

yeah...used also by Armadillo...

check the attachment,and see the matRiX

tested in WinXP SP1,probablly works in other OS

it is a PoC=proof of concept.So of course easy to bypass in debugger,but if unknown as a trick and inside the packer's code,is harder...

[MaRKuS-DJM]

fixed ImpRec. can't guarantee it works on every OS because fix-code is very lame.

EDIT: updated the file because it didn't work on Windows 98!

[TQN]

Hi MaRKus-DJM !
Intead of posting fixed file, can you explain how do you solve it, and how the Karga EXe crash Imprec. I only saw Karga fill the PE header of User32.dll with 0, and the IAT of Karga's EXE contains invalid RVA address.
Regards,
TQN

[MaRKuS-DJM]

ImportRec needs to read the header of user32.dll. it does this in the target process. but there the header got destroyed. i included a little check when ReadProcessMemory is called to compare
lpBaseAddress Parameter of ReadProcessMemory to ModuleBase of user32.dll.
if the check succeeds, i wrote a small read-function which reads the user32.dll loaded by ImportRec instead of the user32.dll used by the target process. so it gets a valid header and valid values.
regards

btw, the invalid IAT-value isn't the point it crashes. most of the time IAT-entry isn't needed.

[nikola]

Then doesnt this bug exist for all dlls that ImpRec reads when resolving them from program?

[MaRKuS-DJM]

the bug only affects to user32.dll. tried it also with kernel32.dll and there were no problems.

lame tricks used by lame protecter, dose this is an effective way to protect import table?
but this is have some reserch value for us.