Slashdot Mirror
iPhones Bricked By Setting Date To Jan 1, 1970 (theguardian.com)
lightbox32 writes: Beware of a hoax circling the interwebs, which can be seen by setting your iPhone's date to January 1, 1970. Many people are reporting that doing so will brick the device. It's unclear what exactly causes the issue, but could be related to how iOS stores date and time formats. Jan. 1, 1970 is a value of zero or less than zero, which would make any process that uses a time stamp to fail. Apple is aware of the issue and is looking into it.
It's recoverable just by letting the battery run out, or disconnecting the battery (harder but faster) Bricking is when you permanently break the device.
-- these are only opinions and they might not be mine.
No problem. You can reset your iPhone to factory default by placing it in a microwave oven on high for 2 minutes. ;-)
Have gnu, will travel.
https://xkcd.com/376/
Hire a Linux system administrator, systems engineer,
nm
Anons need not reply. Questions end with a question mark.
My question is why does it even allow you to set the clock back that far? Are they expecting a lot of sales to time travelers that never go back farther than the 1970s? At this point nothing made today should accept a year less than 2000. Idealy the clock would have a hard coded default time of when it was manufactured.
Minimum threshold fixed. Thanks!
Perhaps someone somewhere in the system frameworks shifted from a timestamp (which is really a double internally in iOS)
Depends on what you mean by "internally". At the Mach layer, you have what mach_absolute_time() returns, which is a 64-bit unsigned integer in platform-dependent units. Above that in the Mach (osfmk) and BSD (bsd) layers, it's mainly seconds since the Epoch and microseconds since that second, i.e. either struct timeval or other pairings of those values. time_t is signed, but in some of the other pairings, the seconds is unsigned (e.g., clock_sec_t).
Perhaps in some layered-atop-UN*X userland frameworks it's a double, but not down in the engine room.
It's not unusual to see some timestamp issues. It is unusual to see a device crippled so sharply by that. It's VERY unusual for Apple to allow such a range of values- this is the same company that doesn't normally even provide options like "make unread mail appear green instead of blue" or whatever.
But most disturbing is that this would allow any source the iphone trusts for timestamps to mostly disable the phone. I'm not sure whether the iphone prefers to get data from a trusted NTP server or some part of the 3G standard, or if it supports all of that, but it implies that you could...
1- (as just some guy) Set up a wifi network that spoofs whatever the trusted NTP server is, and then assign the epoch date that way. ...and of course a more sophisticated attacker could probably do more.
2- (possibly as some hackery type) Find any way to do the equivalent at a greater level.
3- (as some radio phreak) Find a way to spoof the epoch date with a bogus 3G transmitter.
I practically guarantee you...
The problem is with a long or int (32 bit) value having its address passed in for a time_t (64 bit) value.
As long as the number is positive, it appears to work, but if it goes negative (and given that most of the people setting it to that date are West of GMT, it *will* go negative), then the underflow blows all the adjacent bits in the next 32 bit word over.
And it appears that something important was there. This will likely be a problem for the code after 19 January 2038, if that's the case.
This is why there should be strong type enforcement set in the compiler settings, to make sure it doesn't compile if you have this kind of bug in your code.
This should be a trivial fix, but it's pretty clear that you could fix the problem on your own by temporarily disconnecting the battery and/or letting the battery drain (which would likely take a very long time). So take it into your local Apple store and be done with it.
The thing that bothers me about all of the summaries I've read, is that a timestamp less than zero (which is Jan 1 1970) is still valid - otherwise how would you represent dates before 1970???
You represent dates before 1970 with a negative number.
It's not the representation that is the problem-- it is letting the iPhone operate with today's date being a negative number.
The iPhone concludes that you have just time-travelled, and thus bricks itself to enforce the chronology protection protocol.
http://www.geoffreylandis.com
Okay guys, calm down. Assuming iOS is really based on OS X, I'll test something on my Mac right this instant.
Setting the clock to january first 1970 right noW. I DO NOT SEE ANY DIFFERENCE.
OH WAIT, ALL THE COLOURS ARE GONE. IN FACT I THINK THE RESOLUTION IS WAY DOWN AND I'M ONLY SEEING PURE BLACK AND WHITE PIXELS.
Its also bullshit on iOS 9.2.1.
I just set it to exactly midnight EPOCH, I set it to before epoch and I set it back to now. Rebooted multiple times all along the way.
My phone works fine.
I got kicked out of anything authenticated the instant I did the change since doing so effectively renders every certificate on the device invalid as it is suddenly years before the certs were 'issued' but thats exactly as expected.
I pretty much can't find any truth in the story. It claims you can't scroll back that far in the date/time picker without open and closing multiple times, yet here I am with just a bunch of finger flicks looking at the date/time as Dec 1969 right this very moment and I did so without having to enter it multiple times.
Dear slashdot, you have been trolled. Please stop believing the random shit you read on the internet.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
No, it isn't.
A) because it doesn't actually break in the first place
B) Brick means unrecoverable, recovery here is trivial if it were to work as the story goes.
C) You've been trolled, the phone doesn't actually brick in the first place, worst you bought into something this silly.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
So the representation of dates must either handle negative values or have some other method of representing dates as far back as 14,000,000,006 years.
Reminds me of this joke:
Some tourists in the Museum of Natural History are marveling at some dinosaur bones. One of them asks the guard, "Can you tell me how old the dinosaur bones are?"
The guard replies, "They are 3 million, four years, and six months old."
"That's an awfully exact number," says the tourist. "How do you know their age so precisely?"
The guard answers, "Well, the dinosaur bones were three million years old when I started working here, and that was four and a half years ago."