Toshiba USB Drive

[Philip Shaw]

Good morning. I am working on a Toshiba 2.5" drive with a USB PCB. The drive had a head crash and has sustained some platter damage. Before changing the PCB to SATA I went through the PC3000 Toshiba USB option and I have read millions of sectors. The Catalog file and Journal both have some damage so I imaged them as best I could and then did a scan. I have a very nice folder structure with most of the folders and files the customer is looking for. Unfortunately, when I look at the files they are garbage. It is similar to when a drive has had a new operating system loaded and you can get some of the old folder structure but it is not pointing at the actual files. Any thoughts or suggestions?

Virus-free. www.avast.com

[jpv...@gmail.com]

What file system?

Are you aware of, or can scan for any sectors starting with 55 52 42 43 (ascii 'USBC')?

__________________________________
Sent from eM Client | www.emclient.com

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CAPG2Qkawjvwt6ckurVpERB1PQekHLQp25Xc5wiWOoHtAytyF-Q%40mail.gmail.com.

[jpv...@gmail.com]

Example

__________________________________
Sent from eM Client | www.emclient.com

[Philip Shaw]

It is HFS/HFS+. I haven't seen the hex characters you mentioned. What is their significance?

Virus-free. www.avast.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/em4ddcc9b8-ac19-4c7c-b4fc-0ed475a185e9%40alien.

[jpv...@gmail.com]

As you can tell from screenshot it appears they're 'inserted' causing the rest of that data to shift one sector >>. This will f*ck up all offsets in the file system, basically everything that follows it is corrupt or at least appears.

I do not know under what circumstances they exactly occur but they appear to be containing the contents of a USB command block. And since this was a USB drive I wanted to check. I have seen it a few times, trying to determine if it is in fact more common.

You can even decode the command block, so that my previous screenshot USBC block would mean something like "write 16 sectors starting with LBA 63". 2Ah is write command.

__________________________________
Sent from eM Client | www.emclient.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CAPG2Qkas-jrdM5Q-69BcSfsRNxahW4UcJWARTnXPbWWd-GmkSA%40mail.gmail.com.

[jpv...@gmail.com]

USB command block:

__________________________________
Sent from eM Client | www.emclient.com

[t...@desertdatarecovery.com]

Any ideas on how/why this sector would be added.

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

 

From: datarecovery...@googlegroups.com <datarecovery...@googlegroups.com> On Behalf Of jpv...@gmail.com
Sent: Thursday, June 10, 2021 7:33 AM
To: datarecovery...@googlegroups.com
Subject: Re[5]: Toshiba USB Drive

 

USB command block:

 

 

__________________________________
Sent from eM Client | www.emclient.com

 

On 6/10/2021 4:29:28 PM, jpv...@gmail.com wrote:

 

As you can tell from screenshot it appears they're 'inserted' causing the rest of that data to shift one sector >>. This will f*ck up all offsets in the file system, basically everything that follows it is corrupt or at least appears.

 

I do not know under what circumstances they exactly occur but they appear to be containing the contents of a USB command block. And since this was a USB drive I wanted to check. I have seen it a few times, trying to determine if it is in fact more common.

 

You can even decode the command block, so that my previous screenshot USBC block would mean something like "write 16 sectors starting with LBA 63". 2Ah is write command.

__________________________________
Sent from eM Client | www.emclient.com

 

On 6/10/2021 4:03:26 PM, "Philip Shaw" <shawcomput...@gmail.com> wrote:

 

It is HFS/HFS+. I haven't seen the hex characters you mentioned. What is their significance?

 

Virus-free. www.avast.com

 

On Thu, Jun 10, 2021 at 9:55 AM <jpv...@gmail.com> wrote:

Example

 

 

__________________________________
Sent from eM Client | www.emclient.com

 

On 6/10/2021 3:54:11 PM, jpv...@gmail.com wrote:

 

What file system?

 

Are you aware of, or can scan for any sectors starting with 55 52 42 43 (ascii 'USBC')?

 

__________________________________
Sent from eM Client | www.emclient.com

 

On 6/10/2021 3:38:22 PM, "Philip Shaw" <shawcomput...@gmail.com> wrote:

 

Good morning. I am working on a Toshiba 2.5" drive with a USB PCB. The drive had a head crash and has sustained some platter damage. Before changing the PCB to SATA I went through the PC3000 Toshiba USB option and I have read millions of sectors. The Catalog file and Journal both have some damage so I imaged them as best I could and then did a scan. I have a very nice folder structure with most of the folders and files the customer is looking for. Unfortunately, when I look at the files they are garbage. It is similar to when a drive has had a new operating system loaded and you can get some of the old folder structure but it is not pointing at the actual files. Any thoughts or suggestions?

 

Virus-free. www.avast.com

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CAPG2Qkawjvwt6ckurVpERB1PQekHLQp25Xc5wiWOoHtAytyF-Q%40mail.gmail.com.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/em4ddcc9b8-ac19-4c7c-b4fc-0ed475a185e9%40alien.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CAPG2Qkas-jrdM5Q-69BcSfsRNxahW4UcJWARTnXPbWWd-GmkSA%40mail.gmail.com.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/em77855c0a-f948-40f8-abe2-42aa1781c58c%40alien.

[jpv...@gmail.com]

Not really. I found this https://digitalcorpora.s3.amazonaws.com/corpora/drives/nps-2014-usb-non-deterministic/usb-non-deterministic-narrative.pdf

__________________________________
Sent from eM Client | www.emclient.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/005901d75e1b%247023c7c0%24506b5740%24%40desertdatarecovery.com.

[jpv...@gmail.com]

I have seen it before, but I never gave it much thought. The screenshot is a case a Portuguese lab is working on (USB harddrive), and I was asked to edit the disk using DMDE. During this I ran into the issue again on a USB flash drive. From the point the USBC was, everything following seemed to shift and so even cluster aligned raw scans yielded no result from that point onwards. Looking at the Portuguese case it then occurred to the NTFS boot sector had to be on LBA 63. If you decode the boot sector it "thinks" it's at LBA 63. So again a shift >>.

Seems to me easiest way to handle it is image the drive, and simply skip all USBC sectors.

__________________________________
Sent from eM Client | www.emclient.com

[t...@desertdatarecovery.com]

I wonder if this is flash drive specific? And the controller ignores the entry when reading data?

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/emd74b8e60-730a-4fcf-819d-f2463de427f4%40alien.

[jpv...@gmail.com]

No it's on USB hard drives too.

__________________________________
Sent from eM Client | www.emclient.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/007f01d75e23%24ce37f900%246aa7eb00%24%40desertdatarecovery.com.

[t...@desertdatarecovery.com]

If you image and skip the USB sectors wouldn’t the data still be misaligned? You are not skipping the sector you are just not reading it. Or am I not understanding your thought process?

 

I guess if there are not too many you can cut the image into regions and JBOD them.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/emcb823a53-0143-4ea5-a78d-d773e01b4b6d%40alien.

[Philip Shaw]

If I were to convert this drive to SATA is there any chance that could help with this problem?

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/009101d75e27%2424f7bcf0%246ee736d0%24%40desertdatarecovery.com.

[pbzcbf...@gmail.com]

I don't understand why inserting one or more sectors before the NTFS boot sector should make any difference. The cluster numbers in the file system are relative quantities, not absolute. Or am I having a brain fart?

[jpv...@gmail.com]

Well, in case of the example which is a real case it f*cks up file system. Maybe editing the bootsector itself would resolve the issue. I would need to check if we tried bit I think we did. But then, these sectors can be everywhere, so imagine the sector being in the data area, it would shift all data following. So to address a specific cluster we'd need to convert: offset file system + (cluster size * sect/clus) + n (where n is number of occurrences of a USBC sector before cluster).

