| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
|
|
|
| |
Follow-up of f56831336334dddcff00eaf2132e5e0f226f0e32: now the
configuration is for flow-risk, not global
|
|
|
|
|
|
|
| |
int ndpi_add_tcp_fingerprint(struct ndpi_detection_module_struct *ndpi_str,
char *fingerprint, enum operating_system_hint os);
int load_tcp_fingerprint_file_fd(struct ndpi_detection_module_struct *ndpi_str, FILE *fd);
int ndpi_load_tcp_fingerprint_file(struct ndpi_detection_module_struct *ndpi_str, const char *path);
|
|
|
|
|
|
|
| |
Use `NDPI_OBFUSCATED_TRAFFIC` instead; this way, all the obfuscated
traffic is identified via `NDPI_OBFUSCATED_TRAFFIC` flow risk.
Disable fully-encryption detection by default, like all the obfuscation
heuristics.
|
|
|
|
|
|
| |
That flow risk was introduced in 79b89d286605635f15edfe3c21297aaa3b5f3acf
but we can now use the generic `NDPI_TLS_SUSPICIOUS_EXTENSION` instead:
ESNI is quite suspicious nowadays in itself (i.e. even without SNI).
Note that ESNI support has been removed in cae9fb9989838f213eeb857b8fc4bbeac6940049
|
| |
|
|
|
|
| |
For the most common protocols, avoid creating the string message if we
are not going to use it
|
|
|
|
|
|
|
|
| |
This way, the `ndpiReader` output doesn't change if we change the
internal logic about the order we set/check the various flow risks.
Note that the flow risk *list* is already printed by `ndpiReader`
in order.
|
| |
|
|
|
|
| |
Added ndpi_rtp_payload_type2str() API call
|
| |
|
|
|
| |
Close #2524
|
| |
|
|
|
|
| |
Updated (C)
|
| |
|
|
|
|
|
|
|
|
| |
Last step of removing JA3C fingerprint
Remove some duplicate tests: testing with ja4c/ja3s disabled is already
performed by `disable_metadata_and_flowrisks` configuration.
Close:#2551
|
| |
|
| |
|
|
|
|
|
|
| |
ipv6 addresses already containing "::" token shall
not be searched for ":0:" nor patched
Close #1890
|
| |
|
| |
|
| |
|
|
|
| |
Fix: 1bda2bf41
|
|
|
| |
In the same flow, we can have multiple multimedia types
|
|
|
|
| |
Implemented Mikrotik JSON serialization
|
| |
|
|
|
| |
Add fuzzer to test `ndpi_quick_encrypt()` and `ndpi_quick_decrypt()`
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Adde basidc OS detection based on TCP fingerprint
|
|
|
|
| |
Exported domainanme in JSON file (-K JSON)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
u_int ndpi_hex2bin(u_char *out, u_int out_len, u_char* in, u_int in_len);
u_int ndpi_bin2hex(u_char *out, u_int out_len, u_char* in, u_int in_len);
|
|
|
|
|
| |
* Added ndpi_quick_encrypt() ndpi_quick_decrypt(0 APi calls based on AES
* Added aes.c
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```
==6591==ERROR: AddressSanitizer: SEGV on unknown address 0x502000230000 (pc 0x55fbd836a5a0 bp 0x7ffdf4503670 sp 0x7ffdf4502e28 T0)
==6591==The signal is caused by a READ memory access.
#0 0x55fbd836a5a0 in __sanitizer::internal_strlen(char const*) /src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_libc.cpp:176:10
#1 0x55fbd82cfc28 in StrstrCheck(void*, char*, char const*, char const*) /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:579:17
#2 0x55fbd82cfbc2 in strstr /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:598:5
#3 0x55fbd840a04a in ndpi_strrstr /src/ndpi/src/lib/ndpi_utils.c:3471:15
#4 0x55fbd840ba95 in ndpi_get_host_domain /src/ndpi/src/lib/ndpi_domains.c:149:9
#5 0x55fbd83ef751 in ndpi_check_dga_name /src/ndpi/src/lib/ndpi_main.c:10748:17
```
Found by oss-fuzz
|
|
|
|
| |
Fixed bug in ndpi_get_host_domain
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on the paper: "OpenVPN is Open to VPN Fingerprinting"
See: https://www.usenix.org/conference/usenixsecurity22/presentation/xue-diwen
Basic idea:
* the distribution of the first byte of the messages (i.e. the distribution
of the op-codes) is quite unique
* this fingerprint might be still detectable even if the OpenVPN packets are
somehow fully encrypted/obfuscated
The heuristic is disabled by default.
|
| |
|
|
|
|
|
| |
(#2541)
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|