Wrong classification of DCERPC PCAP data

[ronygut]

Describe the bug

NDP failed to decode DCERPC PCAP data

Expected behavior

Classify the PCAP as DCERPC.

Obtained behavior

Classify as Unknown

nDPI Environment (please complete the following information):

• Ubuntu 22.04
• OS22.04
• Architecture: amd64
• nDPI 4.14

run nftflow_pcap or ndpiReader with the attached PCAP file

Reproducible using ndpiReader?

./ndpiReader -i /home/ubuntu/dcerpc_drs_op.pcap

---

• NOTE: This is demo app to show some nDPI features.
• In this demo we have implemented only some basic features
• just to show you what you can do with the library. Feel
• free to extend it and send us the patches for inclusion

---

Using nDPI (4.14.0-5235-f2a9087) [1 thread(s)] Using libgcrypt version 1.8.6internal Reading packets from pcap file /home/ubuntu/dcerpc_drs_op.pcap... Running thread 0...

nDPI Memory statistics: nDPI Memory (once): 42.82 KB Flow Memory (per flow): 1.15 KB Actual Memory: 11.06 MB Peak Memory: 11.06 MB Setup Time: 40 msec Packet Processing Time: 0 msec

Traffic statistics: Ethernet bytes: 6161 (includes ethernet CRC/IFC/trailer) Discarded bytes: 0 IP packets: 19 of 19 packets total IP bytes: 5705 (avg pkt size 300 bytes) Unique flows: 1 TCP Packets: 19 UDP Packets: 0 VLAN Packets: 0 MPLS Packets: 0 PPPoE Packets: 0 Fragmented Packets: 0 Max Packet size: 1280 Packet Len < 64: 5 Packet Len 64-128: 1 Packet Len 128-256: 9 Packet Len 256-1024: 2 Packet Len 1024-1500: 2 Packet Len > 1500: 0 nDPI throughput: 27.38 K pps / 67.73 Mb/sec Analysis begin: 20/Dec/2012 21:19:59 Analysis end: 20/Dec/2012 21:20:00 Traffic throughput: 41.77 pps / 105.81 Kb/sec Traffic duration: 0.455 sec DPI Packets (TCP): 16 (16.00 pkts/flow) Confidence: Unknown 1 (flows)

Detected protocols: Unknown packets: 19 bytes: 5705 flows: 1

Protocol statistics: Unrated packets: 19 bytes: 5705 flows: 1

Risk stats [found 1 (100.0 %) flows with risks]: Susp Entropy 1 [100.0 %]

    NOTE: as one flow can have multiple risks set, the sum of the
          last column can exceed the number of flows with risks.

If your bug is reproducible using a pcap, please attach a pcap file (or a valid link to download it)

Please remove the txt extension to get the PCAP

dcerpc_drs_oppcap.txt

[IvanNardi]

I ack the issue: there is no support for fragmented DCERPC messages

[ronygut]

@IvanNardi , what exactly do you mean by fragmented DCERPC messages? I think that most of the DCERPC messages will be fragmented. I have another PCAP (dcerpc_netlog_op) that is also fragmented and you are classifying it as DCERPC. How come this is classified correctly and the first PCAP is not? Both has fragmented DCERPC messages.

dcerpc_netlog_op.pcap.txt

[IvanNardi]

I am talking about fragmentation at TCP layer. In the first pcap, the first message is split among packets 4, 5 and 7 --> no detection In the last pcap, the first message is entirely transported by pkt 4 --> detection You can check that also with Wireshark

[ronygut]

OK. I can see that. Are you going to support it? It is very important for Cyber classification.

[utoni]

Are you going to support it?

That requires a IPv4 / TCP reassemble component for nDPI, which is currently not globally implemented. Only some dissectors i.e. TLS support reassembling TCP fragments. But, I agree, that every (TCP) dissector should have access to a global reassambler. It will also require more memory and more CPU, so it should be an optional thing.