Open-source project
futurerestore/futurerestore avatar
futurerestore/futurerestore

FutureRestore is an idevicerestore wrapper that lets you choose the SEP yourself

A hacked up idevicerestore wrapper, which allows specifying SEP and Baseband for restoring

693 stars251 forksC++LGPL-3.0

At a glance

What is it?
FutureRestore wraps the standard idevicerestore tool and lets you supply your own signing ticket, SEP and baseband, which is what makes downgrading an iPhone possible, and the readme spends most of its space on the flags that control it.
Who is it for?
FutureRestore suits a developer or device owner who needs to restore a specific firmware to an iPhone or iPad, in particular to downgrade, and who has the backup of their signing ticket. It is the wrong tool if you want an unmodified restore, because idevicerestore already does that and does it with Apple's own signing, and it is the wrong choice if you do not have the ticket, since without it the tool has nothing to sign the firmware with.
Can I use it commercially?
Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
Is it still maintained?
Yes. The repository last received commits 40 days ago.
What is it written in?
Mainly C++, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What the wrapper changes

FutureRestore is a modified idevicerestore wrapper which allows manually specifying SEP and Baseband for restoring. The stated consequence is that this allows unsigned firmwares to be restored onto devices, providing you have a backup of the APTicket, the SHSH blobs, and it can recreate all the specific conditions of the APTicket, for example the ECID, the APNonce and the Board ID. That last clause is the mechanism, because a restore normally requires Apple to sign the firmware, and the signing is tied to a set of device-specific values. If you hold a ticket for the right values, the tool can present the device with the values the ticket expects, which is why a backup of that ticket is the prerequisite for everything the tool does. The project is licensed LGPL-3.0 and written in C++, and the default branch is dev.

The three downgrade methods it supports

The features section lists the supported downgrade methods, and they differ by device generation. Prometheus is supported for 64-bit devices, in two forms: Prometheus via APNonce recreation with the APNonce generator, and Prometheus via APNonce collision. Odysseus is supported for 32-bit and 64-bit devices in the A7 to A11 range. And there is a third path for re-restoring 32-bit devices to iOS 9.x using alitek123's no-APNonce method, which the readme points at as an alternative to idevicererestore. The distinction between the two Prometheus methods is the interesting one, because APNonce recreation uses the generator to produce a nonce that satisfies the ticket while APNonce collision relies on the nonce generator producing a value that matches by chance, and the readme marks the collision route as unreliable by putting it in the description of the wait option.

Where to get the binaries, and what to read first

The readme leads with a warning to make sure to read the page before continuing, which is a reasonable thing for a tool with this many sharp edges. The stable compiled versions are published as GitHub releases. For devices that support iOS 15, and for WiFi-only iPad restores, the instruction is to use the latest beta build for your platform, which is served from a nightly build link rather than from the releases page, and there are currently no pre-compiled beta builds for Windows. The oldest release tags in the list are old enough to matter, since v194 from March 2021 comes with a title telling people to stop using it and use the nightly link instead. Support is handled through a Discord server, and the compiling instructions live in a separate COMPILING document in the repository, which is where the build details are rather than in the readme.

The option table, and the flags that matter

The usage is a single command line, futurerestore with options and an iPSW path, and the options table is where the tool's behaviour actually lives. The ticket option is the apticket path, the signing tickets used for restoring, commonly known as blobs. The update option performs an update instead of an erase install, which requires an appropriate ticket, and the readme attaches two warnings to it: this parameter is recommended to not be used for downgrading, and if you are jailbroken you must make sure your original filesystem snapshot has been restored. The wait option keeps rebooting until the APNonce matches the ticket, which is the APNonce collision route and is described as unreliable. The debug option shows all code and exists to save a log for debugging. The exit-recovery option exits recovery mode and quits.

The custom-latest family is the part that makes the tool a wrapper rather than a restore script. The custom-latest version option specifies a custom latest version to use for SEP, Baseband and other FirmwareUpdater components, the custom-latest-buildid option does the same with a build identifier, and the custom-latest-beta and custom-latest-ota options pull the URL from the list of beta or OTA firmwares. The latest-sep and latest-baseband options invert the custom behaviour by using the latest signed SEP or baseband instead of one you specify, and the no-rsep option declines to send the Restore Mode SEP firmware command at all.

The Odysseus flags and what they require

