KDU v1.2 release and the wonderful world of Microsoft incoherency

It's been a while since last KDU update and thanks to Artem Baranov from Kaspersky my attention is again on it. The new 1.2 release contain eight new providers and set of additional changes that were required for new providers work. Here is list of new providers added, the details on each are following:

• GMER "antirootkit"
• Dell BIOS Utility (assigned CVE-2021-21551)
• Mimikatz "Mimidrv"
• Process Hacker "KProcessHacker2"
• Process Explorer "ProcExp152"
• Dell BIOS Utility (assigned CVE-2021-36276)
• Cheat Engine
• ASUS GPU Tweak II/III (EneTech next-gen)

And after describing new providers we will take a tour into wonderful world of Microsoft incoherency with their newest Win10/Win11 drivers blacklist managed by CI.dll

Providers description 

(number is ID in KDU database)

15. GMER "antirootkit"

Pic 1. What could possible go wrong here

GMER "antirootkit", I'm familiar with this software since it birth and introduction by author (Przemyslaw Gmerek) on SysInternals forums during Rustock's first variants most active period. Since it first release it was a mediocre software with limited capabilities to detect or remove anything despite author claims (he still has a dedicated gallery on his long forgotten site). Since I was developing the same toolset during that time I of course reverse-engineered GMER to find out if there is anything interesting in it. It sounds fun but this is exactly how things were going in the 2005-2010 anywhere with tools developed by enthusiasts. Amount of copy-pasted techniques and code from different authors in different tools of this time is tremendous. GMER driver doesn't surprised me and except obvious bugs I didn't found anything else interesting in it, except number of simple ways how to completely make it blind in case of rootkit detection (we later implemented one of in our laboratory rootkit called Unreal so Gmerek was forced to do an emergency update 😅). Remember, it was year 2006 and Windows XP was all around and shiny again after general Vista fuckup. Entire class of this software died around 2011-2013 so I was surprised that GMER actually managed not only survive but move to x64 world. Ohh, better he doesn't. The actual x64 driver made of copy-paste from x86 version with few things adjusted to make it work on x64 and some features that are bound to x86 only completely removed. For some unknown reason it still has a branches of code that doesn't make any sense on x64, that shows how actually author didn't care about final product. Since acquiring by Avast their Avast MBR tool contain exact the same driver from GMER (because it's powered by "GMER technology", this is a fucking rofl yeah). From current perspective this driver is a wormhole and I'm surprised no one actually tried to exploit it for a fancy CVE id, almost just like Trend Micro tool highlighted in one of my previous posts. For KDU usage the most prominent features of GMER are arbitrary kernel virtual memory read and write. This is not a bug, it is intentionally created mess so GMER can read/write kernel memory via it's process. This feature implemented via MDL mapping and accessible with dedicated IOCTL with simple data structure. One important note is that before calling this (or any other IOCTL) you have to talk with GMER driver first to let it know it was "initialized". This is done with a special IOCTL. Note that GMER driver sets exclusive flag when creating it device object, however when application crash driver stays in memory and accessible for everyone.

TL;DR - current GMER is completely useless (and dangerous due to multiple bugs, just look on pic 1 - few seconds before BSOD) in terms of "rootkit detection" usage and represent a security risk by containing Windows security bypasses available without any proper verification of caller nor access checks. 

16. Dell BIOS Utility (assigned CVE-2021-21551)

This one is pretty simple and well described in CVE entry. This is a typical flaw in giveio-type drivers. It has memmove with completely user controlled parameters send by special IOCTL.  Such "features" aren't so rare in the wonderful world of hardware vendors drivers.

17. Mimikatz "Mimidrv"

This is auxiliary driver from Mimikatz tool which is open-source. Mimikatz is a well known tool and a lot of people found it damn useful. Well I'm not one of them. Speaking of mimidrv - it has full source available and by opening this source you will want to close it ASAP to not hurt your eyes with amount of shitcode you will face. It's a complete bugged wormhole which has number of built binaries with different versions all signed with a valid certificate. No wonder Microsoft banned this certificate in their HVCI blocklist which we will discuss later. We are interested here in arbitrary kernel virtual memory read/write IOCTL's, in fact they are almost the same as in GMER. You don't need any special preconditions to start using mimidrv. Here is the details on other features of mimidrv - Mimidrv In Depth: Exploring Mimikatz’s Kernel Driver if you are interested.

