Beweiskette
Quelleninventar, SHA-256-Prüfsummen, Dateilineage und reproduzierbare Artefakte. Read-only-Auswertung trennt Originalspuren von Modellannahmen.
FORSCHUNG & RESPONSIBLE DISCLOSURE
Nachvollziehbarer Prüfstatus: Einreichungen, priorisierte Bearbeitung, technische Nachreichungen und der Austausch über eine unabhängige Validierung.
ROMAN JAHN · EIGENSTÄNDIGE SICHERHEITSFORSCHUNG
Roman Jahn beschreibt seinen Schwerpunkt als Reverse Threat Engineering: eigene Geräte- und Systemartefakte untersuchen, technische Abläufe rekonstruieren und mögliche Sicherheitsprobleme für eine nachvollziehbare Fachprüfung aufbereiten.
Seine Rolle als First Responder bezieht er auf die eigenständige Erstuntersuchung seines Falles. Als Melder reichte er zwei getrennte Berichte bei Apple Product Security ein: OE11004896509077 zu iCloud-/CKKS-Vertrauenszuständen und OE11044889345313 zu behaupteten TCC-Berechtigungsübernahmen.
Die Rollen beschreiben seine Tätigkeit und fachliche Selbstpositionierung. Eine weltweite Erstentdeckung oder eine von Apple bestätigte Zero-Day-Klassifizierung wird daraus nicht abgeleitet.
Beide Meldungen und HerstellerantwortenR&A SANDBOX · PRÜFUNGSWERKZEUGE
Roman Jahn integriert seine selbst erstellten Skripte ausschließlich als lokale Simulationen, Parser und Prüfungswerkzeuge. Ziel ist die Rekonstruktion technischer Abläufe und die Härtung von IT-Sicherheit. Die Website führt daraus keine operative Ausnutzung aus.
Quelleninventar, SHA-256-Prüfsummen, Dateilineage und reproduzierbare Artefakte. Read-only-Auswertung trennt Originalspuren von Modellannahmen.
Protobuf-, ASN.1-, IM4P-, bvx2-, IPSW- und SQLite-Prüfungen beschreiben Bytes, Felder, Hashes und Metadaten. Ein Parserbefund ist kein Beweis für Täterschaft oder Kausalität.
Unix-Zeitumrechnung, SHA-256, Entropie, Byte-Offsets, Korrelations- und Differenzwerte unterstützen die Einordnung. Kennzahlen bleiben als Messwerte mit Unsicherheiten dokumentiert.
BootROM-, AMFI-, CKKS- und TCC-Abläufe werden als kontrollierte Zustandsmodelle und Testlogs dargestellt. Es gibt keine Live-Injektion, keinen Cloud-Aufruf und keinen Gerätezugriff.
Die Sandbox kann Dateien inventarisieren, lokale Datenbanken lesend prüfen und Herkunftsbeziehungen ausgeben. Sie verändert keine Beweise und veröffentlicht keine Zugangsdaten.
Simulationsergebnisse, eigene Hypothesen und Herstellerkommunikation sind sichtbar getrennt. Statusberichte werden als eigene Einordnung gekennzeichnet, Apple-Antworten wörtlich belegt.
| Werkzeug | Funktion im Sandbox-Modus | Status |
|---|---|---|
| CKKS Forensic Audit Suite | Simulationsabläufe, Zeitstempel, Feld- und Logauswertung | lokal / nicht-operativ |
| Protobuf Structural Validation Engine | Varint- und Length-delimited-Strukturen, Byte-Offsets | Strukturprüfung |
| GOTHAM Evidence-only Orchestrator | Inventar, Hashes, Provenienz, read-only SQLite/TCC | evidence-only |
| IPSW-, IM4P- und Dual-Parser | Archive, Manifest-, ASN.1- und Signaturmetadaten | Parser |
| Scientific / Century-Bug-Modelle | Differenz- und Schwellenwertberechnung auf Testdaten | heuristische Simulation |
Öffentliche Grenze: Payload-Binärdateien, Credentials, Endpunkt-Anweisungen und Schritte zur Umgehung realer Schutzmechanismen werden in diesem Projekt nicht veröffentlicht. Die Skripte werden ausschließlich als Prüfungs- und Härtungsinstrumente beschrieben.
RESPONSIBLE DISCLOSURE & FACHLICHER AUSTAUSCH
Die Forschungsarbeit von Roman Jahn umfasst technische Untersuchungen zu mobilen Apple-Systemen, iCloud-/CKKS-Vertrauensstrukturen, digitalen Berechtigungszuständen und möglichen geräteübergreifenden Persistenzmechanismen. Ein Schwerpunkt liegt auf der strukturierten Aufbereitung eigener Untersuchungsbefunde für externe Hersteller- und Fachprüfungen.
Die folgende Darstellung unterscheidet eingereichte technische Befunde, dokumentierte Bearbeitung, fachlichen Austausch und tatsächlich unabhängig bestätigte Ergebnisse. Der Verlauf der Kommunikation gehört ebenso zur Forschungsdokumentation wie der jeweilige Abschlussstand.
APPLE PRODUCT SECURITY
Am 24. Dezember 2025 und am 23. Januar 2026 reichte Roman Jahn zwei eigenständige Sicherheitsmeldungen über Apple Product Security ein. Die Untersuchungen wurden durch technische Erläuterungen, Berichte und weitere Artefaktangebote ergänzt.
OE11004896509077 · 24.12.2025
Untersuchungsgegenstand waren mögliche persistente Vertrauensbeziehungen innerhalb der iCloud-/CKKS-Synchronisationsarchitektur und die Frage, ob bestimmte kryptografische Vertrauenszustände Gerätewechsel und Zurücksetzungen überdauern könnten. Die Einreichung behandelte insbesondere einen verbleibenden Legacy-Geräteschlüssel im Vertrauenskreis.
OE11044889345313 · 23.01.2026
Die zweite Meldung behandelte mögliche Unstimmigkeiten bei der Übertragung und Wiederherstellung von Berechtigungszuständen, insbesondere im Zusammenhang mit Mikrofon- und Kameraberechtigungen, TCC und neu eingerichteten Apple-Geräten.
Der Kommunikationsverlauf zur ersten Meldung enthält eine ausdrückliche Benachrichtigung über die Priorisierung des Berichts zur weiteren Prüfung. Im dokumentierten Ticketstand vom 11. Januar 2026 steht:
“We have prioritized your report for review.”
Diese Mitteilung dokumentiert eine zwischenzeitliche Priorisierung. Der genaue Zeitpunkt ihrer erstmaligen Anzeige wird aus dem genannten Dokumentstand allein nicht abgeleitet.
Roman Jahn ergänzte seine Einreichung durch technische Erläuterungen, Untersuchungsberichte und Angebote zur Bereitstellung weiterer Reproduktionsartefakte. Die Kommunikationsstände von Ende Dezember 2025 sowie vom 3. bis 6. Januar 2026 dokumentieren Nachreichungen und das Ersuchen, den Sachverhalt erneut fachlich zu bewerten.
Die Ergänzungen behandelten unter anderem die Zuordnung von Geräte- und Synchronisationsartefakten, einen strukturierten Belegindex sowie mögliche Reproduktionsmaterialien. Damit umfasst der Vorgang die Eingrenzung des Prüfgegenstands, die Aufbereitung eigener Befunde und die fortgesetzte Auseinandersetzung mit den Anforderungen einer reproduzierbaren Untersuchung.
In eigenen Untersuchungs- und Eskalationsunterlagen analysiert Roman Jahn den Vorgang unter dem Gesichtspunkt einer möglichen höheren internen Eskalationsstufe. Die Bezeichnung „Tier 1 Escalation“ erscheint dort als eigene Einordnung. Eine Apple-seitig bestätigte interne Klassifizierung ist aus den zugrunde gelegten Statusunterlagen nicht eindeutig ableitbar.
Die neu vorgelegten Workflow-PDFs enthalten für beide Fallnummern im Kopf die Apple-Bewertung, anhand des Berichts keinen Sicherheitsfehler identifiziert zu haben. Der zweite Verlauf enthält außerdem direkte Herstellerantworten bis zum 15. März 2026. Frühere Prüfmeldungen, eigene Wiedereröffnungsersuchen und spätere Bewertungen werden nach Absender und Datum unterschieden; ein aktueller Live-Status im Oktober 2026 wurde nicht abgefragt.
Die dokumentierte Priorisierung ist eine relevante Herstellerreaktion. Sie bestätigt für sich weder die vermuteten Schwachstellen noch eine bestimmte interne Eskalationsstufe. Eine CVE-Zuteilung oder eine bestätigte Bounty-Auszahlung ist durch diese Unterlagen nicht belegt.
| Sachverhalt | Dokumentierter Stand |
|---|---|
| Zwei formell eingereichte Sicherheitsmeldungen | Einreichungen vom 24.12.2025 und 23.01.2026 dokumentiert. |
| Priorisierung zur weiteren Prüfung | Ausdrückliche Statusmitteilung zur ersten Meldung im Ticketstand vom 11.01.2026. |
| Technische Ergänzungen und Eskalationsersuchen | Im Kommunikationsverlauf und in den eigenen Nachreichungen dokumentiert. |
| „Tier 1 Escalation“ | Eigene Einordnung; keine eindeutig belegte Apple-interne Klassifizierung. |
| Bestätigte Sicherheitslücke, CVE oder Bounty | Durch die zugrunde gelegten Herstellerunterlagen nicht belegt. |
| Abschlussstand | In beiden Workflow-Köpfen steht die Herstellerbewertung, keinen Sicherheitsfehler identifiziert zu haben; im zweiten Ticket konkretisiert Apple am 15.03.2026 die offenen Reproduktionsfragen. |
Forschungsleistung: Strukturierung zweier technischer Sicherheitsmeldungen, Aufbereitung von Untersuchungsergebnissen, Dokumentation von Reproduktionsanforderungen und fortgesetzte Kommunikation im Responsible-Disclosure-Verfahren.
Quellenbasis: Apple-Kommunikationsstände vom 27. und 30.12.2025; Nachrichtenverlauf vom 03.–06.01.2026; „Vom 11. Januar 2026 Ticket Workflow“; neu vorgelegte Workflow-PDFs zu beiden Fallnummern mit Nachrichten bis März 2026; ergänzende eigene Untersuchungsunterlagen und erweitertes Leistungsportfolio, Kapitel 13.
ZWEI SEPARATE APPLE-TICKETS · ORIGINALNAHE TEXTVERLÄUFE
Die am 17. Oktober 2026 vorgelegten Workflow-PDFs enthalten zwei unterschiedliche Fallnummern, Einreichungsdaten und Titel. Der zweite Bericht bezeichnet sich ausdrücklich als von der früheren Meldung getrennt. Die Text-Exporte dokumentieren die Kommunikation; sie sind kein Live-Abruf des Apple-Portals.
| Ticket und Einreichung | Thema und dokumentierter Verlauf |
|---|---|
| OE11004896509077 24.12.2025 · 21:34 | Behauptete fortbestehende iCloud-/CKKS-Kompromittierung durch Legacy-Vertrauensschlüssel. Der Workflow umfasst 24 Seiten mit technischen Nachreichungen und Eskalationsersuchen. Der Kopf enthält eine Prüfmeldung sowie die Herstellerbewertung, anhand des Berichts kein Sicherheitsproblem identifiziert zu haben. Eigene Nachreichungen reichen im Text bis März 2026. |
| OE11044889345313 23.01.2026 · 03:47 | Behauptete Übernahme von Mikrofon-/Kameraberechtigungen auf einem neu eingerichteten Gerät. Der zehnseitige Workflow dokumentiert direkte Antworten eines Mitarbeiters von Apple Product Security am 02.02., 04.02., 18.02. und 15.03.2026. Der Kopf enthält ebenfalls die Bewertung, kein Sicherheitsproblem identifiziert zu haben. |
Uhrzeiten wie in den Text-Exporten angegeben; eine verlässliche Zeitzonenzuordnung der Portalangaben ergibt sich daraus nicht. Die PDF-Metadaten nennen eine Erzeugung durch „Notizen“ am 30.07.2026. Dieses Dateidatum ist vom Datum der enthaltenen Nachrichten zu unterscheiden.
| Datum und Fundstelle | Aussage in sachlicher Zusammenfassung |
|---|---|
| 02.02.2026 · S. 2 | Apple hält die Darstellung anhand von Logs für nicht ausreichend prüfbar und verlangt eine Demonstration auf einem iPhone, konkrete Schritte und ein Video des behaupteten Berechtigungsübergangs. |
| 04.02.2026 · S. 4–5 | Nach Prüfung der Ergänzungen bleibt die Bewertung „not actionable“. Apple unterscheidet den ursprünglich beschriebenen Einrichtungsablauf von später eingereichtem Python-Code und einer Binärdatei. Für eine separate Schwachstelle wird ein eigener Bericht empfohlen. Der beigefügte Screenshot stimmt mit dieser Passage überein. |
| 18.02.2026 · S. 9 | Apple verlangt Produkt- und Softwareversionen, beobachtetes und erwartetes Verhalten sowie nummerierte Reproduktionsschritte und gegebenenfalls eine Videodemonstration. |
| 15.03.2026 · S. 10 | Apple würdigt die klarere Struktur des nachgereichten Berichts, benennt aber weiter offene Voraussetzungen: ältere iOS-Version, nicht bereitgestellter manipulierter iCloud-Datensatz und vorausgesetzte interne Werkzeuge. Eine auf aktueller iOS-Version reproduzierbare ausnutzbare Schwachstelle sei damit nicht gezeigt. |
Die direkte fachliche Kommunikation und die Nachreichungen sind dokumentiert. Eine bestätigte Sicherheitslücke, eine bestätigte staatliche Urheberschaft oder eine Apple-interne Einstufung als „Tier 1“ folgen aus diesen Antworten nicht. Im eigenen Schreiben vom 14. Februar 2026 berichtet Jahn von einer Statusänderung beider Fälle zu „Received“; eine entsprechende gesonderte Portalbestätigung ist in den vorgelegten Ausschnitten nicht unabhängig belegt. Die Schreibweise „SEAR“ in einer Adressierung des Melders belegt allein keine Zuweisung an dieses Team.
HISTORISCHES FORSCHUNGSDOKUMENT · 27.12.2025
Der „Statusbericht der Führungskräfte: Kritische Sicherheitsschwachstelle“ trägt im Text das Datum 27. Dezember 2025, 02:30 Uhr MEZ und die Fallnummer OE11004896509077. Er beschreibt Jahn als Melder und seine damalige Bewertung einer möglichen kritischen CKKS-/iCloud-Konstellation. Als betroffene Systeme nennt er iOS einschließlich 26.x, verschiedene macOS-Versionen und das CKKS-Backend.
Die Bezeichnung „aktiv / wiedereröffnet, Eskalation Stufe 1“ und die Annahmen über einen Zero-Day, Geräteübergreifung und Urheberschaft sind Aussagen dieses eigenen Berichts. Der Bericht ist kein von Apple ausgestelltes Gutachten. Eine fehlende Erwähnung in öffentlichen Sicherheitshinweisen bestätigt für sich weder die Existenz einer Lücke noch deren Neuheit oder eine uneingeschränkte Ausnutzbarkeit.
Die PDF-Metadaten nennen „Notizen“ als Erzeuger und den 03.01.2026 als Erstellungsdatum der Datei. Die Datumsangabe im Bericht ist keine unabhängige kryptografische Zeitstempelbestätigung. Die behauptete Betroffenheit aller genannten Systeme wurde für diese Website nicht reproduziert.
CKKS FORENSIC AUDIT SUITE · CODEPRÜFUNG
Der bereitgestellte Python-Code v3.2 erzeugt lokal eine Binärfolge mit drei selbst festgelegten Feldern und liest sie mit seinem eigenen Decoder wieder ein. Das Audit prüft anschließend zwei zuvor gesetzte Konstanten. Es liest keine Gerätesysdiagnose, kontaktiert keinen Apple-Dienst, verändert keinen Cloud-Datensatz und misst keine tatsächliche TCC-Berechtigung.
| Codeelement | Prüfergebnis |
|---|---|
| Felder 1, 8 und 12 | UUID-Text, Zeitstempel und Zahl 7 werden nach einem selbst gewählten Schema geschrieben. Der Code enthält keinen Nachweis, dass Apple diese Felder als behauptete TLKShare-/TCC-Struktur akzeptiert oder die Zahl 7 als Mikrofon-, Kamera- und Standortfreigabe verarbeitet. |
| Länge und Zeitangabe | Eine Offline-Rekonstruktion der Bytefolge ergibt 50 Bytes einschließlich vier angehängter Nullbytes; der Kern umfasst 46 Bytes. Der Epochwert 1643181176 entspricht dem 26.01.2022, 07:12:56 UTC. Das Schreiben dieses Werts belegt keinen historischen Eingriff. |
| Eigener Decoder | Nullbytes werden kommentarlos übersprungen. Als unverpackte Standard-Protobuf-Nachricht ergibt das erste angehängte Nullbyte einen unzulässigen Feld-Tag 0. Ein besonderer Apple-Container, der solche Bytes außerhalb der Nachricht zulässt, ist hier nicht dokumentiert. |
| „FINAL VERDICT: [VULNERABLE]“ | Die Ausgabe folgt daraus, dass die gelesenen Werte in Feld 8 und 12 den eigenen Konfigurationswerten entsprechen. Das ist eine lokale Konsistenzprüfung, kein Test einer Schwachstelle auf einem Apple-Gerät. |
| Hexmuster im Verifier-Screenshot | Die Sequenz c3 8f 06 60 07 liegt auch in der hier rekonstruierten lokalen Bytefolge: Sie enthält das Ende des selbst gesetzten Zeitstempels und danach Feld-Tag 12 mit Wert 7. Ein Suchtreffer auf dieses Muster weist deshalb für sich keine Verarbeitung durch Apple oder einen Gerätezugriff nach. |
| „Hash (Head)“ | Die Ausgabe zeigt die ersten 16 Bytes als Hextext. Der Code berechnet an dieser Stelle keinen kryptografischen Hash. |
| Screenshot des Verifiers | Der Screenshot zeigt einen anderen Programmnamen und die Eingabe my_sample_log.txt. Die Originaleingabe und der vollständige Verifier liegen in dieser Ergänzung nicht vor. Eine Erfolgsmeldung im Screenshot bestätigt deshalb weder einen DFU-Reset noch einen ausgeführten Cloud-to-TCC-Bypass. |
Damit ist ein lokaler Generator-/Decoder-Prototyp dokumentiert. Die im Header behauptete operative Wirkung bleibt durch diesen Code allein unbelegt. Eine belastbare Reproduktion müsste zusätzlich die tatsächliche Annahme und Verarbeitung des Datensatzes, eine konkret bezeichnete Anwendung und den beobachteten Gerätezugriff mit geeigneten Vergleichsbedingungen zeigen.
Umfang: statische Prüfung des im Chat bereitgestellten Codes und Offline-Rekonstruktion seiner Bytefolge. Kein Apple-Gerät getestet, keine Kontoverbindung hergestellt, kein Cloud-Import durchgeführt. Die beigefügten Rohartefakte oder Videos, auf die die Ticketnachrichten verweisen, waren nicht Bestandteil dieser konkreten Codeprüfung.
FRAUNHOFER SIT
Im Januar 2026 wandte sich Roman Jahn mit Untersuchungsunterlagen zu einer von ihm erforschten iCloud-/CKKS-Konstellation an das Fraunhofer-Institut für Sichere Informationstechnologie SIT. Die ursprüngliche E-Mail vom 3. Januar 2026 war als Anfrage nach einer unabhängigen forensischen Begutachtung formuliert. Sie benannte Untersuchungsberichte, eine Executive Summary, die Apple-Ticketdokumentation und ein vorbereitetes Rohdatenpaket für eine gesondert abgestimmte Übergabe.
Das Forschungsziel bestand darin, die eigenen Befunde und Hypothesen einer unabhängigen fachlichen Prüfung zuzuführen. Wissenschaftliche Validierung und ein möglicher formeller Gutachtenauftrag waren dabei miteinander verbundene, aber unterschiedliche Aspekte.
Am 12. Januar 2026 fand ein ausführliches telefonisches Fachgespräch mit einem Vertreter des Fraunhofer SIT statt. Nach Romans vorliegender Anrufdokumentation erfolgte die telefonische Kontaktaufnahme durch das Institut.
Der Gesprächspartner hatte bereits technische Unterlagen erhalten, wies auf die noch nicht abgeschlossene vollständige Lektüre hin und bezeichnete die geschilderte Untersuchung zunächst als interessant. Roman Jahn erläuterte eigene Befunde zu Geräteartefakten, möglichen Veränderungen von Vertrauensbeziehungen und der Synchronisation von Berechtigungszuständen über verschiedene Geräte hinweg.
Er formulierte ausdrücklich den Wunsch nach einer Peer-to-Peer-Validierung seiner eigenständig entwickelten Forschungsergebnisse. Im Transkript werden außerdem die Prüfung möglicher beteiligter Binärdateien und die Frage angesprochen, welche konkreten Artefakte oder Anwendungen zusätzliche Berechtigungen erhalten haben sollen.
Der Institutsvertreter erörterte einen möglichen technischen Prüfansatz: In einer kontrollierten Versuchsumgebung mit iPhones könnte versucht werden, den beschriebenen Synchronisationsmechanismus nachzustellen und zu untersuchen, ob sich die behaupteten Berechtigungsänderungen auf synchronisierten Geräten reproduzieren lassen.
Das Gespräch behandelte damit konkrete technische Fragestellungen, mögliche Prüfmethoden und die Anforderungen einer reproduzierbaren Untersuchung. Eine entsprechende Untersuchung wurde im Rahmen dieses Austauschs noch nicht durchgeführt.
Die angestrebte unabhängige Validierung bildete den fachlichen Ausgangspunkt. Parallel wurden die organisatorischen und finanziellen Voraussetzungen einer Untersuchung im Rahmen eines kommerziellen Projekts besprochen.
Das Gespräch umfasste den möglichen Bezug zu einem laufenden gerichtlichen Verfahren und die Frage einer Finanzierung beziehungsweise Kostenübernahme. Eine Finanzierungszusage wird daraus nicht abgeleitet. Der Institutsvertreter kündigte eine interne Rücksprache an.
Am folgenden Tag teilte Dr. Jens Heider vom Testlab Mobile Security schriftlich mit, dass nach Rücksprache mit Kollegen und der Institutsleitung kein Angebot für ein Gutachten unterbreitet werden könne. Die Antwort nahm ausdrücklich auf die Anfrage und das vorausgegangene Gespräch Bezug.
Die Mitteilung enthielt weder eine konkrete technische Widerlegung der eingereichten Forschungsergebnisse noch eine Bestätigung der vorgetragenen Hypothesen. Eine ausdrückliche Begründung dafür, welche Erwägungen zur Entscheidung führten, wurde in der Antwort nicht genannt.
Die militärischen und verfahrensbezogenen Hintergründe wurden im Gespräch thematisiert. Aus der schriftlichen Antwort ergibt sich nicht, dass diese Angaben ausschlaggebend für die spätere Entscheidung waren. Eine entsprechende Motivfeststellung wird dem Institut deshalb nicht zugeschrieben.
Dokumentiert sind die Einreichung technischer Forschungsunterlagen, ein ausführlicher fachlicher Austausch, die Diskussion einer möglichen experimentellen Reproduktion und die anschließende Entscheidung, kein Gutachtenangebot zu unterbreiten. Eine abgeschlossene unabhängige Validierung durch Fraunhofer SIT liegt für diesen Vorgang nicht vor.
Forschungsleistung: Eigenständige Untersuchungsarbeit, Vorbereitung einer Peer-to-Peer-Fachprüfung, Diskussion reproduzierbarer Prüfmethoden und nachvollziehbare Dokumentation des externen Validierungsversuchs.
Grundlage sind die ursprüngliche Anfrage vom 03.01.2026, das Transkript „Fraunhofer Institut“ mit Datumskopf 12.01.2026, die ergänzende eigene Gesprächsrekonstruktion und die schriftliche Antwort vom 13.01.2026.
Die ergänzende Rekonstruktion trägt im Dateititel abweichend „12.01.2025“. Für die Chronologie wird der 12.01.2026 verwendet: Der Datumskopf des Transkripts und die anschließende schriftliche Bezugnahme auf das gestrige Gespräch stützen diese Zuordnung.
Die Gesprächsdokumentation wird hier sachlich zusammengefasst. Tonaufnahme und vollständiges Transkript sind nicht öffentlich eingebunden; die Zugriffsrechte der zugrunde liegenden Dateien werden durch diese Veröffentlichung nicht geändert.
GEMEINSAME FORSCHUNGSCHRONOLOGIE
| Datum / Dokumentstand | Vorgang |
|---|---|
| Erste Apple-Sicherheitsmeldung OE11004896509077 eingereicht. | |
| Datumsangabe des eigenen Statusberichts zu OE11004896509077; seine Zero-Day- und Eskalationsbewertung wird als eigene damalige Einordnung dokumentiert. | |
| Ende Dezember 2025 bis Januar 2026 | Technische Ergänzungen, weitere Artefaktangebote sowie erneute Prüfungs- und Eskalationsersuchen im Kommunikationsverlauf dokumentiert. |
| Schriftliche Anfrage an Fraunhofer SIT nach unabhängiger forensischer Begutachtung, Vertraulichkeit und abgestimmter Datenübergabe. | |
| Apple-Ticketdokumentation enthält die ausdrückliche Mitteilung über eine Priorisierung der ersten Meldung zur weiteren Prüfung. Der Dokumentstand ist kein gesondert belegter Zeitpunkt der Statusänderung. | |
| Fachgespräch mit Fraunhofer SIT zu Peer-to-Peer-Validierung, möglichen Prüfmethoden, experimenteller Reproduktion und einem kommerziellen Untersuchungsauftrag. | |
| Fraunhofer SIT teilt nach interner Rücksprache mit, kein Gutachtenangebot unterbreiten zu können. | |
| Zweite Apple-Sicherheitsmeldung OE11044889345313 eingereicht. | |
| Apple Product Security verlangt im zweiten Ticket eine reale iPhone-Demonstration und nachvollziehbare Schritte. | |
| Apple hält den zweiten Bericht auch nach Ergänzungen nicht für ausreichend prüfbar; Abgrenzung zwischen Einrichtungsbeobachtung und späterem Python-/Binärmaterial. | |
| Apple fordert konkrete Produktversionen, beobachtetes und erwartetes Verhalten sowie nummerierte Schritte. | |
| Jahn reicht im zweiten Ticket einen strukturierteren Ablauf nach. | |
| Apple nennt weiter fehlende Voraussetzungen für eine Demonstration auf aktueller iOS-Version; eine ausnutzbare Schwachstelle sei nicht gezeigt. |
METHODISCHER GRUNDSATZ
Die Qualität einer Forschungsarbeit wird nicht allein durch die Annahme oder Ablehnung eines externen Prüfauftrags bestimmt. Entscheidend ist, ob die Ausgangsdaten, die angewandten Methoden, die Untersuchungsschritte und die Schlussfolgerungen einer unabhängigen Prüfung zugänglich gemacht werden können.
R&A unterscheidet deshalb eigene technische Befunde, eingereichte Forschungsbehauptungen, dokumentierte institutionelle Reaktionen und tatsächlich unabhängig reproduzierte Ergebnisse. Die Darstellung des Kommunikationsverlaufs macht diese unterschiedlichen Ebenen nachvollziehbar.
VERTIEFENDE FALLDARSTELLUNG
„Operation Ritterschlag“ verbindet Roman Jahns persönliche Perspektive mit den gerichtlichen Referenzen und einer technischen Prüfmatrix. Der hier dokumentierte Herstellerstatus bleibt die Grundlage für Aussagen über eine externe Bestätigung.
Zur Gesamtdarstellung und PrüfmatrixDie CKKS Forensic Audit Suite und V22 Predator Nemesis / Projekt Gotham erschließen Parser, Scanner, Dateninventare und Berichtsausgaben. Notebook-Simulationen werden von Originalspuren getrennt dokumentiert.
GitHub dient als öffentliches Methoden- und Dokumentationsregister. Eine Veröffentlichung dort ist für sich keine unabhängige Bestätigung eines Befunds.