WinHex & X-Ways Forensics Newsletter-Archiv (deutsch)

(Sie können den Newsletter hier abonnieren.)

#152: WinHex, X-Ways Forensics und X-Ways Investigator 19.0 veröffentlicht

18. Okt. 2016

In dieser Ausgabe des Newsletters informieren wir Sie über ein weiteres Update mit vielen beachtlichen Verbesserungen, die Version 19.0.

Evaluationsversion von WinHex: https://www.x-ways.net/winhex.zip (korrekte Download-Adresse auch für Benutzer mit einer privaten, professionellen oder Specialist-Lizenz)

Kunden erhalten Download-Instruktionen, Log-In-Daten sowie Details zur Update-Berechtigung wie immer unter https://www.x-ways.net/winhex/license-d.html. Wenn Ihre Update-Berechtigung oder Lizenz abgelaufen ist, erhalten von dort Angebote zu Upgrades bzw. Lizenzverlängerungen. Das Paßwort für X-Ways Forensics wird sich übrigens in Kürze ändern.

Wenn Sie an Informationen über Service-Releases interessiert sind, wenn diese veröffentlicht werden, können Sie diese im Bereich „Announcements“ des Forums einsehen und sich bei noch aktiver Update-Berechtigung ein Konto anlegen und die Ankündigungen in diesem Bereich per E-Mail abonnieren. Bitte beachten Sie: Wenn Sie vorerst bei einer älteren Version bleiben möchten oder müssen, sollten Sie bitte zumindest das letzte Service-Release der betreffenden Version verwenden.

Schulungstermine

Köln, 13.-16. Februar
Termine im Ausland

Wenn wir Sie über weitere Termine informieren dürfen, geben Sie bitte hier Ihre E-Mail-Adresse ein.

Was ist neu in v19.0?
(Bitte beachten Sie, daß sich die meisten Änderungen nur auf X-Ways Forensics beziehen.)

Performanz

Analog zur logischen Suche unterstützt jetzt auch die Datei-Verarbeitung beim Erweitern des Datei-Überblicks mehrere Threads (nur, wenn nicht auf eine Auswahl angewandt). Dies wird aktuell als experimentell betrachtet. Abhängig von den ausgewählten Operationen und den Dateitypen im Volume, und je nach E/A-Geschwindigkeit kann dies die Performanz verdoppeln, verdreifachen oder gar vervierfachen. Je schneller Ihre Massenspeicherlösung ist (HDD, SSD, RAID) bezüglich Zugriffszeiten und Datentransferrate, desto mehr Zeit sparen Sie prozentual. Dieses Parallelisierungs-Feature wird noch als experimentell und nicht vollständig erachtet, aber das Zeitersparpotential in einer der wichtigsten und zeitintensivsten Programmfunktionen ist bereits jetzt erheblich.

Die Auswahl mehrerer Threads hat nur Auswirkung bei der Verarbeitung von Asservaten, die Datenträger-Sicherungen oder Verzeichnisse sind, nicht bei Datenträgern. Wenn Sie nur einen Thread auswählen, funktioniert es wie bei X-Ways Forensics Versionen vor 19.0. Falls Sie zwei oder mehr Threads auswählen, findet die Verarbeitung in zusätzlichen Arbeiter-Threads statt (so viele, wie Sie auswählen) und der Haupt-Thread des Prozesses bleibt untätig, womit die Oberfläche reaktionsfreudig bleibt. In X-Ways Investigator können bis zu zwei Arbeiter-Threads verwendet werden, in X-Ways Forensics bis zu acht, sofern Ihre CPU dies unterstützt. Falls die Verarbeitung mit mehreren Threads abstürzt, kann Ihnen das Programm beim nächsten Neustart nicht mitteilen, welche Datei vermutlich den Absturz verursacht hat. Bitte beachten Sie, daß bei ohnehin sehr E/A-intensiven Operationen, wie z.B. beim Hashen, nicht mehr viel gewonnen werden kann, wenn das Massenspeichermedium langsam ist.

Die dateiweise Verarbeitung mittels X-Tensions (durch Aufrufe von XT_ProcessItem oder XT_ProcessItemEx) wird ebenfalls parallelisiert, sofern die X-Tension sich selbst als threadsicher identifiziert. Die Verarbeitung von Dateien in Archiven ist intern aktuell von der Parallelisierung ausgeschlossen. Die Parallelisierungsoption wird aktuell nicht angeboten, wenn die Indexierung ausgewählt ist.
Die Zeit, die die Erweiterung des Datei-Überblicks benötigt hat, wird jetzt im Nachrichtenfenster angezeigt, sofern auf ausgwählte Asservate angewandt. Nützlich, um eigene Performanz-Tests mit einzelnen oder mehreren Threads durchzuführen.
Für Performanz-Vergleichstests möchten Sie unter Umständen alle Datei-Puffer entsorgen, die Windows bei hinreichendem Speicherplatz pflegt, um dieselben Operationen auf derselben Datenträger-Sicherung erneut laufen zu lassen, ohne verzerrte Ergebnisse beim zweiten Durchlauf, weil weniger Festplattenoperationen notwendig sind. Eine Funktion zur Wiederverwendung/Erschöpfung überschüssigen Arbeitsspeichers findet sich jetzt im Dialog Optionen | Sicherheit. Klicken Sie auf den Schalter mit dem Recycling-Symbol.
Ein unbeschriftetes (aber mit Tool-Tip ausgestattetes) Kontrollkästchen im Dialogfenster zum Datei-Überblick-Erweitern kann X-Ways Forensics jetzt dazu bringen, anzuzeigen, welche Unteroperationen aktuell auf die aktuell verarbeitete Datei angewandt wird. Eine aus drei Buchstaben bestehende Abkürzung wird angezeigt mit den folgenden Bedeutungen:

Sig: Dateityp-Prüfung
Hsh: Hashen
Vid: vereinzelte Standbilder aus Videos erzeugen
Idx: Vorverarbeitung der Original-Dateiinhalte für die Indexierung
Dec: Text-Dekodierung für die Indexierung
IdX: Vorverarbeitung des dekodierten Texts für die Indexierung
Emb: Suche nach eingebetteten Daten
PDN: PhotoDNA-Datenbank-Abgleich
Pic: andere Bildanalyse-Schritte
Eml: E-Mail-Extraktion
Fuz: FuzZyDoc-Datenbank-Abgleich
Met: Metadaten-Extraktion
Enc: Dateiformatspezifischer Verschlüsselungstest
Ent: Entropie-Prüfung
Arc: Aufnahme von Dateien in Archiven in den Datei-Überblick

Dies kann lehrreich sein, indem es Nutzern eine bessere Vorstellung davon vermittelt, wie aufwendig bestimmte Unteroperationen sind und wieviel Zeit gespart werden könnte, indem man diese nicht auswählt, falls nicht wirklich notwendig. Es könnte sich auch bei der Fehleridentifikation als nützlich herausstellen. Ob diese Option auf bestimmten Systemen die Verarbeitung verlangsamt, wurde nicht getestet.
Eine neue Option ermöglicht, sehr große Dateien nicht zu hashen. Dies kann sehr viel Zeit und Festplattenoperationen sparen. Für sehr große Dateien (wie z.B. Backups, virtuelle Festplatten, Datenbanken, Pagefiles, $UsnJrnl:$J, ...) weil viele davon einmalig sind und nicht basierend auf Hash-Werten gesucht werden oder ihre Hash-Werte in Hash-Datenbanken bekannter Dateien enthalten sind. Ein Grund, diese Option nicht zu verwenden, wäre beispielsweise, wenn Sie nach hochauflösenden Raubkopien von Filmen suchen.
PhotoDNA-Abgleich um ca. 20% beschleunigt!
PhotoDNA-Hash-Werte werden jetzt nur berechnet und abgeglichen, wenn das Bild eine Gesamtanzahl an Pixeln beinhaltet, die ein nutzerdefiniertes Minimum überschreitet (Breite mal Höhe). Dies vermeidet Datenbank-Suchen, die in sehr großen PhotoDNA-Hash-Datenbanken zeitaufwendig sein können und für kleine, wertlose Bilder keinen Nutzen bringen. Die erlaubten Mindestmaße sind 50x50 Pixel, was in früheren Versionen die implizite Bedingung war. Der PhotoDNA-Algorithmus benötigt zwingend eine bestimmte Mindestanzahl an Pixeln, um aussagefähige Ergebnisse zu produzieren.
Die benötigte Mindest-Pixelanzahl in einem Bild für die Berechnung des Hautfarbanteils und die Prüfung auf Schwarz-Weiß ist jetzt nutzerdefinierbar. Falls ein Bilder weniger Pixel hat, wird es als "irrelevant" in der Analyse-Spalte angezeigt, und ein kleines bißchen Zeit wird gespart, indem die Farben nicht geprüft werden. Die Mindesthöhe und -breite waren in allen früheren 16 Pixel. Der neue Standardwert ist jetzt 32x32=1024 Pixel insgesamt.
Die Verarbeitung von EDB-Datenbanken wurde überarbeitet, für verbesserte Geschwindigkeit und Stabilität bei gleichzeitig reduziertem Ressourcenverbrauch. Eine sehr selten auftretende Endlosschleife bei der Verarbeitung von WebCache-Datenbanken wurde behoben.
Fähigkeit, zur Beschleunigung beim Hash-Abgleich größere Teile von großen Hash-Datenbanken in den Hauptspeicher zu laden, und der Nutzer kann jetzt anpassen, wieviel des verfügbaren Speichers verwendet werden sollte.
Die Option, beschädigte Festplattenbereiche beim Klonen von Festplatten zu vermeiden, indem Sektoren übersprungen werden, wenn ein defekter Sektor erkannt wurde, kann jetzt viel größere Sprünge machen und springt immer exakt um die vom Nutzer festgelegte Anzahl Sektoren weiter.

Technische Spezifikationen

Pro Hash-Set und pro Hash-Datenbank werden jetzt bis zu 2³¹ Hash-Werte unterstützt statt 2³⁰ in früheren Versionen.
Fähigkeit, mit der Viewer-Komponente Dateien ein- bzw. in der Vorschau anzusehen, die größer als 2 GB sind.
16-, 32- und 64-Bit-Prüfsummen werden jetzt nicht mehr Byte-weise mit einem Akkumulator der angegebenen Größe berechnet, sondern sind die Summen von Integer-Einheiten der jeweiligen Größe.
Um Breitbildschirme besser zu nutzen, und um Ermittler insbesondere in Asien besser zu unterstützen, die im selben Fall mit in verschiedenen Zeichensätzen und Codepages kodiertem Text konfroniert sein können, ist es jetzt abhängig vom Lizenztyp möglich, gleichzeitig mehrere Textinterpretationen der Binärdaten in der Textanzeige des Hex Editors darzustellen. Sie können die Zeichensätze/Codepages für jede Spalte einzeln im Ansicht-Menü auswählen. Dies ist auch nützlich, um bei der Durchsicht der Roh-Daten von Outlook-PST-Dateien mit Cipher-Kodierung kodierten ANSI-Text, kodierten Unicode-Text und völlig unkodierten Text gleichzeitig lesen zu können.

Persönliche Lizenz für WinHex: nur 1 Zeichensatz gleichzeitig
Professionelle Lizenz für WinHex: bis zu 2 Zeichensätze gleichzeitig
Specialist Lizenz für WinHex, X-Ways Investigator: bis zu 3 Zeichensätze gleichzeitig
WinHex Lab Edition, X-Ways Forensics: bis zu 4 Zeichensätze gleichzeitig

Bitte beachten Sie, daß jede Texteingabe von der Tastatur als auf der aktuell im System eingestellten ANSI-Codepage basierend interpretiert wird, es sei denn, die primäre Textspalte ist auf die IBM/OEM/DOS-Codepage 850 (Latin I) eingestellt, in welchem Fall die Eingabe als auf dieser Codepage basierend interpretiert wird, genau wie in bisherigen Versionen von WinHex/X-Ways Forensics.

Verzeichnis-Browser

Neue Spalte "Existent": Zeigt an, ob eine Datei eine existierende Datei oder ein Unterobjekt einer existierenden Datei ist oder nicht (existierend gemäß dem Bezugssystem, z. B. Dateisystem), entweder mit einem Häkchen oder einem mathematischen Symbol oder in natürlicher Sprache, abhängig von den Notationsoptionen. Ein dritter Zustand ist "virtuell". Um basierend auf dem Existenzzustand zu filtern, verwenden Sie bitte den Beschreibungsfilter. Bitte beachten Sie, daß Sie auch nach dem Existenzzustand gruppieren können (s. Verzeichnis-Browser-Optionen) und nach dieser Spalte sortieren können.
Neue Spalte "Vollpfad" (Specialist-Lizenz oder höher): Der Vollpfad enthält den Namen der Datei bzw. des Verzeichnisses selbst. Nach dem Vollpfad zu sortieren, ergibt eine nützliche Reihenfolge, weil Unterobjekte dabei direkt ihren jeweiligen Eltern folgen.
Es gibt jetzt eine separate Spalte für den optionalen 2. Hash-Wert, ebenfalls mit Filter ausgestattet. Zuvor war eine einzige Spalte optional für beide Hash-Werte zuständig.
Neue Spalte "Gruppe" (forensische Lizenz): In neu erstellten Datei-Überblicken zeigt diese Spalte die ID der Gruppe an, die einer Datei in Linux-Dateisystemen zugeordnet ist..
Neue Spalte "Offset im Dateisystem" (Specialist-Lizenz oder höher): Zeigt den Offset der definierenden Struktur einer Datei oder eines Verzeichnisses im Dateisystem, d.h. die Struktur, die die Basis für die Aufnahme der Datei in den Datei-Überblick bildet. Dieser Offset ist der Ort, an dem Sie manuell Details prüfen können, falls es irgendwelche Zweifel darüber gibt, wo X-Ways Forensics die Metadaten von Dateisystemebene her hat. Dies ist auch der Ort, an dem Sie geeignete Templates für eine alternative Interpretation anwenden können und wohin Sie benachteiligte Nutzer anderer Werkzeuge verweisen können, die solche wichtigen Orte eventuell nicht finden können oder bestimmte gelöschte Dateien gar nicht angezeigt bekommen. Aus Sektoren ausgegliederte oder in anderen Dateien eingebettete Dateien besitzen aus offensichtlichen Gründen keinen Offset im Dateisystem (oder im Fall gecarvter Dateien ist dieser X-Ways Forensics zumindest nicht bekannt). Der Offset im Dateisystem ist auch der Ort, an den Sie mit dem speziellen Kontextmenübefehl zum Aufsuchen des FILE-Records/der Inode/des Verzeichniseintrags/Catalog Key, etc navigieren, wie von allen Versionen bekannt. Der Kontextmenübefehl zum Sortieren nach den Offsets der definierenden Strukturen ist jetzt nicht mehr nötig, da Nutzer nach dieser Spalte sortieren können.
Option, Dateien, die Sie ausdrücklich an ein bestimmtes Verzeichnis oder eine Datei anhängen, als das zu klassifizieren, was sie tatsächlich sind, z.B. Video-Einzelbilder, die außerhalb von X-Ways Forensics erzeugt wurde, E-Mails, die außerhalb von X-Ways Forensics aus E-Mail-Archiven extrahiert wurden, OLE2-Objekte, Datei-Anhänge verschiedener Arten (insbesondere von PDF-Dokumenten), etc. etc. Sofern korrekt als Video-Einzelbilder klassifiziert, werden die angehängten Bilder beispielsweise auch als Vorschau für das jeweilige übergeordnete Video verwendet. Die Klassifizierung ist in der Beschreibungsspalte zu sehen.
Dateien, die ihren jeweiligen Original-Entsprechungen im Datei-Überblick automatisch per eindeutiger ID angehängt werden, übernehmen jetzt die Klassifikation der Original-Datei. Außer für Original-Dateien ohne gesonderte Klassifikatiion, in diesem Fall werden die angehängten Dateien als angehängte Dateien klassifiziert.

Datenträger-/Image-Handhabung

