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.

[Arnulf]

stimmt natürlich die deklarationen hab ich.
Ist aber langwierig sich da durchzusuchen - trotzdem werd ich mir mal ein paar anschauen - klingt sehr interessant :)

Arnulf

Edit:
Ich wollte gerade Brechis methode ausprobieren ( die mir am schnellsten und einfachsten erschien).
Aber ich glaub uallTableHook.HookAPIJMP ist in der collection die ich hab nicht drin.
Ist das eine neue version?

[brechi]

nimm den normalen hook damit sollte das auch gehen,

uallTableHook sollte aber vorhanden sein (in der neusten version, kann sein das ich die Funktion nur anders benannt habe) leider ist die page im moment down, aber der normale uallHook sollte auch funzen

[Arnulf]

hm .. ich denk mal ich warte bis deine seite wieder on ist.
Ich dürfte sowieso eine sehr alte version haben.
uallhook beinhaltetn nämlich nur:
HookCode
HookApiIAT
HookApiIAT
InjectMe
InjectLibrary

also jeglicher unhook fehlt hier.
egal ich wart einfach - hab eh noch genug zu tun :)

Arnulf

[brechi]

hier ich kanns mal beilegen, ist alles bischten dumm gelaufen, musste meinen laptop abgeben wo alles neue druf war und jetzt is die seite auch down und ich komm selbst net an die neuesten daten ran :/

aber hier haste wenigstens etwas wo man unhooken kann usw.

[Arnulf]

oh danke dir
ich bin sowieso ab morgen mal eine woche in Hamburg.
Ja wir Österreicher machen Urlaub in Hamburg :)....

Hast du stress deine seite zu hosten?
Ich kann die seite ja bei mir am server spiegeln wennst magst, dann mußt zur not nur die domain umleiten.
Wenns nicht zu viel traffic braucht, kann ichs auch hosten.
Ich hab nur bemerkt, daß die uall.info öfter mal off ist.

Arnulf

[brechi]

jep die seite ist bisl länger offline, hab die auch nur geschenkt bekommen nur der serevranbieter hat meinem sponsor gekündigt da die seiten zu viel traffic haben wegen ddos attacken.

die neuste version findest im moment hier:

http://uall.overclock.ch/uallCollection.zip

die seite wird in 1-2 wochen umgestellt

[Arnulf]

Hi again - bin zurück :)

Zitat:

seiten zu viel traffic haben

Ja das wäre dann auch bei mir wohl das problem - ich hab nur 200 gig frei im monat.
4-5 gigabyte fallen da nicht auf aber mehr .... naja.

Jedenfalls hab ich probiert die ntdll.dll mit forceloadlibrary nachzuladen - aber ich bekomm von der funktion nichts zurück.
Der hook dürfte funktionieren, zumindestenst springt er in die hook funktion wenn LoadLibraryA aufgerufen wird.
Trotzdem bekomm ich keine neue .dll geladen oder von der func nichts zurück.
die Source hat sich ja nicht geändert hab die nur abgeschrieben - aber trotzdem nochmal:
Der aufruf:

Delphi-Quellcode:

 nt2dll := ForceLoadLibraryNtA('ntdll.dll');

Brechis Source:

Delphi-Quellcode:

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;

Naja ich hoffe du weißt warum ich nämlich nicht :).
Wäre auch super, wenn du eine erklärung für myRtlEqualUnicodeString hättest... weil ich zwar sehe, daß loadlibraryA die funktion verwendet, aber mir nicht klar ist, wie dadurch die .dll neu geladen werden sollte ..

Arnulf

[brechi]

hi
die ForceLoadLibraryNTa funktion liefert dir normal ein neues dll handle zurück, also hättest du LoadLibraryA aufgerufen, dabei sollte GetModuleHandle('ntdll.dll') <> ForceLoadLibraryNtA('ntdll.dll') sein da die dll halt neu geladen wird an einen anderen adressraum

sie gibt auf jedenfall einen handle zurück, wenn nicht funktioniert bekommste GetModuleHandle('ntdll.dll') zurück

also kannst du mit GetModuleHandle('ntdll.dll') <> ForceLoadLibraryNtA('ntdll.dll') prüfen ob die funktion funktioniert hat

