All Posts June 27, 2026

ASR (Apple Software Restore)

Wiki

#Apple #Utilities

ASR (Apple Software Restore) is Apple’s native command-line utility used to efficiently copy disk images to a target volume, clone drives, and restore system snapshots. It is the powerful, invisible backend engine that drives the graphical "Restore" feature in macOS's Disk Utility.

ASR (Apple Software Restore, also written as asr in lowercase for its command-line binary) is the core tool responsible for writing the iOS root filesystem to a device's NAND flash storage during a restore. Inside an iOS restore, ASR runs on the device itself — from within the restore ramdisk — and performs the critical block-copy operation that places the new operating system onto the device's storage. On macOS, ASR also exists as a standalone command-line utility for disk imaging and volume cloning tasks.

Table of Contents 22

What Is ASR?

The Apple Wiki defines ASR concisely: *"Apple System Restore (also known as ASR) is an application found on the Ramdisks of an IPSW firmware file. It works by writing the rootfs image to the actual system drive (ASR RESTORE), then checksums it."*

There are two distinct incarnations of ASR:

ASR on iOS ramdisk: The embedded version of ASR that runs during a device restore. This is a minimal, stripped-down binary that lives inside the restore ramdisk in the IPSW. Its job is singular: receive the root filesystem disk image from the host computer and block-copy it onto the device's internal NAND flash.

ASR on macOS: A full-featured command-line utility (/usr/sbin/asr) that Apple ships with macOS. It can restore, clone, and verify disk images across local and networked volumes. Apple's own Disk Utility app uses ASR as its backend for all restore operations.

Both share the same fundamental mechanism — block-level disk image copying with integrity verification — but serve different environments.

ASR in the iOS Restore Pipeline

During a device restore, the full sequence in which ASR participates is:

[iTunes / Finder / Apple Devices App]
        │
        ▼
1. IPSW downloaded and unpacked locally
2. Device enters Restore Mode
3. Restore ramdisk (containing ASR) is sent to device and booted
        │
        ▼
[Device is now running the restore ramdisk OS]
        │
        ▼
4. Root filesystem disk image sent from host to device
        │
        ▼
5. ASR RESTORE — ASR block-copies the rootfs image to the system partition
6. ASR VERIFY  — ASR checksums the written data to confirm integrity
        │
        ▼
7. Remaining firmware components installed (baseband, NOR, SEP, etc.)
8. Device reboots into newly installed iOS

The ASR stages (steps 5 and 6) are the ones explicitly reported to the host computer as progress messages:

"Restoring [device type] software." — ASR RESTORE phase
"Verifying [device type] software." — ASR VERIFY phase

ASR RESTORE and ASR VERIFY

ASR RESTORE

The RESTORE phase is ASR's primary operation: writing the root filesystem. The root filesystem is the largest single component in the IPSW — it contains all iOS system files, built-in apps, frameworks, and daemons. ASR performs a direct block-copy (not a file-by-file copy) for maximum speed, writing the disk image directly to the NAND flash partition without going through the device's normal filesystem layer.

This block-copy approach bypasses the overhead of filesystem operations and is significantly faster than writing individual files. However, it requires the source disk image to be pre-checksummed — a requirement ASR enforces.

ASR VERIFY

After the RESTORE phase completes, ASR performs a checksum verification pass over the written data. This confirms that what was written to flash matches what was intended, catching any NAND write errors, USB transmission errors, or data corruption that may have occurred during the copy.

If the VERIFY phase fails, the restore is aborted and an error is reported to the host. This is a safety mechanism — an iOS device with a partially or incorrectly written root filesystem would be non-functional.

How ASR Works: Block-Copy vs. File-Copy

ASR supports two restore methods on macOS (the iOS ramdisk version uses only block-copy):

Block-Copy (Erase Mode)

Directly copies the raw disk image sector-by-sector to the target volume
Requires the target volume to be unmounted (cannot block-copy to the currently running system)
Much faster than file-copy, limited only by storage and I/O speed
Requires the source image to be pre-checksummed using asr imagescan
Always erases the target — non-destructive block copies are not supported in modern ASR versions

File-by-File Mode (Legacy)

Copies individual files from the source image to the target
Previously useful for non-destructive restores but has been removed in modern ASR versions
Apple now directs file-copy use cases to ditto instead

Per Apple's documentation: *"asr no longer supports file copying. Such functionality is done better by ditto."*

ASR on macOS

On macOS, asr is a versatile tool for volume cloning and enterprise deployment. Its key capabilities include:

Basic Restore

sudo asr restore --source /path/to/image.dmg --target /dev/disk4 --erase

ASR requires root privileges (sudo) for all operations. The --erase flag is mandatory — ASR always erases the target before writing.

Key ASR Flags

| Flag | Purpose | ||| | --source | Source disk image or volume (DMG, sparsebundle, /dev entry, or mountpoint) | | --target | Destination volume or /dev entry (must be unmountable) | | --erase | Required; erases target before copy | | --noprompt | Suppresses confirmation dialogue (for scripted use) | | --verbose | Shows progress during restore | | --toSnapshot | Restores to a specific APFS snapshot (required for macOS Big Sur+) | | --no-personalization | Skips Apple Silicon personalization (required for Apple Silicon Macs in some contexts) | | --buffersize | Sets buffer size (e.g. 64m) for network/multicast performance |

