Das rätselhafte Verschwinden von Kris Kremers & Lisanne Froon
um 08:43Noch 2 abschließende Test-Ergebnisse, bevor ich auf der schönen Insel NonPublic Urlaub mache. :-)
Ich gehe sicher davon aus, dass der NAND-Speicher nicht im Chip-Off-Verfahren ausgelesen wurde, sondern dass die DVD-Images im lfd. Betrieb zB mit dem simplen Befehl "dd" erstellt wurden. D.h. das iPhone wurde im Juni gebootet.
Die letzte Nutzung am 11. April, selbst wenn 1 Std. im Standby, hätte über 100 neu erstellte und geänderte Dateien zurückgelassen. Diese Anzahl reduziert sich durch ein späteres Booten auf etwa 10 (oder je nach Nutzung mehr), weil der Rest der über 100 Dateien vom 11. April einen Timestamp von Juni erhält, zB dadurch, dass eine Log-Datei weitergeschrieben wird. Das korreliert mit den bekannten 18 vom NFI gefundenen Dateien für den 11. April.
Außerdem sind vom NFI ausgewertete Dateien kryptografisch an das Originalgerät gebunden, weil der neben Passcode und weiteren Keys zur Entschlüsselung nötige UID-Key in den A4-Chip des iPhones eingebrannt und nicht extrahierbar ist (nicht mal von Apple selbst). Würde man die Speicherchips per Chip-Off auslesen (NAND-Dump) oder in ein anderes iPhone 4 einbauen, wären diese Dateien nicht dekodierbar. Auch das spricht eindeutig dafür, dass die Forensik-Tools von zB Cellebrite auf das in Betrieb befindliches iPhone zugegriffen haben.
Der Betrieb am Computer im DFU-Mode per SSH-Ramdisk ist spurenlos möglich. Jedoch startet das iPhone automatisch, sobald man das Kabel anschließt. Auch das Versetzen in den DFU-Mode ist eine Timing-Sache, wo 1-2 Sekunden darüber entscheiden, ob das iPhone bootet oder erfolgreich in den DFU-Mode versetzt wird. Da am 11. April ein Startup-Log existiert (Fakt) wurde das Gerät absichtlich oder unabsichtlich zumindest kurz bis zum Lockscreen gebootet. Dadurch hätten wir bzgl. der 18 Dateien (leider) dieselbe Ausgangslage wie oben beschrieben und können keines der beiden Szenarios festnageln.
Die Verbindung mit einem Computer wird zwar geloggt, aber das lässt sich durch geschicktes Verkabeln verhindern oder ggfs. im Log löschen. Interessanter: 4 der ermittelten 18 Dateien sind lt. meinen Tests in jedem Fall versteckte FSEvents-Dateien.
Die einzige Möglichkeit festzustellen, was am 11. April und auch zB vom 4. bis 6. April mit dem iPhone gemacht wurde, ist eine Analyse der FSEvents (File System Events), einer 2014 forensisch kaum erforschten System-Komponente, die zB auch gelöschte Dateien registriert. Heute gibt es Forensik-Tools, womit so eine Analyse kein Problem ist (selbst getestet).
Wie schon in meinem Blog stand: Forensik-Expertin Nicole Ibrahim (Associates in Digital Forensics and Cyber Crime from Richland College, Bachelors of Technology in Information Assurance and Digital Forensics from Oklahoma State University’s Institute of Technology) berichtete erstmals 2017 über die forensische Bedeutung der FSEvents auf ihrer Website HeX-OR Forensics.
Das RAM/NAND-Problem aufgrund in iOS 7 neu eingeführter Data Protection Maßnahmen scheint 2014 ebenfalls undokumentiert und dem NFI in allen Auswirkungen unbekannt gewesen zu sein. Nehmen wir die FSEvents dazu und im Kamera-Bereich Dinge wie Slack Space + File Carving Methoden sowie die Aussage des FvdG-Teams, dass sie am 11. April eine Fremdnutzung des iPhones nicht ausschließen konnten, dann sind das mMn. genug offensichtliche und technologische Fakten, die aufgrund des NFI-Reports und ungeklärter Sachverhalte Nachermittlungen in Form einer Hinzuziehung von Spezial-Experten erforder(te)n.
Denn aus kriminalistischer Sicht hat das NFI offengelassen, warum das iPhone nach dem letzten Notruf über mehr als 1 Woche lang neunmal gebootet wurde und dabei Notrufe, Not-SMS, Signalstärken, Akkustände und Aktivitäts-Logs fehlen, warum das Handy trotz 40% Akku unsinnig schnell ausgeschaltet wurde sowie was bei dem einstündigen Betrieb am 11. April damit gemacht wurde, um eine "unmögliche" Datenlage zu produzieren.
Und das ist nur der digital-forensische Teil, ungeklärte Sachverhalte und offizielle Forderungen zu Nachermittlungen gab es ja auch in anderen Bereichen. Der Fall wurde mE zum Cold Case, weil die StA eine zu frühe und unfundierte Abschlussbewertung durchgesetzt hat, ohne neue Fakten zu berücksichtigen und auszuermitteln.
Wie u.a. auch eine neue Timeline oder auffallend unterschiedliche Verwesungszustände, trotz extrem schneller Skelettierung bei beiden. Was bei anzunehmenden unterschiedlichen Bedingungen (Wasser=langsamere Verwesung, Luft) und im Vergleich zB zu Cody Dial (zum selben Zeitpunkt wie K+L im Regenwald verstorben, nur auf der anderen Seite der Grenze in Costa Rica), dessen Skelett nach 2 Jahren noch fast vollständig intakt war, eher unplausibel ist.
Eine weitere kleine Sache konnte ich nun auch klären. Notrufe über die Notruffunktion werden definitiv geloggt, auch wenn das Handy nicht initial entsperrt wurde. Die Notruffunktion nimmt nur Notrufnummern an, wie 112 oder 911. Bisher hatte ich nur Fantasienummern getestet und die wurden nicht geloggt bzw. nur, wenn man über den Taschenrechner-Bug den SIM-Pin eingegeben hat (was ein weiterer Bug ist, dass dann alle Nummern gehen).
Jetzt hab ich den Bruchteil einer Sekunde :-) die 911 getestet und das wurde sofort geloggt. Somit ist die bisher geschlussfolgerte Annahme bewiesen, dass der RAM/NAND-"Bug" bei Notrufen keine Rolle spielt und nach dem letzten Notruf am 3. April bis zum 11. April trotz neunmaligem Booten kein Notruf-Versuch mehr erfolgte. Für Not-SMS gilt das sowieso, weil es keine Quick Reply Funktion auf dem Lockscreen gab.
Ich gehe sicher davon aus, dass der NAND-Speicher nicht im Chip-Off-Verfahren ausgelesen wurde, sondern dass die DVD-Images im lfd. Betrieb zB mit dem simplen Befehl "dd" erstellt wurden. D.h. das iPhone wurde im Juni gebootet.
Die letzte Nutzung am 11. April, selbst wenn 1 Std. im Standby, hätte über 100 neu erstellte und geänderte Dateien zurückgelassen. Diese Anzahl reduziert sich durch ein späteres Booten auf etwa 10 (oder je nach Nutzung mehr), weil der Rest der über 100 Dateien vom 11. April einen Timestamp von Juni erhält, zB dadurch, dass eine Log-Datei weitergeschrieben wird. Das korreliert mit den bekannten 18 vom NFI gefundenen Dateien für den 11. April.
Außerdem sind vom NFI ausgewertete Dateien kryptografisch an das Originalgerät gebunden, weil der neben Passcode und weiteren Keys zur Entschlüsselung nötige UID-Key in den A4-Chip des iPhones eingebrannt und nicht extrahierbar ist (nicht mal von Apple selbst). Würde man die Speicherchips per Chip-Off auslesen (NAND-Dump) oder in ein anderes iPhone 4 einbauen, wären diese Dateien nicht dekodierbar. Auch das spricht eindeutig dafür, dass die Forensik-Tools von zB Cellebrite auf das in Betrieb befindliches iPhone zugegriffen haben.
Der Betrieb am Computer im DFU-Mode per SSH-Ramdisk ist spurenlos möglich. Jedoch startet das iPhone automatisch, sobald man das Kabel anschließt. Auch das Versetzen in den DFU-Mode ist eine Timing-Sache, wo 1-2 Sekunden darüber entscheiden, ob das iPhone bootet oder erfolgreich in den DFU-Mode versetzt wird. Da am 11. April ein Startup-Log existiert (Fakt) wurde das Gerät absichtlich oder unabsichtlich zumindest kurz bis zum Lockscreen gebootet. Dadurch hätten wir bzgl. der 18 Dateien (leider) dieselbe Ausgangslage wie oben beschrieben und können keines der beiden Szenarios festnageln.
Die Verbindung mit einem Computer wird zwar geloggt, aber das lässt sich durch geschicktes Verkabeln verhindern oder ggfs. im Log löschen. Interessanter: 4 der ermittelten 18 Dateien sind lt. meinen Tests in jedem Fall versteckte FSEvents-Dateien.
Die einzige Möglichkeit festzustellen, was am 11. April und auch zB vom 4. bis 6. April mit dem iPhone gemacht wurde, ist eine Analyse der FSEvents (File System Events), einer 2014 forensisch kaum erforschten System-Komponente, die zB auch gelöschte Dateien registriert. Heute gibt es Forensik-Tools, womit so eine Analyse kein Problem ist (selbst getestet).
Wie schon in meinem Blog stand: Forensik-Expertin Nicole Ibrahim (Associates in Digital Forensics and Cyber Crime from Richland College, Bachelors of Technology in Information Assurance and Digital Forensics from Oklahoma State University’s Institute of Technology) berichtete erstmals 2017 über die forensische Bedeutung der FSEvents auf ihrer Website HeX-OR Forensics.
Mac Forensics: Looking into the Past with FSEvents - SANS DFIR Summit 2017
Externer Inhalt
Durch das Abspielen werden Daten an Youtube übermittelt und ggf. Cookies gesetzt.
Durch das Abspielen werden Daten an Youtube übermittelt und ggf. Cookies gesetzt.
Das RAM/NAND-Problem aufgrund in iOS 7 neu eingeführter Data Protection Maßnahmen scheint 2014 ebenfalls undokumentiert und dem NFI in allen Auswirkungen unbekannt gewesen zu sein. Nehmen wir die FSEvents dazu und im Kamera-Bereich Dinge wie Slack Space + File Carving Methoden sowie die Aussage des FvdG-Teams, dass sie am 11. April eine Fremdnutzung des iPhones nicht ausschließen konnten, dann sind das mMn. genug offensichtliche und technologische Fakten, die aufgrund des NFI-Reports und ungeklärter Sachverhalte Nachermittlungen in Form einer Hinzuziehung von Spezial-Experten erforder(te)n.
Denn aus kriminalistischer Sicht hat das NFI offengelassen, warum das iPhone nach dem letzten Notruf über mehr als 1 Woche lang neunmal gebootet wurde und dabei Notrufe, Not-SMS, Signalstärken, Akkustände und Aktivitäts-Logs fehlen, warum das Handy trotz 40% Akku unsinnig schnell ausgeschaltet wurde sowie was bei dem einstündigen Betrieb am 11. April damit gemacht wurde, um eine "unmögliche" Datenlage zu produzieren.
Und das ist nur der digital-forensische Teil, ungeklärte Sachverhalte und offizielle Forderungen zu Nachermittlungen gab es ja auch in anderen Bereichen. Der Fall wurde mE zum Cold Case, weil die StA eine zu frühe und unfundierte Abschlussbewertung durchgesetzt hat, ohne neue Fakten zu berücksichtigen und auszuermitteln.
Wie u.a. auch eine neue Timeline oder auffallend unterschiedliche Verwesungszustände, trotz extrem schneller Skelettierung bei beiden. Was bei anzunehmenden unterschiedlichen Bedingungen (Wasser=langsamere Verwesung, Luft) und im Vergleich zB zu Cody Dial (zum selben Zeitpunkt wie K+L im Regenwald verstorben, nur auf der anderen Seite der Grenze in Costa Rica), dessen Skelett nach 2 Jahren noch fast vollständig intakt war, eher unplausibel ist.
Eine weitere kleine Sache konnte ich nun auch klären. Notrufe über die Notruffunktion werden definitiv geloggt, auch wenn das Handy nicht initial entsperrt wurde. Die Notruffunktion nimmt nur Notrufnummern an, wie 112 oder 911. Bisher hatte ich nur Fantasienummern getestet und die wurden nicht geloggt bzw. nur, wenn man über den Taschenrechner-Bug den SIM-Pin eingegeben hat (was ein weiterer Bug ist, dass dann alle Nummern gehen).
Jetzt hab ich den Bruchteil einer Sekunde :-) die 911 getestet und das wurde sofort geloggt. Somit ist die bisher geschlussfolgerte Annahme bewiesen, dass der RAM/NAND-"Bug" bei Notrufen keine Rolle spielt und nach dem letzten Notruf am 3. April bis zum 11. April trotz neunmaligem Booten kein Notruf-Versuch mehr erfolgte. Für Not-SMS gilt das sowieso, weil es keine Quick Reply Funktion auf dem Lockscreen gab.
