Bricked iPhone 16 Can Be Restored Wirelessly Using Another iPhone
(macrumors.com)113 points by impish9208 10 months ago
113 points by impish9208 10 months ago
Everything is a brick until you figure a way to fix it.
I thought I bricked my old phone but it turns out I just needed to open the phone, short a couple of pins 5-10 times and trying to quickly boot into flashboot, repeat if it didn't work.
It turns out I was a fool thinking that it was bricked after all.
Depends on where this process is well-documented: if it is available on iFixit or somewhere super obvious but if I've got to go to xda or some Russian hacking forum, download a bunch of files strictly internal to the company and hope someone made a video about it, then it doesn't matter how "well-documented" it is.
Also it's basically the core of the highly-paid tech expert meme "not paid for turning the screw but to know which screw to turn".
If the issue is not easily troubleshootable and searchable then the keyword for it if the device doesn't reach stage X of boot will always be "bricked".
I don't think I've ever truly "bricked" a iPhone, or got one to the point it CAN'T be put DFU mode and restored. Cydia tweaks made it sound like one wrong move could render your device permanently unusable, at most it was a inconvenience.
Keep trying to de-dramaticize language, you'll get there!
Seriously though, the last time I truely bricked something was because I overwrote the bootloader on a chip that had no other way to flash, and it was an all-in-one, so I couldn't solder to the chip and reprogram it directly. Now that was a brick. A board that I can still solder to a chip and bus pirate my way to victory, isn't a brick. Being able to do so wirelessly? psh.
Edit: I'm remembering now, that hardware was an Apple keyboard. I wanted to flash the firmware so I could have capslock be left Ctrl in hardware, but I flashed the wrong thing and then could not flash an updated image to it.
> I wanted to flash the firmware so I could have capslock be left Ctrl in hardware
You're a person after my own heart. If there is a God, you're doing his/her/their work.
What was the hardware and firmware you were flashing?
I still don't understand why Apple haven't changed their update model to A/B partitions, so if an update can't boot, it boots the previous partition. Android has been doing this for a while and Fedora Silverblue/IoT does the same thing, both of which I've found really useful in the past. If communicated well, it would elviate the update anxiety many people I know have with their iPhones.
It will not be able to reliably work with the A partition once B boots the first time - the update process even for many minor releases will trigger local and cloud data upgrades, and there are security reasons to not leave the option to leave older/unpatched versions runnable.
I don't think I've had a software update fail since iOS 7 beta 1 - and that was an issue with updating local data on first boot, so any attempt to revert to the prior OS without a wipe would have been pointless.
I believe the point isn't to let you rollback at will, but it'll automatically rollback if it fails a boot check, so before anything is written to the filesystem. However, it's worth noting that Fedora Silverblue/IoT let's you rollback at will without problem.
> and Fedora Silverblue/IoT does the same thing,
Silverblue uses ostree, which AIUI uses hard links in a single filesystem. This is probably better most of the time, because it means minimal storage overhead, though it means you can't change filesystems over an update and you don't resist filesystem corruption.
> Apple's latest devices apparently come equipped with a dedicated recovery partition
Didn't they always have this, minus the wireless functionality, isn't that the entire point of DFU/Recovery Mode?
Well, pedantically DFU allows injecting someone else's recovery partition, usually from a computer over USB but probably from Apple's CDN if they have the equivalent of macOS's "Internet Recovery." What I'm guessing this change provides is that the iPhone itself carries a recovery partition, and based on the language allows pseudo-AirDrop-ing it to someone else
Source article iPhone 16 firmware can now be restored wirelessly from another iPhone https://9to5mac.com/2024/09/17/iphone-16-firmware-restored-w...
Needing to connect an iDevice that wouldn't boot to a PC or Mac in order to restore a factory OS image wasn't exactly a high bar to get over, but this does give you another option for recovery.
It isn’t for most people here. But the most valuable tool for fixing a broken computer is a working one, and a lot of people don’t have more than one anymore. Some don’t even have that.
My wife texted me on Friday as she was visiting her mother six hours’ drive away. She needed her laptop. They do not own a desktop, and her dad was at our house on a business trip with his laptop in tow.
Do not underestimate the utility of just outfitting houses that you/spouse spend a fair amount of time at with at least functional computers and such. I put MoCA and three access points in their house as a Christmas gift. It cost me $500 and about two hours of work, but I have never gotten another call about bad WiFi. I bought an AppleTV for their house just to have a Tailscale endpoint. I think they will eventually end up actually using it as an AppleTV, but until then, it’s my door into their network (and another private VPN service for me).
My 2008-era spare laptop isn’t snappy, and it’s not in good shape. But it boots Windows and Linux, and in the absence of anything else it can at least SSH and web-browse, write a USB drive, etc.
> Do not underestimate the utility of just outfitting houses that you/spouse spend a fair amount of time at with at least functional computers and such.
Can confirm the utility - I buy a lot of stuff that lives at my parents house precisely for this kind of reason.
Honestly, that’s mostly been my life for years. I have a laptop I use now and the for programming or a few other little things but I can go months only using my iPhone and possibly iPad. For email, social media, surfing, and other small tasks they work great.
This is for personal stuff. I use a work computer every day, but I don’t use it for personal stuff.
I would not, but quite a lot of HN readers might.
I suppose that if you don’t know how to use the computer as anything more than a tablet with a keyboard and mouse, it probably makes little difference.
Airport security used to go ape when they scanned my personal bag. Nowadays it seems they have largely accepted that yes, two people might need two laptops, two tablets, four phones (primary plus backup for each), two eInk readers, two cameras, at least two USB battery banks, and a giant bag of chargers and cables for everything, but at least I’m not caught flat-footed if things go south.
It’s heavy, it’s not fun to carry, but it does the job. And neither of us works in tech.
This may be an outgrowth that just sort of fell out of their project to allow updating the software on iPhones in the box.
they did that so people wouldn’t buy a new phone that had been sitting on the shelf for a few weeks or whatever and then immediately have to update the OS. By using a special device they designed they can power up and update the phone with the latest OS in the box so buyers are almost always up-to-date when it hits their hands.
But the fact that they did all that probably means that they had everything they needed to do this. Or maybe that’s how they “update” the phone, they don’t update the OS like a user would they just reflash it completely.
Will this not increase the economic value of stealing iPhones?
Right now, in India, iPhone sales compete with used iPhones. With an option to unbrick phones, what methods are preventing a new market of “Chor-Bazaar for iPhones” (market for stolen iPhones)?
Then it's not a brick.
Why is the term "bricked" in the first place?
Because of the utterly dead properties of a brick. The whole point was a visceral image of just how not remotely recoverable under any circumstances, vs merely a little extra effort can recover.
An unformatted empty computer with no os is not a brick in the same way a cd player with no cd inserted is not a brick. It's still fully functional.
Okay, fine, but you're replying in the wrong spot. The point being made here is the difference between broken and locked, regardless of whether it's a little broken or very broken.
No, this is not adding a new version of resetting a device, it's just providing a mode where if your phone is bricked you don't need to find a computer and cable to get back to a working state if you're with someone else who has an iPhone.
The thing the limits the resale/theft value of an iPhone is activation lock - not the ability to reset the device. Resetting or restoring an iPhone does not remove activation lock, and this does not change that.
I am so happy to see a chor bazaar reference here. I got one of my antique SLR cameras from there!
I get the feeling in the future Apple wants to kill the usb c port and lock down the iPhone a access with the proprietary wireless only protocol.
ooh sounds very exploitable!
Would be interested in a deep dive.
How "bricked" is recovery mode? Kernel borked? Like PSP pandora battery?
This looks to be about enabling the "bricked" (as in not recoverable without external tools, in this case) iPhone to receive the recovery image over wireless connection as an alternative to receiving it over a wire. All of the same protections around needing to be a signed image, a device not on Apples stolen/banned list, and needing to be done from an iPhone already asking for recovery (i.e. it's not some state you push wireless TO the device, it's something it requests and other devices can accept helping with) stay in place regardless if the data is received over a wire or now wirelessly. At most the exploitability change here would be in removing the requirement to have another device connected via cable to execute some set of attacks that break the actual security steps.
If that can be done "off grid," then I welcome it because it's likely a jailbreak vector
Not a chance. iOS installs are cryptographically bound to the hardware itself installed on. It’s not possible to get an iPhone to boot an iOS install without an Apple server providing that cryptographic binding.
Almost certainly not affected; even if this new recovery mode had no signature verification at all, you would have to deal with Apple’s impenetrable-since-A12 secure boot.
Well, one will observe that I said "off grid," because I was acutely aware of the desire for them to approve OS reinstalls
I know, "but muh sekurity" and all that, but when the grandkids find an antique iPhone 16 in a barn somewhere, and want to install an iOS image upon it to see how things were in the old-times, I want that to be technically possible even after Apple shuts down the old gatekeeping servers
Curious what you want from a jailbreak at this point? It seems all of the old things that were actually helpful have found them into first party software, or at least in the sanctioned third party. (internet tethering, emulators, side loaded apps, etc.)
I thank goodness I haven't been subjected to (mobile) Apple for many years in order to speak to what they "allow" and don't nowadays, but the short answer is that I want to *fucking own* the hardware I pay fuckloads of money to purchase
Also, while I was typing out the "I want f-droid.org for iOS" I realized there is a pragmatic answer: I want to build and distribute apps without having to pay for the right to do so, not because I am stingy but because paying is gatekeeping. Do you know how much the Joplin devs have to pay Google to put this .apk link here[1]? $0
That’s a web app, it’s on them if they don’t want to offer their services without requiring me to let them out of the web sandbox.
Internet tethering is actually one that's gone backwards, with "unlimited" cellphone plans that are limited when tethering. Or plans that disable tethering even though all the software is there.
The other thing from a jailbreak would be for it to become self hosting, that is, give the ability to make full blown iPhone ipa on an iOS device without needing a macOS device anywhere at all.
> Internet tethering is actually one that's gone backwards, with "unlimited" cellphone plans that are limited when tethering. Or plans that disable tethering even though all the software is there.
The internet tethering limits are in the contract though. Surely the primary goal for jailbreaking isn't just theft of service?
> The other thing from a jailbreak would be for it to become self hosting, that is, give the ability to make full blown iPhone ipa on an iOS device without needing a macOS device anywhere at all.
You can create full-fledged local apps, or publish them for free or sale in the App Store using Playgrounds on an iPad.
The primary limitations are in things like typing speed and screen real estate as well as UX complexity and side-by-side debugging, none of which directly change with an active jailbreak.
> The internet tethering limits are in the contract though.
I don't recognize that 10 GiB downloaded via my phone, or via my laptop connected to my phone as different, no matter what the contract says.
> on an iPad.
I said iOS not iPadOS, but that's good to know.
As someone who does a ton of networking/routing at the link layer for a day job, I can definitely see why they’re taking measures to reduce bandwidth hogs - to the extent I might actually prefer to be on a network that has taken measures to reduce hogging vs one that has not.
When it really truly matters, like when I have a business need to download huge items in remote areas, the $10/GB+ justifies itself.
I have a fairly simple list:
- a weekly, scheduled reboot of the device
- an iMessage addon that can auto-respond with `stop` to every political spam message I get
- an iMessage addon that would let me filter, categorize, and display messages in a manner I choose instead of a Big Dumb List, like we've had for email for decades
- an iMessage addon for services like Beeper
- an iMessage addon that ... I smell a pattern
This is presumably in preparation for removing USB-C next year?
The latest AirPods have usb-c, with the higher tier also including wireless charging. If there was ever a device category to remove usb-c it would be AirPods (which would still be a terrible idea)
I would argue the opposite: AirPods are a pure "client" device — they need to be connected to by something, they don't connect to something; and they have no display, input method, or other means to initiate/change Bluetooth pairing, if the state of the firmware somehow gets in a mucked-up state and they need to be flashed. The only possible way to recover broken AirPods is via tethered recovery.
An iPhone is the opposite: both a "client" and a "host", with plenty of options (in theory) for interactively initiating and configuring a wireless recovery boot. Almost capable enough (again, in theory) to be used for standalone debugging of its own hardware faults (like you'd do with a PC using a live USB image.) For 99% of faults, an iPhone should be capable of non-tethered recovery — if Apple would just write the firmware so as to enable that.
And the other 1% of the time, you've probably got at least one failed critical hardware component preventing early boot. At which point "flashing the OS" would be the least of your concern; and instead, you'd just take the thing into the Genius Bar, and they'd open it up, and then either tap into an interior debugging interface (as presumably they'll leave the lightning debug pins exposed as something like JTAG pads); or they'd temporarily swap the mainboard out into an "everything but the mainboard" recovery harness, flash it there, and then stick it back into the phone. At which point they could then use the recovered base firmware's recovery mode to QC the rest of the hardware!
> if the state of the firmware somehow gets in a mucked-up state and they need to be flashed. The only possible way to recover broken AirPods is via tethered recovery.
There is no process to reflash AirPods, at least one known outside of Apple's official repair channel.
But there's also no way you can diagnose you _need_ such a software recovery mechanism.
USB-C might help if there was a feature to trigger a firmware update, but there is not.
> [iPhone is] almost capable enough (again, in theory) to be used for standalone debugging of its own hardware faults (like you'd do with a PC using a live USB image.) For 99% of faults, an iPhone should be capable of non-tethered recovery — if Apple would just write the firmware so as to enable that.
Sort of. Any diagnostic and recovery tools available at boot time are going to be designed to be non-privileged, so there are a number of things (such as validating the integrity of the encrypted user data partition) that just aren't going to be possible. That locks you down to basically rudimentary hardware validation, but a consumer and even authorized apple repair are unlikely to be able to fix hardware issues that interfere with the main OS boot but allow a recovery process to boot.
> Any diagnostic and recovery tools available at boot time are going to be designed to be non-privileged, so there are a number of things (such as validating the integrity of the encrypted user data partition) that just aren't going to be possible. That locks you down to basically rudimentary hardware validation.
Eh, sort of. Remember that most users have an iCloud Recovery Key enabled. Meaning that Apple could design a non-tethered restore process for iOS that looks like:
1. The device boots into recovery mode; asks the user to configure a wi-fi connection (if none of the ones it has persisted in NVRAM are available.)
2. The device reaches out to Apple, hitting an "I'm a broken device; help me!" endpoint, referencing the iCloud account the device is signed into, and signing the request with the device's root TPM key.
3. Apple validates that the message is from a device that is registered to the given user's iCloud account.
4. Apple sends back a signed payload containing: a device-root-TPM-key-encrypted copy of the device's own disk encryption key (the iCloud Recovery Key), and some amount of "privileged restore" logic (at minimum, just an XPC daemon for the restore image to load and run as root, with a code-signed capabilities manifest that grants the device-shipped client-side of that XPC connection the authority to make changes through it; or, at maximum, a whole second-stage recovery firmware for the restore image to reboot into.)
5. The resulting boot would have the same privileges to modify the on-disk system that an OS firmware update does. But, unlike an OS update, the boot that results by combining this Apple-delivered privileged payload, with the existing restore image, would be interactive. Just like macOS's Remote Recovery image, it would give the user access to some of the same management functionality that Apple would use to repair the filesystem, forensically archive + wipe the disk, repair user permission databases, etc.
6. However, this privileged recovery experience, would still ultimately be a DRMed kiosk experience. (The tool would have full power to access or modify your on-disk system, but the tool wouldn't give you any way to modify the running tool itself. Within the OS of the recovery experience, you're still an unprivileged user. Like running VM software on ChromeOS, where you have root in the VM but not on the host.) Especially, since the disk is decrypted enough to get at the keychain, regular authentication methods could be used to enforce that the device's owner is present and consenting to the repair — i.e. the device could require a "sign-in" with iCloud password + TouchID/FaceID/etc. — just like when first making a purchase on the App Store on a new device. (If the disk is so corrupted that this info is unavailable, then the device could fall back to "authorize with another device on your iCloud account" auth; and if that too wouldn't work, then it'd probably tell you to stop what you're doing and go to an Apple Store so they can identity-verify you.)
7. At the same time, Apple could add special handling into the Secure Enclave for a sort of PKI latch storage type: "anyone with the pubkey can set latch k to a value v; but only a message signed by the associated privkey can modify/delete the latch k once set." Apple could then make this privileged recovery experience do two things once booted:
- Tell the Apple servers "consider me de-activated for now; and require an extended activation — with full remote attestation — to reactivate!" Boot would not proceed until the Apple servers confirm the de-activation.
- Set an on-device TPM latch, using an Apple-provided pubkey.
(These two actions can be atomic, as a "start non-tethered repair session" endpoint, that both marks the device as de-activated, and returns the pubkey for a new dynamically-generated keypair associated with that repair session in Apple's backend.)
8. The latch means that the regular on-disk OS won't be allowed to boot again until this recovery process "considers itself complete" — so you can't break out of it mid-job by hard-resetting the device. And the remote de-activation means that, if you were trying to use non-tethered repair on "some random grey-market iPhone" to wipe it and/or scrap it for parts, the device and/or parts would still be considered stolen.
9. And "extended activation with full remote attestation" means that, when you do finish the recovery process, you wouldn't boot into the regular on-disk OS, but into a special "remote attester" mode (essentially, another type of small-ish factory-shipped recovery volume, that the repair system either has no right to modify, or always puts back after a reformat) that carefully examines and validates the OS to ensure everything is as it should be to enforce security (no rootkits, no jailbreaks) — sending that info to Apple, who then send back activation only if they're happy with what they see. (And if you somehow trick the device into booting into the on-disk OS instead of the remote attester, the on-disk OS will find that it can't activate with Apple; will notice the latch; and will just reboot back to the remote attester to try extended activation.)
Under this tight set of constraints, you can do whatever you need to do during recovery — you have root on the phone! But you're also forced to put everything back into a valid state, before Apple will be willing to "release" you from that mode back into regular use of the phone.
(Amusingly enough, Apple could even let this repair image totally break the "paradigm" that iOS normally operates under. The repair image could expose Terminal.app. The repair image could display a desktop when connected to HDMI. Heck, for the iPhone 16, the repair image could be a somewhat-neutered copy of macOS [similar to macOS Recovery] running on the M-series processor, where you're expected to connect a keyboard/mouse/display to it using a USB-C dock! As long as that sort of stuff is only available in this repair experience — and this repair experience is in turn useless as a phone [or as a general-purpose computer] — then exposing these capabilities during repair wouldn't be sales-cannibalizing.)
Also, if you think about it, this is in spirit basically the same "workflow" as Apple's Self Service [Hardware] Repair process — but without the series of phone calls being required to validate that you're actually someone who was asked to repair that device (instead of some rando who bought the phone on the grey market) and to sign off on your repair "session" as completed at the end.
In this case, you're repairing your own device that Apple knows you own because it's listed on your iCloud account, so Apple already has all the info they need to auto-authorize the "repair"; and you're purely doing a firmware/OS repair, not a hardware repair, so the device itself can do the "signing off" at the end.
> I would argue the opposite: AirPods are a pure "client" device — they need to be connected to by something, they don't connect to something; and they have no display, input method, or other means to initiate/change Bluetooth pairing, if the state of the firmware somehow gets in a mucked-up state and they need to be flashed. The only possible way to recover broken AirPods is via tethered recovery.
Huh?
The charging case (which is an integral part of the system known as "Airpods") has a display (LED indicator) and an input method (a pushbutton).
I'm not so sure. One of the potential benefits of removing ports from the iPhone is improved water resistance (personally, I'd still rather have the port). I don't foresee going swimming with my AirPods case.
I think a big part of the reason (maybe the only reason?) they went to USB-C is because they were legally compelled to by European regulations, not sure if they can then about-face on that just by removing the port.
> think a big part of the reason (maybe the only reason?) they went to USB-C is because they were legally compelled to by European regulations
It wasn't the only reason, it was inevitable even without the regulations. They'd already switched their laptops to USB-C in 2015 (?), and the iPad in 2018. The phones and some accessories (keyboards, mice, charging cases for AirPods and such) were the last remaining Lightning devices. All the regulations did, if anything, was set a deadline that was probably internal no more than one or two years past when they made the switch.
They didn't switch normal iPads until 2022.
I really don't understand the argument that it was inevitable when they spent more than five years shipping lightning on phones and most iPads and USB-C on laptops. Maybe they would have switched on their own, maybe not. But they were clearly not just moving USB-C through their product line piece by piece, or everything would have had it many years earlier.
The problem is that other than faster charging, the vast majority of people would not see USB-C as an upgrade, and instead a play to make them buy new cables and chargers. Even though Apple had switched over to exclusively bundling USB-C to lightning cables with the iPhone 11 (2019) and usb-c to MagSafe for Apple Watch Series 7 (2021), a USB-C port on the device does not in itself provide a clear advantage for migration - Apple switching could just be seen as a play to get everyone to buy new cables and chargers.
Even after the switch to USB-C, it blows my relatives' minds when I explained you could plug a USB flash drive into the phone directly. It is just a charging hole for most.
My hypothesis is that they were already planning to go to USB-C on the pro models last year an then trickle it down to the base model 1-2 years following - the SoC was updated with USB 3 features like 10 Gbps data transfer and DP alt mode, and they had software features like capturing 4k video directly to a connected external SSD. The base 15 was left on an older SoC due to cost/yields at TSMC.
Europe may have moved them to upgrade the base model 1-2 years earlier. However, by doing such a migration "begrudgingly" Apple got to use Europe as a little bit of a scapegoat in the press. The forced migration is the answer to the upset questions about the migrating generating a lot of e-waste in terms of obsolete cable and accessories, and in the consumer cost of upgrading a decade of old chargers and lightning cables around their homes, vehicles, offices, etc.
I'm not sure? what is the threat you're concerned about here?
My reading of this is that it's just removed the requirement to use a wired connection to a laptop to restore a phone that is already in DFU/restore mode - I'm not sure what attack/flaw you get from allowing the recovery path over wifi that would not already be an option with the existing wired path?
Well, IF you have an exploit capable of bypassing all iPhone security you could now use it by setting something on someone’s phone for a few minutes instead of plugging into it.
Is that useful? Maybe. No fingerprints?
Of course you still need that billion dollar exploit first.
You can't bypass "all iPhone security" - this is a restore path: the phone is already in a state where it cannot boot, and cannot access user data. Once an iPhone is in a restore state (restore mode or DFU which afaict are only marginally different) it cannot do anything except install a new OS. If an iPhone is in a restore mode it is not in an "update the device mode" it's in a "the OS is dead and the user data is gone by default".
There are _some_ restore paths it is possible to not lose all of the data on the device, but that requires the user (on the device) to provide their passcode during the restore, and I think even requires their iCloud password to get through activation lock, and it takes like an hour to complete.
There's fundamentally no reason that this should be less secure than the existing state where restore requires a wired connection to a laptop.
Right. I was saying hypothetically if you had a big enough chain of exploits for all the various protections Apple has then this may let you use them without physically touching the device, only being really close.
But if you had that chain of exploits, who cares. You already won the game.
So I don’t think this matters to security.
It _sounds_ like this is just the standard restore path, only now it can be done wirelessly. Restore/DFU is an erase all content path - there are some cases where restore can avoid erasing the old data, but that path requires the device pin, and if you know the pin, then you definitionally don't need to jump through any hoops to unlock the device.
iOS restore doesn't trust anything; that's why you need an internet connection to do it. This proxies the internet connection.
https://support.apple.com/guide/security/secure-software-upd...
As a former hardware engineer, if it can be restored wirelessly or otherwise, it's not a brick yet. Keep trying, you'll get there! ;)