Wenn Beweise von einer Software übersetzt werden, die das Gericht nicht versteht

Für einen Moment wird es im Gerichtssaal still. Auf dem Bildschirm stehen drei Angaben: „Nachricht um 14:32 gesendet.“ „Standort: X.“ „Kontakt: Y.“ Die Staatsanwaltschaft stützt sich darauf, die Verteidigung notiert sie, der Richter blickt in die Akte. Die Tabelle wirkt nicht wie eine Meinung. Sie wirkt wie ein geöffnetes Telefon, das gelernt hat, Amtssprache zu sprechen.

Doch das Telefon hat einen solchen Satz vermutlich nirgends gespeichert. Das Wort „gesendet“, der Name des Kontakts oder die Zeit in dem gerade sichtbaren Format mussten darin nie existiert haben. Vorhanden sein konnten Zahlen, Beziehungen zwischen Tabellen, ein Zeitwert ohne sichtbare Zeitzone und ein Kennzeichen, dessen Bedeutung von einer bestimmten Anwendungsversion abhängt. Der für Menschen verständliche Satz entstand erst auf dem Weg.

Das ist an sich nicht verdächtig. Genau dafür ist forensische Software da. Ohne sie würde ein Ermittler dem Gericht Blöcke binärer Daten vorlegen, keine Kommunikation, Zeitleiste oder Karte. NIST bezeichnet sachgerecht angewandte Methoden der digitalen Forensik in einer umfassenden Überprüfung als zuverlässig, weist aber zugleich darauf hin, dass sich mit Betriebssystemen und Anwendungen auch die Bedeutung von Artefakten verändern kann.^[1]

Die entscheidende Frage lautet daher nicht: Lügt die Software? Weitaus präziser ist: Was genau hat die Software gelesen, was hat sie abgeleitet – und was hat ein Mensch hinzugefügt?

Nehmen wir eine einzige Berichtszeile und gehen den Weg in Gegenrichtung. Nicht vom Telefon zum Gericht, sondern vom gerichtlichen Satz zurück zum ursprünglichen Gerät. Bei jedem Schritt lässt sich zeigen, was festgestellt wurde – und was bereits übersetzt war.

Schon das Wort „Datenbank“ kann den Eindruck erwecken, wir seien am unbestreitbaren Fundament angekommen. Doch eine Datenbank ist kein neutrales Lager der Wirklichkeit. Sie ist die Art, wie eine konkrete Anwendung in einer konkreten Version ihren Betrieb organisiert hat. Manche Tabellen beschreiben Benutzerobjekte, andere Synchronisierung, Warteschlangen, den Zustand der Oberfläche oder temporäre Caches. Dasselbe Ereignis kann mehrere Spuren hinterlassen; eine Spur kann fortbestehen, obwohl sie nicht mehr dem aktuellen Zustand entspricht, den der Nutzer sah.

Auch die Benutzeroberfläche trifft Entscheidungen, selbst wenn diese nur wie Hilfestellung aussehen. Ein Standardfilter kann Systemeinträge verbergen, eine Sortierung Zeiten aus verschiedenen Quellen vermischen und ein vereinheitlichter Kontaktname mehrere Identifikatoren überdecken. Ein Export bewahrt zudem meist nicht alles, was der Analytiker in der Arbeitsumgebung sah – etwa Quellpfad, Genauigkeit des Zeitwerts, Herleitung eines Namens oder einen Hinweis auf nur teilweise Unterstützung. Ein Bericht ist daher nicht bloß eine abgeschriebene Datenbank. Er ist eine Auswahl aus deren Interpretation.

Stellen wir uns einen rein modellhaften Datensatz vor. Er bildet nicht die Struktur einer konkreten Anwendung ab – im Gegenteil. Er ist abstrakt, damit sichtbar wird, wie viel Bedeutung erst noch entstehen muss:

msg_id 88421 peer_id 47 direction 1 created_at 1713184320000 state 3 source messages.db / row 88421

Die Zahl 1713184320000 kann die Software nach korrekter Bestimmung der Einheit in den 15. April 2024, 12:32 UTC, und anschließend in 14:32 Mitteleuropäische Sommerzeit umrechnen. Zum Ergebnis kamen jedoch mindestens drei Annahmen hinzu: dass es sich um Unix-Zeit handelt, dass der Wert in Millisekunden gespeichert ist und dass für die Anzeige die Prager Zeitzone verwendet werden soll. Speichert die Datenbank lokale Zeit, Serverzeit oder eine andere Epoche, erzeugt dieselbe Arithmetik einen präzisen, aber falschen Wert.