18. Process Hacker "KProcessHacker2"

It is famous tool and I remember how it was born. Process Hacker come at SysInternals forum with wj32 in the late 00s in form of open source task manager replacement written in C#. It was immediately criticized for this by forum members and after some reconsiderations wj32 ported it on more suitable programming language (thankfully there wasn't any cancer like Rust popular that days). PH roots from Windows XP era with same design and philosophy. That's how it started and worked just fine until Turla malware group widely popularized BYOVD (Bring Your Own Vulnerable Driver) attacks in 2014-2015. The mentioned PH driver KProcessHacker2 was abused by multiple actors starting from malware and ending up with cheat community. This followed with wave of antivirus detections and game bans. All because of this tool initial design and philosophy from Windows XP era. That is why it was full of wormhole functionality and still have it up-to-date. What is so unique in this driver? It provides a set of IOCTL's which work as Windows API replacements for several key to the Windows security functions. Just a few of them for example: OpenProcess, OpenThread, DuplicateHandle, TerminateThread, TerminateProcess, Set/GetThreadContext, Read/WriteProcessMemory. Natural hackbox isn't it? Earlier versions of PH code (which all nicely written and well documented) even contain remarks where author hopes that this driver client "is not a virus" so wj32 clearly predicted things can go worse 😏 We will go back to PH in the end of this post. For KDU tasks this driver maybe not looking good at first glance (it looks like more suitable for malware usage 😂), but then if you look on the things from a different perspective - hell yeah. Here is why - starting from ancient Windows NT versions up to latest Windows 10 release "System" process keeps handle to physical memory section. It was abused before for physical memory access and later Microsoft banned it from user mode usage by setting object header flag -> kernel only access so you can't open new handle for this section from the user mode. Later MS added protected processes feature which additionally blocked exploitation because you can't open "System" process with sufficient rights. And here Process Hacker driver comes to the rescue with it hackbox IOCTL's allowing us: open full process handle for "System" process, duplicate physical memory section handle to our process with same full access rights. Further is trivial. Important note about fancy new Windows 10 rebrand called Windows 11. There is no physical memory section handle in "System" process as I observed and it is too boring to figure out is it intentional or need any preconditions to make it popup again - you may consider this as homework.

19. Process Explorer "ProcExp152"

Rival of previous task manager. Or previous task manager is a rival to this, or new Windows 10/11 taskmanager is a rival to both or vice versa or..., I don't really follow this "task manager market war" which is a complete bullshit, just the fact that Process Explorer existed long before PH release and PH "release to public" place was Process Explorer developers forums. This is a small handy tool developed by Mark Russinovich before his acquiring by Microsoft and abandoning all his tools (they are now out-sourced to some Microsoft geniuses who decided to remake classic UI with new over overstretched buttons and idiotic bitmaps ruining your old UI experience, and oh-ah "dark mode" I forgot about it). Process Explorer driver provide limited set of features that works almost the same as hackbox from PH. Have you heard about AV detecting Process Explorer as malware? I didn't, maybe because it is signed by Microsoft?😄 Anyway, this driver does have access checks implemented at dispatch routine so it fits into Microsoft wonderland of what they call "security boundaries". It doesn't really matter for BYOVD, this driver allows process opening, handle duplication, process termination and more. It is used in KDU in a similar manner as KProcessHacker2 driver. Oh, it even re-used next by KDU as placeholder for the final shellcode, what an irony.

20. Dell BIOS Utility (assigned CVE-2021-36276)

The same as previous Dell driver except it has different steps required for loading and new device name. In fact this is example of "fix" similar to that I described in my previous blogpost. TL;DR Dell fixed nothing and posed this driver update as ultimate fix for previously reported vulnerabilities. KDU exploits 2.5 version driver as I didn't bothered to find 2.7, but from all the description etc it will work the same way on 2.7 you only need to change device name.

21. Cheat Engine

Pic 2. Cheat Engine 7.4

