Hacker News new | past | comments | ask | show | jobs | submit login
Bricked iPhone 16 Can Be Restored Wirelessly Using Another iPhone (macrumors.com)
113 points by impish9208 73 days ago | hide | past | favorite | 119 comments



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! ;)


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.


Sure, but shouldn't there be a minimum standard like "the built-in and well-documented recovery process failed?"


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.


You can very easily brick an iPhone by logging in to an iCloud account and then forgetting the password (which of course TFA will not help with)


if you go into an apple store, they can fix that for you. might help if you look... i dunno, middle aged?


Does it still work if you're not the original retail customer?


i was not the original retail customer, it was a phone used by a small business that I had owned, the employees were not good about keeping track of stuff like that, they'd use their own personal deets to sign up for business things all the time.

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.


Did you have receipts or any other way to prove that you/the business you owned purchased the phone?


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?


Why have three Ctrl keys? Why not use an empty modifier and have your own shortcut keys that you can guarantee no other program uses?


> Why have three Ctrl keys?

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.


From memory, Linux has spare modifiers. You can see them using xmodmap. It's easy to assign shortcuts using them.


It was one of those wireless Apple keyboards, and I thought I had the settings right, but it turns out I didn't.


semi-brick


Brick Different!


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.


What percentage of iPhones actually require DFU after a bad iOS upgrade?

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.


> 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.


How much space should they reserve for iOS 24?


Sell the base 128GB model that will be too small pretty soon and sell the cloud storage. Win win.


How often does a deployment rollback go smoothly? Almost never. The priority is roll-forward and reduced error scopes.


> 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.


You would be amazed how many normal people dont have a computer - they have an iPad and an iPhone (or android similars), and yeah - its like that now.


You didn't have to be the owner of the computer.

Previously, you just needed temporary access to a computer with an internet connection.


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.


> I bought an AppleTV for their house just to have a Tailscale endpoint.

How the heck does that work?



Very interesting. Thank you.


It’s extremely useful. I barely use most Tailscale features. But exit nodes? Oh yeah.

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.


It’s pretty new, IIRC. In the last year or two.

Very cool it’s possible.


this is the sort of functionality that only appears when the pain in the retail is felt by the corp. though can't say I think it's a good idea though.. feels like a free rein for state level adversaries...


Presumably the signing requirements are the same as the normal USB DFU process?


> though can't say I think it's a good idea though.. feels like a free rein for state level adversaries...

All iOS devices have secure boot that (unfortunately) can't be disabled.


Most ;)


Some have vulnerable bootroms, yes, but I doubt those can use this new restore process anyway


At smaller scale if a problem affects 1 out of 100,000 customers you just eat it. But at Apple's scale and profit margin they can afford to fix it.


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.


Not bricked if it can be fixed.


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)?


Bricked as in doesn’t boot the OS, not bricked as in unable to be activated.


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.


Pretty sure this doesn't remove Activation Lock so it shouldn't make a difference


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!


India have a lot of carriers that don't care about stolen IMEIs?


Funny nobody is asking why a flagship gets bricked in the first place. Also, the author probably doesn't understand the meaning of brick. Bricked means bricked. Dead beyond recovery without doing some extraordinary stuff.


I've never heard of a "bricked" iPhone. I didn't think you could flash its firmware outside of official methods so how exactly would you brick it?


You can always have something (e.g. overheat, battery failure, cosmic ray, …) go wrong during an "official method" and leave it in a bad state.


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.


Assuming it's implemented properly, that is. The whole reason Jailbreaks exist is due to bugs in Apple's implementations.


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


That's not possible because the requirement is built into the ROM. They'd have to release the keys and then you could emulate it.


And just like the original PSP’s batteries, you would be able to jailbreak an iPhone simply using a jailbroken iPhone.


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

1: https://joplinapp.org/help/install/#mobile-applications


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.


I presume you didn't follow the link I pointed to, which for sure points an .apk URL

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"


I did in fact follow the link. I actually went further than you, all the way to the GitHub, where I saw that it was actually just a web app. All TS.

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.


Wow, you have completely missed the parent poster's point!

Whether or not the specific app used as an example happens to be a webapp holds no relevance to what he was saying overall.


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.


Ironically, downloading huge items is easy to do without tethering.

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?


> 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.


Okay, 600kbps is acceptable. Beats a lot of networks. Things are improving since I last checked.

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.


Verizon after 60GB is 600kbps on 5G/4G but up to 3Mbps on UWB. Pretty reasonable IMO. It’s AT&T that’s the holdout, 128k regardless of plan, after 60GB.


> they’re taking measures to reduce bandwidth hogs

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.


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.


Apple started shipping exclusively USB-C cables/chargers with iPhones with the 11 in 2019. There's certainly a case to be made that they should have done that earlier (iPhone X or even back with the iPhone 7).

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.


>Apple started shipping exclusively USB-C cables/chargers with iPhones with the 11 in 2019.

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.


There are really only six options:

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?


> (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.

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.


Well they're not going to switch just for the sake of switching. USB-C has no capabilities that they care about compared to lightning (for phones), that's why they didn't change for so many years. It's just more compatible, and they didn't care about being compatible.

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.


> USB-C has no capabilities that they care about compared to lightning (for phones)

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.


If a specific time promise was the main motivation to stick with lightning, they could have easily said that. I've never seen anyone bring up that mention of ten years before.


> USB-C has no capabilities that they care about compared to lightning (for phones),

Being able to share 1 cable type for charging laptops and phones and data transfer Ana basically everything else is pretty useful/convenient.


Right, but that falls under being compatible, and has been true since about 2015.


All of this is just rationalizing, you know that, right?


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.


The regulation doesn't require having a port I believe. Just that if there is a port, it's USBC.


I interpreted it to mean it must have a USB-C to charge, not that _if_ it has a port it must be USB-C. Then again I'm not an EU regulations lawyer so thats just my interpretation.


Imagine the ramifications of this. I’m not a technician for any secret agents but I can see how this will make black hat attendees very excited.


Yeah that they are confident enough in their chain of trust to allow this says a lot I think


w o w

what could go wrong


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.


Locked iPhone owned by law enforcement target will accept remote firmware push from trusted device?


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...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: