C++ [Driver] a fully featured KM driver ready to use for your external

[laithcool]

Today im sharing with you my KM driver which you can use to replace UM calls to read memory with KM via IOTCL, I'll leave the UM implementation to you since it shouldn't be that hard with the examples included in the README of the repository

Features​

• Process attachment with PID validation
• Memory reading with bounds checking and SEH protection
• Module base address resolution
• Process ID lookup by name
• Batch memory operations for performance
• Proper address validation (user space only, overflow protection)
• Clean IOCTL interface with buffered I/O

Technical Details​

• Device: \Device\laithdriver / \DosDevices\laithdriver
• 5 IOCTL operations (attach, read, get_module, get_pid, batch_read)
• Uses MmCopyVirtualMemory for safe memory copying
• Includes usermode wrapper class for easy integration
• MIT licensed

Safety Features​

• Address range validation (0x10000 - 0x7FFFFFFFFFFFF)
• Size limits (4KB single, 8KB batch per request)
• Integer overflow detection
• Exception handling with __try/__except
• Proper process reference management

Repository Link:

Пожалуйста, авторизуйтесь для просмотра ссылки.

​

 

[learncpp]

Today im sharing with you my KM driver which you can use to replace UM calls to read memory with KM via IOTCL, I'll leave the UM implementation to you since it shouldn't be that hard with the examples included in the README of the repository

Features​

• Process attachment with PID validation
• Memory reading with bounds checking and SEH protection
• Module base address resolution
• Process ID lookup by name
• Batch memory operations for performance
• Proper address validation (user space only, overflow protection)
• Clean IOCTL interface with buffered I/O

Technical Details​

• Device: \Device\laithdriver / \DosDevices\laithdriver
• 5 IOCTL operations (attach, read, get_module, get_pid, batch_read)
• Uses MmCopyVirtualMemory for safe memory copying
• Includes usermode wrapper class for easy integration
• MIT licensed

Safety Features​

• Address range validation (0x10000 - 0x7FFFFFFFFFFFF)
• Size limits (4KB single, 8KB batch per request)
• Integer overflow detection
• Exception handling with __try/__except
• Proper process reference management

Repository Link:

Пожалуйста, авторизуйтесь для просмотра ссылки.

​

Пожалуйста, авторизуйтесь для просмотра ссылки.

bro can u do something urself?

ну и что ты будешь делать если все таки output_buffer переполнится?(и это только одна из проблем их еще достаточно)
как всегда говно переделывай пастерок

 

[laithcool]

Пожалуйста, авторизуйтесь для просмотра ссылки.

bro can u do something urself?

whats wrong with using a base and expanding on it? even that driver you linked is not his, its from cazz from youtube and mine clearly has much more functionality and reading is done much faster and much more secured against BSOD, i dont see the issue here

 

[learncpp]

whats wrong with using a base and expanding on it? even that driver you linked is not his, its from cazz from youtube and mine clearly has much more functionality and reading is done much faster and much more secured against BSOD, i dont see the issue here

dude ur code is literally practically no different from whats been on github for quite sometime now the fact that u added codes::batch_read doesnt change anything(because writing code through the chat gpt is really cool ofc, but u have a ton of problems with just that)

 

[morphe-ya]

using ioctl as a communication tool to create an external project is not a good idea

the main problem of this communication is: speed
this is how ioctl works: DeviceIoControl -> NtDeviceIoControlFile -> syscall handler -> real NtDeviceIoControlFile -> IoCallDriver -> Ioctl Handler

also, ioctl is one of the most insecure communications, it is literally detected by almost all kernel-mode anti-cheats. if you consider it as a solution for cs2 - okay, but for other games with kernel mode anti-cheats (be, gameguard, eac, mrac), you will get a ban during the game with the loaded driver

but in any case, thank you, laithcool, this topic will be useful for beginners.

 

[learncpp]

using ioctl as a communication tool to create an external project is not a good idea

the main problem of this communication is: speed
this is how ioctl works: DeviceIoControl -> NtDeviceIoControlFile -> syscall handler -> real NtDeviceIoControlFile -> IoCallDriver -> Ioctl Handler

also, ioctl is one of the most insecure communications, it is literally detected by almost all kernel-mode anti-cheats. if you consider it as a solution for cs2 - okay, but for other games with kernel mode anti-cheats (be, gameguard, eac, mrac), you will get a ban during the game with the loaded driver

