Das rätselhafte Verschwinden von Kris Kremers & Lisanne Froon

sceptical schrieb:Am Besten mit der Kamera mal ausprobieren, ob die sich daran stört.

Ob sie sich daran stören würde weiß ich nicht, aber sie erzeugt sowas jedenfalls nicht. Das habe ich ja ausprobiert. Ich hatte zunächst sowas erwartet, weil Bits nachträglich von 1 -> 0 setzen ja im NAND theoretisch funktioniert (0 -> 1 dagegen nicht). Nur passiert das halt nicht und der ungenutzte Rest eines Sektors wird auch immer komplett auf 0 gesetzt (alle Bits), womit der nicht mehr veränderbar ist (ohne Erase). Sowohl Windows (7) als auch Kamera und Linux schreiben also das Verzeichnis immer neu.

Offshore7 schrieb:Aber es widerspricht der FAT32-Spezifikation. :-) 0x00 markiert immer das Ende der Liste und kann nicht zwischen gültigen Einträgen liegen. Sonst wäre alles ab 510 ungültig und der Verzeichnis-Cluster korrupt.

Danke, das erklärt's - es ist nämlich eigentlich schrecklich ineffektiv (bzgl. Wear-Management).

sceptical schrieb:Übrigens beantwortet dein Test auch nicht die ursprüngliche Fragestellung, ob der Gelöschteintrag überschrieben wird. Wenn die gelöschte Datei in einem anderen Ordner liegt, dann kann er den Eintrag natürlich nicht verwenden, weil die neue Datei dann im falschen Ordner angezeigt würde.

? Meine Tests zeigen: wenn gelöschte Datei überschrieben wird/wurde und sobald der Ordner(Inhalt) sich verändert, dann entfernt die Kamera den Verzeichniseintrag der gelöschten Datei (anders als Windows-7).

Wenn der Ordner nicht mehr angefasst wird, weil neue Dateien in einem anderen Ordner liegen, dann bleibt der Verzeichniseintrag der gelöschten Datei erhalten, obwohl sie im Datenbereich überschrieben wird.

Der erste Teil zeigt, dass ein Löschen auf der Kamera vor der Aufnahme von #510 möglich war, weil der Verzeichniseintrag dann verschwindet und es also keinerlei Spuren gibt, die belegen dass #509 jemals existiert hätte, so wie es im NFI-Bericht beschrieben wird. Also beantwortet es die Frage...

---

Diebold schrieb:Das ist ja auch durchaus denkbar. Zumindest wenn ich das Verhalten von Lisanne mit meinem vergleiche. Ich hätte genauso alle Fotos der Kamera vor dem Urlaub von der Kamera gelöscht und auf meine Festplatte gezogen, um nicht Gefahr zu laufen, dass die Speicherkarte irgendwann während des Urlaubs zu "voll" wäre...

Denkbar ist wie immer vieles. Man müsste wissen, ob der Januar-Ordner (100___01) leer war und man müsste testen, ob die Kamera leere Ordner behält oder löscht (wenn man auf der Kamera das letzte Bild eines Ordners löscht verschwindet auch der Ordner, aber ob sie Ordner löscht, wenn die vom PC aus geleert wurden ist damit noch nicht gesagt). Und seltsam ist dann, dass es keinen Februar-Ordner gibt.

Wie auch immer, für mich sieht das eher so aus als sei die Kamera ein Geschenk gewesen evtl. aus Anlass der Reise. Dann wäre die Kamera im Januar eingerichtet worden (Datum, Zeit, SD-Karte rein), max. ein paar ganz wenige Testfotos gemacht worden, dann im Februar ungenutzt im Schrank gelegen (kein Februar-Ordner) und erst im März verschenkt und sogleich intensiv benutzt worden.

In dem Fall wären die 64+4 oder 24+4 gelöschten Bilder und Videos zu denen mutmaßlich Verzeichnis-Einträge im Filesystem existierten alle vom März und die restlichen fehlenden Dateinummern (entweder 63 oder 103 weitere) würden vermutlich auch größtenteils aus dem März stammen (hier habe ich mal die Anzahlen aufgeschlüsselt: SD-Karte Filesystem Block/Cluster-Versuche (Seite 3) (Beitrag von cyclic)).

