Log in

View Full Version : Maybe a bug...


j_petrucci
December 28th, 2003, 16:49
Hi!

Recently I had to work on a program invoking some functions from MFC42.dll library: OllyDbg correctly displays names from functions imported from USER32,MSVCRT, but MCF42 are reference with <jmp MFC42#{some number}>. So I can't set breakpoints on these functions! Maybe OllyDbg hasn't them in its library or maybe am I doing wrong?
Anyway, IDA PRO 4.5 correctly import them after loading FLIRT signature for Visual C.

thanks in advance!
bye

focht
December 29th, 2003, 03:34
Greetings,

what you are seeing is correct behavior.
Dump the export table of MFC42.DLL: 6000+ exports by ordinal.

Why?

You have faster load time associated with importing and exporting by ordinal.
Addionally, when exporting an API by ordinal, the linker does not need to store the exported API name in the exporting DLL.
This means a smaller export section, and potentially a smaller binary with less data to demand page in.
(to eliminate the API name, use the NONAME modifier when exporting by ordinal in linker .DEF file)

Getting the exported names for MFC isnt that hard - but for the correct version.
If you have installed VC++ (6.0) you got MFC sources, MFC42.DEF file with 6000+ exports by ordinals, exports by names, .PDB debug info files.
But beware: DLL hell is near, because there are different MFC42.DLL versions out, which export a different number of functions (thats why some people get the dreaded "ordinal #xxx not found in MFC42.DLL".

Ok, i would like to see (de)mangeled C/C++ names in ollydbg too but this is beyond the context of (current) ollydbg.
You already said it: IDA correctly imports AFTER LOADING FLIRT signature for MS runtime.
To implement such behavior, speak: translate ordinals to names, ollydbg needs a compiler/runtime signature database too.

Regards,

A. Focht

j_petrucci
December 30th, 2003, 03:24
Hi Focht!

many many thanks for the very clear explanation! (you're a pretty ASM expert, huh!? )
In fact, after better looking at what IDA did, I realized this thing, and now I understand that from you, also. So, this is not a bug.

So...have nice holidays, and an Happy New Year!

bye
*guido*

PS: wasn't the 1.10 OllyDbg version planned for December by Olly !? ;p

Lord_Looser
May 12th, 2004, 05:18
It's much easier if you use import libraries in OllyDbg.
open menu - Debug - Select import libraries - Add - select MFC42.LIB

example:
Names in mfc42
Address Section Type (Known) Name Comment
6C2A14C7 .text Export #1000_CSimpleList::AddHead

focht
May 12th, 2004, 09:05
Hi,

yes it is - but you have own the import lib that _exactly_ matches the mfc version used.
For instance there exist several flavours of mfc42.dll (different version numbers/exprts, ansi versions, unicode versions, debug versions, localized versions...)

Though one could try to get MS Visual Studio and use the redist import libs that came with it or download Platform SDK...

But if the target app is late binding to unknown/custom version of MFC you're ****.

Easier would be IDAs approach of creating (FLIRT) signatures for all the MS runtime flavours (CRT, MFC, ...), which can be distributed freely and are _small_ of size (if i remember correctly those implibs can have some megabytes in size ...).

Regards

A. Focht