CreateToolHelp32SnapShot hooks umgehen

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