Log in

View Full Version : how do I use an apps dll in my own apps


acane
July 5th, 2004, 09:25
Hi

I got an application (which I bought) which uses its own database files to store data. It use a database dll to access the data in the database.
If load the dll in IDA, I can see a class that handles the database management.

My question is, how could I use this class ion my own app to query the database?
If the database exported a function, I could recontruct the function and use LoadLibrary and GetProcAdress to use the function, but can something similar be done for classes?

Thanks

bilbo
July 6th, 2004, 01:22
Quote:
[Originally Posted by acane]Hi
It use a database dll to access the data in the database.
If load the dll in IDA, I can see a class that handles the database management.


That's not clear. A DLL with some code in it always exports functions.
What do you mean for class?

bilbo

acane
July 6th, 2004, 02:33
Quote:
[Originally Posted by bilbo]That's not clear. A DLL with some code in it always exports functions.
What do you mean for class?

bilbo


Well, a dll could either export a function or and entire class.
ie for a function:
int __declspec(dllexport) MyFunc();

To use this function, you would use LoadLibrary to load the DLL , and use GetProcAddress to get access to the exported function.
Or you could include the lib file and the .h file of the dll and use the exported function as you normally would


for a class
class __declspec(dllexport) MyClass
{
public:
MyClass();
~MyClass();
private:
int MyVar;
};

For classes, as far as I know, you have to include the lib and .h files to use the exported class.

My question is , if you are reversing a dll that exports both a function and a class, you could use the exported functions by reconstructing its parameters and using loadlibrary and getprocaddress.

But how would you use the exported class?

Silver
July 6th, 2004, 04:23
As far as I'm aware, you can't. A class is a high level language construct, which is broken down into functions and vtables. It doesn't really exist. If you don't have the definition of the C++ class (ie: the .h), you can't get a compiler to build the code correctly.

bilbo
July 6th, 2004, 06:27
Quote:
a dll could either export a function or an entire class


No, acane, a dll cannot export a class. It can exports pointers to data, but a class - as Silver pointed out - is an abstract object. Look at it as a structure definition: the concept is very similar. Only when you instantiate it, it will be materialized in members and vtables.

Try to look at your DLL export table. Do you find numbers inside it (that is the case of MFC42.DLL, which is written in C++)? Do you find "decorated names"? So you have at hand all the constructors, destructors and methods of your class(es). You must also infere the size and the public members, and you will be able to call your DLL from another application.

Or, maybe, the exports are only DllGetClassObject, DllCanUnloadNow,
DllRegisterServer, and DllUnregisterServer?
If that is the case, we are facing yet another subject. Your DLL is exporting COM interfaces, not classes. The approach must be different.

Regards, bilbo

acane
July 6th, 2004, 08:59
I understand.
If I manage to construct a .h file, would'n i still need a .lib file then? How would I get that?

I've search around and I can't seem to find a tutorial that deals with this.
I'll create my own dll and reverse it to see if its some way possible

Lord8Bit
July 6th, 2004, 11:20
[QUOTE acane]

If I manage to construct a .h file, would'n i still need a .lib file then? How would I get that?

[/QUOTE acane]

If your .h file is correct, you just need the nifty little tool called DLL2LIB. Search Google, and you will find it easy.

Best Regards
LordByte

_Servil_
July 6th, 2004, 11:39
you need to know exact class declaration otherwise you are out of lock
(compile fake dll with that class declaerateion and use generated importlib in this case)

bilbo
July 6th, 2004, 11:59
Lord8Bit:
Quote:
you just need the nifty little tool called DLL2LIB

dynamic to static converter? it sounds interesting!

I would anyway maintain the original DLL, building by hand the .LIB:
step a) build a TARGETDLL.DEF file
Code:
EXPORTS
exported_function_1
exported_function_2
...


step b) lib /def:targetdll.def
where lib is Microsoft's LIB.EXE

_Servil_:
Quote:
you need to know exact class declaration otherwise you are out of lock


In fact, I tried with a dummy definition such as

Code:
class c {
char dummy[2000];
public:
c(); // constructor to be imported
~c(); // destructor to be imported
...methods to be imported...
};


and it worked!

Regards, bilbo

Silver
July 6th, 2004, 12:35
Bilbo, it did? What happens if you reorder it (not renaming vars, just reordering the definition):

Code:
class c {
public:
c(); // constructor to be imported
~c(); // destructor to be imported
...methods to be imported...
private:
char dummy[2000];
};


I was under the impression that what I've typed is "different" when compiled to what you've typed, not least because now you can't access dummy via a pointer to an instance of class c (whereas you could before, as it was the first member it would be at that address, but now we have an unknown number of function pointers in front of it).

Ok, that was explained badly, but hope it got the point across. If bilbo is right, then it's easy. If I'm right, then it's a hell of a lot harder.

Incidentally that DLL2LIB tool is great, I've used it before.

