How a single line of code could brick your iPhone

https://rambo.codes/posts/2025-04-24-how-a-single-line-of-code-could-brick-your-iphone

351•sashk•16h ago

Comments

_rrnv•14h ago

Great work! This is my favourite type of vulnerability, simple, effective and brutal. Reminds me of a time two decades ago when with a friend from uni we theorised about a perfect server vulnerability where you’d exploit a machine by pinging it. And of course, two years ago it was in fact discovered as CVE-2022-23093.

Rygian•14h ago

Ping of death was already a thing two decades ago.

https://web.archive.org/web/19981206105844/http://www.sophis...

dgfitz•12h ago

This link doesn’t show me anything useful.

giantrobot•12h ago

Try scrolling down. On mobile (maybe because of ad blockers) Wayback pages have a full screen of white space above the page contents anymore for me. This happens on pretty much every Wayback page I've tried. It's also relatively recent and I'm not sure the exact cause.

jasongill•11h ago

Try https://insecure.org/sploits/ping-o-death.html

jasongill•11h ago

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

anyfoo•9h ago

Hard to believe that during those times in IRC, you were used to automatically (and proudly) advertising your IP address, your exact client version, and the means for a direct connection to your client without any server in between (CTCP, literally “client-to-client protocol”). And all of that most often with no packet filter whatsoever, not even NAT, in between.

Everything was plaintext, including “authentication”, which was (at best) just asking the “ident server” on the same machine as your client who you claimed to be, which was considered sufficient because, after all, to run identd on its “privileged” low port meant you were an “administrator” (i.e. root of a unix machine).

sneak•4h ago

CTCP messages still go through the server. DCC (direct client connection) are the p2p connections you are thinking of, but they of course don’t work behind nat.

I was behind NAT when I first got on IRC in ‘98. I set it up with ipfwadm.

chasd00•9h ago

Death on flaxxen wings

driverdan•10h ago

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.

_rrnv•3h ago

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

NitpickLawyer•12h ago

Back in the dial-up days you could disconnect someone by adding ATH commands to a ping payload field.

brontitall•12h ago

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

wat10000•12h ago

Which was fairly common, as Hayes had a patent on those pauses.

brontitall•12h ago

Huh, TIL. I guess they might have used TIES

https://en.wikipedia.org/wiki/Time_Independent_Escape_Sequen...

NitpickLawyer•12h ago

I had an external USRobotics 56k modem, I was immune. But the many many "bulk" no-name modems were vulnerable. You could ping entire ranges of dial-up IPs and watch the results on big IRC channels. Uhmmm, allegedly :)

mycall•11h ago

Commas provided 2 second pauses

brontitall•11h ago

Only in the dial string to ATD, surely?

cryptoegorophy•12h ago

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.

bslanej•11h ago

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.

aaronmdjones•11h ago

An 0x01 control character (CTCP) followed by

    DCC SEND whatever 0 0 0

https://modern.ircdocs.horse/dcc#dcc-send

This caused the DCC ALG helper in ancient Linux kernels to close the connection, as they failed to parse 0 as a valid IP address. Users connecting to IRC servers over TLS were immune, as the ALG helper in the router could not observe the traffic.

This is what breaks DCC in general -- to use DCC on IRC while connecting to the server over TLS and behind a NAT, you must instruct your client to use a specific range of ports for DCC and preforward those ports to your machine in your router, as the ALG helper cannot mark the incoming connection as RELATED (and forward it through to you) as it cannot see the outgoing command that caused the incoming connection to occur. You must also instruct your client to determine the correct external IP address to advertise, as the ALG helper will be unable to rewrite it when the router does masquerading.

genewitch•2h ago

