Challenges in the forensic analysis of PDF files

During the development of the Arlington PDF Model and later, when collaborating with various vendors who adopted the model, it became apparent that different PDF SDKs yielded different results to Arlington’s data integrity rules due to built-in assumptions, simplified APIs, or permissive processing.

This article is designed to support developers considering deeper PDF analysis and discusses the kinds of issues they may face when selecting an API. It may assist PDF SDK architects in considering how existing or new APIs may be better suited for validation, cybersecurity, and PDF forensics.

Driven by global reliance on digital documents, regulatory changes, cybersecurity challenges, and the resulting rapid growth in demand for digital document forensics, the precise analysis of PDF files for correctness is increasingly important. The use of AI to parse and understand PDFs has altered the landscape, with AI systems leveraging vastly different technologies than the PDF viewers humans use.

PDF’s latest core specification, ISO 32000-2:2020, as well as other new ISO standards, specifications, and industry guidance on PDF, enable such detailed analysis. During DARPA’s “SafeDocs” program, the PDF Association created the Arlington PDF Model as a machine-readable definition of all PDF objects and their data-integrity rules defined in ISO 32000-2:2020 and amended by the growing list of errata corrections. Together with the PDF Association’s community forums, these resources increase developers’ awareness of these issues, thereby improving the technical precision of PDF.

Application-level APIs are often simplified to make everyday processing of PDF files easier, but when used for cybersecurity, forensics, or technical validation, these simplifications can lead to poor implementations and incorrect outcomes.

When considering low-level format validation features, security analysis, digital signature validation, or performing forensic analysis of PDF files, the choice of API is critically important, as it can limit which data integrity rules are supported and, thus, which types of malformed, invalid, or malicious PDFs may go undetected or incorrectly validated.

Deep technical validation vs. subset conformance

PDF files that claim to conform to ISO-standardized subsets of PDF, such as PDF/A, PDF/X, or PDF/UA, are commonly “validated” or “preflighted” to assess the conformance claim. In this context, validation commonly refers to checking specific additional rules imposed by a specific ISO standard, with only certain rules checked from the core PDF specification as necessary to ensure compliance with the claimed conformance level.

In this article, “technical validation” refers to a much deeper, more thorough technical analysis of every minute detail of PDF’s core specification. In reality, many PDF files have problems due to bugs in PDF creators and ambiguities in earlier PDF specifications.

Challenges for PDF SDKs / APIs

The following list of challenges is not definitive. The list is intended to provoke deeper thinking when selecting SDKs / APIs, and to highlight challenges that may be encountered when assessing technologies for use in security, forensic analysis, or deep technical validation.

Lexical rules

PDF’s lexical rules are fully and precisely defined in ISO 32000-2:2020. However, many SDKs/APIs designed for mainstream applications may permit syntax outside of PDF specifications or hide essential details, for example:

• Are curly brace delimiters restricted to PostScript functions? See the relevant errata correction.
• Can the encoding of a PDF text string object be determined? (PDFDocEncoding, UTF-16BE, or UTF-8 - or something else entirely)
• Can a PDF string object be identified as a literal string or a hexadecimal string? This can matter because for certain entries PDF’s specification requires one or the other.
• Are PDF integers and real numbers with leading zeros parsed correctly, in alignment with this errata correction?
• Are hexadecimal strings containing PDF comments rejected? Although whitespace is allowed (but ignored) in hexadecimal strings, failing to ignore PDF comments in hex strings poses a security risk.

See also the compacted syntax tests and PDF name encoding below.

PDF name encoding

Many PDF SDK/APIs make development easier by hiding the lexical encoding of dictionary key names. For example, /JS, /J#53, /#4AS, /#4aS, /#4A#53, and /#4a#53 are all valid for use as a JS entry. As a result, different SDKs / APIs may respond differently to PDF files with such obfuscated entries – some software may be unable to determine the encoding of dictionary entries.

¹4A is the hexadecimal value of “J” and 53 is the hexadecimal value of “S” in ASCII and PDFDocEncoding.

Pre-DOM processing (file structure and cross-reference data)

Prior to analyzing the PDF objects that comprise the document object model (DOM), substantial PDF parsing and processing are required to locate any linearization information or startxref entries, process cross-reference information, incremental updates, and (possibly) digital signatures. Even minor variations in this processing or different recovery algorithms (for invalid files) can lead to different outcomes and thus different PDF DOMs.

• Can you confirm, or control, whether Linearization processing was performed?
• Do you know whether the cross-reference information was valid, or did the SDK need to run recovery algorithms? Are the specific issues that trigger recovery processes reported?

Incremental updates

PDF files may contain one or more incremental updates (see ISO 32000-2, §7.5.6), in which changes to a document are appended to the end of the file. The changes may include adding new objects, deleting objects (by marking them as free in the cross-reference information), or modifying entries in the trailer dictionary.

• Can each revision of a document be independently validated? This is especially important for digitally signed PDF documents that may have been revised or annotated, or that are susceptible to “shadow attacks”.

