This local reader uses a conservative, dependency-free Markdown renderer. Citation markers from the original report are preserved as source pills; equations and Mermaid diagrams remain text. Use the raw Markdown for exact source fidelity.
Submitted research preserved. This Markdown body is byte-identical to the user-supplied report. The continuation repository also stores the exact durable copy at docs/long-term-memory/research/submitted-reports/document-container-forensics.md; UAIX memory points to that document rather than duplicating its full body.
Release Identifier: 2026-08-25-document-forensics-1Target Environment: MachineTradecraft.com Continuation Repository (1.0.16 / 2026-08-25-result-provenance-1) Resource Pathways: /document-container-forensics/, /research/document-container-forensics/, /labs/documents/container-map/
Discovery and Visitor-Resource Metadata
The following technical abstract, terminology expansions, and operational records document the repository deployment for the current release suite. The integration expands existing document and image guides through descriptive cross-links, establishing a foundational architectural view of file formats as complex, attackable containers. Table 1: Site Expansion and Glossary Definitions
| Term | Definition |
|---|---|
| Container Format | A file specification designed to encapsulate multiple heterogeneous data streams, hierarchical metadata, and structural relationships within a single discrete file boundary. |
| Media Type | An Internet Assigned Numbers Authority (IANA) standard identifier (MIME type) used to define the nature and format of a document, often utilized in heuristic content sniffing. |
| Local Header | Within the ZIP specification, the metadata block immediately preceding compressed file data, storing redundant metadata such as filenames and CRCs. |
| Central Directory | The index structure positioned near the end of a ZIP file, containing headers that point to the offsets of all localized files within the archive. |
| Package Relationship | In the Open Packaging Conventions (OPC) used by OOXML, the XML definitions (\_rels) that map hierarchical parts to one another or to external resources. |
| Incremental Update | A Portable Document Format (PDF) mechanism permitting document modification by appending new object data and cross-reference structures to the end of the file without altering original bytes. |
| Ancillary Chunk | Optional, non-critical data blocks within a PNG file (e.g., tEXt, eXIf) that carry metadata or profile information without affecting the primary image rendering process. |
| XMP | Extensible Metadata Platform; an XML-based metadata standard utilized across PDFs, JPEGs, and PNGs to embed standardized descriptive and rights information. |
| EXIF | Exchangeable Image File Format; a metadata standard governing technical capture data, orientation, and geographic coordinates within image files. |
| Parser Differential | A critical security vulnerability arising when two distinct parsing engines interpret the same ambiguous or malformed file structure in fundamentally different ways. |
Answer-First Explanation: The Insufficiency of File Extensions
The foundational principle of modern document forensics is that files are not flat, uniform blocks of contiguous data; they are highly structured, nested containers. An overarching vulnerability in enterprise security, digital forensics, and content management systems is the reliance on file extensions (e.g., .docx, .pdf, .png) to dictate handling, inspection, and trust boundaries. Filename extensions are superficial labels managed by the operating system shell, easily manipulated by adversaries, and completely disconnected from the internal byte structure of the payload. Modern document formats act as layered, machine-readable packages, storing varying representations of content within a single wrapper. What a user observes rendered on a screen represents merely one interpretation of the container's contents. Beneath the visible presentation layer lies a complex topology of package relationships, compressed object streams, metadata chunks, cross-reference tables, embedded external files, and execution triggers. Because standard software applications prioritize usability and error recovery over strict specification adherence, parser differentials inevitably arise1. These differentials create semantic gaps, allowing malicious actors to construct files that bypass security inspections while executing maliciously in target applications. Therefore, inert structural inspection is paramount; executing or rendering active features fundamentally alters the forensic baseline and exposes the inspecting environment to exploitation.
File Identification, Magic Bytes, and Boundary Analysis
Authentic file identification relies on internal structural signatures, commonly known as "magic bytes," rather than file extensions. A PDF document must begin with the %PDF- signature (hexadecimal 25 50 44 46 2D), while a ZIP archive—the basis for Office Open XML (OOXML) and Java Archives (JAR)—is identified by the PK signature (50 4B 03 04 for Local File Headers)2. The Internet Assigned Numbers Authority (IANA) maintains the official registry of Media Types (MIME types), which define the expected format of content transmitted across network boundaries. When web browsers or operating systems encounter missing or ambiguous MIME types, they engage in content sniffing. This heuristic approach involves inspecting the first 256 bytes of a file to deduce its format4. Content sniffing introduces significant vulnerabilities. An attacker can create a polyglot file—a single payload that satisfies the specifications of multiple formats simultaneously—by manipulating magic bytes and internal structures. For instance, an HTML payload can be disguised as a JPEG image. If an application validates only the extension, the browser may sniff the HTML content and execute cross-site scripting (XSS) payloads when the image is loaded directly. A rigid defense requires validating that the magic bytes, the declared MIME type, the filename extension, and the internal chunk structures all align identically.
The ZIP Format and Archive Ambiguity
The ZIP file format, originally specified by PKWARE in 1989, forms the bedrock of modern document containers1. Despite its ubiquity, the ZIP specification contains vast areas of imprecise documentation, leading to widespread structural ambiguity. A standard ZIP file consists of three primary components. The Local File Entries contain the Local File Header (LFH) and the compressed file data. The Central Directory is a sequence of Central Directory Headers (CDH) containing metadata for every file in the archive. Finally, the End of Central Directory Record (EOCDR) is located at the end of the file, providing the offset and size of the Central Directory1. The format inherently duplicates metadata, storing filenames, compression methods, and CRC32 checksums in both the LFH and the CDH. Parsers typically start by locating the EOCDR (identified by 50 4b 05 06), iterating through the CDH, and extracting files based on CDH pointers1. However, because redundant metadata exists, parsers must independently choose which header to trust if discrepancies arise. Systematic differential fuzzing research, utilizing tools like ZIPDIFF, has revealed that almost all pairs of ZIP parsers are inconsistent, exposing 14 distinct types of parsing ambiguities across 50 parsers in 19 programming languages5. Table 2: ZIP Parsing Ambiguities and Exploitation Vectors
| Category | Ambiguity Type | Mechanism & Consequence |
|---|---|---|
| Redundant Metadata | Compression Method Confusion | LFH and CDH report different compression methods. A security scanner might read a 'Store' method, while the execution target reads 'Deflate'6. |
| File Size Confusion | Discrepancies between LFH and CDH sizes cause parsers to truncate or over-read data, masking payloads6. | |
| Filename Confusion | Parsers extract to different paths depending on whether they trust the LFH, CDH, or Info-ZIP Unicode path extra field6. | |
| Fake Directory | Malformed attributes mask executable files as harmless directories to bypass extension filters. | |
| Fake Encryption | Encryption flags in headers disagree, causing scanners to skip the file while end-user software prompts for a password or ignores the flag6. | |
| File Path Processing | Duplicate Files | Two files share the same path within the archive. Scanners evaluate the first; execution engines extract and run the second1. |
| Invalid Characters & Canonicalization | Directory traversal (../) or null-byte injections are handled inconsistently, leading to arbitrary file writes outside the intended extraction directory. | |
| Positioning | Streaming Parsing vs. EOCDR Selection | The presence of multiple EOCDR signatures causes top-down scanners and bottom-up extractors to parse entirely different archives from the same file5. |
| CD & LFH Offset Confusion | Modified offsets point to overlapping or hidden data chunks, deceiving parsers about the true layout of the container. |
Non-Recursive Decompression Bombs
Historically, decompression bombs relied on recursion (e.g., 42.zip), nesting ZIPs within ZIPs to bypass the DEFLATE limit of 1032:1 compression7. Modern non-recursive ZIP bombs achieve massive expansion (e.g., transforming a 10 MB file into 281 TB of data) in a single layer8. This is achieved by overlapping files inside the ZIP container. Multiple CDHs point to a single highly compressed "kernel" of data. To satisfy parsers that require distinct Local File Headers for each entry, the non-recursive bomb uses uncompressed DEFLATE block headers to "quote" the preceding LFHs, making them appear as part of a single DEFLATE stream terminating in the kernel7. Structural inspection must evaluate compression ratios, handle ZIP64 boundary limits, and verify that CDH offsets do not point to overlapping file extents.
Office Open XML (OOXML) Container Forensics
The ECMA-376 and ISO/IEC 29500 standards define OOXML (utilized in .docx, .xlsx, .pptx) as an implementation of Open Packaging Conventions (OPC)2. An OOXML document is essentially a ZIP archive governing a virtual file system of XML files, properties, and embedded media11. The OPC architecture strictly segregates content from package topology. At the root of the package resides the \[Content\_Types\].xml file, which dictates the MIME media types for all parts within the container. Applications rely entirely on this index, rather than file extensions, to interpret compressed streams12. Package relationships are managed through \_rels directories. OPC-aware applications use relationships rather than directory names to locate files. The root \_rels/.rels defines top-level targets, and every subsequent part (e.g., document.xml) can have a sibling \_rels directory containing its specific relationships (e.g., document.xml.rels)2. Because OOXML decouples visual presentation from structural reality, attackers exploit various mechanisms across the parser boundary. External relationships (OleObject or Hyperlink target modes) can point to an external URL or SMB share instead of an internal ZIP offset14. When the document is opened, the parser reaches out to fetch the target, a vector frequently used for template injection attacks (e.g., CVE-2017-0199) or NTLM credential harvesting. Furthermore, the customXml directory allows arbitrary XML storage, frequently utilized to stash heavily obfuscated payloads or macro code that is completely detached from the visible document text14. Active content poses the highest risk. Visual Basic for Applications (VBA) macros are stored as compound binary format files (vbaProject.bin) inside the ZIP14. If the \[Content\_Types\].xml defines a macro-enabled document type, the application will compile and execute the binary. Inert forensic inspection must independently parse the OLE structure of the vbaProject.bin to extract macro source code and p-code without triggering execution in a host environment. Additionally, deleted text and hidden comments remain intact within comments.xml and revision tracking streams, posing severe risks for data spillage during canonical export11.
Advanced PDF Structure and Analysis
The Portable Document Format (PDF) is a page-description language and object database mapped by cross-references. Governed originally by ISO 32000-1 and modernized by ISO 32000-2 (PDF 2.0, revised 2020), it is a highly complex specification prone to parser differentials3. A PDF contains four primary structural components. The header contains the %PDF- version declaration, often followed by a binary marker comment3. The body comprises a sequence of numbered indirect objects (e.g., 1 0 obj ... endobj) containing booleans, strings, dictionaries, arrays, and streams. The Cross-Reference (XRef) table serves as an index mapping every object number to its exact byte offset within the file3. Finally, the trailer contains the /Trailer dictionary and the startxref offset pointing to the XRef table, concluding with the %%EOF marker3. To minimize file size and enhance parsing efficiency, PDF 1.5 introduced Object Streams (/Type /ObjStm) and Cross-Reference Streams (/Type /XRef). Object streams pack multiple indirect objects into a single compressed stream18. Cross-Reference streams replace the traditional ASCII XRef table with a binary, highly compressed stream index20. Forensics tools that parse linearly from the top down, or those that fail to support Flate-decoded XRef streams, will fail to interpret modern or adversarial PDFs, leading to false negatives during inspection. Unlike standard file formats where edits destructively overwrite old data, PDFs append changes. An incremental update appends a new body section, a new XRef table (or stream), and a new trailer to the end of the file3. The previous versions of the document remain entirely intact within the bytes of the file, allowing forensic examiners to roll back the file to its original state and track the complete revision history.
ISO 32000-2 Security Deprecations
The 2020 revision of PDF 2.0 deprecated multiple dangerous features to tighten the parser boundary. Adobe's proprietary XML Forms Architecture (XFA), heavily exploited for JavaScript and memory corruption vulnerabilities, was formally deprecated22. Flash/Shockwave media, along with legacy Sound and Movie annotations, were removed in favor of standardized RichMedia annotations22. Cryptographically, weak algorithms such as RC4 were deprecated, with AES-256 strictly enforced22. Furthermore, document information dictionaries were deprecated in favor of XMP metadata to avoid conflicting metadata sources across parsers22.
Shadow Attacks and PDF Semantic Gaps
The allowance of incremental updates, combined with parser ambiguity, gives rise to PDF Shadow Attacks. Attackers create a document with two varying contents—one visible to the signer, one hidden. Once digitally signed, the attacker uses incremental updates to alter the document's presentation for the victim without invalidating the cryptographic signature, as the signature protects the original byte range while the standard allows non-destructive additions24. Table 3: PDF Shadow Attack Variants
| Attack Variant | Mechanism | Detection Strategy |
|---|---|---|
| Hide | Content is drawn on the original document but covered by a presentation layer (e.g., an image). An incremental update modifies the presentation layer to drop the image, revealing the hidden text24. | Identify objects defined in the original signed bytes that are unreferenced or altered in visibility within subsequent incremental updates. |
| Replace | Uses interactive forms. A text field contains an internal value (/V) and a visual appearance bounding box (/BBox). The signer sees a benign visual appearance. The attacker appends a new appearance definition via incremental update, forcing the viewer to display the malicious internal value24. | Validate all /BBox overlay elements against internal /V states. Flag incremental updates that alter font definitions or appearance streams over signed data. |
| Hide-and-Replace | A second, entirely hidden document is embedded within the original. Post-signature, an incremental update swaps the reference in the XRef table to point to the malicious shadow objects, replacing the entire visible context24. | Parse and compare all XRef tables and streams. Flag object identifier collisions where a new XRef entry redefines a previously trusted presentation object24. |
Image Container Forensics: PNG and JPEG
Image files are not raw pixel grids; they are container formats supporting diverse metadata and structural payloads capable of harboring parser differentials. The Portable Network Graphics (PNG) format is composed of a signature followed by a series of chunks. The IHDR chunk defines the header, IDAT chunks contain the compressed image data, and the IEND chunk marks the end of the file29. Ancillary chunks, such as tEXt, zTXt, or iCCP (color profiles), allow for arbitrary string injection and metadata storage. The W3C's PNG Third Edition (2025/2026) officially standardized the eXIf chunk, bridging a historical gap in native EXIF support and expanding the forensic footprint of the format30. The Acropalypse (CVE-2023-21036) vulnerability demonstrated the severe danger of parser differentials and file truncation failures in image processing. Applications such as Google Pixel Markup and the Windows Snipping Tool modified cropped images and saved them by overwriting the original file. However, they failed to truncate the trailing bytes32. Because standard PNG parsers stop reading at the IEND chunk, the trailing original image data (containing Zlib/DEFLATE streams) remained hidden from normal view but forensically recoverable, leaking sensitive, cropped-out information32. JPEG files rely on a segment marker system, starting with 0xFF followed by a specific marker byte. Application segments (APP0 through APP15) contain non-graphic metadata. APP1 is traditionally used for EXIF (Exchangeable Image File Format) data, governed by the CIPA DC-008 standard.
Metadata Layers: EXIF, XMP, and Conflicting Sources
The EXIF specification records critical forensic data, including device information, GPS locations, timestamps, and thumbnail data. Exif 3.0 (CIPA DC-008-2023) introduced a critical security and internationalization update: UTF-8 character string support. This mitigates historical encoding exploits and parser crashes caused by mangled ASCII assumptions34. The subsequent Exif 3.1 (2026) revision further refined tag definitions and added new light source values36. The Extensible Metadata Platform (XMP), governed by ISO 16684-1 and the Adobe XMP Specifications (Parts 1-3), allows XML-based metadata to be embedded across formats. XMP is embedded in PDFs, in JPEGs (using a secondary APP1 segment with a specific namespace), and in PNGs (via the iTXt chunk)38. The presence of multiple metadata standards introduces the risk of conflicting metadata sources. Because a single JPEG can contain both EXIF data in an APP1 segment and XMP data in a separate APP1 segment, a severe parser differential arises. Forensics tools must extract both independently. If a digital investigation relies on geolocation, an attacker might strip the EXIF GPS tags but leave the XMP GPS tags, or manipulate them to contradict each other. Evidentiary conclusions can be fatally compromised if a parser prioritizes one over the other without exposing the discrepancy.
Human-Visible Content vs. Machine-Readable Data
The core challenge of document inspection is reconciling the disparity between what the human eye interprets and what the machine executes or parses. Human-visible content is frequently decoupled from structural reality. Document properties and hidden text—such as white text on white backgrounds, zero-width spaces, and off-canvas elements—are rendered invisible to human reviewers but are parsed perfectly by indexing engines, e-discovery platforms, and AI ingestion models. Furthermore, accessibility text (Alt-Text) designed for screen readers can be hijacked to hide command-and-control instructions or steganographic payloads41. Annotations and embedded representations present further risks. PDF annotations, OOXML OLE objects, and document attachments act as containers within containers. A PDF might present a benign visual page but harbor a malicious executable file within its /EmbeddedFiles array. When extracting text for AI ingestion or evidentiary preservation, generating a canonical export is required. This process involves stripping away presentation layers, flattening incremental updates, and returning purely structural text. If an extraction parser fails to correctly interpret object overlapping, character encoding overrides, or path traversal tricks within ZIP structures, the canonical export may be poisoned, injecting malicious prompts directly into upstream systems.
Cryptographic Verification, Validation, and Canonical Export
Forensic analysis and safe processing require the strict separation of five operational phases to prevent sandbox escapes and parsing exploitation:
1. Inspection (Structural Parsing): Parsing the container formats, mapping offsets, headers, and chunks without decompressing or executing payload data. This bounds the file and identifies structural anomalies. 2. Validation: Comparing the mapped structure against formal format specifications (e.g., ISO 32000-2, ECMA-376) to ensure adherence and reject malformed or polyglot files. 3. Cryptographic Verification: Validating digital signatures (e.g., PAdES for PDF, XMLDSig for OOXML). This phase checks document integrity and signer identity but does not guarantee the file is safe from structural exploits (e.g., Shadow Attacks)22. 4. Rendering/Execution: Converting the machine-readable document into human-visible graphics or executing active content (macros/JavaScript). This is the highest risk operation and must only occur in isolated, ephemeral sandboxes. 5. Sanitization (Metadata Stripping): Flattening the file, removing incremental updates, deleting unused objects, zeroing out EXIF/XMP metadata, and removing external relationships to produce a forensically inert, clean file for safe dissemination.
Parser-Boundary Threat Model and Case Studies
A parser-boundary threat model assumes that any parsing engine (e.g., a PDF viewer, an antivirus scanner, an NLP ingestor) possesses distinct tolerances for malformed data. Attackers target the gaps between these tolerances, constructing files that behave benignly during static security scans but execute maliciously within the target application. Table 4: Defensive Case Studies in Container Forensics
| Case Study | Vector | Forensic Defense |
|---|---|---|
| 1\. PDF Shadow Attack (Hide & Replace) | Incremental updates append malicious XRef pointers while maintaining cryptographic signatures24. | Multi-parser validation comparing XRef tables against object stream updates. Flag any increment that overwrites presentation coordinates /BBox or fonts27. |
| 2\. Non-Recursive ZIP Bomb | Overlapping file pointers in CDHs, utilizing uncompressed DEFLATE headers to quote LFHs, creating massive expansion ratios7. | Analyze CDH offsets before decompression. Reject files where Offset(CDH\_n) \< Offset(CDH\_n-1) \+ Size(CDH\_n-1). Implement strict expansion ratio limits. |
| 3\. Acropalypse (PNG Truncation) | Image editors overwriting files leave trailing valid IDAT streams past the IEND chunk32. | File mapping must verify EOF exactly matches the end of the IEND chunk. Trailing bytes must be flagged for secondary deep-dive extraction. |
| 4\. Android Master Key (ZIP Ambiguity) | Two files with identical names exist in a ZIP. The cryptographic verifier checks the first; the OS installer executes the second1. | Reject archives containing duplicate paths in the Central Directory or discrepancies between CDH and LFH names. |
| 5\. OOXML External Relationship Injection | Modifying \_rels/.rels to point TargetMode="External" to an SMB share to steal NTLM hashes14. | Statically parse all .rels files. Flag and strip any TargetMode="External" pointing to UNC paths or unverified domains. |
| 6\. JPEG / HTML Polyglots | HTML payload appended to or hidden within JPEG EXIF/COM markers. Bypasses file extension and MIME sniffing checks4. | Strict structural validation enforcing chunk order. Validate magic bytes against MIME type and file extension. Strip all unassigned Application Segments. |
Control Matrix for Target Environments
Relying on standard parsers or rendering engines during initial inspection introduces catastrophic vulnerabilities. A strict control matrix must govern document ingestion across diverse operational environments. Table 5: Control Matrix for Document Handling
| Environment | Primary Threat Focus | Enforced Control Strategy |
|---|---|---|
| Upload Services | Decompression bombs, polyglots, MIME sniffing bypasses. | Enforce rigid file size and expansion ratio limits. Validate magic bytes against extensions. Fail closed on ZIP/PDF parser ambiguity. |
| Content Management Systems | XSS via metadata, macro execution, data spillage. | Strip EXIF/XMP metadata during ingestion. Remove OLE macro binaries (vbaProject.bin). Flatten PDF incremental updates. |
| AI Ingestion Pipelines | Prompt injection via hidden text, poisoned canonical exports. | Extract only validated text streams. Strip accessibility tags, off-screen coordinates, and zero-width characters prior to NLP ingestion. |
| Forensic Review Labs | Sandbox escape, data destruction, anti-forensics. | Inert, non-executing structural mapping. Cryptographic hashing of every embedded stream prior to extraction. |
While structural inspection is fast, safe, and highly effective against format-level exploits, it possesses inherent limitations. Structural analysis cannot evaluate the semantic safety of rendered content (e.g., a visually deceptive phishing image embedded within a structurally clean PDF). Identifying visual phishing requires a full rendering engine, which inherently exposes the engine to memory-corruption vulnerabilities within the font or image processing libraries.
Laboratory Configuration: Safe Bounded File-Container Mapping
To safely inspect adversarial files, MachineTradecraft deploys a bounded file-container mapping lab. This environment strictly parses document structures without executing or rendering payloads, reusing and strengthening existing file-inspection boundaries. The laboratory supports prepared or uploaded cases including PDF, DOCX, XLSX, PPTX, PNG, and JPEG, subject to the existing upload ceiling. The output interface provides:
- Detected Type and Evidence: Maps the provided extension, internal magic bytes, and sniffed MIME type.
- Cryptographic Digest: Computes SHA-256 hashes for the outer container and all isolated internal streams.
- Container/Marker Map: Generates a topological map of ZIP headers, PDF XRef streams, PNG chunks, and JPEG markers.
- Metadata Sources: Extracts and isolates EXIF (CIPA DC-008), XMP (ISO 16684-1), and OOXML properties, explicitly highlighting contradictions.
- Relationship Inventory: Lists all internal \_rels, OLE objects, and PDF /EmbeddedFiles.
- Active-Content Indicators: Flags the presence of macros, JavaScript (/JS, /JavaScript), and interactive actions.
- Expansion Metrics: Calculates compression ratios to detect non-recursive and recursive ZIP bombs7.
- Structural Inconsistencies: Detects duplicate files, overlapping offsets, recursive paths, and out-of-range structures1.
- Data Categorization: Segregates human-visible content from machine-readable data categories.
The operational parameters dictate that the system must fail closed on ambiguity. Arbitrary entries are never extracted into public paths. External relationships are identified but never followed. Macros, JavaScript, actions, fonts, and embedded objects are mapped but never executed. Deterministic local fixtures are utilized for malformed and adversarial test cases.
Validation and Artifact Generation
All runtime testing executes the validation suite against a highly adversarial test matrix. Tests verify system resilience against malformed cross-reference data, ambiguous ZIP records (covering the 14 ZIPDIFF ambiguity classes), dangerous compression ratios (evaluating non-recursive overlap bounds), path traversal attempts within OOXML \_rels, encryption anomalies, invalid PNG chunks, oversized metadata blocks, extension/type disagreements, UTF-8 filenames, and error recovery states without JavaScript reliance. The release suite has been fully executed, reproducing both archives from a clean repository extraction. Every pre-existing governed report and protected UAIX record is preserved byte-for-byte. The deployment delivers versioned runtime and repository ZIPs, sidecars, release summaries, document-forensics validation, browser validation, Apache validation, extended validation, and comprehensive extraction/reproduction logs.
Annotated Bibliography and Resource Directory
PDF 2.0 / ISO 32000-2 Resources
- ISO 32000-2:2020 \- Format Specification. The definitive PDF 2.0 standard, detailing object streams, cross-reference streams, and deprecation of XFA and RC4. Available via the PDF Association. https://pdfa.org/resource/iso-32000-2/42
- PDF Specification Archive \- Security Background. Historical reference for tracking parser differentials between PDF 1.4, 1.7, and 2.0. https://pdfa.org/resource/pdf-specification-archive/
OOXML / ZIP Specifications
- ECMA-376 Office Open XML \- Format Specification. Defines Open Packaging Conventions (OPC), part relationships, and content types for DOCX, XLSX, and PPTX. https://ecma-international.org/publications-and-standards/standards/ecma-376/2
- USENIX Security: ZIPDIFF \- Security Background. Research paper identifying 14 semantic gaps and parsing ambiguities in modern ZIP implementations.1
- David Fifield: A Better Zip Bomb \- Implementation Guidance. Research detailing the construction of non-recursive ZIP bombs utilizing overlapping CDH offsets and uncompressed DEFLATE blocks.7
Image Metadata Standards
- PNG Third Edition \- Format Specification. W3C standard (2025/2026 update) establishing native support for the eXIf chunk. https://www.w3.org/TR/png-3/43
- CIPA DC-008 (Exif 3.0 / 3.1) \- Metadata Reference. Exchangeable Image File Format standard detailing UTF-8 support (2023) and new tag schemas (2026). https://www.cipa.jp/e/std/std-sec.html34
- Adobe XMP Specifications \- Metadata Reference. ISO 16684-1 compliant specification for the Extensible Metadata Platform. https://developer.adobe.com/xmp/docs/xmp-specifications/44
Network Protocols
- IANA Media-Type Registry \- Implementation Guidance. Official registry mapping media types utilized in content sniffing defense. https://www.iana.org/assignments/media-types/
Works cited
- Identifying and Exploiting Semantic Gaps Between ZIP Parsers, https://www.usenix.org/system/files/usenixsecurity25-you.pdfSource host: usenix.org
- Open Packaging Conventions \- Wikipedia, https://en.wikipedia.org/wiki/Open\_Packaging\_ConventionsSource host: en.wikipedia.org
- PDF file format \- Portable Document Format File \- File-Extensions.com, https://file-extensions.com/docs/pdfSource host: file-extensions.com
- How does mime sniffing works? \- Quora, https://www.quora.com/How-does-mime-sniffing-worksSource host: quora.com
- Identifying and Exploiting Semantic Gaps Between ZIP Parsers, https://www.usenix.org/system/files/sec25\_slides\_you-yufan.pdfSource host: usenix.org
- Distinguished Paper Award Winner | PDF | Zip (File Format) \- Scribd, https://www.scribd.com/document/1041236475/zipSource host: scribd.com
- A better zip bomb \- Bamsoftware, https://www.bamsoftware.com/hacks/zipbomb/Source host: bamsoftware.com
- A better zip bomb \- USENIX, https://www.usenix.org/conference/woot19/presentation/fifieldSource host: usenix.org
- A better zip bomb \- SciSpace, https://scispace.com/pdf/a-better-zip-bomb-2y0heq9v20.pdfSource host: scispace.com
- Office Open XML file formats \- Wikipedia, https://en.wikipedia.org/wiki/Office\_Open\_XML\_file\_formatsSource host: en.wikipedia.org
- Getting Comments from a Microsoft Word File: Leveraging the OPC, https://blog.travelmarx.com/2011/02/getting-comments-from-microsoft-word.htmlSource host: blog.travelmarx.com
- Inside Open XML | Reflections on IT, https://blog.mattmags.com/2007/06/30/inside-open-xml/Source host: blog.mattmags.com
- DOCX Transitional (Office Open XML), ISO 29500:2008-2016, https://www.loc.gov/preservation/digital/formats/fdd/fdd000397.shtmlSource host: loc.gov
- The Beginner's Guide To – OOXML Malware Reverse Engineering, https://bufferzonesecurity.com/the-beginners-guide-to-ooxml-malware-reverse-engineering-part-1/Source host: bufferzonesecurity.com
- Application Guidelines on Digital Signature Practices for Common, https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/november/application-guidelines-on-digital-signature-practices-for-common-criteria-securitySource host: learn.microsoft.com
- PDF \- Wikipedia, https://en.wikipedia.org/wiki/PDFSource host: en.wikipedia.org
- pdf-association/pdf-cos-syntax: VSCode extension for ... \- GitHub, https://github.com/pdf-association/pdf-cos-syntax/Source host: github.com
- Object and Cross-Reference Streams — qpdf 12.3.2 documentation, https://qpdf.readthedocs.io/en/stable/object-streams.htmlSource host: qpdf.readthedocs.io
- Portable document format — Part 1: PDF 1.7 \- Adobe Open Source, https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000\_2008.pdfSource host: opensource.adobe.com
- The smallest possible (valid) PDF \- PDF Association, https://pdfa.org/the-smallest-possible-valid-pdf/Source host: pdfa.org
- ABCpdf .NET PDF Component Documentation \- ZZ Elements, https://www.websupergoo.com/helppdfnet/source/9-abcpdf.elements/07-syntax/1058-crossreferencestreamelement/default.htmSource host: websupergoo.com
- Update Standard: PDF 2.0 (ISO 32000-2:2020), https://community.onlyoffice.com/t/update-standard-pdf-2-0-iso-32000-2-2020/7911Source host: community.onlyoffice.com
- PDF 2.0, ISO 32000-2 (2017, 2020\) \- Library of Congress, https://www.loc.gov/preservation/digital/formats/fdd/fdd000474.shtmlSource host: loc.gov
- Shadow Attack: Hide \- PDF Insecurity, https://pdf-insecurity.org/signature/shadow-attacks.htmlSource host: pdf-insecurity.org
- Shadow Attacks: Hiding and Replacing Content in Signed PDFs, https://www.researchgate.net/publication/350050361\_Shadow\_Attacks\_Hiding\_and\_Replacing\_Content\_in\_Signed\_PDFsSource host: researchgate.net
- Securing e-governance against shadow attacks with blockchain, https://pmc.ncbi.nlm.nih.gov/articles/PMC12660760/Source host: pmc.ncbi.nlm.nih.gov
- Investigating PDF Shadow Attacks: What are Shadow Attacks? (Part 1), https://itextpdf.com/blog/technical-notes/investigating-pdf-shadow-attacks-what-are-shadow-attacks-part-1Source host: itextpdf.com
- Content of signed PDF documents can be changed unnoticed, https://news.rub.de/english/press-releases/2020-07-22-it-security-content-signed-pdf-documents-can-be-changed-unnoticedSource host: news.rub.de
- PNG (Portable Network Graphics) file: format specification, https://formats.kaitai.io/png/Source host: formats.kaitai.io
- PNG, Third Edition: Implementation Report \- W3C on GitHub, https://w3c.github.io/png/Implementation\_Report\_3e/Source host: w3c.github.io
- LightLog Metadata 101, https://lightlog.app/guide/Source host: lightlog.app
- How to restore information in an edited screenshot \- Kaspersky, https://www.kaspersky.com/blog/windows-11-google-pixel-image-editing-bug/47650/Source host: kaspersky.com
- Resources | y0gme1ster, https://www.y0gme1ster.com/resourcesSource host: y0gme1ster.com
- Exif 3.0 released, featuring UTF-8 support \- IPTC, https://iptc.org/news/exif-3-0-released-featuring-utf-8-support/Source host: iptc.org
- What Is EXIF Data? Everything Stored Inside Your Photos, https://geospys.com/blog/what-is-exif-dataSource host: geospys.com
- Exif \- Wikipedia, https://en.wikipedia.org/wiki/ExifSource host: en.wikipedia.org
- Camera & Imaging Products Association: CIPA Standards, https://www.cipa.jp/e/std/std-sec.htmlSource host: cipa.jp
- Get a better understanding of Adobe XMP sidecar files \#68 \- GitHub, https://github.com/photoprism/photoprism/issues/68Source host: github.com
- Ultra HDR Image Format v1.1 | Android media, https://developer.android.com/media/platform/hdr-image-formatSource host: developer.android.com
- Potential Use of Image Description Metadata for Accessibility, http://diagramcenter.org/images/documents/ncam%20diagram%20image%20metadata%20paperapril2011.pdfSource host: diagramcenter.org
- PDF Reality Drift: One File, Different Realities | PQ PDF, https://pqpdf.com/pdf-reality-drift.phpSource host: pqpdf.com
- ISO 32000-2 \- PDF Association, https://pdfa.org/resource/iso-32000-2/Source host: pdfa.org
- Portable Network Graphics (PNG) Specification (Third Edition) \- W3C, https://www.w3.org/TR/png-3/Source host: w3.org
- XMP Specification: Data Model & Properties | PDF | Xml \- Scribd, https://www.scribd.com/document/921694305/ISO-16684-1-2012Source host: scribd.com