Suche Windows 7 64-Bit fähiges Rootkit

Moin Leute, da ich meinen css cheat vor eac verstecken will, damit es nicht NtReadVirtualMemory hookt und somit meinen cheat außer Gefecht setzt und ich schon etliche Dinge erfolglos durchprobiert habe, dachte ich, ich verstecke meinen Prozess mit nem Rootkit vor EasyAntiCheat, damit es gar nicht erst in mienen Prozess injecten kann. Hat jemand eventuell ein windows 7 + 64-bit fähiges rootkit?
Greetz

was du suchst ist ein treiber und kein rootkit. und wenn "dein" css hack tatsächlich von dir kommt solltest du in 1-2 wochen so einen treiber auch selbst schreiben können - einen fremden nicht signierten treiber (oder gar ein rootkit) zu installieren ist ... nevermind go ahead, cheater.

Nur weil ich nen externen cheat schreibe, kann ich noch lange keinen treiber selbst schreiben. Abgesehen davon wär es mir auch nicht den Aufwand Wert, da ich den eigentlich eher für die Allgemeinheit mache, deshalb dachte ich ja auch an nen pub rootkit oder nen pub win 7 dkom prozess hider o.Ä.

Warum überhaupt einen Treiber machen? Ist doch totaler Schwachsinn, wenn man auch ohne Process Hiding den Hook von EAC relativ leicht aushebeln kann.

Aus demselben Grund warum Valve auf 64bit Systemen nur einen Usermode Schutz nutzt, kannst du diesen auch nur im Usermode aushebeln.
Aus nem kernelmode Rootkit wird so schnell nichts.

Das ergibt überhaupt keinen Sinn. Wenn ich im Kernelmode bin kann ich auf den physischen Speicherbereich (ram+pagefile) nach belieben zugreifen. Warum sollte ich also den Code vom Anticheat im Userland nicht verändern können? Und ein rootkit schleift zwar in der Regel kernelmode Komponenten mit, aber nicht notwendigerweise, siehe bluepill. Das virtualisiert Windows und arbeitet quasi noch eine Ebene ÜBER dem Kernel (daher der name, get it?)

Ob es sinn macht dafür in den Kernelmode zu wechseln ist eine andere Frage, mit sicherheit geht es auch ohne, aber warum nach schwachstellen suchen wenn ich aus dem Kernelmode nach belieben alle Prozessübergreifenden API Funktionen hooken kann, direkt im NT Prozess, der eben die finale gemeinsame Ebene zur Hardware für das 32 und 64bit Subsystem darstellt.

Afaik ist das bei den meisten Anticheat Systemen aber eh egal, da 'eigentlich' nach deutschem und europäischen Recht keine Daten von deinem Rechner ohne Zustimmung übermittelt werden dürfen außer denen, die zu dem Spiel gehören, also in dessen Speicherbereich liegen. Und den eigenen Speicherbereich zu lesen ist eine atomare Basisfunktion der Von-Neumann-Architektur, mov a,b cmp a,b jmpz x kann man nicht hooken, nur verändern. Und zumindest bei Blizzards Anticheat werden auch nur Dateien und der Speicherbereich des Spiels selbst gelesen und überprüft - im gegensatz zu dem Rotz der sich GameGuard nennt.

MrSmith hat da schon nicht ganz unrecht. Klar kannst du im Kernel praktisch alles machen, aber auf einem 64 Bit System einen unsignierten Treiber zu installieren ist nicht ohne großen Umstand (selbst signieren + testmode) möglich. Außerdem hast du bezüglich Rootkit dann noch mit dem PatchGuard zu kämpfen und dabei wünsche ich dir viel Erfolg.

@TE: Warum benutzt du überhaupt WriteProcessMemory und Konsorten? Wie wäre es, wenn du stattdesssen einfach deine DLL in den Spieleprozess injizierst und dann direkt auf die betroffenen Speicherbereiche zugreifst?

Quote:

Originally Posted by Saedelaere* MrSmith hat da schon nicht ganz unrecht. Klar kannst du im Kernel praktisch alles machen, aber auf einem 64 Bit System einen unsignierten Treiber zu installieren ist nicht ohne großen Umstand (selbst signieren + testmode) möglich. Außerdem hast du bezüglich Rootkit dann noch mit dem PatchGuard zu kämpfen und dabei wünsche ich dir viel Erfolg.

gut, man muss einmalig 5 buchstaben in die shell tippen und dann neustarten um in den testmode zu wechseln, aber das signieren übernimmt VS für dich direkt nach dem kompilieren, man muss nichtmal ein zertifikat dafür erstellen (obwohl selbst das nur eine sache von 2-3 minuten ist). und im testmode ist der patchguard deaktiviert (bzw. scannt nur nach bekannter malware im kernel anstatt bei jeder unbekannten software den kernel zu flushen). man darf halt nur keinen groben mist bauen - sonst wird der bildschirm blau... aber deswegen empfiehlt es sich in einer VM zu arbeiten, und die in einem i7 > 4ghz laufen zu lassen, dann dauerts vom sicherungspunkt bis zum gestarteten system i.d.r. nur 4-5 sekunden.

Quote:

Originally Posted by Saedelaere* MrSmith hat da schon nicht ganz unrecht. Klar kannst du im Kernel praktisch alles machen, aber auf einem 64 Bit System einen unsignierten Treiber zu installieren ist nicht ohne großen Umstand (selbst signieren + testmode) möglich. Außerdem hast du bezüglich Rootkit dann noch mit dem PatchGuard zu kämpfen und dabei wünsche ich dir viel Erfolg. @TE: Warum benutzt du überhaupt WriteProcessMemory und Konsorten? Wie wäre es, wenn du stattdesssen einfach deine DLL in den Spieleprozess injizierst und dann direkt auf die betroffenen Speicherbereiche zugreifst?

Ich benutze Wpm und Konsorten, da ich mich mit hooking allgemein nur wenig auskenne und ich den cheat außerdem pub stelle, und ne pub dll im bezug auf VAC(Valve Anti Cheat) ja eher kritisch ist, was aber wiederrum bei externen cheats kein Problem darstellt.

Quote:

Originally Posted by tnd0 im testmode ist der patchguard deaktiviert (bzw. scannt nur nach bekannter malware im kernel anstatt bei jeder unbekannten software den kernel zu flushen)

Das ist interessant. War mir bisher nicht bekannt. Hast du da irgendeine Quelle, die das belegen kann. Fals das stimmt, frage ich mich, warum MS das so implementiert hat. Im Produktivbetrieb kannst du doch sogar mit einem offiziell lizenzierten Treiber keine Kernel Strukturen mehr modifizieren, ohne dass der PatchGuard anschlägt, oder liege ich da auch falsch?

Mal allgemein: Strukturmodifikationen an EProcess z.b. sollte PG ja verhindern. Wie sieht es generell mit der SSDT aus? Sind Kernel Hooks bei aktiviertem PatchGuard noch möglich?

Nein und Ja. Wenn Patchguard in den systemkritischen Bereichen einen Hook oder ähnliches findet callt es Ke!BugCheck - um das System zu crashen. KeBugCheck ist die BlueScreenfunktion die laut msdn jeder Treiber aufrufen sollte wenn durch einen Fehler die Stabilität des Systems nicht mehr gewährt werden kann. Irrsinnigerweise braucht man bloß diese Funktion zuerst hooken und schon crasht das System nicht mehr - man muss sich anschließend allerdings um den Patchguard selbst kümmern da er solange KeDebugCheck versucht zu callen bis es klappt - also nach einem Hook theoretisch unendlich oft, wodurch ein Thread dauerhaft belegt werden würde.

Gut, das ist alles andere als "Patchguard deaktiviert" wie ich es oben geschrieben habe, aber rund die Hälfte der gesamtfunktionalität von Patchguard deaktiviert man, indem man im DebugMode bootet. Nur eben die kritischen Strukturen wie SSDT GDT IDT und MSRs sind noch durch Patchguard geschützt, der sessionmanager bspw. aber nicht mehr.

Wie gesagt, das alles ist möglich wenn erstmal im Kernel ist, was aber für die Sicherheit soweit kein Problem darstellt, da man trotzdem noch manuell in den DebugMode wechseln muss (bcdedit /set TESTSIGNING [ON|OFF]) - es sei denn man hat UAC deaktiviert.


edit: KeBugCheck, nicht kedebugcheck ..