Bricked iPhone 16 Can Be Restored Wirelessly Using Another iPhone
macrumors.com
macrumors.com
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.
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?
You could just swap caps with one.
> Why not use an empty modifier and have your own shortcut keys that you can guarantee no other program uses?
Because that would require messy tinkering with multiple layers of software.
my point was that there was not "official" procedure to verify, I told him the story, he believed me, and went in the back and reset the password or something. They have the capability if they want to. He was a manager I think, and I didn't get to him through the reservations queue, I just walked up to the counter to find out if this was the place I should go, and after I asked my question he took an interest and solved the problem for me.
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.
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".
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.
I’ve had iPhones since the 3GS and never experienced it, neither have anyone I’ve known.
I’m sure it happens, but I suspect it’s really rare.
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.
Didn't they always have this, minus the wireless functionality, isn't that the entire point of DFU/Recovery Mode?
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.
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 is for personal stuff. I use a work computer every day, but I don’t use it for personal stuff.
Previously, you just needed temporary access to a computer with an internet connection.
How the heck does that work?
An acquaintance bought a place in the mountains, and his wife was unhappy that they had to have separate Hulu, Netflix, whatever accounts for their primary residence and the vacation home because they don’t always go there together. Not so much for the cost, because they can easily afford that, but because all the where-did-I-stop-watching or have-I-seen-this data didn’t carry over.
I told them about Tailscale on AppleTV as an exit node. They already had them at both homes, it was just a free app install. Now it’s all coming from the same IP at their primary residence. Symmetrical 1 Gbps fiber, so it’s not a big load.
Very cool it’s possible.
Can confirm the utility - I buy a lot of stuff that lives at my parents house precisely for this kind of reason.
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.
All iOS devices have secure boot that (unfortunately) can't be disabled.
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)?
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.
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.
Would be interested in a deep dive.
How "bricked" is recovery mode? Kernel borked? Like PSP pandora battery?
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
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.
When it really truly matters, like when I have a business need to download huge items in remote areas, the $10/GB+ justifies itself.
And video streaming, probably most people's biggest bandwidth use, fits very well on phones.
Does anyone offer a tethering plan that's rate limited but not data limited?
T-Mobile in the US; they give you a set amount of high-speed tethering based on your plan, then it rate limits severely until the end of the billing cycle unless you upgrade your plan or buy a a pack of data.
Though with how happily and loudly they've made 1.5Mbps video excluded from data caps, it would be better if the throttled speed was at least 1.5Mbps.
My problem with this is that it's the wrong measure.
There's no good technical reason to shape traffic to a specific rate irrespective of network conditions or capacity. All of the links in the chain support QoS.
Shaping a bandwidth hog to a tier below the rest of the users makes sense, but that's not what's going on.
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.
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.
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
Now, if you're trying to be extra cute by saying "react native is a webpage with more steps," I'm not trying to have that fight, but I can assure you with 100% confidence that Joplin's apk loads without Internet connectivity, making it not meet my definition of "a web app"
And you can 100% load PWAs offline, which might be slightly more progressive than your idea of a web app, but I hope not overly so.
Whether or not the specific app used as an example happens to be a webapp holds no relevance to what he was saying overall.
- 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
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!
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).
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.
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.
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.
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.
1. Keep using Lightning
2. Update Lightning
3. Switch to another proprietary connector
4. Switch to a standard but non-USB-C connector
5. Switch to full wireless
6. Switch to USB-C
(1) Makes no sense, they were going to switch to something eventually. If anyone doubts that and thinks Lightning was going to stick around forever, they don't live in the real world. It's so far from reasonable it's not worth considering. Lighting is worse than USB-C for data rates and power, it was outdated years before they made the switch.
(2) Could have made sense but they would have done it earlier if it was in their plans. They could have done that around '20-'21 and given a "Look, see, our new connector is 10x faster than USB-C and fast charges in half the time!" But it would have to match or beat USB-C to make any sense. Maintaining compatibility does means people still get to use old cables with slower charging and data rates for a while until those cables break or get lost, and it means the new cable can still be used with old devices (but will drop to whatever data and power rates they support). It also means Apple has to have, for the iPhone only, an extra team maintaining an extra connector type not used by anything else.
(3) Same issue as (2), but this one has to beat USB-C. And switching to a different proprietary connector means their customers now need at least 3 cables (4 for Apple Watch users, but those folks have to have at least 2 cables anyways since that one is wireless charging only). Users would need Lighting for accessors/peripherals, USB-C for iPad, MBP, and <new proprietary> for a new iPhone. That would go over well.
(4) Same problems as (2) and (3) but at least it's standard. It also has to beat USB-C and what connector would they use that's standard, popular, and not USB-C?
(5) Not viable for the phones. Too many consumers expect their phones to connect, physically, to cars and headsets. Without a 3.5 mm jack that leaves the Lightning, and now USB-C, connector. With cars, unless you have wireless CarPlay (newer cars only) you're SOL for CarPlay, and it's a downgrade to lose that and end up with just audio over Bluetooth. This hurts them substantially in the market and is non-viable. In 5 years, may be a different story.
(6) They already switched to USB-C on pretty much everything else. It opens up every USB-C peripheral (most of Apple's own are already wireless, with Lightning or USB-C to charge, increasingly USB-C). It's the standard connector. It offers fast charging and higher data rates. They already have licenses and contracts in place to use it. They don't have to dedicate an engineering team to support a one-off variant.
(6) is the most sensible option followed by (2). (2) should have happened years ago if it was in their plans. The regulations may have moved up the timeline, but it didn't change what was going to happen.
So what's your argument, which of the non-USB-C options do you think was on Apple's agenda before the regulators came calling? Given that they'd already switched almost every other device in their lineup to USB-C, what was Apple going to do with the iPhone?
I think your argument against 1 is flawed, because I can say the same thing about USB-C, that they won't use it forever.
Or in other words, I pick (1b), they likely, not for sure but likely, would have kept using lighting until the same year they end up switching away from USB-C, whenever that may be.
In the future we might see (4) or (5). I note that you also think (5) might happen in a while, so your reasoning is compatible with (1) in the short term followed by (5) in the longer term.
Being able to share 1 cable type for charging laptops and phones and data transfer Ana basically everything else is pretty useful/convenient.
On the new Pro phones they have been heavily marketing the capability to record ProRes Log video to external USB C 3.1 drives (something not supported recording to internal storage and that Lightning was too slow for)
When they replaced 30-pin with Lightning, they announced it with "this is our connector for the next 10 years". Now it's been 10 years. Simple as that.
It did happen. They added USB 3 5Gbps speed to the lightning port on the 2015 iPad Pro, requiring the lightning to usb 3 camera connector kit.
In 2019, they bundled usb-c to lightning cabling and a usb-c charger with the iPhone 11 and 11 pro. The hardware was updated to support USB-PD, and the USB-C to Lightning cables increased the max wattage over the USB-A variants from 18W to 30W.
But outside pro usage, the port doesn't need USB 3 speeds - in fact, unless they purchased an external hard disk I don't believe most people own a cable capable of USB 3 data speeds. The biggest benefit is Amazon gets to sell a charging cable that costs a few cents less to produce.
It is perhaps worth noting that the USB-IF and Apple had a "complex" relationship for many years, and to this day Apple still doesn't sell a single 1st party device or cable which is USB certified.
Did they? I thought they only moved to USB-C with the iPhone 15 in 2023. Thats what Wikipedia shows me as well.
Edit: Oh you mean the _charger_ was USB-C with a USB-C to Lightning cable. The actual phone didn't get a USB-C port until iPhone 15.
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.
what could go wrong
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?
Is that useful? Maybe. No fingerprints?
Of course you still need that billion dollar exploit first.
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.
But if you had that chain of exploits, who cares. You already won the game.
So I don’t think this matters to security.
https://support.apple.com/guide/security/secure-software-upd...