Wie arbeitet eine HDD?
Festplatten sind kleine Computer die einen ROM-Chip auf der Platine besitzen der ähnlich dem BIOS eines PCs den Systemstart anstößt. Danach wird das "Betribssystem" der Platte die sogenannte Firmware geladen und die Platte startet. Die Firmware befindet sich auf der Platte selbst, abgetrennt von den Userdaten in der sogenannten Service-Area auf die der User keinen Zugriff hat. Um mit der Firmware der Platten zu arbeiten sind spezielle Tools wie zB DFL, MRT oder PC-3000 nötig. Diese bestehen aus einer USB-Box oder PCIe-Karte die die Platten ansteuert und der dazugehörigen Software. Das sind auch jene Tools die professionelle Datenretter einsetzen! Die Kosten derartiger Werkzeuge liegen umgerechnet auf Euro im mittleren 4-stelligen und unteren 5-stelligen Bereich.
Die Firmware ist in sogenannte Module aufgeteilt. Ein Modul ist entwerder ein Programm für eine bestimmte Aufgabe wie zB der sogenannte "Translator". Das ist das Modul, dass die LBA-Adressen in Bewegungen des Schreib-/Lesekopfes umsetzt. Dazu benötigt der Translator unter anderem auch die sogenannte P-List und G-List. Diese zwei Module sind reine Daten, die die werksseitig als defekt ausgemappten Sektoren (P-List / Production-List) und die während des Betriebs ausfallenden Sektoren (G-List / Growing-List) enthalten. Die P-List stellt also die "Produktionsfehler" dar und sorgt dafür, das der Translator diese kennt und überspringt. In der G-List werden Sektoren eingetragen wenn diese kaputt gehen und nachträglich ausgemappt werden.
Die Anzahl der nachträglich ausgefallenen Sektoren wird dann auch in den S.M.A.R.T. Daten vermerkt.
Was ist S.M.A.R.T.?
S.M.A.R.T. steht für Self-Monitoring, Analysis and Reporting Technology und dient zur Überwachung von Festplatten und SSDs. Durch das Erfassen verschiedenster Sensorendaten und diverser statistischer Daten lässt sich ein Überblick über den Zustand des Datenträgers gewinnen und ein möglicher bevorstehender Ausfalls frühzeitig erkennen.
Sehr oft zeigen sich lange vor einem Ausfall des Datenträgers bereits erste Anzeichen für das Ende. Hier wäre zB der "Reallocated Sector Count" (Reallocated_Sector_Ct) zu nennen der angibt wieviele defekte Sektoren ausgemappt wurden. Wenn das Sektorsterben einmal beginnt sollte man sich nach einem Ersatz umsehen - eine Platte kann noch Wochen, Monate oder eventuell sogar Jahre mit defekten und ausgemappten Sektoren laufen aber früher oder später wird sie ausfallen.
Mehr dazu finden Sie unter: https://de.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Technology
Sehen wir uns dazu ein Beispiel einer von uns geretteten Platte an:
=== START OF INFORMATION SECTION ===
Model Family: Seagate Laptop Thin HDD
Device Model: ST500LT012-1DG142
Serial Number: W3PLAKQK
LU WWN Device Id: 5 000c50 08b28efa4
Firmware Version: 0002LVM1
User Capacity: 500.107.862.016 bytes [500 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Jan 30 11:38:49 2021 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 092 088 034 Pre-fail Always - 191075858
3 Spin_Up_Time 0x0003 099 099 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 099 099 020 Old_age Always - 1654
5 Reallocated_Sector_Ct 0x0033 001 001 036 Pre-fail Always FAILING_NOW 63408
7 Seek_Error_Rate 0x000f 069 060 030 Pre-fail Always - 34423923816
9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 1694
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 099 099 020 Old_age Always - 1653
184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 001 001 000 Old_age Always - 1419
188 Command_Timeout 0x0032 100 099 000 Old_age Always - 38655295497
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 074 048 045 Old_age Always - 26 (Min/Max 26/26)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 522
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 25
193 Load_Cycle_Count 0x0032 073 073 000 Old_age Always - 54286
194 Temperature_Celsius 0x0022 026 052 000 Old_age Always - 26 (0 16 0 0 0)
197 Current_Pending_Sector 0x0012 100 099 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 099 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
254 Free_Fall_Sensor 0x0032 100 100 000 Old_age Always - 0
Damit können wir mal rechnen:
500.107.862.016 bytes : 512 bytes Sektorgröße = 976.773.168 Sektoren
63.408 defekte Sektoren : 976.773.168 Sektoren gesamt = 0,000064916 => 0,0064916 % der Sektoren sind ausgemappt worden
Diese Platte wurde wegen der vielen defekten Sektoren derart instabil, dass ein herkömmlicher Windows-Rechner einfrohr wenn die Platte angeschlossen wurde. Darum wurde diese auch an uns zur Datenrettung geschickt.
Was sind LBA- und PBA-Adressen?
LBA (Logical Block Addresses) sind primär für das Betriebssystem gedacht. Diese nummerieren die im oberen Beispiel genannten 976.773.168 Sektoren von 0 bis 976.773.167 durch. Somit kann das Betriebssystem bzw. der Dateisystem-Treiber die Sektoren mit ihrer Nummer ansprechen. PBA (Physical Block Addresses) stellen eine Nummerierung der tatsächlichen physischen Sektoren von 0 - X dar!
In einer perfekten Platte ohne defekte Sektoren stimmen die LBA und PBA Nummern überein.
Was passiert wenn ein Sektor ausfällt?
Wird nun zB Sektor 172.301 (LBA und PBA) defekt, dann wird dieser durch einen Reservesektor ersetzt und dies etweder werkseitig in der P-List eingetragen oder nachträglich im Betrieb in der G-List. Ab diesem Zeitpunnkt zeigt nun LBA 172.301 beispielsweise auf PBA 976.774.200! Das Betriebssystem bekommt davon nichts mit und kann LBA 172.301 wie gewohnt verenden nur ist dieser physisch nun an einer ganz anderen Stelle auf den Magnetscheiben der HDD. Einzig ein Eintrag in den S.M.A.R.T. Daten wird den User darauf hinweisen, dass es nun einen neu zugewiesenen Sektor gibt.
Hierbei zählt S.M.A.R.T. nur die Sektoren die über die G-List neu zugewiesen wurden - also nur diejenigen die im Betrieb nachträglich ausfallen!
Ab dem Zeitpunkt der Neuzuweisung hat der User keinen Zugriff auf diese ausgefallenen Sektoren mehr.
Bei diesem doch schon recht extremen Beispiel gibt es also 63.408 Sektoren die neu zugewiesen wurden, die dann weder gelöscht noch überschrieben werden können ohne das ausmappen rückgängig zu machen. Wir sprechen hier also von 63.408 x 512 bytes = 32.464.896 bytes = 31.704 kb = ca. 31 Megabyte an Datenfragmenten die nicht so einfach zu entfernen sind!
Sicheres löschen
Werden Daten gelöscht (zB indem man den Papierkorb leert) dann wird im Prinzip nur der Speicherplatz dieser Dateien wieder als frei verfügbar markiert. Die Daten sind aber nicht gelöscht sonder verbleiben auf der Platte. Bei einigen neuen HDDs und bei den SSDs werden Daten mit dem sogenannten TRIM Kommando sicher gelöscht. Das funktioniert quasi wie die Müllabfuhr - in der Zeit in der der Rechner nicht ausgelastet ist wird im Hintergund der Datenmüll beseitigt.
Bei allen anderen HDDs verbleiben die Daten auf der Platte bis diese von neuen Daten überschrieben werden. Wird also eine Platte weitergegeben, verkauft oder entsorgt muss man diese vorab sicher löschen oder mechanisch derart beschädigen, dass eine Datenrettung nicht mehr möglich ist. Andernfalls könnte jemand an die Daten kommen.
Beim sicheren Löschen wird die Platte je nach Standard mehrfach überschrieben. Bei DoD wären das dreimalig und bei VSITR wären es 7 Überschreibvorgänge. Also Datenretter kann ich sagen, dass einmaliges überschreiben ausreicht! Die diversen Standards wollen aber nicht nur den momentanen Stand der Technik abdecken, sondern auch bei zukünftigen technischen Entwicklungen entsprechende Sicherheit bieten.
Festplatten speichern Daten als Folge von Nullen und Einsen in Form von magnetischen Ladungen. Diese werden beim Überschreiben mit Nullen in der Theorie nicht völlig eleminiert so, dass kleine magnetische reste überbleiben.
Dies habe ich in der oberen Grafik anhand des Wortes "HDD" (010010000100010001000100) dargestellt. Wo der rote Schreib-/Lesekopf bereits die Daten überschrieben hat, verbleiben kleine Restmagnetisierungen. Diese sind mit der in der Platte verbauten Elektronik nicht mehr von einer Null zu unterscheiden!
Der Ansatz Restmagnetisierung zu nutzen ist stark vereinfacht relativ leicht zu erklären - man nutzt einen Verstärker und wandelt das Signal nicht in 1-bit Werte (0 oder 1) sondern in viele zwischenstufen - zB 0 bis 4096. Damit würden zB die noch nicht gelöschten Einsen in der Datenspur zu 4096 und die bereits gelöschten Ensen zu 32. Die Datenmenge die dadurch entsteht wäre allerdings auch um ein vielfaches größer als die ursprüngliche Platte.
Um die ursprünglichen Daten zu erhalten müsste man dann die 4096 Abstufungen auf die Werte 0 und 1 mappen. So könnte man sagen, dass alle Werte die unter 32 sind eine 0 werden und alles ab 32 eine 1. Platten werden aber nicht nur einmalig bespielt und dann wieder gelöscht - vielmehr wird mit Ihnen gearbeitet und hier kommen auch die zwei rot markierten Nullen ins Spiel. Diese sollen Einsen von zuvor an dieser Stelle gespeicherten Daten darstellen, die dann mit den Nullen von "HDD" überschrieben worden sind. Es wird also davon abhängen, wie gut und genau wir dem Trennpunkt für das Mapping bestimmen können ob wir großteils brauchbare oder großteils beschädigte Daten erhalten!
Ein Datenretter-Kollege hat es mit folgenden Worten auf den Punkt gebracht:
"So, in practice; give me a 250.000 EUR research budget and a year of time, I may be able to recover an old 5MB up to maybe 20MB drive that was zero filled."
Bei modernen Festplatten sind die Daten so dicht gepackt, dass die gleiche Technik nicht mehr möglich ist. Hier kann man nur noch mit Elektronenmikroskopen arbeiten, die eine wesentlich höhere Auflösung und damit feinere Abstufunden erlauben. Abgesehen davon das so ein Elektronenmikroskop ca. 1 Million Euro kostet steigt der Speicherbedarf um die vielen kleinen Abstufungen erfassen zu können nochmals extrem an. Man darf also neben dem Mikroskop auch noch eine kleine Serverfarm voll mit Storage-Servern anschaffen.
Wer sich genauer in die Thematik einlesen und mit den theoretischen Grundlagen beschäftigen will, kann sich zB folgenden Artikel ansehen: https://www.researchgate.net/publication/228775030_Daten_sicher_loschen
Ein praktischer Versuch wäre ebenfalls sehr einfach machbar - kramen Sie Omas alten Kassettenrecorder und eine Musikkasette hervor. Wenn Sie nun bei kompletter Stille die Kasette überspielen, was das Gegenstück zum Nullen der Daten wäre, können Sie diese danach bei voller Lautstärke abspielen und in Hintergrundrauschen sollte die alte Aufnahme noch etwas zu hören sein.
Dabei gehen wir immer vom besten Fall aus, wie sie sich denken können wird es natürlich nochmal schwerer wenn wir die Daten nicht mit Nullen sondern mit einem Zufallsmuster überschreiben. Aber Daten sollen ja nicht nur im Moment sicher sein sondern auch in Zukunft. Daher greife ich nun das Beispiel meines Kollegen auf der eine uralte 5 ¼" Festplatte mit 5 MB Speicher nannte. Eine solche wäre zB die ST506 von Seagate aus dem Jahr 1980/1981.
Wenn es uns heute endlich gelingt die damals streng geheimen Daten die "nur" einmalig mit Nullen überschrieben worden sind wiederherzustellen stellen sich einige weitere Probleme:
In der IT-Branche sind Programme, Systeme und alle verwendeten Technologien sehr kurzlebrig. Selbst wenn man sagen würde die Platte wurde 10 Jahre lang benutzt und erst 1990 außer Dienst gestellt - woher nimmt man nun die Betriebssysteme, Programme und entsprechende funktionierende Hardware oder einen Emulator damit man die Daten auch wieder lesen kann? Es würde auch ungleich schwerer herauszufinden welche Programme damals verwendet wurden wenn man diese nicht zB auf der Platte finden würde oder Insiderwissen besitzt!
Außerdem verblassen magnetische Ladungen mit der Zeit - magnetisieren Sie mal einen Nagel und schauen Sie wie lange dieser dann magnetisch bleibt! Wir mussten die Platte also jahrzehntelang so lagern, dass die kleinen Magnetreste nicht verblassen - auch das ist bereits schon ein enormer Aufwand und ein reales Problem mit dem zB das Rechtssystem zu kämpfen hat. Beweismittel von forensischen Untersuchungen wie HDDs müssen auch da eventuell für sehr lange Zeit gelagert werden.
Ganz abgesehen davon stellt sich natürlich die Frage ob die Daten nun 30 Jahre später noch immer geheimgehalten werden müssen bzw. ob es noch jemanden interessiert oder ob noch ein Schaden entstehen kann. Damalige Firmengeheimnisse können heute völlig wertlos sein, Kundenlisten und Einkaufpreise können unmöglich noch stimmen, usw.
Da in der Regel finanzielle Mittel nicht unbegrenzt zur Verfügung stehen schauen wir uns an wie weit wir mit Tools kommen die rund 5.000 EUR kosten. Dazu habe ich die besagte Platte mit spezialisierter Datenrettungshardware geclont. Zuvor mussten jedoch die Firmware diesbezüglich manipuliert werden, dass auf die ausgemappten Sektoren wieder zugegriffen werden konnte. Dies schließt die "günstigsten" Hardware-Imager (Deepspar DDI und RapidSpar) leider aus, da diese keine so gezielte Firmware-Bearbeitung erlauben. Und so landen wir bei den zuvor genannten Tools der zwei asiatischen Hersteller. Der Branchenführer PC-3000 ist für diese Summe noch nicht zu haben - zumindest nicht mit der Möglichkeit die Daten auch zu klonen!
Es bedarf also eines nicht unerheblichen finanziellen Aufwandes und des Wissens wie man mit den entsprechen Tools arbeitet sowie dem Wissen wie man das ausmappen bei dieser Firmware rückgängig machen kann. Das würde ich schon als erheblichen Aufwand bezeichnen um ein paar Fragmente wiederherzustellen von denen man nicht einmal weiß was diese enthalten!
Auf Spurensuche ...
Also verlassen wir mal den Pfad der Vernunft und nehmen an, dass ein paar Tausend Euro, Sinnhaftigkeit und zeitlicher Aufwand keinerlei Rolle spielen. Dazu habe ich eine kleine Dateisammlung erstellt und jeweils ein 512 Byte (1 Sektor), 4 Kilobyte (ein EF- oder 4k-Sektor) und ein 32 Kilobyte (64 Sektoren bzw. 8 EF-Sektoren) großes Fragment vom Dateianfang und der Dateimitte entnommen.
Dies habe ich mit folgendem Python-Script erledigt:
#!/usr/env/python3
import os
dir = os.getcwd()
files = os.listdir(dir)
for f in files:
fpath = os.path.join(dir, f)
if os.path.isfile(fpath) and not f.endswith(".py"):
print(f)
# Read file
sector_size = 512
sectors = []
with open(fpath, "rb") as fh:
sector = fh.read(sector_size)
while sector:
sectors.append(sector)
sector = fh.read(sector_size)
middle = int(len(sectors) / 2)
# Save fragments
fpath = os.path.join(os.path.join(dir, "512b"), "first_" + f)
with open(fpath, "wb") as fh:
sector = fh.write(sectors[0])
fpath = os.path.join(os.path.join(dir, "512b"), "middle_" + f)
with open(fpath, "wb") as fh:
sector = fh.write(sectors[middle])
fpath = os.path.join(os.path.join(dir, "4kb"), "first_" + f)
with open(fpath, "wb") as fh:
for i in range(8):
sector = fh.write(sectors[i])
fpath = os.path.join(os.path.join(dir, "4kb"), "middle_" + f)
with open(fpath, "wb") as fh:
for i in range(middle, middle + 8):
sector = fh.write(sectors[i])
if f.endswith(".jpg") or f.endswith(".mp4") or f.endswith(".bmp"):
fpath = os.path.join(os.path.join(dir, "32kb"), "first_" + f)
with open(fpath, "wb") as fh:
for i in range(64):
sector = fh.write(sectors[i])
fpath = os.path.join(os.path.join(dir, "32kb"), "middle_" + f)
with open(fpath, "wb") as fh:
for i in range(middle, middle + 64):
sector = fh.write(sectors[i])
Daraus ergibt sich folgende Datei- und Ordnerstruktur:
user@caine ~$ ls *
artikel.docx artikel.txt exif.jpg extract.py no_exif.jpg PIC000.bmp sample.mp4
32kb:
first_artikel.docx first_no_exif.jpg first_sample.mp4 middle_exif.jpg middle_PIC000.bmp
first_exif.jpg first_PIC000.bmp middle_artikel.docx middle_no_exif.jpg middle_sample.mp4
4kb:
first_artikel.docx first_exif.jpg first_PIC000.bmp middle_artikel.docx middle_exif.jpg middle_PIC000.bmp
first_artikel.txt first_no_exif.jpg first_sample.mp4 middle_artikel.txt middle_no_exif.jpg middle_sample.mp4
512b:
first_artikel.docx first_exif.jpg first_PIC000.bmp middle_artikel.docx middle_exif.jpg middle_PIC000.bmp
first_artikel.txt first_no_exif.jpg first_sample.mp4 middle_artikel.txt middle_no_exif.jpg middle_sample.mp4
Die Fragmente können Sie auch herunterladen und sich so selber daran versuchen...
Gehen wir nun die Datentypen vom einfachsten bis zum aufwändigsten Fall durch...
Textdateien
... stellen sicher den schlimmsten Fall dar denn diese enthalten nur Text und sind damit auch problemlos lesbar selbst wenn man nur ein Fragment beseitzt:
user@caine ~$ xxd 512b/middle_artikel.txt
00000000: 6169 6c73 2c20 5765 6273 6569 7465 6e20 ails, Webseiten
00000010: 756e 6420 7669 656c 656e 2061 6e64 6572 und vielen ander
00000020: 656e 2044 696e 6765 6e2e 2044 6120 6469 en Dingen. Da di
00000030: 6573 2069 6d6d 6572 2077 6965 6465 7220 es immer wieder
00000040: 7a75 2053 6368 7769 6572 6967 6b65 6974 zu Schwierigkeit
00000050: 656e 2c20 4665 686c 6572 6e20 756e 6420 en, Fehlern und
00000060: 5072 6f62 6c65 6d65 6e20 66c3 bc68 7274 Problemen f..hrt
00000070: 6520 7775 7264 656e 2064 6965 2055 6e69 e wurden die Uni
00000080: 636f 6465 2d5a 6569 6368 656e 6b6f 6469 code-Zeichenkodi
00000090: 6572 756e 6765 6e20 6465 7220 5546 542d erungen der UFT-
000000a0: 4661 6d69 6c69 6520 6765 7363 6861 6666 Familie geschaff
000000b0: 656e 2e20 4865 7574 6520 6973 7420 5554 en. Heute ist UT
000000c0: 462d 3820 6469 6520 616d 2077 6569 7465 F-8 die am weite
000000d0: 6e73 7465 6e20 7665 7262 7265 6974 6574 nsten verbreitet
000000e0: 6520 5a65 6963 6865 6e6b 6f64 6965 7275 e Zeichenkodieru
000000f0: 6e67 2e0a 0a0a 5554 462d 3820 6465 7220 ng....UTF-8 der
00000100: 5265 7474 6572 2069 6e20 6465 7220 4e6f Retter in der No
00000110: 743a 0a2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d t:.-------------
00000120: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d0a ---------------.
00000130: 0a44 616d 6974 2077 6972 6420 6573 206e .Damit wird es n
00000140: 6963 6874 206d 6568 7220 6ec3 b674 6967 icht mehr n..tig
00000150: 2066 c3bc 7220 6469 6520 7665 7273 6368 f..r die versch
00000160: 6965 6465 6e65 6e20 5370 7261 6368 656e iedenen Sprachen
00000170: 2075 6e74 6572 7363 6869 6564 6c69 6368 unterschiedlich
00000180: 6520 5a65 6963 6865 6e6b 6f64 6965 7275 e Zeichenkodieru
00000190: 6e67 656e 207a 7520 7665 7277 656e 6465 ngen zu verwende
000001a0: 6e20 6465 6e6e 2055 5446 2d38 2076 6572 n denn UTF-8 ver
000001b0: 6569 6e74 2064 6965 205a 6569 6368 656e eint die Zeichen
000001c0: 2076 6572 7363 6869 6564 656e 6572 2053 verschiedener S
000001d0: 7072 6163 6865 6e20 696e 2065 696e 6572 prachen in einer
000001e0: 2065 696e 7a69 6765 6e20 5a65 6963 6865 einzigen Zeiche
000001f0: 6e6b 6f64 6965 7275 6e67 2e20 536f 206b nkodierung. So k
Sie sehen also, dass die Daten direkt leesbar sind mit einem Hexeditor - schöner können wir diese mit cat ausgeben:
user@caine ~$ cat 512b/middle_artikel.txt
ails, Webseiten und vielen anderen Dingen. Da dies immer wieder zu Schwierigkeiten, Fehlern und Problemen führte wurden die Unicode-Zeichenkodierungen der UFT-Familie geschaffen. Heute ist UTF-8 die am weitensten verbreitete Zeichenkodierung.
UTF-8 der Retter in der Not:
----------------------------
Damit wird es nicht mehr nötig für die verschiedenen Sprachen unterschiedliche Zeichenkodierungen zu verwenden denn UTF-8 vereint die Zeichen verschiedener Sprachen in einer einzigen Zeichenkodierung. So k
Also sehen wir uns nun ein mögliches Bedrohungsszenario an:
Nehmen wir an, dass wir innsgesamt 100 MB Textdateien auf der oben genannten Platte haben. Das klingt nach relativ wenig aber eine maschinengeschriebene A4-Seite enthält ca. 2.000 Zeichen und das sind ca. 2 kb! 100 MB entsprechen grob gerechnet 100.000 kb also wären 100 MB Textdateien mind. 50.000 A4-Seiten vertrauliches Material ohne Absätze oder Leerzeilen! Drucken Sie diesen Bericht hier dann sind geschätzt 20% der Fläche leer also können wir eher von 60.000 Seiten hochbrisanter Informationen ausgehen!
Diese 100 MB belegen 204.800 der innsgesammt 976.773.168 Sektoren. Damit haben Sie in dem aktuellen Fall einfach ausgedrückt 63.408 Lottarielose die jeweils eine Chance von 204.800 : 976.773.168 oder verkürzt ca. 1 : 4769 haben einen Treffer zu landen! Wer also seine Festplatten voll mit Geheimnissen hat die unverschlüsselt in reinen Textdateien liegen sollte alte Festplatten lieber einschmelzen oder ins All schießen als diese anderweitig zu entsorgen...
Aber auch das kann man etwas relativieren denn zu den reinen Textdateien zählen auch XML-, YAML, CSV- und viele andere Dateiformate. Diese enthalten nicht nur reinen Text sondern Trennzeichen, Einrückungen um Gruppierungen anzuzeigen oder sogenannte Tags die dazu dienen die Daten zu strukturieren und zu beschreiben. Als Beispiel dazu habe ich eine fiktive Rechnungs-XML erdacht:
<?xml version="1.0" encoding="UTF-8"?>
<bill no="2021-00123">
<clientID>10234</clientID>
<shipto>
<name>Mark Berger</name>
<address>Einestraße 23</address>
<city>4000 Irgendwo</city>
<country>AUSTRIA</country>
</shipto>
<note>Geschenverpackung in blau!</note>
<item>
<title>Hacken mit Kali</title>
<quantity>1</quantity>
<price>29.90</price>
</item>
<item>
<title>Hacken mit Python</title>
<quantity>1</quantity>
<price>24.90</price>
</item>
</shiporder>
Diese ist bewusst so gestatltet, dass Sie genau 512 Byte lang ist. Sie sehen also mit XML passen deutlich weniger Informationen in einen Sektor als in reiner Textform. Dafür werden die Informationen allerdings auch ausführlich erklärt und strukturiert. Praktisch gesehen kann man dies weiter relativieren denn in der Regel schreibt niemand Briefe oder Rechnungen in reiner Textform sondern nutzt Programme wie Word, Excel oder spezielle Fakturierungs- und Buchhaltungsprogramme! Textdateien sind eher typisch für automatisch erstellte Logdateien, temporäre Internetdateien wie HTML-, CSS- und JS-Dateien und XML- kommt meist beim Datenaustausch und bei Datenexport und -import zum Einsatz.
Bitmap-Dateien
Bitmap-Dateiformate sind primitive Bildformate die für jedes Pixel den entsprechenden Wert speichern. Das verbraucht sehr viel Speicherplatz im Vergleich zu komprimierten Bildformaten, ist dafür aber sehr leicht mit einem Hexeditor zu rekonstruieren. Aber sehen wir uns zunächst an wie wir eine BMP-Datei überhaupt erkennen:
user@caine ~$ xxd 512b/first_PIC000.bmp
00000000: 424d 36cc 0300 0000 0000 3600 0000 2800 BM6.......6...(.
00000010: 0000 8001 0000 d800 0000 0100 1800 0000 ................
00000020: 0000 00cc 0300 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 a1a8 b29e a9b3 9aa8 b18f ................
00000040: a5af 8c9f a694 9fa3 a7b2 b9a6 b1bb 9cab ................
00000050: c06d 87a1 1d4e 4e1f 372b 2e38 2c2e 382b .m...NN.7+.8,.8+
00000060: 2d37 2a2e 382b 3040 2b36 4c2f 374d 363c -7*.8+0@+6L/7M6<
00000070: 4f39 424c 3555 5d42 9e88 75ae a393 a3a6 O9BL5U]B..u.....
00000080: 939f a18e 908e 8377 756d 5759 4842 4f39 .......wumWYHBO9
00000090: 3d4f 383a 4f37 3b4f 343c 5133 3d53 323b =O8:O7;O4E+3=)08'
00000120: 2f36 292e 332a 3037 2d3b 4b3d 3a54 403d /6).3*07-;K=:T@=
00000130: 5b3e 4261 4245 6445 4664 453b 543f 2c3f [>BaBEdEFdE;T?,?
00000140: 302f 3f2c 303c 2c2c 3828 2935 2526 3522 0/?,0<,,8()5%&5"
00000150: 273a 222b 4327 2c48 2f2f 4e35 2e51 3732 ':"+C',H//N5.Q72
00000160: 5239 3352 3932 5138 3450 3836 5137 3652 R93R92Q84P86Q76R
00000170: 3437 5332 3d4f 3249 4b31 6d64 4895 846d 47S2=O2IK1mdH..m
00000180: 9f8f 859d 9787 a09f 88bc b5af afb8 a997 ................
00000190: a093 8892 8a77 827e 596e 6533 4c3e 1d34 .....w.~Yne3L>.4
000001a0: 2321 3320 2934 2429 3226 2932 2729 3827 #!3 )4$)2&)2')8'
000001b0: 2a41 2a29 482e 2c4a 332e 4d33 3050 3235 *A*)H.,J3.M30P25
000001c0: 5431 3a58 373b 583a 3b57 3b3d 593c 3d59 T1:X7;X:;W;=Y<=Y
000001d0: 3c44 5d3f 4b61 4048 5d3c 495e 3d54 6747 <D]?Ka@H]<I^=TgG
000001e0: 5b6d 4f6d 7f64 798e 7e85 9c95 91b0 b181 [mOm.dy.~.......
000001f0: a9ad 8195 9998 a0a0 8695 925d 7165 415b ...........]qeA[
Eine BMP-Datei hat einen Header (rot) der mit 0x42 0x4D beginnt. Dies ist die sogenannte "Magic Number" bzw. Dateisignatur die eine BMP-Datei kennzeichnet. Viele andere Dateiformate haben dies ebenfalls. Ein JPG beginnt zB mit 0xFF 0xD8 und endet mit 0xFF 0xD9. Danach folgt der Bitmap-Infoheader (gelb) und die Bilddaten. Formal passt das Fragment also schon mal auf die BMP-Spezifikationen also sehen wir nach was exiftool dazu sagt:
user@caine ~$ exiftool 512b/first_PIC000.bmp
ExifTool Version Number : 10.80
File Name : first_PIC000.bmp
Directory : 512b
File Size : 512 bytes
File Modification Date/Time : 2021:02:01 20:02:46+01:00
File Access Date/Time : 2021:02:01 20:05:30+01:00
File Inode Change Date/Time : 2021:02:01 20:02:46+01:00
File Permissions : rw-rw-r--
File Type : BMP
File Type Extension : bmp
MIME Type : image/bmp
BMP Version : Windows V3
Image Width : 384
Image Height : 216
Planes : 1
Bit Depth : 24
Compression : None
Image Length : 248832
Pixels Per Meter X : 0
Pixels Per Meter Y : 0
Num Colors : Use BitDepth
Num Important Colors : All
Image Size : 384x216
Megapixels : 0.083
Vergleichen wir das mit der Hex-Ausgabe von xdd dann können wir folgendes festhalten. Laut https://de.wikipedia.org/wiki/Windows_Bitmap soll an Offset 18 die Breite und an Offset 22 die Höhe der Datei gespeichert sein - jeweils als 32bit bzw. 4byte langer Wert. An Offset 28 finden wir die Bittiefe als 16bit oder 2byte langen Wert und am Offset 34 finden wir in dem Fall die Bildgröße in Bytes. Die entsprechenden Werte haben ich in der Hex-Ausgabe grün hinterlegt und in der Ausgabe von exiftool auf die gleiche Weise markiert! Außerdem muss man wissen, dass man diese Werte in 2er Gruppen von Hinten nach Vorne lesen muss - also steht 8001 0000 für 0x00000180! Damit können wir nun rechnen:
user@caine ~$ python3
>>> 0x00000180
>>>384
>>> 0x000000d8
>>>216
>>> 0x0003cc00
248832
>>> 0x0018
24
24bit Farbtiefe : 3 Farbkanäle (Rot, Grün, Blau) = 8bit pro Kanal = 1 Byte pro Kanal x 3 Kanäle = 3 Byte pro Pixel!
384 Pixel Breite x 216 Pixel Höhe x 3 Byte für Farbwerte = 248832 Byte. Damit ist die Ausgabe schlüssig und wir haben überprüft, dass exiftool diese Werte aus dem Header zieht und diese 4 Stellen des Headers enthalten Werte die zusammenpassen. Damit ist die Chance sehr groß, dass wir es hier mit einer BMP-Datei zu tun haben. Wie Sie hier gut sehen können, ist das testen und verifizieren um welchen Dateityp es sich handelt eine mühsame "Sisyphus Aufgabe". Genau aus diesem Grund habe ich für dieses Experiment bestimmte Dateitypen ausgewählt und entsprechend präpariert anstatt mit realen Daten zu arbeiten. Eine derartige Aufgabe anhand eines realen Falles durchzuführen würde einige hundert Arbeitsstunden verschlingen! So etwas wird bei forensischen Untersuchungen in Außnahmefällen sogar gemacht.
Nachdem wir nun wissen was für eine Datei wir hier haben, können wir eine leere BMP-Datei mit der entsprechenden Dateigröße erstellen:
user@caine ~$ xxd empty.bmp
00000000: 424d 36cc 0300 0000 0000 3600 0000 2800 BM6.......6...(.
00000010: 0000 8001 0000 d800 0000 0100 1800 0000 ................
00000020: 0000 00cc 0300 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 ffff ffff ffff ffff ffff ................
00000040: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000050: ffff ffff ffff ffff ffff ffff ffff ffff ................
...
0003cc20: ffff ffff ffff ffff ffff ffff ffff ffff ................
0003cc30: ffff ffff ffff ......
Wenn wir diese nun mit den 512 Byte, 4 bzw. 32 Kilobyte fragmenten füllen indem die leere Datei und das Fragment mit einem Hexeditor öffnen und die Daten des Fragments kopieren und damit einfach den Dateianfang der leeren Datei überschrieben. Ich habe dies jeweils unter einem neuen Dateinamen abgespeichert:
Aber was ist wenn wir kein Fragment vom Dateianfang erhalten sondern ein Fragment aus der Mitte?
... dann können wir weder mit Bestimmtheit sagen um welchen Dateityp es sich handelt noch welche Dateigröße oder Bittiefe die BMP-Datei haben würde wenn es denn ein Teil einer Bitmapdatei wäre! Kurz um wir müssen raten - was den Dateityp betrifft kann man bestimmte Dateitypen mit einer Analyse der Datenstruktur ausschließen aber es bleiben viele mögliche Kandidaten über. Daher wollen wir uns nur kurz ansehen was passieren würde wenn wir versuchen das 32 Kilobyte Dateifragment aus der Mitte der Datei in eine leere BMP-Datei einbauen:
Beim ersten Bild sind die Bildgröße und die Farbtiefe richtig - dennoch sind die Farben falsch und das Bild wirkt verschoben. Um dies zu verstehen betrachten wir zunächst die zusammengefügten BMP-Bilder von den Start-Fragmenten. Bei 512b_first.bmp sehen wir, dass sich das Bild von links unten aufbaut und die Daten zeilenweise aufgebaut werden. Mit dem Wissen können wir nun rechnen:
512 Byte - 54 Byte Header-Daten = 458 Byte Bilddaten : 3 Byte pro Pixel = 152,67 Pixel
Darum ist bei diesem Bild die erste Zeile auch nur ca. zur Hälfte gefüllt. Bild 4k_first.bmp zeigt, dass die weiteren 3,5 Kilobyte die ersten 4 Zeilen füllen und bei 32 Kilobyte kann man schon gut erkennen, dass das Bild eine Makroaufnahme einer Platine zeigt.
Nachdem wir nun jeweils 1 Byte für den Rot-, Grün- und Blauwert verwenden ist die Farbverschiebung einfach erklärt - wir haben einen Versatz in den einzelnen Werten so, dass zB die Rotwerte aus den Blauwerten genommen werden, usw. Durch das Einfügen oder Löschen von 1 oder 2 Byte vor den Bilddaten kann dies behoben werden! Außerdem ist der Linienanfang nicht an der linken Seite des Bildes und daher wirkt das Bild wie zwei nicht zusammenpassende Hälften! Nachdem die Farbe korregiert wurde können wir jeweils 3 Byte mit 0xFF vor den Bildfragment einschließen oder löschen bis wir den Bildanfang der Zeilen auch ausgerichtet haben (after_shifting.bmp).
Die Bittiefe und Dateigröße ermitteln wir wie gesagt durch raten - hierzu könnten wir Bildbreiten von zB 100 bis 2000 Pixel erstellen und die Daten einfügen um zu sehen welche Breite passen kann. Kommt man der passenden Breite langsam näher dann wird das Bild erkennbar. Man kann also auch in 2 oder maximal 3 Pixel Schritten arbeiten um ein paar Bilder zu sparen oder alternativ mit einem Hex-Editor einfach das entsprechende Header-Feld schrittweise ändern und die Datei immer wieder speichern und betrachten.
Alles in allem eine Mühsame Aufgabe die noch dazu nicht mal mit Garantie zum Erfolg führt - denn es kann immer noch der falsche Dateityp sein oder das Bild könnte kleiner oder größer als die geschätzte Mindest- bzw. Maximalgröße sein!
JPEG-Bilder
JPEGs sind im Gegensatz zu Bitmaps komprimiert aber dadurch wird auch der Dateiaufbau um einiges komplexer. Sie werden wie bereits erwähnt durch 0xFF 0xD8 eingeleitet. Den weiteren Feldaufbau und die einzelnen Teile des Bildes erklärt dieser Artikel sehr gut. Ich will an dieser Stelle nur noch erwähnen, dass Kameras alles mögliche interessante in den EXIF-Daten einbetten. Das reicht von Infomationen zu Kamera und Objektiv über GPS-Koordinaten bis zu kleinen Vorschaubildern und Copyright-Vermerken des Fotografen. Also sehen wir uns die einmal an:
user@caine ~$ xxd 512b/first_exif.jpg
00000000: ffd8 ffe0 0010 4a46 4946 0001 0101 0060 ......JFIF.....`
00000010: 0060 0000 ffe1 111a 4578 6966 0000 4949 .`......Exif..II
00000020: 2a00 0800 0000 0a00 0f01 0200 1200 0000 *...............
00000030: 8600 0000 1001 0200 0b00 0000 9800 0000 ................
00000040: 1a01 0500 0100 0000 a400 0000 1b01 0500 ................
00000050: 0100 0000 ac00 0000 2801 0300 0100 0000 ........(.......
00000060: 0200 0000 3101 0200 2a00 0000 b400 0000 ....1...*.......
00000070: 3201 0200 1400 0000 de00 0000 3b01 0200 2...........;...
00000080: 0d00 0000 f200 0000 9882 0200 2000 0000 ............ ...
00000090: 0001 0000 6987 0400 0100 0000 2001 0000 ....i....... ...
000000a0: 4a03 0000 4e49 4b4f 4e20 434f 5250 4f52 J...NIKON CORPOR
000000b0: 4154 494f 4e00 4e49 4b4f 4e20 4436 3130 ATION.NIKON D610
000000c0: 0000 4800 0000 0100 0000 4800 0000 0100 ..H.......H.....
000000d0: 0000 4164 6f62 6520 5068 6f74 6f73 686f ..Adobe Photosho
000000e0: 7020 4c69 6768 7472 6f6f 6d20 352e 3620 p Lightroom 5.6
000000f0: 284d 6163 696e 746f 7368 2900 3230 3136 (Macintosh).2016
00000100: 3a30 373a 3236 2031 373a 3534 3a31 3800 :07:26 17:54:18.
00000110: 4d61 7274 696e 2048 7562 6572 0000 7777 Martin Huber..ww
00000120: 772e 6d61 7274 696e 6875 6265 722d 7068 w.martinhuber-ph
00000130: 6f74 6f67 7261 7068 792e 636f 6d00 2300 otography.com.#.
00000140: 9a82 0500 0100 0000 ca02 0000 9d82 0500 ................
00000150: 0100 0000 d202 0000 2288 0300 0100 0000 ........".......
00000160: 0100 0000 2788 0300 0100 0000 6400 0000 ....'.......d...
00000170: 0090 0700 0400 0000 3032 3330 0390 0200 ........0230....
00000180: 1400 0000 da02 0000 0490 0200 1400 0000 ................
00000190: ee02 0000 0192 0a00 0100 0000 0203 0000 ................
000001a0: 0292 0500 0100 0000 0a03 0000 0492 0a00 ................
000001b0: 0100 0000 1203 0000 0592 0500 0100 0000 ................
000001c0: 1a03 0000 0792 0300 0100 0000 0500 0000 ................
000001d0: 0892 0300 0100 0000 0400 0000 0992 0300 ................
000001e0: 0100 0000 1000 0000 0a92 0500 0100 0000 ................
000001f0: 2203 0000 02a0 0900 0100 0000 d007 0000 "...............
Der 512 Byte große Sektor zeigt schon gut, dass auch eine String-Suche denkbar wäre - wir können hier herauslesen, dass das Bild mit einer Nikon D610 aufgenommen und mit Photoshop Lightroom bearbeitet wurde. Außerdem findet sich eine Datums und Zeitangabe sowie ein Name und eine URL die dem Copyright-Vermerk des Fotografen darstellen. Bevor wir nun wieder den Header und die EXIF-Daten von Hand decodieren überlassen wir dies exiftool:
user@caine ~$ exiftool 512b/first_exif.jpg
ExifTool Version Number : 10.80
File Name : first_exif.jpg
Directory : .
File Size : 512 bytes
File Modification Date/Time : 2021:02:01 00:53:34+01:00
File Access Date/Time : 2021:02:01 00:53:34+01:00
File Inode Change Date/Time : 2021:02:01 00:53:34+01:00
File Permissions : rw-rw-r--
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
Warning : JPEG format error
... das schlägt aber leider fehl da das Programm nicht mit halben Datensätze klarkommt und darum nur eine Warnung ausgibt. Nach einer kurzem Studium des Aufbaues der EXIF-Daten war dann klar, dass in diesen keine wirklich wichtigen oder interessanten Informationen stecken. Also sehen wir uns das 4kb Fragment an:
user@caine ~$ exiftool 4kb/first_exif.jpg
ExifTool Version Number : 10.80
File Name : first_exif.jpg
Directory : .
File Size : 512 bytes
File Modification Date/Time : 2021:02:01 00:53:34+01:00
File Access Date/Time : 2021:02:01 00:53:34+01:00
File Inode Change Date/Time : 2021:02:01 00:53:34+01:00
File Permissions : rw-rw-r--
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
Warning : JPEG format error
Auch das schlägt fehl, was darauf hindeutet, dass wir ein eingebettetes Vorschaubild haben könnten. Also prüfen wir das:
user@caine ~$ xxd 4kb/first_exif.jpg | grep JFIF
00000000: ffd8 ffe0 0010 4a46 4946 0001 0101 0060 ......JFIF.....`
000003c0: 0000 0100 0000 ffd8 ffe0 0010 4a46 4946 ............JFIF
Bingo! Um das Vorschaubild zu extrahieren müssen wir alles vom zweiten ffd8 bis zum nächsten ffd9 oder dem Dateiende in einem Hexeditor kopieren und in eine neue Datei einfügen. Gesagt, getan und wir erhalten:
Sushi, yammi!
Außerdem gibt es noch eine JPG-Datei ohne EXIF-Daten in dem Download-Paket. Diese können Sie ebenfalls einfach mit einem robusten Bildbetrachter der eine gewisse Fehlertoleranz hat öffnen. Ich habe hierzu unter Linux Gwenview verwendet. Im Gegensatz zum JPG-Bild mit den Exif-Daten, das beim 4KB Fragment noch keinerlei Informationen des Bildes in voller Auflösung enthält, kann man hier bereits einen kleinen Teil der Bilddaten anzeigen lassen:
Das 32kb Fragment offenbart dann auch noch alle EXIF-Daten:
user@caine ~$ exiftool 32kb/first_exif.jpg
ExifTool Version Number : 10.80
File Name : first_exif.jpg
Directory : 32kb
File Size : 32 kB
File Modification Date/Time : 2021:02:02 10:33:23+01:00
File Access Date/Time : 2021:02:02 10:47:50+01:00
File Inode Change Date/Time : 2021:02:02 10:33:23+01:00
File Permissions : rw-rw-r--
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
JFIF Version : 1.01
Exif Byte Order : Little-endian (Intel, II)
Make : NIKON CORPORATION
Camera Model Name : NIKON D610
X Resolution : 72
Y Resolution : 72
Resolution Unit : inches
Software : Adobe Photoshop Lightroom 5.6 (Macintosh)
Modify Date : 2016:07:26 17:54:18
Artist : Martin Huber
Copyright : www.martinhuber-photography.com
Exposure Time : 1/30
F Number : 4.0
Exposure Program : Manual
ISO : 100
Exif Version : 0230
Date/Time Original : 2016:05:20 18:57:38
Create Date : 2016:05:20 18:57:38
Shutter Speed Value : 1/30
Aperture Value : 4.0
Exposure Compensation : 0
Max Aperture Value : 1.0
Metering Mode : Multi-segment
Light Source : Flash
Flash : Off, Did not fire
Focal Length : 55.0 mm
Exif Image Width : 2000
Exif Image Height : 1335
Focal Plane X Resolution : 1675.014984
Focal Plane Y Resolution : 1675.014984
Focal Plane Resolution Unit : cm
Sensing Method : One-chip color area
File Source : Digital Camera
Scene Type : Directly photographed
CFA Pattern : [Red,Green][Green,Blue]
Custom Rendered : Normal
Exposure Mode : Manual
White Balance : Manual
Digital Zoom Ratio : 1
Focal Length In 35mm Format : 55 mm
Scene Capture Type : Standard
Gain Control : None
Contrast : Normal
Saturation : Normal
Sharpness : Normal
Subject Distance Range : Unknown
Compression : JPEG (old-style)
Thumbnail Offset : 966
Thumbnail Length : 3433
Image Width : 2000
Image Height : 1335
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
Aperture : 4.0
Image Size : 2000x1335
Megapixels : 2.7
Scale Factor To 35 mm Equivalent: 1.0
Shutter Speed : 1/30
Thumbnail Image : (Binary data 3433 bytes, use -b option to extract)
Circle Of Confusion : 0.030 mm
Field Of View : 36.2 deg
Focal Length : 55.0 mm (35 mm equivalent: 55.0 mm)
Hyperfocal Distance : 25.17 m
Light Value : 8.9
... und erlaubt es uns dann ein vollständiges Vorschaubild zu extrahieren:
Außerdem lässt sich das Bild in voller Größe ansehen - zumindest der Teil der in den 32kb enthalten ist:
Gleiches gilt an dieser Stelle für die JPG-Datei ohne EXIF-Daten und die BMP-Datei:
Die Fragmente aus der Mitte lassen sich im Grunde in ähnlicher Weise wie bei einem BMP-Bild rekonstuieren. Nur haben wir hier das Problem, dass wir die Quantisations- und Huffman-Tabellen der Header erraten oder rückrechnen müssten. Hierbei sind die JPG Repair Tools von DiskTuna sehr hilfreich aber auch nur dann wenn wir Headerdaten aus einem anderen Fragment oder einem vollständigen Bild der gleichen Kamera extrahieren konnten. Den Aufbau vom JPEG-Format im Detail zu besprechen würde aber an dieser Stelle den Umfang bei Weitem sprengen. Es ist an dieser Stelle auch ungleich Komplexer als bei einem Bitmap-Bild.
Daher wenden wir uns an dieser Stelle mit dem nächsten Dateityp beschäftigen...
Neue XML-basierte Office-Dateien (docx, xlsx, pptx, ...)
Diese Dateien sind im Grunde nur ZIP-Dateien, die eine bestimmte Ordnerstruktur mit XML-Dateien enthalten. Dies lässt sich sehr einfach prüfen:
user@caine ~$ unzip -l artikel.docx
Archive: artikel.docx
Length Date Time Name
--------- ---------- ----- ----
573 2021-01-31 23:38 _rels/.rels
525 2021-01-31 23:38 docProps/app.xml
731 2021-01-31 23:38 docProps/core.xml
6669 2021-01-31 23:38 word/_rels/document.xml.rels
280 2021-01-31 23:38 word/settings.xml
1576 2021-01-31 23:38 word/fontTable.xml
43 2021-01-31 23:38 word/media/image6.gif
43 2021-01-31 23:38 word/media/image5.gif
43 2021-01-31 23:38 word/media/image4.gif
43 2021-01-31 23:38 word/media/image3.gif
43 2021-01-31 23:38 word/media/image1.gif
43 2021-01-31 23:38 word/media/image2.gif
5146 2021-01-31 23:38 word/styles.xml
1532 2021-01-31 23:38 [Content_Types].xml
1393942 2021-01-31 23:38 word/document.xml
--------- -------
1411232 15 files
Um an den Inhalt zu kommen können wir Zip2Fix von LeeLu Soft verwenden oder ZipRepair von Datanumen oder einige andere Tools. Ich habe mich hier für das kostenlose Zip2Fix entschieden. Außerdem gibt es einige weitere Tools die die Reparatur von Office-Dokumenten erlauben unter anderem auch von Datanumen. Also sehen wir uns an was Zip2Fix extrahieren konnte:
user@caine ~$ unzip -l 512b/first_artikel_ZFX.zip
Archive: 512b/first_artikel_ZFX.zip
Length Date Time Name
--------- ---------- ----- ----
573 2021-01-31 23:38 _rels/.rels
--------- -------
573 1 file
user@caine ~$ unzip -l 512b/middle_artikel_ZFX.zip
Archive: 512b/middle_artikel_ZFX.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
note: 512b/middle_artikel_ZFX.zip may be a plain executable, not an archive
unzip: cannot find zipfile directory in one of 512b/middle_artikel_ZFX.zip or
512b/middle_artikel_ZFX.zip.zip, and cannot find 512b/middle_artikel_ZFX.zip.ZIP, period.
user@caine ~$ unzip -l 4kb/first_artikel_ZFX.zip
Archive: 4kb/first_artikel_ZFX.zip
Length Date Time Name
--------- ---------- ----- ----
573 2021-01-31 23:38 _rels/.rels
525 2021-01-31 23:38 docProps/app.xml
731 2021-01-31 23:38 docProps/core.xml
6669 2021-01-31 23:38 word/_rels/document.xml.rels
280 2021-01-31 23:38 word/settings.xml
1576 2021-01-31 23:38 word/fontTable.xml
43 2021-01-31 23:38 word/media/image6.gif
43 2021-01-31 23:38 word/media/image5.gif
43 2021-01-31 23:38 word/media/image4.gif
43 2021-01-31 23:38 word/media/image3.gif
43 2021-01-31 23:38 word/media/image1.gif
43 2021-01-31 23:38 word/media/image2.gif
5146 2021-01-31 23:38 word/styles.xml
--------- -------
15758 13 files
user@caine ~$ unzip -l 4kb/middle_artikel_ZFX.zip
Archive: 4kb/middle_artikel_ZFX.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
note: 4kb/middle_artikel_ZFX.zip may be a plain executable, not an archive
unzip: cannot find zipfile directory in one of 4kb/middle_artikel_ZFX.zip or
4kb/middle_artikel_ZFX.zip.zip, and cannot find 4kb/middle_artikel_ZFX.zip.ZIP, period.
user@caine ~$ unzip -l 32kb/first_artikel_ZFX.zip
Archive: 32kb/first_artikel_ZFX.zip
Length Date Time Name
--------- ---------- ----- ----
573 2021-01-31 23:38 _rels/.rels
525 2021-01-31 23:38 docProps/app.xml
731 2021-01-31 23:38 docProps/core.xml
6669 2021-01-31 23:38 word/_rels/document.xml.rels
280 2021-01-31 23:38 word/settings.xml
1576 2021-01-31 23:38 word/fontTable.xml
43 2021-01-31 23:38 word/media/image6.gif
43 2021-01-31 23:38 word/media/image5.gif
43 2021-01-31 23:38 word/media/image4.gif
43 2021-01-31 23:38 word/media/image3.gif
43 2021-01-31 23:38 word/media/image1.gif
43 2021-01-31 23:38 word/media/image2.gif
5146 2021-01-31 23:38 word/styles.xml
1532 2021-01-31 23:38 [Content_Types].xml
--------- -------
17290 14 files
user@caine ~$ unzip -l 32kb/middle_artikel_ZFX.zip
Archive: 32kb/middle_artikel_ZFX.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
note: 324kb/middle_artikel_ZFX.zip may be a plain executable, not an archive
unzip: cannot find zipfile directory in one of 32kb/middle_artikel_ZFX.zip or
32kb/middle_artikel_ZFX.zip.zip, and cannot find 32kb/middle_artikel_ZFX.zip.ZIP, period.
Auch hier können wir mit den Fragmenten aus der Dateimitte nichts anfangen - zumindest nicht ohne in irgend einer Form den Dateiheader zu rekonstruieren!
Dann nehmen wir uns mal den schlimmsten Fall vor und betrachten alle extrahierten Dateien - mit 43 Byte sind die GIF-Dateien nicht wirklich interessant sondern nur kleine Spacer-GIFs mit ein paar Pixel. Diese können wir also überspringen. Im Dokument eingefügte Bilder und Grafiken würden sich ebenfalls im Ordner word/media/ finden. Der Hauptteil mit den Daten, die word/document.xml fehlt hier. Eventuell lässt sich mit eigens geschriebener Software auch eine beschädigte Datei mit Fragmenten des XML-Codes extrahieren aber die Standard-Tools lassen dies nicht zu. Also sehen wir uns nun an welche Informationen wir in den anderen XML-Dateien finden:
user@caine ~$ cat first_artikel_ZFX/\[Content_Types\].xml
<Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types"><Override PartName="/_rels/.rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/><Override PartName="/docProps/app.xml" ContentType="application/vnd.openxmlformats-officedocument.extended-properties+xml"/><Override PartName="/docProps/core.xml" ContentType="application/vnd.openxmlformats-package.core-properties+xml"/><Override PartName="/word/_rels/document.xml.rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/><Override PartName="/word/settings.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.settings+xml"/><Override PartName="/word/fontTable.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.fontTable+xml"/><Override PartName="/word/media/image6.gif" ContentType="image/gif"/><Override PartName="/word/media/image5.gif" ContentType="image/gif"/><Override PartName="/word/media/image4.gif" ContentType="image/gif"/><Override PartName="/word/media/image3.gif" ContentType="image/gif"/><Override PartName="/word/media/image1.gif" ContentType="image/gif"/><Override PartName="/word/media/image2.gif" ContentType="image/gif"/><Override PartName="/word/document.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"/><Override PartName="/word/styles.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.styles+xml"/>
</Types>
... liefert keine besonderen Erkenntnisse außer einer weiteren Bestätigung, dass es sich um eine XML-basierte Office-Datei handelt.
user@caine ~$ cat first_artikel_ZFX/docProps/app.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Properties xmlns="http://schemas.openxmlformats.org/officeDocument/2006/extended-properties" xmlns:vt="http://schemas.openxmlformats.org/officeDocument/2006/docPropsVTypes"><Template></Template><TotalTime>4</TotalTime><Application>LibreOffice/6.0.7.3$Linux_X86_64 LibreOffice_project/00m0$Build-3</Application><Pages>37</Pages><Words>8466</Words><Characters>43686</Characters><CharactersWithSpaces>51168</CharactersWithSpaces><Paragraphs>2034</Paragraphs></Properties>
... erlaubt die Feststellung das diese Datei mit Libreoffice 6.0.7.3 unter einem Linux in der 64bit Variante erstellt wurde. Außerdem erhalten wir statistische Informationen zu der Datei wie zB die 37 Seiten (gelb) oder 8466 Wörter (grün) die in der Datei enthalten sind. Eine Kombination aus den Werten der Seiten-, Absatz-, Wörter- und Zeichenanzahl sowie dem Betriebssystem und der Programmversion kann als eine Art "Fingerabdruck" dieser Datei dienen. Sie können gern versuchen eine Datei mit exakt diesen Werte zu erstellen.
user@caine ~$ cat first_artikel_ZFX/docProps/core.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cp:coreProperties xmlns:cp="http://schemas.openxmlformats.org/package/2006/metadata/core-properties" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:dcmitype="http://purl.org/dc/dcmitype/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><dcterms:created xsi:type="dcterms:W3CDTF">2021-02-01T00:16:49Z</dcterms:created><dc:creator></dc:creator><dc:description></dc:description><dc:language>de-DE</dc:language><cp:lastModifiedBy></cp:lastModifiedBy><dcterms:modified xsi:type="dcterms:W3CDTF">2021-02-01T00:38:57Z</dcterms:modified><cp:revision>2</cp:revision><dc:subject></dc:subject><dc:title></dc:title></cp:coreProperties>
... liefert uns in diesem Fall Dinge wie das Erstellungsdatum (rot), das Datum der letzten Modifikation (grün) und die Erkenntniss, dass dies die zweite Version der Datei ist (blau) sowie die Sprache (orange). Weitere mögliche Informationen wie der Titel, eine Beschreinung oder die Namen des Erstellers und desjenigen der die Datei weiter bearbeitet hat sind in diesem Fall nicht ausgefüllt.
Das sind keine Informationen die für sich allein genommen etwas wirklich geheimes verraten. Wir können so maximal sagen wer wann eine 37-seitige Word-Datei mit welcher Software bearbeitet hat. Aber in krimialfällen ist dies unter Umständen Gold wert. So worden derartige Metadaten zB dem BTK-Killer zum Verhängnis der einen Brief auf dem Computer eine Kirchengemeinde geschrieben hatte. Die Lizenznehmer-Informationen, die als Ersteller der Datei eingetragen wurden, führten die Ermittler bis zu dem Computer auf dem die Datei verfasst wurde und von da war es nicht mehr weit zu Dennis Rader!
Hier könnte man ebenfalls anhand des Fragments mit großer Wahrscheinlichkeit eine Datei einem Computer zuordnen denn die Chance, dass auf die Sekunde genau eine andere Datei erstellt und bearbeitet wurde, die ebenfalls in genau 2 Versionen fertiggestellt wurde und die gleiche Anzahl an Seiten, Wörtern, Absätzen, Zeichen, etc. hat ist schon sehr gering vor allem wenn man noch das Betriebssystem Linux und die exakte Programmversion mit einbezieht. Natürlich wäre das kein eindeutiger Beweiß aber mathematisch gesehen eine sehr hohe Wahrscheinlichkeit. Außerdem könnte man zB die 8kb eines EF-Sektors Byte für Byte vergleichen und so mit einer Wahrscheinlichkeit von 1 : 4096256 (4096 Zeichen hoch der 256 möglichen Werte je Zeichen) bzw.
1 : 5. 809. 605. 995. 369. 958. 062. 859. 502. 533. 304. 574. 370. 686. 975. 176. 362. 895. 236. 661. 486. 152. 287. 203. 730. 997. 110. 225. 737. 336. 044. 533. 118. 407. 251. 326. 157. 754. 980. 517. 443. 990. 529. 594. 540. 047. 121. 662. 885. 672. 187. 032. 401. 032. 111. 639. 706. 440. 498. 844. 049. 850. 989. 051. 627. 200. 244. 765. 807. 041. 812. 394. 729. 680. 540. 024. 104. 827. 976. 584. 369. 381. 522. 292. 361. 208. 779. 044. 769. 892. 743. 225. 751. 738. 076. 979. 568. 811. 309. 579. 125. 511. 333. 093. 243. 519. 553. 784. 816. 306. 381. 580. 161. 860. 200. 247. 492. 568. 448. 150. 242. 515. 304. 449. 577. 187. 604. 136. 428. 738. 580. 990. 172. 551. 573. 934. 146. 255. 830. 366. 405. 915. 000. 869. 643. 732. 053. 218. 566. 832. 545. 291. 107. 903. 722. 831. 634. 138. 599. 586. 406. 690. 325. 959. 725. 187. 447. 169. 059. 540. 805. 012. 310. 209. 639. 011. 750. 748. 760. 017. 095. 360. 734. 234. 945. 757. 416. 272. 994. 856. 013. 308. 616. 958. 529. 958. 304. 677. 637. 019. 181. 594. 088. 528. 345. 061. 285. 863. 898. 271. 763. 457. 294. 883. 546. 638. 879. 554. 311. 615. 446. 446. 330. 199. 254. 382. 340. 016. 292. 057. 090. 751. 175. 533. 888. 161. 918. 987. 295. 591. 531. 536. 698. 701. 292. 267. 685. 465. 517. 437. 915. 790. 823. 154. 844. 634. 780. 260. 102. 891. 718. 032. 495. 396. 075. 041. 899. 485. 513. 811. 126. 977. 307. 478. 969. 074. 857. 043. 710. 716. 150. 121. 315. 922. 024. 556. 759. 241. 239. 013. 152. 919. 710. 956. 468. 406. 379. 442. 914. 941. 614. 357. 107. 914. 462. 567. 329. 693. 696
aufzeigen, dass eine Datei auf einem bestimmten PC zumindest gespeichert war. Nicht mal das Erstellen könnte man so zweifelsfrei nachweisen denn Metadaten sind einerseits editierbar und somit fälschbar und das eine Datei auf einer Festplatte gespeichert war bedeutet nicht zwangsläufig, dass diese auch auf dem dazugehörigen Rechner erstellt wurde!
user@caine ~$ cat first_artikel_ZFX/_rels/.rels
<?xml version="1.0" encoding="UTF-8"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"><Relationship Id="rId1" Type="http://schemas.openxmlformats.org/package/2006/relationships/metadata/core-properties" Target="docProps/core.xml"/><Relationship Id="rId2" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/extended-properties" Target="docProps/app.xml"/><Relationship Id="rId3" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="word/document.xml"/>
</Relationships>
... würde Informationen zu verknüpften Dateien enthalten. In diesem Fall sind aber keine zusätzlichen Dateien verknüpft.
user@caine ~$ cat first_artikel_ZFX/word/fontTable.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:fonts xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"><w:font w:name="Times New Roman"><w:charset w:val="00"/><w:family w:val="roman"/><w:pitch w:val="variable"/></w:font><w:font w:name="Symbol"><w:charset w:val="02"/><w:family w:val="roman"/><w:pitch w:val="variable"/></w:font><w:font w:name="Arial"><w:charset w:val="00"/><w:family w:val="swiss"/><w:pitch w:val="variable"/></w:font><w:font w:name="Liberation Serif"><w:altName w:val="Times New Roman"/><w:charset w:val="01"/><w:family w:val="roman"/><w:pitch w:val="variable"/></w:font><w:font w:name="Liberation Serif"><w:altName w:val="Times New Roman"/><w:charset w:val="01"/><w:family w:val="swiss"/><w:pitch w:val="variable"/></w:font><w:font w:name="Barlow Condensed"><w:altName w:val="sans-serif"/><w:charset w:val="01"/><w:family w:val="roman"/><w:pitch w:val="variable"/></w:font><w:font w:name="Liberation Sans"><w:altName w:val="Arial"/><w:charset w:val="01"/><w:family w:val="roman"/><w:pitch w:val="variable"/></w:font><w:font w:name="Liberation Mono"><w:altName w:val="Courier New"/><w:charset w:val="01"/><w:family w:val="roman"/><w:pitch w:val="variable"/></w:font><w:font w:name="Bitstream Vera Sans Mono"><w:charset w:val="01"/><w:family w:val="roman"/><w:pitch w:val="variable"/></w:font><w:font w:name="Anonymous Pro"><w:altName w:val="monospace"/><w:charset w:val="01"/><w:family w:val="roman"/><w:pitch w:val="variable"/></w:font></w:fonts>
... hier wurden einige Schriften aufgelistet (die ersten paar Einträge sind jeweils farbig hervorgehoben), die im Dokument verwendet werden. Auch das sind kaum brauchbare Informationen außer man würde ein Dokument mit noch größerer Wahrscheinlichkeit zuordnen wollen. Bei einem forensischen Bericht würde ich persönlich auch diese Dinge stärker in den Vordergrund rücken da mit jedem weiteren Deteil eine zweite Datei die zufällig die gleichen Zeitstempel, Wort-, Absatz- und Seitenanzahl besitzt und dazu noch die gleichen Schriften verwendet und auf dem gleichen Betriebssystem und mit der gleichen Programmversion erstellt wurde ist schon sehr Unwahrscheinlich vor allem wenn man sich die Schriften ansieht, die nicht auf jedem System zur Grundausstattung gehören (türkis) und meist erst nachinstalliert werden müssen.
user@caine ~$ cat first_artikel_ZFX/word/_rels/document.xml.rels
<?xml version="1.0" encoding="UTF-8"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"><Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/styles" Target="styles.xml"/><Relationship Id="rId2" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="media/image1.gif"/><Relationship Id="rId3" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="_blank" TargetMode="External"/><Relationship Id="rId4" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Leerzeichen" TargetMode="External"/><Relationship Id="rId5" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/NBSP" TargetMode="External"/><Relationship Id="rId6" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Bedingter_Trennstrich" TargetMode="External"/><Relationship Id="rId7" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://en.wikipedia.org/wiki/ISO/IEC_8859-3" TargetMode="External"/><Relationship Id="rId8" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="media/image2.gif"/><Relationship Id="rId9" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="_blank" TargetMode="External"/><Relationship Id="rId10" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Leerzeichen" TargetMode="External"/><Relationship Id="rId11" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/NBSP" TargetMode="External"/><Relationship Id="rId12" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Bedingter_Trennstrich" TargetMode="External"/><Relationship Id="rId13" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://en.wikipedia.org/wiki/ISO/IEC_8859-3" TargetMode="External"/><Relationship Id="rId14" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="media/image3.gif"/><Relationship Id="rId15" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="_blank" TargetMode="External"/><Relationship Id="rId16" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Leerzeichen" TargetMode="External"/><Relationship Id="rId17" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/NBSP" TargetMode="External"/><Relationship Id="rId18" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Bedingter_Trennstrich" TargetMode="External"/><Relationship Id="rId19" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://en.wikipedia.org/wiki/ISO/IEC_8859-3" TargetMode="External"/><Relationship Id="rId20" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="media/image4.gif"/><Relationship Id="rId21" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="_blank" TargetMode="External"/><Relationship Id="rId22" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Leerzeichen" TargetMode="External"/><Relationship Id="rId23" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/NBSP" TargetMode="External"/><Relationship Id="rId24" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Bedingter_Trennstrich" TargetMode="External"/><Relationship Id="rId25" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://en.wikipedia.org/wiki/ISO/IEC_8859-3" TargetMode="External"/><Relationship Id="rId26" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="media/image5.gif"/><Relationship Id="rId27" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="_blank" TargetMode="External"/><Relationship Id="rId28" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Leerzeichen" TargetMode="External"/><Relationship Id="rId29" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/NBSP" TargetMode="External"/><Relationship Id="rId30" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Bedingter_Trennstrich" TargetMode="External"/><Relationship Id="rId31" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://en.wikipedia.org/wiki/ISO/IEC_8859-3" TargetMode="External"/><Relationship Id="rId32" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image" Target="media/image6.gif"/><Relationship Id="rId33" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="_blank" TargetMode="External"/><Relationship Id="rId34" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Leerzeichen" TargetMode="External"/><Relationship Id="rId35" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/NBSP" TargetMode="External"/><Relationship Id="rId36" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://de.wikipedia.org/wiki/Bedingter_Trennstrich" TargetMode="External"/><Relationship Id="rId37" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="https://en.wikipedia.org/wiki/ISO/IEC_8859-3" TargetMode="External"/><Relationship Id="rId38" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/fontTable" Target="fontTable.xml"/><Relationship Id="rId39" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/settings" Target="settings.xml"/>
... Hier finden sich sowohl die Verweise auf eingefügte Dateien als auch die Ziele von eingebetteten Verlinkungen. Hierbei können Dateinamen Informationen verraten oder Deeplinks zu Seiten oder Dateien führen die andernfalls nicht auffindbar wären. So könnte ein Download-Link zB zu der PDF-Version einer Rechnung führen die anderfalls kaum auffindbar wäre oder das Vorhandensein bestimmter andernfalls nicht bekannter Unterordner auf Webseiten verraten.
Und auch hier haben wir es mit vielen "würde", "könnte" und "wenns" zu tun. Natürlich würde Pass Nr. P12387321.jpg eine gültige Passnummer verraten aber wer sollte denn ein Bild so nennen wenn Pass Lisa Müller.jpg doch für uns viel einfacher zu handhaben wäre und die Dateinamen Logo.png und Rechnung 2020-0123.pdf würden nicht wirklich viel verraten!
user@caine ~$ cat first_artikel_ZFX/word/settings.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:settings xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main"><w:zoom w:percent="100"/><w:defaultTabStop w:val="709"/><w:compat></w:compat><w:themeFontLang w:val="" w:eastAsia="" w:bidi=""/></w:settings></span>
... auch diese Datei verrät nur Einstellungen wie zB die Zoom-Stufe und enthält somit weitere Faktoren die "zufällig" übereinstimmen müssten bei einer völlig anderen Datei. Also auch wieder weitere Punkte die ein IT-Forensiker verwenden kann um den "Fingerabdruck" der Datei weitere Details hinzuzufügen. Für alles andere ist diese Datei ebenfalls nicht brauchbar!
user@caine ~$ cat first_artikel_ZFX/word/styles.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:styles xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" xmlns:w14="http://schemas.microsoft.com/office/word/2010/wordml" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" mc:Ignorable="w14"><w:docDefaults><w:rPrDefault><w:rPr><w:rFonts w:ascii="Liberation Serif" w:hAnsi="Liberation Serif" w:eastAsia="Noto Sans CJK SC" w:cs="Lohit Devanagari"/><w:kern w:val="2"/><w:szCs w:val="24"/><w:lang w:val="de-DE" w:eastAsia="zh-CN" w:bidi="hi-IN"/></w:rPr></w:rPrDefault><w:pPrDefault><w:pPr></w:pPr></w:pPrDefault></w:docDefaults><w:style w:type="paragraph" w:styleId="Normal"><w:name w:val="Normal"/><w:qFormat/><w:pPr><w:widowControl/><w:bidi w:val="0"/><w:jc w:val="left"/></w:pPr><w:rPr><w:rFonts w:ascii="Liberation Serif" w:hAnsi="Liberation Serif" w:eastAsia="Noto Sans CJK SC" w:cs="Lohit Devanagari"/><w:color w:val="auto"/><w:kern w:val="2"/><w:sz w:val="24"/><w:szCs w:val="24"/><w:lang w:val="de-DE" w:eastAsia="zh-CN" w:bidi="hi-IN"/></w:rPr></w:style><w:style w:type="paragraph" w:styleId="Berschrift1"><w:name w:val="Heading 1"/><w:basedOn w:val="Berschrift"/><w:qFormat/><w:pPr><w:spacing w:before="240" w:after="120"/><w:outlineLvl w:val="0"/></w:pPr><w:rPr><w:rFonts w:ascii="Liberation Serif" w:hAnsi="Liberation Serif" w:eastAsia="Noto Sans CJK SC" w:cs="Lohit Devanagari"/><w:b/><w:bCs/><w:sz w:val="48"/><w:szCs w:val="48"/></w:rPr></w:style><w:style w:type="paragraph" w:styleId="Berschrift2"><w:name w:val="Heading 2"/><w:basedOn w:val="Berschrift"/><w:qFormat/><w:pPr><w:spacing w:before="200" w:after="120"/><w:outlineLvl w:val="1"/></w:pPr><w:rPr><w:rFonts w:ascii="Liberation Serif" w:hAnsi="Liberation Serif" w:eastAsia="Noto Sans CJK SC" w:cs="Lohit Devanagari"/><w:b/><w:bCs/><w:sz w:val="36"/><w:szCs w:val="36"/></w:rPr></w:style><w:style w:type="character" w:styleId="Internetverknpfung"><w:name w:val="Internetverknüpfung"/><w:rPr><w:color w:val="000080"/><w:u w:val="single"/><w:lang w:val="zxx" w:eastAsia="zxx" w:bidi="zxx"/></w:rPr></w:style><w:style w:type="character" w:styleId="Betont"><w:name w:val="Betont"/><w:qFormat/><w:rPr><w:i/><w:iCs/></w:rPr></w:style><w:style w:type="character" w:styleId="ListLabel1"><w:name w:val="ListLabel 1"/><w:qFormat/><w:rPr><w:rFonts w:ascii="Barlow Condensed;sans-serif" w:hAnsi="Barlow Condensed;sans-serif"/><w:b/><w:i w:val="false"/><w:caps w:val="false"/><w:smallCaps w:val="false"/><w:strike w:val="false"/><w:dstrike w:val="false"/><w:color w:val="000000"/><w:spacing w:val="0"/><w:sz w:val="26"/><w:u w:val="none"/><w:effect w:val="none"/></w:rPr></w:style><w:style w:type="character" w:styleId="ListLabel2"><w:name w:val="ListLabel 2"/><w:qFormat/><w:rPr><w:rFonts w:ascii="Barlow Condensed;sans-serif" w:hAnsi="Barlow Condensed;sans-serif"/><w:b/><w:strike w:val="false"/><w:dstrike w:val="false"/><w:color w:val="000000"/><w:spacing w:val="0"/><w:sz w:val="26"/><w:u w:val="none"/><w:effect w:val="none"/></w:rPr></w:style><w:style w:type="paragraph" w:styleId="Berschrift"><w:name w:val="Überschrift"/><w:basedOn w:val="Normal"/><w:next w:val="Textkrper"/><w:qFormat/><w:pPr><w:keepNext w:val="true"/><w:spacing w:before="240" w:after="120"/></w:pPr><w:rPr><w:rFonts w:ascii="Liberation Sans" w:hAnsi="Liberation Sans" w:eastAsia="Noto Sans CJK SC" w:cs="Lohit Devanagari"/><w:sz w:val="28"/><w:szCs w:val="28"/></w:rPr></w:style><w:style w:type="paragraph" w:styleId="Textkrper"><w:name w:val="Body Text"/><w:basedOn w:val="Normal"/><w:pPr><w:spacing w:lineRule="auto" w:line="276" w:before="0" w:after="140"/></w:pPr><w:rPr></w:rPr></w:style><w:style w:type="paragraph" w:styleId="Liste"><w:name w:val="List"/><w:basedOn w:val="Textkrper"/><w:pPr></w:pPr><w:rPr><w:rFonts w:cs="Lohit Devanagari"/></w:rPr></w:style><w:style w:type="paragraph" w:styleId="Beschriftung"><w:name w:val="Caption"/><w:basedOn w:val="Normal"/><w:qFormat/><w:pPr><w:suppressLineNumbers/><w:spacing w:before="120" w:after="120"/></w:pPr><w:rPr><w:rFonts w:cs="Lohit Devanagari"/><w:i/><w:iCs/><w:sz w:val="24"/><w:szCs w:val="24"/></w:rPr></w:style><w:style w:type="paragraph" w:styleId="Verzeichnis"><w:name w:val="Verzeichnis"/><w:basedOn w:val="Normal"/><w:qFormat/><w:pPr><w:suppressLineNumbers/></w:pPr><w:rPr><w:rFonts w:cs="Lohit Devanagari"/></w:rPr></w:style><w:style w:type="paragraph" w:styleId="VorformatierterText"><w:name w:val="Vorformatierter Text"/><w:basedOn w:val="Normal"/><w:qFormat/><w:pPr><w:spacing w:before="0" w:after="0"/></w:pPr><w:rPr><w:rFonts w:ascii="Liberation Mono" w:hAnsi="Liberation Mono" w:eastAsia="DejaVu Sans Mono" w:cs="Liberation Mono"/><w:sz w:val="20"/><w:szCs w:val="20"/></w:rPr></w:style><w:style w:type="paragraph" w:styleId="Tabelleninhalt"><w:name w:val="Tabelleninhalt"/><w:basedOn w:val="Normal"/><w:qFormat/><w:pPr><w:suppressLineNumbers/></w:pPr><w:rPr></w:rPr></w:style><w:style w:type="paragraph" w:styleId="Tabellenberschrift"><w:name w:val="Tabellenüberschrift"/><w:basedOn w:val="Tabelleninhalt"/><w:qFormat/><w:pPr><w:suppressLineNumbers/><w:jc w:val="center"/></w:pPr><w:rPr><w:b/><w:bCs/></w:rPr></w:style></w:styles>
... reiht sich ebenfalls in die forensisch brauchbaren Daten ein denn hierin werden Absatz- und Zeichenformate definiert die dann beispielsweise konkrete Angaben über verwendete Schriften und Schriftgrößen zugewiesen werden. Auch das verfeinert den Datei-Fingerabdruck und macht es nochmals unwahrscheinlicher das eine andere Datei zufällig die gleichen Merkmale aufweist vor allem wenn sich diese Werte von den Standardwerten abweichen.
Man sieht gut wieviel Arbeit es macht sich mühsam aus diesen Fragmenten entsprechende Informationen zu extrahieren. Vieles ist relevant bzw. enthält Informationen die für sich allein genommen nicht nützlich sind. Natürlich könnte man so an den Namen der CI-Schrift einer Firma oder das Logo kommen aber das kann man auch einfacher haben indem man sich ein Angebot erstellen lässt und dann den Schriftnamen aus der PDF-Datei extrahiert oder das Logo von der Webseite herunterlädt. Vor allem aber sind die Chancen so an diese Informationen zu kommen deutlich höher als beim kauf einer ausrangierten Platte auf eBay und anschließender "Datenrekonstruktion"!
Absolute Sicherheit gibt es nicht aber ausreichende Sicherheit wird dadurch gewährleistet, dass das Umgehen der Sicherheitsmaßnahmen so langsam, aufwändig, riskant, etc. ist, dass es wirtschaftlich keinen Sinn ergibt und das ist hier meiner Meinung nach gegeben.
Das Problem mit den Fragmenten aus der Dateimitte
Den Dateifragmenten vom Dateianfang konnten wir immer zumindest ein paar Daten abringen und sei es nur der Name des Fotografen und dessen Webseite sowie die verwendete Kamera oder die verwendeten Schriften und Programme oder Link-Ziele und Dateinamen, Auflösung und Farbtiefe, Zeitangeben, etc. Wir haben gelernt, dass textbasierte Daten einfach zu lesen sind und so ihre Informationen direkt preisgeben. Darum sind hierbei auch Fragmente egal aus welchem Teil der Datei brauchbar.
Binärdaten sind dagegen einfach nur eine Ansammlung von aneinandergereihten Zahlenwerten zwischen 0 und 255 und erst das Dateiformat verwandelt diese Informationen in etwas sinnvolles. Daher sehen wir uns von folgende zwei Beispiele an:
user@caine ~$ ndisasm 512b/middle_artikel.txt
00000000 C3 ret
00000001 B66E mov dh,0x6e
00000003 6E outsb
00000004 656E gs outsb
00000006 206461 and [si+0x61],ah
00000009 7320 jnc 0x2b
0000000B 6C insb
0000000C 61 popa
0000000D 7465 jz 0x74
0000000F 696E697363 imul bp,[bp+0x69],word 0x6373
00000014 686520 push word 0x2065
00000017 41 inc cx
00000018 6C insb
00000019 7068 jo 0x83
0000001B 61 popa
0000001C 626574 bound sp,[di+0x74]
0000001F 206765 and [bx+0x65],ah
00000022 6E outsb
...
000001F9 0A4469 or al,[si+0x69]
000001FC 657365 gs jnc 0x264
000001FF 73 db 0x73
Das Programm ndisasm interpretiert eine Datei als Programm und rechnet anhand der Binärdaten in der Datei die Assembler-Anweisungen zurück. Das Problem dabei ist allerdings, dass dies wie wir hier sehen auch mit einem Teilstück einer Textdatei klappt!
user@caine ~$ ndisasm 512b/middle_exif.jpg
00000000 53 push bx
00000001 B34C mov bl,0x4c
00000003 06 push es
00000004 9D popf
00000005 9A005CD213 call 0x13d2:0x5c00
0000000A 45 inc bp
0000000B 349A xor al,0x9a
0000000D 6210 bound dx,[bx+si]
0000000F 9A858D48C6 call 0xc648:0x8d85
00000014 A26354 mov [0x5463],al
00000017 4B dec bx
00000018 226A6D and ch,[bp+si+0x6d]
0000001B 2B1A sub bx,[bp+si]
0000001D 4A dec dx
0000001E 18447A sbb [si+0x7a],al
00000021 D4C8 aam 0xc8
00000023 6A01 push byte +0x1
...
000001FD EE out dx,al
000001FE F9 stc
000001FF 4E dec si
Genau so ist dies auch mit dem 512 Byte großen Stück aus der JPG-Datei möglich. Wir können also Daten auf binärer Ebene als alles Mögliche interpretieren. Danach müssen wir versuchen die Ergebnisse zu verifizieren und entscheiden ob diese möglich und richtig sind. Ich habe für dieses Beispiel bewusst einen Disassembler gewählt - man müsste den Code betrachten und dann abschätzen ob dies Teil eines Programmes sein könnte wobei auch oft zur Tarnung von Schadware sinnloser Code eingeführt wird um eine Erkennung durch Antivierensoftware und ein eventuelles Reverse-Engeneering zu erschweren. Außerdem muss ein Kommando nicht genau an der Sektorgrenze beginnen und so müsste man versuchen ob der Assembler-Code mehr Sinn ergibt wenn man diesen ab dem 2. oder 3. oder 4. Zeichen disassembliert.
Dieses Fragment beginnt mit 53 B3 4C 06. Dies entspricht den Assembler-Befehlen push bx, mov bl,0x4c und push es. Würden wir die ersten 2 Bytes auslassen dann erhalten wir für 4C 06 folgenden Assembler-Code:
user@caine ~$ ndisasm 512b/middle_exif.jpg
00000000 4C dec esp
00000001 06 push es
...
Je nach Beispiel kann sich ein solcher Versatz einige Zeilen betreffen und nicht nur wie hier eine einzige. Sie sehen, dass Assembler-Anweisungen ein Zeichen oder mehrere Zeichen lang sein können. Dies gilt auch für alle möglichen Werte in anderen binären Dateiformaten. Genau das verkompliziert weitere Tests denn bevor man überhaupt ein Dateiformat anwenden kann muss man sich auch gedanken machen wo denn ein Einstiegspunkt sein könnte und ob Felder in den Binärdaten eventuell abgeschnitten und damit unvollständig sind.
Dieser Code sieht schon relativ "wild" aus und wird eher nicht zu einem Programm gehören aber dennoch müsste man sich das im Detail ansehen. Genau das gleiche erwartet uns bei allen anderen Datentypen. Wenn wir zB die ersten 32 KB der TXT-Datei in unser Bitmap-Bild einfügen sehen wir:
Hier werden Sie mit höchster Wahrscheinlichkeit kein sinnvolles Bildergebnis herausbekommen egal wie Sie an den Werten für Breite, Höhe und Bittiefe auch drehen. Sollten Sie dank der COVID-19 Lockdowns nichts besseres vor haben, dann können Sie gerne ein paar Tage lang alle möglichen Bilder generieren und prüfen. Eventuell verstecken sich ja doch geheime Botschaften in meinen Artikeln...
Was uns hier nun relativ schnell klar werden sollte ist, dass wir hier viele Möglichkeiten haben die es auszuprobieren gilt. Dies ist nicht nur zeitaufwendig sondern führt auch nicht zwangsläufig zum Erfolg denn es kann sich immer noch um ein exotisches Dateiformat einer Eigenentwicklung handeln oder das Datenfragment enthält verschiedenste Datenreste unterschiedlicher Dateien. Dies kann dadurch entstehen, dass eine Datei über den Speicherplatz einer nicht sicher gelöschten Datei geschrieben wird und diesen nicht vollständig ausfüllt. In diesem sogenannten Slack-Space bleibt dann ein Fragment der alten Datei erhalten die sich dann mit dem Ende der neuen Datei mischt. Da wir die Informationen wie zB Dateilänge oder Dateityp nicht haben können wir auch nicht wissen wieviel Byte gelesen werden müssen (zB BMP) oder bis zu welchem Marker (zB JPG). Somit kann ein solches Fragment auch nicht immer als ganzes zu betrachten sein was die Komplexität der Aufgabe nochmals erhöht.
Fazit
Wenn Sie nun befürchten, dass Ihre Enkel in 30-40 Jahren die "oben ohne" Selfies von ihrer Oma oder die Sch****fotos von ihrem Opa wiederherstellen können dann wipen Sie lieber dreimal. Sollte sich die Angst auch auf die Urenkel erstrecken dann sollten Sie eventuell sogar über das VSITR-Verfahren mit 7-fachem überschrieben nachdenken.
Wenn Sie wirklich zu 100% sicher sein wollen, dass nicht mal die NSA an Ihre Daten kommen kann dann würde ich vorschlagen, dass Sie die Magnetscheiben ausbauen auf die Curie-Temperatur erhitzen damit diese die magnetischen Eigenschaften verlieren. Dann müssen Sie diese zur Sicherheit noch fein säuberlich abschleifen und den Schleifstaub in Säure auflösen. Sie können dann auch noch beim Space-X Projekt anfragen was die verlangen wenn Sie bei der nächsten Mission unterwegs ein Fläschchen Säure ins All schließen... Wobei - in einer weit entfernten Galaxie könnte es eine weiter entwickelte Zivilisation geben die auch dann noch die Daten retten könnten! Und sollen diese Fotos dann wirklich das allererste sein was diese Wesen von unserer Zivilisation zu sehen bekommen?!
Apropos NSA - natürlich wäre es durchaus denkbar, dass diese oder ähnliche Organisationen bereits derartige Techniken einsetzen und zB mit Elektronenmikroskopen Daten wiederherstellen die sonst nicht wiederherzustellen wären. Aber auch diese Organisationen haben keine hunderttausenden solcher Geräte mit Millionen an IT-Experten im Einsatz die im 24/7 Schichtbetrieb Fragmente von geschredderten oder zerlegten Platten nach Daten abtasten die Agenten von Schrottplätzen besorgen oder auf eBay zukaufen denn wie wir bereits alles wissen war es deutlich einfacher und viel schneller und billiger mit Sicherheitslücken in Systeme einzudringen und so an die Daten zu kommen bevor diese gelöscht werden. Darüber ob dies weiterhin mit neuen Lücken oder bewusst eingefügten Hintertüren geschieht kann man nur spekulieren.
Sollte es also tatsächlich diese Technologie bereits geben dann wird diese aus Zeit- und Kostengründen sowie aufgrund der beschränkten Ressourcen sicher nur dann angewendet wenn es keine andere Alternative gibt und ein entsprechender Fall dies auch rechtfertigt. Der Aufwand um ein akzeptables Niveau an Sicherheit zu erhalten hält also doch in Grenzen und selbst wenn die vorgegebenen Standards des BSI mit 3-fachen bzw. 7-fachen Überschreiben (bei Platten bis 80GB) meiner Meinung nach schon zu paranoid sind, sollte man sich dennoch an diese Halten vor allem im Hinblick auf die Rechtssicherheit! Wer diese befolgt braucht sich also nicht nur in rechtlicher sondern auch in technischer Hinsicht keinerlei sorgen zu machen.
Es läuft also darauf hinaus, dass eines unserer 63.408 "Lottarielose" (ausgemappte Sektoren) genau den Dateianfang einer Datei treffen muss und das bei einer Gesamtanzahl von über 976 Millionen Sektoren von denen zB 114 Sektoren die 57 KB große Word-Datei unseres Beispiels beinhalten. Wir können das also mit "Schiffchen versenken" auf einem über 976 Millionen Felder großen Spielfeld vergleichen und müssen zB ein 114 Spielfelder große Schiff nicht nur irgendwo treffen sondern genau am Anfang und dazu haben wir etwas über 63.000 Versuche. Hierbei kann man die Anzahl der Dateien die vertraulich wären mit der Anzahl der Schiffe gleichsetzen. Und dann kann man eventuell Informationsfetzen unter großem Aufwand rekonstruieren die je nach Dateityp nichts, belanglose oder auch brauchbare Informationen preisgeben. Fast jeder mittige Treffer lässt den Arbeitsaufwand um ein vielfaches ansteigen und wird dann zu einem Ratespielchen bei den meisten gängigen Dateitypen. Bei den heutigen Dateigrößen kann man aus Sektoren oder kleinen Fragmenten auch kaum Informationen gewinnen. Sehen wir uns dazu gängige Dateien an:
Ein Foto meiner Digitalcameras mit 12 bzw. 24Mpix hat 5 - 12 bzw. 8-19 MB also umgerechnet ca. 6.000 bis 20.000 KB entspricht. Hier würde selbst das 32 KB Fragment nur 0,53 - 0,16% des Bildes enthalten. Unter der Annahme, dass wir dies also rekonstruieren könnten würde diese sehr geringe Fläche kaum etwas enthüllen. Genau das sehen wir ja auch schon bei den Bespiel-Bildern die bewusst auf eine typischere Größe für das Web heruntergerechnet wurden. Selbst Handy-Kameras haben heute derart große Auflösungen, dass in kleinen Fragmenten nur kleine Ausschnitte zu sehen sein werden und die Datenfragmente vom Dateianfang, die man am ehesten rekonstruieren kann, zeigen dann auch nur einen kleinen Streifen von Bildrand! Die realste Gefahr sind hierbei kleine Vorschau-Bilder die man mit Glück noch wiederherstellen kann. Also betrachten wir nochmal den schlimmsten Fall in dem diese Platte voll mit Fotos wäre.
500 GB Speicherplatz bzw. ca. 500.000 MB : 9 - 14 MB pro Foto = 55.555 - 35.714 Fotos die auf eine solche Platte passen würden. Nehmen wir wiederum den Worst-Case von 55.555 Fotos dann erhalten wir unser Spielfeld mit über 976 Millionen Feldern auf denen 55.555 Ziele darauf warten mit etwas über 63.000 Versuchen getroffen zu werden. Diese 55.555 ersten Sektoren entsprechen 0.0057% der Gesamtfläche und sind damit auch ein sehr kleines Ziel. Sie können sich die Chance auf einen Treffer an dieser Stelle gern selbst ausrechnen.