Ebenso ist direction = 1 nicht von Natur aus „gesendet“. Es ist die Zahl eins. Ihre Bedeutung erhält sie durch das Anwendungsschema und die Parserregel. peer_id = 47 ist keine Person, sondern eine Verknüpfung. Der Name Y kann der aktuelle Kontaktname, ein in einer anderen Tabelle gespeicherter Name, ein Profilwert aus der Synchronisierung oder eine vom Analytiker vergebene Bezeichnung sein. Der Eintrag kann zugleich in Hauptdatenbank, Transaktionsjournal, Cache und Sicherung vorhanden sein.

Die letzte Übersetzung nimmt der Analytiker vor. Er entscheidet, welche Zeile in den Bericht gelangt, womit sie verbunden und wie genau der Schluss formuliert wird. Standort X kann aus einer anderen Quelle stammen als die Nachricht; zeitliche Nähe bedeutet noch kein gemeinsames Ereignis. Kontakt Y kann ein technischer Identifikator sein, der einer Person zugeordnet wurde, doch der Datensatz allein beweist womöglich nicht, wer das Gerät in diesem Moment hielt. Die Software erzeugt ein lesbares Artefakt. Erst der Mensch macht daraus eine Aussage über die Welt.

Dass die Software ein Wort hinzugefügt hat, bedeutet nicht, dass sie es erfunden hat. Es bedeutet, dass sie codierte Bedeutung nach Regeln rekonstruiert hat. Das Beweisproblem entsteht, wenn diese Regeln unsichtbar bleiben, für die konkrete Version nicht verifiziert sind oder ihr Ergebnis als unvermittelter Inhalt des Geräts ausgegeben wird.

Der tückischste Fehler sieht nicht wie eine Störung aus. Die Software stürzt nicht ab, der Bericht zerfällt nicht und keine Zeile ist rot markiert. Die Ausgabe ist vollständig, sauber und in sich konsistent. Nur ein Feld wurde nach einem alten Schema gedeutet, ein Zeitwert in der falschen Einheit oder eine Tabelle der neuen Anwendungsversion nicht erkannt.

Eine Änderung des Datenbankschemas kann die Bedeutung in eine andere Spalte verlagern. Eine unbekannte Anwendungsversion kann eine Struktur enthalten, auf die der Parser lediglich eine ähnliche Regel anwendet. Eine unvollständige Extraktion kann die Hauptdatenbank, aber nicht ihr Journal liefern – oder ein Fragment ohne den Kontext anzeigen, der seinen Zustand erklären würde. Zwei Darstellungen desselben Ereignisses können ein Duplikat erzeugen, während zu aggressive Deduplizierung verbergen kann, dass die Angaben aus verschiedenen Quellen stammten.

Bei einem gelöschten Artefakt ist die Lage noch sensibler. Manche Felder können erhalten sein, andere bereits überschrieben, und schon die Wiederherstellungsmethode kann Fragmente mit unterschiedlicher Sicherheit verbinden. NIST warnt ausdrücklich, dass die Wiederherstellung gelöschter Daten überflüssiges Material einschließen und ein Parser bei falscher Strukturerkennung Einträge auslassen oder fehlerhaft anzeigen kann.^[1]

Solche Fehler sind eher systematisch als zufällig. Wenn eine Regel einem Kennzeichen die falsche Bedeutung zuweist, irrt sie nicht einmal unter tausend Fällen. Sie kann sich bei jedem Datensatz unter derselben Bedingung auf dieselbe Weise irren. Die Konsistenz wirkt dann paradoxerweise wie eine Bestätigung der Richtigkeit.

Ebenso wichtig ist die Unterscheidung zwischen „nicht gefunden“, „nicht extrahiert“, „nicht unterstützt“ und „existiert nicht“. Kennt ein Werkzeug eine neue Struktur nicht, beweist eine leere Kategorie im Bericht nicht, dass das Telefon die entsprechenden Daten nicht enthielt. Umgekehrt kann ein wiederhergestellter oder veralteter Datensatz die Existenz eines Datenfragments belegen, aber nicht zwingend, dass der Eintrag zum maßgeblichen Zeitpunkt aktiv, für den Nutzer sichtbar oder von ihm bewusst erzeugt war. Ein falscher Schluss braucht daher keine falsche Zahl. Es genügt, ihre Beweisreichweite falsch zu benennen.

Je professioneller ein Bericht aussieht, desto leichter übersieht man, dass seine Genauigkeit die Genauigkeit einer Berechnung sein kann – nicht Gewissheit über Bedeutung.