but in any case, thank you, laithcool, this topic will be useful for beginners.

только ioctl не медленный вызов DeviceIoControl → NtDeviceIoControlFile → ядро -> драйвер нууу да цепочка длинная в принципе только вот она очень быстрая особенно для мелких буферов(средняя задержка вызова 1-2 микросекунды даже меньше)
утверждение про то что ioctl это один из самых небезопасных способов ipc тоже неверное
весь твой месседж короче это мусор относительно

 

[laithcool]

using ioctl as a communication tool to create an external project is not a good idea

the main problem of this communication is: speed
this is how ioctl works: DeviceIoControl -> NtDeviceIoControlFile -> syscall handler -> real NtDeviceIoControlFile -> IoCallDriver -> Ioctl Handler

also, ioctl is one of the most insecure communications, it is literally detected by almost all kernel-mode anti-cheats. if you consider it as a solution for cs2 - okay, but for other games with kernel mode anti-cheats (be, gameguard, eac, mrac), you will get a ban during the game with the loaded driver
but in any case, thank you, laithcool, maybe this topic will be useful for beginners.

yeah this is not tailored towards KM anti cheats but rather just VAC, i only made this to work on my fork of DragonBurn (

Пожалуйста, авторизуйтесь для просмотра ссылки.

) which i reworked alot of things such as :
- rewritten the entire cheats.cpp main loop
- added a proper vpk vischeck
- optimized the entire cheat (150~ fps to a stable 500~ fps) the entire cheat loop is running on 1800 cpu cycles lol
- reworked ESP to use batch rendering instead of rendering every element and every player and every text with a seperate draw call we just collect everything then render lol
- reworked the triggerbot system to a proper raycast and triggerbot system (well not fully proper since i havent implemented hitbox capsules yet)
- added humanization to aimbot
- instead of calling read memory on every call to KM, we just do a single batch call to collect everything and sort it on UM and use it

and much more stuff which i forgot to mention
forgot to add: made it support fullscreen
also forgot to add: MultiThreaded the main loop too lol

 

[morphe-ya]

только ioctl не медленный вызов DeviceIoControl → NtDeviceIoControlFile → ядро -> драйвер нууу да цепочка длинная в принципе только вот она очень быстрая особенно для мелких буферов(средняя задержка вызова 1-2 микросекунды даже меньше)
утверждение про то что ioct lэто один из самых небезопасных способов ipc тоже неверное
весь твой месседж короче это мусор относительно

ты не прав
ioctl действительно является одной из самых медленных коммуникаций
сравни скорость обрабатывания большого количества энтити используя ioctl, data pointer swap, shared memory
после этого у тебя будет право что-то предъявлять мне

у того же самого EasyAntiCheat / BattlEye есть большое количество методов обнаружения ioctl коммуникации ( PsLoadedModuleList, EtwTiLogDriverObjectLoad, создание пулов при вызове io create driver и многое другое )

 

[laithcool]

only ioctl is not a slow call DeviceIoControl → NtDeviceIoControlFile → kernel -> driver well yes the chain is long in principle only it is very fast especially for small buffers (average call delay is 1-2 microseconds even less)
the statement that ioctl is one of the most insecure ipc methods is also incorrect
your whole message in short is garbage relatively

whats your issue dude? who made you angry lol, if you dont like something u can just skip the message, there's no need to hate on random ppl

 

[learncpp]

whats your issue dude? who made you angry lol, if you dont like something u can just skip the message, there's no need to hate on random ppl

i didnt hate anyone and i didnt get angry at anyone the person is wrong and received criticism

 

[laithcool]

i didnt hate anyone and i didnt get angry at anyone the person is wrong and received criticism

nah ur angry, you came commenting on my post about my driver being pasted from someone and you dont even know where that original driver came from and how much its diffrient, i literally wrote it in a day to work on my fork of dragonburn and decided to release it for ppl to stop getting banned with externals, ready to use driver fully works on all windows versions

 

[learncpp]

ты не прав
ioctl действительно является одной из самых медленных коммуникаций
сравни скорость обрабатывания большого количества энтити используя ioctl, data pointer swap, shared memory
после этого у тебя будет право что-то предъявлять мне

у того же самого EasyAntiCheat / BattlEye есть большое количество методов обнаружения ioctl коммуникации ( PsLoadedModuleList, EtwTiLogDriverObjectLoad, создание пулов при вызове io create driver и многое другое )

