How to verify the integrity of ISO images in macOS

If you frequently download operating systems or utilities in ISO format for use on your Mac, verifying the integrity of those images isn't just a whim: it's practically mandatory if you want to avoid broken installations, strange errors, or worse, security issues. macOS offers several ways to ensure that the ISO file, the boot process itself, and the firmware are all in good working order.

Throughout this guide we will see, in considerable detail and without too much fluff, how to verify that an ISO image is not corrupted in macOS , what role checksums (MD5, SHA1, SHA256) play, what macOS does "behind the scenes" with recoveryOS and the firmware, how Apple checks the integrity of its own system and diagnostics, and how third-party tools like balenaEtcher or Ventoy fit into this puzzle.

Why is verifying an ISO image so important in macOS?

When you download an ISO to install a system (for example, Manjaro, Debian, Ubuntu, or even recovery utilities), you're relying on the file being downloaded completely and unaltered . A single changed bit can cause anything from installation failures to an unstable system that starts malfunctioning after just a few days.

Besides accidental corruption during download, there's a risk that someone may have modified the ISO image if you download it from an unofficial site or if your connection is being intercepted. In that scenario, you could end up installing a system with malware or backdoors without realizing it.

To make matters worse, once you "burn" that ISO onto a USB drive or external hard drive, another factor comes into play: the integrity of the data written to the storage medium itself . Cheap flash drives, disconnections during the copying process, or even bad sectors can cause the recorded content to not match the original.

And finally, on modern Macs, you also need to consider the integrity of the firmware and recovery environments (RecoveryOS and Apple Diagnostics), which are essential for your system to boot reliably and securely. Apple has implemented a fairly sophisticated system for this, and understanding it helps you get a complete picture of how integrity is protected in macOS.

How checksums (MD5, SHA1, SHA256) and .sum files work

The classic tool for verifying that an ISO file has been downloaded correctly is to use a cryptographic checksum , that is, a code generated from the file's contents using an algorithm such as MD5, SHA1, or SHA256. If the contents change, the code also changes.

In many Linux distributions and systems distributed as ISO images, the vendor publishes a checksum file along with the image. It usually has the same name as the ISO, but with a different extension. For example, for a file like manjaro-xfce-0.8.1-x86_64.iso , you would typically find files like:

• manjaro-xfce-0.8.1-x86_64-sha1.sum
• manjaro-xfce-0.8.1-x86_64-sha256.sum

The "sha" part of the name refers to Secure Hash Algorithm . SHA1 and SHA256 are two variations of the same concept: they generate a unique code for that content; if the ISO standard is altered, that code no longer matches. SHA256 is more modern and robust than SHA1, so if your provider gives you the option, it's preferable to use SHA256 for your checks.

These .sum files are simply text files that contain, on a single line, the expected hash value and the filename associated with both. When you calculate the ISO's hash on your Mac and compare it to the value published by the developer (either in a .sha256.sum file or directly on their website), you are verifying whether the file you downloaded exactly matches the one generated by the provider.

The idea is comparable to a secret password: if the "password" (the hash) generated on your Mac does not match the one published on the official website , it is a sign that the ISO has been corrupted or modified, and in that case it is best not to use it and download it again.

Verify the integrity of an ISO in macOS using Terminal

On macOS, you don't need to install anything to calculate ISO file hashes (unlike Windows ), because the system already includes command-line utilities for MD5, SHA1, and SHA256 . Simply use Terminal and run the appropriate command.

The first step is to navigate to the directory where your ISO image is located. If, for example, it's in your Downloads folder, you could do something like this:

cd ~/Descargas

Once you're in the correct directory, you can generate the checksum with these commands, depending on the algorithm you want to use. If you want an SHA256 hash, which is the most recommended:

shasum -a 256 nombre-de-tu-imagen.iso

The command `shasum -a 256` calculates a SHA256 hash of the file and returns a long string of numbers and letters followed by the filename. You need to compare this string with the value published by the developer (either in a ` .sha256.sum` file or directly on their website).

If the provider only offers you an SHA1 checksum, you can use:

shasum -a 1 nombre-de-tu-imagen.iso

And if all you have is an MD5 hash value, macOS also includes a specific command for that, so you can run:

md5 nombre-de-tu-imagen.iso

When the values ​​generated by these commands match the published values, you can assume the ISO file is intact and ready to use . If they don't match, you'll need to delete the file and download it again, preferably after checking your connection or finding an alternative mirror.

What to do when the ISO does not include a checksum file

Many Linux distributions and recovery systems include files like md5sum.txt, sha1sum, or sha256sum within the ISO itself, or alongside it on the download page. However, not all projects do this; sometimes they only publish the hash on a webpage, or not even that.

If the ISO doesn't include a checksum file, ideally the developer should at least publish the hash value on their official website . In that case, you calculate the hash using shasum or md5 on your Mac and manually compare the string with the one you see on the page.

When there is neither a sum file nor a published value, things get complicated because you don't have a "source" reference . You could generate a hash yourself for future checks, but that doesn't guarantee that the original ISO wasn't already manipulated or corrupted.

In these cases, the most sensible thing to do is:

• Download the ISO only from the official project website or from verified mirrors.
• Avoid third-party sources of dubious origin, especially if it involves operating systems or sensitive tools.
• Check if the provider offers GPG firms or other alternative verification mechanisms.

If there is truly no verification method provided by the developer, you should assume there is no real guarantee of integrity , and consider whether it is worthwhile to use that ISO or look for a more reliable alternative.

How do balenaEtcher and Ventoy verify the integrity of what is recorded on the USB drive?

When you write an ISO to a USB drive using tools like dd on macOS, the process simply copies blocks of data back and forth without any additional checks. If something goes wrong along the way, you won't know until you try to boot and encounter boot errors.

Applications like balenaEtcher or Ventoy go a step further and offer verification options after writing. The concept is simple: once they have replicated the ISO on the drive, they read that data back from the USB and compare it with the source file.

They typically recalculate a hash or compare it block by block . If the content read from the USB drive is identical to the original image, the tool indicates that the process was successful. Otherwise, it warns that there was a problem during the writing process.

This verification after copying is independent of whether the ISO includes files like md5sum.txt . If the developer includes these files within the image, some tools can use them to perform an extra check from the booted system itself, but for tools like balenaEtcher or Ventoy, the key is to compare the source and destination files.

If the ISO does not have an internal checksum, the tool can simply check that the data that has arrived on the USB matches the data in the file on your disk , which does not guarantee that the ISO is legitimate, but does guarantee that it has not been corrupted in the step from "file to physical media".

recoveryOS on Mac: BaseSystem.dmg and BaseSystem.chunklist

In addition to the ISOs you can download, your Mac has its own recovery environment called recoveryOS , which is completely separate from the main macOS installation. This entire recovery system is stored in a disk image file called BaseSystem.dmg.

Alongside that image is another crucial file: BaseSystem.chunklist . This file contains a list of hashes corresponding to 10 MB fragments of BaseSystem.dmg. It is, so to speak, a piecemeal integrity map of the entire recovery image.

When the Mac boots into recoveryOS, the UEFI firmware doesn't blindly trust the disk's contents. It first evaluates the digital signature of the chunklist file , and only if that signature is valid does it begin verifying, one by one, the hashes of each 10 MB block of BaseSystem.dmg.

If any of those hashes don't match, it means the recoveryOS contents have been altered or corrupted. In that situation, booting from the local recoveryOS is canceled , and the firmware attempts to boot into internet recovery mode by downloading a clean image from Apple's servers.

If the chunklist and all BaseSystem.dmg fragment verification completes successfully, the firmware mounts that image as a RAM disk and executes the boot.efi file it contains. UEFI does not need to specifically validate boot.efi or the kernel because the integrity of the entire recovery operating system has already been checked beforehand at the full image level.

Apple Diagnostics and its Integrity Mechanism

Apple not only protects the recovery environment, but also the Apple Diagnostics system , that is, the utility that allows you to check your Mac's hardware without entering the main operating system.

The process of booting local diagnostics is very similar to that of recoveryOS. In this case, AppleDiagnostics.dmg and AppleDiagnostics.chunklist files are used , which function equivalently to BaseSystem.dmg and BaseSystem.chunklist but are geared towards the testing environment.

The UEFI firmware verifies the signature of the diagnostics chunklist and then validates the hashes of the blocks in the AppleDiagnostics.dmg image. If everything matches up, instead of booting boot.efi , the firmware starts a file called diags.efi within that image.

The diags.efi file is responsible for invoking other UEFI drivers capable of interacting with the hardware, running memory and disk tests, etc., and displaying any detected errors. Again, the idea is that only code whose integrity has been previously verified is executed.

This approach, based on signed .dmg images with chunklists, allows Apple to ensure that both recovery and diagnostics start from a trusted environment, without relying on the primary disk being healthy or free from malicious modifications.

Internet recovery and download security

If a problem is detected during recoveryOS or Apple Diagnostics startup, the UEFI firmware has a backup plan: internet recoveryOS . You can also manually invoke it using keyboard shortcuts when you turn on your Mac.

In this mode, the firmware connects to Apple's servers to download the disk images and their corresponding chunklists. Although the transfer is done using HTTP instead of HTTPS, the integrity of these images is protected in the same way as if they were on your own disk.

The trick is that security isn't based on encrypting the transmission, but on validating the downloaded content against the signed chunklist . Even if someone were to intercept the connection and modify the data in transit, the hashes would no longer match, and the firmware would discard the manipulated image.

By design, if the verification of a specific fragment fails, the firmware requests that block from the server up to 11 times before giving up and displaying an error. Only when all fragments pass the integrity test is booting from the downloaded recovery image permitted.

When Apple introduced internet recovery and diagnostics around 2011, they opted for simpler HTTP and handled the critical authentication and content integrity using chunklists . This allowed them to avoid implementing the entire HTTPS stack within the UEFI firmware, resulting in a smaller attack surface and more controlled code.

