I have an MFC DLL that is loaded by a 3rd party application. How can I get the DLL filename from within the code of the DLL? That is, for example, if the DLL's name is mycode.dll, in code I want to be able to retrieve the string "mycode.dll".
I should add that if the DLL file name is changed on disk then I would like to get the current name on disk (I don't mean changed during run-time but changed between invocations of the main program).
My DLL is implemented as a CWinApp class, my code has no explicit DllMain.
You can call AfxGetStaticModuleState to get a pointer to an AFX_MODULE_STATE structure, which has a member m_lpszCurrentAppName containing the module name (app or DLL depending on where it's called from).
See the Get GetModuleFileName function.
When you pass in NULL for the first parameter, it will just use the handle for the current process.
GetModuleFileName function definitely returns the EXE THAT LOADED THE DLL... not the DLL itself. I would have posted this as a comment above but I don't have enough points yet, meh.
Related
Is there a way to load all functions from runtime loaded DLL? Current code:
hGetProcIDDLL = LoadLibrary(dll);
typedef int(*f_connection_a)(args);
typedef int(*f_connection_b)(args);
typedef int(*f_connection_c)(args);
f_connection_a connection_a = (f_connection_a)GetProcAddress(hGetProcIDDLL, "connection_a");
f_connection_b connection_b = (f_connection_b)GetProcAddress(hGetProcIDDLL, "connection_b");
f_connection_c connection_c = (f_connection_c)GetProcAddress(hGetProcIDDLL, "connection_c");
As you can see, this gets cumbersome quickly as you have to define every DLL function like this. Is there a way to load all DLL functions instead of having to list them?
Since here the "connection_*" are only a variables, there is no way to initialize them other than to run a code such as calling a function to get an address of a function. WinAPI doesn't have bulk method for binding functions at run time. This is limitation of WinAPI. The intention of this method was to check the presence of a functions individually and to delay loading library up to the point when it will actually be needed (or to avoid loading at all if it is not used).
But you can avoid such messy code by binding DLL at program loading stage using Import Table feature. In this case Windows loads executable image into memory, then loads all dependent DLLs and automatically binds the imported functions before launching executable code. For this you need:
Prepare *.def file for the library you need to load. The simplest method is to launch "impdef.exe my.dll" command on dll file. You may find tiny impdef.exe that doesn't need installation in TinyC package (see https://bellard.org/tcc/).
Then prepare corresponding *.lib file by launching "lib /def:my.def /out:my.lib"
After that link produced library with your project as regular library.
The drawback of this method is that if DLL is absent or corrupted, your executable file won't start at all. But this is a small payment for the convenience of importing functions.
Related to: How to find a functions address to hook/detour in an EXE file?
I have to detour a function defined inside the executable I'm injecting my code into. The application is Open-Source so I know everything about the function I'd need for hooking it.
In the accepted answer to that question, it says to hook some low level windows api functions first to get the address of the actual function I want to hook, question is, which windows API function should I hook?
Choose an API inside your target EXE that get called first when it runs. Load it to OllyDbg and trace until you find one.
I have an exe file that I had written a while back and cannot find the source code for it (it was written in C++).
It calls the MessageBoxA function in user32.dll and passes necessary parameters to it. I want to modify the flags parameter to include the MB_ICONERROR (0x10) flag.
How do I go about finding which bytes in the exe file need to be modified to accomplish this?
You need a disassembler like ICE or IDA. https://www.hex-rays.com/products/ida/support/download.shtml.
Load the executable. Find the Win32 API call on Names Window, to find it, just type the function name. Then double click CODE XREF to go to referenced caller.
Then you get what you want:
Just select the line and click on Hex-View to get the address.
I have used a lot of modal dialogs and they worked fine without the use of AFX_MANAGE_STATE, but recently I was working on a different project in which the resource dlls are different from the launching dll. I surfed the web and found out the above line and when I inserted it before launching the dialog, it worked. I guess that maybe since we have different dlls, we need to load the state of the main dll in order to launch the dialog, but I am not sure. I have not been able to find a good explanation anywhere on the internet. Could anyone please explain in simple terms what AFX_MANAGE_STATE does and why I suddenly had to use it.
Thanks.
Every .exe and .dll has an internal resource handle, pointing to your dialogs and other resources. If you call a function in your DLL, the current resource handle is pointing to the resources in the .exe, which is wrong and needs to be changed to the resources of the DLL.
This is what AFX_MANAGE_STATE does.
AFX_MANAGE_STATE is a macro which calls resource function so that resource would be looked up only in this DLL, and not the EXE/DLL from which particular function is called. This macro also causes AFX_MAINTAIN_STATE class to be put on stack. This class would, on exit of function, reset the resource lookup, so that EXE/DLL that called this exported function gets it resource searching back.
In C++ terms:
// Some exported function that launches GUI or uses other resources
int GetSomething()
{
AFX_MANAGE_STATE();
...
}
Would be something like (not exactly):
int GetSomething()
{
SetResourceSearchingToThisDLL();
AFX_MAINTAIN_STATE state_RAII;
//Use resource
// Compiler will put destroctor call for state_RAII object here
// which will mean AFX_MAINTAIN_STATE::~AFX_MAINTAIN_STATE()
// And that would call something like:
ResetResourceSearching();
}
Usage of this macro, within same DLL call stack wont hurt anyone, since Resource-Searching has some usage-counter, which will revert to caller (DLL/EXE resource) only if it reaches 0.
It is important to note that, not every MFC DLL has to use this macro. It is only if DLL is loaded by non-MFC client, may be by a C client, a C++ console based application, .NET client etc (yes, may be MFC Windows application client also).
If your EXE and DLL are made in MFC, using same MFC/Compiler/linker version and has one CWinApp object, you need not to use this macro.
I have a C++ Windows application myapp.exe which loads several plug-ins.
Plug-ins need to find the path to their DLLs. I can use GetModuleFileName for this, but it need the handle for the plug-in DLL. I don't know where to get this handle. GetModuleHandle(NULL) returns the handle to the executable.
One option is to use GetModuleHandle (GetModuleHandle("myplugin.dll") ) , but this requires the name of the plugin to be hardcoded which I want to avoid.
Any help is appreciated.
Paul
I don't know where to get this handle
It's passed as a parameter to your DLLMain() entry function.
If the plugin can't access its DLLMain() entry function, it can use the VirtualQuery function on a piece of its own memory and use the AllocationBase field of the filled-in MEMORY_BASIC_INFORMATION structure as its HMODULE.