Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 154 reacties
Submitter: barchettanl

Een video van een Chinese gebruiker op een filmpjessite zorgt ervoor dat iOS-apparaten crashen. Het is nog onbekend waardoor dat gebeurt. Vermoedelijk gaat het om een fout in de manier waarop iOS met video's omgaat.

Wanneer gebruikers de video van enkele seconden afspelen, blijft de telefoon in eerste instantie nog een seconde of vijftien werken, waarna plotseling de interface bevriest. Door de telefoon geforceerd te herstarten via het indrukken van de Home-knop en Aan-/Uit-knop op oudere modellen en Volume Omlaag en Aan-/Uit-knop op iPhone 7-telefoons zal het toestel weer werken.

Het gaat om een video van gebruiker Heroong op het Chinese filmpjesnetwerk Miaopai, waarin een niet herkenbaar persoon een kaart omhoog gooit. Het lijkt te gaan om een ongelukje, want andere video's van deze gebruiker leveren geen problemen op bij het afspelen. Vermoedelijk forceert het mp4-bestand door een fout in de manier waarop iOS video's decodeert een geheugenlek, waardoor na enige tijd de telefoon niet meer kan functioneren.

Heroong plaatste de video op 2 oktober, waarna na twee weken iemand op zijn filmpje reageerde dat zijn telefoon het niet meer deed na het afspelen ervan. De Zwitserse site Watson merkte het verder als eerste op, dat is nu zo'n twee weken geleden. De video is gaan circuleren in westerse media nadat EverythingApplePro, bekend van de filmpjes over lockscreen bypasses, deze zonder bronvermelding opnam in een publicatie met een link naar een mirror op het Russische vk.com.

Moderatie-faq Wijzig weergave

Reacties (154)

Als ik het filmpje in de eerste link afspeel geeft Chrome op W10 ook een groen vlak na het afspelen en die tab weigert om daarna nog iets te doen. Nasty dingetje.. :P
"HÚ gast, dit is misschien een virus of zo, speel jij Úm ook 's af!.."

Nieuwsgierigheid zit in de mens, maar dit ga je toch niet moedwillig op je eigen toestel halen?!

Straks zijn de apparaten die dat filmpje afgespeeld hebben opgenomen in een bot-net of zo...
Lijkt nochtans op een corruptie in de H264 stream, lijkt op een verwijzing naar een niet bestaand blok.
Geen rare signaturen in de file die zouden duiden op een virus.

Dus het lijkt wel op een onopzettelijke corruptie.

Maar ja, het zou ook iets nieuws kunnen zijn waar niets op aan springt, bijvoorbeeld een poging tot buiten het geheugen waarin het videobestand zich bevind te treden om daar mogelijk code te injecteren (al zie ik niet in hoe dat injecteren precies zou moeten gebeuren).
LOL, ik heb al heel vaak beschadigde/incomplete/overcookd videos geprobeerd af te spelen op pc en mobiles... Soms gaat het apparaat ook helemaal de fout in vanwege een corrrupte adressering op geheugen of drive die er niet is, of map, of device...

Het blijft code, en 1 bitje scheef wordt gewoon uitgevoerd. Meestal met een lullige crash als gevolg zonder verdere schade.

Maar als bekend wordt dat een bepaald soort fout, die dan gewoon in bijvoorbeeld filmpjes (viral) ingebakken wordt, root-toegang geeft of zo, hebben we te maken met een beveiligings-"lek". Dunkt me.
Wat mij verbaast is dat een geheugen lek door een mediaspeler een geheel OS kan doen crashen.
Zit er geen beveiliging in die dingen of zo?... "He, jij wilt teveel geheugen gebruiken, dat mag niet. -force close app-".. aldus een proper OS.
Het gaat niet om te veel geheugen gebruiken, het gaat om referenties naar niet-bestaande blokken ;) Als je kijkt naar hoe de decoding werkt tijdens het afspelen zal ergens on the fly geheugen worden overschreven, waar in dit geval (vermoed ik) een gat ontstaat in de data. Als dat gat gelezen wordt met aannames dat er bepaalde data zou moeten staan, kan dat gevolgen hebben.

