Help with data recovery on voice recorder microSD

[pauloa...@gmail.com]

Hello friends, I hope everyone is well and safe!

I come here to ask for help in a case that is being challenging. I received a 16GB memory card microSD from a customer that worked on a voice recorder. I don't have the model of the recorder, I just received the memory card. The customer says he made only a single voice recording and then deleted it on the device itself. His objective is to recover this deleted recording.

I clone all memory card without errors and analyzing through WinHex I see that it is 80% filled with "zeros" and the rest apparently contains data.

When opening the image file in R-Studio, I see that it identifies a partition started in sector 8192 (4MB) of type AIX (0x8).

I scanned and also searched for RAW data with the following software (all in their latest versions): R-Studio, Reclaime Pro, UFS Pro, DMDE pro, Winhex and Data extractor (PC3K).

The only software that recovered data was Reclaime Pro. It recovered 2 PCX files: 1 with 4096MB and the other with 382MB (would that be the recording?). Now I don't know what to do to know if they are really audio files. Do you have any experience with data recovery on voice recorders? Can you help me with some software to try to recover more data from the image or some software to evaluate these PCX files recovered by Reclaime Pro?

Thanks for any help! 

[t...@desertdatarecovery.com]

Most voice recorders use proprietary codecs to record the data, so they are not the type of files that can be scanned for or even played outside of the recorder. Can I suggest you contact the client to find out more information about which VR it was, then contact the manufacturers support line to see if the data is actually playable and what file extension it may have (if any). I think the PCX file you have maybe just a false file.

 

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/9f2a1e04-e63b-4715-a13f-b884a8374a91n%40googlegroups.com.

[Paulo Braga]

Thanks for reply Tim! I will ask for more information with the client and contact the manufacturer. 

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/001801d720ce%24345e3520%249d1a9f60%24%40desertdatarecovery.com.

[pbzcbf...@gmail.com]

Can you show us a hex dump of sector 8192?

My approach would be to take a new, blank 16GB card and make a short recording. Then make an image of the card.

Reinstall the card and delete this recording. Then make another image. Compare the two images and look for "flipped" bytes.

Reinstall the card and add a second recording. Make another image.

Then take a blank card and make two recordings, and image the card after each recording, without deleting any recording.

This will tell you how the data are structured. Perhaps you'll be lucky and find that only a few bytes need to be "flipped" to undelete the file.

[wayne horner]

if you have access to the recorder

you could try fooling it.

new blank card

make a long recording

find recording

find similar data on damaged card

paste data over good recording

try to play in recorder.

Alandata Data Recovery -  (949)287-3282  
"Cleanroom Data Recovery of RAID, VMware, Network Attached Storage, Linux, Tape, Disk, Forensics"

www.AlanData.com   www.AlanDataRecovery.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/3418d43e-2985-4e92-8592-3510c8e8cbf8n%40googlegroups.com.

[pbzcbf...@gmail.com]

It would be good to format a blank card and image it before adding a recording. That should tell us what the file system metadata look like.

[pbzcbf...@gmail.com]

FWIW, the maximum file size for FAT32 is 4GiB, so maybe the recorder's file system is similarly affected. That is, long recordings may be divided into 4GiB chunks.

[Paulo Braga]

Hello friends!

Thank you very much for the incredible responses, they are really great ideas.

Today I was talking to my client and it is really impossible to have access to the voice recorder, so now it is much more complicated.

I send attached the sector 8192 dump that our friend requested.

I really believe that it is a proprietary and unknown format.

Again I would like to thank you, you are incredible.

Em qua., 24 de mar. de 2021 às 20:21, pbzcbf...@gmail.com <pbzcbf...@gmail.com> escreveu:

FWIW, the maximum file size for FAT32 is 4GiB, so maybe the recorder's file system is similarly affected. That is, long recordings may be divided into 4GiB chunks.

--
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/cd5d4ab5-5d69-40ed-9a30-5419e8c5f074n%40googlegroups.com.

[pbzcbf...@gmail.com]

Can you show us the headers and footers of the two "PCX" files?

Let's assume that these two files were correctly extracted. If you now zero fill the areas occupied by these files, you should be left with the file system metadata. If you could upload these metadata, someone may be able to offer further suggestions.

[Paulo Braga]

Hello, good day and thanks for your reply. 

Follow attached the first 1kb from "PCX" files recovered. 

Thanks!

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/VshfKZ--t5A/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/391ec26f-c43a-4897-9835-24b549f37c55n%40googlegroups.com.

[jpv...@gmail.com]

Look like false positives to me

__________________________________
Sent from eM Client | www.emclient.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CANBOQm6jfnMRWB1qLNC4nS5feCehwfGkH%2BVbHDETXaswuSYJBA%40mail.gmail.com.

[jpv...@gmail.com]

and he doesn't even know brand/type of the recorder?

__________________________________
Sent from eM Client | www.emclient.com

[wayne horner]

there are some similarities in the starts of the file

0A 0X 01 01 

Alandata Data Recovery -  (949)287-3282  
"Cleanroom Data Recovery of RAID, VMware, Network Attached Storage, Linux, Tape, Disk, Forensics"

www.AlanData.com   www.AlanDataRecovery.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/em5ce1a7d9-8ed8-4bf3-8e29-b904ee27d959%40alien.

[pbzcbf...@gmail.com]

I can see why the files were detected as PCX:

https://git.cgsecurity.org/cgit/testdisk/tree/src/file_pcx.c

I can't see how the file sizes were determined, though.

[Paulo Braga]

Hi all!

 I talk with client and Voice recorder is:

Olympus WS-811

Thanks guys!

--
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/VshfKZ--t5A/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/e329e364-3959-48a9-8128-0fd5d9a9e0ban%40googlegroups.com.

[pbzcbf...@gmail.com]

Here is a used recorder for 15 GBP:

https://www.ebay.ca/itm/Olympus-WS-811-Voice-Recorder-Dictation-Built-in-USB-2GB-514-hrs-Req-only-1-AAA/254896523672

[jpv...@gmail.com]

Exactly, hence the false positives.

__________________________________
Sent from eM Client | www.emclient.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CAJEn65podkwo36aAxBWL5hOkg%2B05jetkPjerU6YB2rTwn2Di%3DA%40mail.gmail.com.

[jpv...@gmail.com]

It appears to have 2 GB internal memory too.

Organized in 5 folder, 200 files per folder I see somewhere. Can't see if this regards sdcard or internal memory. Format WMA or MP3. What software did you scan the card with and can you check if it raw scanned for WMA and MP3?

__________________________________
Sent from eM Client | www.emclient.com

On 3/26/2021 7:58:25 PM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

Here is a used recorder for 15 GBP:

https://www.ebay.ca/itm/Olympus-WS-811-Voice-Recorder-Dictation-Built-in-USB-2GB-514-hrs-Req-only-1-AAA/254896523672

--
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/14018eaa-7b91-46f2-b712-a749fffab9f2n%40googlegroups.com.

[pbzcbf...@gmail.com]

"I scanned and also searched for RAW data with the following software (all in their latest versions): R-Studio, Reclaime Pro, UFS Pro, DMDE pro, Winhex and Data extractor (PC3K).

The only software that recovered data was Reclaime Pro. It recovered 2 PCX files: 1 with 4096MB and the other with 382MB ."

[jpv...@gmail.com]

You're right Frank, I forgot.

__________________________________
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/c4e007f8-3308-4bfe-934d-82762f26b91en%40googlegroups.com.

[jpv...@gmail.com]

Yeah so for example R-Studio does scan for both WMA and MP3 by default. So then these types not being detected is discouraging. Even so, I have been able to make 'header-less' audio play in a similar scenario using the header of a known good file created with the same device. But in this case it appears anything that could make life easier is lacking. Did a quick Google search to see if I could locate reviews with sample files, it's what I some times do for photos from which I do not have a reference file, but no luck so far.

FWIW, manual of device suggests it either saves to internal memory or sd card. If client indeed opted for the sd card it's not like it's first buffered to internal memory.

__________________________________
Sent from eM Client | www.emclient.com

[pbzcbf...@gmail.com]

What I don't understand is why Windows can see a file system on the recorder without any additional software. This would suggest to me that the recorder is "translating" its own file system into one that Windows understands. Does this make any sense?

[jpv...@gmail.com]

I guess it is weird. And I read max file size is 4 GB so why use proprietary file system in the first place?

And in between the 4 MB 'boot sector' and MBR all zeros? I suppose sharing full disk image is out of the question, sure could help .. Frank has been able to figure out weird file systems before, just saying.

__________________________________
Sent from eM Client | www.emclient.com

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

What I don't understand is why Windows can see a file system on the recorder without any additional software. This would suggest to me that the recorder is "translating" its own file system into one that Windows understands. Does this make any sense?

--
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/9fceca4a-9f02-45a4-8fc6-471dd475d708n%40googlegroups.com.

[Alandata Recovery]

he says its 80% zeros

so it will compress to really 2gb

you could share 

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/em70b05628-d6a5-4a83-8422-b7435f905de3%40alien.

--

Alandata Data Recovery -  (949)287-3282  

"Cleanroom Data Recovery of RAID, VMware, NAS, Linux, Tape, Disk, Forensics"

www.alandata.com   www.alandataRecovery.com

[Paulo Braga]

Once again I thank you for your help. My client is one of those hurried and I believe that the purchase of this recorder abroad would be very delayed. I am in Brazil and this can simply take months of waiting (mainly in this pandemic season). 

I can share the full image, it was 850MB compressed. 

How do you advise me to share?

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CAH-%2BjWRyvvXs2yjkk0vCWqraz3%3DvTgTpspf-EUF9NotAVM%3DVSQ%40mail.gmail.com.

[jpv...@gmail.com]

Google Drive for example.

I advise not to share for the whole world as it is client data.

__________________________________
Sent from eM Client | www.emclient.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CANBOQm6EN%2BGeN3PJF0gyxLmmTw%2Bc1_F0rr-mSEGWVa4cam3OAg%40mail.gmail.com.

[Markus Bauer]

As that thing has 2GB internal memory - did you try to recover from the internal memory?

Many clients don't know where they store there stuff on the PC so I don't belive that the client know this in that case.

[Paulo Braga]

Hi! Thank you for suggesting to check the recorder, but the customer no longer owns it.

I will put the link of the image here and whoever can help me, I ask to ask for the password of the file directly to me by email.

Thanks for everything so far. Even if I am unable to recover this data, I am already grateful for such a good community.

Link to full image: https://we.tl/t-VZ1RIQFs6Y

Thanks

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/VshfKZ--t5A/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/794ed755-e1e1-4fbf-9efd-600758dacd7an%40googlegroups.com.

[Markus Bauer]

Whatever the tool is recognizing but the data tell a different story:

SECTORS TOTAL:        30679040

SECTORS with 0x00:    28347131 (92.40%)

SECTORS with 0xFF:           0 (0.00%)

By looking at the file in hex I found out the following:

• There is just one solis junk of data and that junk is 1.1GB in size but I could not find any file-markers for MP3 not WAV - not even within the data apart from sector beginning.
• The MBR has a strange marker 11AA instead of 55AA. 
• The partition start at sector 8192 and there are 3 sectors mainly empty but all have 11AA in the last 2 bytes, followed by 3 epmty sectors and then again 3 sectors with 11AA in the end.

Apart from something looking like a "header section" in the first 3 sectors the data look quite random - does anyone know a file-marker starting with 09 00 33? Could that be some kind of encryption?

[Desert Data Recovery]

When I spoke to Olympus support in Japan about the one I had. They said they use proprietary codecs and have created an audio file around those codecs. The codecs cover things like voice enhancement, noise cancelling etc. So these files do not have any of the normal structure of audio files. At least that was the case with the one I had. They said they cannot be played outside of an Olympus recorder. I know this case is little different as the VR has a MSD card, but I think it's still an uphill battle. 

Tim

Desert Data Recovery 

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/42838aa1-a32f-4019-8e48-b4f63ab46df3n%40googlegroups.com.

[Markus Bauer]

According to the manual you can connect the recorder and copy the files: https://manualsbrain.com/en/manuals/1196481/?page=81

So my guess would be more that they use some kind of porp. FS or container which get by the device translated. Maybe via MTP or something like that.

[jpv...@gmail.com]

09 00 33

Indeed there's a few of those at offset 0 within sector.

__________________________________
Sent from eM Client | www.emclient.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/42838aa1-a32f-4019-8e48-b4f63ab46df3n%40googlegroups.com.

[Markus Bauer]

Look at Sector 17856 and the following. That's the start of the data junk...

[pbzcbf...@gmail.com]

This looks like a directory. I suspect that "811.nnnn" are file names. I also suspect that the leading character changes from "8" to 0xA1 when the file is deleted.

Offset(h)  00   02   04   06   08   0A   0C   0E

000818000  2A20 2020 2020 2020 2020 2010 0000 0800  *          .....

000818010  1800 1800 0000 0800 1800 0100 0000 0000  ................

000818020  2A2A 2020 2020 2020 2020 2010 0000 0800  **         .....

000818030  1800 1800 0000 0800 1800 0000 0000 0000  ................

000818040  0B08 1909 081B 1002 0001 1022 0000 0800  ..........."....

000818050  1800 3912 0000 0800 1800 0A00 0008 0000  ..9.............

000818060  1008 0119 1B12 1309 0001 1022 0000 0800  ..........."....

000818070  1800 3912 0000 0800 1800 0B00 3000 0000  ..9.........0...

000818080  3831 311B 3031 3839 0910 3320 0000 A019  811.0189..3 .. .

000818090  980A 3912 0000 A019 980A 1200 B233 2302  ˜.9... .˜...²3#.

0008180A0  3831 311B 3032 3031 0910 3320 0000 1319  811.0201..3 ....

0008180B0  1809 3912 0000 1319 1809 320A 0021 2900  ..9.......2..!).

0008180C0  3831 311B 3031 3930 0910 3320 0000 0920  811.0190..3 ... 

0008180D0  830B 3912 0000 0920 830B 1003 0001 9301  ƒ.9.... ƒ.....“.

0008180E0  3831 311B 3031 3931 0910 3320 0000 110A  811.0191..3 ....

0008180F0  880B 3912 0000 110A 880B 8A28 9239 3A00  ˆ.9.....ˆ.Š(’9:.

000818100  3831 311B 3032 3032 0910 3320 0000 0A22  811.0202..3 ..."

000818110  3309 3912 0000 0A22 3309 910A A20A 8800  3.9...."3.‘.¢.ˆ.

000818120  A131 311B 3032 3032 0910 3320 0000 AB30  ¡11.0202..3 ..«0

000818130  3909 3909 0000 AB30 3909 9203 2892 0000  9.9...«09.’.(’..

000818140  3831 311B 3031 3939 0910 3320 0000 323A  811.0199..3 ..2:

000818150  1109 3912 0000 323A 1109 A93A 1A30 9001  ..9...2:..©:.0..

000818160  A131 311B 3032 3031 0910 3320 0000 232B  ¡11.0201..3 ..#+

000818170  3909 3909 0000 232B 3909 9103 0838 0000  9.9...#+9.‘..8..

000818180  A131 311B 3031 3233 0910 3320 0000 8398  ¡11.0123..3 ..ƒ˜

000818190  0303 0303 0000 8398 0303 9A1B 9888 0000  ......ƒ˜..š.˜ˆ..

0008181A0  A131 311B 3031 3238 0910 3320 0000 9198  ¡11.0128..3 ..‘˜

0008181B0  0303 0303 0000 9198 0303 A01B 88AB 9B01  ......‘˜.. .ˆ«›.

0008181C0  A131 311B 3030 3831 0910 3320 0000 A098  ¡11.0081..3 .. ˜

0008181D0  8200 8200 0000 A098 8200 8B1B 82B9 2200  ‚.‚... ˜‚.‹.‚¹".

[pbzcbf...@gmail.com]

Is the root directory?

Offset(h)  00   02   04   06   08   0A   0C   0E

000808000  2A20 2020 2020 2020 2020 2010 0000 0800  *          .....

000808010  1800 1800 0000 0800 1800 0300 0000 0000  ................

000808020  2A2A 2020 2020 2020 2020 2010 0000 0800  **         .....

000808030  1800 1800 0000 0800 1800 0000 0000 0000  ................

000808040  0208 001B 0A01 0901 0001 1022 0000 0800  ..........."....

000808050  1800 1800 0000 0800 1800 0800 0002 0000  ................

000808060  1201 030B 1201 1219 0001 1022 0000 0800  ..........."....

000808070  1800 1800 0000 0800 1800 0900 0002 0000  ................

[pbzcbf...@gmail.com]

Another one:

Offset(h)  00   02   04   06   08   0A   0C   0E

000810000  2A20 2020 2020 2020 2020 2010 0000 0800  *          .....

000810010  1800 1800 0000 0800 1800 0000 0000 0000  ................

000810020  2A2A 2020 2020 2020 2020 2010 0000 0800  **         .....

000810030  1800 1800 0000 0800 1800 0000 0000 0000  ................

000810040  020B 0800 0112 1B01 2020 2010 0000 0800  ........   .....

000810050  1800 1800 0000 0800 1800 0100 0000 0000  ................

000810060  020B 0800 0112 1B02 2020 2010 0000 0800  ........   .....

000810070  1800 1800 0000 0800 1800 0200 0000 0000  ................

000810080  020B 0800 0112 1B03 2020 2010 0000 0800  ........   .....

000810090  1800 1800 0000 0800 1800 0300 0000 0000  ................

0008100A0  020B 0800 0112 1B00 2020 2010 0000 0800  ........   .....

0008100B0  1800 1800 0000 0800 1800 0800 0000 0000  ................

0008100C0  020B 0800 0112 1B01 2020 2010 0000 0800  ........   .....

0008100D0  1800 1800 0000 0800 1800 0900 0000 0000  ................

... and another ...

Offset(h)  00   02   04   06   08   0A   0C   0E

000820000  2A20 2020 2020 2020 2020 2010 0000 0800  *          .....

000820010  1800 1800 0000 0800 1800 0200 0000 0000  ................

000820020  2A2A 2020 2020 2020 2020 2010 0000 0800  **         .....

000820030  1800 1800 0000 0800 1800 0000 0000 0000  ................

000820040  0B08 1909 081B 1002 0001 1022 0000 0800  ..........."....

000820050  1800 3912 0000 0800 1800 1000 0008 0000  ..9.............

000820060  1008 0119 1B12 1309 0001 1022 0000 0800  ..........."....

000820070  1800 3912 0000 0800 1800 1100 3000 0000  ..9.........0...

000820080  3831 311B 3031 3130 0910 3321 0000 AA98  811.0110..3!..ª˜

000820090  8B01 3912 0000 AA98 8B01 1233 382B 1B03  ‹.9...ª˜‹..38+..

0008200A0  3831 311B 3032 3033 0910 3320 0000 2B1B  811.0203..3 ..+.

0008200B0  3A09 3912 0000 2B1B 3A09 9803 2A0A 8200  :.9...+.:.˜.*.‚.

0008200C0  3831 311B 3032 3030 0910 3320 0000 9B21  811.0200..3 ..›!

0008200D0  1209 3912 0000 9B21 1209 9908 B018 8800  ..9...›!..™.°.ˆ.

0008200E0  3831 311B 3031 3330 0910 3320 0000 8392  811.0130..3 ..ƒ’

0008200F0  9809 3912 0000 8392 9809 0318 B2A3 3001  ˜.9...ƒ’˜...²£0.

000820100  A131 311B 3031 3331 0910 3320 0000 390A  ¡11.0131..3 ..9.

000820110  9B09 9B09 0000 390A 9B09 A91A B223 9800  ›.›...9.›.©.²#˜.

000820120  A131 311B 3031 3332 0910 3320 0000 0880  ¡11.0132..3 ...€

000820130  2B0A 2B0A 0000 0880 2B0A 9A1B 2A2A 1000  +.+....€+.š.**..

000820140  A131 311B 3032 3030 0910 3320 0000 2922  ¡11.0200..3 ..)"

000820150  3909 3909 0000 2922 3909 8A02 0032 A102  9.9...)"9.Š..2¡.

It seems that things happen at intervals of 0x8000 bytes, ie 0x40 sectors. Perhaps that's the cluster size?

[pbzcbf...@gmail.com]

A file ...

Offset(h)  00   02   04   06   08   0A   0C   0E

000868000  1012 1309 0000 0001 0000 0030 0038 0031  ...........0.8.1

000868010  0031 001B 0030 0032 0030 0032 0009 0010  .1...0.2.0.2....

000868020  0033 0933 220A 0000 0088 0AA2 0000 0000  .3.3"....ˆ.¢....

... and another ...

Offset(h)  00   02   04   06   08   0A   0C   0E

000888000  1012 1309 0000 0001 0000 0030 0038 0031  ...........0.8.1

000888010  0031 001B 0030 0031 0032 0030 0009 0010  .1...0.1.2.0....

000888020  0033 0891 B01A 0000 0082 A30A 000B 92B2  .3.‘°....‚£...’²

... and again ...

Offset(h)  00   02   04   06   08   0A   0C   0E

0008A8000  1012 1309 0000 0001 0000 0030 0038 0031  ...........0.8.1

0008A8010  0031 001B 0030 0031 0033 0031 0009 0010  .1...0.1.3.1....

0008A8020  0033 0938 82A1 0000 02B3 B998 0000 0000  .3.8‚¡...³¹˜....

[pbzcbf...@gmail.com]

The directory is probably better viewed as follows:

Offset(h)  00   02   04   06   08   0A   0C   0E   10   12   14   16   18   1A   1C   1E

000818000  2A20 2020 2020 2020 2020 2010 0000 0800 1800 1800 0000 0800 1800 0100 0000 0000  *          .....................

000818020  2A2A 2020 2020 2020 2020 2010 0000 0800 1800 1800 0000 0800 1800 0000 0000 0000  **         .....................

000818040  0B08 1909 081B 1002 0001 1022 0000 0800 1800 3912 0000 0800 1800 0A00 0008 0000  ..........."......9.............

000818060  1008 0119 1B12 1309 0001 1022 0000 0800 1800 3912 0000 0800 1800 0B00 3000 0000  ..........."......9.........0...

000818080  3831 311B 3031 3839 0910 3320 0000 A019 980A 3912 0000 A019 980A 1200 B233 2302  811.0189..3 .. .˜.9... .˜...²3#.

0008180A0  3831 311B 3032 3031 0910 3320 0000 1319 1809 3912 0000 1319 1809 320A 0021 2900  811.0201..3 ......9.......2..!).

0008180C0  3831 311B 3031 3930 0910 3320 0000 0920 830B 3912 0000 0920 830B 1003 0001 9301  811.0190..3 ... ƒ.9.... ƒ.....“.