RtlEqualUnicodeString wird intern benutzt um zu prüfen ob eine dll schon geladen ist, d.h. normal würde imemr der alte handle zurückgegeben werden, da ich aber bei einer bestimmten dll (die du laden willst, zb.b. ntdll.dll) dort false zurückgebe, denk windows sie ist noch nicht geladen und lädt sie ein 2. mal

[Arnulf]

Ja so hab ich mir das auch gedacht, aber ich bekomme immer 0 zurück wenn ich das so benutze:

Delphi-Quellcode:

nt2dll := ForceLoadLibraryNtA('ntdll.dll');

schon das hier liefert 0 zurück:

Delphi-Quellcode:

result := LoadLibraryA(dllname);

beim hook springt er beim aufruf von loadlibraryA in diese möglichkeit:

Delphi-Quellcode:

result := nextRtlEqualUnicodeString(a,b,c);

ansonsten danke für die erklärung bei der hook funktion :)

Arnulf
Edit:
Also ich hab mal geschaut was in b bei myRtlEqualUnicodeString überhaupt drin steht
b:

Zitat:

Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\Sys tem32\Wbem;C:\PROGRA~1\Borland\Delphi6\Bin;C:\PROG RA~1\Borland\Delphi6\Projects\Bpl;C:\Programme\ATI Technologies\ATI Control Panel;C:\Programme\Gemeinsame Dateien\Avid;C:\Programme\SSH Communications Security\SSH Secure Shell

Das scheint aber nicht das zu sein, was hier erwartet wird ????
also das mit forcename zu vergleichen ergibt scheinbar keinen sinn.
Vielleicht fällt dir etwas dazu ein.
Arnulf

[Arnulf]

Mit den native apis bin ich auch nicht weiter gekommen, weil ich einfach keine funktion gefunden hab, die mir module auflistet.
system information hab ich gefunden - aber nichts für module in einem prozess....

ich werd mich mal bei rootkit umschauen, schade daß brechi zu seinem code nichts mehr geschreiben hat, das war doch spannend aber hat hald für mich auch nicht funktioniert :)

Arnulf

[Olli]

:shock:

Wie wäre es mit RtlQueryProcessDebugInformation()? Kleiner Tip: die Toolhelp-API von Windows 2000 aufwärts basiert auf den Native APIs, ergo muß es da was geben.

[Arnulf]

Man - ich bin erschlagen lol.
Wenn man mal anfangen will hinter die normalen windows funktionen zu blicken wird man erschlagen...
Jedenfalls hab ich code von nico gefunden
http://www.swissdelphicenter.ch/de/showcode.php?id=281
der mit zeigen sollte was du meinst.
Naja tut es nicht wirklich lol - muß wohl erstmal damit spielen ums zu begreifen.
In den native apis hab ich das gefunden:

Delphi-Quellcode:

function  RtlQueryProcessDebugInformation(
    ProcessId : ULONG;
    DebugInfoClassMask : ULONG;
    DebugBuffer : PDEBUG_BUFFER
  ): NTSTATUS; stdcall;

Logischerweise sagt mir das nichts, vielleicht hilft mir wirklich das rumspielen mit nicos code :)
Arnulf

Edit:
Ach debugBuffer dürfte wohl das sein was ich suche lol - sachen gibts.

Dazu hab ich nur noch eine frage was ist der Handle eines Moduls?
Ist das die Base adresse? - also beginnt dort dann der dos header und alle weiteren?

Danke
Arnulf

[NicoDE]

Zitat:

Zitat von Arnulf

Jedenfalls hab ich code von nico gefunden

Netter alter Code, keine Ahnung ob der auf aktuellen Windows-Versionen noch funktioniert (von Debug-Releases ganz zu schweigen :))...

Zitat:

Zitat von Arnulf

Dazu hab ich nur noch eine frage was ist der Handle eines Moduls?
Ist das die Base adresse?

Ja und nein. In 99% ist es die Basisadresse - wenn die Datei allerdings mit LoadLibraryEx(..., ..., LOAD_LIBRARY_AS_DATAFILE) geladen wurde, dann kommt zum Handle (die ja eigentlich untypisierte Zeiger sind) +1 dazu...

Zitat:

Zitat von Arnulf

also beginnt dort dann der dos header und alle weiteren?

Du solltest dich von der Vorstellung trennen, dass die Header in den Adressraum des Prozesses eingeblendet/kopiert werden müssen...

[Arnulf]

Zitat:

aktuellen Windows-Versionen noch funktioniert

ja funktioniert noch - habs ausprobiert :)

Zitat:

Du solltest dich von der Vorstellung trennen, dass die Header in den Adressraum des Prozesses eingeblendet/kopiert werden müssen...

lol also davon bin ich jetzt wirklich ausgegangen.
ich dachte wenn ich loadlibrary verwende wird immer der header mitsamt aller funktionen geladen?
wo drifte ich denn jetzt wieder ab - jetzt wirds freaky :).
Darauf basiert ja mein ganzer check.
1. nachschauen welche module geladen sind.
2. header einlesen und schauen ob opengl32.dll oder bestimmte funktionen importiert werden.

so hab ichs bisher gelernt lol....
was kommt jetzt, daß mir meine träume zerstört?

Arnulf

[Olli]

Zitat:

Zitat von NicoDE

Du solltest dich von der Vorstellung trennen, dass die Header in den Adressraum des Prozesses eingeblendet/kopiert werden müssen...

Jetzt will ich aber mal was hören *g* ... erklär mal. Also ich habe schonmal rumgespielt um die Header zu überschreiben und das gab klägliche Probleme, weil sie eben weg waren.

[Arnulf]

@Olli
Was ist hier im zusammenhang mit native api gemeint?
Werden hier nicht auch nur die ntdll.dll functionen importiert und dann verwendet.
Vielleicht kannst du mir gerade anhand dieses beispiels erklären was bei den native apis eigentlich gemacht wird?.

Delphi-Quellcode:

// Dynamic version of RtlQueryProcessDebugInformation
function  RtlQueryProcessDebugInformation(
    ProcessId : ULONG;
    DebugInfoClassMask : ULONG;
    DebugBuffer : PDEBUG_BUFFER
  ): NTSTATUS; stdcall;
begin
  GetProcedureAddress(_RtlQueryProcessDebugInformation, ntdll, 'RtlQueryProcessDebugInformation');
  Result := TFNRtlQueryProcessDebugInformation(_RtlQueryProcessDebugInformation)(
    ProcessId, DebugInfoClassMask, DebugBuffer
  );
end;

Also worauf basieren diese native apis?
Die Pricedure Adresse von der originalen ntdll verwenden? - wäre wirklich interessant den zusammenhang zu verstehen.

Arnulf

[NicoDE]

Zitat:

Zitat von Arnulf

so hab ichs bisher gelernt lol....
was kommt jetzt, daß mir meine träume zerstört?

Hier ein Beispiel um den DOS-Header im Speicher zu überschreiben

Delphi-Quellcode:

program Project1;

uses
  Windows;

const
  HelloWorld = 'Hello, World!';
var
  ModuleHandle: HMODULE;
  BaseAddress: Pointer absolute ModuleHandle;
  OldProtect: DWORD;
8begin
  ModuleHandle := GetModuleHandle(nil);
  if not VirtualProtect(BaseAddress, (Length(HelloWorld) + 1) * SizeOf(Char),
    PAGE_READWRITE, OldProtect) then
    Exit;
  lstrcpy(BaseAddress, HelloWorld);
  VirtualProtect(BaseAddress, (Length(HelloWorld) + 1) * SizeOf(Char),
    OldProtect, OldProtect);
  MessageBox(HWND(nil), BaseAddress, 'foo', MB_OK or MB_ICONINFORMATION);
end.

Die Ermittlung der Module funktioniert weiterhin problemlos (zum Beispiel mit: tasklist /M /FI "WINDOWTITLE eq foo").

[Olli]

Puh, ich schreibe gerade zusammen mit Marcel van Brakel einen Artikel für TDM über Native APIs, da glaube ich kaum, daß man das in wenigen Sätzen abhandeln kann *g*

Ich versuche es dennoch. Die Native APIs sind erstmal aufgeteilt in einen U-Mode und einen K-Mode-Teil. Der größte Teil der Native APIs im U-Mode wird von der NTDLL.DLL exportiert, im K-Mode ist dies NTOSKRNL.EXE.
Diese APIs bilden die Grundlage für alle Subsysteme und werden teilweise auch im DDK dokumentiert - inzwischen teils sogar im PSDK. Sie haben je nach Aufgabengebiet verschiedene Präfixe (Rtl* = Runtime Library). Eine Liste der Native APIs kannst du auf unserer JEDI-Apilib-Seite finden:
http://jedi-apilib.sourceforge.net/n...ativeList.html

