Das rätselhafte Verschwinden von Kris Kremers & Lisanne Froon

Jemand hat mich auf dieses großartige Forum zum Panama-Fall aufmerksam gemacht. Ich freue mich sehr, dass @cyclic das Ergebnis, das ich vor etwa vier Jahren auf Reddit gepostet habe, vollständig reproduzieren konnte! Für alle, die sich für die technischen Details interessieren, hier die Links zu meiner Analyse bezüglich eines losen, schlechten oder wassergeschädigten SD-Karten-Kontakts.

Diese Beobachtungen führen tatsächlich zu folgender, vollständig reproduzierbarer Abfolge:
1) Man versucht, ein Foto zu machen, die Kamera fällt herunter und schlägt auf einen Stein – oder landet vielleicht im Wasser, oder beides.
2) Man hebt sie auf, prüft sie und erhält beim nächsten Auslöserversuch die Meldung „Memory Card Error“; die Bildnummer wird übersprungen und nichts wird auf der SD-Karte gespeichert (anders als bei einer Löschung).
3) Schaltet man die Kamera aus und wieder ein, erscheint derselbe Fehler erneut, und die Kamera wirkt nun wie ein nutzloser „Backstein“.
4) Der Fehler lässt sich in der Regel leicht beheben: SD-Karte herausnehmen und erneut einsetzen oder die Kamera ein paar Tage trocknen lassen. Wahrscheinlich gibt es deshalb in Canon-Foren nicht massenhaft Beschwerden über dieses Problem – die meisten Nutzer lösen es selbst oder kaufen einfach eine neue SD-Karte.

In den letzten Tagen habe ich mich eingehend mit den inneren Abläufen von iOS 7 auf einem iPhone 4 beschäftigt. Dabei wurde ich darauf hingewiesen, dass es in den Fehler-195-Logs vom 3. April ein wichtiges Feld gibt, das die Uptime – also die seit dem letzten vollständigen Neustart vergangene Zeit – anzeigt. Diese lag offenbar im Bereich von rund 32 Tagen. Es ist daher gut möglich, dass Kris nie einen vollständigen Ausschaltvorgang durchgeführt hat, sondern lediglich die Sleep/Wake-Taste in Kombination mit eingeschaltetem Flugmodus verwendet hat. Diese Vermutung wird durch die Kommentare von Matt auf der IP-Seite zusätzlich untermauert:

It is not always possible with absolute certainty to determine when a phone was on and in use or only on and at what exact time it was turned off. The data presented here is the best judgment of the forensics expert.

Und dieser Kommentar aus der hervorragenden forensischen Analyse von @Offshore7:

Offshore7 schrieb am 14.03.2025:While the iPhone records the time of each shutdown in hidden system files (accurate to the second), it’s possible that the NFI or their forensic tools determined the shutdown time based on missing or ending activities/power logs. However, it would be strange if these hidden files were overlooked, as the forensic experts at the NFI are highly qualified professionals.

Diese Zweifel sind merkwürdig, denn es wird definitiv eine Log-Datei angelegt, wenn das Telefon vollständig herunter- oder hochfährt, und diese hätte in den forensischen Daten auftauchen müssen. Daher ist die Hypothese plausibel, dass das NFI Ein- und Ausschaltvorgänge lediglich aus indirekten Datenquellen abgeleitet hat.

Außerdem gilt:
• Bei einer Uptime von 32 Tagen muss Kris ihr iPhone bereits auf dem Hinflug nach Panama in den Ruhezustand versetzt und den Flugmodus aktiviert haben. Dabei konnte sie beobachten, wie gut der Akku während der etwa 11–12 Stunden Flugzeit hielt.
• Wer führt überhaupt regelmäßig einen vollständigen Neustart durch? Ich mache das nur bei einem neuen Release oder wenn sich das Gerät aufhängt. Sleep/Wake sind die üblichen Betriebsmodi.
• Mit eingeschaltetem Flugmodus sinkt der Akkustand nur um 1–3 % pro Tag. Das iPhone 4 war für Wanderer ideal. Das passt gut zu den gemeldeten Akku-Prozenten.
• Das Umschalten von Sleep/Wake wird von iOS nicht geloggt. Wenn man also das Gerät aufweckt, die Uhrzeit kontrolliert, die Helligkeit anpasst oder sogar die Taschenlampenfunktion nutzt (ebenfalls nicht geloggt), hinterlässt man keinen einzigen Eintrag in den System-Logs.

