iOS-apparaten met 64bit-socs belanden in bootloop door wijzigen datum

Een bug in iOS 8 en hoger zorgt ervoor dat iOS-apparaten met 64bit-socs in een bootloop kunnen belanden. Door bij het instellen van de datum terug te scrollen naar 1 januari 1970 en vervolgens het toestel te rebooten, kan iOS niet meer goed opstarten.

Het terugscrollen naar 1 januari 1970 vergt enkele stappen, omdat iOS niet in een keer zover teruggaat. Wie dat wil, moet zover terugscrollen als mogelijk is, dan op Terug klikken, vervolgens weer de datum instellen en zo steeds verder teruggaan tot 1 januari 1970. Daarna functioneert het toestel wel, tenzij de gebruiker besluit te rebooten. De bug kwam naar boven in posts op 4Chan en Reddit.

Het is onbekend wat de bootloop veroorzaakt, maar het is mogelijk dat iOS werkt met een Unix-timestamp, die aan 1 januari 1970 middernacht GMT het getal 0 toekent. Als gebruikers in een tijdzone zitten ten westen van deze tijdzone, zou het gaan om een 'negatieve tijd'. Apple heeft de bug nog niet bevestigd.

Gebruikers op 4Chan en Reddit wijzen diverse fixes aan. Omdat het herstellen van de iPhone in dfu-modus niet werkt, dragen sommige gebruikers aan na het herstel een simkaart in het toestel te stoppen. Ook het helemaal laten leeglopen van de accu lijkt te werken. Sommige gebruikers hebben met succes een beroep gedaan op de garantie en een vervangend toestel gekregen van Apple.

De bug lijkt alleen apparaten te treffen met een 64bit-soc. Daarbij gaat het om de iPhone 5s en nieuwer en de iPad Air en nieuwer. Onder meer Zach Straley heeft op YouTube een demonstratie geplaatst van de werking van de bug.

Reacties (172)

[Zenety]

Er zijn ook al meerdere foto's in de omloop met als hastag #blastfromthepast zodat mensen dit proberen..

http://imgur.com/a/twFkp

[stin00]

Op 4chan zit een select groepje dat dit keer op keer weer probeert/flikt, voorheen waren er al andere pranks zoals bijvoorbeeld deze twee:

http://www.dailymail.co.u...crowave-charge-phone.html
http://www.dailydot.com/l...-ios-7-waterproof-iphone/

Ik moet er persoonlijk wel om lachen, je moet wel heel naïef zijn om dit te geloven

[S-1-5-7]

"Ik moet er persoonlijk wel om lachen, je moet wel heel naïef zijn om dit te geloven "

Hier ben ik het niet mee eens. Hoe vaak bouwen programmeurs niet iets leuks in de software voor de fun, wat op een vreemde manier geactiveerd moet worden? Denk aan het spelen van snake bij YouTube en Google heeft/had er ook een paar.

[TIGER79]

je hoeft geen kennis van technologie te hebben om een dure smartphone te kopen, sterker nog deze specifieke merk speelt juist in op zoveel mogelijk gebruikersvriendelijkheid zodat zelfs een kind van 3 (zonder enige kennis van technologie) ermee om kan gaan...
Veel van de gebruikers die uit de jetset komen en dure smartphones kopen hebben geen idee van de gebruikte technologie, en willen best geloven dat hun smartphone bijv waterdicht is...

[supersnathan94]

Die mensen zijn normaal gesproken niet echt bepaald dom. Ze hebben het voorrecht om iedere opleiding te kunnen betalen en hebben hun geld niet zomaar ergens vandaan.

Een telefoon in de magnetron is toch echt wel het domste wat je kunt doen. Metalen voorwerpen zoals bestek mogen er ook niet zomaar in (speciale metalen magnetron rekjes daargelaten).

Ik heb geen denigrerende bedoelingen gehad met mijn comment dus excuses als dit zo is overgekomen. Misschien had ik er wat meer smilies bij moeten zetten

[Verwijderd]

Een telefoon in de magnetron is toch echt wel het domste wat je kunt doen. Metalen voorwerpen zoals bestek mogen er ook niet zomaar in (speciale metalen magnetron rekjes daargelaten).

Warmee je zelf het bewijs levert dat het allemaal niet zo eenvoudig is. In sommige gevallen is het zelfs heel verstandig om wel metaal te gebruiken, zoals bij het koken van zuiver water.

M.a.w.: wat voor de ene persoon heel logisch is kan voor iemand anders best vreemd zijn, en andersom. De retro-plank had prima een easter-egg kunnen zijn.

[Ronosho]

Zijn reactie heeft geen betrekking tot Status om een Apple aan te schaffen.
Hij heeft het over smartphones in het algemeen.

[supersnathan94]

Nee helemaal niet juist. Dit is ook helemaal niet negatief bedoelt als in de zin van status. Volgens mij is het gewoon gezond verstand wat zou moeten zeggen dit kan niet in de twee gevallen die stin00 noemt. Een teefoon in de magnetron is levensgevaarlijk en hij wordt echt niet waterdicht van een software upgrade.

Als je hier in trapt dan zijn er toch een aantal dingen in je algemene ontwikkeling niet helemaal goed gegaan.

Heeft helemaal niks met apple of wat dan ook te maken. Had van mij part ook een samsung S6 mogen zijn of eender welke budget toestel. Als je zo met je spullen omgaat dan verdien je het gewoon niet.

