Kernel driver / BYOVD

Input

Any Windows PE image. Upload it, or give a link and the analysis host fetches the bytes. The gate is the MZ magic, so a driver delivered as .dat or under a random GUID is typed by content.

Ceilings

128 MB at the upload form. The module parses to a smaller ceiling of its own; a file between the two is still accepted, and the document names the size and the ceiling; nothing is quietly truncated to fit.

Layers

Static is the whole scan. Dynamic is a disabled field, not an unticked one, so a hand-crafted POST does not enable it. The derived-data AI layer is optional and off.

Calibration

Every import, rule and hardware primitive the module weighs is measured against how common it is across a corpus of real signed drivers, so an ordinary call is not read as a finding. The measured figure is printed beside the name it belongs to.

Output

Twelve named stages, four hashes including the Authenticode hash, an ATT&CK mapping in kill-chain order, generated Sigma rules as a downloadable bundle, and a verdict drawn from a vocabulary the rest of the platform does not have.

Time

Seconds. There is no snapshot to restore and no run to wait out; every document reports its own end-to-end duration in milliseconds.

What the module takes in, and what comes back refused

The submission gate is two bytes. A file whose first two bytes are not MZ is refused at the form with the reason and with somewhere to go instead, because for an archive, a script or a truncated blob there is no driver report to be had, only an empty one. Everything past that gate is typed by content: the extension decides nothing, which matters because a loader that brings its own vulnerable driver rarely drops it under the name it was published with.

A user-mode PE is deliberately accepted. Whether an image is kernel mode is a finding, and a finding belongs in the report: the decisive field is the optional header's subsystem, and when it is not the native subsystem the document says so in plain words and tells you the kernel-specific panels below it will be empty. Refusing that submission would teach the analyst nothing and cost them the round trip.

The submitted name is an input in its own right. It keys the cross-reference against publicly documented driver vulnerabilities, and it supplies the filename and version context the block-policy lookup needs. The name recorded on the submission wins over the stored sample's display name, because a sample row is shared by content and two analysts can submit the same bytes under two different names.

Does the driver ever get loaded or run?

No. Nothing is loaded, nothing is executed, no guest is opened and no snapshot is restored, so the driver does not become running kernel code on this platform. The form makes that structural: the dynamic layer is a disabled field, which ignores submitted data entirely and cleans to its initial value, and the view passes a literal false whatever arrives. An unticked box would have hidden the switch from an ordinary user while leaving it reachable to a crafted request.

The reason is an engineering one. Detonating a driver means loading kernel code in a guest, and doing that properly needs three things this platform has not built yet: a path that loads an unsigned or revoked image, a policy for the bugcheck that a genuinely vulnerable driver usually ends in, and a revert that survives the crash. An option nobody honours is a promise the report cannot keep, so the report's live panel states that kernel detonation is not yet available and shows the real queue of control codes that would be exercised. No field in it is filled with a plausible-looking value.

Being static has a consequence worth stating plainly, because it is the main practical difference an analyst feels. There is no restore, no arming and no run duration to wait out, so an answer arrives in seconds. Every document also carries its own measured end-to-end duration next to the stage list, so the figure you read is the one your own submission produced.

Which primitive does the driver hand to user mode?

A kernel driver is dangerous for one reason: it holds a capability that user mode does not have and it may be persuaded to use that capability on somebody else's behalf. So the first question is not whether the file looks malicious. It is which primitive the binary contains, and the binary declares that in two different places that have to be read two different ways.

Imports, read from the directory and graded against a base rate

The import table is parsed from the PE import directory, so "imports MmMapIoSpace" means the loader will bind MmMapIoSpace. A name lifted out of extracted strings would mean something much weaker, since any mention anywhere in the file produces one and a call bound by ordinal produces none at all. Ordinal-only imports are kept here under a synthetic name so the count stays complete, they do not match the graded table, and the report says so on the panel where it matters.

Every graded call is then weighed against how ordinary it is, and that ordinariness is measured: each name carries the share of a corpus of real signed drivers that also imports it, and a call that most drivers import is not treated as a finding. That grading is what keeps a module like this from calling every driver suspicious, because the call groups an ordinary driver trips are exactly the ones a naive reading scores. A common call is still shown, because an analyst reading a dispatch routine wants to see it; it is labelled as context and contributes nothing to the verdict.

Calls are then grouped into the eight primitives a driver can actually hand over, and a group takes its weight from its least common member, because a group is only as surprising as the most surprising call in it. Each panel names what the group gives away in one sentence, separates the calls it weighed from the ones it carried for context, and prints the measured prevalence beside every name, so the reading can be checked against the corpus and need not be taken on trust. The distribution above the panels labels the calls it did not weigh, so a name carried for context is never read as a severity judgement about it.

The primitives no import table can show