Wenn das zutrifft, wäre folgendes Szenario möglich:
• Kris versetzte das iPhone um 17:50 in den Ruhezustand und schaltete den Flugmodus EIN. So konnte sie es nachts als Lichtquelle oder Uhr verwenden, ohne dass ein Log entstand – eine plausible Erklärung für bemerkenswerte dreizehn (!) Stunden Funkstille.
• Für den nächsten Versuch um 8:12 Uhr am 2. April weckte sie das iPhone, schaltete den Flugmodus AUS und versuchte einen Anruf. Danach setzte sie den Flugmodus wieder auf EIN und legte das Telefon wieder schlafen.
• Tagsüber konnte sie häufig kurz die Uhrzeit prüfen (ohne dabei den Empfang zu prüfen).

Vor diesem Hintergrund ergibt auch die merkwürdige Tatsache – „2 April, 8:14 Uhr: Einstellung geändert, sodass das Kontrollzentrum ohne Passcode nutzbar ist“ – mehr Sinn. Sie wusste, dass sie das Kontrollzentrum (mit Taschenlampe, Helligkeit, Flugmodus-Button) häufiger brauchen würde und sparte sich so das ständige Eingeben des Passcodes. Apropos Passcode: Das System loggt nur fehlgeschlagene Passcode-Eingaben; erfolgreiche werden nie protokolliert. Daraus folgt, dass die oft gelesene Behauptung, der Passcode sei an jedem Tag (auch am 11.) eingegeben worden, so nicht belegt werden kann.

Ein Haken bleibt allerdings: Das Ein- bzw. Ausschalten des Flugmodus wird geloggt und löst auch Radio-Events aus; diese sollten in den System-Logs erscheinen. Genau dieses Log wird jedoch nach etwa zehn Einträgen überschrieben – und es füllt sich in einer Null-Empfangszone schneller durch die berüchtigten 195-Meldungen. Ein denkbares Szenario ist also, dass sämtliches Material vor dem 3. April schon gelöscht war, bevor die Forensik darauf zugreifen konnte.

Dies ist das Material, auf dem meine Vermutung beruht, dass stets nur Sleep/Wake verwendet wurde und kein vollständiges Herunterfahren mit anschließendem Reboot stattfand.

Ich habe die Funktionsweise des Samsung-Handys nicht näher überprüft, aber es würde mich nicht wundern, wenn auch dieses Gerät wie üblich nur in den Ruhezustand versetzt wurde und man am 2. April vergaß, den Flugmodus zu aktivieren. Das ist in einer Funkloch-Situation das Schlimmste, was man tun kann – und erklärt, warum der Samsung-Akku bereits am nächsten Tag völlig leer war.

Könnte dieses Szenario realistisch sein?

Agno schrieb:Daher ist die Hypothese plausibel, dass das NFI Ein- und Ausschaltvorgänge lediglich aus indirekten Datenquellen abgeleitet hat.

Herzlich willkommen in diesem in der Tat "großartigen" Forum und danke für die interessanten Theorien, die rationale Erklärungen bringen könnten. Allerdings stimmen sie nicht mit den Phonelogs überein.

1. Dass das IPhone zwischen dem "An- und Ausschalten" immer aus und nicht angewesen ist, zeigen die Bootlogs. Es wurde also immer hochgefahren, heißt, war aus.

2. Der Flugmodus war laut Logs nie aktiviert, auch nicht vor der Wanderung. Auch nicht bei Lisanne.

Wo hast du diese Information her?

Agno schrieb:dass es in den Fehler-195-Logs vom 3. April ein wichtiges Feld gibt, das die Uptime – also die seit dem letzten vollständigen Neustart vergangene Zeit – anzeigt. Diese lag offenbar im Bereich von rund 32 Tagen