Een 16 jarige snapt ook wel dat dat niet gaat werken.

[monojack]

Die 2 voorbeelden zijn misschien dom maar als ik de nieuwe prank van 4chan zie is ze toch goed gevonden omdat het zelfs de meest intelligente mensen zou kunnen beetnemen. Die denken gewoon "oh een easter egg"

Maar dat mensen niet waardig zouden zijn een dure telefoon te kopen is wel heel kort door de bocht. Als je het geld hebt voor een dure smartphone ben je waardig genoeg om er één te kopen.

[Zezura]

Ja maar alles wat van 9gag, 4chan of reddit afkomt moet je toch met een korrel zout nemen, ik bedoel het is anoniem en het is een bepaald soort forum waar je van snapt dat er niet altijd de meeste hoogwaardige dingen gepost worden.

[SampleUser]

Maar als je je tijd handmatig instelt dan gaat iOS er toch vanuit dat je in die tijdzone zit en dat de tijd in die tijdzone 1-1-1970 00:00 is? Of wordt er tegelijk ook nog GMT opgevraagd wat in dat geval vroeger is..?

[deadinspace]

Maar als je je tijd handmatig instelt dan gaat iOS er toch vanuit dat je in die tijdzone zit en dat de tijd in die tijdzone 1-1-1970 00:00 is? Of wordt er tegelijk ook nog GMT opgevraagd wat in dat geval vroeger is..?

Unix Time is het aantal seconden sinds 1970-01-01 00:00:00 UTC (voorheen bekend als GMT). Dit nulpunt staat bekend als de epoch van Unix Time.

1970-01-01 00:00:00 in Nederland is dus Unix Time -3600, want wij zitten in UTC+1
1970-01-01 00:00:00 in Turkije is dan Unix Time -7200.
1970-01-01 00:00:00 in Engeland is Unix Time 0, want de UK zit op UTC.
1970-01-01 00:00:00 in New York (UTC+5) tot slot is Unix Time 18000.

Wat dat betreft is het probleem met negatieve Unix Time precies andersom dan in het artikel staat; het zijn juist de timezones ten oosten van Greenwich welke met negatieve Unix Times te maken kunnen krijgen op 1970-01-01.

Misschien slaat de iPhone in dit geval precies Unix Time 0 op, wat zich in Nederland zou vertalen naar 1970-01-01 01:00:00, maar in New York naar 1969-12-31 19:00:00. Al is het mij onduidelijk hoe zoiets een bootloop zou veroorzaken.

Negatieve Unix Time is trouwens goed gedefinieerd en normaalgesproken geen probleem; het is onder dat systeem dan ook de enige manier om momenten voor 1970 aan te duiden. Maar als een computer bijvoorbeeld probeert de Unix Time voor 1970-01-01 00:00:00 in Nederland in een unsigned 64-bit integer op te slaan, dan krijg je geen -3600 maar 2⁶⁴ - 3600, een datum ergens in Januari 584942419325. Ik kan me voorstellen dat sommige software daar moeite mee heeft.

[Reactie gewijzigd door deadinspace op 26 juli 2024 12:59]

[Maurits van Baerle]

Even mierenneuken, GMT en UTC zijn niet hetzelfde. GMT is een tijdzone (Greenwich Mean Time) voor een deel van de wereld. UTC is geen tijdzone maar een afspraak voor een gemeenschappelijk nulpunt. Ze hebben doorgaans dezelfde waarde maar dat is niet vanzelfsprekend.

[Verwijderd]

GMT is een gemeenschappelijke afspraak voor een nulpunt. UTC ook. Noem mij voorbeelden dat die twee ongelijk zijn.

[Maurits van Baerle]

Het verschil is dat UTC geen tijdzone is terwijl GMT dat wel is en dat ze beide op iets anders gebaseerd zijn. GMT is gebaseerd op draaiing van de aarde terwijl UTC gebaseerd is op atoomtijd. Aangezien de draaiing van de aarde niet constant is lopen ze dus nog wel eens uit elkaar. Voor het gemak kun je ze overigens in het dagelijks gebruik wel door elkaar gebruiken omdat het verschil tussen die twee vaak hooguit een seconde is en de tijdzone waarin je afspreekt impliciet gelijk is.

Een beetje programmeur die tijdsystemen maakt zal trouwens donders goed het verschil tussen GMT en UTC moeten weten om fouten te voorkomen. Het is heel makkelijk om fouten te maken met tijd, tijdzones en data omdat het veel complexer is dan mensen denken. Daarom wordt er ook, net als bij encryptie, aangeraden nooit je eigen tijdsystemen te ontwikkelen maar altijd gebruik te maken van bestaande libraries waar de fouten door de jaren uitgehaald zijn.

Ik gebruik zelf GMT dagelijks omdat het de tijdzone is waar ik in woon. Ik zou het echter nooit als nulpunt in computertoepassingen gebruiken, daarvoor is alleen UTC geschikt.

Leuk leesvoer voor beginnende time-geeks:
Difference between GMT and UTC
GMT vs UTC
Ntimed: A NTPD replacement (een presentatie over hoe moeilijk het is om tijd nauwkeurig te synchroniseren)
Dr David Mills, Emeritus Professor aan de University of Delaware en dé opper time geek

