Jump to content











Photo
- - - - -

problem reading GPT external drive (using windows 7 32bits)


  • Please log in to reply
5 replies to this topic

#1 matrix.rebooted

matrix.rebooted

    Newbie

  • Members
  • 26 posts
  •  
    France

Posted 14 December 2020 - 05:07 PM

Hello,

I'm trying to read a toshiba sata/usb external storage drive (500GB/465GiB). A friend told me he can't read it anymore and that there is some photos on it. Don't know what happened.

I'm using bios/windows 7 32bits computer and for what I can see using testdisk and photorec, disk is empty but formatted in GPT and there is a first 'microsoft reserved' partition of 16.5 MB (not 32?); indeed I can't read it but maybe there is some trouble with it since I get 'bad sector count' error message or 'can't open for reading' with gdisk and 'unallocated' in windows disk management.

Here are some tests I made so far, let me know if you need anything else:
(hd0 or /sda is my current windows, hd1 or /sdb is the problematic usb drive)

- tinyhexer log and MBR/PBR/GPT backup can be found in the attached file (link at the end of the msg)

- drive doesn't show up in windows explorer but appears in device manager and as shown in the screenshot disk management shows unalocated drive space. Didn't try 'set new volume' and assign letter to not wipe out any content but the option is not greyed out (hence, can't try chkdsk for now - but don't know if it will be of any help here, gpt drive pluged in bios/mbr system)

- testdisk finds an efi/gpt drive but with 'bad sector count' error; tried different geometry (num of sectors per head 255, 240, 16, 32, 128), no change
  also tried intel/pc (mbr) or mac, same

- ran photorec all night long then easeUS data recovery wizard, didn't find anything

- used 'Toshiba Storage Diagnostic Tool_1.30.8920', it says disk passes the tests and is healthy (chs is effectively 60801 255 63 / 512)

- booted a linux system rescue iso with gparted, it finds the two partitions but can't read them, even that 'microsoft reserved partition'

- used dmde-3.6.0.770:
  first message is something like 'volume is probably not fully accessible' but initial and available space mentioned are the same (976 773 168 LBA x 512 (500 GB))

  didn't try 'gpt off' without your advice
 
  ntfs and mft modes just shows 0 everywhere from lba 3 to 976 773 163 (nothing after, shouldn't it be  976 773 168?)

  I put some screens of the first 3 and the last bloc, everything in between seems to be 0 everywhere, but I don't know if the drive is read correctly.
 
  performing full scan: will end tomorrow!

What I'm wondering firstly is wether I'm supposed to be able to read a GPT drive or not (a priori win7 x86 should have driver for it) and then what can I do except clean the disk and convert to mbr? (unless it is actually empty) It seems like someone/something ;) formatted the drive in GPT type

(unfortunately I don't have an efi/gpt computer with windows x64 to test further)

 

log files at mediafire: https://www.mediafir...reports.7z/file

 

Thank you

 



#2 matrix.rebooted

matrix.rebooted

    Newbie

  • Members
  • 26 posts
  •  
    France

Posted 15 December 2020 - 06:56 AM

(can't edit?)

 

dmde didn't find any file neither, added diskpart info and found one non empty secteur near the end (976773131) https://www.mediafir...reports.7z/file



#3 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 15 December 2020 - 10:11 AM

Once said that I am partial to DMDE, if it didn't find anything, it usually means that there is not anything.

 

As well, for pure file carving Photorec is a very good tool.

 

Everything you posted points to a (thoroughly) wiped partition/volume, anyway nothing connected to GPT or your running system, DMDE accesses/interprets it independently from the running OS, and if a byte is read as 00, it is a 00.

 

You should check also the second last sector of the disk, in GPT they are a "mirrored mirror" of the partitioning, i.e:

LBA0 Protective MBR ->nothing
LBA1 EFIPART sector ->last sector

LBA2 GPT partition table first sector -> second last sector (this should be LBA 976773163)

 

LBA2 has no traces of a second partition besides the Microsoft reserved one

 

Only for the record, the dmde_part.table.mode.PNG makes no sense, a possible MBR table (which in this case is a GPT protective one) is on LBA0, that image is about LBA39  :w00t:

 

Other sectors you want to check manually (and a few sectors after them):
1) LBA 34 (the bootsector of the MS reserved partition )

2) LBA 2048 (the "standard" place for a bootsector in case of a single partition)
3) LBA 32768 (the bootsector of the (maybe) following partition)
4) LBA 2048+786432*8=6293504 (the "standard" place for the $MFT in case of a single partition)

5) LBA 32768+786432*8=6324224 (the "standard" place for the $MFT in case of a (maybe) second partition)

 

Another (not so quick) test is to write a batch revolving around:
dsfo \\.\PHYSICALDRIVE1 <start in bytes> 1048576 nul

this command will transfer 1 MB of data to the nul device AND output the MD5 of the transferred bytes.

 