Davon sehe ich nichts in dem Untersuchungsprotokoll.

@Agno

Ich wollte auch nur kurz hallo und herzlich willkommen sagen.

Hast du mal getestet, was sehr kurze Unterbrechungen bewirken? Soweit ich sagen kann nichts - jedenfalls keinen Fehler (das Speichern dauert nur etwas länger). Aber mein Testequipment ist etwas (hüstel) limitiert. Hast du dein Equipment noch?

Ich stimme mit deinen Schlussfolgerungen nicht wirklich überein. Du hast ein schönes Bild der Spuren, die die Kamerakontakte auf der SD-Karte hinterlassen. Die Kamerakontakte sind nadelfein, der Anpressdruck (pro Fläche) daher enorm. Ich habe schon Mühe mir vorzustellen, dass ein Sturz überhaupt den Kontakt unterbricht. Für fast ausgeschlossen halte ich eine Unterbrechung die anhält (also über, was weiß ich, über 1/1000s hinaus geht).

Kurze Unterbrechungen steckt die Kamera aber offenbar weg (re-try x mal oder bis zum Timeout, ...). Also selbst wenn jetzt Sturz und Auslösen quasi zeitgleich passieren, dürfte der Fehler nicht auftreten.

Feuchtigkeit, ist was ich auch nicht restlos überzeugend finde, was ich aber nicht so deutlich ausschließen würde. (Und was ich momentan noch nicht testen möchte, jedenfalls nicht wirklich mit Wasser).

Gut das war jetzt nicht ganz so kurz, das "Hallo" ;-)

Doctective schrieb:1. Dass das IPhone zwischen dem "An- und Ausschalten" immer aus und nicht angewesen ist, zeigen die Bootlogs. Es wurde also immer hochgefahren, heißt, war aus.

Warum sind weder Matt noch Offshore7 sicher, dass das Telefon wirklich ausgeschaltet wurde? Beide äußern Zweifel an dieser einfachen Tatsache – Zweifel, die sie bei klar vorhandenen Boot-Logs nicht hätten. Wenn du diese Boot-Logs tatsächlich selbst im an Pitti gesandten NFI-Report gesehen hast, dann habe ich nichts weiter hinzuzufügen.

Doctective schrieb:Wo hast du diese Information her?

Von einer zuverlässigen Quelle, die ich nicht preisgeben werde.

Agno schrieb:Warum sind weder Matt noch Offshore7 sicher, dass das Telefon wirklich ausgeschaltet wurde?

Zumindest Offshore ist sich sicher, dass das Telefon aus war, wenn es hochfährt. Ich glaube, da verwechselst du was. Der Forensiker sieht immer, wenn das Telefon hochfährt, denn es wird immer (!) ein Bootlog erzeugt. Es gibt allerdings keinen „Ausschalt-Log“, daher wird bei vollständiger Inaktivität durch die Forensik geschätzt, dass das Telefon aus ist – was auch sehr wahrscheinlich ist. Übrigens auch an den Akkuständen erkennbar. Kris kann nicht 13 Stunden ihr Handy anlassen und dabei keinen Prozent Akku verlieren.

@cyclic

cyclic schrieb:Ich wollte auch nur kurz hallo und herzlich willkommen sagen.

Danke für die freundliche Aufnahme :-)

Natürlich behaupte ich nicht, dass es genau so gewesen ist, aber als einfache Erklärung für die Abfolge der Ereignisse:
• Foto 509 fehlt – keinerlei Spuren auf der SD-Karte
• plötzlich werden keine weiteren Fotos gemacht, auch nicht mit dem Handy (die Stimmung ändert sich, wenn die Kamera kaputt ist)
• ein Kameraproblem, das behoben werden konnte oder sich von selbst behoben hat (man musste also nicht im Morgengrauen des 8. an der SD-Karte herumfummeln; sie hätten die Kamera einfach nehmen, ausprobieren und feststellen können, dass sie wieder funktioniert – z. B. weil sie getrocknet war).