Imaging:

LBA 0 -----------LBA 63 USBC - LBA 64 NTFS BS - LBA 65 - LBA 66 etc.

If I skip USBC sector all will be well, or am I missing something?

LBA 0 ------------ LBA 63 NTFS BS - LBA 64 - LBA 65 etc. so NTFS bootsector that was in LBA 64 automatically shifts <<

We simply omit extra sectors from image file.

- Joep

__________________________________
Sent from eM Client | www.emclient.com

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/acc82325-221b-47c9-9f47-3d6fa00de3f9n%40googlegroups.com.

[pbzcbf...@gmail.com]

I would think that data recovery tools would ignore the sector offset in the boot sector, otherwise how would they deal with an image of an NTFS volume? I suspect that Windows may ignore it, too.

In fact I just tried this with an internal drive. Changing the "hidden sectors" value from 63 to 64 did not prevent DMDE from seeing the file system. I also recovered a file without any resultant corruption.

[jpv...@gmail.com]

But Frank, TBH it's all over chat and we tried all sorts of stuff and my memory of what we tried is blurry. I think we tried

- Edit BS

- restore BBS (to LBA 63)

- Edit partition table to set NFS volume to start @ LBA 64

But like I said that would only address this 'inserted' sector. If such an USBC sector was inserted in data area then everything that follows is misaligned.

Anyway I have been waiting for an as-is image file for a while so I can see what's happening.

__________________________________
Sent from eM Client | www.emclient.com

On 6/10/2021 8:49:47 PM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/acc82325-221b-47c9-9f47-3d6fa00de3f9n%40googlegroups.com.

[jpv...@gmail.com]

__________________________________

Sent from eM Client | www.emclient.com

On 6/10/2021 9:19:32 PM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

I would think that data recovery tools would ignore the sector offset in the boot sector, otherwise how would they deal with an image of an NTFS volume? I suspect that Windows may ignore it, too.

Yes agreed, but what if there are additional USBC sectors?

In fact I just tried this with an internal drive. Changing the "hidden sectors" value from 63 to 64 did not prevent DMDE from seeing the file system. I also recovered a file without any resultant corruption.

We tried editing hidden sectors too, still corruption so I suspect to fund more USBC sectors once I have the image file. The boot sector I showed is only to illustrate what happens (the sector shift) because it's so obvious there. The USB flash drive I had from client had one in the 'data area', these are harder to spot other than noticing from a certain LBA everything is corrupt.

[pbzcbf...@gmail.com]

I just rebooted and Windows was still happy, so it would appear that the "hidden sectors" parameter is ignored.

[jpv...@gmail.com]

Again, this is not per se about hidden sectors in BS, it's just an illustration of a sector being inserted rather than it overwriting a sector.

__________________________________
Sent from eM Client | www.emclient.com

On 6/10/2021 9:28:45 PM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

I just rebooted and Windows was still happy, so it would appear that the "hidden sectors" parameter is ignored.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/db57de67-3621-46b6-a587-b342a9b4359en%40googlegroups.com.

[t...@desertdatarecovery.com]

I am still not understanding the shifts in data. So if this mysterious sector suddenly gets inserted at LBAx why does everything get shifted so data recovery software cannot find the data. It cannot insert the sector and suddenly every sector after gets shifted 1 sector. That’s physically not possible. So if the sectors is just overwriting a sector that just one file might be corrupt.

 

Still trying to get my head around it.

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

 

From: datarecovery...@googlegroups.com <datarecovery...@googlegroups.com> On Behalf Of jpv...@gmail.com
Sent: Thursday, June 10, 2021 12:27 PM
To: datarecovery...@googlegroups.com
Subject: Re[8]: Toshiba USB Drive

 

__________________________________

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/emaecfe912-4a24-4d63-8a22-143a428370a5%40alien.

[pbzcbf...@gmail.com]

