Table of Contents for
Learning Malware Analysis

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Learning Malware Analysis by Monnappa K A Published by Packt Publishing, 2018
  1. Learning Malware Analysis
  2. Title Page
  3. Copyright and Credits
  4. Learning Malware Analysis
  5. Dedication
  6. Packt Upsell
  7. Why subscribe?
  8. PacktPub.com
  9. Contributors
  10. About the author
  11. About the reviewers
  12. Packt is searching for authors like you
  13. Table of Contents
  14. Preface
  15. Who this book is for
  16. What this book covers
  17. To get the most out of this book
  18. Download the color images
  19. Conventions used
  20. Get in touch
  21. Reviews
  22. Introduction to Malware Analysis
  23. 1. What Is Malware?
  24. 2. What Is Malware Analysis?
  25. 3. Why Malware Analysis?
  26. 4. Types Of Malware Analysis
  27. 5. Setting Up The Lab Environment
  28. 5.1 Lab Requirements
  29. 5.2 Overview Of Lab Architecture
  30. 5.3 Setting Up And Configuring Linux VM
  31. 5.4 Setting Up And Configuring Windows VM
  32. 6. Malware Sources
  33. Summary
  34. Static Analysis
  35. 1. Determining the File Type
  36. 1.1 Identifying File Type Using Manual Method
  37. 1.2 Identifying File Type Using Tools
  38. 1.3 Determining File Type Using Python
  39. 2. Fingerprinting the Malware
  40. 2.1 Generating Cryptographic Hash Using Tools
  41. 2.2 Determining Cryptographic Hash in Python
  42. 3. Multiple Anti-Virus Scanning
  43. 3.1 Scanning the Suspect Binary with VirusTotal
  44. 3.2 Querying Hash Values Using VirusTotal Public API
  45. 4. Extracting Strings
  46. 4.1 String Extraction Using Tools
  47. 4.2 Decoding Obfuscated Strings Using FLOSS
  48. 5. Determining File Obfuscation
  49. 5.1 Packers and Cryptors
  50. 5.2 Detecting File Obfuscation Using Exeinfo PE
  51. 6. Inspecting PE Header Information
  52. 6.1 Inspecting File Dependencies and Imports
  53. 6.2  Inspecting Exports
  54. 6.3  Examining PE Section Table And Sections
  55. 6.4 Examining the Compilation Timestamp
  56. 6.5 Examining PE Resources
  57. 7. Comparing And Classifying The Malware
  58. 7.1 Classifying Malware Using Fuzzy Hashing
  59. 7.2 Classifying Malware Using Import Hash
  60. 7.3 Classifying Malware Using Section Hash
  61. 7.4 Classifying Malware Using YARA
  62. 7.4.1 Installing YARA
  63. 7.4.2 YARA Rule Basics
  64. 7.4.3 Running YARA
  65. 7.4.4 Applications of YARA
  66. Summary
  67. Dynamic Analysis
  68. 1. Lab Environment Overview
  69. 2. System And Network Monitoring
  70. 3. Dynamic Analysis (Monitoring) Tools
  71. 3.1 Process Inspection with Process Hacker
  72. 3.2 Determining System Interaction with Process Monitor
  73. 3.3 Logging System Activities Using Noriben
  74. 3.4 Capturing Network Traffic With Wireshark
  75. 3.5 Simulating Services with INetSim
  76. 4. Dynamic Analysis Steps
  77. 5. Putting it All Together: Analyzing a Malware Executable
  78. 5.1 Static Analysis of the Sample
  79. 5.2 Dynamic Analysis of the Sample
  80. 6. Dynamic-Link Library (DLL) Analysis
  81. 6.1 Why Attackers Use DLLs
  82. 6.2 Analyzing the DLL Using rundll32.exe
  83. 6.2.1 Working of rundll32.exe
  84. 6.2.2 Launching the DLL Using rundll32.exe
  85. Example 1 – Analyzing a DLL With No Exports
  86. Example 2 – Analyzing a DLL Containing Exports
  87. Example 3 – Analyzing a DLL Accepting Export Arguments
  88. 6.3 Analyzing a DLL with Process Checks
  89. Summary
  90. Assembly Language and Disassembly Primer
  91. 1. Computer Basics
  92. 1.1 Memory
  93. 1.1.1 How Data Resides In Memory
  94. 1.2 CPU
  95. 1.2.1 Machine Language
  96. 1.3 Program Basics
  97. 1.3.1 Program Compilation
  98. 1.3.2 Program On Disk
  99. 1.3.3 Program In Memory
  100. 1.3.4 Program Disassembly (From Machine code To Assembly code)
  101. 2. CPU Registers
  102. 2.1 General-Purpose Registers
  103. 2.2 Instruction Pointer (EIP)
  104. 2.3 EFLAGS Register
  105. 3. Data Transfer Instructions
  106. 3.1 Moving a Constant Into Register
  107. 3.2 Moving Values From Register To Register
  108. 3.3 Moving Values From Memory To Registers
  109. 3.4 Moving Values From Registers To Memory
  110. 3.5 Disassembly Challenge
  111. 3.6 Disassembly Solution
  112. 4. Arithmetic Operations
  113. 4.1 Disassembly Challenge
  114. 4.2 Disassembly Solution
  115. 5. Bitwise Operations
  116. 6. Branching And Conditionals
  117. 6.1 Unconditional Jumps
  118. 6.2 Conditional Jumps
  119. 6.3 If Statement
  120. 6.4 If-Else Statement
  121. 6.5 If-Elseif-Else Statement
  122. 6.6 Disassembly Challenge
  123. 6.7 Disassembly Solution
  124. 7. Loops
  125. 7.1 Disassembly Challenge
  126. 7.2 Disassembly Solution
  127. 8. Functions
  128. 8.1 Stack
  129. 8.2 Calling Function
  130. 8.3 Returning From Function
  131. 8.4 Function Parameters And Return Values
  132. 9. Arrays And Strings
  133. 9.1 Disassembly Challenge
  134. 9.2 Disassembly Solution
  135. 9.3 Strings
  136. 9.3.1 String Instructions
  137. 9.3.2 Moving From Memory To Memory (movsx)
  138. 9.3.3 Repeat Instructions (rep)
  139. 9.3.4 Storing Value From Register to Memory (stosx)
  140. 9.3.5 Loading From Memory to Register (lodsx)
  141. 9.3.6 Scanning Memory (scasx)
  142. 9.3.7 Comparing Values in Memory (cmpsx)
  143. 10. Structures
  144. 11. x64 Architecture
  145. 11.1 Analyzing 32-bit Executable On 64-bit Windows
  146. 12. Additional Resources
  147. 13. Summary
  148. Disassembly Using IDA
  149. 1. Code Analysis Tools
  150. 2. Static Code Analysis (Disassembly) Using IDA
  151. 2.1 Loading Binary in IDA
  152. 2.2 Exploring IDA Displays
  153. 2.2.1 Disassembly Window
  154. 2.2.2 Functions Window
  155. 2.2.3 Output Window
  156. 2.2.4 Hex View Window
  157. 2.2.5 Structures Window
  158. 2.2.6 Imports Window
  159. 2.2.7 Exports Window
  160. 2.2.8 Strings Window
  161. 2.2.9 Segments Window
  162. 2.3 Improving Disassembly Using IDA
  163. 2.3.1 Renaming Locations
  164. 2.3.2 Commenting in IDA
  165. 2.3.3 IDA Database
  166. 2.3.4 Formatting Operands
  167. 2.3.5 Navigating Locations
  168. 2.3.6 Cross-References
  169. 2.3.7 Listing All Cross-References
  170. 2.3.8 Proximity View And Graphs
  171. 3. Disassembling Windows API
  172. 3.1 Understanding Windows API
  173. 3.1.1 ANSI and Unicode API Functions
  174. 3.1.2 Extended API Functions
  175. 3.2 Windows API 32-Bit and 64-Bit Comparison
  176. 4. Patching Binary Using IDA
  177. 4.1 Patching Program Bytes
  178. 4.2 Patching Instructions
  179. 5. IDA Scripting and Plugins
  180. 5.1 Executing IDA Scripts
  181. 5.2 IDAPython
  182. 5.2.1 Checking The Presence Of CreateFile API
  183. 5.2.2 Code Cross-References to CreateFile Using IDAPython
  184. 5.3 IDA Plugins
  185. 6. Summary
  186. Debugging Malicious Binaries
  187. 1. General Debugging Concepts
  188. 1.1 Launching And Attaching To Processes
  189. 1.2 Controlling Process Execution
  190. 1.3 Interrupting a Program with Breakpoints
  191. 1.4 Tracing Program Execution
  192. 2. Debugging a Binary Using x64dbg
  193. 2.1 Launching a New Process in x64dbg
  194. 2.2 Attaching to an Existing Process Using x64dbg
  195. 2.3 x64dbg Debugger Interface
  196. 2.4 Controlling Process Execution Using x64dbg
  197. 2.5 Setting a Breakpoint in x64dbg
  198. 2.6 Debugging 32-bit Malware
  199. 2.7 Debugging 64-bit Malware
  200. 2.8 Debugging a Malicious DLL Using x64dbg
  201. 2.8.1 Using rundll32.exe to Debug the DLL in x64dbg
  202. 2.8.2 Debugging a DLL in a Specific Process
  203. 2.9 Tracing Execution in x64dbg
  204. 2.9.1 Instruction Tracing
  205. 2.9.2 Function Tracing
  206. 2.10 Patching in x64dbg
  207. 3. Debugging a Binary Using IDA
  208. 3.1 Launching a New Process in IDA
  209. 3.2 Attaching to an Existing Process Using IDA
  210. 3.3 IDA's Debugger Interface
  211. 3.4 Controlling Process Execution Using IDA
  212. 3.5 Setting a Breakpoint in IDA
  213. 3.6 Debugging Malware Executables
  214. 3.7 Debugging a Malicious DLL Using IDA
  215. 3.7.1 Debugging a DLL in a Specific Process
  216. 3.8 Tracing Execution Using IDA
  217. 3.9 Debugger Scripting Using IDAPython
  218. 3.9.1 Example – Determining Files Accessed by Malware
  219. 4. Debugging a .NET Application
  220. Summary
  221. Malware Functionalities and Persistence
  222. 1. Malware Functionalities
  223. 1.1 Downloader
  224. 1.2 Dropper
  225. 1.2.1 Reversing a 64-bit Dropper
  226. 1.3 Keylogger
  227. 1.3.1 Keylogger Using GetAsyncKeyState()
  228. 1.3.2 Keylogger Using SetWindowsHookEx()
  229. 1.4 Malware Replication Via Removable Media
  230. 1.5 Malware Command and Control (C2)
  231. 1.5.1 HTTP Command and Control
  232. 1.5.2 Custom Command and Control
  233. 1.6 PowerShell-Based Execution
  234. 1.6.1 PowerShell Command Basics
  235. 1.6.2 PowerShell Scripts And Execution Policy
  236. 1.6.2 Analyzing PowerShell Commands/Scripts
  237. 1.6.3 How Attackers Use PowerShell
  238. 2. Malware Persistence Methods
  239. 2.1 Running the Registry Key
  240. 2.2 Scheduled Tasks
  241. 2.3 Startup Folder
  242. 2.4 Winlogon Registry Entries
  243. 2.5 Image File Execution Options
  244. 2.6 Accessibility Programs
  245. 2.7 AppInit_DLLs
  246. 2.8 DLL Search Order Hijacking
  247. 2.9 COM hijacking
  248. 2.10 Service
  249. Summary
  250. Code Injection and Hooking
  251. 1. Virtual Memory
  252. 1.1 Process Memory Components (User Space)
  253. 1.2 Kernel Memory Contents (Kernel Space)
  254. 2. User Mode And Kernel Mode
  255. 2.1 Windows API Call Flow
  256. 3. Code Injection Techniques
  257. 3.1 Remote DLL Injection
  258. 3.2 DLL Injection Using APC (APC Injection)
  259. 3.3 DLL Injection Using SetWindowsHookEx()
  260. 3.4 DLL Injection Using The Application Compatibility Shim
  261. 3.4.1 Creating A Shim
  262. 3.4.2 Shim Artifacts
  263. 3.4.3 How Attackers Use Shims
  264. 3.4.4 Analyzing The Shim Database
  265. 3.5 Remote Executable/Shellcode Injection
  266. 3.6 Hollow Process Injection (Process Hollowing)
  267. 4. Hooking Techniques
  268. 4.1 IAT Hooking
  269. 4.2 Inline Hooking (Inline Patching)
  270. 4.3 In-memory Patching Using Shim
  271. 5. Additional Resources
  272. Summary
  273. Malware Obfuscation Techniques
  274. 1. Simple Encoding
  275. 1.1 Caesar Cipher
  276. 1.1.1 Working Of Caesar Cipher
  277. 1.1.2 Decrypting Caesar Cipher In Python
  278. 1.2 Base64 Encoding
  279. 1.2.1 Translating Data To Base64
  280. 1.2.2 Encoding And Decoding Base64
  281. 1.2.3 Decoding Custom Base64
  282. 1.2.4 Identifying Base64
  283. 1.3 XOR Encoding
  284. 1.3.1 Single Byte XOR
  285. 1.3.2 Finding XOR Key Through Brute-Force
  286. 1.3.3 NULL Ignoring XOR Encoding
  287. 1.3.4 Multi-byte XOR Encoding
  288. 1.3.5 Identifying XOR Encoding
  289. 2. Malware Encryption
  290. 2.1 Identifying Crypto Signatures Using Signsrch
  291. 2.2 Detecting Crypto Constants Using FindCrypt2
  292. 2.3 Detecting Crypto Signatures Using YARA
  293. 2.4 Decrypting In Python
  294. 3. Custom Encoding/Encryption
  295. 4. Malware Unpacking
  296. 4.1 Manual Unpacking
  297. 4.1.1 Identifying The OEP
  298. 4.1.2 Dumping Process Memory With Scylla
  299. 4.1.3 Fixing The Import Table
  300. 4.2 Automated Unpacking
  301. Summary
  302. Hunting Malware Using Memory Forensics
  303. 1. Memory Forensics Steps
  304. 2. Memory Acquisition
  305. 2.1 Memory Acquisition Using DumpIt
  306. 3. Volatility Overview
  307. 3.1 Installing Volatility
  308. 3.1.1 Volatility Standalone Executable
  309. 3.1.2 Volatility Source Package
  310. 3.2 Using Volatility
  311. 4. Enumerating Processes
  312. 4.1 Process Overview
  313. 4.1.1 Examining the _EPROCESS Structure
  314. 4.1.2 Understanding ActiveProcessLinks
  315. 4.2 Listing Processes Using psscan
  316. 4.2.1 Direct Kernel Object Manipulation (DKOM)
  317. 4.2.2 Understanding Pool Tag Scanning
  318. 4.3 Determining Process Relationships
  319. 4.4 Process Listing Using psxview
  320. 5. Listing Process Handles
  321. 6. Listing DLLs
  322. 6.1 Detecting a Hidden DLL Using ldrmodules
  323. 7. Dumping an Executable and DLL
  324. 8. Listing Network Connections and Sockets
  325. 9. Inspecting Registry
  326. 10. Investigating Service
  327. 11. Extracting Command History
  328. Summary
  329. Detecting Advanced Malware Using Memory Forensics
  330. 1. Detecting Code Injection
  331. 1.1 Getting VAD Information
  332. 1.2 Detecting Injected Code Using VAD
  333. 1.3 Dumping The Process Memory Region
  334. 1.4 Detecting Injected Code Using malfind
  335. 2. Investigating Hollow Process Injection
  336. 2.1 Hollow Process Injection Steps
  337. 2.2 Detecting Hollow Process Injection
  338. 2.3 Hollow Process Injection Variations
  339. 3. Detecting API Hooks
  340. 4. Kernel Mode Rootkits
  341. 5. Listing Kernel Modules
  342. 5.1 Listing Kernel Modules Using driverscan
  343. 6. I/O Processing
  344. 6.1 The Role Of The Device Driver
  345. 6.2 The Role Of The I/O Manager
  346. 6.3 Communicating With The Device Driver
  347. 6.4 I/O Requests To Layered Drivers
  348. 7. Displaying Device Trees
  349. 8. Detecting Kernel Space Hooking
  350. 8.1 Detecting SSDT Hooking
  351. 8.2 Detecting IDT Hooking
  352. 8.3 Identifying Inline Kernel Hooks
  353. 8.4 Detecting IRP Function Hooks
  354. 9. Kernel Callbacks And Timers
  355. Summary
  356. Other Books You May Enjoy
  357. Leave a review - let other readers know what you think

