Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Obtaining GET Requests

AndreaSmithAndreaSmith Member Posts: 2

Hello everyone. I am modifying the NDIS 6 filter driver sample. My goal is to parse the network packets so that I can capture GET requests. I have parsed Ethernet, IP and TCP headers inside one MDL and found my GET request in the next MDL. However, I have observed that after the TCP header ends, the payload does not directly come after.

I have also observed that the data length of my NET_BUFFER is nearly 600 when it includes the HTTP request. My question is, is there a way to find the GET request without traversing the MDL chain?

Comments

  • MBond2MBond2 Member Posts: 391

    Your problem is quite a bit harder than just traversing an MDL chain. TCP can split the payload of the higher level protocol into multiple packets on any arbitrary byte boundary. This means that not only could an HTTP GET request be split into multiple packets, but even the G and the ET bytes of GET could be in different packets. You have to reconstruct the entire stream and then do whatever it is that you want with the data. If your activity is read-only, then you can allow the origional packets to be indicated up. If you are planning to modify the data, then you have to prevent them from being indicated up, and then create new 'packets' with your modified data that you can indicate up.

    Also note that most HTTP traffic is TLS encrypted and intercepting that traffic is MUCH more complex

  • AndreaSmithAndreaSmith Member Posts: 2

    I am a bit new to this. My understanding was that after stripping away the headers, the payload would be ordered in MDLs. So are you saying that it was just a coincidence that my GET request was ordered and I should not rely on this notion?

  • Pavel_APavel_A Member Posts: 2,810
    edited October 16

    Well you are not the first naïve developer to subscribe to this sort of project. Just to filter some http requests, not a big deal. Just filter it.
    It is only a top of the iceberg.

  • MBond2MBond2 Member Posts: 391

    It is a deep iceberg. But think about the layers involved. The media could be Cat5, DAC or even WIFI, but it will transmit IPv4 or IPv6 frames. Somehow those frames will be reassembled into a TCP stream. And that virtual piece of paper tape contains the various parts of the HTTP protocol. It happens that most network devices do not fragment frames smaller that 1500 bytes (slightly smaller when VPN exists) and it happens that network stacks generally do not fragment requests from higher levels that can be sent in single TCP segments. That means that is happens that you see the full request together. But you can't be sure except by reconstructing the stream and then parsing it in a protocol aware way. Add TLS and this can get very complex very quickly

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 24 January 2022 Live, Online
Internals & Software Drivers 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online
Developing Minifilters 23 May 2022 Live, Online