symlink) to make it accessible to standard user processes. Devices & SymlinksĪ driver, in order to be accessed from user mode, has to create a device and a symbolic link (a.k.a. sys file from which the kernel loads the driver code). The RegistryPath argument is a pointer to a UNICODE_STRING structure (which is a structure containing a UTF-16 string and some other control information) that contains the registry path of the driver image (the. The DriverObject argument represents a pointer to a DRIVER_OBJECT data structure that holds information about the driver itself more on that later. 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.
0 kommentar(er)
