Forensische Investigation - iPhone

:note: 02.09.2024 | Update 20.11.2024

New facts and findings (technically validated by field tests) regarding the Panama case of Kris and Lisanne, in a nutshell:

• **iOS 7 RAM/NAND Flash Bug** Shutting down the iPhone without ever entering the unlock code will erase all Powerlogs (including signal strength, battery level, Control Center app activities, etc.) generated during that lock screen session. There will be no entries in the log files CurrentPowerlog.powerlog or powerlog.gz; only boot logs (such as "Starting Up") are stored in the NAND flash (in the log file lockdownd.log). When shutting down immediately after unlocking, the same Powerlogs (from the longer lockscreen session, 20 seconds +) are retroactively stored in the NAND flash.
• The **iOS 7 Control Center Bug** allows users to enter the SIM PIN (e.g. for signal checks) without first entering the iPhone unlock code, which would be an unusual and illogical use.
• 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.
• The data situation on April 11 can only be explained by the **iOS 7 RAM/NAND Flash Bug**, which was unknowingly triggered by K+L or someone who found the iPhone. Otherwise, foul play must be involved, possibly during a DFU mode session or when attempting to exploit known vulnerabilities.
• The last real measured (not logged) signal strength was -94 dBm on April 1 at approx. 1:26 PM.
• Invalid logged signal strength values (-94 dBm, 1 Bar) clearly indicate freeze logs (display shows "Searching" or "No Service") on April 1 from 1:38 PM.
• Invalid logged signal strength values (-113 dBm, 1 Bar) clearly indicate dummy logs (display shows "Searching" or "No Service") on April 2 and 3.
• The iPhone unlock code was correctly entered on April 6 at 10:26 AM (at all other times without power logs this cannot be verified because this action is not recorded in the boot logs). - This confirms that the touchscreen was fully operational on April 6. [The snapshots automatically created by iOS 7, such as on April 6 at 10:27 AM, are screenshots that Apple calls "snapshots". The images are used for the fade-out effect when exiting an app and by the App-Switcher, which is accessed by double-clicking the Home button.]

Basically, power logs confirm that the iPhone has been used for more than one minute. The absence of power logs confirms the opposite.

For all iPhone usage without power logs (April 3, 11:46 AM and from April 4 onward), it cannot be assumed that the corresponding power logs are merely undocumented in the NFI report because, if this were the case, it would not have been necessary to estimate the battery level from April 4 onward.



Hier dokumentiere + update ich die Vorgehensweise und Ergebnisse meines kleinen iPhone-Feldtests im Zusammenhang mit dem Fall:
Das rätselhafte Verschwinden von Kris Kremers & Lisanne Froon

Generell geht es um die forensische Untersuchung eines iPhone 4 mit Root-Rechten, insbesondere in folgenden Bereichen:

• Bootlogs enthalten Realtime-Infos zB über die Startzeit oder die richtige Eingabe des SIM-Pins
• Powerlogs sind Betriebslogs und liefern Echtzeit-Daten zB zu Akkuwerten, Signalstärke-Werten oder App-Nutzungen
• Automatische System-Snapshots (Screenshots) von Benutzeraktivitäten
• SQLite-Datenbanken mit Anrufprotokollen, E-Mails etc.
• Warn-, Crashreports
• DFU-Mode

Testgerät 1: iPhone 4 - Modell A1332 - A4 CPU / GPU-Chip - Firmware: iOS 7.0.6
Testgerät 2: iPhone 4S - Modell A1387 - A5 Dual-Core CPU / GPU-Chip - Firmware: iOS 7.0.6 (Dualboot mit iOS 9)

Alle Tests werden mit Gerät 1 durchgeführt, da dieses meinen Recherchen zufolge Kris' Hardware- / Firmware-Kombination entspricht (ggfs. Akte, IMEI-Check, Log- / Performance-Unterschiede). Gerät 2 dient Plausibilitäts-Tests. iOS 7 ist jeweils weitgehend auf Standardeinstellungen belassen. Ausnahmen: WLAN aus, Bluetooth aus, Mobile Daten aus, Dual 2G / 3G mal aus mal an, Ortungsdienste (GPS) aus (obwohl bei Kris eher an, da von div. Apps verlangt), iCloud-Sync aus, Code-Sperre ein, SIM-Pinschutz ein

Das iPhone 4 hat einen Kompass sowie Drei-Achsen-Gyroskop und Accelerometer. Bewegungsdaten konnten aber erst mit stromsparenden Motion Coprozessoren (verbaut ab iPhone 5) im Hintergrund erfasst und geloggt werden.

Funkloch-Simulation: Alufolie

+++ iOS 7 Bugs - RAM / NAND-Flash & Kontrollzentrum +++

Beide "Bugs" sind auch in der finalen iOS 7 Firmware (7.1.2) vorhanden und daher offenbar beabsichtigt bzw. Features. ^^

Bug 1 - RAM / NAND-Flash

Wie unter Punkt I - Timing beschrieben beginnt das Logging der Powerlogs ab einer Betriebszeit von ~1:05 Minute. Ist das iPhone zB 1 Stunde in Betrieb, entstehen mehrere hundert Realime-Powerlogs.

Jedoch loggt iOS 7 die Powerlogs ins volatile RAM, solange das Handy noch nicht entsperrt ist. Nach einer Stunde Betrieb passiert dann Folgendes:







iPhone wird entsperrt (Eingabe Entsperr-Code, Wechsel vom Lockscreen auf den Homescreen)

• Die paar hundert Realtime-Powerlogs werden vom volatilen RAM quasi rückwirkend und persistent ins NAND-Flash geschrieben. Neue Powerlogs werden danach in Realtime direkt ins NAND-Flash geloggt.

iPhone wird nicht entsperrt, sondern ausgeschaltet (Heruntergefahren)

• Die paar hundert Realtime-Powerlogs im volatilen RAM werden nicht ins NAND-Flash übertragen, sondern verschwinden in Apples Bermuda-Dreieck. ^^ .. Ergebnis: Keine Powerlogs, trotz 1 Stunde Handynutzung.

Der iOS 7 RAM / NAND-Flash Bug hat absolut nichts mit irgendeiner iPhone-Einstellung zu tun. Insofern das Handy per Code geschützt ist, tritt dieser Bug immer auf. Nachweislich produziert iOS 7 beim längeren Verbleiben auf dem Lockscreen (mit oder ohne Nutzung der Apps des Kontrollzentrums) Powerlogs, die ohne erstmalige Eingabe des Entsperr-Codes beim Ausschalten (Herunterfahren) verworfen werden. Gibt man den Entsperr-Code nach längerem Verbleiben auf dem Lockscreen ein und schaltet das Handy direkt danach aus, werden dieselben Logs dagegen gespeichert.


Bug 2 - Kontrollzentrum

Ruft man bei gesperrtem Handy das iOS 7 Kontrollzentrum auf und tippt dann auf Uhr oder Taschenrechner, dann kann man den SIM-Pin eingeben und erhält (bei Netz) sofort Empfangs-Dots und verpasste Anrufe und Nachrichten auf den Sperrbildschirm. .. Dieser Bug erlaubt (geringfügig) schnellere und echte Signalchecks sowie Nachrichtenabrufe, ohne das Handy zuvor entsperrt zu haben bzw. ohne sich den Entsperr-Code merken zu müssen oder diesen zu kennen.

In Kombination ergeben dieses beiden Bugs einen "Interpretations-Spielraum" hinsichtlich der fehlenden Powerlogs und der Punkte I, II und III. Als übertriebenes Beispiel und unter Vorbehalt (forensische Suche nach verdächtigen Datei-Timestamps an allen Tagen) erlaubt die bekannte Datenlage im Zusammenhang mit der Bug-Kombi zB folgendes Handyverhalten (gilt sinngem. auch für einen mögl. Täter): Spoiler
4. April 13:42 Uhr

• Kris schaltet iPhone ein und macht ne halbe Stunde echte Signalchecks
• Handy geht in Standby
• Um 19 Uhr macht sie erneut ne halbe Stunde echte Signalchecks
• Außerdem nutzt sie im Dunklen die Taschenlampe
• Verpasste Anrufe und SMS würden bei Netz automatisch in der Mitteilungszentrale auftauchen (Standardeinstellung)
• Um 20 Uhr schaltet sie das iPhone aus
• Powerlogs: Keine, Forensische Ausschaltzeit: Nonsens
• :achtung: Keine (nicht geloggten) Notrufversuche möglich (siehe Punkt VII) und keine Signalchecks ab 5.April 13:37 Uhr (kein SIM-Pin)

Isoliert betrachtet kann der RAM / NAND-Flash Bug Einfluss auf die nicht vorhandenen Powerlogs bzw. die Betriebszeiten am 5.April 13:37 Uhr, 6. April 14:35 Uhr und 11. April haben. Am 11. April sogar technisch zwingend, falls kein FP vorliegt. Plausibilitätstabelle




File System Events

Um festzustellen, ob jede Nutzung Systemspuren hinterlässt, habe ich das iPhone auf den 2. Juni gestellt, abgewartet bis zum 3. Juni, dann gebootet, 7 Minuten ohne Entsperren auf dem Lockscreen belassen und wieder heruntergefahren:



Ergebnis: Jede Nutzung (außer im DFU-Mode) hinterlässt mind. 2 versteckte Dateien in 2 versteckten Ordnern, deren Timestamps exakt auf die Sekunde genau die Ausschaltzeit zeigen.

:achtung: Die Bugs (insbesondere RAM / NAND-Flash) und der "Hidden Files"-Sachverhalt (sekundengenauer Ausschaltzeitpunkt) sind im NFI-Bericht mWn. nicht dokumentiert. Obwohl es kaum bessere technische Ansätze gab, FP nachzuweisen oder zu relativieren.

Fallrelevanz:
Bei jeder Nutzung ohne (und mit) Entsperren des Handys werden beim Ausschalten mind. 2 Systemdateien erstellt. Außerdem verbleiben vom Tag der letzten Handynutzung weitere Systemdateien bzw. entsprechende Timestamps. Das könnte insgesamt (mit dem RAM / NAND-Flash Bug) die Datenlage der einstündigen Nutzung am 11. April erklären, wo zwar ein "Starting Up"-Log existiert, aber keine Powerlogs. Genau genommen gibt es keine andere technische Erklärung für den 11. April, insofern das iPhone nicht im DFU-Mode manipuliert wurde.

Bei den anderen Tagen käme es darauf an, ob die Forensiker bzw. deren Tools die Hidden Files erkannten oder die Ausschaltzeit am 11. April anhand anderer, nicht versteckter Dateien ermittelt haben. Im ersten (aus professioneller Sicht anzunehmenden) Fall bleibt es trotz der Bugs bei unsinnig kurzen Betriebszeiten am 3. April 11:46 Uhr und vom 4. bis 6. April. Zu diesen Zeitpunkten ist als Ausschaltzeit immer 1 Minute nach der Einschaltzeit dokumentiert (inkl. 45 Sek. Bootzeit).

I - Dokumentation & Timing eines Ein- / Ausschaltvorgangs

Das angegebene Timing ist exemplarisch. Je nach Background-Apps, Akkustand, Temperatur und Laune des iPhones differieren die Zeiten im Bereich von ~5-10 Sekunden. :| = Powerlogging bereits begonnen

Vorgang	iPhone 4	iPhone 4S
Einschalten	00:00	00:00
"Starting Up"-Log (erster Boot-Log)	00:25	00:10
Lockscreen	00:45	00:25
Bedienbar / Ausschaltbar	00:50	00:25
Homescreen nach Eingabe Entsperr-Code+SIM-Pin	00:58	:|
Anzeige Empfangs-Dots / Provider	01:03	:|
Logging-Beginn Powerlog (Signalstärke, Akku etc.)	01:05	00:30
Anzeige "Kein Netz" im Funkloch (+ 30 Sek.)	:|	:|
Max. Nutzbarkeit bei nicht existenten Powerlogs	15 Sek.	5 Sek.

Bestimmung der Ausschaltzeit:

• ~40 Sek. nach dem "Starting Up"-Log (wenn keine Powerlogs und kein SIM-Pin-Log vorhanden)
• ~5 Sek. nach Loggen einer korrekten SIM-Pin-Eingabe (wenn keine Powerlogs vorhanden)
• ~5 Sek. nach dem letzten Powerlog-Eintrag (falls kein Standby / Sleep)
• oder anhand versteckter Systemdateien (siehe iOS 7 Bugs)

Im Funkloch sucht das iPhone ca. 30 Sekunden (Status "Suchen ..") bis die Anzeige "Kein Netz" in der Statusbar erscheint. Nur bei gutem Netz ist der Signalcheck bzw. die Verbindungsherstellung zum Funkmast in 5-10 Sekunden abgeschlossen. Zum Ausschalten ist ein Swipen erforderlich, daher kann das iPhone am 11. April nicht auf einen Stein gefallen sein o.ä. und sich dabei quasi selbst ausgeschaltet haben.

Fallrelevanz:
Unsinnig schnelles Ausschalten und für einen Signalcheck nicht ausreichende Betriebszeit am 3. April, 11:46 Uhr und vom 4. bis 6. April. Technische Begründung: Nicht existente Powerlogs für diese Zeiträume. :achtung: .. siehe iOS 7 Bugs ..

Ab dem 5. April 13:37 Uhr macht ein Signalcheck natürlich sowieso keinen Sinn, da kein SIM-Pin mehr eingegeben wurde. Statt "Suchen .." oder "Kein Netz" steht dann nur "SIM gesperrt" in der Statusbar. Auch ein reiner Zeitcheck ist nicht plausibel, da dazu weder die Eingabe der SIM-Pin (bis 5. April) noch die des Entsperr-Codes (6. April, siehe Punkt V) nötig ist. Ebenso ist es Blödsinn anzunehmen, das iPhone bzw. die Uhrzeit wäre als Kompass verwendet worden. Spoiler
Abgesehen davon, dass K+L wohl kaum Survival-Wissen hatten und das iPhone eine leicht zu findende Kompass-App als Standard besitzt (deren Nutzung geloggt wird und demzufolge nie ausprobiert wurde), macht es keinen Sinn 2x am Tag "Süden" festzustellen, wenn man sich nicht bewegt. Bewegt man sich doch, wird die Sonne nicht mehr im selben Winkel bzw. zu ähnlichen Zeiten durchs Blätterdach scheinen. Außerdem ist es im dichten Dschungel ohne Sichtlinie und Machete sinnfrei punktuell "Süden" zu bestimmen, wenn man eh nur einem Pfad oder Flussbett folgen kann.

Bestätigt ViP / Franciscos Feldtest (Apple-Experte).

II - iOS 7 Kontrollzentrum & Einstellung Dual 2G (GSM) / 3G (UMTS)

Am 2. April wurden auf dem iPhone ein oder zwei Systemeinstellungen verändert:



(1) Die Dualnutzung der 2G (GSM) und 3G (UMTS) Netztechnologie
Einen Test bzgl. des Geschwindigkeitsunterschieds bei der Netzsuche spare ich mir (3G wurde eh 2021 abgeschaltet). Grundsätzlich weist 2G (GSM) die bessere Reichweite und einen geringeren Stromverbrauch auf. In den Powerlogs sieht der Unterschied so aus:

2G

09/02/24 00:03:36 [Telephony] current_rat=GSM; preferred_rat=GSM; [..]


2G / 3G Dual

09/02/24 00:03:54 [Telephony] current_rat=Dual; preferred_rat=UMTS; [..]


(2) Das in iOS 7 neu eingeführte Kontrollzentrum wurde auf dem Lockscreen verfügbar gemacht, was der iOS 7 Standardeinstellung entspricht, sodass man die Funktionen (Flugmodus, WLAN, Bluetooth, Nicht stören, Ausrichtungssperre, Helligkeit) und Apps (Musikplayer, Taschenlampe, Weltuhr / Wecker / Stoppuhr / Timer, Rechner, Kamera) auch ohne Eingabe eines Entsperr-Codes nutzen kann. Uhrzeit, Kamera und Notruf stehen immer ohne ein Entsperren zur Verfügung.

:achtung: Es ist möglich, dass Kris Einstellung (2) nur überprüfte, aber nicht änderte, sondern in Standardeinstellung beließ. Die Nutzung der Taschenlampe wird nicht geloggt.

Lt. meinen Recherchen hatte und nutzte Kris GSM-Roaming (Telefon / SMS), aber kein GPRS / UMTS Datenroaming. (ohne GSM-Roaming keine Signalstärke-Werte, Telefon-Kontakt Miriam)

Fallrelevanz:
Das iOS 7 Kontrollzentrum in einer Notlage zusätzlich auf den Sperrbildschirm zu verlegen macht nur für einen Refresh der Netzsuche per Flugmodus (SIM-Pin nötig) oder einen schnellen Zugriff auf die Taschenlampe Sinn, da die Uhrzeit groß auf dem Lockscreen steht. Die Taschenlampe wurde aber, falls überhaupt, nie länger als 15 Sek. tagsüber im Hellen benutzt. :achtung: .. siehe iOS 7 Bugs ..

Eine 2G / 3G Umstellung zwecks absichtlicher Verlangsamung der Netzsuche (durch einen Täter) halte ich für abwegig. Plausibler als Grund sehe ich die Hoffnung auf größere Chancen beim Netzempfang, auch wenn das technisch keinen Sinn macht.

III - Handy Entsperr-Code & SIM-Pin

Das iPhone loggt jede richtige Eingabe des SIM-Pins (wodurch der Versuchszähler genullt wird), was nach dem 5. April morgens nicht mehr passiert ist. Gäbe es danach noch eine Falscheingabe, wäre das im Versuchszähler direkt auf der SIM-Karte gespeichert worden und auch bei nur einem falschen Versuch (max. 3 möglich) für die Forensiker ersichtlich gewesen.

Log bei gesperrter SIM-Karte

Fri Aug 9 09:29:24 2024 pid=54 (0x3c42018c) determine_activation_state_old: SIM status: kCTSIMSupportSIMStatusPINLocked


Log bei richtiger SIM-Pin-Eingabe

Fri Aug 9 09:30:37 2024 pid=54 (0x3c42018c) determine_activation_state_old: SIM status: kCTSIMSupportSIMStatusReady