6.1 The Role Of The Device Driver

When the driver is loaded into the system, the I/O manager creates a driver object (DRIVER_OBJECT structure). The I/O manager then calls the driver's initialization routine, DriverEntry (which is analogous to the main() or WinMain() functions), by passing a pointer to the DRIVER_OBJECT structure as an argument. A driver object (DRIVER_OBJECT structure) represents an individual driver on the system. The DriverEntry routine will use the DRIVER_OBJECT to populate it with various entry points of the driver for handling specific I/O requests. Typically, in the DriverEntry routine, the driver creates a device object (DEVICE_OBJECT structure) that represent logical or physical devices. The device is created using an API called IoCreateDevice or IoCreateDevice-Secure. When the driver creates a device object, it can optionally assign the name to the device and it can also create multiple devices. After the device is created, the pointer to the first created device is updated in the driver object. To help you understand this better, let's list the loaded kernel modules and look at a driver object of a simple kernel module. For this example, we will examine the null.sys kernel driver. As per Microsoft documentation, the Null device driver provides the functional equivalent of \dev\null in the Unix environment. When the system starts during the kernel initialization phase, null.sys gets loaded into the system. In the kernel module listing, you can see that null.sys is loaded at base address 8bcde000:

kd> lm k
start end module name
80ba2000 80baa000 kdcom (deferred) 
81e29000 81e44000 luafv (deferred) 
[REMOVED]
8bcde000 8bce5000 Null (deferred)

Since null.sys is already loaded, its driver object (DRIVER_OBJECT structure) will be populated with metadata information during the driver initialization. Let's look at its driver object to understand what kind of information it contains. You can display the driver object information using the !drvobj extension command. From the following output, the driver object representing null.sys is at address 86a33180. The value 86aa2750 below Device Object list is the pointer to the device object created by null.sys. If the driver creates multiple devices, you will see multiple entries under the Device Object list:

kd> !drvobj Null
Driver object (86a33180) is for:
 \Driver\Null
Driver Extension List: (id , addr)

Device Object list:
86aa2750

You can use the driver object address 86a33180 to examine the _DRIVER_OBJECT structure of null.sys using the dt (display type) command. From the following output, you can see that the DriverStart field holds the base address (0x8bcde000) of the driver, the DriverSize field contains the size of the driver(0x7000), and the Drivername is the name of the driver object (\Driver\Null). The DriverInit field holds the pointer to the Driver initialization routine (DriverEntry). The DriverUnload field contains the pointer to the driver's unload routine, which normally frees up resources created by the driver during unload process. The MajorFunction field is one of the most important fields, that points to a table of 28 major function pointers. This table will be populated with the addresses of the dispatch routines, and we will look at the MajorFunction table later in this section. The driverscan plugin covered earlier performs pool tag scanning for the driver objects and gets the information related to the kernel module such as base address, size, and the driver name by reading some of these fields:

kd> dt nt!_DRIVER_OBJECT 86a33180
   +0x000 Type : 0n4
   +0x002 Size : 0n168
   +0x004 DeviceObject : 0x86aa2750 _DEVICE_OBJECT
   +0x008 Flags : 0x12
   +0x00c DriverStart : 0x8bcde000 Void
   +0x010 DriverSize : 0x7000
   +0x014 DriverSection : 0x86aa2608 Void
   +0x018 DriverExtension : 0x86a33228 _DRIVER_EXTENSION
   +0x01c DriverName : _UNICODE_STRING "\Driver\Null"
   +0x024 HardwareDatabase : 0x82d86270 _UNICODE_STRING "\REGISTRY\MACHINE\HARDWARE\DESCRIPTION\SYSTEM"
   +0x028 FastIoDispatch : 0x8bce0000 _FAST_IO_DISPATCH
   +0x02c DriverInit : 0x8bce20bc long Null!GsDriverEntry+0
   +0x030 DriverStartIo : (null) 
   +0x034 DriverUnload : 0x8bce1040 void Null!NlsUnload+0
   +0x038 MajorFunction : [28] 0x8bce107c

The DeviceObject field in the DRIVER_OBJECT structure contains the pointer to the device object created by the driver (null.sys). You can use the device object address 0x86aa2750 to determine the name of the device created by the driver. In this case, Null is the name of the device created by the driver null.sys:

kd> !devobj 86aa2750
Device object (86aa2750) is for:
 Null \Driver\Null DriverObject 86a33180
Current Irp 00000000 RefCount 0 Type 00000015 Flags 00000040
Dacl 8c667558 DevExt 00000000 DevObjExt 86aa2808 
ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
Device queue is not busy.

You can also look at the actual DEVICE_OBJECT structure by specifying the device object address next to the display type (dt) command, as shown in the following code. If the driver creates more than one device, then the NextDevice field in the DEVICE_OBJECT structure will point to the next device object. Since the null.sys driver creates only one device, the NextDevice field is set to null:

kd> dt nt!_DEVICE_OBJECT 86aa2750
   +0x000 Type : 0n3
   +0x002 Size : 0xb8
   +0x004 ReferenceCount : 0n0
   +0x008 DriverObject : 0x86a33180 _DRIVER_OBJECT
   +0x00c NextDevice : (null) 
   +0x010 AttachedDevice : (null) 
   +0x014 CurrentIrp : (null) 
   +0x018 Timer : (null) 
   +0x01c Flags : 0x40
   +0x020 Characteristics : 0x100
   +0x024 Vpb : (null) 
   +0x028 DeviceExtension : (null) 
   +0x02c DeviceType : 0x15
   +0x030 StackSize : 1 ''
   [REMOVED]

