This document discusses a massive fuzzing system for USB device drivers on Windows, addressing the challenges of analyzing closed-source drivers installed via Windows Update. It outlines the architecture of the fuzzing system, including techniques for monitoring and testing without physical hardware, and emphasizes the importance of controlling various system states during the fuzzing process. The goal is to identify vulnerabilities in driver implementations to enhance system security.

1. Massive Scale USB Device
Driver Fuzz WITHOUT device
HyperChem @ Tencent’s XuanLab

2. Agenda
•USB Backgroud；
•Windows Driver 010；
•Previous Research；
•My work；
•Result；

3. USB
• Universal Serial Bus；
• USB 1.0、1.1、2.0、3.0、3.1;
• Four type of Transfers：Control、Isochronous、Interrupt and
Bulk；
• Concept：
• Device
• Configuration
• Interface；
• Endpoint；
• Endpiont is bacic element for Transfers；

4. USB
• VID=Vendor ID，PID=Product ID;
• Device/InterfaceClass，Define device Class；
• Type of Descriptor：
• Device Descriptor ；
• Configuration Descriptor ；
• Interface Descriptor ；
• Endpoint Descriptor ；

5. USB
• Passive Device: receive request and send responds (except OTG)；
• Many different Classes: HID, WebCam，Printer；
• Plug and Play；
Enumeration
Driver
Selection
Driver
Loading
Initialization

6. Windows USB
• Detect Voltage Change between D+ and D-;
• Start Enumeration by USBHUB.sys；
• Loading Class driver；
• Search Device driver；
• Load Device driver；
• Call device driver EP；
• Done initialization, notify user mode；

7. Windows USB
• Action while Searching Driver：
• Spawn a userland process DrvInst.exe，with arguments InstanceID, VID
and PID;
• Call chkwudrv.dll!WUFindMatchingDriver to do the search；
• Enter into Windows Update service via LPC；
• Call wuaueng!CAgentProtocolTalker::SyncServerUpdates;
• If found, WUFindMatchingDriver return True；
• Key to Driver Searching：VID，PID，InstanceID；
• InstanceID is checked locally；

8. Previous Research
• BadUSB;
• vUSBf;
• USB MITM fuzz;
• USB fuzz via Arduino；
How about massive scale fuzzing on closed-source OS？

9. The Target
• Massive Fuzzing on USB drivers automatically installed from Windows Update：
• How many？
• How to obtain？
• How to analyze, and what to analyze!?
• NO hardware available!
• How the design the fuzzing system:
• Monitor;
• Fuzz target;
• State machine;
• Result collection;
• TestCase Generation;
• Crash analysis？
• Exploit bugs!？
Attack Scheme:
Plug a USB device,
Download and install drivers,
Trigger bugs and pwn

10. Attack Surface
Fuzzing on
Enumeration
Fuzzing On Class
Driver
Fuzzing on
Device Driver

11. How many drivers？
• For each combination of VID and PID, Only ONE driver will match；
• VID and PID are WORD, max to 65535；
• Total numbers are 4294967296(4GB);
• Valid VID：
• USB IF assigned；
• Library maintained by Microsoft :catalog.update.microsoft.com；
www.catalog.update.microsoft.com/v7/site/Search.aspx?q=usb%5Cvid_

12. How many drivers？
993 valid VIDs in total，
How to get all the drivers？
• Scheme 1：
• Simulate the progress of driver
searching；
• The PROS:
• Eazy coding(really!?);
• The CONS:
• Have to bypass InstanceID；
• Low efficiency；
• Memory leak in WUAU；
• Different Version have different
offset to hook；
• Only UpdateID available；
• Scheme 2：
• Make a standalone tool;
• The PROS:
• Ignore InstanceID；
• High efficiency;
• Easy to port to other version;
• A lot information got in one portion;
• The CONS:
• Need to reverse-engineering the protocol;

13. How many drivers？
• Read the protocol spec(WSUS) and extract data via RE;
• Partially implement a client in Python;
• Enumerate VID one by one；
• Deduplicate the same updateid and same download URI；
win7x64 win10x64 win7x86 win10x86
RAW 5598 6735 5756 6843
After updateid 3066 3230 3261 3406
After URI 966 1047 951 1014
Total 3978

14. What to obtain from driver cab?
• Roughly 45K drivers found in catalog website；
• What we need:
• Is sys file exists?
• How many sys files?
• Driver type;
• Device type；
• PIDs Supported；
• Number of INF files；
• Dynamic information while installation；
• Information in binary level；

15. Obtain information from driver cab
• Auto Cab file analysis System：
• Filter out those with NO sys file;
• Parse INF file；
• Get Supported PIDs；
• Get dynamic behavior of INF file: registry, file copy；
• Driver and device type；
• IDA plugin for binary analysis：
• Determine driver type precisely；
• Identify Callback/ Event handler；
• Sensitive APIs and strings Scanning;
• WDF prototype recovery;

