WEBVTT
Kind: captions
Language: en

1
00:00:00.070 --> 00:00:02.270
I wasn't going to do another video
about iPhone bugs,

2
00:00:02.270 --> 00:00:05.360
but the 1970 glitch that's been going round
is interesting --

3
00:00:05.360 --> 00:00:08.839
because it's probably a type of exploit I
haven't covered before. In short:

4
00:00:08.839 --> 00:00:12.879
it is almost certainly an integer underflow
caused by the Unix epoch.

5
00:00:12.879 --> 00:00:16.429
And if you understand those terms, you don't
need this video.

6
00:00:16.429 --> 00:00:19.340
Everyone else: buckle up, 'cos here we go.

7
00:00:19.340 --> 00:00:23.789
January 1, 1970 is a special day for computers.
Back in the 70s,

8
00:00:23.789 --> 00:00:27.460
when the UNIX system and all its friends were
being originally designed,

9
00:00:27.460 --> 00:00:31.789
the programmers needed a simple way to represent
dates and times,

10
00:00:31.789 --> 00:00:36.899
without having to deal with all those awkward
human things like days and hours and minutes.

11
00:00:36.899 --> 00:00:40.570
They just needed a ticking clock that it was
easy to do arithmetic on.

12
00:00:40.570 --> 00:00:45.219
And the simplest way to do that is just a
number, an integer,

13
00:00:45.219 --> 00:00:50.020
representing how many seconds had elapsed
since January 1, 1970.

14
00:00:50.020 --> 00:00:52.649
And we're still using that. All over the place,

15
00:00:52.649 --> 00:00:54.800
in pretty much every computer everywhere.

16
00:00:54.800 --> 00:00:57.489
It's generally the best way to store dates
and times,

17
00:00:57.489 --> 00:01:02.090
because it ignores time zones and irritating
human things like that.

18
00:01:02.090 --> 00:01:05.540
Now, I've done videos about it before, so
I won't dwell on it,

19
00:01:05.540 --> 00:01:07.500
but all you need to know for this is that
midnight

20
00:01:07.500 --> 00:01:09.990
at the start of January 1, 1970 --

21
00:01:09.990 --> 00:01:13.350
the date in question -- is zero.

22
00:01:13.350 --> 00:01:16.390
That's the first clue to what's going on.
Clue number two:

23
00:01:16.390 --> 00:01:19.560
it only happens on modern, 64-bit iPhones.

24
00:01:19.560 --> 00:01:22.790
Now 64-bit refers to how numbers are stored
on the processor.

25
00:01:22.790 --> 00:01:26.200
You've got 64 binary digits to play with,

26
00:01:26.200 --> 00:01:28.470
instead of the old 32, which means you can...

27
00:01:28.470 --> 00:01:30.670
well, you can deal with bigger numbers,

28
00:01:30.670 --> 00:01:33.259
down at the really basic processor level,

29
00:01:33.259 --> 00:01:36.049
without having to resort to fancy programming
tricks.

30
00:01:36.049 --> 00:01:38.170
Changing the phone, and its operating system,

31
00:01:38.170 --> 00:01:42.170
from that old 32-bit system to 64 requires
some work, though,

32
00:01:42.170 --> 00:01:45.200
so there'll be subtle differences in the code
between the two.

33
00:01:45.200 --> 00:01:47.950
And somewhere, this bug slipped in.

34
00:01:47.950 --> 00:01:51.259
Now, showing you 64 bits on screen is a bit
tricky,

35
00:01:51.259 --> 00:01:55.329
so let's just use four bits to demonstrate
how this works.

36
00:01:55.329 --> 00:01:56.770
0000 is 0.

37
00:01:56.770 --> 00:01:58.979
Then you count up in base 2, in binary,

38
00:01:58.979 --> 00:02:01.630
1, 2, 3, 4, until you get to 15.

39
00:02:01.630 --> 00:02:03.340
Biggest number you can store in four bits.

40
00:02:03.340 --> 00:02:06.259
You can not count higher than that.

41
00:02:06.259 --> 00:02:07.649
But what happens if you try? Well,

42
00:02:07.649 --> 00:02:09.770
then you get what's called an integer overflow.

43
00:02:09.770 --> 00:02:12.380
After 15 comes... 0.

44
00:02:12.380 --> 00:02:14.910
It wraps round and you start again, like an
old,

45
00:02:14.910 --> 00:02:16.960
analogue odometer on a car. Now,

46
00:02:16.960 --> 00:02:18.890
if you've only got four bits, sure,

47
00:02:18.890 --> 00:02:21.970
that's going to be a problem: if you've got
64, well,

48
00:02:21.970 --> 00:02:22.790
you're only going to get into trouble

49
00:02:22.790 --> 00:02:29.320
when you've counted up past 15 quintillion.
It'll probably be fine.

50
00:02:29.320 --> 00:02:33.480
Except. If the largest number you can store,
plus one,

51
00:02:33.480 --> 00:02:35.430
comes back as zero...