From the preceding output, you can see that the DEVICE_OBJECT contains a DriverObject field that points back to the driver object. In other words, the associated driver can be determined from the device object. This is how the I/O manager can determine the associated driver when it receives the I/O request for a specific device. This concept can be visualized using the following diagram:

You can use a GUI tool such as DeviceTree (http://www.osronline.com/article.cfm?article=97) to look at the devices created by the driver. The following is a screenshot of the tool showing the Null device created by the null.sys driver:

When a driver creates a device, the device objects are placed in the \Device directory in the Windows object manager's namespace. To view the object manager's namespace information, you can use the  WinObj tool (https://docs.microsoft.com/en-us/sysinternals/downloads/winobj). The following screenshot shows the device (Null) created by null.sys in the \Device directory. You can also see the devices that have been created by other drivers:

The device created under the \Device directory is not accessible to the applications running in the user mode. In other words, if a user mode application wants to perform I/O operations on the device, it cannot directly open a handle to the device by passing the name of the device (such as \Device\Null) as the argument to the CreateFile function. The CreateFile function is not just used for creating or opening a file, it can also be used to open a handle to the device. If a user mode application cannot access the device, then how can it perform I/O operations? To make the device accessible to the user mode applications, the driver needs to advertise the device. This is done by creating a symbolic link to the device. A driver can create a symbolic link using the kernel API IoCreateSymbolicLink. When a symbolic link is created for a device (such as \Device\Null), you can find it in the \GLOBAL?? directory in the object manager namespace, which can also be viewed using the WinObj tool. In the following screenshot, you can see that NUL is the name of the symbolic link created for the \Device\Null device by the null.sys driver:

The symbolic link is also referred to as an MS-DOS device name. A user mode application can simply use the name of the symbolic link (MS-DOS device name) to open the handle to the device using the convention \\.\<symboliclink name>. For example, to open a handle to \Device\Null, a user mode application has to just pass \\.\NUL as the first argument (lpFilename) to the CreateFile function, which returns the file handle to the device. To be specific, anything that is a symbolic link within the object manager's directory GLOBAL?? can be opened using the CreateFile function. As shown in the following screenshot, the C: volume is just a symbolic link to \Device\HarddiskVolume1. In Windows, I/O operations are performed on virtual files. In other words, devices, directories, pipes, and files are all treated as virtual files (that can be opened using the CreateFile function):

At this point, you know that the driver, during its initialization, creates the device and advertises it to be used by the user application using symbolic links. Now, the question is, how does the driver tell the I/O manager what type of operation (open, read, write, and so on) it supports for the device? During initialization, another thing the driver normally does is update the Major function table (dispatch routine array) with the addresses of the dispatch routines in the DRIVER_OBJECT structure. Examining the major function table will give you an idea of the type of operations (open, read, write, and so on) supported by the driver, and the addresses of dispatch routines associated with the specific operation. The major function table is an array of 28 function pointers; the index values 0 to 27 represents a particular operation. For example, the index value 0 corresponds to the major function code IRP_MJ_CREATE, the index value 3 corresponds to the major function code IRP_MJ_READ, and so on. In other words, if an application wants to open a handle to a file or device object, the request will be sent to the I/O manager, which will then use the IRP_MJ_CREATE major function code as the index into the major function table to find the address of the dispatch routine that will handle this request. In the same manner for the read operation, IRP_MJ_READ is used as the index to determine the address of the dispatch routine.

The following !drvobj commands displays the dispatch routine array populated by the null.sys driver. The operations that are not supported by the driver point to IopInvalidDeviceRequest in the ntoskrnl.exe (nt). Based on this information, you can tell that null.sys only supports IRP_MJ_CREATE (open), IRP_MJ_CLOSE (close), IRP_MJ_READ (read), IRP_MJ_WRITE (write), IRP_MJ_QUERY_INFORMATION (query information), and IRP_MJ_LOCK_CONTROL (lock control) operations. Any request to perform any of the supported operations will be dispatched to the appropriate dispatch routine. For example, when the user application performs a write operation, the write request to the device will be dispatched to the MajorFunction[IRP_MJ_WRITE] function, which happens to be at address 8bce107c within the null.sys driver's unload routine. In the case of null.sys, all the supported operations are dispatched to the same address, 8bce107c. Normally, that is not the case; you will see different routine addresses for handling different operations:

kd> !drvobj Null 2
Driver object (86a33180) is for:
 \Driver\Null
DriverEntry: 8bce20bc Null!GsDriverEntry
DriverStartIo: 00000000 
DriverUnload: 8bce1040 Null!NlsUnload
AddDevice: 00000000 

Dispatch routines:
[00] IRP_MJ_CREATE                   8bce107c Null!NlsUnload+0x3c
[01] IRP_MJ_CREATE_NAMED_PIPE        82ac5fbe nt!IopInvalidDeviceRequest
[02] IRP_MJ_CLOSE                    8bce107c Null!NlsUnload+0x3c
[03] IRP_MJ_READ                     8bce107c Null!NlsUnload+0x3c
[04] IRP_MJ_WRITE                    8bce107c Null!NlsUnload+0x3c
[05] IRP_MJ_QUERY_INFORMATION        8bce107c Null!NlsUnload+0x3c
[06] IRP_MJ_SET_INFORMATION          82ac5fbe nt!IopInvalidDeviceRequest
[07] IRP_MJ_QUERY_EA                 82ac5fbe nt!IopInvalidDeviceRequest
[08] IRP_MJ_SET_EA                   82ac5fbe nt!IopInvalidDeviceRequest
[09] IRP_MJ_FLUSH_BUFFERS            82ac5fbe nt!IopInvalidDeviceRequest
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION 82ac5fbe nt!IopInvalidDeviceRequest
[0b] IRP_MJ_SET_VOLUME_INFORMATION   82ac5fbe nt!IopInvalidDeviceRequest
[0c] IRP_MJ_DIRECTORY_CONTROL        82ac5fbe nt!IopInvalidDeviceRequest
[0d] IRP_MJ_FILE_SYSTEM_CONTROL      82ac5fbe nt!IopInvalidDeviceRequest
[0e] IRP_MJ_DEVICE_CONTROL           82ac5fbe nt!IopInvalidDeviceRequest
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL  82ac5fbe nt!IopInvalidDeviceRequest
[10] IRP_MJ_SHUTDOWN                 82ac5fbe nt!IopInvalidDeviceRequest
[11] IRP_MJ_LOCK_CONTROL             8bce107c Null!NlsUnload+0x3c
[12] IRP_MJ_CLEANUP                  82ac5fbe nt!IopInvalidDeviceRequest
[13] IRP_MJ_CREATE_MAILSLOT          82ac5fbe nt!IopInvalidDeviceRequest
[14] IRP_MJ_QUERY_SECURITY           82ac5fbe nt!IopInvalidDeviceRequest
[15] IRP_MJ_SET_SECURITY             82ac5fbe nt!IopInvalidDeviceRequest
[16] IRP_MJ_POWER                    82ac5fbe nt!IopInvalidDeviceRequest
[17] IRP_MJ_SYSTEM_CONTROL           82ac5fbe nt!IopInvalidDeviceRequest
[18] IRP_MJ_DEVICE_CHANGE            82ac5fbe nt!IopInvalidDeviceRequest
[19] IRP_MJ_QUERY_QUOTA              82ac5fbe nt!IopInvalidDeviceRequest
[1a] IRP_MJ_SET_QUOTA                82ac5fbe nt!IopInvalidDeviceRequest
[1b] IRP_MJ_PNP                      82ac5fbe nt!IopInvalidDeviceRequest

You can also look at the supported operations in the DeviceTree tool, as shown the following screenshot:

At this point, you know that the driver creates the device, advertises it to be used by the user applications, and it also updates the dispatch routine array (major function table) to tell the I/O manager what operation it supports. Now, let's look at what the role of the I/O manager is and understand how the I/O request received from the user application is dispatched to the driver.