Entwickler-Ecke
Open Source Projekte - uallHook, uallProtect, uallDisasm, uallKernel, uallUtil etc.
uall@ogc - Di 29.03.05 17:06
Titel: uallHook, uallProtect, uallDisasm, uallKernel, uallUtil etc.
uallHook, funktion zum injecten von dlls in andere prozesse, hooken von APIs durch importtabelle, oder JMP hook
uallDisasm, Disassembler (noch nicht gant fertig)
uallKernel, kernel funktionen selbst geschrieben, GetProcAddress, LoadLibrary und funcktionen die unter win9x nicht möglich waren
OpenthreadX oder CreateRemoteThreadX
uallUtil, kleine funktionen wie ExtractFilePath UpperCase etc. für nen kleine EXE
uallProtect, kleinere AntiDebugger funktionen (nicht zu ernst nehmen ;>) verstecken von dlls, debug privilegien bekommen etc.
http://uall.overclock.ch/uallCollection/
http://cvs.sourceforge.net/viewcvs.py/omorphia/uallCollection/
F34r0fTh3D4rk - Di 29.03.05 17:37
uallutil -> alles was man so braucht ^^
besser als immer alles rauszukopieren, um nicht die sysutils einbinden zu müssen ^^
nette sammlung 8)
mimi - Do 14.04.05 10:41
sysutils -> macht die dann so viel aus ? ich dachte immer die Forms.pas macht soviel aus :?:
F34r0fTh3D4rk - Do 14.04.05 19:22
ja die erst recht, aber in ner dll brauch man die meistens eh net ^^
mimi - Do 14.04.05 19:31
Tino: Frage gelöscht :? (Weiß nicht wie ich den beitrag löschen kann(meinen))
Tino - Do 14.04.05 20:59
Bitte klärt das in einem seperaten Topic oder per PN. Hier geht es um das Projekt von uall@ogc!
retnyg - Do 21.04.05 19:10
ich wollte grade mal deine uallProcess.pas ausprobieren.
bei delphi 5 gibt er mir einen fehler zurück (uallprotect):
Quelltext
1: 2:
| @muell: DB $0F DB $80 |
undefinierter bezeichner DB
bei delphi7 gehts, aber erst nachdem ich das hier geändert habe:
Quelltext
1:
| function GetOwnModuleHandle: cardinal; stdcall; |
war erst auf integer ^^
uall@ogc - Do 21.04.05 19:32
den fehler mit GetModuleHandle werde ich beheben wurde mir heute schonmal gesagt
das mit dem DB ist bischen blöd ic weiß nicht wie man sonst einfach ein byte in den code einfügen kann
uall@ogc - Do 21.04.05 19:40
Hab das mal bei delphi 3 getestet:
funktioniert da einwandfrei :shock:
retnyg - Do 21.04.05 20:38
ich habe es nun geändert zu:
Delphi-Quelltext
1: 2: 3: 4:
| @muell: DB $0F, $80 @weiter: RDTSC |
nun frisst er das DB, bleibt dafür aber bei RDTSC hängen: inline assembler syntaxfehler
den befehl kann man sicher durchn bytecode ersetzen
uall@ogc - Do 21.04.05 22:15
RDTSC kennt der nicht, müsste mal opcode dafür raussuchen dann sollte es gehen
retnyg - Di 26.04.05 18:07
so ich hab das mal geändert so dass das ganze auch unter delphi 5 rennt:
uallprotect.pas hat folgendes geschrieben: |
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:
| procedure ProtectCall(proc: pointer); stdcall; asm MOV EBX, [EBP+4] PUSH EBX MOV EAX, proc XOR EAX, EBP PUSH EAX XOR EAX, EAX TEST EAX, EAX JNZ @muell JNZ @muell2 JMP @weiter @muell: DB $0F, $80 @weiter: DW $310F MOV ECX, EAX MOV EBX, EDX JMP @weiter2 @muell2: DB $0F, $80 @weiter2: DW $310F SUB EAX, ECX SUB EDX, EBX NEG EDX XOR EAX, EDX SHR EAX, 8 XOR EBP, EAX @ende: POP EAX XOR EAX, EBP POP EBX POP EBP POP ECX MOV [ESP], EBX JMP EAX end;
function IsDebuggerPresent: boolean; stdcall; asm MOV EAX, FS:[$18] MOV EAX, [EAX+$30] DB $0F, $B6, $40, $02 end; |
|
desweiteren habe ich deiner uallprocess.pas noch die prozedur killprocess verpasst.
was noch fehlt ist eine funktion, mit der man geladene Module eines Prozesses (injizierte Dll's) über ihr hModule Handle killen kann. bin aber leider nicht fündig geworden, vielleicht fällt dir ja was ein.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:
| function KillProcess(pid: integer): boolean; stdcall; var procHnd: THandle; begin result := false; if pID <> 0 then begin procHnd := OpenProcess (PROCESS_TERMINATE or PROCESS_QUERY_INFORMATION, False, pID); if procHnd <> 0 then begin result:= TerminateProcess(procHnd, 0); end; end; end; |
retnyg - Di 26.04.05 23:08
mir ist da noch ein bug untergekommen:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14:
| function DeleteExe(s: string): string; var i, j: integer; begin setlength(result,length(s)); result := ''; j := 0; for i := 1 to length(s) do begin if (copy(s,i,5) = ('.EXE'#13#10)) then j := 4; if (j > 0) then dec(j) else result := result+s[i]; end; end; |
da muss ne 6 hin
uall@ogc - Di 26.04.05 23:18
jo richtig war vorher durch simiko,on getrennt ich hab da schon so viel geändert neue version upp ich mal jetzt
RDTSC für delphi 5 hab ich noch nicht geändert und deine funktion auch noch nicht eigneabut werde ich morgen mal machen, habe ausserdem paar neue schöne funktionen und bugfixes die ich auch noch adde wenn ich in den nächsten tagen zeit habe,
das mit dem copy hab ich aber eben geändert ausserdem faslcher header für GetOwnModuleHandle
desweiteren hat uallProtect die funktion IsHooked wo man eine API angeben kann und dann geprüft wird ob die per Import/Export/oder jump hook gehooked wurde
uall@ogc - Mi 27.04.05 19:10
neue Version ist up, habe auch einige bugs gefixed
ausserdem hab ich es mal geschafft auf die schnelle 5 beispiele zu erstellen
1) CodeHook
2) Dll inejction
3) ProzessListe
4) HideLibray und ForceLoadLibrary
5) Disassembler
retnyg - Fr 29.04.05 20:47
mal ne frage: ich habe mir nen hook für CreateFileW zusammengeschustert, es passiert aber nix (z.b. wenn man mit notepad was speichert, wird diese funktion aufgerufen).
an was kann das liegen ? ausserdem wird nextCreateFile nie was zugewiesen, habe das aber eigentlich 1 zu 1 von deinem beispiel abgekupfert.
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:
| program hooktest; {$APPTYPE CONSOLE} uses windows, uallhook, uallutil;
type TCFfunc = function(lpFileName:pchar; dwDesiredAccess, dwShareMode:DWORD; lpSecurityAttributes: pointer; dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile: DWORD): DWORD; stdcall;
var oldCreateFile, nextCreateFile: tcffunc;
function myCreateFile(lpFileName:pchar; dwDesiredAccess, dwShareMode:DWORD; lpSecurityAttributes: pointer; dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile: DWORD): DWORD; stdcall;
begin writeln(lpfilename^); result := nextCreateFile(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile); end;
var p:pointer;
begin p := GetProcAddress(GetModuleHandle('kernel32.dll'),'CreateFileW'); if p <> nil then begin @oldCreateFile := p; uallHook.HookCode(@oldCreateFile,@myCreateFile,@nextCreateFile); while true do begin sleep(10); end; end else writeln('fehler'); readln; end. |
retnyg - Sa 30.04.05 13:16
kann es sein, dass deine hook-unit nur lokal, nicht systemweit funktioniert?
oder muss ich den systemweiten hook wie gehabt in eine dll auslagern ?
uall@ogc - Sa 30.04.05 14:39
unter NT systemen hat jeder prozess seine eigene DLL, d.h. jeder prozess hat die kernel32.dll / ntdll.dll etc.
d.h. du kannst keinen globalen API hook machen wie unter 9x
also mussu den code in eine dll auslagern und diese in JEDEN prozess laden
uall@ogc - Sa 30.04.05 16:23
hab hier mal nen kleinen globalen hook gemacht, der alles was mit TextOutW ausgegeben wird spiegelt
F34r0fTh3D4rk - Sa 30.04.05 16:44
bei mir ist net immer alles umgekehrt und wenn ich mit der maus drüber gehe, wirds invertiert, egal wie rum es ist (auch irgendwie logisch, da das dann nochmal ausgegeben wird, aber merkwürdig, dass dann da manchmal der richtige text steht !?)
aber lustig :)
uall@ogc - Sa 30.04.05 16:50
jo dann benutzt windows noch andere APIs zum textanzeigen, frag mich aber net welche oO
F34r0fTh3D4rk - Sa 30.04.05 16:51
aber irgendwie blödsinnig, das es noch andere gibt, aber die werden wohl am besten wissen warum :lol:
uall@ogc - Sa 30.04.05 16:55
könnte aber auch sein das die funktion das 2 mal umdreht oO und somit wieder normal ist
F34r0fTh3D4rk - Sa 30.04.05 18:05
stimmt, einmal beim normalen und dann das, was im fenster steht und nicht die interne variable, also zb nicht:
Delphi-Quelltext
1: 2:
| drehum(variable); edit1.text:= variable; |
sondern
Delphi-Quelltext
1: 2:
| edit1.text:= variable; drehum(edit1.text); |
:D
retnyg - Di 03.05.05 19:43
uall@ogc hat folgendes geschrieben: |
hab hier mal nen kleinen globalen hook gemacht, der alles was mit TextOutW ausgegeben wird spiegelt |
vielen dank, ich habs endlich hinbekommen CreateFileW zu hooken :)
äussert interessant wäre nun auch eine UnInject funktion oder so, damit man die DLL bei programmende entladen kann...hast du in die richtung etwas geplant ?
mael - Di 03.05.05 21:30
Schöne Sachen. Besonders der Disassembler interessiert mich. :les:
Versuche auch sowas, und habe dabei im Prinzip einfach die Tabelle des Intel-Manuals in Delphi Code übersetzt: Viel Arbeit, wenig Denken :wink:
Hast Du irgendwelche Quellen die Dir sonst noch hilfreich waren außer Intel/AMD und NASM?
retnyg - Mi 04.05.05 03:24
hmm...mir treten sporadisch abstürze der "befallenen" prozesse auf :evil:
wie debuggst du deine dlls ? mit "mit prozess verbinden" klappt das nicht so ganz...
edit: n paar push's und pop's haben das problem behoben...ne debug-möglichkeit wär aber trotzdem gut
uall@ogc - Mi 04.05.05 16:45
@retnyg:
du musst auf passen wenn due dll in alle prozesse injezierst, dann darfst du KEINE statsichen imports haben d.h. nur die unit windows einbinden. wenn du die sysutils einbindest, hat windows autoamtisch nen import von der user32.dll die aber nicht in allen prozessen vorhanden ist -> die prozesse crashen.
also musst dir die dynamsch laden oder du schmeist das getdebugprivilege raus dann bekommste auch nur prozesse mit openprocess geöffnet wo auch die user32.dll schon geladen ist.
@mael: ich habe jeden einzelen opcode ausprobiert und in delphi debugged mit
asm
DB $00 $00 $00 $00 $00
end;
usw. da ich immer nur wiedersprüche gefunden habe
b0rg 0.9 hat aber auch tabellen die man benutzen kann aber da stimmt auch einiges nicht,
also ich habs ohne das intelmanuel gemacht
dafür hab ich aber noch die extended code table nicht (0xF0) wenn ich mal zeit habe mach ich daran weiter
F34r0fTh3D4rk - Fr 06.05.05 14:10
1337 h00k :D R4mmst31n r0x 8) numb/encore auch :wink:
retnyg - Sa 07.05.05 20:58
muss nochmal nachhooken...
kannst du ma nen tip zum debuggen der hook-dlls geben ?
und ist ne UnInject funktion geplant ?
uall@ogc - So 08.05.05 10:41
UnInject hab ich gestern fertig gemacht genau wie UnHook und GlobalInjectLibray / GlobalUnloadLibrary
sources kommen im laufe des tages on
hier ide neuste version die hooken/enthooken kann
und neta auf win9x benutzen sonst crashed es :)
http://www.uall.info/files/1337.zip
uall@ogc - So 08.05.05 18:12
update:
- added 1337 global hook example (winNT only)
- added GlobalInjectLibrary
- added UnhookCode
- added GlobalUnloadLibrary
- added UnloadLibrary
downloadlink 1. post
maps - Mi 11.05.05 20:35
Sehr beeindruckend, uall!
Auf einen API-Hook wie deinen habe ich schon lange gewartet!
Derzeit spiele ich mit den verschiedensten API-Calls rum, um die gebotenen Möglichkeiten alle überhaupt verstehen zu können.
Jetzt bin ich allerdings bei
"GetCursorPos" [
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/cursors/cursorreference/cursorfunctions/getcursorpos.asp] angelangt und ich weiss nicht, wie ich dort "lpPoint" manipulieren kann.
Hier ist der entsprechende Teil, welcher nicht funktionieren will:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9:
| function myGetCursorPos(lpPoint: Pointer): Boolean; stdcall; var CurPos: TPoint; begin CurPos.X := 123; CurPos.Y := 123; lpPoint := @CurPos; Result := True; end; |
Bei aktiviertem API-Hook bekomme ich allerdings bei "lpPoint" immer X = 0 und Y = 0 ausgegeben - der Pointer hat also nicht funktioniert.
Es wäre schön, wenn du mir weiterhelfen könntest!
Mach weiter so!
Mappelchen
retnyg - Mi 11.05.05 20:48
so sollte es gehen
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9:
| function myGetCursorPos(lpPoint: Pointer): Boolean; stdcall; var CurPos: TPoint; begin @curpos := lpPoint; CurPos.X := 123; CurPos.Y := 123; Result := True; end; |
oder so:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9:
| function myGetCursorPos(lpPoint: PPoint): Boolean; stdcall; var CurPos: PPoint; begin curpos := lpPoint; CurPos^.X := 123; CurPos^.Y := 123; Result := True; end; |
maps - Mi 11.05.05 20:59
Vielen Dank für deine Antwort, retnyg!
Leider bekomme ich bei deinem Vorschlag allerdings die Fehlermeldung
"Left side cannot be assigned to".
Ich benutze Borland Delphi 6 Personal Edition.
Edit:
Dein zweiter Vorschlag wird zwar tadellos kompiliert, jedoch bekomme ich weiterhin X = 0 und Y = 0 ausgegeben.
retnyg - Mi 11.05.05 21:10
dann muss es so gehen:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7:
| function myGetCursorPos(var lpPoint: TPoint): Boolean; stdcall; var begin lpPoint.x := 123; lpPoint.Y := 123; Result := True; end; |
bzw so
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7:
| function myGetCursorPos(var lpPoint: PPoint): Boolean; stdcall; var begin lpPoint^.x := 123; lpPoint^.Y := 123; Result := True; end; |
maps - Mi 11.05.05 21:22
Beide werden zwar ebenfalls fehlerfrei kompiliert, jedoch führen sie mich auch nicht zu dem gewünschten Ziel.
Deine erste Methode bringt meine Anwendung komplett zum Absturz und die zweite gibt wieder nur X/Y = 0 aus.
Ich benutze "uallCollection_08_05_05_1".
retnyg - Mi 11.05.05 21:57
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:
| library hook_2;
uses windows, uallhook;
type TCFfunc = function(lppoint:pointer):boolean; stdcall;
var oldCreateFile, nextCreateFile: tcffunc;
function myCreateFile(lpPoint:pointer):boolean; stdcall; begin tpoint(lppoint^).x := 123; tpoint(lppoint^).y := 123; result := true; end;
var p:pointer;
begin p := GetProcAddress(GetModuleHandle('user32.dll'),'GetCursorPos'); if p <> nil then begin @oldCreateFile := p; uallHook.HookCode(@oldCreateFile,@myCreateFile,@nextCreateFile); end; end. |
bei mir gehts so, logischerweise aber nur, wenn die anwendung, die den getcursorpos test macht, bereits vor dem start des inject-programmes (exemain) geladen ist
uall@ogc - Mi 11.05.05 22:06
ich weiß nicht warum ihr das so kompliziert macht, in der windows pas stehen doch alle header drin:
Delphi-Quelltext
1:
| function GetCursorPos(var lpPoint: TPoint): BOOL; stdcall; |
das würde dann so etwas aussehen:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:
| var oldGetCursorPos, nextGetCursorPos: function(var lpPoint: TPoint): BOOL; stdcall;
function myGetCursorPos(var lpPoint: TPoint): BOOL; stdcall; begin result := true; lpPoint.x := 123; lpPoint.y := 123; end;
|
uall@ogc - Mi 11.05.05 22:16
so habs hier nochmal getestet:
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:
| var oldGetCursorPos, nextGetCursorPos: function(var lpPoint: TPoint): BOOL; stdcall;
function myGetCursorPos(var lpPoint: TPoint): BOOL; stdcall; begin result := true; lpPoint.x := 123; lpPoint.y := 123; end;
procedure TForm1.FormCreate(Sender: TObject); var lp: Tpoint; begin @oldGetCursorPos := GetProcAddress(GetModuleHandle('user32.dll'),'GetCursorPos'); uallHook.HookCode(@oldGetCursorPos,@myGetCursorPos,@nextGetCursorPos);
GetCursorPos(lp); form1.caption := inttostr(lp.X)+' '+inttostr(lp.Y); end; |
funktioniert einwandfrei
man kann immer die header aus der windows.pas bzw andere vordefinierte header nehmen, es ist egal wie diese aussehen
maps - Mi 11.05.05 22:29
Eben habe ich noch einen Fehler im Code gefunden,
welcher eigentlich richtige Werte als ungültig (X/Y = 0) darstellte.
Alles funktioniert nun einwandfrei - man darf lediglich das "var" in
function XXXGetCursorPos(var lpPoint: TPoint): BOOL; stdcall;nicht vergessen! :wink:
Vielen Dank, retnyg und uall!
maps - Sa 14.05.05 01:08
Hallo,
Ich habe leider ein weiteres Problem:
Ich möchte "
SystemParametersInfo [
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/systemparametersinfo.asp]" manipulieren.
Das gelingt mir soweit auch, allerdings crasht es beim "Unloaden" jedesmal die Programme.
Ich habe die Funktionen auf ihr Minimum reduziert und zudem nur das "1337 global hook" Beispiel abgeändert, um die möglichen Fehlerquellen zu minimieren.
Jedoch kann ich mir nicht erklären, weshalb es beim "Unloaden" immer zu einem Crash kommt.
Hier ist der Loader:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19:
| program exemain;
uses windows, uallHook, uallUtil;
begin if paramcount < 1 then MessageBox(0,'No Param, use PARAM -load / -unload.',Nil,0) else
if uppercase(paramstr(1)) = uppercase('-load') then GlobalInjectLibrary(pchar(uallUtil.GetExeDirectory+'hook.dll')) else
if uppercase(paramstr(1)) = uppercase('-unload') then GlobalUnloadLibrary(pchar('hook.dll')) else
MessageBox(0,'Wrong Param, use PARAM -load / -unload.',Nil,0); end. |
Und hier der Hook:
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:
| library hook;
uses windows, uallHook;
var oldSystemParametersInfoA, oldSystemParametersInfoW, nextSystemParametersInfoA, nextSystemParametersInfoW: function(uiAction, uiParam: UINT; pvParam: Pointer; fWinIni: UINT): BOOL; stdcall;
function mySystemParametersInfoA(uiAction, uiParam: UINT; pvParam: Pointer; fWinIni: UINT): BOOL; stdcall; begin Result := nextSystemParametersInfoA(uiAction, uiParam, pvParam, fWinIni); end;
function mySystemParametersInfoW(uiAction, uiParam: UINT; pvParam: Pointer; fWinIni: UINT): BOOL; stdcall; begin Result := nextSystemParametersInfoW(uiAction, uiParam, pvParam, fWinIni); end;
procedure injectmain; var h: integer; begin h := GetModuleHandle('user32.dll'); if h > 0 then begin @oldSystemParametersInfoA := GetProcAddress(h, 'SystemParametersInfoA'); If @oldSystemParametersInfoA <> Nil then uallHook.HookCode(@oldSystemParametersInfoA, @mySystemParametersInfoA, @nextSystemParametersInfoA); @oldSystemParametersInfoW := GetProcAddress(h, 'SystemParametersInfoW'); If @oldSystemParametersInfoW <> Nil then uallHook.HookCode(@oldSystemParametersInfoW, @mySystemParametersInfoW, @nextSystemParametersInfoW); end; end;
procedure uninjectmain; begin uallHook.UnhookCode(@nextSystemParametersInfoA); uallHook.UnhookCode(@nextSystemParametersInfoW); end;
procedure dllmain(dwReason: integer); begin case dwreason of DLL_PROCESS_ATTACH: injectmain; DLL_PROCESS_DETACH: uninjectmain; end; end;
begin DLLProc := @DLLMain; DLLMain(1); end. |
Wäre schön, wenn ihr eine Erklärung (besser noch: Lösung) parat habt.
Danke!
uall@ogc - Sa 14.05.05 11:00
ich schau mir das gleich mal an aber du könntest beim unhook schaun ob uallHook.UnhookCode auch funktioniert hat weil wenn die dll entladen wird aber immer noch gehookt ist crashed es natürlich
maps - Sa 14.05.05 11:31
Nein, "UnhookCode" meldet bei beiden Aufrufen "False".
uall@ogc - Sa 14.05.05 11:45
Delphi-Quelltext
1: 2: 3:
| var oldSystemParametersInfoA, oldSystemParametersInfoW, nextSystemParametersInfoA, nextSystemParametersInfoW: function(uiAction, uiParam: UINT; pvParam: Pointer; fWinIni: UINT): BOOL stdcall = nil; |
Delphi-Quelltext
1: 2: 3:
| if @nextSystemParametersInfoA <> nil then if uallHook.UnhookCode(@nextSystemParametersInfoA) then |
kannste das mal so abändern und mir sagen welches programm z.b. crashed damit ich das mal selbst testen kann?
maps - Sa 14.05.05 12:00
Bei
Delphi-Quelltext
1: 2: 3:
| var oldSystemParametersInfoA, oldSystemParametersInfoW, nextSystemParametersInfoA, nextSystemParametersInfoW: function(uiAction, uiParam: UINT; pvParam: Pointer; fWinIni: UINT): BOOL stdcall = nil; |
bekomme ich "Cannot initialize multiple variables", auch nachdem ich ein Semikolon hinter "BOOL" gesetzt habe.
Ansonsten habe ich es nun ein weiteres Mal getestet und trotzdem stürzen die Programme ab.
Es stürzen alle Prozesse mit Fenstern ab, sobald irgendeine Aktion auf ihren Fenstern durchgeführt werden soll.
Ich habe zB. einfach auf "Explorer.exe"'s "Start"-Button geklickt und schon ist der Prozess abgestürzt.
"Winlogon.exe" stürzt zB. beim Herunterfahren ab, also sobald es selber ein Fenster generiert.
uall@ogc - Sa 14.05.05 12:15
das mit dme nil is klar das es net geht ;P mein fehler ich teste mal eben selber
maps - Sa 14.05.05 12:19
Ich habe soeben den Fehler gefunden.
Ich benutze die "
Key Objects Library [
http://bonanzas.rinet.ru/]" und zu der gibt es auch noch Replacements für "SysInit", "System", "SysUtils", "Classes", etc., um die Größe noch weiter zu reduzieren.
Ich habe jetzt einfach mal testweise alle Replacements entfernt, beide Binaries neu kompiliert und schon gab es diese Crashes nicht mehr.
Ich werde nun die Fehlerquelle weiter eindämmen, um genau zu wissen, welche PAS/DCU-Datei für die Crashes verantwortlich ist.
Edit:
Es liegt an dem "SysInit" Replacement.
uall@ogc - Sa 14.05.05 12:35
ja pass auf ich habs auch getestet bei mir gehts.
wichtig ist das du in der dll nur STATISCHE imports von der KERNEL32.DLL hast.
keine anderen! das liegt daran das die dll auch in system prozesse geladen wird die nur die ntdll.dll und kernel32.dll geladen haben. sollte deine dll da irgendwelche komischen dlls statisch laden kanns crashen wenn se beim unloaden oder so nicht auch entladen werden.
ich weiß auch nicht was die keyobject library macht (ich schaus mit mal an) aber in der hookdll nur die windows.pas benutzen alles andere dynamisch einbinden und versuchen kaum neue dlls zu laden
ansonsten mussu das GetDebugPrivilege rausnehmen, dann wird nich in systemprozesse injected.
uallProcess ruft immer GetDebugPrivilege beim start auf. vielleicht sollte ich das mal ändern.
nen veruschs isses wert das mal zu entfernen und schaun obs dann geht.
maps - Sa 14.05.05 12:51
Auch bei auskommentiertem "GetDebugPrivilege" und KOL's "SysInit" Replacement kommt es zum Crash.
Aber der Fehler ist ja nun eigentlich gelöst - ich benutze einfach nicht mehr das "SysInit" Replacement.
Vielen Dank!
maps - So 15.05.05 12:00
Dir ist schon aufgefallen, dass in dem Dateinamen ein Datum vorhanden ist und dein Link folglich zu einer veralteten Version führt?
reepo2k - Mo 16.05.05 21:03
Wär seht nett, wenn das mit dem Link gefixt wird, würd mich sogar bereiterklären das File zu hosten.
MfG: reepo2k
uall@ogc - Mo 16.05.05 21:59
hatte ich doch heute mittang schon geändert :)
war nur so weil der source in die code sparte bei delphipraxis reinkam und ich da nen fixen link nehmen musste damit ich da immer alles uppen kann
also ohne ein datum isses jetzzt immer,hab das jetzt mal dahinter geschrieben
retnyg - Mo 16.05.05 23:39
vielen dank für die unhook funktion ! :D
hast du an der process und protect unit auch was geändert (weil ich da schon einiges geändert habe, noch bei der 27.04er version) ?
uall@ogc - Mo 16.05.05 23:46
ausser dass ich die funktionen hinzugefügt habe hab ich sonst nichts verändert im gegensatz zu der verion davor.
hatte in der version davor halt die bugs gefixt.
aber ich schreib das besser nächtes mal dazu
retnyg - Mo 16.05.05 23:54
vielleicht denkst du beim nächsten update noch daran ein paar assembler-befehle der uallprotect.pas zu hardcoden, weil mein delphi5 frisst deine doppel-DB statements nicht, und auch bei MOVZX kommt ein fehler:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19:
| @muell: DB $0F, $80 @weiter: DW $310F MOV ECX, EAX MOV EBX, EDX JMP @weiter2 @muell2: DB $0F, $80
function IsDebuggerPresent: boolean; stdcall; asm MOV EAX, FS:[$18] MOV EAX, [EAX+$30] DB $0F, $B6, $40, $02 end; |
retnyg - Mi 22.06.05 00:55
GlobalUnloadLibrary('nirvana.dll'); -> BSOD
F34r0fTh3D4rk - Mi 22.06.05 12:26
ja alles unter delphi 6 (also bis einschließlich delphi 5) scheints so ziemlich überall noch probleme zu geben :idea:
BenBE - Mi 22.06.05 17:11
Delphi 5 kommt schon mit MOVZX zurecht, jedoch will der Assembler die korrekte Größe wissen.
Wäre in besagtem Fall BYTE PTR ...
@uall: Hab ich Dir doch aber schonmal gesagt, dass Größenangaben für einige Befehle nicht schlecht wären.
@RDTSC: Kann D5 wirklich nicht ^^
maurits - Di 28.06.05 12:02
Titel: mehr info uber Delphi inline RDTSC asm command
Probiere diese link fur mehr info uber Delphi inline RDTSC asm command:
http://www.geocities.com/izenkov/howto-rdtsc.htm
PS: Entschuldigung fur mein sprache, aber ich bin Holländisch.
uall@ogc - Mo 04.07.05 09:09
ich werd das alles im laufe der woche mal beheben, aber bei dem wetter kommt man ja nicht dazu, das mit dem bluescreen, haste die dll vorher injected odereinfach nur irgend ne dll zum spass entladen die gar nicht existiert?
retnyg - Di 05.07.05 02:23
uall@ogc hat folgendes geschrieben: |
das mit dem bluescreen, haste die dll vorher injected odereinfach nur irgend ne dll zum spass entladen die gar nicht existiert? |
ich hab das probiert mit ner dll die nicht existiert, und mit ner dll die ich vorher injected habe (global).
mit einer anderen dll, die auf meinem rechner rumhängt (cmdlineext03.dll) geht das entladen(beim ersten mal), die ist allerdings nur in explorer.exe geladen.
retnyg - Mo 08.08.05 18:56
brech.. äh uall bissu schon dahintergekommen warum der kernel crasht wenn man ne nicht geladene DLL unloaden will ? habe gerade gesehen dass in der aktuellen uallCollection noch die alte hook.pas drin is :/
uall@ogc - Mo 08.08.05 19:02
wenn ich z.b.
Delphi-Quelltext
1:
| GlobalUnloadLibrary('nirvana.dll'); |
aufrufe bekomme ich keinen BS
kannst du bitte bei dir mal einzelschritt machen
d.h. einfach schaun bei welchem process der BS kommt?
retnyg - Mo 08.08.05 19:50
er stürzt beim aufruf von CreateRemoteThread ab, bei der 4. prozessID (csrss.exe)
habe aber zum testen die uallkernel vom 12.05 package genommen
//edit: habe das ganze auf einer VM getestet (XP SP1 unpatched)
uall@ogc - Mo 08.08.05 19:54
nimm mal bitte die neue uallHook, uallProtect und uallKernel
bei mir kam kein BS bei 2k und XP :/
retnyg - Mo 08.08.05 20:03
cool, damit gehts 8)
der fehler war scheinbar in der uallkernel o0
retnyg - Mo 08.08.05 20:25
zu früh gefreut: ich habe mal versucht ne dll von mir zu entladen (ist ein hook auf createfilew). die dll wurde auch mit der alten uallcollection erstellt
pserv2 ist das tool um die pipe des hooks auszulesen
kurz gesagt: unloadlibrary führt nicht direkt zu nem BS aber alle prozesse stürzen beim ersten zugriff ab :P
und der explorer crasht schlussendlich so dass das system neu bootet
Moderiert von
Narses: Anhang "hdhook.rar" wegen Virenverdacht gelöscht.
uall@ogc - Mo 08.08.05 20:32
du bist auch sicher das du alles wieder unhookst wenn die dll entladen wird?
wenn die nicht mehr im speiocher ist und es ist noch ein jumphook installiert dann srpingt der ja natürlich irgendwo in leeren speicher
retnyg - Mo 08.08.05 20:38
uall@ogc hat folgendes geschrieben: |
du bist auch sicher das du alles wieder unhookst wenn die dll entladen wird? |
wie ? UnhookCode ?
also erst unhook, dann globalunloadlibrary ?
wie kann ich dann eine fremde dll entladen, die sich in irgendeinen prozess eingeklinkt hat ? [url=
http://www.planet-smilies.de/]
[/url]
uall@ogc - Mo 08.08.05 20:46
nein du musst in dllmain prüfen ob die dll entladen wird (DLL_PROCESS_DETACH) und dann alle funktionen die du mit HookCode gehookt hast wieder enthooken (siehe meinem 1337 hook beispiel)
wolke - Fr 26.08.05 16:30
habe probleme beim kompilieren unter delphi5 - er kann mit
nichts anfangen (Invalid combination of opcode and operands, kommt mehrmals in uallHook vor). verwendet habe ich die uallCollection vom 8.8.05.
kann mir jemand helfen? :)
retnyg - Fr 26.08.05 16:34
wolke hat folgendes geschrieben: |
kann mir jemand helfen? :) |
Delphi-Quelltext
1:
| db $e8, $0, $0, $0, $0 |
uall@ogc - Fr 26.08.05 16:40
oder in
call dword [$00000000]
abändern
und ja ich werds mal ändern ;>
wolke - Fr 26.08.05 16:47
oh mann, ihr seid einfach zu schnell für die welt!
PPointer kennt delphi5 übrigens auch nicht, das konnte ich aber durch eine Typdeklaration beheben. jetzt stört er sich noch an:
Quelltext
1:
| CMP [ECX+$54], 00000001 |
(uallProtect, Zeile 498)
uall@ogc - Fr 26.08.05 16:49
fehlt auch ein dword vor der eckigen klammer
delphi7 nimmt automatisch immer ein dword wenn nichst vorsteht
delphi5 konnte das wohl noch net ;(
BenBE - Fr 26.08.05 17:24
Delphi-Quelltext
1:
| CMP DWORD PTR [...], $00000000 |
@uall: Hatten wir das nicht schon öfters, den Hinweis, dass DWORD PTR bitte anzugeben ist? Erspart unter D5 einige Unannehmlichkeiten mit Register-Größen ...
uall@ogc - Fr 26.08.05 17:34
ja aber ich weiß halt nicht wo überall der fehelr auftritt also muss ich mir erst delphi5 besorgen um zu testen was wp geändert werden muss
wolke - Fr 26.08.05 18:00
super, danke, klappt alles inzwischen.
sehe ich es richtig, daß so ein globaler API hook nur mit NT-systemen funktioniert?
uall@ogc - Fr 26.08.05 18:06
gibts nen kleines problem ;> wenn du kernel32 oder user32 unter 9x hookst, dann hookst du IMMER global demanch muss die dll in der die funktio nreinspringt auch global geladen sein (shared memory) sonst crashed dir das system
grundsätzlich sollte das injecten auch global auf 9x funktionieren, und hooken sollte da auch nicht dasproblem sein für funktionen die im speicherbereich unter 0x80000000 (shared area) liegen
retnyg - Mi 12.10.05 09:55
deine uallDisAsm unit läuft bei mir nur wenn ich obige zeile auskommentiere. ansonsten: ned schlecht ;)
gibts mal wieder was neues ?
wolke - Fr 25.11.05 18:53
das (globale) hooken scheint unter win64 nicht zu funktionieren... :(
uall@ogc - Fr 25.11.05 19:02
hooken der APIs? mit uallHook.HookCode? dann liegts daran, dass ich die assembler instructions mit deren opcodes noch nicht drinhabe, ohne win64 (mit entsprechendem PC) wird das auch nix
BenBE - Fr 25.11.05 19:16
@uall: Wenn alles gut geht, wir mein nächster PC Athlon 64, dann könnte ich das testen.
Genauso gibt es noch Probleme mit Hooks unter Win2K3. Ich wäre (da ich Teile von ualls Code für Omorphia nutze) dankbar, wenn jemand, der Win2K3 laufen hat, bitte mal eine genaue Fehlerursache des lokal Hooking auf kernel32.dll austesten könnte.
Wer Beispiel-Sourcen brauch:
Omorphia-Repo [
http://viewcvs.omorphia.de/] auschecken und das DebugInterface (Unit ODbgInterface) einbinden.
@uall: Oder gibt es da schon neue Releases, seit der Ver, die in Omorphia genutzt wird?
wolke - Fr 25.11.05 19:26
ich habe es mit der madCodeHooks library probiert, dort funktioniert das hooken ohne probleme.
ich selbst habe keinen 64bit-rechner, aber mein mitbewohner. ich stelle mich also gerne für tests zur verfügung.
gibt es nicht andere wege, als für jedes system individuell die library anzupassen? sonst steht mit vista gleich wieder die nächste änderung an...
uall@ogc - Fr 25.11.05 19:55
das liegt eher am prozessor und nicht am betriebssystem.
der disassembler kommt mit den neue OPcodes nicht klar, d.h. er weigert sich einfach bei den 64 bit ops die länge auszugeben, daher funktioneirt der hook nicht. ne einfache kernel API disassembly würde mir reichen. (z.b. CreateFileA/W)
wolke - Di 29.11.05 02:22
hat sich schon was ergeben? angebot zwecks 64bit steht noch (siehe PM).
uall@ogc - Mi 22.03.06 17:22
hihu
ich habe mal wieder viel gemacht, denk Link gibts im ersten Post.
Codehooking (mit code overwriting) funktioniert nun auch unter Win9x.
Ich mach noch die online erklärung ganz feritg, dann schau ich mir mal die 64bit Systeme an.
Henner - Mi 26.04.06 20:14
gibts ein Beispiel fuer InjectMe?
warum dllmain als parameter?
ich moechte code in eine exe einschleusen, damit ich dessen Fenster kopieren kann (z.B. von einem Service).
Ich habe wScripts die vom SQL-Server-Agent aus gestartet werden und sich aufhaengen - mit einer Messagebox...
Ich wuesste jetzt gern, was da steht...
gruss
Henner
uall@ogc - Do 27.04.06 01:34
Hi Henner.
InjectMe lädt die eigene EXE in den Speicherbereich eines anderen Programms. Es muss halt DLLmain angegeben werden weil die Funktion dann in dem ZielProzess aufgerufen wird (z.b. initalisation oder halt der code der ausgeführt werden soll)
Das ist aber ein kleiner Hack, erstell besser eine DLL die du dann mt InjectLibrary in den Zielprozess lädst. Das ist sicherer und es wird die KernelAPI LoadLibrary benutzt. InjectMe versucht das Image selbständig zu erstellen und dann in den Prozess zu laden. Das funktioniert soweit gut, aber dort treten öfter mal Probleme auf.
InjectLibrary ist aber sicher, es wäre das selbe als wenn die Anwenung selbst LoadLibrary aufruft.
Das Dllmain ist wie gesagt nur der Code der dann in dem Zielprocess aufgerufen wird. Such mal hier im Forum, ich weiß dass ich irgendwo mal ein Beispiel dazu geschrieben habe.
Noteip - Fr 28.04.06 08:53
Hi uall@ogc,
versuche schon seit Tagen deine Webseite zu erreichen um mir die Units runterzuladen. Aber ich erreiche die Seite nicht. Geht es den Anderen hier auch so, oder liegt das an meiner Verbindung?
Gruß Noteip
uall@ogc - Fr 28.04.06 12:38
Hi, ja leider ist die Seite gerade down. Da hatte ich noch die Dokumentation und einige Beispiele. Hab aber jetzt mal den alternativlink zu souceforge in den ersten Post dazugetragen. Da bekommst aber halt nur den Source :)
Noteip - Fr 28.04.06 19:01
Echt super Tools ... weiter so!
moddin - Do 08.06.06 23:02
@Topic Mich interresiert ob das Injecten von Processen bzw Thread-Injection von den Units unterstützt wird
Wie wird eigentlich gehooked? Wird "extended Overwriting" verwendet so das es möglich sei die wahre API funcktion zu erreichen indem man die Adresse der ersten 5 bytes der gehookten function ermittelt und so den Hook umgehen kann?
@Alle Ist es eigentlich möglich nicht eine DLL sondern die ausführende EXE selbst in eineren anderen PRocess zu injezieren sodas man sie beenden kann und trotzdem läuft sie in dem anderen Prozess weiter oder ist es besser einfacher mit einer Injezierten DLL zu kummunizieren?
Terra - Fr 09.06.06 10:39
Habe ich das jetzt richtig verstanden, das wenn ich SendInput hooken möchte folgendes eingeben muss?
Delphi-Quelltext
1:
| p := GetProcAddress(GetModuleHandle('user32.dll'),'SendInput'); |
Irgendwie Peil ich das nicht...
Terra
BenBE - 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 ...
uall@ogc - 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.
SAiBOT - Di 01.08.06 18:07
Alle Links sind down :(.
Edit:
was fürn glück gehen wieder :)!
Julian W. - 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 - 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.
0xCC - 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 - 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***
0xCC - 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 - 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.
Julian W. - 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 - 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 :arrow: Neuer Thread. Bitte dort auch ein paar Source-Ausschnitte vom Hiding ergänzen.
uall@ogc - 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'); |
0xCC - 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
http://int3.at/virtualalloc.gifModeriert von
Christian S.: img- in url-Tags umgewandelt. Der Screenshot sprengt das Layout.
0xCC - 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 - So 15.04.07 22:23
gibt es einen funktionierenden Link zu einer aktuellen Version?
Bei mir funktionieren die Links alle nicht :(
RedBaron2k7 - Mo 16.04.07 13:36
thx
elzumo - 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 - Do 31.01.08 11:35
*push* :cry:
_frank_ - Do 31.01.08 17:04
@elzumo: hast du das posting vor deinem ersten gelesen???
der SVN-Link funktioniert weiterhin...
Frank
BenBE - Do 31.01.08 18:45
Ach ja: Für Patches usw. könnt ihr u.U auch direkt mich anschreiben und ne Kopie an uall; ich kann die dann auch gleich in den Source einbinden.
Ach ja: Weil ich grad bei bin: Es scheint bei uallHook mit der Funktion HookCode (IAT) einen Konflikt mit der Tiny Firewall (6.5.1) zu geben, der dazu führt (Gehoookt in meinem Beispiel ist die Funktion kernel32.RaiseException ;-)), dass der Treiber der TinyFirewall sich aufhängt (und man entweder die Prozessüberwachung der FW abschalten muss, oder den Prozess killen und neustarten muss). Das Problem ist bei mir ständig reproduzierbar. Wer's testen will und auch die TinyFW hat (in besagter Version oder anderer), kann das uallCollection-Package in der Delphi-IDE installieren und danach das Omorphia-Package versuchen zu laden: Reaktion ist, dass sich Delphi aufhängt. Schaltet man die Prozessüberwachung nun ab, so kommt es zu einer AccessViolation ;-)
Wäre um Mithilfe dankbar, wenn mir da jemand ein paar Tipps dazu geben könnte ...
Boldar - Mo 08.09.08 16:52
Gibt es noch irgendwo einen funktionierenden Download??
EDIT: Hat sich erledigt...
BenBE - Mo 08.09.08 19:56
Das ist ein SVN-Repository. Mit TortoiseSVN kannst Du da (Read-Only) auch alles mit einmal ziehen ...
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 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!