Fähigkeit, die interne Beschreibung eines Images und den Namen des Bearbeiters beim Sichern eines Datenträgers automatisch von der Kommandozeile festzulegen. Zum Beispiel erzeugt
:1 "|e01|G:\Test.e01|My description|My name
eine Sicherung des Datenträgers mit der internen Nummer 1 in Windows im .e01 Evidence-File-Format mit Namen "Test.e01" im Verzeichnis G:, mit der Beschreibung "My description" und dem Namen "My name". Die Parameter werden von Vertikalstrichen (Pipes) getrennt und dürfen Leerzeichen enthalten. Die Reihenfolge der Parameter ist fix. Beschreibung und Ermittler sind optional.
Eine neue Option erlaubt es, den Arbeitsspeicher kurz vor der Hash-Überprüfung so auszulasten, daß die von Windows verwendeten Dateipuffer automatisch aufgelöst werden und ein Lesen der Image-Daten direkt von der Platte erzwungen wird (so daß die Daten nicht aus dem Speicherpuffer entnommen werden). Diese Option besteht für kleine Images und für etwas paranoide oder höchst sorgfältige Nutzer. Sie ist nicht notwendig für Sicherungen, die deutlich größer sind, als der im System installierte Arbeitsspeicher, da in diesem Fall die anfänglichen Teile nicht mehr im Puffer sind, bis die letzten Teile endlich geschrieben sind, und die letzten Teile sind nicht mehr im Puffer, wenn sie zur Überprüfung dran sind, da in der Zwischenzeit die anfänglichen Teile zur Überprüfung wieder dorthin geladen wurden. Diese Option kann eine kleine, temporäre Auswirkung auf die Systemperformanz haben und die Hash-Überprüfung kann etwas langsamer sein als üblich.
X-Ways Forensics unterstützt jetzt mehrere Images mit identischem Namen im selben Fall, in allen Fällen, die von v16.1 oder später erzeugt wurden. Nützlich für Nutzer, die aus irgendwelchen Gründen Datenträger mit einem Werkzeug sichern, das allen Sicherungen denselben Namen zuweist. Auch nützlich, wenn Sie mehrere Images mit demselben Namen innerhalb einer Datenträger-Sicherung vorfinden (nicht ungewöhnlich für vom Verdächtigen verwendete virtuelle Festplatten), und Sie diese dann nicht einzeln umbenennen müssen. Bitte beachten Sie, daß Sie nicht mit Asservaten, die von mehrfach verwendeten Namen betroffen sind, in v18.9 oder früher arbeiten sollten, da diese Versionen ggf. den falschen Datei-Überblick laden könnten.
Eine neue "allgemeine" Option läßt den Benutzer beim Interpretieren von Roh-Images immer die bevorzugte Handhabung bestätigen, d. h. von welcher Art von Image (Volume oder Disk) ausgegangen werden soll, welche Sektorgröße angenommen werden soll und in welchem Pfad ggf. weitere Image-Datei-Segmente gesucht werden sollen. Das ist genau das, was auch passiert, wenn Sie die Umsch-Taste gedrückt halten während des Interpretierens eines Images als Datenträger oder beim Hinzufügen eines Images zum Fall. Normalerweise nicht nötig, wenn das Image von X-Ways Forensics selbst erzeugt wurde, aber dennoch, bestimmte Wechseldatenträger (USB-Sticks und Speicherkarten) können zu unterschiedlichen Zeiten sowohl als Volume als auch als partitionierter Datenträger formatiert und verwendet worden sein. In solchen Situationen kann das Interpretieren als Volume und als Disk unterschiedliche Dateisysteme zum Vorschein bringen, die einander überlappen.
Die Optionen zum Hervorheben von freiem und Schlupfspeicher für Specialist-Lizenzen und höher sind in das Dialogfenster für allgemeine Optionen verschoben worden.
Option, bereits aus Dateien extrahierte Metadaten mit in Datei-Containern zu speichern, damit der Empfänger diese direkt sehen kann, ohne erneut Metadaten extrahieren lassen zu müssen.
LVM2-Container-Partitionen werden jetzt als solche auch dann erkannt, wenn der zugewiesene Partitionstyp in MBR oder GPT falsch ist.
Fähigkeit, Ext*-Dateisysteme mit einer Blockgröße zu parsen, die kleiner ist als die Sektorgröße des sie umgebenden physischen Images, was bei Android-Geräten vorkommen kann.
Falls der Benutzer die Interpretation eines Volumes als NTFS erzwingt, weil der Boot-Sektor das Dateisystem nicht mehr als NTFS identifiziert und der Backup-Boot-Sektor ebenfalls fehlt, fragt WinHex jetzt nach der erwarteten Cluster-Größe, damit Sie keinen fiktiven Boot-Sektor mehr überlagern müssen, um den Speicherort von Dateidaten richtig interpretiert zu bekommen (unter der Annahme, daß die gründliche Dateisystem-Datenstruktur-Suche FILE-Records findet).

PhotoDNA

Ein neuer Schalter mit einem Lupensymbol ermöglicht Ihnen jetzt, die Datenbank auf Anwesenheit eines spezifischen Hash-Wertes zu prüfen, den Sie in Hex ASCII oder Base64 angeben. Sofern es einen Treffer gibt, wird der Name der Hash-Sammlung angezeigt, die den Hash-Wert enthält. Sofern der betreffende Eintrag in der Datenbank eine Textbeschreibung besitzt, wird diese Beschreibung ebenfalls angezeigt. Bis zu 19 Treffer werden angezeigt, jeder mit seiner jeweiligen Genauigkeit (je höher, desto genauer; selbe einfache Skala wie z. B. bein benutzerdefinierten Strengegrad für den Abgleich, d.h. Level 1 bedeutet sehr grobe Treffer). Sie haben die Möglichkeit, die Ergebnisliste auf genauere Treffer zu beschränken, indem Sie einen höheren Strengegrad erzwingen, was nützlich ist, wenn mehr Treffer existieren, als angezeigt werden können.
Fragt den Nutzer nochmal, falls der niedrigstmögliche Strengegrad (Level 1) beim PhotoDNA-Abgleich ausgewählt ist, da diese Einstellung gelegentlich falsche Treffer liefert. Sie wird in X-Ways Forensics nur angeboten, weil die ursprünglichen Entwickler von PhotoDNA diesen als möglichen Startwert vorgeschlagen hatten. Der empfohlene und voreingestellte Strengegrad in X-Ways Forensics ist Level 3.
Option, bequem und frei den Pfad für die PhotoDNA-Datenbank in den allgemeinen Optionen festzulegen. Nutzer können jederzeit von einer zu einer anderen Datenbank wechseln.
Option, Prüfungen auf Duplikate und Konsistenz beim PhotoDNA-Import komplett zu überspringen, was potentiell mehrere Stunden spart, mit dem Nachteil, daß der Abgleich beim Erweitern des Datei-Überblicks länger dauert und für Varianten desselben Bilder u.U. unterschiedliche Klassifikationen gemeldet werden (nur zutreffend, falls die Hash-Sammlungen, die Sie importieren, untereinander nicht sehr konsistent sind oder sich sogar widersprechen).
Die Umkategorisierung bestehender PhotoDNA-Datenbankeinträge, die neu importierten Einträgen entsprechen, ist jetzt gründlicher und betrifft nicht mehr nur den besten übereinstimmenden Eintrag. Dies bedeutet allerdings langsameres Importieren.
Option, ausgewählte PhotoDNA-Kategorien als "bevorzugt" zu kategorisieren, mit einem schwarzen Stern. Falls für ein Bild beim Abgleich Treffer in verschiedenen Kategorien gefunden werden, bekommen die bevorzugten Priorität. Solche bevorzugten Kategorien werden auch dann als Treffer gemeldet, wenn andere Treffer mit nicht bevorzugten Kategorien eigentlich genauere Treffer sind. Dies ist nützlich, wenn Sie zum Beispiel in Ihrer Datenbank Kategorien haben, deren Genauigkeit und Verwendbarkeit Sie vertrauen, und andere, denen Sie weniger trauen, weil Sie beispielsweise wissen, daß diese Fehler enthalten (z.B. das gleiche Bild sowohl als KP als auch irrelevant klassifiziert) und/oder weil diese aus ausländischen Quellen mit ggf. anderen Gesetzen und Vorschriften stammen.
Wenn beim Import neuer Hash-Werte in die interne PhotoDNA-Datenbank einer der neuen Hash-Werte einem bestehenden oder einem ebenfalls neuen Hash-Wert sehr ähnlich ist, kann X-Ways Forensics den bisherigen Hash-Wert durch den neuen komplett ersetzen, um die Datenbank schlanker und weniger redundant zu halten. Dies passiert, wenn die Abweichung zwischen den beiden Werten unter einem bestimmten Grenzwert liegt. Dieser Grenzwert wurde erhöht, d.h. die Genauigkeit für die Redundanzverringerung wurde verringert, was bedeutet, daß mehr Hash-Werte als ähnlich erachtet und entfernt werden.
Die zwei Strengegrade für die Redundanzverringerung und Konsistenzverbesserung beim Import in die PhotoDNA-Datenbank sind jetzt beide nutzerdefinierbar.
Die Statistik am Ende eines PhotoDNA-Imports zeigt jetzt auch an, wie viele bereits existierende Einträge in der Datenbank eine neue Klassifizierung erhalten haben.
Fähigkeit, ausgewählte Hash-Sammlungen aus der internen PhotoDNA-Hash-Datenbank in Textdateien zu exportieren, um diese mit anderen Nutzern auszutauschen, oder um zu prüfen, welche Hash-Werte enthalten bzw. welche als Duplikate entfernt worden sind, etc.
Das Parsen von ODATA/JSON-Dateien wurde überarbeitet.

Fallbericht

Die Formatierungsdefinitionen im "Cascading Style Sheet" (CSS) für den Fallbericht in der Textdatei "Case Report.txt" besitzen jetzt reichlich Erläuterungen, die es einfacher machen sollten, die Formatierung nach Ihren Wünschen anzupassen.
Falls .eml-Dateien direkt als HTML im Browser angezeigt werden (die sogenannte alternative Darstellung), können die Anhänge jetzt optional zusammen mit den .eml-Dateien kopiert und direkt aus der HTML-Darstellung verlinkt werden.
In diesem Zusammenhang: Die Darstellung von .eml-Dateien ohne die Header und die alternative .eml-Darstellung sind jetzt getrennte Optionen, die miteinander kombiniert werden können.
Möglichkeit, die Beschreibung von Berichtstabellen direkt in den Dialogfenstern für den Berichtstabellenfilter und für die Erzeugung und Verwaltung von Berichtstabellen und -verknüpfungen zu sehen.

Suchtreffer

Block-Hash-Treffer können jetzt größer als ~ 64 KB sein. Größere Treffer müssen daher nicht mehr in Fragmente von je ~ 64 KB aufgeteilt werden.
Physische Suchtreffer (d.h. in Disk/Partition/Volume-Modus definierte) können jetzt ebenfalls größer als ~ 64 KB sein, z. B. selbst definierte Suchtreffer (sog. eigene Suchtreffer).
Die Vergleichsfunktion wurde aus dem Menü Datei-Tools in das Menü Extras verschoben (da sie ggf. für Datenträger noch nützlicher ist als für Dateien) und wurde für Nutzer von X-Ways Forensics weiter überarbeitet. Sie besitzt jetzt die Möglichkeit, die identifizierten unterschiedlichen oder identischen Datenbereiche als Suchtreffer (ein Eintrag pro zutreffendem Bereich) anstelle einer Textdatei (eine Zeile pro zutreffendem Byte) auszugeben, für bequemere Einsicht und Navigation direkt im Programm in der Suchtrefferliste, analog zu Block-Hash-Treffern. Diese Option ist nur verfügbar, wenn zumindest die zweite Datenquelle ein Asservat ist. Das Ergebnis ist in der Suchtrefferliste dieses Asservats zu sehen. Nützlich beispielsweise für Nutzer, die geklonte Festplatten mit kleineren Änderungen miteinander vergleichen wollen, wenn sich deren Hash-Werte unterscheiden, oder eine der beiden Platten noch etwas verwendet wurde, um die tatsächlichen Unterschiede zu identifizieren und besser zu verstehen, was diese verursacht hat. Auch nützlich, um die an einem RAID-Level 0 System beteiligten Platten oder Mirror-Volumes zu vergleichen, um zu prüfen, ob diese tatsächlich völlig identisch sind, bzw. falls nicht, die tatsächlich abweichenden Bereiche leicht zu finden, zu sehen wie groß diese sind, was für Daten diese enthalten, und um zu beurteilen, ob auch die zweite Kopie einer vollständigen Untersuchung unterzogen werden muß, einschließlich Carven, Begriffssuchen, etc. Bitte bedenken Sie auch, daß Sie zum visuellen Vergleich der Daten in verschiedenen Datenfenstern auf Unterschiede an einander entsprechenden Offsets den Befehl Synchronisieren & vergleichen einsetzen können.
Die Länge der Block-Hash-Treffer, nutzerdefinierter physischer Suchtreffer und der Vergleichsergebnisse wird jetzt in der Suchtrefferliste in der Größenspalte angezeigt. Dies ist beispielsweise nützlich, um Block-Hash-Treffer nach ihrer Länge sortieren zu können und die relevanteren (größeren) Übereinstimmungen zuerst zu sehen.
Die maximale Anzahl Suchbegriffe, die in der Suchbegriffsspalte angezeigt wird, wurde von 25 auf 50 erhöht.

Dateityp-Unterstützung

Die Abdeckung der Generator-Signaturen wurde deutlich weiter zur Perfektion gebraucht.
Die spartan.edb Datenbank des Edge Browsers wird für die Metadaten-Extraktion unterstützt. Eine HTML-formatierte Vorschau wird erzeugt und Ereignisse werden zur Ereignisliste hinzugefügt für alle Favoriten und ReadingList-Einträge.
Windows PowerShell Events und ihre wichtigsten Werte werden aus Windows-Event-Logs extrahiert und in die Ereignisliste ausgegeben. Diese Ereignisse beinhalten Start und Stop der Konsole und die (ggf. erfolglose) Ausführung von Skripten (einschließlich deren Pfad). Für Untersuchungen von Schadprogrammen potentiell nützlich.
Die interne Behandlung von Dateiarchiven wurde überarbeitet.
Die Extraktion von Exif-Metadaten aus Nikon-Kameras wurde verbessert.
MP3-Metadaten-Extraktion überarbeitet. Eine sinnvolle Auswahl wird in die Metadaten-Spalte ausgegeben, um besser zwischen MP3-Dateien verschiedener Arten oder aus verschiedenen Quellen unterscheiden zu können, z.B. Sprachaufnahmen oder kommerzielle Audio-Dateien. Bitte beachten Sie, daß Sie auch nach generischer Relevanz sortieren lassen können, um zu versuchen solche Dateien zu unterscheiden.
Zeitstempel in der HTML-Vorschau von EDB-Datenbanken werden jetzt basierend auf der nutzerdefinierten Zeitzone anstatt UTC ausgegeben.
Die Gewichtung, mit der die Aktualität und die Größe einer Datei ihre berechnete generische Relevanz beeinflussen, ist jetzt nutzerdefinierbar. 100% bedeutet Standard-Gewichtung. 50% bedeutet halb soviel. 0% bedeutet, der Faktor hat gar keinen Effekt. Maximum ist 255%.
Die berechnete generische Relevanz wird jetzt als Zahlenwert dargestellt.

Datei-Header-Signatur-Suche

Die Zahl der falschen Carving-Treffer Signatur-Suche mit vermuteter NTFS-Kompression wurde reduziert.
Falls die Datei-Header-Signatur-Suche abstürzt beim Parsen der Daten, unter Annahme eines bestimmten Dateiformats, die in einem bestimmten Sektor beginnen, wurde bisher nur ein solcher Sektor festgehalten und automatisch übersprungen, wenn die Datei-Header-Signatur-Suche erneut gestartet wurde. Jetzt werden bis zu acht solcher Sektornummern festgehalten, und sie werden in den Eigenschaften des Asservats gespeichert, statt im Datei-Überblick, was bedeutet, daß die Informationen nicht verloren gehen, wenn ein neuer Datei-Überblick erzeugt wird. Diese können eingesehen und bearbeitet werden, indem man auf den neuen "..." Schalter im Dialogfenster für die Asservat-Eigenschaften klickt.
Datei-Header-Signaturen können in den "File Type Signatures *.txt"-Dateien jetzt optional direkt (nicht in GREP) festgehalten werden, mit dem neuen Flag "d". Nützlich beispielsweise, wenn Sie mit GREP-Notation nicht sonderlich vertraut sind, oder kein GREP brauchen und die Zeichen einfach nur wörtlich basierend auf der Codepage Ihres aktuellen Windows-Systems interpretiert haben möchten, ohne darüber nachdenken zu müssen, ob bestimmte Zeichen in GREP Sonderbedeutung haben. Zum Beispiel ist <?xml version="1 eine gültige Signatur für bestimmte XML-Dateien, funktioniert aber nur mit dem neuen "direkt"-Flag, da das Fragezeichen in GREP Sonderbedeutung hat, die für diese Signatur intern eine andere Byte-Wert-Sequenz ergeben würde, falls der Ausdruck in GREP interpretiert wird, und würde bei aktiver GREP-Interpretation keinerlei Treffer ergeben.
Ein neues Flag "L" in "File Type Signatures Search.txt" identifiziert Verweise, die lediglich andere Definitionen referenzieren. Nützlich beispielsweise, um einen Eintrag für OpenOffice-Dateien zu haben, der von einigen Nutzern vermisst wurde, und dessen Abwesenheit zu der Fehlannahme führt, daß es nicht möglich ist, OpenOffice-Dateien mit WinHex oder X-Ways Forensics zu carven. Falls der Eintrag für OpenOffice-Dateien zum Carven ausgewählt wird, wählt dies intern automatisch ZIP-Archive zum Carven aus, was Sinn ergibt, da OpenOffice-Dateien technisch ZIP-Dateien sind und als solche auch gecarvt werden können. Der Nachteil ist nur, daß auch ZIP-Archive gecarvt werden, die keine OpenOffice-Dateien sind. Allerdings können diese dank der internen Dateityp-Erkennung voneinander unterschieden werden, beispielsweise auf der Basis der automatisch zugewiesenen Dateierweiterung.

X-Tensions API

Flags, um Kommentare und extrahierte Metadaten zu Dateien in Datei-Container zu übernehmen, wurden definiert.
Neue X-Tensions API Funktion: XWF_SetHashValue.
Dokumentation aktualisiert.

Verschiedenes

Beim Import von Hash-Werten aus NSRL RDS, wenn Sie das Hash-Set als irrelevant klassifizieren, werden als besonders oder als bösartig gekennzeichnete Hash-Werte ignoriert (nicht importiert). Wenn Sie das Hash-Set als verdächtig klassifizieren, werden nur als bösartig gekennzeichnete Hash-Werte importiert. Wenn Sie das Hash-Set als unkategorisiert kennzeichnen, werden nur Werte importiert, die als besonders klassifiziert sind, oder ein unbekanntes Flag besitzen. Wenn Sie also alle Hash-Werte importieren möchten, können Sie dieselbe NSRL-Hash-Set-Datei dreimal importieren, mit jeweils anderer Klassifizierung, und alle Hash-Werte kommen in angemessen klassifizierte interne Hash-Sets.
Wiederherstellen/Kopieren: Option, Dateien zu überspringen, wenn identisch benannte Dateien im Ausgabeverzeichnis bereits existieren.
Beim Start einer weiteren Instanz wird Ihnen jetzt angezeigt, welche Instanzen mit jeweils welchem Fall bereits laufen, und Sie können auswählen, exakt welche dieser Instanzen Sie analysieren oder wiederbeleben möchten, und Sie haben jetzt zusätzlich die Möglichkeit, eine bestimmte Instanz direkt zu beenden, wie mit dem Windows Task Manager (aber mit der Sicherheit, die korrekte Instanz zu erwischen, da Sie den Namen des jeweiligen Falles sehen können).
Fortschrittsbenachrichtigungen werden jetzt optional nur verschickt, wenn der Bildschirm gesperrt ist, d.h. der Benutzer bekanntermaßen nicht am Arbeitsplatz ist.
Die chinesische Übersetzung ist jetzt mit jedem Lizenztyp verfügbar. (Besonders wichtige Information im deutschsprachigen Newsletter.)
Viele kleinere Verbesserungen.
Einige kleinere Korrekturen.
Die Programmhilfe und das Benutzerhandbuch wurden auf den Stand von v19.0 gebracht.

Änderungen der Service-Releases von v18.9

SR-1: Fixed inability to convert certain old volume snapshots to the current format.
SR-1: Fixed synchronization of report table associations for multiple examiners in the same case.
SR-1: Fixed exception errors that could occur when viewing the SAM registry hive.
SR-1: Inline files embedded in original .eml/.emlx files are now extracted and provided as child objects.
SR-1: Avoided "Hash database not suitable for matching" error message in certain situations.
SR-2: No longer ignores certain FILE records deleted by certain non-Windows NTFS file system drivers.
SR-2: Fixed an instability issue that could occur when parsing certain olk14Message files.
SR-2: Fixed problems with EDB database processing.
SR-2: The Description filter option "list respective parent video as well" had a problematic effect when checked if the check box was invisible. That was fixed.
SR-3: Fixed crashes that could occur when loading certain TIFF and olk14message files.
SR-3: The creation of report tables for group IDs of files whose group permissions are different from the permissions of others (only v18.9) is now optional (see volume snapshot options), and should best be inactive when parsing Android Ext4* file systems because of the sheer number of defined user groups.
SR-3: Quoted printable decoding in the alternative .eml preview now also for multi-part messages.
SR-3: Creation timestamps in orphaned inodes of Ext4 file systems, where available, are now included in the volume snapshot.
SR-4: Automatic hash verification of multi-segment images immediately after creation failed in v18.9 even though the images were fine. That was fixed.
SR-5: In v18.6 SR-4 and later (but not v18.8), when trying to resolve conflicting categorizations in newly imported PhotoDNA hash values, the category of some existing hash values in the database may have been inadvertently changed. That was fixed.
SR-5: Accelerated duplicate and consistency checks when importing huge PhotoDNA hash set collections.
SR-5: PhotoDNA import logic generally slightly revised.
SR-5: If during the import of a ProjectVic database it is discovered that the same picture is categorized as child abuse and child exploitation at the same time, this is still counted as an inconsistency, but such instances are no longer specifically brought to the user's attention. The first 10 encountered other conflicting classifications, if any, are still output in great detail, and the affected PhotoDNA hash values are now listed in Base64 notation instead of Hex ASCII, i.e. in the same encoding as used in ODATA JSON files for easier reference.
SR-5: Classification inconsistencies are now reported also when importing X-Ways Forensics PhotoDNA hash databases.
SR-5: Ability to import extracted metadata from evidence file containers as stored in containers by v19.0 and later.
SR-6: The recommended data reduction no longer causes directory browser cells of red X files to be omitted from logical searches.
SR-6: An exception error was avoided that could occur during assembler opcode interpretation by the Data Interpreter in v18.9.
SR-6: Fixed a rare exception error that could occur when parsing .evt event log files.
SR-6: The values of some integer fields in .evtx event log files were not output in the HTML previews. That was fixed.
SR-6: With certain case report settings certain copied files were not linked. That was fixed.
SR-7: A change of internal Windows behavior introduced with Windows 10 Anniversary Update caused instability when using Details mode. That effect is now prevented.
SR-7: Fixed missing update of the gallery in certain situations when the listing of files in the directory browser was changed.
SR-8: X-Tension API: A new flag (XT_PREPARE_TARGETZEROBYTEFILES) now allows an X-Tension to tell X-Ways Forensics that it wishes to be called also for files with a size of 0 bytes.SR-8: The "Other" option of the Owner filter did not always work correctly for files from file systems other than NTFS. That was fixed.
SR-8: The option to jump to a specified absolute disk sector number within its respective partition did not work quite right if partitions overlapped. That was fixed.
SR-8: Fixed problem of missing date in the 2nd timestamp column of weekly index.dat files.
SR-8: Fixed an exception error that could occur when taking a snapshot of Ext3/Ext4 volumes with WinHex Lab Edition or WinHex with a specialist license.
SR-8: Some other exception errors fixed.
SR-9: In the registry viewer in v18.9 some rare values or keys were not displayed or triggered an exception error. That was fixed.
SR-10: Fixed an exception error in the Export List command that occurred when not working with a case.
SR-10: Fixed instability resulting from SQLite databases with 100,000 embedded binary objects or more.
SR-10: Selecting values in the registry viewer that are stored beyond the first 64 MB of a registry hive did not update the block in the underlying data window and or the information in the lower right corner of the registry viewer. That was fixed.
SR-10: Timestamps extracted from registry hives were not presented correctly to local time for the event list. That was fixed.
SR-10: Fixed an exception error that could occur when running a file header signature search on a partitioned disk with overlapping partitions.

Wir hoffen, Sie bald wieder auf http://www.x-ways.net zu sehen, oder bei Facebook oder Twitter. Bitte leiten Sie diesen Newsletter an andere Interessenten weiter. Anmelden kann man sich (z. B. noch mit weiteren E-Mail-Adressen) hier. Vielen Dank.

Freundliche Grüße

Stefan Fleischmann

--
X-Ways Software Technology AG
Carl-Diem-Str. 32
32257 Bünde

#151: WinHex, X-Ways Forensics und X-Ways Investigator 18.9 veröffentlicht

12. Juli 2016

In dieser Ausgabe des Newsletters informieren wir Sie über ein wichtiges Update mit vielen nützlichen Verbesserungen, die Version 18.9. Erscheinungstermin war der 10. Juli.

Evaluationsversion von WinHex: https://www.x-ways.net/winhex.zip (korrekte Download-Adresse auch für Benutzer mit einer privaten, professionellen oder Specialist-Lizenz)

Insbes. Benutzer von X-Ways Forensics, X-Ways Investigator und X-Ways Imager finden Download-Instruktionen, Log-In-Daten sowie Details zur Update-Berechtigung wie immer unter https://www.x-ways.net/winhex/license-d.html. Lizenzierte Benutzer, deren Update-Berechtigung abgelaufen ist, erhalten von dort Upgrade-Angebote.

Schulungstermine

Köln, Ende Aug/Anfang Sep 2016
Termine im Ausland

Wenn wir Sie über weitere Termine informieren dürfen, geben Sie bitte hier Ihre E-Mail-Adresse ein.

Viewer-Komponente

Die neue Version 8.5.3 steht seit dem 5. Mai 2016 lizenzierten Benutzern von X-Ways Forensics und X-Ways Investigator mit aktiver Update-Berechtigung zur Verfügung.

Laut Oracle waren die Hauptziele dieses Releases:
* originalgetreuere Darstellung mehrerer besonders wichtiger Dateitypen,
* verbesserte allgemeine Schriftartauswahl und
* erschöpfendere Formatunterstützung.

Andere Kundenwünsche wurden laut Oracle ebenfalls umgesetzt, aber keine Details dazu veröffentlicht. Des weiteren flossen laut Oracle Fehlerbehebungen in das Release ein. Die Viewer-Komponente scheint nun bzgl. PDF-Dateien stabiler zu sein.

Die Version 8.5.3 der Viewer-Komponente erfordert nun das MS Visual C++ 2013 Redistributable Package statt 2005, d. h. dieselbe Version, wie sie auch Dokan benötigt. Das 2013er Package ist nicht unbedingt in allen Windows-Systemen enthalten. Das Installieren des Updates 8.5.3 ist empfehlenswert, aber viele Benutzer wollen v8.5.2 wahrscheinlich behalten, für den Gebrauch in Situationen, wenn sie X-Ways Forensics auf Computern ausführen möchten, die nicht ihre eigenen sind, z. B. auf Live-Systemen, die untersucht werden sollen, und die evtl. nur das 2005er Package installiert haben.

Verlust von Dongles

Es erreichen uns immer noch gelegentlich Anfragen nach Ersatzdongles für verlorengegangene unversicherte Dongles, obwohl diese bekanntlich nicht ersetzt werden. Wir stellen nur einen funktionsfähigen Dongle pro Lizenz bereit, nicht so viele, wie der Kunde gern hätte.

Was ist neu in v18.9?
(Bitte beachten Sie, daß sich die meisten Änderungen nur auf X-Ways Forensics beziehen.)

Datei-Format-Unterstützung

Eine generische Relevanz von Dateien kann nun von X-Ways Forensics eingeschätzt werden. Dies ist eine Unteroperation der Metadaten-Extraktion. Diese Relevanz basiert auf einer Vielzahl von Faktoren, darunter Dateityp, Generator sofern bekannt (für JPEG- und PDF-Dateien), Aktualität (Datum der letzten Änderung), Bekanntheit aus einer Hash-Datenbank, Reichtum an enthaltenen internen Metadaten, Größe, visuelle Eigenheiten im Fall von Bildern, ob eine PNG-Datei ein Bildschirmfoto von einem Smartphone ist, ob eine HTML-Datei vom Benutzer manuell lokal abgespeichert wurde, ob die Datei erkennbare Besonderheiten aufweist usw. usf. Die Relevanz ist nicht bloß inhaltsbasierend, sondern das Ergebnis einer fundamentalen Analyse. Insbes. ist die Generatorsignatur ein herkunftsbasiertes Kriterium.

Die grundlegende Idee ist, wenn die Zeit für die Untersuchung begrenzt ist, man mit den Dateien mit der höchsten generischen Relevanz anfangen sollte, um die Chancen zu maximieren, das, wonach man sucht, zu finden, sofern es existiert, und zwar möglichst rasch. Um aufgelistete Dateien absteigend nach Relevanz zu sortieren, sie also für die Begutachtung zu priorisieren, rufen Sie im Kontextmenü der Verzeichnis-Browsers den Befehl „Navigation | Nach Relevanz sortieren“ auf. Ein Häkchen in der daraufhin sichtbar werdenden Relevanz-Spalte zeigt an, daß die Relevanz der Datei tatsächlich eingeschätzt und für die Sortierung herangezogen wurde.
Generator-Signaturen werden jetzt auch für PDF-Dokumente ausgegeben. Analog zu JPEG-Dateien hilft dies bei der Herkunftsbeurteilung von PDF-Dateien und bei der Identifikation von PDF-Dateien, die vermutlich dieselbe Quelle wie eine bereits bekannte Datei haben. Die Generator-Signatur läßt beispielsweise erkennen, ob eine PDF-Datei von einem Scanner erzeugt wurde. Ca. 2.750 PDF-Generator-Signaturen sind aktuell (Stand v18.9) definiert, die ca. 95% aller PDF-Dateien abdecken. Eine besonders beachtenswerte PDF-Generator-Signatur-Kategorie ist "Reporting/Records", die Dokumente wie Kontoauszüge und Rechnungen identifiziert. Die Identifikation verbessert auch die automatische Relevanz-Bewertung. PDF-Generator-Signaturen werden jetzt in der Metadaten-Spalte ausgegeben und sind sogar für solche PDF-Dateien verfügbar, für die sonst keine Metadaten extrahiert werden (falls mit bestimmten Verschlüsselungen geschützt oder doppel-komprimiert).
Es gibt jetzt eine vom Benutzer pflegbare Datei namens "Generator Signatures.txt", die den anderen benutzerdefinierten Textdateien in X-Ways Forensics ähnelt. Sie können diese Datei ändern, um die Relevanz-Einschätzung anzupassen, die Teil der Metadaten-Extraktion ist. Wenn für Sie z. B. die Information, daß eine JPEG-Datei von einem Scanner erzeugt wurde, wichtig ist (weil Sie Steuerbetrug oder ähnliches untersuchen und sich für gescannte Dokumente interessieren), würden Sie sicherstellen, daß die Gruppe "JPEG/Scan" ein hohes Gewicht (z. B. 9) hat. Das ist die Zahl nach dem Tabulator in der Zeile mit der *** Gruppendefinition. Wenn eine solche Datei für Sie von weniger Bedeutung ist (z. B. weil die Bilder, nach denen Sie suchen, Kipo-Fotos sind), reduzieren Sie das Gewicht dieser Gruppe (indem Sie es z. B. auf 1 setzen). Sie können auch die individuelle Bedeutung einzelner Generator-Signaturen in einer Gruppe auf einer Skala von 0 bis 9 anpassen, wobei 9 die höchste Relevanz bedeutet. Sie können auch die Beschreibungen der JPEG- und PDF-Generator-Signaturen in der Textdatei editieren.
Metadaten-Extraktion aus PDF-Dateien leicht verbessert.
Besserer Schutz vor defekten PDF-Dateien, die die Viewer-Komponente unter bestimmten Umständen instabil werden lassen oder komplett zum Absturz bringen können (bei der logischen Suche oder Indexierung mit Text-Dekodierung, Dateiformat-spezifischem Verschlüsselungstest, FuzZyDoc). Der Schutz benötigt die Metadaten-Extraktion. Die absturzsichere Text-Dekodierung verhindert Abstürze des X-Ways Forensics Haupt-Prozesses in solchen Fällen ebenfalls.
Unterstützung für bestimmte 3-byte-Escape-Sequenzen in bestimmten Ostasiatischen ISO-2022 Code-Pages in der Textspalte.
Fähigkeit, Suchbegriffe zu finden, die aus mindestens zwei asiatischen Schriftzeichen aus ostasiatischen ISO-2022 Code-Pages (JIS) bestehen, selbst, wenn diese nicht direkt auf die vorangestellte Escape-Sequenz folgen.
Verbesserte Stabilität bei der Verarbeitung von EDB-Datenbanken. Ereignisse aus EDB-Datenbanken werden zur Ereignisliste wieder hinzugefügt wie in v18.6 und früher. Einige geringfügigere Verbesserungen bei der Verarbeitung von EDB-Datenbanken.
HTML-Metadaten-Extraktion und HTML-Dateityp-Erkennung verbessert.
Ereignisse, die aus Windows .evtx-Event-Log-Dateien in die Ereignisliste übernommen werden, tragen jetzt immer die Event-ID und die Log-Eintragsnummer in der Beschreibungsspalte zu Filterzwecken.
Ereignisse in .evtx-Event-Logs können jetzt optional vollständig übernommen werden. Zuvor wurde nur eine Unterauswahl verarbeitet, die vermutlich "wichtigeren" Ereignisarten.
Die Unfähigkeit, die Daten von in großen komprimierten Dateien eingebetteten Dateien korrekt zu lesen, wurde behoben.
Ein seltener Absturz mit bestimmten TIFF-Dateien wurde behoben.

PhotoDNA/Hash-Datenbanken

