{"id":147,"date":"2007-06-18T11:01:32","date_gmt":"2007-06-18T11:01:32","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2007\/06\/18\/we-want-samples\/"},"modified":"2026-07-25T16:05:21","modified_gmt":"2026-07-25T16:05:21","slug":"we-want-samples","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2007\/06\/18\/we-want-samples\/","title":{"rendered":"We want samples"},"content":{"rendered":"
\"\"<\/a><\/div>\n

\"\"<\/p>\n

A few months after my hiring into Open<\/a>, they asked me to do a participation in a lecture about Secure Code<\/strong>. My part was about stack overflow and how to take advantage of that oversight programmer to break into the program. The major point to note was in addition to programmers, the audience was composed by software engineers and architects, the commercial\u00a0staff, who had more contact with customers were there also, there were one or two people from administrative sector as well, in summary, an audience that few of them have heard about call stack. One of them said: “I sort of remember from when I got my .Net certification, which said that structures are created on the heap and objects are created on the heap, or vice versa.”<\/em> Anyway, things became more complicated when I started to show the sample code I supplied, with PUSHs, MOVs and POPs. The result was: some slept, while others just drooled and spoke in that alien language while they sleep. I know that language very well because my wife always talks to me while she sleeps and I’m sitting in bed with the notebook. Despite her words being completely incomprehensible, she always responds when I make questions to her. She introduces the subject by saying: “Admivoza bumizav”<\/em> then I ask: “Why do you think so?”<\/em> And she replies: “Zumirag abmish mua”<\/em>. But back to the subject, it became clear that the amount of technical detail was incompatible with the public. So, not long ago, in a talking about Windows drivers, I tried to pass a vision with little details, just to give an idea what drivers are and how they contribute to the system work. After all, the entire development department was there, including architects, engineers and .Net coders (nothing against them). To my surprise, at the end of the lecture, everyone was expecting more details, something like: \u00a0“Hey, what about the remaining? Don’t you have any little example?”<\/em>. So, okay… In this post, I will write a minimal driver, but one that has some interaction with a test application.<\/p>\n

At the beginning…<\/h3>\n

Here I will assume that you have already known how to create a driver project from scratch<\/a> and how to use Visual Studio to code drivers<\/a>, going straight to the point where we must write the driver. The today’s example will be a very basic\u00a0echo driver commands that will receive commands through reading and writing. So, it would be like that: you initially write buffers, which are strings in our example using the WriteFile()<\/a> function and everything will be stored into the driver. The subsequent readings from the function ReadFile()<\/a> will bring the same data from where were written. This example will be very useful in other posts, and will also serve as a starting point for those wanting to write their first driver.<\/p>\n

Knowing that we will store the strings in a list, and then we need to create a buffer\u00a0list composed by nodes defined as shown below.<\/p>\n

\n
\/\/-f--> Type definition to be stored into<\/span><\/pre>\n
\/\/      our buffer list.<\/span><\/pre>\n
typedef<\/span> struct<\/span> _BUFFER_ENTRY<\/pre>\n
{<\/pre>\n
    PVOID       pBuffer;    \/\/-f--> Sent buffer<\/span><\/pre>\n
    ULONG       ulSize;     \/\/      Buffer size<\/span><\/pre>\n
    LIST_ENTRY  Entry;      \/\/      List node<\/span><\/pre>\n
 <\/pre>\n
} BUFFER_ENTRY, *PBUFFER_ENTRY;<\/pre>\n
 <\/pre>\n
 <\/pre>\n
\/\/-f--> List head and mutex for protection <\/span><\/pre>\n
LIST_ENTRY      g_BufferList;<\/pre>\n
KMUTEX          g_Mutex;<\/pre>\n<\/div>\n
After defining the structure, we have to create a global variable that will be the list head and also a mutex<\/a>, to protect our list from possible accesses in parallel. This would happen if we had two test applications running at the same time. If you want more details about the DDK linked lists, there is a post<\/a> that explains about that, too.<\/p>\n
Writing DriverEntry routine<\/h3>\n
The first point to notice here is that, since our example has been coded in a .CPP\u00a0file, it’s necessary to put an extern “C”<\/strong> at the DriverEntry<\/em> function definition. Otherwise, the linker will not find the driver\u00a0entry point. Early in the implementation, we can see the message that will be launched to the debugger via KdPrint()<\/a>. Next, I will initialize our linked list head and the mutex that protect it. Now let’s set some members in the DriverObject<\/em> structure and the first will be DriverUnload\u00a0member, which receives a pointer to a callback function that will inform the driver that it is being unloaded. The next few members are the routines that will be called when the driver receives requests about Create<\/strong>\/Open<\/strong>, Close<\/strong>, Read<\/strong> and Write<\/strong>. I will talk about these routines with more details a little later. Continuing, the DeviceObject <\/strong>is created<\/span><\/em>, which will be our way of communication way with the driver. As I said at the lecture, all requests a driver receives are through a device. IoCreateDevice()<\/a> function makes this for us. Created the device, I will now configure it so that it should use intermediate buffers. For this, I have to set the bit DO_BUFFERED_IO <\/strong>in Flags<\/em> field from DeviceObject<\/em> you have just created. Intermediate buffers?<\/strong> We’ll talk about BufferedIo<\/em> versus DirectIo<\/em> in a future opportunity. There are so many new concepts in this post and I, unfortunately cannot go very deep into their details, otherwise nobody would read it that never seems ending up.<\/p>\n
Having a DeviceObject is cool, but it is not everything in driver’s life; for a User Mode<\/strong> application being able to communicate with a driver, you must create a Symbolic Link<\/strong>. This is done next with IoCreateSymbolicLink()<\/a> function. The remaining function code should not cause great surprise to most of you, but if in doubt, just send me an e-mail and we can resolve this in a fight.<\/p>\n
\n
\/****<\/span><\/pre>\n
***     DriverEntry<\/span><\/pre>\n
**<\/span><\/pre>\n
**      This is the driver entry point.<\/span><\/pre>\n
**      Knife in teeth and blood in eyes.<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
extern<\/span> \"C\"<\/span><\/pre>\n
NTSTATUS DriverEntry(IN PDRIVER_OBJECT pDriverObj,<\/pre>\n
                     IN PUNICODE_STRING pusRegistryPath)<\/pre>\n
{<\/pre>\n
    NTSTATUS        nts;<\/pre>\n
    PDEVICE_OBJECT  pDeviceObj = NULL;<\/pre>\n
 <\/pre>\n
    __try<\/span><\/pre>\n
    {<\/pre>\n
        \/\/-f--> Saying hello to the Kernel Debugger<\/span><\/pre>\n
        KdPrint((\"Starting KernelEcho driver...\\n\"<\/span>));<\/pre>\n
 <\/pre>\n
        \/\/-f--> Initializing the buffer head list and mutex<\/span><\/pre>\n
        InitializeListHead(&g_BufferList);<\/pre>\n
        KeInitializeMutex(&g_Mutex, 0<\/span>);<\/pre>\n
 <\/pre>\n
        \/\/-f--> Setting the driver unload callback<\/span><\/pre>\n
        pDriverObj->DriverUnload = OnDriverUnload;<\/pre>\n
 <\/pre>\n
        \/\/-f--> Setting the driver routines that<\/span><\/pre>\n
        \/\/      will be supported.<\/span><\/pre>\n
        pDriverObj->MajorFunction[IRP_MJ_CREATE] = OnCreate;<\/pre>\n
        pDriverObj->MajorFunction[IRP_MJ_CLOSE] = OnClose;<\/pre>\n
        pDriverObj->MajorFunction[IRP_MJ_WRITE] = OnWrite;<\/pre>\n
        pDriverObj->MajorFunction[IRP_MJ_READ] = OnRead;<\/pre>\n
 <\/pre>\n
        \/\/-f--> Creating the control device<\/span><\/pre>\n
        nts = IoCreateDevice(pDriverObj,<\/pre>\n
                             0<\/span>,<\/pre>\n
                             &g_usDeviceName,<\/pre>\n
                             FILE_DEVICE_UNKNOWN,<\/pre>\n
                             0<\/span>,<\/pre>\n
                             FALSE,<\/pre>\n
                             &pDeviceObj);<\/pre>\n
        if<\/span> (!NT_SUCCESS(nts))<\/pre>\n
            ExRaiseStatus(nts);<\/pre>\n
 <\/pre>\n
        \/\/-f--> Configuring I\/O using intermediary buffer<\/span><\/pre>\n
        pDeviceObj->Flags |= DO_BUFFERED_IO;<\/pre>\n
 <\/pre>\n
        \/\/-f--> Creating a symbolic link, so applications<\/span><\/pre>\n
        \/\/      can reach this device.<\/span><\/pre>\n
        nts = IoCreateSymbolicLink(&g_usSymbolicLink,<\/pre>\n
                                   &g_usDeviceName);<\/pre>\n
        if<\/span> (!NT_SUCCESS(nts))<\/pre>\n
            ExRaiseStatus(nts);<\/pre>\n
 <\/pre>\n
    }<\/pre>\n
    __except<\/span>(EXCEPTION_EXECUTE_HANDLER)<\/pre>\n
    {<\/pre>\n
        \/\/-f--> Getting the error code<\/span><\/pre>\n
        nts = GetExceptionCode();<\/pre>\n
 <\/pre>\n
        \/\/-f--> That will force the debugger to stop here.<\/span><\/pre>\n
        \/\/      But only when this code is built in Checked mode.<\/span><\/pre>\n
        ASSERT(FALSE);<\/pre>\n
        KdPrint((\"An exception occurred at \"<\/span> __FUNCTION__ \"\\n\"<\/span>));<\/pre>\n
 <\/pre>\n
        \/\/-f--> Since we had problems during the initialization, let's<\/span><\/pre>\n
        \/\/      undo what was done.<\/span><\/pre>\n
        if<\/span> (pDeviceObj)<\/pre>\n
            IoDeleteDevice(pDeviceObj);<\/pre>\n
    }<\/pre>\n
 <\/pre>\n
    return<\/span> nts;<\/pre>\n
}<\/pre>\n<\/div>\n
Writing Dispatch Functions<\/h3>\n
I’ll also assume that you have already had an idea of what an IRP is<\/a>.\u00a0Now let’s write the functions to manipulate them. They are called Dispatch Functions<\/strong>.\u00a0These functions are set at driver\u00a0startup time as you have seen in the code above. In the DriverObject structure, the MajorFunction\u00a0member is a function pointer\u00a0array indexed for macros like IRP_MJ_READ<\/a>.\u00a0The function prototype is the same for all functions and it will be displayed below. Dispatch Function<\/strong> needs to handle IRPs following some rules, like everything else at DDK.\u00a0A minimal function could be written as follows:<\/p>\n
\n
\/****<\/span><\/pre>\n
***     OnDispatch<\/span><\/pre>\n
**<\/span><\/pre>\n
**      A minimum Dispatch Function example<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
NTSTATUS<\/pre>\n
OnDispatch(IN PDEVICE_OBJECT  pDeviceObj,<\/pre>\n
           IN PIRP            pIrp)<\/pre>\n
{<\/pre>\n
    \/\/-f--> Here I fill the IRP status.<\/span><\/pre>\n
    pIrp->IoStatus.Status = STATUS_SUCCESS;<\/pre>\n
    pIrp->IoStatus.Information = 0<\/span>;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Completing the IRP. After that, touching the IRP structure<\/span><\/pre>\n
    \/\/      is absolutely prohibited. That does not belong to you anymore.<\/span><\/pre>\n
    IoCompleteRequest(pIrp, IO_NO_INCREMENT);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Return status code to the IoManager.<\/span><\/pre>\n
    return<\/span> STATUS_SUCCESS;<\/pre>\n
}<\/pre>\n<\/div>\n
But what if we had called the ReadFile() <\/strong>function <\/strong>with a handle to our device if we did not fill the position IRP_MJ_READ? Would we burn up forever in marble from hell?<\/strong> Indeed, if we take a look at MajorFunction<\/em> table before filling it, we can see that there is the same address in all slots.\u00a0Let’s put a break-point at DriverEntry\u00a0entrance, take a look on the table slots before being filled out and see what’s there.<\/p>\n
\"\"<\/div>\n
As we saw, this table is all initialized with a function pointer that it’s in implementation; considering that the power management IRPs have a special treatment, it completes the IRP with status STATUS_INVALID_DEVICE_REQUEST<\/strong>.<\/p>\n
A Dispatch Function basically follows one of the three alternatives for dealing with an IRP. In cases of filters, our driver could pass the IRP to the driver which it was attached to. Okay, that was noted here… “Do a post providing a filter example”. The second alternative would retain the IRP to an asynchronous processing and the last but not least, simply complete the IRP. Notice that in our example, all that we do is to tell the application that the IRP was successfully performed and completed it. To complete the IRP, we use the IoCompleteRequest()<\/a> function, which receives the IRP to be completed and the Priority Boost<\/em>. What?<\/strong> Assuming your IRP had some interaction with hardware, it would consume some thread time in Kernel Mode. This time it would create a delay in the current thread and this would be compensated by this Boost<\/em>. Because this is not our case, we use the macro to define no Boost. DDK has a list of constants that determines the boost that a thread should receive for each type of device. See the WDM.h\u00a0excerpt (this definition may be in ntddk.h depending on your DDK version).<\/p>\n
\n
\/\/<\/span><\/pre>\n
\/\/ Priority increment for completing CD-ROM I\/O.  This is used by CD-ROM device<\/span><\/pre>\n
\/\/ and file system drivers when completing an IRP (IoCompleteRequest)<\/span><\/pre>\n
\/\/<\/span><\/pre>\n
 <\/pre>\n
#define<\/span> IO_CD_ROM_INCREMENT             1<\/span><\/pre>\n<\/div>\n
At the end of this post, there will be a link to download all the files needed to build the application and driver.\u00a0Notice, in the sample\u00a0sources, that our OnCreate()<\/em> and OnClose()<\/em> Dispatch Functions are too similar to the example above.\u00a0That’s because we don’t take no action when it opens or closes a handle to the device we had created.<\/p>\n
Getting parameters from IRP.<\/span><\/h3>\n
In the other OnRead() and OnWrite() Dispatch Functions, we must get data that the driver needs to execute the IRP, such as buffer posted by the user and its size, both in writing and reading.\u00a0These parameters are into a Stack Location<\/strong> within the IRP.\u00a0Wow, the more I pray, the more weird names appear to me<\/strong>…\u00a0Stack Locations structures are parameters that are allocated along with the IRP.\u00a0There is a Stack Location for each device in the device stack that was called.\u00a0This conversation can become quite fun, but we have a post to finish.\u00a0Let’s leave this subject about Stack Locations to our future filter example.\u00a0There, the matter makes more sense,\u00a0but if you cannot take such a curiosity and want to know more about it, see what the reference says about Stack Locations<\/a>.\u00a0For now, let’s just consider that these parameters are there and to have access to this structure we need to use IoGetCurrentIrpStackLocation()<\/a> macro.\u00a0To have a more practical idea of all this bullshit, here it goes all the OnWrite()<\/em> function code with tons of comments.<\/p>\n
\n
\/****<\/span><\/pre>\n
***     OnWrite<\/span><\/pre>\n
**<\/span><\/pre>\n
**      This routine is called, whenever an application calls WriteFile()<\/span><\/pre>\n
**      using our device handle as a parameter.<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
NTSTATUS<\/pre>\n
OnWrite(IN PDEVICE_OBJECT  pDeviceObj,<\/pre>\n
        IN PIRP            pIrp)<\/pre>\n
{<\/pre>\n
    PIO_STACK_LOCATION  pStack;<\/pre>\n
    PVOID               pUserBuffer;<\/pre>\n
    ULONG               ulSize;<\/pre>\n
    PBUFFER_ENTRY       pBufferEntry = NULL;<\/pre>\n
    NTSTATUS            nts;<\/pre>\n
    BOOLEAN             bMutexAcquired = FALSE;<\/pre>\n
 <\/pre>\n
    __try<\/span><\/pre>\n
    {<\/pre>\n
        \/\/-f--> Say hello to the debugger<\/span><\/pre>\n
        KdPrint((\"Writing into EchoDevice...\\n\"<\/span>));<\/pre>\n
 <\/pre>\n
        \/\/-f--> The Buffer address is a parameter that comes<\/span><\/pre>\n
        \/\/      from the IRP<\/span><\/pre>\n
        pUserBuffer = (PCHAR)pIrp->AssociatedIrp.SystemBuffer;<\/pre>\n
        ASSERT(pUserBuffer != NULL);<\/pre>\n
 <\/pre>\n
        \/\/-f--> Get the current stack location address from the IRP<\/span><\/pre>\n
        pStack = IoGetCurrentIrpStackLocation(pIrp);<\/pre>\n
 <\/pre>\n
        \/\/-f--> Get the buffer size<\/span><\/pre>\n
        ulSize = pStack->Parameters.Write.Length;<\/pre>\n
 <\/pre>\n
        \/\/-f--> Here, the node and the string buffer<\/span><\/pre>\n
        \/\/      are allocated all together<\/span><\/pre>\n
        pBufferEntry = (PBUFFER_ENTRY) ExAllocatePoolWithTag(<\/pre>\n
            PagedPool,<\/pre>\n
            sizeof<\/span>(BUFFER_ENTRY) + ulSize,<\/pre>\n
            ECHO_TAG);<\/pre>\n
 <\/pre>\n
        \/\/-f--> If there is no memory, forget it...<\/span><\/pre>\n
        if<\/span> (!pBufferEntry)<\/pre>\n
            ExRaiseStatus(STATUS_NO_MEMORY);<\/pre>\n
 <\/pre>\n
        \/\/-f--> Initializing the structure<\/span><\/pre>\n
        pBufferEntry->pBuffer = (pBufferEntry + 1<\/span>);<\/pre>\n
        pBufferEntry->ulSize = ulSize;<\/pre>\n
 <\/pre>\n
        \/\/-f--> Do the copy string from the buffer sent by the user<\/span><\/pre>\n
        \/\/      to the buffer allocated here.<\/span><\/pre>\n
        RtlCopyMemory(pBufferEntry->pBuffer,<\/pre>\n
                      pUserBuffer,<\/pre>\n
                      ulSize);<\/pre>\n
 <\/pre>\n
        \/\/-f--> Acquire the mutex that protect the list<\/span><\/pre>\n
        \/\/      against simultaneous accesses.<\/span><\/pre>\n
        nts = KeWaitForMutexObject(&g_Mutex,<\/pre>\n
                                   UserRequest,<\/pre>\n
                                   KernelMode,<\/pre>\n
                                   FALSE,<\/pre>\n
                                   NULL);<\/pre>\n
        if<\/span> (!NT_SUCCESS(nts))<\/pre>\n
            ExRaiseStatus(nts);<\/pre>\n
 <\/pre>\n
        \/\/-f--> We need to remember this in case something<\/span><\/pre>\n
        \/\/      really bad happens.<\/span><\/pre>\n
        bMutexAcquired = TRUE;<\/pre>\n
 <\/pre>\n
        \/\/-f--> Insert the new node to the list's tail.<\/span><\/pre>\n
        InsertTailList(&g_BufferList,<\/pre>\n
                       &pBufferEntry->Entry);<\/pre>\n
 <\/pre>\n
        \/\/-f--> Tell the IoManager that all data sent<\/span><\/pre>\n
        \/\/      to the driver were read successfully.<\/span><\/pre>\n
        pIrp->IoStatus.Information = ulSize;<\/pre>\n
        nts = STATUS_SUCCESS;<\/pre>\n
    }<\/pre>\n
    __except<\/span>(EXCEPTION_EXECUTE_HANDLER)<\/pre>\n
    {<\/pre>\n
        \/\/-f--> Get the error code.<\/span><\/pre>\n
        nts = GetExceptionCode();<\/pre>\n
 <\/pre>\n
        \/\/-f--> That will force the debugger to stop here.<\/span><\/pre>\n
        \/\/      But only when compiled in Checked mode.<\/span><\/pre>\n
        ASSERT(FALSE);<\/pre>\n
        KdPrint((\"An exception occurred at \"<\/span> __FUNCTION__ \"\\n\"<\/span>));<\/pre>\n
 <\/pre>\n
        \/\/-f--> If something gets wrong and we have already allocated<\/span><\/pre>\n
        \/\/      this buffer, so let's release it.<\/span><\/pre>\n
        if<\/span> (pBufferEntry)<\/pre>\n
            ExFreePool(pBufferEntry);<\/pre>\n
 <\/pre>\n
        \/\/-f--> Tell the IoManager the no data were transferred.<\/span><\/pre>\n
        pIrp->IoStatus.Information = 0<\/span>;<\/pre>\n
    }<\/pre>\n
 <\/pre>\n
    \/\/-f--> Release the mutex<\/span><\/pre>\n
    if<\/span> (bMutexAcquired)<\/pre>\n
        KeReleaseMutex(&g_Mutex,<\/pre>\n
                       FALSE);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Complete the IRP.<\/span><\/pre>\n
    pIrp->IoStatus.Status = nts;<\/pre>\n
    IoCompleteRequest(pIrp, IO_NO_INCREMENT);<\/pre>\n
    return<\/span> nts;<\/pre>\n
}<\/pre>\n<\/div>\n
Another important point to notice here is about filling the Information<\/em> member on IoStatus<\/em> structure that is in the IRP. In those data transfer functions, this field informs IoManager the data amount that was transferred from the application to the driver and vice versa.\u00a0This field directly\u00a0reflects on the fourth parameter of WriteFile() API, which has exactly the same function.\u00a0Once received and validated the parameters, we allocate a node that will receive the buffer.\u00a0Notice that we are allocating in paged memory<\/em>; after all, all our functions will be executed in PASSIVE_LEVEL<\/strong>.\u00a0Although this function is a Dispatch Function, it\u00a0does not mean that it runs in DISPATCH_LEVEL<\/strong>.\u00a0Take it easy, these are very different things.\u00a0Noting…\u00a0“Post about IRQLs and POOL_TYPEs”<\/em>.\u00a0The OnRead() <\/em>function is similar to OnWrite(), so I’ll spare you of putting all code here.<\/p>\n
When my driver is unloaded<\/h3>\n
OnDriverUnload()<\/em> function will be called when the driver is being unloaded.\u00a0Here, in addition to empty the buffer\u00a0list that may have been forgotten in the driver, let’s delete the Symbolic Link and DeviceObject that was created at startup time.\u00a0Simple as that…<\/p>\n
\n
\/****<\/span><\/pre>\n
***     OnDriverUnload<\/span><\/pre>\n
**<\/span><\/pre>\n
**      The party is over, go home, regards for your wife<\/span><\/pre>\n
**      and a kiss in your kids.<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
VOID OnDriverUnload(IN PDRIVER_OBJECT   pDriverObj)<\/pre>\n
{<\/pre>\n
    PLIST_ENTRY     pEntry;<\/pre>\n
    PBUFFER_ENTRY   pBufferEntry;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Say good night<\/span><\/pre>\n
    KdPrint((\"Terminating KernelEcho driver...\\n\"<\/span>));<\/pre>\n
 <\/pre>\n
    \/\/-f--> Here we remove all nodes that weren't read by<\/span><\/pre>\n
    \/\/      the application. That would happen if the application call<\/span><\/pre>\n
    \/\/      WriteFile() but not ReadFile().<\/span><\/pre>\n
    while<\/span>(!IsListEmpty(&g_BufferList))<\/pre>\n
    {<\/pre>\n
        \/\/-f--> Take the first list node.<\/span><\/pre>\n
        pEntry = RemoveHeadList(&g_BufferList);<\/pre>\n
 <\/pre>\n
        \/\/-f--> Get the outer structure from its node address.<\/span><\/pre>\n
        pBufferEntry = CONTAINING_RECORD(pEntry, BUFFER_ENTRY, Entry);<\/pre>\n
 <\/pre>\n
        \/\/-f--> Finally, release the memory used by<\/span><\/pre>\n
        \/\/      this node.<\/span><\/pre>\n
        ExFreePool(pBufferEntry);<\/pre>\n
    }<\/pre>\n
 <\/pre>\n
    \/\/-f--> Deleting DeviceObject and SymbolicLink<\/span><\/pre>\n
    \/\/      created at startup time.<\/span><\/pre>\n
    IoDeleteSymbolicLink(&g_usSymbolicLink);<\/pre>\n
    IoDeleteDevice(pDriverObj->DeviceObject);<\/pre>\n
}<\/pre>\n<\/div>\n
Wow, that horrible mistake! What if the driver is finished while some reading or writing operation is being performed?\u00a0Does a dark future await us and our souls will be damned for eternity?\u00a0Does the Little Mermaid<\/a><\/strong> have something to do with it?<\/strong><\/p>\n
Well, better to let our beliefs aside and focus on the DDK.\u00a0A driver cannot be terminated while there are some references to this device driver.\u00a0Note that this routine has no return so, we cannot tell the system that the driver may or may not be unloaded.\u00a0If an application still has an opened\u00a0handle to any device while you ask to stop it, the system will respond that the driver cannot be terminated.\u00a0In this condition, the OnDriverUnload()<\/em> routine will not be called.\u00a0But otherwise, if nothing prevents the driver from being unloaded and our routine is called, forget it…\u00a0Your driver is already going to driver’s heaven.<\/p>\n
The wonderful world of Userland<\/h3>\n
I will not put all the application\u00a0source code in the post, but all sources are on a file available for downloading.\u00a0I think one thing that’s worth showing here is the syntax of how to get the handle to the device we have created in our sample driver.<\/p>\n
\n
    \/\/-f--> Here we open a handle to the device that<\/span><\/pre>\n
    \/\/      was created by the driver. Remember that our<\/span><\/pre>\n
    \/\/      sample driver must be installed and be working,<\/span><\/pre>\n
    \/\/      in order the call bellow can work correctly.<\/span><\/pre>\n
    hDevice = CreateFile(\"\\\\\\\\.\\\\EchoDevice\"<\/span>,<\/pre>\n
                         GENERIC_ALL,<\/pre>\n
                         0<\/span>,<\/pre>\n
                         NULL,<\/pre>\n
                         OPEN_EXISTING,<\/pre>\n
                         0<\/span>,<\/pre>\n
                         NULL);<\/pre>\n<\/div>\n
Once the handle to the device is obtained, the Read, Write and Close operations will follow exactly as if we were performing the same operations with files. You don’t need to be a Jedi\u00a0master to be able to use these functions.<\/p>\n
\n
    \/\/-f--> It sends the received string to the driver via<\/span><\/pre>\n
    \/\/      WriteFile.<\/span><\/pre>\n
    if<\/span> (!WriteFile(hDevice,<\/pre>\n
                   szBuffer,<\/pre>\n
                   dwBytes,<\/pre>\n
                   &dwBytes,<\/pre>\n
                   NULL))<\/pre>\n<\/div>\n
Installing and testing<\/h3>\n
I have shown in another post<\/a> how to install a driver by hand. However, there are more civilized ways to install a driver. One of them is using the OSR Driver Loader<\/a>, a tool that is offered by OSR to install your driver without rebooting the machine. Actually, this is a very simple procedure to do, but not simple enough to comment about it yet in this post, so let’s use the tool for now.<\/p>\n
After compiling the driver, put a copy of it in the System32\\drivers<\/em> of the victim machine.\u00a0Then run the DriverLoader and fill in the fields as shown in the figure below.<\/p>\n
\"\"<\/div>\n
Then click on Register Service<\/em> to install the new driver and then click on Start Service<\/em> to start the driver.\u00a0Okay, now you can use the test application.\u00a0The application is very simple to use.\u00a0Once started, enter the strings that should be sent to the driver.\u00a0An empty string indicates the end of the strings and then it starts reading the same string queued in the driver.<\/p>\n
Phew! As we have seen, even a driver that does something simple requires a considerable amount of code and many different concepts. I know that some gaps are remained in the post, but I hope I have helped. If you have questions at some points at driver or even at test application, do not hesitate to ask or send your comments. The contacts are very helpful to define the next posts.
\n Have fun!<\/p>\n

<\/p>\n
KernelEcho.zip<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
A few months after my hiring into Open, they asked me to do a participation in a lecture about Secure Code. My part was about stack overflow and how to take advantage of that oversight programmer to break into the program. The major point to note was in addition to programmers, the audience was composed […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-147","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/147","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/comments?post=147"}],"version-history":[{"count":1,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/147\/revisions"}],"predecessor-version":[{"id":148,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/147\/revisions\/148"}],"wp:attachment":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/media?parent=147"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/categories?post=147"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/tags?post=147"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}