How a single line of code could brick your iPhone

Facebook predates iPhones by 3 years.

Only sensitive notifications require an entitlement. Tracking wasn't mitigated.

I think it’s most interesting for 3rd party SDKs (analytics, advertising, others?), because they’re in a position to have their code running in apps from different vendors.

> There's physically no way to permanently "brick" an iPhone.

There definitely are (If you count jailbroken iPhones). I've managed to brick one by removing all thermal throttling limits and subsequently damaging the motherboard with the world's shittiest watercooling setup.

Can't use DFU to restore if you've got damaged hardware

> There have even been stories of peoples' computers being bricked via rm -rf /

I would expect that most systems should be recoverable from this state with a CMOS clear.

"physically" is overstating it. Certainly during development it's possible, which means that -- conditioned on a bad enough bug -- it could hypothetically happen to customers too. Not that I think that's likely, of course, but it is physically possible.

Right now someone in Fort Meade is falling off their chair laughing...

I'm gonna walk through this because I have a bit of experience here on the computer side of things, but I'm not really making an excuse for the fact that the PC version of this is less user-friendly; from my perspective, I fully respect that Apple has done a good job with user experience where PC manufacturers have lagged. However, my main concern is devices turning to e-waste, so the important thing for that isn't UX, it's just how plausible it is to recover once you've bricked. With that out of the way...

> This is in contrast to some PCs, where if you damage the BIOS (e.g. by suddenly losing power during a firmware update), your device may or may not be bricked.

I accidentally destroyed the firmware on a machine that did not have any recovery features, when flashing modified UEFI images, leaving it mostly inoperable. I wound up recovering it using flashrom and a Raspberry Pi. I think this counts as a hard brick, but the modular nature of PCs (e.g. most BIOS chips are on sockets so you can pull them out easily) it's not nearly as big of an issue if you hard-bricked a device that's more integrated and locked down. It's not instant e-waste because no bricks are permanent.