How to check if your EFI firmware is up to date on macOS

The integrity of the ISO and recoveryOS images is good, but it's also important to know the status of your Mac's EFI firmware . Having outdated firmware can leave you vulnerable to issues, boot failures, or incompatibilities with recent macOS versions.

To see which boot ROM version you have installed, simply follow these steps from within the macOS system:

1. Open the menu  and select the option About this Mac.
2. When the window appears, click the button to show the System report.
3. In the sidebar, go to the section Hardware and look for the field Boot ROM version.

You'll see something similar to MBP114.0177.B00 . The first block (MBP114 in the example) identifies your Mac model, in this case a 2015 15-inch 11,4-inch MacBook Pro.

The groups that follow, in hexadecimal format, indicate the major and minor firmware versions . These are the values ​​you should compare with the official tables or updated lists that compile the latest firmware versions available for each Mac model.

If your version is behind the one shown in those tables, it usually means you're missing a macOS update or firmware patch , since Apple distributes many of these firmware improvements integrated into system updates.

Verify firmware integrity with eficheck on macOS

macOS also includes a command-line utility specifically designed to check the integrity of EFI firmware by comparing it to a list of versions allowed by Apple. This tool is called eficheck.

To use it, open the Terminal application and run the following command:

/usr/libexec/firmwarecheckers/eficheck/eficheck --integrity-check

If all goes well, you'll get an output like this:

EFI Version: MBP114.88Z.0183.B00.1804091616
Primary allowlist version match found. No changes detected in primary hashes.

In that output, the MBP114 prefix again indicates the Mac model (in this case, the same MacBook Pro 11,4), while the following parts provide information about the firmware version and its date.

Block 0183 corresponds to the major firmware version, and B00 to the minor version. The final number, 1804091616 in the example, encodes the firmware compilation date (here it could be read as 2018/04/09 16:16).

The message “Primary allowlist version match found. No changes detected in primary hashes.” indicates that the firmware matches a version recognized and allowed by Apple , and that no modifications have been detected in the primary hashes. If you see a very different message or if discrepancies are indicated, it is a serious sign that there may be problems with the firmware's integrity.

In that scenario, it's advisable to contact an Apple Store or an Authorized Service Provider to have the device checked, since altered or corrupted firmware is beyond the scope of typical home repairs.

Check for errors on disks and USB drives from macOS

The integrity of an ISO depends not only on the downloaded file, but also on the disk or USB drive where it is stored or burned . A disc with bad sectors can ruin an installation even if the ISO itself is perfect.

macOS includes the Disk Utility application , which acts as a partition manager and basic diagnostic tool. You can find it in the Applications > Utilities folder , or by searching for it using Spotlight (the magnifying glass icon in the menu bar).

Disk Utility can also be run in safe mode to analyze the system's own startup disk, although for that it is advisable to follow Apple's instructions, as the steps may vary depending on the macOS version and the type of Mac (Intel or Apple Silicon).

Up to versions like Snow Leopard and Mavericks, the application included clear options for Verify Disk and Repair Disk , as well as functions to check and repair permissions on Mac OS Extended (HFS+) formatted volumes. On those systems:

• You would choose the drive or partition in the left panel,
• You entered the tab First aid,
• And from there you would launch the necessary checks and repairs.

In later versions of macOS, from Yosemite through Sierra and beyond, the interface changed, but the First Aid concept remained . You select the indented volume (the data volume) and click First Aid to have macOS check the file system and, if possible, correct errors.

These analyses can take anywhere from a few seconds to several minutes, depending on the size of the data volume and the number of corrections that need to be applied. The window allows you to show or hide the process details to see what is being checked and what problems are being detected.

Note that only volumes formatted as Mac OS Extended or APFS support certain advanced operations. Formats like FAT32 (MS-DOS) do not support permissions and have additional limitations, so to verify USB drives with those formats, it may be best to use specific tools from the manufacturer.

If after trying First Aid you notice recurring error messages or the drive continues to behave strangely, it is quite likely that the physical media is failing , and in that case it is advisable to change the USB drive or hard drive before continuing to use ISO images on it.

Using third-party checksum tools on macOS

Although the macOS Terminal more than covers the basics with md5 and shasum , some users prefer a graphical interface or more advanced features, especially when working with many files or needing to automate checks.

Applications like Quick Hash and other checksum utilities allow you to visually calculate SHA1, SHA256, and other hashes by dragging and dropping files or entire folders. These tools typically display multiple hashes at once and make it easy to copy and compare results.

If you handle many ISO images, it can be convenient to have a tool like this to centralize all checks , save logs, or even verify batches of files downloaded from different projects.

However, the principle remains the same: the application generates a hash from the ISO file, and you compare it to the official values ​​published by the developers. Therefore, reliability still depends on using trusted sources and verifying against authentic data.

Between verifying the downloaded file with checksums, checking the media with Disk Utility, and the integrity checks that Apple performs in recoveryOS, diagnostics, and firmware, you have a pretty solid security chain to ensure that the ISO images you use in macOS are reliable and that your computer boots from verified environments.