Wendet man Ockhams Rasiermesser an, ist dies das einfachste Szenario, das mir einfällt. Andere Geschichten werden schnell immer abenteuerlicher – ich habe schon Varianten gelesen, die letztlich auf böse indigene Einheimische mit umfangreicher Canon-Expertise hinauslaufen...

Agno schrieb:Wo hast du diese Information her?
Von einer zuverlässigen Quelle, die ich nicht preisgeben werde.

Dann ist die Quelle entweder nicht zuverlässig, denn es gibt diesen Eintrag nicht im NFI-Bericht. Oder es gibt tatsächlich geheime Berichte, von denen niemand etwas weiß. Das könnten eigentlich nur die DVDs sein. Meines Erachtens hat die noch niemand gesehen. Wäre das so wäre das eine unfassbare Neuigkeit, und in dem Fall würde ich Dich bitten, das bekanntzugeben. Ich brauche nicht den Namen der Quelle, sondern ein Quellenzitat - also, wo genau das steht, was deine Quelle behauptet.

Es gibt allerdings keinen „Ausschalt-Log“, daher wird bei vollständiger Inaktivität durch die Forensik geschätzt, dass das Telefon aus ist – was auch sehr wahrscheinlich ist.

Das stimmt definitiv nicht. Wenn das iPhone 4 mit IOS7 vollständig herunterfährt, werden Einträge in CurrentPowerlog.powerlog, shutdown.log, log-bb-YYYY-MM-DD-HHMMSS-stats.plist erzeugt und die letzte CommCenter-Datei sauber geschlossen. Ein vollständiges Ausschalten hinterlässt zahlreiche Spuren, wohingegen das Bloße Ein- und Ausschalten per Sleep/Wake überhaupt nicht protokolliert wird.

Kris kann nicht 13 Stunden ihr Handy anlassen und dabei keinen Prozent Akku verlieren.

Ich behaupte nicht, dass sie das Gerät 13 Stunden lang eingeschaltet ließ; ich vermute lediglich, dass es sich im Ruhezustand mit aktiviertem Flugmodus befand und sie es gelegentlich aufweckte, um die Uhrzeit zu prüfen oder etwas Licht zu haben. Das wäre eine wesentlich logischere Erklärung als anzunehmen, „sie gingen für 13 Stunden in einen Blackout und berührten ihre Telefone gar nicht“.

Das iPhone 4 war bekannt für sein äußerst effizientes Batterieverhalten im Ruhezustand. Die größten Stromfresser sind das Funkmodul und das Display. Befindet sich das Funkmodul jedoch in einem Funkloch, leert sich der Akku daher sehr schnell.

Agno schrieb:Wenn das iPhone 4 mit IOS7 vollständig herunterfährt, werden Einträge in CurrentPowerlog.powerlog, shutdown.log, log-bb-YYYY-MM-DD-HHMMSS-stats.plist

Das wissen wir. Diese Daten liegen dem Bericht nicht bei und diese zieht der Forensiker auch nicht heran. Es geht um sogenannte Powerlogs - es gibt keine Ausschalt-Powerlogs. Des Weiteren bedeutet im NFI-Bericht - "keine Aktivität" eben genau das. Sie können annehmen, dass die Handys aus waren, weil sie nichts getan haben. Das ist nicht schwer anzunehmen.

Die Forensiker des NFI haben keinen Zweifel daran, dass die Handys ausgeschaltet wurden, ich bin mir da auch sicher. Wäre der Flugmodus aktiviert worden, hätte das ebenfalls einen Powerlog erzeugt. Doch der Flugmodus war inaktiv. Das heißt, die Theorie, dass die Handys tatsächlich an waren, kann widerlegt werden. Es gibt eine einzige theoretische Ausnahme und das wäre ein willentlich aktivierter iPhone-Bug. Dazu hat Offshore viel geschrieben.

Willkommen Agno

