cgsecurity.org

aleph wrote: 15 Jul 2024, 20:06 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

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,

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?

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 can't see an interest in doing so.

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

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 wrote: 16 Jul 2024, 03:04

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

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

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?

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.

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

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

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

sudo ddrescue Disktocopy  addressImage.dd addresslog.log

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

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.

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.

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 wrote: 16 Dec 2024, 18:34 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 have also to say that, when operating on the image of the same disk, I can see files in the directory MS Data

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.

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