PDA

View Full Version : FLIRT issues...

Externalist
October 3rd, 2008, 04:13
Hi,
I'm trying to create a FLIRT signature of a binary that's statically linked with mfc90.dll and msvcr90.dll. I could think of 2 ways to do it. Either create a .pat of the 2 dll files with idb2sig and feed them to sigmake, or find the corresponding .lib files and use pcf then sigmake. I've tried the 1st and here's what I got.

http://i34.tinypic.com/2lx6ujk.jpg

Not bad but would be better if all of them could be resolved. This requires the .lib files of the .dll files which I had in my posession.
So I first started with mfc90.lib included in VS2008 lib directory and fed it to pcf.exe after using link.exe to make it into a static library, but pcf prints an error saying :

Fatal [mfc90.lib] (objr\i386\_alias0.obj): not a coff module

I don't know what that object file is(google doesn't either) and neither can find them anywhere. I found out there were about 500 of those included in the .lib file, but compared to the number of functions imported from mfc90.dll the rate was low so I decided it won't be that much of a big influence and excluded all of them using a simple script and LIB.exe. After that, pcf and sigmake creates a nice .sig file with a total of 6500 signatures and I used it on a simple test MFC dll I made statically linked with mfc90.lib.

And the result... 0 signatures identified.

I'm not sure if I went through the right steps, but I did everything the Manual said. The two vc32rtf.sig & vc32mfc.sig files initially included in the IDA sig directory identifies a statically linked MFC binary most of the time. But I have no clue what procedure was used to build them...
Hence, my question is, is there a way to create properly working sig files from the lib files included in Visual Studio?
reverser
October 3rd, 2008, 07:08
You don't "statically link" to DLLs. mfc90.lib is a DLL import library, not a static lib. There are no real functions in it.
If you're sure it was statically linked, load vc32rtf.sig and vc32mfc.sig manually. If it's dynamic linking, signatures are of no use, as all the library code is in external DLLs and not the exe.
Externalist
October 3rd, 2008, 09:26
Ah, I made a mistake there. :/ statically linked with mfc90.lib and msvcr90.lib. sorry about that.
Maybe I should send an e-mail to hex-rays, or dig a little bit deeper to find out what the real problem is. I just thought there would be a quicker and time efficient way that some people might know. I'll post the details if I ever get to the bottom of this.
naides
October 3rd, 2008, 18:02
From MSDN , get LIB.EXE (may be you already have it as part of VC++2008). Get a list of the functions in the library. Make sure that they are indeed COFF files.
Do a dry run on the MFC42.LIB which I know for a fact produce FLIRT files: The point is to try isolate the problem to the mfc90.lib file or your FLIRT kit.
reverser
October 3rd, 2008, 19:34
Quote:
[Originally Posted by Externalist;77248]Ah, I made a mistake there. :/ statically linked with mfc90.lib and msvcr90.lib. sorry about that.
Maybe I should send an e-mail to hex-rays, or dig a little bit deeper to find out what the real problem is. I just thought there would be a quicker and time efficient way that some people might know. I'll post the details if I ever get to the bottom of this.

Do you mean "statically linked to libcmt.lib and nafxcw.lib" (since those are the static CRT and MFC libraries)? If so, their signatures are already included in IDA (vc32*.sig). Does FLIRT not detect CRT and MFC functions? I see plenty of cyan in your navigation bar.
Externalist
October 3rd, 2008, 23:10
Thanks for the replies!

naides//
The first time I tried to make a sig file with mfc90.lib, I converted it to COFF format with link.exe and fed it directly to pcf, but like I mentioned in the former post, there were a bunch of

objr\i386\_alias0.obj
objr\i386\_alias1.obj
objr\i386\_alias2.obj
...

these files included in the library. MFC42.lib didn't contain any of those so those files seemed to be the main problem. So I just simply excluded those obj files cause there wasn't that many of them compared to the number of functions imported from mfc90.dll. But after making the .sig file and applying it, no signatures was identified. The problem seemed to be lying somewhere else...


reverser//

The reason I can't use vc32*.sig is because the the vc32*.sig files I have are a little outdated, and they only recognize a small portion of the static libraries when I apply them to any statically linked MFC file created with VS2008.
On the other hand, I always thought statically linked mfc apps were linked with mfc90.lib and msvcrt.lib but I guess I was wrong. Thanks for the advice. After converting the the two libcmt.lib and nafxcw.lib files to COFF and using pcf, pcf compalins that it can't process the .lib file cause it contains .obj files.

Code:
Microsoft (R) Library Manager Version 6.00.8168

Copyright (C) Microsoft Corp 1992-1998. All rights reserved.