Infamous open-source tool mostly used for game cheating and cracking. Has a kernel mode component called DBK (DarkByte Kernel?) which is a wormhole by design with WHQL signature, yeah. This driver abused by malware in recent GhostEmperor attacks. KDU uses similar pattern to write and execute code in kernel mode. Cheat Engine author tried to complicate his driver usage by 3rd parties (most likely by other cheat programs) by introducing few pseudo-security checks implemented on driver side. None of them can be considered as sufficient and mentioned above malware fully bypass them. KDU uses driver from the up-to-date Cheat Engine 7.4 package and proxy application "kernelmodeunloader.exe" from the same package. This driver is in HVCI blocklist. Warning to these who want to try: while installing Cheat Engine package (from official site) may install you a bunch of scamware if you won't pay attention to installation process and just spam "Next" clicks. Note that Cheat Engine driver has some problems with Windows 7, so it may not work or load here.

Pic 3. Cheat Engine DBK load failure, Windows 7

22. ASUS GPU Tweak II/III (EneTech next-gen)

It is implementation of what is stated in my previous blogpost. Nothing changed since that time, ASUS continuously use this trash in a number of it software products up to date. Side note, they also introduced new driver which looks like heavy remake of original WinIO with most of it dangerous features stripped, however not all. It is a something to investigate later.

HVCI blocklist or welcome to wonderful world of Microsoft incoherency

This feature introduced with HVCI on Windows 10. It is implemented as blocklist stored in \systemroot\system32\codeintegrity\driversipolicy.p7b file as certificate blob and specific code at CI.DLL to manage it. Decoding this "driverspolicy" data maybe accomplished with the following PowerShell script -> https://gist.github.com/mattifestation/92e545bf1ee5b68eeb71d254cec2f78e. Microsoft maintains current state of this list on github -> https://github.com/MicrosoftDocs/windows-itpro-docs/blob/public/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules.md. This blocklist is loaded and parsed by CI.DLL in kernel mode and invoked when HVCI is enabled (Core Isolation -> Memory Integrity) and something is trying to load driver. If this driver (authenticode hash, page hash, filename from version block, filename and version range from version block) found in blocklist Windows will deny it loading and log event. Presumable this list will be updated and each new Windows 1X "release" will bring brand new blocklist. Or they even managed to do it auto updating didn't checked that, at least previous Windows 10 versions doesn't seems update it since install.

Lets take Process Hacker discussed above, but latest version, and try to load it as admin with HVCI enforced:

Pic 4. HVCI enforced block of kprocesshacker.sys

With event 5038 added to the system security event log: 

Code integrity determined that the image hash of a file is not valid.  The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.

File Name: \Device\HarddiskVolume3\ProcessHacker\kprocesshacker.sys

and NTSTATUS codes like STATUS_IMAGE_CERT_REVOKED and STATUS_DRIVER_UNABLE_TO_LOAD. This is actual Process Hacker v3.0 with valid digital signature and KProcessHacker3 which is immune to previous abuse by malware and cheaters. 

Why is this happening or welcome to wonderful world of Microsoft incoherency.

Microsoft added Process Hacker (PH) to HVCI blocklist just recently. There are no live examples of Process Hacker v3 abuse by malware except one from Crowdstrike dated back to 2019 and updated in the Dec 2021, https://www.crowdstrike.com/blog/how-doppelpaymer-hunts-and-kills-windows-processes/. This post gives you a brief to supposedly PH driver malicious usage involving full bypass of it integrated client verification introduced in 2.39 and still used in 3.0+. From that post you will learn that over-engineered approach which is used almost everywhere in PH code doesn't guarantee security and wormhole features are still can be used by 3rd party if they really want to. From my point of view malware authors has nothing else to do by choosing Process Hacker driver as their "provider" because:

1. There are exist alternatives with much simpler (or none at all) verification logic, using them you can achieve the same "terminator" features;
2. Process Hacker already signatured by various FakeAV as PUP/Tool/HackTool (or TrojanMulDrop lol) because it different old versions are used by malware and they share scan patterns.

Or they just wanted to piss-off PH authors showing them bypass of it over-engineered verification. Why then Microsoft doesn't considers its own Process Explorer (PE) driver as malicious security breaking tool? Lets leave aside "because it Microsoft signed lol" or "because it fits into security boundaries, have you saw secure device and SePrivilegeCheck?". If you compare how exactly PH and PE drivers does their "process" management you will notice that PH actually does it on lower level than PE. There are other functionally which is also should not exist at all - like duplicating handles, write/reading arbitrary processes memory, changing thread contexts etc. But lets start with simple thing, how PH and PE both acquire process handles. 