Die Fachdiskussion ist daher keine Anklage gegen forensische Werkzeuge. Die Literatur unterscheidet Werkzeugfehler, bekannte Werkzeuggrenzen sowie Fehler bei Anwendung oder Interpretation – drei verschiedene Probleme, die im Bericht ähnlich aussehen können.^[9] Studien und Testprogramme zeigen zugleich, dass Werkzeuge in der Regel außerordentlich nützliche Ergebnisse liefern. Tests sollen die Grenzen bestimmen: für welche Eingaben und Versionen eine Funktion verifiziert ist, woran sie scheitert und wann eine weitere Methode ergänzt werden muss.^[2][3]

Ein Hash spielt in der digitalen Forensik eine grundlegende Rolle. Der Fingerabdruck des Quellabbilds und der Arbeitskopien ermöglicht den Nachweis, dass sich die analysierte Datenfolge nicht verändert hat. Er ist eine Integritätskontrolle und eine Säule der Beweismittelkette. Standards zur Identifizierung, Sammlung, Erfassung und Bewahrung digitaler Beweise beruhen gerade auf dokumentierter Herkunft und Kontinuität.^[6][8]

Ein Hash beantwortet jedoch nicht, ob die Extraktion vollständig war, der Parser das richtige Schema erkannte, die Zeit in der richtigen Zone umgerechnet wurde oder der Datensatz das Handeln einer bestimmten Person belegt. Er kann eine falsche Interpretation vollkommen schützen, denn er bestätigt die Unverändertheit der Eingabe – nicht die Richtigkeit der Übersetzung.

Deshalb ist neben der Integrität eine Prüfspur wichtig: Wer übernahm das Gerät wann, welche Art der Erfassung wurde durchgeführt, welche Werkzeuge und Versionen kamen mit welchen Einstellungen zum Einsatz, welche Zwischenergebnisse entstanden und woher genau stammt das entscheidende Artefakt? Taucht später ein neuer Parser oder ein Zweifel an der Zeitumrechnung auf, muss der Weg wiederholbar sein, ohne auf Eindrücke zurückzufallen.

Gute forensische Praxis beruht nicht auf der Überzeugung, „unsere Software irrt sich nicht“. Sie beruht auf einem Verfahren, das mit Fehlern rechnet, nach ihnen suchen kann und die verbleibende Unsicherheit beschreibt. SWGDE empfiehlt getestete Methoden, Kenntnis bekannter Anomalien, Dokumentation, technische Überprüfung und eine Kombination von Werkzeugen oder Methoden entsprechend dem Risiko der jeweiligen Schlussfolgerung.^[3][4]

Validierung

Nachweis, dass eine Methode oder Funktion für ihren beabsichtigten Zweck geeignet ist. Die Frage „Existiert der Datensatz?“ erfordert andere Belege als der Schluss „Der Nutzer hat die Nachricht tatsächlich zu diesem Zeitpunkt gesendet“.

Verifikation

Prüfung, ob eine konkrete Implementierung, Version und Umgebung wie erwartet arbeiten – typischerweise mit bekannten Daten und vorab festgelegtem Ergebnis.

Reproduzierbarkeit

Die Möglichkeit für einen anderen qualifizierten Sachverständigen, aus derselben Quelle und dem beschriebenen Verfahren zu einem materiell gleichwertigen Befund zu gelangen und dessen Herkunft nachzuvollziehen.

Peer Review

Technische Überprüfung durch eine zweite qualifizierte Person: nicht nur sprachliche Kontrolle des Berichts, sondern Prüfung von Notizen, Daten, Verfahren, Schlussfolgerungen und Grenzen.

Unabhängiges Werkzeug

Überprüfung eines Artefakts mit einem anderen Parser oder einer anderen Methode. Zwei Programme sind nicht automatisch unabhängig, wenn sie eine Bibliothek, Dokumentation oder dieselbe Annahme teilen.

Manuelle Kontrolle

Gezielte Prüfung von Quelltabelle, SQL-Abfrage, Bytes, Zeitumrechnung, Schema oder Kontrollgerät. Es geht nicht darum, das gesamte Telefon von Hand zu lesen.

Die Unterscheidung zwischen Validierung und Verifikation wird nicht in allen Fachgebieten völlig gleich verwendet. Der praktische Sinn ist jedoch klar: Es genügt nicht zu wissen, dass ein Werkzeugtyp im Allgemeinen funktioniert. Wir müssen wissen, ob diese Funktion in dieser Version korrekt diese Frage zu dieser Art von Daten beantwortet. SWGDE erinnert zugleich daran, dass wegen der Vielzahl von Hardware- und Softwarekombinationen nicht jede Situation getestet werden kann.^[2]