Het is niet zo dat de bestanden zoals in het .AVI-tijdperk losse frames storen maar complete indexaties met mathematiek. Dan lopen de soorten effecten bij afwijkende input als wat volgens de codec zou kloppen soms hard op in edge-cases. "Lege" of missende blokken in h.264 streams tonen meestal als felgroene blokken, als mogelijk herkenbaar voorbeeld.
Klinkt allemaal logisch, maar verklaart nog niet het vastlopen van een OS door een corrupte video(stream).
Of moet ik het probleem eerder zoeken in de decoder die niet goed met excepties om kan gaan?.. of de videospeler?
Als ik een corrupte file in mijn videospeler gooi dan kapt ie de playback gewoon af vanaf het moment dat hij een fout tegenkomt en skipt hij verdere playback van het bestand. Dit gebeurt nog vrij vaak; ik rip veel videostreams van het internet en daar gaat nogal eens wat bij mis, met als gevolg dat een video van bvb. 5 minuten na 30 seconde stopt en de speler naar het volgende bestand gaat.

Ik weet dat 'good enough' een veel voorkomend uitgangspunt is bij de ontwikkeling van software maar mij is toch echt altijd geleerd dat je als programmeur moet proberen elke mogelijke exceptie af te vangen en correct af te handelen.
Stel dat die videospeler door de stream wordt verwezen naar een memoryblock dat door een totaal ander stuk van het OS in gebruik is, en activiteiten elkaar gaan raken. Nu kan ik mij nog niet voorstellen hoe een read operatie het gebruik van dat memoryblock corrumpeert. Misschien dat twee elkaar concurrerende read operaties ook een OS kunnen laten vastlopen.

Vroeger, toen de PC geheugens maar enkele MB's groot waren kon het nog wel eens voorkomen dat een grafische driver in een niet aan hem toegewezen geheugengebied zat te rommelen. Met dramatische gevolgen. Maar een driver schrijft en leest, dus be´nvloedt dat geheugengebied ook echt.

Een tweede vroeger verhaal is dat oude programma's hard/absoluut/expliciet geheugenadressen voor gebruik aanwezen. Hield de programmeur geen rekening met alle mogelijke configuraties kon dit ook vervelende gevolgen hebben.

Maar een content bestand... Dit is toch echt virusgelijkend gedrag. De speler en het OS zijn om de tuin geleid. Hoe corrupt dat bestand ook mag zijn, met alle gevaar die echte virussen opleveren zou software dit toch langzamerhand moeten afvangen, "vind ik".
Stel dat die videospeler door de stream wordt verwezen naar een memoryblock dat door een totaal ander stuk van het OS in gebruik is, en activiteiten elkaar gaan raken
Dat zou het OS dan toch juist moeten verbieden? Lijkt me een ernstige tekortkoming van het OS. Die zou de ultieme baas moeten zijn op je apparaat, het heet niet voor niks Operating System. Als apps daar al onderuit kunnen komen, wat voor gezag heb je dan nog als OS?
Vroegah, in de tijd van Mac OS 9 en ervoor, verbood het OS dat niet. Dat is ook heel de reden dat Apple naar een nieuw OS is overgestapt.

Wat er wel kan gebeuren is dat de videospeler een ander stuk van zijn eigen geheugen overschrijft, daar zal het OS niks tegen doen.

Maar, zo'n iDevice heeft vast hardwarematige videodecodering. In dat geval liggen de zaken misschien net wat anders. Als het een stukje hardware is wat de videodecodering doet, dat directe toegang krijgt tot het geheugen, dan kan het OS niet controleren of de hardwarematige videodecoder wel binnen geheugen blijft dat aan het proces van de videospeler is toegewezen. Het draait immers niet op de CPU. En de hardwaredecoder buiten zijn geheugen begint te schrijven, dan reken maar dat er gekke dingen gebeuren.
Precies dit, maar de huidige generaties hebben geen flauw benul van digitale veiligheid
Firefox en Edge werken gewoon.
Mijn Android 5 cyanogenmod ook, na afspelen.
Er komt op mijn OnePlus One (Android 7.1 TugaPower) alleen een groen balkje in de rechterbovenhoek van de video, maar hij blijft wel werken.
OPO Android 6 CM geen problemen
Edge op Windows 10 Mobile heeft er trouwens ook geen problemen mee.
Mijn Chrome op W10 speelt het gewoon af. Geen probleem.
Galaxy s7 android 6 geeft geen enkele fout.
*bij mij werkt ie nog wel, alhoewel wel dat groene vlak maar kan ook in de vidoe zelf of de player zitten* dit is dan op een PC met W10
mijn chrome op w10 werkt prima met deze video. Versie 54.0.2840.99 m
chrome op w10 hier geen probleem, mss door de titan x videokaart ?
Ja ik heb hetzelfde, net voor het einde word het scherm heel even zwart, alsof de video-driver herstart. Daarna het groene vlak.
Ik heb het ook, de tab blijft laden maar kan wel gewoon via de tab naar een andere site. Meerdere keren getest en het scherm blijft heel even zwart.
Ja inderdaad! Als ik hem afspeel ( ook win10 + chrome ) lijkt het zelfs alsof er een hele scherm overlay te voorschijn komt, die gelijk weer weggaat. ( Gaat erg snel! )
Geen probleem voor Chrome (54.xxxxx m) op Windows 7
Dit zie ik niet in Chrome op OS X! Bij mij stopt de video gewoon als ie voorbij is, al lijkt er wel nog een seconde of twee op de timerbalk onderin te staan.

