Found a nice bug in IOS today, bricks your phone and kills the Simulator | Hacker News Reader

Found a nice bug in IOS today, bricks your phone and kills the Simulator

pastie.org

50 pointsjimsteinhart31 comments

Im the original poster, that found the bug. Nah it doesnt brick it, it does however require (atleast on 4.1. for me) a factory reset.

The problem seems to be that springboard locks up in an endless loop, restarting the device wont help it because its still loading the offending notification from the cache.

More apt would have been that it disables your iphone temporarily until a factory reset or restore is performed. Saying it bricks it causes me to think back to messing up the flashing of firmware on a device and the device never working again.

Yeah, I know. Its to bad though because all the discussions are turning into discussions about the proper use of "bricking".

Well, I'm pretty sure that getting "fscked" is not that bad. I mean, running file-system checks is probably a good idea to do periodically.

Wait. Is it really an endless loop, or just a queue that is getting filled up faster than it empties resulting in a more DOS-style problem? Because it sounds much more like the second case, in which case not only does it not brick the phone, but it isn't even a bug...

OP:Nope, you didnt read the code. Try reading the other version I posted. Works without a loop as well.

errr, that's what I said...

Which is why I wrote "OP" in front :)

In the post that I replied to, you said that Springboard is getting into an endless loop. Having looked at the code that you posted, I commented that it doesn't look like an endless loop but more like a denial of service type problem, to which you replied that I should read the code, and that it doesn't need a loop, which was just repeating my point about it not appearing to be a loop!

Ahhh, I give up. Just try reading what I wrote before replying, mkay?

If you try hard enough you can always find a piece (or many) of code that will "brick" (using your definition...) your device (whatever that is). I don't consider this a bug, or not a serious one at least.

And in this case Apple's approval process could protect the consumer. They would never let something like this past the gates.

If a sandboxed application can get the sandboxing environment into a state where the only way to get the sandboxing environment working again is by restoring it from a backup, that is a serious defect in that environment.

Also, since this issue is very trivial to trigger, it's not very difficult to hide the triggering mechanism in a malicious application in a way that even a reasonably thorough source code inspection would not necessarily spot it. See also: The Underhanded C Contest.

Does it really "brick" your phone, as in "makes it crash in a way that is completely irrecoverable and that can never ever be repaired, therefore turning your phone forever into a piece of hardware comparable in functionality to a brick" or does it just make the phone crash?

People use bricked incorrectly way too often. Leading to others wondering if they actually mean it is as functional as a brick or that it just crashed and thus can be rebooted or restored.

Then again I haven't personally bricked a device in a long time.

> Heretofore, "to brick" can brick anything.

http://apple.slashdot.org/comments.pl?sid=423338&cid=221...

I have to say, I once came fairly close to bricking my router. However after I realized the router was complete and utter garbage I put the brick to it, so now it is officially bricked, office space style.

I'll accept "brick" when recovery requires flashing via JTAG. But not when you just have to press a few buttons.

This is the definition used by people that actually hack hardware, people who are used to performing brain surgery on set-top-boxes and such like. It's not bricked unless unbricking requires a soldering iron or similar, and some JTAG action.

These days its getting harder and harder to brick devices, as bootloaders are becoming more and more advanced and more separate from the cores of the devices themselves. Once upon a time a faulty network cable could render your router forever inoperable due to a dropped byte in a firmware flash.

Today, my galaxy S phone has had some truly awful things done to it, including corruption of the supposedly sacred NVRAM data, and the USB bootloader has always faithfully come up after the button combo, ready to accept a new flash. It must run on totally separate hardware from the phone proper.

Most of the newer SoC chips like Freescale iMX and TI OMAP have the USB core hardware built into the chip, so it's easy to have the chip provide it's own USB bootloader that doesn't require any code out of flash or RAM to get started. The only trick is to make sure the chip can start in this mode when necessary, usually a little helper PIC or some custom gates takes care of that.

You say this because you haven't tinkered with wireless routers...

Just because it's harder to brick things doesn't mean the meaning of the word has changed. People are right to think this is a mis-statement.

Also here is a nicer version that still triggers the bug http://www.pastie.org/private/8a48wgmcuuhjjwbupbk3g

So what's the bug then? If there's no loop here?

alarm.repeatInterval = NSEraCalendarUnit

Triggers the bug, its totally valid as well.

So basically the repeatInterval is expected to have one of the values of an enumeration assigned to it, where the enumerated values are calendar units (representing daily, weekly, monthly, etc.), and it somehow mishandles the value representing "once-per-era"?

That would seem to be the case.

What's the radar number?

I am not an iPhone developer, but the code doesn't seem unreasonable to me.

Can anybody explain what is special about this code?

It's a function that configures ten timers to call itself. So it causes an exponential number of timers to be set.

Thats not the bug though. Can do it without a loop as well. This was an old version, check the other one I posted here in this thread.

Ok. I would be very grateful for an explanation, then. ;-)

It creates 10 copies of an alarm on the same date with a setting to repeat twice. So I imagine 10 alarms firing at the same time is not a good idea. I don't see where it calls itself like other people are saying.

For people lost in the thread, I've read the whole thing. The actual problem here as posted by the guy who found it (Fjanth in this thread) is that setting a local notification with a repeat value of era breaks iOS and requires a factory reset in order to recover.

Reply on news.ycombinator.com