{
	"id": "4cd14289-6271-4fd1-8fc1-becb97cb387d",
	"created_at": "2026-04-06T00:17:33.44232Z",
	"updated_at": "2026-04-10T03:20:04.876902Z",
	"deleted_at": null,
	"sha1_hash": "2fd914b81c3a0a63bb5e80d1e63f0c23e9904809",
	"title": "Remsec driver analysis - Part 2",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2426867,
	"plain_text": "Remsec driver analysis - Part 2\r\nBy Artem Baranov\r\nArchived: 2026-04-05 21:47:20 UTC\r\n📌 Chapters:\r\nIntroduction\r\nSome basic terms\r\nHowto\r\nExploring Win11 disk subsystem\r\nSet up a secure environment\r\nOverview of the driver\r\nPatching kernel data\r\nSecuring disk I/O operations\r\nSecuring file I/O operations\r\nTracing kernel mode code\r\nAbout PPL'ed processes\r\n📝 Introduction\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 1 of 28\n\nGMER is a well-known powerful anti-rootkit tool, which has been used for years by Windows IT pros to detect\r\nthe presence of rootkits in the system. A rootkit is a kind of malicious software intended to hide the components\r\nand artifacts of malware. Historically, rootkits can be divided into two types: user mode (Ring 3) and kernel mode\r\n(Ring 0). Nowadays, there are also malicious implants designed to work at the hypervisor (Ring -1) and SMM\r\n(Ring -2) privilege levels. We're gonna focus on the most common type, the kernel mode rootkit, and will simply\r\nrefer to it as a rootkit.\r\nRootkits were popular in the Windows x86 era, when there were no restrictions on intercepting anything in\r\nprivileged kernel mode. Typically, rootkits use three types of techniques: hooking, patching, DKOM. We won't\r\ndelve into them in detail, but it's worth noting that the first one is used to replace a pointer to the necessary\r\nfunction in the function table, the second involves inline code patching and the third is used to modify members of\r\nkernel objects such as KTHREAD or EPROCESS.\r\nThe authors of other well-known anti-rootkits have dropped their support due to the growing dominance of the\r\nx64 platform and the emergence of new Windows versions. The restrictions imposed on kernel mode code on this\r\nplatform have affected not only rootkits but also anti-rootkits. Rootkits have lost the ability to gain control over\r\nthe system making anti-rootkit checks useless. Nevertheless, some rootkits were able to bypass the new security\r\nperimeter by rebooting the system with the test signing bootloader option. One of them was Necurs, along with\r\nseveral other bootkits.\r\nUnlike other anti-rootkits, GMER has an x64 version of the driver, although doesn't support modern versions of\r\nWindows. It has an impressive arsenal of clever tricks for detecting the presence of rootkits and unhooking them,\r\nwhich can be useful nowadays. Since malware aims to detect the launch of GMER, it drops the driver to disk with\r\na random name and deletes it once it's loaded. This way, the malware can't block its loading. Within the tool, the\r\ndriver, which is located in the resource section, is packed twice: the tool itself is packed with UPX and its\r\nunpacked version stores the compressed driver. The tool's executable is also landed on the disk with a random\r\nname.\r\n📖 Some basic terms\r\nAnti-rootkit - a standalone tool/utility or component within a security product that is designed to deeply inspect\r\nWindows environment at both user and kernel mode levels to detect system anomalies.\r\nDirect Kernel Object Manipulation (DKOM) - a rootkit technique that means modification of Windows kernel\r\nobjects through direct access to them without any API.\r\nDisk driver - a Windows driver called disk.sys that is responsible of processing disk I/O operations usually\r\ncoming from the partition manager (PartMgr.sys), volume manager (Volmgrx.sys) or any other clients via\r\n\\PhysicalDriveX objects. In fact, the classpnp.sys driver dispatches all disk.sys driver requests.\r\nDisk port driver - while disk.sys implements a high-level logic of communication with various disk types\r\nconnected to different interfaces, the disk port driver is designed to communicate with a specific disk device.\r\nThere are several common disk port drivers such as atapi.sys, scsiport.sys, ataport.sys, storport.sys.\r\n🔬 Howto\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 2 of 28\n\nTo extract the driver, the dropper first should be unpacked. The driver inside the resource section of the dropper is\r\ncompressed with zlib. In order to decompress it, I personally simply used the built-in VirusTotal decompressor. In\r\nthe Relations tab, you can find a link to the report with the decompressed driver.\r\nC:\\test\u003eupx -d -o C:\\test\\gmer\\gmer_unpacked.exe C:\\test\\gmer\\gmer.exe    \r\nTo make the analysis process faster, I ran GMER on my Win7 SP1 x64 VM and took a kernel memory dump.\r\nSince the dump contains the driver with already initialized variables and decrypted text strings, we can determine\r\nthe purpose of each pointer in the disassembled version of the driver. Next, we need to rebase the driver loaded\r\ninto IDA so that the offsets of both drivers are identical.\r\nEdit-\u003eSegments-\u003eRebase program...\r\n🔐 Set up a secure environment\r\nAny anti-rootkit shouldn't trust the environment in which it works. Members of kernel mode objects, pointers in\r\ndispatch tables, the integrity of the WinNT kernel executable, and drivers - all this stuff may already be\r\ncompromised before an anti-rootkit is launched.\r\nA secure environment means a set of artifacts such as kernel object pointers, their values, kernel function pointers,\r\nthat have been retrieved or restored in a secure way and are suitable for further use.\r\nGMER takes the following actions to initialize its own secure environment in DriverEntry.\r\nTo construct names of driver objects of interest on the stack, such as \\Filesystem\\Ntfs, \\Driver\\Disk,\r\n\\Driver\\atapi.\r\nTo select kernel object offsets depending on the OS version, including, EPROCESS.Peb,\r\nEPROCESS.UniqueProcessId, KPROCESS.ThreadListHead, ETHREAD.StartAddress, etc.\r\nIn case of an unknown Windows version, it obtains those offsets through manual analysis of the\r\nappropriate ntoskrnl functions, such as PsGetProcessPeb, PsGetProcessSectionBaseAddress, etc.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 3 of 28\n\nDynamically resolves some important imports such as IofCompleteRequest and IofCallDriver using\r\nMmGetSystemRoutineAddress.\r\nTo map the NT layer DLL ntdll.dll, which is used further to get additional information.\r\nTo obtain the start address of loaded Ntfs.sys and Fastfat.sys, locate the entry point and scan it for a\r\nspecific signature to retrieve the real address of their IRP_MJ_CREATE handlers.\r\nTo get information about loaded ataport.sys and scsiport.sys. These drivers are responsible for low-level\r\ndisk communication.\r\nTo use its own PE export parser and get the addresses of the sensitive functions listed below.\r\nFor most of the kernel objects offsets, GMER obtains them by analyzing the following functions.\r\nThe following driver function looks up for most offsets due to their simple structure at the beginning.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 4 of 28\n\nThe situation varies when it comes to finding the corresponding EPROCESS and ETHREAD fields used to collect\r\ninformation about threads, as different Windows versions use a different number of lists.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 5 of 28\n\nGMER obtains the addresses of nt!Zw exports (services) in a tricky way. First, it obtains the\r\nKeServiceDescriptorTable address by finding a 8-byte signature \"8B F8 C1 EF 07 83 E7 20\" and two other values\r\nin ntoskrnl, which represent the following instructions inside the KiSystemServiceStart function. As a starting\r\npoint, it takes the address of the nt!strnicmp function and scans it to the KdDebuggerNotPresent variable.\r\nThe disposition of the target ntoskrnl functions.\r\nTo obtain the address of a specific ntoskrnl!Zw function, it maps Ntdll and retrieves from it the address of the\r\nrequired export function. Next, it grabs the System Service Number (SSI) from the second instruction of the\r\nexport, which is identical for all of them: mov eax, SSN (B8 3F 00 00 00).\r\nWith these pieces together, the process of obtaining ntoskrnl exports for Zw services looks as follows:\r\n1. To get an export function address from the mapped Ntdll.\r\n2. To take the SSN from the second instruction of the function.\r\n3. To use this SSN as an index in the KeServiceDescriptorTable.KiServiceTable array and calculate the\r\nappropriate Zw function address. Note that the pointers in this array are protected by PatchGuard.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 6 of 28\n\nAn interesting fact is that when scanning ntoskrnl data between strnicmp and KdDebuggerNotPresent to find the\r\naddress of KeServiceDescriptorTable, the driver doesn't validate the current pointer with MmIsAddressValid. Since\r\nthe space between these symbols belongs to multiple ntoskrnl sections, one of them may be INIT, which may be\r\nalready discarded from memory.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 7 of 28\n\n📖 Overview of the driver\r\nThe driver provides its user mode counterpart with various valuable interfaces aimed at obtaining trustworthy data\r\nabout the Windows environment. These features are available via the appropriate IOCTL codes listed below. After\r\nobtaining the necessary data, GMER compares it with the data obtained through regular Windows API and report\r\nto the user about the detected anomalies.\r\nBasically, to supply the requested data, the driver leverages Windows kernel API, low-level disk and file system\r\naccess skipping the intermediate filters, DKOM and custom implementation of some Windows kernel functions.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 8 of 28\n\nDuring initialization, the driver creates a separate thread to execute the following operations in the System process\r\ncontext: shutdown system, read process memory, suspend thread, query information about thread, process, system,\r\nand system registry. When the GMER's DeviceIoControl handler, which is executed in the current process context,\r\nrecognizes one of those IOCTLs, it builds the context structure with a pointer to a specific handler and sets the\r\nappropriate event that triggers another thread to execute it.\r\n📚 Exploring Win11 disk subsystem\r\nBefore we start discussing the topic, let's take a look at some basic aspects of Windows disk subsystem.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 9 of 28\n\nThe Disk.sys driver is responsible for dispatching storage devices I/O. The client must specify the offset from the\r\nbeginning of the disk and data length. The driver in turn redirects this request to one of the corresponding disk\r\nport drivers.\r\nWe can start by exploring disk device stack and go deeper.\r\nAs we can see there are four devices on that device stack.\r\nThe first one belongs to the partition manager and presents the device of the raw disk partition. Partmgr\r\nforwards the disk I/O request further to the disk driver, providing it an LBA instead of a partition offset.\r\nThe second device belongs to the disk driver itself, described above.\r\nThe next device was created by the common driver acpi.sys which, essentially simply forwards disk I/O\r\nrequests to the port driver. The responsibilities of Acpi. sys include support for power management and\r\nPlug and Play (PnP) device enumeration.\r\nThe latter belongs to the iaStorVD disk port driver (Intel Rapid Storage Technology) and is used in many\r\ncomputers with Intel chipsets. Being a disk port driver, it's responsible for low-level communication with a\r\nspecific storage device type, including, initializing the storage controller and identifying and attaching\r\nstorage devices.\r\nBut the whole picture of processing disk requests is a bit more complicated, since there are more drivers that are\r\nindirectly involved in it. Let's inspect those driver objects on the disk device stack.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 10 of 28\n\nAs we can see both drivers redirect their driver dispatch routines to another drivers. In the case of disk.sys its table\r\nof driver dispatch routines points to Classpnp functions. The driver name stands for \"Class Plug and Play Driver\"\r\nand is responsible for managing Plug and Play (PnP) devices. Classpnp handles the device requests addressed to\r\ndisk.sys. classpnp!ClassGlobalDispatch, in turn, simply redirects the execution flow to the appropriate classpnp\r\ndispatch function. Therefor, these items of the disk driver dispatch table are perfect targets for any rootkit (if it can\r\ndefeat PatchGuard first).\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 11 of 28\n\nIf we know the pointer to the disk device object, we can get information about the real dispatch table of the\r\nclasspnp driver.\r\nThe second driver iaStorVD.sys relies on its counterpart storport.sys. The latter is a general-purpose storage driver\r\nresponsible for managing communication between storage devices and the operating system itself. While\r\niaStorVD.sys provides functionality for managing RAID arrays and handling I/O requests for devices connected\r\nto the Intel RAID controller, storport.sys is directly responsible for communication with storage devices. Thus,\r\nStorport.sys operates at a lower level than iaStorVD.sys, providing basic communication and data transfer\r\nfunctionality with the storage hardware.\r\niaStorVD.sys also creates one more device incorporated in another device stack that ends up in Pci.sys. It's used to\r\nhandle requests for the PCI bus driver Pci.sys.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 12 of 28\n\n️ Patching kernel data\r\nGMER aims to patch kernel mode code and disk port driver data in two cases mentioned below. In both of them, it\r\nis interested in intercepting control of the disk I/O operation before the disk port driver returns control to the\r\nclient. The driver parses the SCSI_REQUEST_BLOCK structure and, in particular, its Cdb structure to obtain\r\ninformation about the LBA and the size of the requested data.\r\nThe anti-rootkit driver overwrites the IAT entry of the disk port driver that matches the IofCompleteRequest\r\nfunction with a GMER's one.\r\nIt also implements run-time code patching. First 0xF bytes of ataport!IdePortDispatch-\r\n\u003eataport!IdePortPdoDispatch are subject to this modification in the case of a sector write operation.\r\nGMER puts the following instruction at the beginning of ataport!IdePortPdoDispatch. A pointer to its\r\nimplementation of IofCompleteRequest follows the instruction.\r\nWhile the address of ataport!IdePortDispatch can simply be obtained from the driver's dispatch function table, to\r\nfind the address of ataport!IdePortPdoDispatch GMER needs to check the body of the first function for a specific\r\nsignature chain. This signature chain is presented below.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 13 of 28\n\nBelow you can see part of the code that implements the interception of the ataport!IdePortPdoDispatch function.\r\nThe first call is used to modify that function and copy the old 0xF bytes. The second one saves the copied old\r\nbytes to the global driver data.\r\nIt's worth noting that the GMER function for patching kernel mode code isn't safe for use in multiprocessor\r\nsystems (SMP). Instead of raising IRQL on all CPUs, the driver does this only on the current one. GMER\r\nimplements a typical method for patching kernel mode data as follows.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 14 of 28\n\n🔑 Securing disk I/O operations\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 15 of 28\n\nThe driver provides GMER with the ability to work with disk at a low level by addressing directly to the\r\nAtapi/Ataport or Scsiport disk drivers. It builds a request packet and sends it to one of them through the\r\nIRP_MJ_INTERNAL_DEVICE_CONTROL request depending on which one is active in the system.\r\nThe driver receives the name of the disk device object from its user-mode counterpart. Before sending a request to\r\nthe disk device, the driver obtains the pointer to the lowest device on the stack using\r\nIoGetBaseFileSystemDeviceObject, thus bypassing all potentially non trusted devices.\r\nstruct _CDB10 {\r\nUCHAR OperationCode;\r\n...\r\nUCHAR LogicalUnitNumber : 3;\r\nUCHAR LogicalBlockByte0;\r\nUCHAR LogicalBlockByte1;\r\nUCHAR LogicalBlockByte2;\r\nUCHAR LogicalBlockByte3;\r\n...\r\nUCHAR Control;\r\n} CDB10, *PCDB10;\r\nBefore calling the disk driver, GMER patches its IAT entry matching the IofCompleteRequest function to GMER's\r\none.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 16 of 28\n\nGMER supports IOCTL code 0x7201C008 to perform secure disk I/O operation for its user-mode application.\r\nBelow you can see its pseudo code, which omits minor operations.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 17 of 28\n\nGMER has several I/O completion routines that are designed to be used in multiple anti-rootkit scenarios when\r\nprocessing disk I/O operations.\r\nThe first is used to secure (intercept) the disk read operation\r\n(IRP_MJ_INTERNAL_DEVICE_CONTROL, SCSIOP_READ) globally (IOCTL 0x7201C020). Its\r\npointer replaces IofCompleteRequest in the disk port driver IAT entry and is used to copy read data from\r\nthe system buffer to the GMER's one.\r\nAnother one is involved in securing the disk write op (IRP_MJ_INTERNAL_DEVICE_CONTROL,\r\nSCSIOP_WRITE) globally (IOCTL 0x7201C02C). The driver uses a pointer to this function in the\r\npatching code for ataport!IdePortPdoDispatch. This routine is used to prohibit write access to disk sectors\r\n(LBA) supplied from user mode .\r\nThe latter is used to dispatch the initiated disk I/O request coming from the GMER app (IOCTL\r\n0x7201C008).\r\nIn addition to those IOCTLs, GMER has a feature to scan the classpnp handlers for potential run-time hooks\r\n(0x9876C058). The driver obtains the handler offset inside the classpnp driver file, its\r\nSYSTEM_MODULE_ENTRY.ImageBase, and checks its prologue for two signature sequences: 0x55 0x8B\r\n0xEC, 0x8B 0xFF 0x55.\r\nBut it's unclear why the 64-bit GMER driver checks the classpnp dispatch functions for x86 instructions...\r\n️ Securing file I/O operations\r\nGMER secures file operations as follows.\r\nTo open a file, the driver calls the IoCreateFileSpecifyDeviceObjectHint API, sending a request directly to\r\nthe FSD, skipping possible intermediate filters. To obtain a pointer to the FSD device object that is the\r\nlowest on the stack, it uses IoGetBaseFileSystemDeviceObject (IoGetDeviceAttachmentBaseRef).\r\nIf the function fails, GMER tries to check IofCallDriver for hooks, but only its the old version, which has a\r\njump instruction to the IopfCallDriver pointer at the beginning.\r\nIn addition to checking IofCallDriver for hooks, the driver also checks and restores the original\r\nIRP_MJ_CREATE handlers for Ntfs and Fastfat driver objects. As was mentioned above, GMER obtains\r\nthese handlers at the driver initialization phase.\r\nAfter obtaining a handle to the requested file, the driver uses the ordinary APIs ZwReadFile, ZwWriteFile,\r\nZwDeleteFile, ZwQueryInformationFile, ZwSetInformationFile, ZwClose.\r\nThese operations are performed in the System process context.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 18 of 28\n\nThe following pseudocode demonstrates how GMER secures file I/O operations.\r\n⛓️Tracing kernel mode code\r\nAlong with information about system anomalies, GMER is also capable of providing details about possible code\r\nexecution flow violations involved in processing file system operations. This feature is based on code tracing or\r\nsingle-step CPU mode, when the driver code intercepts control after each executed CPU instruction and saves\r\ninformation about each system module to which this instruction belongs. This mode is activated by setting the trap\r\nflag in the RFLAGS register {pushfq; pop rax; or eax 100h; push rax; popfq}.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 19 of 28\n\nBelow you can see the driver code responsible for intercepting the int 1 handler and the corresponding x64\r\nstructures.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 20 of 28\n\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 21 of 28\n\nThe driver interrupt handler is simply a wrapper, it prepares the necessary data on the stack and calls the real\r\nhandler.\r\nWhen tracing code, the driver maintains a context structure with several arrays that store information about system\r\nmodules and their call stack frames. Then this data will be copied to the provided user buffer and analyzed by the\r\napplication for the presence of unknown system modules.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 22 of 28\n\nThe driver single step mode dispatch function looks as follows.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 23 of 28\n\nThe above function is involved in code tracing in two scenarios - calling the FSD driver directly via IofCallDriver\r\nand ZwQueryDirectoryFile.\r\nThe second scenario.\r\n📦About PPL'ed processes\r\nPPL is a widely known built-in Windows security feature designed to provide high-end protection for trusted\r\nWindows services such as anti-malware processes. It's recognized as a robust security measure aimed at protecting\r\nrunning processes from any form of modification or other destructive impact. Access checks for PPL-protected\r\nprocesses are implemented at the opening process handle level, without any exceptions for kernel mode code. As a\r\nresult, these processes cannot be terminated using ZwOpenProcess and ZwTerminateProcess calls made by the\r\nkernel mode driver.\r\nThe required access checks can only be successfully passed by code that works on another PPL protection level\r\nwith an equal or higher one. GMER isn't an exception; like other renowned security tools, including, Process\r\nExplorer, Process Hacker, Process Informer, WinArk, it can't terminate PPL'ed processes. This limitation arises\r\nnot only because it employs a simple trick involving a pair of aforementioned functions after attaching to the\r\nSystem process, but also due to its constraints when working on modern Windows versions. To terminate a PPL-protected process, kernel mode code requires a pointer to the kernel object of the process and a pointer to an\r\ninternal ntoskrnl function, PspTerminateProcess, capable of process termination by a pointer rather than its\r\nhandle.\r\nGMER terminates the process as shown below (IOCTL 0x9876C094).\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 24 of 28\n\nTo make the process of finding PspTerminateProcess more reliable across Windows versions, a signature chain\r\ncandidate should consist of unique byte sequences. GMER can easily find many Windows kernel undocs, so\r\nlocating PspTerminateProcess shouldn't be difficult for it.\r\nIf we delve deeper, we find that the key function in the process of checking PPL protection is an open procedure\r\nfor the process object type (PsProcessType) called PspProcessOpen. This is the only purpose of this function,\r\nwhich is responsible for comparing PSPROTECTION values of both processes. Before implementing PPL, the\r\nprocess kernel object didn't have the open procedure.\r\nBelow, you can see the process of obtaining a handle to the PPL'ed process, starting with the call of\r\nNtOpenProcess and ending with the actual validation of the protection.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 25 of 28\n\nThe process of removing PPL protection could be simplified with just zeroing EPROCESS_Protection value that\r\nis used by the Windows kernel to set the corresponding level of protection. It's related to DKOM and there are\r\nseveral projects on GitHub demonstrating this method. It can also be used by attackers or defenders for the\r\nopposite purpose to enable the protection for specific processes, making them inaccessible for any kind of\r\nmodification. Below you can see the corresponding structures describing PPL.\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 26 of 28\n\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 27 of 28\n\nTo disable PPL, the protection byte or all three fields should be set to zero (see Kernel Driver Utility, KDU).\r\nTo enable protection for the process (EDRSandblast).\r\nSource: https://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nhttps://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html\r\nPage 28 of 28",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-2.html"
	],
	"report_names": [
		"remsec-driver-analysis-part-2.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434653,
	"ts_updated_at": 1775791204,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2fd914b81c3a0a63bb5e80d1e63f0c23e9904809.pdf",
		"text": "https://archive.orkl.eu/2fd914b81c3a0a63bb5e80d1e63f0c23e9904809.txt",
		"img": "https://archive.orkl.eu/2fd914b81c3a0a63bb5e80d1e63f0c23e9904809.jpg"
	}
}