flat assembler
Message board for the users of flat assembler.

flat assembler > Windows > No includes will be missing from now

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
I wrote a small program that creates a correct include file containg API names exported by a given DLL. It means that one won't care about missing includes, he just needs to have this DLL and my program in the system. Unfortuantely I didn't have so much will to create intuitive and nice GUI so the only interaction with user is commandline Smile.

Usage: apiresolve dllname.dll
Example: apiresolve opengl32.dll

In the directory where the program was run, after a second there'll be an dllname.inc (in this case opengl32.inc) file with API names. I coded it so that it omits widechar APIs (these ended with W), but I include a sourcecode so anyone can change it easily. Hope you'll like this little proggie. I wrote it, because needed to write some OGL stuff, and didn't want to create ImportDirectory by hand.

EDIT: New v2.0 release with some enhancements due to requests from board. Support for ANSI names, Unicode names or both at the same time. Rewritten from scratch

EDIT2: New v2.1 can output includes to use with 'format MS COFF' also

EDIT3: Version 2.2. Fixed issue with MS COFF format. It is now like:
Code:
if used ActivateKeyboardLayout
  extrn '__imp__ActivateKeyboardLayout@8' as ActivateKeyboardLayoutdword
end if    


EDIT4: Fixed a bug with MS COFF format (thx flaith, sorry for so long time to fix it.... I just forgot Smile)

EDIT5: Again some new bug was found. This time in PE format include, always the last import was badly output. Fixed in 2.3.1 version

EDIT6: There's a new Length Disassembly Engine version which is the base of ApiResolve engine for COFF format. New ApiResolve is compiled with the current LDE


Description: ApiResolve v2.3.2
Download
Filename: ApiResolve.v2.3.2.zip
Filesize: 21.81 KB
Downloaded: 312 Time(s)



Last edited by Reverend on 23 Oct 2006, 12:29; edited 7 times in total
Post 11 Mar 2005, 22:30
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1046
Location: Michigan, USA
Very nice Reverend!!!! Very Happy This will help a lot Cool ! Amazing you should say opengl, I was in the process of converting the opengl function proto's. Good Work Exclamation Wish you would've posted this a week ago. Rolling Eyes
MadMatt Shocked
Post 12 Mar 2005, 00:12
View user's profile Send private message Reply with quote
Vasilev Vjacheslav



Joined: 11 Aug 2004
Posts: 392
like dll2inc
Post 12 Mar 2005, 07:49
View user's profile Send private message Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
madmatt: hey, thx a lot, I also needed it for opengl Smile
Vasilev Vjacheslav: I don't know dll2inc. Do you mean that such a program existed before? So why there were so many libraries' includes missing?

So for now I think that decard can even remove section with includes from his page, and put there my program as it can create include file for any dll. What do you think?
Post 12 Mar 2005, 12:41
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7310
Location: Kraków, Poland
The imports are not all - there remains the problem with equates. Some kind of H2ASH might be useful, but that would be a bit harder project.
Post 12 Mar 2005, 12:53
View user's profile Send private message Visit poster's website Reply with quote
Vasilev Vjacheslav



Joined: 11 Aug 2004
Posts: 392
Reverend wrote:
Vasilev Vjacheslav: I don't know dll2inc. Do you mean that such a program existed before? So why there were so many libraries' includes missing?


yes, such program existed before, i found two versions: at comrade homepage (he is author) and at wasm.ru page

_________________
[not enough memory]
Post 12 Mar 2005, 15:09
View user's profile Send private message Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Privalov wrote:
The imports are not all - there remains the problem with equates. Some kind of H2ASH might be useful, but that would be a bit harder project.

It'd be a more difficult project, because a parser would have to be written. Not exactly a parser, but the program would have to (just as C/C++ compiler) interpret all equates, structeres, etc. and write them in a fasm way
Post 12 Mar 2005, 15:35
View user's profile Send private message Visit poster's website Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Uploaded new version in the first post
Post 26 Jul 2005, 20:32
View user's profile Send private message Visit poster's website Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
That's one amazing program!

Thanks!
Post 26 Jul 2005, 21:24
View user's profile Send private message Reply with quote
Raedwulf



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

It'd be a more difficult project, because a parser would have to be written. Not exactly a parser, but the program would have to (just as C/C++ compiler) interpret all equates, structeres, etc. and write them in a fasm way


Yes it would be - though one has been done for MASM so its not impossible (h2inc)
Though h2inc does has its problems.......it seems to be unable to convert quite a number of c headers i have Smile
Post 28 Jul 2005, 18:21
View user's profile Send private message MSN Messenger Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1135
Location: Russian Federation
It would also be nice to have a feature to create include files that import in this style:

Code:
extrn '__imp__MessageBoxA@16' as MessageBoxdword
    


This is useful for MS COFF format.
Post 30 Jul 2005, 13:01
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1135
Location: Russian Federation
In your PE.inc, it is recommended you use = for numerical constants (those IMAGE_ ones), instead of equ
Post 30 Jul 2005, 13:04
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7310
Location: Kraków, Poland
This recommendation is no longer true for all cases - if the constant values don't involve calculations and you don't need to forward-reference them, the EQU might actually be better (faster) than =.
Post 30 Jul 2005, 13:23
View user's profile Send private message Visit poster's website Reply with quote
Ancient One



Joined: 28 Feb 2005
Posts: 55
Quote:

This recommendation is no longer true for all cases - if the constant values don't involve calculations and you don't need to forward-reference them, the EQU might actually be better (faster) than =.

this is new info for me. can u explain more?
Post 01 Aug 2005, 01:31
View user's profile Send private message MSN Messenger Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7310
Location: Kraków, Poland
The recommendation to use = for all equations when possible was because the symbol table for EQU constants was much slower in the old implementations. In the newer versions of fasm this was fixed, and EQU might be even actually faster in some cases, as it get fully processed at the preprocessing stage, so assembler doesn't have to chew it in the each pass.
For example:
Code:
ALPHA EQU 1234h
mov eax,ALPHA    

is no worse and might be even better in performance than:
Code:
ALPHA = 1234h
mov eax,ALPHA    

In the first case assembler sees only the
Code:
mov eax,1234h    

line, since this is what it becomes after preprocessing. In the second case assembler sees both the lines and processes "ALPHA" in the same way as it would process the label.
However if you need to forward reference ALPHA label you should use =. Also for the calculated constants like:
Code:
ALPHA = BETA + GAMMA    

it's better not to use EQU, consider this:
Code:
mov eax,ALPHA*4    

If you used
Code:
ALPHA EQU BETA + GAMMA    

you would get
Code:
mov eax,BETA + GAMMA*4    

which is perhaps not what would you want. Well, you could define it like:
Code:
ALPHA EQU BETA+GAMMA    

but also note that if BETA and GAMMA are labels, it will be more suitable for assembler to access the single ALFA label (and BETA and GAMMA only to calculate its value in definition) than to access two labels each time.

So the general conclusion might be: for numerical values you should use =, as it was designed for this purpose, but if the EQU works for your needs in your case, you don't have to change it.


Last edited by Tomasz Grysztar on 01 Aug 2005, 17:25; edited 1 time in total
Post 01 Aug 2005, 08:40
View user's profile Send private message Visit poster's website Reply with quote
Vortex



Joined: 17 Jun 2003
Posts: 334
comrade wrote:
It would also be nice to have a feature to create include files that import in this style:

Code:
extrn '__imp__MessageBoxA@16' as MessageBoxdword
    


This is useful for MS COFF format.


Did you check my MASM to FASM function prototype converter?

http://board.flatassembler.net/topic.php?t=588

_________________
Code it... That's all...
Post 01 Aug 2005, 17:17
View user's profile Send private message Visit poster's website Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
comrade: I started to code MS COFF output, but I'll have to write length disassembler engine first, because now it searches for 0C2h, xxh, xxh or 0C3h. And it works in most cases but sometimes not eg.:
Code:
        mov     eax, 0C3h    
And then it outputs wrongly
Post 02 Aug 2005, 18:57
View user's profile Send private message Visit poster's website Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1135
Location: Russian Federation
Disassembling is an unsure technique to get the number of parameters. You will be able to cover most cases, but never all. FASM has some special 'PCOUNT' includes that have the number of parameters for most Win32 API. However, the most sure way that I see would be to extract information from import libraries (MS .lib)
Post 03 Aug 2005, 01:09
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
In first post there's an updated version which enables an option to output includes for 'format MS COFF'. I made it with my LDE engine, because now the program 'knows' where starts and where ends any opcode, so it can easily find 'retn' opcode.

Even though there are some flaws. For MS COFF it assumes that all exports are stdcall. So the program will work with most of windows libraries corectly, but eg. wsprintf from user32.dll is outputed wrongly. Unfortunately my program reads from binaries, from compiled version and there's no info, whether the function is stdcall or ccall.
Also if the library has some obfuscated code, my LDE engine might get wrong, so the whole output won't be ok. But I guess such situation is nearly impossible to happen Smile

comrade: I don't know why, but I just in the moment saw your answer. I didn't see it before, so I didn't even concern what you were talking about. If I thought about it this way I may never write LDE engine Smile But in whcich cases do you think reading from binary will output wrongly? (instead of stdcall/ccall problem)
Post 13 Aug 2005, 14:45
View user's profile Send private message Visit poster's website Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1135
Location: Russian Federation
DLL functions may have runtime decryption, or a very complex system of jumps where the actual C2 XX XX may be hidden away. You will never be certain with a disassembler, but it is better than nothing Smile so all cool
Post 13 Aug 2005, 15:59
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< 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


Copyright © 1999-2019, Tomasz Grysztar.

Powered by rwasa.