CreateToolHelp32SnapShot hooks umgehen

[Arnulf]

Hallo
Ich hab schon wieder verrückte ideen :).
Da ich inzwischen dank dieses forums viel über Pe header und prozesse gelernt hab, hab ich mir gedacht ich könnte doch versuchen von einem prozess die importtierten module aus der import table auslesen.

Jetzt brauch ich ja nur den header der .exe und deshalb dachte ich es reicht die ersten 1000 bytes einzulesen und mir dann die module auflisten lassen.

Delphi-Quellcode:

    buffer := VirtualAlloc(nil,$1000,MEM_COMMIT,PAGE_EXECUTE_READWRITE);
    Read := OpenProcess(PROCESS_ALL_ACCESS,false,Pid);
    ReadProcessMemory(Read,pointer(0),buffer,$1000,read);
    CheckImports(buffer);

Natürlich gehts so nicht :) - falsch ist sicherlich schon mal

Delphi-Quellcode:

pointer(0)

allerdings weiß ich auch nicht wo im prozess ich anfangen soll zu lesen - wo beginnt der eigentlich?

Arnulf

[NicoDE]

Zitat:

Zitat von Arnulf

Jetzt brauch ich ja nur den header der .exe und deshalb dachte ich es reicht die ersten 1000 bytes einzulesen und mir dann die module auflisten lassen.

Erwartungshaltungen in Form von Konstanten sind an dieser Stelle unangebracht. Im Dos-Header steht der Offset des PE-Headers (das könnten auch 5MB sein).

ps: Was hat das Thema mit der Frage zu tun?
pps: das Modul-Handle (= Basisadresse) des "Images mit dem der Prozess erzeugt wurde" ist immer das erste (CreateToolHelpSnapshot)

[Arnulf]

Zitat:

könnten auch 5MB sein

ok das bedeutet wohl ich müsste mich immer durchhanteln.
also erste den dosheader ---> read process am offset und dann ntheader einlesen?

Delphi-Quellcode:

Was hat das Thema mit der Frage zu tun?

Naja - wenn die apis gehookt werden um prozesse zu verstecken, dachte ich mir einfach ich les den prozess ein und schau auf die import tabelle des prozesses, um ohne der api funktionen die module auszulesen die der prozess verwendet.
Das war ja nur eine idee wie man eben diese hooks umgehen kann (Module32First/module32next).

Delphi-Quellcode:

ist immer das erste (CreateToolHelpSnapshot)

naja dann komm ich aber um die apis nicht herum.
Und genau darum geht es ja eigentlicht.

Edit:
ich glaub die funktion heißt eigentlich NtQuerySystemInformation - die gehookt wird - vielleicht sollte ich den titel des threads ändern - bin mir aber nicht sicher.

Arnulf

[NicoDE]

Zitat:

Zitat von Arnulf

ok das bedeutet wohl ich müsste mich immer durchhanteln.

Jupp.

Zitat:

Zitat von Arnulf

also erste den dosheader ---> read process am offset und dann ntheader einlesen?

Es besteht keine Notwendigkeit, dass der Loader des Betriebssystems den DOS- und/oder NT-Header in den Adressraum des Prozesses kopiert. Insofern wirst Du (wenn es 'sauber' funktionieren soll) immer das Image (und dessen Header) von Platte einlesen müssen (um an die Adresse der Import-Tabelle zu gelangen (ausser, das Betriebssystem bietet Dir eine Möglichkeit/API um direkt an die Import-Tabelle eines Prozesses zu gelangen...).

Zitat:

Zitat von Arnulf

naja dann komm ich aber um die apis nicht herum.
Und genau darum geht es ja eigentlicht.

Wenn keinem in diesem Forum etwas dazu einfällt (außer spezifische Lösungen), dann wird's schwierig das zu vermeiden...

[Arnulf]

Nagut wieder eine auf die Nase bekommen :)

Ich dachte echt es gäbe eine Möglichkeit, process hider die auf api hooks basieren zu umgehen.
Damit bleibt mir wieder nichts anderes als mich damit zu beschäftigen hooks zu entdecken.
Danke jedenfalls
Arnulf

[NicoDE]

Zitat:

Zitat von Arnulf

Ich dachte echt es gäbe eine Möglichkeit, process hider die auf api hooks basieren zu umgehen.

Viele solcher Tools vergessen, dass es auch andere Wege als die Win32-API gibt um an die Informationen zu gelangen (WMI, PSAPI, ...). Generische Lösungen (gerade wenn sie bekannt und etabliert sind) sind immer die ersten die umgangen werden. Da dieses Katz&Maus-Spiel schon ein paar Jahre geht, haben sich Unmengen von Hacks und Anti-Hacks angesammelt...