Wouldn't that just mean that the OS wouldn't see the partition table or boot sector, or whatever metadata are supposed to be in sector 0? So that would mean that the OS wouldn't be able to find a file system, in which case the possibility of file system corruption would be moot???

[jpv...@gmail.com]

I am still not understanding the shifts in data. So if this mysterious sector suddenly gets inserted at LBAx why does everything get shifted so data recovery software cannot find the data. It cannot insert the sector and suddenly every sector after gets shifted 1 sector. That’s physically not possible. So if the sectors is just overwriting a sector that just one file might be corrupt.

It's what I saw in this case (screenshot) where NTFS boot sector is shifted from LBA 63 to LBA 64 while USBC sector now occupies LBA 63.

It's what I saw on a flash drive where every cluster boundary was one sector off after a USBC sector.

Sounds like a translator thing maybe?

 

Still trying to get my head around it.

Yeah and me.

[pbzcbf...@gmail.com]

Ah, OK, that would make sense then.

[t...@desertdatarecovery.com]

A translator issue would definitely explain that in a flash drive.

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

 

From: datarecovery...@googlegroups.com <datarecovery...@googlegroups.com> On Behalf Of jpv...@gmail.com
Sent: Thursday, June 10, 2021 12:34 PM
To: datarecovery...@googlegroups.com

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/emfcd70a6d-1b07-4202-bf4c-e26f5bd9e094%40alien.

[jpv...@gmail.com]

On 6/10/2021 9:32:09 PM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

Wouldn't that just mean that the OS wouldn't see the partition table or boot sector, or whatever metadata are supposed to be in sector 0? So that would mean that the OS wouldn't be able to find a file system, in which case the possibility of file system corruption would be moot???

I don't understand what you're asking.

Let's try:

Suppose BS is okay so we have offset, pointer to first cluster of MFT etc.. Now IN BETWEEN shift is introduced, or maybe even after MFT. Then all cluster references will be off one sector, no?

[jpv...@gmail.com]

A translator issue would definitely explain that in a flash drive.

Good one! Let me check if the USB harddrive is an SMR drive.

[t...@desertdatarecovery.com]

Yes I guess it could happen on an SMR drive. But not sure how a USB generated sector gets mixed in to the secondary translator but stranger things have happened..   

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

 

From: datarecovery...@googlegroups.com <datarecovery...@googlegroups.com> On Behalf Of jpv...@gmail.com
Sent: Thursday, June 10, 2021 12:40 PM
To: datarecovery...@googlegroups.com

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/em121f33a6-3053-40ea-9482-c18ad4b8560a%40alien.

[pbzcbf...@gmail.com]

I was unaware that there were additional "insertions". I was of the impression that the only insertion was at the start. It all makes sense now.

[jpv...@gmail.com]

On 6/10/2021 9:46:42 PM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

I was unaware that there were additional "insertions". I was of the impression that the only insertion was at the start. It all makes sense now.

Or maybe I wasn't clear.

Just found this:

"But there were also signatures of office documents (Word, Excel, PowerPoint). The standard approach for parsing a flash drive dump yielded two dozen working documents, although there were an order of magnitude more signatures themselves. It was decided to exclude uninformative sectors from consideration. This approach made it possible to recover about 400 documents, which, as further analysis showed, was the maximum result.

Conclusion: The appearance of USBC sectors may indicate problems with the device, as well as cause offsets in the data area. When recovering, it is recommended to carry out additional analysis and take into account the displacements (shifts) that they cause."

URL: https://512byte.ua/articles/usbc-na-fleshke.html

It's a translation but he may be hinting at the same thing. I am going to email him to see if he remembers.

[DiskTuna]

But yes, I think you're right and IF it only occurs at sector 63 (shift > 64) and nowhere else then file system would still be aligned. 

[DiskTuna]

And:

"Work-around for a certain type of data corruption that appears to happen frequently using certain USB card readers (internal and external). Symptoms are the sudden loss of files and or partitions etc. Usually in combination with FAT. Remaining files and/or folders may get names such as "USBC◘╧è◘" or "USBC..". Possibly related to ADATA NH92 adaptors though that is not certain! After researching the issue online it seems a lot of people think this is a virus. I see mention of the "USBC virus" and "USBC malware", yet it's not. It's a hardware / firmware failure that happened while data was being written to the SD card. IsoBuster is now able to detect and compensate for such issues on the fly so that files and folders can still be found and extracted"

Author of ISOBuster wrote this. Still kind of vague, but may be same issue.

[pbzcbf...@gmail.com]

IsoBuster's author refers to SD cards, but he also refers to an "ADATA NH92 adaptor". AFAICT ADATA's NH92 is an external 2.5" HDD. If we are theorising that the USBC sectors are due to a translator fault, then how likely is it that the same fault appears in two different firmware platforms?

[jpv...@gmail.com]

I have no idea Frank. I get the idea he also has only seen tip of the iceberg.

My thought is, suppose this 'USBC sector' occurs in MBR or boot sector or in sector where FAT directory is supposed to be, then it might get noticed. It wouldn't surprise me if a lot of these are missed because they're just at some random sector and cause some unexplained file system corruption. I don't mean to say it happens all over the place, but IF unexplained file system corruption occurs it may be an option to consider. 

__________________________________
Sent from eM Client | www.emclient.com

On 6/11/2021 7:26:14 AM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

IsoBuster's author refers to SD cards, but he also refers to an "ADATA NH92 adaptor". AFAICT ADATA's NH92 is an external 2.5" HDD. If we are theorising that the USBC sectors are due to a translator fault, then how likely is it that the same fault appears in two different firmware platforms?

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---

You received this message because you are subscribed to a topic in the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/datarecoverycertification/TY9PaD_hNqU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/a3b6fa3e-d7b4-418e-bc2a-0479824607e2n%40googlegroups.com.

[$300 Data Recovery]

Did you clear glist on the Toshiba drive? If so, did you try reverting to original? If not, did you try? Are you reading normally or doing "utility read?" Does it make a difference? If nothing works, you can fix shifts in DE using Virtual Translator option.

[pbzcbf...@gmail.com]

If this "USBC" sector shift happens in USB HDDs, then it must be the bridge firmware which is writing these sectors to the hard drive. The hard drive wouldn't see the USB commands. This would then exclude the possibility of a translator issue.

SD cards would be different because the controller is in direct control of the translator.

[DiskTuna]

I finally got one!!!

https://youtu.be/xfhu96N5JR4

[pbzcbf...@gmail.com]

Nice work.

[pbzcbf...@gmail.com]

Would you mind uploading one of these USBC groups?

[Desert Data Recovery]

Great work Joep. 

On Sun, Sep 19, 2021, 5:16 PM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

Would you mind uploading one of these USBC groups?

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---

You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.

To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/cd08abe9-c534-4c98-a21a-9d760f4278fen%40googlegroups.com.

[jpv...@gmail.com]

You mean one of those USBC sectors + bunch of trailing sectors?

https://drive.google.com/file/d/1dVJmbvF6WtjMLJWa1uP6WtV0Ryr9qf5x/view?usp=sharing

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---

You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.

To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/cd08abe9-c534-4c98-a21a-9d760f4278fen%40googlegroups.com.

[jpv...@gmail.com]

Although what I did worked, it may yet be even different... I start counting from actual sector offset. One may need to actually take the value from USBC command block and use LBA you get from that to base calculations on.

[jpv...@gmail.com]

I can even mount the patched image and browse/copy all folders/files

[pbzcbf...@gmail.com]

Thanks.

Am I right in assuming that the stuff that follows the CDB, up to the end of the sector, is just noise?

[jpv...@gmail.com]

What's CDB?

------ Original Message ------

From: "pbzcbf...@gmail.com" <pbzcbf...@gmail.com>