(It's a little harder for laptops, but I did also flashrom a laptop in a similar fashion, in-circuit using a SOIC8 clamp. This was not a brick recovery but rather messing with coreboot.)

Definitely not as much for the faint of heart, but a repair technician could do it for you. Alternatively, for PCs with socketed BIOS, you can buy a new EEPROM that's already flashed with the right firmware--they were readily available on eBay last I looked.

That was probably a decade ago or more by now. Many modern PC motherboards from many vendors have mitigations for this; it was a common enough pain point after all. For example, my desktop PC has an embedded controller that can boot and rewrite the flash chip for you, using a copy of BIOS from a USB stick. (Works even if the CPU isn't installed. Pretty cool.)

> There have even been stories of peoples' computers being bricked via rm -rf /, due to removing everything at /sys/firmware/efi/efivars/ (which is actually stored inside the motherboard), and sometimes contains things that the motherboard won't boot without

EFI vars are stored in NVRAM, not the EEPROM. You can usually clear that a couple of ways:

- Use an integrated NVRAM reset system. Some machines have a way to do this listed in their manual. On desktop PC motherboards, it tends to be a jumper you set for a few seconds. Sometimes you will have an easier option, like a button somewhere, or even possibly a key combination at boot (Long time Macintosh fans probably have memorized the NVRAM reset key chord for Apple computers... I wonder if it still works on Apple Silicon.)

- Remove the battery for a few seconds. Usually easily accessible on a desktop. Usually a little less easy to get to on a laptop, but nothing absurd, usually just some screws.

Certainly it could be easier to recover from, I'd say it's actually not very easy to brick a typical desktop PC in a particularly permanent fashion. The only time I've ever done it was because I was modifying my UEFI image intentionally. Screwing up EFI vars doesn't make most systems unbootable. I have corrupted my EFI vars quite a few times trying to do funny things. UEFI implementations do tend to be buggy, but not all of them are that catastrophically bad.

--

Now... as for whether or not an Apple Silicon device can "physically" be bricked by software, the most obvious way to do that would be to wear the SSD down to the point where it can no longer be rewritten. I think the M4 Mac Mini finally no longer solders these and that the Mac Minis do have a way you can recover from this brick (using another Mac to restore to a new SSD) but there are many Macs where if the SSD is destroyed, it's pretty hard to fix since you need Apple tools that are hard to obtain if you want to pair a new SSD. This is unfortunate because Apple has often had dodgy hardware choices around the SSD (e.g. the notorious TPS62180 buck converter) and doesn't always use SSDs that have the best reliability (IIRC they use a lot of Kioxia in the newer Apple Silicon devices, which are not considered to be bad devices by any means, but are generally considered less durable than e.g. Samsung SSDs.)

Rather than have an Apple device become ewaste due to software issues, in recent years, it is much more likely that it will become ewaste due to hardware issues, as a result of parts pairing and having failure-prone components that are not modular even when they really can and should be (Good on them for rectifying this lately, e.g., with the Mac Mini SSD, but it's a bit sad that it took this long. And on the note of that SSD... Apple, you really could've used a standard electrical interface for that.)

This is somewhat a testament to Apple's software and system design, but it's simultaneously a condemnation of their recent track record with repair, too. Best we can hope is that they don't go backwards from this point forward, because they created a lot of devices that will become ewaste over time for almost no gain for anyone. (I strongly dislike but can understand the justification for something like parts pairing in iPhones and iPads, but much less so for similar sorts of mechanisms in computers.)

rm -rf is nightmare, if used mistakenly. I myself have been victim of this.

https://news.ycombinator.com/item?id=43775027

[flagged]

And for that reason I wouldn't hassle laymen over it but among the HN crowd I expect a bit more care. An "anything goes" attitude makes communication more difficult.

"Soft brick" is the correct term that already exists.

Also, although HN readers probably have many devices in their homes there are people out there who have only a phone and no computer. For them this would be pretty catastrophic. Hopefully they’d take their device to Apple or a third party technician

Almost like a "soft"-brick, if you would.

Ah yes, the Goebbels effect, also known as "A lie told a thousand times becomes the truth."

Incorrect. Bricking means a device becomes a doorstop that cannot be resurrected or repaired by the user non-invasively. That's the whole point of the term.

It doesn't just force a reboot, it forces a never-ending loop of reboots, rebooting each time you reboot it.

> The result is a device that’s soft-bricked, requiring a device erase and restore from backup.

Requiring a device erase isn't a full brick, no, but it's still pretty serious.

is this the one: https://news.ycombinator.com/item?id=43025038

Probably one of those https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

They wouldn’t, especially considering they aren’t operating anymore.

It was actually almost 3 decades ago, making me feel extremely old - the period right at the end of '96 and into mid '97 when this was a popular way to cause mischief via IRC was truly a magical time

When I was in college circa 2001 we used to prank each other with the ping of death and other crash exploits. Also random IPs on the college network when we were bored. It was crazy how long it was around for and how easy it was to exploit.

DOS yes, but that freebsd cve I referenced is a theoretical RCE.

This link doesn’t show me anything useful.

Only if their modem didn’t implement the Hayes command set properly or you could otherwise control the per-character timing of the OS sending. It required a pause (1sec by default), “+++” with no pauses, another pause, _then_ the ATH command

I’m too lazy to look it up but there was some string you could send over IRC that would make some routers drop the connection immediately - if you pasted that string in a big channel you would see dozens of people immediately disconnect.

I remember you could brute force passwords by brute forcing in sequence single characters to access anyone’s disk on a giant dialup network. Crazy times.

Hilariously, the PPP (Point-to-Point Protocol) is still used in modern IoT modules. It is actually the only way to run your own TCP/IP stack (and maintain control over TLS), as not all modules support QMI or MBIM.

This is an internal broadcast notification API (akin to dbus on Linux), distinct from the API used to display notifications to the user.

Wasn’t it in OS X before that?