AbdeckungBranche

Die Abdeckung sollte nicht vom Veröffentlichungszyklus eines Herstellers abhängen

Die folgenreichste Entscheidung einer forensischen Auswertung fällt oft Monate früher, in einer Produktbesprechung, bei der der Analyst nicht dabei war.

Veröffentlicht 14. Juli 2026 6 Min. Lesezeit Alexandre Ansart

Es gibt in einer Auswertung der digitalen Forensik einen Moment, den niemand in das Verfahrenshandbuch schreibt. Ein Analyst öffnet eine Extraktion, findet eine Anwendung, die er nicht erkennt, und prüft, ob sein Werkzeug sie unterstützt. Das tut es nicht. Die Daten liegen genau dort, vollständig vorhanden, in einer Datenbank, deren Dateinamen er sehen kann. Und die Antwort auf die Frage, ob sie gelesen werden können, lautet: nicht in diesem Quartal.

Dieser Moment wird gewöhnlich als Supportfrage behandelt. Jemand eröffnet ein Ticket. Vielleicht nimmt der Hersteller es in einen Rückstand auf, vielleicht kommt in sechs Monaten eine Version, vielleicht ist die Anwendung regional verbreitet genug, um die Zeit eines Entwicklers wert zu sein, und vielleicht ist sie es nicht. Derweil hat das Verfahren seine Fristen.

Das ist keine Supportfrage. Es ist eine strukturelle Eigenschaft der Art, wie die Branche sich entschieden hat zu arbeiten, und sobald man es so sieht, hat viel von der täglichen Frustration in einem Labor eine einzige Ursache.

Die Entscheidung fällt woanders

Jedes gängige Werkzeug der forensischen Analyse arbeitet auf dieselbe Weise. Jemand beim Hersteller erschließt das Speicherformat einer Anwendung durch Reverse Engineering, schreibt einen Parser dafür, testet ihn und liefert ihn in einer Version aus. Der Analyst erhält das Ergebnis dieser Arbeit als Fähigkeit.

Das ist wirklich schwierige Entwicklungsarbeit, und die Menschen, die sie leisten, sind gut darin. Das Problem ist nicht die Kompetenz. Das Problem ist, dass damit die folgenreichste Entscheidung einer Auswertung, welche Daten überhaupt gelesen werden können, bei jemandem liegt, der nicht weiß, dass der Fall existiert.

Diese Person trifft ein vernünftiges kommerzielles Urteil. Sie schaut darauf, wie viele Kunden auf diese Anwendung treffen werden, wie stabil ihr Format ist und wie viel Entwicklungsaufwand sie kosten wird. Eine Messenger-Anwendung mit zweihundert Millionen Nutzern ist den Aufwand offensichtlich wert. Eine regionale soziale Plattform mit vierhunderttausend Nutzern, konzentriert genau in der Region, in der Ihre Gruppierung der organisierten Kriminalität tätig ist, ist ein deutlich schwierigerer Geschäftsfall. Aus der Sicht des Herstellers ist es richtig, die Umsetzung abzulehnen. Aus Ihrer Sicht, mit der Extraktion in der Hand, ist es der ganze Fall.

Versionen sind die größere Hälfte des Problems

Die Geschichte der nicht unterstützten Anwendung ist die, die erzählt wird, aber sie untertreibt das Problem. Der häufigere Fehler ist subtiler: eine unterstützte Anwendung, deren Speicherlayout sich geändert hat.

Eine Anwendung wird aktualisiert. Sie ordnet eine Tabelle neu, verschiebt eine Datei, ändert, wie sie einen Zeitstempel kodiert. Der Parser wurde gegen die vorherige Version geschrieben und liefert jetzt nichts zurück, oder, schlimmer, etwas Plausibles und Falsches. Das Werkzeug meldet die Anwendung als unterstützt, weil sie es ist, und der Analyst muss bemerken, dass die Ausgabe dünn ist.

Die Veröffentlichungszyklen von Anwendungen werden in Wochen gemessen. Die Veröffentlichungszyklen forensischer Werkzeuge werden in Monaten gemessen. Diese Lücke schließt sich nie, und es ist niemandes Schuld. Es ist Arithmetik.

Was es kostet, in den Begriffen, auf die es ankommt

Die Kosten zeigen sich gewöhnlich nicht als gescheiterte Auswertung. Sie zeigen sich still als Verringerung des Umfangs.