On AOL in chatrooms you could play sounds, so if you sent S{/con/con As the sound, you could crash anyone on windows that hadn't shut off user sounds.

My memory is a bit hazy and I don't want to look up the exact sequence, but that's close enough.

dado3212•14h ago

Neat, $17,500 is pretty good, I’m so used to these blog posts being for peanuts, or where companies fix the vulnerability but don’t pay out at all. Apple’s gotten better about this since 2019.

nativeit•13h ago

I read a comment under the story about the recent YouTube vulnerability where one could unmask the related Google account and its owner using the standard YouTube API (something similar to that anyway), and they explained a lot of lesser-known nuances in establishing values for bounties like these, and it helped explain a lot (not all) of the reasons for what might seem like low-ball/high-ball valuations on the surface. If I can find their comment I’ll post back, it was really insightful. That said, there are also plenty of examples of people just getting shafted.

sdeframond•13h ago

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

croisillon•13h ago

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

williamscales•7h ago

That’s definitely the one I thought of

cantrecallmypwd•7h ago

Maybe Zerodium would've paid $75k but that would be less ethical because Israel and America would weaponize it.

saagarjha•7h ago

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

cantrecallmypwd•3h ago

Which was Vupen too before that. One company name is unimportant because multiple shady groups and individuals are out there buying and selling 0daya. This is definitely the case because state actors don't develop 100% them themselves and must get them from somewhere. It's a small but nonzero market of expediency.

saagarjha•2h ago

I'm sure there are companies that have stepped up to fill the void. But the market for "I DDoSed your phone" doesn't really exist.

cantrecallmypwd•2h ago

Except that's not true because rendering a target's device unusable temporarily and/or effectively permanently is a useful payload regardless of what you think.

saagarjha•1h ago

A useful payload for whom? Point me to someone who is willing to pay for such a bug and I'll believe you. Zerodium's old payout scale didn't even list denial of service, and to my knowledge no other serious vendor does either. If I can list a bunch of people who don't care about this surely you can find one who does.

shrx•14h ago

> Looking into the binaries, SpringBoard was observing that notification to trigger the UI. The notification is triggered when the device is being restored from a local backup via a connected computer, but as established before, any process could send the notification and trick the system into entering that mode.

This should probably be reworked regardless if the patch described in the article was implemented.

jonplackett•14h ago

Anyone know how long ago that system would have been introduced?

It seems like such an obvious security concern. Maybe it was pre-AppStore? And more assumed trust in other apps?

plorkyeran•13h ago

The notification API is quite old (iOS 3). It's explicitly an untrusted API that you shouldn't use for something like showing the restore in progress UI, so I suspect that was something written quite a bit later. Widget extensions are iOS 14. There's older ways to run background tasks, but none of them would give the soft brick. Background fetch, for example, originally didn't run until after you launched an app for the first time after restarting.

MBCook•12h ago

Wasn’t it in OS X before that?

plorkyeran•9h ago

Documentation claims 10.6, which is the equivalent OS X version (both are the 2009 releases).

lilyball•9h ago

That's actually just for the block-based APIs like notify_register_dispatch(), the other notify APIs have no availability annotations at all.

lukeh•3h ago

Manual page says Mac OS X 10.3.

duskwuff•11h ago

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

plorkyeran•9h ago

Yes, I am aware. I'm not sure what makes you think I was talking about UI notifications?

bee_rider•9h ago

FWIW I also thought you meant UI notifications (the reason is: I’m dumb). But anyway, I found the point of clarification helpful even though it wasn’t strictly necessary.

lilyball•9h ago

Darwin notifications are so old they don't have any availability annotations (block-based darwin notification APIs like notify_register_dispatch() were introduced in macOS 10.6 / iOS 3.2, but the rest of them are declared as always available). They absolutely predate any notion of an AppStore, of being able to install apps without implicitly putting a lot of trust in the app to not be malicious.

brcmthrowaway•13h ago

Ultimately, does this require installing a sketchy app in the first place?

saagarjha•13h ago

Yes.

g-b-r•13h ago

Or a reputable one with that line of code included (in one of the updates, after having built a good reputation); maybe dormant until a certain date.

MBCook•12h ago

Or a bug in some good app that allows an attacker to execute the right thing.

piyuv•12h ago

Lots of credible apps use lots of dependencies. Find an abandoned one, get your code into it, …

urbandw311er•13h ago

Nice. I can only imagine what a crap day in the office it was when the iOS core team reviewed that one.

doesnt_know•12h ago

I get that it's potentially lower priority since a user needs to actively install a malicious app, but that timeline doesn't exactly feel me with confidence...

95014_refugee•11h ago

The exploit as described doesn't "brick" the device; that would require permanently disabling it. A tethered restore would be all that's required to recover in this case.

the__alchemist•11h ago

From observation, "brick" has evolved, as things do in language. In practice, it rarely means the traditional definition you refer to, but the softer one used here.

Kerbonut•10h ago

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

taneq•10h ago

You could say the device was pillowed. :D Although given the typical behaviour of old phone batteries, I guess that’s a little ambiguous.

dmckeon•8h ago

Thus, perhaps "loafed" as in something brick-like, but which may also be soft. And a "loafed" device, being idle, would be loafing.

nullhole•6h ago

A soft brick would be a brick before being fired in an oven, no?

So maybe the term shouldn't be 'soft brick' but rather 'muddied'.

"That updated muddied my device, I had to clean it up with a restore"

dgoldstein0•4h ago

I appreciate the sentiment but I don't see that catching on. I think a variant of bricked makes sense as it basically means you can't use the device until you can figure out how to fix it. Which the "muddied" analogy doesn't really fit - it's usually possible to use muddy things if not necessarily pleasant.

codetrotter•10h ago

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

guappa•6h ago

I'm quite convinced apple would just sell them a new one.

two_handfuls•9h ago

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

fc417fc802•8h ago

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.

rendall•6h ago

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

Which is the term that the article uses.

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

taneq•10h ago

“Bricking” isn’t a rigorously defined term, it’s more like “realtime” in the sense that it comes with an implicit “(for this particular user in this particular scenario)”. For most users a device is bricked if it doesn’t turn on and work when you press the power button. For most readers here, using dev tools to re-flash a bootloader would be fairly easy but if USB stops working it might be game over. I’m sure there are a few around who could de-cap an ASIC and circuit bend it back to life.

cantrecallmypwd•7h ago

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.

AStonesThrow•5h ago

When devices were a bit larger, we would customarily refer to “boat-anchors”

cantrecallmypwd•3h ago

That was a pejorative for unwieldy and inconvenient devices like rugged government secure cell phones that lagged behind consumer tech.

Brick means entirely useless except as a doorstop, projectile, or building material.

mook•8h ago

More importantly, the single line only forces a reboot; even if we consider needing external fixes to be a brick, the title is still incorrect.

SamBam•7h ago

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.

mrunkel•4h ago

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

He totally murdered that guy!

What? Why would you say murdered, he only gave him a black eye?

I know, but that's still pretty serious.

mook•4h ago

No, the _single line_ part forces a single reboot. The never-ending loop requires setting up a widget, so that's more than one line.

cantrecallmypwd•7h ago

Correct. The terminology is wrong. It's an annoying, repeated DoS that doesn't ruin the device permanently but could lose user data if it must be erased.

miki123211•3h ago

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

DFU mode boots entirely from read-only ROM, and from there, you can just restore everything via USB cable.

Same applies to Apple Silicon Macs. You can damage the system, recovery and emergency recovery volumes, but even then, you can still boot into DFU from ROM and re-initialize everything via another Mac.

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

Koshcheiushko•3h ago

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

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

moduspol•11h ago

Doesn't this imply that third-party apps with their own notification schemes could be impersonated similarly? They wouldn't be able to brick the phone, obviously, but they could potentially trigger other actions.

andrekandre•10h ago

  > That single line of code was enough to make the device enter “Restore in Progress”.

  > as established before, any process could send the notification and trick the system into entering that mode.

sleep data, sleep...

e28eta•9h ago

I’m fascinated that they aren’t requiring an entitlement for all usage of setting & posting notifications through this API. A way to share 64 bits of information (at a time) to any process on the device? That is right in the wheelhouse of tracking a user across apps.

I don’t specifically know the types of things that you’d want to share across apps, but there’s a long history of cross process information channels being removed or restricted.

If the system is storing values for you, and isn’t keeping track of which app they came from, now you’ve got persistent storage across app deletion & re-install, as long as there isn’t a reboot in between.

I think you could easily use it to work around IDFA or IDFV resets, as a simple example.

tgv•4h ago

> That is right in the wheelhouse of tracking a user across apps.

The design is old. It probably predates facebook, so it's not been intentional, as your comment might be interpreted. But it certainly seems ripe for abuse. I'm curious if it would actually be used for that, because any app that can access internet already has a better way to share information.

LunaSea•1h ago

Facebook predates iPhones by 3 years.

jen20•1h ago

NSNotificationCenter predates the iPhone by 13 years, though…

agos•3h ago

this is exactly where my mind went immediately - 64 bits is more than enough for easy (1 line!) unenforced cross-app tracking of a user for advertising purposes, basically a super cookie for iOS. If they now require an entitlement for this API it's a privacy win

croemer•1h ago

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

icoder•1h ago

The IDFV already supports tracking user across apps, as long as they are from the same vendor. It resets when apps from a vendor are removed from a device. Not sure if the user can reset it by themselves, but the vendor could then always tie things together using another self-generated identifier stored on the device, as long as any of its apps are on it, which boils down to the same.

I think the approach you describe allows roughly the same, except perhaps doing so without (or with different) permissions, and allowing to do this between vendors (that must agree upon this upfront).

keepamovin•8h ago

This was an epic read. That very old skool API was so powerful! Cool demo seeing it trigger all this low-level states for iOS. I wonder what happened to notify_post now..

Loocid•6h ago

The sheer simplicity of this exploit is wild.

gitroom•5h ago

Damn, makes me miss those old IRC days but also, stuff like this just reminds me how risky even tiny changes can be on any tech. You think security ever gets ahead or we just keep patching leaks forever?

genewitch•2h ago

Depends, are people going to keep producing new code?

Internet in a Box

Show HN: I made a web-based, free alternative to Screen Studio

AI helps unravel a cause of Alzheimer’s and identify a therapeutic candidate

Full power outage in Spain and Portugal

How a single line of code could brick your iPhone

Inference-Aware Fine-Tuning for Best-of-N Sampling in Large Language Models

I just want to code (2023)

Reversing the Fossilization of Computer Science Conferences

Ask HN: What are you working on? (April 2025)

Presentation Slides with Markdown

Show HN: Cleverb.ee – open-source agent that writes a cited research report

Read the Obits

Naur's "Programming as Theory Building" and LLMs replacing human programmers

Did 5G kill the IMSI catcher?

New material gives copper superalloy-like strength

To 'Reclaim Future-Making', Amazon Workers Published Collection of SciFi Stories

Show HN: I486SX_soft_FPU – Software FPU Emulator for NetBSD 10 on 486SX

The suburban office park that launched Silicon Valley

Virginia passes law to enforce maximum vehicle speeds for repeat speeders

Reverse geocoding is hard

The coming knowledge-work supply-chain crisis

How a Pipe Organ Works (2020)

Boxie – an always offline audio player for my 3 year old

Show HN: Daily Jailbreak – Prompt Engineer's Wordle

Computer Architects Can't Find the Average

Show HN: Bhvr, a Bun and Hono and Vite and React Starter

TmuxAI: AI-Powered, Non-Intrusive Terminal Assistant

Business co-founders in tech startups are less valuable than they think

Tiny Emulators

Unlocking Ractors: Object_id

Internet in a Box

Show HN: I made a web-based, free alternative to Screen Studio

AI helps unravel a cause of Alzheimer’s and identify a therapeutic candidate

Full power outage in Spain and Portugal

How a single line of code could brick your iPhone

Inference-Aware Fine-Tuning for Best-of-N Sampling in Large Language Models

I just want to code (2023)

Reversing the Fossilization of Computer Science Conferences

Ask HN: What are you working on? (April 2025)

Presentation Slides with Markdown

Show HN: Cleverb.ee – open-source agent that writes a cited research report

Read the Obits

Naur's "Programming as Theory Building" and LLMs replacing human programmers

Did 5G kill the IMSI catcher?

New material gives copper superalloy-like strength

To 'Reclaim Future-Making', Amazon Workers Published Collection of SciFi Stories

Show HN: I486SX_soft_FPU – Software FPU Emulator for NetBSD 10 on 486SX

The suburban office park that launched Silicon Valley

Virginia passes law to enforce maximum vehicle speeds for repeat speeders

Reverse geocoding is hard

The coming knowledge-work supply-chain crisis

How a Pipe Organ Works (2020)

Boxie – an always offline audio player for my 3 year old

Show HN: Daily Jailbreak – Prompt Engineer's Wordle

Computer Architects Can't Find the Average

Show HN: Bhvr, a Bun and Hono and Vite and React Starter

TmuxAI: AI-Powered, Non-Intrusive Terminal Assistant

Business co-founders in tech startups are less valuable than they think

Tiny Emulators

Unlocking Ractors: Object_id

How a single line of code could brick your iPhone

Comments