Das ist im Moment jedenfalls mal meine Arbeithypothese, auch wenn es sicherlich bei weitem nicht die einzige physikalisch mögliche Variante darstellt.

@Offshore7

Offshore7 schrieb am 14.03.2025:XI - Handy Timeline (beide Handys)

War es eine bewusste Entscheidung, die mit jedem Handy aufgenommenen Fotos oben am Mirador nicht einzubeziehen?

Ich war überrascht zu lesen:
• Kris’ iPhone wurde am 31. März um 13:13 Uhr vollständig neu gestartet. Ein komplettes Ausschalten war für sie also offenbar nicht ungewöhnlich. Gibt es Daten darüber, wann genau sie das Gerät ausgeschaltet hat? Meine Vermutung: Sie hat es vor dem Besuch der Guardería Aura ausgeschaltet.
• Auf Kris’ iPhone blieb zwischen 17:00 Uhr am 31. März und 11:05 Uhr am 1. April erstaunlich lange jede Aktivität aus. Das sind volle 18 Stunden Funkstille, obwohl WLAN verfügbar war. Nicht einmal am Morgen des 1. April wurde WhatsApp gecheckt (laut NFI war 11:05 Uhr die erste Aktivität). Das wäre angesichts der Zeitverschiebung zu Freunden und Familie in den Niederlanden eigentlich zu erwarten gewesen. Das NFI müsste in diesem Zeitraum jedoch mehrere Powerlogs gefunden haben (mindestens im Stundentakt wegen Sleep/Wake) und hätte wie beim Samsung den Akkustand melden können. Man gewinnt den Eindruck, dass für den Morgen ebenfalls keine Powerlogs vorliegen, dass dies aber nicht ausdrücklich erwähnt wurde, weil der Zeitraum 13:38–16:39 für den Fall relevanter ist. Gibt es Hinweise auf Aufbewahrungsfristen oder darauf, dass diese Logs beim Überschreiten einer Dateigröße automatisch gelöscht werden?

Agno schrieb:War es eine bewusste Entscheidung, die mit jedem Handy aufgenommenen Fotos oben am Mirador nicht einzubeziehen?

Ja. Je mehr Einträge eine Timeline enthält desto unübersichtlicher wird sie.

Agno schrieb:Ein komplettes Ausschalten war für sie also offenbar nicht ungewöhnlich.

Lt. Romain C 74 Neustarts seit 31.7.2013, macht im Schnitt jeden 4ten Tag.

Agno schrieb:Gibt es Daten darüber, wann genau sie das Gerät ausgeschaltet hat?

Gibt es 100pro, aber mir nicht bekannt.

Agno schrieb:Auf Kris’ iPhone blieb zwischen 17:00 Uhr am 31. März und 11:05 Uhr am 1. April erstaunlich lange jede Aktivität aus.

Nein. Es gab am 31.3. zB auch iPhone-Aktivitäten nach 19 Uhr oder Änderungen im Dateisystem am 1.4. um 4 Uhr morgens.

Agno schrieb:Man gewinnt den Eindruck, dass für den Morgen ebenfalls keine Powerlogs vorliegen

Mein Eindruck ist eher, dass das NFI zwischen Logs mit Aktivität und solchen ohne unterscheidet.

Agno schrieb:Gibt es Hinweise auf Aufbewahrungsfristen oder darauf, dass diese Logs beim Überschreiten einer Dateigröße automatisch gelöscht werden?

Auf meinen Testgeräten keine Hinweise. Powerlogs werden Tag für Tag in eigene Dateien archiviert (powerlog.gz). Da habe ich Tage mit über 10.000 Logs dabei. Kann sein, dass die iwann rollierend gelöscht werden, aber nicht in dem relevanten Zeitraum des Falls K+L.

Danke für die Klarstellungen. Mein Bild wird nach und nach vollständiger.

Offshore7 schrieb:Mein Eindruck ist eher, dass das NFI zwischen Logs mit Aktivität und solchen ohne unterscheidet.

Das leuchtet ein: Wenn man die Daten nur durch die „Aktivitäten“-Brille betrachtet, um eine mögliche Handlungskette zu erstellen, blendet man zwangsläufig den Großteil der hunderten detaillierten Powerlogs aus.