f:\dd\vctools\crt_bld\SELF_X86\crt\prebuild\build\INTEL\mt_obj\_bintree_.obj

f:\dd\vctools\crt_bld\SELF_X86\crt\prebuild\build\INTEL\mt_obj\_callsite_.obj

f:\dd\vctools\crt_bld\SELF_X86\crt\prebuild\build\INTEL\mt_obj\_chsyheap_.obj

f:\dd\vctools\crt_bld\SELF_X86\crt\prebuild\build\INTEL\mt_obj\_contain_.obj

f:\dd\vctools\crt_bld\SELF_X86\crt\prebuild\build\INTEL\mt_obj\_convert_.obj

f:\dd\vctools\crt_bld\SELF_X86\crt\prebuild\build\INTEL\mt_obj\_error_.obj

f:\dd\vctools\crt_bld\SELF_X86\crt\prebuild\build\INTEL\mt_obj\_fileio_.obj

...

...

...


There are about a thousand of them included in the library, and I can't just simply exclude them like I did with mfc90.lib cause the library is only consisted of obj files. I'm thinking about writing a script that extracts all those .obj files with LIB.exe and processes all of them through plb.exe, then merge them into one .sig file. Is that the right way to go, or am I doing it the hard way?
Thanks.

Edit : I thought the .obj files were OMF files since pcf can't process the .lib file properly, but if I process the .obj files individually, then pcf runs with no problem. This makes things even more confusing...
Externalist
October 5th, 2008, 04:14
Problem solved.
Many thanks to reverser for the tip! I'll post a writeup as soon as I get some free time. Busy with schoolwork, RL and such...
dELTA
October 24th, 2008, 13:53
Any spare time to write down an explanation yet? We are all very curious. Doesn't have to be long, just a few sentences about what the problem was would be great.
Externalist
October 25th, 2008, 09:54
I almost forgot about this thread! Thanks for reminding me deLTA. And long time no see.

Attached is a bash script that takes care of making .pat files out of microsoft's .lib files for statically linked binaries.

Quote:
Usage : ./lib2pat libname
Requirements : lib.exe, pcf.exe, sigmake.exe in the same folder


output should be like this

Quote:
$ ./lib2pat LIBCMT.lib
going through phase 1...
going through phase 2...
number of COFF modules : 593
number of non COFF modules : 40
going through phase 3...
going through phase 4...
See the documentation to learn how to resolve collisitions.
: modules/leaves: 14230075/1140, COLLISIONS: 953
done! check the *.exc file for collisions.


only tested with nafxcw.lib/libcmt.lib(both from VS2008) on cygwin cause those were the only 2 I needed... And sorry for the sloppy scripting! These things are sort of new to me.
Have Phun!
reverser
October 25th, 2008, 17:14
You know you could've just used pcf with the -s switch insteaf of all this listing and extracting...
Externalist
October 25th, 2008, 20:03


You're right... But it wasn't in the manual!
Actually, it was.
Quote:
parselib [-sw or @file] input-file pattern-file

but there was no explanation of that -s switch in the description... I should have gave it a shot though.
I feel dumb now.
Thanks anyways!

Edit : A simple execution of pcf with no arguments led to this

Quote:
-s skip (don't process) non-COFF modules


I must have been blind or something to miss that...
linux_feixue
April 2nd, 2010, 05:13
Quote:
[Originally Posted by Externalist;77491]I almost forgot about this thread! Thanks for reminding me deLTA. And long time no see.

Attached is a bash script that takes care of making .pat files out of microsoft's .lib files for statically linked binaries.



output should be like this



only tested with nafxcw.lib/libcmt.lib(both from VS2008) on cygwin cause those were the only 2 I needed... And sorry for the sloppy scripting! These things are sort of new to me.
Have Phun!

hi,i also experience that problem,my IDA5.2 cant recognize library function of mfc90u.lib,I use the bash you provided for the mfc90u.lib
it seems doesn't work,it returns:

going through phase 1...
going through phase 2...
number of COFF modules : 0
number of non COFF modules : 0
going through phase 3...
going through phase 4...
MFC90U.sig: NO LIBRARY MODULES ARE FOUND!!!
done! check the *.exc file for collisions.

So what should i do next,and did anybody has the sig result for IDA5.2 of mfc90u.lib.
linux_feixue
April 6th, 2010, 02:18
Is there any body still care about this, when i use pcf -s mfc90u.lib,it display the result:
mfc90u.lib: skipped 16220, total 16220 (SKIPPED ALL MODULES!)

what should i do ,and i extract many *.obj,but seems all of are not coff format,
so there none result back.what should i do ?