Phying News
P非影 中文
Curated security research, vulnerabilities, advisories and tools for practitioners.

Part II: Returning to Adobe Reader symbols on macOS

projectzero.google | blog | #reverse-engineering | #macos | #project-zero | #adobe-reader

Summary

In a blog post titled "The story of Adobe Reader symbols" published in October 2019, I presented an analysis of the debug symbols shipped with some older versions of Adobe Reader for Unix-family systems released between 1997-2013. Such symbols can prove immensely useful for both understanding the inner workings of various Reader components while reverse engineering, and for automated tasks such as crash classification and deduplication in fuzzing projects. In that blog post, I only briefly mentioned the macOS Reader packages as containing up-to-date symbols for the JP2K and 3D components, but missing any other interesting information beyond that. Upon a closer and more thorough inspection of the Mac releases, I have discovered that in fact more debug metadata made its way to the publicly available installers, some of which is unique (i.e. not present in other symbol sources) and/or more recent than the latest Unix symbols. Considering the added value of this new data, I wish to share it with you here in this follow-up post. As a reminder, legacy builds of Adobe Reader dating back to the '90s can be downloaded from the official ftp.adobe.com FTP server and the corresponding paths on the ardownload.adobe.com HTTP server.
Published
Collected

original ↗

Related coverage

blog · projectzero.google
The story of Adobe Reader symbols
Modern day security analysis of client applications is often hindered by the inaccessibility of their source code and other aids such as debug symbols. As a result, it is necessary to perform completely black-box reverse engineering of the software, in order to better understand their internals and reconstruct the missing context information, which is required to identify security flaws, triage and deduplicate crashes and so forth. This part of the process may be quite daunting, and the time spent on manual labor takes away from the time that could be spent testing the security properties of the program. Or in other words, it could be considered a waste of time. :-)
blog · projectzero.google
Breaking the Sound Barrier Part I: Fuzzing CoreAudio with Mach Messages
Part one of a macOS audio series: building a fuzzer for CoreAudio by sending Mach messages, covering the attack surface, harness design, and early results.
blog · projectzero.google
The Windows Registry Adventure #5: The regf file format
Part 5 of the Windows Registry Adventure series, dissecting the regf file format underlying registry hives, its parsing hazards, and why it matters for fuzzing.
blog · projectzero.google
The Qualcomm DSP Driver - Unexpectedly Excavating an Exploit
Research into the Qualcomm DSP driver that unexpectedly unearthed an exploitable bug, covering reverse engineering of its interface, root cause analysis, and exploit development.
blog · projectzero.google
Simple macOS kernel extension fuzzing in userspace with IDA and TinyInst
A practical recipe for fuzzing macOS kernel extensions in userspace by combining IDA-assisted harnessing with TinyInst, lowering the cost of finding driver bugs.
blog · projectzero.google
The Windows Registry Adventure #4: Hives and the registry layout
Part 4 of the Windows Registry Adventure series, explaining hive files and the overall registry layout, laying the groundwork for the later attack surface analysis.
back