Small C program PeExpLib2Inc1.exe write function PROTO's from import library to inc-file.
PeExpLib2Inc1.zip
Hi Timo,
I made a test with some lib files as input but so far no output. How exactly do you use it?
PeExpLib2Inc1.exe kernel32.lib > kernel32.inc
Works:
PeExpLib2Inc1.exe \Masm32\lib\Kernel32.lib >Kernel32.inc
Fails:
PeExpLib2Inc1.exe \Masm32\lib\masm32.lib >masm32.inc
Why that?
Maybe masm32.lib isn't import library ?
Right. Excuse my ignorance ;-)
PeLib2Inc.zip with FindFirstFile/FindNextFile mask.
Any better now ?
EDIT fix for silly error.
Hmmm....
PeLib2Inc.exe \masm32\lib\user32.lib works fine
PeLib2Inc.exe \masm32\lib\kernel32.lib has "file open error" (and worked fine with version 1)
Edit: Works like a charm now :)
Quote from: timovjl on December 06, 2013, 08:34:37 PM
PeLib2Inc.zip with FindFirstFile/FindNextFile mask.
Any better now ?
EDIT fix for silly error.
Hi Jochen,
lib2inc can create an include file from a static library :
http://forum.pellesc.de/index.php?topic=701.0
I recommend that too ;D
Quote from: Vortex on December 07, 2013, 05:37:36 PM
lib2inc can create an include file from a static library
Hi Erol & Timo,
I have a n00bish question. I use inc files on a daily basis, and I always appreciated that there are gentlemen like Pelle or Hutch who write them. The question is really: how do they do that?
I know there are tools that convert a DLL into a static lib, and you can grab the number of dword paras from the name tables etc - but what about REAL4 or REAL8 or RECT PTR args? Do you parse a set of C header files to get these subtleties, do you grab it from MSDN online docu, ...? The DLLs certainly don't contain the definition of RECT or WNDCLASSEX, so some manual parsing must take place, but what are the best sources?
Hi Jochen,
Converting the equates and structure definitions from the SDK C\C++ header files is a difficult task. As you mentioned, some manual tweakings are unavoidable. Japheth,ToutEnMasm and Donkey created their own include file set. Creating include files for API function declarations is easier. You need to read the MS COFF import library specification to understand the structure of import libraries. Converting a statement like _MessageBoxA@16 to a sequence of PROTO and DWORD is easy. To be honest, my converter assumes everything as DWORDs.
Quote from: timovjl on December 07, 2013, 06:08:31 PM
I recommend that too ;D
If only Avast allows downloading that file.
Hi Timo,
Are you referring to my lib2inc tool?
Timo,
As an assembly programmer, you should probably know that it's false-positive :
http://virusscan.jotti.org/en/scanresult/17924fd8de471ba282983f41deb6d84ca08e3b36/7768e871004cc7c04dbdb3acffe6ba75b14fc3be
https://www.virustotal.com/tr/file/0f4828389b2e1da84f025828b01834276072a6eba68fc0adccddb56f9275b0e6/analysis/1386439581/
Avast reports the exe as safe so you should be more careful while commenting another coder's work. Think twice before posting here. I hope you got it clearly.
I just inform Avast's heuristics problem, that prevent downloading some file.
BTW: I'm not an assembly programmer.
You can check virustotal's scan report. No any heuristics problem as you mentioned.
Quote from: Vortex on December 07, 2013, 07:12:25 PM
Hi Jochen,
Converting the equates and structure definitions from the SDK C\C++ header files is a difficult task. As you mentioned, some manual tweakings are unavoidable. ...my converter assumes everything as DWORDs.
Thanks, Erol. I've studied some of the C header files in C:\Program Files\Microsoft SDKs\Windows\v7.0A\Include, and they look messy indeed, but for a seasoned C programmer it looks feasible (not for me, though).
As to DWORDs, I guess it would be feasible to load the System32 DLLs, get the address tables and the functions' start addresses, and then check for specific actions linked to arguments, such as
fld [ebp+8] meaning "a REAL4 was passed".
Re Avast: I don't think Timo intended to mark your tool as a potential threat. False positives are a really nasty phenomenon, and it would be really great if one day an institution with a good standing and reputation would sue the AV companies for damaging smaller software companies. As it stands, the AV get better ratings if they find more threats, but nobody downgrades their benchmarks for false positives. It's an unhealthy situation.