Beim Importieren von PhotoDNA-Hash-Werten aus ProjectVic, deren Kategorisierungen sich in der Hash-Datei widersprechen (z. B. als "Child Exploitation" und "non-pertinent" für dasselbe Bild), wird X-Ways Forensics diese jetzt zu "ProjVic Cat5 - Uncategorized" hinzufügen, außer, es handelt sich um die Hash-Werte für bedeutungslose, einfarbige Bilder (z. B. vollständig schwarz), dann "ProjVic Cat0 - non-pertinent" oder, falls es sich um die beiden recht ernstlichen Kategorisierungen "Child Exploitation" und "Child Abuse" handelt, wird die erste Kategorisierung beibehalten. X-Ways Forensics wird dies auch für die ersten 10 Konflikte in großem Detail berichten, um Ihnen oder dem Ersteller eine Chance zu geben, die Qualität der Hash-Sammlung zu verbessern. Nach 10 Konflikten wird es weniger gesprächig werden. In neueren ProjectVic-Datensätzen ist offenbar mit deutlich über 1000 widersprüchlichen Kategorisierungen zu rechnen, weswegen es wichtig ist, daß X-Ways Forensics zahlreiche doppelte Einträge und insbesondere fälschliche Kategorisierungen in der Datenbank verhindert.
Es ist jetzt möglich, eine PhotoDNA-Hash-Datenbank um ungewollte Hash-Werten zu bereinigen. Dafür gibt es jetzt einen neuen Schalter im Verwaltungs-Dialogfenster für die PhotoDNA-Datenbank. Die zu entfernenden Hash-Werte werden als einfache Text-Datei übergeben, mit einem Hash-Wert in Hex-ASCII-Notation pro Zeile und "PhotoDNA" in der ersten Zeile. Die angegebenen Hash-Werte betreffen sowohl exakte Übereinstimmungen in der Datenbank als auch kleine Abweichungen (dieselbe Abweichung ist erlaubt wie für den Abgleich eingestellt). Es kann notwendig werden, die PhotoDNA-Hash-Datenbank zu bereinigen, wenn Sie Hash-Sets aus einer fremden Quelle importiert haben, deren Inhalte teilweise Ihren Anforderungen nicht entsprechen, was offenkundig wird, wenn Sie falsche Treffer erhalten, falls Sie dennoch nicht das ganze Hash-Set entfernen wollen, oder falls Sie selbst versehentlich das falsche Bild in Ihre Hash-Datenbank aufgenommen haben.
Bei der Erzeugung eines PhotoDNA-Hash-Sets aus ausgewählten Bilder können Sie jetzt wahlweise das Hash-Set nicht in die interne Datenbank aufnehmen lassen, sondern eine separate Text-Datei mit PhotoDNA-Hash-Werten erzeugen lassen. Kreuzen Sie zu dem Zweck "Speichern unter..." an. Solche Dateien können an andere Nutzer weitergegeben werden, falls diese die angegebenen Hash-Werte zu ihren Datenbanken hinzufügen möchten, oder selbige entfernen wollen (s. oben).
PhotoDNA-Hash-Einträge können jetzt optional als verdächtig oder irrelevant klassifiziert werden, oder sie können unkategorisiert bleiben. Unkategorisiert kann als "noch nicht entschieden" oder "unsicher" interpretiert werden.
Übereinstimmungen mit der PhotoDNA-Datenbank zeigen jetzt die entsprechenden Kategorien in der Spalte Hash-Kategorie an und können entsprechend über diese Spalte gefiltert werden.
Hash-Sets in konventionellen Hash-Datenbanken (basierend auf MD5, SHA-1, etc.) können jetzt ebenfalls unkategorisiert bleiben. Dies könnte beispielsweise nützlich sein für Hash-Sets, die nur temporär in einem Fall benötigt werden, um bestimmte doppelte Dateien zu finden.
Beim Aufnehmen von PhotoDNA-Hash-Werten in die interne PhotoDNA-Hash-Datenbank mit dem entsprechenden Kontextmenü-Befehl haben Sie jetzt die Möglichkeit, Ihre Kommentare zu den ausgewählten Dateien in diese Datenbank als Beschreibungen aufnehmen zu lassen. Diese Beschreibungen können automatisch wieder als Kommentare übernommen werden, wenn beim nächsten Mal dieselben Bilder in einem anderen Fall gefunden werden. Diese können bestehende Kommentare in dem anderen Fall ersetzen oder (falls das entsprechende Feld nur halb angekreuzt ist) zu bestehenden Kommentaren hinzugefügt werden. Dies ist insbesondere für Benutzer bei der Polizei in Deutschland von Vorteil, die aufgrund eines BGH-Urteils (2 StR 279/07) für jedes kinderpornographische Bild für gerichtliche Zwecke eine Textbeschreibung bereitstellen müssen, um ihnen zumindest die wiederholte Eingabe der Beschreibung bereits bekannter Bilder zu ersparen. Ebenfalls nützlich, um Informationen wie z. B. bekannte Identitäten der Personen in einem Bild, frühere Fallnummern, etc. für zukünftige Verwendung zu hinterlegen, falls dieselben Bilder nochmal woanders gefunden werden.

Die Beschreibungen in der Hash-Datenbank können mit Ihren Kommentaren aktualisiert werden, indem man einfach die PhotoDNA-Hash-Werte derselben Dateien erneut durch den entsprechenden Befehl in die interne Datenbank aufnehmen läßt. Wenn Sie die interne Hash-Datenbank eines Kollegen importieren (durch Auswahl deren RHDB-Datei), stellen Sie sicher, dass Sie nicht nur die entsprechende RHCN-Datei (mit den Kategorie-Namen) im selben Verzeichnis haben, sondern auch die neuen Unterverzeichnisse, die die Beschreibungen enthalten, falls vorhanden, falls Sie auch diese Beschreibungen mit importieren möchten.

Um all diese internen Beschreibungen zu löschen, können Sie schlicht die "D*" genannten Unterverzeichnisse des PhotoDNA-Hash-Datenbank-Verzeichnisses löschen. Oder falls Sie Ihre Datenbank anderen Benutzern ohne die Beschreibungen weitergeben möchten, fügen Sie die D* Unterverzeichnisse einfach nicht bei. Sie können auch einzelne Beschreibungen in den Text-Dateien in den D* Unterverzeichnissen jederzeit manuell löschen oder aktualisieren. Beschreibungen, die Sie bereits in Ihrer Datenbank haben, werden durch das erneute Importieren der gleichen Hash-Werte aus anderen Quellen nicht verloren gehen; sie werden aber überschrieben, falls es sich bei der anderen Quelle um eine PhotoDNA-Hash-Datenbank von X-Ways Forensics handelt, die Beschreibungen für dieselben Bilder enthält.
Der Befehl "Hash-Set erzeugen" wurde umbenannt zu "In Hash-Datenbank aufnehmen", da einer seiner Zwecke jetzt lediglich die Aktualisierung von PhotoDNA-Datenbank-Einträgen mit Kommentaren aus dem Datei-Überblick ist.
X-Ways Investigator hat jetzt ebenfalls die Fähigkeit, PhotoDNA-Hash-Datenbanken zu verwalten und befüllen. Andererseits wurde die Funktionalität entfernt, rohe Datei-Header-Signaturen zur Auffindung eingebetteter Daten auf Dateien anzuwenden.

Performanz-Verbesserungen

Eine Parallelisierungsmöglichkeit (derzeit noch im experimentellen Status) erlaubt es nun, bei der logischen parallelen Suche mehrere Prozessorkerne besser zu nutzen, durch den Einsatz von mehreren Threads. Die hat nur dann einen Effekt, wenn Sie in Asservaten suchen, die Images oder Verzeichnisse sind, keine Datenträger. Je schneller die Datenträger sind, auf denen die Images/Verzeichnisse liegen, in Form von Seek Times und Datenübertragungsrate, desto prozentual mehr Zeit können Sie hierdurch einsparen. Unter perfekten Bedingungen kann die Geschwindigkeit der logischen Suche so mehr als verdoppelt werden. Wenn Sie nur einen einzigen Thread für die logische Suche wählen, funktioniert sie wie in X-Ways Forensics vor Version 18.9. Wenn Sie zwei oder mehr Threads wählen, wird die Suche in zusätzlichen Worker-Threads durchgeführt, und der Haupt-Thread des Prozesses hat während dessen nichts zu tun, außer auf Benutzeraktivitäten in der Benutzeroberfläche zu reagieren, wodurch diese jederzeit blitzschnell ansprechbar bleibt. In X-Ways Investigator können bis zu zwei Worker-Threads verwendet werden, in X-Ways Forensics bis zu sechs (aber weniger, wenn eine unzureichende Anzahl von Prozessorkernen vorgefunden wurde).
Leicht verbesserter Umgang mit extrem großen Suchtreffer-Zahlen.
Die Indexierung ist jetzt ebenfalls eine sparse-erkennende Operation, wird also sowohl nicht allokierte Bereiche sparse gespeicherter Dateien in NTFS und anderen Dateisystemen als auch genullte Festplattenbereiche, die als solches auf der .e01-Evidence-File-Ebene gekennzeichnet sind, überspringen.

Automatisierung

X-Ways Forensics (nicht X-Ways Investigator) unterstützt jetzt eine neue Kommandozeilen-Syntax, die es ermöglicht, 1) Fälle zu erzeugen, 2) Datenträger-Sicherungen hinzuzufügen und 3) den Datei-Überblick aller hinzugefügten Asservate zu erweitern. Beispiel:
xwforensics64.exe "NewCase:D:\Fall\Mein Fall" "AddImage:Z:\Images\Mein Image.e01" "AddImage:Z:\Images\Mein anderes Image.dd" RVS:~ auto

Die Anführungszeichen sind nur für Parameter mit Leerzeichen erforderlich. Wenn für den Fall kein Pfad angegeben ist, wird dieser im Standard-Fallverzeichnis angelegt. Mit "auto" schließt sich X-Ways Forensics am Ende selbst.

Zur Erweiterung des Datei-Überblicks (Befehl "RVS:~") wird X-Ways Forensics dieselben Operationen anwenden, wie sie laut der Datei WinHex.cfg zuletzt auf einen völlig unverarbeiteten Datei-Überblick angewandt wurden. Wenn Sie für unterschiedliche Fälle unterschiedliche Einstellungen verwenden möchten, müssen Sie diese Einstellungen in verschiedenen WinHex.cfg-Dateien (in verschiedenen Verzeichnissen oder unter unterschiedlichen Namen) speichern und vor der Ausführung von X-Ways Forensics die gewünschte Datei einsetzen. Beachten Sie bitte auch, daß bestimmte Einstellungen in anderen Dateien gespeichert werden, z. B. "X-Tensions.txt" und "Unwanted Metadata.txt".
Die Datenträger-Sicherung per Kommandozeile beinhaltet jetzt die Hash-Überprüfung der Sicherung (sofern zuvor in der Nutzeroberfläche ausgewählt) und die optionale beschreibende Text-Datei beinhaltet den sogenannten technischen Detailbericht.

Diejenigen Nutzer, die mit dieser Funktion nicht vertraut sind, seien bitte nochmals auf die Syntax hingewiesen: Der erste Kommandozeilen-Parameter sollte mit einem Doppelpunkt beginnen und dann die Gerätenummer in Windows angebe (z. B. ":1" für die Festplatte Nr. 1, also die zweite Festplatte). Dies führt dazu, daß der Datenträger beim Start automatisch geöffnet wird. Der zweite Parameter sollte mit dem Vertikalstrich beginnen, gefolgt von entweder "e01" oder "raw", um das gewünschte Sicherungsformat anzugeben, gefolgt von einem weiteren Vertikalstrich und dem Pfad und Dateinamen der Sicherung (z. B. "|e01|G:\Ausgabe Dateiname.e01"). In v19.0 wird es auch möglich sein, eine interne Beschreibung und den Namen des Bearbeiters anzugeben. Der dritte Parameter kann "auto" sein, um X-Ways Forensics nach dem Ende der Sicherung automatisch zu schließen.
Fähigkeit, in X-Ways Imager Dateien, interpretierte Sicherungen und Datenträger zu hashen. Fähigkeit, in X-Ways Imager Sicherungen direkt nach deren Erzeugung zu überprüfen.

Dateisystem-Unterstützung

Unterstützung für bestimmte neue und bislang seltene XFS-Varianten, mit Änderungen in praktisch allen relevanten Dateisystem-Strukturen, einschließlich einer neuen Inode-Version mit zusätzlichen Zeitstempeln und neuen Verzeichnisstruktur-Varianten.
Einige kleinere interne Verbesserungen in der XFS-Unterstützung.
Ein Ausnahmefehler wurde behoben, der beim Einlesen von Ext4-Dateisystemen auftreten konnte.
Nimmt jetzt Dateinamen und Zeitstempel von bestimmten teilweise überschriebenen Index-Records im Datei-Überblick auf, die in früheren Versionen wegen als ungültig abgelehnt wurden, als Teil der gründlichen Dateisystem-Datenstruktur-Suche.
Die Auflösung von Reparse-Punkten in NTFS zum Abschluß des Datei-Überblicks ist in bestimmten Windows-Installationen jetzt schneller.
Verbesserte Erkennung und Darstellung von Volumes mit BitLocker und BitLocker To Go. Metadaten werden im technischen Detailbericht ausgegeben: Volume-Erzeugungszeitstempel, textuelle Volume-Beschreibung, Verschlüsselungsmethode, Schutz-Typ und die letzte Änderung des Volume-Master-Keys. BitLocker-bezogene Zeitstempel werden auch als Ereignisse ausgegeben. Verbesserte Darstellung der verschlüsselten und unverschlüsselten Dateien im Wrapper-Dateisystem von BitLocker To Go Volumes.
Unterstützung für die Signatursuche nach englischsprachigen BitLocker Recovery Key Textdateien.

X-Tensions API

Fähigkeit, mittels XWF_GetItemInformation herauszufinden, ob alternative Dateidaten über XWF_OpenItem verfügbar sind, falls gewünscht, z. B. ein von X-Ways Forensics erzeugtes Vorschaubild. Fragen Sie das Flag 0x400000000 (XWF_ITEM_INFO_FLAG_ALTERNATIVE_DATA_AVAILABLE) ab.
Neue Funktion XWF_GetMetadataEx. XWF_GetMetadata jetzt überholt.
XWF_GetItemInformation unterstützt jetzt einen anderen Informationstyp, XWF_ITEM_INFO_PIXELINDEX.
XT_Init sollte jetzt 2 zurückgeben statt bisher 1, falls sich die X-Tension als thread-sicher betrachtet. Falls Ihre X-Tension sich nicht als thread-sicher identifiziert, könnte dies in zukünftigen Versionen von X-Ways Forensics zu suboptimaler Performanz bei der Ausführung von Operationen führen, die Ihre X-Tension ausführen.
Die X-Tension API-Funktion XWF_GetItemType wurde überarbeitet um die Ausgabe der Typ-Beschreibung einer Datei zu unterstützen.
The X-Tension API Demo-DLLs wurden neu kompiliert und eine Demo-X-Tension zu XWF_GetItemType wurde dem Delphi-Download hinzugefügt.

Filter

Bis zu vier Filterausdrücke werden jetzt für die Metadaten-, Kommentar- und Ereignis-Beschreibungsfilter unterstützt. (Bislang nur 2.) Diese Filterausdrücke werden jetzt mit allen anderen Filtereinstellungen in Fällen und in .settings-Dateien gespeichert.
Metadaten-, Kommentar- und Ereignis-Beschreibungsfilter-Ausdrücke können jetzt flexibler mit UND und ODER kombiniert werden. Die letzte Kombination hat immer Priorität. Beispielsweise wird "A und B oder C" interpretiert als "A und (B oder C)". "A oder B und C" wird interpretiert als "A oder (B und C)".
Metadaten-, Kommentar- und Ereignis-Beschreibungsfilter-Ausdrücke können jetzt mit einem Doppelpunkt anfangen, um einzelnen Ausdrücken zu einem NICHT zu verhelfen.
Der Größenfilter funktioniert jetzt nicht mehr genauso wie bisher, da Dateien mit unbekannter Größe jetzt nicht mehr immer durch den Filter fallen. Und Sie haben jetzt die Möglichkeit, gezielt auf Dateien mit unbekannten Größen mit der Bedingung ≤ -1 zu filtern.

Dateien kopieren

Wenn Sie im Wiederherstellen/Kopieren-Dialog einen nicht existierenden Ausgabepfad eingeben, werden Sie informiert und können dennoch fortfahren, der Pfad wird automatisch erzeugt.
Wiederherstellen/Kopieren: Die eindeutige ID kann jetzt nicht mehr nur in die Mitte des Dateinamens eingefügt werden, falls gewünscht, sondern auch vorangestellt werden.
Eine neue Option im Wiederherstellen/Kopieren-Dialog erlaubt das Überschreiben von Dateien mit identischen Namen, statt einen neuen, eindeutigen Namen zu erzeugen, wie das in früheren Versionen immer passiert ist.
Falls die Option, eine künstliche oberste Verzeichnisebene in Datei-Containern einzufügen, halb ausgewählt ist, bedeutet dies jetzt, daß für Asservat-Partitionen mit einem physischen Asservat als Eltern-Objekt nur der Name der Partition verwendet wird. Nützlich, wenn der Name des Eltern-Asservats sehr lang und überflüssig ist, da Sie den gesamten Container ohnehin nur mit Dateien aus einem einzigen physischen Asservat befüllen werden und dessen Name ohnehin bereits im Container-Namen referenzieren.

Verschiedenes

Mehr Details im Info-Fenster (das erscheint, wenn Sie auf die Versionsnummer am rechten Ende der Menüleiste klicken), wie z. B. wieviel freier Speicher auf dem Laufwerk für temporäre Dateien und Datenträger-Sicherungen frei ist, ob das Programm mit Administrator-Rechten läuft, ob das MS Visual C++ 2013 Redistributable Package (für die aktuellste Version der Viewer-Komponente und Dokan) installiert ist und falls nicht, ob wenigstens MS Visual C++ 2005 Package installiert ist (für v8.5.2 der Viewer-Komponente und älter). Insbesondere nützlich zu prüfen, wenn Sie X-Ways Forensics auf einer Maschine laufen lassen, die nicht Ihnen gehört, z. B. auf einem Live-System, das Sie einsehen möchten (Triage).
Die Notations-Option "Erzeugung > Änderung → kopiert" ist jetzt eine Anzeige- und Filtereinstellung der Beschreibungsspalte. Das Wort "kopiert" ist also jetzt Teil der Beschreibung. Da regelmäßig gefragt wird, was es mit dieser Option auf sich hat, erinnern Sie sich bitte daran, daß ein Erzeugungsdatum, das später ist, als das Änderungsdatum einer Datei, darauf hindeutet, daß die Datei an die Stelle kopiert wurde, an der Sie sie vorgefunden haben.
Option, Textfarben für Schlupf- und nicht initialisierten Speicher in Optionen | Allgemein zu ändern.
Es ist jetzt möglich, einzelne Historien-Einträge aus Editierfeldern zu löschen, indem man diese im Popup-Menü auswählt, während die Umschalt-Taste gedrückt ist.
Alternative Dateinamen werden jetzt im HTML-Format von der Funktion Liste exportieren und im Log von Wiederherstellen/Kopieren genauso ausgegeben wie im Verzeichnis-Browser.
Leicht überarbeitete Status-Darstellung im Fenster für die Fortschrittsanzeige.
Ein neuer Befehl im Verzeichnis-Browser-Kontextmenü im Untermenü Navigation erlaubt jetzt jetzt bequem das Aufsuchen eines Objekts mit einer bestimmten internen ID, egal, ob Datei oder Verzeichnis. Sollte ein Filter aktuell die Anzeige des Objektes verhindern, werden automatisch alle Filter deaktiviert.
Die Tastenkombination Umsch+Entf kann jetzt dazu verwendet werden, die Ausblendung aktuell angezeigter Dateien aufzuheben.
Viele kleinere Verbesserungen.
Einige kleinere Korrekturen.
Die Programmhilfe und das Benutzerhandbuch wurden auf den Stand von v18.9 gebracht.