Reading model-specific registers, writing an I/O port, moving a control register and touching the hardware breakpoint registers are compiler intrinsics. They compile straight to an opcode and do not appear in an import table at all, so a reading built on import names has nothing to say about the primitive that defines the best known cases of driver abuse. __readmsr, __writemsr and READ_PORT_UCHAR are not imports of anything; they are two-byte and three-byte instructions sitting in the middle of a function.

They are read off the decoded instruction stream, in the same walk that recovers control codes. A read and a write are separated by operand position, so the two never collapse into one "register access" finding, and each site is recorded with its address so a reviewer can go and look at the function it sits in. Sites of one kind are kept up to a bound, because the count of them is what carries meaning and the thousandth address does not; the report prints how many were seen alongside the addresses it kept. That separation is the useful part: port I/O is what a hardware driver does for a living, a control register write is something else entirely, and reading them through one label would put the two on the same page as the same fact.

Some of those primitives never appear in the corpus at all, and the module is careful about what that licenses. An unobserved primitive is an absence of observation, and the code says so at the point where a clean sweep would otherwise read as a guarantee: a corpus drawn from one population can only report what that population does, and silence in it is a statement about the corpus before it is a statement about the file.

The IOCTL surface, and how a control code decodes

A dispatch routine reads the control code out of the current stack location and compares it, arm by arm, against the codes it serves. That comparison is the signal. Scanning a file for every aligned dword that merely has the shape of a control code is a different thing entirely: run over a real signed driver it returns tens of thousands of candidates, almost all of them ordinary constants that happen to fit the bit layout. Keeping only the immediates the driver's own code compares leaves a couple of dozen, and those are checkable against the driver's own claim about itself, because a storage class driver comes back with codes whose device type decodes to mass storage.

code            0x81232403
device type     0x8123  (vendor-defined range)
function code   0x900
transfer        METHOD_NEITHER
access          FILE_ANY_ACCESS
compared        yes, at 0x140003C7A
bytes in        .text  (executable)
evidence        compared at 0x140003C7A in an executable section

A worked example: one code, four fields

Take the code in the panel above, 0x81232403, invented for this page. Four fields are packed into those 32 bits, and the report separates them because each one answers a different question about the interface.

Read together, the four fields say: a vendor-defined interface, reachable by anyone who can open the device, serving one narrow operation, handed raw user pointers. That combination is what the module grades, and no single field would have carried it. The evidence line matters as much as the decode, because the same four fields decoded out of a constant the driver never compares describe an interface that does not exist.

Immediates that survive the disassembly are still filtered for plausibility before they are reported, because driver code compares a great many 32-bit constants that are not control codes: status values, four-character magic constants, bit masks. The filter separates those out, and its predicate is not published here, since written down it would be a map of what the extractor drops.

A short set of control codes that are already public knowledge in bring-your-own-vulnerable-driver tooling is also searched for as raw bytes, because the prior for those is different: the code is public, so its presence is worth reporting even where this pass cannot prove the driver compares it. They cover arbitrary process termination, physical memory read and write, and model-specific register read and write. The list itself is not printed here, and the distinction the report draws matters more than the list: a public code found only inside a firmware blob is reported as exactly that, with the section it landed in named, and it is not counted as a served interface. Without that distinction an ordinary signed device driver that happens to embed the constant would read as a finding.

What the binary says about itself: signing, mitigations, and who can open the device

Signing, and three things it is careful not to claim

The certificate is parsed, and parsing is all that is claimed. There is no signature verification here, no chain walk and no revocation check, and the report says so in its own note, and does not leave the reader to assume the stronger thing. What the module does answer is who is named, when the certificate expires, and whether the embedded digest still covers the bytes that are in front of it.

Resolving the signer correctly is less obvious than it sounds. A countersigned signature puts every certificate needed to validate it into one unordered bag, including the timestamping authority's own chain, so taking the first certificate in the file reports a driver as signed by a timestamping service: true of a certificate in the file, and false about who signed the driver. The leaf is resolved instead by code-signing extended key usage and by being the certificate that issued nothing else in the bag, and the issuer chain is then walked by name, with an organisational-unit fallback for cross-certificates that carry no common name at all.

The Authenticode hash is treated as a first-class identity for the same reason. It is computed over the image with the certificate table excluded, so stripping the signature off a driver moves all three flat hashes and leaves that one alone. That evasion is a practical one, and it is why the known-vulnerable corpus is queried on four identities in strength order, with the report stating which one matched and exactly what claim it licenses. "This exact file" and "the same image, re-signed or stripped of its signature" are different sentences, and the page prints whichever one is true.

The block policy is an operator-supplied artifact. This platform does not ship it, does not fetch it and hard-codes no location for it, and when it is absent the lookup records that it had no answer, and a clean result is never printed for a question nobody asked. What the lookup answers is narrow and worth stating exactly: whether this image would be admitted under the code-integrity policy the operator supplied. The module makes no claim about how strong that policy is or what it would stop. Where both corpora speak, two corpora agreeing is treated as one fact and counted once.