TQN
July 6th, 2004, 23:06
Hi Silver !
We can use a class exported in a DLL. I have tried and successed.
First, we use dumpbin to create a def file for DLL (dumpbin.exe /exports theDll.dll). Don't change the name mangling of functions and class define.
Then we build the import lib with lib.exe.
After, we use undname.exe or new depends.exe to view the unname mangling of class members, copy to the new .h file, and place a __declspec(dllimport) to the class define.
Ex: class __declspec(dllimport) Cxxx {
Hope my information will help you.
Regards
TQN

acane
July 7th, 2004, 02:22
Thanks
That DLL2Lib tool is excellent. Makes you wonder. Someone could add all the security in the world to their main app but if there core logic is in a dll, someone could write their own GUI and use the DLL's

Anyway, I'm gonna take a look at the DLL2lib tool in depth and there do the tutorials on adding extra menu functions to the app

bilbo
July 7th, 2004, 03:29
Silver:
Quote:
What happens if you reorder it

Again, a class is just an extension of a structure. The functions (object methods) are not included in the class definition, but are compiled as external code. So the order in class member definitions is irrelevant.
Try to compile this snippet:
Code:

#include <iostream>
using namespace std;

class c0 {
public:
c0(); // constructor to be imported
~c0(); // destructor to be imported
//...methods to be imported...
private:
char dummy[2000];
};

class c1 {
private:
char dummy[2000];
public:
c1(); // constructor to be imported
~c1(); // destructor to be imported
//...methods to be imported...
};

void
main(void)
{
cout << sizeof(c0) << "," << sizeof(c1) << endl;
}

Both c0 and c1 will have a size of 2000 bytes!

TQN
Quote:
We can use a class exported in a DLL. I have tried and successed.

Not exactly. Try to compile this:
Code:

/* bilbo 6jul04 - compile as cl -W3 -GX -LD try.cpp */

#include <iostream>
using namespace std;

class
__declspec(dllexport)
c {
private:
public:
int m_i;
c();
void prt(void);
};

c::c()
{
m_i = 777;
}

void
c:rt(void)
{
cout << m_i << endl;
}

You are feeling all the class is being exported, isn't it? But look at the exports of your resulting DLL: They are three:
Code:

??0c@@QAE@XZ __thiscall c::c(void)
??4c@@QAEAAV0@ABV0@@Z class c & __thiscall c:perator=(class c const &
?prt@c@@QAEXXZ void __thiscall c:rt(void)


Only the functions were exported. The concept of class has gone away: no space for member m_i. (Incidentally, an assignment function was inferred by the compiler, the second one).

Quote:
place a __declspec(dllimport) to the class define.

__declspec(dllimport) is not needed in the calling program. Try this:
Code:

#pragma comment(lib, "trydll"

class c {
char dummy[2000];
public:
c();
void prt(void);
};

void
main(void)
{
c cc;
cc.prt();
}


In both cases (with or without __declspec(dllimport)) the two functions related to class c (the constructor and the method prt()) will be placed in the IMPORTS section of the executable.

acane
Quote:
That DLL2Lib tool is excellent.

Yup, not so bad. But you need some knowledge of the DLL to use it from your application, exactly as in the case you do not use DLL2LIB.

Regards, bilbo

Silver
July 7th, 2004, 05:37
Bilbo you misunderstood, probably because I explained it really badly.

Quote:
Again, a class is just an extension of a structure. The functions (object methods) are not included in the class definition, but are compiled as external code. So the order in class member definitions is irrelevant.


Here:

TEST.CPP:

Code:
#include "dumped.h"
#include "original.h"

CDumped cDumpInstance;
COriginal COriginalInstance;

int main(int argc, char* argv[])
{
void* pPointer = &cDumpInstance.var1;
cout << "DumpInstance var1 addr: " << pPointer << endl;
pPointer = &cDumpInstance.var2;
cout << "DumpInstance var2 addr: " << pPointer << endl;

pPointer = &COriginalInstance.var1;
cout << "OriginalInstance var1 addr: " << pPointer << endl;
pPointer = &COriginalInstance.var2;
cout << "OriginalInstance var2 addr: " << pPointer << endl;

return 0;
}


ORIGINAL.H
Code:
class COriginal
{
public:

int var1;
int var2;

COriginal();
virtual ~COriginal();

};

DUMPED.H

Code:
class CDumped
{
public:

int var2;
int var1; // Note different order

CDumped();
virtual ~CDumped();

};


Output is:

Code:
DumpInstance var1 addr: 0x0042E180
DumpInstance var2 addr: 0x0042E17C
OriginalInstance var1 addr: 0x0042E16C
OriginalInstance var2 addr: 0x0042E170


Note the order/position in mem of the class vars, simply because of the order they are declared in the class definition.

Quote:
Both c0 and c1 will have a size of 2000 bytes!


You're right, they will, but do what I did and view the structure in mem and they will be different.

That was kinda my point - I didn't know whether var ordering made a difference when trying to reconstruct a .h from a DLL.

I might suck at swimming, but I know C++

bilbo
July 7th, 2004, 08:16
Sorry Silver if I looked too hard to you, but what I wanted to say is that the order of the class members is not relevant as far as they are not used by the application. This is surely true:

(a) if the member is an object method (function): it will be used by the application but it does not appear inside the class definition.
So the classes c0 - see above in this thread - (with dummy[] defined after methods) and c1 (with dummy[] defined before) are equivalent

(b) if the members are private: the application cannot touch them, so it has no need to bother with their position.

But if the members are public and the application wants/needs to access them, you are right: the position inside the class storage is of capital importance. For example, in MFC, we must know the position of CWinApp.m_lpCmdLine to access it!

As an initial step, in order to quickly build an application which loads the DLL, I thought to coalesce all the class members in some storage - possibly oversized - named char dummy[2000]. But more steps are required as far as the reversing process goes on...

Quote:
I might suck at cracking, but I know C++

cracking? do not speak so loud, JMI can hear you!
C++? surely you know it better than me: I hate it, mostly when I have to use it for work!

Best regards, bilbo

Silver
July 7th, 2004, 09:59
Cracking? Who said cracking?