A group of options belongs to the Odysseus path and each states its requirement in the description. The use-pwndfu option restores devices with the Odysseus method and the device needs to be in pwned DFU mode already. The no-ibss option covers the Odysseus method as well, and for checkm8 or iPwnder32 specifically the bootrom needs to be patched already unless you have an iPwnder. The rdsk option sets a custom restore ramdisk for entering restore mode and the rkrn option sets a custom restore kernelcache, both requiring use-pwndfu. The set-nonce option sets a custom nonce from your blob and then exits recovery, and there is a second form of the same option that takes the nonce value directly. The serial option enables serial during boot, which needs a serial cable and use-pwndfu, and the boot-args option sets custom restore boot arguments with a caution to proceed carefully, also requiring use-pwndfu. The no-cache option disables the cached patched iBSS and iBEC, and the skip-blob option skips SHSH blob validation, again marked with a caution and requiring use-pwndfu.

The repository layout

The repository is the layout you would expect for a C++ project that vendors its dependencies as submodules rather than pulling them from a package manager. There is a CMakeLists.txt at the root, a build.sh script, a version.txt and a .version file, a src/ directory holding the implementation, an external/ directory for the vendored dependencies, a dep_root/ directory and a fix_dep_root.sh script that presumably repairs that tree, a COMPILING.md with the build instructions, and a .gitmodules file recording where the submodules come from. The .github directory carries the continuous integration workflow, whose status badge in the readme is the one for the ci.yml workflow on the main branch, and the nightly builds that the readme points to for beta versions come from that same continuous integration setup rather than from a release process. The consequence of that arrangement is worth noting for anyone reading the project now, which is that the useful artefacts are the nightly builds and the 2021 release tags are historical.

Where this is the wrong choice

Three limits are worth naming. The first is that the tool does nothing useful without the ticket, since the ticket is what carries the device-specific values that let unsigned firmware be accepted, and a ticket backup is something most owners never made and cannot retroactively create for a device whose values have changed. The second is that the blast radius of a mistake here is a device that will not boot, and the readme's own warnings about the update option, the boot arguments and skipping blob validation are all pointing at the same thing. The third is the platform matrix, since there are no pre-compiled beta builds for Windows and the newer device support depends on the nightly builds rather than on a stable release, so anyone who wants the newer paths is compiling from source or running a nightly. What the project does well is be specific and honest about its methods, naming each technique and linking the reference implementation for the alternative, which is more than most tools of this kind do.

Editorial conclusion

FutureRestore suits a developer or device owner who needs to restore a specific firmware to an iPhone or iPad, in particular to downgrade, and who has the backup of their signing ticket. It is the wrong tool if you want an unmodified restore, because idevicerestore already does that and does it with Apple's own signing, and it is the wrong choice if you do not have the ticket, since without it the tool has nothing to sign the firmware with. It is also the wrong choice if you need a supported workflow, because the readme's own advice is to only use it if you are sure what you are doing. Before running it, read the option table carefully, since the update option is explicitly recommended against when downgrading and the blob validation can be skipped, which the readme marks with a caution. The last push was on 2026-09-13 and the newest tagged release is v194 from 2021-03-02.

Frequently asked questions

What does FutureRestore do that idevicerestore cannot?

FutureRestore is a modified idevicerestore wrapper that allows manually specifying the SEP and baseband when restoring. That lets unsigned firmware be restored onto a device provided you have a backup of the APTicket, the SHSH blobs, because the tool can recreate the specific ticket conditions such as the ECID, the APNonce and the Board ID.

Which downgrade methods does FutureRestore support?

Prometheus for 64-bit devices, either via APNonce recreation with the APNonce generator or via APNonce collision. Odysseus for 32-bit and 64-bit devices in the A7 to A11 range. And a no-APNonce method for re-restoring 32-bit devices to iOS 9.x, credited to alitek12 and described as an alternative to idevicererestore.

Where do I get a FutureRestore build?

The latest stable compiled version is published in the GitHub releases. For devices that support iOS 15 and for WiFi-only iPad restores the README points to the latest beta build from the nightly CI link, and there are currently no pre-compiled beta builds for Windows. The oldest tags, such as v194 from 2021, are marked as superseded by the nightly link.

Official sources

  1. futurerestore/futurerestore on GitHub
  2. License: LGPL-3.0
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/futurerestore-futurerestore.svg)](https://hysenlabs.com/projects/futurerestore-futurerestore)

Was this useful?