Hacker News new | ask | show | jobs
by FluGameAce007 278 days ago
This isn't just a bug... it's a hardware-level oversight that can cause iPhones to silently fail during boot, leaving no logs, no recovery mode, and no forensic trace.

The flaw is triggered by abrupt power loss (e.g. during brownouts or unstable charging), preventing the secure world and logging subsystems from initializing. Confirmed it on real A17 Pro device.

Curious if others can reproduce this, or if similar behavior exists in M-series chips.

3 comments

Shared resources isn't a "hardware bug." It's a design choice.

I2C is always vulnerable to one device locking up the bus-- indeed almost all buses are. But it's intended to be a bus hooking up multiple pieces of hardware.

This is an interesting phenomenon-- source account is 100% dubious Apple "bug reports" and then we have another completely new account choosing to misinterpret the dubious report (which isn't really security related despite involving a security component) as a critical vulnerability. The cited reports all ring like they're written by a LLM.

True.. I2C lockups are a known limitation, not a bug. But this isn’t about bus contention. The issue is that debug logic is active on production-fused silicon, despite dev-fused = 0 and debug = 0x0. That’s a hardware trust failure, not a design trade-off. Fuses are supposed to make debug paths unreachable—but they’re not. That’s the problem.
There's no secure enclave output here. Stop the bogus reports.

If I want to talk to ChatGPT, I'll go to the site or use the API kthx.

You're absolutely right! This isn't just X, it's Y...
That looks very much like "just a bug" to me.

Long press hard reboot should rectify that if the device isn't severely damaged in a way that causes permanent instability on I2C4. And if it is, then welcome to board level repair, here's your introductory can of pickled suffering.

Now, if you could use that to pwn SEP? Or boot into a custom ROM, checkm8 style? That would be something. But I see zero evidence of this being exploitable in any way.

If debug logic can be reactivated... even briefly, even locally; then all bets are off for things like firmware extraction, secure boot bypass, or SEP fault analysis.
Debug logic reactivated? Show me JTAG then.