PDF version

A PDF file’s version is defined by a combination of the PDF file header (%PDF-x.y) or, if present, the optional Version entry in the document catalog. For PDFs that contain one or more incremental updates, the Version entry may have been changed in one or more of those updates. Even though PDF version numbers in real-world PDFs aren’t reliable, PDF SDK/APIs should be clear about how the version they report is determined, including whether the PDF version changes during document revisions (as demonstrated by our recent pdf-differences test files).

Object ID validity

Determining the validity of PDF objects depends on various rules implemented in a given PDF SDK/API, for example:

• Is the Size entry in the trailer dictionary implemented correctly, such that object numbers which exceed the value of the Size entry are ignored (not processed)? In files with incremental updates, this entry may be updated in each revision.
• Does the API determine object numbers by the cross-reference data or by the object number of the object (e.g., 10 0 obj)? What does the SDK/API do if these object numbers do not match?

Indirect references

Many PDF SDK/APIs automatically resolve indirect references for convenience. However, in some cases, the PDF specification explicitly requires indirect references (e.g., the Pages key in the document catalog), so knowing whether a PDF object is referenced indirectly or directly can be essential to file trustworthiness and validity.

Duplicate key names in dictionaries

PDF’s specification does not permit (see ISO 32000-2, §7.3.7) duplicate key names in PDF dictionaries; however, they can (and do!) occur in extant PDF files. Depending on the PDF API, duplicate dictionary entries may not be exposed (and thus not detectable), or it may be challenging to determine which specific key an API elects to use.

Explicit null as dictionary key values

PDF’s specification states that dictionary entries with invalid references (see Object ID validity, above) must be treated as the null object. This can mean that APIs hide the presence of such keys. Furthermore, dictionary key values that are explicitly null may also get hidden for “developer convenience”.

Linearization data

Linearization dictionaries are not referenced in the PDF document object model (DOM), which begins with the Root entry in the trailer dictionary and continues through the document catalog. Accordingly, some APIs may not expose any of the Linearization dictionaries, but may use this data for processing pages.

Trailer entries

When APIs are based on the document catalog, they often treat the trailer dictionary (or multiple trailer dictionaries, in the case of PDFs with incremental updates) differently. Thus, some APIs may not be able to access every key in specific trailer dictionaries (including any private keys), or may return incorrect key data (e.g., from the wrong trailer when processing file revisions, such as may be required when validating digital signatures).

Encountering unsupported encryption

Many PDF SDK/APIs simply stop when encountering unknown or unsupported encryption algorithms, or when a password is incorrect. In PDF, however, only string and stream objects are encrypted, so other types of PDF objects (dictionaries, arrays, names, numbers, booleans, conventional cross-reference tables, etc.) are still processable for forensic analysis and other purposes.

“Anywhere” entries and private data

PDF files are not limited to the dictionaries and keys explicitly defined in ISO 32000. For example, both XMP metadata (Metadata entries) and Associated Files (AF entries), as described in ISO 32000-2, are permissible to occur on (almost) any PDF object. The exception is when indirect references are explicitly prohibited for all entries in an object; in that case, validators should report such entries as a technical specification violation.

In a similar fashion, undocumented keys may occur in any object, including the trailer dictionary, or array objects may have additional entries. These entries may result from private extensions, newly published extensions, attempted obfuscation by attackers (see above), or files written to comply with other specifications. For implications to PDF/A, PDF’s archival subset, see our publication: “Understanding Private Data in PDF/A”.

Redundant data

PDF defines various data structures that are effectively redundant. When valid and trusted files are processed, such redundancies can help improve the performance or responsiveness of user interfaces. However, these same redundancies can also lead to differences between implementations that rely on different data but do not sufficiently validate the data’s integrity.

Examples range from parallel data structures such as the EmbeddedFiles name tree listing some (but not necessarily all!) embedded files; parent/child entries, previous/next entries, or other data pointers may not be correctly matched or linked in unexpected ways; and various indicators of data length that may disagree. Detailed technical forensic processing of such data faces challenges in both identifying all risks while remaining performant.

Conclusion

When architecting PDF SDK/APIs, it is crucial to understand that forensic analysis and low-level technical file validation requirements differ significantly from those of general-purpose document processing. Vendors wishing to support the growing forensic tools market may need to extend their APIs and documentation with technically precise descriptions.

When selecting a PDF SDK/API to build detailed cybersecurity or forensic analysis tools, or to develop comprehensive low-level technical file validators, software developers should closely review the SDK/API documentation. This understanding must include recognizing any limitations or assumptions built into the SDK/APIs which may limit the functionality of the intended tools. These assumptions can lead to, for example, “false positive” failures (e.g., validating invalid files) or “false negative” failures (e.g., invalidating correct files).

The PDF Association provides various technical forums to support developers requiring a deeper understanding of these issues. In addition, the PDF Association maintains public GitHub repositories (such as pdf-differences and safedocs) with documented, targeted test files that can help developers understand some of these issues.