Obtaining GET Requests

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?

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

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?

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.

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