Slack Space

Core concept

Slack Space:
Slack space refers to a number of different areas of unusable space, as opposed to unused space such as unallocated space. Slack space is not seen as available by the operating system for file storage. That is, it is not unallocated space.

Volume slack space: If a drive is divided into partitions and one of those partitions is not formatted, then files cannot be saved to that partition. In the example, Partition 3 is volume slack space.

File system slack space: Recall that a cluster (block or allocation unit) is a multiple of sectors. If, at the end of a file system, there are not enough sectors to constitute a cluster, then those sectors cannot be written to. These sectors will remain unavailable and are called system slack space.

File slack RAM: Not to be confused with RAM memory, RAM file system slack space is from the last byte of a file in a sector until the end of the sector (not cluster). In the example below, this is final, unused part of sector 2.

Drive slack space: This is the slack space from the last byte of the file until the end of the cluster. In the example above, this is the final part of sector 2 and sectors 3 and 4 (There are 4 sectors to a cluster).

Calculate the hash value

┌──(root㉿kali)-[~/Desktop]
└─# md5sum lab2.dd 
a2be5eb52cda823f6afb41f4e8c53f4d  lab2.dd

┌──(root㉿kali)-[~/Desktop]
└─# sha1sum lab2.dd 
3f20424f1fc0835607643c21502aafafda3b8d5b  lab2.dd

┌──(root㉿kali)-[~/Desktop]
└─# sha256sum lab2.dd 
7d9b132b2d3e3d9f3697bff84bdfb75c84b8720f44fb7cf75d3d632f266cd627  lab2.dd

We also compare the difference manually

┌──(root㉿kali)-[~/Desktop]
└─# cp lab2.dd lab2_Original.dd

┌──(root㉿kali)-[~/Desktop]
└─# md5sum lab2.dd
a2be5eb52cda823f6afb41f4e8c53f4d  lab2.dd

┌──(root㉿kali)-[~/Desktop]
└─# md5sum lab2_Original.dd 
a2be5eb52cda823f6afb41f4e8c53f4d  lab2_Original.dd

Or by command

┌──(root㉿kali)-[~/Desktop]
└─# dcfldd if=lab2.dd vf=lab2_Original.dd 
Total: Match

If I use the below command, actually it will not output to the txt file

┌──(root㉿kali)-[~/Desktop]
└─# dcfldd if=lab2.dd vf=lab2_Original.dd >> hash.txt
Total: Match

Because >> can only be used for stdout, while total: match always be treated as stderr. So, we need change it from stderr to stdout

2>&1
2：表示标准错误输出（stderr）的文件描述符。
>：表示重定向。
&1：表示将输出重定向到文件描述符 1，也就是标准输出（stdout）

标准输入（stdin）: 文件描述符为 0，默认来自键盘输入。
标准输出（stdout）: 文件描述符为 1，默认输出到终端。
标准错误输出（stderr）: 文件描述符为 2，用于显示错误信息，默认也是输出到终端。

┌──(root㉿kali)-[~/Desktop]
└─# dcfldd if=lab2.dd vf=lab2_Original.dd >> lab2hash.txt 2>&1

piece hash

Also, we can hash the file piecely.

┌──(root㉿kali)-[~/Desktop]
└─# dcfldd if=lab2.dd hash=md5 hashwindow=9000 hashlog=lab2_bytehashes.txt

if=lab2.dd：输入文件 lab2.dd。
hash=md5：指定使用 MD5 哈希算法。
hashwindow=9000：表示每 9000 字节计算一次哈希值。
hashlog=lab2_bytehashes.txt：将哈希值记录在 lab2_bytehashes.txt 文件中。

0 - 9000: d8c9d22b30d6580a876a174e893ed2be
9000 - 18000: c74372cd08269bdd506944d21810f610
18000 - 27000: 378fa2d0131f9269f267a85dd46de36b
27000 - 36000: b551d966b49b34ab2f19800325c9a4d7
36000 - 45000: 6263c6ecfe37842cd27ab2a0b522c26b
45000 - 54000: 8f0811e7d36111db47656dc7907255a0
54000 - 63000: fcc8c701ac3b49cff25693fbe408cb4f
63000 - 72000: 1ee5e59ed04ccdb5aa707374a19ab6f9
72000 - 81000: 2f066db5516b3ea149b391f13907e837
81000 - 90000: 0e5a15c19fb89d4ae1695fdb31324338
90000 - 99000: 47cb0772a01536d90209b2dd20b63bca
99000 - 108000: 2cda8aa603b23fb3599b81c2c38f2e06
108000 - 117000: 5d7939d00e70f9d55425a163788f3e33
117000 - 126000: 89bd6bd614687c1e008f387072104db9
126000 - 135000: 9eaa9bbb020e885d782ea4717370aedc
135000 - 144000: f0a55694ca3f86b009ebdea326b8ec88
144000 - 153000: aa1859f63c11b0c1360edc32109a6295
153000 - 162000: 5420afa22f6423a9f59e669540656bb4
162000 - 171000: 5420afa22f6423a9f59e669540656bb4
171000 - 180000: 5420afa22f6423a9f59e669540656bb4
180000 - 189000: 5420afa22f6423a9f59e669540656bb4
189000 - 198000: 5420afa22f6423a9f59e669540656bb4
......

wc (word count)

It contains a lot of information, so we can use wc to display the count of the lines, words, and characters.

┌──(root㉿kali)-[~/Desktop]
└─# wc --h
Usage: wc [OPTION]... [FILE]...
  or:  wc [OPTION]... --files0-from=F
Print newline, word, and byte counts for each FILE, and a total line if
more than one FILE is specified.  A word is a non-zero-length sequence of
printable characters delimited by white space.

With no FILE, or when FILE is -, read standard input.

The options below may be used to select which counts are printed, always in
the following order: newline, word, character, byte, maximum line length.
  -c, --bytes            print the byte counts
  -m, --chars            print the character counts
  -l, --lines            print the newline counts
      --files0-from=F    read input from the files specified by
                           NUL-terminated names in file F;
                           If F is - then read names from standard input
  -L, --max-line-length  print the maximum display width
  -w, --words            print the word counts
      --total=WHEN       when to print a line with total counts;
                           WHEN can be: auto, always, only, never
      --help        display this help and exit
      --version     output version information and exit

GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
Full documentation <https://www.gnu.org/software/coreutils/wc>
or available locally via: info '(coreutils) wc invocation'

┌──(root㉿kali)-[~/Desktop]
└─# wc lab2_bytehashes.txt
 1051  4199 54343 lab2_bytehashes.txt

hexedit

As our image is NTFS – the first bytes are: EB 52 90 4E. The image did not come from a bootable USB stick, so our next point of interest in the file is the Master File Table (MFT but written as $MFT). We shall examine the MFT entry signature which begins with ‘46 49 4C 45’, so we can search for this entry in hexedit.

Ctrl + G go to the position (in hex)
Tab switch to content column
Ctrl + S search

Cluster number

We find the start of the MFT entry (signature) at 0x2000 which is 8192 in decimal. This is sector 17. (8192/512=16) Because start from 0.

Display metadata

One new command which is useful for displaying metadata information including sector, cluster and MFT information is the fsstat command.

fsstat

┌──(root㉿kali)-[~/Desktop]
└─# fsstat lab2.dd           
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: NTFS
Volume Serial Number: 2C8E13DA8E139B80
OEM Name: NTFS    
Volume Name: lab7disk
Version: Windows XP

METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 6144
First Cluster of MFT Mirror: 16
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 - 256
Root Directory: 5

CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 512
Total Cluster Range: 0 - 18430
Total Sector Range: 0 - 18430

$AttrDef Attribute Values:
$STANDARD_INFORMATION (16)   Size: 48-72   Flags: Resident
$ATTRIBUTE_LIST (32)   Size: No Limit   Flags: Non-resident
$FILE_NAME (48)   Size: 68-578   Flags: Resident,Index
$OBJECT_ID (64)   Size: 0-256   Flags: Resident
$SECURITY_DESCRIPTOR (80)   Size: No Limit   Flags: Non-resident
$VOLUME_NAME (96)   Size: 2-256   Flags: Resident
$VOLUME_INFORMATION (112)   Size: 12-12   Flags: Resident
$DATA (128)   Size: No Limit   Flags: 
$INDEX_ROOT (144)   Size: No Limit   Flags: Resident
$INDEX_ALLOCATION (160)   Size: No Limit   Flags: Non-resident
$BITMAP (176)   Size: No Limit   Flags: Non-resident
$REPARSE_POINT (192)   Size: 0-16384   Flags: Non-resident
$EA_INFORMATION (208)   Size: 8-8   Flags: Resident
$EA (224)   Size: 0-65536   Flags: 
$LOGGED_UTILITY_STREAM (256)   Size: 0-65536   Flags: Non-resident

We see from this information that:

• The sector size is 512 bytes
• The cluster size is also 512 bytes, so there is 1 sector per cluster
• The sector / cluster range is 0-18430
  We take the number of clusters (18430) and multiply it by the cluster size (512 bytes).

18430 * 512 = 9,436,160
Our lab2.dd image is 9 MiB (9 x 1024 x 1024) which is 9,437,184 bytes.

9,437,184 - 9,436,160 = 1024 which is the size of the MFT entries size. So, our disk is 1024 bytes reserved for the MFT plus 18430 clusters of 512 bytes for files.

The following is a list of MFT byte locations and is from:
A Journey into NTFS: Part 6 by Matt B.

• Bytes 0–3 (46 49 4c 45) contain the MFT entry signature, FILE. This will be marked as BAD if an error was found in the entry.
• Bytes 4–5 (30 00) provide the offset to the fixup array, which is 48 bytes in the entry.
• Bytes 6–7 (03 00) provide the number of entries in the fixup array; 3 in this case.
• Bytes 8–15 (c6 55 43 d7 01 00 00 00) provide the $LogFile sequence number (this converts to 7906481606)
• Bytes 16–17 (01 00) provide the MFT sequence value; 01 in this case.
• Bytes 18–19 (01 00) provide the link count; a value of 01 means this file has only one name.
• Bytes 20–21 (38 00) provide the offset to the first attribute; 56 bytes.
• Bytes 22–23 (01 00) provide the flags (is the file in-use and/or is this a directory?); a value of 01 says this is a file
• Bytes 24–27 (A8 01 00 00) provide the used size of the MFT entry, where as
• Bytes 28–31 (00 04 00 00) provide the allocated size of the MFT entry. The allocated size is 16,384 bytes.
• Bytes 32–39 (00 00 00 00 00 00 00 00) determine whether this entry is a base entry or not; a value of zero means it is.
• Bytes 40–41 (06 00) provide the next attribute ID to be assigned; 06 means that there are already five attributes.
• Bytes 42+ contain attributes and fixup values.

Notice also that the file system is correctly identified as NTFS but the Version is incorrectly listed as Windows XP. The Version is in fact Windows 10 – perhaps a legacy of older commands that are not updated to identify later operating systems. The name of the disk that the image was created from is correctly identified as lab2disk.

The MFT begins at hex 0x20F2 (8434 decimal)

fls

┌──(root㉿kali)-[~/Desktop]
└─# fls -f ntfs lab2.dd
r/r 4-128-1:    $AttrDef
r/r 8-128-2:    $BadClus
r/r 8-128-1:    $BadClus:$Bad
r/r 6-128-4:    $Bitmap
r/r 7-128-1:    $Boot
d/d 11-144-4:   $Extend
r/r 2-128-1:    $LogFile
r/r 0-128-6:    $MFT
r/r 1-128-1:    $MFTMirr
r/r 9-128-8:    $Secure:$SDS
r/r 9-144-11:   $Secure:$SDH
r/r 9-144-5:    $Secure:$SII
r/r 10-128-1:   $UpCase
r/r 10-128-4:   $UpCase:$Info
r/r 3-128-3:    $Volume
r/r 42-128-1:   caranimated.gif
r/r 42-128-3:   caranimated.gif:Zone.Identifier
r/r 43-128-1:   cutedog.jpg
r/r 43-128-3:   cutedog.jpg:Zone.Identifier
r/r 45-128-1:   elephant.png
r/r 45-128-3:   elephant.png:Zone.Identifier
r/r 37-128-1:   presentation.pptx
r/r 39-128-1:   smalldocx.docx
r/r 40-128-1:   smallpdf.pdf
d/d 34-144-1:   System Volume Information
-/r * 38-128-1: presentationd.ppt
-/r * 41-128-1: smallpdfd.pdf
-/r * 44-128-1: dogd.jpg
-/r * 44-128-3: dogd.jpg:Zone.Identifier
-/r * 46-128-1: elephantd.png
-/r * 46-128-3: elephantd.png:Zone.Identifier
V/V 256:        $OrphanFiles

All 10 files are found, including the 4 deleted files which are displayed at the bottom of the output with a *. The ‘d’ means that what is shown is a directory (folder) and the ‘r’ means it is a file. If the file system information is not included in the command (-f ntfs) fls will try different file systems and likely find the correct one anyway.

This will create a text file with the output in that we can use another new command against, the mactime command. This will give a timeline of the file events. However, when running the previous fls command, the -m switch must be used to embed timeline information in the fls output. If not, then the mactime command will have no effect – there will be no timeline information to show. I therefore, run the command again with -m switch and produce a much more detailed file.

┌──(root㉿kali)-[~/Desktop]
└─# fls -m / lab2.dd > flslab2_outputtime.txt

0|/$AttrDef ($FILE_NAME)|4-48-2|r/rr-xr-xr-x|0|0|82|1607118024|1607118024|1607118024|1607118024
0|/$AttrDef|4-128-1|r/rr-xr-xr-x|0|0|2560|1607118024|1607118024|1607118024|1607118024
0|/$BadClus ($FILE_NAME)|8-48-3|r/rr-xr-xr-x|0|0|82|1607118024|1607118024|1607118024|1607118024
0|/$BadClus|8-128-2|r/rr-xr-xr-x|0|0|0|1607118024|1607118024|1607118024|1607118024
0|/$BadClus:$Bad|8-128-1|r/rr-xr-xr-x|0|0|9436672|1607118024|1607118024|1607118024|1607118024
0|/$Bitmap ($FILE_NAME)|6-48-2|r/rr-xr-xr-x|0|0|80|1607118024|1607118024|1607118024|1607118024
0|/$Bitmap|6-128-4|r/rr-xr-xr-x|0|0|2304|1607118024|1607118024|1607118024|1607118024
0|/$Boot ($FILE_NAME)|7-48-2|r/rr-xr-xr-x|48|0|76|1607118024|1607118024|1607118024|1607118024
0|/$Boot|7-128-1|r/rr-xr-xr-x|48|0|8192|1607118024|1607118024|1607118024|1607118024
0|/$Extend ($FILE_NAME)|11-48-3|d/dr-xr-xr-x|0|0|80|1607118024|1607118024|1607118024|1607118024
0|/$Extend|11-144-4|d/dr-xr-xr-x|0|0|552|1607118024|1607118024|1607118024|1607118024
0|/$LogFile ($FILE_NAME)|2-48-2|r/rr-xr-xr-x|0|0|82|1607118024|1607118024|1607118024|1607118024
......

We can now run mactime against this fls output with timeline information.

┌──(root㉿kali)-[~/Desktop]
└─# mactime -b flslab2_outputtime.txt > mactimelab2_output.txt
Old package separator "'" deprecated at /usr/bin/mactime line 154.
Old package separator "'" deprecated at /usr/bin/mactime line 167.

Sat Dec 05 2020 10:13:24    34205 m... -/rrwxrwxrwx 0        0        41-128-1 /smallpdfd.pdf (deleted)
Sat Dec 05 2020 10:13:41    31397 m... r/rrwxrwxrwx 0        0        40-128-1 /smallpdf.pdf
Sat Dec 05 2020 10:14:24    11937 m... r/rrwxrwxrwx 0        0        39-128-1 /smalldocx.docx
Sat Dec 05 2020 10:15:43     8360 m... -/rrwxrwxrwx 0        0        44-128-1 /dogd.jpg (deleted)
                              172 m... -/rrwxrwxrwx 0        0        44-128-3 /dogd.jpg:Zone.Identifier (deleted)
Sat Dec 05 2020 10:16:01     5524 m... r/rrwxrwxrwx 0        0        43-128-1 /cutedog.jpg
                               96 m... r/rrwxrwxrwx 0        0        43-128-3 /cutedog.jpg:Zone.Identifier
Sat Dec 05 2020 10:17:08   388376 m... r/rrwxrwxrwx 0        0        45-128-1 /elephant.png
                              132 m... r/rrwxrwxrwx 0        0        45-128-3 /elephant.png:Zone.Identifier
Sat Dec 05 2020 10:17:48   816429 m... -/rrwxrwxrwx 0        0        46-128-1 /elephantd.png (deleted)
                              149 m... -/rrwxrwxrwx 0        0        46-128-3 /elephantd.png:Zone.Identifier (deleted)
Sat Dec 05 2020 10:18:43  2066410 m... r/rrwxrwxrwx 0        0        42-128-1 /caranimated.gif
                              142 m... r/rrwxrwxrwx 0        0        42-128-3 /caranimated.gif:Zone.Identifier
Sat Dec 05 2020 10:19:54    33782 m... r/rrwxrwxrwx 0        0        37-128-1 /presentation.pptx
Sat Dec 05 2020 10:20:20    85504 m... -/rrwxrwxrwx 0        0        38-128-1 /presentationd.ppt (deleted)
Sat Dec 05 2020 10:33:01    33782 ..c. r/rrwxrwxrwx 0        0        37-128-1 /presentation.pptx
                            85504 ..c. -/rrwxrwxrwx 0        0        38-128-1 /presentationd.ppt (deleted)
                            11937 ..c. r/rrwxrwxrwx 0        0        39-128-1 /smalldocx.docx
......

Fri Dec 04 2020 16:16:01     5524 m... r/rrwxrwxrwx 0        0        43-128-1 /cutedog.jpg

The line above is from the ‘mactime’ output in the ‘mactimelab2_output.txt’ for the cutedog.jpg file.

The first column is the date and time (on the computer) when an activity on the file took place. This may be created, modified or accessed.

The next column, 5524, is the size of the file in bytes. Note that it is the actual size of the file, not the file on disk which would extend to the end of the final cluster. As Windows 10 was used to download and modify the files in Photoshop, the cluster size relates to Windows 10 which is 4096 bytes. There are 2 clusters required to fit the file into, hence the 8192 bytes on disk (2 x 4096). Note: The image is from Windows and is not from the .dd file which was created prior to the screenshot, hence the time and date difference and the larger cluster size.

The next column is the activity. The ‘c’ in NTFS is for ‘MFT modified’ and ‘m’ is for ‘file modified’ as per the below table. Later in the mactime file, this jpeg was modified (m) at 10:33. However, 2 issues are apparent here. The first is that the ‘modified’ file time is before the ‘MFT modified’ time. This has occurred because the file was created and then saved as a new file when it was reduced in size, so this needs to be interpreted rather than taken as accurate.
Next, there are a number of files with the same time of 16:33 and ‘c’ in the column. As they cannot all be ‘MFT modified’ at the same time, this indicates they are all moved to a particular folder at the same time, effectively creating them. The modified time relates to when they were originally modified and then, slightly later, they were moved, and this is the later ‘create’ time. File systems display the ‘c’ or ‘m’ or ‘a’ or ‘b’ meaning different activities and below is an example of the different interpretations for this column.

MAC Meaning by File System

File System	m	a	c	b
Ext4	Modified	Accessed	Changed	Created
Ext2/3	Modified	Accessed	Changed	N/A
FAT	Written	Accessed	N/A	Created
NTFS	File Modified	Accessed	MFT Modified	Created
UFS	Modified	Accessed	Changed	N/A

At 16:42, the following line is in the mactime file. The files were created, copied onto the USB stick and then a lab2.dd image was taken, all within an hour. How can there be such a large time difference from 10:16 when the cutedog.jpg was created and 16:16 (4:42pm) when it was ‘a’ accessed and ‘b’ created (again?). The answer is that the time in this column relates to the time on the Linux VirtualBox machine which is not accurate and not the same as the host Windows 10 time – a discrepancy which must be interpreted by the forensic investigator and is not immediately obvious.

31397 .a.b r/rrwxrwxrwx 0        0        40-128-1 /smallpdf.pdf

The next column is unix permissions (r/rrwxrwxrwx) followed by User Group and then Group ID: these are only non-zero for Ext2 and Ext3 (Unix and Linux) file systems.

The next column is the inode (index node) address (in the MFT address in NTFS) 40-128-1 followed by the file name.

Note that even with a deleted file, the name of the file is still most likely available – the first letter is replaced in the MFT with a dollar sign ($) and this is how forensic tools know that the file is deleted. As the $ sign writes over the first letter, the original first letter often cannot be recovered. However, this tool has recovered the full name of the file.

82 macb -/rrwxrwxrwx 0 0 44-48-2 /dogd.jpg ($FILE_NAME) (deleted)

ffind

The next new tool of use is ffind.

This tool takes an inode address and produces the name of that file at that address.

┌──(root㉿kali)-[~/Desktop]
└─# ffind lab2.dd 44-48-2                    
* //dogd.jpg

hide file

┌──(root㉿kali)-[~/Desktop]
└─# foremost -w lab2.dd -o lab2_headers
Processing: lab2.dd

Foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit File

Foremost started at Tue Sep 24 12:53:58 2024
Invocation: foremost -w lab2.dd -o lab2_headers 
Output directory: /root/Desktop/lab2_headers
Configuration file: /etc/foremost.conf
------------------------------------------------------------------
File: lab2.dd
Start: Tue Sep 24 12:53:58 2024
Length: 9 MB (9437184 bytes)

Num  Name (bs=512)         Size  File Offset     Comment 

0:        1135.jpg         2 KB          581530      
1:        1473.jpg         5 KB          754176      
2:        1484.jpg         8 KB          759808      
3:       10496.gif        19 KB         5373952       (1060 x 1060)
4:        1152.ole        85 KB          589824      
5:        1086.pptx           32 KB          556032      
6:        1157.zip        526 B          592471      
7:        1158.zip         4 KB          593295      
8:        1168.zip         1 KB          598236      
9:        1173.zip         2 KB          600707      
10:       1179.zip         1 KB          603694      
11:       1183.zip         1 KB          605963      
12:       1186.zip         3 KB          607390      
13:       1193.zip         1 KB          611053      
14:       1196.zip         1 KB          612559      
15:       1199.zip         2 KB          614004      
16:       1203.zip         1 KB          616182      
17:       1207.zip         1 KB          618003      
18:       1209.zip         1 KB          619152      
19:       1211.zip         1 KB          620450      
20:       1215.zip         1 KB          622325      
21:       1218.zip         1 KB          623838      
22:       1221.zip         1 KB          625530      
23:       1224.zip         1 KB          626948      
24:       1319.docx           11 KB          675328      
25:      14532.png       379 KB         7440384       (894 x 894)
26:       1343.pdf        30 KB          687616      
27:       1405.pdf        33 KB          719360      
Finish: Tue Sep 24 12:53:58 2024

