Yes, just for fun I am eliminating the IAT, but I have a problem:

extern _imp__VirtualAlloc@16:NEAR
VirtualAlloc EQU FCALL4 PTR _imp__VirtualAlloc@16; make an invokeable form

VirtualAlloc is a public symbol in kernel32.lib, so I get a name conflict

2A718 __imp__VerifyVersionInfoA@16
2A78C _VerifyVersionInfoW@16
2A78C __imp__VerifyVersionInfoW@16
[COLOR=red]2A800 _VirtualAlloc@16[/COLOR]
2A800 __imp__VirtualAlloc@16
2A86E _VirtualAllocEx@20
2A86E __imp__VirtualAllocEx@20
2A8DE _VirtualFree@12

I wonder what Hutch's tool does to the lib and second, could a lib be made/modified so that the __imp__ only was public and still work??

Otherwise, I just have to rename any API I used if I wanted to use a text equate to cover up the FCALL(n) pointer mess. I think I'll rename VirtualAlloc, George......

Thanks for any crazy ideas.
Posted on 2003-01-18 12:10:47 by ThoughtCriminal
Doh!!! just hit me. rem it out in

edit: I am still curious if a lib would work if only the imports were public.
Posted on 2003-01-18 12:12:46 by ThoughtCriminal
Maybe I have not got the swing of the problem but the generated prototype is as follows,

externdef _imp__VirtualAlloc@16:PTR pr4
VirtualAlloc equ <_imp__VirtualAlloc@16>

I gather that if you want to bypass the prototypes and directly call them, you need another mechanism to get the addresses. I have played with manually coding a list of API calls at the beginning of a program with LoadLibrary/GetProcAddress and just calling the addresses which works OK but I am not sure if that will do what you want with the import allocation table.

Posted on 2003-01-18 14:27:43 by hutch--
Thanks Hutch, we are basically doing the same thing, but I am also adding in prototype info for invoke:

LCALL4 TYPEDEF proto :dword,:dword,:dword,:dword

externdef _imp__VirtualAlloc@16:NEAR

VirtualAlloc EQU FCALL4 PTR _imp__VirtualAlloc@16

This works fine. I figured out a solution to my main problem of the name collision.

I'm not sure what you are talking about needing another mechanism to get the address.

lea eax,_imp__VirtualAlloc@16


Both versions make an 0xFF indirect call with no problem. Now if I could just figure out a way to get 0xE8 calls, but thats all done at link time.

Hmmm this will call the adress directly, but with an indirect call:

lea eax,_imp__VirtualAlloc@16
mov eax,[eax]

It is also to much work for to little benefit.
Posted on 2003-01-19 02:53:25 by ThoughtCriminal