Multicast ASR

ASR supports multicast deployment via asr:// URLs, allowing a single server to simultaneously image thousands of Macintosh computers over a network. This was heavily used in enterprise and education environments (e.g. school districts deploying Mac labs) before Apple moved toward MDM-based deployment.

ASR and macOS Big Sur / APFS Signed System Volume

Starting with macOS Big Sur, Apple introduced the Signed System Volume (SSV) — an APFS snapshot of macOS that is cryptographically signed. ASR was updated to handle SSV restores, requiring the --toSnapshot flag to specify the signed snapshot UUID. As Apple noted at WWDC 2019: *"developers should use ASR instead of third-party applications for backups of APFS volumes."*

On macOS Catalina (10.15.5), a bug temporarily caused third-party backup apps not using ASR to fail to create bootable backups — underlining ASR's central role in Apple's volume cloning architecture.

ASR Error Handling

ASR performs preflight checks before beginning a restore. Common errors include:

"Not enough space" — Target volume insufficient for the source image
"Codec overrun" — Source image may be corrupted; run hdiutil verify on the DMG
I/O errors during copy — May be transient; retry the restore
If output is unclear, re-running the restore often resolves transient issues

ASR and Jailbreaking

ASR's central role in the iOS restore pipeline made it a frequent target in jailbreak tooling:

ASR Patching in Custom IPSWs

Tools like PwnageTool, redsn0w, and sn0wbreeze routinely patched the ASR binary inside the restore ramdisk as part of creating custom IPSWs. The patch caused ASR to return "Image passed signature verification" in response to any firmware image — including unsigned, modified, or decrypted root filesystems — instead of performing genuine verification.

The Apple Wiki's documentation on tethered downgrades details this precisely: patching ASR to bypass SHA signature checks was a required step, alongside patching iBSS/iBEC and modifying the ramdisk.

Consequences of ASR Patching

Because ASR's SHA signature is changed when it is patched, the kernel's code-signing check on ASR itself fails. This means proper kernel patches are also required when using a patched ASR — otherwise the kernel refuses to execute the patched binary and the restore fails with Error 9.

This error is documented in The Apple Wiki's Restore Errors page: *"Due to ASR being patched, the SHA signature is automatically changed and after being resigned the kernel will refuse to use it. Therefore proper kernel patches are required. If necessary kernel patches are not applied, it will fail to load ASR and error 9 would occur during restore."*

ASR Corruption

Error messages related to ASR during a restore can indicate:

The IPSW is damaged or was improperly modified
A sn0wbreeze custom firmware with a bad ASR patch (sn0wbreeze 1.6 was known to have this issue — 1.7+ resolved it)
NAND chip failure on the device itself

| Error / Symptom | ASR Context | Resolution | |||| | Error 9 | Patched ASR rejected by kernel; missing kernel patches in custom IPSW | Use a properly built custom IPSW with kernel patches; or use stock IPSW | | "ASR does not exist on ramdisk or is corrupt/not signed" | Corrupt or improperly built custom IPSW | Use sn0wbreeze 1.7+ or PwnageTool; or use stock IPSW | | "Restoring software" hangs indefinitely | ASR block-copy stalled due to USB issue or NAND problem | Try different USB cable/port; if persists, may indicate hardware fault | | Error 1 / kernel signature failure | ASR patched without corresponding kernel patches | Rebuild custom IPSW with all required patches applied | | Restore fails at VERIFY stage | Data integrity check failed after block-copy | Retry restore; if persistent, indicates NAND write errors (hardware fault) |

Frequently Asked Questions

Q: Is ASR the same thing on iOS and macOS? They share the same design philosophy and core block-copy mechanism, but are separate binaries compiled for their respective environments. The iOS ramdisk ASR is a stripped-down version focused solely on device restore; the macOS ASR is a full-featured tool with multicast, scripting, and snapshot support.

Q: Can I run ASR manually on a device? Not in normal operation. The iOS ramdisk ASR runs automatically as part of the restore sequence. It is not accessible through a normal iOS environment.

Q: Why does a restore sometimes fail at the VERIFY step but not the RESTORE step? The VERIFY step is a checksum of what was written to flash. If the RESTORE step wrote incorrect data due to NAND errors, USB transmission glitches, or power fluctuations, VERIFY will catch it and abort. Retrying with a different cable or port resolves most cases; persistent VERIFY failures suggest a failing NAND chip.

Q: What is "ASR multicast" used for? Enterprise deployment of macOS across large numbers of Macs simultaneously. A single server streams a disk image to many clients at once using multicast networking, imaging all machines in the time it takes to image one. Largely superseded by MDM-based deployment in modern Apple environments.

External Resources

The Apple Wiki — ASR — Primary technical reference for ASR in the iOS restore context
The Apple Wiki — Restore Errors — ASR-related error codes documented
iOSBuddy — Download the correct IPSW (containing the ASR ramdisk) for your device
Apple macOS asr man page — Full CLI reference for macOS ASR

Based on technical documentation from The Apple Wiki and Apple's developer documentation. Last updated: June 2026.

Comments

No comments yet. Be the first to comment!

ASR (Apple Software Restore)

What Is ASR?

ASR in the iOS Restore Pipeline