[Reactie gewijzigd door RVervuurt op 22 november 2016 14:16]

Hier ook. Chrome geeft even zwart beeld en daarna groen in het video-schermpje. Edge speelt 'm hier helemaal niet af, IE wel en zonder problemen. W10 x64 1607 build 14393.447.
Ook na down loaden van het filmpje speel deze gewoon tot het einde in Ubuntu. Het filmpje is overigens slechts 6 minuten.
Met Chrome 54.x op Ubuntu 16.10 geen probleem, Firefox 50.0 speelt het filmpje dan weer gewoon niet af
M'n mac kan dat filmpje niet eens afspelen zonder iedere paar frames weer te stoppen
Ow ow, wat een onzin opmerking. Apple zit hardwarematig top in elkaar, sterker nog misschien wel het beste. Echter heeft dit weinig met de hardware te maken. Maar goed je komt hier toch alleen om te bashen en niet in staat om inhoudelijk te reageren.
Heeft echt helemaal niks met de kracht van de hardware te maken, meer de architectuur. Als je de moeite zou doen om de comments hier te lezen dan kan je dat er al uit opmaken.

Correctie

[Reactie gewijzigd door Xm0ur3r op 23 november 2016 08:48]

Ik heb het getest met een iPhone die toch weer terug moet naar Apple (no way dat ik het test op m'n eigen toestel :P), en de iPhone 7 herstelde zichzelf na een tijdje weer. Hij werd heel traag, wilde nergens meer op reageren, etc - maar na 1 a 2 minuten herstelde ie en voerde ie alle toetsencombo's die ik gedaan had achter elkaar uit. Siri lekker trippen... Maar het toestel recovered wel. Misschien een OOM-killertje dat actief wordt? :P

Onschuldig of niet, ik zou toch twee keer nadenken voor ik dit zomaar op m'n telefoon of computer uitvoer... Je weet niet wat je binnenhaalt en waar het, terwijl het toestel/pc/browser zich in die staat bevind, mogelijk deuren voor opent.
Ik doe veel met it-security dus erg paranoia, wat de bedoeling is in dat vak :P, maar vind wel dat mensen erg roekeloos zijn met zomaar dingen uitvoeren. ;(
Persoonlijk zou ik die video niet afspelen voordat er bekend is wat er precies mee is. Het zou niet de 1e keer zijn dat er op die manier een mooie exploit wordt uitgerold. Ik kijk wel uit.
Net even de film gedownload en de binary bekeken - maar daar zie ik niets vreemds in.

Daarna de film geopend in een editor, en frame-voor-frame bekeken.

Enige dat opvalt, is dat op het eind er een black-frame (rood) in zit en het geluid iets eerder stopt dan de video-track.

Wellicht een samenloop van omstandigheden, waardoor iOS daardoor op zijn bek gaat...

- edit -

Het gaat "zelfs" om twee framedrops op het eind... :Y)

[Reactie gewijzigd door deathgrunt op 22 november 2016 14:43]

Gebeurt het na het downloaden en los op de iPhone zetten ook? En wat als je een nieuwe video maakt met die twee frames erin? Of een video maakt waarvan het geluid eerder stops (lees: zichtbaar in mediainfo korter is)? En als je de audio extract en los afspeelt?

[Reactie gewijzigd door TomONeill op 22 november 2016 17:02]

Geen idee, ik heb niets van Apple in huis...

Maar dat de audio-track korter is dan de video-track, mag niets uitmaken; dat zie je zo vaak.

Ook die black-frames op het eind zijn niet heel spannend.

Wellicht is het een unieke combi;

- Lengte van de video
- Lengte van de audio
- Vierkant formaat video
- Bestandsnaam
- Gebruikte codec
- WAV stream
- etc...
Hier op w10 speelt het braaf af in een chrometab maar opmerkelijk is dat het na het afspelen even probeert fullscreen te gaan of andere (javascript?) code probeert uit te voeren.

Voor de volledigheid heb ik daar even een, waarschijnlijk nutteloze, screenshot gemaakt van een zwart/lege window (sorry heb 4k resolutie).

De video in de tab blijft staan op 4 van de 5 s dus ben wel benieuwd wat er allemaal gebeurd! :)
Ik merk op het eind (ik denk op het moment dat iOS crashed of schade oploopt) onder W10 (Chrome) ongeveer hetzelfde.

