You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[
Serialised(
Hypothesis {
hypothesis_title: "Arbitrary Physical Memory Read/Write via IOCTL 0x220014 (MmMapIoSpace)",
description_of_hypothesis: "IOCTL 0x220014 in FUN_00011260 (the IRP_MJ_DEVICE_CONTROL handler registered at DriverObject+0xe0 in entry()) accepts a user-supplied buffer. It loads puVar5 directly from param_2+0x18 (the IRP SystemBuffer). The only check is iVar2==0x10 (InputBufferLength == 16). It then calls MmMapIoSpace(*puVar5, puVar5[1], 0) — physical address from puVar5[0] and size from puVar5[1] are both fully attacker-controlled with zero range validation. If mapping succeeds (non-NULL), FUN_00012600(*(undefined8*)(puVar5+2), lVar9, puVar5[1]) is called, which is a confirmed memmove implementation (handles both forward and backward copy based on pointer ordering, verified in decompile). This copies puVar5[1] bytes between the mapped physical pages and the caller's data buffer at puVar5[2..3]. MmUnmapIoSpace is called after.\n\nPrimitive granted: Arbitrary physical memory read AND write. The direction of the copy (read vs. write) is determined by whether param_1 < or > param_2 in FUN_00012600; the attacker controls both endpoints.\n\nSecond-order capabilities from this primitive:\n1. Read any physical memory region: SMRAM (SMM code/data, potentially BIOS passwords or SMM handler code), kernel pool allocations (token structures, process objects, EPROCESS, credentials), page tables (PML4, PDPTs), firmware/BIOS ROM shadow copies, DMA buffers, hypervisor data if not protected by IOMMU, hardware register spaces.\n2. Write to kernel pool objects: overwrite token->Privileges, token->IntegrityLevel, or EPROCESS->Token to escalate to SYSTEM. Overwrite SSDT entries (if not protected). Patch kernel code pages if mapped as writable via MmMapIoSpace with MmNonCached. Corrupt security-critical kernel structures (LSASS process token, CI.dll code integrity checks, PatchGuard context).\n3. SMRAM access: On systems without SMM_BWP and TSEG protection enforced in firmware, writing to SMRAM enables persistent BIOS-level rootkit implantation surviving OS reinstalls.\n4. Hypervisor bypass: Reading hypervisor memory regions (VMCS, EPT tables) can leak cryptographic material or enable VM escape on Hyper-V configurations without IOMMU isolation.\n5. Defeating all software mitigations: KASLR is defeated by reading physical memory to locate kernel base. PatchGuard can be disabled by locating and patching its context structure. DSE (Driver Signature Enforcement) can be disabled by patching CI.dll's g_CiEnabled in physical memory.\n\nEnd goals: Complete kernel compromise, SYSTEM privilege from any user-mode integrity level, persistent firmware rootkit, hypervisor escape, credential harvesting (dump LSASS physical pages), defeat all Windows security boundaries including Secure Boot (if SMRAM not locked).",
bug_class: KernelPhysicalMemoryMapping,
primary_attack_surface: "Any user-mode process that can open the device. IoCreateDevice is called with NULL (0) security descriptor (6th argument = 0 in entry() decompile: IoCreateDevice(param_1,0,0x13010,0x22,0,0,auStackX_18)), meaning the device inherits a default DACL that allows low-privileged users to open it. A symbolic link is created unconditionally.",
path_and_state_to_reach_vulnerability: "1. entry() calls IoCreateDevice(param_1, 0, 0x13010, 0x22, 0, 0, auStackX_18) — NULL security descriptor, device type 0x22 (FILE_DEVICE_UNKNOWN). 2. entry() registers FUN_00011260 as IRP_MJ_DEVICE_CONTROL handler at DriverObject+0xe0. 3. entry() calls IoCreateSymbolicLink to expose the device. 4. Attacker calls CreateFile on the symbolic link (no ACL blocks access). 5. Attacker calls DeviceIoControl(handle, 0x220014, inputBuf, 0x10, NULL, 0, ...) where inputBuf[0..7]=target_phys_addr, inputBuf[8..15]=size, inputBuf[16..23]=user_data_ptr. 6. FUN_00011260 checks *pcVar4 == 0x0e (MajorFunction == IRP_MJ_DEVICE_CONTROL), switches on IOCTL 0x220014, checks iVar2==0x10 (passes), calls MmMapIoSpace(*puVar5, puVar5[1], 0), then FUN_00012600(puVar5[2], lVar9, puVar5[1]), then MmUnmapIoSpace.",
why_plausible: "Decompiled case 0x220014: `if (iVar2 == 0x10) { lVar9 = MmMapIoSpace(*puVar5, puVar5[1], 0); if (lVar9 == 0) { uVar7 = 0xc0000141; } else { FUN_00012600(*(undefined8 *)(puVar5 + 2), lVar9, puVar5[1]); MmUnmapIoSpace(lVar9, puVar5[1]); uVar7 = 0; } }`. puVar5 = *(undefined4**)(param_2+0x18) — the IRP SystemBuffer, directly from attacker. No range/sanity check on *puVar5 (physical address) or puVar5[1] (size). FUN_00012600 confirmed as full memmove with no bounds checking. entry() confirmed IoCreateDevice with 0 security descriptor.",
any_evidence_to_the_contrary: "None found. The only check (iVar2 == 0x10) validates input buffer size to be exactly 16 bytes but does not constrain the physical address or copy size encoded within those 16 bytes. MmMapIoSpace itself accepts any physical address. No SEH, no ProbeForRead/ProbeForWrite on puVar5[2] (the user data pointer), no privilege level check (e.g., SePrivilegeCheck), no allowlist of physical address ranges.",
potentially_vulnerable_function: "FUN_00011260 (IOCTL dispatch, case 0x220014)",
potentially_vulnerable_ioctl_if_relevant: "0x220014",
severity: Critical,
likelihood_of_exploitability: Critical,
next_step: Conclude,
},
),
Serialised(
Hypothesis {
hypothesis_title: "Unvalidated IRP Major Function Index Used as Jump Table Offset in FUN_000111c0",
description_of_hypothesis: "FUN_000111c0 (the hooked IRP dispatch routine installed by IOCTL 0x22001c) performs: uVar2 = (**(code **)((ulonglong)*pbVar1 * 8 + 0x13060))(param_1, param_2) where *pbVar1 is the raw IRP MajorFunction byte read from *(byte **)(param_2 + 0xb8) — the IO_STACK_LOCATION pointer at IRP+0xb8, whose first byte is the MajorFunction field. This byte is used directly without any bounds check as an index into a 28-entry (0x1c-slot) function pointer table at 0x13060. The table is populated during IOCTL 0x22001c hook installation: the loop runs lVar15 = 0x1c iterations, writing saved dispatch pointers to lVar12 + 0x12ff0 (= 0x13060..0x131d8). MajorFunction values 0x00-0x1B are valid. Values 0x1C-0xFF multiply by 8 and produce offsets reading from uninitialized or otherwise-populated kernel memory outside the table. The dereference first reads an 8-byte pointer from that address, then calls it as a function pointer. Exploitation primitive: an attacker gains arbitrary kernel read (OOB read at 0x13060 + code*8 leaks kernel pointers) and potentially arbitrary kernel code execution if the out-of-bounds region can be groomed to contain a controlled pointer, enabling ring-0 execution. From ring-0 execution the attacker can overwrite EPROCESS token fields for SYSTEM privileges, patch kernel code signing enforcement, install DKOM rootkit hooks, and establish persistent kernel backdoors. Critically, triggering MajorFunction >= 0x1c requires kernel-mode IRP crafting — normal Win32 APIs only produce codes 0x00-0x1B — which significantly limits exploitability to scenarios where the attacker already has a kernel driver or a separate kernel bug to craft raw IRPs.",
bug_class: KernelArbitraryReadOrWrite,
primary_attack_surface: "Any process with access to the hooking driver (admin/high-integrity by default due to NULL security descriptor in IoCreateDevice) can issue IOCTL 0x22001c to install FUN_000111c0 as a dispatch hook. Subsequently any process that can craft kernel IRPs with MajorFunction >= 0x1c directed at the hooked target driver triggers the OOB table read and call.",
path_and_state_to_reach_vulnerability: "1. entry() [0x119d0]: IoCreateDevice creates device with NULL security descriptor (admins only by default). 2. Caller issues IOCTL 0x22001c to the driver. 3. FUN_00011260 [0x11260] handles IRP_MJ_DEVICE_CONTROL, dispatches to case 0x22001c: opens target driver via ZwOpenFile+ObReferenceObjectByHandle, loops 0x1c times patching MajorFunction slots 0-27 to FUN_000111c0, saves originals to 0x13060-0x131d8. 4. Attacker causes hooked target driver to receive an IRP with MajorFunction byte >= 0x1c (requires kernel-mode IRP crafting). 5. FUN_000111c0 [0x111c0]: reads pbVar1 = *(byte**)(param_2+0xb8), computes address = (ulonglong)*pbVar1 * 8 + 0x13060, reads 8-byte pointer from that address, calls it — no bounds check anywhere in this path.",
why_plausible: "Decompiled FUN_000111c0 shows: pbVar1 = *(byte **)(param_2 + 0xb8); ... uVar2 = (**(code **)((ulonglong)*pbVar1 * 8 + 0x13060))(param_1,param_2); — the only conditionals before this are identity checks (param_1 == lRam0000000000013020) and specific major-code comparisons (0x04 and 0x16) that fall through to the jump for all other codes including >=0x1c. The hook installation loop in FUN_00011260 case 0x22001c explicitly runs exactly 0x1c iterations (lVar15 countdown from 0x1c to 0), confirming the table has exactly 28 entries. Ghidra warns 'Could not recover jumptable at 0x00011250. Too many branches' confirming the unbounded indirect dispatch.",
any_evidence_to_the_contrary: "(1) Standard Windows IRP routing in the IO Manager only produces MajorFunction codes 0x00-0x1B via normal Win32 APIs. To send an IRP with MajorFunction >= 0x1c the attacker must use a kernel-mode driver to craft IRPs directly or exploit a separate kernel bug — this is a significant prerequisite that substantially reduces exploitability. (2) IoCreateDevice is called with NULL security descriptor (param_6=0 confirmed in entry() decompile), so default ACLs apply restricting access to administrators. (3) Only the specific target driver identified by ZwOpenFile in case 0x22001c is hooked, and that driver may also have restrictive DACLs.",
potentially_vulnerable_function: "FUN_000111c0 (hooked IRP dispatch handler at 0x000111c0)",
potentially_vulnerable_ioctl_if_relevant: "0x22001c (installs the hook that causes FUN_000111c0 to be invoked for all IRPs on the target driver)",
severity: Medium,
likelihood_of_exploitability: Low,
next_step: Conclude,
},
),
Serialised(
Hypothesis {
hypothesis_title: "No Device Access Control — Any Low-Integrity Process Can Access All IOCTLs",
description_of_hypothesis: "In entry() at 0x000119d0, IoCreateDevice is called as: `IoCreateDevice(param_1, 0, 0x13010, 0x22, 0, 0, auStackX_18)`. The 6th argument (SecurityDescriptor) is explicitly 0/NULL, and the 5th argument (Exclusive) is 0 (shared/non-exclusive). The device type is FILE_DEVICE_UNKNOWN (0x22). No subsequent call to IoCreateDeviceSecure, SetSecurityInfo, ObSetSecurityDescriptorInfo, or any SDDL-based ACL application is present anywhere in the binary. The symbolic link is created via IoCreateSymbolicLink with no restricted DACL. The IOCTL dispatch function FUN_00011260 performs zero caller identity, privilege, or integrity-level checks before branching into any IOCTL handler. Windows assigns a permissive default security descriptor when NULL is passed to IoCreateDevice, granting access to all authenticated users including low-integrity processes (e.g., sandboxed browser tabs, restricted service accounts). Exploitation chain: (1) Any low-integrity process calls CreateFile on the symbolic link (0x13010 device name). Access succeeds because the device DACL is permissive. (2) The attacker sends IOCTL 0x220014 (MmMapIoSpace physical memory mapping): the handler reads a physical address and size from the user-supplied input buffer (puVar5[0], puVar5[1]) with only a size-equals-0x10 check, maps arbitrary physical memory into kernel virtual address space, copies data via FUN_00012600, then unmaps. This grants arbitrary physical memory read/write — covering all of RAM. (3) From arbitrary physical memory read/write: the attacker can scan for kernel data structures (e.g., EPROCESS, token objects, page table entries), locate the SYSTEM token, overwrite the current process token (token-swapping / token-stealing), achieve SYSTEM-level kernel code execution, disable PatchGuard by locating and corrupting its monitoring structures, disable DSE (Driver Signature Enforcement) by patching g_CiEnabled or ci.dll in memory, load unsigned kernel code, install persistent kernel rootkits, and fully own the machine. (4) IOCTL 0x220000/0x220004 expose direct CMOS I/O port 0x70/0x71 read/write — allows RTC manipulation and CMOS poisoning. (5) IOCTL 0x22000c calls func_0x000125e6(3) which maps to HalReturnToFirmware(3) — immediate kernel-mode system reboot/power-off reachable from any user. (6) IOCTL 0x22001c hooks dispatch routines of another driver (overwrites IRP_MJ_* function pointers) — a kernel code execution primitive usable for rootkit installation. All of these are reachable from low integrity with zero preconditions beyond being able to call CreateFile.",
bug_class: KernelWeakIOCTLAccessControl,
primary_attack_surface: "All IOCTLs exposed by the driver — reachable from any user-mode context including low-integrity processes with no privilege requirement beyond CreateFile on the symbolic link.",
path_and_state_to_reach_vulnerability: "DriverEntry (entry at 0x000119d0) → IoCreateDevice(NULL SecurityDescriptor) → IoCreateSymbolicLink → device accessible to all authenticated users → user-mode CreateFile on symbolic link → DeviceIoControl → FUN_00011260 (dispatch at 0x00011260) → switch on IOCTL code → any handler (0x220014: MmMapIoSpace arbitrary physical memory; 0x220000/0x220004: CMOS I/O; 0x22000c: HalReturnToFirmware; 0x22001c: driver dispatch hook)",
why_plausible: "Decompiled entry() confirms: `IoCreateDevice(param_1,0,0x13010,0x22,0,0,auStackX_18)` — 6th arg (SecurityDescriptor) = 0, 5th arg (Exclusive) = 0. No security setup call exists anywhere in the binary. FUN_00011260 decompile shows: after checking IRP_MJ_DEVICE_CONTROL (0x0e), it immediately reads the IOCTL code and dispatches — zero identity/privilege checks. IOCTL 0x220014 handler reads physical address from puVar5[0..1] (user buffer) and calls MmMapIoSpace with attacker-controlled address and size, granting arbitrary physical memory access to any caller.",
any_evidence_to_the_contrary: "None found. No IoCreateDeviceSecure, no SDDL string, no SetSecurityDescriptorDacl, no SeAccessCheck, no PsGetCurrentProcessToken, no integrity level check, no privilege (SeDebugPrivilege etc.) check anywhere in the binary. FUN_000111c0 (IRP hook) checks lRam0000000000013020/globals but these are driver-state flags, not caller identity checks.",
potentially_vulnerable_function: "entry() at 0x000119d0 (device creation with NULL DACL); FUN_00011260 at 0x00011260 (IOCTL dispatch with no access control)",
potentially_vulnerable_ioctl_if_relevant: "All IOCTLs: 0x220000 (CMOS read), 0x220004 (CMOS write), 0x220008, 0x22000c (HalReturnToFirmware), 0x220014 (MmMapIoSpace arbitrary physical memory RW), 0x220018, 0x22001c (driver dispatch hook), 0x220020, 0x220024, 0x220028, 0x22002c, 0x220030",
severity: Critical,
likelihood_of_exploitability: Critical,
next_step: Conclude,
},
),
Serialised(
Hypothesis {
hypothesis_title: "IOCTL 0x22000c Causes Immediate System Reboot/Shutdown via HalReturnToFirmware",
description_of_hypothesis: "IOCTL 0x22000c in FUN_00011260 (the IRP_MJ_DEVICE_CONTROL dispatch routine) unconditionally executes `func_0x000125e6(3)` with no preconditions, input validation, or privilege check. func_0x000125e6 at offset 0x125e6 in .text is a 6-byte JMP thunk: `FF 25 14 2A 00 00` (JMP QWORD PTR [0x12a14]), which resolves through the IAT to HalReturnToFirmware imported from HAL.DLL (confirmed by the 'HalReturnToFirmware' string at 0x15558 in .idata and Ghidra's external stub at 0x5556). Argument value 3 corresponds to HalRebootRoutine, which triggers an immediate unconditional hardware reboot bypassing all Windows shutdown procedures.\n\nFull exploitation chain:\n1. PRIMITIVE: Any caller with a handle to the device object can trigger an immediate system reboot (full machine reset) from ring 3, with a single DeviceIoControl call. The reboot is immediate and unconditional — no shutdown, no graceful termination, no logged event, no cancellation path.\n2. SECOND-ORDER CAPABILITIES from this primitive:\n - Denial of Service (DoS): Unconditional full system reboot — any active work, transactions, or OS state is destroyed.\n - Data corruption: Abrupt reboot without sync/flush can corrupt filesystems, databases, or applications mid-write.\n - Availability attack loop: If the device persists across reboots (auto-loaded driver), an attacker can create a reboot loop by re-triggering on startup — bricking the system into an unbootable state if combined with any boot-time side effect.\n - Forced crash as exploit aid: The reboot clears in-memory forensic evidence (logs, kernel structures, network state), useful for covering tracks after another exploit.\n - Security bypass via reboot: Reboot may disable kernel mitigations that are runtime-only (e.g., PatchGuard active state, HVCI enforcement before re-enabling, certain LSA protections), making post-reboot state more exploitable.\n3. END GOALS:\n - Complete denial of service for any service, server, or workstation running this driver — trivially achievable by any standard user process with access to the device.\n - In a multi-tenant or shared-kernel scenario (e.g., RDSH, Hyper-V host running this driver), any low-privilege session can reboot the entire machine, affecting all tenants/VMs.\n - If combined with a persistence mechanism, a full denial-of-availability attack is achievable (infinite reboot loop).\n - No code execution is granted, but the severity of the impact (complete system availability destruction, possible data corruption) is equivalent to a Critical DoS.",
bug_class: KernelWeakIOCTLAccessControl,
primary_attack_surface: "Any user-mode process with a handle to the device object (trivially obtainable due to no device DACL — IoCreateDevice called with DeviceCharacteristics=0, meaning no FILE_DEVICE_SECURE_OPEN, and no ACL is set post-creation) can trigger a full system reboot with a single DeviceIoControl call.",
path_and_state_to_reach_vulnerability: "1. entry() [0x000119d0]: DriverEntry calls IoCreateDevice(param_1, 0, 0x13010, 0x22, 0, 0, ...) — DeviceType=0x22 (FILE_DEVICE_UNKNOWN), DeviceCharacteristics=0 (no FILE_DEVICE_SECURE_OPEN), no explicit DACL. IoCreateSymbolicLink(&DAT_00013000, 0x13010) exposes the device via a symbolic link. 2. entry() also installs FUN_00011260 as handler for IRP_MJ_DEVICE_CONTROL at param_1+0xe0, IRP_MJ_READ at param_1+0x70, IRP_MJ_WRITE at param_1+0x80. 3. User calls CreateFile on the symbolic link name, obtains a handle. 4. User calls DeviceIoControl(handle, 0x22000c, ...). 5. I/O Manager dispatches to FUN_00011260. 6. FUN_00011260 checks *pcVar4 == 0x0e (IRP stack MajorFunction == IRP_MJ_DEVICE_CONTROL), reads IoStackLocation->Parameters.DeviceIoControl.IoControlCode at pcVar4+0x18, matches case 0x22000c. 7. func_0x000125e6(3) is called — a JMP thunk [FF 25 14 2A 00 00] resolving to HalReturnToFirmware(HalRebootRoutine=3). System immediately reboots.",
why_plausible: "Directly confirmed by decompiled code in FUN_00011260: `case 0x22000c: func_0x000125e6(3); break;` — no preceding check, no input size validation, no privilege check. func_0x000125e6 bytes: FF 25 14 2A 00 00 (JMP QWORD PTR [IAT slot]). Import table lists HalReturnToFirmware from HAL.DLL (Ghidra external stub 0x5556, idata string 'HalReturnToFirmware' at 0x15558 confirmed). IoCreateDevice called with DeviceCharacteristics=0 (no FILE_DEVICE_SECURE_OPEN), meaning the default device DACL permits any logged-on user to open the device. No security descriptor applied after device creation.",
any_evidence_to_the_contrary: "None found. The only guard before the IOCTL switch is a MajorFunction check (`if (*pcVar4 != 0x0e) goto code_r0x000118f9`) which is satisfied by any IRP_MJ_DEVICE_CONTROL IRP — i.e., any DeviceIoControl call. There is no token privilege check (e.g., SeShutdownPrivilege), no IoIsOperationSynchronous gate, no input buffer size check (uVar3/iVar2 are read but not evaluated before case 0x22000c), and no device-level ACL enforcing elevated access.",
potentially_vulnerable_function: "FUN_00011260 (IRP_MJ_DEVICE_CONTROL dispatch handler, case 0x22000c calling func_0x000125e6 = HalReturnToFirmware thunk)",
potentially_vulnerable_ioctl_if_relevant: "0x22000c",
severity: High,
likelihood_of_exploitability: High,
next_step: Conclude,
},
),
Serialised(
Hypothesis {
hypothesis_title: "IOCTL 0x220000/0x220004 Allow Arbitrary CMOS NVRAM Read/Write via Direct I/O Port Access",
description_of_hypothesis: "FUN_00011260 is the IRP_MJ_DEVICE_CONTROL dispatch handler (registered at DriverObject+0xe0) for device \\Device\\BioNT_BS (symlink \\DosDevices\\BioNT_BS, user-accessible as \\\\.\\BioNT_BS). IoCreateDevice is called with ExclusiveAccess=0 and no security descriptor, yielding a device object with default (world-readable/writable) ACL. Case 0x220000: `out(0x70, *(undefined1*)puVar5); uVar6 = in(0x71); *(undefined1*)puVar8 = uVar6;` — the first byte of the attacker-supplied input buffer is sent directly to I/O port 0x70 (CMOS index register), then port 0x71 (CMOS data register) is read and returned to the attacker's output buffer. Case 0x220004: `out(0x70, *(undefined1*)puVar5); out(0x71, *(undefined1*)((longlong)puVar5+1));` — byte 0 selects the CMOS register index, byte 1 is written as the data value. No range check, no privilege check, no validation of any kind on the register index or data byte. Exploitation primitive: full 8-bit arbitrary read/write of all 256 CMOS/RTC registers accessible via port 0x70/0x71. Second-order capabilities: (1) CMOS write to register 0x0F (shutdown status byte) can corrupt POST/reset behavior and trigger non-maskable BIOS-level effects on legacy/hybrid firmware; (2) Write to BIOS boot order bytes (registers 0x2D, 0x38-0x3F in Award/Phoenix BIOSes) can redirect boot device to attacker-controlled media; (3) Write to register 0x0E (diagnostic status) can trigger BIOS setup re-entry on next boot, wiping user configuration; (4) Read of registers 0x10–0x2D leaks installed hardware configuration (drive types, memory size, equipment flags); (5) Writing arbitrary values to RTC time registers (0x00–0x09) enables time-of-day manipulation; (6) Bit 7 of port 0x70 controls NMI (Non-Maskable Interrupt) disable — sending index byte with bit 7 set disables NMI, potentially masking hardware faults; (7) On systems where BIOS password is stored in CMOS (registers 0x38–0x3F or OEM-specific), reading those registers may leak or allow clearing the BIOS password. End goals: persistent boot-level manipulation (redirect to malicious boot device), BIOS configuration destruction (denial of service via corrupt CMOS checksum causing BIOS to halt POST), BIOS password bypass, and hardware fault masking via NMI disable. All achievable by any unprivileged user-mode process with a handle to the device.",
bug_class: KernelWeakIOCTLAccessControl,
primary_attack_surface: "Any user-mode process (no privileges required) that opens \\\\.\\BioNT_BS and issues DeviceIoControl with IOCTL 0x220000 or 0x220004. Device has no restrictive ACL (IoCreateDevice called with NULL SecurityDescriptor and ExclusiveAccess=FALSE).",
path_and_state_to_reach_vulnerability: "1. entry() [DriverEntry] calls IoCreateDevice(param_1, 0, L\"\\Device\\BioNT_BS\", 0x22, 0, FALSE, &devobj) — creates device with default ACL (world accessible). 2. entry() calls IoCreateSymbolicLink(L\"\\DosDevices\\BioNT_BS\", L\"\\Device\\BioNT_BS\") — creates Win32 accessible symlink. 3. entry() sets DriverObject+0xe0 = FUN_00011260 (IRP_MJ_DEVICE_CONTROL). 4. Attacker calls CreateFile(\"\\\\\\\\.\\\\BioNT_BS\", ...) from any user-mode process — succeeds with no privilege requirement. 5. Attacker calls DeviceIoControl(handle, 0x220000, ®_index, 1, &result, 1, ...) — FUN_00011260 dispatches to case 0x220000, executes out(0x70, reg_index); result = in(0x71) with no validation. 6. Attacker calls DeviceIoControl(handle, 0x220004, &{reg_index, value}, 2, NULL, 0, ...) — FUN_00011260 dispatches to case 0x220004, executes out(0x70, reg_index); out(0x71, value) with no validation.",
why_plausible: "Decompiled code confirms: (1) case 0x220000 literally executes `out(0x70,*(undefined1 *)puVar5)` and `in(0x71)` with puVar5 = *(undefined4**)(param_2+0x18) — the Type3InputBuffer pointer from the IRP stack location, sourced directly from user DeviceIoControl input buffer; (2) case 0x220004 executes `out(0x70,*(undefined1 *)puVar5); out(0x71,*(undefined1 *)((longlong)puVar5 + 1))` — both index and data are user-supplied bytes with no range check; (3) IoCreateDevice is called with ExclusiveAccess=0 and no SDDL string, confirmed by decompiled entry(); (4) no SeAccessCheck, SeSinglePrivilegeCheck, or token privilege validation found anywhere in FUN_00011260 or entry().",
any_evidence_to_the_contrary: "None found. There is no ACL restricting device access, no privilege check in the dispatch path, no register index range validation (e.g., limiting writes to non-critical CMOS registers), and no input length check before dereferencing puVar5. The IOCTL method for 0x220000/0x220004 uses METHOD_BUFFERED (low 2 bits = 0x0), so the kernel copies user data to a system buffer before use — this prevents user-mode pointer attacks but does not mitigate the CMOS register exposure.",
potentially_vulnerable_function: "FUN_00011260 (IRP_MJ_DEVICE_CONTROL handler), confirmed cases 0x220000 and 0x220004",
potentially_vulnerable_ioctl_if_relevant: "0x220000 (CMOS arbitrary read), 0x220004 (CMOS arbitrary write)",
severity: High,
likelihood_of_exploitability: High,
next_step: Conclude,
},
),
]
Model claude-haiku-4-5 (triage only)
TRIAGE OUTPUT: Serialised(
FileTriage {
file_name: "drv.bin",
hypotheses: [
Hypothesis {
hypothesis_title: "Arbitrary Physical Memory Mapping via IOCTL 0x220014",
description_of_hypothesis: "IOCTL 0x220014 calls MmMapIoSpace with user-controlled physical address and size parameters from IRP buffer. The function accepts a user-provided 16-byte buffer containing physical address, size, and output pointer, then maps the region and passes it to FUN_00012600 with the buffer size. No apparent bounds checking on the physical address or size.",
bug_class: KernelPhysicalMemoryMapping,
primary_attack_surface: "DeviceIoControl call with IOCTL 0x220014, requiring 16-byte minimum input buffer from user-mode caller",
path_and_state_to_reach_vulnerability: "1. Open device via symbolic link \\DosDevices\\BioNT_BS 2. Send DeviceIoControl with IOCTL 0x220014 3. Provide 16-byte buffer with arbitrary physical address, size, and output buffer pointer 4. Successfully map arbitrary physical memory and copy to output buffer",
why_plausible: "At line 000114ce-000114fa in FUN_00011260: instruction loads *puVar4 (physical address from input buffer), puVar4[1] (size), and calls MmMapIoSpace without validating these values come from usermode. The decompilation shows iVar2 == 0x10 check (input size >= 16 bytes) is the only validation before using the first two dwords as address/size parameters. No privilege check, no address range validation.",
any_evidence_to_the_contrary: "The size must be exactly 0x10 (16 bytes) minimum; however, arbitrary physical addresses within that constraint can be mapped. The mapped region is then copied by FUN_00012600, which implements memmove-like semantics allowing reading of arbitrary physical memory locations.",
potentially_vulnerable_function: "FUN_00011260 (main dispatch handler)",
potentially_vulnerable_ioctl_if_relevant: "0x220014",
severity: Critical,
likelihood_of_exploitability: Critical,
next_step: Conclude,
},
Hypothesis {
hypothesis_title: "Kernel Function Pointer Hijacking via IOCTL 0x22001c",
description_of_hypothesis: "IOCTL 0x22001c opens a file (\\SystemRoot\\\\) via ZwOpenFile, extracts a function pointer table from the file object's related device, and overwrites a table of 28 kernel function pointers in data section at address DAT_00013020 + 0x70 with a custom function (FUN_000111c0). This allows replacing kernel routines through a controlled file reference.",
bug_class: KernelArbitraryReadOrWrite,
primary_attack_surface: "DeviceIoControl call with IOCTL 0x22001c, which triggers file-based function pointer table replacement",
path_and_state_to_reach_vulnerability: "1. Open device via symbolic link 2. Send DeviceIoControl IOCTL 0x22001c 3. Driver opens \\SystemRoot\\ file and extracts function pointer table from related device 4. Loops 28 times, overwriting kernel function pointers with address of FUN_000111c0 at offsets 0x70 to 0x1c bytes 5. Subsequent calls to hooked functions are redirected",
why_plausible: "At line 00011546-000116b5 in FUN_00011260: ZwOpenFile is called, file object is obtained via ObReferenceObjectByHandle, then at line 0001164c-00011680, a loop extracts function pointers from lVar9 (derived from file object structure) and overwrites the driver's function table with FUN_000111c0. The code stores lVar9 in DAT_00013020 and modifies addresses lVar13 + *(longlong)(lVar9 + 8), effectively hooking dispatcher functions. No privilege check, no validation of file object type.",
any_evidence_to_the_contrary: "Condition DAT_00013020 == 0 is checked, meaning this IOCTL only succeeds once. However, once executed, it permanently modifies the dispatch table. The hooked function FUN_000111c0 checks global flags (DAT_00013030, DAT_00013031) before processing further IOCTLs, providing some state-based filtering but this is inadequate.",
potentially_vulnerable_function: "FUN_00011260 (main dispatch handler)",
potentially_vulnerable_ioctl_if_relevant: "0x22001c",
severity: Critical,
likelihood_of_exploitability: Critical,
next_step: Conclude,
},
Hypothesis {
hypothesis_title: "Unchecked User Pointer Dereference in File Handle Operations",
description_of_hypothesis: "Multiple IOCTLs accept a user-mode file handle as the first element of an input buffer, pass it to ObReferenceObjectByHandle to obtain a file object in kernel space, then use that object to build I/O control requests. The function validates buffer sizes (0x1b or 0x14 bytes minimum for input, 3+ bytes for output) but does not validate the file handle validity or whether the user actually owns the handle. A user could provide an arbitrary handle value.",
bug_class: KernelUncheckedUserPointer,
primary_attack_surface: "DeviceIoControl calls with IOCTLs 0x220018, 0x22002c, 0x220030, accepting user file handles in SystemBuffer[0]",
path_and_state_to_reach_vulnerability: "1. Open device 2. Send IOCTL 0x220018 with minimum buffer (0x1c bytes) containing arbitrary file handle 3. Driver calls ObReferenceObjectByHandle with the user-supplied handle 4. If handle dereferences to a valid FileObject, driver builds a read request and sends it to the device 5. User can cause I/O operations on arbitrary file objects they do not own access control to",
why_plausible: "At line 0001137d-000113d0 in FUN_00011260: puVar15 (user buffer pointer) is loaded, SystemBuffer[0] is cast to a file handle and passed to ObReferenceObjectByHandle. The return value is checked (must not be < 0), but there is no check that the handle actually belongs to the calling process or that the calling process has permission to access the underlying file. The ObReferenceObjectByHandle call uses default parameters which does not enforce security context checking.",
any_evidence_to_the_contrary: "ObReferenceObjectByHandle is an OS function that may perform additional handle validation internally; however, the decompiled code shows no explicit security check before using the returned FileObject. The fact that ObReferenceObjectByHandle succeeds does not guarantee the user is authorized.",
potentially_vulnerable_function: "FUN_00011260 (main dispatch handler)",
potentially_vulnerable_ioctl_if_relevant: "0x220018, 0x22002c, 0x220030",
severity: High,
likelihood_of_exploitability: High,
next_step: Conclude,
},
Hypothesis {
hypothesis_title: "Weak IOCTL Dispatch Security - No Privilege Checks on Dangerous Operations",
description_of_hypothesis: "The main IOCTL dispatch function FUN_00011260 does not perform any privilege checks (no SePrivilegeCheck, no PsGetCurrentProcess integrity level checks, no ACL validation) before handling IOCTLs. All dangerous operations (memory mapping, file access, function hooking) are callable by any user-mode application that can open the device. The device is created via IoCreateDevice without explicit ACL restrictions.",
bug_class: KernelWeakIOCTLAccessControl,
primary_attack_surface: "Device creation and IOCTL handler dispatch in entry() and FUN_00011260",
path_and_state_to_reach_vulnerability: "1. Any user-mode application can open the symbolic link \\DosDevices\\BioNT_BS 2. Application sends any IOCTL code to the device 3. FUN_00011260 processes the IOCTL without checking caller privilege 4. All IOCTLs including 0x220014 (memory mapping), 0x22001c (function hooking), etc. are unrestricted",
why_plausible: "In entry() at 000119d0: IoCreateDevice is called with flags 0x22, but no ACL or secure device creation function is used. FUN_00011260 begins at line 00011293: CMP byte ptr [RDI], 0xe, checking IRP major function is IRP_MJ_DEVICE_CONTROL, but there is no subsequent privilege check. No calls to SePrivilegeCheck, PsGetCurrentProcess, or similar are visible in the decompilation.",
any_evidence_to_the_contrary: "The device creation flag 0x22 may apply default Windows DACL; however, decompilation confirms no explicit privilege check in the dispatch handler, and the presence of critical vulnerabilities (memory mapping, function hooking) in the handler suggests default permissions are too permissive.",
potentially_vulnerable_function: "entry (DriverEntry), FUN_00011260",
potentially_vulnerable_ioctl_if_relevant: "All IOCTLs: 0x220000, 0x220004, 0x220008, 0x22000c, 0x220014, 0x220018, 0x22001c, 0x220020, 0x220024, 0x220028, 0x22002c, 0x220030",
severity: Critical,
likelihood_of_exploitability: Critical,
next_step: Conclude,
},
Hypothesis {
hypothesis_title: "Unsafe Memory Copy in FUN_00012600 Combined with Arbitrary Physical Memory Access",
description_of_hypothesis: "FUN_00012600 implements a custom memmove function that copies data between param_1 (mapped kernel buffer) and param_2 (user buffer) for param_3 bytes. It is called from IOCTL 0x220014 with user-supplied output buffer pointer and size. Combined with IOCTL 0x220014's arbitrary physical address mapping, this allows reading arbitrary physical memory regions and copying them into user-space buffers.",
bug_class: KernelArbitraryReadOrWrite,
primary_attack_surface: "FUN_00012600 called from IOCTL 0x220014 with user-supplied buffer pointer and size",
path_and_state_to_reach_vulnerability: "1. Send IOCTL 0x220014 with physical address pointing to sensitive kernel memory (SSDT, kernel code, kernel data) 2. Set output buffer size to large value 3. Provide user-mode output buffer address via SystemBuffer 4. FUN_00012600 copies data from mapped IO space to user buffer 5. User reads arbitrary kernel memory contents",
why_plausible: "FUN_00012600 at line 000112ce-00012612 implements a memory copy that does not validate source or destination addresses. It is designed for performance with optimized bulk copy paths, but lacks bounds checking. The function is called directly with user-controlled parameters from IOCTL 0x220014, which also lacks bounds checking on the physical address being mapped.",
any_evidence_to_the_contrary: "The function does implement direction-aware copying (backward vs forward) to handle overlapping regions correctly. However, it does not validate that the source and destination are in valid memory ranges or that the caller has permission to access them.",
potentially_vulnerable_function: "FUN_00012600, FUN_00011260",
potentially_vulnerable_ioctl_if_relevant: "0x220014",
severity: High,
likelihood_of_exploitability: High,
next_step: Conclude,
},
],
next_step: Conclude,
number_of_iterations: 1,
},
)
