Week 9: More scripting
The names of the files are not embedded in the files: rather, they are recorded in the MFT of the host storage and so the binary of the files are identical – they do not have the names of the files in the binary.
Any file saved to a storage device will always be either in the $MFT table if it is a thumbnail or will begin at the start of a cluster. Therefore, for a file to be located in slack space, it must have been deliberately placed there. Rather than searching for files, locating files and then manually checking if any are ‘placed’ in slack space, there is a command which will only look in slack space command.
blkls
This command is ‘blkls’ and requires the ‘-s’ switch to display the file.
┌──(root㉿kali)-[~/Desktop]
└─# blkls lab3.dd -s
secret file in slack spaceSorter
the ‘Sorter’ command will recover files and then sort them based on their type.
sorter 需要知道目录结构的位置，可以尝试明确指定输出目录或者将其导出到某个临时文件夹。需要 -d，并且必须已经存在。
┌──(root㉿kali)-[~/Desktop]
└─# sorter -d lab3_sorter lab3.dd
Directory lab3_sorter does not exist
sorter [-b size] [-E] [-e] [-h] [-l] [-md5] [-s] [-sha1] [-U] [-v] [-V] [-a hash_alert] [-c config] [-C config] [-d dir] [-m mnt] [-n nsrl_db] [-x hash_exclude] [-o imgoffset] [-f fstype] [-i imgtype] image [images] [dir_meta_addr]
┌──(root㉿kali)-[~/Desktop]
└─# mkdir lab3_sorter
┌──(root㉿kali)-[~/Desktop]
└─# sorter -d lab3_sorter lab3.dd
Analyzing "lab3.dd"
Loading Allocated File Listing
Processing 47 Allocated Files and Directories
100%
All files have been saved to: lab3_sorterAnd the result is a number of text files describing the contents of the image.
Looking at documents.txt as an example, information about the 3 documents is displayed. Note that documents includes the PowerPoint presentation and the 2 pdf files.
smallpdf.pdf
PDF document, version 1.7, 1 page(s) (zip deflate encoded)
Image: lab3.dd Inode: 40-128-1
presentationd.ppt
Composite Document File V2 Document, Little Endian, Os: Windows, Version 10.0, Code page: 1252, Title: This is a Presentation, Author: Alastair Nisbet, Last Saved By: Alastair Nisbet, Revision Number: 2, Name of Creating Application: Microsoft Office PowerPoint, Total Editing Time: 00:56, Create Time/Date: Fri Dec 4 21:19:23 2020, Last Saved Time/Date: Fri Dec 4 21:20:20 2020, Number of Words: 5
Image: lab3.dd Inode: 38-128-1
smallpdfd.pdf
PDF document, version 1.7, 1 page(s) (zip deflate encoded)
Image: lab3.dd Inode: 41-128-1And looking at the disk.txt file:
$Boot
DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS ", Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 128, dos < 4.0 BootSector (0), FAT (1Y bit by descriptor); NTFS, sectors/track 63, physical drive 0x80, sectors 18431, $MFT start cluster 6144, $MFTMirror start cluster 16, clusters/RecordSegment 2, clusters/index block 8, serial number 02c8e13da8e139b80; contains bootstrap BOOTMGR
Image: lab3.dd Inode: 7-128-1The information is fairly comprehensive, especially for the presentation PowerPoint file and simple to follow. However, the folder only contains information about each of the files, not the files themselves. To recover the files as well, the ‘-s’ switch must be used with the command, so we run the command again with this switch.
┌──(root㉿kali)-[~/Desktop]
└─# sorter -d lab3_sorter -s lab3.dd
Analyzing "lab3.dd"
Loading Allocated File Listing
Processing 47 Allocated Files and Directories
100%
All files have been saved to: lab3_sorter
This produces the same text files and the recovered image files named with the inode address.
However, the txt files do list the correct file names. As an example, the images folder contains:
And the images.txt file contains:
$Extend/$RmMetadata/$TxfLog/$TxfLog.blf
Targa image data - Map 33355 x 50764 x 1 ""
Image: lab3.dd Inode: 33-128-1
Saved to: images/lab3.dd-33-128-1.blf
$UpCase
Targa image data - Map 6 x 7 x 8 +4 +5
Image: lab3.dd Inode: 10-128-1
Saved to: images/lab3.dd-10-128-1
caranimated.gif
GIF image data, version 89a, 1060 x 1060
Image: lab3.dd Inode: 42-128-1
Saved to: images/lab3.dd-42-128-1.gif
cutedog.jpg
JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 259x194, components 3
Image: lab3.dd Inode: 43-128-1
Saved to: images/lab3.dd-43-128-1.jpg
elephant.png
PNG image data, 894 x 894, 8-bit/color RGBA, non-interlaced
Image: lab3.dd Inode: 45-128-1
Saved to: images/lab3.dd-45-128-1.png
dogd.jpg
JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 284x177, components 3
Image: lab3.dd Inode: 44-128-1
Saved to: images/lab3.dd-44-128-1.jpg
elephantd.png
PNG image data, 3457 x 4134, 8-bit/color RGBA, non-interlaced
Image: lab3.dd Inode: 46-128-1
Saved to: images/lab3.dd-46-128-1.pngAnd the text.txt file contains:
caranimated.gif:Zone.Identifier
ASCII text, with CRLF line terminators
--- Extension Mismatch! ---
Image: lab3.dd Inode: 42-128-3
Saved to: text/lab3.dd-42-128-3.identifier
cutedog.jpg:Zone.Identifier
ASCII text, with CRLF line terminators
--- Extension Mismatch! ---
Image: lab3.dd Inode: 43-128-3
Saved to: text/lab3.dd-43-128-3.identifier
elephant.png:Zone.Identifier
ASCII text, with CRLF line terminators
--- Extension Mismatch! ---
Image: lab3.dd Inode: 45-128-3
Saved to: text/lab3.dd-45-128-3.identifier
dogd.jpg:Zone.Identifier
ASCII text, with CRLF line terminators
--- Extension Mismatch! ---
Image: lab3.dd Inode: 44-128-3
Saved to: text/lab3.dd-44-128-3.identifier
elephantd.png:Zone.Identifier
ASCII text, with CRLF line terminators
--- Extension Mismatch! ---
Image: lab3.dd Inode: 46-128-3
Saved to: text/lab3.dd-46-128-3.identifierNote that the images metadata also contains the size of the image. This is occasionally embedded in files in the binary. It may also be calculated by subtracting the start address of the file from the end address, and it also may be read from the FAT or MFT table, even if the file has been deleted. Whilst it would be preferable for the recovered images to retain their correct names rather than having to match up 2 files to align the correct name to a file, this demonstrates that recovering the files and recovering the file names are 2 different operations. With Foremost and Sorter, the investigator is left to match the name to the file that is recovered.
Foremost, Scalpel and Photorec:
To recap, we shall recover the files with Foremost, Scalpel and Photorec and compare how each tool recovers files.
Foremost:
The most basic tool and the simplest to use to quickly recover many types of files.
┌──(root㉿kali)-[~/Desktop]
└─# foremost -i lab3.dd -o lab3_foremost
Processing: lab3.dd
|foundat=_rels/.rels �(�
foundat=ppt/presentation.xml��ݎ�0��7�whz�qD@#N��1��M��<@�J��VW����T@7��pG{���ד��K���**�R�iL ���
qH��n5J(Q����J@J�������E=�%(�it%▒F�9K�Q�z�y*;B��SU�@۾�%Ӹ�/���/��ǑW�BP�/?�_��E?��Tb�&�n�PǢV�h�g����/I�3lOo
��Z!�Ķ�3�A���J?��"Oi��q�L��ɹ�A�O�������sd▒���λ��~�삅�
The audit.txt file shows the files recovered, their size and the byte offset to their location. The jpg images do not show the dimensions of the files.
The name of the file is the ‘File Offset’ divided by the block size to get the cluster starting location. There is some rounding for some files.
For example, 00001473.jpg is offset 754176 / 512.
Foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit File
Foremost started at Sat Sep 28 22:43:41 2024
Invocation: foremost -i lab3.dd -o lab3_foremost
Output directory: /root/Desktop/lab3_foremost
Configuration file: /etc/foremost.conf
------------------------------------------------------------------
File: lab3.dd
Start: Sat Sep 28 22:43:41 2024
Length: 9 MB (9437184 bytes)
Num Name (bs=512) Size File Offset Comment
0: 00001135.jpg 2 KB 581530
1: 00001473.jpg 5 KB 754176
2: 00001484.jpg 8 KB 759808
3: 00010476.jpg 9 KB 5364035
4: 00016885.jpg 5 KB 8645540
5: 00010496.gif 19 KB 5373952 (1060 x 1060)
6: 00001152.ole 85 KB 589824
7: 00001086.pptx 32 KB 556032
8: 00001157.zip 526 B 592471
9: 00001158.zip 4 KB 593295
10: 00001168.zip 1 KB 598236
11: 00001173.zip 2 KB 600707
12: 00001179.zip 1 KB 603694
13: 00001183.zip 1 KB 605963
14: 00001186.zip 3 KB 607390
15: 00001193.zip 1 KB 611053
16: 00001196.zip 1 KB 612559
17: 00001199.zip 2 KB 614004
18: 00001203.zip 1 KB 616182
19: 00001207.zip 1 KB 618003
20: 00001209.zip 1 KB 619152
21: 00001211.zip 1 KB 620450
22: 00001215.zip 1 KB 622325
23: 00001218.zip 1 KB 623838
24: 00001221.zip 1 KB 625530
25: 00001224.zip 1 KB 626948
26: 00001319.docx 11 KB 675328
27: 00014532.png 379 KB 7440384 (894 x 894)
28: 00001343.pdf 30 KB 687616
29: 00001405.pdf 33 KB 719360
Finish: Sat Sep 28 22:43:42 2024
30 FILES EXTRACTED
jpg:= 5
gif:= 1
ole:= 1
zip:= 20
png:= 1
pdf:= 2
------------------------------------------------------------------
Foremost finished at Sat Sep 28 22:43:42 2024Foremost: Recovered 10 files including deleted files. It did not recover the file in slack space. It named files with the offset, not the correct name. It did name the files with the correct extension. There are many false positive zip files.
Scalpel
Scalpel is a later development of Foremost. This tool requires editing of the configuration file as the default is to look for no files. As we know already what files are present, we can uncomment the appropriate lines in the configuration file. I have added in a ‘cus’ file type with the custom file signatures to see if that file will be recovered.
In this link /etc/scalpel/scalpel.conf
# Here is an example of how to use the no extension option. Any files
# beginning with the string "FOREMOST" are carved and no file extensions
# are used. No footer is defined and the max carve size is 1000 bytes.
#
# NONE y 1000 FOREMOST
#
#---------------------------------------------------------------------
# GRAPHICS FILES
#---------------------------------------------------------------------
# custom Signature
cus y 15000 \xee\xf0\xda\x4d \x12\x34
#
# AOL ART files
# art y 150000 \x4a\x47\x04\x0e \xcf\xc7\xcb
# art y 150000 \x4a\x47\x03\x0e \xd0\xcb\x00\x00
#
# GIF and JPG files (very common)
# gif y 5000000 \x47\x49\x46\x38\x37\x61 \x00\x3b
# gif y 5000000 \x47\x49\x46\x38\x39\x61 \x00\x3b
# jpg y 5242880 \xff\xd8\xff???Exif \xff\xd9 REVERSE
# jpg y 5242880 \xff\xd8\xff???JFIF \xff\xd9 REVERSE
#And run the command
┌──(root㉿kali)-[~/Desktop]
└─# scalpel lab3.dd -o lab3_scalpel
Scalpel version 1.60
Written by Golden G. Richard III, based on Foremost 0.69.
Opening target "/root/Desktop/lab3.dd"
Image file pass 1/2.
lab3.dd: 100.0% |***************************| 9.0 MB 00:00 ETAAllocating work queues...
Work queues allocation complete. Building carve lists...
Carve lists built. Workload:
cus with header "\xee\xf0\xda\x4d" and footer "\x12\x34" --> 1 files
gif with header "\x47\x49\x46\x38\x37\x61" and footer "\x00\x3b" --> 0 files
gif with header "\x47\x49\x46\x38\x39\x61" and footer "\x00\x3b" --> 1 files
jpg with header "\xff\xd8\xff\x3f\x3f\x3f\x45\x78\x69\x66" and footer "\xff\xd9" --> 0 files
jpg with header "\xff\xd8\xff\x3f\x3f\x3f\x4a\x46\x49\x46" and footer "\xff\xd9" --> 7 files
png with header "\x50\x4e\x47\x3f" and footer "\xff\xfc\xfd\xfe" --> 0 files
bmp with header "\x42\x4d\x3f\x3f\x00\x00\x00" and footer "" --> 0 files
tif with header "\x49\x49\x2a\x00" and footer "" --> 1 files
tif with header "\x4d\x4d\x00\x2a" and footer "" --> 0 files
doc with header "\xd0\xcf\x11\xe0\xa1\xb1\x1a\xe1\x00\x00" and footer "\xd0\xcf\x11\xe0\xa1\xb1\x1a\xe1\x00\x00" --> 1 files
doc with header "\xd0\xcf\x11\xe0\xa1\xb1" and footer "" --> 1 files
pdf with header "\x25\x50\x44\x46" and footer "\x25\x45\x4f\x46\x0d" --> 2 files
pdf with header "\x25\x50\x44\x46" and footer "\x25\x45\x4f\x46\x0a" --> 0 files
txt with header "\x2d\x2d\x2d\x2d\x2d\x42\x45\x47\x49\x4e\x20\x50\x47\x50" and footer "" --> 0 files
zip with header "\x50\x4b\x03\x04" and footer "\x3c\xac" --> 108 files
Carving files from image.
Image file pass 2/2.
lab3.dd: 100.0% |***************************| 9.0 MB 00:00 ETAProcessing of image file complete. Cleaning up...
Done.
Scalpel is done, files carved = 122, elapsed = 0 seconds.
Note that Scalpel reports 122 files carved (we know there are only 14 so there are 108 zip files that are false positives) and that ‘cus’ appears to have been recovered. The audit.txt gives more information. As it is quite long with 122 entries, the start and finish of the file are shown. Note ‘cus’ at the end.
Scalpel version 1.60 audit file
Started at Sat Sep 28 23:01:31 2024
Command line:
scalpel lab3.dd -o lab3_scalpel
Output directory: /root/Desktop/lab3_scalpel
Configuration file: /etc/scalpel/scalpel.conf
Opening target "/root/Desktop/lab3.dd"
The following files were carved:
File Start Chop Length Extracted From
00000121.zip 685859 NO 54933 lab3.dd
...
00000015.zip 557030 NO 69487 lab3.dd
00000014.zip 556032 NO 70485 lab3.dd
00000013.pdf 719360 NO 34026 lab3.dd
00000012.pdf 687616 NO 65770 lab3.dd
00000011.doc 589824 YES 8847361 lab3.dd
00000010.doc 589824 NO 8847361 lab3.dd
00000009.tif 5364065 YES 4073120 lab3.dd
00000008.jpg 8646120 NO 4747 lab3.dd
00000007.jpg 8645540 NO 5327 lab3.dd
00000006.jpg 5366353 NO 3284514 lab3.dd
00000005.jpg 5364035 NO 3286832 lab3.dd
00000004.jpg 759808 NO 5144208 lab3.dd
00000003.jpg 754176 NO 5149840 lab3.dd
00000002.jpg 581530 NO 5206533 lab3.dd
00000001.gif 5373952 NO 20125 lab3.dd
00000000.cus 9216000 NO 2571 lab3.dd
Completed at Sat Sep 28 23:01:31 2024Scalpel: Recovered all 14 files including deleted files but some are recovered twice. Did not recover the text file in slack space – there seems to be no configuration file line for text files because they do not have a file signature so it is unlikely these can be searched for (or could they – keyword in the txt?). Names begin at number 1 and add 1 to each file name. Tif file is listed as recovered (and chopped) but no tif exists. This file and many zip files are false positives. Extensions are corrected. Gif file is recovered as a corrupted file and may not open in Kali so try Windows if it does not open.
Photorec
This tool was originally designed to recover files from camera memory sticks. It has grown to include many other files and can be run against a mounted storage device or directly on an image file – lab3.dd.
┌──(root㉿kali)-[~/Desktop]
└─# photorec /log lab3.dd /d lab3_photorec lab3.dd
PhotoRec 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.orgPhotorec recovers 10 of the 14 files including the 4 deleted files but not the text file and not the custom file. Running Photorec again on unallocated space recovers just the 4 deleted files.
Note that the original name of the usb stick is recovered – lab7disk - even though the file has been named lab3.dd
And this correctly recovers the 4 deleted files only.
And only the 4 deleted files are recovered.
PhotoRec 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
Disk lab3.dd - 9437 KB / 9216 KiB (RO)
Partition Start End Size in sectors
P NTFS 0 0 1 1 37 36 18432 [lab7disk]
4 files saved in lab3_photorec directory.
Recovery completed.
You are welcome to donate to support and encourage further development
https://www.cgsecurity.org/wiki/Donation One issue with the report file is that it is in xml format so is not simple to open and read like a text file.
Photorec: Recovered 10 files including deleted files. It did not recover the file in slack space. It names files with ‘f’ followed by the offset, not the correct name. It did name files with the correct extension. The gif file is recovered as the full animated gif file.
All 4 of these tools, including Sorter, are fairly simple to use and provide quick results with allocated and unallocated space checked for files. Some can be used to search just the unallocated space which identifies deleted files but none of these tools recovered the text file hidden in slack space. The leads to an interesting question:
Will a file with a file signature located in slack space be recovered? The text file we have hidden does not have a file signature and the jpg file has a custom signature that will not be searched for, so this is the reason they are missed?
Recall from earlier in the lab that slack space can be searched with the blkls tool and that this did recover the text file in slack space. Consider how this tool may have recognized that this file exists if it has no file signature – ASCII text recognized as text perhaps? Recall that the blkls tool has an option to only search slack space and that it did recover the small text but not as a file. Note that the output cannot be directed to a file.
Saving & Deleting Files:
When a file is saved to a storage device, the file system makes 3 changes to the drive. The first is to save the file to available space in the data area of the drive. The second is to record the cluster chain information in the File Allocation Table (FAT) and the mirror of the FAT. The third is to link the file information in the metadata line to the cluster chain.
For example, the minion.jpg file is saved to the usb stick. The stick now has the boot information, followed by the FAT tables which is followed by the metadata area which is followed by the data area which takes up the rest of the usb stick. The minion.jpg begins at 0x1A000 which is byte 106496. This is sector (106496/512) 208 and cluster 13. For the purpose of this lab, when referring to a cluster it is from the start of the file, not the cluster area.
Boot information:
Cluster chain information for 1 file – at location 0x1000 (4096)
Copy of cluster chain information – at location 0x8800 (34816)
Start of area beginning with the name of the stick
0x10000 (65536) Cluster 8
Similar screenshot but extended to 8 columns of 2 bytes so that the minion.jpg information begins at the start of a line.
0x10080 (65664).
4D 49 4E 49 4F 4E 20 20 4A 50 47 20 18 2F 4F 51 2B 57 2B 57 00 00 EA 75 41 54 05 00 89 15 00 00
This line contains information about the file that is saved.
4D 49 4E 49 4F 4E - hex converted to ASCII is ‘minion’
20 20 is 2 spaces as the filename has 8 spaces reserved as a maximum.
4A 50 47 20 - jpg followed by a space. This allows for a file extension of 4 characters.
The rest of the line is time information for create, modify, access and permissions.
The minion.jpg file begins at 0x1A000 (106496) – cluster 13.
The minion.jpg file ends at 0x1B589 (112009).
A second minion.jpg file (renamed minion1.jpg) is then dragged onto the stick. The cluster chain now reflects the added cluster that is allocated to this new file. The addition is FF FF.
And the file information:
4D 49 4E 49 4F 4E 20 20 4A 50 47 20 18 2F 4F 51 2B 57 2B 57 00 00 EA 75 41 54 05 00 89 15 00 00
4D 49 4E 49 4F 4E 31 20 4A 50 47 20 18 C7 35 5A 2B 57 2B 57 00 00 EA 75 41 54 06 00 89 15 00 00
Most of the information is similar but the times have changed as these operations were a few minutes apart.
The second minion1.jpg is located at 0x1c000 (114688) cluster 14.
We can surmise that files are dragged onto a USB stick in Windows that has been formatted with Fat16, they are placed in the next unallocated cluster. We can therefore predict the location of the files if the order of saving the files is known.
The first minion.jpg file is then deleted.
The cluster chain information is updated to reflect that the cluster is now unallocated.
The information began with one file saved as:
F8 FF FF FF FF FF FF FF FF FF FF FF
When the second minion was added it was:
F8 FF FF FF FF FF FF FF FF FF FF FF FF FF
And when the first minion is deleted, it is now:
F8 FF FF FF FF FF FF FF FF FF 00 00 FF FF
It can be surmised that where the 00 00 has replaced FF FF, this is the cluster chain information for the first minion.
Note that the cluster chain information has been wiped. It does not exist now and it cannot be recovered.
The file information has also been updated. The starting letter of the name minion.jpg has been changed from hex 4D to hex E5. As E5 is an unprintable character, a dot is printed in the ASCII window in place of E5.
This is the only change to this information.
The progression from 2 files to deleting one file is then:
2 files:
4D 49 4E 49 4F 4E 20 20 4A 50 47 20 18 2F 4F 51 2B 57 2B 57 00 00 EA 75 41 54 05 00 89 15 00 00
4D 49 4E 49 4F 4E 31 20 4A 50 47 20 18 C7 35 5A 2B 57 2B 57 00 00 EA 75 41 54 06 00 89 15 00 00
First file deleted:
E5 49 4E 49 4F 4E 20 20 4A 50 47 20 18 2F 4F 51 2B 57 2B 57 00 00 EA 75 41 54 05 00 89 15 00 00
4D 49 4E 49 4F 4E 31 20 4A 50 47 20 18 C7 35 5A 2B 57 2B 57 00 00 EA 75 41 54 06 00 89 15 00 00
This file is saved as minion_deleted.dd with a byte size of 150,000, easily large enough for all the information that needs to be retained including the 2 minion files.
Fragmented Files:
Fragmentation of files is fairly rare now because storage devices tend to be larger than required. If a file cannot fit on a storage device in contiguous blocks, then it can be broken into pieces (fragmented) so that it can be squeezed into multiple locations allowing for a file to be saved to storage even though there is not one area that is big enough for the file to fit in. This usually occurs where the hard drive is full and some files have been deleted. If the deleted files are smaller than the file that needs to be saved, and those deleted files were not physically located next to each other, then gaps have become unallocated, but no single gap is big enough for the file.
Imagine a drive with 8192 byte clusters. There are files smaller than 8192 bytes that have been saved onto the hard drive and it is now full. The user wishes to save a file that is 13,158 bytes. Two files have been deleted but they were not saved on the drive next to each other, so that there are 2 gaps that add up to more than the size of the file. That is, the file will require one full cluster of 8192, and then one partial cluster of 13,158-8192=4966 bytes required of the second cluster and 8192-4966=3266 bytes of slack space in the second cluster.
The myusbflag.dd file has been created by using a 128mb usb stick formatted to FAT16 with 8192 cluster sizes.
Then, 122 graphics of a minion, sized 5513 bytes, were dragged onto the usb stick. These were dragged one at a time until an error message was received that the disk was full.
The fsstat command provides some useful information about the file system
┌──(root㉿kali)-[~/Desktop]
└─# fsstat minionsflag.dd
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: FAT12
OEM Name: MSDOS5.0
Volume ID: 0x5674681e
Volume Label (Boot Sector): NO NAME
Volume Label (Root Directory): MYUSB
File System Type Label: FAT12
Sectors before file system: 0
File System Layout (in sectors)
Total Range: 0 - 2047
* Reserved: 0 - 5
** Boot Sector: 0
* FAT 0: 6 - 6
* FAT 1: 7 - 7
* Data Area: 8 - 2047
** Root Directory: 8 - 39
** Cluster Area: 40 - 2039
** Non-clustered: 2040 - 2047
METADATA INFORMATION
--------------------------------------------
Range: 2 - 32646
Root Directory: 2
CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 8192
Total Cluster Range: 2 - 126
FAT CONTENTS (in sectors)
--------------------------------------------
40-55 (16) -> EOF
56-71 (16) -> EOF
...The usb stick was then imaged to the Desktop as minions1mb.dd and it was truncated to 1000KiB (1,024,000 bytes). The first minion.jpg graphic begins at the data area at 0xB000 (45056) which is cluster 6. As this usb stick was only 1MB in size, the FAT area is reduced in size. 8 sectors and 5 full clusters are used for FAT information. The number of clusters available for files is therefore 1048576/8192= 128. Taking away the 6 clusters used by the file system leaves 122 available for the minion.jpg files.
The usb stick with the minions graphics.
The minions1mb.dd file has the first minion.jpg file located at 0xB000 (45,056).
Two minions.jpg files are then deleted. It is vital that these are not located physically next to each other, so 05 and 10 are chosen and deleted. Strangely, an additional file required deletion to fit the rybflag.bmp file of 13,158 bytes, so 15 was also deleted. The files were deleted in Windows and the rybflag.bmp file was dragged onto the usb stick in Windows.
The free space is shown as 0 bytes. It is now necessary to place a file on the ‘device’ but ensure it is fragmented. To do this, a file greater than one cluster is required. The file I chose is 13,158 bytes. Bigger than one cluster but smaller than 2 clusters. It will need two clusters.
The usb stick is imaged to 1,024 kibibytes (1048576 bytes). It is saved as minions1mb.dd to avoid any confusion over the size of the file.
The minions1mb.dd file can be mounted as a device using the losetup command. In this way, the file can be opened as if it was a usb stick. The loop device is a pseudo device that mounts the .dd file as if it were a device, meaning the file can be opened and the files on the device (minions.dd) viewed, saved or deleted.
losetup /dev/loop0 Desktop/minions1mb.dd
An icon for MYUSB appears on the Kali Desktop. Double clicking this icon opens the file and the minions icons can be viewed. Note that it is the name of the usb stick that is used to identify the file, not the name of the file.
The rybflag.bmp file is then deleted in Windows. The usb stick is imaged again and the image is called minionsflag.dd.
The 3 minion graphics that were not physically located next to each other were deleted. This left 3 gaps of 1 cluster each (8192 bytes each) on the drive. Two clusters is enough to fit the rybflag.bmp file. Blow is the hex of the bitmap file.
The usb stick was then imaged again and the file called minionsflag.dd. The BMP file is located at 0x1D000 (118,784) Cluster 15.
Note that there is a small amount of information in the header of the file and then the colour of the pixels begins at byte 55. This is E8A200 (yellow). The bmp file ends at 0x1F000 (126976).
126976-118784=8192.
The files are recovered with Foremost searching for bmp files only by using the -t bmp switch.
┌──(root㉿kali)-[~/Desktop]
└─# foremost -t bmp minionsflag.dd -o minions
Processing: minionsflag.dd
|*|
The first cluster of the bmp file is recovered only. This is because Foremost is not pointed to the second part of the file. We must locate this ourselves and ‘stitch’ the two parts of the file together.
Searching manually could take hours, but a simpler method is to search for the colour that the first part ended with. If we are very unlucky, the colour could change right at this point, but it is far more likely that the colour will continue for at least a small part of the second part. Note that it can be inferred that the bitmap is drawn from the bottom up, so the first part recovered is the end of the file.
The first part of the bmp recovered ends with F2 FF and the 00 is missing. Therefore, we need to search for 00 F2 FF.
This is located at 0x27000 (159,744) cluster 19.5. (19).
The next file we expect to find is a minion.jpg file, so we search for FF D8 FF E0 and find it at 0x29000 (167,936).
The BMP file has finished before this jpg file, so there is some drive slack space. The end of the bmp is found by paging up in the hex until the file is located.
Be careful that you don’t find the end of the deleted jpg file (FF D9) and use that instead. BMP files are uncompressed and finish with a pixel colour, so it is fairly obvious when you have found the end of the file.
The end of the file is at 0x28366 (164,710). As we know the start of the file location and the size of the file, we can check that this is the end. When the rybflag graphic of 13,158 bytes was dragged onto the usb stick it had to be fragmented into 2 parts with one full cluster utilized for the first part of the flag and one part cluster used for the remaining of the flag graphic.
164710-159744=4966.
Adding the first cluster located of 8192 give 4966+8192=13,158. This is the correct size, so we have found the end of the file.
We can now recover the 2 parts and stitch them together.
The process is to use dd:
1: Jump to the start of part 1 and carve 1 cluster (8192 bytes).
2: Jump to the start of part 2 and carve out 4966 bytes.
3: Use the cat command (concatenate) to stitch the 2 parts together.
NOTE: The cat command will take any number of parts and will send these parts to the file with the >.
┌──(root㉿kali)-[~/Desktop]
└─# dd if=minionsflag.dd of=graphicpart1.bmp bs=1 skip=118784 count=8192
8192+0 records in
8192+0 records out
8192 bytes (8.2 kB, 8.0 KiB) copied, 0.0259277 s, 316 kB/s
┌──(root㉿kali)-[~/Desktop]
└─# dd if=minionsflag.dd of=graphicpart2.bmp bs=1 skip=159744 count=4966
4966+0 records in
4966+0 records out
4966 bytes (5.0 kB, 4.8 KiB) copied, 0.0184278 s, 269 kB/s
┌──(root㉿kali)-[~/Desktop]
└─# cat graphicpart1.bmp graphicpart2.bmp > graphicwhole.bmp