Er treed een korte flikkering op in zowel het venster van de video als een andere instance van Chrome die op mijn 2e monitor staat (met een hele andere site daarin).

Dus het lijkt op een rendering / video issue waarbij alle open instances van Chrome zichzelf lijken te resetten.

Hierna is de tab waar de video in af speelde een aantal seconden niet meer bruikbaar - niet responsive, maar na ongeveer 30 seconden herstelt zich dat vanzelf.

Het feit dat niet alleen het actieve tabblad, maar ook een totaal ander venster van Chrome exact hetzelfde issue op exact dezelfde tijd laten zien, geeft voor mij aan dat het een video- / render-issue is; niet zo zeer iets dat executed wordt (omdat je normaliter niet cross-domain / XHR code kan uitvoeren... of het zou een extreem slimme video-codec moeten zijn) :p
omdat je normaliter niet cross-domain / XHR code kan uitvoeren
Maar ja, normaliter crasht IOS ook niet door een video ;)
mooi die screenshot, mag ik hem gebruiken als wallpaper ?? :P

[Reactie gewijzigd door _Ger_ op 22 november 2016 22:43]

ik heb op andere tabs youtube open en nadat die video klaar was crashde de video feed met error dus idk wat hij doet
Heb hem ook even gescand met eset van de zaak, lijkt niks vreemds in te zitten.
Kan natuurlijk nooit voorzichtig genoeg zijn maar denk dat het wel meevalt.
zullen ze blij mee zijn op "de zaak". hihi :)
Echter zien we hier in de reacties dat het niet alleen iOS is die problemen geeft, maar ook Android en de desktop omgevingen (echter freezed daar soms alleen de browser). Dat maakt het nog vreemder.
"The above URL leads to a likely corrupt MP4 video file that causes the iPhone's processor to go into overdrive and eat up all available resources."

Via:
http://www.bleepingcomput...crash-iphones-in-seconds/

Dit gaat om een video op VK, maar waarschijnlijk hetzelfde geval.
Lijkt me dat het inderdaad in die richting is. Zelf getest op mijn iPhone 6 (iOs 10.1.1) en na een tijdje force restart gedaan. Crash dump gaf unmapped threads waardoor het lijkt te gaan om memory violations.

http://i.imgur.com/pwNBkOz.png
Ik zie in de MediaInfo output geen vreemde settings, dus het probleem zal wel een stuk dieper ligger.

Edit: een paar opmerkingen.

-Een video track die langer is dan de audio track is geen probleem en komt zo nu en dan voor.
-De encode date zou geen effect mogen hebben op het decoden van de video/audio, zelfs als deze verkeerd staat ingesteld op 1904.
General
Complete name : /video.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 529 KiB
Duration : 5s 120ms
Overall bit rate : 846 Kbps
Encoded date : UTC 1904-01-01 00:00:00
Tagged date : UTC 1904-01-01 00:00:00
Writing application : Lavf56.40.101

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L3
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 5s 120ms
Duration_LastFrame : 40ms
Bit rate : 783 Kbps
Width : 480 pixels
Height : 480 pixels
Display aspect ratio : 1.000
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.136
Stream size : 486 KiB (92%)
Encoded date : UTC 1904-01-01 00:00:00
Tagged date : UTC 1904-01-01 00:00:00

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 4s 505ms
Bit rate mode : Constant
Bit rate : 72.0 Kbps
Channel(s) : 2 channels
Channel(s)_Original : 1 channel
Channel positions : Front: C
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 39.2 KiB (7%)
Encoded date : UTC 1904-01-01 00:00:00
Tagged date : UTC 1904-01-01 00:00:00