[Reactie gewijzigd door Maurits van Baerle op 26 juli 2024 12:59]

[Armin]

Ik gebruik zelf GMT dagelijks omdat het de tijdzone is waar ik in woon

West-Afrika of Groenland?

Engeland en de rest van Groot Britanie zit namelijk maar 50% van het jaar op GMT

[YStec]

Zomertijd. .

UTC kent geen zomertijd, GMT wel.

Alsjeblieft:
http://www.timeanddate.co...me.html?iso=20140218T1600
http://www.timeanddate.co...me.html?iso=20140419T1600

GMT +1 in de winter, GMT +2 in de zomer.

[Reactie gewijzigd door YStec op 26 juli 2024 12:59]

[xChOasx]

Dan snap ik je redenatie niet.

Waar kent GMT zomer/wintertijd ? Voor zover ik weet doet GMT niet aan die onzin.

[Reactie gewijzigd door xChOasx op 26 juli 2024 12:59]

[Armin]

GMT ken inderdaad géén zomertijd ivm het historisch gebruik als 'absolute tijd'. De Britten gebruiken daarom ook BST (Britisch Standard Time).

Samengevat:
- GMT was de oude standaard referentie voor tijd en tijdzones. Het is gebaseerd op aardrotatie.
- UTC is wat nu gebruikt wordt voor al die zaken, plus meer zoals computers, scheepvaart, etc. Dat is gebaseerd op atoomklokken.
- GMT kent géén zomertijd.
- Landen die dus op UTC+0 zitten en wél aan zomertijd willen doen, moeten iets verzinnen. De meest gebruikte methode is de speciale BST tijdzone voor die helft van het jaar.

Merk dus op dat Groot Brittanie dus maar voor de helft van het jaar op GMT zit!

Diverse Afrikaanse landen en delen van Groenland echter doen niet aan zomertijd en zitten dus het hele jaar op GMT.

Samengevat: GMT is dus enkel nog een tijdzone (voor wintertijd) die toevallig op UTC+0 zit.

[Verwijderd]

Als GMT zomertijd zou kennen zou het geen GMT +2 zijn maar gewoon GMT+1 blijven

[z1rconium]

Wij kennen zomer/wintertijd, daarom GMT+1/2.

[.oisyn]

1970-01-01 00:00:00 in Nederland is dus Unix Time 3600, want wij zitten in UTC+1

Nee, dat klopt dus niet. Als het In GMT+1 1970-01-01 00:00:00 is, dan is de GMT tijd 31-12-1969 23:00, en zou de timestamp dus -3600 moeten zijn.

[deadinspace]

Ik had het al gezien ja en snel gecorrigeerd, maar helaas had je mijn ongewijzigde post al op je scherm

[Vaevictis_]

Misschien kan IOS niet omgaan met een unsigned datatype in de timestamp? Zou een hoop verklaren.

[xoniq]

Oftewel, geen negatieve integers. Snap sowieso het nut van signed of unsigned niet zo goed in regulier gebruik, die ene bit verschil.

[smiba]

Dat is mogelijk dus ook het probleem, veel mensen met een tijd zone met -GMT, ipv. +GMT hebben volgens mij geen last van het probleem.

Het lijkt me dus iets van een interger underflow

EDIT: Of natuurlijk het omgekeerde (-GMT zorgt voor problemen), hoe dan ook er word wel gespeculeerd dat de timezone grote invloed heeft

[Reactie gewijzigd door smiba op 26 juli 2024 12:59]

[Arjant2]

Veel mensen hebben er last van?
Hoe dan?
Wie zet die datum nu bewust terug (in meerdere stappen anders gaat het niet eens) naar 1-1-1970? Het is niet dat je dat per ongeluk kan doen.

[RebelwaClue]

Sowieso als je de iphone leeg laat lopen, echt leeg, springt hij ook terug na die datum. Zo had ik op de zaak een iPhone 4s die bijna 24 millioen minuten geblokkeerd was omdat hij naar deze datum was terug gesprongen.

[Arjant2]

dat lijkt me dan informatie die in dit artikel wel opgenomen mag worden, want dan treft het meer mensen anders dan die paar ontwikkelaars die wat testen.
Overigens zeggen ze dat dit alleen 64 bit socs treft en die zouden pas vanaf de iPhone 5s in gebruik zijn, dus hoe kan dan een iPhone 4s hier last van hebben?

De bug lijkt alleen apparaten te treffen met een 64bit-soc. Daarbij gaat het om de iPhone 5s en nieuwer en de iPad 4 en nieuwer.

[Reactie gewijzigd door Arjant2 op 26 juli 2024 12:59]

[supersnathan94]

Bij iedere reparatie waar de accu langer dan 5 minuten niet is aangesloten wordt de tijd gereset naar 00:01 01-01-1970. Heb je een pincode op je simkaart (wat tegenwoordig echt superdom is, maar dat terzijde), dan kan je de simkaart niet ontgrendelen doordat de timestamps te ver uit elkaar liggen. Dit kan je verhelpen door het toestel aan een wifi verbinding te hangen en automatisch tijd bijhouden in te schakelen. Anders loopt het toestel vast omdat je provider de pincode wel kan verifiëren, maar het toestel niet wil aanmelden wegens veiligheids redenen.

[HashIT]

