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.