[Reactie gewijzigd door JackDashwood op 22 november 2016 15:18]

Dan heb je niet goed gekeken:

Video Duration : 5s 120ms

Dat klopt helemaal niet, het filmpje is korter.
Volgens die info duurt de video 5 seconden en de audio 4,5. Misschien dat dat het probleem is, misschien ook niet.
Als ik hem in Quicktime afspeel zegt hij ook keurig 5 seconde. Het geluid houdt er iets eerder mee op, maar dat is te zien in de MediaInfo. Ook de Finder meldt een afspeel lengte van 5 seconde.

Dus klopt wel gewoon?
In mijn Firefox duurt het filmpje 4,5 seconden (126 parsed frames)
Zoals Rowdy.nl al aangeeft, gebeurd dit ook onder bepaalde W10 installaties met Chrome. Zelf ervaar ik dit ook.

Wat mij opvalt is dat de video plots bij 4 seconden stopt, terwijl de video 5 seconden is. Dit doet mij vermoeden dat er iets in de audiotrack zit.
Misschien kan je het testen door de de audio te verwijderen en dan alleen het filmpje zonder geluid opnieuw af te laten spelen op je telefoon. Kijken wat er gebeurd.
Op Mac OS 10.12.1 precies hetzelfde als op W10 met Chrome. In Quicktime speelt 'ie wel gewoon.
http://imgur.com/a/JVssQ
Bedankt voor de media info output, dat is alvast ÚÚn van de meest nuttige comments.

Voor mijn hobby heb ik ook weleens spul zien platgaan op slechte encoding (magix output op h.264 en dan afgespeeld in CasparCG) en dat bleek m dus uiteindelijk in een encoder fout te liggen. Ik heb het voorrecht gehad om in een datacenter van Ericsson onder het Mediapark te mogen kijken en als je ziet wat daar voor geld (miljarden) in de hardware wordt gepompt... niet zo gek dus uiteindelijk

Vaak is het nuttig om het filmpje met ffplay af te spelen en desnoods verbose logging aan te zetten. Als ik de verhalen hoor gok ik met mijn kennis op een encoding fout waardoor ergens een bug ontstaat in een low level api o.i.d.
Maar om daar echt iets zinnig van te zeggen weet ik niet genoeg van de gebruikte codecs en hardware.
Encoded date het jaar 1904?
Ik vraag me af hoeveel mensen nu massaal hun iPhone / iPad gaan laten vastlopen. :) De nieuwsgierigheid is natuurlijk te groot. Het "DO NOT PRESS" gevalletje van een rode knop. :)
Ik zou het niet doen. Zojuist het filmpje op mijn Xiaomi Mi5 in developer modus afgespeeld... ik kreeg direct al de melding van mijn virusscanner op mijn telefoon dat er iets gevonden was, in developer modus de graphics uitgelezen en vlak voor het einde lijkt er software te worden ge´nstalleerd en de video driver gereboot, het lijkt er ook op dat de telefoon informatie verstuurt naar een ip-adres dat begint met 218.107.132.XX de rest is niet te volgen.
Wel interessant. Zou denken dat het inderdaad ˇf een video met virus is, of het filmpje is dusdanig corrupt op het eind dat de gpu/videoprocesser crasht en reboot waarna er diagnostische gegevens naar Xiaomi verstuurd worden. Alleen de mogelijke installatie van software is dan niet te verklaren.
+3 voor dit verhaal zonder bron? Zit ik op Tweakers.net of nu.nl? PCAP or it didn't happen!
PCAP or it didn't happen.
Wat een onzin, net meerdere runs geprobeerd op een OnePlus3, een Samsung Galaxy Tab A (2015) en een Xiaomi Mi5 en er wordt GEEN data gewijzigd op geen enkele van de apparaten, daarnaast blijft de netwerk verbinding (buiten het filmpje om) stil (vanuit de router gecaptured).