Ein Analyst mit drei Wochen und vierzig Asservaten verbringt nicht zwei Tage damit, eine unbekannte SQLite-Datenbank von Hand zu lesen, einen Hex-Editor daneben, auch wenn er es könnte. Er wertet aus, was das Werkzeug dekodiert hat, schreibt den Bericht darüber und vermerkt den Rest als nicht analysiert. Das ist eine vertretbare fachliche Entscheidung. So kommt es auch dazu, dass Beweismittel, die existieren, auf einem Gerät, das die Dienststelle bereits hat, in einem Fall, der bereits offen ist, am Ende nie angesehen werden.

Mit einem Fallaufkommen multipliziert ergibt das die Zahl, um die sich die Leitungen der Labore tatsächlich sorgen: der Anteil der sichergestellten Daten, der nie ausgewertet wird. Das ist kein Versagen der Triage. Es ist ein Versagen der Abdeckung, das als Triage neu eingeordnet wurde.

Die Alternative ist unbequem, aber einfach

Wenn der Engpass darin besteht, dass Parser von einem Hersteller im Voraus geschrieben werden, für Anwendungen, die er ausgewählt hat, dann besteht die Abhilfe darin, nicht mehr zu verlangen, dass ein Mensch bei einem Hersteller sie im Voraus schreibt.

Das ist inzwischen technisch auf eine Weise machbar, wie es vor fünf Jahren nicht war. Zu erkennen, wozu eine unbekannte Datenbank dient, was ihre Tabellen enthalten und wie sie sich auf die Begriffe abbilden, mit denen ein Ermittler arbeitet, Unterhaltungen, Kontakte, Standorte, ist eine Schlussfolgerungsaufgabe über Dateipfade, Schema und Inhalt zusammen. Es ist genau die Art von Aufgabe, in der generative Modelle ungewöhnlich gut sind und Klassifikatoren es nicht sind.

Der naheliegende Einwand ist der richtige. Sie können ein Modell nicht entscheiden lassen, wie Beweismittel interpretiert werden, und dem Ergebnis einfach vertrauen. Also tun Sie das nicht. Erzeugen Sie das Mapping, validieren Sie es strukturell, führen Sie es gegen eine Stichprobe der echten Daten aus und zeigen Sie dem Analysten eine Vorschau der tatsächlichen Datensätze, bevor irgendetwas angewendet wird. Wenn das Mapping die Quelle missverstanden hat, ist das sofort sichtbar, weil die Vorschau voller Unsinn ist. Der Analyst nimmt es an, korrigiert es in einem visuellen Editor oder wirft es weg.

Was sich ändert, ist nicht der Beweismaßstab. Der Analyst prüft weiterhin, und nichts gelangt ungeprüft in einen Bericht. Was sich ändert, ist, wer die Arbeit des ersten Verstehens leisten muss und wann sie stattfinden kann. Sie kann an dem Tag stattfinden, an dem der Fall sie braucht, und nicht in dem Quartal, für das ein Hersteller sie eingeplant hat.

Warum es sich lohnt, das laut zu sagen

Jedes Labor, mit dem wir gesprochen haben, hat eine Fassung derselben Geschichte, und jedes erzählt sie, als wäre sie ein lokales Ärgernis. Sie ist nicht lokal. Es ist dieselbe Einschränkung in jeder Dienststelle in jedem Land, und sie besteht, weil die ganze Branche früh eine architektonische Entscheidung getroffen und sie nie wieder aufgegriffen hat.

Sie zu benennen, ändert, wonach Sie fragen. Eine Dienststelle, die glaubt, ein Supportproblem zu haben, bittet ihren Hersteller um schnellere Veröffentlichungen, und das ist eine Bitte, die niemand erfüllen kann. Eine Dienststelle, die ein strukturelles Problem erkennt, stellt eine andere Frage: Was wäre nötig, damit die Abdeckung aufhört, etwas zu sein, worauf wir warten.

Das ist die Frage, zu deren Beantwortung VERA gebaut wurde, und der Grund, warum wir die These lieber vertreten, als das Produkt zu beschreiben.

VERA

VERA ist forensische Analysesoftware für sichergestellte Geräte. Es strukturiert eine Extraktion, danach befragt der Analyst das Asservat in einfacher Sprache, einschließlich dessen, was ein Bild zeigt. Jede Aussage des Assistenten öffnet die Quellzeile. Es läuft offline auf Ihrer eigenen Infrastruktur.

Zugang anfragen

Sehen Sie es mit einer echten Extraktion im Einsatz

Eine Dienststelle fragt nach einer Demonstration, in der Regel dreißig Minuten mit fiktiven Daten. Ein unabhängiger Sachverständiger fragt nach Zugang: Eine Person prüft die Anfrage, danach wird die Jahreslizenz über das Konto bestellt.

Zugang anfragen

Jede Anfrage wird geprüft, bevor der Zugang gewährt wird.