[Boot] is present when operating testdisk on Physical Disk, while it is not when operating on Disk .dd image

[aleph]

I am trying to repair an originally internal hard disk (now in an external case) which cannot be open anymore.

When operating testdisk on the physical disk, choosing the advanced option, I get the following screen:

Screenshot 2024-07-14 193712.png (33.14 KiB) Viewed 21502 times

and, selecting the [Boot] option,

Screenshot 2024-07-15 204319.png (51.22 KiB) Viewed 21502 times

while, when performing the same operation on an dd image of the whole disk, mounted as a physical external disk using OSFmount, I get

Screenshot 2024-07-15 202644.png (53.74 KiB) Viewed 21502 times

I can see the [Boot] option only when mounting the two partitions in the disk as separate virtual disks, but in this case the EFI partition is not recognized and I cannot operate on the image by using BackupBS, since I get the following error

Code: Select all

Write error: can't overwrite exFAT main boot record 

I would like to try to recover the BS on the image, before to try to do it on the physical disk.

Is there a way to reproduce the same testdisk's behaviour as I get on the physical disk operating on the dd image of the whole disk or am I doing something wrong in operating testdisk on the image?

I thank you very much

[recuperation]

I am trying to repair an originally internal hard disk (now in an external case) which cannot be open anymore.

When operating testdisk on the physical disk, choosing the advanced option, I get the following screen:

Screenshot 2024-07-14 193712.png

and, selecting the [Boot] option,

Screenshot 2024-07-15 204319.png


while, when performing the same operation on an dd image of the whole disk, mounted as a physical external disk using OSFmount, I get

Instead of using dd which works well with flawless disks you should have used ddrescue instead as recommended in the TestDisk manual.
After cloning with dd I guess you have no information about the outcome of the cloning process whereas ddrescue provides you with a summary screen that you can copy and a detailed analysis in the mapfile.

Screenshot 2024-07-15 202644.png

I can see the [Boot] option only when mounting the two partitions in the disk as separate virtual disks,

I can't see an interest in doing so.

but in this case the EFI partition is not recognized and I cannot operate on the image by using BackupBS, since I get the following error

Code: Select all

Write error: can't overwrite exFAT main boot record 

This is not a TestDisk error - I pretend!
May I kindly ask you to read the documentation of OSFmount?

I don't know if FileDisk (Windows) would resolve your problem, but the linux command "losetup" will work. I just read that Windows 11 has a built-in "mount"-function.

I would like to try to recover the BS on the image, before to try to do it on the physical disk.

Is there a way to reproduce the same testdisk's behaviour as I get on the physical disk operating on the dd image of the whole disk or am I doing something wrong in operating testdisk on the image?

If you had been able to create a 100% clone and providing TestDisk in addition to the image with the correct sector size I don't see any reason for failures.

[aleph]

Instead of using dd which works well with flawless disks you should have used ddrescue instead as recommended in the TestDisk manual.
After cloning with dd I guess you have no information about the outcome of the cloning process whereas ddrescue provides you with a summary screen that you can copy and a detailed analysis in the mapfile.

I apologise, I wrote a dd image, but actually I meant a .dd image, produced with ddrescue.

I can't see an interest in doing so.

Me neither I just wrote that this was the only way I could obtain the option [Boot] somewhere.

This is not a TestDisk error - I pretend!
May I kindly ask you to read the documentation of OSFmount?

In fact, I apologise once more for not having made myself clear, I did not mean to say that this was a testdisk error, I just described the output of the operation.

If you had been able to create a 100% clone and providing TestDisk in addition to the image with the correct sector size I don't see any reason for failures.

The size of the image I created using ddrescue is correct; I created it repeating the command many times. The output screen at last passage is the following

Schermata del 2024-07-16 03-29-51.png (46.57 KiB) Viewed 21453 times

I stopped, since bad sectors and bad areas were the same at the last two passage.

By applying testdisk directly on the whole disk image (working under linux), I get again

Schermata del 2024-07-16 03-50-28.png (40.19 KiB) Viewed 21453 times

A couple of question: should not be possible to apply testdisk to the image of the full disk and obtain the same result as applying it to the physical disk?
Is it possible that the few bad sectors/areas make the difference?

Thank you very much

[recuperation]

Instead of using dd which works well with flawless disks you should have used ddrescue instead as recommended in the TestDisk manual.
After cloning with dd I guess you have no information about the outcome of the cloning process whereas ddrescue provides you with a summary screen that you can copy and a detailed analysis in the mapfile.

I apologise, I wrote a dd image, but actually I meant a .dd image, produced with ddrescue.

