Das rätselhafte Verschwinden von Kris Kremers & Lisanne Froon

Agno schrieb:1. Der erste Punkt sagt nichts darüber aus, wann das Gerät ausgeschaltet wurde – nur, dass es ausgeschaltet wurde. Es könnte also ebenso um 23:00 Uhr abgeschaltet worden sein.

Weil du den Punkt isoliert betrachtest, nicht in Kombination mit den anderen Punkten. Schaltest du um 23 Uhr aus, gibt es um 23 Uhr Powerlogs und geänderte Dateien.

Agno schrieb:meine Vermutung: keine Powerlogs

Falsch vermutet.

Agno schrieb:also muss irgendwo im iOS-Code stehen: „if passcode = successful → RAM-Daten in Datenbank schreiben“

Nö, muss nicht. Der Speicherort der Powerlogs kann auch einfach bis zur Passcode-Eingabe gesperrt sein. Bei einem Bitlocker verschlüsselten LW musst du auch nur einmal pro Sitzung das BL-Passwort eingeben, Standby und Bildschirmsperre ändern daran nix.

Agno schrieb:3. Der dritte Punkt stützt sich stark auf den Vergleich mit dem Samsung, bei dem ein Abschalten eindeutig belegt ist.

Nein die Methodik des NFI ist belegt, dass eine Dateisystem-Analyse gemacht wurde. Und diese Vorgehensweise lässt sich auch aufs iPhone übertragen, denn rein technisch ist es kein Problem.

Agno schrieb:Offenbar haben wir darauf keine eindeutige Ja-oder-Nein-Antwort, wobei ein Hinweis für das Vorhandensein eines Logs darin liegt, dass uns der Akkustand von 42,18 % um 16:39 Uhr vorliegt. Man würde annehmen, dass dieser Wert aus einem Powerlog stammt

Natürlich ist das ein Powerlog, ebenso der Signalstärke-Log um 16:40 Uhr.

Agno schrieb:Und dennoch fehlen angeblich drei Stunden Powerlogs – nämlich zwischen 13:38 Uhr und 17:52 Uhr

Bei mir ist 13:38 plus 3 Std. = 16:38 :-) .. danach haben wir wie gesagt Powerlogs, sowohl Akku als auch Signalstärke.

Agno schrieb:Eine mögliche Erklärung ist daher, dass das iPhone 4 im Sleep-Modus in einer Funkloch­situation noch effizienter mit Energie umgeht, als ich zunächst angenommen hatte.

Beim Aufstieg gab es schlechten Empfang bis hin zu Netzverlust, außerdem eine Fotosession auf dem Mirador. In solchen Situationen nahe am Verbindungsabbruch wird die Leistung des Funkmoduls erhöht, was Strom kostet.

Offshore7 schrieb:Schaltest du um 23 Uhr aus, gibt es um 23 Uhr Powerlogs und geänderte Dateien.

Das wäre merkwürdig, denn auch für 17:52 liegen keinerlei Powerlogs vor; andernfalls hätte das NFI zu diesem Zeitpunkt den Akkustand oder die Signalstärke ausgewiesen. Man wäre zudem auch deutlich entschiedener zu dem Schluss gekommen, dass das Gerät dann tatsächlich ausgeschaltet wurde.

Offshore7 schrieb:Falsch vermutet.

Hast du dieses Szenario also schon explizit getestet?

Offshore7 schrieb:Natürlich ist das ein Powerlog, ebenso der Signalstärke-Log um 16:40 Uhr.

Ich könnte mir vorstellen, dass dieses Powerlog durch den 112-Anruf ausgelöst und direkt in die Datenbank geschrieben wurde. Aber gibt es noch weitere Powerlog-Datenpunkte nach 16:40 Uhr? Falls nicht, ist es weiterhin möglich, dass Ereignisse im RAM gespeichert wurden, die nie in die Datenbank gelangt sind. Es bleibt doch merkwürdig, dass es dir in deinen Tests nie gelungen ist, das Telefon eine Zeit lang im Ruhezustand zu lassen, ohne dass zumindest einige Powerlog-Einträge auftauchten?

Offshore7 schrieb:Bei mir ist 13:38 plus 3 Std. = 16:38 :-)

Ja, natürlich :-) Hier habe ich mich bei dieser einfachen Rechnung vertan!

Wir haben also einen dreistündigen Ausfall der Powerlogs von 13:38 bis 16:38, die du bislang noch nicht reproduzieren konntest. Welche plausible Erklärung könnte es dafür geben?

Agno schrieb:Das wäre merkwürdig

Das ist nicht merkwürdig, sondern Fakt.