Geht man dagegen davon aus, dass dem NFI diese detaillierten Powerlog-Daten gar nicht vorlagen, könnte ein bislang unentdeckter Bug oder sogar eine Datenschutz-Einstellung verhindert haben, dass nur die im RAM gespeicherten Daten jemals in den NAND-Flash geschrieben wurden – fast den gesamten Zeitraum über.

Rein aus dem Bauchgefühl heraus vermute ich, dass die iOS-7-Entwickler die Powerlogs im Ruhezustand bewusst nur im flüchtigen RAM sammelten und erst nachträglich gebündelt in den NAND-Flash schrieben, um Energie zu sparen. Das Öffnen und Schließen einer Datenbank sowie das Einzel-Schreiben jedes Logs ins NAND verursacht Overhead und verbraucht mehr Strom. Deshalb wurden letztlich nur die markanten Nutzerereignisse – etwa das Tätigen eines Anrufs oder das Aufnehmen eines Fotos – sauber protokolliert; dabei ist das Telefon ohnehin wach, der Bildschirm an und der Datenbankkanal bereits geöffnet (z. B. für Foto- oder Anrufprotokolle). Die zusätzlichen Kosten, einen Powerlog direkt in den NAND-Flash zu schreiben, sind in solchen Momenten marginal.

Agno schrieb:Rein aus dem Bauchgefühl heraus vermute ich, dass die iOS-7-Entwickler die Powerlogs im Ruhezustand bewusst nur im flüchtigen RAM sammelten und erst nachträglich gebündelt in den NAND-Flash schrieben, um Energie zu sparen.

Nope, im Sleep-Modus gibt es keine Powerlogs:


[.. Sleep ..]
09/03/24 18:28:27 [Sleep] event=did_sleep;

[.. Wake ..]
09/03/24 19:25:34 [Wake] reason= ...


Dazwischen ist nix ..

Offshore7 schrieb:Dazwischen ist nix ..

Aber ich dachte, das Gerät wacht etwa jede Stunde kurz auf vom Sleep-Modus, um Akkustand und Signalstärke im RAM zu protokollieren? Dein Beispiel deckt weniger als eine Stunde ab – sobald man die Stundenmarke überschreitet, müsste doch eigentlich ein Powerlog auftauchen, oder?

Agno schrieb:Aber ich dachte, das Gerät wacht etwa jede Stunde kurz auf vom Sleep-Modus, um Akkustand und Signalstärke im RAM zu protokollieren? Dein Beispiel deckt weniger als eine Stunde ab – sobald man die Stundenmarke überschreitet, müsste doch eigentlich ein Powerlog auftauchen, oder?

Das da oben sind ja bereits 2 Powerlogs, nämlich Sleep und Wake. Meine Geräte wachen ca. 1 pro Stunde "alleine" auf, messen DANACH Signalstärke und Akkustand und loggen es zusammen mit mehreren Dutzend anderen Powerlogs direkt ins NAND-Flash. Dann geht es nach wenigen Sekunden wieder in den Sleep-Modus.

Bei Kris iPhone sieht es so aus, als würde es nur aufwachen, wenn man den Hardware-Button am Gerät drückt. Aber auch hier: Erst DANACH werden Powerlogs generiert und direkt persistent gespeichert. In der Sleep-Phase null, was nicht heißt, dass nix gemessen oder überwacht wird und zB der Funkmast gewechselt oder ein Wake ausgelöst wird.

Offshore7 schrieb:Meine Geräte wachen ca. 1 pro Stunde "alleine" auf, messen DANACH Signalstärke und Akkustand und loggen es zusammen mit mehreren Dutzend anderen Powerlogs direkt ins NAND-Flash. Dann geht es nach wenigen Sekunden wieder in den Sleep-Modus.

Das ist interessant, und nur zum Verständnis: Funktioniert dies nicht in folgender Abfolge, bei der der RAM-NAND-Bug greift:
Telefon booten → warten, bis es in den Ruhezustand geht → warten bis das System nach einer Stunde von selbst kurz aufwacht und DANACH Signalstärke und Akkustand messt→ und es wird dabei noch immer gar nichts vom RAM in den NAND geschrieben?

Offshore7 schrieb:und loggen es zusammen mit mehreren Dutzend anderen Powerlogs direkt ins NAND-Flash. Dann geht es nach wenigen Sekunden wieder in den Sleep-Modus.