PH uses PsLookupProcessThreadByCid/PsLookupProcessByProcessId and ObOpenObjectByPointer. This allows it to skip ordinary access checks, ETW logging and... bypass some of the security products relying on filtering. It is basically reimplemented ntoskrnl ZwOpenProces->PsOpenProcess function with all the Se validation replaced with PH client/call verification. In comparison PE simple calls ZwOpenProcess with GENERIC_ALL desired access value. Both approaches are terrible piece of shit and comes from Windows XP era. If you need a handle to process/thread etc - use usermode call, that's is the only solid way to guarantee security and audit. If you still insist on accessing protected processes then entire operation should only take place in kernel after Windows security verification without returning anything important to usermode. Any termination/memory read/write from driver should be banned at all. This will however turn off "hacking" features of products as they won't be able to open/read/write everything. Sorry guys but this is how Windows now designed - if you not a part of trusted system code you can't access what ever you want. And there we have a dilemma - two drivers with wormhole functionality ideal for BYOVD attacks. One maintained open-source project, second proprietary Microsoft code without updates for decades. Both used by malware including APT. One in HVCI blocklist, second nope. I call this bullshit, Microsoft. What about PH, guys you are fucking process manager with extended features, not a Windows subsystem to replace or reinvent the MS security wheel just because you have nothing else to do and want to practice with system programming. Your "multi-purposing" is actually playing against you and serves no other purpose. You already removed a lot of "hacking" code from Process "Hacker" and still have a lot to remove/rework. Leave all this "hacking" to where it started - in the Windows XP era.

Another piece in this blocklist that attracted my attention is a number of strange drivers MS added seems by lurking on unknowncheats.me forum, including leaked certificates. Well it is good to know you lurk on most currently famous forum dedicated to kernel mode rootkits (what an irony yeah).

VBoxDrv innotek entry brings good old memories of Turla and later DSEFix/TDL. The only question here is why innotek only. Unlike popular opinion the exploit used by Turla group wasn't previously disclosed and therefore fixed in next versions, so basically it was a zeroday. This entire confuse makes you think that VirtualBox has only innotek signed Turla-style exploitable drivers. Meanwhile I would remember you that Sun acquired innotek GmbH in 2008 and later VirtualBox versions came out signed by Sun certificate. Since this vulnerability in vboxdrv wasn't fixed - all vboxdrv drivers at least up to 3.0 version are equally vulnerable and can be easily adopted to be used like in DSEFix or TDL 😉 (which was already done by some Chinese APT few years ago). Strange that this is not noticed by Microsoft.

Pic 5. The old the new thing

Ideally this blocklist should be twice or triple size bigger with only what is available on public today. No iobit, zemana fakeav drivers, no mihoyo, other anticheat crapware, no nVidia trash, no endless MSI packs of crap. Are you kidding, Microsoft? This is all available and exploitable. Right here, right now. Stop being a slowpoke, I've cookie for you.

Trend Micro's Rootkit Buster - Blast From The Past? Nope.

Pic 1. TrendMicro abandonware.

 

Recently I came across an article "How to use Trend Micro’s Rootkit Remover to Install a Rootkit" by Bill Demirkapi. It covers TrendMicro out of date antirootkit called "RootkitBuster". TL;DR it is dangerous software full of hacks and potential kernel level vulnerabilities. My interest was attracted by the part about some pieces of code author of blogpost found weird. After reading it I thought that I can actually answer on questions made in this blogpost. A little introduction and small excursion into history are required before we can move on to answering questions.

Long time ago in a galaxy far away

I'm familiar with this software since... hmm decades? It just so happened that I probably know one of the guys who worked on this software and in general familiar with this software class, it design and reasons why it looks so terrible from this year perspective.

Rootkit Buster is a classic 3rd generation antirootkit created in the second half of the 200x in response to dominance of kernel mode rootkits on MS Windows. Almost every ISV created this kind of software in that times, some made standalone tools like TrendMicro, Kaspersky, Avast, BitDefender, Sophos, F-Secure (with their infamous by it uselessness BlackLight). Some ISV incorporated their functionality directly into their mainstream products like for example Dr.Web or later Avast (when they acquired author of freeware GMER). Almost all of them were useless and never bothered rootkit developers to address their detection's in rootkit updates. There is a few exceptions of course like Dr.Web antirootkit engine and Kaspersky TDSSKiller. Aside of this anything else were merely a jokes. Entire battlefront with rootkits of that era was up to freeware tools made by enthusiasts. Starting from Rutkowska PoC's (like system virginity verifier, klister) and following 2nd generation with IceSword from pjf, Darkspy from CardMagic and wowocock and ending up 3rd generation with various tools like KDetective, RootRepeal, GMER many many of them (I have complete museum collection of them, including various versions, which is about 200 mb archive).

