Ja, du kannst natürlich die Grafiktreiber im r0 beeinflussen.
Du kannst dazu einen Treiber schreiben, der das ganze bewerkstelligt, als Resource in dein Programm einbinden und dann erstellen und starten.
Die Frage ist, ob du das dir antun willst? Es gibt soweit ich weiß keine öffentliche Dokumentation über die r0 Implementation von DirectX, das heißt, du müsstest mit nem Kernel Debugger ankommen und alles selbst reversen.
Dazu kommt, dass viele Funktionen schon im Usermode implementiert sind.
Ich kann mir gut vorstellen, dass nur die Funktionen, die direkt mit der hardware interagieren, im Kernel implementiert sind und diese sind sicherlich gar nich aus dem Usermode direkt aufrufbar, sondern werden von den öffentlichen DX Funktionen aufgerufen.
Diese nehmen dann natürlich auch schon diverse Berechnungen und Arbeit mit den Parametern ab, deshalb bezweifle ich, dass die Zusammenhänge im Kernel noch so stark sind, dass du da einen ordentlichen DX Hook schreiben könntest.
Du wirst es sicherlich nicht so leicht haben, einfach eine R0DrawIndexedPrimitive zu hooken, die genau die gleichen Parameter wie die Usermode Funktion annimmt.
Du würdest also höchstwahrscheinlich eh nicht um eine Dll herum kommen, die an deinen Treiber gewisse Hinweise bezüglich der Parameter, die wichtig zur Fallunterscheidung sind, sendet.
Ach ja:
Ein Umleiten in deine Exe ist nicht möglich, du könntest höchstens den Code der Exe im Treiber implementieren und dann gewisse Dinge von der Exe abfragen, wenn du nicht alles im Kernelmode laufen lassen willst.
Mir bleibt die Frage:
Wieso das ganze? Eine Dll ist sicherer, angenehmer, leichter zu realisieren und du hast mehr Möglichkeiten, was den Hook angeht. Dlls kann man auch verstecken, sollte es um ein AntiCheat gehen.
Und wenn du eh schon bereit bist, einen r0 Treiber zu schreiben, auch im Kernel lässt sich die Dll verstecken; du kannst sie sogar direkt darüber injecten. Dann bleibt dem Zielprozess kaum noch eine Möglichkeit, die Dll zu finden.
|