palera1n: a checkm8 jailbreak for A8 to A11 devices, and what it costs you

The hardware window palera1n is built around

palera1n exists because of checkm8, a bootrom-level exploit that cannot be patched on the chips it affects. That fixes its audience precisely. The README lists iPhone 6s through iPhone X, the iPhone SE (2016), iPad mini 4, iPad 5th through 7th generation, iPad Air 2, several iPad Pro models, the iPod touch 7th generation, Apple TV HD, Apple TV 4K (1st generation), and a long set of T2 machines including iMac20,1, MacBookPro16,x, Macmini8,1 and MacPro7,1. If your device is not in those tables, this project is not for you, and no amount of configuration changes that.

The version floor is stated as iOS/iPadOS/tvOS 15.0 and bridgeOS 5.0 and higher. That is unusually broad for a jailbreak, and it is a direct consequence of the exploit sitting below the operating system. The trade is that the exploit is not the hard part. Getting the device into DFU reliably, and keeping the jailbroken state alive across reboots, is where the practical friction lives.

DFU, PongoOS and the boot chain

The mechanism is a chain of stages. palera1n drives the device into DFU mode, runs checkm8 against the bootrom, and hands control to PongoOS, a pre-boot environment that the project can override with its own image. From there it uploads a ramdisk, applies kernel patches through a patchfinder, and boots the system with the jailbreak attached. The README exposes each of those as a flag: -k for the Pongo image, -r for the ramdisk, -K for the kernel patchfinder, -o for the overlay, and -i to override the bundled checkra1n binary.

That override surface tells you something about the design. palera1n ships a built-in checkra1n, extracts it to the directory named by the TMPDIR environment variable, and lets you swap components out. The Makefile links a vendored dependency tree under dep_root rather than relying on system libraries, pulling in libimobiledevice, libirecovery, libusbmuxd, libplist and mbedtls as static archives. On Linux the release build is linked with -static -no-pie, which is why a single binary can run across distributions. On Darwin, CoreFoundation and IOKit are the only framework dependencies.

The command line also covers recovery and diagnostics: -E enters recovery, -n exits it, -R reboots in normal mode, -I prints connected device info, -D exits after DFU, and -s drops into safe mode. For deeper work, -p boots a PongoOS shell and -P boots one with default images already uploaded.

Installing palera1n and running a first jailbreak

The README does not carry build or install steps. The Installing section is one line: visit https://palera.in. That site is the distribution point for the tool and the guides, so treat it as the source of truth for the binary that matches your platform rather than grabbing an arbitrary build. The repository does contain a Makefile, so a source build is possible, and the flags it uses are visible, but the documentation does not walk through one.

What the README does give is the interface you will actually use. The usage block is the contract:

palera1n [-DEhpvVdsSLRnPI] [-e boot arguments] [-k Pongo image] [-o overlay file] [-r ramdisk file] [-K KPF file] [-i checkra1n file]

Before touching anything, connect the device and ask palera1n what it sees. This is the cheapest sanity check and it confirms the cable and driver stack are working:

palera1n -I

If the device is listed and the model and version match the supported tables, the next step is the exploit run itself. Adding -v turns on debug logging and can be repeated for more verbosity, which is what the troubleshooting section asks for when you file an issue:

palera1n -v

When the run finishes, the device boots with the jailbreak in place. If something goes wrong mid-run and the device sits in recovery, the README offers three exits: futurerestore --exit-recovery, irecovery -n, or palera1n -n. The last one is the one you already have installed.

Removing the jailbreak is a separate, explicit action rather than a reinstall. The flag is --force-revert, and it is documented as removing the jailbreak. Note that the README does not describe what state the device is left in afterwards, so plan a backup before you run it.

The A11 passcode rule and other hard limits

