iPhones Bricked By Setting Date To Jan 1, 1970 (theguardian.com) 170
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.
False headline... (Score:5, Informative)
Re: (Score:1)
How long will it take to drain completely on a full charge for the newest iPhones? Can you keep the screen on while it's in this state, or is it locked into a screen off, not doing anything, and barely touching the battery state?
Why does a battery pull fix a software issue that a forced reboot (holding power button I presume) can't?
Re: (Score:2)
Probably because you need to drain power to the clock and a hard reset doesn't do that? When the clock resets, it probably goes back to the equivalent of 1/1/1980 that PCs used to default to.
Re:False headline... (Score:4, Informative)
Re:False headline... (Score:5, Informative)
Re: (Score:3)
Re: (Score:3, Interesting)
First, you'll be fucking around with itty bitty screws that have a significant digit measured in microns. And there are like five (slightly) different kinds of the little bastards. Second, if you don't
Re: (Score:2)
I've never knowingly seen an iPhone, so I've no way to know if it's voodoo or not, but it doesn't sound unreasonable to anticipate that handling a flexible device that depends on the area of sheets maintained at a small but necessary spacing would affect the capacity of that device.
(I probably have seen an iPhone, but as far as I know they look identical to other pho
Re:False headline... (Score:5, Funny)
Yeah, those 10^15 sided screws are a bugger to not strip. That's why I replace mine with pentalobe screws - much more robust.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
And then your phone bricks itself with an Error 53 for not having the work done by an Apple tech...
Error 666 , surely... Or is that number specific to Apple desktops?
Re: (Score:2)
So you get better fuel economy with a Toyota Prius than a Caterpillar backhoe. Congratulations. They are completely different classes of device, so it is thoroughly pointless to compare them in that way.
Re: False headline... (Score:2)
Your reply was solid. A bit vulgar, but on point. Don't hide behind the anonymous coward uid next time.
Re: (Score:1)
What? "Positive Karma" doesn't fill your day with love and kisses? ;-) Hyuk....
Re: (Score:1)
Hold it right there. That's over a week? For real?
Keep your wireless one, I keep my corded one. It can only make calls but it can do so forever without a charge.
Oh, what's that? You want for it to be mobile? You want for it to be able to text? Yeah, so there is a trade off. Most sane people understand these concepts and don't come off like a fucking retard in a public forum.
Go get fucked, retarded asshole.
Yeah he's full of it. The battery in those dunb phones is lucky to last 2 days.. I know because I use them...
Re: (Score:1)
Probably because you need to drain power to the clock and a hard reset doesn't do that? When the clock resets, it probably goes back to the equivalent of 1/1/1980 that PCs used to default to.
You are likely correct. You could probably do a factory-defaults Reset; but then you'd have to reconfigure a bunch of stuff or (hopefully) have an iTunes backup to Restore; so letting the battery run down until the clock runs out of juice is probably the least-annoying way to get the clock to Reset to a legal date (assuming you don't have a decent backup).
Re: (Score:2)
Probably because you need to drain power to the clock and a hard reset doesn't do that?
That assumes that Apple don't have a backup power source for the clock in the not-too-unlikely even that the battery runs out of charge. There are digital cameras that will keep time accurately over several months with a completely flat battery, so I'd expect something similar from a phone.
Re: (Score:3)
"There are digital cameras that will keep time accurately over several months with a completely flat battery, so I'd expect something similar from a phone."
But digital cameras usually don't hide a phone within them so they can't have the advantage of sync'ing the time from the network as soon as they boot up.
Re: (Score:2)
Go to http://www.apple.com/iphone/co... [apple.com] and search for "Power and Battery" section...
Re: (Score:2)
Re: (Score:2)
Bullshit headline, it doesn't work. (Score:5, Interesting)
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.
Re: (Score:2)
I've read that you also need to change the time zone to something that would bring it to the next earlier day after setting it to the earliest possible date (presumably causing it to subtract a few hours and underflow the value.) Dunno. I'm not dumb enough to try it.
Re: (Score:2)
Its also bullshit on iOS 9.2.1.
That's the clever thing about the story; nobody will be willing to check it.
On the other hand, it has been reported that the problem isn't setting the time to Midnight Jan 1st 1970. The problem is setting that time for example in the USA, because in the USA you set the time to some hours _earlier_ in UTC. And these reports say that the problem fixes itself when the time goes into positive time UTC (in Los Angeles you might have to wait nine hours). And _I_ am not going to check if this is true.
Re: (Score:1, Troll)
A faster way to drain the battery is by putting it in the microwave for ~2 minutes on "High".
Re:So it's only a brick for several days (Score:4, Informative)
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.
Re: So it's only a brick for several days (Score:1)
I did this and now can't access my phone. This is a real issue.
Re: (Score:2)
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.
Less than zero is a valid timestamp (Score:1)
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???
I don't know what is going on but a timestamp being merely "less than zero" seems alone to not be a problem, it's how some other part of the system is dealing with this timestamp. Perhaps someone somewhere in the system frameworks shifted from a timestamp (which is really a double internally in iOS) to some kind of la
Re: (Score:1)
Timestamp? As in a system generated date/time? Why would you ever expect a less than zero value?
Now, for date calculations; yes. Dates before the O/S epoch must be valid. 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.
Re: (Score:2)
Because I"m hardpressed to imagine any advantage in making that assumption. And useless assumptions are bad
Re:Less than zero is a valid timestamp (Score:5, Funny)
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 [mistupid.com]:
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."
Re: (Score:2)
Dinosaurs died out 65 million years ago.
Re: Less than zero is a valid timestamp (Score:1)
You mean they were fake bones?
Re: (Score:2)
Faked by God [wikipedia.org].
I must bookmark the GP post so that I can make a weak joke in August 2020 :)
Re: (Score:1)
as far back as 14,000,000,006 years.
You got modded down by a Christian fundie.
Re: (Score:3)
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 [apple.com]. 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 i
Re: (Score:2)
Re: (Score:1)
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
Like I said... (Score:2)
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.
Re:Less than zero is a valid timestamp (Score:5, Funny)
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. [classic-sf.com]
Re: (Score:2)
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?
Re: (Score:1)
So, 1/1/0001 instead.
Re: (Score:3, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: Less than zero is a valid timestamp (Score:1)
Does The Doctor use an iPhone?
Re: (Score:2)
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.
Hoax? (Score:3, Funny)
No problem. You can reset your iPhone to factory default by placing it in a microwave oven on high for 2 minutes. ;-)
Re: (Score:1, Flamebait)
No problem. You can reset your iPhone to factory default by placing it in a microwave oven on high for 2 minutes. ;-)
They patched that. That reset method now only works on Android phones.
Re: (Score:2)
Yeah, what is the hoax here? Did TFS mean "bug"?
Re: (Score:1)
Not true. An iPhone requires a convection microwave oven, not a standard microwave oven.
Re: (Score:3)
Damn, Apple, can't you go for standards just ONCE?
Re: (Score:1)
A microwave oven acts as a faraday cage; causing the phone to boost output signal to find and ping a tower, thus... draining the battery faster!
Obligatory XKCD (Score:5, Funny)
https://xkcd.com/376/ [xkcd.com]
Re: (Score:3)
good luck proving this isn't true.
Re: (Score:2)
since it makes no difference whatsoever to my behavior, I shan't bother.
Re: (Score:3)
Impossible. The universe was created last Thursday with the appearance of coming into existence in 1970.
good luck proving this isn't true.
Impossible. The universe was created last Friday with the appearance of {being created last Thursday with the appearance of coming into existence in 1970}.
Therefore, the universe was not created last Thursday with the appearance of coming into existence in 1970.
Good luck proving this isn't true.
Re: (Score:2)
Impossible. The universe was created last Friday with the appearance of {being created last Thursday with the appearance of coming into existence in 1970}.
Therefore, the universe was not created last Thursday with the appearance of coming into existence in 1970.
Good luck proving this isn't true.
Sorry, but the universe was just created. I never wrote this post. In fact, you never read it. It's just a memory implanted in your mind.
Re: (Score:2)
good luck proving this isn't true.
It reminds me of something I've argued with creationists.
Surely God could have created a world with an infinite past? Theres no reason to suppose that the universe had a moment of beginning when God created it.
Usually their heads explode. Because they want to believe God is that powerful but they also want to believe that the world is 5000 years old.
....why? (Score:2)
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"
iOS isn't Linux (Score:1)
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.
Re: (Score:2)
Even better - why even let the user set the date to a time that far back? If you're going to ask for the current date and time, there should be no reason to be able to set it before the software release date. Maybe set it long in the future, but if you release the software in 2016, there
Re: (Score:2)
According to CBS Sacramento [cbslocal.com] setting the date back is supposed to show some vintage screen(s).
Re: (Score:1)
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"
Over 800 million units sold 2007-2015: That's a lot of monkeys typing....
Re: (Score:2)
Argh, it's times like this that I'm annoyed Slashdot won't let me assign points to an post when I've posted. This totally deserves a +1 funny.
EPOCH FAIL! (Score:5, Funny)
nm
Less Than Zero? (Score:1)
"It's unclear what exactly causes the issue..." (Score:2)
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.
Re: (Score:2)
But Apple never signed the Temporal Convention of 2237. Their CEO Steve21 even laughed at the threat the he'd be confined to the limits of his own mainframe, citing something along the lines of "that's 90% of all virtual space anyway, dorks!"
Why would they even bother with something like that?
Re: "It's unclear what exactly causes the issue... (Score:1)
They will have gotten around to signing it one of these epochs, eventually. Maybe on January 1, 1970.
Re: (Score:2)
But Apple never signed the Temporal Convention of 2237.
Yeah, and Apple was the first to drop the floppy drive too.
Hrm (Score:5, Interesting)
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.
Re: Hrm (Score:3)
1. Open Mobile Phone Repair shop
2. Setup bogus access point (wifi, gsm)
3. Poison time sync protocols to connected devices
4. Profit!
Re: (Score:1)
Re: (Score:1)
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. 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. ...and of course a more sophisticated attacker could probably do more.
Actually, I am pretty sure my iPhone uses a time server provided by my wireless carrier. In fact, you have to specifically turn OFF the "Set date and time automatically" (which is the default setting) to do this. Therefore, I could see a bug like this creeping into iOS at some point along the way, and not getting tested properly. Not wonderful; but perhaps understandable.
Re: (Score:3)
uses a time server provided by my wireless carrier.
Not exactly. From the cell tower connection itself. For GSM to work, all wireless communication must have access to a nearly perfect time source. [wikipedia.org]
Re: (Score:1)
uses a time server provided by my wireless carrier.
Not exactly. From the cell tower connection itself. For GSM to work, all wireless communication must have access to a nearly perfect time source. [wikipedia.org]
Thanks! I didn't know that.
Re: (Score:1)
I practically guarantee you... (Score:5, Insightful)
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.
Re: (Score:2)
Uh, underflow/rollover wrecks the adjacent memory? What sort of silly language allow that? Rollover usually results in a -1 turning into some gigantic positive value, not that it starting trying to use additional memory in an attempt to store an even smaller value. Similar with a floating point underflow, except that the ALU detects it (and usually puts out zero, although I don't know what an iPhone processor does).
Re: (Score:1)
In reply to one of your replyers (!), there are CPUs (most CPUs?) that detect and signal both floating-point and integer errors in hardware. Unix has broadened the meaning of SIGFP
Re: (Score:2)
No. In your scenario, whether the 64-bit time is positive or negative, the called function will attempt to write the full 64 bits back into the 32-bit variable, thus overwriting the following 4 bytes. CPUs don't think to themselves, "Hmm, this is a positive 64-bit value that could fit into 32 bits, so I'll only store 32 bits."
This is inaccurate. The value is being passed by address to a a function that increments it or decrements it as a result of a "settings wheel". So it's basically doing math on the value passed by address.
Unless the math messes with something outside the low order 32 bits, it really doesn't matter what the increment or decrement does to them, it won't dick with the other 32 bits which aren't where they are expected to be.
As a bonus: This likely is not a problem on 32 bit hardware; you should try it on a no
Alright, I'll bite (Score:5, Funny)
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.
Re: (Score:2)
Re: (Score:1)
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.
Are you sure? Actually, it should have looked similar to this [blogspot.com].
Re: (Score:2)
Same thing, only the screen hardware just has more than green phosphor to light up. If you light up the whole screen, you get white.
Goes to show (Score:2)
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.
conspiracy (Score:2)
This is just Apple's way of forcing users to upgrade their phones before Jan 1 1970 rolls around.
Why would you want to manually set the date/time? (Score:2)
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 fu
Devices should be de-brickable (Score:1)
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, s
Re: (Score:2)
Yes, yes, that's all very clever of you, except for the fact that iPhones do have that. You can reset the firmware, or all the internal storage, from a plugged-in computer. Almost every single byte of internal flash can be rewritten by Apple, or, hell, by an end user with iTunes. (I think the only parts that can't be overwritten are the parts that allow the phone to enter recovery.)
These 'bricked' phones? They enter recovery mode just fine, and all their internal memory can be rewritten just fine. Everyth
DFU Restore will fix it (Score:2)
The medium is the message
Re: (Score:1)
-1 word salad
Re: (Score:2)
I know "robust against pathological clock-frobbing" was the main factor that drove me to choose Android.
Re: (Score:2)
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?
Re: unix epoch (Score:1)
Certificate of deposit.
Re: Hoax? (Score:1)
Is it a hoax or is it a not-hoax.
This is /., everyone here already knows that the answer is yes.