I can't see an interest in doing so.

Me neither I just wrote that this was the only way I could obtain the option [Boot] somewhere.

This is not a TestDisk error - I pretend!
May I kindly ask you to read the documentation of OSFmount?

In fact, I apologise once more for not having made myself clear, I did not mean to say that this was a testdisk error, I just described the output of the operation.

You did not understand my hint, unfortunately.
I know that OSFMount exists but never used it. So I just used the leading search engine that pointed me to the following result:
https://www.osforensics.com/tools/mount ... mages.html

The page states:
[... Overview ... By default, the image files are mounted as read only so that the original image files are not altered. OSFMount supports mounting disk image files as read/write in "write cache" mode. This stores all writes to a "write cache" (or "delta") file which preserves the integriy of the original disk image file...]

You don't have to be a computer expert to find, read and understand this description, I guess.

When using third party software make sure it does what you want it to do. For instance take a copy of a big file or generate one using h2testw, mount it and try to write on it (under Windows usex HxD for example).

If you had been able to create a 100% clone and providing TestDisk in addition to the image with the correct sector size I don't see any reason for failures.

The size of the image I created using ddrescue is correct; I created it repeating the command many times. The output screen at last passage is the following

Schermata del 2024-07-16 03-29-51.png

I stopped, since bad sectors and bad areas were the same at the last two passage.

By applying testdisk directly on the whole disk image (working under linux), I get again

You should use the most recent version of TestDisk from this year, not the outdated one that appeared five years ago.

Schermata del 2024-07-16 03-50-28.png

A couple of question: should not be possible to apply testdisk to the image of the full disk and obtain the same result as applying it to the physical disk?

I answered this question in my posting above. Have you read it at all?

Is it possible that the few bad sectors/areas make the difference?

Assuming a sector size of 512 bytes the bad sector size in your ddrescue screen translates into roughly 700 000 bad sectors. That does not correspond to my understanding of the word "few".

Unfortunately you did not bother documenting how you created the image.

[aleph]

Thank you very much.

The page states:
[... Overview ... By default, the image files are mounted as read only so that the original image files are not altered. OSFMount supports mounting disk image files as read/write in "write cache" mode. This stores all writes to a "write cache" (or "delta") file which preserves the integriy of the original disk image file...]

You don't have to be a computer expert to find, read and understand this description, I guess.

Actually, I read the OSFMount documentation, before to used. I supposed that testdisk operated on the "write cache" file, because so happened for other softwares I used in the past on image mounted through OSFMount, like chkdsk (while operating on the mounted image, changes are made on the "write cache" file, as if it would be the image, and one can decide if make them permanent at a later stage).
But I must have been wrong on how it works.

You should use the most recent version of TestDisk from this year, not the outdated one that appeared five years ago.