Um das genauer zu verstehen: können diese „mehreren Dutzend anderen Powerlog-Einträge“ auch solche enthalten, die zuvor im Hintergrund mit älteren Zeitstempeln im RAM gesammelt wurden? Oder handelt es sich ausschließlich um neue Einträge mit dem Zeitstempel des selbsttätigen Aufwachens? Anders gefragt: Löst dieses system­seitige Aufwachen auch eine rückwirkende Übertragung der flüchtigen RAM-Daten in den persistenten NAND-Flash aus?

Offshore7 schrieb:Bei Kris iPhone sieht es so aus, als würde es nur aufwachen, wenn man den Hardware-Button am Gerät drückt. Aber auch hier: Erst DANACH werden Powerlogs generiert und direkt persistent gespeichert. In der Sleep-Phase null, was nicht heißt, dass nix gemessen oder überwacht wird und zB der Funkmast gewechselt oder ein Wake ausgelöst wird.

Das wirft die Frage auf, ob der kleine „Daemon“, der das Telefon normalerweise stündlich aufwecken sollte, bei Kris iPhone irgendwie deaktiviert wurde oder ob seine Abfrage­frequenz vielleicht herabgesetzt wurde, um den Akku noch effizienter zu schonen (some extreme power saving mode). Allerdings fällt es mir schwer zu glauben, dass es dafür überhaupt Nutzereinstellungen gibt. Oder ist womöglich vorübergehend etwas mit der „RTC“ (wird die nicht von einem kleinen Kondensator gepuffert?) schief gelaufen, die eigentlich messen soll, ob eine Stunde vergangen ist?

Agno schrieb:Telefon booten → warten, bis es in den Ruhezustand geht → warten bis das System nach einer Stunde von selbst kurz aufwacht und DANACH Signalstärke und Akkustand messt→ und es wird dabei noch immer gar nichts vom RAM in den NAND geschrieben?

Beim Booten ohne weitere Bedienung ist die Abfolge so:

Booten -> Bootlogs ins NAND-Flash -> Lockscreen mit Uhrzeit etc. -> Standby (Display aus) -> Loggen von ~40 Powerlogs (darunter Signalstärke und Akku, mehrfach) ins RAM -> Sleep-Modus (kein Logging)

Standby und Sleep sind also nicht dasselbe, Sleep erfolgt erst, wenn alles erledigt (geloggt) ist.

Agno schrieb:Anders gefragt: Löst dieses system­seitige Aufwachen auch eine rückwirkende Übertragung der flüchtigen RAM-Daten in den persistenten NAND-Flash aus?

Nein. Es sind ausschließlich neue Powerlogs beginnend mit dem Timestamp des Aufwachens. Ob die ins RAM oder ins NAND geschrieben werden, hängt natürlich davon ab, ob das Handy initial entsperrt wurde.

Agno schrieb:Das wirft die Frage auf, ob der kleine „Daemon“, der das Telefon normalerweise stündlich aufwecken sollte, bei Kris iPhone irgendwie deaktiviert wurde o

Agno schrieb:Oder ist womöglich vorübergehend etwas mit der „RTC“ (wird die nicht von einem kleinen Kondensator gepuffert?) schief gelaufen,

Es ist nicht genau 1 Stunde, manchmal wacht es auch 2x pro Stunde auf. Wohlgemerkt in Alufolie, also kein WLAN etc. vorhanden. Mir ist RTC auch nur als RealTimeClock bekannt, aber bei Apple kann es offenbar auch RealTimeCommunication bedeuten. :-) Wie es im Blog steht hat dieser Punkt nur theoretische Relevanz, genauso wie die Möglichkeit einer Spy-App. Ohne weitere Daten aus dem NFI-Report oder von den DVDs kann ich da nix Konkretes zu sagen. Wenn das NFI das gemacht hat, was ich vermute, weiß ich da bald etwas mehr.

https://www.t-online.de/nachrichten/panorama/ungluecke/id_100790294/juliana-m-rettung-kommt-zu-spaet-touristin-stirbt-nach-sturz-am-vulkan.html