Waarom is een pincode op je SIM volgens jou 'superdom'? Als iemand de SIM uit je toestel trekt, kan hij op jouw kosten bellen en data gebruiken door deze in een ander toestel te steken. Een pincode op je SIM voorkomt dat.

Daarnaast klopt het technisch niet dat je provider de pincode verifieert, dat doet de SIM zelf.

Ook vraag ik me af waar exacte tijd kritisch is voor het verkrijgen van netwerktoegang. Het enige terrein waar ik niet helemaal vertrouwd mee ben is de communicatie tussen telefoon en 'antenne' (NodeB / eNodeB), het zou kunnen dat daar iets uit de pas gaat lopen.

[supersnathan94]

Omdat een simkaart erg makkelijk te blokkeren is als je hem kwijtraakt. Er is geen enkele dief die het wat kan schelen of er wel of geen simkaart in een toestel zit. Het toestel is vaak vele malen meer waard dan alleen het simkaartje (wat prepaid is en je dus geen extra kosten aan hebt, of hooguit een paar tientjes als je er niet op tijd bij bent. Ook is het nogal dom een gestolen sim te gebruiken. Dingen kunnen door de provider getraceerd worden en sms berichten zijn onversleuteld.

Het probleem zit em er echter in dat je diensten als find my iPhone blokkeert doordat ze niet automatisch kunnen verbinden met een netwerk en een home call kunnen doen. Dit is cruciaal als je je toestel nog een keer terug wil zien. Soms raak je je toestel gewoon kwijt omdat je hem bijvoorbeeld in de trein laat liggen ofzo. Een lege accu betekent dat een eerlijke vinder nooit de kans krijgt om het toestel te kunnen reourneren. Jij kan het appraat niet bellen of op een andere manier een melding naar het toestel sturen om hem weer terug te krijgen.

Komt ook nog eens bij dat niemand de moeite neemt om de code te wijzigen en deze dus standaard blijft staan op 0000, 1234 of iets anders wat jouw provider als standaard gebruikt.

Vroeger in de tijd van de nokia 3310 was het nuttig omdat bellen zelf pauperduur was en traceren niet eenvoudig was. Toen ging het om de simkaart. Tegenwoordig om het toestel zelf.

[HashIT]

Vanuit die optiek had ik het nog niet bekeken, ik snap je punt. Ik zou echter wel de nuance willen maken dat het blijkbaar een risico-afweging is tussen de kans en kosten op het kwijtraken van je toestel en de mogelijke fraude die er met je SIM gepleegd wordt bij diefstal.

Ik zou echter het risico van misbruik van een SIM niet uitvlakken. Zie bijvoorbeeld dit artikel van Kassa en deze van security.nl.

[supersnathan94]

Fair, but then again. Hoeveel mensen ken jij die hun simkaart pincode hebben gewijzigd? Ik zie iedere week tientallen toestellen langskomen en met 0000 is vrijwel altijd raak. Dergelijke problemen ga je hier niet mee voorkomen en zoals ook kassa aangeeft: geef zo snel mogelijk aan dat je toestel is gestolen en dat de boel dan maar geblokkeerd moet worden. Een toevoeging die ik daaraan wil doen is dat je er te allen tijden voor moet zorgen dat diensten als find my iphone eerst ingeschakeld zijn. Dus je hebt het toestel als gestolen gemarkeerd en/of je hebt een bericht op het toestel zichtbaar waar een ander telefoonnummer (van partner of kind) in zichtbaar is. Daarna kan je de kaart blokkeren.

[Keneo]

Als iemand je (phone + ) sim kaart steelt en er staat een code op die sim kan je die nooit meer terugvinden nadat de dief de phone uitzet/sim kaart verwijderd.

Als er geen code op staat kan de dief beginnen bellen en internetten, waardoor je (provider/de politie) deze kan traceren, en zo de dief terugvinden.

Het is dus beter om geen pin te hebben, right?

[supersnathan94]

Amen to that. Behalve in het buitenland. Dan zou ik er iets voozichtiger mee omgaan en nadat je een findmyiphone achtige constructie hebt geactiveerd en bevestiging terug hebt gehad zou ik de sim direct laten blokkeren (tenzij je zo slim bent geweest een lokale prepaid kaart e halen).

[RebelwaClue]

Omdat dit niet de bug is zoals omschreven in het artikel. Dit was alleen een iPhone die geblokkeerd was. Het ging alleen om de informatie omtrent de datum, niet de bootloop.

[Reactie gewijzigd door RebelwaClue op 26 juli 2024 12:59]

[bebkook]

Ik weet nog wel dat toen ik in de 3e zat, zo'n 5 jaar geleden, de iPod van een vriend ook 24 miljoen minuten geblokkeerd was, misschien toch al een wat oudere bug?

[RebelwaClue]

Is niet echt een bug (en redelijk snel verholpen). Lag aan het feit dat je paar keer verkeerde pincode intikt, dan zal hij blokkeren. In de tussentijd is hij leeg geweest en springt de datum terug naar 1-1-1970 maar de blokkade staat nog wel vast op de datum van nu. Recovery mode en je hebt het redelijk snel verholpen.

[jmmk]

24.000.000 minuten : 60 : 24 : 365 = ruim 45 jaar... ?!? Iets zegt me dat je overdrijft, hij kan niet zo lang geblokkeerd zijn geweest...

[RebelwaClue]

Je ziet het plaatje toch? En als de datum terug springt naar 1 januari 1970 en in 2015 was hij geblokkeerd... hoeveel jaar is dat?

[Reactie gewijzigd door RebelwaClue op 26 juli 2024 12:59]

[SampleUser]

Ontwikkelaars die hun implementatie van een date/time library willen testen toevallig?

[SunnieNL]

security officers die testen of alle security nog werkt als je de datum terug zet.
Ontwikkelaars die een timestamp gebruiken voor licentie en willen zien wat er gebeurd als je de tijd terug zet..

[Verwijderd]

Niet per ongeluk maar wel bewust en met opzet. Zoals je veel dingen bewust doet op je telefoon. Welke reden je ook hebt, het gaat mis.

[monojack]

Als je op 1 januari 1970 geboren bent kan je dat per ongeluk doen

[xoniq]

De huidige datum daarop zetten? Als je dat vaker doet zullen wel meer systemen hier niet tegen kunnen die de Unix timestamp gebruiken. Die willen gewoon een positieve waarde opslaan (signed) en verwachten geen negatieve datum qua huidige timestamp.

[.oisyn]

Maar dat is toch precies andersom? Als een New Yorker (GMT-5) zijn tijd instelt op 1-1-1970 0:00, dan is zijn unix timestamp gelijk aan 18000, want het is dan 5:00 GMT. Ik zou eerder verwachten dat het probleem optreedt bij mensen ten oosten van GMT, want dan wordt de timestamp negatief.

[smiba]

Het klinkt inderdaad logischer, maar volgens mij is het toch niet zo (Al kan ik er ook ver naast zitten hoor haha). Zou namelijk ook wel verklaren waarom ze er bij Apple zelf niet achterkwamen.

Het is vooral wachten op het officiële nieuws van Apple denk ik.

[Reactie gewijzigd door smiba op 26 juli 2024 12:59]

[kaphot]

Bij een negatieve tijdzone krijg je een tijd die jouw tijd weergeeft - een aantal uur. Dat kun je programmeren door elke keer de unix tijd een aantal uur eerder te laten weergeven of door juist de unix tijd eenmalig te verlagen. Dat tweede is iets sneller bij gebruik, maar dan moet wel ingsteld worden dat voor het aanpassen gecontroleerd wordt of die tijd bruikbaar is.

[xoniq]

Een negatieve Unix timestamp is gewoon legitiem in gebruik. Daarmee geef je een datum of tijd aan van voor de 0-punt. Het lijkt me eerder dat Apple het signed probeert op te slaan maar de waarde is unsigned. Maar dat verklaard niet waarom dit enkel bij 64-bit devices gebeurt.

[Loller1]

Ik ben eerlijk gezegd een beetje verbaasd hoeveel Tweakers hier zeggen "waarom zou je". Een reden om met de datum en tijd van je toestel te knoeien is toch best wel makkelijk te vinden en helemaal niet vergezocht: ontwikkelen en testen.

[Crazy4ever]

Ik las op /r/jailbreak dat er een bug was met de tijd in iOS 9/3Beta3 en dat een user dit probeerde te fixen door de tijd terug te zetten. Hier kwam de telefoon in een loop en bracht hij de methode naar buiten op een Aziatisch forum.

EDIT: hier is de link

https://www.reddit.com/r/...e_date_settings_to_jan_1/

[Reactie gewijzigd door Crazy4ever op 26 juli 2024 12:59]

[Donstil]

Maar wat moet er precies getest worden met de datum op 1-1-1970 dan?

[bytemaster460]

Uit ervaring kan ik zeggen dat het regelmatig voorkomt dat je met een testteam drie weken uitgebreid hebt zitten testen en binnen een uur na inproductiename er gebruikers melding maken van zaken die fout gaan. Puur omdat ze handelingen en processen hebben waar het testteam nooit bij nagedacht heeft en zich ook afvragen waarom je het zou willen. Toch zijn er vaak plausibele verklaringen voor.

[xoniq]

Zit daar ook dit bij? De datum naar een negatieve Unix timestamp duwen die eigelijk bedoelt is om de huidige datum in te stellen? Ik zit nu 14 jaar in het programmeren maar zoiets heb ik werkelijk nog nooit getest. Kan best eens voorkomen dat een veld signed staat en dan het systeem onverwacht hiermee omgaat.

Een Unix timestamp mag zelfs negatief zijn, daarmee geef je historie datums op van voor 1970. Maar of ik daar ooit rekening mee heb gehouden? Nee. Wellicht als ik ooit een project heb waarin een timeline ingevuld moet kunnen worden van een historisch event ofzo, dan zou ik dat wel testen.

[bytemaster460]

Er zijn mensen die de datum van hun computer aanpassen om een overzicht te krijgen van hoe de dagen van de week in dat jaar in een bepaalde maand vielen. Daar zijn ook andere manieren voor, maar de manier die voor gebruikers voor de hand ligt is het terugzetten van je systeemtijd.
Er zijn nog allerlei redenen te noemen die niet voor de hand liggen, maar toch kunnen voorkomen.

[supersnathan94]

Buiten dat om. Ik doe veel reparaties aan toestellen en veelal moet ik daarvoor de accu loshalen. Als dit 5 minuten duurt is het vaak niet zo heel erg, maar na een half uur zonder accu (iig langer dan 5 minuten) worden tijdsinstellingen gerest naar, je raad het al, 01-01-1970 00:00. Goed dat ik dit nu weet want dan weet ik ook dat ik het toestel op dat moment niet meer moet rebooten tenzij ik de datum anders heb ingesteld. Dit tijdsprobleem is op meerder manieren lastig, want je simkaart activeert niet als de tijd een aantal uren afwijkt. Automatisch tijd instellen werkt dus ook niet meer.

Edit: auto tijd instellen werkt nog wel met wifi.

[Reactie gewijzigd door supersnathan94 op 26 juli 2024 12:59]

[ddkiller0900]

1 januari 1970 is de basis van het Unix tijdsysteem (epoch time) en wordt gebruikt om vanaf deze datum middernacht de tijd te meten in secondes.

[Arator]

Een filmpje over het andere uiterste van etoch time. Wordt mooi de technische kant van dergelijke fouten in uitgelegd.https://youtu.be/QJQ691PTKsA

Ik vraag me dan ook af of je die Iproducten via die datum in te stellen ook in een bootloop krijgt. Iemand die het wil proberen?

[Reactie gewijzigd door Arator op 26 juli 2024 12:59]

[xoniq]

GMT. Het oosten van het 0-punt zullen een negatieve waarde krijgen als ze de datum daarheen zetten met behoud van hun eigen tijdzone. Wij krijgen dan -3600. (GMT+1). Een negatieve Unix timestamp.

[dehardstyler]

Jammer dat het gebeurt, maar wie wil zijn telefoon nou op 1 januari 1970 zetten?

[o_f_course]

Ik vermoed dat dit ook kan gebeuren als de datum niet handmatig wordt bijgewerkt maar via een programma.

Een virus zou hier gebruik van kunnen maken om een aparaat onklaar te maken.
Een programmeer fout zou dit 'perongeluk' kunnen doen.

Het is in ieder geval niet onderdeel van de 'happy flow', maar wel iets waar je wel op wilt testen. Throw een exception, keur dit soort getallen af, geef een leuke popup, whatever, maar niet dat je systeem gaat hangen.

[MarcoC]

Wat jij zegt is alleen mogelijk als je een jailbreak uitgevoerd hebt, dus dat beperkt het risico al voor een groot gedeelte.

[jqv]

als de timesync computer het signaal geeft dat dit de datum en tijd is kan dat natuurlijk ook.
Alleen zullen die dat gelukkig niet doen.

[Verwijderd]

Volgens mij niet.... als het tijdsverschil tussen een NTP Server en cliënt te groot is, weigert de cliënt om de tijd bij te werken. Heb het hier enige tijd geleden getest met een NTP Daemon op een Debian Linux server en getracht een aantal devices te laten synchroniseren (terwijl de Debian server 10 jaar terug in de tijd gezet was) en alle devices weigerde in iedere toon om de datum/tijd aan te passen.

[tom.cx]

Dit is niet zo. Gebruikers kunnen namelijk door middel van verlopen certificaten van bedrijven ook apps met een omweg installeren. Je weet niet wat deze apps doen. Die kunnen ook aangepast zijn. Maar het lijkt mij iets anders te zijn.

[Macshack]

Tuurlijk kan een programma niet de datum van de telefoon verzetten. Dat zou echt enorm slecht zijn. Geen enkele gebruiker loopt hier tegen aan. Alleen degene die grensen van het apparaat willen opzoeken om welke reden dan ook.

[Verwijderd]

'kan niet' en 'zou slecht zijn' zijn geheel verschillende dingen.
Waarom zou het niet kunnen?

Feit blijft dat het een probleem is dat naar voren is gekomen bij bepaald gebruik. Wie weet wanneer het nog meer mis gaat met datums.

[aval0ne]

Ik vermoed dat dit ook kan gebeuren als de datum niet handmatig wordt bijgewerkt maar via een programma.

Je kan zoveel vermoeden als je wil maar wat je zegt is dus onmogelijk.

[o_f_course]

Het welles/nietes zonder bronvermelding of achtergrond vind ik erg irritant. Volgende link biedt enige achtergrond.
http://stackoverflow.com/...stem-time-of-rooted-phone

Kan dus by design niet, maar onder bepaalde voorwaarden wel.

[Carpento]

De enige reden die ik zo snel kan bedenken is als een app-ontwikkelaar iets zou willen testen. Bijvoorbeeld hoe de betreffende app omgaat met datums. Dan heb je dus wel een ontwikkelaar die grondiger test dan Apple, kennelijk

[mohf]

Je moet je toestel nog steeds laten rebooten om dit bug te laten inwerken.
In de praktijk reboot men zijn telefoon niet 10 keer per dag. En als je bij het gebruik 1 januari 1970 ziet, zal dat wel opvallen denk ik.

[Iblies]

Kennelijk begrijpen veel mensen het nog niet helemaal,

Unix time;
https://en.wikipedia.org/wiki/Unix_time
1 Januari 1970 is als ijkpunt gebruikt voor de datum.

Het is misschien niet helemaal vrij logisch dat je die datum eens een keer wilt testen, maar ik kan me wel voorstellen dat wanneer iemand een soort van agenda-applicatie maakt het wel interessant zou vinden om te kijken wat er gebeurt als de datums anders zijn. Blijft die synchroniseren bijvoorbeeld.

En het lijkt er op dat Apple misschien wel eens iets heeft aangepast.
Bij Apple was het normaal dat je tijd begon in 1969 om die negatieve melding te ontwijken;
https://www.google.com/se...e%3Adiscussions.apple.com
Oude pc/Mac hadden nog een batterij inzitten die zo nu en dan vervangen moest worden.

[ard1998]

misschien kan het gebruikt worden voor een jailbraik?

[johnbetonschaar]

Zou best kunnen, de Pangu jailbreak voor iOS 7 deed ook al iets raars met de datum/tijd, die moest je dan op 2 juni 2014 zetten om de jailbreak te laten werken. Lijkt erop alsof de datum/tijd op iOS op een manier wordt opgeslagen die kan worden misbruikt voor stack smashing of iets dergelijks.

http://ioshacker.com/how-...gu-iphone-ipad-ipod-touch

[bbob]

Of om iemand zijn telefoon te laten vastlopen

[mystic]

Ik kwam op 9Gag afbeeldingen tegen dat als je dit deed, de telefoon zou booten met het oude appel logo en lettertype. Dat zal wel de reden zijn dat mensen het ook daadwerkelijk proberen

[xoniq]

Zulke pranks zijn er al heel lang. Zo werd je telefoon vanaf iOS 7 ineens waterdicht. Weet je hoeveel mensen bij Apple aanklopten met hun natte iPhone? zulke mensen verdienen geen smartphone, maar gewoon een dicht gekitte Nokia 3310 ofzo.

[Verwijderd]

Jammer dat het gebeurt, maar wie wil zijn telefoon nou op 1 januari 1970 zetten?

• Ik weet van de PC's dat die een batterijtje hebben om te voorkomen dat de data van de CMOS verloren gaat. De tijd is onderdeel van die data. Dus als het batterijtje leeg is, dan zie je een datum van 1 jan 1970.
• Voor hetzelfde geld kan een virus de datum zetten op 1 jan 1970.

Er zullen vast wel meerdere redenen zijn waarom de tijd teruggezet kan worden naar 1 jan 1970. Over het algemeen kan een lek in de software aanleiding zijn voor een "hacker" om te onderzoeken of hij ergens kan binnendringen. Een lek wil zeggen dat de fabrikant geen controle kan uitoefenen over een bepaald deel van de software. Dat kan een kwaadwillend persoon misbruiken.

[StarLite]

Niemand handmatig, maar als er een app (bijv een time sync app) iets met de tijdsinstelling doet, kan je natuurlijk relatief eenvoudig door een bug op timestamp 0 uitkomen.

[ZpAz]

Apps kunnen (zonder jailbreak) de tijd en datum niet wijzigen.

[hendymen]

Behalve als jij op mijn gasten-wifi komt, ik lijd de NTP servers van apple e.d. om naar mijn eigen NTP servers waar het 01-01-1970 is...

Hier al aan gedacht?

[xChOasx]

Een NTP client past de tijd niet aan als de servertijd teveel afwijkt van de huidige lokale tijd.

Dus, daar is aan gedacht, ja.

[xoniq]

Exact 1000 seconden is de maximale offset zoals deze standaard gehanteerd moet worden als ik t goed heb.

[Verwijderd]

Lees de reactie van mystic net voor jou reactie eens....

[Emula]

een specifieke post op 9gag jaja je raad het al

simpel plaatje met een retro thema die aangeeft dat alle ios gebruikers het hebben maar niet gebruiken
door de telefoon in te stellen op 1 jan 1970 veranderd het normale thema in de zogenoemde retro theme

dit is een klasiek verhaal van dombo laat dombo iets zien en andere dombo wil het ook

[Triblade_8472]

Dit.

Dit is (bijna?) nieuwsonwaardig. Het is een mega-minor bug omdat niemand dit per ongeluk zal doen.

Desalniettemin in interessante find. Hoe kom je er op...

[Blokker_1999]

Van wat ik op een andere site gelezen heb is hij er op gekomen door een andere bug. De datum wermd niet getoont op een bepaalde plaats dus ging iemand hem wijzigen en kwam toevallig op 1/1/1970 uit waarna de telefoon niet meer wou starten.

[Loller1]

Niet echt, ik rommel vaak met de tijd van apparaten waarop ik mijn software test gewoon om te zien hoe deze omgaat met datums. Ik kan me best inbeelden hoe ontwikkelaars hier tegenaan kunnen lopen.

[core_dump]

Dit is nauwelijks een bug te noemen mar valt onder bewust een telefoon proberen te slopen.
Je hoort ook niemand zeuren over het feit dat de lak van je auto beschadigt als je hem tegen een boom rijdt.

Vreemd gedrag van een apparaat als je het buiten de specificaties gebruikt is géén bug.

[Verwijderd]

Het is wel een bug. Er wordt een optie geboden om de datum te wijzigen. En die functie werkt niet naar behoren. Het apparaat gevraagd zich dan zoals jij zegt vreemd, zeg maar gewoon fout. Dat is nog altijd een bug.
Het heeft niets met bewust je telefoon slopen te maken. Zo kan het nu gebruikt gaan worden nu de bug bed is geworden maar het vastlopen ontstaat niet door bewust fout gebruik maar door normaal gebruik.

Je vergelijking met de auto tegen een boom gaat daarom ook mank want dat is geen normaal gebruik van de auto.

[Ultrapc]

Oke dit is leuk, de datum en tijd verkeerd instellen is 'bewust een telefoon proberen te slopen' en zelfs 'buiten de specificaties'? Yeah sure, dan zijn alle devs hardwarekillers.

[Yariva]

Geeft je leuke gespreksstof bij je maten. Beetje rondpronken dat je hun telefoons in een bootloop kan zetten

[Pyrone89]

[evilmodus] Of dat je hun kunt helpen een nieuw vers toestel te scoren onder garantie [/evilmodus]

[Carpento]

in dat geval altijd nog vondst

[idavid]

Tja, het is niet goed natuurlijk maar wie heeft hier last van? Niet de gewone gebruiker hoor, die gaat zijn toestel niet 40+ jaar terug in de tijd instellen. Schuifje bij Set automatically omzetten en je hebt nergens last van

[SunnieNL]

set automatically kan juist wel dit probleem veroorzaken.

Ook via een wifi signaal is een tijdsynchronisatie te doen. Heb dat al een paar keer meegemaakt met grote events. Bijvoorbeeld een paar jaar geleden met TechEd in de Rai zette mijn iPhone4 automatisch datum en tijd terug zogauw ik de keynote zaal in liep en verbinding maakte met het wifi netwerk. En niet alleen mijn iPhone had daar last van. Ik hoorde het toen van meerdere mensen met iDevices.

[w00t0r]

Het lijkt me behoorlijk vervelend voor een Media Markt of een Apple Store, waarin iedereen een demo-model kan bekijken en proberen.
Daar sta je dan, nadat een grapjas het hele Apple-hoekje in een bootloop heeft gezet, dat wordt zweten voor de gemiddelde Media Markt werknemer.

[Somoghi]

+1 voor een gezonde schaterlach

Tja even de batterij verwijderen is er ook niet bij..

[Reactie gewijzigd door Somoghi op 26 juli 2024 12:59]

[Donstil]

Haha ja voor de mediamarkt enz is dit niet zo leuk. Apple Stores hebben geen full working demo's in hun winkels, die phones daar draaien allemaal een soort demo mode.

[monojack]

Nu het bekend is denk ik dat er toch wel een pak mensen last van zullen krijgen. Je 12 jarige broertje die eens wil lachen, de echt irritante fandroid collega die je een easter egg wil laten zien. Toonzaal modellen.

Ze kunnen het dus maar beter snel fixen.

[Reactie gewijzigd door monojack op 26 juli 2024 12:59]

[brentvvosselen]

Vreemd dat dit echter enkel op de 64bits versie is.
Aangezien de timestamp waarschijnlijk op de 32bits soc's toch wel de zelfde time stamp gebruiken, of ben ik hier mis?

[majoh]

Memory addressing werkt anders met 64 bit, misschien zit daar het bugje in.

[bolke de beer]

Kan zijn dat de 32bit versie van iOS niet lager kan dan nul. In oudere versies van PHP was een negatieve timestamp bijvoorbeeld niet mogelijk.

[Blowthebullet]

Vraag me zeer af of de oudere iphones met een 32bit soc last zullen hebben van de 2038 jaar probleempje. Wiki Ref: https://en.wikipedia.org/wiki/Year_2038_problem

[Blokker_1999]

Zelf net even geprobeerd bij de andere fabrikanten en zowel Android als Windows 10 Mobile hebben er geen last van. Windows had zelfs de klok al weer goed gezet enkele seconden na de reboot hoewel ik de automatische instelling voor tijd had uitgeschakeld.

[bolke de beer]

uit her artikel:
"Het is onbekend wat de bootloop veroorzaakt, maar het is mogelijk dat iOS werkt met een Unix-timestamp, die aan 1 januari 1970 middernacht GMT het getal 0 toekent. Als gebruikers in een tijdzone zitten ten westen van deze tijdzone, zoals Amerikaanse tijdzones, zou het gaan om een 'negatieve tijd'."

In Nederland zitten we een uur vroeger dan GMT, dus als het artikel klopt komt de bug in onze tijdzone niet voor.

[SunnieNL]

Windows 10 mobile valt bij spanningloos worden ook terug naar de datum van de RTM build (WP 8 doet dat ook) en niet naar de 1970 datum waar Apple op terugvalt.
Dus ik denk dat die ook geen datum aankan die lager ligt dan de build datum en die automatisch reset naar die datum.

[winwiz]

Dont try this at home

Probleem is blijkbaar simpel op te lossen door hem leeg te laten lopen. Kan wel even duren natuurlijk omdat de IPhone werkelijk niets aan het doen is.

[Triogap]

Nou als hij in de bootloop tot het witte splash screen komt kan dat je batterij denk ik nog aardig snel leeg trekken.

[kevinwalter]

Vreemd, als ik de accu loskoppel van de iPhone dan reset hij zichzelf ook naar 1 januari 1970. Nog nooit gehad dat een telefoon in een bootloop kwam.

[Johan9711]

Dan wordt waarschijnlijk ook de tijdzone gereset naar GMT + 0

[Alexxxxxxxxxx]

Dit komt omdat je niet in een GMT- tijdzone zit (zoals Amerika).

[Snake]

Je zit dan hier ook op een positieve timezone offset.