While notorious malware families of that time largely utilized kernel mode rootkit components it were developed by a really small group of original authors. It was obvious for everyone who were familiar with their design and implementation (winking for those I know). Later in the beginning of 201x they left and market was flooded with copy-pasted, "renewed" junk copies. It quickly degenerated completely and moved into limited usage in the APT, like for example Turla rootkit which is heavily inspired by 200x solutions for antidetection.

Really, really bad code?

Both rootkits/antirootkits were using completely undocumented stuff, internal Windows structures, doing with kernel basically all what they want in a completely unsafe manner. Was it bad code? Obviously, for reference you can look on KSBinSword - a Chinese IceSword copy-paste clone with source code available. Solutions it used were widely used in any other antirootkits of that times. Or look on more recent Kernel Detective with also now available source code. Unfortunately there was no way to successfully counteract malware rootkits without going on their or deeper level. Which required going deeper into undocumented thing and unsafe solutions. So was it really "bad" code? BSOD-generators for sure. Have you ever saw Kaspersky AV 6.0-7.0 source code? It is a ridiculous mess and their drivers are dangerous bugfest by design. Does it mean Kaspesrky 6/7 were failures? Nope, they both were highly successful and actually delivered a lot of problems for malware authors of that time. It was bad but it was adequate solution to that time. Simple because everything else was ineffective. This mess required operation system vendor response at first place. And MS did the job so now we can look into the past and be horrified.

Rootkit Buster is a direct successor of those times (it both design and code) and has been really polished compared to most of other ISV tools of this kind. This does not mean it is highly effective against dedicated malware it only mean that others are can be worse.

Bruteforcing Processes

What is the point of it and why not use documented API here, as blogpost author stated? It is a simple answer if you somewhat familiar with rootkit/antirootkit development. 

Usually we use the ZwQuerySystemInformation function in the kernel to traverse the process module and obtain the process information. This is through the normal process traversal method. Therefore, multiple rootkits will intercept the ZwQuerySystemInformation function to filter the specified process to realize the hidden process. At the time, you couldn't trust in regular API call result because they can be easily faked through DKOM or manipulations with API hooks on various levels. Trust no one except yourself - is a main slogan for antirootkits of that era. One of the first tools implemented PID bruteforce for detecting hidden processes was, suprise-surprise, F-Secure Blacklight. There is nothing wrong with this method, it quickly became outdated as rootkits managed to go deeper and started modifying kernel objects structures, however it still has right to exist. Of course all this apply to 200x era.

Bruteforcing Offsets

Why not use ZwQueryInformatonProcess with ProcessImageFileName here?

Again if you familiar with things answer is simple. Using API in that case will ultimately lead into malicious hook where returned data will be faked. Aside from this it is not an Rootkit Buster innovation - in fact they simple used same code snipped with known for ages Russinovich RegMon source code (or maybe even earlier). In an effort to remain version-independent, rather than using a hard-coded offsets, it scan the process object structure memory looking for the name, which should match that of the GUI process, see RegMon source code.

EPROCESS PEB Offset

Same as above. You can't trust API here unless you want to jump into rootkit trap. Notorious hardcore rootkits of that era always played at the edge of system collapse, modifying anything until the limit where they can't keep system alive anymore. Besides, offset are required to direct access to the kernel structures (thus avoiding all API hooks). Process Environment Block location is one of the key things for every antirootkit.

ETHREAD StartAddress Offset

Same as above. This offset needed for direct access to the object structure field. Additionally such scans are somewhat version independent code thus you don't need to hardcode 10-15 versions of ETHREAD offsets for single structure member if you have to support multiple Windows versions. None of API calls here (ZwQueryInformationThread) does makes any sense.

Pretty much all of the questions author made can be answered by just taking a look in any of "Rootkits blah blah blah" books dated back to 200x.

So Why?

