Das rätselhafte Verschwinden von Kris Kremers & Lisanne Froon

@staminag

Also ich habe das spaßeshalber auch mal ausprobiert (ich habe ja ein gesundes Misstrauen und div. schlechte Erfahrungen mit LLMs).

ChatGPT fand das nicht fishy, da ich von Anfang an erwähnt habe, dass es sich um kein normal genutztes Gerät, sondern um ein Testgerät handelt. Als möglicher Grund wurden u.a. immer wieder "SIM card issues" genannt. Also habe ich gefragt ob denn das komplette Fehlen einer SIM-Karte konsistent mit dem Log wäre. Antwort (der wesentliche Satz daraus ohne zusätzliche Erklärungen):

Yes, this baseband log is exactly what you'd expect if no SIM card was present.

Ob das jetzt stimmt weiß ich nicht (gesundes Misstrauen, s.o.) Aber in jedem Fall: Man muss schon Kontext dazu geben und sinnvoll nachfragen.

Offshore7 schrieb: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-

Sehr schön, dass es dir gelungen ist, den Uptime-Zähler reset vollständig zu reproduzieren. Es handelt sich also um einen Reset der Baseband-/Funkmodul und Initialisierung der SIM-Karte. Vielleicht passiert das auch, wenn die Werkseinstellungen (factory value restore) wiederhergestellt werden.

April 3, 2014 um 16:33 Uhr (CET) minus 31,9 Tage ergibt ungefähr Sonntag, 2. März 2014 um 18:57 Uhr (CET) – also kurz nach der Abendessenszeit in den Niederlanden. Ich erinnere mich vage, dass Kris dieses iPhone 4 als Geschenk zu ihrem Abschluss bekam, finde aber die Quelle nicht mehr. Aber es ist sehr wahrscheinlich, dass die Aktivierung ihrer PIN den letzten Reset dieses Zählers induziert hat.

cyclic schrieb:Also habe ich gefragt ob denn das komplette Fehlen einer SIM-Karte konsistent mit dem Log wäre. Antwort (der wesentliche Satz daraus ohne zusätzliche Erklärungen):

„Mein“ ChatGPT sagt dazu (nur das jeweilige Fazit, den Rest lasse ich auch weg):

Wäre das komplette Fehlen einer SIM-Karte konsistent mit dem Log?

Fazit: Ist fehlende SIM-Karte konsistent mit dem Log?

❌ Nein, nicht wirklich. Das Log zeigt:

Das Baseband reagiert nicht mehr (AT timeout).
Das Gerät resettet sich mehrfach, mit nur Sekunden Uptime.
Es werden sogar Crashdumps ausgelöst.
All das würde nicht passieren, wenn einfach nur keine SIM-Karte eingelegt wäre.

Was wäre, wenn es sich um ein Testgerät handelt, das nicht normal genutzt wird, ändert das etwas an der Bewertung?

Fazit: Ändert der Testgeräte-Kontext die Bewertung?
Nur bedingt. Die Hauptbewertung bleibt bestehen:
🛑 Das Verhalten zeigt, dass das Baseband-Modul nicht korrekt funktioniert – unabhängig davon, ob es ein Testgerät ist.
Mögliche Optionen im Testkontext:
* Das Gerät wird absichtlich ohne Baseband betrieben (z. B. Prototyp ohne Funkmodul)
* Oder es wird gezielt getestet, wie das System auf Baseband-Ausfälle reagiert
👉 In diesem Fall wäre der Fehler erwartet, aber dennoch real.

Quelle: ChatGPT

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

KIs lieben es, Menschen zu irritieren. :-)

Bei derart spezifischen Themen ist das Ergebnis unspezifischer Prompts in der Regel Bullshit gemixt mit korrekten und z.T. auch außergewöhnlich guten Infos, was aber kein Laie / Intermediate wirklich bewerten und unterscheiden kann und was einem weiteren produktiven Chatverlauf im Weg steht.

Hier insbesondere weil ChatGPT massig ursächliche Szenarien auslässt und nicht zwischen iPhone mit iOS7 und Infineon Baseband/Funkmodul mit eigenem OS unterscheidet. Das sind zwei verschiedene Geräte mit eigenem Betriebssystem und eigenem Prozessor. Das iPhone stürzt nicht ab oder startet neu, außer es läge wirklich ein Hardware-Defekt vor.

Weder bei meinem Test-Log (Ursache: ungültige SIM) noch bei dem Auszug des Original-Logs (Ursache: Funkloch), den @Doctective gepostet hat, gibt es den kleinsten Hinweis auf einen Hardware-Defekt des Infineon Baseband-Moduls.

In meinem Testfall gab es einen vollständigen Reset / Reboot des Infineon Moduls in rund 1 Sekunde, inkl. Neustart der Uptime. Bestimmungsgemäßes Verhalten, um in wenigen Sekunden alle Funkzellen in der Umgebung anzuzeigen (trotz ungültiger SIM).

Der Originallog bedeutet, dass sich das Baseband (Modem-Stack) aufgrund des fehlgeschlagenen Anrufs im Funkloch in Teilen (vermutl. Soft-Reset ohne Reset der Uptime) refresht hat, ebenfalls ein bestimmungsgemäßes Optimierungs-Verhalten ohne "Crash", bei funktionierendem Baseband und intakter SIM.

Also nix Hardware-Defekt, sondern mE normales und spezifikationsgerechtes Verhalten, um das Modem bei temporären Fehlern wie gescheiterter Anrufaufbau im Funkloch zu refreshen. Vermutlich auch davon abhängig, wie oft ein Anruf scheitert oder ob noch gecachete Daten einer früheren funktionierenden Verbindung vorhanden sind. Jedenfalls eher klares Indiz für funktionierende Baseband-Hardware (32 Tage Netto-Uptime seit letztem Reset) und eine intakte und registrierte SIM.

cyclic schrieb:Ob das jetzt stimmt weiß ich nicht (gesundes Misstrauen, s.o.) Aber in jedem Fall: Man muss schon Kontext dazu geben und sinnvoll nachfragen.

Glückwunsch, fast richtig! :Y:

Agno schrieb:April 3, 2014 um 16:33 Uhr (CET) minus 31,9 Tage ergibt ungefähr Sonntag, 2. März 2014 um 18:57 Uhr (CET) – also kurz nach der Abendessenszeit in den Niederlanden. Ich erinnere mich vage, dass Kris dieses iPhone 4 als Geschenk zu ihrem Abschluss bekam, finde aber die Quelle nicht mehr. Aber es ist sehr wahrscheinlich, dass die Aktivierung ihrer PIN den letzten Reset dieses Zählers induziert hat.

Wobei das die Netto-Uptime des Infineon-Moduls ist. Hatte sie ihr Handy im März weitgehend im Standby, kann das hinkommen. In der Nacht vom 31. März auf den 1. April war es jedenfalls im Standby / Sleep-Modus.

Offshore7 schrieb:Glückwunsch, fast richtig!

Ich geb's weiter (ChatGPT freut sich immer so süß).

Bzgl. Themen wo es einfach mal 1000x mehr Infos auf Englisch gibt (bzw. auf Deutsch eher kaum welche) kommuniziert man auch besser in Englisch (IMHO) und wenn man das arme LLM erstmal mit falschem oder fehlendem Kontext in die falsche Richtung manövriert hat, lohnt es nochmal einen neuen Chat anzufangen. (mein Abschluss des heutigen kleinen KI-Promting-Lehrgangs).

Ich habe jetzt einige Tage nicht mitgelesen. So wie es sich anhört, ist man von löschen und überschreiben durch die Kamera mit 510 abgekommen. Warum, wenn ich fragen darf?

Ich kenne mich mit FAT und Datenrettung aus und hier werden einfach falsche Aussagen in den Raum geworfen. Der nahtlose Übergang im Datenbereich bezieht sich auf die Einteilung in Clustern. 511 schließt nicht direkt am letzten Byte von 510 an sondern am nächsten Clusteranfang.
Das ergibt sich direkt aus der Funktionsweise von FAT. Wenn die Dateigröße kein Vielfaches der Clustergröße ist, dann bleibt ein Rest im letzten Cluster frei, den man als Schlupfspeicher bezeichnet und in dem noch Datenreste der vorherigen Datei vorhanden sein können. Das ist in den Berichten nur schematisch so nicht dargestellt. Nach sowas suchen Datenrettungsprogramme normalerweise nicht.

Deswegen wäre vielleicht sinnvoll, das einmal auszuprobieren.


Die Theorie mit den Testbildern bezieht sich übrigens nicht auf die Nachtbilder sondern auf die letzten Tagaufnahmen.

sceptical schrieb:Warum, wenn ich fragen darf?

Deswegen: SD-Karte Filesystem Block/Cluster-Versuche (Seite 2) (Beitrag von Offshore7)

Das NFI sagt, dass es keinerlei Spuren von #509 finden konnte, trotz Einsatz von Tools, die dazu geeignet wären solche aufzuspüren.

@Offshore7 hat nun bewiesen (was ich aufgrund der Ausgabe eines best. Recovery-Tools vorher auch nicht gedacht hätte), dass die Verzeichniseinträge gelöschter Dateien selbst dann noch vorhanden und auffindbar sind, wenn die Datei selbst vollständig überschrieben wäre.

Ob da am Ende im letzten Cluster ein Rest bleiben kann oder Clusterweise der NAND-Speicher erased wird, ist ne interessante Frage. Nur wenn nicht, ist das ja noch ein starkes Argument dagegen, dass #509 jemals existiert hat, denn dann hätte man ja auch noch Content finden können. Und wie ich ausprobiert habe, kann man auch kleinere Reste eines JPG-kodierten Bilds (hier des am Ende der Datei liegenden eingebetteten 1450x1080-Pixel-Preview-Bilds) sichtbar machen, wenn man komplette Vergleichsbilder im selben Format hat.

sceptical schrieb:Die Theorie mit den Testbildern bezieht sich übrigens nicht auf die Nachtbilder sondern auf die letzten Tagaufnahmen.

Welche Theorie?

@sceptical

cyclic schrieb:Ob da am Ende im letzten Cluster ein Rest bleiben kann oder Clusterweise der NAND-Speicher erased wird, ist ne interessante Frage

Da ich nun eh in die Wunderwelt der HexEditoren herabgestiegen bin, habe ich auch das noch getestet.

Kurz zur Erklärung: es gibt Cluster von 32768 Bytes (32 kiB). Eine Datei fängt immer an einem Cluster-Anfang an. Außerdem gibt es Sektoren von 512 Byte. Bevor Speicher einer SD-Karte neu beschrieben werden kann, muss er gelöscht werden (Erase). Die Frage war nun werden ganze Cluster gelöscht, oder nur wirklich benötigte Sektoren.

Vorgehen:
Erst einen Cluster (32768 Bytes) mit 10101010... vollgeschrieben, dann die Datei wieder gelöscht (SD-Karten-Reader abgezogen und neu connectet) und dann mit einer kleinen Datei mit 200 Bytes "ABC..." überschrieben.



Wie man sieht wurde nur der erste Sector (512 Bytes) gelöscht bevor mein "ABC..." reingeschrieben wurde, der Rest des ersten Clusters (32768 - 512 = 32256 Bytes) enthalten noch die Reste der 01-er-Datei. Da hast du absolut Recht.

Nun mit dieser Erkenntnis ist es wohl so, dass wenn eine Datei durch mehrere kleinere Dateien an sich vollkommen überschrieben wird, kann und wird i.d.R. in den jeweils letzten Clustern dieser Dateien ein kleiner Rest der gelöschten Datei zurückbleiben (außer eine Datei füllt ihren letzten Cluster bis in den letzten Sector hinein aus). Das wäre insbes. fast sicher der Fall gewesen wenn #509 ein Tagbild oder gar ein Video gewesen wäre, da die Nachtbilder sehr viel kleiner sind (bei den ersten beiden #510 und #511 sieht man es bei IP, die sind nur 0.8 und 1.3 MiB groß)

Hätte es #509 also tatsächlich gegeben hätte man sogar noch File-Content finden können. Das hätte ich bis vor ein paar Tagen als ziemlich spannende Erkenntnis empfunden. Da man auf jeden Fall aber die Verzeichnisdaten hätte finden müssen, ist das (jetzt) bzgl. #509 kaum noch relevant. Bzgl. anderer Dateien ggf. schon. Bei zumindest einigen von 64 gelöschten Bildern und fast sicher bei allen 4 Videos hätte man solche Reste finden können. Vermutlich allerdings zu klein um damit viel anfangen zu können (ein solcher Rest kann im allergünstigsten Fall 32768-512 Bytes groß sein). Aber auch von denen muss man die Verzeichnisdaten gefunden haben und da die von vor Ende März waren hat man sie offenbar nicht weiter ausgwertet.

sceptical schrieb:Der nahtlose Übergang im Datenbereich bezieht sich auf die Einteilung in Clustern. 511 schließt nicht direkt am letzten Byte von 510 an sondern am nächsten Clusteranfang.

