1

I am currently investigating a disk image with a FAT12 file system for data recovery purposes/researching for file carving. For this investigation, I have the actual files that need to be carved/recovered from the disk image so that I can validate my results obtained from the carving process/recovery.

During the comparison and analysis from the recovered files, I noticed that after exactly 2 clusters (each of size 16384 bytes/32 sectors) of file data there are 4 extra/embedded bytes. These repetitive and distinct 4 bytes that are being noticed after 2 clusters are not found in the corresponding actual files. I think that these bytes are used somehow by the file system, is this right? What is their purposes and how can be identified during the recovery process?

Hex dump:

Actual File that needs to be recovered from disk (hex between 2 clusters):

Offset      0  1  2  3  4  5  6  7   8  9 10 11 12 13 14 15

00016336   BC 55 B4 F8 A5 E1 69 82  2A DD 4A 5D DC 46 B9 80   ¼U´ø¥ái‚*ÝJ]ÜF¹€
00016352   E1 33 D3 F9 76 AE 8A 79  2E 22 0F 58 EE 67 FD AD   á3Óùv®Šy." Xîgý­
00016368   49 E9 7B 76 45 99 3E 25  69 36 F2 00 8B 71 70 C0   Ié{vE™>%i6ò ‹qpÀ
00016384   FC BB 6D 65 E9 DC F2 30  7E BD 6A B4 BF 17 52 0B   ü»meéÜò0~½j´¿ R 
00016400   64 9A 2D 13 58 B8 0E FB  13 65 9B 1E 87 93 F9 00   dš- X¸ û e› ‡“ù 
00016416   7F 11 55 4F 21 AD A7 3A  51 D7 B9 CF 3C DE 35 25    UO!­§:Q×¹Ï<Þ5%

Disk Image:

Offset      0  1  2  3  4  5  6  7   8  9 10 11 12 13 14 15

00132880   BC 55 B4 F8 A5 E1 69 82  2A DD 4A 5D DC 46 B9 80   ¼U´ø¥ái‚*ÝJ]ÜF¹€
00132896   E1 33 D3 F9 76 AE 8A 79  2E 22 0F 58 EE 67 FD AD   á3Óùv®Šy." Xîgý­
00132912   49 E9 7B 76 45 99 3E 25  69 36 F2 00 8B 71 70 C0   Ié{vE™>%i6ò ‹qpÀ
00132928   **08 B5 A9 88** FC BB 6D 65  E9 DC F2 30 7E BD 6A B4    µ©ˆü»meéÜò0~½j´
00132944   BF 17 52 0B 64 9A 2D 13  58 B8 0E FB 13 65 9B 1E   ¿ R dš- X¸ û e› 
00132960   87 93 F9 00 7F 11 55 4F  21 AD A7 3A 51 D7 B9 CF   ‡“ù  UO!­§:Q×¹Ï
00132976   3C DE 35 25                                        <Þ5%

From the above hex dump it can be visualized that 08 B5 A9 88 is exactly between the two clusters, however in the actual file those 4 bytes were eliminated.

brandbir
  • 305
  • 3
  • 14
  • FAT's allocation block is cluster. If file's size is less then a cluster size then you can observe unused "garbage" at the end of the cluster. Is this what you see? Without exact hex dump of your disk image it's difficult to provide anything useful. Keep in mind that there's **12bits** per FAT entry so to traverse correctly you need to do some bit-shifting arithmetic. See also http://wiki.osdev.org/FAT#FAT_12 – xmojmr Mar 13 '15 at 15:33
  • Yes, I agree perfectly with you; however in this case I don't think that the extra bytes are garbage, since the file is taking more than one cluster. The extra bytes are found between the 2 allocated clusters which can be visualized from the above description - refer to the updated description. – brandbir Mar 13 '15 at 16:23
  • There's no space allocated or used by the file system itself between clusters, nor are there some clusters made special. It's continuous area allocated to files or directories and the allocation map is stored in FAT (as far as I remember). It looks like the original file (some `EXE` or `COM` code?) was overwritten by a broken virus or by an encryptor interrupted in the middle. Just guessing. I'd try to view the disk with `Norton Disk Doctor` and probe http://reverseengineering.stackexchange.com site for some expertise – xmojmr Mar 13 '15 at 16:53
  • 1
    The original file/s are JPG images and the disk image was analyzed by autopsy (refer to http://www.sleuthkit.org/autopsy). This was able to overcome this problem, since the extra bytes are being eliminated and the JPG images are being successfully recovered. – brandbir Mar 13 '15 at 17:09
  • Great, I'll be of no more help here. If you already know the answer then post it as [self-answer](http://stackoverflow.com/help/self-answer) and earn some points. If you don't know then I'd try to use some stepping in the debugger as the `autopsy` seems to come with source code. It looks like the way to find out for sure - no guesswork – xmojmr Mar 13 '15 at 17:17
  • 1
    Honestly, I still do not have any clue about those embedded bytes between clusters. The main point of this question is to check whether the file system uses any embedded bytes between clusters, and if yes what do they represent since there is no any documentation that states that the file system uses any metadata in data region - Thank you for your help. – brandbir Mar 13 '15 at 17:35

1 Answers1

0

The extra 4 bytes that were being encountered between the two clusters were CRCs that were embedded by the Encase disk image file format for security purposes. You can refer to the following link for more detail.

brandbir
  • 305
  • 3
  • 14