No includes will be missing from now

Index > Windows > No includes will be missing from now

Goto page Previous 1, 2

Author

Thread

Reverend

Joined: 24 Aug 2004
Posts: 408
Location: Poland

Reverend 13 Aug 2005, 18:34

I know that my program won't recognize such situations like:

Code:

        jmp     @F

        db      0C3h ; 0C3h = retn opcode btw.
      @@:
        ...
        retn    08h

Correct here would be 8, but my program will recognize it as 0 (as it will find 0C3h first).
But such code as above isn't common - I may even say it doesn't appear in 95% of dlls - so ApiResolve will do just fine. For those 5% left the include file can be built manually, it's always better than doing everything by hand

13 Aug 2005, 18:34

Raedwulf

Joined: 13 Jul 2005
Posts: 375
Location: United Kingdom

Raedwulf 15 Aug 2005, 13:31

If you search the whole function i.e. check in the function address table for the next function address and and subtract it from the currect function address.
Then find all the ret statement within the function and take the highest return value. This will give more accurate results at the slight cost of speed. (most of the time - worked on kernel32 anyway Smile

)

Btw,
However, bewary of the last function Smile

....I put a fixed number so it doesn't check the rest of the dll.

_________________
Raedwulf

15 Aug 2005, 13:31

Reverend

Joined: 24 Aug 2004
Posts: 408
Location: Poland

Reverend 16 Aug 2005, 15:13

Raedwulf: Your idea may be correct, but I guess only in system dlls. Example: I can make such library.

AddressOfFunctions:
FirstFunction = 0
SecondFunction = 100
ThirdFunctions = 50

Then your code will search offsets from 0-100 in the first pass (but in fact the first function is in 0-50). Then it will get negative value as delta Smile

Also when dealing with Microsoft libraries never depend on fixed values Smile

. They change many things even in an ordinary update

16 Aug 2005, 15:13

Raedwulf

Joined: 13 Jul 2005
Posts: 375
Location: United Kingdom

Raedwulf 17 Aug 2005, 06:23

Yeah thats true Smile

....so maybe the best way is preprocess the locations of each of the functions and sort them so that it doesn't have -delta.
This is just a lot of progging though Razz

but it may prove making it a very useful tool.

17 Aug 2005, 06:23

Reverend

Joined: 24 Aug 2004
Posts: 408
Location: Poland

Reverend 27 Dec 2005, 22:38

Added new 2.2 version in edited 1st post.

27 Dec 2005, 22:38

flaith

Joined: 07 Feb 2005
Posts: 122
Location: $300:20 58 FC 60 N 300G => Vietnam

flaith 28 Dec 2005, 08:28

Thx Reverend for your prog, it helps me Very Happy

but ...
here its ok

Code:

if used BroadcastSystemMessage
  extrn '__imp__BroadcastSystemMessage@20' as BroadcastSystemMessage:dword
end if

but here it isn't ok (look what happened to the 'endif' Exclamation

)

Code:

if used BroadcastSystemMessageA
  extrn '__imp__BroadcastSystemMessageA@20' as BroadcastSystemMessageA:dword
:dword ;<-- ???

Code:

if used BroadcastSystemMessage
  extrn '__imp__BroadcastSystemMessage@20' as BroadcastSystemMessage:dword
end if
if used BroadcastSystemMessageA
  extrn '__imp__BroadcastSystemMessageA@20' as BroadcastSystemMessageA:dword
:dword
if used CallMsgFilter
  extrn '__imp__CallMsgFilter@8' as CallMsgFilter:dword
end if
if used CallMsgFilterA
  extrn '__imp__CallMsgFilterA@8' as CallMsgFilterA:dword
:dword

param of the prog :

Quote:

ApiResolve.exe -coff user32.dll

_________________
Je suis sur de 'rien', mais je ne suis pas sur du 'tout'.

28 Dec 2005, 08:28

chris

Joined: 05 Jan 2006
Posts: 62
Location: China->US->China->?

chris 25 Jan 2006, 15:58

Hi, Reverend

thanks for your handy tool which saves me a lot of time building an API import list. One suggestion is that, just as comrade mentioned above, for MS COFF output format, which requires a linker to produce the final execuable(this is usually what we really trying to make), import library files are required at link stage. So why not take the .lib file(those files should be availabe) as input when -coff command switch is activitied? But anyway, disassembling the binary isn't too bad;)

25 Jan 2006, 15:58

Reverend

Joined: 24 Aug 2004
Posts: 408
Location: Poland

Reverend 05 Feb 2006, 19:21

There is ApiResolve v2.3 in the first post. Another bug removed.

flaith: The bug is now fixed. Sorry that you had to wait so long Sad

(over a month sic!). I forgot about this error... At least it's ok now

chris: Maybe getting data from .lib is much more accurate, but I don't have time currently to even read this formats' specification.

05 Feb 2006, 19:21

Reverend

Joined: 24 Aug 2004
Posts: 408
Location: Poland

Reverend 17 Feb 2006, 10:38

New version in edited first post. Fixed another bug.

17 Feb 2006, 10:38

Reverend

Joined: 24 Aug 2004
Posts: 408
Location: Poland

Reverend 23 Oct 2006, 12:31

New version in the first post. Compiled with the new LDE engine

23 Oct 2006, 12:31

CoolCmd

Joined: 27 Dec 2023
Posts: 11

CoolCmd 27 Dec 2023, 11:15

ApiResolve is a bad program for COFF because its algorithm is unreliable by the nature. two examples:

the program generates __imp__VirtualAllocEx@8 for kernel32.dll. the actual import is __imp__VirtualAllocEx@16.
this function uses jmp instruction instead of ret instruction.

the program generates __imp__wsprintfA@0 for user32.dll.
this is CDECL function, it dos not need @number suffix.

27 Dec 2023, 11:15

Goto page Previous 1, 2

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum