Up to: Mika Raento's Symbian Programming pages

Reverse engineering LIBs

Sometimes it happens that there's this feature that you just have to have, but it's not public: there are no headers. Then you realize that most of this information is available in the LIB files!. Here's a brief description of how to get to that info and what to with it (you'll need the dumpbin that comes with Visual C++ 6.0 for this).

Getting declarations from LIB files

If you run dumpbin /all LIBFILE you get a lot of output. Looking at the lines beginning with 'Symbol name', you find the actual exported symbols including the demangled names, like this (from BTENG.LIB):

Symbol name  : ?SetPowerStateL@CBTMCMSettings@@QAEHHH@Z (
public: int __thiscall CBTMCMSettings::SetPowerStateL(int,int))

(wrapped for legibility). The demangled name is in parenthesis. It seems now that there is a class CBTMCMSettings with a method SetPowerStateL which has parameters int, int. Not that difficult (of course we don't know what the parameters mean, not yet at least).

You could manually retrieve all the symbols from the dumpbin output, but that's kind of tedious. So I wrote a script: lib_to_h.pl that does that. Just run:

dumpbin /all LIBFILE > DUMPFILE
perl lib_to_h.pl DUMPFILE

and you get a new .h (named DUMPFILE=~s/\./_/ ".h") file with all the exported symbols neatly put into class declarations, like this:

#ifndef BTENG_DUMP_H_INCLUDED
#define BTENG_DUMP_H_INCLUDED 1
class CBTMCMSettings;
...

class CBTMCMSettings {
public:
	...
	IMPORT_C int  SetPowerStateL(int, int);
	...
};

(with of course all the other methods and classes as well). Now you just add the needed #includes, add a few enums and mixin-class declarations and off you go.

Probably the easiest way to get the header to work is to remove anything you are not interested in, so that you don't have to fix the declarations those methods/classes rely on.

One library this works particularly well for is PROFILEENGINE.LIB, as that's the only way to get all the settings for the current profile (ringing volume, vibration etc.).

Limitations

Of course there are a lot of things limitations:

• This only really works with C-classes, since they have a method (NewL) for constructing the object. It won't work for e.g. R classes since you they are allocated on the statically and you need to know their size (you could try playing around with a memory buffer and placement new, but I don't know if it would work.
• You don't know the parameter names (meanings), or default parameter (values). Sometimes these are easy to guess, sometimes not. You might see code somewhere that uses those, ask somebody, find old documentation or just try them on a device. Note that TBool is a typedef for an int, so many int parameters may actually be booleans.
• You can't use any things that need callbacks, if you don't have a header for the callback interface, since M don't generate any symbols in a LIB.
• You can't call inherited methods (unless you can guess the inheritance chain)

(BTW: to switch the bluetooth power, use SetPowerStateL(ETrue/EFalse, EFalse)

Mika Raento, mikie(at)iki.fi