Feature/fake mp4 structural detection

[RajaMuhammadAwais]

Please sign (check) the below before submitting the Pull Request:

• I have signed the ntop Contributor License Agreement at https://github.com/ntop/legal/blob/main/individual-contributor-licence-agreement.md
• I have read the contributing guidelines at https://github.com/ntop/nDPI/blob/dev/CONTRIBUTING.md
• I have updated the documentation (in doc/) to reflect the changes made (if applicable)

Link to the related issue:

Describe changes:

Generic Fake-MP4 Structural Detection with Memory-Safety Hardening

Overview

This pull request adds a conservative, generic detector for suspicious HTTP responses that resemble ISO Base Media File Format (ISO-BMFF) / MP4 containers but contain an unusually large private uuid box instead of normal playable media data.

The detection is based on file-structure evidence only. It does not depend on domains, IP addresses, filenames, User-Agent strings, malware names, campaign identifiers, hard-coded UUID values, PowerShell content, or other campaign-specific indicators.

The implementation is inspired by the public Censys research on fake MP4 files being used as payload carriers:

:contentReference[oaicite:0]{index=0}

The detector reports the existing NDPI_HTTP_SUSPICIOUS_CONTENT risk because the observed content is structurally inconsistent with a normal playable MP4 file. It does not classify the response as malware by itself.

Detection Conditions

The HTTP response is considered suspicious only when all of the following structural conditions are satisfied:

1. The first top-level ISO-BMFF box is ftyp.
2. At least one private uuid box is present.
3. The declared UUID payload is at least 1 MiB.
4. The UUID payload accounts for at least 90% of the parsed response-body box bytes.
5. A valid, bounded HTTP Content-Length header is present.
6. The response body has been received up to the declared Content-Length.
7. No top-level moov or mdat box has been observed.
8. The parser has not encountered malformed or unsafe box declarations.

This combination is intended to distinguish a suspicious carrier-like structure from an ordinary MP4 file containing small UUID metadata.

Streaming and Fragmentation Support

The parser processes the response body incrementally across TCP packets.

It supports:

• Fragmented HTTP response headers.
• Fragmented MP4 box headers.
• Fragmented extended-size box headers.
• Fragmented ftyp, uuid, and other top-level boxes.
• Response body continuation packets after the initial HTTP response.
• Large UUID payloads without buffering the payload in flow state.

Only an incomplete 8-byte or 16-byte MP4 box header is temporarily retained. Box payloads are skipped according to their declared size and are never copied, decrypted, executed, or stored.

This keeps memory usage independent of the carrier payload size.

Content-Length Validation

The detector uses Content-Length only when it can be parsed safely and unambiguously.

The following cases do not generate the structural alert:

• Missing Content-Length.
• Malformed values.
• Zero-length values.
• Values larger than the supported parser limit.
• Duplicate or ambiguous valid Content-Length headers.
• Content-Length/body-size inconsistencies.

This is intentional. Without a reliable total body size, a file-level dominance ratio would be unreliable and could produce false positives.

Chunked or unknown-length responses are therefore conservatively ignored by this specific heuristic.

Parser Resource Limits

The MP4 parser uses bounded arithmetic and resource limits:

• Maximum cumulative declared top-level box budget: 64 MiB.
• Maximum individual box declaration: bounded by the same parser budget.
• Checked additions for 64-bit counters.
• No payload allocation based on attacker-controlled box sizes.
• Parsing stops safely when malformed or unsafe input is encountered.

The cumulative budget prevents an attacker from bypassing a per-box limit by sending many individually valid but collectively excessive boxes.

Memory-Safety Fixes

Additional research-based hardening was added after reviewing the original implementation.

Extended-Size Box Underflow

ISO-BMFF allows a 16-byte extended-size box header when the normal 32-bit size field is 1.

Previously, a malformed extended-size declaration smaller than the required 16-byte header could result in:

box_size - header_len

# NOTE

The MP4 parser is intentionally scoped to the HTTP dissector because it is entered only after HTTP metadata identifies a potential MP4 response. The parser maintains bounded, flow-local state under flow->http; it does not allocate unbounded buffers or create independent flow state. If preferred, the ISO-BMFF helper implementation can be split into http_mp4.c in a follow-up cleanup without changing the state model or detection behavior.

[IvanNardi]

@RajaMuhammadAwais, could you rebase please?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud