My folder turned into a 'USB***' file

Solution 1:

I have seen this on multiple occasions and have been looking for a solution for years. I think I have one now. If you actually look at the USBC sector you'll find you can decode it as a USB command block. And also that these sector cause following sectors to shift.

Here's an example I have which is interesting for more than one reason, which I will explain in a minute:

Two things:

1. We see the USBC sector plus an NTFS boot sector. If we decode the NTFS boot sector you'll learn that it 'thinks' it is at LBA 63 while it is in fact at LBA 64.

2. The USBC sector can be decoded as USB command block!

In my case it would decode to something like "write 16 sectors starting with LBA 63" (2Ah is write command).

So, my analysis is, for some reason (no idea really) the USB command block ends up being written to the drive, but more importantly, it 'shifts' data following it by one LBA sector. So the USBC sector is inserted rather than overwriting a sector.

On this same drive I found several other 'USBC' sectors that all resulted in sector shift. If these occur in visible places, like in my example very close to the boot sector or in OP example in a directory we actually notice then. However these sectors may also occur inside user data (we only would discover it by opening the file in a hex editor) or perhaps in unallocated disk space. I guess USBC cases, sometimes it's assumed they're result of a virus, we can find on the internet, may be a tip of the iceberg. Perhaps some cases that are deemed unrecoverable are in fact caused by this very issue.

These shifts have consequences depending on where they occur as in a file system data is addressed by cluster numbers versus a certain offset. This explains why the file system fails, but also why file recovery software fails. Both fail for the exact same reason. To properly address clusters we need to take the shifts into account:

n = number of USBC sectors inserted prior to current cluster. fs_ofs = file system offset (LBA address) cl_factor = sectors per cluster

Cluster to LBA conversion should be LBA = fs_ofs + (cluster * cl_factor) + n

An easier way of dealing with the issue I found is imaging the drive and simply skip all 'USBC sectors'. Advantage of that is that all file recovery software that is capable of working with dd type disk images can be used to recover data.