I tried with the last version of TestDisk (7.2, downloaded here : https://www.cgsecurity.org/wiki/TestDisk_Download), but I get the same result (no [Boot] option).

I answered this question in my posting above. Have you read it at all?

Yes, I did, but I continue in not obtaining the same result; but this is probably then due to the fact that there are too many bad sectors, although I would think (as a not computer expert) that such bad sectors should be present on the physical disk too.

Unfortunately you did not bother documenting how you created the image.

And I apologise for that, what I did is to operate ddrescue through the following instructions

Code: Select all

sudo ddrescue Disktocopy  addressImage.dd addresslog.log

until when I got twice the same result (in terms of bad sectors). I don't remember the number of times I repeated the command, but it was may be 3 or 4.

Thank you very much, once more.

[recuperation]

Please post your TestDisk logfile and the length of your clone file.

"DisktoCopy" is not the syntax that works with ddrescue.
Please, do not post virtual invented names. Based on the type of questions you were asking in March this year I want to see the details.

I looked at the source code of TestDisk. Although I am not a c programmer I can tell you that the advanced menu options at the bottom of the TestDisk screen are partition-dependant.

If your partition is rotten and TestDisk can't run special features it will leave out those features. That leads to the menu you have shown only containing
the menu entries [Type] [Image Creation] [Quit].
This behaviour tells me that your clone does not match the source or the sector size is incorrect. When dealing with a physical disk, TestDisk can read out the sector size.
Although writing a clone into a file does not risk overwriting disks and prevents from unwanted access by uncontrollable operating systems like Windows I always recommend duplicating onto a disk as this typically avoids the question of sector size.

What is the manufacturer and model of your external case? Did it come empty or did the case contain a disk already?
Some cases contain electronics which emulate a sector size of 4096 byte towards the computer.

The manual contains on page 59 the Chapter Seventeen "Scripted Run". The first greyed line shows you how to have TestDisk operate on your cloned file.
This way there is no need to run any third party mounting software.

You might have a look at the disk and the file simultaneously, HxD does not allow that type of comparison I think, Active@ Disk Editor might do the job.

[aleph]

Thank you very much, I apologise for the late answer.

Please post your TestDisk logfile and the length of your clone file.

I did not analysed the disk before, I did it now, but I stopped it at some point because the file was bigger than 512Kib and I was afraid to damage further the hd.

Here is the (zipped) TestDisk logfile I got

testdisk.zip

(35.54 KiB) Downloaded 3163 times

The length of my clone file is

Code: Select all

500.107.879.660 byte

"DisktoCopy" is not the syntax that works with ddrescue.
Please, do not post virtual invented names. Based on the type of questions you were asking in March this year I want to see the details.

I understand , the instruction I used

Code: Select all

sudo ddrescue /dev/sdb  /media/user/ExtHDD/Image.dd /media/user/ExtHDD/Image.log 

If your partition is rotten and TestDisk can't run special features it will leave out those features. That leads to the menu you have shown only containing
the menu entries [Type] [Image Creation] [Quit].
This behaviour tells me that your clone does not match the source or the sector size is incorrect. When dealing with a physical disk, TestDisk can read out the sector size.
Although writing a clone into a file does not risk overwriting disks and prevents from unwanted access by uncontrollable operating systems like Windows I always recommend duplicating onto a disk as this typically avoids the question of sector size.

Thank you very much, I think you are right. Unfortunately I don't have a whole disk to use for that, so I tried with the image, hoping to be able to prove on it before to act on the original disk.
The fact that it seemed to be possible to repair the boot sector gave me some hope, but, since the HD is not mine but of a relative of mine, I did not want to act directly on the disk.

What is the manufacturer and model of your external case? Did it come empty or did the case contain a disk already?
Some cases contain electronics which emulate a sector size of 4096 byte towards the computer.

My external case is a Vultech GS25-U3: the disk contained in it is the internal disk of laptop (it was placed there some year ago, before it started to have problems).

The manual contains on page 59 the Chapter Seventeen "Scripted Run". The first greyed line shows you how to have TestDisk operate on your cloned file.
This way there is no need to run any third party mounting software.

Thank you very much, I did it (obtaining the same result).

You might have a look at the disk and the file simultaneously, HxD does not allow that type of comparison I think, Active@ Disk Editor might do the job.

Thank you very much, I installed Active@ Disk Editor : I shall study it and try to use it (I never used such a kind of software, I am not an expert so I have to learn ).

Thank you, once more.

[aleph]

Finally, I tried to operate on the physical disk.

I tried BackupBS.

This is the screen I get when analysing the boot sector

Screenshot 2024-12-16 182359.png (22.95 KiB) Viewed 11725 times

and this is what I get after choosing to copy the backup boot record

Screenshot 2024-12-16 182432.png (13.12 KiB) Viewed 11725 times

Is there something I could do to recover the disk?

I have also to say that, when operating on the image of the same disk, I can see files in the directory MS Data while I cannot on the physical drive, and I get this screen

Screenshot 2024-12-16 182218.png (22.63 KiB) Viewed 11725 times

I thank you very much.

[recuperation]

Finally, I tried to operate on the physical disk.

I tried BackupBS.

This is the screen I get when analysing the boot sector

Screenshot 2024-12-16 182359.png


and this is what I get after choosing to copy the backup boot record

Screenshot 2024-12-16 182432.png

Is there something I could do to recover the disk?

I don't know. Your log file does not mention the manufacturer and the model of your 500 GB.
I guess it is a HDD, in case of being a SSD the SSD can be broken but allowing read operations.

I have also to say that, when operating on the image of the same disk, I can see files in the directory MS Data

There is no directory. "MS Data" is a partitioned that should contain a Microsoft type file system.
If you can see files in there, the easiest way to rescue is to mark them and copy them to another healthy location.

[aleph]

I don't know. Your log file does not mention the manufacturer and the model of your 500 GB.
I guess it is a HDD, in case of being a SSD the SSD can be broken but allowing read operations.

Yes, it is a HDD, labelled as ASMT 2115. The manifacturer is HGST.

If you can see files in there, the easiest way to rescue is to mark them and copy them to another healthy location.

Yes, I shall do this.
But the owner of the HDD (my nephew) would like me to try to recover the HDD. Of course, if this is not possible there are no ways, but if somehow it is...