Agno schrieb:Es ist daher gut möglich, dass Kris nie einen vollständigen Ausschaltvorgang durchgeführt hat, sondern lediglich die Sleep/Wake-Taste in Kombination mit eingeschaltetem Flugmodus verwendet hat.

Kannst du erklären, ob der Flugmodus in den Logs oder Dateien überhaupt erwähnt wird? Nach Angaben der Eltern waren die Handys nicht im Fluchtmodus. Laut Matt auch nicht. Laut LitJ und ViP/CH auch nicht.

In welcher Akten oder Datei ist vermerkt, dass das iPhone in den Flugmodus versetzt wurde? Ab welchem Zeitpunkt könnte der Flugmodus eingestellt worden sein?

Agno schrieb:sie gingen für 13 Stunden in einen Blackout und berührten ihre Telefone gar nicht

Genau das ist ja der Knackpunkt, worüber hier schon ewig diskutiert wird.

Nur wie passt dieses Verhalten zu einem Unfall Geschehen? Eigentlich gar nicht, wie du ja auch schon festgestellt hast.

Agno schrieb:ich vermute lediglich, dass es sich im Ruhezustand mit aktiviertem Flugmodus befand und sie es gelegentlich aufweckte, um die Uhrzeit zu prüfen oder etwas Licht zu haben. Das wäre eine wesentlich logischere Erklärung

Es gab schon viele Erklärungsversuche und Vermutungen.

Anthurium schrieb:Kannst du erklären, ob der Flugmodus in den Logs oder Dateien überhaupt erwähnt wird? Nach Angaben der Eltern waren die Handys nicht im Fluchtmodus. Laut Matt auch nicht. Laut LitJ und ViP/CH auch nicht.

Da bin ich auch gespannt.

Agno schrieb:In den letzten Tagen habe ich mich eingehend mit den inneren Abläufen von iOS 7 auf einem iPhone 4 beschäftigt. Dabei wurde ich darauf hingewiesen, dass es in den Fehler-195-Logs vom 3. April ein wichtiges Feld gibt, das die Uptime – also die seit dem letzten vollständigen Neustart vergangene Zeit – anzeigt. Diese lag offenbar im Bereich von rund 32 Tagen.

Deine Info stammt aus dem Baseband Crash-Log. Das dortige "Uptime"-Feld hat nix mit der Uptime seit dem letzten Booten zu tun. Auf meinen Testgeräten sind hunderte Baseband 195 Crashlogs. Vermutlich hat Kris 32 Tage vorher am 2. März ne neue SIM ins Handy gefriemelt oder das Update auf iOS7 gemacht.

Im Übrigen hat dieser Log auch nix mit dem Loggen von Notrufen zu tun. Ich will es nur schon mal gesagt haben. :-)

Agno schrieb:Das Umschalten von Sleep/Wake wird von iOS nicht geloggt. Wenn man also das Gerät aufweckt, die Uhrzeit kontrolliert, die Helligkeit anpasst oder sogar die Taschenlampenfunktion nutzt (ebenfalls nicht geloggt), hinterlässt man keinen einzigen Eintrag in den System-Logs.

Das ist komplett falsch. Alle diese Ereignisse werden sekundengenau geloggt.

Agno schrieb:Das Ein- bzw. Ausschalten des Flugmodus wird geloggt und löst auch Radio-Events aus; diese sollten in den System-Logs erscheinen. Genau dieses Log wird jedoch nach etwa zehn Einträgen überschrieben – und es füllt sich in einer Null-Empfangszone schneller durch die berüchtigten 195-Meldungen. Ein denkbares Szenario ist also, dass sämtliches Material vor dem 3. April schon gelöscht war, bevor die Forensik darauf zugreifen konnte.

Nope. Das wird notfalls 1000 mal am Tag geloggt, da wird nix gelöscht.

Agno schrieb:Dies ist das Material, auf dem meine Vermutung beruht, dass stets nur Sleep/Wake verwendet wurde und kein vollständiges Herunterfahren mit anschließendem Reboot stattfand.

Gibt es eine professionelle Quelle oder ist das eine KI-Befragung? :-)

Agno schrieb:Könnte dieses Szenario realistisch sein?