To: "DataRecoveryCertification" <datarecovery...@googlegroups.com>

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/35f8ab33-dac6-46ae-a3f3-7ba91c93fafbn%40googlegroups.com.

[pbzcbf...@gmail.com]

You refer to it in your own blog:

https://www.disktuna.com/sudden-appearance-of-usbc-named-folder-and-files/

CDB = SCSI Command Descriptor Block

https://en.wikipedia.org/wiki/SCSI_CDB

[jpv...@gmail.com]

Ahhhh, yes lol.

See: https://digitalcorpora.s3.amazonaws.com/corpora/drives/nps-2014-usb-non-deterministic/usb-non-deterministic-narrative.pdf

------ Original Message ------

From: "pbzcbf...@gmail.com" <pbzcbf...@gmail.com>

To: "DataRecoveryCertification" <datarecovery...@googlegroups.com>

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/c13d28e5-7101-42d5-8479-b7a7a54120c1n%40googlegroups.com.

[pbzcbf...@gmail.com]

I can see how a non-deterministic sector could replace the real sector in the image of the drive, but I can't see how this would result in an offset. If it supports SCSI UNMAP, I would TRIM the entire flash device and then see if every sector becomes  non-deterministic.

[Skyclad]

I am exhuming this thread because I have the same problem. I did the conversion from USB to SATA. 

APFS file system with only 59MB file catalogues with over 3TB of data, at least that's what DE told me. 

Cloned catalog file with only a few hundred KB with errors. Scanned catalog file and obtained structure with the folders the customer was looking for. 

Cloned the priority folder (500GB) with active utility at 3-4MB/s that the customer wanted. Unfortunately, an initial check showed that the files (photos) were corrupted, even though the map displayed that all sectors of these checked files had been cloned. 

Now it's a big mess because cloning those 500GB took almost 2 days and I have to do the same thing with another folder that has a capacity of 900GB.

[Eastcoast Data Recovery]

Not sure if it's related, but I've had this before when using Utility.  I don't trust it on Toshiba drives.  I would go back and start a new task but not use utility and sample for integrity an image that you just checked as corrupted in your current task.

If it's good, then you might have to start the task again but this time use standard access (no utility).  

[Skyclad]

In fact that is what I am doing. Unfortunately the drive has problems with the surfaces especially the 0 and I had already started a task using UDMA or HW retries for the image but the read was too unstable with frequent power cycling. 

But a 59MB catalogue file for a data volume of more than 3TB seems a bit small to me. 

I suspect the user "succumbed" to the operating system's request to format the drive as Windows does when there are physical problems.

[Eastcoast Data Recovery]

Yes, APFS is usually massive but if it's data only and if it was videos, it might be possible.  Anyway, best of luck..

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/71d315b9-24ba-41e6-9e8e-01cd44fcd2ffn%40googlegroups.com.

[t...@desertdatarecovery.com]

Totally agree with this reply. The ‘The read by active PC-3000 utility’ in DE is not means to work with Toshiba Drives, it will give you corrupt data. You have no choice but to start the recovery again.

 

Read the bottom of this blog.

https://blog.acelab.eu.com/pc-3000-for-hdd-active-utility.html

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

 

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/8a82336e-1bb9-4bce-8cc4-5d4b3684f8c0n%40googlegroups.com.

[Skyclad]

I have been successful with active utility in other cases of Toshiba drives, but this one is a MQ04UBB400. 

A long time ago in one case I had gotten all garbage in the files and ACE told me it was because I had switched from UDMA, HW retries, to Active Utility without giving a power OFF-power ON. 

With this case I had selected Active Utility because I was not getting head mapping with HDD-access but only with PBA access (solve G-list damage) and the reading, although very slow, (I had selected PIO mode) was smoother. 

I will redo the recovery from scratch and let you know. Yes Tim I had seen that article in the blog, thank you, like this also https://blog.acelab.eu.com/2045.html