I dont like it either, but its not that bad. The best way is loading the dll with own code, but then you dont have a HMODULE, and having no resource functions can be pain in the ass (Dialogs etc...) - but thats not a problem in most cases with sc plugins. And by writing a FindResource(), most of the resource functions can be emulated.
Maybe not in the best place, but I attached an example. This dll loading routine does the same as scloader2b's -dllex parameter.
Here is our primitive slave DLL that wants us to load it "manually":
building dll.c, dll.def:
cl /c /I<your_include_dir> dll.c
link /subsystem:windows /dll /def:dll.def dll.obj
The code that is able to load the DLL: (3 files)
load_dll_test.cpp, load_dll.cpp, load_dll.h
Known issues with "manual load":
- You do not have a HMODULE. The Imagebase you get can only be used with one of the MyGetProcAddress functions but only when you loaded the DLL with headers. The most painful thing is that you can not use resource functions. These functions can also be emulated. One way to solve the problem is Finding the resource manually and then use Dialog functions that work on memory templates. Some of the Resource functions work on binary data, for example one of my favorites is CreateIconFromResource that creates cursor/icon from anywhere, you must point to the icon data where its BITMAP_INFO_HEADER begins, and 2 words back if you create a cursor and you must store the hotspot before the BITMAP_INFO_HEADER in that 2 words. There are several tricks to solve resource handling, but I usually convert the data I use to C/pascal array (source code) and compile it to the code. This is the easiest way to go.
- You wont recive DLL_THREAD_ATTACH/DETACH notifications. You can emulate them with the lpfDllMain member of LOAD_DLL_INFO if you have another real workhorse DLL.
- LoadDLL does not give you detailed error message when an import resolving error occurs. You dont know what DLL or function is missing. Patch the code yourself, its not that hard.
The sample code uses 0 as dwFalgs when it call LoadDLL or any of its descendants that implement the readproc (streaming). When you use antihack use the DLL_NO_HEADERS flag to make it harder to sweep your module.
Own FindResource:
Some win32 functions that may come handy when you load resources by hand after you used the MyFindResource(), MyLoadResource() and MySizeOfResource() functions and you have the pointer to the raw resource data:
- ICON and CURSOR
CreateIconFromResource()
- DIALOG
CreateDialogIndirect()
CreateDialogIndirectParam()
- MENU
LoadMenuIndirect()
The FindResource sources can be compiled as both ANSI and UNICODE.
The sources were compiled under VC++6.