Dll Code:
#include <windows.h>
BOOL APIENTRY DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
MessageBoxW(NULL, L"Hello world!", L"Test DLL", MB_OK);
return TRUE;
}
LoadLibrary Code:
#include <windows.h>
int main()
{
LoadLibrary("dll.dll");
return 0;
}
When I load the dll with the above code the message box pops up as expected.
When I instead try to inject the dll with any injector I was able to find, DllMain never gets called.
The target process and dll architecture is both x64. The target process has the required library for MessageBoxW() already loaded.
If needed, this is how I compile the dll (mingw): gcc.exe main.cpp -shared -fPIC -o dll.dll
Maybe I'm unlucky with my 5 injector's I already tried, any recommendation?
What else could cause the message box to not pop up?
Looks like the injectors weren't working. Finally found one called "Remote DLL" from securityxploded.com, making strings show up on DebugView. Thanks to #WhozCraig.
Related
How can I debug a dll using visual studio?
I have the DLL source, pdb, etc.
I tried these options:
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
void DebugBreak();
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
{
//...
}
break;
case DLL_PROCESS_DETACH:
{
//...
}
break;
}
);
return TRUE;
}
It launches the exe but doesn't inject the DLL, by default this exe didn't load the DLL, im manually injecting it.
Is possible to visual studio attach the DLL? and be able to put breakpoints on it, view call stack on a crash, etc?
The quickest way to fix this is via the Modules Window in the Debugger:
Put a breakpoint after your LoadLibrary call.
Go to Debug->Windows->Modules in the menu bar to bring up the Modules window.
Search for your dll file in the list. In the Symbol Status column
it should read "Cannot find or open the PDB file".
Right click the dll and choose Load Symbols from the context menu.
Point it to the correct pdb file.
The Symbol Status should now change to "Symbols Loaded".
You should now be able to step into functions from the dll and put breakpoints.
I'm creating a windows DLL using gcc that is loaded via LoadLibrary in a third party program (I don't have access to it's code). When I try to debug my DLL in Visual Studio Code using gdb with an attach request, I'm unable to get any breakpoints to hit. It works fine if I use a launch request. Loading the host program takes enough time as it is, and it takes even longer when gdb and VSCode are launching it directly.
I created a test EXE in gcc/VSC and compiled it with and without debugging information. I then provided a message box in test prior to loading the dll to give me time to attach the debugger. The breakpoints where hit just fine when test.exe was compiled with debugging info. However, I was able to recreate the issue when the test was compiled without debugging info, which tells me it has something to do with the EXE not having debugging symbols available.
Is there a way to load symbols for a debug-enabled DLL when the host program doesn't provide debugging symbols while attaching to the process with gdb/VSC?
dllmain.cpp
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
switch(fdwReason) {
case DLL_PROCESS_ATTACH:
MessageBoxA(NULL, "We've loaded the library", "Title", 0); // message box displays
break;
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE; // set breakpoint here, doesn't hit if test.exe is compiled without -g
}
gcc -g -shared dllmain.cpp -o dllmain.dll
test.cpp
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
int main() {
MessageBoxA(NULL, "Attach the debugger now, then click OK", "Attach debugger", 0);
HMODULE h = LoadLibraryA("path/to/dllmain.dll"); // dll breakpoint should hit
if (h == 0) return GetLastError();
FreeLibrary(h); // dll breakpoint should hit
return 0;
gcc test.cpp -o test.exe
gcc -g test.cpp -o test.exe
launch.json
{
"name":"Attach to Process",
"type":"cppdbg",
"miDebuggerPath":"path/to/gdb.exe",
"MIMode":"gdb",
"request":"attach",
"program":"path/to/test.exe",
"processId":"${command:pickProcess}",
"cwd":"path/to/source files",
}
Tools: Msys2, MinGW-w64, gcc#11.2.0, gdb#11.2, Visual Studio Code v1.66
I added the lua package to my c++ project, but anytime lua is included in my project no functions are called when my DLL gets attached, but when I dont include lua the messagebox appears on attachment. I'm certain it isn't the injection program since I tested my DLL w/ multiple programs and it's now driving me crazy. Does anyone have any solutions or steps in the right path? I would really appreciate it!
Package Used: https://bitbucket.org/sgrottel_nuget/lua/overview
EDIT: Including lua headers will remove functionality from my dll. Removing the lua headers (commenting out "#include "lua.hpp") will let the messagebox pop up. Am I using the lua package wrong or is there a small step I missed?
#include "FVM.h" // includes lua headers etc. (when removed function works on attachment)
// Entry point
BOOL APIENTRY DllMain(HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
MessageBoxA(NULL, "attached", "Function", MB_OK);
case DLL_THREAD_ATTACH:
MessageBoxA(NULL, "attached", "Function", MB_OK);
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
I can't reproduce this issue. Please follow my steps to see if it can reproduce this issue.
Create a main application using Windows Desktop Application template.
Create a DLL application using Dynamic-Link Library(DLL) template.
Install LUA nuget package to the DLL application.
Add the header file to the dllmain.cpp and add MessageBoxA same with your code.
Load DLL in the main application:
HMODULE myDll = LoadLibraryA("D:\\TestDllLoad\\Debug\\Dll1.dll");
The result is the message box display "attached" every time I launch the main application.
I want to write DLL but I want to test what I am writing.
I tried to debug it with F5 but I receive an error:
I read the article Walkthrough: Creating and Using a Dynamic Link Library (C++) how to do it and its latest version.
But they suggest to create header file that contains the functions.
In my case, I created DLL project (Loader) with dllmain.cpp.
// dllmain.cpp : Defines the entry point for the DLL application.
#include "stdafx.h"
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
HANDLE hd;
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
hd = CreateFileA("C:\\Users\\myuser\\Desktop\\test.dll", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
OutputDebugString(L"HELLO");
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
I created a new C++ console project in the same solution but I don't know how to call the function DllMain and debug it.
Just to make it organized, I have now two projects:
1. Loader - this is the DLL project
2. DLLTester - this is a console application that will run the DLL from the Loader project.
I added the folder of the DLL project (Loader) to the Additional Include Directories of the DLLTester project.
I created a header (Loader.h) to the DLL project and added the function signature DLLMain.
Now I can see it in the DLLMain function.
But I don't have idea what arguments I need to pass to this function:
I understand that I need to pass 3 arguments:
1. HMODULE hModule
2. DWORD ul_reason_for_call
3. LPVOID lpReserverd
But I don't what I need to enter there.
Code:
Loader project:
Loader.h:
#pragma once
#include "stdafx.h"
BOOL APIENTRY DllMain(HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
);
dllmain.cpp:
// dllmain.cpp : Defines the entry point for the DLL application.
#include "stdafx.h"
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
HANDLE hd;
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
hd = CreateFileA("C:\\Users\\myuser\\Desktop\\test.dll", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
OutputDebugString(L"HELLO");
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
DLLTester project:
DLLTester.cpp:
// DLLTester.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "Loader.h"
int main()
{
DllMain(?,?,?) -> not sure what to enter here
return 0;
}
How it looks:
DllMain is actually a fairly special function that is automatically called when a DLL is loaded using LoadLibrary or LoadLibraryEx (unless you do some evil stuff to prevent it).
If you really want to call it, you can use GetProcAddress, but believe it or not, a DLL's actual entry point will normally be _DllMainCRTStartup (which actually calls DllMain in addition to doing things like calling constructors and doing other initialization). It can even be overridden by the developer to be something completely different.
So I don't really see how calling DllMain can do anything useful for any normal DLL. It doesn't perform all of the initialization/cleanup (notably the C++ constructor calls at startup), and it's already being called (unless you suppress it with DONT_RESOLVE_DLL_REFERENCES).
The easy way to debug DllMain is to use static linking (that is with __declspec(dllexport)/__declspec(dllimport) syntax), and to then set your DLL project as the startup project but have the debugger start the .exe that links to the library. You set the program to run in the project settings (Project->Properties then Debugging -> Command.
You can then set breakpoints and do traces as normal from your DLL.
I know you can do breakpoints and whatnot for normal functions in a dynamic-loaded DLL I'm just not sure about DllMain.
I attempted to inject a C++ DLL in another WIN32 console programme. The injector (winjet) shows that it is successfully injected but the DLL itself does nothing.
As compiler I use Visual Studio 2013 and I just found out if I use precompiled header and this preset .cpp instead of a empty project without precompiled header, it works.
Dll.cpp :
BOOL APIENTRY Dllmain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved){
switch (reason) {
case DLL_PROCESS_ATTACH:
MessageBoxA(NULL, "Attached!", "InjectedDLL", MB_OK);
}
return TRUE;
}
This code works with preset settings and precompiled header. But why it doesn't without that?
The entry point to a Windows DLL is called DllMain, not Dllmain.
You do not get a compile error for this (like when mis-spelling main), because it is optional.