4

A folder (not the disk itself) containing misc. things in my flash drive turned into a single USBC[]ÇNY file when I was running the Sublime Text app. It has no modified-date, nothing, looks like something corrupted and the file manager says it's both 3.42 GB and 0 GB large.

My question is now how can that happen? I rant disk-check (dskchk) and a tool like Recuva and yet nothing got back. The best I got is, thanks to dskchk, disrupt that file, but it just had a USBC... header with most content nulled, and were just 32 KB., meaning it had nothing! How could I at least avoid that to happen?

Before I tried dskchk and Recuva, I used WinRaR to open the USBC file and it said the file doesn't exist. I've tried renaming it too and it were still n't existing. Only the command prompt found it:

Yet more, that _Self folder just had a ascargo folder. That ascargo folder was open in Sublime Text (a workspace), so maybe that could be the issue?

Now I doubt I can really recover the content, but lucky it was just an experiment... I'd like to know how that happens.

1 Answers1

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. Oh, and it is not a virus, nor has it got anything to do with any virus.

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

enter image description here

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!

enter image description here

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.