28 FILES EXTRACTED

jpg:= 3
gif:= 1
ole:= 1
zip:= 20
png:= 1
pdf:= 2
------------------------------------------------------------------

Foremost finished at Tue Sep 24 12:53:58 2024

As we know what files are in the image and that there are 10 of them (the presentation.ppt file is identified with a ‘.ole’ extension which is used sometimes for secure ppt, DOCX etc) I know that the 20 zip files are false positives – they do not exist. The file names relate to the sector where the file is located, so for example:

1473.jpg 5 KB 754176

is located beginning at sector 1473 (1473 * 512 bytes = 754,176)

Note that png and gif files contain the dimensions of the file – eg: 894 x 894 (pixels)

We shall examine Foremost more closely in the following lab.

1135.jpg 2 KB 581530

I now choose to carve this file out to be sure what it is as the size does not match any of the files I know are on the image. The starting sector is 581,530 which is 0x8DF9A. I search for the end signature in hexedit using ‘ctrl s’ and search for ‘DD F9’. I find this location at 0x8EA76 which is 584,310 in decimal. 584,310 – 581,530 = 2780 bytes, so the file is 2780 bytes. I carve out the file with:

┌──(root㉿kali)-[~/Desktop]
└─# dcfldd if=lab2.dd skip=581530 bs=1 count=2780 of=unknowpic.jpg
2560 blocks (0Mb) written.
2780+0 records in
2780+0 records out

it appears to be the Powerpoint file that was not deleted – ‘presentation.pptx’. With a Foremost header showing another file as a pptx file, perhaps Foremost has not identified these 2 files correctly as there was only one pptx file and this is recovered as a jpg file. Or has it? It appears the pptx file was changed to a jpeg file as the file signatures are for a jpeg. It seems Linux has done this but it is very strange.

I then search for the pptx file on lab2.dd with a search for the start file signature of ‘50 4B 03 04’. I find this at location 0x87C00 which is decimal 556,032. I see from the Foremost header that it is 32 KB and check the file properties in Windows – it is 33,782 bytes.

I carve out the ‘real’ pptx file with:

┌──(root㉿kali)-[~/Desktop]
└─# dcfldd if=lab2.dd skip=556032 bs=1 count=33782 of=unknow.pptx 
33536 blocks (0Mb) written.
33782+0 records in
33782+0 records out

And the file opens in Windows and is the ‘presentation.pptx’ file. Where did the 1135.jpg file come from?

The answer is that the single slide in the presentation is also saved as a thumbnail jpeg, so the pptx file is actually made up of xml with a jpeg embedded in the xml as a thumbnail. This jpeg is saved separately but linked to the file.

In the NTFS file system, thumbnails are small, so for efficiency they are saved in the MFT. This is why 1135.jpg is not where it ‘should be’. The file offset shown in audit.txt is 581,530 but (1135 x 512=581,120). The discrepancy is because the file is in the MFT and not at offset 1135.

By looking at this screenshot of a previous file, we see that in that case the jpeg is named ‘thumbnail.jpg’. There are actually only 2 ‘real’ jpegs in the lab2.dd file, ‘cutedog.jpg’ and ‘dogd.jpg’ (this one is deleted). The ‘hidden.jpg’ is actually ‘hidden.txt’ and Foremost has not been fooled by the changed extension. However, we can see how easily a forensic investigator can be fooled by the ‘thumbnail jpg’ of the Powerpoint slide. Foremost correctly recovered a jpeg file, but it is only by examining the hex data carefully that we realise that it is not a standalone jpeg file. Foremost does not tell us this but meticulous forensic techniques can.