он медленный только если вызывать его на каждую "сущность" отдельно тогда издержки на каждый переход usermode → kernelmode становятся ощутимыми
и говорить опять таки что ioctl действительно является одной из самых медленных коммуникаций бред ведь с batch обработчиком ioctl спокойно укладывается в 1–2 микросекунды на вызов

nah ur angry, you came commenting on my post about my driver being pasted from someone and you dont even know where that original driver came from and how much its diffrient, i literally wrote it in a day to work on my fork of dragonburn and decided to release it for ppl to stop getting banned with externals, ready to use driver fully works on all windows versions

yes this is all cool ofc only ur driver is very similar to the one that has been lying around on github for quite sometime(my complaint was precisely because of this i think there would be no problem leaving the credits)

 

[laithcool]

он медленный только если вызывать его на каждую "сущность" отдельно тогда издержки на каждый переход usermode → kernelmode становятся ощутимыми
и говорить опять таки что ioctl действительно является одной из самых медленных коммуникаций бред ведь с batch обработчиком ioctl спокойно укладывается в 1–2 микросекунды на вызов

which's exactly

Пожалуйста, авторизуйтесь для просмотра ссылки.

im

Пожалуйста, авторизуйтесь для просмотра ссылки.

 

[morphe-ya]

он медленный только если вызывать его на каждую "сущность" отдельно тогда издержки на каждый переход usermode → kernelmode становятся ощутимыми
и говорить опять таки что ioctl действительно является одной из самых медленных коммуникаций бред ведь с batch обработчиком ioctl спокойно укладывается в 1–2 микросекунды на вызов