Eine Frau aus Brasilien verunglückt während einer Wanderung, sie kann kurzfristig nicht gerettet werden, kann sich aber noch selbstständig bewegen, nach 4 Tage finden sie die Rettungstrupps, sie war schon verstorben.
Beileid der Familie, die Dschungelumgebung kann lebensgefährlich sein.

Ich vermute, so ähnlich ist es auch bei Kris und Lisanne passiert.

Nachtrag, am Vulkan ist kein Dschungel, sondern felsiges Gelände, da sollte man denken, dass eine Suche recht schnell geht, aber das Wetter war zu schlecht.

MajorQuimby schrieb:Ich vermute, so ähnlich ist es auch bei Kris und Lisanne passiert.

Sehr traurig. Leider dass sie nicht beizeiten gerettet werden konnte.

Allerdings wette ich, diese junge Frau hat keine mysteriösen Telefon Logs hintergelassen.

Offshore7 schrieb:Beim Booten ohne weitere Bedienung ist die Abfolge so:

Booten -> Bootlogs ins NAND-Flash -> Lockscreen mit Uhrzeit etc. -> Standby (Display aus) -> Loggen von ~40 Powerlogs (darunter Signalstärke und Akku, mehrfach) ins RAM -> Sleep-Modus (kein Logging) (...).

Aus Neugier: Hast du schon einmal versucht, die Passcode-Eingabe vollständig zu deaktivieren? Und falls ja, verschwindet der RAM → NAND-Bug dann?

Agno schrieb:Hast du schon einmal versucht, die Passcode-Eingabe vollständig zu deaktivieren? Und falls ja, verschwindet der RAM → NAND-Bug dann?

Ja. Wenn du den Passcode deaktivierst, verschwindet das RAM->NAND-Problem. Es steht zwar weiterhin "Zum Entsperren streichen" auf dem Lockscreen, aber es ist kein "initiales" Swipen nötig, Powerlogs werden sofort (ab Logging-Beginn) ins NAND-Flash geloggt.

Daher bin ich inzwischen auch sicher, dass der "Bug" quasi ein unschöner Nebeneffekt der iOS Data Protection Richtlinie ist, die mit iOS7 zwangsweise aktiviert wurde:

Mit iOS 7 aktiviert Apple diese Verschlüsselung jetzt zwangsweise. Konkret werden alle Dateien, die eine App in den Unterordnern Documents/ und Library/ mit der Schutzklasse NSFileProtectionCompleteUntilFirstUserAuthentication versehen. Diese sorgt dafür, dass die Daten erst verfügbar sind, wenn sich der Anwender nach dem Start des Geräts das erste Mal mit seinem Passcode angemeldet hat.

https://www.heise.de/hintergrund/iOS-Verschluesselung-durchleuchtet-2066500.html

Offshore7 schrieb:a. Wenn du den Passcode deaktivierst, verschwindet das RAM->NAND-Problem. Es steht zwar weiterhin "Zum Entsperren streichen" auf dem Lockscreen, aber es ist kein "initiales" Swipen nötig, Powerlogs werden sofort (ab Logging-Beginn) ins NAND-Flash geloggt.

Daher bin ich inzwischen auch sicher, dass der "Bug" quasi ein unschöner Nebeneffekt der iOS Data Protection Richtlinie ist, die mit iOS7 zwangsweise aktiviert wurde:

Das alles liefert sehr überzeugende Hinweise darauf, dass deine Analyse des RAM-→-NAND-Bugs vollkommen zutrifft.

Aber was für ein seltsamer Fall ist dies? Im rätselhaften Zeitraum zwischen Foto 508 um 13:50 Uhr und den beiden 112-Notrufen um 16:39 und 16:51 Uhr, zeigen die forensischen Daten, dass sich ALLE elektronischen Geräte der beiden plötzlich auffällig verhielten:
• Das iPhone 4 liefert auf einmal keinerlei Powerlogs mehr.
• Das Samsung verbraucht ungewöhnlich schnell Batterie (nicht allein durch den Aufenthalt in einer Funkloch-Zone erklärbar).
• Die Canon SX270 überspringt die Bildnummer 509, und es werden keine weiteren Fotos gemacht.

Wenn die zugrunde liegenden Daten stimmen, wie wahrscheinlich ist es, dass alle drei Effekte gleichzeitig eintreten? Kein Zweifel, Carl Jung hätte sich an dieser Synchronizität erfreut...

