Autor |
Beitrag |
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: Fr 09.06.06 11:51
Die uallCollection unterstützt mehrere Hook-Typen: 1. IAT (Import API Table) als auch Code Hooks. Die im eigenen Einsatz stabiliere Version war IMHO die IAT-Variante.
@SendInput: In der uallCollection gibt es eine vereinfachte Version für IAT, die nur das Modulhandle und den Funktionsnamen, sowie die neue Funktion wissen will. Ich weiß aber nicht, ob die nur im Omorphia Repo enthalten ist, oder ob uall die offiziell übernommen hat ...
@Process Injection: Es ist stabiler die DLL zu injecten ... Man beachte dazu auch den Kommentar im Source zu InjectMe ... Liegt im wesentlichen daran, dass u.U. das Patchen der Relocations unvollständig erfolgt (von Hand) und es dadurch zu Problemen bei der Ausführung der injecteten EXE kommt ...
_________________ 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.
|
|
uall@ogc 
      
Beiträge: 1826
Erhaltene Danke: 11
Win 2000 & VMware
Delphi 3 Prof, Delphi 7 Prof
|
Verfasst: Fr 09.06.06 13:05
BenBe hat eigentlich schon alles gesagt.
1) Extended Code Overwriting ist einfach die Funktion uallHook.HookCode mit 3 Parametern. Die Adresse wo gehookt werden soll, die wo er hinsprigen soll und die, die man anstatt der original Funktion aufrufen muss damit man in keine Endlosschleife läuft.
2) Schau dir einfach die Beispiele an. Ich hab für Importhook/Relocationhook/Codehook[Codeoverwriting]/PageGguardhook usw. die Sourcen drin, wie man es machen sollte.
3) Ja, ich habe auch eine funktion InjectMe gemacht. Diese lädt die Exe die aufgerufen wurde in den Zielprozess und startet eine angegebene Funktion. Das herstelen der Relocation/Importtabelle ist nicht das Problem. Man muss aber nur beachten, dass kein Initialization Teil (ob nun von System.pas Sysutils.pas oder ein eigener) aufgerufen wird. Es wird lediglich die Funktion aufgerufen die man angibt. Inwiefern da jetzt Fehler auftreten können, weiß ich selbst nicht genau. Ein Beispiel mit InjectMe ist der SimpleWallhack.
_________________ 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 01.08.06 18:07
Alle Links sind down  .
Edit:
was fürn glück gehen wieder  !
|
|
Julian W.
      
Beiträge: 47
Win 2000
D7 Enterprise
|
Verfasst: Mi 14.02.07 22:43
Erstma meinen Glückwunsch!  Das ist echt ne hammer geile Sammlung und endlich mal was in der Richtung, was nicht kompliziert ist wie sonstwas xD
So jetz meine Frage: Wie soll ma denn die Funktion HidelibraryNT() benutzen? Also ich weiß nich was ich da fürn libraryhandle angeben soll... Angenommen ich injecte die dll etc. wie soll ich da das handle rausbekommen?
Greetz Julian
|
|
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: Mi 14.02.07 22:52
Lass die DLL doch sich selber Hiden ... Handle für das aktuelle Modul (die DLL für sich selbst) sollte sie mit GetModuleHandle(nil); bekommen.
_________________ 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.
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Mi 21.02.07 14:15
das hier ist sche****
Delphi-Quelltext 1: 2: 3:
| dwProcessID2 := OpenProcess(PROCESS_ALL_ACCESS, False, dwProcessID); if (dwProcessID2 <> 0) then dwProcessID := dwProcessID2; |
entweder man nimmt ein ProzessHandle, ODER eine ProcessId. aber nicht beides auf einmal.
ich schaffe es jedenfalls nicht mehr, ne einfache DLL zu injecten (mithilfe der X funktionen).
GetLastError bringt immer "Falscher Parameter", ich glaube es liegt daran dass immer mehr processhandles auf die selbe pid geöffnet werden, bis irgendwann etwas nicht stimmt (closehandle wird erst aufgerufen, wenn die ganze inject-prozedur durch ist).
ausserdem muss man die dwWritten variable initialisieren, dies hat auch einen fehler bewirkt
Delphi-Quelltext 1: 2: 3: 4:
| if (pLLA <> nil) and (pTargetMemory <> nil) and (pLibraryName <> nil) then begin dwWritten := 0; if WriteProcessMemory(hProc,pTargetMemory,pLibraryName,dwMemSize,dwWritten) and |
|
|
uall@ogc 
      
