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,
I can understand why one would need to use that date as test data for an application, but why would anyone set their system date to that in the first place? (Not that I'm apologizing for Apple, that's a pretty stupid bug...)
I'm always curious about how such things come about. Did some kid go "Oh! I know, lets see how far back the iPhone can go! LOL YOLO"
nm
Anons need not reply. Questions end with a question mark.
I love Elvis Costello!
I can't say how it's represented internally, but the iOS "epoch" time isn't 1970, it's 2001 (beginning of the third millennium) according to the doc. If this has anything to do with 1970 being the 0 time, there is a seriously uniformed programmer somewhere at Apple.
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!
Duh, it's because the first hand-held cell phone didn't exist until 1973. The iPhone believes it has gone back in time, and is trying to prevent damage to the space-time continuum from a sudden intrusion of 21st century tech into the past.
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.
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???
Well, according to the man page of time(), if the timestamp is negative, you are supposed to check errno.
I guess the time is stored there for dates in the 60s and earlier.
I don't know what is going on [.. ]
Read about it here https://en.wikipedia.org/wiki/Unix_time
I know "robust against pathological clock-frobbing" was the main factor that drove me to choose Android.
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
Because I"m hardpressed to imagine any advantage in making that assumption. And useless assumptions are bad
Your ad here. Ask me how!
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
Ever since all OSs went 64-bit, wouldn't that allow all systems to make 1/1/0000 as the starting point in time? And still allow millenia before the clocks would have to reset? Why have it at any date before which there are plenty of people on this planet still alive?
This demonstrates why the Windows Phone is clearly a superior platform.
In order to brick that, you would have to set its date all the way back to January 1, 1601. That allows the user to live in many more interesting historical eras.
If I want to play iNethack, changing the time so that I only play on full moons, I'll need to be able to set the time back multiple years. Or are you some sort of Rogue-like purist who doesn't take advantage of being able to modify the system?
This is just Apple's way of forcing users to upgrade their phones before Jan 1 1970 rolls around.
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."
Well, according to the man page of time(), if the timestamp is negative
Like I said - it can be negative.
Read about it here
Yes I already know that hence pointing out it can be negative.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Just remembered from CD classes long time that this is Unix start time. Wonder if this is related
CD classes? Is that for cross-dressing? Or compact disks?
In the free world the media isn't government run; the government is media run.
Dinosaurs died out 65 million years ago.
The Quirkz Handbook of Self-Improvement for People Who Are Already Pretty Okay
At least on a PHONE? The cellular network provides a very high quality time signal to begin with, probably better than the internal clock can deliver. AFAIK it's also the iPhone default.
The only reason I can see why you would want to would be to lock the time zone to a specific one different from the one you're in (iPhone seems to set the timezone either via GPS or from the cell network). OK, maybe this is someone's preference, but every time I have done something similar out of my timezone it always fucks me up to be out of sync with local time.
And why on earth would you want to be on a different date?
I've said it again and again, consumer devices should be de-brickable.
Business devices too for that matter.
They should all have a "factory reset jumper" or similar that resets the machine - or at least the non-replaceable parts of the machine - to factory conditions.
I can think of three exceptions to this rule:
* Things that must not be wiped due to legal reasons or fraud-prevention reasons, like a hard drive's in-use-hours, should not be wiped,
* Certain "write once" storage, such a log of reported thefts, should not be wiped, and
* if the consumer explicitly shoulds a different jumper, the ability to do a factory reset is permanently lost, rendering the device "brickable." Some users may want their devices to wipe their secuity keys and brick themselves if they are reported stolen or after too many unsuccessful logins in a row as a way to discourage theft.
On an iPhone, this might mean booting from a "restore" boot loader that would wipe the real boot loader, storage, ram, security, and everything else not "burned in" as "read only" at the factory or which wan't on the "no wipe" list such as a carrier-lock or powered-on-hour then set variables like the clock to sane albeit incorrect factory-default values. It would also preserve things normally "off limits" or "read only" to the bootloader and iOS for legal reasons (such as radio hardware). Then it would restore the regular bootloader and Apple security credentials from ROM and copy a temporary "iOS-restore" mini-operating system from ROM into storage and reboot. On the next boot, the special "iOS restore" OS would tell the user to either plug the USB cable into a PC running iTunes or to connect to the internet using USB, WiFi, or Bluetooth then it would load the real iOS from iTunes or an Apple internet server, then, after verifying the iOS was properly signed, set it so it would boot from the just-downloaded iOS and reboot. Sure, it would take awhile, and yes, all user data would be lost, but at least the phone would be usable.
On a PC with non-soldered RAM and disk or SSD storage, those devices would not need to be wiped as part of the machine's de-bricking routine - if those parts are contributing to the problem, the consumer can replace them.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Does The Doctor use an iPhone?
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Certificate of deposit.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
They will have gotten around to signing it one of these epochs, eventually. Maybe on January 1, 1970.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
as far back as 14,000,000,006 years.
You got modded down by a Christian fundie.
Sorry I must have missed something are there not any full moons in the future? My ipad running ios 6.1.3 allows me to set the time to as far in the future as 2038.
Does the game check to make sure you've not started at the same time or something that you would need more than one full moon?
Setting the clock back to 1970 does make it rather obvious something's gone terribly wrong though as it breaks https.
Minimum threshold fixed. Thanks!
You mean they were fake bones?
Doubtful the iPhone won't accept any time outside of the 1969~2038 range. Then again that might be a function included with Universal Roaming. Either way the doctor strikes me as a android type guy.
Minimum threshold fixed. Thanks!
Faked by God.
I must bookmark the GP post so that I can make a weak joke in August 2020 :)
I did this and now can't access my phone. This is a real issue.
So, 1/1/0001 instead.
Just adding that the platform-dependent units used by mach_absolute_time are tiny. Nanoseconds on some systems, based on the processor or motherboard clock speed on others. GCD use 64 bit nanoseconds, NSDate uses double precision seconds since some reference date which is _not_ 1970; I think 2001 or something like that. Very easy to use with microsecond resolution for the next +/- 200 years.
The medium is the message
You knew what would happen but did it anyway?
It is not a real issue. If the phone set the date itself to that, then it would be a real issue.