Ich frage mich, warum mein Programm bei nem Kumpel nicht funktioniert. Es lädt eine DLL in einen Prozess, davor werden natürlich nötige Privilegien gesetzt.

Nun, bei mir funktioniert das laden einer DLL (Von mir erstellt, nix drin außer DllMain) in einen Prozess eines Spiels (egal.exe) einwandfrei, beim Kumpel wird die DLL einfach nicht reingeladen...

Woran kann das liegen? Er ist natürlich Admin und hat dasselbe Betriebssystem.
Natürlich legt er die DLL auch ins richtige Verzeichnis (C:\) und startet den Prozess vorher, er macht alles gleich wie ich... Programm und DLL sind beide "Release built".

Bin am verzweifeln... Mit dem Injection-Code möchte ich euch nicht bombadieren, aber der ist nicht von mir sondern aus dem Netz.
Naja, falls es wichtig sein könnte (Bei mir gehts aber doch...):

http://datakeeper.lima-city.de/html/winject.txt
http://datakeeper.lima-city.de/html/winject_h.txt

Und so wird das Modul geladen:

char* exe = "egal.exe";
char* path = "c:/test.dll";

DWORD PID = GetPIDbyEXE(exe);
int result = DoInject(PID, path);

if(!IsModuleLoaded(PID, path))
{
	// Meier...
    // Und result == 8 (0 wäre success)
}

Leider gehts beim Kumpel in den Abschnitt "Meier...".
Also, woran kanns liegen?

Achja: Mit ner anderen DLL funktionierts bei ihm (detoured.dll zB.)!
Aber mit meiner DLL müsste es doch genauso tun, zumal es bei mir ja geht:

#include <windows.h>

bool WINAPI DllMain(HMODULE hDll, DWORD dwReason, PVOID pvReserved)
{
	if(dwReason == DLL_PROCESS_ATTACH)
		;
	else if(dwReason == DLL_PROCESS_DETACH)
		;

    return true;
}

Danke!
MfG

Was ist da los? Was schränkt Home da wieder ein? Liegt es an:

TOKEN_PRIVILEGES priv;
	HANDLE hThis, hToken;
	LUID luid;
	hThis = GetCurrentProcess();
	OpenProcessToken(hThis, TOKEN_ADJUST_PRIVILEGES, &hToken);
	LookupPrivilegeValue(0, "seDebugPrivilege", &luid);
	priv.PrivilegeCount = 1;
	priv.Privileges[0].Luid = luid;
	priv.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
	AdjustTokenPrivileges(hToken, false, &priv, 0, 0, 0);
	CloseHandle(hToken);
	CloseHandle(hThis);

Geht das auf XP Home nicht oder wie?
Und noch eine Seltsamkeit:

SendMessage(analyzePanel, LB_ADDSTRING, 0, reinterpret_cast<LPARAM>(entry.c_str()));

Scheint bei nem Kumpel mit XP Home keine Auswirkung zu haben. Es wird kein Text der ListBox hinzugefügt. Bei mir gehts aber...

//EDIT:
Mit LB_INSERTSTRING gehts auf Home... aber das kann doch nicht sein? Was ist da nur los?
Aber das Hauptproblem ist eher, dass sich die DLL unter Home nicht laden lässt...

//EDIT 2:
Auf 2 von 3 Home-Systemen funzt LB_ADDSTRING, warum funzt das auf einer Maschine nicht?

Nana... es muss doch an etwas grundlegendem scheitern, sonst würde es auf XP Prof. doch auch nicht tun.

Nun, hier ein kürzerer injection-Code, mit dem es auf XP Professional funktioniert, auf XP Home wieder nicht...:

bool insertDll(DWORD procID, std::string dll)
{
    //Find the address of the LoadLibrary api, luckily for us, it is loaded in the same address for every process
    HMODULE hLocKernel32 = GetModuleHandle("Kernel32");
    FARPROC hLocLoadLibrary = GetProcAddress(hLocKernel32, "LoadLibraryA");

    //Adjust token privileges to open system processes
    HANDLE hToken;
    TOKEN_PRIVILEGES tkp;
    if(OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken))
    {
        LookupPrivilegeValue(NULL, SE_DEBUG_NAME, &tkp.Privileges[0].Luid);
        tkp.PrivilegeCount = 1;
        tkp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
        AdjustTokenPrivileges(hToken, 0, &tkp, sizeof(tkp), NULL, NULL);
    }

    //Open the process with all access
    HANDLE hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, procID);

    //Allocate memory to hold the path to the Dll File in the process's memory
    dll += '\0';
    LPVOID hRemoteMem = VirtualAllocEx(hProc, NULL, dll.size(), MEM_COMMIT, PAGE_READWRITE);

    //Write the path to the Dll File in the location just created
    DWORD numBytesWritten;
    WriteProcessMemory(hProc, hRemoteMem, dll.c_str(), dll.size(), &numBytesWritten);

    //Create a remote thread that starts begins at the LoadLibrary function and is passed are memory pointer
    HANDLE hRemoteThread = CreateRemoteThread(hProc, NULL, 0, (LPTHREAD_START_ROUTINE)hLocLoadLibrary, hRemoteMem, 0, NULL);

    //Wait for the thread to finish
    bool res = false;
    if (hRemoteThread)
        res = (bool)WaitForSingleObject(hRemoteThread, 10000) != WAIT_TIMEOUT;

    //Free the memory created on the other process
    VirtualFreeEx(hProc, hRemoteMem, dll.size(), MEM_RELEASE);

    //Release the handle to the other process
    CloseHandle(hProc);

    return res;
}

