Vorsicht vor Video-Bug: Manipuliertes mp4 bringt iPhones zum Absturz

iPhone-Nutzer haben es derzeit nicht leicht. Video-Links, die aus nicht bekannten Quellen kommen, sollte man derzeit besser nicht anklicken - ein merkwürdiger Bug bringt ansonsten das iPhone zum sofortigen Absturz. Dahinter steckt ein Fehler in der Speicherverarbeitung. mehr... Iphone, iOS, Bug, Absturz, Memory Leak Bildquelle: EverythingApplePro Iphone, iOS, Bug, Absturz, Memory Leak Iphone, iOS, Bug, Absturz, Memory Leak EverythingApplePro

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Windows Mobile gibt das Video ohne Murren wieder. Ist ja auch lächerlich, dass ein Video ein Gerät zum Absturz bringt. Obwohl: Steve Jobs hätte sicher gesagt "Ihr seht die falschen Videos an!"
 
@regulator: Stimmt, Windows Mobile hatte ja auch noch nie Fehler oder Qualitätsprobleme! Sowas gibts prinzipiell nur bei der Konkurrenz!
 
@ger_brian: Okay, die letzte Kernelpanic wegen einer Lappalie hatte ich in der WP8.1 Developer Preview.
 
@regulator: und was hast Du an "manipuliertes Video" nicht verstanden?
 
@Rumpelzahn: Manipuliertes Video führt zu Kernel Panic ist immer noch sehr peinlich.
 
@Alexmitter: Ist ja total easy dieses Videozeug, dass Videoplayer schon immer eines der größten Einfallstore waren ist ja nicht so wichtig, IT Profis wie Alexmitter programmieren das schnell mal am Wochenende und zwar fehlerfrei und 3 mal so performant! Was ist eigentlich manipuliertes Video führt zu RCE wie MS15-100 und die paar tausend Bugs davor? Ich dachte immer das gehört zu Software dazu.
 
@regulator: "Windows Mobile gibt das Video ohne Murren wieder. Ist ja auch lächerlich, dass ein Video ein Gerät zum Absturz bringt."

Eigentlich könnten alle Smartphone-Hersteller, inkl. Samsung und Apple, ihre Software-Qualitätssicherung an dich outsourcen. Sie spendieren dir immer das neuste Gerät und du testest kurz und gibst die Software dann frei.
 
@Skidrow: Testest kurz?
Hast du denn ne Ahnung wie groß (Codezeilen gesamt) ein heutiges Spiel/App so ist? xD

Kurz testen, der war gut...xD

Zum Vergleich: ZombiU (5 Gbyte, komprimiert, WiiU-Version) vs. 21 Gbyte auf PC & anderen Konsolen (unkomprimiert).

Na, fällt was auf? 5 MILLIARDEN Codezeichen vs. 21 Milliarden xD

Kein WUNDER dass das Spiel keine Sau auf Bugs damals getestet hat. Die würden nämlich glatt heute noch dran sitzen :D

Oder auch schön: Mario Kart 8 (popliges, faules ARM-Spiel) 5 Gbyte (5 Milliarden Codezeichen!) vs. FRN, noch nichtmal 1 Gbyte groß (aber immer noch 1 Milliarde Codezeichen.

Bei der Masse an App-Müll der heute auf den Markt geworfen wird, ist es kein Wunder dass das keiner mehr händisch durchgeht.

Da wird einmal der Massen-Debugger angeworfen und das wars. Findet der keine groben Bugs ist die App "Frei" für die Leute :D
 
@BestUser: Ironie ist dir Fremd? Aber die Rechnung das 5 Gbyte = 5 Milliarden Codezeilen sind sehr interessant ... Grafiken und Sound Files sind also Codezeilen ;)
 
@Rumpelzahn: Zu den Codezeilen zählen auch Grafiken & Sound-Files. Schließlich können die heute ebenfalls Bugs enthalten bzw. auslösen.

Gerade bei programmierbaren Shadern ist der Anteil der verbuggten Assets immer höher. Und da wird heute einmal der Debugger drüber geworfen das wars.

Findet die Maschine nichts ist der Code für den Entwickler fertig bzw. brauchbar.

Es reicht heute aber schon lange nicht mehr, nur die Exe-Datei auf Bugs zu kontrollieren xD

Denn die meisten Grafik-Bugs kommen heute von den Shadern selbst. Das heißt, der Shadecode ist falsch.