Agno schrieb:Hast du dieses Szenario also schon explizit getestet?

Welches Szenario? Wenn du das Gerät ausschalten willst, musst du es vorher zwingend aus dem Standby holen und diese Aktivität (Drücken des Buttons am Gehäuse) wird in Realtime ins NAND-Flash geloggt, bevor du Herunterfahren, Passcode eingeben oder Sonstwas machen kannst:


06/17/25 18:26:10 [Wake] reason=hold;
06/17/25 18:26:12 [Battery] level=61.39%; voltage=3859 mV; current=0 mA; current_capacity=590 mAh; raw_max_capacity=961 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=26.40 C; adapter_info=0; connected_status=0;
06/17/25 18:26:12 [Baseband State Durations] …
06/17/25 18:26:12 [SpringBoard-states] screen_state=unblanked; lock_state=locked;

Agno schrieb:Ich könnte mir vorstellen, dass dieses Powerlog durch den 112-Anruf ausgelöst und direkt in die Datenbank geschrieben wurde.

Vor dem Notruf wurde das Handy aus dem Standby geholt, dann folgen dutzende Logs, wovon 2 öffentlich bekannt sind (Akku und Signalstärke).

Agno schrieb:Wir haben also einen dreistündigen Ausfall der Powerlogs von 13:38 bis 16:38, die du bislang noch nicht reproduzieren konntest. Welche plausible Erklärung könnte es dafür geben?

Genau. Erklärung unbekannt. Klar ist für mich aber, dass es in der Session des 1. Aprils an die 5.000 Powerlogs gab und zB am 3. April in 3 Sessions keine 300 ..

Offshore7 schrieb:Genau. Erklärung unbekannt.

Okay, belassen wir es dabei. Ich möchte nicht noch mehr von deiner kostbaren Zeit in Anspruch nehmen. Ganz überzeugt bin ich allerdings noch nicht; ich halte es nach wie vor für möglich, dass der von dir entdeckte RAM/NAND-Bug irgendwie bei den drei fehlenden Powerlog-Stunden am 1. April eine Rolle spielt.

Auf jeden Fall vielen Dank für deine Geduld. Ich habe unser Gespräch sehr genossen :-)

Agno schrieb:also muss irgendwo im iOS-Code stehen: „if passcode = successful → RAM-Daten in Datenbank schreiben“. Es erscheint mir wenig plausibel, dass man zusätzlich ein „if first entry after boot“ eingebaut hätte.

Vermutlicher technischer Grund iOS 7 RAM / NAND-Flash Verhalten:

Sicherheit (NSFileProtectionCompleteUntilFirstUserAuthentication) https://support.apple.com/de-de/guide/security/secb010e978a/web

Offshore7 schrieb:Vor dem Notruf wurde das Handy aus dem Standby geholt, dann folgen dutzende Logs, wovon 2 öffentlich bekannt sind (Akku und Signalstärke).

Kurze Rückfrage: sind nur zwei im Bericht und deswegen bekannt oder enthält der Bericht mehr?

Habt ihr es jetzt nochmal mit Kamerafunktionen getestet?

Das wäre wichtig.

Lieber Offshore7, seit wann ist das Teil der FAT Spezifikation. Die gibt das nicht vor, natürlich kann die Firmware den Eintrag Überschreiben.

Bitte testet das nochmal mit Firmware.

Ansonsten könnte das tatsächlich ein Anzeichen für ein Löschprogramm sein, dessen Überschreibaktion sich im Schlupfspeicher eventuell zeigt. Aber das können nur die Behörden prüfen.

Diebold schrieb:Kurze Rückfrage: sind nur zwei im Bericht und deswegen bekannt oder enthält der Bericht mehr?

Ich kann nur sagen, dass ein Notruftest bei mir in einer Minute ca. 70 Powerlogs produziert, davon 5x Akku und 3x Signalstärke. Ob die alle in der Akte stehen, kann nur @Doctective beantworten.

sceptical schrieb:Lieber Offshore7, seit wann ist das Teil der FAT Spezifikation. Die gibt das nicht vor, natürlich kann die Firmware den Eintrag Überschreiben.

Du hast recht. Hab mir die uralte FAT32 Spezifikation gestern durchgelesen und ausgerechnet der Punkt ist nicht spezifiziert. Sieht so aus, dass Win7 die Einträge nicht überschreibt, Canons DryOS aber schon.

So "natürlich" ist das allerdings nicht, sonst hättest du das Nichtüberschreiben der Einträge seitens Microsofts Win 7 nicht ungewöhnlich gefunden. Die haben das FAT Dateisystem schließlich entwickelt. Von daher ist es eher ungewöhnlich, was Canon da macht. :-)