Ein zweites Werkzeug ist wertvoll, aber kein magischer Stempel. Die Übereinstimmung zweier Ausgaben stärkt das Vertrauen nur, wenn die Wege nicht in Wahrheit identisch sind. Stärker kann ein Dreieck sein: automatischer Parser, gezielte Prüfung der Quellstruktur und Kontrollexperiment mit derselben Anwendungsversion. Nicht jedes Artefakt braucht diese Tiefe. Entscheidende, ungewöhnliche oder versionssensitive Schlussfolgerungen schon.

Hier entsteht eine rechtliche Asymmetrie. Ein Spezialist kann in wenigen Minuten erklären, warum eine bestimmte Zeile eine Nachricht darstellt, wie die Zeit berechnet wurde und woher die Kontaktidentität stammt. Die übrigen Verfahrensbeteiligten sehen häufig erst das Ergebnis. Je technischer die Zwischenschicht, desto größer das Risiko, dass die Überprüfung zur Frage persönlichen Vertrauens wird: Glauben wir der Person, die das Werkzeug bedient?

Ein Richter muss keinen Parser schreiben können, ebenso wenig wie er einen DNA-Sequenzierer bedienen muss. Das Gericht muss jedoch genügend Informationen erhalten, um Grundlage, Logik und Grenzen des fachlichen Schlusses beurteilen zu können. Das tschechische Verfassungsgericht hat wiederholt betont, dass ein Sachverständigengutachten keine privilegierte Beweiskraft besitzt und der gesamte Prozess seiner Entstehung – Unterlagen, Methode und Herleitung der Schlussfolgerungen – geprüft werden muss.^[10]

Für digitale Beweise bedeutet das: Überprüfbarkeit muss nicht darin bestehen, dass jedes Mitglied des Spruchkörpers den Quellcode eines kommerziellen Programms versteht. Sie sollte jedoch ermöglichen, konkrete Fragen zu stellen und konkrete Antworten zu erhalten:

1. Was war die Primärquelle, welche Art der Erfassung wurde verwendet und wie lautete ihr Hash? Was konnte diese Erfassung ihrer Natur nach nicht gewinnen?
2. Welches Werkzeug, welche Version, welches Modul und welche Einstellungen erzeugten die Ausgabe? Wurde die konkrete Anwendungsversion unterstützt?
3. Aus welcher Datei, Tabelle, welchem Datensatz oder Offset stammt der entscheidende Eintrag?
4. Welche Teile sind direkt gespeicherte Werte, welche Ergebnis von Zuordnung, Tabellenverknüpfung oder Normalisierung?
5. Wie wurde die Zeit umgerechnet: Einheit, Epoche, UTC oder Ortszeit, Zeitzone und Sommerzeit?
6. Wie behandelte die Software Duplikate, Journale, Caches sowie gelöschte oder unvollständige Datensätze?
7. Wurde das Schlüsselartefakt mit einer anderen Methode verifiziert, und wurden Abweichungen oder bekannte Grenzen dokumentiert?

Die Verteidigung braucht eine reale Möglichkeit, die Schlussfolgerung anzugreifen; das Gericht muss feststellen können, ob ein Einwand Daten, Methode, Interpretation oder lediglich das Ergebnis betrifft. Das bedeutet nicht, dass in jedem Verfahren der Quellcode eines Werkzeugs offengelegt oder der gesamte Geräteinhalt frei herausgegeben werden muss. Schutz von Privatsphäre, Sicherheit und Rechten Dritter kann Einschränkungen rechtfertigen. Es muss jedoch eine ausreichende technische Grundlage geben: Identifizierung der Quelle, Protokolle, Versionen, Beschreibung der Umwandlungen, Zugang zu relevanten Artefakten unter angemessenen Bedingungen und Möglichkeit fachlicher Kontrolle.

Ein Screenshot oder ein wenige Seiten langer PDF-Export schafft diese Möglichkeit für sich genommen meist nicht. Andererseits ist auch die Übergabe eines terabytegroßen Abbilds ohne Erläuterung keine echte Transparenz: Der Empfänger erhält Material, aber keine Karte zum angegriffenen Schluss. Überprüfung ist wirksam, wenn sich eine konkrete Schlussfolgerung mit einer konkreten Quelle verbinden und die entscheidenden Transformationen wiederholen lassen. Es geht um gezielte Rückverfolgbarkeit, nicht um Überwältigung durch technische Datenmenge.