PS: 1 Megabyte = 1 Million Zeichen. So neu ist das nicht. Sorry, ich meinte Zeichen. Aber das sind trotzdem einige Tausend Codezeilen, die heute keiner mehr von Hand kontrollieren will.

Ein durchschnittlicher Entwickler schafft übrigens 100 Zeilen pro Tag. Entweder 100 Zeilen am Tag anschauen und auf FEHLER prüfen. Oder 100 Zeilen neu schreiben. Allein. Von Hand.

Selbst die popligste ARM-App heute hat heute in etwa 500 Mbyte. Sind immerhin 500 Mio Zeichen.

Gefühlt hat eine App in etwa 1 Milliarde mögliche Bugs xD Besonders, wenn man billige Java-Engines eingesetzt hat...

Edit: Ein Entwickler der eine ARM-App gemacht hat, hat sich neulich darüber beschwert dass er 6 Monate für das Debugging gebraucht hat...xD 6 Monate!

Für eine simple 300-Mbyte-App. Nix Komplexes also.

Und genau diese "App" wird nun geportet und somit die Bugs wohl auch 1:1 übernommen. Und die App hat immer noch ne Menge Bugs. Mit jedem Patch kommen neue hinzu, weil auch neuer Inhalt/neue Funktionen hinzukommen.

Genau das ist ja der Grund, warum heutige Spiele dauerhaft gepatcht werden müssen. Weil mit jedem Inhalt den du hinzufügst (etwa ein weiterer DLC), das Spiel mehr Bugs haben kann. Und die zeigen sich erst, wenn du den DLC installierst.
 
@BestUser: 300mb für eine App ist gigantisch, schon ein Messenger ist sehr komplex und der passt auf 30mb.
Wobei wir hier über UWP Apps Reden.
 
@BestUser: Du hättest dir das ganze Geschreibe ersparen können, denn der Kommentar auf den du einen Roman losgelassen hast, war einfach nicht ernst gemeint.
 
@Alexmitter: Es geht um Spiele-Apps. Ein Messager ist nur ein Kommunikationswerkzeug.

Wenn du meinst 30 Mbyte wären wenig, was würdest du dann sagen wenn man dir erzählte dass du das ganze auch in 5 Mbyte Quetschen könntest? Und zwar indem du das ganze für PowerPC programmierst und die Onboard-Komprimierung verwendest? ARM hat nämlich von Haus aus keine Komprimierung bzw. wird in 99% aller Fällig nicht verwendet weil es verdammt viele Ressourcen kostet. Auf PowerPC kostet das vielleicht 1% der Ressourcen.

Und wenn ich da sehe dass da neulich erst wieder ein 9 Gbyte ARM-Spiel auf den Markt gekommen ist (das nennt sich z.b. Paper Mario Colour Splash). Dann sieht man wie ineffizient und verschwenderisch diese Technik in Wahrheit ist. Manche "Apps" sind gar 20 Gbyte schwer. Allerdings bekommt man diese dann auch nicht auf dem regulären Android-Smartphone :D

Für ein ordentliches Spiel sind 300 Mbyte für APPs heute gar nichts. Selbst nen Shooter der bekannteren Marke kommt mit 2-3 Gbyte auf dem Smarpthone daher. Und das ist noch relativ human xD

Zum Vergleich: Discovery auf PowerPC-Basis: 100 Mbyte. Ja richtig gelesen. 100 Mbyte! Und das würde man gar nicht erwarten. Auf x86 wär das vielleicht 2-3 Gbyte groß (10-20x größer weil nicht komprimierbar).
 
@AcidRain: Hat er schon gesagt. Hatte ich schon verstanden. Aber da wars halt schon dahingetippselt ;) Und ich tippe fix.
 
@BestUser: Das meiste davon sind Texturen...
In jedem fall
 
@Alexmitter: Es kann auch Shadercode sein. Die Programmierbaren Shader brauchen ja immer mehr.
 
@regulator: Für Symbian gab's ein .gif welches das System schon beim Laden der Vorschau in den Abgrund gerissen hat.
 
@regulator: Weder bei WP8.1 noch bei W10M brauchte ich unter meinen L720/L930/L950 ein Video welches das System zum Absturz gebracht hätte. Das hat der berüchtigte everyday-use schon bewerkstelligt. Fairerweise muss man sagen dass die Phones meistens von selbst neu gestartet haben - immerhin.
Diese mimimi *beliebiges-System* ist so viel besser ist einfach lächerlich. Es gibt überall Bugs. Wer was benutzt ist unterm Strich nur noch persönliche Präferenz.
 