The most consequential limitation is stated plainly. On A11 hardware, which the README identifies as iPhone X, iPhone 8 and iPhone 8 Plus, you must disable your passcode while in the jailbroken state. On iOS 16 the requirement is stronger: you need to reset your device before proceeding with palera1n. That is not a configuration preference. It means an A11 device running iOS 16 cannot be jailbroken without wiping it and running without a passcode afterwards. For anyone whose phone holds work accounts, two-factor tokens or payment cards, that alone is a reason to stop.

Hardware is the second limit. The README recommends USB-A cables and warns that USB-C cables may fail because their accessory IDs differ and the device may not be recognised. On Apple Silicon Macs, the USB-C port may require manually unplugging and replugging the Lightning cable after the checkm8 exploit, with a USB hub suggested as a workaround whose behaviour varies. AMD CPUs, specifically non-mobile AMD parts, are called out as having a very low success rate with checkm8 and are not recommended.

Virtual machines are a flat no. The README states palera1n will not work in VirtualBox, VMware, or any virtual machine without PCI passthrough, because the exploit needs direct access to the USB controller. If your only computer runs Windows in a VM to reach Linux, that path is closed.

Finally, the disclaimers are blunt: the project is not responsible for data loss or a bricked device, and the user accepts that risk. There is no rollback documentation beyond --force-revert, and no statement about what a failed run leaves behind.

How palera1n differs from checkra1n and from rootless jailbreaks

palera1n is a descendant of the checkra1n lineage, and the relationship is visible in the binary: it embeds checkra1n, extracts it at runtime to TMPDIR, and lets you replace it with -i. The practical difference is scope. checkra1n was built around the same bootrom exploit but its supported version range stopped earlier, and palera1n extends the same primitive to iOS, iPadOS and tvOS 15.0 and bridgeOS 5.0 and above. If you are on a modern iOS release with an A8 to A11 chip, checkra1n is not the tool for that job and palera1n is.

A more interesting comparison is with rootless jailbreaks on newer hardware, which restructure where tweaks live on the filesystem so that system partitions stay untouched. palera1n's flags include a demote operation and an overlay file that can be overridden, which points at a different strategy: it patches the kernel and mounts an overlay rather than relying on a rewritten root layout. The README does not document the overlay format or the demote semantics, so this is a place where the documentation is genuinely thin, and anyone planning custom overlays will be reading source rather than docs.

Maintenance, licensing and what upgrading costs

The repository is not archived, and the last push was on 2026-09-21, one day before this article's reference point. That is current activity, not a dormant project. The release history is more mixed. v3.0.0-beta.2 landed on 2026-08-03, v2.4 on 2026-07-27, and v3.0.0-beta.1 on 2026-07-26. So the stable line sits at v2.4 while the 3.0 series is still in beta, and the two are close together in time. Anyone deploying this should decide deliberately which line they are on, because the beta tag is explicit in the release name.

Upgrade cost is dominated by the boot model rather than by the version number. Because the jailbreak is re-established through checkm8 on each boot, a new release does not silently update itself on the device. You re-run the tool from a computer. That also means a bad upgrade is recoverable by re-running an older binary, provided you still have it and still have the cable.

The licence is MIT. That is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. It does not carry a warranty, and the README's disclaimer about data loss and bricking sits on top of that. Nothing here is legal advice, and if you plan to redistribute a modified build, read the LICENSE file at the repository root rather than relying on the SPDX identifier alone.

Editorial conclusion

Adopt palera1n if you own a listed A8 to A11 device, run Linux or macOS, have a USB-A cable, and accept that booting the jailbroken state depends on a computer and a checkm8 run each time. Do not adopt it on an A12 or newer phone, on an unlisted T2 model, inside a virtual machine, or on an A11 device whose passcode you cannot remove, since the README requires the passcode disabled in the jailbroken state and a reset on iOS 16. Before you start, verify three things: your exact model identifier appears in the device tables, your iOS or bridgeOS version is 15.0 or 5.0 or higher, and the release you download is the one you intend to run, because v3.0.0 is still at beta.2 while v2.4 is the stable tag.

Frequently asked questions

Official sources

1. License: MIT
2. palera1n/palera1n on GitHub
3. Project website
4. README
5. Releases