Dieses Basis-Wissen wird hier idR impliziert. Die NFI-Darstellung 508->510 ist nun mal "Sektor an Sektor".

cyclic schrieb:Wunderwelt der HexEditoren

Logisch betrachtet bleiben eigentlich nur 3 Varianten, wenn das NFI den Schlupfspeicher im letzten Cluster des Bildes #510 gecheckt hätte und der etwas größer war, als ein paar Bytes (was ja jeder mit Wissen der #510 Originalgröße ausrechnen kann):

Kein Schlupfspeicher (Nullen):
1. #509 wurde von #510 vollständig überschrieben oder via PC entfernt -> Manipulation am PC
2. #509 hat auf der Original-SD nie existiert -> Manipulation am PC oder Kamerafehler

Schlupfspeicher:
3. Manipulation am PC (wenn feststeht, dass L. die SD-Karte neu hatte und kein ganz alter Müll drauf war)

Ganz irrelevant ist das also nicht. Oder übersehe ich was?

Offshore7 schrieb:Dieses Basis-Wissen wird hier idR impliziert. Die NFI-Darstellung 508->510 ist nun mal "Sektor an Sektor".

Wobei man vielleicht fragen sollte, was hier "Sektor an Sektor" eigentlich genau meint. Dafür muss #508 seinen letzten Cluster ja bis mind. in den letzten Sektor gefüllt haben. Da es 64 Sektoren a 512 Byte pro Cluster (32768 Byte) gibt ist die Wahrscheinlichkeit dafür 1/64 also ca. 1.5%. Ich habe das nochmal an einem Satz Urlaubsbilder von mir gegengecheckt da waren es 5/256 (~2%) - das passt also.

Das wäre an sich noch eine Kuriosität on top, aber ich vermute ehrlich gesagt, dass hier eigentlich "Cluster an Cluster" gemeint ist. Schade, dass sie die Dateigröße nicht in ihrer Tabelle haben, daran würde man es sehen.

Offshore7 schrieb:Ganz irrelevant ist das also nicht. Oder übersehe ich was?

Ja du hast schon recht. Man könnte am Schlupfspeicher über alle Dateien u.a. sehr sicher erkennen, ob die Karte vorher schon mal benutzt wurde und dann nur schnell formatiert wurde (ich glaube nicht dass viele Leute sich die Mühe machen das extra Häkchen für Low-Level-Formatierung zu setzen).

Offshore7 schrieb:Logisch betrachtet bleiben eigentlich nur 3 Varianten, wenn das NFI den Schlupfspeicher im letzten Cluster des Bildes #510 gecheckt hätte und der etwas größer war, als ein paar Bytes (was ja jeder mit Wissen der #510 Originalgröße ausrechnen kann):

Der theoretische Schlupfspeicher kann nur Vielfache von 512 B groß sein (0, 512, 1024, ...). Praktisch kann die überschriebene Datei natürlich an jeder Position geendet haben. Allerdings ist #510 so ziemlich die kleinste Canon-Jpeg-Datei die ich kenne. Wäre #509 deutlich größer als 0.8 MiB gewesen, dann wäre die Chance >= 512 Bytes zu finden also 63/64 (~98.5%), 62/64 für >= 1024 B, ..., 1/64 für 32768-512 B.

Wenn aber jemand per HexEditor den Verzeichniseintrag von #509 wegeditiert hätte, hätte er vermutlich auch den Schlupfspeicher gekillt(?)

Ich werde mir den Link später anschauen. Das hört sich tatsächlich ungewöhnlich an, dass die FAT Einträge trotz Überschreiben der Daten noch da sein sollen.

sceptical schrieb:Ich werde mir den Link später anschauen. Das hört sich tatsächlich ungewöhnlich an, dass die FAT Einträge trotz Überschreiben der Daten noch da sein sollen.

Kann ich übrigens auch voll bestätigen. Mit ImHex sehe ich sie auch. Nur DMDE zeigt sie nicht an, obwohl auch DMDE sie fast zwangsläufig auch auslesen muss, da die Einträge davor und danach ja auch ausgelesen werden (aber da nicht wiederherstellbar macht das für ein Recovery-Tool schon Sinn).

@Offshore7

cyclic schrieb:Da es 64 Sektoren a 512 Byte pro Cluster (32768 Byte) gibt ist die Wahrscheinlichkeit dafür 1/64 also ca. 1.5%. I

