Modifying the WinpkFilter C# Packet filter code question

Home Forums Discussions Support Portal Modifying the WinpkFilter C# Packet filter code question

This topic contains 1 reply, has 1 voice, and was last updated by  stsf 2 years, 7 months ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #5410

    stsf
    Participant

    Hi guys, I have recently downloaded and have been experimenting with the WinpkFilter package and I had a few questions.

    I was able to implement in a separate project the Packet Filter source code in C#.
    Inside the code samples the source and destination IPs, ports, MAC addresses, etc are displayed to the console in the WriteToConsole function.

    It seems to me that the packet itself is “watched for” with the following command:

    if (Ndisapi.ReadPacket(driverPtr, ref request)) /// Line 87 in Program.cs in the packet sniffer code

    Then the buffer is set – which we use to extract information in the WritetoConsole function

    My question is this – what do I have to change in that code in order to allow or deny the packet? It seems to me that the Ndisapi.ReadPacket function reads the packet and “lets it through”, I would like to be able to look at the packet, extract information from it (the same way WriteToConsole does) and let it go through or block it based on that information.

    How can I go about achieving that?

    Thank you in advance. My apologies if this seems like a simple question, I just have not been able to figure this out yet

    #7180

    stsf
    Participant

    Figured the problem out, replying here if anyone encountered the same thing.

    Instead of using the PacketFilter project, I should have used the passthrough project – which looks rather similar – but has some key differences:

    1. The dwFlags loaded in the new adapter mode
    2. The sendPacketToAdapter and sendPacketToMstcp function calls at the end of the loop when processing an individual packet – that’s what I was looking for. I ended up changing “WriteToConsole” to test the packet, and if it failed – i just did not call the functions above.

    Thanks again – you have a great product

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.