Op een klein groen blokje op de OnePlus na (wat waarschijnlijk de video decoder is die over de flos gaat) is er niets aan de hand...
Dan zal die 218.107.132.XX wel rap geDOSt zijn :).
Er wordt software ge´nstalleerd op Windows, iOS Ún Android? Klinkt een beetje als die virus hoax mails uit de jaren '90.
Het zal wel je phone zijn die weer vanalles naar de Xiaomi servers stuurt Xiaomi kennende.
Nee hoor, ik stuur 'm enkel naar vrienden die altijd zomaar op linkjes klikken zonder. Slechte dag voor nieuwsgierigheid vandaag :Y)
Wellicht iets vergelijkbaars als 2.2250738585072011e-308; Dat je een bepaalde instructie die samen met een specifieke waarde die ergens iets laat vastlopen. Altijd leuke bugs :)

Edit: Op verzoek de video link verwijderd

[Reactie gewijzigd door Gamebuster op 22 november 2016 14:29]

Zou je die link weer willen weghalen? Ik heb expres gelinkt naar de oorspronkelijke bron (waar de video ook staat) op de Chinese videosite. Dit is een mirror op een Russische site. Nu ben ik geen koude-oorlog-aluhoedje, maar het zou niet ondenkbaar zijn dat dit geen rechtstreekse kopie is, maar iets waar iemand nog wat 'bagage' aan heeft toegevoegd.
Edit: thanks :)

[Reactie gewijzigd door arnoudwokke op 22 november 2016 14:34]

.....
Echt?

Wat maakt dat nou uit, een flv bestand is een flv bestand en je kan niet op magische wijze iets erin slipstreamen wat als commando uitgevoerd word.
tja, dat dacht men vroeger bij foto's ook die standaard als bijlage gedownload werden in outlook :+
Dat was allang bekend vanaf dag nul. en dan alsnog moet je het decoden (mits echt embedded code in JPG)
En anders is het gewoon een extensie mask, waarbij geen thumbnail verschijnt

Dit is wat anders
een flv bestand is een flv bestand en je kan niet op magische wijze iets erin slipstreamen wat als commando uitgevoerd word.
Met steganografie kan je data embedden, zelfs hele bestanden en crypto volumes. Dan is het ook best mogelijk om malware mee te sturen.

http://www.ateneo.edu/sit...ash%20video%20(FLV)_0.pdf
https://appliedtech.iit.e...rojects/mp4-steganography
De video doet zo al onverwachte zaken met sommige videoplayers of zelfs het OS. Als dit komt door bijvoorbeeld een buffer overflow dan kan er wel degelijk code ge´njecteerd en uitgevoerd worden.
Zooo naief. Als player x een bekende bug heeft zoals een buffer overflow is het heel goed mogelijk een flv te maken die op player x code gaat uitvoeren. Niets magisch aan.
Deze video is niet het origineel. Volgens de info van ffmpeg is deze video gemaakt op "2016-11-17 20:14:29".
Tevens is deze video 11 honderdste seconde korter dan de video in de eerste link.
Hij werkt wel, getest op whatsapp bij niets vermoedende iOS gebruikers :)
Het enige wat me opvalt aan beide video's is dat de audiotrack ongeveer een halve seconde korter is dan de videotrack. Misschien ligt daar het probleem bij iOS...
Ik heb het bestandje zelf nog niet bekeken, zou er wel naar willen kijken maar aangezien ik nog een paar uurtjes op het werk zit is er binnen die tijd vast wel iemand anders met een logische verklaring. Ben toch wel benieuwd naar de oorzaak.
Zo simpel maar zo leuk!

Ik wist niet dat het uberhaupt mogelijk was door een filmpje.
Precies, direct ook allemaal minnetjes op mijn reactie :+

Het waren vrienden in een groep mensen, don't worry.
Hij liet me mobiel inderdaad vast lopen waarop die later respringde. zodra ik een gevolg van het klikken op de video zie zal ik het laten weten

[Reactie gewijzigd door MiranoV op 22 november 2016 14:27]

Handig, kunnen nog meer mensen erop klikken, stel dat er daadwerkelijk iets in zit. Zou de link even weghalen als ik jou was. |:(
De link die daar gepost is, om de video te delen is gewoon safe hoor. Het is een .mp4 bestand, waar verder niets mis mee is.
Volgens mij gaat het hele artikel juist over een MP4-video, die gemirrored is op vk.com? ;)

[Reactie gewijzigd door CH40S op 22 november 2016 14:25]