Nein. Wie @Doctective schon sagte: Es gibt Bootlogs, die bei jedem Booten (nach vollständigem Herunterfahren) generiert werden.

Außerdem wäre im Standby/Sleep/Wake keine Eingabe der SIM-Pin erforderlich und möglich, was aber bis zum 5. April ebenfalls geloggt wurde.

Agno schrieb:Warum sind weder Matt noch Offshore7 sicher, dass das Telefon wirklich ausgeschaltet wurde? Beide äußern Zweifel an dieser einfachen Tatsache – Zweifel, die sie bei klar vorhandenen Boot-Logs nicht hätten. Wenn du diese Boot-Logs tatsächlich selbst im an Pitti gesandten NFI-Report gesehen hast, dann habe ich nichts weiter hinzuzufügen.

Also ich bin mir sicher. Zweifel gibt es lediglich an der sekundengenauen Ausschaltzeit, die - neben vielen weiteren Infos - aus den FS-Events hervorgeht, welche vermutlich vom NFI bzw. deren Forensic-Tools nicht ausgewertet wurden.

Agno schrieb:shutdown.log, log-bb-YYYY-MM-DD-HHMMSS-stats.plist

shutdown.log gibt es in iOS7 nicht und das andere ist der Baseband-Crashreport, der mal gar nix mit dem Ausschalten zu tun hat.

#

Sry, klingt vllt. etwas demotivierend, aber soll dich nicht von weiteren iPhone-Forschungen abhalten.

.. Und cooler Test mit der Kamera. :Y:

Offshore7 schrieb:Deine Info stammt aus dem Baseband Crash-Log. Das dortige "Uptime"-Feld hat nix mit der Uptime seit dem letzten Booten zu tun. Auf meinen Testgeräten sind hunderte Baseband 195 Crashlogs. Vermutlich hat Kris 32 Tage vorher am 2. März ne neue SIM ins Handy gefriemelt oder das Update auf iOS7 gemacht.

Vielen Dank für die Info. Ich war bereits auf der Spur, dass dieses „uptime“-Feld nicht den Kernel-, sondern den Baseband-Zähler darstellt. Einzig hat es mich überrascht, dass es sich nach einem vollständigen Neustart nicht auf null zurücksetzt. Meine Vermutung ist, dass dieser Zähler permanent weiterläuft und vielleicht vom Qualcomm-Hersteller zur Berechnung der MTBF verwendet wird (es könnte aber auch einen anderen Zweck haben). Weißt du, wofür er genau gedacht ist?

Offshore7 schrieb:Sry, klingt vllt. etwas demotivierend, aber soll dich nicht von weiteren iPhone-Forschungen abhalten.

In Ordnung – und um mit Goethe abzuschließen: In der Uptime zeigt sich erst der Meister :-)

Offshore7 schrieb:Deine Info stammt aus dem Baseband Crash-Log. Das dortige "Uptime"-Feld hat nix mit der Uptime seit dem letzten Booten zu tun.

Danke für die vielen Richtigstellungen bzw. Erklärungen.

Ich habe das Ganze auch noch mal nachgeschaut. Der einzige Baseband Crash Log vom 3.4. mit String 195 listet überhaupt keine Uptime auf, sondern bezieht sich auf den abgebrochenen Notruf. Aber da das eh keine Rolle spielt....

Agno schrieb:In der Uptime zeigt sich erst der Meister :-)

Bitte hinterfrage deine Quellen. Hättest du mit jemandem gesprochen, der tatsächlich den Originalbericht hat, hätte er dir zum Beispiel zeigen/sagen können, dass überall für den 3.4. ganz fett Airplane Mode: Off steht. (Wie auch sonst immer)

Es sind einfach unfassbar viele Fake News unterwegs sind, auch von Leuten, die mal auszugsweise Einsicht in die Akten hatten, sie aber nicht verstehen oder einordnen können. Die Akten sind kein Buch, in dem man mal easy was nachschlagen kann. Wir haben viele Wochen gebraucht, um alles korrekt zu übersetzen und an die richtigen Stellen zu bringen. Die Originalakte ist völlig chaotisch zusammengesetzt. Das führte auch zu vielen Fehlern unserer "Vorgänger" von LitJ.