опять таки, если попытаться обработать одинаковые данные драйвером, использующий Ioctl, Data Pointer Swap или же Shared Memory, то ты ощутишь колоссальную разницу между скоростями ( в пользу НЕ ioctl'a )
я тебе это говорю по личному опыту
также, я не понимаю почему ты считаешь, что ioctl не является небезопасной коммуникацией, когда я тебе написал про несколько детект векторов данной коммуникации

 

[laithcool]

it is slow only if you call it for each "entity" separately, then the costs for each transition usermode → kernelmode become noticeable
and to say again that ioctl is really one of the slowest communications is nonsense, because with the batch handler ioctl easily fits into 1-2 microseconds per call

yes this is all cool ofc only ur driver is very similar to the one that has been lying around on github for quite sometime(my complaint was precisely because of this i think there would be no problem leaving the credits)

we both used cazz driver, which he released on youtube and github, only diffrience is that he copied it 1:1 and i made signifact changes and yet you think im pasting from him lol

 

[learncpp]

опять таки, если попытаться обработать одинаковые данные драйвером, использующий Ioctl, Data Pointer Swap или же Shared Memory, то ты ощутишь колоссальную разницу между скоростями ( в пользу НЕ ioctl'a )
я тебе это говорю по личному опыту
также, я не понимаю почему ты считаешь, что ioctl не является небезопасной коммуникацией, когда я тебе написал про несколько детект векторов данной коммуникации

вопрос был только про ioctl и про его скорость(изначально никакого упоминания о shared memory/data pointer swap не было)
никакого отношения ioctl к детекту векторов(по типу psloadedmodulelist или etw) не имеет ведь iotcl это просто хуйня которая общается с драйвером
детектится не сам ioctl а факт существования и активности драйвера особенно если он создан стандартным способом и не маскируется

we both used cazz driver, which he released on youtube and github, only diffrience is that he copied it 1:1 and i made signifact changes and yet you think im pasting from him lol

ur changes are additions to batch code(and even that can be improved, maybe someday I'll make a pull request on github)
i didnt try to hurt u in anyway

 

[morphe-ya]

вопрос был только про ioctl и про его скорость(изначально никакого упоминания о shared memory/data pointer swap не было)
никакого отношения ioctl к детекту векторов(по типу psloadedmodulelist или etw) не имеет ведь iotcl это просто хуйня которая общается с драйвером
детектится не сам ioctl а факт существования и активности драйвера особенно если он создан стандартным способом и не маскируется

если у тебя есть минимальные знания в обратной разработке, то ты можешь загрузить ntoskrnl.exe в иду, подгрузив PDB к нему же ( он автоматически скачается с майкрософт сервера ), то открой функцию IoCreateDriver, где есть упоминания про PsLoadedModuleList, EtwTiLogDriverObjectLoad

а кстати, если ты попытаешься очистить / анликнуть свой драйвер с PsLoadedModuleList, то тебя бсоднет через 30 секунд вследствие того, что ты тригернул PatchGuard ( технология защита, которая предотвращает изменение кода в >= ntoskrnl && <= ntoskrnl + size )

вопрос был только про ioctl и про его скорость(изначально никакого упоминания о shared memory/data pointer swap не было)

про скорость ioctl я говорил только в контексте сравнения со скоростями с другими коммуникациями.

 

[learncpp]

если у тебя есть минимальные знания в обратной разработке, то ты можешь загрузить ntoskrnl.exe в иду, подгрузив PDB к нему же ( он автоматически скачается с майкрософт сервера ), то открой функцию IoCreateDriver, где есть упоминания про PsLoadedModuleList, EtwTiLogDriverObjectLoad

а кстати, если ты попытаешься очистить / анликнуть свой драйвер с PsLoadedModuleList, то тебя бсоднет через 30 секунд вследствие того, что ты тригернул PageGuard ( технология защита, которая предотвращает изменение кода в >= ntoskrnl && <= ntoskrnl + size )

Посмотреть вложение 309892

про скорость ioctl я говорил только в контексте сравнения со скоростями с другими коммуникациями.

все что ты описал это классические детект векторы для драйвера и с этим никто не спорит
но речь шла вообще конкретно про ioctl как способ коммуникации а не про IoCreateDriver PsLoadedModuleList или EtwTiLogDriverObjectLoad
ioctl сам по себе не создает дополнительного детекта он просто использует уже существующий DeviceObject который да может быть детектед но это не проблема ioctl а вопрос того как драйвер реализован и загружен

про скорость ioctl я говорил только в контексте сравнения со скоростями с другими коммуникациями.

ок

 

[morphe-ya]

все что ты описал это классические детект векторы для драйвера и с этим никто не спорит
но речь шла вообще конкретно про ioctl как способ коммуникации а не про IoCreateDriver PsLoadedModuleList или EtwTiLogDriverObjectLoad
ioctl сам по себе не создает дополнительного детекта он просто использует уже существующий DeviceObject который да может быть детектед но это не проблема ioctl а вопрос того как драйвер реализован и загружен

если ты загрузишь драйвер мануал мапом, используя тот же самый kdmapper, то два аргумента драйвера будут нулевыми. тем самым тебе будет ПРОСТО НЕОБХОДИМО вызвать IoCreateDriver, который СОЗДАСТ DeviceObject, запишет его в psloadedmodulelist, вызовет EtwTiLogDriverObjectLoad, добавив вектор детекта анти читом.

все что ты описал это классические детект векторы для драйвера и с этим никто не спорит
но речь шла вообще конкретно про ioctl как способ коммуникации а не про IoCreateDriver PsLoadedModuleList или EtwTiLogDriverObjectLoad
ioctl сам по себе не создает дополнительного детекта он просто использует уже существующий DeviceObject который да может быть детектед но это не проблема ioctl а вопрос того как драйвер реализован и загружен

Посмотреть вложение 309894

ок

я тебе дальше в сообщение пояснил, почему я назвал ioctl медленной коммуникацией.

 

[learncpp]

если ты загрузишь драйвер мануал мапом, используя тот же самый kdmapper, то два аргумента драйвера будут нулевыми. тем самым тебе будет ПРОСТО НЕОБХОДИМО вызвать IoCreateDriver, который СОЗДАСТ DeviceObject, запишет его в psloadedmodulelist, вызовет EtwTiLogDriverObjectLoad, добавив вектор детекта анти читом. Посмотреть вложение 309895Посмотреть вложение 309896

я тебе дальше в сообщение пояснил, почему я назвал ioctl медленной коммуникацией.Посмотреть вложение 309897

ты опять немного уходишь от сути речь была не про создание драйвера а про ioctl как способ коммуникации между юзермодом и кернелмодом
да IoCreateDriver может триггернуть ETW и добавить объект в PsLoadedModuleLis это очевидно но это не часть самого ioctl это вопрос того как и чем драйвер грузится

если ты уже работаешь с драйвером у которого DeviceObject создан и он корректно замаплен то ioctl просто способ обращения к нему
а дальше уже все зависит от реализации хочешь сделай батч хочешь пиши через shared memory детектится не ioctl а контекст в котором он используется
так что мой пойнт остается в силе ioctl сам по себе не дает дополнительного детекта это просто механизм вызова