Related
I created a wrapper DLL using a DEF file for describing its EXPORTS.
From the original DLL's exports (generated using dumpbin):
EXPORTS
??0FooBar##QAE#ABV0##Z #1
From the created DEF file for my wrapper DLL:
EXPORTS
??0FooBar##QAE#ABV0##Z=__E__0__ #1
When checking the resulting wrapper DLL using OllyDbg, I can see that the export actually gets changed towards:
Names in FooBarDLL, item 0
Address=0F085685
Section=.text
Type=Export
Name=??0FooBar
As you see, it is missing that additional garbledegock (##QAE#ABV0##Z) usually generated by Microsoft Visual C++ for this type of a class/function/parameter combination.
To make sure that this is not a user error on the usage of OllyDbg, I checked the original DLL's exports as well and to no surprise those looked just like the stuff I was expecting:
Names in FooBarDLLOriginal, item 1
Address=1003A800
Section=.text
Type=Export
Name=??0FooBar##QAE#ABV0##Z
As I need my wrapper DLL to look exactly like the original DLL, this result is obviously no good.
How can I prevent Visual C++ from ignoring fragments of my DEF exports definitions?
I have tried to play with many compiler and linker options but utterly failed in getting any closer to my goal.
I finally got it working.
As Hans Passant noted, the linker somehow does handle #-signs within export definitions in a way that I found hard to grasp...
My observations:
Mangled C++ function (??0FooBar##QAE#ABV0##Z) forwarded to an unmangled (extern "C") function (__E__0__)
=> C++ function mangling gets cropped at the first #-sign (??0FooBar)
Mangled C++ function (??0FooBar##QAE#ABV0##Z) forwarded to a mangled (extern "C" __declspec(dllexport)) function (___E__0__#4)
=> C++ function mangling stays intact
This would be my initial test-case, now being close enough to my initial goal.
From the DEF file of the wrapper:
EXPORTS
??0FooBar##QAE#ABV0##Z=___E__0__#4 #1
From the wrapper DLL's exports (generated using dumpbin):
ordinal hint RVA name
1 0 00001000 ??0FooBar##QAE#ABV0##Z = ___E__0__#4
2 1 00001000 ___E__0__#4 = ___E__0__#4
What really astonished me is that the export from ordinal 1 remains invisible when using OllyDbg to read the exports table. Still, when loading the DLL (LoadLibrary) and resolving the address of that function using GetProcAddress(hDLL, "??0FooBar##QAE#ABV0##Z"), things work just fine.
So I now have a DLL that wraps the original one, using a functionally identical exports table. It now shows an additional export of my proxy implementation, but that is no problem for my purposes. That way it is possible to create a proxy DLL that intercepts and, if needed, enhances the original implementation even when C++ mangling is involved. I somehow feel that I overcomplicated things a little but hey, it works.
For functions that I entirely pass through, I simply create a forwarding export in my DEF file, looking like this:
??BarFoo#WhoCares###Z = OriginalDllName.??BarFoo#WhoCares###Z
This question (and others like it) relate to creating proxy DLLs automatically using the Code Project WRAPPIT tool. The solution using the observation from Till, is to:
Always declare the wrapper function to be __stdcall so that it gets decorated with a leading _ and trailing #0, and then use that in the .def file so that the original function decoration (if any) is preserved.
(When/if you replace the wrapper with a real function, you need to remember to change the call convention from __stdcall to the one needed, as well as remove __declspec(naked), add argument declarations, change or remove the .def file declaration to match etc.)
Wrapper .cpp snipet:
// _OriginalFunction#12
extern "C" __declspec(naked) void __stdcall __E__0__()
{
__asm
{
jmp p[0*4];
}
}
.def file:
EXPORTS
_OriginalFunction#12=___E__0__#0 #1
etc.
I modified my version of the WRAPPIT tool to do this automatically:
165c165
< fprintf(fdef,"%s=%s #%u\r\n",v[i].en,v[i].in,v[i].o);
---
> fprintf(fdef,"%s=_%s#0 #%u\r\n",v[i].en,v[i].in,v[i].o);
167c167
< fprintf(fdef,"%s=%s #%u NONAME\r\n",v[i].en,v[i].in,v[i].o);
---
> fprintf(fdef,"%s=_%s#0 #%u NONAME\r\n",v[i].en,v[i].in,v[i].o);
225c225
< fprintf(fcpp,"// %s\r\nextern \"C\" __declspec(naked) void %s %s()\r\n",v[i].en,argv[3],v[i].in);
---
> fprintf(fcpp,"// %s\r\nextern \"C\" __declspec(naked) void %s %s()\r\n",v[i].en,"__stdcall",v[i].in);
I created a wrapper DLL using a DEF file for describing its EXPORTS.
From the original DLL's exports (generated using dumpbin):
EXPORTS
??0FooBar##QAE#ABV0##Z #1
From the created DEF file for my wrapper DLL:
EXPORTS
??0FooBar##QAE#ABV0##Z=__E__0__ #1
When checking the resulting wrapper DLL using OllyDbg, I can see that the export actually gets changed towards:
Names in FooBarDLL, item 0
Address=0F085685
Section=.text
Type=Export
Name=??0FooBar
As you see, it is missing that additional garbledegock (##QAE#ABV0##Z) usually generated by Microsoft Visual C++ for this type of a class/function/parameter combination.
To make sure that this is not a user error on the usage of OllyDbg, I checked the original DLL's exports as well and to no surprise those looked just like the stuff I was expecting:
Names in FooBarDLLOriginal, item 1
Address=1003A800
Section=.text
Type=Export
Name=??0FooBar##QAE#ABV0##Z
As I need my wrapper DLL to look exactly like the original DLL, this result is obviously no good.
How can I prevent Visual C++ from ignoring fragments of my DEF exports definitions?
I have tried to play with many compiler and linker options but utterly failed in getting any closer to my goal.
I finally got it working.
As Hans Passant noted, the linker somehow does handle #-signs within export definitions in a way that I found hard to grasp...
My observations:
Mangled C++ function (??0FooBar##QAE#ABV0##Z) forwarded to an unmangled (extern "C") function (__E__0__)
=> C++ function mangling gets cropped at the first #-sign (??0FooBar)
Mangled C++ function (??0FooBar##QAE#ABV0##Z) forwarded to a mangled (extern "C" __declspec(dllexport)) function (___E__0__#4)
=> C++ function mangling stays intact
This would be my initial test-case, now being close enough to my initial goal.
From the DEF file of the wrapper:
EXPORTS
??0FooBar##QAE#ABV0##Z=___E__0__#4 #1
From the wrapper DLL's exports (generated using dumpbin):
ordinal hint RVA name
1 0 00001000 ??0FooBar##QAE#ABV0##Z = ___E__0__#4
2 1 00001000 ___E__0__#4 = ___E__0__#4
What really astonished me is that the export from ordinal 1 remains invisible when using OllyDbg to read the exports table. Still, when loading the DLL (LoadLibrary) and resolving the address of that function using GetProcAddress(hDLL, "??0FooBar##QAE#ABV0##Z"), things work just fine.
So I now have a DLL that wraps the original one, using a functionally identical exports table. It now shows an additional export of my proxy implementation, but that is no problem for my purposes. That way it is possible to create a proxy DLL that intercepts and, if needed, enhances the original implementation even when C++ mangling is involved. I somehow feel that I overcomplicated things a little but hey, it works.
For functions that I entirely pass through, I simply create a forwarding export in my DEF file, looking like this:
??BarFoo#WhoCares###Z = OriginalDllName.??BarFoo#WhoCares###Z
This question (and others like it) relate to creating proxy DLLs automatically using the Code Project WRAPPIT tool. The solution using the observation from Till, is to:
Always declare the wrapper function to be __stdcall so that it gets decorated with a leading _ and trailing #0, and then use that in the .def file so that the original function decoration (if any) is preserved.
(When/if you replace the wrapper with a real function, you need to remember to change the call convention from __stdcall to the one needed, as well as remove __declspec(naked), add argument declarations, change or remove the .def file declaration to match etc.)
Wrapper .cpp snipet:
// _OriginalFunction#12
extern "C" __declspec(naked) void __stdcall __E__0__()
{
__asm
{
jmp p[0*4];
}
}
.def file:
EXPORTS
_OriginalFunction#12=___E__0__#0 #1
etc.
I modified my version of the WRAPPIT tool to do this automatically:
165c165
< fprintf(fdef,"%s=%s #%u\r\n",v[i].en,v[i].in,v[i].o);
---
> fprintf(fdef,"%s=_%s#0 #%u\r\n",v[i].en,v[i].in,v[i].o);
167c167
< fprintf(fdef,"%s=%s #%u NONAME\r\n",v[i].en,v[i].in,v[i].o);
---
> fprintf(fdef,"%s=_%s#0 #%u NONAME\r\n",v[i].en,v[i].in,v[i].o);
225c225
< fprintf(fcpp,"// %s\r\nextern \"C\" __declspec(naked) void %s %s()\r\n",v[i].en,argv[3],v[i].in);
---
> fprintf(fcpp,"// %s\r\nextern \"C\" __declspec(naked) void %s %s()\r\n",v[i].en,"__stdcall",v[i].in);
if kernel32.dll is guaranteed to loaded into a process virtual memory,why couldn't i call function such as Sleep without including windows.h?
the below is an excerpt quoting from vividmachine.com
5. So, what about windows? How do I find the addresses of my needed DLL functions? Don't these addresses change with every service pack upgrade?
There are multitudes of ways to find the addresses of the functions that you need to use in your shellcode. There are two methods for addressing functions; you can find the desired function at runtime or use hard coded addresses. This tutorial will mostly discuss the hard coded method. The only DLL that is guaranteed to be mapped into the shellcode's address space is kernel32.dll. This DLL will hold LoadLibrary and GetProcAddress, the two functions needed to obtain any functions address that can be mapped into the exploits process space. There is a problem with this method though, the address offsets will change with every new release of Windows (service packs, patches etc.). So, if you use this method your shellcode will ONLY work for a specific version of Windows. Further dynamic addressing will be referenced at the end of the paper in the Further Reading section.
The article you quoted focuses on getting the address of the function. You still need the function prototype of the function (which doesn't change across versions), in order to generate the code for calling the function - with appropriate handling of input and output arguments, register values, and stack.
The windows.h header provides the function prototype that you wish to call to the C/C++ compiler, so that the code for calling the function (the passing of arguments via register or stack, and getting the function's return value) can be generated.
After knowing the function prototype by reading windows.h, a skillful assembly programmer may also be able to write the assembly code to call the Sleep function. Together with the function's address, these are all you need to make the function call.
With some black magic you can ;). there have been many custom implementations of GetProcAddress, which would allow you to get away with not needing windows.h, this however isn't be all and end all and could probably end up with problems due to internal windows changes. Another method is using toolhlp to enumerate the modules in the process to get kernel.dll's base, then spelunks its PE for the EAT and grab the address of GetProcAddress. from there you just need function pointer prototypes to call the addresses correctly(and any structure defs needed), which isn't too hard meerly labour intensive(if you have many functions), infact under windows xp this is required to disable DEP due to service pack differencing, ofc you need windows.h as a reference to get this, you just don't need to include it.
You'd still need to declare the function in order to call it, and you'd need to link with kernel32.lib. The header file isn't anything magic, it's basically just a lot of function declarations.
I can do it with 1 line of assembly and then some helper functions to walk the PEB
file by hard coding the correct offsets to different members.
You'll have to start here:
static void*
JMIM_ASM_GetBaseAddr_PEB_x64()
{
void* base_address = 0;
unsigned long long var_out = 0;
__asm__(
" movq %%gs:0x60, %[sym_out] ; \n\t"
:[sym_out] "=r" (var_out) //:OUTPUTS
);
//: printf("[var_out]:%d\n", (int)var_out);
base_address=(void*)var_out;
return( base_address );
}
Then use windbg on an executable file to inspect the data structures on your machine.
A lot of the values you'll be needing are hard to find and only really documented by random hackers. You'll find yourself on a lot of malware writing sites digging for answers.
dt nt!_PEB -r #$peb
Was pretty useful in windbg to get information on the PEB file.
There is a full working implementation of this in my game engine.
Just look in: /DEP/PEB2020 for the code.
https://github.com/KanjiCoder/AAC2020
I don't include <windows.h> in my game engine. Yet I use "GetProcAddress"
and "LoadLibraryA". Might be in-advisable to do this. But my thought was the more
moving parts, the more that can go wrong. So figured I'd take the "#define WIN32_LEAN_AND_MEAN" to it's absurd conclusion and not include <windows.h> at all.
I would like to call a method from an dll, but i don't have the source neither the header file. I tried to use the dumpbin /exports to see the name of the method, but i can found the methods signature?
Is there any way to call this method?
Thanks,
If the function is a C++ one, you may be able to derive the function signature from the mangled name. Dependency Walker is one tool that will do this for you. However, if the DLL was created with C linkage (Dependency Walker will tell you this), then you are out of luck.
The C++ language does not know anything about dlls.
Is this on Windows? One way would be to:
open the dll up in depends.exe shipped with (Visual Studio)
verify the signature of the function you want to call
use LoadLibrary() to get load this dll (be careful about the path)
use GetProcAddress() to get a pointer to the function you want to call
use this pointer-to-function to make a call with valid arguments
use FreeLibrary() to release the handle
BTW: This method is also commonly referred to as runtime dynamic linking as opposed to compile-time dynamic linking where you compile your sources with the associated lib file.
There exists some similar mechanism for *nixes with dlopen, but my memory starts to fail after that. Something called objdump or nm should get you started with inspecting the function(s).
As you have found, the exports list in a DLL only stores names, not signatures. If your DLL exports C functions, you will probably have to disassemble and reverse engineer the functions to determine method signatures. However, C++ encodes the method signature in the export name. This process of combining the method name and signature is called "name mangling". This Stackoverflow question has a reference for determining the method signature from the mangled export name.
Try the free "Dependency Walker" (a.k.a. "depends") utility. The "Undecorate C++ Functions" option should determine the signature of a C++ method.
It is possible to figure out a C function signature by analysing beginnig of its disassembly. The function arguments will be on the stack and the function will do some "pops" to read them in reverse order. You will not find the argument names, but you should be able to find out their number and the types. Things may get more difficult with return value - it may be via 'eax' register or via a special pointer passed to the function as the last pseudo-argument (on the top of the stack).
If you indeed know or strongly suspect the function is there, you can dynamically load the DLL with loadLibrary and get a pointer to the function with getProcAddress. See MSDN
Note that this is a manual, dynamic way to load the library; you'll still have to know the correct function signature to map to the function pointer in order to use it. AFAIK there is no way to use the dll in a load-time capability and use the functions without a header file.
Calling non-external functions is a great way to have your program break whenever the 3rd party DLL is updated.
That said, the undname utility may also be helpful.
Sooooo I'm writing a script interpreter. And basically, I want some classes and functions stored in a DLL, but I want the DLL to look for functions within the programs that are linking to it, like,
program dll
----------------------------------------------------
send code to dll-----> parse code
|
v
code contains a function,
that isn't contained in the DLL
|
list of functions in <------/
program
|
v
corresponding function,
user-defined in the
program--process the
passed argument here
|
\--------------> return value sent back
to the parsing function
I was wondering basically, how do I compile a DLL with gcc? Well, I'm using a windows port of gcc. Once I compile a .dll containing my classes and functions, how do I link to it with my program? How do I use the classes and functions in the DLL? Can the DLL call functions from the program linking to it? If I make a class { ... } object; in the DLL, then when the DLL is loaded by the program, will object be available to the program? Thanks in advance, I really need to know how to work with DLLs in C++ before I can continue with this project.
"Can you add more detail as to why you want the DLL to call functions in the main program?"
I thought the diagram sort of explained it... the program using the DLL passes a piece of code to the DLL, which parses the code, and if function calls are found in said code then corresponding functions within the DLL are called... for example, if I passed "a = sqrt(100)" then the DLL parser function would find the function call to sqrt(), and within the DLL would be a corresponding sqrt() function which would calculate the square root of the argument passed to it, and then it would take the return value from that function and put it into variable a... just like any other program, but if a corresponding handler for the sqrt() function isn't found within the DLL (there would be a list of natively supported functions) then it would call a similar function which would reside within the program using the DLL to see if there are any user-defined functions by that name.
So, say you loaded the DLL into the program giving your program the ability to interpret scripts of this particular language, the program could call the DLLs to process single lines of code or hand it filenames of scripts to process... but if you want to add a command into the script which suits the purpose of your program, you could say set a boolean value in the DLL telling it that you are adding functions to its language and then create a function in your code which would list the functions you are adding (the DLL would call it with the name of the function it wants, if that function is a user-defined one contained within your code, the function would call the corresponding function with the argument passed to it by the DLL, the return the return value of the user-defined function back to the DLL, and if it didn't exist, it would return an error code or NULL or something). I'm starting to see that I'll have to find another way around this to make the function calls go one way only
This link explains how to do it in a basic way.
In a big picture view, when you make a dll, you are making a library which is loaded at runtime. It contains a number of symbols which are exported. These symbols are typically references to methods or functions, plus compiler/linker goo.
When you normally build a static library, there is a minimum of goo and the linker pulls in the code it needs and repackages it for you in your executable.
In a dll, you actually get two end products (three really- just wait): a dll and a stub library. The stub is a static library that looks exactly like your regular static library, except that instead of executing your code, each stub is typically a jump instruction to a common routine. The common routine loads your dll, gets the address of the routine that you want to call, then patches up the original jump instruction to go there so when you call it again, you end up in your dll.
The third end product is usually a header file that tells you all about the data types in your library.
So your steps are: create your headers and code, build a dll, build a stub library from the headers/code/some list of exported functions. End code will link to the stub library which will load up the dll and fix up the jump table.
Compiler/linker goo includes things like making sure the runtime libraries are where they're needed, making sure that static constructors are executed, making sure that static destructors are registered for later execution, etc, etc, etc.
Now as to your main problem: how do I write extensible code in a dll? There are a number of possible ways - a typical way is to define a pure abstract class (aka interface) that defines a behavior and either pass that in to a processing routine or to create a routine for registering interfaces to do work, then the processing routine asks the registrar for an object to handle a piece of work for it.
On the detail of what you plan to solve, perhaps you should look at an extendible parser like lua instead of building your own.
To your more specific focus.
A DLL is (typically?) meant to be complete in and of itself, or explicitly know what other libraries to use to complete itself.
What I mean by that is, you cannot have a method implicitly provided by the calling application to complete the DLLs functionality.
You could however make part of your API the provision of methods from a calling app, thus making the DLL fully contained and the passing of knowledge explicit.
How do I use the classes and functions in the DLL?
Include the headers in your code, when the module (exe or another dll) is linked the dlls are checked for completness.
Can the DLL call functions from the program linking to it?
Yes, but it has to be told about them at run time.
If I make a class { ... } object; in the DLL, then when the DLL is loaded by the program, will object be available to the program?
Yes it will be available, however there are some restrictions you need to be aware about. Such as in the area of memory management it is important to either:
Link all modules sharing memory with the same memory management dll (typically c runtime)
Ensure that the memory is allocated and dealloccated only in the same module.
allocate on the stack
Examples!
Here is a basic idea of passing functions to the dll, however in your case may not be most helpfull as you need to know up front what other functions you want provided.
// parser.h
struct functions {
void *fred (int );
};
parse( string, functions );
// program.cpp
parse( "a = sqrt(); fred(a);", functions );
What you need is a way of registering functions(and their details with the dll.)
The bigger problem here is the details bit. But skipping over that you might do something like wxWidgets does with class registration. When method_fred is contructed by your app it will call the constructor and register with the dll through usage off methodInfo. Parser can lookup methodInfo for methods available.
// parser.h
class method_base { };
class methodInfo {
static void register(factory);
static map<string,factory> m_methods;
}
// program.cpp
class method_fred : public method_base {
static method* factory(string args);
static methodInfo _methoinfo;
}
methodInfo method_fred::_methoinfo("fred",method_fred::factory);
This sounds like a job for data structures.
Create a struct containing your keywords and the function associated with each one.
struct keyword {
const char *keyword;
int (*f)(int arg);
};
struct keyword keywords[max_keywords] = {
"db_connect", &db_connect,
}
Then write a function in your DLL that you pass the address of this array to:
plugin_register(keywords);
Then inside the DLL it can do:
keywords[0].f = &plugin_db_connect;
With this method, the code to handle script keywords remains in the main program while the DLL manipulates the data structures to get its own functions called.
Taking it to C++, make the struct a class instead that contains a std::vector or std::map or whatever of keywords and some functions to manipulate them.
Winrawr, before you go on, read this first:
Any improvements on the GCC/Windows DLLs/C++ STL front?
Basically, you may run into problems when passing STL strings around your DLLs, and you may also have trouble with exceptions flying across DLL boundaries, although it's not something I have experienced (yet).
You could always load the dll at runtime with load library