Du benutzt sie also bereits, auch wenn du sie nicht so nennst ;)

Weitere Quellen zum Thema findest du in unserer ntapi-Unit.

@Nico: Komisch, bei mir gab es Probleme mit den ersten 3 Bytes, danach konnte ich eine Menge überschreiben (im DOS-Header) und dann mußte ich wieder im PE-Header aufpassen. Entweder liegt es an Unterschieden zwischen Delphi und VC, oder da ist was anderes zu beachten ... (ja, die Seitenzugriffsberechtigung habe ich angepaßt gehabt).

[brechi]

ihr das mit dem absolute ist ja mal hässlich gelöst ;P

Delphi-Quellcode:

program Project1;

uses windows;

const
  HelloWorld = 'Hello, World!';
var
  ModuleHandle: HMODULE;
  OldProtect: DWORD;
begin
  ModuleHandle := GetModuleHandle(nil);
  if not VirtualProtect(pointer(ModuleHandle), (Length(HelloWorld) + 1) * SizeOf(Char),
    PAGE_READWRITE, OldProtect) then
    Exit;
  lstrcpy(pointer(ModuleHandle), HelloWorld);
  VirtualProtect(pointer(ModuleHandle), (Length(HelloWorld) + 1) * SizeOf(Char),
    OldProtect, OldProtect);
  MessageBox(HWND(nil), pointer(ModuleHandle), 'foo', MB_OK or MB_ICONINFORMATION);
end.

man sollte das schon besser so durch typecasting lösen

absolut sagt aus das der gleiche sepicher benutzt wird

->

Delphi-Quellcode:

var bla: pointer;
    blub: integer absolute bla;

dann zeigen bla und blub auf gleiche adresse

Delphi-Quellcode:

var bla: pointer;

begin
  integer(bla) //<- würde das selbe sein wie blub
end;

[Olli]

Zitat:

Zitat von brechi

ihr das mit dem absolute ist ja mal hässlich gelöst

Wes Grundes? In Delphi ist dies die einzige Form des echten Aliasing. Entspricht fast exakt dem Verhalten einer Referenz in C++.

[brechi]

aus 2 gründen benutze ich das nicht

1) wenn man viel mit pointern arbeitet, und man macht mal einen fehler und es crashed bei einer zuweisung
wie z.b.

Delphi-Quellcode:

a := 1234;

dann weiß man nichst sofort das es eventl eine "absolute" variable handelt

sollte z.b.

Delphi-Quellcode:

var bla: byte;
  blub: array [0..1221] of integer absolute bla;

benutzt werden

durch die zuweisung

Delphi-Quellcode:

blub[1221] := 12345678

crashed es eventl. und man erkennt nicht sofort das es sich hierbei einfach um ein

Delphi-Quellcode:

pinteger(integer(@bla)+4*1221)^ := 12345678

handelt (auch wenn das ausgeschrieben mehr arbeit ist)

2) kann man nichts dynamisch machen, braucht man das einmal vermischt man beide "methoden" was ich dann doch unübersichtlicher finde


aber das ist nur meien persönliche meinung

[NicoDE]

Zitat:

Zitat von brechi

aber das ist nur meien persönliche meinung

Und meine ist, dass Handles untypisierte Zeiger sind, und selbige in der Delphi RTL 'falsch' deklariert sind... um mir die ganzen Casts in dem Beispiel zu sparen, habe ich mich für die 'schnelle und dreckige' Lösung entschieden :)

[Arnulf]

Ich muß das thema nochmal aufwärmen :)
Also die native apis scheinen dann nicht ganz das richtige zu sein.
Wenn nämlich ein hook auf QueryProcessDebugInformation gemacht wird, dann werden wohl auch die native apis gehookt.

Was jetzt brechis methode betrifft - leider funktioniert die so nicht wäre aber sehr interessant das hinzubekommen.

Als ersatzlösung wäre es vermutlich möglich mir ntdll.dll aus dem system ordner in mein verzeichnis zu kopieren, die .dll umzubenennen ( zufallszahl oder sowas ) und dann einfach mit loadlibrary zu benutzen.
Wenn ich das jedesmal nach dem programmstart mache, dann wirds mit einem hook auch recht schwer.

