This is a quick write up after some initial research into occurrence of sectors that start with the string USBC or 0x55534243. These are common cause for data loss and can be hard to recover from. I think I see why data recovery software is often unsuccessful as these sectors appear to be ‘inserted’ causing sector that follow to shift one LBA.
If these inserts happen near a boot sector or a inside directory entry they may be noticed quite easily. All of a sudden a file called USBC appears with erroneous file size while other files disappeared. In many online guides and forums the issue is mistaken for a virus, which it is most definitely not.
‘USBC’ file or sector
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:
- 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 (0x3F) while it is in fact at LBA 64.
- The USBC sector can be decoded as USB command block!
In my case it would decode to something like “write 16 (10h) sectors starting with LBA 63 (3Fh)” (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.
Can USBC sectors that go unnoticed explain unsolvable cases?
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.
Anecdote: In a recent case I was recovering JPEGs by doing a cluster aligned RAW (signature) scan. From some point my tool stopped detecting files although the entropy map revealed we were still reading data with JPEG like entropy. Of course JPEG like entropy can be result of other compressed data like video, but I was actually expecting more JPEGs. By taking a look with HxD it became cleat more JPEGs were out there, but for some reason their signature 0xFFD8FF now occurred at cluster boundary + 1 sector. Not being aware of this USBC sector shift issue I unfortunately never looked for USBC sectors. In hindsight an USBC sector would be a good explanation for it.
A data recovery technician should determine if sector shift can be observed. Solution may depend on where the USBC sector(s) is/are. If a single occurrence like in above screenshot the NTFS boot sector can be patched. If there are multiple USBC sectors, also in unallocated space for example any solution file recovery software computes for file system offset will be invalid after the USBC sector.
File recovery software
File recovery software could try to detect all ‘USBC’ sector and account for each sector shift. 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
Only one occurrence!
We can scan drive for number of occurrences. If limited to one then in above example we could patch the NTFS boot sector to update the value for hidden sectors from 63 to 64.
Probably simplest method..
An easier way of dealing with the issue I found is imaging the drive and simply skip all ‘USBC sectors’, all following sectors will automatically ‘shift back’. 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.
I’ll soon release a version JpegDigger with some provisional methods to detect USBC sectors and image drives affected by the issue.
If however file system reconstruction is of no concern a sector aligned RAW scan should have no issues recovering files either.
A few hours later…
Another idea.. What if only sectors shifted that the device was planning to write. Back to my hex dump at the start of the post, if we decode the USB command block we got:
“write 16 sectors starting with LBA 63” (2Ah is write command)
I can see how for some reason write fails, USBC command block is written to LBA 63, the rest of the buffer is dumped to next consecutive sectors. Perhaps last sector in buffer ‘drops’, perhaps it overwrites one sector. But shift does not continue throughout entire drive perhaps.
This would change how we need to handle these USBC blocks! We’d need to decode the command to see where it and how many sectors it intended to write.