Ich halte es für sehr plausibel, dass das Überspringen (und Fehlen) der 509 durch einen kräftigen Sturz oder Wasserschaden reproduziert werden kann. Unbestritten ist, dass die Kamera in ihrer eigenen Tasche im Rucksack steckte; dieser muss also geöffnet gewesen sein, als das Foto 509 aufgenommen werden sollte – und dadurch lagen die Telefone ungeschützt. Ein ernsthafter Sturz in einen Fluss beim Versuch, die 509 zu machen, könnte den offenen Rucksack umgekippt haben; die Telefone landen im Wasser und erleiden kurzzeitige Kurzschlüsse auf ihren Platinen.

Viele andere rationale Szenarien fallen mir nicht ein ­– außer vielleicht, dass sich die Telefone gegenseitig beeinflussten, weil sie zu eng zusammenlagen (was angesichts der Einhaltung aller EC-Normen äußerst unwahrscheinlich ist).

Agno schrieb:Ich halte es für sehr plausibel, dass das Überspringen (und Fehlen) der 509 durch einen kräftigen Sturz oder Wasserschaden reproduziert werden kann.

Sturz halte ich wie gesagt für ziemlich unplausibel. Wasserschaden wäre denkbar, wobei das für mich auch nicht hochplausibel klingt. Müsste schon ein recht selektiver Wasserschaden gewesen sein.

Agno schrieb:Unbestritten ist, dass die Kamera in ihrer eigenen Tasche im Rucksack steckte;

Zum Zeitpunkt des Auffindens des Rucksacks ja, da enthielt der aber u.a. auch die BHs. Die beiden werden bei dem angeschlagenen Tempo mMn nicht jedesmal die Kameratasche aus dem Rucksack und dann die Kamera aus dieser Kameratasche gefriemelt haben.

Bzgl. Handys stimme ich zu. Man sieht auf keinem der Kamerafotos jemals eines der Handys. Es liegt z.B. keines je auf einem Tisch und auch sonst hat keine der gerade fotografierten je ein Handy in der Hand oder sichtbar z.B. in der Hosentasche. Da sie am Pianista nur einen Rucksack dabei hatten werden beide Handys darin verstaut gewesen sein.

Agno schrieb:die Telefone landen im Wasser und erleiden kurzzeitige Kurzschlüsse auf ihren Platinen.

Beide ohne irgendwelche diesbezüglichen Fehler-Logs (auch später nicht)?

Agno schrieb:Aber was für ein seltsamer Fall ist dies?

Ja das sehe ich auch so: es ist extrem auffällig, was da alles im gleichen Zeitraum an Merkwürdigkeiten aufgelaufen ist. Wobei #509 natürlich irgendwann zw. #508 und #510 "passiert" sein kann - das ist eine ganze Woche.