sceptical schrieb:Habt ihr es jetzt nochmal mit Kamerafunktionen getestet?

Ich habe jetzt mehrere Anläufe unternommen um den Effekt der weiterhin existierenden Verzeichnis-Einträge selbst zu reproduzieren. Obwohl ich auch dachte, dass ich den Effekt vorher mal gesehen habe, glaube ich mittlerweile, dass ich da einem Fehler aufgesessen bin. Ich hatte das auch nur nebenbei gesehen, weil ich da gerade etwas anderes untersuchen wollte. Entweder die Dateien bei mir wurden nicht überschrieben, oder, was ich momentan eher vermute: bei ImHex muss man höllisch aufpassen, dass man keinen alten gecachten Stand sieht.

Das kann aber nicht das Problem bei @Offshore7 gewesen sein, denn man sieht wie das neue Bild 0510 im selben Sektor anfängt wie das gelöschte 0509.

Jedenfalls habe ich jetzt alles auf der Kamera (Formatieren, Fotos machen und Löschen) probiert, aber auch alles vom Linux-Rechner und auch gemixt. Egal wie, bei mir verschwinden Verzeichnis-Einträge immer sofort, sobald der Datenbereich der gelöschten Datei neu belegt wird.

Erklärung habe ich momentan keine. Evtl. macht es (nur) Win7 anders, wie @Offshore7 vermutet. Das könnte ich auch nochmal testen. Aber es sieht so aus, dass man vom Verbleiben der Verzeichnis-Einträge zumindest nicht ausgehen kann. Dabei kam mir das so logisch vor, denn es hätte erklärt woher man weiß, dass genau 64 Bilder + 4 Videos gelöscht wurden aber nicht wiederherstellbar waren.

Und bzgl. #509 machen wir wohl eine große Rolle rückwärts und vielleicht einen ganz kleinen Schritt vorwärts: Verzeichnis-Einträge raus, Schlupfspeicher rein. Ist nur die Frage, ob Schlupfspeicher analysiert wurde und ob das irgendetwas aussagt. Wenn die Karte z.B. vorher schon mal bis über #509 hinaus gefüllt war und dann nur schnell formatiert wurde, hätte man den Schlupfspeicher schon extrem genau analysieren müssen, um mit Glück Rückschlüsse daraus zu ziehen. Und das hat man offenbar nicht gemacht, sonst wäre das beschrieben worden.

Nachtrag: @Offshore7 hat Recht - Windows7 macht das so.

Mir schießt gerade ein vielleicht blöder Gedanke durchs Hirn: Wenn die 64+4 Dateien auf einem Windows-Rechner gelöscht wurden, dann wäre verständlich woher man weiß dass es 64+4 sind¹⁾

Allerdings verschwinden die Einträge sobald man auf der Kamera oder z.B. einem Linux-Rechner irgendetwas in dem Verzeichnis macht (neues Bild).

¹⁾ evtl. auch nur 24+4, wenn die 40 rekonstruierbaren Bilder in den 64 eingerechnet sind

cyclic schrieb:Allerdings verschwinden die Einträge sobald man auf der Kamera oder z.B. einem Linux-Rechner irgendetwas in dem Verzeichnis macht (neues Bild).

Und wenn man die 03 Bilder erst in 04 löscht? Dann werden die Cluster der gelöschten Dateien aus 03 alle überschrieben .. während die 0xE5 Verzeichniseinträge in 03 bestehen bleiben?

Offshore7 schrieb:Und wenn man die 03 Bilder erst in 04 löscht? Dann werden die Cluster der gelöschten Dateien aus 03 alle überschrieben .. während die 0xE5 Verzeichniseinträge in 03 bestehen bleiben?

Das sieht so aus. Wenn der Content überschrieben wird (selber Start-Cluster hier z.B. 6), aber die neue Datei organisatorisch in einem anderen Verzeichnis liegt, dann bleibt der als gelöscht markierte (0xE5) Verzeichniseintrag bestehen, auch wenn die neue Datei z.B. unter Linux kopiert wird. Ob das wirklich auch so ist, wenn man auf der Kamera ein neues Bild macht, muss ich aber sicherheitshalber noch testen.

PS: In dem Fall wäre sogar ein Löschen auf der Kamera, aber erst nach dem letzten März-Bild denkbar (falls die gelöschten Dateien vom März waren).

cyclic schrieb:PS: In dem Fall wäre sogar ein Löschen auf der Kamera, aber erst nach dem letzten März-Bild denkbar (falls die gelöschten Dateien vom März waren).

