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.
Edit Nov 2021: Quick recipe for correcting/patching the issue:
The observed shift only affects the number of sectors written by the command. To patch the drive or disk image
- Decode the USBC sector.
- Determine number of sectors the command was writing (n)(offset 22, WORD value, MSB first).
- Assuming n = 8, shift sector 2 – 8 (one based) up one LBA.
- Fill last sector in block with zeros.
So this:
USBC
SECTOR 2
SECTOR 3
SECTOR 4
SECTOR 5
SECTOR 6
SECTOR 7
SECTOR 8
becomes this:
SECTOR 1 (was 2)
SECTOR 2 (was 3)
SECTOR 3 …
SECTOR 4
SECTOR 5
SECTOR 6
SECTOR 7
ZERO FILLED SECTOR
‘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:
Two things:
- 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!
Sector shift?!
In my case it would decode to something like “write(2Ah) 16(10h) sectors starting to LBA 63(3Fh)”.
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.
I need to revise strike-through text:
Possible solutions
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.
RAW Scan
If however file system reconstruction is of no concern a sector aligned RAW scan should have no issues recovering files either.
A few months later (Sept 21, 2021)
I finally received a full disk image of an SD Card with the issue! I have done various experiments using different data recovery tools and finally manually patched the ‘USBC sectors’. I’ll document it later and I also intend to update the JpegDigger disk imager so it handles these USBC sectors while imaging. This way you can either image the drive directly or an image of the drive that would result in a disk image data can be recovered from.
I don’t know what happened to my original file, 106_0306 from my camera – because in a split second my pictures about 4 disappeared and this blank file it changed to -; USBCP└\r.
If it’s just pictures DMDE may recover them. Scan drive and look in RAW folder.
This usbc-sector-patcher worked for me, I recovered most of my Gopro videos using Testdisk just now.
I opened a few issues in the Github page. I had to add a break to stop the forever loop, and there’s a for loop that needs to start with 1 instead of 2. And I think the script modifies the original file also (backed up my copies), not only changing the Patched one. I don’t know enough python and enough github to fix the issues correctly in git.
I had an image with at least 7 USBC sectors. I only manipulated the first 30MB of a 32GB image, then did ‘dd’ with conv=notrunc option to copy only the initial part of the image. And the FAT32 image became alive in Testdisk!
Oh, very nice! If time permits I’ll test it again some USBC affected file systems I collected.
Hey Joep,
with your instructions I was able to patch my image and after writing it to the sd card and running chkdsk the card is readable again and so far everything works!
Thanks a lot!
Paul
My example has wrong endianess for LBA and TransferLength.
This should be correct:
Sector: 32768
Tag: A9455770
DTLen: 00000400
Flags: 00
Lun: 00
CDB Len: 0A
opCode: 2A
Flags: 00
LBA: 00008000
Group: 00
TransferLength: 0002
Control: 00
Me again…
Could it be that you mean move sectors down instead of up?
If I delete the USBC sector then move the number of sectors down and then add one empty sector to account for the USBC sector it makes more sense to me :)
So for example USBC is at sector 1000
I move 1001 to 1000
1002 to 1001
and after that I insert an empty sector
Is this correct?
Yes.
Hey,
thanks for the writeup.
I corrupted an SD card yesterday and have the exact same error.
Windows was telling me to format the drive so I tried replacing the FAT32 boot sector with the backup.
Now Windows sees the drive but with only one file with filename, you guessed it, USBCp¸ð¬…
This is a card from a Nintendo Switch so Image recovery doesn’t really help here do you see any chance in restoring the data or at least some of it?
Best Regards
Paul
Hello,
What’s the size of the card? Perhaps you could create a sector-by-sector disk image (see: https://youtu.be/skkOa0sTJvc) and share that with me? Perhaps I can repair the file system as I did with the other example. At least file recovery should be possible.
Hi Joep,
the file size is 128GB so it would take some time to upload but I can share it if you like.
I can also write a tool myself thats does the patching but could you elaborate on the points stated in the video:
1. Decode USBC sector, determine number of sectors (n): do you mean check the size of the write and divide the length by sectorsize?
2. Delete USBC sector: just skip it in the resulting image?
3. Insert dummy sector at (n-1) of current offset: I don’t get the calculation here.
Lets say I have a USBC sector at 0x00000000 and it writes 2 bytes to 0x00008000 I have one sector that needs replacing at 0x00008000?
Thank you!
Yeah, so most successful appears
– decode USBC sector > get number of sectors n
– remove USBC sector
– move n sectors one sector up (so they kinda cascade and fall in place of USBC sector
– insert stuff sector
assuming n = 8
USBC > +1
+1 > +2
+2 > +3
+3 > +4
+4 > +5
+5 > +6
+6 > +7
+7 > +8
+8 > 00000000000000000000
Hi,
sorry I still don’t get it…
This is the first sector with the USBC header:
Sector: 32768
Tag: A9455770
DTLen: 00000400
Flags: 00
Lun: 00
CDB Len: 0A
opCode: 2A
Flags: 00
LBA: 00800000
Group: 00
TransferLength: 0200
Control: 00
Could you explain with this example?
Sorry to bother you with this…
Thanks a lot.
Paul