Yes, just for fun I am eliminating the IAT, but I have a problem:
VirtualAlloc is a public symbol in kernel32.lib, so I get a name conflict
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.
extern _imp__VirtualAlloc@16:NEAR
VirtualAlloc EQU FCALL4 PTR _imp__VirtualAlloc@16; make an invokeable form
.code
invoke VirtualAlloc,NULL,esi,MEM_COMMIT,PAGE_READWRITE
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.
Doh!!! just hit me. rem it out in kernel32.inc
:stupid:
edit: I am still curious if a lib would work if only the imports were public.
:stupid:
edit: I am still curious if a lib would work if only the imports were public.
Maybe I have not got the swing of the problem but the generated prototype is as follows,
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.
Regards,
hutch@movsd.com
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.
Regards,
hutch@movsd.com
Thanks Hutch, we are basically doing the same thing, but I am also adding in prototype info for invoke:
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.
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:
It is also to much work for to little benefit.
LCALL4 TYPEDEF proto :dword,:dword,:dword,:dword
FCALL4 TYPEDEF PTR LCALL4
externdef _imp__VirtualAlloc@16:NEAR
VirtualAlloc EQU FCALL4 PTR _imp__VirtualAlloc@16
.code
invoke VirtualAlloc,NULL,esi,MEM_COMMIT,PAGE_READWRITE
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
invoke FCALL4 PTR [eax],NULL,esi,MEM_COMMIT,PAGE_READWRITE
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]
invoke LCALL4 PTR eax,NULL,esi,MEM_COMMIT,PAGE_READWRITE
It is also to much work for to little benefit.