Änderungen der Service-Releases von v18.8

SR-1: The option "Default to evidence object folders for output" did not have any effect on the Recover/Copy functionality in the original v18.8 release. That was fixed.
SR-1: The case report option "Copy and link each file only once" counted even previous report outputs if the order of files in the case root window was used. That was fixed.
SR-1: v18.8 miscounted directories recreated by the Recover/Copy command. That was fixed.
SR-1: The option to exclude all but one duplicate in each group did not have an effect in all situations in v18.8. That was fixed.
SR-1: PhotoDNA matching did not have any effect when not computing skin tone percentages at the same time. That was fixed.
SR-1: Avoids a time-out when loading certain corrupt picture files with the internal graphics viewing library.
SR-2: The entropy check for fully encrypted files was not applied to all files in v18.8. That was fixed.
SR-2: In Ext* partitions with very few blocks, the file system was not recognized by an internal plausibility check. That was fixed.
SR-2: Virtual files generated by X-Ways Forensics v18.8 for examination purposes were potentially output with timestamps of when they were generated. That is now prevented.
SR-3: Ability to display certain PNG pictures with certain illegal compression with the internal graphics viewing library in the 64-bit edition. Those pictures were previously shown as all black.
SR-3: Fixed an exception error that could occur when trying to list more than 134 million search hits at the same time.
SR-3: Ability to import plain text files with 1 PhotoDNA hash value per line in hex ASCII or Base64 no matter whether the last line is followed by another line break or not.
SR-3: Fixed potential miscounting of child objects that were targeted for inclusion in an evidence file container, leading to an incorrect confirmation message ("x of y files were added to ___.ctr").
SR-4: Fixed an exception error that could occur in v18.8 when uncovering embedded data in P7M and VCF files.
SR-4: The file header signature search option "Output as child objects of existing files if suitable" did not work correctly. It did not check the surroundings of carved files thoroughly enough and occasionally made wrong decisions about whether to present newly added files as child objects. That was fixed.
SR-4: Fixed an error in Quoted Printed decoding.
SR-4: X-Tension API: In all releases from today, ProcessItem[Ex] is also called for virtual files such as "Free space" as part of volume snapshot refinement although these files are otherwise largely ignored by that operation.
SR-5: Fixed missing conversion of search hits in certain code pages to Unicode in the search hit list display.
SR-5: The "Full path display" option had no effect on items in the root directory. That was fixed.
SR-5: Previously, when working with multiple open data windows, the category statistics in the Category filter's pop-up menu may have been shown for another data window after changing the filter settings, not the active data window. That was fixed.
SR-5: The case report may have been output incompletely under certain circumstances if the option "Position pictures above the text" was not selected. That was fixed. The error occurred if the "successfully saved" confirmation message at the end was absent.
SR-5: Fixed an exception error that could occur under certain circumstances when analyzing documents with FuzZyDoc.
SR-6: Fixed incomplete import of large plain-text files with PhotoDNA hash values.
SR-6: The descriptive imaging text file may have reported a certain number of unreadable sectors when creating a cleansed image although no sectors were unreadable. That was fixed.
SR-6: Fixed a possible exception error when extracting events from .evt event log files.
SR-6: Fixed a stability problem that occurred later in the same session after X-Ways Forensics recommended to decode text in HTML and RTF files for indexing due to the presence of non 7-bit ASCII characters, if that message had not been yet suppressed yet with the "Do not show again" option.
SR-7: Timestamps of files in evidence file containers that were based on an unknown local time zone (e.g. from a FAT file system), not on UTC, were treated as if they were based on UTC. That was fixed.
SR-7: Prevented an exception error with corrupt (typically carved) jumplists.
SR-7: Under certain circumstances, files that were classified as irrelevant in a previous volume snapshot refinement run already were touched again by subsequent runs when they should have been omitted. That was fixed.
SR-7: Fixed exception errors that could occur when starting a logical search in v18.8 under certain circumstances.
SR-7: The case report option "Position pictures above the text" prevented the output links to non-pictures files from the report. That was fixed.
SR-7: v8.5.3 of the viewer component hangs with various versions of the NTFS $UpCase file. That file is now no longer sent to the viewer component to generate a non-picture thumbnail for the gallery.
SR-8: The XML list export did not include the contents of the "Report table" column. That was fixed.
SR-8: Prevented an exception error that could occur when the case was saved.
SR-9: GREP syntax: # now has its special meaning even inside square brackets.
SR-9: Fixed an exception error that could occur with physical search hits on physical media without case association.
SR-9: Prevented a possible infinite recursion and an exception error when searching for embedded data in carved DLLs.
SR-10: Fixed the report table independent listing of Unicode search hits in the case report.
SR-10: Ability to identify more PDF and HTML documents with no extractable text.
SR-10: Fixed an exception error that could occur in v18.8 when trying to decode text in files of certain types that do not contain extractable text, if the crash-safe decoding option was not selected.
SR-10: Fixed duplicated output of the case log if output at the same time as the case report.
SR-10: Prevented an exception error that could occur when searching embedded data in corrupt service_worker files.
File EDBex.dat in the X-Ways Forensics download replaced. In some previous versions, if something went wrong during EDB database processing, the user had to click away an error message to proceed. This is now avoided.

Wir hoffen, Sie bald wieder auf http://www.x-ways.net zu sehen, oder bei Facebook oder Twitter. Bitte leiten Sie diesen Newsletter an andere Interessenten weiter. Anmelden kann man sich (z. B. noch mit weiteren E-Mail-Adressen) hier. Vielen Dank.

Freundliche Grüße

Stefan Fleischmann

--
X-Ways Software Technology AG
Carl-Diem-Str. 32
32257 Bünde

#150: WinHex, X-Ways Forensics und X-Ways Investigator 18.8 veröffentlicht

25. Apr. 2016

In dieser Ausgabe des Newsletters informieren wir Sie über ein wichtiges Update mit vielen nützlichen Verbesserungen, die Version 18.8. Erscheinungstermin war der 23. April.

Evaluationsversion von WinHex: https://www.x-ways.net/winhex.zip (korrekte Download-Adresse auch für Benutzer mit einer privaten, professionellen oder Specialist-Lizenz)

Schulungstermine

Köln, Ende Aug/Anfang Sep 2016
Termine im Ausland

Wenn wir Sie über weitere Termine informieren dürfen, geben Sie bitte hier Ihre E-Mail-Adresse ein.

Videos

Quick Start Guides • Settings & Setup

Was ist neu in v18.8?
(Bitte beachten Sie, daß sich die meisten Änderungen nur auf X-Ways Forensics beziehen.)

Datei-Format-Unterstützung

Der Typstatus „neu erkannt“ wurde aufgeteilt in „neu erkannt“ (mit einer schwächeren Bedeutung, z. B. in dem Sinn, daß X-Ways Forensics vor der Typprüfung keine Vorstellung vom Typ der Datei hatte, weil der Dateiname keine Erweiterung enthält) und „anders erkannt“ (was auf eine irreführende Dateinamenserweiterung hindeutet und verdächtiger ist). Der Typstatus „neu erkannt“ aus Datei-Überblicken, die mit früheren Versionen erweitert wurden, wird als „neu erkannt“ übernommen.
Dateityp-Signatur-Definitionen können nun die ersten 1024 Bytes einer Datei ausnutzen, nicht mehr nur die ersten 512 Bytes. Dies erlaubt in einigen Fällen eines genauere Bestimmung des Typs oder Untertyps.
Erkennung des Zip-Untertyps appx, der in neu initialisierten Installationen nun der „Special Interest“-Gruppe von Archiven angehört, in der sich auch jar, apk und ipa befinden. Er wird daher optional verarbeitet.
Die Dateityp-Prüfung wurde allgemein weiter verbessert.
Die Extraktion von Caches von Google Chrome wurde überarbeitet und vor allem für größere Exemplare verbessert. Unterstützung für eine relativ neue Erweiterung des Dateiformats. Unterstützung für multiple Datenströme desselben Cache-Eintrags: Die HTTP-Antwort (genannt .chrome1) wird nun auch ausgegeben, sofern vorhanden, ebenso wie kompilierte JavaScript-Einträge (genannt .js1). Wenn eine „no-cache“ Anweisung vom Web-Server gesendet wurde, so wird zumindest die HTTP-Antwort dennoch im Cache gespeichert. Im Vorschau-Modus können Sie eine besondere Darstellung diese HTTP-Antworten sehen.
Chrome-Caches können nun auch dann verarbeitet werden, wenn ihr Index nicht verfügbar ist, z. B. wenn Cache-Fragmente per Datei-Header-Signatur-Suche gefunden und aus den Sektoren ausgegliedert wurden oder wenn der Cache teilweise gelöscht oder beschädigt wurde. In Einzelfällen erhält man nun ohne Verarbeitung des Index' möglicherweise sogar ein besseres Extraktionsergebnis als als mit. Um das bei vorhandenem Index auszuprobieren, können Sie, sofern der Index nicht bereits zuvor verarbeitet wurde, die Funktion zum Suchen von eingebetteten Daten auf „data_4“-Dateien anwenden und den Index bei der Erweiterung des Datei-Überblicks auslassen. data_4 ist nun Teil der optionalen „Special Interest“-Gruppe.
Unterstützung des neuen Dateityps „service_worker“, der Teil des neuen Chrome-Offline-Caches ist. Dateien dieses Typs können nun bei der Typprüfung erkannt werden, per Datei-Header-Signatur-Suche gefunden werden, und Metadaten sowie eingebettete Daten können extrahiert werden.
Firefox-Cache-Extraktion überarbeitet.
Algorithmische Erkennung von URL-codierten ESC-Dateien aus Browser-Caches und deren menschlesbare Darstellung im Vorschau-Modus. Diese Dateien enthalten Metadaten von Video-Streaming-Diensten.
Verarbeitung von iPhone-Backups neuerer iOS-Versionen, als Teil der Metadaten-Extraktion.
Der Dateityp "locky" wurde definiert, da er dank der Verbreitung der Erpressungssoftware „Locky“ nun recht verbreitet ist. Solche Dateien werden automatisch als verschlüsselt markiert, zur leichteren Erkennung.
Extraktion von Rängen aus einzelnen Jump-List-Einträgen sowie aus Jump-Lists als ganzem. Diese Ränge sind Gleitkommazahlen, die ungefähr proportional zur Zugriffshäufigkeit sind und daher potentiell relevante Informationen darstellen. Die Ränge werden von Windows berechnet.
Gezielte Unterstützung von Jump-Lists von Windows 10, einschließlich einer erst kürzlich eingeführten neuen Version.
Unterstützung des neuen thumbcache_idx.db-Formats von Windows 10.
Unterstützung von $I-Dateien von Windows 10.
Eine unendliche Rekursion in bestimmten Registry-Hives bei einer seltenen Art der Beschädigung wurde verhindert.
Fähigkeit zum Auffinden von eingebetteten Dateien in .p7m S/MIME-Dateien.
Informationen über die Soundqualität in Videos (Abtastfrequenz und Anzahl der Kanäle) werden bei der Erzeugung von vereinzelten Standbildern nun gleich mit extrahiert. „No audio“ wird ausgegeben, wenn ein Video keinen Sound hat. Dies erlaubt es, nach Videos mit oder ohne Sound zu filtern.
Eintrag in der Kategorie Video für den Dateityp „dash“ aus Browser-Caches. Es handelt sich um einen MP4-Untertyp für gestreamte Video-Daten. Um mit herkömmlichen Video-Abspielprogrammen dargestellt zu werden, müssen Dateien dieses Typs erst konvertiert werden.
Datei-Archive weiterer Typen werden nun im Verzeichnisbaum links dargestellt, sobald ihr Inhalt in den Datei-Überblick aufgenommen wurde.
Überarbeitete Unterstützung von TAR-Archiven. Fähigkeit zum Extrahieren von bestimmten TAR-Archiven, die vorher nicht verarbeitet werden konnten. Exaktere Darstellung von Dateien in TAR-Archiven. Schnellere Verarbeitung und Caching von TAR-Archiven innerhalb von GZ-Archiven.
Fähigkeit zur Bestätigung des Typs von GZ-Archives mit dem sog. Extra-Flag, und deren Verarbeitung.
Intern überarbeitete Behandlung von Datei-Archiven, und Behebung einiger seltener Fehler. Verbesserte Verarbeitung bestimmter defekter Datei-Archive.
Stark verbesserte Datei-Header-Signatur-Suche nach XML-Dateien, für fast alle Untertypen. XML-Definitionen in FTSS.txt and FTSCO.txt.
Erhöhte Kontextsensitivität führen zu einer Verbesserung der Ergebnisse der Datei-Header-Signatur-Suche nach XML-, CSV- und Base64-Dateien.
Rudimentäre Datei-Header-Signatur-Suche nach CSV-Dateien möglich.
Unterstützung von Microsoft ONE-Dateien bei der Datei-Header-Signatur-Suche.
Wenn Sie wirklich jeden einzelnen Punkt hier lesen, Hut ab, Sie sind wirklich interessiert.
Definitionen für die Datei-Header-Signatur-Suche nach OECustomProperty-Objekten, die E-Mail-Metadaten von MS Outlook enthalten können und oft in Form von alternativen Datenströmen gespeichert werden.
Per Datei-Header-Signatur-Suche können nun Fragmente von Windows.edb-Dateien gefunden werden, die Internet-Browsing-Ereignisse enthalten (s. „Special Interest“-Gruppe).

Bilder-Unterstützung

Fähigkeit, unvollständige JPEG-Bilder mit progressiver Kompression soweit wie möglich mit der internen Grafikanzeige-Bibliothek darzustellen.
Eine Ausnahmesituation wurde verhindert, die bei bestimmten defekten oder sehr großen GIF-Bildern auftreten konnte.
Die Darstellung der JPEG-Generator-Signatur wurde überarbeitet. Eine menschenlesbare textuelle Beschreibung ist nun für fast alle Signaturen zusätzlich zur Hexadezimal-Darstellung verfügbar.

Die Generator-Signatur ist ein experimentelles Konzept, das dabei helfen kann, den Ursprung von Dateien bestimmter Typen zu identifizieren. Es wird in X-Ways Forensics für JPEG-Dateien verwendet. Die Signatur basiert auf der JPEG-Quantisierungstabelle und einigen anderen invarianten Eigenschaften. Wenn die erzeugende Software-Bibliothek identifiziert wird, wird zusätzlich zur Hexadezimal-Signatur auch eine textuelle Beschreibung ausgegeben. Der am weitesten verbreitete JPEG-Generator ist die IJG-Bibliothek, aber es gibt noch mehr als 10.000 weitere. „Photoshop“ und „Photoshop Web“ beispielsweise sind ebenfalls gängig. „Photoshop Web“ identifiziert eine JPEG-Datei als von Photoshop erzeugt mit Optimierung für den Gebrauch im Web. Andere Generatoren, die X-Ways Forensics erkennt, sind iPhone, Apple 75, Apple 90, Kodak, Adobe Fireworks, Nikon, Sony, Blackberry, Canon EOS, Canon EOS fine, Canon norm, Canon fine, Canon superfine, Canon PowerShot, HP Scanjet, HP PhotoSmart, HTC, CASIO, Quicktime Med, ImageGear 84 und LEAD Technologies. Die Qualtitätseinstellung, die zum Erzeugen einer JPEG-Datei verwandt wurde, wird ebenfalls ausgegeben („Q=...“). Es handelt sich um eine Zahl im Bereich von 1 bis 100 (im Fall des regulären Photoshop-Generators nur zwischen 1 und 12). Je höher dieser Wert, umso stärker die Kompression und umso geringer die Bildqualtität.

Generator-Signaturen werden bei der Datei-Header-Signatur-Suche in X-Ways Forensics zur Benennung von aus Sektoren ausgegliederten JPEG-Dateien eingesetzt, wenn keine „besseren“ Metadaten vorhanden sind (z. B. Kameramodell und Zeitstempel aus den Exif-Daten). Wenn die Metadaten-Extraktion keine „besseren“ Metadaten findet, kann immer noch die Generator-Signatur ausgegeben warden, und diese erlaubt es Ihnen zumindest, Gruppen zusammengehöriger Dateien zu identifizieren, die wahrscheinlich dieselbe Herkunft haben. Wenn Exif-Metadaten vorhanden sind, können Sie überprüfen, ob Generator-Signatur und Exif-Metadaten miteinander konsistent sind, und das kann zeigen, ob ein Bild bearbeitet und erneut gespeichert wurde.

Insbesondere erlaubt die Generator-Signatur es, Dateien zu erkennen, die von Scannern erzeugt wurde, da nur eine handvoll Generatoren in Scannern üblich ist. D. h. damit kann man eingescannte Bilder als solche auch dann erkennen, wenn sie nicht schwarz-weiß sind und nicht zu 100% nur Graustufen-Farben enthalten.

E-Mails

Option zum gezielten Filtern basierend darauf, ob bestimmte Empfänger auf Kopie oder Blindkopie gesetzt wurden oder Hauptadressat sind, in E-Mails und Datei-Anhängen, die von v18.8 extrahiert wurden. Nützlich zum Beispiel dann, wenn in der bei Ihnen gültigen Rechtssprechung an einen Rechtsanwalt geschickte E-Mails weniger geschützt sind, wenn der Rechtsanwalt nur auf Kopie gesetzt wurde und nicht der Hauptadressat ist.
Die Metadaten-Extraktion von E-Mails ist nun etwas präziser.
Extrahiert E-Mails und Datei-Anhänge aus .olk14message-Dateien von MS Outlook 2011 für Apple Mac OS X.
Quoted Printable im Rumpf einer E-Mails wird nun in der alternativen .eml-Vorschau/Darstellung decodiert.
Ein Ausnahmefehler wurde behoben, der auftreten konnte beim Extrahieren von Metadaten aus bestimmten .eml-Dateien mit defekter Quoted-Printable-Codierung.

Fallbericht

Neue CSS-Definitionen: RTpicthumb und RTdocthumb, für Miniaturansichten von Bildern bzw. Nichtbildern.
Option zum Beschränken der Metadaten-Ausgabe von Video-Einzelbildern im Fallbericht auf Name und Kommentare.
"Bilder zum Einbindungen in Bericht herauskopieren" kopiert nun auch ein Einzelbild pro Video, sofern verfügbar, und zeigt es direkt im Bericht an, um das Video zu repräsentieren. Die Videodatei selbst wird bei dieser Einstellung nicht kopiert, um Speicherplatz zu sparen. Die Video-Datei wird nur dann kopiert, wenn "Dateien zum Einbindungen in Bericht herauskopieren" ganz angekreuzt ist.
Manuelle Protokolleinträge unterstützen jetzt Unicode. Und es gibt eine Option, nur manuelle Einträge im Protokoll auszugeben.

Bedienbarkeit

Das Dialogfenster zum Wiederherstellen/Kopieren wurde neu und klarer strukturiert. Die Option zum Einbetten von Datei-Anhängen von E-Mails hängt nun nicht mehr von der Option ab, daß auch Unterobjekte von Dateien kopiert werden sollen, oder davon daß die Anhänge explizit selbst mit ausgewählt sind, was das Einbetten intuitiver und leichter benutzbar macht.
Eine neue Option beim Wiederherstellen/Kopieren erlaubt das Erzeugen einer zweiten Kopie aller ausgewählten Dateien in einem separaten Verzeichnis. Das ist nützlich, wenn Sie zwei Parteien dieselben relevanten Dateien zur Verfügung stellen müssen und Zeit sparen möchten. Die Protokollfunktion bezieht sich allerdings nur auf die erste Kopie.
Beim Erkennen von Duplikaten können identische Dateien nun paarweise miteinander als sog. zugehörige Objekte verknüpft werden, so daß das Navigieren von einer Datei zu zumindest einem Duplikat sehr viel leichter fällt. Das Ausblenden von allen Duplikaten in einer Gruppe bis auf eins ist nun optional, ebenso wie das Kennzeichnen von Dateien als Duplikate in der Beschreibungsspalte.
Das Identifizieren von doppelten Bildern anhand von gespeicherten PhotoDNA-Hash-Werten ist jetzt sehr viel schneller als vorher, in Abhängigkeit von verfügbarem Arbeitsspeicher und der Anzahl der Prozessorkerne.
Datenträger-Sicherung: Sie können nun bereits im Vorfeld ein Überlaufverzeichnis angeben, in dem weitere Segmente der Sicherung gespeichert werden sollen, wenn der Platz auf dem primären Ausgabedatenträger zur Neige geht. Dies verhindert im Fall der Fälle einen unnötigen Zeitverlust, bis Sie reagieren können und die Sicherung fortgesetzt wird. Wenn Sie das Feld leer lassen oder wenn sogar der Speicherplatz im Überlaufverzeichnis erschöpft ist, werden Sie wie in früheren Versionen bei Bedarf nach einem neuen Pfad gefragt. Wenn Sie ein Überlaufverzeichnis im voraus angeben und gleichzeitig eine zweite Sicherungskopie erzeugen lassen, beachten Sie bitte, daß das Überlaufverzeichnis nur für die erste Sicherungskopie verwendet wird, die den ihr zur Verfügung stehenden Speicherplatz ganz ausfüllt, falls dies passiert. Für die jeweils andere Sicherungskopie werden Sie bei knappem Speicherplatz gefragt.
Hash-Werte von Roh-Images, die von X-Ways Forensics erzeugt wurden, werden nun automatisch aus der begleitenden beschreibenden Textdatei entnommen, sofern verfügbar, und in den Eigenschaften des Asservats angezeigt.
Der Beschreibungsfilter für Video-Einzelbilder hat nun eine zusätzliche Option, mit deren Hilfe Sie auch das zugehörige Video anzeigen lassen können, und zwar direkt vor dessen Einzelbildern. Auf diese Weise ist es in der Galerie einfach zu sehen, welche Einzelbilder aus welchem Video stammen, und Sie können Kommentare zu dem Video eingeben oder das Video mit einer Berichtstabelle verknüpfen, ohne hin- und her zu navigieren und ohne auf die weniger intuitive Bedienungsweise zurückgreifen zu müssen, Berichtstabellenverknüpfungen für Objekte zu erstellen, die Sie gar nicht sehen können (mit der Option „für übergeordnete Datei“). Die Kacheln, die die Videos repräsentieren, können zudem in der Galerie als visuelle Trennelemente dienen, wenn Sie „ersatzweise Miniaturansichten“ in den Galerie-Optionen ausschalten. Dann fällt es sehr leicht zu sehen, wo die Bilder des nächsten Videos anfangen.
Der Beschreibungsfilter kann nun Dateien erfassen, die in X-Ways Forensics indexiert wurden.
Wenn sich mehrere Benutzer eine Installation von X-Ways Forensics oder X-Ways Investigator teilen, mit individuellen, in den Benutzerprofilen gespeicherten Konfigurationen, werden error.log-Dateien nun nicht mehr im Installationsverzeichnis erzeugt, wenn dieses beschreibbar ist, sondern ebenfalls im Benutzerprofil. Das ist nützlich, wenn die anderen Benutzer die Asservat-Metadaten, die sich in der error.log-Dateie wiederfinden können, nicht sehen sollen. Ähnlich wird nun auch die msglog.txt-Datei im Benutzerprofil erzeugt, wenn Nachrichten ausgegeben werden während kein Fall aktiv ist. (Aber diese Datei wird nach wie vor im Log-Unterverzeichnis des Falls erzeugt, wenn ein Fall aktiv ist.)
Nicht-Option für den Namensfilter.
Die Modulo-Einstellung für den Int.-ID-Filter ist nun flexibler.
Das Anklicken der Überschriftszeile der Textspalte (wo die aktuell aktive Codepage in hellgrauer Farbe angezeigt wird), erlaubt nun ein komfortables, schnelles Umschalten der in dieser Spalte aktiven Codepage.
Wenn die Textspalte Text in einer Codepage anzeigt, die nicht die aktive Codepage in Ihrem Windows-System ist, und wenn Sie Daten aus der Hex-Editor-Anzeige in die Zwischenablage kopieren, fragt WinHex Sie nun, ob Sie den Text dabei konvertieren möchten, von der in der Textspalte aktiven Codepage nach UTF-16, zum korrekten Einfügen in externen Programmen.
Die Vollpfad-Sortier-Option ist jetzt eine Anzeigeoption des Verzeichnis-Browsers. Sie kann weiterhin dazu verwendet werden, eine Sortierreihenfolge herzustellen, in der Unterobjekte direkt ihren jeweiligen Elternobjekten folgen, aber sie hat nun auch eine Auswirkung auf die Anzeige in dem Sinn, daß der Pfad nun optional den Namen des Objekts selbst enthalten kann, z. B. damit sie ihn aus der Pfadspalte in einem einzigen Schritt in die Zwischenablage kopieren können.
Eine neue Option in den Falleigenschaften erlaubt es, die Suchbegriffsliste bei der nächsten Erzeugung auf dem Bildschirm als einspaltige Liste darzustellen. Darin läßt sich vertikal statt horizontal rollen, so wie es in älteren Versionen von X-Ways Forensics Standard war. Das kann z. B. dann vorteilhaft sein, wenn Ihre Suchbegriff recht lange Wörter sind.

Diverses

In Datei-Containern wird nun gezielt der DÜE-Status der enthaltenen Dateien vermerkt, d. h. ob bereits bereits vereinzelte Standbilder zu Videos erzeugt wurden oder ob bereits eingebettete Daten gesucht wurden usw. usf. Wenn Sie sich dafür entscheiden, diesem Status zu trauen und ihn zu übernehmen, was Sie ab sofort in den Optionen des Datei-Überblicks einstellen können, werden diese Dateien nicht erneut verarbeitet, wenn Sie sich dazu entschließen, den Datei-Überblick des Containers selbst zu erweitern. U. U. könnten Sie es bevorzugen, den DÜE-Status von Dateien in Containern nicht zu übernehmen, damit Sie nichts übersehen, wenn Sie vermuten, daß der ursprüngliche Bearbeiter keine so gründlichen Einstellungen für die Erweiterung verwendet hat wie Sie es vorhaben, oder wenn zuvor eine ältere, weniger mächtige Version von X-Ways Forensics zur Verarbeitung der Dateien eingesetzt wurde. Das Übernehmen des DÜE-Status ist eine Voraussetzung dafür, um in einem Container enthaltene Videos mit rotierend durchlaufenden repräsentativen Einzelbildern dargestellt zu bekommen.
Wenn Sie externe Dateien an einen Datei-Überblick anhängen, kann X-Ways Forensics nun optional auch die Zeitstempel dieser Dateien übernehmen (Erzeugung, Änderung und/oder Zugriff). Das ist empfehlenswert, wenn Sie sich sicher sind, daß diese Zeitstempel original sind und nicht etwa das Resultat Ihrer eigenen Kopier- oder Konvertierungsaktivitäten mit diesen Dateien.
Der Daten-Dolmetscher beachtet nun die Big-Endian-Einstellung auch beim Übersetzen von FILETIME-Strukturen. Das ist nützlich, weil FILETIME-Zeitstempel in Windows Storage Spaces in Big-Endian-Speicherung zu finden sind.
Der unterstützte Bereich von Zeitstempeln im Verzeichnis-Browser ist 5. Mai 1829 bis 14. May 2514. Über- und Unterschreitungen werden nun in Form des Vermerks „außerhalb der Grenzen“ angezeigt und können voneinander unterschieden und korrekt sortiert und gefiltert werden.
Das Anzeigen der Datei-Größe in weißen Kacheln in der Galerie ist nun optional, so daß Sie ggf. eine Überfrachtung des Bildschirms mit nicht benötigten Informationen reduzieren können.
Bei aktiver Überlagerung von Sektoren wird das Dateisystem von Volumes wird nun versucht zu zu erkennen, wenn Sie den Datei-Überblick neu einlesen.
Das Auswerten von Ext-Journals wurde optimiert. Das Ergebnis sieht nun besser aus, wenn die Option nur halb gewählt ist, und das ist die neue Voreinstellung. Seltene Probleme mit voller Wahl dieser Option sollten nicht mehr auftreten.
X-Ways Forensics kann nun den schnellen Suchalgorithm für die parallele Suche auch dann anwenden, wenn Sie sich nah an der Grenze der maximalen Anzahl von Suchbegriffen pro Suchvorgang bewegen , d. h. etwa 8190. (Bitte beachten Sie, daß die Zahl der insgesamt in einem Fall angesammelten Suchbegriffe auch auf ca. 8190 begrenzt ist.)
Die Funktion XWF_GetHashValue der X-Tension API kann nun auch dazu verwendet werden, zuvor berechnete und permanent im Datei-Überblick gespeicherte PhotoDNA-Hash-Werte von Bildern zu in einen übergebenen Puffer zu kopieren.
Die Funktion XWF_GetItemType der X-Tension API erlaubt es nun alternativ, die Kategorie, zu der eine Datei gehört, zu ermitteln.
Die italienische Übersetzung der Benutzeroberfläche wurde aktualisiert.
Viele kleinere Verbesserungen.
Einige kleinere Korrekturen.
Die Programmhilfe und das Benutzerhandbuch wurden auf den Stand von v18.8 gebracht.

Änderungen der Service-Releases von v18.7

SR-1: If multiple images were added to a case simultaneously, they had to be closed and re-opened in v18.7 to get the volume snapshot taken. That was fixed.
SR-1: File type recognition of certain lose Hotmail e-mails improved.
SR-2: Fixed blank Owner column in v18.7 for NTFS file systems.
SR-2: Fixed inability of 18.7 to maximize the detached lower half of a data window in most modes.
SR-2: Edit box histories now accessible additionally by scrolling with the mouse wheel and by pressing the Down cursor key.
SR-2: Fixed bad quality carving of NTFS-compressed files in recent versions.
SR-2: Improved interaction with MPlayer.
SR-3: Fixed inability of v18.7 to extract files from large GZ archives completely.
SR-3: Avoided a condition in which no still images were captured from videos.
SR-3: Fixed an exception error that could occur when extracting metadata from certain huge AVI video files.
SR-4: The Unique ID filter now allows to enter a list of unique IDs consisting of up to 2,000,000 characters instead of 30,000 characters before. (Characters = digits, dashes, and line breaks).
SR-4: Thumbnails in thumbs.db were extracted without original filename if the names were very long. That was fixed.
SR-4: The Sender and Recipients filters are now applied to e-mail attachments again as well.
SR-4: Fixed an exception error that occurred in v18.6 and v18.7 when ending the program if unlocked with a network dongle.
SR-4: Fixed jump to wrong offset when clicking certain embedded files in Partition mode. Fixed incorrectly displayed 1st sector values for the same files.
SR-5: Fixed an exception error that could occur in v18.7 when adding entries to the history of edit boxes.
SR-5: The scope of the file header signature search on a physical, partitioned evidence object now includes very small auxiliary partitions that do not contain any known file system and that have not been added to the case as evidence objects.
SR-5: Fixed an error that could occur when opening evidence objects without accessible disk or image.
SR-5: When exploring archives with subdirectories without computing hash values at the same time, the primary hash value was set as all zeroes. That was fixed.
SR-6: Fixed an exception error that could occur under certain circumstances when copying data from a data window with no directory browser.
SR-6: Fixed an error that occurred in v18.7 when reading from reconstructed RAID5 systems with a missing component.
SR-6: Fixed a potential exception error with CAB files that are smaller than 256 bytes.
SR-6: Fixed a potential infinite loop when carving JNX files.
SR-6: Fixed a rare volume snapshot anomaly where the files of a certain directory became part of "Path unknown" although the path should have been known to X-Ways Forensics.
SR-6: Fixed a rare exception error that could occur in the Export List command in the registry viewer.
SR-7: Fixed inability to import PhotoDNA hash values from certain current ProjectVic ODATA JSON files.
SR-7: Some other aspects of PhotoDNA hash value imports improved.
SR-7: Fixed a miscategorization issue when importing conventional hash values from certain current ProjectVic ODATA JSON files.
SR-7: Ability to import hash values from JSON files belonging to previously unexpected, newly defined category numbers 4 and 5.
SR-7: Avoided certain unnecessary messages about corrupt directory entries in exFAT.
SR-7: More convenient option to have a user-specific configuration only for selected users of a shared installation, by creating an empty file named winhex.user.[username] in the installation directory for every user that shall be allowed to maintain his or her individual configuration, while using a shared configuration for everyone else, e.g. using a write-protected general WinHex.cfg file with predefined settings as deemed appropriate for your organization.
SR-8: Ability to import hash values from current Project Vic/Hubstream ODATA JSON files.
SR-8: Accepts category numbers up to 9 in ODATA JSON files.
SR-8: Search hits in the case report could be empty or garbled depending on the Export List options for search hits. That was fixed.
SR-8: Fixed an exception error that occurred when running a logical search immediately after removing items from the volume snapshot.
SR-8: Prevents annoying, lengthy and unnecessary font cache initialization in MPlayer versions from 2015.
SR-8: Alternative e-mail preview: Fixed encoding error in the header representation at the bottom.
SR-9: Fixed an exception error that could occur in v18.7 when extracting metadata from XML files.
SR-9: Fixed a rare floating point exception error that could occur when dealing with timestamps in certain formats.
SR-9: Less false positives and fast processing of full file encryption test.
SR-9: BLOBs (binary data chunks) are now also optionally provided as child objects for SQLite database of an unknown purpose/subtype.
SR-10: Now preserves the original filename extension when naming original single .eml files after their subject lines.
SR-10: Support for .evtx event log files larger than 2 GB.
SR-10: Fixed problems with PhotoDNA hash databases that contain no hash values.
SR-10: Fixed output of Boolean values in BPLists.
SR-10: More stable when processing corrupt BPList files.
SR-10: Prevents occurrence of zeroed out primary hashes in volume snapshots in certain situations.

Freundliche Grüße

Stefan Fleischmann

--
X-Ways Software Technology AG
Carl-Diem-Str. 32
32257 Bünde

#149: WinHex, X-Ways Forensics und X-Ways Investigator 18.7 veröffentlicht

27. Jan. 2016

