Entwickler-Ecke
Windows API - CreateRemoteThread; FreeLibraray
SAiBOT - Di 19.08.08 17:16
Titel: CreateRemoteThread; FreeLibraray
Hi, ich versuche mittels
CreateRemoteThread eine DLL eines fremden Prozesses frei zugeben.
Leider funktioniert mein Code nicht :nixweiss:.
Das
ModuleHandle wird korrekt übergeben daran liegt es
NICHT.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47:
| function RemoteFreeLibrary(PID: Cardinal; DLL:PChar):Boolean; var lib:Cardinal; BytesWritten, hProcess, hThread, TID: Cardinal; params: pointer;
begin Result := False;
lib := GetDllHandle(PID, DLL); if lib = 0 then Exit; try hProcess := OpenProcess(PROCESS_ALL_ACCESS, False, PID); if hProcess = INVALID_HANDLE_VALUE then Exit;
try params := VirtualAllocEx(hProcess, nil, 4, MEM_COMMIT or MEM_RESERVE, PAGE_READWRITE);
if params = nil then Exit;
WriteProcessMemory(hProcess,params,@lib, 4,BytesWritten);
if BytesWritten <= 0 then Exit;
hThread := CreateRemoteThread(hProcess, nil, 0, GetProcAddress(GetModuleHandle('kernel32.dll'), 'FreeLibrary'), params, 0, TID);
if hThread <> INVALID_HANDLE_VALUE then Result := True; finally CloseHandle(hProcess); end; except end; end; |
Delete - Di 19.08.08 18:28
| Zitat: |
| Leider funktioniert mein Code nicht :nixweiss: |
Es werden also keine Fehler angezeigt oder doch? :wink:
BenBE - Di 19.08.08 18:57
Und lass mich raten: Das Fremde Programm stürzt daraufhin mit einer Zugriffsverletzung ab ... ;-)
SAiBOT - Di 19.08.08 20:06
j.klugmann hat folgendes geschrieben: |
| Zitat: | | Leider funktioniert mein Code nicht :nixweiss: |
Es werden also keine Fehler angezeigt oder doch? :wink: |
Keine Fehler :mahn:
BenBE hat folgendes geschrieben: |
| Und lass mich raten: Das Fremde Programm stürzt daraufhin mit einer Zugriffsverletzung ab ... ;-) |
Ne' ;).
Delete - Di 19.08.08 22:20
Also, ich darf noch mal zusammenfassen: Dein Code wird ohne Fehler und Warnungen compiliert. Das andere Programm stürzt nicht ab. Du sagst: "Es funktioniert nicht."
Müssen wir jetzt einem Geheimbund beitreten, um zu erfahren, was du unter "funktioniert nicht" verstehst oder sagst du es uns noch? Ansonsten stellt sich die Frage, warum du hier um Hilfe bittest, wenn du uns die entscheidenden Informationen vorenthältst.
uall@ogc - Mi 20.08.08 15:35
Du solltest mal bei Byteswritten auf 4 testen.
GetExitCodeThread gibt dir den ExitCode des Threads (somit den von FreeLibrary zurück)
FreeLibrary MUSS die dll nicht entladen, sondern veringert nur den ThreadCounter und bei 0 (oder -1) wird sie erst entladen.
Delete - Mi 20.08.08 16:17
uall@ogc hat folgendes geschrieben: |
| GetExitCodeThread gibt dir den ExitCode des Threads (somit den von FreeLibrary zurück) |
Ich will da jetzt nicht widersprechen, aber kann denn das sein? Den ExitCode bestimmt ja ich. Und ob FreeLibrary fehlschlägt oder nicht, darauf habe ich ja keinen Einfluss. Würde FreeLibrary fehlschlagen, würde es ja meinen ExitCode überschreiben. Desweiteren ist der Rückgabewert von FreeLibrary mit BOOL deklariert, der ExitCode ist aber ein Integer. Und den ExitCode muss man vor dem Aufruf von FreeLibrary abfragen, denn da nach verliert er seine Gültigkeit. Und warum hängt der ExitCode eines Threads mit FreeLibrary zusammen? das sind doch zwei Paar Schuhe. Oder habe ich hier eine Wissenslücke?
SAiBOT - Mi 20.08.08 16:19
Luckie hat folgendes geschrieben: |
Also, ich darf noch mal zusammenfassen: Dein Code wird ohne Fehler und Warnungen compiliert. Das andere Programm stürzt nicht ab. Du sagst: "Es funktioniert nicht."
Müssen wir jetzt einem Geheimbund beitreten, um zu erfahren, was du unter "funktioniert nicht" verstehst oder sagst du es uns noch? Ansonsten stellt sich die Frage, warum du hier um Hilfe bittest, wenn du uns die entscheidenden Informationen vorenthältst. |
Ich denke du weißt so gut wie ich, das ich erreichen wollte das eine bestimmte DLL entladen werden sollte.. und das "funktioniert nicht" sich darauf bezieht das die DLL halt NICHT entladen wird. Solche Beiträge kannst du dir sparen, deinem Beitrags-Counter mags' dienen aber weder mir noch der Community danke!
Hier noch ein Link für dich ->
Klick mich [
http://de.wikipedia.org/wiki/Spezial:Search?ns0=1&search=freundlichkeit&fulltext=Suche]
uall@ogc hat folgendes geschrieben: |
FreeLibrary MUSS die dll nicht entladen, sondern veringert nur den ThreadCounter und bei 0 (oder -1) wird sie erst entladen. |
Aha! Das werde ich mal prüfen, Danke
Luckie hat folgendes geschrieben: |
uall@ogc hat folgendes geschrieben: | | GetExitCodeThread gibt dir den ExitCode des Threads (somit den von FreeLibrary zurück) |
Ich will da jetzt nicht widersprechen, aber kann denn das sein? Den ExitCode bestimmt ja ich. Und ob FreeLibrary fehlschlägt oder nicht, darauf habe ich ja keinen Einfluss. Würde FreeLibrary fehlschlagen, würde es ja meinen ExitCode überschreiben. Desweiteren ist der Rückgabewert von FreeLibrary mit BOOL deklariert, der ExitCode ist aber ein Integer. Und den ExitCode muss man vor dem Aufruf von FreeLibrary abfragen, denn da nach verliert er seine Gültigkeit. Und warum hängt der ExitCode eines Threads mit FreeLibrary zusammen? das sind doch zwei Paar Schuhe. Oder habe ich hier eine Wissenslücke? |
Ist mir auch unklar :nixweiss:
Delete - Mi 20.08.08 22:30
SAiBOT hat folgendes geschrieben: |
Luckie hat folgendes geschrieben: | Also, ich darf noch mal zusammenfassen: Dein Code wird ohne Fehler und Warnungen compiliert. Das andere Programm stürzt nicht ab. Du sagst: "Es funktioniert nicht."
Müssen wir jetzt einem Geheimbund beitreten, um zu erfahren, was du unter "funktioniert nicht" verstehst oder sagst du es uns noch? Ansonsten stellt sich die Frage, warum du hier um Hilfe bittest, wenn du uns die entscheidenden Informationen vorenthältst. |
Ich denke du weißt so gut wie ich, das ich erreichen wollte das eine bestimmte DLL entladen werden sollte.. und das "funktioniert nicht" sich darauf bezieht das die DLL halt NICHT entladen wird. |
Ich finde es ja nett, dass du mir hellseherische Fähigkeiten unterstellst, aber die habe ich dann doch nicht. Und ist es denn so schwer sich so auszudrücken, dass andere, die helfen wollen, nicht erst rumraten müssen?
Woran machst du denn fest, dass die DLL nicht entlaen wird? Hast du mal den Rückgabewert von FreeLibrary abgefragt und bei Fehlschlag mal GetLastError aufgerufen?
Ach und mein Beitragszähler ist mir so was von egal. Käme es mir darauf an könnte ich wohl in fast jeden zweiten Thread antworten.
uall@ogc - Mi 20.08.08 23:40
Ganz einfach:
eine Thread-Funktion ist wie folgt aufgebaut:
Delphi-Quelltext
1: 2: 3: 4: 5:
| function MeinThread(Param: integer): integer; stdcall;
function FreeLibrary(DllHandle: DWord): Bool; stdcall; |
Jetzt wird im Fremdprozess bei FreeLibrary ein Thread gestartet. Dies hat den gleichen Aufbau wie eine Thread-Funktion! Würde man einen Thread bei MeinThread starten würde der Rückgabewert dem Wert entsprechen den MeinThread als Result zurückliefert. Result ist dabei immer EAX. FreeLibrary verwendet einen Bool, dieser wird aber auch in EAX abgelegt.
GetExitCodeThread funktioniert solange bist das Handle geschlossen wird (Closehandle, im aufrufenden Thread). Im Grunde wird ein Thread bei FreeLibrary gestartet, das ergebnis (Bool) steht in EAX, danach ist der "Thread" (also FreeLibrary) zu Ende und EAX wird als ExitCode verwendet. Genau das kann abgefragen werden, jedenfalls solange bis das mit CreateRemoteThread gestartete Threadhandle geschlossen wurde.
SAiBOT - Fr 22.08.08 15:40
Luckie hat folgendes geschrieben: |
SAiBOT hat folgendes geschrieben: | Luckie hat folgendes geschrieben: | Also, ich darf noch mal zusammenfassen: Dein Code wird ohne Fehler und Warnungen compiliert. Das andere Programm stürzt nicht ab. Du sagst: "Es funktioniert nicht."
Müssen wir jetzt einem Geheimbund beitreten, um zu erfahren, was du unter "funktioniert nicht" verstehst oder sagst du es uns noch? Ansonsten stellt sich die Frage, warum du hier um Hilfe bittest, wenn du uns die entscheidenden Informationen vorenthältst. |
Ich denke du weißt so gut wie ich, das ich erreichen wollte das eine bestimmte DLL entladen werden sollte.. und das "funktioniert nicht" sich darauf bezieht das die DLL halt NICHT entladen wird. |
Ich finde es ja nett, dass du mir hellseherische Fähigkeiten unterstellst, aber die habe ich dann doch nicht. Und ist es denn so schwer sich so auszudrücken, dass andere, die helfen wollen, nicht erst rumraten müssen?
Woran machst du denn fest, dass die DLL nicht entlaen wird? Hast du mal den Rückgabewert von FreeLibrary abgefragt und bei Fehlschlag mal GetLastError aufgerufen?
Ach und mein Beitragszähler ist mir so was von egal. Käme es mir darauf an könnte ich wohl in fast jeden zweiten Thread antworten. |
Uall hats' ja "irgendwie" auch geschafft etwas produktives zu posten. Selbst wenn die Fragestellung nicht Optimal sein sollte, ist so eine erhabene Art, meiner Ansicht nach, nicht nötig. Ein freundlicher Hinweis darauf hätte genügt!
~Delphi-Forum.de - Deine freundliche Delphi Community
SAiBOT - Fr 22.08.08 20:44
So ich habe mir das mal angesehen, die DLL wird im ZielProzess NUR im MainThread geladen, dh. normalerweise müßte sich die DLL ohne weiteres "entladen". Mit Uall's "UnloadLibrary"-Funktion funktioniert es!
Ich finde das Problem beim besten Willen nicht :nixweiss:
uall@ogc - So 24.08.08 17:44
Hab mir nochmal den Code genauer angeschaut und wenn ich mich nicht ganz irre musst du direkt die Adresse übergeben. Nicht erst in den Fremdprozess schreiben. CreateRemoteThread(..,..,..,DllHandle,..);
Der Parameter wird dann schon selbst aufn stack gepushed für FreeLibrary
SAiBOT - Mo 25.08.08 15:55
uall@ogc hat folgendes geschrieben: |
Hab mir nochmal den Code genauer angeschaut und wenn ich mich nicht ganz irre musst du direkt die Adresse übergeben. Nicht erst in den Fremdprozess schreiben. CreateRemoteThread(..,..,..,DllHandle,..);
Der Parameter wird dann schon selbst aufn stack gepushed für FreeLibrary |
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57: 58: 59: 60: 61: 62: 63: 64: 65: 66: 67: 68: 69:
| function RemoteGetModuleHandle(PID: Cardinal; DLL: PChar): Cardinal; var ModuleList: THandle; ModuleInfo : tagMODULEENTRY32; label go; begin Result := 0;
ModuleList := CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, PID); if ModuleList = INVALID_HANDLE_VALUE then Exit; try ModuleInfo.dwSize:=Sizeof(tagMODULEENTRY32);
if Module32First(ModuleList, ModuleInfo) then begin go: if LowerCase(ModuleInfo.szModule) = LowerCase(DLL) then begin Result := ModuleInfo.hModule; Exit; end;
if Module32Next(ModuleList, ModuleInfo) then goto go; end; finally CloseHandle(ModuleList); end; end;
function RemoteFreeLibrary(PID: Cardinal; DLL:PChar):Boolean; var lib:Cardinal; BytesWritten, hProcess, hThread, TID: Cardinal; params: pointer;
begin Result := False;
lib := RemoteGetModuleHandle(PID, DLL); if lib = 0 then Exit; try hProcess := OpenProcess(PROCESS_ALL_ACCESS, False, PID); if hProcess = INVALID_HANDLE_VALUE then Exit;
try hThread := CreateRemoteThread(hProcess, nil, 0, GetProcAddress(GetModuleHandle('kernel32.dll'), 'FreeLibrary'), @lib, 0, TID);
if hThread <> INVALID_HANDLE_VALUE then Result := True; finally CloseHandle(hProcess); end; except end; end;
end. |
@topic:
Ich habe mir mal eine TestDLL gemacht, die mir über
GetModuleHandle das eigene Handle liefert um es mit dem "lib" Wert im debugger zu vergleichen, beide stimmen überein!
Also liegt da wohl, wie vermutet, nicht das Problem. Trotzdem habe ich mal meine "RemoteGetModuleHandle"-Funktion angehängt!
@uall:
Das scheint leider auch nicht zu funktionieren :cry:
uall@ogc - Di 26.08.08 08:43
ich hab im Moment zu wenig Zeit mir das genauer anzuschauen. Aber du weißt schon, dass du RemoteFreeLibrary auch mal im eigenen Prozess (z.b. vorehr opengl32.dll laden) testen kannst? nen BP auf FreeLibrary und schaun was der Parameter ist. Ist im Grunde ne Sache von 5 Minuten
SAiBOT - Di 26.08.08 17:12
uall@ogc hat folgendes geschrieben: |
| ich hab im Moment zu wenig Zeit mir das genauer anzuschauen. Aber du weißt schon, dass du RemoteFreeLibrary auch mal im eigenen Prozess (z.b. vorehr opengl32.dll laden) testen kannst? nen BP auf FreeLibrary und schaun was der Parameter ist. Ist im Grunde ne Sache von 5 Minuten |
Ja das war mal eine gute Idee. :dance: :dance2:
So funktioniert es:
Delphi-Quelltext
1: 2: 3: 4: 5:
| hThread := CreateRemoteThread(hProcess, nil, 0, GetProcAddress(GetModuleHandle('kernel32.dll'), 'FreeLibrary'), ptr(lib), 0, TID); |
Vielen Dank für deine Hilfe :zustimm:
uall@ogc - Di 26.08.08 19:20
das hätte funktioniert wenn du es so umgesetzt hättest wie ich geschrieben habe ;P
nen ptr(lib) ist was anderes als ein @lib :) (ersteres hab ich vogeschlagen)
SAiBOT - Mi 27.08.08 18:07
uall@ogc hat folgendes geschrieben: |
das hätte funktioniert wenn du es so umgesetzt hättest wie ich geschrieben habe ;P
nen ptr(lib) ist was anderes als ein @lib :) (ersteres hab ich vogeschlagen) |
Ja, habe ich aber auch erst bemerkt als ichs' mir im Speicher angesehen habe :).
"@lib" ist der Pointer vom Pointer vom Wert, Oder :gruebel:
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!