Das dritte Praktikum beschäftigt sich mit der weiterführenden Analyse des sichergestellten Festplattenabbildes. In diesem Kontext werden auch gelöschte Dateien aus nicht-allozierten Bereichen wiederhgerstellt.
| Skript-Anfang | Praktikum 3 – Seite 1 |
|---|---|
| Skript-Ende | Praktikum 3 – Seite 1 |
Datenträgeranalyse
Analyse der Partitionen
Vergewissern Sie sich, dass keine Veränderungen am Image der zweiten Partition durchgeführt wurden.
Wir berechnen den Hashwert des Images und vergleichen diesen rückblickend mit den Ergebnissen aus dem zweiten Praktikum.
# sha256sum partition_2.dd
af1b66fdf5ae27c07da0fb9915c4d7f6f6be2941484136698e73fa75cc6aab86 partition_2.ddWelches Dateisystem befindet sich auf partition_2.dd?
Da sich an dem Hashwert nichts geändert hat und wir somit noch auf dem gleichen Image arbeiten, handelt es sich um eine FAT16-Partition. Der Vollständigkeit halber lassen wir uns diese Information nochmals durch fsstat zeigen.
# fsstat partition_2.dd
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: FAT16
OEM Name: mkdosfs
Volume ID: 0x3ccb36b8
Volume Label (Boot Sector):
Volume Label (Root Directory):
File System Type Label: FAT16
...Kopieren Sie den Bootsektor von partition_2.dd nach partition_2_boot.dd und berechnen Sie dessen Hashsumme.
Da der Bootsektor von Partition 2 nur einen HDD-Block groß ist, setzen wir die Parameter count=1 und bs=512.
# dd if=partition_2.dd of=partition_2_boot.dd count=1 bs=512\n1+0 records in\n1+0 records out\n512 bytes (512 B) copied, 3.9738e-05 s, 12.9 MB/s
# sha256sum partition_2_boot.dd \n5ab9eb35a368441b3c3a16da8945fe58a99cd224b7061382a92fa608bdec3732 partition_2_boot.ddFAT-Analyse
Ermitteln Sie nur unter Zuhilfenahme eines Hexdump-Viewers aus dem Bootsektor die Größe der Reserverd Area, die Anzahl und Größe der FATs.
Zunächst extrahieren wir die Informationen aus dem Bootsektor mittels xxd.
# xxd partition_2_boot.dd \n0000000: eb3c 906d 6b64 6f73 6673 0000 0204 0100 .<.mkdosfs......\n0000010: 0200 0200 a0f8 2800 2000 4000 0000 0000 ......(. .@.....\n0000020: 0000 0000 0000 29b8 36cb 3c20 2020 2020 ......).6.< \n0000030: 2020 2020 2020 4641 5431 3620 2020 0e1f FAT16 ..\n0000040: be5b 7cac 22c0 740b 56b4 0ebb 0700 cd10 .[|.".t.V.......\n0000050: 5eeb f032 e4cd 16cd 19eb fe54 6869 7320 ^..2.......This \n0000060: 6973 206e 6f74 2061 2062 6f6f 7461 626c is not a bootabl\n0000070: 6520 6469 736b 2e20 2050 6c65 6173 6520 e disk. Please \n0000080: 696e 7365 7274 2061 2062 6f6f 7461 626c insert a bootabl\n0000090: 6520 666c 6f70 7079 2061 6e64 0d0a 7072 e floppy and..pr\n00000a0: 6573 7320 616e 7920 6b65 7920 746f 2074 ess any key to t\n00000b0: 7279 2061 6761 696e 202e 2e2e 200d 0a00 ry again ... ...\n00000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n0000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n0000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n0000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n0000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n0000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n0000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n0000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n0000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n0000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n0000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00001b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.Die folgende Tabelle zeigt die Struktur einer FAT-Partition und wie die Informationen zu interpretieren sind.
| Bytes | Länge in Byte | Inhalt |
|---|---|---|
| 0x000 | 3 | Jump instruction |
| 0x003 | 8 | OEM Name |
| 0x00B | 2 | Bytes per logical sector in powers of two (512) |
| 0x00D | 1 | Logical sectors per cluster (1, 2, 4, 8, 16, 32, 64, and 128) |
| 0x00E | 2 | Count of reserved logical sectors |
| 0x010 | 1 | Number of File Allocation Tables |
| 0x011 | 2 | Number of root directory entries (224) 0 for FAT32. 512 is recommended for FAT16. |
| 0x013 | 2 | Total logical sectors |
| 0x015 | 1 | Media descriptor |
| 0x016 | 2 | Logical sectors per File Allocation Table |
| 0x018 | 2 | Physical sectors per track for disks |
| 0x01A | 2 | Number of heads for disks |
| 0x01C | 4 | Count of hidden sectors preceding the partition that contains this FAT volume |
Wir übertragen die Ausgabe von xxd in dieses Schema, um die gesuchten Werte zu ermitteln.
| Wert | Hexdump-Ausgabe | Wert |
|---|---|---|
| Größe der Reserved Area | 01 00 | 0x0001 = 1 Block |
| Anzahl der FATs | 02 | 0x02 = 2 Stück |
| Größe der FATs | 28 00 | 0x0028 = 40 HDD-Blöcke |
Welche HDD-Blöcke werden von der FAT belegt?
- HDD-Block 0 wird von der Reserved Area belegt
- Folglich belegt FAT0 die HDD-Blöcke 1 bis 40
- Die FAT1 belegt die HDD-Blöcke 41-80
- Somit werden von der FAT die HDD-Blöcke 1 bis 80 belegt
Bestimmen Sie nur unter Zuhilfenahme eines Hexdump-Viewers, welche HDD-Blöcke von Cluster 2 und 178 belegt werden.
Um den Offset und die Größe der Cluster zu bestimmen, verwenden wir die folgenden Angaben.
Komponenten der Formel
\( \ \text{Teil 1} = \text{Groesse d. Reserved Area } + \text{ FAT-Groesse }* \text{ FAT-Anzahl } \ \text{Teil 2} = \frac{\text{ Max. Eintraege im Root Directory} * \text{ Byte pro Eintrag}}{\text{HDD-Blockgroesse}} \ \text{Teil 3} = (n – 2) * \text{HDD-Bloecke pro Cluster} \)
Start von Cluster n = Teil 1 + Teil 2 + Teil 3
Variablen
- Größe der Reserved Area (Offset 14−15): 01 00 = 00 01 = 1 HDD-Block
- Größe einer FAT (Offset 22−23): 28 00 = 0x0028 = 40 HDD-Blöcke
- Anzahl der FATs (Offset 16): 02 = 0x02 = 2 Stück
- Verzeichniseinträge im Root Directory (Offset 17-18): 00 02 = 0x0200 = 512 Stück
- Ein Eintrag im Root Directory ist immer 32 Byte groß
- Größe eines HDD-Blocks in Bytes (Offset 11−12): 00 02 = 0x0200 = 512 Byte
- Größe eines Clusters (Offset 13): 04 = 0x04 = 4 HDD-Blöcke pro Cluster
Setzt man die Variablen in die Formeln ein und addiert diese, unter Berücksichtigung, dass ein Cluster immer 4 HDD-Blöcke groß ist, so ergeben sich folgende Resultate.
Ergebnis
- Cluster 2: 113 + (0)*4 = 113-116
- Cluster 178: 113 + (176)*4 = 817-820
Ist Cluster 25 alloziert? Welche Informationen können Sie aus dem Eintrag gewinnen?
Zunächst extrahieren wir die Informationen aus der FAT0 mittels blkcat.
# blkcat partition_2.dd 1 | xxd | less
\n0000000: f8ff ffff 9815 0400 0500 0600 0700 0800 ................\n0000010: 0900 0a00 0b00 0c00 0d00 0e00 0f00 1000 ................\n0000020: 1100 1200 1300 1400 1500 1600 1700 1800 ................\n0000030: 1900 1a00 1b00 1c00 1d00 1e00 1f00 2000 .............. .\n0000040: 2100 2200 2300 2400 2500 2600 2700 2800 !.".#.$.%.&.'.(.\n0000050: 2900 2a00 2b00 2c00 2d00 2e00 2f00 3000 ).*.+.,.-.../.0.
...Wir wissen, dass jeder FAT-Eintrag 16 Bit bzw. 2 Byte groß ist. Somit handelt es sich bei Cluster 25 um 1a00. Seine Information zeigt auf das nächste Cluster, was bedeutet, dass er alloziert ist. Wir überprüfen dies nochmals mit istat.
# istat partition_2.dd 25 | head
Directory Entry: 25
Allocated
File Attributes: Long File Name
Size: 0
Name: pm090930_geis
Directory Entry Times:
Written: 0000-00-00 00:00:00 (UTC)
Accessed: 0000-00-00 00:00:00 (UTC)
Created: 0000-00-00 00:00:00 (UTC)Was bedeutet der Wert 0xFFF7 als Clusterbelegung?
- Cluster unbelegt: 0x0000
- Cluster beschädigt: 0xfff7
- End-of-File-Label: 0xfff8 bis 0xffff
Geben Sie hexadezimal an, in welchem Speicherbereich (in Bytes) der Hexdump des Verzeichniseintrags (’Inode’) 6 im Image zu finden ist, wenn die Nummerierung der Verzeichniseinträge gemäß dem Vorschlag des Sleuthkits gewählt wurde.
Zunächst extrahieren wir alle Verzeichniseinträge mittels hexdump und Gruppieren diese entsprechend ihrer Inodes.
# hexdump -C partition_2.dd | less\n0000a200 43 66 00 00 00 ff ff ff ff ff ff 0f 00 71 ff ff |Cf...........q..| // Inode 3\n0000a210 ff ff ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
\n0000a220 02 63 00 2d 00 62 00 73 00 69 00 0f 00 71 2d 00 |.c.-.b.s.i...q-.| // Inode 4\n0000a230 32 00 30 00 30 00 35 00 2e 00 00 00 70 00 64 00 |2.0.0.5.....p.d.|
\n0000a240 01 73 00 74 00 75 00 64 00 69 00 0f 00 71 65 00 |.s.t.u.d.i...qe.| // Inode 5\n0000a250 2d 00 76 00 6f 00 69 00 70 00 00 00 73 00 65 00 |-.v.o.i.p...s.e.|
\n0000a260 53 54 55 44 49 45 7e 31 50 44 46 20 00 64 5b 50 |STUDIE~1PDF .d[P| // Inode 6\n0000a270 9d 3b 9d 3b 00 00 5b 50 9d 3b 03 00 4d a3 ac 00 |.;.;..[P.;..M...|
\n0000a280 e5 6f 00 74 00 2e 00 6a 00 70 00 0f 00 9c 67 00 |.o.t...j.p....g.| // Inode 7\n0000a290 00 00 ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
\n0000a2a0 e5 7a 00 65 00 69 00 63 00 68 00 0f 00 9c 6e 00 |.z.e.i.c.h....n.| // Inode 8\n0000a2b0 75 00 6e 00 67 00 2d 00 64 00 00 00 65 00 70 00 |u.n.g.-.d...e.p.|
\n0000a2c0 e5 45 49 43 48 4e 7e 31 4a 50 47 20 00 00 07 6c |.EICHN~1JPG ...l| // Inode 9\n0000a2d0 9d 3b 9d 3b 00 00 07 6c 9d 3b 75 18 d0 db 00 00 |.;.;...l.;u.....|
\n0000a2e0 e5 7a 00 7a 00 7a 00 7a 00 7a 00 0f 00 44 7a 00 |.z.z.z.z.z...Dz.| // Inode 10\n0000a2f0 00 00 ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
\n0000a300 e5 7a 00 7a 00 7a 00 7a 00 7a 00 0f 00 44 7a 00 |.z.z.z.z.z...Dz.| // Inode 11\n0000a310 7a 00 7a 00 7a 00 7a 00 7a 00 00 00 7a 00 7a 00 |z.z.z.z.z...z.z.|
\n0000a320 e5 5a 5a 5a 5a 5a 7e 31 20 20 20 20 00 00 ed 50 |.ZZZZZ~1 ...P| // Inode 12\n0000a330 9d 3b 81 44 00 00 ed 50 9d 3b 00 00 00 00 00 00 |.;.D...P.;......|
\n0000a340 e5 59 4d 41 4e 54 7e 31 50 53 20 20 00 64 6a 50 |.YMANT~1PS .djP| // Inode 13\n0000a350 9d 3b 9d 3b 00 00 6a 50 9d 3b da 16 aa 7b 12 00 |.;.;..jP.;...{..|
\n0000a360 41 74 00 72 00 6f 00 6a 00 61 00 0f 00 78 6e 00 |At.r.o.j.a...xn.| // Inode 14\n0000a370 65 00 72 00 2e 00 70 00 6e 00 00 00 67 00 00 00 |e.r...p.n...g...|
\n0000a380 54 52 4f 4a 41 4e 45 52 50 4e 47 20 00 00 73 50 |TROJANERPNG ..sP| // Inode 15\n0000a390 9d 3b 81 44 00 00 73 50 9d 3b 2a 19 dd 62 1d 00 |.;.D..sP.;*..b..|
\n0000a3a0 43 7a 00 74 00 61 00 67 00 2e 00 0f 00 b7 70 00 |Cz.t.a.g......p.| // Inode 16\n0000a3b0 64 00 66 00 00 00 ff ff ff ff 00 00 ff ff ff ff |d.f.............|
\n0000a3c0 02 49 00 44 00 5f 00 47 00 72 00 0f 00 b7 75 00 |.I.D._.G.r....u.| // Inode 17\n0000a3d0 6e 00 64 00 73 00 63 00 68 00 00 00 75 00 74 00 |n.d.s.c.h...u.t.|
\n0000a3e0 01 32 00 30 00 30 00 39 00 2d 00 0f 00 b7 30 00 |.2.0.0.9.-....0.| // Inode 18\n0000a3f0 32 00 2d 00 31 00 32 00 5f 00 00 00 52 00 46 00 |2.-.1.2._...R.F.|
\n0000a400 32 30 30 39 2d 30 7e 31 50 44 46 20 00 64 a5 50 |2009-0~1PDF .d.P| // Inode 19\n0000a410 9d 3b 9d 3b 00 00 a5 50 9d 3b 23 27 50 fd 1c 00 |.;.;...P.;#'P...|
\n0000a420 42 69 00 63 00 68 00 74 00 2d 00 0f 00 8f 32 00 |Bi.c.h.t.-....2.| // Inode 20\n0000a430 30 00 30 00 37 00 2e 00 70 00 00 00 64 00 66 00 |0.0.7...p...d.f.|
\n0000a440 01 42 00 4b 00 41 00 2d 00 4a 00 0f 00 8f 61 00 |.B.K.A.-.J....a.| // Inode 21\n0000a450 68 00 72 00 65 00 73 00 62 00 00 00 65 00 72 00 |h.r.e.s.b...e.r.|
\n0000a460 42 4b 41 2d 4a 41 7e 31 50 44 46 20 00 00 db 50 |BKA-JA~1PDF ...P| // Inode 22\n0000a470 9d 3b 81 44 00 00 db 50 9d 3b d7 1c 23 1c 17 00 |.;.D...P.;..#...|
\n0000a480 24 52 45 43 59 43 4c 45 42 49 4e 16 00 0d d9 01 |$RECYCLEBIN.....| // Inode 23\n0000a490 81 44 81 44 00 00 da 01 81 44 75 18 00 00 00 00 |.D.D.....Du.....|
\n0000a4a0 42 74 00 65 00 72 00 77 00 61 00 0f 00 31 6c 00 |Bt.e.r.w.a...1l.| // Inode 24\n0000a4b0 64 00 2e 00 70 00 64 00 66 00 00 00 00 00 ff ff |d...p.d.f.......|
\n0000a4c0 01 70 00 6d 00 30 00 39 00 30 00 0f 00 31 39 00 |.p.m.0.9.0...19.| // Inode 25\n0000a4d0 33 00 30 00 5f 00 67 00 65 00 00 00 69 00 73 00 |3.0._.g.e...i.s.|
\n0000a4e0 50 4d 30 39 30 39 7e 31 50 44 46 20 00 a4 ec 01 |PM0909~1PDF ....| // Inode 26\n0000a4f0 81 44 81 44 00 00 75 55 7f 44 77 18 62 83 00 00 |.D.D..uU.Dw.b...|
\n0000a500 e5 4c 2d 41 20 20 20 20 4a 50 47 20 18 89 ed 01 |.L-A JPG ....| // Inode 27\n0000a510 81 44 81 44 00 00 42 55 7f 44 88 18 28 2c 00 00 |.D.D..BU.D..(,..|Der Eintrag für Inode 6 belegt den Speicherbereich 0xA260 bis 0xA27F. Die erste Cluster-Adresse ist 03 00 bzw. Cluster 3. Verwenden wir die Formel aus der vorherigen Teilaufgabe und bestimmten den Offset des HDD-Blocks, so ergibt sich 117. Diesen Wert können wir in ifind eintragen, um zu verifizieren, dass es sich um Inode 6 handelt.
# ifind -f fat -d 117 partition_2.dd\n6Schauen wir uns Inode 6 mit istat an, erhalten wir bereits einige Informationen über die Sektoren und Attribute der dahinterliegenden Datei.
# istat partition_2.dd 6
Directory Entry: 6
Allocated
File Attributes: File, Archive
Size: 11313997
Name: STUDIE~1.PDF
Directory Entry Times:
Written: 2009-12-29 10:02:54 (EST)
Accessed: 2009-12-29 00:00:00 (EST)
Created: 2009-12-29 10:02:54 (EST)
Sectors:\n117 118 119 120 121 122 123 124
...Um welche Art von Verzeichniseintrag handelt es sich?
An Byte 11 liegen die Attributinformationen, hier 0x20. Intepretiert man dies als binärzahl, lässt sich das Archive-Flag 0010 0000 identifizieren.
Archive. (Since DOS 2.0) Typically set by the operating system as soon as the file is created or modified to mark the file as „dirty“, and reset by backup software once the file has been backed up to indicate „pure“ state.http://en.wikipedia.org/wiki/Design_of_the_FAT_file_system
Bestimmen Sie die Größe des im Verzeichniseintrag referenzierten Objekts anhand der Informationen des Verzeichniseintrages
Die letzten 4 Bytes (28-31) repräsentieren die Dateigröße in Bytes, hier 4d a3 ac 00 bzw. 0x00aca34d. Dies entspricht einer Dateigröße von 11.313.997 Byte. Bei Verzeichnisses ist der Wert Null.
Beantworten Sie die gleichen Fragen fur den Verzeichniseintrag 23.
- Der Speicherbereich von Inode 23 liegt an A480 bis A49F
- Es handelt sich um ein Hidden File (0000 0010), System File (0000 0100) und Verzeichnis (0001 0000)
- Seine Dateigröße beträgt, trotz der vier allozierten Sektoren, 0 Byte, da es ein Verzeichnis ist
- Der Name des Verzeichnisses lautet Name
$RECYCLE.BIN
Dateiwiederherstellung
Geben Sie den Namen aller fragmentierten, allozierten Dateien sowie deren belegte HDD-Blöcke in der richtigen Reihenfolge an.
Mittels fsstat können wir uns die Fragmentierung der allozierten Dateien ansehen.
# fsstat partition_2.dd
...
FAT CONTENTS (in sectors)
--------------------------------------------\n113-116 (4) -> 22217\n117-22216 (22100) -> EOF\n22217-25148 (2932) -> EOF\n25149-25152 (4) -> EOF\n25153-25156 (4) -> EOF\n25157-25224 (68) -> EOF\n25225-25248 (24) -> EOF\n25249-25252 (4) -> EOF\n25873-29636 (3764) -> EOF\n29637-32596 (2960) -> EOF\n40181-40956 (776) -> 113Offensichtlich gibt es eine Datei, die mit 40181 beginnt, dann später an 113 fortgesetzt wird und zuletzt an 22217 fortgeführt wird, bis zum EOF. Alle anderen Dateien enden direkt und sind somit nicht fragmentiert. Mittels ifind finden wir die Inode der dazugehörigen Datei heraus.
# ifind -f fat -d 113 partition_2.dd\n19Weitere Informationen zu dieser Datei rufen wir über istat der Vollständigkeit halber ab.
# istat partition_2.dd 19
Directory Entry: 19
Allocated
File Attributes: File, Archive
Size: 1899856
Name: 2009-0~1.PDF
Directory Entry Times:
Written: 2009-12-29 10:05:10 (CET)
Accessed: 2009-12-29 00:00:00 (CET)
Created: 2009-12-29 10:05:10 (CET)
Sectors:\n40181 40182 40183 40184 40185 40186 40187 40188
...\n40949 40950 40951 40952 40953 40954 40955 40956\n113 114 115 116\n22217 22218 22219 22220 22221 22222 22223 22224
...\n25141 25142 25143 25144 25145 25146 25147 0Speichern Sie die Datei mittels dd oder blkcat lokal ab.
Wir fügen die fragmentierten Bereich schrittweise zusammen mit blkcat.
# blkcat partition_2.dd 40181 776 >> file.pdf
# blkcat partition_2.dd 113 4 >> file.pdf
# blkcat partition_2.dd 22217 2932 >> file.pdfAlternativ könnte man es auch komfortabel mit icat unter Angabe der Inode machen.
# icat -r partition_2.dd 19 > file.pdfIn beiden Fällen wird das folgende Dokument erzeugt.
Finden Sie alle gelöschten Dateien auf der Partition.
Wir könnten an dieser Stelle das Wurzelverzeichnis nach allen Einträgen durchsuchen, die mit 0x35 beginnen. Dies steht für eine gelöschte Datei.
0000a280 e5 6f 00 74 00 2e 00 6a 00 70 00 0f 00 9c 67 00 |.o.t...j.p....g.|\n0000a290 00 00 ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
\n0000a2a0 e5 7a 00 65 00 69 00 63 00 68 00 0f 00 9c 6e 00 |.z.e.i.c.h....n.|\n0000a2b0 75 00 6e 00 67 00 2d 00 64 00 00 00 65 00 70 00 |u.n.g.-.d...e.p.|
\n0000a2c0 e5 45 49 43 48 4e 7e 31 4a 50 47 20 00 00 07 6c |.EICHN~1JPG ...l|\n0000a2d0 9d 3b 9d 3b 00 00 07 6c 9d 3b 75 18 d0 db 00 00 |.;.;...l.;u.....|
\n0000a2e0 e5 7a 00 7a 00 7a 00 7a 00 7a 00 0f 00 44 7a 00 |.z.z.z.z.z...Dz.|\n0000a2f0 00 00 ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
\n0000a300 e5 7a 00 7a 00 7a 00 7a 00 7a 00 0f 00 44 7a 00 |.z.z.z.z.z...Dz.|\n0000a310 7a 00 7a 00 7a 00 7a 00 7a 00 00 00 7a 00 7a 00 |z.z.z.z.z...z.z.|
\n0000a320 e5 5a 5a 5a 5a 5a 7e 31 20 20 20 20 00 00 ed 50 |.ZZZZZ~1 ...P|\n0000a330 9d 3b 81 44 00 00 ed 50 9d 3b 00 00 00 00 00 00 |.;.D...P.;......|
\n0000a340 e5 59 4d 41 4e 54 7e 31 50 53 20 20 00 64 6a 50 |.YMANT~1PS .djP|\n0000a350 9d 3b 9d 3b 00 00 6a 50 9d 3b da 16 aa 7b 12 00 |.;.;..jP.;...{..|
\n0000a500 e5 4c 2d 41 20 20 20 20 4a 50 47 20 18 89 ed 01 |.L-A JPG ....|\n0000a510 81 44 81 44 00 00 42 55 7f 44 88 18 28 2c 00 00 |.D.D..BU.D..(,..|Dies ist jedoch zu aufwendig und skaliert schlecht mit großen Datenmengen. Stattdessen verwenden wir fls, um uns die gelöschten Dateien anzuzeigen.
# fls -d partition_2.dd
r/r * 9: zeichnung-depot.jpg
r/r * 12: zzzzzzzzzzzzzzzzzzz
r/r * 13: _YMANT~1.PS
r/r * 27: _l-a.jpgDa wir vorhin in Inode 23 den Papierkorb gefunden haben und diese Dateien im Wurzelverzeichnis liegen, schauen wir uns noch an, welche Dateien denn generell auf dieser Partition noch zu finden sind.
# fls -r partition_2.dd
r/r 6: studie-voipsec-bsi-2005.pdf
r/r * 9: zeichnung-depot.jpg
r/r * 12: zzzzzzzzzzzzzzzzzzz
r/r * 13: _YMANT~1.PS
r/r 15: trojaner.png
r/r 19: 2009-02-12_RFID_Grundschutztag.pdf
r/r 22: BKA-Jahresbericht-2007.pdf
d/d 23: $RECYCLE.BIN
+ r/r 401093: desktop.ini
+ r/r 401094: $IO93PF1.jpg
+ r/r 401095: $RO93PF1.jpg
r/r 26: pm090930_geisterwald.pdf
r/r * 27: _l-a.jpg
v/v 654067: $MBR
v/v 654068: $FAT1
v/v 654069: $FAT2
d/d 654070: $OrphanFilesInteressanterweie wurden die Dateien im Papierkorb nicht als gelöscht vermerkt. Somit liegt die Vermutung nahe, dass sie manuell dorthin geschoben wurden ohne wirklich gelöscht worden zu sein.
Welche Informationen können Sie aus den gefundenen Dateien gewinnen?
Wir verwenden icat zum Rekonstruieren der Dateien.
# icat -r partition_2.dd 9 > 9.jpg
# icat -r partition_2.dd 12 > 12
# icat -r partition_2.dd 13 > 13.PS
# icat -r partition_2.dd 27 > 27.jpg
# icat -r partition_2.dd 401093 > 401093.ini
# icat -r partition_2.dd 401094 > 401093.jpg
# icat -r partition_2.dd 401095 > 401093.jpgAus den Inodes 27 und 401093 ließen sich zwei Bilder wiederherstellen. Beispielhaft folgt das teilweise rekonstruierte Bild von Inode 9. Das Bild von Inode 27 stellt dieses in vollständiger Form dar.
Schreiben Sie den zweiten nicht allozierten Bereich aus arbeitskopie.dd nach unallocated_2.dd.
# mmls arbeitskopie.dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description\n01: ----- 0000000000 0000002047 0000002048 Unallocated\n04: ----- 0010272768 0010295295 0000022528 Unallocated\n08: ----- 0012138496 0012648613 0000510118 Unallocated
# dd if=arbeitskopie.dd of=unallocated_2.dd bs=512 skip=0010272768 count=22528\n22528+0 Datensätze ein\n22528+0 Datensätze aus\n11534336 Bytes (12 MB) kopiert, 0,0609157 s, 189 MB/sVermerken Sie den Hashwert.
# sha256sum unallocated_2.dd \n68a5487b1df9c081bfcf62bee3937dd0703c335fae04147084379536a8e9be1e unallocated_2.ddUntersuchen Sie das Image unallocated_2.dd.
Wir verwenden zunächst hexdump um potenzielle Informationen zu extrahieren.
# hexdump unallocated_2.dd \n0000000 0000 0000 0000 0000 0000 0000 0000 0000
*\n0a001b0 0000 0000 0000 0000 0000 0000 0000 d9 00\n0a001c0 80 9a 95 07 f3 a2 08 00 00 00 20 00 00 1c 00 00\n0a001d0 0000 0000 0000 0000 0000 0000 0000 0000
*\n0a001f0 0000 0000 0000 0000 0000 0000 0000 aa55\n0a00200 0000 0000 0000 0000 0000 0000 0000 0000
*\n0abe000 7254 6575 7263 7079 2074 6150 7373 6f77\n0abe010 7472 203a 6b37 3545 2d76 593c 715f 4659\n0abe020 373a 0a59 0000 0000 0000 0000 0000 0000\n0abe030 0000 0000 0000 0000 0000 0000 0000 0000
*\n0b00000Die Informationen zu Beginn des Dumps liefern uns keine brauchbaren Informationen. Vermutlich wurden sie schon durch Schreibzugriffe auf diesen Bereich beschädigt bzw. sind unvollständig. Der zweite Bereich scheint jedoch interessanter zu sein. Wir schauen uns mit strings an, ob wir etwas herausfinden können.
# strings unallocated_2.dd
Truecrypt Passwort: 7kE5v-<Y_qYF:7YScheinbar wurde ein Passwort für einen Truecrypt-Container an dieser Stelle gespeichert.