Äh und ein absolutes Ding der Unmöglichkeit ist dass das für alle 7 Bilder (#504 bis #511) in der Tabelle von IP zutrifft, obwohl die Tabelle ja genau das suggeriert (Wahrscheinlichkeit 0.015⁶ also 1.1 / 10¹¹ also erstmal 10 Nullen nach dem Komma).

cyclic schrieb:Wobei man vielleicht fragen sollte, was hier "Sektor an Sektor" eigentlich genau meint.

cyclic schrieb:Äh und ein absolutes Ding der Unmöglichkeit ist dass das für alle 7 Bilder (#504 bis #511) in der Tabelle von IP zutrifft, obwohl die Tabelle ja genau das suggeriert

Hier nochmal die Tabelle von IP:


https://imperfectplan.com/2021/04/06/kris-kremers-lisanne-froon-missing-photo-509-testing-canon-powershot-sx270-hs/

Ich habe die Begriffe nun auch mal nachgelesen und Folgendes erfahren: Jede Datei bekommt grundsätzlich einen eigenen Cluster (bestehend aus mehreren Sektoren) zugewiesen. Bleibt ein Rest, wird der Cluster nicht voll genutzt. Das ist der Schlupfspeicher.

Nach der Tabelle von IP ist eine (erstaunliche) Sektor an Sektor-Belegung für alle sieben vorhandenen Bilder vermerkt. Mögliche Erklärung: Die Sektoren des "angebrochenen Clusters" werden als belegt angesehen, weil sie ohnehin nicht von einer anderen Datei genutzt werden können. Daher wird es als Sektor an Sektor dargestellt, was eigentlich Cluster an Cluster meint, indem der Schlupfspeicher ignoriert wird.

@Offshore7: Bei deinem Test hätte es keine neue Clusterzuweisung für den neuen Verzeichniseintrag gegeben?

Offshore7 schrieb:Hier insbesondere weil ChatGPT massig ursächliche Szenarien auslässt und nicht zwischen iPhone mit iOS7 und Infineon Baseband/Funkmodul mit eigenem OS unterscheidet. Das sind zwei verschiedene Geräte mit eigenem Betriebssystem und eigenem Prozessor. Das iPhone stürzt nicht ab oder startet neu, außer es läge wirklich ein Hardware-Defekt vor.

Ich habe das dann auch nochmal ChatGPT vorgelegt und siehe da:

Du hast vollkommen recht – unter diesen Annahmen ist das beobachtete Verhalten kein Anzeichen für einen Hardwaredefekt.
Vielmehr spricht der Ablauf für eine intakte Baseband-Hardware, die sich gemäß ihrer Spezifikation verhält.

Danke für deinen wertvollen Hinweis – das ist eine sehr saubere Analyse und eine hervorragende Ergänzung zur ursprünglichen Interpretation.

Untertänigste Grüße von: ChatGPT

cyclic schrieb:Äh und ein absolutes Ding der Unmöglichkeit ist dass das für alle 7 Bilder (#504 bis #511) in der Tabelle von IP zutrifft, obwohl die Tabelle ja genau das suggeriert (Wahrscheinlichkeit 0.0156 also 1.1 / 1011 also erstmal 10 Nullen nach dem Komma).

Ja, das ist Quark. Natürlich wäre eine Darstellung "Cluster an Cluster" besser gewesen. "Sektor an Sektor" ist aber dennoch verständlicher als "Bild an Bild".

staminag schrieb:Jede Datei bekommt grundsätzlich einen eigenen Cluster (bestehend aus mehreren Sektoren) zugewiesen.

IdR eine Clusterkette, die über die FAT-Tabelle verknüpft ist. Ein Bild der SX270 besteht aus ~ 30 bis 200 Clustern zu je 64 Sektoren.

staminag schrieb:@Offshore7: Bei deinem Test hätte es keine neue Clusterzuweisung für den neuen Verzeichniseintrag gegeben?

Der Ordner 102__04 ist ein eigener Cluster und kann 1024 Bilder / Verzeichniseinträge aufnehmen, die quasi "Byte an Byte" liegen. Dieser Verzeichnis-Cluster war mit 133 Einträgen also gerade mal zu 13% gefüllt. Erst bei 100% würde ein zweiter Cluster zugewiesen.

staminag schrieb:Untertänigste Grüße von: ChatGPT

:'D