In dieser Ausgabe des Newsletters informieren wir Sie über ein größeres Update mit vielen nützlichen Verbesserungen, die Version 18.7.

Evaluationsversion von WinHex: https://www.x-ways.net/winhex.zip (korrekte Download-Adresse auch für Benutzer mit einer privaten, professionellen oder Specialist-Lizenz)

Schulungstermine

Köln, 7.-10. März 2016
Termine im Ausland

Wenn wir Sie über weitere Termine informieren dürfen, geben Sie bitte hier Ihre E-Mail-Adresse ein.

Was ist neu in v18.7?
(Bitte beachten Sie, daß sich die meisten Änderungen nur auf X-Ways Forensics beziehen.)

Dateiformat-Unterstützung

Die Genauigkeit der Dateityp-Prüfung wurde weiter verbessert. Weniger Dateitypen mit generischen Dateierweiterungen werden jetzt unnötig als „neu erkannt“ gekennzeichnet, sondern bestätigt, falls der volle Dateiname für den Dateityp angemessen ist.
Überprüfung vieler weiterer Dateitypen unterstützt. Insgesamt erkennt die Datetyp-Prüfung jetzt über 3.000 Dateitypen.
Überarbeitete hiberfil.sys Unterstützung für 64-Bit-Windows.
hiberfil.sys-Schlupf (komprimierte Daten aus früheren Verwendungen der Datei hiberfil.sys, wie sie gegen deren Ende gefunden werden, wenn die letzte Verwendung stärkere Komprimierung erreicht hat als frühere Verwendungen) wird im Zuge der Funktion „Eingebettete Daten in diversen Dateitypen suchen“ jetzt automatisch extrahiert und dekomprimiert und in dekomprimierter Form als Unterobjekt zur Verfügung gestellt.
Datei-Carving-Methoden für .cwm (Bildschirmvideos) und .accountpicture-ms-Dateien aus Windows 8 wurden implementiert. .accountpicture-ms-Dateien werden jetzt standardmäßig bei der Suche nach eingebetteten Dateien mit geprüft.
Typ-Prüfung für .thumbdata3-Dateien (Android-Dateien, die beispielsweise auf SD-Karten gefunden werden).
E-Mail-Extraktion so angepaßt, daß bestimmte Base64-kodierte E-Mails von externen Programmen nach Wiederherstellen/Kopieren korrekt angezeigt werden.
Unterstützung für bestimmte alte Outlook PST E-Mail-Archive mit bislang nicht unterstützter Text-Kodierung. Benötigt die Auswahl der korrekten regionalen ANSI-Codepage in den Eigenschaften des Falls und Ankreuzen des unbeschrifteten Kästchens daneben, das einen Tooltip „Diese Codepage in Outlook PST erwarten“ zeigt.
Falls E-Mail-Nachrichten eine „Sender:“-Zeile zusätzlich zu einer „From:“-Zeile haben, wird der Absender laut „Sender:“-Zeile jetzt zusätzlich in der Absender-Spalte im Verzeichnis-Browser angezeigt, nach dem „From:“-Absender, falls diese tatsächlich unterschiedlich sind. Sie werden von Leerzeichen und einem Vertikalstrich ( | ) getrennt. Ein deutschsprachiges MS Outlook beispielsweise zeigt solche E-Mails als gesendet „im Auftrag von“ jemand anderem (vom „Sender:“-Absender im Auftrag des „From:“-Absenders). Sie können nach solchen E-Mails filtern, indem Sie den Vertikalstrich als Teilwort für die Absender-Spalte eingeben. Unterschiedliche Arten von Empfängern ( To:, Cc: und Bcc: ) werden jetzt analog mit Vertikalstrichen in der Empfänger-Spalte voneinander getrennt.
Ein möglicher Ausnahmefehler wurde behoben, der bei der Verarbeitung beschädigter OLE2-Verbund-Dateien auftreten konnte.
Abstürze im Umgang mit bestimmten EDB-Datenbanken verhindert.

Unterstützung für Bilder

Die Bildschirmfläche wird für die Galerie jetzt viel besser genutzt, da die Miniaturansichten nicht mehr zwangsweise quadratisch sind. Sie können jetzt Breite und Höhe Ihrer bevorzugten Kachelgröße getrennt eingeben, im Dialog Optionen | Viewer-Programme. Die angegebenen Maße werden automatisch angepaßt (vergrößert), um den verfügbaren Bildschirmplatz optimal auszunutzen, ohne Miniaturansichten teilweise anzuzeigen. Da die meisten Fotos und fast alle Videos im Querformat gemacht werden, möchten Sie Breite und Höhe evtl. entsprechend auswählen (die Breite größer als die Höhe), wenn Sie Bilder einsehen. Die Miniaturansichten für Dokumente können oft frei auf jede beliebige Rechteckform angepaßt werden, beispielsweise solche, die Textverarbeitungsdokumente oder Tabellenkalkulationen darstellen, aber nicht Präsentationen. Für die meisten Dokumente außer Präsentationen erscheint Hochformat als natürlichere Darstellungsform. Das Verhältnis der von Ihnen festgelegten Höhe und Breite wird im Optionen-Dialog angezeigt, um Ihnen schnell eine grobe Vorstellunge davon zu geben, wie verträglich diese Maße mit normalen Fotos, Videos oder Dokumenten sind.
Die Vorschau und Anzeige von Bildern (nicht mit der Viewer-Komponente) zeigt jetzt zusätzlich die Namen verknüpfter Berichtstabellen in der oberen linken Ecke und die Namen zutreffender PhotoDNA-Kategorien in der unteren rechten Ecke an.
Als Teil der Datei-Überblick-Erweiterung kann X-Ways Forensics Miniaturansichten von hochauflösenden Digitalbildern erzeugen, um die Galerie zu beschleunigen. Es ist jetzt möglich, die Auflösung (maximale Breite oder Höhe in Bildern) und Qualität (JPEG-Kompressionsfaktor) in der Benutzeroberfläche einzustellen. Der maximale Speicherplatz, den ein Miniaturbild im Datei-Überblick belegen darf, ist allerdings auf 64 KB beschränkt. Wenn ein erzeugtes Miniaturbild größer als das wird, wird X-Ways Forensics die benutzerdefinierte Auflösung automatisch entsprechend reduzieren.
Neue interne Berichtstabelle für animierte PNG-Bilder.
Extraktion eingebetteter Daten aus PNG-Dateien (z. B. GIF-Bilder) unterstützt.
Neue interne Berichtstabelle für PNG-Bilder, die wahrscheinlich Bildschirmfotos von Mobilgeräten sind. Diese Annahme basiert lediglich auf für Smartphones typische Auflösungen. Nützlich, wenn solche Bildschirmfotos nicht ihre typischen Dateinamen haben (wenn sie gecarvt, per App erhalten, auf andere Medien kopiert und vom Nutzer umbenannt oder von bestimmten Apps erzeugt und im Cache dieser App gespeichert wurden).
Die leichte und seltene Ungenauigkeit in der Darstellung von GeoTagging-Koordinaten in JPEG-Dateien wurde korrigiert.

Video-Verarbeitung

Ein neuer Befehl im Kontextmenü ermöglicht das gezielte Extrahieren aller Einzelbilder aus einem festgelegten Abschnitt eines ausgewählten Videos. Nützlich wenn ein bestimmter Abschnitt eines Videos von hohem Interesse ist und Sie die visuellen Details bestimmter Einzelbilder genauer anschauen oder diese im Bericht einfügen müssen. Sie können festlegen, wie viele aufeinanderfolgende Einzelbilder extrahiert werden sollen und ab welcher Sekunde. Die Anzahl der Einzelbilder, die Sie benötigen, um einen bestimmten Zeitraum abzudecken, können Sie aus der Bildrate, die in der Metadaten-Spalte angezeigt wird, ableiten (fps = frames per second). Bitte beachten Sie, daß die Startsekunde unter Umständen nur sehr grob interpretiert wird, je nach Häufigkeit der „Keyframes“ (genannt I-Frames in MPEG) im Video. MPlayer kann in einer Video-Datei nur Keyframes anspringen. Falls ein Video beispielsweise alle 4 Sekunden einen Keyframe besitzt, dann kann die Startsekunde der Extraktion um bis zu 4 Sekunden verschoben sein. Bitte bedenken Sie das, wenn Sie die Zahl der zu extrahierenden Einzelbilder, die Sie benötigen, oder die Startsekunde eingeben. Um auf der sicheren Seite zu sein, extrahieren Sie mehr Einzelbilder, als Sie brauchen, und vielleicht ab einer früheren Startsekunde.

Die Einzelbilder werden als JPEG-Dateien in einem Verzeichnis Ihrer Wahl gespeichert, wo Sie diese außerhalb von X-Ways Forensics durchsehen können. Wenn Sie möchten, können Sie die wichtigsten Einzelbilder der Original-Video-Datei natürlich als Unterobjekte im Datei-Überblick zuweisen. Die Einzelbilder werden standardmäßig nicht im Datei-Überblick gespeichert, um die Größe des Datei-Überblicks nicht unnötig mit möglicherweise überwiegend irrelevanten und redundanten Bilder aufzublähen. Falls das Ausgabeverzeichnis bereits extrahierte Einzelbilder enthält, werden Dateien mit identischen relativen Bildernummern überschrieben. Die relativen Bildnummern beginnen bei jeder Extraktion immer mit 00000001 und werden mit jedem Bild inkrementiert. Sie können die JPEG-Kompression für stärkere Komprimierung oder bessere Qualität anpassen, wenn nötig. (Sie können in den meisten Fällen natürlich keine sehr gute Qualität erwarten, da Videos zumeist bereits stark komprimiert sind.) Die Datei-Überblick-Erweiterungsoperation zur Erzeugung repräsentativer Einzelbilder aus Videos (vereinzelt, in bestimmten größeren Intervallen) wurde umbenannt, um den Unterschied zum neuen Kontextmenü-Befehl zur Erzeugung fortlaufender Einzelbilder anzuzeigen.
Aus Videos werden jetzt mehr Metadaten extrahiert (nur beim Exportieren von Einzelbildern), üblicherweise Kodierungs-/Kompressionsformat (coding), Auflösung, Bit pro Pixel (bpp), Bildrate (fps), Datenrate pro Sekunde für Videodaten.
Eine neue 64-Bit-Version des MPlayer von 2015 steht auf dem Web-Server zum Herunterladen bereit, zusätzlich zur 32-Bit-Version von 2014. MPlayer ist jetzt das einzige unterstützte Video-Extraktionsprogramm. Bitte beachten Sie, daß Sie die 64-Bit-Version von MPlayer durchaus auch von der 32-Bit-Fassung von X-Ways Forensics aus aufrufen lassen können und umgekehrt.

Dateisystemunterstützung