Agno schrieb:Einzig hat es mich überrascht, dass es sich nach einem vollständigen Neustart nicht auf null zurücksetzt. Meine Vermutung ist, dass dieser Zähler permanent weiterläuft und vielleicht vom Qualcomm-Hersteller zur Berechnung der MTBF verwendet wird (es könnte aber auch einen anderen Zweck haben). Weißt du, wofür er genau gedacht ist?

Das ist die Baseband/Funkmodul Uptime. Wenn nötig wird das Baseband/Funkmodul resettet und inkl. SIM-Karte neu initialisiert. Hier während des Betriebs ausgelöst durch Wählen der Nummer *3001#12345# (GSM-Code = Umschalten in Fieldtest Mode):
-iPhone lag monatelang bis gestern ausgeschaltet im Schrank-

Original anzeigen (0,5 MB)

Doctective schrieb:Ich habe das Ganze auch noch mal nachgeschaut. Der einzige Baseband Crash Log vom 3.4. mit String 195 listet überhaupt keine Uptime auf, sondern bezieht sich auf den abgebrochenen Notruf.

Müsste eigentlich am 3. April gegen 16:32 Uhr NL-Zeit in so einem Eintrag stehen (in den meisten Fällen wird aber trotz Eintrag nicht voll resettet). Dieser Log vom 3. April wurde vermutl. erst am 4. April 10:16 Panama-Zeit final gespeichert, also beim Booten am nächsten Tag.

Offshore7 schrieb:Müsste eigentlich am 3. April gegen 16:32 Uhr NL-Zeit in so einem Eintrag stehen (in den meisten Fällen wird aber trotz Eintrag nicht voll resettet). Dieser Log vom 3. April wurde vermutl. erst am 4. April 10:16 Panama-Zeit final gespeichert, also beim Booten am nächsten Tag.

Tatsache, am 3. April um 16:33: "reason=call failed; uptime=2759047;count=0;"

cyclic schrieb:es ist ein schönes Beispiel dafür dass LLMs immer sehr überzeugend klingen, selbst wenn sie mangels echter Infos gerade im Fantasier-Modus sind

Aber wirklich! Ein weiteres Beispiel dafür: Ich habe ChatGPT gebeten, die Logs oben zu bewerten hinsichtlich eines Geräteschadens.
Ergebnis:

Ja, es liegt mit sehr hoher Wahrscheinlichkeit ein Hardwareschaden am Baseband/Mobilfunkchip vor.
Das iPhone stürzt regelmäßig wegen Fehlern in der Kommunikation mit dem Mobilfunkmodul ab.

Quelle: ChatGPT

Nochmal nachgefragt:
Könnte es auch an fehlendem Netzempfang liegen? Was ist wahrscheinlicher: Fehlender Empfang oder ein Problem mit dem Chip?

Warum ein Hardwaredefekt wahrscheinlicher ist:

Kurze Uptime-Zyklen:
Ein Gerät rebootet sich nicht alle paar Sekunden nur wegen schlechtem Empfang – es würde höchstens eine Fehlermeldung anzeigen ("Kein Netz", "Suchen...").
Fehlermeldung XCREG triggered dump:
Diese Dump-Auslösung ist ein interner Schutzmechanismus, meist durch inkonsistente Baseband-Kommunikation. Das tritt nicht bei normalem Empfangsverlust auf.
AT response timeout + state=Resetting:
Das iPhone versucht das Baseband-Modul neu zu initialisieren – ein typisches Verhalten bei nicht ansprechbarem Baseband-Chip.
Das ist kein normales Verhalten bei schlechtem Empfang.
Häufigkeit und Regelmäßigkeit der Resets:
Bei einfachem Netzverlust würde das iPhone nicht abstürzen oder neustarten – das wäre softwareseitig abgefangen.

Fazit