@coke21: Ich kann für das 920, 930, 630, 550 und 950 sprechen, Auto-Neustarts sind nicht normal, egal um welche Situation es geht.
 
Für Windows Mobile gibt es sicherlich zahlreiche andere Glitches , aber die herauszufinden lohnt sich nicht für die 5 Leute die Windows Mobile nutzen.
 
@Lanezzz: Es gab mal einen der mich zur Kernel Panic brachte, das war damals in der WP8.1 Developer Preview. bisher konnte ich nichts neues finden, und ich teste wirklich sehr ausgiebig.
 
@Lanezzz: Es waren kurzzeitig 6 Leute, Joe Smith aus South Dakota hatte gestern auf Reddit geschrieben, das er es testen will.
 
@JacksBauer: Du Outest dich als Reddit User und versuchst noch andere Lächerlich zu machen? Was für ein Selbstschuss...
 
@Alexmitter: Ja da hast du Recht. Ich bin schon eine Marke.
 
Iphone Besitzer haben es zur Zeit nicht leicht.....ähm, woher kommt diese geistreiche Erkenntnis?
 
Welches Mitglied der heutigen Zeit klickt denn bitte noch auf Links zu einer unbekannten Quelle?
Man könnte genauso gut vor fantastischen EMails eines reichen nigerianischer Prinzen warnen.
 
@erso: nun die links können ja auch von bekannten zugesendet werden, ein einbinden in imageboards, foren o.ä. reicht ja auch schon
 
@erso: Würde es nicht reichen, wenn ein Bekannter das Video bei Facebook postet und man anschließend die Timeline übers iPhone aufruft (wegen autoplay)? Hab selbst kein Facebook, daher kann ich nur spekulieren ;)
 
@SouThPaRk1991: Ich glaube bei Facebook werden die Videos nicht 1:1 eingebettet sondern noch mal neu gerendert. Habe in meinem Leben da erst ein mal ein Video hoch geladen, ich glaube da war so was, wenn nicht kann mir gerne jemand das Gegenteil sagen.

/edit: wollte gerade mal das Video sichten, es ist bei VKontakte eingebettet, da geht es also oder bei deren Encoding ist der Fehler passiert. Das Video wurde inzwischen aber entfernt.
 
@erso: Dann wird das Video halt per Messenger verschickt[1] und da gibt es viele die diese Videos abspielen. Ist das Video einmal auf dem IPhone, so wird es auch gerne mal von vielen Nutzern einfach mal angeschaut, bevor man es löscht [2].

@SouThPaRk1991: Das Hochladen bei Facebook oder Youtube geht natürlich nicht, da Facebook/Youtube das Video nach dem Hochladen neu encodiert.

[1] - WhatsApp & Signal hatte dieses Video 1:1 versendet. Bei Threema konnte man es ohne Probleme von der Android-Version mit den Komprimierungseinstellungen "Original Qualität" versenden (alternativ nutzt man hier die Funktion beliebige Dateien zu Versenden, denn dann wird das Video nicht verändert). Vielleicht geht es auch per MMS, aber hier habe ich es nicht geschafft, dass das Video 1:1 das Gerät verlassen würde (Es wurde vorher immer vom Gerät neu komprimiert),
[2] - Die Neugier siegt halt meistens.
 
@erso: Womöglich ist leider einer der in dem Newstext beschriebenen "Spaßvögel" näher mit einem bekannt, als man bisher dachte ?
 
Ich habe es mal angetestet. Nach dem abspielen, ca 10-15 Sekunden später, fängt das iPhone an zu stottern bis es dann komplett einfriert.

Interessant wäre für mich zu wissen wie das, im technischen Sinne, Zustande kommt. Jemand hier der mit fundiertem Wissen eine Vermutung aufstellen könnte?
 
@d0351t: Vermutlich wird in kürze der Folgebericht erscheinen, in dem die Informationen erscheinen, das sich doch mit dem Video ein bösartiger neuartiger Virus auf iOS verbreitet hat.
Himmel, wie kann man auf so einen Mist auch noch freiwillig klicken? Es sind doch keine Fakten bekannt.
 
@d0351t: Ich hab zumindest Theorien. Aber nagel mich nicht drauf fest.

