Bizarre problem resolving imports from KERNEL32
 

hi guys,

i am resolving imports from kernel32, using my own routine (that scan dll export table, in the classical and tested way), but i am getting weird results with some APIs...

for example, when trying to get the address of HeapAlloc, i get a address... but in this address, isnt function code, but a string: NTDLL.HeapAllocate

the same happen with others APIs, like RtlUnwind

anybody know whats happening? i am using xp sp2, and i already coded that dll export scan routine 100 times, and it always worked :confused:

thanks in advance,
ancev

Google keyword: import forwarding. If you know Russian:h++p://wasm.ru/print.php?article=packlast01

Hello ancev:

This happens in NT OS. Their kernel imports some apis' performed by ntdll.dll. This could be fixed in your import table just renaming that string NTDLL.HeapAllocate that you obtained, by HeapAlloc in the function names table.

Do the same with the others api exported by ntdll.dll to kernel32.dll. Just take the name of the api that is compatible to that of Win98 (no NT OS) and voil��!

I hope this helps.


Cheers :cool:

Nacho_dj

BTW: This workaround is not performed by Import Reconstructor, so if used it is giving you the same problem. I have read in some part of the forum that certain patch for this tool is fixing this.

thanks nacho_dj and nskSem,

i am coding a new pe packer(once again), and found this problem packing the own packer´s .exe, compiled with msvc .net 2003

i am kinda ashamed of not knowing this, as i play with pe files at long time: i always thought that import forwarding has to do with the ForwarderChain field in iat dir

as i never found a sample of this (as i used w9x till few time ago), i just thought that the whole dll was forwarded, and that in ForwarderChain field was the dll base address

i think i can resolve this doing something like this:

thanks for the help, guys :)

ancev

That code seems interesting. Could you update here if it was working as you wanted?

I used in a built-in import reconstructor for an unpacker the method I explained before. So, I would like to know if your code is performing fine the task required in your first post.

Thanks and cheers! :cool:

Nacho_dj

Here is an interesting example
 

MASM example of Alternative to GetProcAddress API
http://win.asmcommunity.net/board/index.php?topic=17130.msg133137#msg133137

Also handles export forwarding (Even with Ordinals). :)

nacho_dj,

the code work, but with some small changes... the point is that there´s a "." between dll and apiname that i need turn to 0 (which i forgot in my lil snippet)

and there´s the fact i can write my 0 in kernel mem... so, i need copy the string to a buffer, before do the trick

but, in general lines, my idea work, and i am using it

thanks once again for the help
ancev

ps: thanks for the code, goggles99!

Thanks for the link, goggles99 :)
Sure, I could pick of it some good way to perform the rebuilding of the IAT.

ancev, I think I will try your code, when done I will tell you how it is working.


Thanks! :rolleyes:

Nacho_dj :cool:

go to code-breakers journal site, and read the essay about PE.
There you will find how import tables are built. For maintaining portability across versions, m$ allows redirection of api from a DLL to another, thus freeing from the need to implement all the prior version calls within a module, or making stubs for compatibility issues.