aboutsummaryrefslogtreecommitdiff
path: root/tests/cfgs/default/pcap
Commit message (Collapse)AuthorAge
...
* Add Ethernet Global Data support (#2437)Vladimir Gavrilov2024-05-11
|
* Remove Vevo support (#2436)Vladimir Gavrilov2024-05-11
| | | Co-authored-by: Ivan Nardi <12729895+IvanNardi@users.noreply.github.com>
* Viber: add detection of voip calls and avoid false positives (#2434)Ivan Nardi2024-05-11
|
* Raknet/RTP: avoid Raknet false positives and harden RTP heuristic (#2427)Ivan Nardi2024-05-09
| | | | | | | | | 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..)
* Protobuf: fix false positives (#2428)Ivan Nardi2024-05-09
|
* Add support for Mastodon, Bluesky and (FB-)Threads (#2418)Ivan Nardi2024-05-06
|
* DTLS: add support for Alert message type (similar to TLS) (#2406)Ivan Nardi2024-04-25
|
* Add Adobe Connect support (#2407)0x41CEA552024-04-24
|
* Remove PPStream protocol and add iQIYI (#2403)0x41CEA552024-04-23
| | | | | | P2P video player PPStream was discontinued shortly after the purchase of PPS.tv by Baidu (iQIYI) on 2013 (see https://www.techinasia.com/report-baidu-acquires-video-rival-pps) So we remove the old `NDPI_PROTOCOL_PPSTREAM` logic and add `NDPI_PROTOCOL_IQIYI` id to handle all the iQIYI traffic, which is basically video streaming traffic. A video hosting service, called PPS.tv, is still offered by the same company: for the time being we classified both services with the same protocol id.
* Add BFCP protocol support (#2401)0x41CEA552024-04-23
|
* Remove obsolete protocols: tuenty, tvuplayer and kontiki (#2398)0x41CEA552024-04-19
|
* Add KNXnet/IP protocol support (#2397)0x41CEA552024-04-19
| | | | | * Add KNXnet/IP protocol support * Improve KNXnet/IP over TCP detection
* STUN: add support for ipv6 in some metadata (#2389)Ivan Nardi2024-04-13
|
* STUN: fix boundary checks on attribute list parsing (#2387)Ivan Nardi2024-04-12
| | | | | Restore all unit tests. Add some configuration knobs. Fix the endianess.
* Implemented STUN peer_address, relayed_address, response_origin, ↵Luca Deri2024-04-12
| | | | | | | other_address parsing Added code to ignore invalid STUN realm Extended JSON output with STUN information
* Add Label Distribution Protocol support (#2385)Vladimir Gavrilov2024-04-12
| | | | | | | * Add Label Distribution Protocol support * Fix typo * Update unit test results
* Add The Elder Scrolls Online support (#2376)Vladimir Gavrilov2024-04-10
| | | | | | | | | | | * Add The Elder Scrolls Online support * Use ndpi_memmem instead of memmem from libc * Add protocol description * Change selection bitmask to V4_V6 * Update protocols.rst
* Add Shellscript risk detection. (#2375)Toni2024-04-10
| | | Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Add ELF risk detection (detect transmitted linux executables). (#2373)Toni2024-04-06
| | | Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Add PE32/PE32+ risk detection (detect transmitted windows executables). (#2312)Toni2024-04-05
| | | Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Added binary data transfer risk alertLuca2024-04-03
|
* Improve LoL: Wild Rift detection (#2359)Vladimir Gavrilov2024-03-28
|
* Add LoL: Wild Rift detection (#2356)Vladimir Gavrilov2024-03-26
|
* Add more TencentGames signatures (#2354)Vladimir Gavrilov2024-03-21
|
* Improve TencentGames detection (#2353)Vladimir Gavrilov2024-03-20
| | | | | * Improve TencentGames detection * Add more signatures
* STUN: dissection of TURN Channel DataNardi Ivan2024-03-20
|
* Add FLUTE protocol dissector (#2351)Vladimir Gavrilov2024-03-19
| | | | | * Add FLUTE protocol dissector * Add flute.c to MSVC project
* Add PFCP protocol dissector (#2342)Vladimir Gavrilov2024-03-13
|
* Add Path of Exile protocol dissector (#2337)Vladimir Gavrilov2024-03-06
| | | | | * Add Path of Exile protocol dissector * Update protocols.rst
* ahocorasick: improve matching with subdomains (#2331)Ivan Nardi2024-03-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The basic idea is to have the following logic: * pattern "DOMAIN" matches the domain itself (i.e exact match) *and* any subdomains (i.e. "ANYTHING.DOMAIN") * pattern "DOMAIN." matches *also* any strings for which is a prefix [please, note that this kind of match is handy but it is quite dangerous...] * pattern "-DOMAIN" matches *also* any strings for which is a postfix Examples: * pattern "wikipedia.it": * "wikipiedia.it" -> OK * "foo.wikipedia.it -> OK * "foowikipedia.it -> NO MATCH * "wikipedia.it.com -> NO MATCH * pattern "wikipedia.": * "wikipedia.it" -> OK * "foo.wikipedia.it -> OK * "foowikipedia.it -> NO MATCH * "wikipedia.it.com -> OK * pattern "-wikipedia.it": * "wikipedia.it" -> NO MATCH * "foo.wikipedia.it -> NO MATCH * "0001-wikipedia.it -> OK * "foo.0001-wikipedia.it -> OK Bottom line: * exact match * prefix with "." (always, implicit) * prefix with "-" (only if esplicitly set) * postfix with "." (only if esplicitly set) That means that the patterns cannot start with '.' anymore. Close #2330
* Add NetEase Games detection support (#2335)Vladimir Gavrilov2024-03-05
|
* Add Naraka Bladepoint detection support (#2334)Vladimir Gavrilov2024-03-04
|
* Add BFD protocol dissector (#2332)Vladimir Gavrilov2024-02-29
|
* Telegram: improve identificationNardi Ivan2024-02-26
| | | | | | | | | | | | | | | | | Follow up of 31c706c3dbbf0afc4c8e0a6d0bb6f20796296549 and 75485e177ccc4fafcc62dd46c6917d5b735cf7d2. Allow fast classification by ip, but give time to other dissectors to kick in (for example, the TLS code for the Telegram Web flows). Even if we don't classify it anymore at the very first packet (i.e. SYN) we fully classify Telegram traffic at the first packet with payload, as *any* other protocol. This way, we always have the proper category, the proper confidence for the UDP flows and we don't overwrite previous classifications (TLS or ICMP) Remove old and stale identification logic for TCP flows
* Add DLEP protocol dissector (#2326)Vladimir Gavrilov2024-02-20
|
* Add identification of Huawei generic and cloud traffic (#2325)Ivan Nardi2024-02-20
|
* Add ANSI C12.22 protocol dissector (#2317)Vladimir Gavrilov2024-02-15
| | | | | * Add ANSI C12.22 protocol dissector * Add UDP sample
* Skype: remove old detection logic (#1954)Ivan Nardi2024-02-12
| | | | | | | Skype has been using standard protocols (STUN/ICE or TLS) for a long, long time, now. Long gone are the days of Skype as a distribuited protocol. See: #2166
* reader_util: fix GRE detunneling (#2314)Ivan Nardi2024-02-10
|
* fuzz: improve fuzzing coverage (#2309)Ivan Nardi2024-02-09
|
* Add detection of Gaijin Entertainment games (#2311)Vladimir Gavrilov2024-02-09
| | | | | | | | | * Add detection of Gaijin Entertainment games * Short NDPI_PROTOCOL_GAIJINENTERTAINMENT to NDPI_PROTOCOL_GAIJIN * Add default UDP port for Gaijin Entertainment games * Remove NDPI_PROTOCOL_CROSSOUT protocol id
* Add TencentGames protocol dissector (#2306)Vladimir Gavrilov2024-02-08
|
* Add Gearman protocol dissector (#2297)Vladimir Gavrilov2024-02-01
|
* Implemented CIP I/O (UDP version of the CIP protocol), Common Industrial ↵Luca Deri2024-01-29
| | | | protocol
* Fix RESP detection (#2289)Vladimir Gavrilov2024-01-27
| | | | | * Rename redis_net.c to resp.c * Fix RESP detection
* Add Raft protocol dissector. (#2286)Toni2024-01-25
| | | Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Improve MySQL detection (#2279)Vladimir Gavrilov2024-01-25
| | | | | * Improve MySQL detection * Update copyright
* Add Radmin protocol dissector (#2283)Vladimir Gavrilov2024-01-25
| | | | | * Add Radmin protocol dissector * Update test results
* fuzz: extend fuzzing coverage (#2281)Ivan Nardi2024-01-24
|
* QUIC: fix decryption with CH fragments with different Destination CID (#2278)Ivan Nardi2024-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QUIC decryption fails when the Client Hello is split into multiple UDP packets and these packets have different Destination Connection IDs (because the server told the client to switch to a different CID; see RFC 9000 7.2) ``` The Destination Connection ID field from the first Initial packet sent by a client is used to determine packet protection keys for Initial packets. [..] Upon first receiving an Initial or Retry packet from the server, the client uses the Source Connection ID supplied by the server as the Destination Connection ID for subsequent packets ``` From a logical point of view, the ciphers used for decryption should be initialized only once, with the first Initial pkt sent by the client and kept for later usage with the following packets (if any). However it seems that we can safely initialize them at each packet, if we keep using the DCID of the **first** packet sent by the client. Keep initializing the ciphers at each packet greatly simplifie this patch. This issue has been undetected for so long because: * in the vast majority of the cases we only decrypt one packet per flow; * the available traces with the Client Hello split into multiple packets (i.e. cases where we need to decrypt at least two packets per flow) were created in a simple test environment to simulate Post-Quantum handshake, and in that scenario the client sent all the packets (with the same DCID) before any reply from the server. However, in the last months all major browsers started supporting PQ key, so it is now common to have split CH in real traffic. Please note that in the attached example, the CH is split into 2 (in-order) fragments (in different UDP packets) and the second one in turn is divided into 9 (out-of-order) CRYPTO frames; the reassembler code works out-of-the-box even in this (new) scenario.
Powered by cgit, Themed by Ted Yin.