Beiträge: 1826
Erhaltene Danke: 11
Win 2000 & VMware
Delphi 3 Prof, Delphi 7 Prof
|
Verfasst: Mi 21.02.07 14:37
zum OpenProcess: Meine Funktionen funktionieren mit dem ProzessHandle und der ID.
Failed OpenProcess isses egal und ich geh davon aus, dass ein ProzessHandle übergeben wurde und arbeite damit weiter.
Fun ktioniert das OpenProcess nehme ich das neue ProzessHandle und amch damit weiter, aber schließe das Handle am Schluss wieder mit CloseHandle
-> kein sche***
Und Seit wann muss ein Ausgabeparameter bei ReadProcessMemory/WriteProcessMemory initialisiert werden? Wird doch eh überschrieben. -> das ist sche***
_________________ wer andern eine grube gräbt hat ein grubengrabgerät
- oder einfach zu viel zeit
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Do 22.02.07 05:53
ich hab mir die aktuellste version aus dem omorphia cvs geholt, nun gehts.
die geschichte mit dem parameter find ich trotzdem ziemlich unsauber.
erstens verwirrt es einen aussenstehenden auf den ersten blick,
zweitens wird OpenProcess unnötig oft aufgerufen,
drittens ist es nicht die feine art übergabeparameter zu überschreiben.
sauberer wäre es z.b. so
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
| function CreateRemoteThreadX(dwProcessHandle: DWord; pThreadAttributes: Pointer; dwStackSize: DWord; pStartAddr: Pointer; pParameter: Pointer; dwCreationFlags: DWord; var dwThreadID: DWord; const Param1isPID : boolean = false): DWord; stdcall; var hProcess : DWord; begin Result := 0; dwThreadId := 0; hProcess := dwProcessHandle; if Param1isPID then hProcess := OpenProcess(PROCESS_ALL_ACCESS,false,dwProcessHandle); |
dann gibt es keine unklarheiten.
|
|
uall@ogc 
      
Beiträge: 1826
Erhaltene Danke: 11
Win 2000 & VMware
Delphi 3 Prof, Delphi 7 Prof
|
Verfasst: Do 22.02.07 09:20
Ja oder ich schmeiss den Support für ProzessHandles ganz raus. Die ProzessID sollte ja reichen, und wenn man nur ein Handle hat, kann man es mit der Funktion GetProcessID ja selbst in eine ID umwandeln. Wollte es nur für den Benutzer soeinfach wie möglich halten, dann muss der sich um nichts mehr kümmern. Und so eine InjectLibrary Funktion wird jetzt auch nicht so oft aufgerufen.
_________________ wer andern eine grube gräbt hat ein grubengrabgerät
- oder einfach zu viel zeit
|
|
Julian W.
      