ISO/IEC 27042 verknüpft die Analyse digitaler Beweise mit Kontinuität, Validität, Wiederholbarkeit, Reproduzierbarkeit und der Aufzeichnung ausreichender Informationen für eine unabhängige Überprüfung.^[5] Mit anderen Worten: Ein Sachverständiger darf eine komplexe Übersetzung vornehmen, doch das Beweisverfahren darf nicht allein auf seiner Autorität beruhen.

Es ist leicht, ins andere Extrem zu verfallen und zu behaupten, nur rohe Bytes seien echte Beweise. Das sind sie nicht. Ein Byte ohne Struktur ist ebenso unverständlich wie ein Buchstabe ohne Sprache. Ein modernes Telefon enthält enorme Datenmengen, verteilt auf Datenbanken, Journale, Container, Systemdienste, Sicherungen und Cloud-Verknüpfungen. Jedes Element manuell zu verarbeiten wäre langsam, anfällig für menschliche Fehler und in realen Ermittlungen praktisch unmöglich.

Forensische Software wiederholt Routinen, erhält Verknüpfungen, indexiert, konvertiert und ermöglicht den Vergleich von Millionen Einträgen. Ihre grafische Oberfläche ist keine Kosmetik, sondern ein Denkwerkzeug. NIST betreibt das CFTT-Programm gerade deshalb, damit Werkzeugfunktionen anhand von Spezifikationen, bekannten Daten und öffentlichen Testverfahren geprüft werden können.^[7]

Das falsche Dilemma „Mensch oder Software“ löst daher nichts. Ein Mensch ohne Software sieht große Teile der digitalen Wirklichkeit nicht. Software ohne Menschen weiß nicht, welche Rechtsfrage sie beantwortet, ob ein Artefakt erheblich ist und welchen Grad an Gewissheit eine Schlussfolgerung tragen kann. Wir brauchen beides – und eine sichtbare Kontrollverbindung zwischen beiden Teilen.

Überprüfbarkeit bedeutet nicht, das Gericht unter Hunderten Seiten hexadezimaler Ausgaben zu begraben. Ein gut gestalteter Bericht kann einfach sein. Entscheidend ist, ob unter seiner Oberfläche ein nachvollziehbarer Weg existiert, den man bei Zweifeln zurückverfolgen kann.

Anstelle des kategorischen Satzes „Das Telefon beweist, dass die Nachricht um 14:32 gesendet wurde“ könnte ein solcher Bericht präziser formulieren: „In Datenbank X wurde in Datensatz Y ein Kennzeichen gefunden, das Parser-Version Z für das unterstützte Schema als ausgehende Nachricht interpretiert. Der Zeitwert wurde von UTC nach Europe/Prague umgerechnet; das Ergebnis wurde durch Prüfung des Quelldatensatzes verifiziert.“

Ein längerer Satz gehört nicht immer in die Hauptübersicht. Er muss aber im Fachteil, Protokoll oder in den Anmerkungen verfügbar sein. Lesbarkeit und Überprüfbarkeit sind keine Gegensätze. Der lesbare Bericht ist der Gipfel; überprüfbare Dokumentation sein Fundament.

Auf dem Bildschirm steht noch dieselbe Zeile. Nachricht um 14:32 gesendet. Standort X. Kontakt Y. Nach dem gesamten Weg zurück wirkt sie jedoch nicht mehr wie ein Satz, den das Telefon selbst für das Gericht geschrieben hat. Sie ist eine fachliche Aussage, entstanden aus erhaltenen Daten, erkannter Struktur, Parserregeln, Umwandlungen der Oberfläche und menschlicher Auswahl.

Das schwächt den Beweis nicht automatisch. Im Gegenteil. Wenn wir seine Herkunft kennen, können wir feststellen, welcher Teil belastbar ist, welcher von einer Version abhängt, welcher verifiziert wurde und wo Unsicherheit bleibt. Vertrauen ruht dann nicht auf dem Logo der Software oder der Autorität des Spezialisten, sondern auf einem transparenten Weg, der erneut beschritten werden kann.

Das größte Paradox eines professionellen Berichts besteht darin, dass seine Übersetzungen umso unsichtbarer werden, je besser er seine Aufgabe erfüllt. Eine exakt ausgerichtete Tabelle verbirgt Datenbankbeziehungen, Zeitumrechnungen, Deduplizierung, Parserentscheidungen und das Urteil des Analytikers. Einfachheit ist hier das Ergebnis von Komplexität – nicht deren Abwesenheit.