1

I used to filter packets into Wireshark with the simple dtls argument as filter. (Data Transport Layer Security which is some UDP TLS protocol)

Now, i wanted to do the same using C# and PcapDOTNet wrapper that uses WinPcap filters. Sadly, i can't find anywhere the equivalent, and dtls is not recognised in the C# app, and so doesn't grab any packet anymore. (Simply it crashes the interpreter since the string is not recognised)

using (PacketCommunicator communicator = selectedDevice.Open(65536, PacketDeviceOpenAttributes.None, 1000))
    {
        using (BerkeleyPacketFilter filter = communicator.CreateFilter("dtls") {
            communicator.SetFilter(filter);
            communicator.ReceivePackets(1, packetHandler);
        }
    }

Is there any equivalent, please ?

EDIT : It looks like dtls is only a DISPLAY filter, and not a CAPTURE one. I could only capture filter by using udp port xx (xx being the port) but since the used ports are always randoms, i can't. So i would be glad to find another filtering workaround if you have one! I prefer only capturing the desired packets, rather than capturing everything then filtering the datas... Wireshark : DTLS

There is only two packets i would like to capture. The one containing The Server Hello Done message or the one containing handshake message (the one with Record Layer) :

Server Hello packet Handshake Message packet

EDIT 2 : Ok, i am close to find what i need, but i need your help. This answer from here must be the solution. tcp[((tcp[12] & 0xf0) >> 2)] = 0x16 is looking for handshake 22, but dtls is udp and not tcp and so the 12 offset might be different. Can anyone help me figure out what would be the correct formula to adapt it for dtls instead of tcp tls ? I tried to use this on wireshark, but the filter is invalid and i don't really know why. If at least you could make it to work into wireshark, i could experiment differents value myself and come back with a final answer. udp[((udp[12] & 0xf0) >> 2)] = 0x16 is not a valid filter on wireshark.

user3916429
  • 562
  • 6
  • 25
  • 1
    Just some additional details: beside of the CCS all other messages here a handshake messages. Those of epoch 0 are not encrpyted and so could be parsed. The one in epoch 1 is encrypted and, without additional data, could not be parsed. Anyway, I'm not sure, why you consider the server hello done and the client's finish (that's the encrypted handshake message) to be most important. – Achim Kraus Aug 18 '21 at 17:29

1 Answers1

1

So, i gave up on the dynamical way of finding the correct position of the data. But this is what i ended with :

using (PacketCommunicator communicator = selectedDevice.Open(65536, PacketDeviceOpenAttributes.None, 1000))
    {
        using (BerkeleyPacketFilter filter = communicator.CreateFilter("udp && ((ether[62:4] = 0x16fefd00) || (ether[42:4] = 0x16fefd00))") {
            communicator.SetFilter(filter);
            communicator.ReceivePackets(1, packetHandler);
        }
    }

bytes[62:4] is the position of 16fefd00 for ipv6 packets, (42 for ipv4). The 16 is for Content type handshake protocol 22 and the following fefd is for DTLS version 1.2. The last two zeros are just because using slice of bytes only works for 1,2 or 4, not 3. So i had to take them in consideration.

This is absolutly not perfect, i know, but for now, it works, since i couldn't find any other workaround yet.

user3916429
  • 562
  • 6
  • 25