52
00:02:35.430 --> 00:02:38.190
what do you get if you do zero minus one?

53
00:02:38.190 --> 00:02:40.120
Well, that's called an integer underflow.

54
00:02:40.120 --> 00:02:42.590
You can't store negative numbers in this format.

55
00:02:42.590 --> 00:02:46.410
If you can drop the number below 0, you won't
end up with -1,

56
00:02:46.410 --> 00:02:49.620
you'll end up with it wrapping around to its
maximum value.

57
00:02:49.620 --> 00:02:53.050
That's why, in the original version of the
video game Civilisation,

58
00:02:53.050 --> 00:02:55.500
Gandhi was a dick.

59
00:02:55.500 --> 00:02:58.520
He started out with an aggression score of
1.

60
00:02:58.520 --> 00:03:00.670
And later in the game, it'd drop further,

61
00:03:00.670 --> 00:03:03.010
and no-one wrote code to check it didn't drop
below zero.

62
00:03:03.010 --> 00:03:06.120
So instead, it wrapped around, became the
maximum possible,

63
00:03:06.120 --> 00:03:09.200
and suddenly Gandhi started declaring war
on everyone.

64
00:03:09.200 --> 00:03:11.280
Thankfully, only in a video game.

65
00:03:11.280 --> 00:03:15.770
Now. There is a version of this format where
negative numbers are allowed,

66
00:03:15.770 --> 00:03:17.960
but if Apple were using that, well,

67
00:03:17.960 --> 00:03:20.050
they probably wouldn't have this problem.

68
00:03:20.050 --> 00:03:23.370
After all, why would you ever have a negative
time value?

69
00:03:23.370 --> 00:03:25.650
It's not like anyone's ever going to do something
like

70
00:03:25.650 --> 00:03:28.950
set their iPhone clock back to earlier than
1970(!)

71
00:03:28.950 --> 00:03:32.720
And you'll note that you actually can't.

72
00:03:32.720 --> 00:03:34.160
If you scroll all the way back,

73
00:03:34.160 --> 00:03:38.130
the calendar stops at January 1, 1970, at
zero,

74
00:03:38.130 --> 00:03:39.170
because someone at Apple went,

75
00:03:39.170 --> 00:03:41.200
no, hang on. That's a bad idea.

76
00:03:41.200 --> 00:03:42.810
That could cause a problem.

77
00:03:42.810 --> 00:03:45.910
So they set the Unix epoch, as it's called,
the zero time,

78
00:03:45.910 --> 00:03:47.110
as the limit.

79
00:03:47.110 --> 00:03:49.720
But if you do set you phone's time to near
zero,

80
00:03:49.720 --> 00:03:52.080
then somewhere else in the code, there's a
check --

81
00:03:52.080 --> 00:03:54.440
maybe it tries to do a battery time calculation,

82
00:03:54.440 --> 00:03:57.340
maybe it just runs the math on when the last
call was, or...

83
00:03:57.340 --> 00:03:59.520
well, it's something that no-one's worked
out yet.

84
00:03:59.520 --> 00:04:01.900
But whatever that check does,

85
00:04:01.900 --> 00:04:05.860
it ends up with a time before January 1, 1970,

86
00:04:05.860 --> 00:04:08.050
which just should be a negative integer...

87
00:04:08.050 --> 00:04:08.740
except it's not.

88
00:04:08.740 --> 00:04:10.160
It's wrapped all the way round,

89
00:04:10.160 --> 00:04:12.810
it's giving you a date twenty times longer

90
00:04:12.810 --> 00:04:15.020
than the expected lifespan of the universe.

91
00:04:15.020 --> 00:04:19.150
And I suspect it may not deal with displaying
that date all that well.

92
00:04:19.150 --> 00:04:23.770
But whatever it is, it causes what's formally
known as "undocumented behaviour"

93
00:04:23.770 --> 00:04:25.390
and informally known as a crash.

94
00:04:25.390 --> 00:04:27.750
Now, I should say that, like always when I
try and

95
00:04:27.750 --> 00:04:31.300
break down a bug in an Apple product, this
is speculation:

96
00:04:31.300 --> 00:04:34.310
it's unlikely they'll ever confirm exactly
what happened,

97
00:04:34.310 --> 00:04:36.140
and it was probably a bit more subtle than
this.

98
00:04:36.140 --> 00:04:38.450
And there is another type of binary integer
--

99
00:04:38.450 --> 00:04:40.070
it's called a signed integer --

100
00:04:40.070 --> 00:04:41.850
that does handle negative numbers...

101
00:04:41.850 --> 00:04:44.630
but that's a story for another time.

102
00:04:44.630 --> 00:04:47.620
Even if this isn't exactly what caused it?

103
00:04:47.620 --> 00:04:49.880
Well, hopefully it'll stop you making the
same mistake

104
00:04:49.880 --> 00:04:50.380
in your code in future.

105
00:04:51.380 --> 00:04:53.380
[Translating these subtitles? Add your name here!]