Fals ich schon wieder unsinn rede, dann bitte mitteilen :)

Danke
Arnulf

[Olli]

Zitat:

Zitat von NicoDE

Und meine ist, dass Handles untypisierte Zeiger sind, und selbige in der Delphi RTL 'falsch' deklariert sind...

Pah ... das sind doch keine Zeiger :mrgreen: ... Indeces in eine Handletabelle, ja, aber Zeiger ...

Zitat:

Zitat von Arnulf

Also die native apis scheinen dann nicht ganz das richtige zu sein.
Wenn nämlich ein hook auf QueryProcessDebugInformation gemacht wird, dann werden wohl auch die native apis gehookt.

RtlQueryProcessDebugInformation ist eine Native API ;)

Ich muß das thema nochmal aufwärmen :)Als ersatzlösung wäre es vermutlich möglich mir ntdll.dll aus dem system ordner in mein verzeichnis zu kopieren, die .dll umzubenennen ( zufallszahl oder sowas ) und dann einfach mit loadlibrary zu benutzen.[/quote]Ich bezweifele, daß das geht, da eigentlich diese DLLs nicht dafür ausgelegt sind reloziert zu werden, aber vielleicht hängt das auch davon ab, welche Funktionen man aufruft ;)

[Arnulf]

Zitat:

RtlQueryProcessDebugInformation ist eine Native API

Ja klar aber mir hat man gesagt, daß createtoolhelpsnapshot ebenfalls die native api benutzt.
Damit wäre es doch logisch RtlQueryProcessDebugInformation zu hooken wenn man .dlls oder was auch immer verstecken will.
Oder irre ich mich da?
Und das ist doch das eigentliche ziel solche hooks zu verhindern.
Ich hab ja bisher noch nichtmal solche einschlägigen programme gefunden die .dlls verstecken - man hat mir nur gesagt, daß man die cheat checks damit umgehen kann und das klingt auch logisch.

Zitat:

da eigentlich diese DLLs nicht dafür ausgelegt sind reloziert zu werden

Das ist wohl war.
Die frage ist aber warum nicht? - ist das in der .dll festgeschrieben oder weiß das das betriebssystem?
wenn ich also den namen der ntdll.dll ändere wäre es doch durchaus möglich, daß es funktioniert.
Vermutlich hast du recht und es geht mit bestimmten funktionen.
Aber das war auch nur meine notlösung.

Arnulf

[Olli]

Zitat:

Zitat von Arnulf

Zitat:

RtlQueryProcessDebugInformation ist eine Native API

Ja klar aber mir hat man gesagt, daß createtoolhelpsnapshot ebenfalls die native api benutzt.
Damit wäre es doch logisch RtlQueryProcessDebugInformation zu hooken wenn man .dlls oder was auch immer verstecken will.

Durchaus, aber es ist nicht die einzige Native API, die in der Toolhelp API benutzt wird.

Zitat:

Zitat von Arnulf

Zitat:

da eigentlich diese DLLs nicht dafür ausgelegt sind reloziert zu werden

Das ist wohl war.
Die frage ist aber warum nicht? - ist das in der .dll festgeschrieben oder weiß das das betriebssystem?

1. sind alle DLLs aufeinander abgestimmt. Schau dir mal die Base Address in den einzelnen DLLs zB mit dem Dependency Walker an, die passen alle wie ein Zahnrad ins andere.
2. sind die DLLs nicht darauf ausgelegt, auch wenn sie meist dennoch eine Relokationstabelle enthalten.

Zitat:

Zitat von Arnulf

wenn ich also den namen der ntdll.dll ändere wäre es doch durchaus möglich, daß es funktioniert.

Ja, aber eben nur durch relozieren, weil die NTDLL bereits in jeden Prozess eingeblendet ist.

[Arnulf]

Zitat:

Durchaus, aber es ist nicht die einzige Native API, die in der Toolhelp API benutzt wird.

Das ist klar toolhelp api kann ja auch viel.
Trotzdem kann ich einfach nicht erkennen wie ich damit dann hooks umgehen können soll.
Vielleicht versteh ichs ja auch noch nicht so richtig.

Zitat:

Ja, aber eben nur durch relozieren, weil die NTDLL bereits in jeden Prozess eingeblendet ist.

