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:


Delphi-Quelltext
1:
2:
3:
asm
  DB $90
end;


funktioniert da einwandfrei :shock:


retnyg - Do 21.04.05 20:32

ich verstehe es selber nicht ganz, laut http://64.233.183.104/search?q=cache:CSx4ade0o_gJ:info.borland.com/techpubs/delphi/delphi5/oplg/assemblr.html+delphi+5+asm+DB&hl=de
sollte DB absolut kein problem darstellen. ist ja auch eigentlich ein standardbefehl.


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:
  //RDTSC
  DW    $310F
  MOV ECX, EAX
  MOV EBX, EDX
  JMP @weiter2
@muell2:
  DB $0F$80
@weiter2:
//  RDTSC
  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]
  //MOVZX EAX, [EAX+2]
  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);
      // CloseHandle(ProcHnd);
    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 > 0then
        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
//  kol,
  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^); // zu dem breakpoint komme ich nie...
  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);
       //   application.processmessages;
    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

user profile iconuall@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


uall@ogc - Fr 06.05.05 14:01

und hier nochmal zu zeigen wie mächtig ein globaler hook ist :)

http://www.uall.info/pics/textoutw3.JPG


F34r0fTh3D4rk - Fr 06.05.05 14:10

1337 h00k :D R4mmst31n r0x 8) numb/encore auch :wink:


uall@ogc - Sa 07.05.05 13:04

auf wunsch von mehreren Leuten:
http://www.uall.info/files/1337%20global%20hook.zip


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
  // alter aufruf überhaupt nötig?
  // result := nextGetCursorPos(lpPoint);
  // ansonsten nur:

  result := true;
  lpPoint.x := 123;
  lpPoint.y := 123;  
end;

// und noch hooken


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
  // alter aufruf überhaupt nötig?
  // result := nextGetCursorPos(lpPoint);
  // ansonsten nur:

  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); //alter aufruf
  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,0else

  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
   // MessageBoxA(0,pchar(paramstr(0)),nil,0); <- aber messageboxa dynamisch importieren



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 - Sa 14.05.05 21:23

Der Link http://www.uall.info/uallCollection/uallCollection_12_05_05_1.zip ist tot.


toms - Sa 14.05.05 21:38

http://www.uall.info/sources/uallCollection_27_04_05_1.zip


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 DB $80 -->
  DB $0F$80
@weiter:
  //RDTSC
  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]
  //MOVZX EAX, [EAX+2] --> hier kommt bei D5 auch ein fehler, aber so gehts:
  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

user profile iconuall@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 user profile iconNarses: 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

user profile iconuall@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/]user defined image[/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


Quelltext
1:
    call [$00000000]                    


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

user profile iconwolke 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! user defined image

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


Delphi-Quelltext
1:
  //if VirtualProtect(p,1,PAGE_EXECUTE_READWRITE,old) then                    

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 <> 0then
       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 <> niland (pTargetMemory <> niland (pLibraryName <> nilthen
  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

user profile iconBenBE 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');  // ist dann 0


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.gif

Moderiert von user profile iconChristian 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 <> 0and (GetProcessVersion(temp) <> 0then
    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;
//var dwProcessH: DWord;
begin
//  dwProcessH := OpenProcess(PROCESS_ALL_ACCESS, False, dwProcessHandle);
//  if (dwProcessH <> 0) then
//  begin
//    CloseHandle(dwProcessH);
//    Result := dwProcessHandle;
//  end else
  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 :(


BenBE - Mo 16.04.07 00:56

Lad Dir die Dateien bei SourceForge aus dem Repo von Omorphia: http://omorphia.svn.sourceforge.net/viewvc/omorphia/trunk/uallCollection/


RedBaron2k7 - Mo 16.04.07 13:36

user profile iconBenBE hat folgendes geschrieben:
Lad Dir die Dateien bei SourceForge aus dem Repo von Omorphia: http://omorphia.svn.sourceforge.net/viewvc/omorphia/trunk/uallCollection/


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...


SAiBOT - Mo 08.09.08 17:43

DownloadMirror [http://www.evilsoft.de/Ablage/uallCollection.zip] (Seit 23-Jan-2008 Online :D )


Boldar - Mo 08.09.08 19:43

ahhh. Ich hab mir jetzt alle einzeln von da runtergeladen :twisted: :twisted: http://omorphia.svn.sourceforge.net/viewvc/omorphia/trunk/uallCollection/


BenBE - Mo 08.09.08 19:56

Das ist ein SVN-Repository. Mit TortoiseSVN kannst Du da (Read-Only) auch alles mit einmal ziehen ...