Yuma 4×4

Media and Communications

Why 1/1/1970 Bricks Your iPhone

Why 1/1/1970 Bricks Your iPhone

I wasn’t going to do another video
about iPhone bugs, but the 1970 glitch that’s been going round
is interesting — because it’s probably a type of exploit I
haven’t covered before. In short: it is almost certainly an integer underflow
caused by the Unix epoch. And if you understand those terms, you don’t
need this video. Everyone else: buckle up, ‘cos here we go. January 1, 1970 is a special day for computers.
Back in the 70s, when the UNIX system and all its friends were
being originally designed, the programmers needed a simple way to represent
dates and times, without having to deal with all those awkward
human things like days and hours and minutes. They just needed a ticking clock that it was
easy to do arithmetic on. And the simplest way to do that is just a
number, an integer, representing how many seconds had elapsed
since January 1, 1970. And we’re still using that. All over the place, in pretty much every computer everywhere. It’s generally the best way to store dates
and times, because it ignores time zones and irritating
human things like that. Now, I’ve done videos about it before, so
I won’t dwell on it, but all you need to know for this is that
midnight at the start of January 1, 1970 — the date in question — is zero. That’s the first clue to what’s going on.
Clue number two: it only happens on modern, 64-bit iPhones. Now 64-bit refers to how numbers are stored
on the processor. You’ve got 64 binary digits to play with, instead of the old 32, which means you can… well, you can deal with bigger numbers, down at the really basic processor level, without having to resort to fancy programming
tricks. Changing the phone, and its operating system, from that old 32-bit system to 64 requires
some work, though, so there’ll be subtle differences in the code
between the two. And somewhere, this bug slipped in. Now, showing you 64 bits on screen is a bit
tricky, so let’s just use four bits to demonstrate
how this works. 0000 is 0. Then you count up in base 2, in binary, 1, 2, 3, 4, until you get to 15. Biggest number you can store in four bits. You can not count higher than that. But what happens if you try? Well, then you get what’s called an integer overflow. After 15 comes… 0. It wraps round and you start again, like an
old, analogue odometer on a car. Now, if you’ve only got four bits, sure, that’s going to be a problem: if you’ve got
64, well, you’re only going to get into trouble when you’ve counted up past 15 quintillion.
It’ll probably be fine. Except. If the largest number you can store,
plus one, comes back as zero… what do you get if you do zero minus one? Well, that’s called an integer underflow. You can’t store negative numbers in this format. If you can drop the number below 0, you won’t
end up with -1, you’ll end up with it wrapping around to its
maximum value. That’s why, in the original version of the
video game Civilisation, Gandhi was a dick. He started out with an aggression score of
1. And later in the game, it’d drop further, and no-one wrote code to check it didn’t drop
below zero. So instead, it wrapped around, became the
maximum possible, and suddenly Gandhi started declaring war
on everyone. Thankfully, only in a video game. Now. There is a version of this format where
negative numbers are allowed, but if Apple were using that, well, they probably wouldn’t have this problem. After all, why would you ever have a negative
time value? It’s not like anyone’s ever going to do something
like set their iPhone clock back to earlier than
1970(!) And you’ll note that you actually can’t. If you scroll all the way back, the calendar stops at January 1, 1970, at
zero, because someone at Apple went, no, hang on. That’s a bad idea. That could cause a problem. So they set the Unix epoch, as it’s called,
the zero time, as the limit. But if you do set you phone’s time to near
zero, then somewhere else in the code, there’s a
check — maybe it tries to do a battery time calculation, maybe it just runs the math on when the last
call was, or… well, it’s something that no-one’s worked
out yet. But whatever that check does, it ends up with a time before January 1, 1970, which just should be a negative integer… except it’s not. It’s wrapped all the way round, it’s giving you a date twenty times longer than the expected lifespan of the universe. And I suspect it may not deal with displaying
that date all that well. But whatever it is, it causes what’s formally
known as “undocumented behaviour” and informally known as a crash. Now, I should say that, like always when I
try and break down a bug in an Apple product, this
is speculation: it’s unlikely they’ll ever confirm exactly
what happened, and it was probably a bit more subtle than
this. And there is another type of binary integer
— it’s called a signed integer — that does handle negative numbers… but that’s a story for another time. Even if this isn’t exactly what caused it? Well, hopefully it’ll stop you making the
same mistake in your code in future. [Translating these subtitles? Add your name here!]

100 thoughts on “Why 1/1/1970 Bricks Your iPhone

  1. Stop apearing in my recomended. I watched one video and now i keep getting your videos in my recomended. Im getting smarter. This is bad

  2. I actually expected you to do it on an old iPhone, not just talk about it. Yet this was interesting enough for me to watch all of it.

  3. Hmmm the date changes to something older than the universe? Odd, but considering the components are still alive and well nothing should happen…..unless theres code to make the iPhone in question run slower with each passing year. Case closed, another one bites the dust.

  4. Who was also here just to learn how to birck everyones iPhone but instead learned about how to get Ghandi to delcare war on everyone

  5. Nobody:
    Computers: 010010101010101000010101011100100101001011101001100100101010101110010100101001111001001001010110101010010101010101010101010001

  6. Think it might be having something record (like a screen recording) and then changing your date, then ending it, as I don’t know how it stores the date whether it’s the date when started, date when ended, or date when ended minute recording time

  7. At 4:10 you say that the result is a date "20 times longer than the expected lifespan of the universe".
    Uh, I don't think so. I think, you meant to say the estimated age of the universe, right?

    Anyway, that's just me nitpicking. Awesome video! 🙂

  8. I had an iPhone 5s which I did not use for a while, I came back to the power button not working, checked the date and time to see it is on 1969. Dodged a bullet there.

  9. Back in the day, when CD burners had less buffer than they could write out in a second, computers weren't very fast, Windows wasn't able to prioritize I/O, and CD burners weren't able to resume on an interrupted burn, you had these errors "Buffer underrun".
    It is from those infamous errors that I had always assumed the opposite of "overflow", to be "underrun". Apparently I was wrong and it is an underflow?

  10. that's such an easy bug fix, without even needing to find the source (if date is close to max you have underflow, then force date to 1 jan 1970; reset back to 0). I doubt this is anything but a myth, or if it was a real bug, it was alive for a very very short time

  11. Seriously tho, who the actual f**k thought that those two wallpaper patterns go together.

    On the same wall.

    I mean……
    I have no words.

  12. The reason this video doesn't have more dislikes is because the people dumb enough to actually try it out… bricked their phone, so they couldn't dislike the video.

Leave comment

Your email address will not be published. Required fields are marked with *.