| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
There is some overlap between RTP and Raknet detection: give precedence
to RTP logic.
Consequences:
* Raknet might require a little bit more packets for some flows (not a
big issue)
* some very small (1-2 pkts) Raknet flows are not classified (not sure
what do do about that..)
|
|
|
|
|
|
|
|
|
| |
Avoid code duplication between these two protocols.
We remove support for RTCP over TCP; it is quite rare to find this kind
of traffic and, more important, we have never had support for RTP
over TCP: we should try to add both detecion as follow-up.
Fix a message log in the LINE code
|
| |
|
|
|
| |
We need to check all the attributes, to look for any possible metadata
|
| |
|
| |
|
|
|
| |
Add other 2 configuration options
|
|
|
|
|
| |
Restore all unit tests.
Add some configuration knobs.
Fix the endianess.
|
|
|
|
|
|
|
| |
other_address parsing
Added code to ignore invalid STUN realm
Extended JSON output with STUN information
|
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
|
|
|
| |
* fixed invalid read
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
|
|
| |
- Fixed issue with XOR-MAPPED-ADDRESS decoding
- Implemented MAPPED_ADDRESS (IPv4 only)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enable parsing of Mapped-Address attribute for all STUN flows: that
means that STUN classification might require more packets.
Add a configuration knob to enable/disable this feature.
Note that we can have (any) STUN metadata also for flows *not*
classified as STUN (because of DTLS).
Add support for ipv6.
Restore the correct extra dissection logic for Telegram flows.
|
|
|
|
|
| |
The main goal is to have the "real" application (if any; i.e.
Signal/Whatsapp/Telegram/...) always as "application" protocol and not
as "master" one
|
| |
|
|
|
|
|
| |
* unused parameters and functions pollute the code and decrease readability
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
|
|
| |
We are able to demultiplex RTP packets in STUN flows since 3608ab01b, at
least; no need to explicity call the RTP dissector
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Tradeoff between key comparison efficiency (i.e. no `memcmp`) and key
length.
At least in the ipv4 cases, we have no more different entries with the
same key.
|
| |
|
|
|
| |
Tradeoff: performance (i.e. number of packets) vs sub-classification
|
|
|
| |
Same logic already used for Signal/Whatsapp/Line/Facebook/...
|
|
|
|
| |
path (#2320)
|
|
|
|
|
|
|
|
|
| |
* Normalization of host_server_name
The ndpi_hostname_sni_set() function replaces all non-printable
characters with the "?" character and removing whitespace characters
at the end of the line.
* Added conditional hostname normalization.
|
|
|
|
|
| |
When switching to (D)TLS dissector from the STUN one, we need to clear
any flow risks set from the latter (because we don't have anymore
`NDPI_PROTOCOL_STUN` in the classification results)
|
| |
|
| |
|
|
|
|
|
| |
* Remove Google Hangouts/Duo support
* Update protocols.rst
|
|
|
|
|
|
|
| |
Keep looking for RTP packets but remove the monitoring concept.
We will re-introduce a more general concept of "flow in monitoring
state" later.
The function was disabled by default.
Some configuration knobs will be provided when/if #2190 is merged.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a memory leak
```
==97697==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x55a6967cfa7e in malloc (/home/ivan/svnrepos/nDPI/fuzz/fuzz_ndpi_reader+0x701a7e) (BuildId: c7124999fa1ccc54346fa7bd536d8eab88c3ea01)
#1 0x55a696972ab5 in ndpi_malloc /home/ivan/svnrepos/nDPI/src/lib/ndpi_memory.c:60:25
#2 0x55a696972da0 in ndpi_strdup /home/ivan/svnrepos/nDPI/src/lib/ndpi_memory.c:113:13
#3 0x55a696b7658d in processClientServerHello /home/ivan/svnrepos/nDPI/src/lib/protocols/tls.c:2394:46
#4 0x55a696b86e81 in processTLSBlock /home/ivan/svnrepos/nDPI/src/lib/protocols/tls.c:897:5
#5 0x55a696b80649 in ndpi_search_tls_udp /home/ivan/svnrepos/nDPI/src/lib/protocols/tls.c:1262:11
#6 0x55a696b67a57 in ndpi_search_tls_wrapper /home/ivan/svnrepos/nDPI/src/lib/protocols/tls.c:2751:5
#7 0x55a696b67758 in switch_to_tls /home/ivan/svnrepos/nDPI/src/lib/protocols/tls.c:1408:3
#8 0x55a696c47810 in stun_search_again /home/ivan/svnrepos/nDPI/src/lib/protocols/stun.c:422:4
#9 0x55a6968a22af in ndpi_process_extra_packet /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:7247:9
#10 0x55a6968acd6f in ndpi_internal_detection_process_packet /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:7746:5
#11 0x55a6968aba3f in ndpi_detection_process_packet /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:8013:22
#12 0x55a69683d30e in packet_processing /home/ivan/svnrepos/nDPI/fuzz/../example/reader_util.c:1723:31
#13 0x55a69683d30e in ndpi_workflow_process_packet /home/ivan/svnrepos/nDPI/fuzz/../example/reader_util.c:2440:10
#14 0x55a69680f08f in LLVMFuzzerTestOneInput /home/ivan/svnrepos/nDPI/fuzz/fuzz_ndpi_reader.c:135:7
[...]
SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s).
```
Found by oss-fuzzer
See: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64564
|
|
|
| |
See: b08c787fe
|
|
|
|
|
|
| |
Keep demultiplexing STUN/RTP/RTCP packets after DTLS ones.
We might end up processing the session a little longer, because we will
process the STUN/RTP/RTCP packets after the DTLS handshake.
|
|
|
|
|
|
| |
1) Public API/headers in `src/include/` [as it has always been]
2) Private API/headers in `src/lib/`
Try to keep the "ndpi_" prefix only for the public functions
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try to have a faster classification, on first packet; use standard extra
dissection data path for sub-classification, metadata extraction and
monitoring.
STUN caches:
* use the proper confidence value
* lookup into the caches only once per flow, after having found a proper
STUN classification
Add identification of Telegram VoIP calls.
|
|
|
| |
Fix: 2c7fb9179
|
|
|
|
| |
Attribute 0xC057 is defined in the Google public implementation of
webrtc (which is used by Google products but also by other applications)
|
| |
|
| |
|
|
|
|
|
|
| |
Regardless of the name, the removed trace doesn't contain meaningful
Hangout traffic.
Remove last piece of sub-classifiction based only on ip addresses.
|
| |
|
|
|
|
| |
TCP framing is optional
|
| |
|
|
|
|
| |
Look for RTP packets in the STUN sessions.
TODO: tell RTP from RTCP
|