Ich hoffe ich irre mich nicht, aber "Löschen auf der Kamera" ist damit doch wieder voll im Rennen, oder?

(Ein hin und her - technisch wie auch mental... 😅)

Danke, @sceptical für den neuen, wichtigen Input!

@Offshore7

Versuch alles auf der Kamera:

1. Low-Level-Formatierung (mal wieder)
2. 3 Bilder: 73, 74, 75
3. Monat auf Juli vorgestellt
4. 1 Bild: 76
5. Bild 74 wieder gelöscht
6. Kamera aus/an
7. Noch 1 Bild: 77

Ergebnis: der Verzeichniseintrag von Bild 74 ist noch da, obwohl Bild 77 den gleichen Speicherbereich belegt.

ringelnatz schrieb:Ich hoffe ich irre mich nicht, aber "Löschen auf der Kamera" ist damit doch wieder voll im Rennen, oder?

Bzgl. #509 ja, denn #508 und #510 sind ja beide aus dem April und daher auch im selben Ordner 102___04 (es sind übrigens 3 Unterstriche). Der Verzeichniseintrag von #509 wäre also verschwunden als #510 aufgenommen wurde.

Bzgl. der 64+4 gelöschten Dateien ist möglich, dass Bilder jeweils gelöscht wurden als der jeweilige Monat schon rum war. Also als kein Bild/Video zum jeweiligen Monat mehr gemacht wurde. Das ist interessant, weil es für mich bisher die einzige Erklärung darstellt, woher man die genaue Anzahl kennt (wenn man nicht nur die Lücken in den Bildnummern addiert hat, aber das dürften mehr als 68 sein). Klar ist auch, dass das Bilder von vor April sein müssen (oder dass nicht auf der Kamera, sondern z.B. einem Windows(-7)-Rechner gelöscht wurde). In jedem Fall müssen danach noch reichlich Bilder gemacht oder auf die Karte kopiert worden sein, weil sonst Bilder/Videos wiederherstellbar gewesen wären (das Löschen und neue Bilder müssen nicht zwangsläufig in einem Rutsch gemacht worden sein).

cyclic schrieb:Das ist interessant, weil es für mich bisher die einzige Erklärung darstellt, woher man die genaue Anzahl kennt (wenn man nicht nur die Lücken in den Bildnummern addiert hat, aber das dürften mehr als 68 sein). Klar ist auch, dass das Bilder von vor April sein müssen

Das ist alles echt sehr interessant - danke für die ganze Mühe und Zeit, die du investiert hast!

@Doctective
Dazu hätte ich eine Frage an dich, da du ja Akteneinsicht hast: Sind die Fotos im Koude Kaas Blog die einzigen, die von vor April da sind? Konkret spiele ich auf die Zeit in Bocas an und bin wie gesagt dabei, die Fotos vor Boquete mit den Tagebucheinträgen zu verbinden.

cyclic schrieb:Ergebnis: der Verzeichniseintrag von Bild 74 ist noch da, obwohl Bild 77 den gleichen Speicherbereich belegt.

Cool, danke, damit sind wir wohl erst mal am Ende der Low Level Fahnenstange angekommen und hätten ein paar Erklärungsmöglichkeiten in petto. :-)

U.a. wären Anzahl + Typ (Bild/Video) der 64+4 erklärbar und belegter Schlupfspeicher in #510 könnte dann auch aus dem März stammen. Matt äußerte vor 3 Tagen, dass er selbst nicht weiß, ob nun 40 plus oder 40 von 64+4. :|

Diebold schrieb:@Doctective
Dazu hätte ich eine Frage an dich, da du ja Akteneinsicht hast: Sind die Fotos im Koude Kaas Blog die einzigen, die von vor April da sind? Konkret spiele ich auf die Zeit in Bocas an und bin wie gesagt dabei, die Fotos vor Boquete mit den Tagebucheinträgen zu verbinden.

Fotos von Bocas oder Boquete von vor dem 1. April befinden sich nicht in der Akte. Meines Erachtens sind die gesammelten Bilder auf Koudekas auch nicht von der Kamera stammend, sondern von Handys. Ich vermute, sie stammen von den Facebookseiten von Kris und Lisanne.

Doctective schrieb:Fotos von Bocas oder Boquete von vor dem 1. April befinden sich nicht in der Akte. Meines Erachtens sind die gesammelten Bilder auf Koudekas auch nicht von der Kamera stammend, sondern von Handys. Ich vermute, sie stammen von den Facebookseiten von Kris und Lisanne.

Schade, dass sie nicht in der Akte sind.