Mijn iPhone 5c loopt niet vast bij desbetreffende video. Is dus niet bij alle iOS apparaten.
Dat is heel gek; ik heb het onder meer getest bij de iPhone 5 - die heeft dezelfde hardware als de 5c - en die loopt wel consequent vast. Op welke iOS-versie zit je?
Bij sommige vrienden kwam het effect al na 1 keer kijken, anderen moesten hem 3 keer kijken voor dat er wat gebeurde. (Of ze waren te ongeduldig, dat kan ook)
Ik heb hem nu 5x gekeken. Incl een paar minuten wachttijd ertussen. Maar er loopt niks vast. Dus oftewel iPhone 5c is een uitzondering of iOs 10.0.2 word hier niet door aangetast
IPhone 6S heeft het probleem ook niet via de link ;) bij het terug keren via de homeknop een vastlopert :D

[Reactie gewijzigd door Punkbuster op 22 november 2016 15:10]

Mijn iPhone 5c loopt op iOs 10.0.2 Niet de nieuwste versie dus.

Edit: Heb beide linkjes geprobeerd en hij loopt niet vast. Best raar dus.

[Reactie gewijzigd door Risath op 22 november 2016 15:14]

Ik heb het eventjes getest op een oude iphone 5C met 10.1.1. Die loopt inderdaad niet vast, mijn ipad 2 daar in tegen wel.

Hopelijk kan dit probleem worden gebruikt voor een jailbreak! :)
Mijn Iphone 6S loopt na dit filpje vast. (10.1) Maar er zijn nog filmpjes want gisterenavond had ik net hetzelfde voor na het bekijken van een ander filmpje. (Toen zei ik nog tegen men vriendin dat het de eerste keer was dat ik me kon inbeelden dat men iphone volledig vast dat, hoogst abnormaal.)

[Reactie gewijzigd door Coolstart op 22 november 2016 19:47]

Met mijn iPhone 6 (nieuwste iOS versie) is ook niks mee. Filmpje gekeken, telefoon doet alles nog.
Mijn 5 heeft ook nergens last van. tot ik hem op standby had. En weer aan wou drukken....

na een reset doet hij het weer.
Ik ben dan erg benieuwd wat deze video daarin zo speciaal maakt. Dit moet dan ook te reproduceren zijn in andere video's lijkt me ?
Dat zal precies zijn waar de Apple devs zich op dit moment over buigen. Paar smsjes naar huis - schat, ik kom wat later ;-)
Best wel bijzonder de techniek. (Vanuit gaande) dat het onschuldig is, toch bizar hoe een foutje in een filmbestand alle telefoons draaiende op een versie van iOS kan laten crashen. Natuurlijk heel simpel en begrijpelijk uit te leggen. Maar toch ergens speelt er toch een doom-scenario af. Wat als iemand echt kwaadaardigs zou willen doen en de opening vind in een kleine bugje... is toch wel eng. Nu is het gewoon simpel opnieuw starten en het is gefixt...wie weet. Ik ben erg benieuwd naar de komende 10-15 jaar... welke vooruitgang we maken en welke problemen het mogelijk gaat creŰren. Gezien de afhankelijkheid van technologie. Stel je zou alle iphones en ipad kunnen uitschakelen (welke weer gefixt kan worden door apple ) hoeveel bedrijven problemen gaan ondervinden omdat ze paar dagen niet de iphones en ipads kunnen gebruiken.
Ik vind dat niet een foutje van een filmbestand. Ondanks dat het de video is die er aanleiding voor geeft dat het gebeurd zou het hooguit de videospeler moeten laten crashen, niet het hele apparaat.
Er wordt waarschijnlijk een pointer in het werkgeheugen verkeerd gezet, tenminste dat zou een logische verklaring zijn a.d.v. de symptomen dat of een overload door alle recources in gebruik te nemen en vast laten lopen door snelle memory leak/cpu 100% iets.
Dit zou beter afgevangen moeten worden waardoor het een foutje is van Apple.
(btw de encode date is ook vreemd bij de video en er was ooit een bug bij iOS dat als je je telefoon op datum 1 jan 1970 zet het brickte)
Als je een setje imei nummers op de goede plek zet kunnen die phones ook niet meer bellen. Zo hebben ze in australie alle note 7 toestellen afgesloten van alle telefoonproviders. Er kan en gebeurd nu al veel meer dan je denkt.


Om te kunnen reageren moet je ingelogd zijn



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True