Gerade habe ich ein XP Home System gefunden, auf dem das Ganze funktioniert aber...

XP Professional System:
DLL Injizieren funktioniert

XP Home System 1:
DLL Injizieren funktioniert

XP Home System 2:
DLL Injizieren funktioniert nicht
(detoured.dll geht aber zB, nur meine nicht!)

XP Home System 3:
DLL Injizieren funktioniert nicht
(detoured.dll geht aber zB, nur meine nicht!)

Bei Home System 2 & 3 werden zwar msvcp71.dll und MSVCR71.DLL in den Prozess geladen, meine DLL aber nicht... Was ist da los?

Danke!
MfG

Wie anfangs schon erwähnt, funktioniert nur meine DLL nicht, aber zB. detoured.dll von Microsoft schon!
(Also dort, wo sich meine DLL injizieren lässt, geht natürlich auch detoured.dll, aber dort wo sich meine DLL nicht injizieren lässt, geht es jedoch mit detoured.dll)

MfG

Aber: Es tritt kein Fehler auf!

Hab jede Funktion in insertDll() geprüft, jede gibt einen Wert ungleich 0 zurück. Auf jedem System. Aber trotzdem wird auf manchen Systemen nicht injiziert... Bei "XP Media Center Edition" gehts auch nicht...
Überall als Admin probiert, kein AntiVirus, ...

MfG

Das ist unmöglich.

Ja, das denke ich auch ständig

#include <windows.h>

bool WINAPI DllMain(HMODULE hDll, DWORD dwReason, PVOID pvReserved)
{
	if(dwReason == DLL_PROCESS_ATTACH)
		;
	else if(dwReason == DLL_PROCESS_DETACH)
		;

    return true;
}

Es ist aber so... Aber es muss doch mit meiner DLL zu tun haben, immerhin funktioniert es mit anderen ja überall, doch mit meiner Selbsterstellten nicht überall...

MfG

ht = CreateRemoteThread( hProcess, 0, 0, (DWORD (__stdcall *)( void *)) p, c, 0, &rc );
if ( ht == NULL ) 
	nResult=6;

. Hast du in deinem Codestückchen mal probiert, ob CreateRemoteThread schiefgeht? Wenn's NULL zurückgibt, dann zeig mal den GetLastError.

http://www.c-plusplus.net/forum/viewtopic-var-t-is-214120-and-postdays-is-0-and-postorder-is-asc-and-start-is-0.html#1517111

...funktioniert es nicht. Dabei geben aber alle Funktionen auf jedem System !0 zurück, trotzdem wird auf einigen Systemen nicht injiziert.

MfG

Mögichkeit:
1. Deine DLL funktioniert nicht...
2. Deine DLL braucht DLLs die auf dem Zielsystem nicht geladen werden können
3. Dein DLL beendet DllMain nicht korrekt und wird wieder entladen.

Hab das Problem immer noch. Jetzt wirds aber dringend, dass es auf allen XP Systemen funktioniert...
Grade wieder mit nem Kumpel getestet.

Hab mir jetzt einen Universal-DLL-Injector zugelegt. Er gibt bei mir keinen Fehler aus, und die DLL wird tatsächlich im Prozess ausgeführt.
Beim Kumpel gibt der Injector auch keinen Fehler aus, aber die DLL wird nicht im Prozess ausgeführt!

Somit ist es klar, es liegt nich an meinem Injektor, sondern an meiner DLL!
Denn der UniversalInjektor wurde zu genüge getestet...

Frage:
Was muss ich beim schreiben einer DLL beachten, welche in einem Prozess ausgeführt werden soll? Brauche ich da extern "C", __declspec(dllimport) Anweisungen?

An irgendwas muss es ja liegen...

Eine andere DLL lässt sich ja sogar laden, zB. eine von Microsoft...
Deshalb bin ich mir so sicher, dass es an meinem DLL Code liegt (Eh schon gepostet)...

XP Professional System:
DLL Injizieren funktioniert

XP Home System 1:
DLL Injizieren funktioniert

XP Home System 2:
DLL Injizieren funktioniert nicht
(detoured.dll geht aber zB, nur meine nicht!)

XP Home System 3:
DLL Injizieren funktioniert nicht
(detoured.dll geht aber zB, nur meine nicht!)

Bei Home System 2 & 3 werden zwar msvcp71.dll und MSVCR71.DLL in den Prozess geladen, meine DLL aber nicht... Was ist da los?

Falls das immer noch so ist, dann prüf mal mit einem "DependencyWalker" ob die eigene DLL außer den beiden ev. noch eine DLL braucht (die auf dem "Zielsystem" nicht vorhanden ist).

Thx a lot!