

This function is defined by the Microsoft documentation as follows: NTSTATUS DriverEntry(ĭon’t let the SAL annotation (the _In_ before the arguments) scare you, it only means the two arguments are supposed to be input arguments passed to the DriverEntry function. Like most pieces of code, drivers have a sort of “ main” function, known as DriverEntry. With that being said, let’s have a look at the structure of a driver. In fact, drivers are listed by Process Explorer as loaded modules inside the System process (the one with PID 4) You can think of drivers as some sort of kernel-side DLLs. Such events may be interrupts or processes requiring the operating system to do stuff the kernel handles those interrupts and may execute appropriate drivers to fulfill the requests. In Windows, drivers are essentially loadable modules containing code that will be executed in the context of the kernel when certain events occur. Before reverse-engineering the driver itself and looking for vulnerabilities we first have to take a look at what drivers are and how they work.
