
Windows-Kernelmodus-Treiber mit User-Mode-Client, der IOCTL-basiertes Lesen/Schreiben von physischem und virtuellem Speicher, Page-Table-Walking, Pattern-Scanning und Eingabeemulation für Game-Cheating bereitstellt.
██╗ ██╗████████╗██╗ ██╗██╗██╗ ██╗███╗ ███╗
██║ ██║╚══██╔══╝██║ ██║██║██║ ██║████╗ ████║
██║ ██║ ██║ ███████║██║██║ ██║██╔████╔██║
██║ ██║ ██║ ██╔══██║██║██║ ██║██║╚██╔╝██║
███████╗██║ ██║ ██║ ██║██║╚██████╔╝██║ ╚═╝ ██║
╚══════╝╚═╝ ╚═╝ ╚═╝ ╚═╝╚═╝ ╚═════╝ ╚═╝ ╚═╝
Windows-Kernel-Mode-Treiber-Framework mit User-Mode-Client
[!IMPORTANT]
Das vollständige Projekt erhalten
Lösungsdateien sind über den Discord-Server verfügbar.
Interesse am Kauf des vollständigen Quellcodes? Kontaktiere mich auf Telegram oder Discord: @tonythimself.
Lithium ist ein Windows-Kernel-Mode-Treiber (lithium-kernel) in Kombination mit einem User-Mode-Client (lithium-usermode). Die Kommunikation erfolgt über eine benutzerdefinierte IOCTL-Schnittstelle und stellt Low-Level-Speichermanipulation, Page-Table-Walking und Eingabegerätesteuerungsprimitive bereit.
| Funktion | Beschreibung |
|---|---|
| Physischer Speicher R/W | Direktes Lesen/Schreiben physischer Adressen über MmCopyMemory |
| Virtueller Speicher R/W | Prozessübergreifender virtueller Speicherzugriff über MmCopyVirtualMemory |
| DTB-Auflösung | Extraktion der Directory Table Base über PFN-Datenbank-Enumeration |
| Page-Table-Walking | Lineare Adressübersetzung mit PML4/PDPT/PD/PT-Layer-Caching |
| Pattern-Scanning | IDA-artiges Signatur-Scanning über den Prozessspeicher |
| Speicherallokation | ZwAllocateVirtualMemory im Kontext des Zielprozesses |
| Speicherschutz | ZwProtectVirtualMemory im Kontext des Zielprozesses |
| Maus-Emulation | Maus-Eingabe auf Kernel-Ebene über MouClass-Service-Callback-Hook |
| Thread-Verschleierung | ETHREAD-Feld-Spoofing (Startadresse, CID, Erstellungszeit usw.) |
| NMI-Callback-Deaktivierung | NMI-Callback-Unterdrückung zur Debugger-Umgehung |
| Pool-Bereinigung | Entfernung von Big-Pool-Table-Einträgen aus dem Kernel-Pool-Tracker |
lithium/
├── lithium-kernel/ # Kernel-mode driver (KMDF)
│ ├── entry.cpp # DriverEntry entry point
│ ├── core/
│ │ ├── dispatch/ # IOCTL dispatch and request routing
│ │ ├── requests/
│ │ │ ├── directory-table-base/ # DTB resolution & page table walk
│ │ │ ├── image-base/ # Process module base retrieval
│ │ │ ├── mouse/ # Mouse input emulation via MouClass
│ │ │ ├── read-write/ # Physical and virtual memory R/W
│ │ │ └── virtual-memory/ # Allocate, protect, query, pattern scan
│ │ └── utilities/
│ │ ├── kernel/ # Module enumeration, NMI, thread ops
│ │ └── ... # Pool cleaner, CRT shim
│ └── dependencies/
│ ├── additional/
│ │ ├── crt/ # Minimal CRT implementation
│ │ ├── security/ # skCrypter string encryption, oxorany
│ │ └── structures/ # Shared invoke data structures
│ └── includes.hpp # Master include header
│
└── lithium-usermode/ # User-mode client
├── entry.cpp # Client entry point
├── core/
│ └── driver/ # IOCTL communication layer
└── dependencies/
├── additional/
│ └── structs.hpp # Page table entry unions & helpers
└── includes.hpp
Die Kommunikation wird durch Hooking der IOCTL-Dispatch-Routine eines vorhandenen Treibers (ProcObsrvesx.sys) hergestellt. Beim Laden lokalisiert das Kernel-Modul den Zieltreiber, sucht nach dessen IRP-Dispatch-Handler und überschreibt diesen mit einem Trampolin zu Lithiums eigenem hooked_ioctl. Der User-Mode-Client öffnet \\.\ProcObsrvesx und alle IOCTLs werden transparent durch den Hook umgeleitet.
| Code | Eingabestruktur | Aktion |
|---|---|---|
invoke_base | base_invoke { pid, handle } | Prozess-Image-Basis abrufen |
invoke_dtb | dtb_invoke { pid, dtb } | Directory Table Base auflösen |
invoke_read | read_invoke { pid, directory_table, address, buffer, size } | Physischen Speicher lesen |
invoke_write | write_invoke { pid, directory_table, address, buffer, size } | Physischen Speicher schreiben |
invoke_read_virtual | read_virtual_invoke { pid, address, buffer, size } | Virtuellen Speicher lesen |
invoke_write_virtual | write_virtual_invoke { pid, address, buffer, size } | Virtuellen Speicher schreiben |
invoke_allocate | allocate_invoke { pid, type, protection, address, size } | Virtuellen Speicher allokieren |
invoke_protect | protect_invoke { pid, protection, address, size } | Speicherschutz ändern |
invoke_virtual_query | query_virtual_invoke { pid, address, mbi } | Virtuelle Speicherinformationen abfragen |
invoke_pattern_scan | pattern_invoke { pid, signature, address, pattern_address } | Speicher nach Muster scannen |
invoke_move_mouse | mouse_invoke { x, y, flags, button_flags } | Mauseingabe emulieren |
Der Treiber iteriert über die von MmGetPhysicalMemoryRanges zurückgegebenen physischen Speicherbereiche, durchläuft die PFN-Datenbank, um den selbstreferenzierenden PML4-Eintrag zu lokalisieren, und validiert jede Page-Table-Ebene, um die korrekte Directory Table Base für einen gegebenen Prozess zu bestätigen.
Die Linear-zu-Physisch-Übersetzung durchläuft die vierstufige x64-Page-Table-Hierarchie (PML4 → PDPT → PD → PT) mit Caching pro Ebene. Unterstützung für große Seiten (2MB / 1GB) ist nach bestem Bemühen enthalten.
Der Treiber lokalisiert die Treiberobjekte MouClass und MouHID, löst den MouseClassServiceCallback aus der HID-Geräteerweiterung auf und injiziert MOUSE_INPUT_DATA-Pakete direkt in die Callback-Kette.
Wichtige ETHREAD-Felder — Erstellungszeit, Startadresse, Win32-Startadresse, Kernel-Stack, CID und Exit-Status — werden gespeichert und durch harmlose oder Null-Werte ersetzt. Beim Abbau werden die Originalwerte vor der Thread-Beendigung wiederhergestellt.
lithium.sln in Visual Studiolithium-kernel → lithium-kernel.syslithium-usermode → lithium-usermode.exeOder über MSBuild:
msbuild lithium.sln /p:Configuration=Release /p:Platform=x64
#include <core/driver/driver.hpp>
g_driver->initialize_handle();
DWORD pid = g_driver->get_process_id(L"target.exe");
g_driver->attach(pid);
g_driver->image_base = g_driver->get_image_base(0);
g_driver->dtb = g_driver->resolve_directory_table_base();
auto value = g_driver->read<uintptr_t>(g_driver->image_base + 0xOFFSET);
g_driver->mouse_event(-10, -10, 0, 0);