blacktop/ipsw-diffs is a continuously updated public archive of per-build firmware diffs for iOS, iPadOS and macOS, giving authorized researchers a head start on binary-level security analysis.

ipsw-diffs is best understood not as a traditional tool you install and run, but as a research corpus: a MIT-licensed repository, authored by blacktop (the maintainer of the well-known ipsw firmware analysis toolkit), that publishes diffs between Apple firmware builds for iOS, iPadOS and macOS. Each entry in the repo compares two consecutive builds — for example 27.2 beta 2 (24B5089g) versus 27.2 beta 3 (24B5099f) — and links into a per-diff directory containing the detailed comparison. For anyone doing authorized Apple-platform security research, this collapses hours of downloading multi-gigabyte IPSW archives into a single browse operation.

The repository's README is essentially a navigable index. A quick navigation bar lists coverage stretching from recent releases like iOS 27.2 beta and macOS 26.6 back through the entire iOS 26.x and 18.x lines, and even legacy versions such as iOS 15.8, 12.5 and iPadOS 17.7. Coverage granularity is impressive: not only do stable releases get diffs, but nearly every beta transition is captured, including RC candidates and point releases. That beta-to-RC and RC-to-GM chain is precisely where security researchers look for last-minute code changes, and the repo makes it browsable.

What makes this corpus operationally interesting is what firmware diffing reveals. When Apple ships a security patch, the accompanying advisory names the fixed vulnerability, but the diff between the two builds shows which binaries actually changed — file-level additions, deletions, and modifications across system dylibs, frameworks, and daemons. A researcher reading iOS 18.7.2 (22H124) versus 18.7.3 (22H217) can immediately narrow the blast radius of a patch down to the affected subsystems, then focus deeper static analysis only on those components. This is classic patch-diff triage, and it is entirely passive analysis of publicly distributed firmware.

The metadata language of the repo is Just, a command runner, which strongly suggests the archive is generated by a Justfile pipeline rather than maintained by hand. That matters for two reasons. First, it implies reproducibility: the diffs are presumably produced by the same ipsw machinery blacktop maintains, scripted end-to-end from fetching the IPSW to emitting markdown diff reports. Second, it signals ongoing automation — the presence of bleeding-edge entries like iOS 27.2 beta 3 and macOS 27.2 beta indicates the pipeline runs on each new Apple beta drop, keeping the archive continuously fresh rather than a one-off snapshot.

Some entries carry research-relevant annotations that a naive scraper would miss. The iOS 26.0 section includes an explicit note about the switch from iPhone17,1 to iPhone18,1 — a hardware identifier transition — and the directory naming for the 26.3.1 (a) rapid security response diff (23D8133 vs 23D771330a) includes the device identifier in the path. These details matter because Apple's Rapid Security Responses and device-specific builds break naive diff tooling, and the repo visibly accounts for them, including OTA-based comparisons such as the 26.5 beta 1 (v2) entry flagged with OTAs.

The historical depth also enables longitudinal studies that go beyond single patch triage. With chains like 18.5 (22F76) all the way forward to 27.0, a researcher can trace how a specific system component evolved across a major OS transition, observe when binaries were introduced or retired, and generally build a mental map of Apple's system surface over time. There is even a dedicated A17 versus A18 comparison embedded in the 18.1 section, which speaks to the maintainer's interest in silicon-specific firmware differences — relevant territory for anyone studying low-level platform security like Secure Enclave-adjacent components.

For defensive teams, the value proposition is indirect but real. Vulnerability management for Apple fleets improves when analysts can correlate a CVE disclosure with the actual binaries that changed in the corresponding build pair listed here. Threat intelligence teams tracking iOS exploit chains benefit from understanding which frameworks were patched in which window — knowledge that helps distinguish actively exploited bugs from routine maintenance. All of this is educational analysis of publicly available, legitimately distributed firmware images; nothing in the repository contains exploit code or targets, and the diffs themselves are derived artifacts of Apple's own public releases.

The natural companion workflow pairs this archive with blacktop's main ipsw tool. The diffs tell you where to look; the ipsw toolchain lets you extract, parse, and disassemble the specific Mach-O binaries identified as changed between two builds. Because ipsw-diffs is simply a git clone away, integrating it into a local research pipeline is trivial: clone the repo, grep the per-diff README.md files for the frameworks you monitor, and you have a lightweight subscription mechanism for Apple's silent patch behavior. With 888 stars and an active release cadence, it has clearly found an audience among Apple security researchers.

There are caveats worth noting for professionals adopting it. The repository is a point-in-time mirror of Apple's release stream, so completeness depends on the maintainer's pipeline running; the README itself is the only documentation, with no formal usage guide, because usage is self-evident — you read it. Diff granularity is at the file/component level in the index pages, meaning deep function-level analysis still requires the researcher to pull the actual IPSW files and do the disassembly work. It is a triage accelerator, not an automated vulnerability oracle.

In sum, ipsw-diffs occupies a quietly valuable niche in the Apple security research ecosystem. It converts the tedious, bandwidth-heavy chore of pairwise firmware comparison into a browsable, versioned archive covering betas, RCs, GMs, and Rapid Security Responses across three operating systems. For authorized researchers, defensive analysts, and firmware hobbyists alike, it functions as both a daily-driver reference for new release triage and a historical dataset for longitudinal platform study — a testament to how much leverage a well-maintained public diff corpus provides.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• androguard 5 for Android reverse engineering and APK vulnerability auditing