[Olli]

Zitat:

Zitat von Arnulf

Ich dachte echt es gäbe eine Möglichkeit, process hider die auf api hooks basieren zu umgehen.

ROFL, klar gibbet die. Muddu "nur" einen K-Mode-Treiber schreiben, der die Prozesse auflistet (ich rede mal nur von NT4 aufwärts). Alternativ, wenn du weißt, daß die Toolhelp-APIs gehookt wurden, kannste auch ganz einfach so die Native API benutzen. Such mal unter OpenSource. Da habe ich den Link zu einer Unit gepostet, wo es um Native APIs geht.

Aber Achtung: nur weil ich dir einen K-Mode-Treiber ans Herz lege, heißt das nicht, daß man nciht auch im K-Mode bereits vor anderen Treibern die Prozesse verstecken könnte. Da gibt es auch eine Seite www dot rootkit dot com, wo du mehr Informationen zu diesem Thema bekommst (also zB Programme welche Rootkits austricksen und wieder neue Rootkits die eben jene Programme austricksen und so weiter und so weiter ... :mrgreen:

[brechi]

Als wenn ich nichts dafür hätte ;)

Delphi-Quellcode:

var oldRtlEqualUnicodeString: function(a,b: pointer; c: boolean): boolean; stdcall;
    nextRtlEqualUnicodeString: function(a,b: pointer; c: boolean): boolean; stdcall;
    forcename: string;

function myRtlEqualUnicodeString(a,b: pointer; c: boolean): boolean; stdcall;
begin
  if pos(forcename,uppercase(pwidechar(pointer(cardinal(b)+4)^))) > 0 then
    result := false else
    result := nextRtlEqualUnicodeString(a,b,c);
end;

function ForceLoadLibraryNtA(dllname: pchar): cardinal; stdcall;
begin
  @oldRtlEqualUnicodeString := GetProcAddress(GetModuleHandle('ntdll.dll'),'RtlEqualUnicodeString');
  if (@oldRtlEqualUnicodeString <> nil) then
  begin
    uallTableHook.HookAPIJMP(@oldRtlEqualUnicodeString,@myRtlEqualUnicodeString,@nextRtlEqualUnicodeString);
    forcename := uppercase(dllname);
    result := LoadLibraryA(dllname);
    uallTableHook.UnhookAPIJMP(@nextRtlEqualUnicodeString);
  end else
    Result := LoadLibraryA(dllname);
end;

mit ForceLoadLibraryNtA('ntdll.dll') kannste die ntdl ein 2. mal laden und dann davon GetProcaddress(x,'NtQuerySystenbob') machen und die funtkion dann benutzen, die ist dann garantiert nicht gehookt :)

[Arnulf]

Man mit euch geht echt die post ab :)
Da will ich nur nen simplen anticheat für mein lieblingsspiel schreiben, und ich lande in den untiefen der windows system programmierung.
Hab mir gerade die native api's runtegeladen, aber hab keine Beschreibung gefunden wie die dann verwendet werden.
Sachen gibts....

Und Brechi der alte hacker hat sowieso wieder was lol.

Aber um nicht nur zu quatschen eine kleine verständniss frage?
Die Apis müssen immer im prozess gehookt werden der die verwendet (klar) also global im system um eben ein modul zu verstecken.
Wenn jetzt ein hook für das verstecken von prozessen gemacht wird, dann kann ich ja uall.protect.ishook in meinem eigenen prozess verwenden.
Oder Brechis vorschlag einfach die ntdll.dll nachladen (lol gute idee).
Oder eben die Native apis - wenn ich dazu eine beschreibung finde, die find ich ja sehr interessant.

All diese methoden sollten bei einfachen process hide programmen die auf NtQuerySystemInformation basieren funktionieren wenn ich die in mein eigenes programm einbau, weil die ntdll.dll in meinem programm gehookt werden muß wenn ich von einem anderen prozess die module auflisten will?
hoff ich :)
Arnulf

Edit:
Eigentlich eine dumme frage, aber ich bin mir immer noch so unsicher bei dem ganzen thema und ich hab mich schon so oft geirrt :)

[Olli]

Zitat:

Zitat von Arnulf

Hab mir gerade die native api's runtegeladen, aber hab keine Beschreibung gefunden wie die dann verwendet werden.
Sachen gibts....

Sei froh, daß du wenigstens die Deklarationen hast. Die sind nämlich allesamt undokumentiert (abgesehen von diversen verstreuten Informationen). Aber die werden vermutlich auch nochmal dokumentiert.