Hook

[derseitzer]

Hallo,
Ich möchte mich mit Hooks beschäftigen und einfach etwas dazulernen und nun habe ich aus einem Video diesen Code programmiert und eine "DDetours-Library" hinzugefügt.

Code:

var
HookedExitProcess: function(Cardinal: integer) : PVOID; stdcall = nil;

function myExitProcess(Cardinal: integer) : PVOID; stdcall;
begin
  Result:= nil;
end;


procedure TForm1.HookExitProcessClick(Sender: TObject);
begin
if not Assigned (HookedExitProcess) then
begin
  @HookedExitProcess:= Interceptcreate(@ExitProcess, @myExitProcess);
end;

end;

procedure TForm1.CallExitProcessClick(Sender: TObject);
begin
ExitProcess(0);
end;

procedure TForm1.UnhookExitProcessClick(Sender: TObject);
begin
if Assigned (HookedExitProcess) then
begin
  Interceptremove(@HookedExitProcess);
  HookedExitProcess:=nil;
end;

end;

Hier verhindere ich das verlassen eines Prozesses, aber wie kann ich nun Tastendrücke, Mausdrücke oder ähnliches verhindern?
MFG
derseitzer

[Assarbad]

Zitat von derseitzer:

Hier verhindere ich das verlassen eines Prozesses, aber wie kann ich nun Tastendrücke, Mausdrücke oder ähnliches verhindern?

Mit einem Fensterhook. Das ist aber eine andere Sorte Hook als du sie oben zeigst.

Aber auch diese Hooks haben ihre Grenzen. Wenn du ganz sichergehen willst, nimmst du Filtertreiber. Aber da kommste nicht mehr drum herum auch C zu lernen. Und selbst solche Treiber haben ihre Achillesfersen im Vergleich zu Hardwarelösungen. Am sichersten ist es die Tastatur und Maus vom Rechner zu trennen (Scherz! ).

[mensch72]

..."aber wie kann ich nun Tastendrücke, Mausdrücke oder ähnliches verhindern?"...

-> billigeste und einfachste Lösung:
- kaufe den billigsten 2..fach USB Umschalter oder 2..fach KVM Switch mit "TASTEN"
- kaufe ne billige 2+ Relaisplatine mit dokumentierer USB Ansteuerung
- schalte elektrisch jeweils den Relaiskontakt mit je 2Drähten parallel zu den Umschalttasten (ja da muss man das Umschalter Gehäuse meist per kaputtmachen dazu mal öffnen)
- Programmiere in deiner App "Relais1 für 1sec ein" zum Tastatur+Maus "zuschalten"
- Programmiere in deiner App "Relais2 für 1sec ein" zum Tastatur+Maus "abschalten"
=> das ist so einfachse Software, billig und nahezu 100% Manipulationssicher, da eine sogenannte "AirGapLösung"

[derseitzer]

@assarbad ich dachte alles was C kann kann delphi auch das wird hier doch immer so hoch angeprießen
@mensch72 sehr nett aber ich möchte trotzdem mal so einen Fensterhook programmieren aus Interesse eher weniger des zweckes wegen

[Luckie]

Programmiertechnisch stimmt das auch. Nur für Windowstreiber benötigst du Tools von Microsoft und die verstehen kein Delphi.

Hinzukommen die fehlenden Header Übersetzungen. Kann man zwar auch übersetzen, nur wird da ausgiebig Gebrauch von C Sprachfeatures gemacht, die sich nicht so einfach nach Delphi übersetzen lassen.

Es geht zwar, siehe NicoDe, aber es ist umständlich, unpraktisch und macht eigentlich keinen Sinn.

[Assarbad]

Zitat von Luckie:

Programmiertechnisch stimmt das auch.

Naja, vielleicht fällt diese Hürde bald. Zumindest für bestimmte Treiberarten. Denn Microsoft hat schon mit anderen Sprachen geliebäugelt. Bestimmte Usermode-Treiber können bereits heute in anderen Sprachen entwickelt werden, da sie pur auf Win32 aufsetzen.

Zitat von Luckie:

Hinzukommen die fehlenden Header Übersetzungen. Kann man zwar auch übersetzen, nur wird da ausgiebig Gebrauch von C Sprachfeatures gemacht, die sich nicht so einfach nach Delphi übersetzen lassen.

Eigentlich sind da - bis auf die Macros - nicht sonderliche viele C-spezifische Features.

Microsoft hatte beim DDK (Driver Development Kit, später in WDK: Windows Driver Kit umbenannt) bis zu den Versionen für Windows 2000 keine Toolchain (Compiler, Linker etc) beigelegt. Einspringen sollte damals die aktuelle Version von Visual C++. Das war umständlich. Mit dem DDK für XP änderte sich das und die Toolchain lag bei. Microsoft riet auch explizit davon ab die Toolchain von irgendeiner Visual C++ Version zu benutzen, sondern empfahl jene im DDK/WDK. Die entsprechenden Werkzeuge, die sich an das damalige Buildsystem für Windows anlehnten, waren aber umständlich. Dies führte zu Brückenlösungen wie VisualDDK oder meinem DDKWizard, der auch nur eine schöne Oberfläche für meine Neufassung von ddkbuild.cmd war (es gab/gibt noch die älteren Versionen von Don Burn und von OSR's ddkbuild.bat).

Es gab viele Rezepte bzgl. der Nutzung anderer Toolchains: Nico's Variante für Delphi darf hier ruhig erwähnt werden, aber auch welche unter Nutzung von GCC mit MinGW oder des Visual C++ Compilers. Alle diese Rezepte verkannten aber die speziellen Herausforderungen und richteten sich explizit gegen den Rat von Microsoft zum Thema Treiber. So gilt im Kernelmode eine Beschränkung des Stacks pro Thread. 12 KiB für "normale" Threads und knappe 64 KiB für GDI-Threads.

Code:

KERNEL_LARGE_STACK_COMMIT equ 03000H
KERNEL_LARGE_STACK_SIZE equ 0F000H
KERNEL_STACK_SIZE equ 03000H
DOUBLE_FAULT_STACK_SIZE equ 03000H

Typische Bugcheck-Codes im Fall des Überlaufs wären PANIC_STACK_SWITCH und UNEXPECTED_KERNEL_MODE_TRAP. Das passiert, wenn ein beliebiger Treiber zuviel Stack frißt. Und bei Filtertreibern, welche übereinander sitzen und dann als Stapel auf einem PDO aufsetzen, kann man sich denken, daß 12 KiB ziemlich knapp sind, wenn ein halbes Dutzend Filtertreiber im System nicht allzu ungewöhnlich sind und man als Treiberentwickler jederzeit mit Stacknotstand rechnen muß. Die Toolchains im den DDKs/WDKs bringen dazu spezielle Werkzeuge mit um mittels statischer Code-Analyse zu ermitteln wieviel Stack die Funktionen im eigenen Treiber fressen (Array auf dem Stack ist ja durchaus Usus für Usermode-Entwickler). Genau genommen war das DDK/WDK bis vor einiger Zeit die billigste Variante um an statische Analysewerkzeuge für Windows-C/C++-Entwicklung zu kommen. Es gibt noch weitere spezielle Werkzeuge die ebenfalls ausschließlich im DDK/WDK zu finden sind, weshalb es höchst unsinnig wäre hier krampfhaft zu versuchen an den vorhandenen Mitteln vorbei eine Lösung für ein eigentlich nicht vorhandenes Problem zu finden.

Und jetzt erkennt man auch was Luckie mit folgender Aussage gemeint haben könnte:

Zitat von Luckie:

Nur für Windowstreiber benötigst du Tools von Microsoft und die verstehen kein Delphi.

Erst mit Windows 8 besann sich Microsoft auf eine Integration des WDK in Visual C++. Präziser, Visual C++ ist heute die Voraussetzung für die neue Generation der WDKs, denen keine Toolchain mehr beiliegt. Damit schließt sich sozusagen der Kreis. Aber natürlich nicht ganz, denn als Treiberentwickler sind wir die absolute Minderheit, weshalb man bei Microsoft etwas schnarchnasig hinterherhinkt wenn es um die Anpassung der neuen WDKs an die aktuellsten VS-Versionen geht.