
Changing Date to Jan 1, 1970 disables 64-bit iOS devices - _jomo
https://www.reddit.com/r/jailbreak/comments/458ao3/discussion_changing_time_date_settings_to_jan_1/
======
fpgaminer
I learned about this yesterday from a Tom Scott video
([https://www.youtube.com/watch?v=MVI87HzfskQ](https://www.youtube.com/watch?v=MVI87HzfskQ)).
I find it odd that his sources are suggesting that this is an integer
underflow bug. First, while integer underflow itself would be a bug in this
case (if it's occurring) the real bug would be not handling large time values.
If they are indeed using u64 to store time, the system should be designed to,
you know, handle u64. Why would parts of the system break for values like
0xFFFFFFFFFFFFFFFF?

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.

~~~
OliverJones
I wonder what happens if one sets the iOS clock forward to noon on Jan 19,
2038? (at 03:14:08 UTC on Jan 19 2038 the 32-bit signed time_t flips over).

~~~
Elv13
Well, if they use 32bit time_t: Exactly the same is this bug.

If they use 64bit time_t: Nothing unusual for the next 4 billion years or so
until the sun explode.

~~~
madaxe_again
Tsch, such obvious planned obsolescence, trying to force us into a mere
gigayear scale upgrade cycle.

~~~
valarauca1
At least after the 128bit switch I know that proton decay will be the next
thing I need to worry about.

~~~
simonh
Introducing the iPhone 7. It's the first iPhone specifically engineered to
withstand the Sun exploding in 7 billion years' time, and we think you're
going to love it.

------
thesimon
And 4chan (?) already started trolling people with "blast to the past images".
At least a bit more clever than waterproofing or microwaving.

[https://twitter.com/Chubzey422/status/698210841078984706](https://twitter.com/Chubzey422/status/698210841078984706)

[https://twitter.com/gabdi_/status/698230041591836672](https://twitter.com/gabdi_/status/698230041591836672)

~~~
ly
Yep, that was 4chan:
[http://i.imgur.com/lPqI1nD.png](http://i.imgur.com/lPqI1nD.png)

------
Monory
Not permanently. Some report that it fixes itself after time, but the most
widely accepted solution is to let your iPhone battery die. It seems to fix
this bug every time.

[https://discussions.apple.com/thread/7458347](https://discussions.apple.com/thread/7458347)

~~~
imaginenore
I find that more interesting than the bug itself. Why battery dying fixes the
issue? Does that reset the time? And if it does, then to what?

~~~
hrrsn
I fix iPhones. The battery needs to be really, really dead before it'll fix
the issue. When a battery is reconnected the internal date is reset back to 0
(Jan 1 1970) until the phone connects to a cellular network/NTP server.

~~~
kiliankoe
Wouldn't that result in the same outcome though? I find it more likely that
the clock is reset to a more "sane" time - like Laforet stated as being "well
into the 2000s".

~~~
Macha
When I least had an iPod touch, pretty sure it reset to 1/1/07

------
profmonocle
> Theoretically, attackers can send malicious NTP requests to adjust every
> iPhone's time settings to January 1, 1970

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.

~~~
mb0
What if you crafted a program that mimicked the functionality of an ntp
server, and but it had a built in memory of what times have been given out to
network clients? Couldn't you in theory send a series of NTP answers that
quickly stepped back the clock of the target system, with the stepback value
being whatever the maximum value the ntp client will handle? Answer one
subtracts the time by 24 hours, the next by another 24 hours, the next by 24
hours? Is there a limit to how frequently the time can be stepped back?

------
ikeboy
I once had an iPod touch disabled for millions of minutes after entering the
wrong password too many times. Turns out the date was reset back, probably
because it had died, while the "last pass enter" must have been set forward,
and so it was waiting several years to allow another password.

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.

~~~
mjmsmith
Yep, this was my iPad after I had a broken screen replaced:
[http://blog.marksmith.org/too-much-security/](http://blog.marksmith.org/too-
much-security/)

I had to reinstall from a backup to enable wifi so it could talk to an ntp
server and sort itself out.

~~~
TazeTSchnitzel
I'm surprised the default time/date is UNIX epoch + 0. Realistically, it ought
to be the date that version of iOS was released.

~~~
natch
No programmer ever wished for more special cases when integrating date
handling code, especially on a networked device and one that's so tightly
integrated with other platforms and devices. And imagine the nightmare of
testing the device pre-release, all while faking out the dates, both local and
on NTP servers and on development desktop machines the under-development
devices are tethered to, and somehow knowing exactly when the release day was
going to be, possibly years in advance. So... no, I'm not sure about that
plan. And I guess the bug would be unaffected in any case.

~~~
TazeTSchnitzel
> And imagine the nightmare of testing the device pre-release, all while
> faking out the dates

Huh? Why would you set the date to one in the future? Make the date be the one
of the build.

------
frou_dh
"bricked", "permanently bricked" seem to be the hardware world's "literally".
Throw the words around and contradict yourself simultaneously. Who's keeping
track?

~~~
CyberDildonics
Not people looking for traffic to their site.

~~~
martinald
lol, nice.

------
cjensen
I repaired a MacBook Pro which had been powered off for an extended time and
couldn't load OS X onto it. Turned out it was using hardware time to determine
if a cert was valid when validating the OS X install image. (Validation is
done by the downloaded installer so I infer that it was trying to make sure
the download was okay and was not trying to prevent third-party OS installs).
I fixed it by spawning a shell from the installer and setting the date the
unix way -- but what is a mere civilian supposed to do?

~~~
abrowne
Still not known or obvious to many, but less cryptic than a terminal to most:
reset the NVRAM (aka PRAM). Hold command-option-P-R keys until you hear the
startup chime for a second time.

~~~
cjensen
Did that. It did not set a date close enough to now to work.

~~~
abrowne
Ah, of course not, since how can the default be set to the current time?

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).

~~~
cjensen
On Linux and Windows, the NTP update daemon "sanity checks" the new date. It
refuses to update the time if the new time is "too far" from the current time.
Is the Mac any different on this front?

------
kolbe
I wish Jobs were alive to respond with something like, "then don't do that--
problem solved."

------
intopieces
Why does the device allow the user to set the date back before the device was
released?

~~~
serf
Rather than wonder why a device isn't more restrictive to the user, why not
wonder why a device has problems with arbitrary dates?

~~~
pklausler
I think that we can be more generous to a vendor who didn't test sufficiently
for a failure mode that would be a legitimate use only to a (reverse) time
traveller who wouldn't be able to connect the device to any network in
existence in 1970 anyway. Seriously, people are complaining about problems
when they go out of their way to set the date to a bogus value? Some behavior
is its own punishment, people!

~~~
vacri
You mean a failure mode that is simply the time server saying "start of epoch,
no offset"? There's a ton of ways for an offset to be zeroed by accident.

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.

------
pearjuice
I remember they thought Y2K would pose a challenge and everybody laughed it
off afterwards. Could they have ever imagined bugs like these would become
prevalent in the future?

~~~
Elv13
We (at ring.cx) had a "Y2K" bug on Jan 1. Some old boring code was replaced
with more "readable" one and "underflowed" (technically, it did not expect
negative values).

Explosion:
[https://gist.github.com/Elv13/73ae14074c85974ca952](https://gist.github.com/Elv13/73ae14074c85974ca952)

Fixed:
[https://gist.github.com/Elv13/5fc6bb2bba51aeb14f63](https://gist.github.com/Elv13/5fc6bb2bba51aeb14f63)

(LGPLv2+, not designed to be "correct", but close enough so it isn't
noticeable.)

------
marknutter
"Doctor, it hurts when I move my arm like this..."

------
fnayr
I wonder if instead of it being an integer underflow issue, it has to do with
a divide-by-zero issue (if something ever is divided by the entered date).

------
beedogs
"If it compiles, it ships" seems to be the order of the day at AAPL these
days.

