A practical guide to analyzing a Windows .sys kernel driver: PE structure, dangerous imports, IOCTL extraction, code signing, YARA, and how to read an automated risk score.
Whether you are triaging an unknown .sys file during incident response or vetting a driver before deployment, the goal of kernel driver analysis is to answer one question: what can this driver do, and could it be abused? This guide walks through the signals that matter and how to read them.
1. Start with the file and its hashes
Compute the MD5, SHA1, and SHA256. The SHA256 is your primary key for cross-referencing reputation and known-vulnerable corpora. A hash match against a known-vulnerable or malicious driver list is often the fastest possible verdict.
2. Validate the PE structure and entropy
Confirm the file is a valid Windows PE with the native (kernel) subsystem. Parse the section table and compute per-section entropy: values close to 8.0 suggest compression, encryption, or packing, which is unusual for a legitimate driver and worth a closer look.
3. Inspect the imports
The Import Address Table reveals capability. Flag dangerous kernel APIs such as ZwMapViewOfSection, MmMapIoSpace, ZwTerminateProcess, PsLookupProcessByProcessId, and routines that read or write physical memory or other processes' address space. A driver that imports process-termination or arbitrary-memory primitives has the building blocks of a BYOVD weapon.
4. Extract the IOCTL dispatch surface
Most driver abuse happens through IOCTL codes - the commands user-mode code sends via DeviceIoControl. Recover the dispatch routine and enumerate the IOCTLs it handles. An IOCTL that exposes arbitrary read/write, physical memory mapping, or process control is the single most important risk signal in a driver.
5. Check the code signing
Parse the Authenticode chain: signer, issuer, serial, and validity. Remember that a valid signature does not mean the driver is safe - it only tells you who shipped it. Read our guide to driver code signing for why signing and safety are different questions.
6. Match against rules and known-bad sets
Run YARA rules tuned for vulnerable-driver patterns and cross-reference the hash against known-vulnerable and CVE-linked driver corpora. Map any behavioural indicators to MITRE ATT&CK techniques such as T1068 (privilege escalation) for reporting.
Manual analysis vs. automated scoring
Manual reverse engineering gives the deepest understanding but does not scale. Automated analysis turns the signals above into a single composite score in seconds, which is ideal for triage. The two are complementary: use automation to prioritise, then reverse-engineer the high-risk outliers.
Reading a DriverShield report
Upload the .sys on the scan page or look up its hash. DriverShield runs all of the steps above and returns a 0-100 composite risk score mapped to four verdict bands: clean (0-29), suspicious (30-59), vulnerable (60-79), and malicious (80-100). The report breaks out the imports, extracted IOCTLs, YARA hits, signing details, and ATT&CK mapping so you can see exactly why the score is what it is. See the methodology for the full 14-stage pipeline and scoring weights.