9 ms·
Changing Date to Jan 1, 1970 disables 64-bit iOS devices
- Monory 11y agoNot 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
- dang 11y agoOK, since "brick" implies permanent, we've replaced that with "disables" above.
- raldi 11y agoSounds a lot like the Dec 31, 2008 Zune bug.
- waiseristy 11y agoThe Zune bug was persistent though, and caused by the leapyear. Even if the battery drained it went straight to bootlock. But yeah, it did fix itself at midnight.
- kazinator 11y agoSo simply pulling and re-inserting the battery is not effective every time?
- gsnedders 11y agoYou can't do that without violating the warranty.
- colejohnson66 11y agoTrue, but because there's no "warranty void if removed" stickers inside, you could open up the iPhone, unplug and replug(?) the battery, and close it up. Apple wouldn't be able to tell. Heck, I've replaced batteries in iPhones and they were taken into the store for other issues and they were covered under the warranty w/o a problem. 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.
- mikeash 11y agoIt doesn't matter anyway, they can't void your warranty just because you did some work on your phone. If you break something then of course that wouldn't be covered, but the warranty would still apply to everything else.
- engi_nerd 11y agoHow do you "simply pull and re-insert" an iPhone battery?
- kazinator 11y agoNo idea; not an Apple user.
- deleted 11y ago[deleted]
- iopq 11y agoReally? I had a Nano and I was able to open it with a soft plastic knife. Does Apple really not allow you to replace your own battery?
- natch 11y agoThe phone is not "glued" shut. It's shut with tiny torx screws that are near the lightning connector.
- dzhiurgis 11y agoI am not sure about iPhones but opened all of my Macs before, sometimes to do some upgrades or clean up. It never voided warranty. All three had some work done by Apple. As long as you do not screw up yourself something during repair, it is fine. I would expect majority of HN population to be able to follow step by step guides online.
- Monory 11y agoI heard this works, too. Didn't mention because too difficult.
- imaginenore 11y agoI 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?
- kuschku 11y agoIt’s not that – but "waiting until the time isn’t negative anymore" fixes it.
- speeder 11y agoWhen the iPod I am using as test device lost battery, it reseted to 1970, but some months later than january.
- hrrsn 11y agoI 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.
- Laforet 11y agoBefore non-removable battery became mainstream, most phones had a small internal battery to keep the internal clock ticking when the battery is being swapped. This is not unlike the CMOS battery found on PC motherboards. 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.
- frou_dh 11y ago"bricked", "permanently bricked" seem to be the hardware world's "literally". Throw the words around and contradict yourself simultaneously. Who's keeping track?
- CyberDildonics 11y agoNot people looking for traffic to their site.
- martinald 11y agolol, nice.
- the_other_os 11y ago"Think different" (except when writing unit tests or asserts for date code) "Your changing the date wrong" "It just works" (and by works we mean we plain don't test our code for a single boundary condition)
- ikeboy 11y agoI 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.
- Monory 11y agoAs far as I know, you can reset iPods via DFU mode and connection to computer. It erases all your data, though.
- mjmsmith 11y agoYep, 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 11y agoI'm surprised the default time/date is UNIX epoch + 0. Realistically, it ought to be the date that version of iOS was released.
- natch 11y agoNo 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.
- fpgaminer 11y agoI 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 11y agoI 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 11y agoWell, 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 11y agoTsch, such obvious planned obsolescence, trying to force us into a mere gigayear scale upgrade cycle.
- pearjuice 11y agoI 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 11y agoWe (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.)
- intopieces 11y agoWhy does the device allow the user to set the date back before the device was released?
- serf 11y agoRather than wonder why a device isn't more restrictive to the user, why not wonder why a device has problems with arbitrary dates?
- pklausler 11y agoI 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!
- Ezhik 11y agoI don't think the ability to completely disable a device is ever justifiable, especially on an Apple product.
- vacri 11y agoYou 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.
- gcr 11y agoWhy allow you to set your own date anyway? The device should just talk to an NTP server. Wouldn't want a malicious human setting an incorrect date now, would we? That's dangerous!
- thesimon 11y agoAnd 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
- deleted 11y ago[deleted]
- fnayr 11y agoI 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).
- kolbe 11y agoI wish Jobs were alive to respond with something like, "then don't do that--problem solved."
- cjensen 11y agoI 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 11y agoStill 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 11y agoDid that. It did not set a date close enough to now to work.
- abrowne 11y agoAh, 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 11y agoOn 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?
- thought_alarm 11y agoCivilians should create a bootable installer on a USB thumb drive, of course: https://support.apple.com/en-us/HT201372 https://support.apple.com/en-us/HT201372 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.
- profmonocle 11y ago> 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.
- duskwuff 11y agoMore importantly, iPhones usually don't use NTP. They get time directly from the cellular network.
- mb0 11y agoWhat 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?
- beedogs 11y ago"If it compiles, it ships" seems to be the order of the day at AAPL these days.
- marknutter 11y ago"Doctor, it hurts when I move my arm like this..."