Lt. Romain C (Quelle unten) steht im NFI-Report eine Zahl von 74 Handy-Neustarts seit dem 31.7.2013. Davon wurde der SIM-Pin nur 4x nicht eingegeben, nämlich ab dem 5. April mittags.

Vom 6. April wissen wir, dass da der Handy-Entsperr-Code richtig eingegeben wurde (siehe Punkt V). Außerdem gesichert zu allen Zeitpunkten einer richtigen SIM-Pin-Eingabe (bis einschl. 5. April morgens), denn diese Abfrage



erscheint nur bei zuvor entsperrtem Handy. :achtung: .. siehe iOS 7 Bugs ..

:achtung: Die richtige Eingabe des Handy-Entsperr-Codes wird nicht in den Bootlogs geloggt. Es bleiben also nur die hier genannten indirekten Beweise und bei jedem Entsperren ab ~01:05 Minuten Betriebszeit entsprechende Powerlogs. Update: Die richtige Eingabe des Entsperr-Codes lässt sich lt. ersten Tests indirekt über den security.log ableiten. Beitrag von Outback (Seite 4)

Fallrelevanz:
Es gab nie eine falsche Eingabe des SIM-Pins, sondern 4 Nichteingaben, was für Kris als Benutzerin ungewöhnlich wäre. Der Benutzer / die Benutzerin am 6. April kannte und nutzte den Handy-Entsperr-Code.

IV - Signalstärke

Datum	Uhrzeit	Signalstärke	Statusbar / Dots	Bemerkung	Modus
1. April	11:05	-82 dBm	* * * * *	Einschalten des iPhones	Boot
1. April	13:16	-89 dBm	* * * *	Mirador	Standby / Aktiv
1. April	13:17-13:37 *	-94 dBm	Display aus	Letztes gemessenes Signal vor Funkloch=Freeze-dBm	Standby (no Log)
				Ab hier loggt iOS7 falsche Werte (nicht real gemessen)
				Freeze-Logs bei Aktivität im Funkloch
1. April	13:38	Funkloch	Suchen/Kein Netz	Freeze-Log: -94 dBm; bars=1	Standby / Aktiv
1. April	16:39	Funkloch	Suchen/Kein Netz	Freeze-Log: -94 dBm; bars=1	Standby / Aktiv
1. April	16:40	Funkloch	Suchen/Kein Netz	Freeze-Log: -94 dBm; bars=1	Standby / Aktiv
				Dummy-Logs nach Booten im Funkloch
2. April	08:13	Funkloch	Suchen/Kein Netz	Dummy-Log: -113 dBm; bars=1	Boot
3. April	09:33	Funkloch	Suchen/Kein Netz	Dummy-Log: -113 dBm; bars=1	Boot
3. April	16:00	Funkloch	Suchen/Kein Netz	Dummy-Log; -113 dBm; bars=1	Boot

* Für den Zeitpunkt der letzten realen Messung hinter dem Mirador bei bidirektionaler Netzverbindung (dBm-Wert volatil im RAM gespeichert, nicht persistent auf NAND-Flash, nicht geloggt) gibt es mehrere Varianten:
(1) Netz war sofort weg = 13:17
(2) Netz war nach 8 Minuten weg = 13:25 (am wahrscheinlichsten)
(3) Netz war von 13:20 bis 13:35 weg und dann noch mal 2 Minuten da = 13:37


iOS 7 verhält sich bzgl. des Loggens der Signalstärke wie folgt:

Netz vorhanden

• Im Betrieb (Display aktiv) wird die Signalstärke lfd. gemessen und regelmäßig geloggt
• Im Standby (Display inaktiv, Sleep-Modus) wird die Signalstärke lfd. gemessen und je nach Bewegung regelmäßig bis sporadisch (alle ~10 Min.) geloggt

:achtung: Beim Übergang ins Funkloch wird die letzte gemessene Signalstärke (bei vorhandener bidirektionaler Netzverbindung) eingefroren (Freeze-dBm).

Funkloch

• Bei Aktivität oder Wake-Events im Standby wird die falsche Signalstärke (Freeze-Log) geloggt
• Nach Booten des Handys im Funkloch wird eine Dummy-Signalstärke geloggt (-113 dBm)

Man könnte das iPhone also zB auf dem Mirador in Alufolie einwickeln, mit einem Hubschrauber nach Amsterdam fliegen und das iPhone dort in einem Funkloch aus der Alufolie befreien. Es würde den letzten real gemessenen Wert (Freeze-dBm) vom Mirador weiterloggen (Freeze-Log). Startet man es in Amsterdam im Funkloch neu, würde es -113 dBm (Dummy-Log) loggen.

Test-Protokolle:

Freeze-Logs Flugmodus an

09/02/24 10:26:41 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=GSM; call_status=Inactive; airplane_mode=off; signal=-73 dBm; bars=4;

[.. Freeze-Logs ..]
09/02/24 10:34:04 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=on; signal=-77 dBm; bars=1;
09/02/24 10:37:28 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=on; signal=-77 dBm; bars=1;
09/02/24 10:37:58 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=on; signal=-77 dBm; bars=1;

09/02/24 10:38:12 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=GSM; call_status=Inactive; airplane_mode=off; signal=-68 dBm; bars=5;



Freeze-Logs Alufolie-Funkloch Standby

08/11/24 19:22:45 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=GSM; call_status=Inactive; airplane_mode=off; signal=-63 dBm; bars=5;

[.. Alufolie im Sleep-Modus ..]

[.. Freeze-Logs ..]
08/11/24 19:58:43 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-65 dBm; bars=1;
08/11/24 20:54:15 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-65 dBm; bars=1;
08/11/24 21:28:35 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-65 dBm; bars=1;

[ .. ]

08/11/24 21:36:05 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=GSM; call_status=Inactive; airplane_mode=off; signal=-76 dBm; bars=5;



Freeze-Logs Alufolie-Funkloch Aktiv

08/09/24 17:05:03 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=GSM; call_status=Inactive; airplane_mode=off; signal=-70 dBm; bars=5;

[.. Alufolie bei Display an ..]

[.. Freeze-Logs ..]
08/09/24 17:05:15 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-100 dBm; bars=1;
08/09/24 17:09:05 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-100 dBm; bars=1;
08/09/24 17:14:28 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-100 dBm; bars=1;

[ .. ]

08/09/24 17:15:10 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=GSM; call_status=Inactive; airplane_mode=off; signal=-72 dBm; bars=5;



Dummy-Logs Booten im Funkloch

[.. Alufolie ..]

08/10/24 11:37:25 [Log] state=booting; existingLogdate=<unknown>; periodStart=<unknown>; rolloverDate=<unknown>; rotatePowerlogKey=Default; loggingMode=Lite; binary=aggregated; pid=28;

[.. Dummy-Logs ..]
08/10/24 11:37:25 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-113 dBm; bars=1;
08/10/24 11:37:33 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-113 dBm; bars=1;
08/10/24 11:39:27 [Telephony] current_rat=GSM; preferred_rat=GSM; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-113 dBm; bars=1;



Fallrelevanz:
Die letzten sechs dokumentierten Signalstärke-Werte des iPhones (ab 1. April 13:38 Uhr) sind falsch / bedeutungslos bzw. bedeuten alle dasselbe, nämlich "Funkloch". Der Ort des ersten Notrufs muss keinesfalls nahe des Miradors gewesen sein. Ein Rückweg von Q1 über den Mirador ist unter normalen Umständen ausgeschlossen, weil die Signalstärke bei Netzempfang im Standby regelmäßig bis sporadisch (alle ~10 Min.) geloggt wird.

V - Snapshots

Bei Nutzung von iOS 7 Apps erstellt das System automatische "Last-State"-Snapshots (Screenshots) der letzten Aktivität des Benutzers in der jeweiligen App. Das können angefangene SMS sein, die Änderung / Überprüfung einer Einstellung (wie am 2. April Kontrollzentrum), der Aufruf eines Kontakts im Telefonbuch (wie am 3. April Kontakt Miriam) oder der Aufruf der Uhr-App (wie am 6. April) .. und noch viele Aktivitäten mehr. Bei der nächsten App-Nutzung wird der letzte "Last-State"-Snapshot dieser App überschrieben. Der Sinn der "Last State"-Snapshots ist die Erstellung eines aktuellen Bildes für den Fade-Out Effekt beim Verlassen einer App und für die Anzeige im App-Switcher (Doppelklick auf Homebutton).



So sah das zB beim Aufruf der Uhr-App am 6. April um 10:27 Uhr aus:



Wird die Uhr-App direkt vom Lockscreen aus via Kontrollzentrum aufgerufen (ohne Eingabe Entsperr-Code), erfolgt keine automatische Erstellung eines Snapshots. Last-State-Snapshots werden also nur bei App-Aktivitäten erstellt, die nach richtiger Eingabe des Entsperr-Codes vom Homescreen aus initiiert werden.

:achtung: Die Nutzung sämtlicher Apps wird nur dann zusätzlich in den Powerlogs geloggt [Application], wenn das Realtime-Powerlogging begonnen hat (iPhone 4 ab ~01:05, iPhone 4S ab ~00:30).

Fallrelevanz:
Alle 3 Snapshots können in irgendeiner Form fallrelevant sein, aber besonders ist der Aufruf der Uhr-App am 6. April um 10:27 Uhr, weil man daraus die unmittelbar zuvor erfolgte richtige Eingabe des Handy-Entsperr-Codes ableiten kann. U.a. beweist das eine unsinnige Nutzung (Uhrzeit steht groß auf Lockscreen, Ausschalten nach max. 15 Sek.) und ein intaktes Gerät mit reagierendem Touchscreen am 6. April.

VI - Defekte, Warnungen und Crash-Reports

Hier viel zu schreiben lohnt nicht, da das iPhone am 6. April intakt war (siehe Punkt V).

Bei Überhitzung, Akku-Problemen, Boot-Fehlern, Systemabstürzen gibt es Warn- und Crashreports. Exemplarisch zeige ich hier einen Boot-Failure-Crashreport, der bei Hängen des Geräts (Boot nur bis Apple-Logo) oder bei Abschalten während des Bootens erstellt wird und einen Low Battery Log bei einem Akkustand < 10%:

Boot-Crash
{"os_version":"iPhone OS 7.0.6 (11B651)" [..]
Incident Identifier: [..]93BD-54C4578DC834
CrashReporter Key: [..]ab68c570ab9860bdaf6fc
Date: 2024-08-14 19:59:20 +0200
Boot failure count: 1
Boot faults: wdog wdog
Boot stage: 47
[..]

Low Battery
LowBatteryLog
bug_type 120
Incident Identifier: [..]EE-7773390B021F
CrashReporter Key: b02a889d[..]860bdaf6fc
Date: 2024-09-11 01:18:27 +0200
OS Version: iPhone OS 7.0.6 (11B651)
[..]
Voltage: 3194 mV


Ein (moderat) aufgeblähter Akku wurde festgestellt. Hauptgründe wären äußere Einflüsse (Beschädigungen) und Tiefentladung. Normal funktioniert das iPhone aber trotzdem. Teildefekter Touchscreen und Wasserschaden sind aufgrund des 6. Aprils eh schon abwegig. Zudem hat das iPhone 4 an der Lade- und Kopfhörerbuchse zwei eingebaute Flüssigkeitssensoren (LCI), die anzeigen, ob das Gerät mit Wasser (nicht Feuchtigkeit) in Berührung gekommen ist.

Fallrelevanz:
Fallrelevante und forensisch nicht erkannte / dokumentierte Defekte sind eher unwahrscheinlich. Nach der Nutzung am 11. April dürfte der Akku noch einen Ladestand von mind. ~5-10% gehabt haben, da kein Low Battery Report existiert, was gleichzeitig ein aktives Ausschalten (oder ein vollständiges Entladen im DFU-Mode) beweist.

VII - DFU-Mode

Automatic SSH iPhone ramdisk

Externer Inhalt
Durch das Abspielen werden Daten an Youtube übermittelt und ggf. Cookies gesetzt.

Normal-Mode, Wiederherstellungs-Mode, Low Level DFU-Mode
SSH-Ramdisk, Forensic Ramdisk, spurenloser Zugriff ohne Jailbreak + Entsperr-Code

Im DFU-Mode verhält sich das iPhone so, als wäre der Akku leer (Display aus, Gerät nicht einschaltbar). Durch Akkuwechsel oder bei leerem Akku beendet sich der DFU-Mode automatisch. Bei einem vollständigen Entladen im DFU-Mode wird kein Low Battery Report generiert.

Ramdisk-Zugriff im DFU-Mode


SSH-Zugriff per Ramdisk


SQ-Lite Datenbank Call History


Die Notrufversuche mit der Nummer *0* wurden ohne Entsperrcode über die Notruf-Funktion auf dem Lockscreen getätigt (danach Handy heruntergefahren), *3* bei entsperrtem Handy.

Fallrelevanz:
Der RAM / NAND-Flash Bug verhindert zwar das persistente Speichern von Powerlogs, wenn das iPhone ohne Entsperren heruntergefahren wird, aber nicht das Loggen von Notrufversuchen in der Call-History Datenbank. Daher gab es ab 3. April mittags keine Notrufversuche mehr, auch nicht via Ausnutzung der Bugs.

Daneben wäre der DFU-Mode natürlich perfekt geeignet für Schnüffelei und Manipulation.

VIII - Full Logs & rtc-Events

Kommentierte Beispiele der relevanten Boot- und Powerlogs über einen Zeitraum von 2 Stunden im Standby und im Funkloch. Die meisten Werte habe ich eliminiert, man sieht also nur die Log-Kategorie.

Bootlogs

[.. Eingeschaltet 18:25:05 .. ]

Tue Sep 3 18:25:29 2024 pid=55 (0x3a91718c) main: Starting Up

Tue Sep 3 18:25:29 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:29 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:30 2024 pid=55 (0x3a91718c) lockstart_local: Build= 11B651
Tue Sep 3 18:25:30 2024 pid=55 (0x3a91718c)

[.. Produkt-Typ 3.1 = iPhone 4 ..]
Tue Sep 3 18:25:30 2024 pid=55 (0x3a91718c) __get_device_type_internal_block_invoke: product_type: iPhone3,1

Tue Sep 3 18:25:30 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:30 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:30 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:31 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:31 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:31 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:31 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:31 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:38 2024 pid=55 (0x3a91718c) ping_configd: Not setting host name, it already has one: iPhone
Tue Sep 3 18:25:38 2024 pid=55 (0x3a91718c) lookup_baseband_info_old: Inserting baseband version into the data ark
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c) lookup_baseband_info_old: Inserting baseband bootloader version into the data ark
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c) dealwith_activation: No care flag. Looking for a record that matches the SIM.

[.. SIM Karte ICCID (frei erfunden) - Integrated Circuit Card Identifier ..]
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c) dealwith_activation: Looking up the record for ICCID 228672635330891650

Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c) dealwith_activation: No record for the SIM. Looking for wildcard.
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c) determine_activation_state_old: This device is a phone. It supports factory activation.
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c) determine_activation_state_old: The original activation state is WildcardActivated

[.. SIM-Karte Pin geschützt / gesperrt ..]
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c) determine_activation_state_old: SIM status: kCTSIMSupportSIMStatusPINLocked

Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c) deliver_baseband_ticket: SIM is not in operator locked state. Ignoring activation ticket
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x283000) __check_on_identity_block_invoke: identity check
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:39 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:40 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:40 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:40 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:40 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:40 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:40 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:40 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:40 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:25:40 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:08 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c) lookup_baseband_info_old: The SIM status has changed
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c) lookup_baseband_info_old: Inserting an IMSI into the data ark. Triggering an activation check.
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)

[.. SIM-Pin korrekt eingegeben ..]
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c) determine_activation_state_old: SIM status: kCTSIMSupportSIMStatusReady

Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)
Tue Sep 3 18:26:09 2024 pid=55 (0x3a91718c)



Powerlogs

[.. Eingeschaltet 18:25:05 .. ]

09/03/24 18:26:11 [Log] state=booting; existingLogdate=<unknown>; periodStart=<unknown>; rolloverDate=<unknown>; rotatePowerlogKey=Default; loggingMode=Lite; binary=aggregated; pid=28;

09/03/24 18:26:10 [BLM Duet Snapshot]
09/03/24 18:26:10 [BLM Duet Snapshot]
09/03/24 18:26:10 [BLM Duet Info]
09/03/24 18:26:10 [BLM Duet Info]
09/03/24 18:26:10 [BLM Duet Info]
09/03/24 18:26:10 [BLM Duet Info]
09/03/24 18:26:10 [BLM Duet Info]
09/03/24 18:26:10 [BLM Duet Info]
09/03/24 18:26:11 [WiFi Notifications]
09/03/24 18:26:11 [WiFi Module]

[.. Signalstärke Log .. ]
09/03/24 18:26:11 [Telephony] current_rat=Dual; preferred_rat=UMTS; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-113 dBm; bars=1;

09/03/24 18:26:11 [WiFi] status=off;
09/03/24 18:26:11 [Log] state=continue; existingLogdate=09/03/24 00:29:34; periodStart=09/03/24 00:00:00; rolloverDate=09/04/24 00:00:00; rotatePowerlogKey=Default; loggingMode=Lite; binary=aggregated; pid=28;
09/03/24 18:26:11 [Display Info] slider_range=[0,65536]; iDAC_range=[0,2047]; mNits_range=[0,600000]; uAmps_range=[0,25000];
09/03/24 18:26:11 [ProcessMonitor]
09/03/24 18:26:12 [BasebandLoggingConfig]
09/03/24 18:26:11 [Network Usage]
09/03/24 18:26:12 [WiFi Module]
09/03/24 18:26:12 [Accessibility]
09/03/24 18:26:12 [SpringBoard-wallpaper]
09/03/24 18:26:12 [Display] active=yes; brightness=79.0%; user_brightness=<unknown>; als=disabled; mie=off; slider=51777; mNits=0; uAmps=0;
09/03/24 18:26:11 [Locale] timezone_secondsFromGMT=7200;
09/03/24 18:26:11 [Audio] active=NO; route=Speaker; volume=50.0; output_category=Ringtone; muted=NO;

[.. Signalstärke Log .. ]
09/03/24 18:26:12 [Telephony] current_rat=Dual; preferred_rat=UMTS; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-113 dBm; bars=1;

09/03/24 18:26:11 [CoreLocation Client]
09/03/24 18:26:12 [CoreLocation Client]
09/03/24 18:26:11 [WiFi] status=off;
09/03/24 18:26:12 [CoreLocation Client]
09/03/24 18:26:12 [CoreLocation Client]
09/03/24 18:26:12 [CoreLocation Client]
09/03/24 18:26:12 [CoreLocation Client]
09/03/24 18:26:12 [CoreLocation Client]
09/03/24 18:26:12 [CoreLocation Client]
09/03/24 18:26:11 [Battery] level=61.58%; voltage=3741 mV; current=-303 mA; current_capacity=622 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=29.10 C; adapter_info=0; connected_status=0;
09/03/24 18:26:12 [CoreLocation Client]
09/03/24 18:26:12 [CoreLocation Client]
09/03/24 18:26:12 [CoreLocation Client]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [CoreLocation] gps=off; nmea=off; accessory=off; wifi=off; skyhook=off; cell=off; lac=off; mcc=off; gps_coarse=off;
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:11 [Config] version=6.01; build=11B651;
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Network Connections Symptoms]
09/03/24 18:26:12 [Application]
09/03/24 18:26:13 [Battery] level=61.39%; voltage=3718 mV; current=-353 mA; current_capacity=620 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=29.30 C; adapter_info=0; connected_status=0;
09/03/24 18:26:33 [Battery] level=61.29%; voltage=3757 mV; current=-235 mA; current_capacity=619 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=29.60 C; adapter_info=0; connected_status=0;
09/03/24 18:26:53 [Battery] level=61.09%; voltage=3757 mV; current=-234 mA; current_capacity=617 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=29.80 C; adapter_info=0; connected_status=0;
09/03/24 18:26:58 [WiFi Notifications]
09/03/24 18:26:58 [WiFi Notifications]
09/03/24 18:27:14 [Battery] level=60.99%; voltage=3758 mV; current=-239 mA; current_capacity=616 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=30.10 C; adapter_info=0; connected_status=0;
09/03/24 18:27:14 [Network Usage]
09/03/24 18:27:14 [WiFi Module]
09/03/24 18:27:14 [ProcessMonitor]

[.. Signalstärke Log .. ]
09/03/24 18:27:14 [Telephony] current_rat=Dual; preferred_rat=UMTS; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-113 dBm; bars=1;

09/03/24 18:27:14 [WiFi] status=off;
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Battery] level=60.99%; voltage=3758 mV; current=-242 mA; current_capacity=616 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=30.10 C; adapter_info=0; connected_status=0;
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:14 [Network Connections Symptoms]
09/03/24 18:27:30 [Baseband State Durations]
09/03/24 18:27:30 [Baseband State Durations]
09/03/24 18:27:30 [Baseband State Durations]
09/03/24 18:27:34 [Battery] level=60.89%; voltage=3766 mV; current=-205 mA; current_capacity=615 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=30.40 C; adapter_info=0; connected_status=0;

[.. Display aus, Standby ..]
09/03/24 18:27:43 [Display] active=no; brightness=0.0%; user_brightness=<unknown>; als=disabled; mie=off; slider=0; mNits=0; uAmps=0;
09/03/24 18:27:43 [SpringBoard-screens] Screens=0;
09/03/24 18:27:43 [SpringBoard-states] screen_state=blanked; lock_state=locked;

[.. in Alufolie eingewickelt ..]

09/03/24 18:27:54 [Battery] level=60.79%; voltage=3820 mV; current=-69 mA; current_capacity=614 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=30.60 C; adapter_info=0; connected_status=0;
09/03/24 18:28:15 [Battery] level=60.79%; voltage=3842 mV; current=-12 mA; current_capacity=614 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=30.70 C; adapter_info=0; connected_status=0;
09/03/24 18:28:15 [Battery] level=60.79%; voltage=3843 mV; current=-45 mA; current_capacity=614 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=30.70 C; adapter_info=0; connected_status=0;
09/03/24 18:28:21 [Sleep] event=can_sleep;
09/03/24 18:28:21 [Sleep] event=will_sleep;
09/03/24 18:28:21 [ProcessMonitor]
09/03/24 18:28:21 [Baseband] state=recovered;
09/03/24 18:28:21 [Battery] level=60.79%; voltage=3832 mV; current=-80 mA; current_capacity=614 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=30.70 C; adapter_info=0; connected_status=0;
09/03/24 18:28:22 [Powerlog Error] Could not get wake reason (errno: 2)
09/03/24 18:28:22 [LoggedWake] reason=<unknown>;
09/03/24 18:28:22 [Sleep] event=didnot_sleep;
09/03/24 18:28:22 [NoSleepWake] reason=<unknown>;
09/03/24 18:28:22 [Baseband State Durations]
09/03/24 18:28:26 [Sleep] event=can_sleep;
09/03/24 18:28:26 [Sleep] event=will_sleep;
09/03/24 18:28:26 [ProcessMonitor]
09/03/24 18:28:26 [Battery] level=60.79%; voltage=3823 mV; current=-67 mA; current_capacity=614 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=30.70 C; adapter_info=0; connected_status=0;

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

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

09/03/24 19:25:35 [WiFi Module]
09/03/24 19:25:35 [WiFi] status=off;
09/03/24 19:25:35 [WiFi Available]
09/03/24 19:25:35 [WiFi Notifications]
09/03/24 19:25:35 [WiFi Notifications]
09/03/24 19:25:35 [LoggedWake] reason=rtc;
09/03/24 19:25:35 [Baseband State Durations]
09/03/24 19:25:35 [Battery] level=59.60%; voltage=3853 mV; current=0 mA; current_capacity=602 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=28.10 C; adapter_info=0; connected_status=0;
09/03/24 19:25:35 [WiFi Module]
09/03/24 19:25:35 [ProcessMonitor]
09/03/24 19:25:35 [Baseband State Durations]
09/03/24 19:25:35 [Network Usage]
09/03/24 19:25:35 [WiFi] status=off;

[.. Signalstärke Log .. ]
09/03/24 19:25:35 [Telephony] current_rat=Dual; preferred_rat=UMTS; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-113 dBm; bars=1;

09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:35 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:36 [Network Connections Symptoms]
09/03/24 19:25:45 [Sleep] event=can_sleep;
09/03/24 19:25:45 [Sleep] event=will_sleep;
09/03/24 19:25:45 [ProcessMonitor]
09/03/24 19:25:45 [WiFi Module]
09/03/24 19:25:45 [WiFi] status=off;

[.. Sleep ..]
09/03/24 19:25:46 [Sleep] event=did_sleep;

[.. Wake ..]
09/03/24 20:25:24 [Wake] reason=rtc;

09/03/24 20:25:25 [WiFi Module]
09/03/24 20:25:25 [LoggedWake] reason=rtc;
09/03/24 20:25:25 [Baseband State Durations]
09/03/24 20:25:25 [WiFi] status=off;
09/03/24 20:25:26 [WiFi Available]
09/03/24 20:25:25 [Battery] level=58.42%; voltage=3838 mV; current=0 mA; current_capacity=590 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=27.70 C; adapter_info=0; connected_status=0;
09/03/24 20:25:26 [WiFi Notifications]
09/03/24 20:25:26 [WiFi Notifications]
09/03/24 20:25:26 [ProcessMonitor]
09/03/24 20:25:26 [WiFi Module]
09/03/24 20:25:26 [WiFi] status=off;
09/03/24 20:25:26 [Network Usage]
09/03/24 20:25:26 [Network Connections Symptoms]

[.. Signalstärke Log .. ]
09/03/24 20:25:26 [Telephony] current_rat=Dual; preferred_rat=UMTS; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-113 dBm; bars=1;

09/03/24 20:25:26 [Baseband State Durations]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:26 [Network Connections Symptoms]
09/03/24 20:25:30 [Sleep] event=can_sleep;
09/03/24 20:25:30 [Sleep] event=will_sleep;
09/03/24 20:25:30 [ProcessMonitor]
09/03/24 20:25:31 [WiFi Module]
09/03/24 20:25:31 [WiFi] status=off;

[.. Sleep ..]
09/03/24 20:25:31 [Sleep] event=did_sleep;

[.. aus Alufolie befreit ..]

[.. Wake ..]
09/03/24 20:29:17 [Wake] reason=hold;

[.. Display eingeschaltet ..]
09/03/24 20:29:18 [Display] active=yes; brightness=79.0%; user_brightness=<unknown>; als=disabled; mie=off; slider=51777; mNits=0; uAmps=0;
09/03/24 20:29:18 [SpringBoard-screens] Screens=lockscreen;

09/03/24 20:29:18 [WiFi Module]

[.. Signalstärke Log .. ]
09/03/24 20:29:18 [Telephony] current_rat=Dual; preferred_rat=UMTS; camped_rat=Unknown; call_status=Inactive; airplane_mode=off; signal=-113 dBm; bars=1;

09/03/24 20:29:18 [Baseband State Durations]
09/03/24 20:29:18 [WiFi] status=off;
09/03/24 20:29:18 [WiFi Available]

[.. iPhone Code gesperrt .. ]
09/03/24 20:29:18 [SpringBoard-states] screen_state=unblanked; lock_state=locked;

09/03/24 20:29:18 [LoggedWake] reason=hold;
09/03/24 20:29:18 [Baseband State Durations]
09/03/24 20:29:19 [Battery] level=58.32%; voltage=3842 mV; current=-4 mA; current_capacity=589 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=27.70 C; adapter_info=0; connected_status=0;

[.. Entsperr-Code richtig eingegeben .. ]
09/03/24 20:29:24 [SpringBoard-states] screen_state=unblanked; lock_state=unlocked;
09/03/24 20:29:24 [SpringBoard-screens] Screens=homescreen;

09/03/24 20:29:29 [Battery] level=58.12%; voltage=3770 mV; current=-176 mA; current_capacity=587 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=28.20 C; adapter_info=0; connected_status=0;

[.. Ausschalt-Taste 2 Sek. gedrückt 20:29:34 ..]

[.. Swipe-Screen Ausschalten ..]
09/03/24 20:29:36 [SpringBoard-screens] Screens=1;

[.. Letzter Powerlog-Eintrag ..]
09/03/24 20:29:38 [Battery] level=58.12%; voltage=3770 mV; current=-197 mA; current_capacity=587 mAh; raw_max_capacity=1010 mAh; charging_state=Inactive; charging_current=0 mA; battery_temp=28.20 C; adapter_info=0; connected_status=0;

[.. Forensische Ausschaltzeit 20:29:43 ..]
[.. Echt aus 20:29:44 ..]



Am 1. April scheinen für den 3-Stunden Zeitraum vor dem ersten Notruf (13:38 Uhr bis 16:39 Uhr) keine Powerlogs zu existieren. Das iPhone war im Standby bzw. im Sleep-Modus (und im Funkloch). Geloggt wird dann nur bei Aktivität, also Einschalten des Displays. Lt. meinen Tests wachen die iPhones zusätzlich ca. 1x pro Stunde kurz mit dem Grund "rtc" auf und loggen u.a. Signalstärke und Akkustand. Das würde ich auch bei Kris iPhone annehmen, also falsche Signalstärke-Logs (Freeze -94 dBm) um 14:38 Uhr und 15:38 Uhr.

Fallrelevanz:
Der genaue Grund für die rtc-Wakes ist unklar. Fallrelevanz könnte vorliegen, wenn o.g. Annahme zutrifft.

IX - Exkurs Stalking & Jailbreak / Spy-App

Eine illegale Handyüberwachung bzw. Nutzerüberwachung (Stalking) per versteckter Spy-App funktioniert nur bei Internet-Zugang über WLAN, Mobile Hotspot (zB Fremd-Handy) oder mobiles Datenroaming.

Damit könnte man zB den Standort und Bewegungsverlauf abrufen, Telefongespräche mithören, Nachrichten lesen oder das Mikro einschalten, um Vor-Ort-Gespräche zu belauschen. Über einen Jailbreak sind dabei natürlich auch ungeprüfte / zwielichtige Apps möglich.

Die Beschreibung einer Profi-Überwachung via IMSI-Catcher spare ich mir. Das hier angedachte Szenario impliziert ein simples "Unterjubeln" eines Jailbreaks oder einer Spy-App auf dem iPhone, vllt. bereits in Bocas. Dafür braucht es keinen PC oder Mac, es reicht ein 5 Minuten lang verliehenes oder nicht beaufsichtigtes Handy, welches entsperrt ist und Internetzugang hat.

Bemerkbar macht sich das ggfs. im Akku- und Datenverbrauch, durch temporäre Freeze-Zustände oder einer insgesamt schlechteren System-Performance. Selbstverständlich ist so ein Szenario spekulativ, jedoch stellen Jailbreaking und Infiltrationen mit Malware / Spyware grundsätzlich plausible Ursachen für bestimmte Auffälligkeiten dar (u.a. gestörtes oder verzögertes Timing / Logging / Bedienverhalten).

X - Forensic Conclusion

Alle 6 dokumentierten Signalstärke-Werte hinter dem Mirador sind falsch / nicht real gemessen. Ab 1. April 13:38 Uhr zeigte die Statusbar "Suchen / Kein Netz" auf dem Display an. Um 13:38 Uhr befand sich das iPhone bereits im Funkloch, aber noch relativ nahe (max. 20 Min.) eines Ortes mit Netz / des Miradors, zum Zeitpunkt des Notrufs und später irgendwo im Funkloch. Aufgrund des iOS 7 RAM / NAND-Flash "Bugs" gibt es keine (zwingenden) Indizien mehr dafür, dass ein Profi die Logs manipuliert oder den DFU-Mode benutzt hat (bezogen auf fehlende Powerlogs).


Entscheidend dafür, dass überhaupt ein persistenter Signalstärke-Log (egal ob real gemessen, Freeze-Log, Dummy-Log) oder anderer Powerlog (wie Akkustand) erfolgt, ist die erstmalige richtige Eingabe des Handy-Entsperr-Codes und eine Gesamt-Betriebszeit ab Einschalten größer ~1:05 Minute (siehe iOS 7 Bugs und Punkt I). SpoilerManche iPhone 4 starten unfassbar langsam, sodass das Powerlogging erst ab einer Betriebszeit > ~1:40 Minute beginnt. Selbst mit 50 im Hintergrund geöffneten Apps konnte ich das auf meinen iPhones nicht nachstellen. Gründe für so eine schlechte Performance wären zB ein Jailbreak oder eine Überwachungs-App oder andere Gründe. Im Fall K+L muss die Möglichkeit so einer schlechten Performance unbedingt berücksichtigt werden .. auch schon vor dem 1. April!

Was ist ein Signalcheck? Spoiler
Das iPhone einzuschalten und auf die Anzeige "5 Bars" oder "Kein Netz" zu warten ist kein Signalcheck, da das ohne SIM-Pin nicht funktioniert und dauerhaft "SIM gesperrt" auf dem Display erscheint. Notrufe sind trotzdem möglich, weil diese in allen verfügbaren Netzen freigeschaltet sind (mind. bei gültiger SIM-Karte). Erst nach Eingabe des Entsperr-Codes und der SIM-Pin beginnt technisch der individuelle "Roaming-Netz"-Signalcheck, was auf dem Display mit "Suchen .." angezeigt wird und im Funkloch mind. 30 Sekunden dauert. Spätestens wenige Sekunden nach Eingabe der SIM-Pin werden aber bereits Powerlogs generiert.

Deshalb gilt im Fall K+L grundsätzlich: Keine Powerlogs (Akkustand, Signalstärke, etc.) = Keine Signalchecks. Lassen wir die eher unrealistische Nutzung des "Taschenrechner"-Bugs (SIM-Pin Eingabe ohne Handy-Entsperren) außen vor, dann gab es am 3. April mittags sowie ab 4. April keine Signalchecks. Denn entweder stand dann "SIM gesperrt" oder nach Eingabe der SIM-Pin der Status "Suchen .." auf dem Display, aber niemals "Kein Netz". Im ersten Fall kann das iPhone länger eingeschaltet gewesen sein (iOS 7 RAM/NAND-Flash Bug). Im zweiten Fall wurde das iPhone wieder ausgeschaltet, bevor ein Signalcheck ein Ergebnis liefern konnte (was durch fehlende Powerlogs nachgewiesen ist).

:achtung: Lag auf Kris iPhone schon vor dem 1. April ein Performance-Problem vor (wovon ich zu 100% ausgehe!), dann müsste der Grund (Jailbreak, Spy-App, Cache-Problem etc.) im Filesystem gecheckt werden und ob der ganze Boot- und Startvorgang inkl. SIM-Pin Eingabe und Signalcheck verzögert war oder nur der Beginn des Powerloggings ([Log] state=booting;). Das ließe sich u.a. mit dem Timestamp des SIM-Status-Logs (kCTSIMSupportSIMStatusReady, siehe Punkt 3) überprüfen.


Unklar | seltsam / unrealistisch (für selbstbestimmtes Handeln in einer lebensbedrohlichen Notlage) sind::

• Der Ort des erstmaligen Einschaltens am 1. April 11:04 Uhr in Korrelation mit Foto #476 und einer wahrscheinlichen Umfahrung der ersten 500 Meter des Pianista-Trails
• Die letzten Roaming Telefon-/SMS-Kontakte und GPS-Daten
• Scheinbar fehlende Provider-Daten vom Zeitpunkt Pianista- / Mirador-Aufenthalt, auch Auswertung registrierte fremde Handys im Sektor der Funkzelle (Abstrahlwinkel) vom 1. April 11 Uhr bis 3. April
• Stealth Ping Ortungsversuche der Polizei?
• Der Ort und die Aktivität am / ab 1. April 13:38 Uhr


• Die 3 Stunden ohne Powerlogs vor dem ersten Notruf (siehe Punkt VIII) .. plus der hohe Akkuverbrauch des Samsung-Handys in dieser Zeit (19%)
• Die (Nicht-)Nutzung in der Stunde nach dem ersten Notruf (null Akkuverbrauch zwischen 1. April Notruf 16:39 Uhr 42,18% und dem 2. April 8:12 Uhr 42,98%)
• In 11 Tagen wären > 100 Notrufversuche plausibel, da Notrufe in allen Netzen funktionieren, nicht nur wie Signalchecks im Roaming-Partnernetz
• Über 1 Woche lang keine Notrufversuche seit 3. April morgens (siehe Punkt VII), obwohl die Handy-Bedienungen bis 11. April (Tippen, Swipen, Code-/Pin-Eingaben) und die Kamera- / Bastel-Aktionen am 8. April ein intaktes iPhone sowie intakte feinmotorische und intellektuelle Fähigkeiten zeigen
• Unsinnig / lebensfremd kurze Betriebszeiten am 3. April mittags sowie ab 4. April (lt. NFI-Bericht & ohne Berücksichtigung der Bugs)
• Nichteingabe SIM-Pin ab 5. April mittags (= Signalchecks + Anzeige verpasste Anrufe / SMS unmöglich)
• Lebensfremde Bedienung am 6. April 10:27 Uhr (Eingabe Entsperr-Code, Aufruf Uhr-App, Ausschalten nach 15 Sek.)
• Keine Nutzung vom 7. bis 10. April
• Lebensfremde mind. einstündige Nutzung am 11. April ohne Notrufversuche / Signalchecks, aber mit aktivem Ausschalten (oder Verbleiben im DFU-Mode). Alle 18 neu erstellten / geänderten Dateien sind im NFI-Report scheinbar nicht namentlich aufgeführt, ich vermute Systemdateien der letzten Nutzung (Run-States, Pids, Locks, Filesystem-Events etc.).

Befragung einer KI zu den Themen ..

• Handyverhalten, Notruf-Häufigkeit, Psychische Aspekte, Signalchecks, Roaming, Funktionelle Unkenntnis, FP-Wahrscheinlichkeit, Täter-Motive Inszenierung Lost-Szenario statt Kamera- / Handy-Vernichtung .. Beitrag von Outback (Seite 2)
• Ursachen für fehlende Logs .. Beitrag von Outback (Seite 3)

XI - Handy Timeline (beide Handys)

Hier meine (z.T. interpretierte) Timeline relevanter Handy-Aktivitäten am 31. März und 1. April.



Info-Quellen Zeitmarken:
M - Matt, Link unten
R - Romain C, Link unten
V - ViP S. 154-159, 253
A - Anthurium, Beitrag von Anthurium (Seite 3)
S - Schlussfolgerung / Annahme

Bei allen Bewertungen der Test-Ergebnisse gehe ich davon aus, dass die Forensiker des NFI alle wichtigen Daten und Logs aus den DVD-Rohdaten extrahiert und im NFI-Report dokumentiert haben. Und dass Leute mit Kenntnis des NFI-Reports diese Daten erst recht nicht weglassen. Ab 4. April wird der Akkustand vom NFI nur noch geschätzt. Das ist ein weiteres Indiz dafür, dass im NFI-Bericht fehlende (wichtige) Powerlogs auch nicht auf DVD existieren.
Alle Test-Ergebnisse sind auf beiden Testgeräten sinngleich reproduzierbar.


Quellen zu guten anderen / ergänzenden NFI-Report- / Handy-Auswertungen

• Buch / eBook Verschollen in Panama (u.a. iPhone Feldtest) - Autoren: @Doctective @Annju
• Imperfect Plan - Forensische Analyse der Telefondaten (Matt)
• CamilleG - Offizielle Daten der Mobiltelefone (Romain C)

.

InspektorLemon schrieb:Ich würde vermuten, wenn es eine Manipulation gegeben hat, das diese hauptsächlich am 11.04 am Iphone stattfand. Der mögliche Täter hatte bis dahin Zeit sich darüber zu informieren und sich einzulesen, wie man die Daten so verändert, dass es passt. Ein paar Fehler sind ihm unterlaufen (DFU Modus) bzw. er hat nicht damit gerechnet, dass es auffällt, wenn ein paar Powerlogs fehlen, weil er Probleme bei der Darstellung des Akkustandes bekommen hätte.

Eine interessante Sache kommt da noch hinzu:

Der DFU-Mode wird von iOS erstaunlicherweise als Boot Failure erkannt. Der Boot Failure Zähler springt auf 1. Der Crashreport dazu wird aber erst im Juni nach Auffinden des iPhones erstellt, entweder bei einem Funktionstest oder beim "Ziehen" eines 1 zu 1 Images des gesamten NAND-Flashspeichers durch die Forensiker (falls via DFU-Mode). Letzteres würde den Boot-Failure-Zähler auf 2 erhöhen.

Fraglich ist, ob Forensik-Tools Daten aus Juni ausgewertet haben oder nur von April. Ich hätte da leichte Zweifel und eine Ahnung, dass so ein möglicher DFU-Mode-Beweis aufgrund des Juni-Timestamps oder aufgrund eigener forensischer Nutzung des DFU-Modes unerkannt blieb.

Tatsächlich müsste man das Ganze auch andersrum testen, also ob forensische Aktivitäten im Juni Dateien erstellen und ändern konnten, die Timestamps vom 11. April haben. Halte ich nicht für gänzlich ausgeschlossen, weil der NAND-Flashspeicher bei leerem Akku quasi einfriert und das Handy im Juni zunächst (oder bis heute) denkt, es wäre noch der 11. April. Denn für die Aktualisierung von Datum und Uhrzeit braucht es iOS-Routinen, die der Low Level DFU-Mode (von iOS als Bootfehler erkannt) vermutlich nicht bietet. Das wäre die Lost / Unfall Erklärung des 11. Aprils, zumindest ein plausibler Ansatz.

Man sollte aber eigentlich davon ausgehen, dass der NAND-Flashspeicher im Chip-Off-Verfahren bzw. direkt vom Chip ausgelesen und eine 1:1 Kopie erstellt wurde, ohne für diesen Zweck das Handy im DFU-Mode zu booten (obwohl das viele Forensik-Tools erfordern).

Sry dass das ziemlich kompliziert klingt, daher hier. :'D

Also ich habe es verstanden und finde es wie immer sehr interessant. :)

Outback schrieb:Tatsächlich müsste man das Ganze auch andersrum testen, also ob forensische Aktivitäten im Juni Dateien erstellen und ändern konnten, die Timestamps vom 11. April haben.

Das wäre natürlich einerseits eine neue wichtige Erkenntnis, andererseits aber auch ein herber Rückschlag, wenn es darum geht eine Manipulation durch Dritte nachzuweisen. Ich gehe aber auch, wie du davon aus, dass sie den Juni nicht ausgelesen haben, was sehr ärgerlich wäre, aber auch verständlich.

Ich habe es auch verstanden (aber gut ich bin ITlerin).

Deine Nachforschungen sind unglaublich umfangreich und zeigen doch nochmal ganz andere und neue Aspekte.

Outback schrieb:1. April 13:17 - 13:37 -94 dBm letztes gemessenes Signal vor Funkloch = Freeze-dBm Standby

... Das ist sozusagen Deine Schlussfolgerung (oder taucht das irgendwo in öffentlich zugänglichen Dokumenten auf?)

bergfreund schrieb:... Das ist sozusagen Deine Schlussfolgerung (oder taucht das irgendwo in öffentlich zugänglichen Dokumenten auf?)

Richtig, das ist das Ergebnis meiner Tests. Natürlich taucht es nicht in irgendwelchen öffentlichen Dokumenten auf, sonst wären es ja keine neuen Erkenntnisse.

Outback schrieb:sonst wären es ja keine neuen Erkenntnisse.

...ist eben nur auf den zweiten Blick zu sehen weil nicht gekennzeichnet - denn die anderen Zeitmarken sind ja nicht neu

bergfreund schrieb:..ist eben nur auf den zweiten Blick zu sehen weil nicht gekennzeichnet

Das reicht. Sollte ja selbstverständlich sein, dass ich keine neuen Zeitpunkte erfinde. Technisch gesehen gibt es eben einen unbekannten Zeitpunkt, irgendwann zwischen 13:17 und 13:37, wo die reale -94 dBM Messung bei letztmaliger Netzverbindung stattfand.

Bei einem langsamen Einwickeln in Alufolie wäre dieser Wert deutlich schlechter (-108 bis -110 dBm), weil mein Handy in meiner Umgebung immer zum Funkmast zurück funken kann. Schaust du dir Tunnelgänge mit 3-4 Meter hohen Fels-Seitenwänden hinter dem Mirador an, ist klar, dass der Funkmast zwar noch das Handy erreicht, das Handy aber nicht mehr den Funkmast. Daher Freeze / Abbruch schon bei -94 dBm.

...alles verstanden und logisch für mich, ich war nur über die vier aufeinanderfolgenden -94dBm gestolpert (... ich hätte es besser gekennzeichnet so wie eben bei meiner eingefügten Signalstärketabelle damit auch der unbedarfte Leser schneller reinfindet, der zusätzliche Eintrag ist ja genau die entscheidende Stelle - da hättest Du Deine Arbeit durchaus hervorheben können)

bergfreund schrieb:der zusätzliche Eintrag ist ja genau die entscheidende Stelle

Sehe ich nicht so. Alle 6 Stellen dahinter sind genauso entscheidend. Nicht wegen der bekannten Zeitpunkte, sondern wegen den nicht mehr real gemessenen Signalstärke-Werten und den Freeze- und Dummy-Begründungen.