Tja damit muß ich mich wohl mit relozieren beschäftigen oder mit den relocation tables :).
Es wird nie ein ende nehmen und irgendwann kommt dann .net wo soll das nur hinführen....

Arnulf

[brechi]

das blöde daran ist das bei RtlQueryProcessDebugInformation die ntdll IPC benutzt um die daten von dem prozess zu bekommen

es wird ein Thread in dem ZiuelProcess (von dem wo die daten ausgelesen werden sollen) erstellt, lödt man die dll ein 2. mal übergibt aber die ntdll eine falsche startadresse (und zwar wo sie neu geladen wurde) diese gibt es im zielprzess aber nicht und wird der code zum auslesen nie aufgerufen... naja könnt noch mehr erzählen, aber hier mal nen tricky code mit dem das funzt :)

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, uallProtect, uallHook;

type
  TForm1 = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    Edit1: TEdit;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

type
  PDebugModule = ^TDebugModule;
  TDebugModule = packed record
    Reserved: array [0..1] of Cardinal;
    Base: Cardinal;
    Size: Cardinal;
    Flags: Cardinal;
    Index: Word;
    Unknown: Word;
    LoadCount: Word;
    ModuleNameOffset: Word;
    ImageName: array [0..$FF] of Char;
  end;

type
  PDebugModuleInformation = ^TDebugModuleInformation;
  TDebugModuleInformation = record
    Count: Cardinal;
    Modules: array [0..0] of TDebugModule;
  end;
  PDebugBuffer = ^TDebugBuffer;
  TDebugBuffer = record
    SectionHandle: THandle;
    SectionBase: Pointer;
    RemoteSectionBase: Pointer;
    SectionBaseDelta: Cardinal;
    EventPairHandle: THandle;
    Unknown: array [0..1] of Cardinal;
    RemoteThreadHandle: THandle;
    InfoClassMask: Cardinal;
    SizeOfInfo: Cardinal;
    AllocatedSize: Cardinal;
    SectionSize: Cardinal;
    ModuleInformation: PDebugModuleInformation;
    BackTraceInformation: Pointer;
    HeapInformation: Pointer;
    LockInformation: Pointer;
    Reserved: array [0..7] of Pointer;
  end;

const
  PDI_MODULES = $01;
  ntdll = 'ntdll.dll';

var
  HNtDll: HMODULE;
  HNtDll2: HMODULE;

type
  TFNRtlCreateQueryDebugBuffer = function(Size: Cardinal;
    EventPair: Boolean): PDebugBuffer;
  stdcall;
  TFNRtlQueryProcessDebugInformation = function(ProcessId,
    DebugInfoClassMask: Cardinal; var DebugBuffer: TDebugBuffer): Integer;
  stdcall;
  TFNRtlDestroyQueryDebugBuffer = function(DebugBuffer: PDebugBuffer): Integer;
  stdcall;
  TFNRtlCreateUserThread = procedure(ProcessHandle: THANDLE;
   SecurityDescriptor: PSECURITY_DESCRIPTOR;
   CreateSuspended: Boolean;
   StackZeroBits: ULONG;
   StackReserved: PULONG; StackCommit: PULONG;
   StartAddress: Pointer;
   StartParameter: Pointer;
   ThreadHandle: PHANDLE;
   ClientID: Pointer);
  stdcall;


var
  RtlCreateQueryDebugBuffer: TFNRtlCreateQueryDebugBuffer;
  RtlQueryProcessDebugInformation: TFNRtlQueryProcessDebugInformation;
  RtlDestroyQueryDebugBuffer: TFNRtlDestroyQueryDebugBuffer;
  RtlCreateUserThread: TFNRtlCreateUserThread;
  nextRtlCreateUserThread: TFNRtlCreateUserThread;

procedure myRtlCreateUserThread(ProcessHandle: THANDLE;
   SecurityDescriptor: PSECURITY_DESCRIPTOR;
   CreateSuspended: Boolean;
   StackZeroBits: ULONG;
   StackReserved: PULONG;
   StackCommit: PULONG;
   StartAddress: Pointer;
   StartParameter: Pointer;
   ThreadHandle: PHANDLE;
   ClientID: Pointer); stdcall;