Beiträge: 47
Win 2000
D7 Enterprise
|
Verfasst: Do 22.02.07 23:48
BenBE hat folgendes geschrieben: | Lass die DLL doch sich selber Hiden ... Handle für das aktuelle Modul (die DLL für sich selbst) sollte sie mit GetModuleHandle(nil); bekommen. |
Irgendwie funzt das nich... =(
Die dll bleibt sichtbar, wie vorher. Woran kann das liegen? Greetz Juli
|
|
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: Fr 23.02.07 14:43
Validiere einfach das Hooking durch ein paar ShowMessages, ob das ermittelte Handle korrekt ist. Ansonsten VirtualQuery auf eine beliebige Adresse innerhalb deiner DLL und dann davon die Basisadresse ermitteln (entspricht dem Modulhandle der DLL). Aber: Neue Frage  Neuer Thread. Bitte dort auch ein paar Source-Ausschnitte vom Hiding ergänzen.
_________________ 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.
|
|
uall@ogc 
      
Beiträge: 1826
Erhaltene Danke: 11
Win 2000 & VMware
Delphi 3 Prof, Delphi 7 Prof
|
Verfasst: Fr 23.02.07 15:34
änder mal die Zeile
Quelltext 1:
| LEA EBX, [EDX+$28] // if so get the library name |
in
Quelltext 1:
| LEA EBX, [EDX+$30] // if so get the library name |
ab
Dann sollte folgendes nicht mehr funktionieren:
Delphi-Quelltext 1: 2:
| HideLibraryNT(LoadLibraryA('opengl32.dll')); GetModuleHandle('opengl32.dll'); |
_________________ wer andern eine grube gräbt hat ein grubengrabgerät
- oder einfach zu viel zeit
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Fr 23.02.07 21:32
hi, ich hab mich vorgestern doch nicht getäuscht, es kann nämlich vorkommen (zumindest auf meinem System), dass OpenProcess ein Handle zurückliefert, obwohl der Parameter bereits ein handle ist (eine entsprechende PID existiert jedoch nicht). die processid in meinem beispiel ist 3269, als erstes handle kriege ich 1780 zurück, und bei virtualallocexx dann -> 1784. das hat zur folge dass virtualalloc scheitert und nil zurückliefert. in meiner momentanen Testumgebung liefert der erste Aufruf der Inject Funktion dadurch immer FALSE, beim zweiten durchlauf funktioniert es hingegen. anbei ein screenhshot, der parameter dwProcessId ist in ESI int3.at/virtualalloc.gifModeriert von Christian S.: img- in url-Tags umgewandelt. Der Screenshot sprengt das Layout.
|
|
0xCC
      
Beiträge: 150
|
Verfasst: Fr 23.02.07 23:07
bugfix:
in allen uall-units folgende such und ersetzen prozedur vornehmen
aus Quelltext 1:
| if (dwProcessID2 <> 0) then |
mach Quelltext 1:
| if (dwProcessID2 <> 0) and (isValidProcessHandle(dwProcessID2) then |
alle einträge ersetzen, aber einzeln durchgehen und WENN FOLGENDE ZEILE folgt, ersetzen:
Quelltext 1:
| dwProcessID := dwProcessID2; |
folgende funktion in der uallkernel.pas einfügen und deklarieren:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8:
| function isValidProcessHandle(hProcess : DWORD):Boolean; var temp : DWORD; begin result := false; temp := GetProcessId(hProcess); if (temp <> 0) and (GetProcessVersion(temp) <> 0) then result := true; end; |
zusätzlich muss noch folgender bereich der uallkernel.pas auskommentiert werden:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:
| function GetProcessID(dwProcessHandle: DWord): DWord; stdcall; begin if isNt then Result := GetProcessIDNT(dwProcessHandle) else Result := GetPRocessID9X(dwProcessHandle); end; |
edit:
es könnte allerdings sein, dass prozeduren in der uallcollection, die die function GetProcessID verwenden, nicht mehr das gewünschte ergebnis erhalten. diese wären dann mit isValidProcessHandle(hProcess : DWORD) erst zu prüfen.
hier kann man nach folgendem suchen und ersetzen:
Quelltext 1:
| dwProcessID := GetProcessID(dwProcessID); | =>
Quelltext 1:
| if isValidProcessHandle(dwProcessID) then dwProcessID := GetProcessID(dwProcessID); |
|
|
RedBaron2k7
      
Beiträge: 25
SuSE Linux, Windows XP
BDS06
|
Verfasst: So 15.04.07 22:23
gibt es einen funktionierenden Link zu einer aktuellen Version?
Bei mir funktionieren die Links alle nicht 
|
|
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: Mo 16.04.07 00:56
Lad Dir die Dateien bei SourceForge aus dem Repo von Omorphia: omorphia.svn.sourcef...runk/uallCollection/
_________________ 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.
|
|
RedBaron2k7
      
Beiträge: 25
SuSE Linux, Windows XP
BDS06
|
Verfasst: Mo 16.04.07 13:36
|
|
elzumo
      
Beiträge: 20
WindowsXP pro
Delphi 2007, Dreamweaver CS3, Eclipse
|
Verfasst: Do 25.10.07 21:06
Beide Links sind leider Defekt, würde mich freuen, wenn jemand so freundlich ist und mir due uallCollection noch ein Mal hochlädt.
|
|
elzumo
      
Beiträge: 20
WindowsXP pro
Delphi 2007, Dreamweaver CS3, Eclipse
|
Verfasst: Do 31.01.08 11:35
*push* 
|
|
_frank_
      
Beiträge: 343
Erhaltene Danke: 1
Win XP
Delphi 3 Prof / Turbo Delphi Explorer
|
Verfasst: Do 31.01.08 17:04
@elzumo: hast du das posting vor deinem ersten gelesen???
der SVN-Link funktioniert weiterhin...
Frank
_________________ EB FE (die wahrscheinlich kürzeste Endlosschleife der Welt  )
BA 01 00 00 00 52 EB 09 BB 4D 11 86 7C FF D3 EB 0D E8 F2 FF FF FF 63 68 61 72 6D 61 70 00 C3
|
|