Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Bug IOS Iphone Apple Technology

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.
This discussion has been archived. No new comments can be posted.

iPhones Bricked By Setting Date To Jan 1, 1970

Comments Filter:
  • False headline... (Score:5, Informative)

    by slashkitty ( 21637 ) on Friday February 12, 2016 @03:48PM (#51496205) Homepage
    It's recoverable just by letting the battery run out, or disconnecting the battery (harder but faster) Bricking is when you permanently break the device.
    • 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?

      • by SQLGuru ( 980662 )

        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)

          by Culture20 ( 968837 ) on Friday February 12, 2016 @04:29PM (#51496505)
          You could just remove the battery. Oh. Well, at least it's not soldered on to the motherboard.
          • Re:False headline... (Score:5, Informative)

            by slashkitty ( 21637 ) on Friday February 12, 2016 @04:47PM (#51496621) Homepage
            It's actually attached with a snap clip. Only the original iphone had it soldered on. I've replaced a few iphone batteries.
            • After using petalobe screwdrivers to gently remove the casing. It's not quite as easy as with other phones (and yes, I know, as I too am an iPhone junky).
              • Re: (Score:3, Interesting)

                by flopsquad ( 3518045 )
                I have owned multiple iPhones. I love taking apart electronics and fixing/modifying/resoldering them. Taking apart the iPhone to do anything, even as simple as unhooking the battery, is a special hell I would not recommend for any but the most diehard enthusiasts. (Or a dedicated repair outfit, ofc.)

                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
                • Third, and maybe this is just observational voodoo, but I swear that manhandling the flexible polymer battery too much degrades battery life.

                  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

              • by GrahamCox ( 741991 ) on Saturday February 13, 2016 @12:43AM (#51499119) Homepage
                using petalobe screwdrivers

                Yeah, those 10^15 sided screws are a bugger to not strip. That's why I replace mine with pentalobe screws - much more robust.
            • by jandrese ( 485 )
              The ones I've replaced are just glued in with rubber cement (comes out with a firm but gentle pull) and only the power connector is clipped in. The power connector comes out with a gentle pull as well.
          • And then your phone bricks itself with an Error 53 for not having the work done by an Apple tech...
            • by doccus ( 2020662 )

              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?

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

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

          • "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.

      • Go to http://www.apple.com/iphone/co... [apple.com] and search for "Power and Battery" section...

      • Fire up an Arduino that scans the WLAN for Apple OUIs and send them a WOL every five seconds (Project SHITWEASEL), that runs down the battery in no time.
    • by BitZtream ( 692029 ) on Friday February 12, 2016 @04:54PM (#51496673)

      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.

      • by samkass ( 174571 )

        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.

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

    • A faster way to drain the battery is by putting it in the microwave for ~2 minutes on "High".

  • 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

    • by PPH ( 736903 )

      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.

      • Timestamp? As in a system generated date/time? Why would you ever expect a less than zero value?

        Because I"m hardpressed to imagine any advantage in making that assumption. And useless assumptions are bad

      • by Tim the Gecko ( 745081 ) on Friday February 12, 2016 @05:18PM (#51496925)

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

      • by Anonymous Coward

        as far back as 14,000,000,006 years.

        You got modded down by a Christian fundie.

    • 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

      • Just adding that the platform-dependent units used by mach_absolute_time are tiny. Nanoseconds on some systems, based on the processor or motherboard clock speed on others. GCD use 64 bit nanoseconds, NSDate uses double precision seconds since some reference date which is _not_ 1970; I think 2001 or something like that. Very easy to use with microsecond resolution for the next +/- 200 years.
    • by Anonymous Coward

      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

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

    • by Geoffrey.landis ( 926948 ) on Friday February 12, 2016 @04:39PM (#51496569) Homepage

      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]

    • 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?

  • Hoax? (Score:3, Funny)

    by PPH ( 736903 ) on Friday February 12, 2016 @03:51PM (#51496235)

    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)

      by macs4all ( 973270 )

      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.

    • Yeah, what is the hoax here? Did TFS mean "bug"?

    • Not true. An iPhone requires a convection microwave oven, not a standard microwave oven.

    • 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!

  • by Etcetera ( 14711 ) on Friday February 12, 2016 @03:53PM (#51496247) Homepage

    https://xkcd.com/376/ [xkcd.com]

    The universe started in 1970. Anyone claiming to be over 38 is lying about their age.

  • 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"

    • by Anonymous Coward

      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.

    • by tlhIngan ( 30335 )

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

      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

    • by Longjmp ( 632577 )
      It's kind of an eater egg hoax as someone said.
      According to CBS Sacramento [cbslocal.com] setting the date back is supposed to show some vintage screen(s).
    • 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....

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

    by Gravis Zero ( 934156 ) on Friday February 12, 2016 @03:59PM (#51496299)

    nm

  • I love Elvis Costello!
  • 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.

    • 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?

  • Hrm (Score:5, Interesting)

    by cfalcon ( 779563 ) on Friday February 12, 2016 @04:24PM (#51496479)

    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.

    • 1. Open Mobile Phone Repair shop
      2. Setup bogus access point (wifi, gsm)
      3. Poison time sync protocols to connected devices
      4. Profit!

      • by umghhh ( 965931 )
        I think your post should be removed as it presents idea that could actually be used for profit which "1.2.3...n. profit!" posts never do.
    • 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.

    • by Gr8Apes ( 679165 )
      The funny thing is that 1970-1-1 is not an epoch for iOS.
  • by tlambert ( 566799 ) on Friday February 12, 2016 @04:37PM (#51496561)

    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.

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

    • by obsess5 ( 719497 )
      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."

      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
      • 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

  • by U2xhc2hkb3QgU3Vja3M ( 4212163 ) on Friday February 12, 2016 @04:54PM (#51496671)

    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.

    • Oh this is very easy to explain: it's because the first color Macintosh didn't come out until 1985, and all Macs before that had 512x384 screens.

    • 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].

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

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

  • This is just Apple's way of forcing users to upgrade their phones before Jan 1 1970 rolls around.

  • 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

  • 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

    • by DavidTC ( 10147 )

      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

  • The medium is the message

Real Programmers don't write in FORTRAN. FORTRAN is for pipe stress freaks and crystallography weenies. FORTRAN is for wimp engineers who wear white socks.

Working...