Changing Date to Jan 1, 1970 disables 64-bit iOS devices
reddit.com
reddit.com
Second, and this is more important, iOS likely is _not_ using u64. It's a BSD derivative, so it's using time_t, which is signed. No underflow involved. It just literally goes negative. And this is far more likely to be the cause of the issue. In POSIX systems, many time fetching functions return -1 as an error code, and I can easily see some programmer doing `if ((t = time(NULL)) < 0) { halt_and_catch_fire(); }` or `while (time(NULL) < 0); // wait for RTC to start up`. That's more likely, in my opinion, than some part of iOS using u64 for time and not handling large values.
The take away? My fellow engineers, please stick with time specific types (like time_t) that are i64 underneath, and please don't return negative values as error codes. Wrap broken functions like `time` into functions that return the time and an error code separately. If you'll recall from those history classes in high school and college, time before 1970 was fairly important (though clearly not as exciting without iPhones), so it's worth representing.
If they use 64bit time_t: Nothing unusual for the next 4 billion years or so until the sun explode.
A trivial example would be casting an `unsigned int` to a `time_t` (i.e., `long`). It will work with negative numbers on 32-bit systems, but will fail with negative numbers on 64-bit systems.
Particular in this case which traditionally is a function which does not indicate failure by setting `errno`. On many systems it's impossible to distinguish a second before epoch with a legitimate failure.
So, AFAIK, there's no warranty monitor to tell if the battery had been removed because that would almost certainly have false positives with phones that have fully depleted batteries. Sure, if you replace the pentalobular screws with the Phillips from iFixIt, they'd know you opened it, but if you put the pentalobular ones back on before going in, they won't be able to tell.
And the explanation is surely that the RTC is backed by the main battery and gets cleared to some default state by this procedure.
iPhones does not need this backup power since the battery is always attached. Hence in case the battery becomes completely drained the internal clock will reset. I can't recall what the default time iOS resorts to after a total power loss but IIRC it was a date well into the 2000s.
Just to be clear, this (typically) isn't possible. NTPD refuses to adjust the clock if the time difference is too large. (I don't recall what the default threshold is, but IIRC it's less than 24 hours, certainly less than 46 years.)
This is important for TLS - if an attacker could significantly roll back your system clock, they could trick your browser into accepting an expired certificate. Compromised certificates would be a problem forever, rather than just until they expired.
On a similar note, you could get extra tries at the restrictions password by setting the date forward. Don't know if either has been fixed, haven't tried recently.
I had to reinstall from a backup to enable wifi so it could talk to an ntp server and sort itself out.
Huh? Why would you set the date to one in the future? Make the date be the one of the build.
> NSDate dateWithTimeIntervalSince1970:23510262*60
2014-09-13 13:42:00 +0000
I almost always install after booting to a full OS X system on an external hard drive (so NTP syncs the time), either via a downloaded installer or after logging in to the wifi captive portal (since Internet Recovery won't do WPA Enterprise).
And I'm only being slightly facetious.
The ability of modern hardware to download install an OS directly from firmware is a truly great and useful modern innovation, but it leaves a lot of unanswered questions: What if my network is bad? What if this used hardware is stolen? What if I don't have an account? What if Apple goes bankrupt?
USB/SD/DVD installers do not require network access nor any sort of account/purchase verification, and can be created (relatively) easily and officially from downloaded installers. I have bootable disk images for every OS X installer since OS X Mavericks and I highly recommend it.
I'll include a USB installer whenever I sell an old laptop. It costs me next to nothing and gives the buyer some reassurance that they're not buying a brick. And if I decide to hang on to a piece of hardware, I have some assurance that I'll be able to use it 10 years from now.
To answer your question: a non-technologist pays someone like you to fix it. Much like the way most people bring their cars to mechanics instead of spending hundreds of hours learning to fix the vehicles personally. This type of specialization is prerequisite to the large civilizations in which we live.
It's pure luck that I'd seen this type of issue before because I'm one of those mere civilians: my Windows machine at work loses BIOS settings on power down. I've seen that until the date is restored, DropBox and several other things don't work.
Hell, two years ago I was setting up logstash, and was wondering why none of my front-end searches were getting loglines. Turns out the front-end was expecting four-digit years and I was saving two-digit years - by widening my search to include the year 14AD (rather than 2014), there were my loglines.
I don't expect a vendor to intelligently handle this error and fix it for me, but I do expect a product not to irrevocably break itself if such an error does crop up.
How locked down is locked down enough?
1. Added complexity
2. No discernible benefits
3. Time travel
Explosion: https://gist.github.com/Elv13/73ae14074c85974ca952
Fixed: https://gist.github.com/Elv13/5fc6bb2bba51aeb14f63
(LGPLv2+, not designed to be "correct", but close enough so it isn't noticeable.)