Alternative zu FindFirst/Next im SpeedCommander ??

[F.W.]

Ich arbeite gerade an einem Programm, welches einige Verzeichnisse oder Dateien aus den Ordnerlisten vom Explorer und anderen Dateimanagern ausblenden soll.
Ich bin schon recht weit und es funktioniert auch das was ich bisher gemacht habe, jedoch funktionieren meine Maßnahmen bei einigen Dateimanagern nicht...

Mein Vorgehen:
Ich installiere einen "leeren" GetMsg-Hook global, um mit einer Dll in alle Prozesse zu gelangen.
Dort führt die Dll beim DLL_PROCESS_ATTACH eine Patchroutine aus, die die Adressen von FindFirst(A/W) und FindNext(A/W) patcht.
Bis jetzt habe ich nur die FindNext-Funktionen gepatcht und durch eigene ersetzt, die vorher prüfen ob ein Pfad "versteckt" werden soll oder nicht.
Wenn ich (unter WinXP Home SP 2) die FindNextW patche, so funktioniert im Explorer alles so, wie ich es will, wobei mir auch völlig klar ist, warum es erst Wirkung zeigt wenn ich die WideChar-Variante patche usw.
Allerdings bekomme ich im SpeedCommander alle Dateien und Verzeichnisse angezeigt. Die naheliegendste Antwort auf diese Frage wäre wohl, dass der SpeedCommander zum Dateien auflisten eine andere Routine als FindFirst oder FindNext benutzt, aber welche? Oder macht der SC das anders?+

Grüße Felix

[sx2008]

Nimm den Dependency Walker und lade den SC.
Dann mit F7 das Profiling starten und unten im Logfenster schauen, welche DLL Funktionen aufgerufen werden.

[wido]

Wie hookst Du? IAT? EAT? Code Overwriting? Ich hoffe mal Du denkst daran, daß Du bei IAT Hooks dynamic linking selbst abfangen musst über nen GetProcAddress Hook.

Du musst übrigens ausschließlich die WideChar Varianten patchen. Eigentlich fast alle ANSI Funktionen sind nur Wrapper für die WideChar Funktionen. Hookst Du beide, filterst Du alle Sachen doppelt. Windows Komponenten benutzen übrigens eigentlich fast ausschließlich WideChar Funktionen um UNICODE kompatibel zu sein. Entsprechend hat der Hook im Explorer auch erst funktioniert, nachdem Du FindNextW gehookt hast ;).

[F.W.]

Zitat:

Wie hookst Du? IAT? EAT? Code Overwriting? Ich hoffe mal Du denkst daran, daß Du bei IAT Hooks dynamic linking selbst abfangen musst über nen GetProcAddress Hook.

Vielleicht zeigt sich jetzt wieder mein gefährliches Halbwissen, aber was ist IAT und EAT?
Ich habe gerade nach der Quelle gesucht, von der ich die Prozedur zum Adressen patchen genommen habe, aber ich find sie nicht mehr. Es war hier aus der DP, ich glaube ein Beitrag von Luckie, ich habe jedenfalls noch den Ahang des Threads hier auf der Platte, er heißt "MutexHook", dazu findet die Forensuche aber nichts ^^

Ich poste sie einfach mal:

Delphi-Quellcode:

function PointerToFunctionAddress(Code: Pointer): PPointer;
var
  func: PImportCode;
begin
  Result := nil;
  if Code = nil then Exit;
  try
    func := code;
    if (func.JumpInstruction = $25FF) then
    begin
      Result := func.AddressOfPointerToFunction;
    end;
  except
    Result := nil;
  end;
end;

function FinalFunctionAddress(Code: Pointer): Pointer;
var
  func: PImportCode;
begin
  Result := Code;
  if Code = nil then Exit;
  try
    func := code;
    if (func.JumpInstruction = $25FF) then
    begin
      Result := func.AddressOfPointerToFunction^;
    end;
  except
    Result := nil;
  end;
end;


function PatchAddress(OldFunc, NewFunc: Pointer): integer;
var
  BeenDone: TList;

  function PatchAddressInModule(hModule: THandle; OldFunc, NewFunc: Pointer):
                                                                        integer;
  var
    Dos: PImageDosHeader;
    NT: PImageNTHeaders;
    ImportDesc: PImage_Import_Entry;
    rva: DWORD;
    Func: PPointer;
    DLL: string;
    f: Pointer;
    written: DWORD;
  begin
    Result := 0;
    Dos := Pointer(hModule);
    if BeenDone.IndexOf(Dos) >= 0 then Exit;
    BeenDone.Add(Dos);
    OldFunc := FinalFunctionAddress(OldFunc);
    if IsBadReadPtr(Dos, SizeOf(TImageDosHeader)) then Exit;
    if Dos.e_magic <> IMAGE_DOS_SIGNATURE then Exit;
    NT := Pointer(integer(Dos) + dos._lfanew);
    // if IsBadReadPtr(NT,SizeOf(TImageNtHeaders)) then exit;

    RVA := NT^.OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].
                                                                 VirtualAddress;

    if RVA = 0 then Exit;
    ImportDesc := Pointer(integer(Dos) + RVA);
    while (ImportDesc^.Name <> 0) do
    begin
      DLL := PChar(integer(Dos) + ImportDesc^.Name);
      PatchAddressInModule(GetModuleHandle(PChar(DLL)), OldFunc, NewFunc);
      Func := Pointer(integer(DOS) + ImportDesc.LookupTable);
      while Func^ <> nil do
      begin
        f := FinalFunctionAddress(Func^);
        if f = OldFunc then
        begin
          WriteProcessMemory(GetCurrentProcess, Func, @NewFunc, 4, written);
          if Written > 0 then Inc(Result);
        end;
        Inc(Func);
      end;
      Inc(ImportDesc);
    end;
  end;
begin
  BeenDone := TList.Create;
  try
    Result := PatchAddressInModule(GetModuleHandle(nil), OldFunc, NewFunc);
  finally
    BeenDone.Free;
  end;
end;

Den Rest hab ich selbst geschrieben, eben einen ganz normalen Hook, den ich aber nur benutze um in die Prozesse zu gelangen:

Delphi-Quellcode:

function GetMsgProc(nCode: Integer; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
begin
 Result := CallNextHookEx(PData^.HookHandle, nCode, wParam, lParam);
end;

Zitat:

Eigentlich fast alle ANSI Funktionen sind nur Wrapper für die WideChar Funktionen.

Ich habe das gerade mal ausprobiert. Ich benutze in meinen Programmen meist nur die einfache FindFirst Version, wenn ich in der Dll aber jetzt nur die Unicode Varianten patche, bekomme ich gar nichts mehr. Also sind zumindest gerade diese keine Wrapper. Oder es hängt damit zusammen, dass ich die Adressen im Programm patche und wenn ein Programm eben FindFirst oder FindFirstA aufruft ist ja klar, dass ich dann nichts mehr mitbekomme.

Zitat:

Nimm den Dependency Walker und lade den SC.

Den Dependency Walker schaue ich mir gleich mal an!

[Luckie]

Was soll das eigentlich werden? Klingt mir irgendwie gefährlich nach Rootkit.

[F.W.]

Ach ja, die Rootkits. Dann ist hier jetzt sicher gleich Schluss mit Hilfe was?

Man kann der Funktionalität nach Rootkit dazu sagen. Aber das Programm soll ausschließlich auf meinem Rechner laufen und ein Verzeichnis bzw. einige Dateien verstecken, worunter das Programm selbst nicht zählt. Mehr kann ich nicht sagen.

Aber letztendlich frage ich hier nicht wie man Schadsoftware schreibt und will auch keinen Code von jemanden. Ich will nur wissen, welche Möglichkeiten es noch gibt, Dateien aufzulisten.

[Luckie]

Damit erschließt sich mir der Sinn immer noch nicht. Windows kennt Benutzerkonten und ein Rechtemanagement.

[wido]

Also mit der von dir oben beschriebenen Methode wird das hinten und vorne nix.

Du hast da gleich mehrere Probleme:
1. SC hat keine komplette Import Address Table weils mit ASProtect versehen ist. Das wäre nicht ganz so schlim, aber ...
2. Du injezierst über nen Message Hook. Bedeutet im Endeffekt Du gelangst erst in den Prozess nachdem der ASProtect Stub die vollständige IAT aufgebaut hat via LoadLibrary/GetProcAddress.

Im Endeffekt gibts 2 Lösungen:
1. Benutz eine andere Methode zum Injezieren.
2. Benutz Code Overwriting zum Hooken.

Welche Du davon nutzt bleibt Dir überlassen. Google ist übrigens Dein Freund ;).

Zitat:

Zitat von F.W.

Ich habe das gerade mal ausprobiert. Ich benutze in meinen Programmen meist nur die einfache FindFirst Version, wenn ich in der Dll aber jetzt nur die Unicode Varianten patche, bekomme ich gar nichts mehr. Also sind zumindest gerade diese keine Wrapper. Oder es hängt damit zusammen, dass ich die Adressen im Programm patche und wenn ein Programm eben FindFirst oder FindFirstA aufruft ist ja klar, dass ich dann nichts mehr mitbekomme.

Wie Du siehst ruft auch FindNextFileA nur FindNextFileW auf:

Code:

.text:7C834EB1 ; Exported entry 218. FindNextFileA
.text:7C834EB1
.text:7C834EB1 ; =============== S U B R O U T I N E =======================================
.text:7C834EB1
.text:7C834EB1 ; Attributes: bp-based frame
.text:7C834EB1
.text:7C834EB1 ; BOOL __stdcall FindNextFileA(HANDLE hFindFile, LPWIN32_FIND_DATAA lpFindFileData)
.text:7C834EB1                 public FindNextFileA
.text:7C834EB1 FindNextFileA   proc near
.text:7C834EB1
.text:7C834EB1 var_268         = dword ptr -268h
.text:7C834EB1 var_264         = byte ptr -264h
.text:7C834EB1 var_25C         = byte ptr -25Ch
.text:7C834EB1 var_25A         = word ptr -25Ah
.text:7C834EB1 var_258         = dword ptr -258h
.text:7C834EB1 FindFileData    = _WIN32_FIND_DATAW ptr -254h
.text:7C834EB1 var_4           = dword ptr -4
.text:7C834EB1 hFindFile       = dword ptr  8
.text:7C834EB1 lpFindFileData  = dword ptr  0Ch
.text:7C834EB1
.text:7C834EB1 ; FUNCTION CHUNK AT .text:7C836601 SIZE 00000016 BYTES
.text:7C834EB1 ; FUNCTION CHUNK AT .text:7C83C993 SIZE 0000000D BYTES
.text:7C834EB1
.text:7C834EB1                 mov     edi, edi
.text:7C834EB3                 push    ebp
.text:7C834EB4                 mov     ebp, esp
.text:7C834EB6                 sub     esp, 268h
.text:7C834EBC                 mov     eax, dword_7C8846CC
.text:7C834EC1                 push    ebx
.text:7C834EC2                 push    esi
.text:7C834EC3                 mov     esi, [ebp+lpFindFileData]
.text:7C834EC6                 lea     ecx, [ebp+FindFileData]
.text:7C834ECC                 mov     [ebp+var_4], eax
.text:7C834ECF                 mov     eax, [ebp+hFindFile]
.text:7C834ED2                 push    ecx             ; lpFindFileData
.text:7C834ED3                 push    eax             ; hFindFile
.text:7C834ED4                 call    FindNextFileW
[...]

Allerdings ist das Problem mehr oder weniger, daß Deine Hook Methode nur Calls hooken kann, die sich auf die IAT stützen. FindNextFileW wird von der Anwendung nicht direkt aufgerufen, folglich gibts halt auch keine Möglichkeit den Call mit nem IAT Hook zu erwischen. Code Overwriting hilft da.

[F.W.]

Zitat:

Windows kennt Benutzerkonten und ein Rechtemanagement.

Nur blöd, wenn man auch was vor dem eigenen Benutzerkonto verstecken muss. Sich abzumelden wenn man mal schnell jemand anderen an den Computer (Heimcomputer) lässt, damit der seine E-Mails abholen kann, würde Misstrauen erwecken, genauso wie ich eig. kein Freund von Passwörtern in der Familie bin.

@wido: Gut, dass mit dem LoadLibrary und GetProcAddress im SC leuchtet mir ein, genauso wie die Aufrufe von FindNextFileA/W.
Dann werde ich wohl doch nochmal nach einer anderen Variante suchen müssen. Aber es ging mir nebenbei eigentlich mehr um die Erfahrung, das mal gemacht zu haben. Ich betrachte es mehr als Spielerei.

Kennt jemand ein Tutorial zu "CodeOverwriting"? ;-)

[SirThornberry]

ein Tutorial kenne ich nicht. Aber was hältst du davon wenn du einfach LoadLibrary mit filterst und abfängst wenn dort die Funktionen dynamisch geladen werden?