👉 Ein Baseband-Fehler durch Hardwaredefekt (z. B. kalte Lötstelle, Schaden am Baseband-Chip oder beschädigte Stromversorgung des Chips) ist mit Abstand die wahrscheinlichste Ursache.
Ein bloßer Netzverlust (kein Signal, defekte SIM) führt in der Regel nicht zu Kernel Dumps, AT-Timeouts oder sich ständig wiederholenden Resets.

Quelle: ChatGPT

@Offshore7: Zeit für ein neues Handy!

staminag schrieb:Ein weiteres Beispiel dafür: Ich habe ChatGPT gebeten, die Logs oben zu bewerten hinsichtlich eines Geräteschadens.

Da gab es doch schon diverse Anfragen und ein Ergebnis war, ChatGPT gibt die Antwort, welche man hören möchte 😉

Tatum schrieb:Je nachdem wie du fragst gibt dir die KI irgendwann die Antwort die du hören willst. Der "Prompt" entscheidet über die Antwort, das ist eine wichtige Kompetenz im Umgang mit KIs.

lucyvanpelt schrieb:Da gab es doch schon diverse Anfragen und ein Ergebnis war, ChatGPT gibt die Antwort, welche man hören möchte

Man kann die KI beeinflussen und sie hat auch kein Problem damit, ihre Meinung komplett zu ändern, wenn man ihr entsprechende Vorgaben macht. Die Vorgaben können offen, aber auch indirekt gemacht werden. Man muss sich den Prompt dann genau anschauen.

Es geht jetzt um offen gestellte, interessierte Fragen, bei denen aber der Kontext fehlt oder die allgemeine Informationslage zu dünn ist. Da legt sich ChatGPT offensichtlich zu schnell fest und ist dabei enorm überzeugend. ChatGPT weiß nicht, dass Offshore7 das Logverhalten eines funktionierenden iPhone4 getestet hat und zieht das auch gar nicht in Erwägung.

Ich habe noch weiter gefragt:
Es wurde diese Nummer gewählt: *3001#12345#.
Was bedeutet das für die Analyse der Logs?

📱 Bedeutung von *3001#12345#:

Dieser Code öffnet den sogenannten Field Test Mode (FTM) auf iPhones.

➡️ Er zeigt Diagnose-Infos zum Mobilfunkmodul: Signalstärke, Zellinformationen, Registrierung im Mobilfunknetz usw.
Es handelt sich nicht um einen normalen Anruf, sondern um einen spezialisierten Zugriff auf das Baseband.

🔎 Relevanz für die Loganalyse

Im Log sehen wir unter anderem:

23:09:22 [rm] reset: reason=AT response timeout (call): atd3001#...
Das zeigt:

Das iPhone versuchte, auf das Baseband mit einem sogenannten AT-Befehl (ATD = Dial) zuzugreifen.
Der AT-Befehl wurde nicht beantwortet (AT response timeout).
Das führte zu einem Baseband-Reset und löste sogar einen Systemdump aus.

Mit der Eingabe von *3001#12345#:

Wurde gezielt getestet, ob das Baseband ansprechbar ist.
Das Gerät versuchte den Befehl auszuführen (ATD...).
Scheiterte, da das Baseband nicht reagierte.
➡️ Das belegt eindeutig, dass:

Nicht der Empfang das Problem ist.
Sondern das Baseband nicht (mehr) richtig ansprechbar ist – also vermutlich defekt.
(…)
👉 Der Baseband-Chip oder seine Stromversorgung ist sehr wahrscheinlich defekt.
Ein bloßer Netzverlust wäre nie die Ursache für diesen Effekt.

Quelle: ChatGPT

Das ist für das Thema nicht großartig relevant, aber allgemein vielleicht ganz interessant, damit man sich eine gesunde Skepsis bewahrt, was die Antworten der KI betrifft und auch sich selbst überprüft, ob man ihr alle verfügbaren Informationen gegeben hat.

(Wenn ich das nochmal genau lese, bin ich schon wieder irritiert. Die Analyse von ChatGPT IST doch falsch, @Offshore7?)