| Autor |
Beitrag |
SAiBOT
      
Beiträge: 323
Erhaltene Danke: 6
XP SP2; 7
D7; D2009
|
Verfasst: Di 19.08.08 17:16
Hi, ich versuche mittels CreateRemoteThread eine DLL eines fremden Prozesses frei zugeben.
Leider funktioniert mein Code nicht  .
Das ModuleHandle wird korrekt übergeben daran liegt es NICHT.
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; |
_________________ Debuggers don't remove bugs, they only show them in slow-motion.
|
|
j.klugmann
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Di 19.08.08 18:28
| Zitat: | Leider funktioniert mein Code nicht  |
Es werden also keine Fehler angezeigt oder doch? 
|
|
BenBE
      
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Di 19.08.08 18:57
Und lass mich raten: Das Fremde Programm stürzt daraufhin mit einer Zugriffsverletzung ab ... 
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
SAiBOT 
      
Beiträge: 323
Erhaltene Danke: 6
XP SP2; 7
D7; D2009
|
Verfasst: Di 19.08.08 20:06
_________________ Debuggers don't remove bugs, they only show them in slow-motion.
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: 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
      
Beiträge: 1826
Erhaltene Danke: 11
Win 2000 & VMware
Delphi 3 Prof, Delphi 7 Prof
|
Verfasst: 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.
_________________ wer andern eine grube gräbt hat ein grubengrabgerät
- oder einfach zu viel zeit
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: 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 
      
Beiträge: 323
Erhaltene Danke: 6
XP SP2; 7
D7; D2009
|
Verfasst: 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
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 
_________________ Debuggers don't remove bugs, they only show them in slow-motion.
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: 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
      
Beiträge: 1826
Erhaltene Danke: 11
Win 2000 & VMware
Delphi 3 Prof, Delphi 7 Prof
|
Verfasst: 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.
_________________ wer andern eine grube gräbt hat ein grubengrabgerät
- oder einfach zu viel zeit
|
|
SAiBOT 
      
Beiträge: 323
Erhaltene Danke: 6
XP SP2; 7
D7; D2009
|
Verfasst: 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
_________________ Debuggers don't remove bugs, they only show them in slow-motion.
|
|
SAiBOT 
      
Beiträge: 323
Erhaltene Danke: 6
XP SP2; 7
D7; D2009
|
Verfasst: 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 
_________________ Debuggers don't remove bugs, they only show them in slow-motion.
|
|
uall@ogc
      
Beiträge: 1826
Erhaltene Danke: 11
Win 2000 & VMware
Delphi 3 Prof, Delphi 7 Prof
|
Verfasst: 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
_________________ wer andern eine grube gräbt hat ein grubengrabgerät
- oder einfach zu viel zeit
|
|
SAiBOT 
      
Beiträge: 323
Erhaltene Danke: 6
XP SP2; 7
D7; D2009
|
Verfasst: 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 |
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 
_________________ Debuggers don't remove bugs, they only show them in slow-motion.
|
|
uall@ogc
      
Beiträge: 1826
Erhaltene Danke: 11
Win 2000 & VMware
Delphi 3 Prof, Delphi 7 Prof
|
Verfasst: 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
_________________ wer andern eine grube gräbt hat ein grubengrabgerät
- oder einfach zu viel zeit
|
|
SAiBOT 
      
Beiträge: 323
Erhaltene Danke: 6
XP SP2; 7
D7; D2009
|
Verfasst: Di 26.08.08 17:12
_________________ Debuggers don't remove bugs, they only show them in slow-motion.
|
|
uall@ogc
      
Beiträge: 1826
Erhaltene Danke: 11
Win 2000 & VMware
Delphi 3 Prof, Delphi 7 Prof
|
Verfasst: 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)
_________________ wer andern eine grube gräbt hat ein grubengrabgerät
- oder einfach zu viel zeit
|
|
SAiBOT 
      
Beiträge: 323
Erhaltene Danke: 6
XP SP2; 7
D7; D2009
|
Verfasst: 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 
_________________ Debuggers don't remove bugs, they only show them in slow-motion.
|
|
|