ntop/nDPI

Incorrect classification of CS:GO / CS2 & DOTA2 traffic

0xA50C1A1 opened this issue · 7 comments

0xA50C1A1 commented

Describe the bug

A check in the Steam dissector is triggered before a similar check in the CS:GO dissector, so this causes incorrect classification of game traffic.

Steam itself (I mean the app) uses TLS connections in its operation, and the Steam Datagram Relay protocol is used exclusively for game traffic. Btw, this protocol can also be used in non-Valve games.

Expected behavior

I guess it would be nice to create a new ID for the Steam Datagram Relay protocol (e.g. NDPI_PROTOCOL_SDR) and move the CS and DOTA2 detection logic into its sub-protocol dissectors.

Obtained behavior

All traffic (game and service) is currently classified as Steam.

Detected protocols:
	MDNS                 packets: 9             bytes: 1408          flows: 3            
	SSDP                 packets: 66            bytes: 11979         flows: 14           
	Steam                packets: 9206          bytes: 5928355       flows: 63           
	ICMP                 packets: 7             bytes: 1433          flows: 4            
	TLS                  packets: 670           bytes: 227598        flows: 8            
	ICMPV6               packets: 41            bytes: 3510          flows: 7            
	UbuntuONE            packets: 2             bytes: 346           flows: 1            
	QUIC                 packets: 1             bytes: 114           flows: 1            


Protocol statistics:
	Safe                 packets: 670           bytes: 227598        flows: 8            
	Acceptable           packets: 126           bytes: 18790         flows: 30           
	Fun                  packets: 9206          bytes: 5928355       flows: 63

nDPI Environment (please complete the following information):

  • OS name: Ubuntu
  • OS version: 23.04
  • Architecture: x86_64
  • nDPI version or commit hash: latest
  • nDPI compilation flags used: --with-pcre2 --with-nbpf-path=~/PF_RING/userland/nbpf/
  • Attach the config.log file generated after ./configure ran (if you are building from source).

config.log

How to reproduce the reported bug

Reproducible using ndpiReader?

  • The reported bug is reproducible using ndpiReader.

If applicable, the used ndpiReader options:

ndpiReader -i cs2_capture.pcap

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

steam_capture.zip
cs2_capture.zip

0xA50C1A1 commented

@IvanNardi @utoni What do you think about that? I think the Steam and CS:GO dissectors need to be reworked, as the second one simply doesn't work.

The Source Engine dissector is also questionable, as all modern games from Valve now use SDR.

IvanNardi commented

Let me see if I understood it:

  • keep NDPI_PROTOCOL_STEAM for the generic/TLS traffic
  • add NDPI_PROTOCOL_SDR for the realtime traffic. If possible, add two sub-classifications: NDPI_PROTOCOL_CS and NDPI_PROTOCOL_DOTA2

Is that correct? Please, note that I don't know anything about these games...

BTW: reading GIT history, some kind of SDR support has been added by @utoni in 01f384f and in 62bae30

0xA50C1A1 commented

Let me see if I understood it:

* keep `NDPI_PROTOCOL_STEAM` for the generic/TLS traffic

* add `NDPI_PROTOCOL_SDR` for the realtime traffic. If possible, add two sub-classifications: `NDPI_PROTOCOL_CS` and `NDPI_PROTOCOL_DOTA2`

Is that correct? Please, note that I don't know anything about these games...

BTW: reading GIT history, some kind of SDR support has been added by @utoni in 01f384f and in 62bae30

NDPI_PROTOCOL_STEAM protocol id should definitely be kept for things like TLS (most of the traffic), HTTP (a small part) and Steam Remote Play.

For game traffic (i.e. Steam Datagram Relay protocol) I suggest adding a new ID (NDPI_PROTOCOL_SDR) and implementing (if possible) sub-protocol dissectors for various games that use it. DOTA2 and CS are just the most popular games that use this protocol.

  • 👍1
IvanNardi commented

Ok, thanks for the clarification. It is fine for me; @utoni, what do you think?

utoni commented

I agree with @0xA50C1A1.
Dunno why I didn't do that while implementing the SDR dissector. :D

0xA50C1A1 commented

For game traffic (i.e. Steam Datagram Relay protocol) I suggest adding a new ID (NDPI_PROTOCOL_SDR) and implementing (if possible) sub-protocol dissectors for various games that use it. DOTA2 and CS are just the most popular games that use this protocol.

Well, it didn't turn out the way I'd expected. I played a few Counter Strike 2 and Dota 2 matches to capture the traffic and it looks like it only differs by dst port and address (btw, the addresses are from the same /24 subnet).

0xA50C1A1 commented

Well, it didn't turn out the way I'd expected. I played a few Counter Strike 2 and Dota 2 matches to capture the traffic and it looks like it only differs by dst port and address (btw, the addresses are from the same /24 subnet).

It seems that the traffic is encrypted, so there's no way to to detect which game is using the SDR protocol. Ofc it contains some text signatures (like sdping), but it's identical in both cases.

Btw, I've also noticed that in online mode Dota 2 always tries to establish TLS connections with www.dota2.com. Probably the in-game browser is doing it, also it could be an update of guides and builds for heroes.

However, I guess it's worth to add a new ID (or mby replace NDPI_PROTOCOL_CSGO with it) for SDR, even if there's no way to detect the game that uses it.

So, my suggestion is this:

  • Rework the Steam dissector, implementing only detection of Steam service traffic (downloads and Steam Remote Play).
  • Implement a separate Steam Datagram Relay protocol dissector for game traffic.
  • Add NDPI_PROTOCOL_DOTA2 identifier with detection by hostname.

@IvanNardi @utoni so guys, what do you think about it?

  • 👍2