Verbesserte Einstellungen im Attr.-Filter für Unix-übliche Dateizugriffsrechte. Sie können jetzt auf jedes der 9+3 Bits ausdrücklich filtern und diese mit ODER, UND oder GLEICH verbinden. GLEICH verlangt, daß der Zustand aller 12 Bits exakt so ist, wie ausgewählt (egal, ob gesetzt oder nicht). UND bedeutet, daß alle ausgewählten Bits gesetzt sein müssen, der Rest aber egal ist. ODER bedeutet, es genügt bereits, wenn irgendeines der ausgewählten Bits gesetzt ist. SUID- und SGID-Bits können jetzt ebenfalls logisch mit ODER oder UND verknüpft sein (bisher waren sie immer mit ODER verknüpft). Bitte beachten Sie, wenn Sie sich für Verzeichnisse mit dem Sticky-Bit interessieren, müssen Sie Verzeichnisse beim rekursiven Erkunden mit ausgeben und Filter auch auf Verzeichnisse anwenden lassen (nicht die Standardeinstellung). Bitte beachten Sie, der logische Operator für die Zugriffsrechte sollte nicht normalerweise auf GLEICH gesetzt sein, da dies zu aktiver Filterung auf Zugriffsrechte auch dann führt, wenn gar keine Bits im Dialogfenster ausgewählt sind, im Unterschied zu den ODER- oder UND-Operatoren. GLEICH mit keinen ausgewählten Bits für Zugriffsrechte bedeutet, es wird auf Dateien gefiltert, die keine Bits für Zugriffsrechte gesetzt haben oder deren Zugriffsrechte unbekannt sind.
iNode*-Dateien (auf Deutsch: indirekte Knoten-Dateien) in HFS+ zeigen jetzt auf einen ihrer harten Verweis-Gegenstücke als „zugehöriges Objekt“ im Datei-Überblick, womit es sehr bequem wird, zumindest einen dieser harten Verweise zu identifizieren und die tatsächliche Verwendung und Ort der Datei zu sehen. Um andere harte Verweise für dieselbe iNode*-Datei zu finden, können Sie beispielsweise nach der Spalte „1. Sektor“ sortieren.
Ressourcenzweige in HFS und HFS+ werden jetzt als Unterobjekte dargestellt, analog zu alternativen Datenströmen und erweiterten Attributen in NTFS.
Attribut-Filter für Ressourcenzweige hinzugefügt.
Einzelne $MFT-Dateien können jetzt direkt und bequem interpretiert werden, als seien sie NTFS-Volumes, um zumindest die volle Auflistung aller Dateien und Verzeichnisse, mit Pfaden, Zeitstempeln und Attributen zu sehen. Es ist möglich, residente Dateien zu öffnen (Dateien, deren Inhalte klein genug sind, um in die FILE-Records zu passen), aber natürlich keine anderen Dateien. Nützlich in speziellen Situationen, wenn Sie nur die $MFT haben, nicht das gesamte Volume, z. B. extrahiert aus einer Schattenkopie.
Option, zusätzliche harte Verweise beim Erweitern des Datei-Überblicks in NTFS/HFS+ auszulassen, wie schon bisher bei logischen Suchen, um Zeit zu sparen und die Zahl redundanter identischer Unterobjekte zu reduzieren, etc. Dies kann auf Partitionen mit Windows-Installationen, die viele harte Verweise enthalten, und auf HFS+-Partitionen mit Mac OS X Time Machine einen großen Unterschied machen. Welche harten Verweise intern als die „zusätzlichen“ verstanden werden, kann wie bisher aus der Spalte „Verweise“ (graue Zahl bedeutet optional ausgelassen) und jetzt auch aus der Beschreibungsspalte abgelesen werden, die alle harten Verweise (d.h. Dateien mit zwei oder mehr harten Verweisen) und speziell die zusätzlichen textuell kennzeichnet. Derjenige harte Verweis, der in der Beschreibungsspalte nicht als „optional ausgelassen“ gekennzeichnet ist, wird intern als der „Haupt“-Verweis betrachtet.
Umbenennungsereignisse aus $J und Fragmenten davon werden jetzt in der Ereignisliste ausgegeben.
Dateien mit nur teilweise initialisierten Inhalten (gültige Datenlänge < logische Dateigröße) werden jetzt in der Attr.-Spalte mit dem Rautezeichen (#) gekennzeichnet, und eine Erklärung des #-Zeichens steht in der Legende.
In neu erzeugten Datei-Überblicken zeigt die Spalte „1. Sektor“ jetzt an, daß bestimmte Zahlen ungefähr sind, beispielsweise bei eingebetteten Dateien, mittels grauer Farbe und Tilde.
Beim Anklicken einer Datei im Partitions-/Volume-Modus ist der Sprung zum Anfang der Daten bestimmter Dateien jetzt präziser, beispielsweise bei residenten Dateien in NTFS führt dies direkt zum Body des Attributs 0x80 und bei bestimmten eingebetteten Dateien direkt zum Anfang der Daten. Das Sortieren nach der Spalte „1. Sektor“ gibt die physische Startposition von Dateien im Fall bestimmter nicht-Sektor-ausgerichteter Dateien präziser wieder.
Findet mehr Sessions von Multi-Session CDs/DVDs mit CDFS sofort, ohne die gründliche Dateisystem-Datenstruktur-Suche laufen lassen zu müssen.
Vermeidet die Session-Verdopplung bei CDs/DVDs mit CDFS, wo zusätzliche Sessions nur mittels der gründlichen Dateisystem-Datenstruktur-Suche gefunden werden.

Unterstützung für Datenträger & Images

Probeweise Unterstützung für ältere virtuelle Festplatten-Images vom Typ VirtualBox VDI von Sun Microsystems.
Ein Fehler wurde vermieden, der bei der gleichzeitigen Berechnung von zwei Hash-Werten bei der Datenträger-Sicherung auftreten konnte, wenn die Sicherung in einer sehr speziellen Konfiguration, einer Kombination aus einem spezifischen Hardware-Schreibblocker-Modell und einer spezifischen Windows-Version, erfolgte. Die Daten in der Sicherung waren dennoch in Ordnung.
Berichtet die Gesamtzahl nicht lesbarer Sektoren im Sicherungslog zusätzlich zu den betroffenen Sektorbereichen.
Die Sicherung bricht nach einem Datenträger-Trennungs-Fehler jetzt ab.

Fall- & Berichtseinstellungen

Kleinere Versionen von Bildern können jetzt optional speziell für den Bericht erzeugt werden, um den Speicherverbrauch des Browsers oder der Textverarbeitungsanwendung beim Laden des HTML-Berichts erheblich zu reduzieren und das Laden zu beschleunigen. Dies kann bei Berichten mit vielen hochauflösenden Fotos einen großen Unterschied machen. Der JPEG-Kompressionsfaktor ist vom Benutzer definierbar. Die Auflösung hängt von der angegebenen „max. Bildgröße im Bericht“ ab.

Das Kontrollkästchen, das diese Option repräsentiert, ist 3-stufig. Halb angekreuzt werden die kleineren Versionen der Bilder nur für die Darstellung direkt im HTML-Bericht verwendet. Voll angekreuzt sehen Sie auch nach dem Anklicken des Bildes im Bericht nur die kleinere Version und die größere Original-Datei ist im Bericht gar nicht enthalten. Dies kann nützlich sein, wenn Ihnen der Platzverbrauch Ihres Berichts mitsamt verlinkter Dateien wichtiger ist als die Ausgabequalität der Bilder.
Der Bericht kann jetzt optional auch Miniaturansichten von Nicht-Bild-Dateien anzeigen, z. B. Office-Dokumente, E-Mails, Webseiten, Software-Quellcode, usw. usf., ähnlich wie die Galerie. Sie können die Vorschaudarstellung leicht, oder erheblich, oder auch gar nicht schrumpfen lassen, um entweder in der Lage zu sein, einen Teil des Textes direkt im Bericht lesen zu können, ohne das Dokument zu öffnen, oder um einen besseren Eindruck der Gesamtdarstellung des Textes zu bekommen und nur Logos o.ä. zu sehen.
Wenn Sie gezielt eine Berichtstabelle im Fallbericht ausgeben lassen, wird jetzt automatisch ein Berichtsname basierend auf dem Namen der Berichtstabelle vorgeschlagen.
In den Eigenschaften eines Falls können Sie jetzt festlegen, ob X-Ways Forensics das fallspezifische Verzeichnis für temporäre Dateien (das Unterverzeichnis _temp dieses Falls) statt des allgemeinen verwenden soll, während dieser Fall aktiv ist.
Rein physische eigene Suchtreffer (im Disk-/Partitions-Modus festgelegt, nicht im Datei-Modus) können jetzt auch im Bericht ausgegeben werden, im Abschnitt über das Asservat, zu denen sie gehören. Datei-bezogene Suchtreffer werden weiterhin im Eintrag der Datei in der Berichtstabelle angezeigt, zusammen mit den ausgewählten Metadaten. Falls die Datei, zu der ein Suchtreffer gehört, der für die Ausgabe im Bericht ausgewählt wurde, nicht mit einer Berichtstabelle ausgegeben wird, kann der Suchtreffer jetzt im Abschnitt über das Asservat gesehen werden.
Option, fortlaufende Nummern im Fallbericht auszugeben, für jeden Eintrag in einer Berichtstabelle, um eine Datei in diesem Bericht eindeutig zu identifizieren.

Benutzeroberfläche

Alle Textfelder im gesamten Programm (mit Ausnahme von solchen für Paßwörter und Spaltenbreiten) merken sich jetzt eine Historie von bis zu 10 zuletzt verwendeten Einträgen. Die Historie kann gesehen werden, indem man den winzigen Knopf anklickt, der in einem Textfeld erscheint, für das eine Historie verfügbar ist. Alternativ können Sie die F4-Taste drücken, wie in normalen Drop-Down-Auswahlfeldern. Wenn Sie einen der früheren Einträge aus dem Pop-Up-Menü auswählen, wird dieser automatisch in das Textfeld eingetragen. Benutzer, die diese Historien löschen oder an andere weitergeben wollen, seien darauf hingewiesen, daß diese in der Datei History.dat gespeichert werden, wenn das Programm geschlossen wird. Wenn Sie keine Historien zwischen Programmläufen speichern möchten, z. B. als Schutz vor neugierigen Kollegen, können Sie einfach selbst eine leere Datei namens History.dat erzeugen und diese schreibschützen.
Eine neue Tastenkombination, Umsch+Strg+Entf, erlaubt Abgleich-Treffer mit gewöhnlichen Hash-Sets, FuzZyDoc-Hash-Sets und PhotoDNA-Kategorien für ausgewählte Dateien im Datei-Überblick zu entfernen, die sonst nicht verworfen werden, selbst, wenn die Hash-Sets aus der Datenbank gelöscht werden.
Das Drücken von Strg+C im Verzeichnis-Browser kopiert jetzt die Text-Daten der ausgewählten Objekte in die Zwischenablage, mit derselben Notation wie im Verzeichnis-Browser selbst, ansonsten dem Befehl Liste exportieren sehr ähnlich.
Die Farben für die Markierung (sofern nicht in Form von Häkchen dargestellt) sind jetzt etwas anders, und sie können jetzt in Optionen | Verzeichnis-Browser geändert werden. Nützlich beispielsweise, wenn Sie stärkere Farben bevorzugen oder die Standardfarben Bildern zu sehr ähneln, die Sie in der Galerie anschauen (z. B. viele Außenaufnahmen mit blauem Himmel). Falls Ihnen die etwas weniger auffälligen Farben früherer Versionen gefallen haben, können Sie diese manuell wieder einstellen: Farbe 1 = RGB 225, 225, 255 (für die obere linke Ecke) und Farbe 2 = RGB 163, 163, 255 (für die untere rechte Ecke).
Die Farben, die Dateien als bereits eingesehen kennzeichnen, sind jetzt ebenfalls nutzerdefinierbar, über Optionen | Viewer-Programme | Eingesehene Dateien merken | .... Falls Ihnen die Farben früherer Versionen gefallen haben, können Sie diese manuell wieder einstellen: Farbe 1 = RGB 233, 225, 223 (für die obere linke Ecke) und Farbe 2 = RGB 145, 250, 103 (für die untere rechte Ecke). In v18.7 wurden diese lediglich vertauscht.

Suchfunktionen

Die Option „1 Treffer pro Datei genügt“ der logischen parallelen Suche überspringt jetzt den Schlupfspeicher einer Datei nicht mehr, nachdem ein Treffer im logischen Teil gefunden wurde, wenn die Option „Schlupf öffnen und durchsuchen“ voll angekreuzt ist. Es durchsucht auch den Schlupf nach höchstens einem zusätzlichen Treffer.
Rein physische eigene Suchtreffer werden nun im Asservat-Überblick angezeigt, auch wenn Sie in diesem Fenster nicht zu den Sektorinhalten navigieren können, wenn Sie den Suchtreffer anklicken.
Es gibt jetzt eine Option, die Suche nach verlorenen Partitionen auf physischen Datenträgern auf die Sektoren zu beschränken, die der aktuellen Cursor-Position folgen.
Die Fehlinterpretation eines wörtlich spezifizierten # Zeichens in eckigen Klammern in GREP-Ausdrücken wurde behoben.
Verhindert sich überlappende Treffer in Zellen des Verzeichnis-Browsers bei Suche mit einem GREP-Ausdruck variabler Ziellänge.

Verschiedenes

Beim Ausblenden von Duplikaten basierend auf Hash-Wert oder Name zieht X-Ways Forensics jetzt im Zweifelsfall diejenige Kopie vor, deren Eigentümer bekannt ist.
Wiederherstellen/Kopieren und Bericht erzeugen benennen jetzt auch eingebettete .eml-Dateien nach ihrer eindeutigen ID, wenn die entsprechende Option ausgewählt ist.
Die interne Beschränkung der Datenmenge, die aus Dateien eines einzelnen Datei-Überblicks extrahiert werden kann (bislang 1 TB) wurde aufgehoben. Datei-Überblicke, die von v18.7 erzeugt wurden, können von v18.6 und früheren nicht mehr geöffnet werden.
Größere Dateien können jetzt an den Datei-Überblick angehängt werden.
Für die Datensatz-Darstellung im Hex-Editor werden die Datensätze jetzt standardmäßig beginnend mit 0 durchnumeriert, nicht mehr mit 1. 1-basierte Record-Nummern sind optional weiterhin möglich. Die Datensatz-Größe wird jetzt hexadezimal angegeben, wenn die Benutzeroberfläche aktuell hexadezimale Offsets benutzt.
Neue X-Tension API Funktion GetEvObj().
Fähigkeit, zugewiesene Hash-Sets in Berichtstabellen-Verknüpfungen umzuwandeln, im Dialog-Fenster für Berichtstabellen-Verknüpfungen, wo Sie auch enthaltene Suchtreffer in Berichtstabellen-Verknüpfungen umwandeln können. Dies kann beispielsweise nützlich sein, wenn Sie Ihre Hash-Datenbank neu anlegen oder löschen möchten, und nicht nur die Hash-Kategorie bekannter Dateien im Datei-Überblick erhalten möchten, sondern auch die exakten Namen der betreffenden Hash-Sets. Auch nützlich, wenn Sie Dateien zu einem Datei-Container hinzufügen möchten und dem Empfänger die ursprünglichen Hash-Set-Übereinstimmungen mitteilen möchten, nicht nur die Hash-Kategorie. Diese unterstützenden Berichtstabellen werden in einer anderen Farbe angezeigt, um sie zu unterscheiden von 1) gewöhnlichen benutzerdefinierten Berichtstabellen, 2) intern erzeugten Berichtstabellen, die den Benutzer auf bestimmte Besonderheiten hinweisen, und 3) Suchtreffer-basierten Berichtstabellen. Verknüpfungen mit Hash-Set-basierten Berichtstabellen können auch spontan beim Kopieren von Dateien in Datei-Container erzeugt werden.
Das Beifügen von Kommentaren und/oder Berichtstabellen-Verknüpfungen in einen Datei-Container ist jetzt optional für jede einzelne Kopier-Operation wählbar und muß nicht mehr ein für alle mal bei der Erzeugung des Containers festgelegt werden.
Die hauptsächlichen ausführbaren Dateien des Programms sind jetzt digital signiert.
Windows 10 ist jetzt eine offiziell unterstützte Plattform.
Viele kleinere Verbesserungen.
Einige kleine Fixes.
Die Programmhilfe und das Benutzerhandbuch wurden für v18.7 aktualisiert.

Änderungen der Service-Releases von v18.6:

SR-1: Verbesserte FuzZyDoc-Abgleich-Ergebnisse für PDF-Dokumente.
SR-1: Zeitzonen-Bewußtsein für Zeitstempel in exFAT jetzt für jede Datei einzeln definiert.
SR-1: Fähigkeit, „Virtual Allocation Table“ virtueller UDF-Partitionen in bestimmten nicht-standardmäßigen (unvollständigen) Datenträger-Sicherungen zu finden, wie sie von anderer Software erzeugt werden.
SR-1: Ein Ausnahmefehler wurde behoben, der in v18.6 beim Carven von Dateien in einem Datenfenster aufgetreten ist, das eine einzelne Datei ohne Datei-Überblick und ohne Verzeichnis-Browser darstellt.
SR-1: Der Effekt der nicht ausgewählten Option „Dateisystem-Dateien ausgeben“ für Dateien in Archiven wurde behoben.
SR-1: Die erfolglose Dekodierung bestimmten Base64-Codes wurde behoben.
SR-1: Ein extrem seltener Ausnahmefehler wurde verhindert, der beim Abgleich von Hash-Werten gegen die Hash-Datenbank auftreten konnte.
SR-2: Die Unfähigkeit von X-Ways Imager 18.6, Festplatten zu sichern, wurde behoben.
SR-3: Die gelegentlich unvollständige Extraktion eingebetteter JPEGs in PDF-Dokumenten wurde behoben.
SR-3: Ein möglicher Zeitzonen-Informationsfehler in den Eigenschaften eines Asservats mit einer Windows-Installation wurde behoben.
SR-3: Ein Ausnahmefehler wurde behoben, der mit bestimmten beschädigten Zoom Browser-Dateien (Canon) auftreten konnte.
SR-4: Die Zeitzonen-Umrechnung in der zweiten Spalte der Vorschau bestimmter index.dat-Dateien wurde korrigiert.
SR-4: Das gelegentlich unvollständige Ausblenden von Duplikaten auf Hash-Basis wurde behoben.
SR-4: Deduplizierung mehrerer sehr ähnlicher PhotoDNA-Hash-Werte jetzt auch beim Import in eine leere (neu erzeugte) PhotoDNA-Hash-Datenbank.
SR-4: Wenn ein neuer PhotoDNA-Hash-Wert nah genug an einem bestehenden ist, um als Treffer zu gelten, aber unterschiedlich genug, um einen getrennten Eintrag in der PhotoDNA-Hash-Datenbank zu begründen, wird seit v18.6 der bestehende Eintrag aktualisiert und ein neuer hinzugefügt. Dieser Doppeleintrag hat bislang nicht stattgefunden, wenn beide ähnlichen Hash-Werte in der gleichen Import-Operation hinzugefügt wurden, jetzt aber schon.
SR-5: Die Größenerkennung von Ext*-Partitionen größer als 2^32 Blöcke in Situationen, in denen sie nicht von einer Partitionstabelle referenziert werden, wurde korrigiert.
SR-5: Ein Speicherleck in der Dateisystem-Unterstützung von HFS wurde behoben.
SR-5: Die Unfähigkeit in SR-4, alle Filter mit einem Mausklick zu deaktivieren, wurde behoben.
SR-6: Ein Ausnahme- und Instabilitätsfehler, der beim Extrahieren von Metadaten aus bestimmten Dokumenten im OLE2-Format auftreten konnte, wurde behoben.
SR-6: In Ext4-Dateisystemen wurden einige sehr seltene Dateien mit nicht-initialisierten Bereichen bislang teilweise mit falschen Daten gelesen. Dies wurde behoben.
SR-6: Das Parsen von FAT32-Dateisystemen mit Cluster-Größen von 128 KB oder mehr in X-Ways Forensics wurde korrigiert.
SR-6: Fähigkeit, die ungefähre Pixelanzahl für Bilder anzuzeigen, die Treffer in der PhotoDNA-Datenbank haben.
SR-6: Die Optionen in investigator.ini bezüglich des neuen Beschreibungsfilters haben in v18.6 nicht funktioniert. Dies wurde behoben.
SR-7: Ein seltener Ausnahmefehler wurde behoben, der bei der Erzeugung einer HTML-Vorschau für Dateien bestimmter Typen auftreten konnte.
SR-7: Die mögliche Unfähigkeit wurde behoben, Miniaturansichten in der Galerie auszuwählen, während Bilder mit der Viewer-Komponente angezeigt werden.
SR-7: Verbesserte Stabilität bei der Verarbeitung von SQLite-Datenbanken.
SR-7: Verbessertes Sicherungsverhalten nach einem Datenträger-Trennungs-Fehler.
SR-7: Die Möglichkeit, in v18.6 die Option +51 der investigator.ini zu umgehen, wurde verhindert.
SR-8: Eine möglicherweise unvollständige Auflistung der Partitionen im Verzeichnis-Browser wurde behoben, wenn mehr als eine Partition halb-automatisch erkannt wurde, beginnend mit dem vom Nutzer angezeigten Sektor.
SR-8: Ein Fehler wurde behoben, der beim Lesen von Partitionen auftreten konnte, deren Dateisystem eine andere Sektorgröße verwendet als die Sektorgröße des physischen Datenträgers.
SR-8: Eine falsch angezeigte Dateigröße für riesige Dateien in UDF-Dateisystemen wurde korrigiert.
SR-8: Ein seltener Fehler beim Auflösen symbolischer Verweise wurde korrigiert.

Viewer-Komponente

Oracle hat ein "Critical Patch Update" für die Version 8.5.2 der Viewer-Komponente herausgegeben. Die aktualisierte Version ist von unserem Web-Server herunterladbar. Sie ist wahrscheinlich aus Sicherheitsgründen empfehlenswert.

Oracles Beschreibung des Updates beginnt wie üblich mit der Ankündigung, daß eine Beschreibung dessen, was gefixt wurde, folgt, hält dies aber nicht ein:

What this Update Fixes:
January 2016 Critical Patch Update for Outside In
This patch is cumulative with all previous Outside In 8.5.2 Critical Patch Updates

Auf einer Web-Seite von Dritten wurde folgende Beschreibung des Fixes des Sicherheitsproblems gefunden: "Ein lokaler Benutzer kann eine Schwachstelle in der Oracle Outside In Technology Outside In Filter-Komponente component ausnutzen, um teilweise Denial-of-Service-Bedingungen zu verursachen." Die einzige Datei, die sich tatsächlich geändert hat, ist sccfnt.dll. Diese Datei ist für Schriftarten zuständig.

Freundliche Grüße

Stefan Fleischmann

--
X-Ways Software Technology AG
Carl-Diem-Str. 32
32257 Bünde

> Archiv des Jahres 2015 <

> Archiv des Jahres 2014 <

> Archiv des Jahres 2013 <

> Archiv des Jahres 2012 <

> Archiv des Jahres 2011 <

> Archiv des Jahres 2010 <

> Archiv des Jahres 2009 <

> Archiv des Jahres 2008 <

> Archiv des Jahres 2007 <

> Archiv des Jahres 2006 <

> Archiv des Jahres 2005 <

> Archiv des Jahres 2004 <

> Archiv des Jahres 2003 <

> Archiv des Jahres 2002 <

> Archiv des Jahres 2001 <

> Archive of the year 2000 <


Preise einsehen, Angebote einholen, bestellen (Neulizenzen)
Upgrades und Verlängerungen bestehender Lizenzen
Produkte
	X-Ways Forensics
	Integrierte Forensik-Software
	X-Ways Investigator
	Ermittler-Version von X-Ways Forensics
	X-Tensions
	Zusätzliche Module
	Excire Forensics
	Foto-Analyse mit KI
	WinHex
	Lizenztypen
	Upgrade
	Forensische Features
	Alle Features
	X-Ways Imager
	Disk-Imaging
Dienstleistungen
	Schulungsangebot
	Zertifizierung
	Benutzerforum

	Kontakt
	Die X-Ways AG
	Datenschutzerklärung
	Stellenangebote