Deine Tabelle besagt ja sogar dasselbe, wie meine Testergebnisse, nur eben ohne technische Erklärung der Freeze- und Dummy-Werte. Aber deine Interpretation ist richtig. Ich verstehe nur nicht den inaktiven Entsperrcode ab 3.4., was bei aktivierter SIM nicht möglich ist.

Outback schrieb:Deine Tabelle besagt ja sogar dasselbe, wie meine Testergebnisse, nur eben ohne technische Erklärung der Freeze- und Dummy-Werte.

Zumindest ist dann 13:17 Uhr der offensichtlich schlechteste Empfang für den gesamten 01.04., wahrscheinlich nach dem Aufenthalt auf dem Mirador dann im " Funkschatten"...

Mit dem inaktivem Sperrcode kann ich bestimmt helfen - dachte ich hatte es vor Wochen schon mal erwähnt, aber finde es jetzt nicht mehr:
Bei meinem iphone 5 ist mit deaktiviertet SIM-Pin (faktisch = permanent aktivierte SIM)

Outback schrieb:Ich verstehe nur nicht den inaktiven Entsperrcode ab 3.4., was bei aktivierter SIM nicht möglich ist.

ein Booten möglich mit einem nachfolgenden 100%-igem Zugriff auf alle Funktionen und Apps ohne dass ich den Entsperrcode vom iphone eingeben muss.
--> Mit iOS: 10.3.4 (14G61)

bergfreund schrieb:Zumindest ist dann 13:17 Uhr der offensichtlich schlechteste Empfang für den gesamten 01.04., wahrscheinlich nach dem Aufenthalt auf dem Mirador dann im " Funkschatten"...

Um 11:49 Uhr haben wir auch bereits Netzverlust. Ich vermute schon ab 11:30 Uhr bis zum Gipfel mit kurzen Unterbrechungen. Daher auch keine sporadisch geloggten Werte im Standby (wobei wir ja von IP wissen, dass es nicht nur die aufgeführten 15 Signalstärkelogs gibt, sondern eher 50).

Hinter dem Gipfel gibt es mehrere Varianten:
(1) Netz war sofort weg = 13:17
(2) Netz war nach 8 Minuten weg = 13:25
(3) Netz war von 13:20 bis 13:35 weg und dann noch mal 2 Minuten da = 13:37

Am wahrscheinleisten ist natürlich (2).

bergfreund schrieb:Bei meinem iphone 5

Öhm .. klingt nach Jailbreak. :'D

Outback schrieb:klingt nach Jailbreak. :'D

...es war mal zur Rep. bei einem Handyservice, könnte natürlich dort gemacht worden sein.

Outback schrieb:Ich verstehe nur nicht den inaktiven Entsperrcode ab 3.4., was bei aktivierter SIM nicht möglich ist.

Vielleicht probierst Du nochmal falls noch nicht durchgeführt beim iphone 4 :

1. SIM-PIN deaktivieren
2. Zeit bis zur Anzeige der Signalstärke-Balken messen beim Booten ( ohne Bildschirm - Entsperrcode einzugeben)
3. Dann Ausschalten
4. Signalstärke im Logfile für Ausschalten vor Anzeige, bei erstmaliget Anzeige und 10 s nach Anzeige der Signalstärke ?

Mit deaktivierter SIM-Pin muss nicht erst der Entsperrcode und danach die SIM-PIN eingegeben werden um die Signalstärke anzeigen zu lassen, --> zumindest nicht beim iphone 13, die Balkenanzeige wird schneller sichtbar.
Mit meinem iphone 5 kann ich das aber ( mit dem Jailbreak) nicht zuverlässig testen.

bergfreund schrieb:2. Zeit bis zur Anzeige der Signalstärke-Balken messen beim Booten ( ohne Bildschirm - Entsperrcode einzugeben)

~5 Sek. (Total 00:50)

Funkloch: ~35 Sek. bis Anzeige "Kein Netz" und Log -113 dBm (Total 01:20)

bergfreund schrieb:Ausschalten vor Anzeige

Keine Powerlogs

bergfreund schrieb:bei erstmaliget Anzeige

Keine Powerlogs

bergfreund schrieb:10 s nach Anzeige der Signalstärke

Keine Powerlogs

Was auch einleuchtet, da das Logging der Powerlogs frühestens bei 01:05 beginnt (siehe Timing oben). Natürlich ist in den Bootlogs und auf der SIM-Karte erkennbar, wenn der SIM-Pinschutz deaktiviert ist.

bergfreund schrieb:Mit meinem iphone 5 kann ich das aber ( mit dem Jailbreak) nicht zuverlässig testen.

Fall du die Cydia-App drauf hast, was ja der Sinn jeden Jailbreaks ist, kannste dir iOS 7.0.6 als Dualboot installieren, falls dein iPhone 5 eh nur noch im Schrank die Rente genießt. :-) Die Timing-Sachen kannste natürlich vergessen, da dein A6-Chip viel zu schnell ist, aber die Powerlogs kannste dir anschauen (nach 2 Min. PN-Instruktion).

Outback schrieb:Der DFU-Mode wird von iOS erstaunlicherweise als Boot Failure erkannt. Der Boot Failure Zähler springt auf 1. Der Crashreport dazu wird aber erst im Juni nach Auffinden des iPhones erstellt,

Warum würde denn der Crashreport erst im Juni erstellt und nicht schon im April bzw. wann gebau erstellt das IPhone so einen Report? Beim Start über DFU-Modus oder beim beenden bzw. Kabel trennen?

@InspektorLemon

Die Frage nach dem Zeitpunkt kann ich beantworten:

Weder beim Start des DFU-Modes noch beim beenden noch beim Kabel trennen, sondern beim nächsten vollständigen Booten. Wurde Kris iPhone nach dem Auffinden nie mehr gebootet, wartet es heute noch darauf, einen Crashreport zu erstellen. oO

Zur Frage nach dem Warum: Keinen Plan bzw. noch nicht erforscht. Iwo muss ja zumindest ein kryptischer Key und ein Zähler-Flag schon beim Start des DFU-Modes gespeichert werden. Wahrscheinlich in einer Systemdatei, die bei jedem Start überschrieben wird und zuvor, falls kryptischer Key vorhanden, der Crashreport erstellt wird.

Outback schrieb:Wurde Kris iPhone nach dem Auffinden nie mehr gebootet, wartet es heute noch darauf, einen Crashreport zu erstellen.

Angenommen die Forensiker haben die Daten bzw. bestimmte Tools im DFU-Modus benutzt und das Handy wurde nicht gebootet. Würden dann zwei Crashreports beim nächsten vollständigen booten erstellt? Also April Crashreport (Manipulation durch Dritten) und Juni Crashreport (Arbeit der Forensiker)?

Outback schrieb:Zur Frage nach dem Warum: Keinen Plan bzw. noch nicht erforscht. Iwo muss ja zumindest ein kryptischer Key und ein Zähler-Flag schon beim Start des DFU-Modes gespeichert werden. Wahrscheinlich in einer Systemdatei, die bei jedem Start überschrieben wird und zuvor, falls kryptischer Key vorhanden, der Crashreport erstellt wird.

Sehr wichtige Forschungsfrage finde ich.

InspektorLemon schrieb:Angenommen die Forensiker haben die Daten bzw. bestimmte Tools im DFU-Modus benutzt und das Handy wurde nicht gebootet. Würden dann zwei Crashreports beim nächsten vollständigen booten erstellt? Also April Crashreport (Manipulation durch Dritten) und Juni Crashreport (Arbeit der Forensiker)?

Nein einer im Juni, aber mit dem Boot Failure Count 2. Count 1 = Täter, Count 2 = Forensiker

InspektorLemon schrieb:Sehr wichtige Forschungsfrage finde ich.

Meine Erklärung: Weil die ganzen iOS Logging- und Reporting-Routinen im Low Level DFU-Mode nicht geladen werden, rotzt das System beim Boot-Failure (DFU) iwas Kryptisches iwo hin. Ähnlich wenn man über das UEFI-Bios eines Computers auf die SSD zugreifst oder zB einen USB-Anschluss deaktiviert, davon bekommt Windows nix mit oder erst beim nächsten vollständigen Booten.

Deshalb ist der Zugriff im DFU-Mode ja weitgehend spurenlos, auch wenn das iPhone 10 Stunden in Betrieb ist. Es wäre auch merkwürdig, wenn ein iOS eigener Modus (DFU) von iOS als Boot Failure erkannt wird. iOS wird da vermutlich gar nix mit zu tun haben, weil nicht geladen.

Outback schrieb:Nein einer im Juni, aber mit dem Boot Failure Count 2. Count 1 = Täter, Count 2 = Forensiker

* Nicht im Juni, sondern iwann beim nächsten Booten.

#

Um das iPhone überhaupt in den DFU-Mode versetzen zu können, muss es zwingend per Lade- / Datenkabel am Computer angeschlossen sein. Geht man nach Anleitungen im Netz vor oder verhaut das Timing beim Drücken bestimmter Tasten, dann bootet das iPhone automatisch und erzeugt einen "Starting Up"-Log. Erst danach kann man es wieder ausschalten und in den DFU-Mode versetzen.