I check the mactimelab2_output.txt file and locate the ‘elephant.png’.

388376 ..c. r/rrwxrwxrwx 0 0 45-128-1 /elephant.png

This confirms the size which will be the ‘count’ but I need the starting sector address so I need to convert the inode address of ’45-128-1’ to hex. I use the ‘istat’ command with the inode number. This will list all of the sectors that the file occupies, so this will give me the first sector and I can calculate where the final byte in the file is by adding the size of the file (388,376) to this.

root@kali:~# istat Desktop/lab2.dd 45-128-1
MFT Entry Header Values:
Entry: 45        Sequence: 1
$LogFile Sequence Number: 1065225
Allocated File
Links: 1

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 264  ()
Created:        2020-12-04 16:42:14.221850800 (EST)
File Modified:  2020-12-04 16:17:08.425317900 (EST)
MFT Modified:   2020-12-04 16:33:01.612084400 (EST)
Accessed:       2020-12-04 16:42:14.304882900 (EST)

$FILE_NAME Attribute Values:
Flags: Archive
Name: elephant.png
Parent MFT Entry: 5     Sequence: 5
Allocated Size: 388608          Actual Size: 0
Created:        2020-12-04 16:42:14.221850800 (EST)
File Modified:  2020-12-04 16:42:14.221850800 (EST)
MFT Modified:   2020-12-04 16:42:14.221850800 (EST)
Accessed:       2020-12-04 16:42:14.221850800 (EST)

Attributes: 
Type: $STANDARD_INFORMATION (16-0)   Name: N/A   Resident   size: 72
Type: $FILE_NAME (48-2)   Name: N/A   Resident   size: 90
Type: $DATA (128-1)   Name: N/A   Non-Resident   size: 388376  init_size: 388376
14532 14533 14534 14535 14536 14537 14538 14539 
……… to
15284 15285 15286 15287 15288 15289 15290 
Type: $DATA (128-3)   Name: Zone.Identifier   Resident   size: 132

I have deleted the information regarding the additional sectors in the middle of this output as the output takes several pages – there are 759 sectors. I can now locate the end of the ‘elephant.png’ file by taking the start sector address of 14,532 and multiplying this by 512 and then adding 388,376 bytes.

512 x 14,532 = 7,440,384. This should be the start address of the file.

7,440,384 + 388,376 = 7,828,760. This should be the final byte in the file. As I shall be using hexedit to check this, I need the starting and ending address for the file in hex.

7,440,384 in decimal is 718,800 in hex.

7,828,760 in decimal is 777,518 in hex.

I then search for the file signature and locate it at the expected at 0x718800

and then the end of the file at 0x777518.

perhaps ‘hidden.jpg’ will fit here. It is a text file (extension changed) of only 43 bytes.

0x777519 is 7,828,761 in decimal. I add 43 bytes to this and calculate it to be 7,828,804. In hex this is 0x777,544 which will overwrite the start of the next file – 43 bytes is just too big. I shall ‘cheat’ a little here and modify the ‘hidden.jpg’ file to be a little smaller. I remove a few words from the file and it is now 26 bytes – it will now fit here.

7,828,761 + 26 = 7,828,787 which in hex is 0x777533. This confirms there is sufficient room in slack space for the file. First, I open the text file in hexedit.

Note that there is no file signature for a txt file. There is no metadata contained in the file.

┌──(root㉿kali)-[~/Desktop]
└─# dd if=Desktop/hidden.jpg of=Desktop/lab2.dd bs=1 seek=7828761 count=26 conv=notrunc

Others are almost same process.