Deine Vermutung stimmt meiner Meinung nach jedoch einerseits nicht, da die Bildnummern der meisten dort veröffentlichten Fotos (das erste dort veröffentlichte Foto aus Panama/Costa Rica: #170 vom 17.3. und das letzte aus Bocas: #420 vom 28.3.). Insofern sind sie zumindest meiner Meinung von der Kamera. Es stellt sich jedoch die Frage, ob alle Fotos von der Kamera geleakt wurden.

Andererseits stimmt deine Vermutung ein wenig, da aus Bocas zahlreiche Fotos vorhanden sind, die entweder eindeutig bzw. mutmaßlich mit den Handys der beiden oder aber bsp. von Ingrid und anderen gemacht wurden. Hinzu kommen ein paar wenige Fotos, deren Herkunft nicht klar wird.

Diebold schrieb:Es stellt sich jedoch die Frage, ob alle Fotos von der Kamera geleakt wurden

Ich habe keine Ahnung, woher diese Bilder stammen, sollten sie von der Kamera sein. Dazu müsste derjenige, der die Bilder in die Welt gesetzt hat, direkten Zugriff auf die Speicherkarte der Kamera gehabt haben. Man müsste dem Ursprung der Quelle mal nachgehen. Ich weiß nur, dass Matt von IP sagt, er habe alle Bilder der Kamera gesehen. Das kann nicht über eine Panama-Connection passiert sein. Die Kamerabilder von vor dem 1. April sind nicht Teil der Akten. Das NFI hat sie auch nicht untersucht. Wo die SD-Karte heute ist, weiß ich auch nicht. Entweder im NFI verblieben, nach Panama zurückgeschickt oder Lisannes Eltern übergeben (das Wahrscheinlichste). Wer oder ob sich jemand, der mit den Bildern zu tun hatte, eine "Privatkopie" angefertigt hat, die Voraussetzung also für einen Leak, weiß ich auch nicht. Vielleicht kennt @Anthurium den Ursprung dieser Bilder.

Ich kann mir immerhin noch vorstellen, dass Lisanne während ihres Urlaubs Bilder der Kamera am PC hochgeladen und auf ihre Facebookseite gestellt hat.

Doctective schrieb:Ich habe keine Ahnung, woher diese Bilder stammen, sollten sie von der Kamera sein. Dazu müsste derjenige, der die Bilder in die Welt gesetzt hat, direkten Zugriff auf die Speicherkarte der Kamera gehabt haben.

Spätestens beim NFI werden wohl hoffentlich Kopien gemacht worden sein, inkl. eines Bit für Bit identischen 1:1-Abbilds (sog. "Image" - hat mit Foto nichts zu tun). Auf dem wären dann auch genau die Überreste gelöschter Dateien, wie auf der originalen SD-Karte.

Und mind. eine Person aus dem Kreis derer die Zugang zu solchen Kopien (od. der orig. Karte) hatten, muss die Bilder geleakt haben.

---

Offshore7 schrieb:U.a. wären Anzahl + Typ (Bild/Video) der 64+4 erklärbar und belegter Schlupfspeicher in #510 könnte dann auch aus dem März stammen. Matt äußerte vor 3 Tagen, dass er selbst nicht weiß, ob nun 40 plus oder 40 von 64+4. :|

Aha, bin ich also nicht ganz alleine mit meiner Konfusion bzgl. der 64.

Ich habe nochmal wild gerechnet: wären 64 Bilder + 4 Videos erst nach dem letzten März-Bild gelöscht worden, wäre es mit den 33 Bildern der Wanderung und den 100 Nachtbildern schon eng geworden bzgl. überschreiben und man hätte eine gute Chance gehabt noch wiederherstellbare Bilder hinter #609 zu finden.

Nur mit den 100 Nachtbildern, die überwiegend viel kleiner als normale Bilder sind, hätte man die 64+4 wohl nicht überschreiben können.

Mit 24+4 sähe das anders aus. Aber natürlich können z.B. auch im März schon Januar-Bilder gelöscht worden sein.

Was ich gerade noch getestet habe: wenn man alle Bilder in einem Ordner löscht, dann wird auch der Ordner gelöscht und wenn ich neue Bilder mache, dann bekommt der neue Ordner dieselbe fortlaufende Nummer. Also könnte es sogar einen Februar-Ordner 101___02 gegeben haben, wenn alle Bilder vor dem ersten März-Bild gelöscht worden wären, dann hätte der März-Ordner trotzdem auch die Nummer 101 bekommen (101___03). Ich vermute aber in einem gelöschten Ordner bleiben keine Infos bzgl. gelöschter Dateien. Die 64+4 dürften dann also nicht von Februar sein.