a) der ARM-Prozessor hat nur geringe Bandbreite (Hauptgrund warum z.b. Smartphones manchmal "ruckeln").
b) Das Video benötigt eine gewisse Bandbreite pro Sekunde um es abzuspielen
c) ARM-Prozessoren geht sehr schnell die nötige Bandbreite für Berechnungen aus (etwa beim Multitasking oder auch bei simplen Videos kämpfen die um jedes Mbyte was da durchgeht durch den Halbleiter). Gerade bei verschlüsselten Videos mit DRM kann das manchmal sehr belastend sein. Am PC kannst du z.b. problemlos eine Bluray mit ner gängigen Grafikkarte abspielen. Wenn du aber keine Grafikkarte hast die unterstützt wird, muss die CPU das erledigen. Dann hast du Pech, wenn diese deutlich zu langsam ist.
d) Es reicht also eine Überlastung dieser Bandbreite (etwa wenn du das Video absichtlich mit viel Mbyte/s kodierst, z.b. Blurays sehen dadurch ja so gut aus. Weil du 10 Mbyte und mehr Bandbreite pro Sekunde hast). Oder aber du nutzt eine simple Schwachstelle im Code aus der besagt dass das Video z.b. mehr Bandbreite pro Sekunde nutzt als angegeben (wer prüft das schon?).

Meine Vermutung: Das ist ein speziell codiertes Video.

Der ARM Prozessor bzw Video-Dekodierer bekommt gesagt "Das Video ist lauffähig". Er kann es aber nicht. Irgendwann erschöpft die Bandbreite. Und dann stürzt der Chip ab, weil er keine anderen Befehle mehr annehmen kann und/oder überhitzt.

Im Grunde haben alle ARM-Chips dieselben Probleme und Einschränkungen was das angeht.
Du hast ja bestimmt schon davon gehört, dass ARM-Chips in Smartphones ihre Apps nur mit bestimmten Taktraten betreiben dürfen. Da läuft quasi immer ein Timer.

Und der Timer läuft, damit eine App nicht den Prozessor zum Absturz bringt z.b. durch Überhitzung und um andere Apps nicht leer dastehen zu lassen.

Ein Smartphone kann nunmal dauerhaft den Prozessor nicht mit 2 Ghz laufen lassen. Es würde hoffnunglos zu heiß werden wenn das mehr als 30 Sekunden so laufen würde. Ergo taktet es runter, in der Regel auf 600-800 Mhz.

Womöglich hat z.b. ein Android-OS auch einen Filter der dem Prozessor sagt "Halt, das kannst du nicht abspielen, lasse es also sein". Oder eine Art Blacklist.

Im Grunde ist es aber immer dasselbe: Du hast ein Video. Dieses wird durch einen Hardware-Videodecoder geschickt. Den kannst du zur Überlastung bringen. Dann stürzt dein Smartphone ebenfalls ab.
Es kann aber auch sein dass das Video gar nicht vom Videodekodierer Gebrauch macht, sondern eben gezielt durch "Software-Beschleunigung" (also dem ARM-Prozessor) angetrieben wird wie oben mit dem Beispiel am PC gezeigt.

Und bei Android gibts vielleicht eine Regel die besagt dass nur bestimmte Videos oder Videos mit bestimmten Endungen von der CPU wiedergegeben werden können/dürfen.

Eins der beiden Sachen dürfte aber zutreffen. Entweder überhitzt der Prozessor oder der Videochip wird überlastest/überhitzt und schaltet das Smartphone aus Sicherheitsgründen ab.

Denn wie du weißt, ist der Videochip- also die Grafikkarte- in einem Smartphone viel wichtiger. Denn alles was du am Smartphone machst, und sei es nur das öffnen eines Browsers läuft- anders als beim PC- über die Grafikchips.

Überlastet dieser bzw. wird zu heiß, schaltet das Gerät ab.

Nochwas:

Hier ein Zitat was ich von woanders habe: ""Angreifer können Android-Geräte mit den Versionen 4.3 bis 5.1.1 mit einem präparierten Video im MKV-Container dauerhaft lahmlegen."

Überhitzt eine GPU und wird zu heiß, kann sie dabei Schaden nehmen. Das Smartphone kann so beschädigt werden dass es nicht mehr eingeschaltet werden kann. Solche Fälle müssten dann aber relativ neu sein. MIr sind zum Glück davon noch keine bekannt.

Edit: hier ist der Link dazu: https://www.heise.de/security/meldung/Praeparierte-Videos-legen-Android-Geraete-lahm-2765247.html
 
@BestUser: Also bei Android ist das Gerät gleich dauerhaft hinüber, während in diesem Fall bei iOS nach einem erzwungenem Neustart wieder alles fit ist? Wo sind auf einmal die ganzen Android-Fanboys hin?
Kommentar abgeben Netiquette beachten!

iPhone 7 im Preisvergleich

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.