begin
  StartAddress := Pointer(dword(StartAddress)-dword(HNtDll2)+dword(HNtDll));
  nextRtlCreateUSerThread(ProcessHandle, SecurityDescriptor,
    CreateSuspended,StackZeroBits,  StackReserved, StackCommit,
    StartAddress, StartParameter, ThreadHandle ,ClientID);
end;

function LoadRtlQueryDebug: LongBool;
begin
  if HNtDll = 0 then
  begin
    HNtDll := LoadLibrary(ntdll);
    HNtDll2 := uallProtect.ForceLoadLibraryNt(ntdll);
    if HNtDll <> 0 then
    begin
      RtlCreateQueryDebugBuffer       := GetProcAddress(HNtDll2, 'RtlCreateQueryDebugBuffer');
      RtlQueryProcessDebugInformation := GetProcAddress(HNtDll2,
        'RtlQueryProcessDebugInformation');
      RtlDestroyQueryDebugBuffer      := GetProcAddress(HNtDll2,
        'RtlDestroyQueryDebugBuffer');
      RtlCreateUserThread := GetProcAddress(HNtDll2,'RtlCreateUserThread');
      uallHook.HookCode(@RtlCreateUserThread,@myRtlCreateUserThread, @nextRtlCreateUserThread);
    end;
  end;
  Result := Assigned(RtlCreateQueryDebugBuffer) and
    Assigned(RtlQueryProcessDebugInformation) and
    Assigned(RtlQueryProcessDebugInformation);
end;
procedure TForm1.Button1Click(Sender: TObject);
var
  DbgBuffer: PDebugBuffer;
  Loop: Integer;
begin
  if not LoadRtlQueryDebug then Exit;

  Memo1.Clear;
  Memo1.Lines.BeginUpdate;
  DbgBuffer := RtlCreateQueryDebugBuffer(0, False);
  if Assigned(DbgBuffer) then
    try
      if RtlQueryProcessDebugInformation(StrToIntDef(Edit1.Text, GetCurrentProcessId),
        PDI_MODULES, DbgBuffer^) >= 0 then
      begin
        for Loop := 0 to DbgBuffer.ModuleInformation.Count - 1 do
          with DbgBuffer.ModuleInformation.Modules[Loop], Memo1.Lines do
          begin
            Add('ImageName: ' + ImageName);
            Add('  Reserved0: ' + IntToHex(Reserved[0], 8));
            Add('  Reserved1: ' + IntToHex(Reserved[1], 8));
            Add('  Base: ' + IntToHex(Base, 8));
            Add('  Size: ' + IntToHex(Size, 8));
            Add('  Flags: ' + IntToHex(Flags, 8));
            Add('  Index: ' + IntToHex(Index, 4));
            Add('  Unknown: ' + IntToHex(Unknown, 4));
            Add('  LoadCount: ' + IntToHex(LoadCount, 4));
            Add('  ModuleNameOffset: ' + IntToHex(ModuleNameOffset, 4));
          end;
      end;
    finally
      RtlDestroyQueryDebugBuffer(DbgBuffer);
    end;
  Memo1.Lines.EndUpdate;

end;

end.

der code is ausm swissdelphicenter und von NicoDe

[Arnulf]

Der code scheint zu funktionieren.
Keine Ahnung warum es bei mir nicht ging ( was du vorher einmal gepostet hast ) aber ich werde es mir genauer anschauen.

Übrigens ist das vielleicht gleich etwas für deine uall.Protect.
Das würde ich ProtectCall nennen oder so ähnlich.
Also ProtectCall(xxx.dll, funcname)...

Was mir gleich mal aufgefallen ist, daß strtointdef hier nicht so viel sinn zu haben schein, bei mir stürtzt er nämlich ab, wenn ich versuche das mit dem eigenen prozess zu machen.

noch eine verständnisfrage.
Warum ladest du vorher nochmal ntdll.dll mit loadlibrary?

Delphi-Quellcode:

   HNtDll := LoadLibrary(ntdll);
    HNtDll2 := uallProtect.ForceLoadLibraryNt(ntdll);

soweit ich deine ForceLoadLibraryNt kenne machst du das in der function eh nochmal mit hook eben!

Arnulf

[brechi]

aso ne klar hab ich von NicoDe's code ncoh dringeladden, nen getmoduelhandle würde reichen um nacher die richtige adresse im Hook von CreateThread zu berechnen