Sophos Cloud Optix
Earlier this month, iPhone fans and detractors alike were abuzz on technical forums over what seemed to be a rather tricky bug in iOS.
According to the rumours, setting the date on your iPhone to 01 January 1970 would activate a time bomb in the device…
…so that when you next restarted it, it would freeze during bootup.
Even a complete firmware reinstall wouldn’t help, because the fresh copy of iOS would have the same boot-time bug, and a firmware reset doesn’t update the time.
So your phone would continue freezing every time you restarted, even after the firmware “fix.”
You can imagine what some self-styled security researchers took to doing in Apple Stores, just so they could tell their buddies:
Holy s***! It worked. iPad Pro out of commission.
Others, it seems, decided that a rumour like this was bound to be nonsense, and set out to prove it to themselves with a confidence that was as impressive as it was misguided.
Why 1970?
All of this raises the questions, “Why 1970? And why New Year’s Day? Is it anything to do with flared trousers?”
We can’t talk to the sartorial question, but we can explain the significance of 1970.
On Unix-derived systems like iOS, the system time is stored as a non-negative integer (that’s fancy talk for “zero and up”) that is the number of seconds since 1970-01-01T00:00:00Z, which is exactly (OK, almost exactly*) when the decade of the 70s started at Greenwich in London.
In other words, midnight on New Year’s Day, 1970, is represented by the number zero in what’s known as the Unix epoch, and timestamps go up from there.
Unix time Conventional date and time
------------- -----------------------------------------------
0 = 1970-01-01T00:00:00Z, start of the epoch
60 = One minute past midnight
86,400 = Midnight the next day (02 Jan 1970)
946,684,800 = Start of the current millennium (01 Jan 2000)
1,000,000,000 = 01:46:40 on Sunday, 09 Sep 2001
1,234,567,890 = 23:31:30 on Friday, 13 Feb 2009
1,414,213,562 = 05:06:02 on Saturday, 25 Oct 2014 (√2 x 1 billion)
2,147,483,647 = 03:14:07 on Tuesday, 19 Jan 2038 (doomsday time for signed 32-bit integers)
3,141,592,653 = 00:37:33 on Sunday, 21 July 2069 (π x 1 billion)
Bugs involving Unix times of zero have happened before, not least because zero often has a special meaning in computer programs.
As well as meaning “the start of the 1970s,” it’s often used to denote a range of different situations, such as “FALSE” (meaning that an error happened), or “not-yet-used” (meaning something that hasn’t been changed from its default), or “nothing-out-of-the-ordinary” (meaning that an error did not happen).
When one value inside a program can be interpreted in different ways, problems can easily arise, especially when you think that in C programs and Unix shell scripts, zero sometimes means “it worked just fine” and sometimes means “it broke really badly.”
Combine that with a timestamp, which will never be zero unless someone deliberately sets the clock way back in time – something that might never happen during testing – and you have a recipe for a bug that is a zero day, literally and figuratively.
The good news is that Apple will be fixing this problem in the next release of iOS, version 9.3, so that this bricking trick will no longer work.
Apple’s HT205248 article suggests that the bug isn’t limited to a time of exactly zero, but to any time that’s within six months of zero. Presumably, if you keep your bricked iPhone charged up for the next six months so the clock’s still ticking, it will heal itself once the device thinks it’s mid-1970 again.
Better yet, if you have a device that was already bricked by the 1970 bug, you can register for Apple’s Beta program, reflash the latest pre-release firmware version (iOS 9.3 Beta 4), and when you restart…
…your iDevice should have a new lease on life.
[*] Times denoted by Z-for-Zulu are UTC, an absolute measure of time that is not exactly the same as Greenwich Time, a mean solar time. They differ by up to one second, but that’s a story for another timezone.
• James Marshall Hendrix stamp thanks to catwalker / Shutterstock.com.
• Phone image thanks to Yeamake / Shutterstock.com.
Ha ha, Apple always boasts about it’s OS ties to Unix and is bitten by such a trivial issue – how ironic. But, then again, if you can’t design a proper power supply……
Disconnecting the battery for a little bit will fix this also.
I thought they weren’t user-removable.
They aren’t, for the most part. But apparently that’s how Apple has been fixing devices that people have vandalised in its stores – and, presumably, how it would repair your phone if you took it in.
In short: you can access the battery yourself; it’s just not a job for the faint-hearted (and you need just the right tools, plus a patient approach that can judge when you’re applying to much force to a hidden clip that won’t open :-).
How do you download the beta from your computer? (Phone is bricked)
You download a complete firmware image and start DFU (device firmware upgrade) mode on your iDevice. This is a special startup mode on your phone that doesn’t boot into iOS, but instead runs its own special-purpose “mini operating system” that knows just enough to download and install the new firmware from your OS X or Windows computer. You use iTunes on your computer to push the new firmware to your iPhone.
This should absolutely have been caught in testing. It’s a standard test case for time/date related functions. This is like, programming basics.
Apple has had a history of doing a really bad job testing time functions though. Leap year bugs, daylight savings time bugs – this kind of stuff is embarrassingly easy to test. It’s embarrassingly easy to come up with a list of stuff to test. It’s incredibly frustrating that a company as big as apple is making these mistakes.