Wer ein bestimmtes Datum auf einem iOS-Gerät mit 64-Bit-Chip einstellt, kann es offenbar dauerhaft zerstören. Das besagen zumindest Nutzerberichte im Jailbreak-Forum auf Reddit. Demnach endet das Gerät bei einem Neustart in einer endlosen Bootschleife, wenn manuell der 1. Januar 1970 – der Beginn der Unix-Zeitzählung – ausgewählt wird.
Die Datumseinstellung 1. Januar 1970 führt dazu, dass ein iPhone in einer Bootschleife hängen bleibt (Screenshot: ZDNet.de).Von dem Problem betroffen scheinen alle Geräte mit einem 64-Bit-Prozessor zu sein, also Apples A7, A8, A8X, A9 und A9X. Dazu zählen sämtliche iPhone-Modelle ab dem iPhone 5S sowie entsprechend ausgestattete iPads und iPods Touch, inklusive der jeweils aktuellen Generation.
Ein Youtube-Video demonstriert das Phänomen. Demnach kann es nur auftreten, wenn in den allgemeinen Einstellungen unter dem Punkt „Datum & Uhrzeit“ der automatische Bezug der Uhrzeit deaktiviert und anschließend das besagte Datum eingestellt wurde. Letzteres kann eigentlich nur absichtlich geschehen, denn für die Auswahl muss man bis ans Ende des verfügbaren Zeitraums scrollen, was nur über einen mehrmaligen Umweg über das Haupteinstellungsmenü möglich ist. Wird das Gerät anschließend neu gestartet, bleibt es beim Versuch des Hochfahrens bei der Anzeige des Apple-Logos hängen.
Bisher ist keine konkrete Ursache und keine Lösung für das Problem bekannt. Auch ein Wiederherstellen des Geräts über iTunes, was sonst ein probates Mittel bei hartnäckigen Problemen ist, funktioniert angeblich nicht. Zwar soll sich der Wartungsmodus (DFU) aktivieren und die Wiederherstellung starten lassen, doch auch danach bleibt das Gerät beim Neustart hängen, wie 9to5Mac berichtet. Eventuell hängt der Fehler damit zusammen, dass die interne Uhrzeit durch Einstellen der Unix-Startzeit in bestimmten Zeitzonen auf einen Wert unter 0 fällt.
Produktiver arbeiten mit Unified Communications & Collaboration
Mit Unified Communications & Collaborations können Unternehmen die Produktivität der Anwender steigern, die Effizienz der IT verbessern und gleichzeitig Kosten sparen. Damit die unbestrittenen Vorteile einer UCC-Lösung sich in der Praxis voll entfalten können, müssen Unternehmen bei der Implementierung die Leistungsfähigkeit der Infrastruktur überprüfen.
Ein Twitter-Nutzer schreibt, dass sein Gerät nach fünf Stunden wieder startete. Es sei dann zwar „höllisch“ langsam gewesen, erlaubte aber, das korrekte Datum einzustellen. Andere Anwender melden jedoch, dass sie ihr Gerät auch nach 24 Stunden nicht wieder in Betrieb nehmen konnten.
Schon zuvor sorgten diverse Fehler dafür, dass iOS-Geräte abstürzten und sich unter Umständen auch nicht mehr starten ließen. Vergangenes Jahr wurde beispielsweise ein Bug in iOS 8 bekannt, durch den ein iPhone beim Empfang einer Textnachricht mit einer bestimmten Folge aus Symbolen und arabischen Schriftzeichen abstürzen und ebenfalls in einer Bootschleife enden konnte. Vor Kurzem tauchte zudem eine Prank-Website auf, deren Aufruf den Browser Safari abstürzen ließ und auf einem iPhone einen Neustart des Geräts auslösen konnte.
Tipp: Wie gut kennen Sie das iPhone? Überprüfen Sie Ihr Wissen – mit 15 Fragen auf silicon.de.
Neueste Kommentare
11 Kommentare zu Falsche Datumseinstellung kann iOS-Geräte dauerhaft lahmlegen
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Nett ist gewarnt zu werden, aber wenn „nette“ Zeitgenossen das am ipad deines Kindes in einer Tabletklasse „ausprobieren“ – da dient diese Warnung leider nur als Information, um weitere Geräte mutwillig lahm zu legen, denn versehentlich stellt man sein Gerät sicher nicht auf 1970 zurück.
Vielleicht nimmt man den Artikel lieber von der Seite… und allen anderen Seiten.
Wir für unseren Teil müssen erstmal sehen, wie wir den Schaden von den „netten“ Zeitgenossen ersetzt bekommen.
Hallo Frau Schmidt,
Apple hat bereits einen Fix für das Problem angekündigt. Zudem soll ein auf diese Weise lahmgelegtes Gerät wieder starten, nachdem sich der Akku einmal komplett entleert hat. Weitere Informationen dazu finden Sie hier: http://www.zdnet.de/88259968/apple-kuendigt-fix-fuer-datumsfehler-bei-ios-geraeten-an/
Sorry hab noch was vergessen:
Wenn man selbstgefällig von sich behauptet, man sei unfehlbar und die eigene Fangemeinde glaubt das auch noch und verbreitet es schön weiter, dann kommt halt irgendwann mit Sicherheit das böse Erwachen.
Aber das wird jetzt bestimmt wieder mit zahllosen links Pseudo wiederlegt oder als Sicherheitsfeature verteidigt
@Frank Furter ( cooler Name )
Das Problem betrifft aber nur System die, die Unix Zeit verwenden, und ich gehe davon aus das es sowohl Apple als auch die Linux-Community es schaffen werden in 22 Jahren eine Lösung zu finden, natürlich ist auch Android Unix basierend, Google nutzt meines Wissens aber nicht die Unix-Zeit.
Lustig oder auch nicht, wenn man dann in einem wlan Netzwerk die NTP Einstellungen manipuliert. Dann braucht man wahrscheinlich nichtmal Hand an die iphones anlegen und es wäre alle im Netzwerk auf das Datum umgestellt…oh oh
@Hmm Genau aus diesem Grund würde ein NTP Client aber keine Zeit vom Server akzeptieren, wenn diese mehr als 10 Minuten (das ist glaube ich der Default) von der eigenen Systemzeit abweicht. Um die NTP Pakete mit so einer Differenz anzunehmen, muss man erst die Systemzeit auf einen ähnlichen Level bringen. Also funktioniert das höchstens theoretisch…
Stimmt. Mein Fehler.
Wie kommt bloß jemand auf die Idee, den 1.1.1970 als Datum in ein technisches Gerät einzugeben???
Was viele, für die die Welt in Apple und Microsoft aufgeteilt ist, nicht wissen: es gibt da draußen, wo die richtg großen Rechner stehen, auch noch ganz andere Betriebssysteme, die auch nicht auf dem Blech unterm Schreibtisch laufen wollen.
Bei einem dieser Betriebssysteme beginnt die „Zeitrechnung“ mit dem 1. Januar 1970. Alles davor ist „negative“ Zeit.
Deshalb ist es gar nicht so abwegig für Menschen, die mehr als nur ein Betriebssystem kennen, bei technischen Geräten mal zu testen, was denn die frühest mögliche Zeit ist, die eingegeben werden kann, um dadurch etwas über die internen Zeitstrukturen herauszufinden.
Am 19. Januar 2038 um 3:14:08 Uhr UTC wird es übrigens bei den Rechnern mit dem gewissen Betriebssystem, bei denen die Zeit in einer vorzeichenbehafteten 32-Bit-Variable gespeichert ist, Probleme geben, weil es dann einen Überlauf geben wird.
Aber das kann den oben genannten „Fraktionen“ egal sein, da deren Systeme sowieso eine deutlich geringere Lebenserwartung haben…
Ha ha.
Das wundert mich immer wieder, auf was für Ideen die Leute kommen, und wie viel Zeit investiert wird, um nach möglichen Fehlerquellen zu suchen.
Ich schätze mal, da muss man schon sehr phantasievoll sein, um auf derartige Lösungen zu kommen.
@ATX Das macht man sicher nicht selber, aber es gibt ja immer mal wieder „lustige“ Zeitgenossen, die solche Sachen testen, wenn sie ein fremdes Handy in die Hand bekommen. Die ominöse Textnachricht, welche zum Crash des iPhones führte, habe ich damals auch von mehreren Bekannten geschickt bekommen – welche das ganz witzig fanden. Allerdings hatte ich damals noch ein Android Gerät, also war es mir egal. Ich bin aber froh, mit solchen Meldungen hier vorgewarnt zu werden… ;)
Und wer hat vor, sein Gerät auf dieses Datum zu stellen? Etwa die Redaktion oder Redakteur. Da kann man nur noch mit dem Kopf schütteln über derartige Artikel. Denken scheint ein unbekanntes Wort zu sein.