0008180E0  3831 311B 3031 3931 0910 3320 0000 110A 880B 3912 0000 110A 880B 8A28 9239 3A00  811.0191..3 ....ˆ.9.....ˆ.Š(’9:.

000818100  3831 311B 3032 3032 0910 3320 0000 0A22 3309 3912 0000 0A22 3309 910A A20A 8800  811.0202..3 ..."3.9...."3.‘.¢.ˆ.

000818120  A131 311B 3032 3032 0910 3320 0000 AB30 3909 3909 0000 AB30 3909 9203 2892 0000  ¡11.0202..3 ..«09.9...«09.’.(’..

000818140  3831 311B 3031 3939 0910 3320 0000 323A 1109 3912 0000 323A 1109 A93A 1A30 9001  811.0199..3 ..2:..9...2:..©:.0..

000818160  A131 311B 3032 3031 0910 3320 0000 232B 3909 3909 0000 232B 3909 9103 0838 0000  ¡11.0201..3 ..#+9.9...#+9.‘..8..

000818180  A131 311B 3031 3233 0910 3320 0000 8398 0303 0303 0000 8398 0303 9A1B 9888 0000  ¡11.0123..3 ..ƒ˜......ƒ˜..š.˜ˆ..

0008181A0  A131 311B 3031 3238 0910 3320 0000 9198 0303 0303 0000 9198 0303 A01B 88AB 9B01  ¡11.0128..3 ..‘˜......‘˜.. .ˆ«›.

0008181C0  A131 311B 3030 3831 0910 3320 0000 A098 8200 8200 0000 A098 8200 8B1B 82B9 2200  ¡11.0081..3 .. ˜‚.‚... ˜‚.‹.‚¹".

[pbzcbf...@gmail.com]

I'm wondering how the file system keeps a record of free and in-use clusters. That would show up in an image comparison with an actual voice recorder before and after file deletion.

[pbzcbf...@gmail.com]

I think these are the files.

[Markus Bauer]

Really nice job - i was also googeling a bit and didn't find any documentation or infos about that FS. I guess the best way would be get a used recorder, use it as "translator" and run a RAW-recovery then on the card in a recorder.

Or did you find some info?

[jol qwerr]

what I cant understand

according to the manual the recording format is either mp3 or wma

[pbzcbf...@gmail.com]

I haven't found any info. I'm still trying to work out how to locate the position of the file from the metadata in the directory. I also don't understand the metadata in the "boot sector".

[pbzcbf...@gmail.com]

Maybe the data are headerless, as DiskTuna has previously stated?

[jpv...@gmail.com]

This looks kinda FAT-tish

__________________________________
Sent from eM Client | www.emclient.com

On 3/29/2021 9:50:02 PM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

I'm wondering how the file system keeps a record of free and in-use clusters. That would show up in an image comparison with an actual voice recorder before and after file deletion.

--
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/1d307535-a982-4640-a588-3bee859c50abn%40googlegroups.com.

[jpv...@gmail.com]

It's FAT based at least I assume. If I replace

*

**

by 

.

..

DMDE to some degree allows to navigate folder structure

__________________________________
Sent from eM Client | www.emclient.com

On 3/29/2021 10:25:08 PM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

I think these are the files.

--
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/c0382f1c-7ca7-4551-8830-c2c5798e9af8n%40googlegroups.com.

[jpv...@gmail.com]

FAT

__________________________________
Sent from eM Client | www.emclient.com

[pbzcbf...@gmail.com]

Brilliant!

This appears to be the first non-zero sector of the first copy of the FAT:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00458000 B8 BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
00458010 BB BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
00458020 BB BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
00458030 BB BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
00458040 BB BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
00458050 BB BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
00458060 BB BB BB 0B 1A 00 00 00 1B 00 00 00 18 00 00 00
00458070 19 00 00 00 1A 00 00 00 1B 00 00 00 20 00 00 00
00458080 21 00 00 00 22 00 00 00 23 00 00 00 20 00 00 00
00458090 21 00 00 00 22 00 00 00 23 00 00 00 28 00 00 00

... and the second copy ...


Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0062C000 B8 BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
0062C010 BB BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
0062C020 BB BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
0062C030 BB BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
0062C040 BB BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
0062C050 BB BB BB 0B BB BB BB 0B BB BB BB 0B BB BB BB 0B
0062C060 BB BB BB 0B 1A 00 00 00 1B 00 00 00 18 00 00 00
0062C070 19 00 00 00 1A 00 00 00 1B 00 00 00 20 00 00 00
0062C080 21 00 00 00 22 00 00 00 23 00 00 00 20 00 00 00
0062C090 21 00 00 00 22 00 00 00 23 00 00 00 28 00 00 00

The two copies are separated by 3744 sectors. This corresponds to 479232 entries in each FAT (one 32-bit entry per cluster).

479 232 x 32 KiB = 15.70 GB

[pbzcbf...@gmail.com]

ISTM that if a fragmented file is deleted, then we will have a problem assembling the fragments. Moreover, if the voice recorder is translating its FS to a standard FAT32 FS when talking to an external OS, then it may "TRIM" those sectors that were occupied by deleted files.

[pbzcbf...@gmail.com]

I was able to extract 38 files using DMDE's raw scan by defining a custom signature:

\x09\x00\x33\x03\x00\x00\x00\x00\x0B\x32\x18\x0B\x08\x19\x00\x00\x01\xA8\x00\x00\x03\x29\x30\x33\x02\x00\x01\x00\x02\x00\x00\x00\x38\x31\x31\x1B\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20

[pbzcbf...@gmail.com]

     32,768 f2233152.Voic

     32,768 f1193152.Voic

     65,536 f2233600.Voic

     65,536 f1193216.Voic

     65,536 f833088.Voic

    196,608 f2233216.Voic

    327,680 f21504.Voic

  1,638,400 f476352.Voic

  1,769,472 f307840.Voic

  1,867,776 f17856.Voic

  2,981,888 f1236224.Voic

  4,980,736 f823360.Voic

  5,275,648 f136320.Voic

  8,552,448 f1193344.Voic

  9,994,240 f518592.Voic

 10,584,064 f172224.Voic

 11,403,264 f61888.Voic

 11,894,784 f113088.Voic

 13,107,200 f146624.Voic

 13,402,112 f1210048.Voic

 14,811,136 f84160.Voic

 15,302,656 f277952.Voic

 19,988,480 f479552.Voic

 20,348,928 f22144.Voic

 21,135,360 f1670272.Voic

 24,379,392 f379584.Voic

 25,165,824 f427200.Voic

 30,441,472 f1046976.Voic

 34,963,456 f311296.Voic

 43,548,672 f192896.Voic

 43,810,816 f833216.Voic

 44,400,640 f1106432.Voic

 59,375,616 f2233728.Voic

 65,634,304 f918784.Voic

 70,942,720 f684800.Voic

 75,104,256 f538112.Voic

219,250,688 f1242048.Voic

267,059,200 f1711552.Voic

38 File(s)  1,193,902,080 bytes

[pbzcbf...@gmail.com]

If I get DMDE to parse the boot sector at 8192 as a FAT32 boot sector, it reports 2720 sectors per FAT. That's 1024 sectors less than the actual size (3744 = 2720 + 1024). It would appear that Olympus have taken a standard Microsoft FAT32 file system and mangled specific components.

[Paulo Braga]

Wow, you really are amazing.

I will follow your tips, extract the files as listed and try to convert them into a common audio format.

I can't forget to thank you. Fantastic job.

Em ter., 30 de mar. de 2021 às 06:33, pbzcbf...@gmail.com <pbzcbf...@gmail.com> escreveu:

If I get DMDE to parse the boot sector at 8192 as a FAT32 boot sector, it reports 2720 sectors per FAT. That's 1024 sectors less than the actual size (3744 = 2720 + 1024). It would appear that Olympus have taken a standard Microsoft FAT32 file system and mangled specific components.

--
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/VshfKZ--t5A/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/34c2bfd5-4448-471f-a5c8-f1412d775c81n%40googlegroups.com.

[pbzcbf...@gmail.com]

I had to use a custom header, so it stands to reason that no tool (other than an Olympus tool) will be able to play these audio files. I suspect that the voice recorder converts these files into standard MP3 or WMA formats when uploading them to a computer via USB. I would ask the client if s/he has a recording which was saved via USB, then we could try to editing the header.

If a simple edit is not possible, then you could try Wayne's solution, but you would need a recorder. Start with a blank card and make a single long recording. Locate the voice file and zero fill it, then paste each of your deleted files into this file space. Upload the file via USB and repeat the procedure for each of the remaining files.

Further on the FAT32 "mangling", the first FAT starts at offset 0x458000. That's sector 8896. The boot sector is at 8192, so the FAT begins at logical sector 704 (= 8896 - 8192). When DMDE parses the boot sector, it reports 640 reserved sectors, so the FAT would normally start at logical sector 640. That's a difference of 64 sectors. ISTM that a determined person could write a tool to "deobfuscate" the file system and convert it to a regular FAT32 FS that could then be mounted by regular tools.

[pbzcbf...@gmail.com]

BTW, DMDE's file extraction is not perfect. If you navigate to the end of each file and perform a reverse search for 0x00 0x00 0x00 0x00, you will find zero filled slack space which corresponds to the real end of file.

For example ...

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

01D03000  08 2A 20 92 9B 88 AB 1A 38 B1 33 83 08 B2 98 00

01D03010  91 BB BA 98 1B 2B 91 33 28 83 B2 89 99 2A 00 00

01D03020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01D03030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01D03040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

........

01D031D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01D031E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01D031F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

01D03200  B2 B0 8A AB A8 81 A2 A2 80 83 00 31 30 A1 08 12

01D03210  11 98 82 8B A9 1A A1 81 A8 01 B0 92 89 8A 90 90

[jpv...@gmail.com]

Yes, I've had no luck with getting these files to play.

I that regard today sucked anyway, people sending me all kinds of corrupt photos with non matching reference files. Anyway.

__________________________________
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/d48d088b-3a27-458f-b840-c2db237e82ebn%40googlegroups.com.

[jpv...@gmail.com]

"ISTM that a determined person could write a tool to "deobfuscate" the file system and convert it to a regular FAT32 FS that could then be mounted by regular tools."

Yeah, but isn't main issue the files themselves?

__________________________________
Sent from eM Client | www.emclient.com

On 3/30/2021 8:40:45 PM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

I had to use a custom header, so it stands to reason that no tool (other than an Olympus tool) will be able to play these audio files. I suspect that the voice recorder converts these files into standard MP3 or WMA formats when uploading them to a computer via USB. I would ask the client if s/he has a recording which was saved via USB, then we could try to editing the header.

If a simple edit is not possible, then you could try Wayne's solution, but you would need a recorder. Start with a blank card and make a single long recording. Locate the voice file and zero fill it, then paste each of your deleted files into this file space. Upload the file via USB and repeat the procedure for each of the remaining files.

Further on the FAT32 "mangling", the first FAT starts at offset 0x458000. That's sector 8896. The boot sector is at 8192, so the FAT begins at logical sector 704 (= 8896 - 8192). When DMDE parses the boot sector, it reports 640 reserved sectors, so the FAT would normally start at logical sector 640. That's a difference of 64 sectors.

--
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/d48d088b-3a27-458f-b840-c2db237e82ebn%40googlegroups.com.

[pbzcbf...@gmail.com]

True, as long as the files are not fragmented.

Unfortunately this is one of those cases where the client is not helpful.

[jpv...@gmail.com]

On 3/30/2021 9:51:06 PM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

True, as long as the files are not fragmented.

Unfortunately this is one of those cases where the client is not helpful.

Yes, a tad frustrating ...

[jol qwerr]

I found 1 of my Olympus voice recorders, its a WS-821

I assume its supposed to be the same in regards of the FS and the file structure

will try do some testings next week

I do have an older model (IIRC its a) ws-80x

still couldnt find it, if I do find it, I'll try to test it too and compare against the newer 1 (821) to see if there is any difference

[pbzcbf...@gmail.com]

"Loading a file to a PC" reads the same as the WS-811. It also supports the same file formats (WMA, MP3). ISTM that you should be able to recover the OP's files. :-)

https://www.olympusamerica.com/files/oima_cckb/WS821_WS822_WS823_EN_U02.pdf

[jol qwerr]

There was certainly some changes from WS-81"2" and above

1 of them is stated in the manual

it supports wav 

[pbzcbf...@gmail.com]

Can you show us WMA and MP3 audio recordings before and after they have been uploaded to a PC?

[pbzcbf...@gmail.com]

I'm laughing now. :-))) This thread is what is known as an epic fail.

We were all so convinced that Olympus was doing proprietary shenanigans that nobody noticed that data bits #2 and #6 were always 0. That is, either the card or the reader has two stuck bits.

[jpv...@gmail.com]

Oh dammit, should have seen that!! Good spot anyway Frank.

__________________________________
Sent from eM Client | www.emclient.com

On 3/31/2021 3:35:51 AM, "pbzcbf...@gmail.com" <pbzcbf...@gmail.com> wrote:

I'm laughing now. :-))) This thread is what is known as an epic fail.

We were all so convinced that Olympus was doing proprietary shenanigans that nobody noticed that data bits #2 and #6 were always 0. That is, either the card or the reader has two stuck bits.

--
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/ebf01953-a7ca-4e48-8374-b543fb93e542n%40googlegroups.com.

[Paulo Braga]

Very interesting the amount and information you got.

I believe that the best thing to do in this case is to acquire an identical voice recorder and do the tests that you have indicated.

I apologize but I didn't understand the part where you talk about "stuck bits", I cloned the card using a reader here in the lab. What is wrong?

Thanks masters.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/emfb972797-95fd-4fc4-b5ee-c02934e986ef%40alien.

[pbzcbf...@gmail.com]

All the data are corrupt. 

A "stuck bit" is a hardware failure which causes a particular bit to be always read as a 0 (if stuck low) or a 1 (if stuck high). This could happen if data pin #2 on your SD card is shorted to ground or open circuit, or if data pin #2 on your reader is shorted or open circuit.

See ...

https://en.wikipedia.org/wiki/SD_card#Transfer_modes

I would examine pin #1 (DAT2) of the card or reader.

If there are no physical problems with pin#1, then I would try to read the card in "SPI bus mode" or "One-bit SD bus mode". Pin #1 is not used in either of these modes.

 

[jpv...@gmail.com]

Try a different reader.

I have seen this with CF cards a few times, a few of those it was a bent pin on the reader. Other cases were unrecoverable. A stuck bit is a bit that by definition reads 0 or 1. Remember we see * and ** at offset 0 and 16 in a directory while we know it needs to be . and ..

So we see in hex 0x2A and 0x2A, 2A where we should see 0x2E and 0x2E, 2E.

Or in binary

we get 00101010 where we should see 00101110

          

if xxxxxyxx the y here is ALWAYS zero there's a good chance it is wrong but we have no way ti tell when it will be wrong. So these cases are practically impossible to recover from unless you can get a good read. So IOW if the issue is the reader you can clone again using different reader. If that does not solve it I believe this is unrecoverable.

__________________________________
Sent from eM Client | www.emclient.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CANBOQm7vh-kn-o%3DV9qTYMwbRJP5e4yM%2Bbt5oGa7Nkmvgk%3D6-RQ%40mail.gmail.com.

[Markus Bauer]

Hi. I just to show you that in python:

>>> bin(ord("*"))

'0b101010'

>>> bin(ord("."))

'0b101110'

Here bit #2 (the 3rd one) is a 0 instead of a 1. The same is with the 11AA instad of 55AA in the MBR.

To test that I fast wote a fast test and run it againce a few MB of the data and the result confirm that:

No of bits in pos. 0 which are 1:   500639

No of bits in pos. 1 which are 1:   496432

No of bits in pos. 2 which are 1:        0

No of bits in pos. 3 which are 1:   502589

No of bits in pos. 4 which are 1:   497394

No of bits in pos. 5 which are 1:   501338

No of bits in pos. 6 which are 1:        0

No of bits in pos. 7 which are 1:   494082

Really great job Frank. How did you figure that out?

[Paulo Braga]

HAHAHHAHAHAHAHHA

I do not believe! I can't believe how incredible you guys can be!

You were right! I tried another player and recognized a FAT32 structure with fully readable mp3 files!

I am grateful to everyone who tried and also explained the problem to me, I would never be able to identify it in an image. I confess to being a little ashamed of having spent your time in a case like this.

See attached image, all right now!

Incredible, I would like to thank everyone!

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/5c373ce5-8dd4-4d42-80d7-5fc54b8b493fn%40googlegroups.com.

[jpv...@gmail.com]

Next time 11 AA instead of 55 AA, * and ** instead of . ad .. should be dead giveaways. I can not believe I missed it seeing Canon change into Cankn in JPEG headers several times now, all due to similar issue. I spot those instantly, why not this. Anyway.

__________________________________
Sent from eM Client | www.emclient.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/5c373ce5-8dd4-4d42-80d7-5fc54b8b493fn%40googlegroups.com.

[Markus Bauer]

One of my procedures is always to try another reader / cable / etc. when I get strange results. And to be hornest I also never hear about a stuck bit but yes that make perfectly sene when some data pins are shorted you get always a 0 or a 1. 

The SPI trick is great - there are some tutorials how to read a SD card with an Arduino and once that helped me also out but it's painfully slow! If you don't know that one just google it and save you some of that tutorials. I store such things in PDF form over the time and often I write small test scripts or helpers fo me. So I create a lib. with solutions or ideas and I check them always when I have a strange problem.

You guys are really awsome - thanks for sharing that knowledge! 

[jpv...@gmail.com]

This isn't first time for Frank to spot this either: https://forum.hddguru.com/viewtopic.php?f=10&t=39156&hilit=cankn&start=20

__________________________________
Sent from eM Client | www.emclient.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/3533a3fc-0ca4-4d1b-8d03-c46402517133n%40googlegroups.com.

[t...@desertdatarecovery.com]

Franc and Joep – Great work.

At last we know the newer Olympus are not as much of a PITA as the old ones.

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/3533a3fc-0ca4-4d1b-8d03-c46402517133n%40googlegroups.com.

[pbzcbf...@gmail.com]

I have seen stuck bits hundreds of times. My epic fail was a case of misdirection by prior experience. I knew that Olympus did proprietary things, and I was also involved in a thread at HDD Guru where a DVR manufacturer did in fact mangle an MS FAT file system.

I'm still slapping my head. I feel so stupid. Eventually I realised that these 2 bits were involved, but I still just assumed that they were being intentionally flipped. It was only after I had decided to "deobfuscate" the FATs that I realised that these bits were cold, not inverted.

[pbzcbf...@gmail.com]

I wrote a FreeBasic program to count the 1's, but it took FOREVER to work through the first 1.2GB of the image.

Bit#          64-bit        32-bit        16-bit        8-bit         4-bit

0             72708918      145381336     290626780     581153630     1152707516

1             71710345      143373966     286583784     573125633     1151348065

2             0             0             0             0             0

3             72729671      145397390     290674474     581387908     1152127791

4             71531429      142976668     285921151     571553886

5             72340084      144606768     289109062     578222432

6             0             0             0             0

7             71340319      142661424     285330395     570739883

8             72676286      145241060     290526850

9             71638111      143242487     286541849

10            0             0             0

11            72698983      145380607     290713434

12            71498118      142915249     285632735

13            72286206      144497784     289113370

14            0             0             0

15            71423181      142765422     285409488

16            72633785      145245444

17            71549386      143209818

18            0             0

19            72644697      145277084

20            71487209      142944483

21            72287457      144502294

22            0             0

23            71367466      142668971

24            72619703      145285790

25            71634957      143299362

26            0             0

27            72664826      145332827

28            71327150      142717486

29            72313414      144615586

30            0             0

31            71298892      142644066

32            72672418

33            71663621

34            0

35            72667719

36            71445239

37            72266684

38            0

39            71321105

40            72564774

41            71604376

42            0

43            72681624

44            71417131

45            72211578

46            0

47            71342241

48            72611659

49            71660432

50            0

51            72632387

52            71457274

53            72214837

54            0

55            71301505

56            72666087

57            71664405

58            0

59            72668001

60            71390336

61            72302172

62            0

63            71345174

[Markus Bauer]

Had the same idea: https://opensource-data-recovery-tools.com/scripts.php?t=stuck_bit_test

[pbzcbf...@gmail.com]

This is my current version:

http://www.users.on.net/~fzabkar/FreeBasic_W32/Utils/bitcount32.exe

http://www.users.on.net/~fzabkar/FreeBasic_W32/Utils/bitcount32.bas

[Markus Bauer]

May I ask why you are lookig for 4 - 64 bit... Why just 8 bit is not sufficient enough in your opinion?

[pbzcbf...@gmail.com]

The microSD interface is 4-bit but the internal NAND flash memory may be 8-bit or 16-bit. A single stuck bit on a NAND chip may not be easily visible via an 8-bit tool.

For example, if the counts for bits 2, 6, 10 and 14 are 0, then this points to a stuck bit #2 on the card's 4-bit interface.

Otherwise, if the counts for bits 2, 6 and 10 are non zero, and if the count for bit 14 is 0,  then this points to a cold bit on a 16-bit NAND, or some other internal 16-bit (or 32-bit) bus.

IDE drives sometimes have stuck bits, usually due to a bad connection in the cable. The IDE bus is 16-bit, so an 8-bit tool won't detect this fault.

I'm thinking that it would be better for our software to report the bit counts as percentages rather than absolute numbers. For truly random data one would expect that the bit frequency would be 50%. Any marked deviation from this average could point to a bit which is "weak" but not completely dead.

BTW, your tool did not process all the sectors that I specified. It also took 3 hours to run on my Core 2 Duo. I guess that's because Python is an interpreter rather than a compiler. The FreeBasic compiler produces code which executes in just over 1 minute. That was an eye opener for me. I think if I use Python in future, it will only be for simple tasks. Thanks for the program.

C:\python.exe stuck_bit_tester.py "C:\Downloads\FZ\Voice_Recorder\Generic Storage Device 0_truncated.dsk" 2349696

Reading sector no. 2331909 of 2349696

REPORT FOR 'C:\Downloads\FZ\Voice_Recorder\Generic Storage Device 0_truncated.dsk':

Counting bits which are 1

BITS:          0 |          1 |  !!! 2 !!! |          3 |          4 |          5 |  !!! 6 !!! |          7 |

-------------------------------------------------------------------------------------------------------------

ONES:  581153630 |  573125633 |          0 |  581387908 |  571553886 |  578222432 |          0 |  570739883 |

MAX.: 1193937408 | 1193937408 | 1193937408 | 1193937408 | 1193937408 | 1193937408 | 1193937408 | 1193937408 |

[Markus Bauer]

I where thinking it must be that but I am not sure. I am working on a book about Python performance tuning - there are some ways to speed it up. If you are interested Frank just let me know. I can send you a PDF version when it's done. 

What version of python did you use? I will test it on my Z600 with a X5550 Xeon (also not the newest hardware) but it should not take so long. Over eastern I will have time to play with that.

PS.: You can "compile" Python as well with tools like nuitka to make distributing easier and the code run after a bit faster but Python is generally great to make coding faster and not to get the fastest execution times.

[pbzcbf...@gmail.com]

I remember that you suggested Cython to compile the code.

My Python version is ...

Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 22:45:29) [MSC v.1916 32 bit (Intel)] on win32

BTW, FreeBasic can make use of assembly language code. I have sometimes used ASM code to speed up computations, but in most cases the FreeBasic compiler produces optimal code that doesn't benefit greatly from such optimisations.

I confess that I'm a lousy programmer. The only Python code I've written was by using other code as a template. The other frustrating thing is that early Python scripts are incompatible with the latest version. I would be interested in your Python performance tuning PDF. Thanks. 

BTW, I'm also limited to Windows 10 32-bit, so that may account for some of the performance problems.

[pbzcbf...@gmail.com]

The latest version of my tool now displays the bit frequencies as absolute counts and percentages.

[pbzcbf...@gmail.com]

I've replaced the computational portion of my code with assembler. The execution time is now halved, approximately 30sec per GB on my Core 2 Duo running 32-bit Win 10.