The mitigation matrix, and what each gap costs

Alongside those, the module lists the imports that reach a call target no compiler-emitted call site points at: a kernel routine resolved by name at run time and then invoked through the resolved pointer. That is reported as an observation about the image, with nothing attached about what any particular mitigation or policy would make of it.

Who can open the device object?

Reachability asks whether user mode can name the driver. The device ACL asks the other half of the question: whether an unprivileged caller can open it once it is named. A physical memory primitive behind a device only SYSTEM can open is a very different risk from the same primitive behind one any authenticated user can open. Security descriptors are recovered in both ASCII and UTF-16LE, split access-control entry by entry, and decoded into trustee, trustee privilege class and named rights, and the module separately reports which imports could actually bind a descriptor at all, because a descriptor string in a file with none of those calls present is a string and not an applied ACL.

Classification first, then a number that says how it was made

The driver is classified before it is graded, because nearly every heuristic in a module like this quietly assumes a driver that owns its own dispatch table. Classification runs on four axes, each carrying its evidence and its measured prevalence: the framework the driver is built on, its functional role, whether it belongs to a platform class whose whole job is direct hardware access, and whether the binary is itself a framework or port library, or a client of one.

Read the second row without the class and "no device interface named" looks like a finding, when for a substantial share of drivers it is close to the default. The class therefore emits its warnings onto the exact panels it makes unreliable, each one printed with the measurement behind it, and it changes no weight and no base rate anywhere: what an absence earns is an annotation on the panel where it would otherwise have read as a finding. Any softening a framework or port library earns is withdrawn the moment the signature no longer covers the bytes, because a port library's primitives are normally the ones it offers to its own clients, and that reading does not survive a binary that is no longer the one that was signed.

Functional role is read from the registration symbol a given kind of driver calls, then from an export, then from a linked library, in that order, and the report prints the corpus prevalence of the role it settles on. General purpose is the bulk of the population; network, storage, file system minifilter, network transport, audio, human interface, USB and display trail it, and the tail matters because a claimed role that does not fit the imports is itself worth reading.

The rule corpus, and the double count it refuses

The kernel-driver rule corpus is kept separate from the platform's general file-scanning corpus. It holds a small set of hand-written behaviour rules for the bring-your-own-vulnerable-driver case, and a much larger body of rules that identify a known-vulnerable driver by its version resource. API names are matched on word boundaries, and that detail is not cosmetic: a plain substring match binds the prefix of longer symbol names, which inflates how common a rule looks, and a rule that looks common is read as ordinary when it is nothing of the kind.

Every match is also tested positionally against the file offsets the import directory points at. A match whose entire evidence is the import name table is flagged as such and refused a second count, because the import layer has already graded exactly those names against a measured rate. One observation counted twice under two headings would read as two signals agreeing with each other, and it is not that.

ATT&CK and generated Sigma

Seven kinds of Sigma rule are generated from what was actually found, for driver-load and process-creation log sources: a hash rule that survives a rename, a rule for a published exploit control code, rules for the process termination, register access and physical memory primitives, one for a process opening the device object this driver names, and one for the kernel service install that is how such a driver gets loaded in the first place. Rule ids are derived deterministically from the sample hash and the rule kind, so importing the same driver's rules twice does not give a SIEM two copies, and the YAML comes out of a serialiser, so a hostile filename does not restructure the document it lands in.

The number, and which arithmetic produced it

Two arithmetics run. One is a weighted average over nine components, renormalised across the components that had an answer, so a layer that did not run is removed from the divisor, and never counted as a zero that would quietly make a driver look cleaner than it is. The other is a floor driven by definitive, specific facts, and it exists because a driver whose only finding is that it exposes arbitrary physical memory through a published control code is fully malicious with one signal, and no average of nine components will ever say so. The report states which of the two produced the number, and when the floor wins it lists the facts that set it, in words, beside the score. An analyst who adds the components up and gets something else should be able to see why in one glance, and should not be left to distrust the page.

"Vulnerable" is the module's own word. The platform-wide verdict vocabulary has no place for it, so it is mapped conservatively to suspicious for the shared scorer and shown in full on the driver report, and the driver score acts as a floor on the scan's overall verdict: it can pull the scan up, never down. Alongside the verdict the module prints a behaviour classification, one of endpoint-agent killer, privilege escalation primitive, rootkit component, bring-your-own-vulnerable-driver candidate, or no abusable primitive found, with a confidence, a rationale and the method named plainly as a primitive heuristic, with no pretence that a model produced it. Where the framework owns the dispatch table, the "nothing found" branch says the absence is weak evidence and does not state a conclusion.

What this module does not do

A driver this module calls clean can still be malicious in a way only a running kernel would show, because nothing here runs. Everything below is printed in the report itself, at the panel it applies to, so none of it waits to be discovered halfway through an incident.

Where this module hands off