FourTools iOS Recovery — a project by Ahsan Mahmood
A cross-platform Tauri 2 desktop suite that helps owners recover access to their own iPhones, iPads, and iPods.
You own the device and you cannot get into it.
That is a real situation with a disreputable search history attached to it. The same handful of words describes somebody recovering an iPad that spent two years in a drawer and somebody holding a phone that is not theirs. Every tool in this corner has to decide which of the two it is built for.
FourTools iOS Recovery decides it in the software rather than in the marketing.
Runs are gated on a server. A licence is activated and a preflight check passes before the desktop application will touch a device at all. The acceptable-use and stolen-device rules are enforced there rather than printed in a document nobody opens.
Enforcement that lives in the client is enforcement a user can delete.
The desktop half is Tauri 2, a Rust core under a React interface, shipping in five languages: English, German, Spanish, French and Japanese.
Most of the design effort went into one wizard.
A guided DFU restore removes a passcode, with per-model animations, because DFU is a sequence of button presses that differs between devices and a static instruction is the wrong shape for it. Getting it wrong only puts you back at the beginning, which is tolerable once and infuriating on the fourth attempt.
Two paths leave the contents alone.
Screen Time and Restrictions passcode removal clears the passcode without wiping the device, and an MDM enrollment-screen bypass covers the small business that has lost the credentials to hardware it bought outright.
Underneath sits the part that is genuinely hard.
17 Rust crates wrap the libimobiledevice and idevicerestore C stack through bindgen FFI, and IPSW download carries TSS personalisation with signature verification rather than trusting whatever file happened to arrive. A Rust CLI drives every orchestrator headlessly, so the desktop application is one caller rather than the only one.
A Go backend handles licensing, telemetry, billing and the refusal rules, with PostgreSQL, Redis and OpenTelemetry behind it, and Next.js front-ends for the operations side.
Now the part that decides whether this page is honest.
It is early stage. The architecture, the crates, the services, the continuous integration and the interface all build and run against a mock device backend. The real on-device path is gated on two things I have not done: vendoring the LGPL C libraries, and validating against physical hardware.
So nothing here has recovered a real device yet. Not one. The gap between a mock backend and a phone in DFU mode is where projects of this kind usually find out what they got wrong.
What it cost is the promise.
The truthful answer to a lot of these requests is no, and what is possible depends on the chip generation in the device you are holding. A tool that says so at the start loses the sale that a vaguer one would take, and I would rather lose it there than at the end of a restore.
That framing is the actual product, more than any single wizard is.
There is no public link here. The project is not publicly reachable, and there will be nothing to open until the on-device path has been validated on hardware somebody can watch.
A monorepo in three languages is also a cost worth naming.
Rust for the device work, Go for the services, TypeScript for the interfaces, and one person moving between all three. Each boundary is a place where a change has to be made twice, and the reason to accept that is that the alternative was doing the C interop in a language that would have to reimplement it.
Read the refusal rules before the feature list. They are the part that decides what this is.
What it does, and what that costs to build
- Guided DFU passcode-removal restore with per-model animations
- Screen Time / Restrictions passcode removal without wiping the device
- MDM enrollment-screen bypass for lost small-business credentials
- IPSW download with TSS personalization and signature verification
- Developer CLI driving every orchestrator headlessly
- Server-side license activation and run preflight gating
- Acceptable-use and stolen-device refusal enforcement
- Five-language UI (English, German, Spanish, French, Japanese)
Built with
- Rust
- Tauri 2
- React
- TypeScript
- Go
- PostgreSQL
- Redis
- Next.js
- Tailwind CSS
- Radix UI
- OpenTelemetry
- bindgen FFI
Worth knowing
- ios-recovery
- tauri
- rust
- golang
- desktop-app
- dfu-restore
- monorepo
- device-recovery
Who built FourTools iOS Recovery?
Ahsan Mahmood built it, as a single monorepo holding Rust, Go and TypeScript. The desktop application is Tauri 2, a Rust core under a React interface; the device work is 17 Rust crates over the libimobiledevice and idevicerestore C stack through bindgen FFI; the licensing and enforcement side is Go with PostgreSQL and Redis behind it. There is no public link on this page, because the project is early stage and there is nothing yet for a reader to open and check.
What does it refuse to do?
Run against a device somebody else owns, as far as the software can tell. Licence activation and a run preflight happen on the server rather than in the desktop application, so acceptable-use and stolen-device rules are enforced where a user cannot simply edit them out. That is a deliberate architecture choice with a cost attached: it means the tool needs a working connection to start a run, and it means the enforcement is only as good as the checks behind it. Both of those are better said than discovered.
Does it wipe the device?
That depends which path you run, and two of them are built specifically not to. The guided DFU passcode-removal path is a restore, with per-model animations because the button sequence differs by device. Screen Time and Restrictions passcode removal is described the other way round: it clears the passcode without wiping what is on the device. The MDM enrollment-screen path addresses a business that has lost the credentials to hardware it owns. Read which one you are about to run before you run it.
Can I point it at a real device today?
No. Everything currently builds and runs against a mock device backend, and the real on-device path is gated on two things that have not happened: vendoring the LGPL C libraries, and validating against physical hardware. So the architecture, the crates, the services, the continuous integration and the interface are all real and exercised, and no phone has been recovered by it. Saying otherwise would be the easiest claim on this page to make and the most expensive one to be caught in.
Why is there a command-line version as well?
So that every orchestrator can be driven headlessly, without the window. A Rust CLI called fourtools runs the same operations the desktop application does, which matters twice: a technician can script a repeatable sequence instead of clicking through one, and the orchestrators are forced to stay separable from the interface that usually calls them. A tool where the only way to run the logic is the graphical front end is a tool whose logic and window have quietly become the same thing.
https://aoneahsan.com/projects/com.aoneahsan.fourtools