The MD5 of 1048576 00 bytes is B6D81B360A5672D80C27430F39153E2C.

 

You can use this tool:

https://www.edenprim...hCalculator.htm

to calculate the hash for larger (or smaller) chunks.

 

If the chunk results in a MD5 corresponding to all 00's it essentially means "Nothing to see here, move on!". :(

 

If - on the other hand - the chunk has a different MD5, *something* in it is non-00 and may be worth a manual look at it.

 

:duff:

Wonko



#4 matrix.rebooted

matrix.rebooted

    Newbie

  • Members
  • 26 posts
  •  
    France

Posted 15 December 2020 - 10:37 AM

Thank you for the calculations and the clear explanations

 

All mentioned sectors are empty

 


Another (not so quick) test is to write a batch revolving around:
dsfo \\.\PHYSICALDRIVE1 <start in bytes> 1048576 nul

this command will transfer 1 MB of data to the nul device AND output the MD5 of the transferred bytes.

 


:duff:

Wonko

 

What should I choose for <start>, except the firsts and last sector I just found lba 976773131 not empty (see 2nd archive); If I understand you tell me to run loop in batch for example, trying different start value? except it would be faster, would it possibly give a different result than just looking at sector via hexa editor because I've already walk through a certain amount.. :)

 

Well, main point is that if you tell me that when dmde read 0 what ever my system is and whatever the disk is, it is 0 then I guess it's the conclusion. Even if there were something on the drive, somewhere, I don't think it would represent hundreds of files and I don't think the guy tried to crypt, hide or I don't what anything, it is clearly a mistake; but I was worry about the 'bad sector count' from testdisk.

 

again thank you for your time

 

ps: just to be sure, is this the correct way to 're-initialize' the drive:

diskpart
  list disk
  select disk 1
  clean
  convert mbr

then assign letter and format to ntfs


Edited by matrix.rebooted, 15 December 2020 - 11:01 AM.


#5 matrix.rebooted

matrix.rebooted

    Newbie

  • Members
  • 26 posts
  •  
    France

Posted 15 December 2020 - 11:56 AM

done - disk is starting a new life :)



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 15 December 2020 - 02:03 PM



Good :) (that from a data recovery viewpoint means bad :().

Only for the record the idea is/was to "scan" the whole disk in (arbitrarily sized to 1 MB, but given the context you can probably make bigger, let's say 10 MB) chunks.
 
It is usually faster (speed is essentially connected to read speed of the device only) than looking at sectors individually, and it allows to exclude from manual anslysis/review all the chunks that are 00ed.
 
Let's say that for the first ten runs you have:
C:\dummy2>dsfo \\.\physicaldrive1 0 1048576 nul
OK, 1048576 bytes, 0.031s, MD5 = c3b708404a1a28dafc407e769b218e9a

C:\dummy2>dsfo \\.\physicaldrive1 1048576 1048576 nul
OK, 1048576 bytes, 0.016s, MD5 = b6d81b360a5672d80c27430f39153e2c

C:\dummy2>dsfo \\.\physicaldrive1 2097152 1048576 nul
OK, 1048576 bytes, 0.000s, MD5 = b6d81b360a5672d80c27430f39153e2c

C:\dummy2>dsfo \\.\physicaldrive1 3145728 1048576 nul
OK, 1048576 bytes, 0.015s, MD5 = b6d81b360a5672d80c27430f39153e2c

C:\dummy2>dsfo \\.\physicaldrive1 4194304 1048576 nul
OK, 1048576 bytes, 0.000s, MD5 = b6d81b360a5672d80c27430f39153e2c

C:\dummy2>dsfo \\.\physicaldrive1 5242880 1048576 nul
OK, 1048576 bytes, 0.016s, MD5 = e2b1dba1c3bcb63943f7b1b012f58a1e

C:\dummy2>dsfo \\.\physicaldrive1 6291456 1048576 nul
OK, 1048576 bytes, 0.000s, MD5 = 84f50e8930da5e87182a9f27557548d8

C:\dummy2>dsfo \\.\physicaldrive1 7340032 1048576 nul
OK, 1048576 bytes, 0.016s, MD5 = b6d81b360a5672d80c27430f39153e2c

C:\dummy2>dsfo \\.\physicaldrive1 8388608 1048576 nul
OK, 1048576 bytes, 0.000s, MD5 = b6d81b360a5672d80c27430f39153e2c

C:\dummy2>dsfo \\.\physicaldrive1 9437184 1048576 nul
OK, 1048576 bytes, 0.015s, MD5 = b6d81b360a5672d80c27430f39153e2c
You know that chunks # 2,3,4,5,8,9,10 contain no data, so you can check contents of # 1, 6 and 7 only.

Please note that due to math limits in batch, it would be easier to create the commands in a spreadsheet (or you will need to use a suitable workaround).

:duff:
Wonko




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users