64bit IOS-Geräte booten nicht mehr, nach manueller Datumsrückstellung auf 1.1.1970.

Kurios. Aber hat das praktische Relevanz?
 
Kann man bei jeder nicht pre-auth remote code execution fragen, oder?
Kann man bei allem fragen wo sich die Frage stellt. Gibt es denn nun eine praktische (sicherheitstechnische) Relevanz? Das ist keine rhetorische Frage meinerseits. Ich will ja gar nicht widersprechen, dass das durchaus interessant ist. :kopfkratz:
 
das naheliegende wäre eine app die z.b. die unixtime, aus welchen gründen oder fehlern auch immer, auf 0 setzt.
 
Zuletzt bearbeitet:
Gesetzt den Fall, jemand bittet darum, mal eben kurz das iDevice benutzen zu dürfen. Es gibt genug Situationen im Alltag, wo man das macht. Es muss ja keine fremde Person sein.

Kann dieser jemand das iDevice über diesen Bug bricken? Auch das sollte theoretisch doch gehen, oder?
 
Naja, ich drücke nicht Hinz und Kunz mein Handy in die Hand... Und bei denen, wo ich das tue, weiss ich, dass die solchen Quatsch nicht machen.
 
Es geht mir nicht darum, ob und wem Du ggf. Dein Telefon gibst, außerdem betrifft es auch andere Geräte als das iPhone.
Quelle
Betroffen scheinen alle iOS-Geräte mit 64-Bit-Prozessor zu sein, also mit A7, A8, A8X, A9 und A9X – iPhones, iPads und iPod touch inklusive der jeweils jüngsten Generation.

Es geht mir darum, ob es grundsätzlich möglich wäre.
 
Also ich konnte neulich Bilder nicht finden, die ich frisch mit dem iPhone geschossen habe.
Danach habe ich sie in Fotos entdeckt - sie sind auf dem Handy mit dem Datum 01.01.1970 abgelegt worden.
Das war um Weihnachten, ich glaube da gabs 9.2 noch nicht.
Scheinbar kann da auf jeden Fall schon was schiefgehen! Eventuell kann sich also auch mal die Uhrzeit verstellen und man hat den Salat.
 
@fröschlein
ja, ist natürlich möglich, dauert aber ... endlos lang, bis ... er/sie ... beim ... 01 ... 01 ... 1970 ... ist.

@bigmatze
das hat damit eher nichts zu tun. dateien ohne oder besser mit ungültigem datum werden, je nach betriebssystem, als unixtime 0, was dem 01.01.1970 entspricht, angezeigt.

so wie es aussieht, ist apple einfach zu blöd den umgang mit 0 in verbindung mit (noch dazu negativen) zeitzonen ordentlich zu implementieren.
 
Zuletzt bearbeitet:
Hi Olivetti :xsmile:

danke. Dann habe ich den Bug schon richtig verstanden. Auch wenn es lange dauert, für „einen Racheakt unter Freunden” ist er damit geeignet. Ich habe da bestimmte Szenarien im Kopf, das ist nicht schön...
 
jo. gelöscht wird ja nix, aber das kann ziemlich nerven, solange warten zu müssen, bis der akku leer ist.
taugt also schon als 'spaß am kumpel'. :drink:
 
Ach, ist inzwischen klar, dass die Schleife bei allen Geräten vorübergehend ist?

Ich las von einigen Besitzern, bei denen der Fehler bleibt. Bei anderen, je nach Zeitzone, startete das Gerät nach ein paar Stunden wieder vollständig.

Ich bin gespannt, ob hier jemand mit diesem Problem auftaucht.

Bei Dir soweit alles gut?
 
üblicherweise ist spätestens nach akkuentnahme oder warten bis selbiger leer ist, schluss. dann booten sie wieder.

jo, hier alles bestens. lass dich nicht so arg stressen. :boykiss:
 
:girlkiss: wie kann ich da noch gestresst sein... Alles wieder gut, miese Tage hat jeder mal.

Danke, für die Antwort an bigmatze. Da bin ich ganz drüber weg gekommen, sorry @bigmatze.
 
es gibt die private frameworks, da weiß der normalsterbende üblicherweise nicht, was alles geht. :p
siehe: Is there any way to change the date/time as seen on the iOS simulator (other than changing Mac settings)?
Also jedenfalls bei Apps aus dem Store hätte ich da keine Bedenken. Worauf wolltest Du bei dem Link hinaus? Vielleicht übersehe ich etwas, aber da ist ja von method swizzling die Rede. Dadurch wird der eigenen App aber bloß ein anderes Datum vorgetäuscht und nicht etwa die Systemzeit geändert.
 
mir geht's um's swizzling an sich. der link ist in dem zusammenhang evtl. unglücklich gewählt.
 
Zurück
Oben Unten