16. Before After

17. No hardware available
• The obstacles：
• Prepare devices for
thousands of drivers；
• Unable to make it
automatically；
• Different type devices；
• Costly；
• The solution:
• Emulated USB device;
• USB protocol in python;
• Based on Virtual Machine；
• All in software, easy to monitor；
QEMU+USBRedir

19. Hardware emulation
• USB redir Protocol: redirect physical USB device into virtual machine；
• Has to enable this feature while compiling QEMU；
• The cmd options to use this feature：-device usb-
redir,chardev=usbchardev,debug=0 -chardev
socket,server,id=usbchardev,nowait,path=/tmp/usbr_{CCC}.sock“
• Connect the socket normally, send the protocol packets, then a USB
device shows in VM；
• Keys：
• Use scapy to construct USB protocol in Python (Based on vUSBf’s work)；
• Parse real USB device descriptor file；
• Modify VID and PID to trigger different driver loading;
• Extend the code this suite for different classes；
• Microsoft specific descriptor；

20. Hardware emulation
• Bulk transfer is included in many device driver；
• Customized struct of data often used in Bulk transfer；
• Data sent by USB device；
• Add some code on responsing Bulk transfer requests；

21. Execute program inside VM
• Some Fuzz progress need to be done inside VM→
Execute program inside VM；
• QGA(Qemu Guest Agent),much like VMTools, but customizable；
• Run as service on Windows,expose Virtual COM device inside VM；
• Exposed as regular socket outside VM；
• Feature：
• Probe VM status；
• Read/Write File；
• Execute Program；
• Etc.

22. VM Management
• Management various state
of VM life cycle；
• Automatically switch states
depends on criteria；
• Collect different info at
different state；
Initial
EnvOK DrvInstalled
VMSnap
Alive
Plugin
Fuzzing
End
Restart
VMCrash
BSOD
DrvRdy
VMStuck

23. Driver Installation System
• Pre-install drivers into OS before fuzzing；
• Dynamically parse CAB file depends on results of installation for
each INF file；
• Hypothesis：
• CAB is valid with a valid signature;
• CAB can be installed successfully；
• At least one valid INF file in CAB;
• Information obtained：
• List of valid INF file;
• INF dynamic behavior while installation；
• The actual copied/ installed sys file；

24. Three mode of fuzzing
Plugin Fuzz
Bulk Fuzz
IoControl Fuzz
• Find bugs triggered while plug a USB device;
• Mostly in AddDevice callback,and IRP_PNP handler;
• BSOD immediately after a USB device pluged;
• A lot of…；
• Find bugs while parsing/processing BULK in data
• Vulnerable code varies；
• Many communication;
• Also many bugs；
• Most common bugs in drivers；
• Easiest to discover and exploit kernel mode bugs；
• Huge attack surface;
Crafted Device descriptor
Bulk transfer fuzzing code
Fuzzer Running inside VM

25. Design a Fuzzer
• Running inside VM，For fuzzing IoControlCode；
• Dynamically enumerate device interface created by drivers；
• Iterate each IoControlCode by random fuzzing;
• Record random seed and progress before each fuzzing；
• Record any buffer out data for further analysis；
• Support bug verification；

26. Monitor and Record
• Inside VM：
• Device interfaces；
• Fuzzing Progress；
• Continue to fuzz while BSOD；
• Record the random seed；
• Detect Virtual USB pluged；
• Detect status of driver loading；
• Outside VM：
• VM living；
• BSOD；
• CrashDump and testcase；
• Valid INF and Copied Drivers；
• Fuzz Progress and crash record；
• VM state management；

28. What to Monitor
• Status Monitor：
• Is VM alive；
• Is VM stuck；
• Is VM BSOD；
• Heartbeat in
Share Directory；
• Progress Monitor：
• Does Fuzzing
Complete；
• Extract Progress
record；
• Parse and record
progress；
• Shutdown while
finished；
• Crash Monitor：
• Does BSOD
happen；
• Extract
Crashdump while
BSOD；
• Extract testcase；
• Shutdown while
finished；
• Driver Monitor：
• Check if driver is
installing；
• Check if driver
status；

29. Bug verification
• Verify bugs from all three fuzzing mode；
• Support Kernel Debugging on Linux；
• One-Click to enable kernel debugging mode；
• Kernel Debugging based on virtual serial com；
• Testcase loading;
• Symbol supported;

30. CrashDump Auto-analysis
• Hundreds of CrashDump to be analyzed
• Lots of duplication and time consuming ；
• python+pykd make life easier；
• Parse Crashdump and output basic
information；

31. Example

32. Result

33. Demo

34. Summary
• We propose a novel attack surface of Windows；
• We established a fuzzing system to fuzz USB device driver;
• 3rd party driver developer differs in code quality；
• Low quality of device drive may harm to Microsoft ecology;
• Virtual device make driver fuzzing possible, extensible, reliable
and efficient;

35. Q&A