RootkitBuster is a combination of out-dated techniques, methods from Windows XP era, that (it is my guess) are just blatantly copied from x86-32 and compiled for x64 without any actual refactoring (except part for making it compilable and verifier friendly ROFL). Obviously parts of code highlighted by author has a little sense (if any) on 64 bit Windows version with PatchGuard and other fancy security features built-in. In general this software has no sense on x64 and looks completely abandoned. It version 5 was released in 2011, do you see any hints here?

Just reversing of drivers for exploits is not enough for their code complete understanding. You have to be familiar with what they actually do and how this is implemented, not to say about baggage of experience in that field.

From a malicious usage perspective RootkitBuster also has nothing to offer. Take it as a sort of unusual museum exponent. If you want to look at really dangerous software actively developed and distributed under multiple "best security" crapware brands - take Zemana (or any of it pseudonyms) driver as example of complete hack-o-rama, right here, right now on x64.

BKAV - Arbitrary File Deletion Feature

Today post is a continuation of journey into the wonderful world of so called "security solutions" full of programming unicorns and other kind of pure magic. Today it will be about BKAV or Bkav, whatever. This software is from Vietnam. While it definitely better than previously analyzed "MaxSecure" scam, it still not something I would recommend to use 😊 If you care about your files, of course. 😅

Our target is BKAV Professional (Internet Security AI 2019 whatever this mean) - super duper last version available for download.

During it install and startup this software install and load the following drivers.

Pic 1. BKAV drivers.

All these drivers have devices everyone can access. It can take a while debugging and reversing all of them (despite most have identical code patterns) however I got success with my first driver I tried. It is called BkavSP.sys and this is "BKAV SD Minifilter Module", version 1.0.0.246. It is set to autoload each Windows boot with Start type set to SERVICE_SYSTEM_START. 

This driver has dispatch entry with user callable IOCTLs 0x2221CC, 0x22E141, 0x22E145. First one work with internal driver data, two others are more interesting. First is for file deletion, second is for file renaming. As filename they use parameter of device I/O control input buffer from user mode. However even if BKAV device called \Device\BkavSP has default security descriptor they can't be called directly without some little magic. This driver approves calls only from few processes that is hardcoded inside and requester checked everytime IOCTL 0x22E141 or 0x22E145 dispatch hit.

Approval algorithm is the following:

• Query requester full image path name, ZwQueryInformationProcess(ProcessImageFileName), shake it a bit, lower chars;

• Compare result with hardcoded values, if they equal - caller is trusted, process IOCTL.

Hardcoded values are: 

BkavService.exe, BluProService.exe, BkavFirewallService.exe, EnterpriseUpdateService.exe

They are expected to be in \SystemRoot\SysWOW64. And yes after installation there is at least one of them present - BkavService.exe. There is no validation if this is valid executables from BKAV or renamed or malicious, just filename comparison. Perhaps authors thinks if they are in SysWOW64 this protect them from tampering. That is a mistake. By the way I saw identical requester check in some trash from ASUS software with same pity result.

What we need to do is to run BkavService.exe with our code inside, create a typical zombie process. What is BkavService.exe? It is 32 bit application with requestedExecutionLevel = requireAdministrator set in embedded manifest. So we will use 32 bit loader and to be able to exploit this BKAVSP feature we need to bypass requireAdministrator manifest setting. We cannot modify this file as it in SYSWOW64 folder and we cannot use it from outside this folder. So we need another simple workaround. During CreateProcess phase we will create copy of our environment with RtlCreateEnvironment and extend it by RtlSetEnvironmentVariable with the new variable __COMPAT_LAYER with value RUNASINVOKER. Next this environment block will be supplied as parameter for CreateProcess API. This will override manifest setting and launch this BkavService.exe requiring administrator rights. From this zombie process we can do our "hack the planet" stuff. Even from Guest account.

The full source code below. As target for deletion selected Windows driver "pci.sys" with hardcoded path. You can use other filenames, they not necessary must be inside Windows directory.


I would suggest BKAV to reconsider the way they validate requester process, discover for yourself modern security API to secure driver devices and stop using code solutions found in Google search. Otherwise this is just another lolAV with loldrivers that only does damage to client PC. Moving this "security solution" to the Recycle Bin as usual.

Pic2. Running proof-of-concept from Guest account.

Pic 3. Inject success, device opened.

Pic 4. PCI.sys deleted successfully.

P.S. Journey will continue ⛵ The much more dangerous "security solutions" are still waiting for publication.