cyclic schrieb am 21.06.2025:Kannst du das genauer beschreiben? Sobald ich die Karte rausziehe, oder an best. Pins den Kontakt unterbreche (mind. einer der Masse-Pins) geht sofort die Kamera aus.
Du kannst die Karte ziehen, die Kamera bleibt an und danach noch mind. ein Foto machen und der Zähler zählt hoch?
(Man kann schon ohne Karte "Fotos" machen - sie werden halt logischer Weise weder gespeichert, noch zählt der Zähler dabei weiter hoch

Wenn du die SD Karte rausziehst während oder unmittelbar nachdem (<1s oder so) du den Auslöser drückst geht die Kamera zwar aus, aber wenn du die SD Karte wieder einsteckst und danach weiter Fotos machst wirst du feststellen dass ein Foto übersprungen wurde. Das ist gut reproduzierbar.

Meine spontane Interpretation ist, dass der Zähler inkrementiert wird bevor der Speichervorgang abgeschlossen ist. Verliert die Kamera in dieser Zeit den Kontakt zur Speicherkarte dann hat man den Effekt eines fehlenden Bildes.

Agno schrieb:• Das iPhone 4 liefert auf einmal keinerlei Powerlogs mehr.
• Das Samsung verbraucht ungewöhnlich schnell Batterie (nicht allein durch den Aufenthalt in einer Funkloch-Zone erklärbar).

Gibt es da eine Übersicht bzw. kann man zeitlich weiter eingrenzen wann die Auffälligkeiten genau losgingen?

Tatum schrieb:Gibt es da eine Übersicht bzw. kann man zeitlich weiter eingrenzen wann die Auffälligkeiten genau losgingen?

Die beste Quelle hierfür ist die Telefonanalyse von @Offshore7, hier zu finden.

Allerdings ist keineswegs sicher, dass die zugrunde liegenden Daten zum angeblich seltsamen Verhalten der drei Geräte wirklich hieb- und stichfest sind. Es könnte sich ebenso um Interpretationen von NFI-Interpretationen der Rohdaten handeln – auf die wir keinen Zugriff haben. Das NFI war womöglich in erster Linie darauf bedacht, eine Zeitleiste zu erstellen, und hat nur „harte“ Ereignisse (Anrufe, Fotos, Netzverlust) herausgefiltert. Eine Meldung wie „keine Powerlogs“ könnte daher schlicht bedeuten: „In diesem Zeitfenster gab es keine fallrelevanten Ereignisse.“

Man tappt schnell in die Falle zu denken: „Um 13:50 Uhr bei Foto 508 wirkten sie noch fröhlich“ – und dann: „Niemand in den Niederlanden würde um 16:39 Uhr die 112 wählen, wenn nichts sehr Ernstes passiert wäre“ (was zweifellos stimmt). Daraus ließe sich vorschnell schließen, es müsse etwas Schreckliches vorgefallen sein. Sobald man diese Brille aufsetzt, wirkt plötzlich alles verdächtig, und es wird schwer, das Signal vom Rauschen zu trennen.

Es ist durchaus möglich, dass den Mädchen nichts Schlimmes passiert ist und der 112-Versuch lediglich dazu diente, den Gastgeber in Boquete zu beruhigen: Man habe sich verlaufen, komme zum Abendessen nicht rechtzeitig zurück, werde aber sicher am nächsten Nachmittag wieder da sein (sie konnten mit den SIM-Karten ihren Handys schlicht keine andere Nummer als 112 anrufen).

Es ist außerdem nicht eindeutig, ob der starke Akkuabfall beim Samsung darauf zurückzuführen war, dass eine App offen und aktiv war (Facebook war dafür berüchtigt) und das Gerät sich gleichzeitig in einer Funklochzone befand.

Die Daten zum fehlenden Foto 509 – einschließlich der fortlaufenden Speicheradressen auf der SD-Karte – halte ich für ziemlich belastbar. Bei den Telefondaten bin ich mir weit weniger sicher, solange wir die Rohdaten-DVD nicht gesehen haben.

Agno schrieb:Es ist durchaus möglich, dass den Mädchen nichts Schlimmes passiert ist und der 112-Versuch lediglich dazu diente, den Gastgeber in Boquete zu beruhigen: Man habe sich verlaufen, komme zum Abendessen nicht rechtzeitig zurück, werde aber sicher am nächsten Nachmittag wieder da sein (sie konnten mit den SIM-Karten ihren Handys schlicht keine andere Nummer als 112 anrufen).

Das ist nicht logisch. Wer sich hinter dem Mirador im Dschungel verläuft, und die Nacht vor sich hat, der hat einen ernsten Notfall. Dann muss man den Notruf verständigen. Es geht bereits dann ums Überleben und nicht darum, der Gastmutter mitzuteilen, dass man sich verlaufen habe. Ich bin überzeugt davon, dass sie größere Sorgen hatten, als um die Befindlichkeit ihrer Gastmutter, mit der sie sowieso zuvor so gut wie keinen Kontakt hatten. Schließlich haben sie ihr auch nicht mitgeteilt, dass sie überhaupt weggehen. Tatsächlich hat sich Miriam ja auch überhaupt keine Sorgen gemacht, als Kris und Lisanne abends nicht nach Hause gekommen sind.

Agno schrieb:(sie konnten mit den SIM-Karten ihren Handys schlicht keine andere Nummer als 112 anrufen).

Warum nicht? Sie hätten jede Nummer anrufen können, und es wäre logisch gewesen, es auszuprobieren. Wenn man allerdings keinen Empfang hat, kann man weder seine Angehörigen noch den Notruf erreichen.