| Commit message (Collapse) | Author | Age |
... | |
|
|
|
| |
shouldd not be mixed
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The check for grease was too broad and filtered some valid values.
In particular, the value 257 was skipped because it matched the previous check.
This has been discovered while parsing tests/pcap/443-firefox.pcap
expected ja3:
771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-51-57-47-53-10,0-23-65281-10-11-35-16-5-51-43-13-45-28-21,29-23-24-25-256-257,0
previously generated ja3:
771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-51-57-47-53-10,0-23-65281-10-11-35-16-5-51-43-13-45-28-21,29-23-24-25-256,0
Signed-off-by: Patrick Havelange <patrick.havelange_ext@softathome.com>
|
| |
|
| |
|
|
|
|
|
|
|
| |
Detected by oss-fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26880
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26906
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43782
https://oss-fuzz.com/testcase-detail/6334089358082048
|
|
|
|
|
| |
Detected by oss-fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43754
https://oss-fuzz.com/testcase-detail/5329842395021312
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* build: update m4/ax_pthread.m4 from serial 23 -> serial 31
Update ax_pthread.m4 to the latest version from the autoconf-archive
project.
Signed-off-by: Sam James <sam@gentoo.org>
* build: properly detect AR, CC, RANLIB
It's necessary to be able to override choice of AR/CC/RANLIB and other toolchain
variables/tools for cross-compilation, testing with other toolchains, and
to ensure the compiler chosen by the user is actually used for the build.
Previously, GNU_PREFIX was kind-of used for this but this isn't a standard
variable (at all) and it wasn't applied consistently anyway.
We now use the standard autoconf mechanisms for finding these tools.
(RANLIB is already covered by LT_INIT.)
Signed-off-by: Sam James <sam@gentoo.org>
* build: use $(MAKE)
This ensures that parallel make works correctly, as otherwise, a fresh
make job will be started without the jobserver fd, and hence
not know about its parent, forcing -j1.
* build: respect CPPFLAGS, LDFLAGS
- CPPFLAGS is for the C preprocessor (usually for setting defines)
- LDFLAGS should be placed before objects for certain flags to work
(e.g. -Wl,--as-needed)
Signed-off-by: Sam James <sam@gentoo.org>
Co-authored-by: Luca Deri <lucaderi@users.noreply.github.com>
|
|
|
|
|
|
|
| |
Detected by oss-fuzz
See: https://oss-fuzz.com/testcase-detail/6730505580576768
Fix a function prototype
Update a unit test results
|
| |
|
| |
|
|
|
|
| |
via a new (internal) function named ndpi_add_domain_risk_exceptions()
|
|
|
|
| |
Detected by oss-fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43705
|
|
|
|
|
| |
Fix: 20b5f6d7
Detected by oss-fux:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43700
|
|
|
|
|
|
|
|
| |
These dissectors have *never* been triggered because their registration
functions use the wrong parameter/bitmask.
Diameter code is buggy since the origianl commit (1d108234), while
XBox code since 5266c726.
Fix some false positives in Xbox code.
|
| |
|
|
|
|
| |
Detected by oss-fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43677
|
|
|
|
| |
Detected by oss-fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43664
|
| |
|
|
|
| |
Follow-up of 7cba34a1
|
|
|
|
|
|
|
|
|
|
|
| |
self-signed certificates
This allows to avoid triggering alerts for trusted albeit private certificate issuers.
Extended the example/protos.txt with the new syntax for specifying trusted issueDN.
Example:
trusted_issuer_dn:"CN=813845657003339838, O=Code42, OU=TEST, ST=MN, C=US"
|
| |
|
| |
|
| |
|
|
|
| |
Close #1397
|
|
|
|
|
|
|
| |
Found by oss-fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40269
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41432
Fix fuzz compilation (follow-up of f5545a80)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reported by oss-fuzz:
```
==685288==ERROR: AddressSanitizer: SEGV on unknown address 0x61a100000687 (pc 0x0000005aba64 bp 0x7ffe3f29f510 sp 0x7ffe3f29f400 T0)
==685288==The signal is caused by a READ memory access.
SCARINESS: 20 (wild-addr-read)
#0 0x5aba64 in quic_len ndpi/src/lib/protocols/quic.c:203:12
#1 0x5aba64 in decrypt_initial_packet ndpi/src/lib/protocols/quic.c:993:16
#2 0x5aba64 in get_clear_payload ndpi/src/lib/protocols/quic.c:1302:21
#3 0x5aba64 in ndpi_search_quic ndpi/src/lib/protocols/quic.c:1658:19
#4 0x579f00 in check_ndpi_detection_func ndpi/src/lib/ndpi_main.c:4683:6
#5 0x57abe6 in ndpi_check_flow_func ndpi/src/lib/ndpi_main.c:0
#6 0x583b2c in ndpi_detection_process_packet ndpi/src/lib/ndpi_main.c:5545:15
#7 0x55e75e in LLVMFuzzerTestOneInput ndpi/fuzz/fuzz_process_packet.c:30:3
[...]
```
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a general rule, the higher the confidence value, the higher the
"reliability/precision" of the classification.
In other words, this new field provides an hint about "how" the flow
classification has been obtained.
For example, the application may want to ignore classification "by-port"
(they are not real DPI classifications, after all) or give a second
glance at flows classified via LRU caches (because of false positives).
Setting only one value for the confidence field is a bit tricky: more
work is probably needed in the next future to tweak/fix/improve the logic.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
named NDPI_POSSIBLE_EXPLOIT
|
|
|
|
|
|
|
| |
See:
https://www.apple.com/privacy/docs/iCloud_Private_Relay_Overview_Dec2021.PDF
TODO: an up-to-date list of egress IP ranges is publicly available. Can
we use it somehow?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove some unused fields and re-organize other ones.
In particular:
* Update the parameters of `ndpi_ssl_version2str()` function
* Zattoo, Thunder: these timestamps aren't really used.
* Ftp/mail: these protocols are dissected only over TCP.
* Attention must be paid to TLS.Bittorrent flows to avoid invalid
read/write to `flow->protos.bittorrent.hash` field.
This is the last(?) commit of a long series (see 22241a1d, 227e586e,
730c2360, a8ffcd8b) aiming to reduce library memory consumption.
Before, at nDPI 4.0 (more precisly, at a6b10cf7, because memory stats
were wrong until that commit):
```
nDPI Memory statistics:
nDPI Memory (once): 221.15 KB
Flow Memory (per flow): 2.94 KB
```
Now:
```
nDPI Memory statistics:
nDPI Memory (once): 231.71 KB
Flow Memory (per flow): 1008 B <---------
```
i.e. memory usage per flow has been reduced by 66%, dropping below the
psychological threshold of 1 KB.
To further reduce this value, we probably need to look into #1279:
let's fight this battle another day.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve Microsoft, GMail, Likee, Whatsapp, DisneyPlus and Tiktok
detection.
Add Vimeo, Fuze, Alibaba and Firebase Crashlytics detection.
Try to differentiate between Messenger/Signal standard flows (i.e chat)
and their VOIP (video)calls (like we already do for Whatsapp and
Snapchat).
Add a partial list of some ADS/Tracking stuff.
Fix Cassandra, Radius and GTP false positives.
Fix DNS, Syslog and SIP false negatives.
Improve GTP (sub)classification: differentiate among GTP-U, GTP_C and
GTP_PRIME.
Fix 3 LGTM warnings.
|
| |
|
| |
|
| |
|
|
|
| |
Credits to @viniciussn (see #1312)
|
| |
|
| |
|