Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
HFS+ Rescue / Re: HFS on SSD, logical page map with duplicates
« Last post by Elmar on September 15, 2019, 14:11:07 PM »
Hello Pete,

till now, I did not go as deep as you did into the SSD low level topic. I never looked at a SSD firmware source code. So, I don't know if I can help you. Also its difficult over the web, without a copy of the drive.

The volume header is found at around 14MB offset (is that normal-ish?)

This location can have various reasons.
Is there a partition before the data partition?
Maybe the EFI boot partition?
Is this the location after your low level SSD extraction?


BTW the terminology confuses me a bit, because in the SSD firmware code project blocks are sections of 2MB or so, pages of 16kb are the smallest data size it uses. Whereas in OS programming blocks seem to be 512 bytes etc. I hope you understand what I mean above.

When you write a file to the drive, then there are a few levels with (but not always) different block sizes.

You have the file system block size, which is (depending on the FS type and disk size) nowadays 4096 bytes (4K).
You have the standard block size of the drive 512 bytes for hard disks.
Inside the disk, you maybe have a block size of 512, 4K or another, which is not important for the upper levels. Except, its a matter of speed. When you have a disk with a 4K block size, then its better to align the partition/file system to 4K (is standard nowadays and aligned by the partitioning software). However, usually the internal block size is only important for the firmware.


What you already figured out is, that its required to create a disk image, where the blocks of the SSD are at the correct location in the disk image. I don't know where the SSD firmware gets/writes the information the for the block translation. Maybe you found already such information? We can also exclude the wrong duplicate blocks when we know, how the translations works.


Best regards
Elmar
22
HFS+ Rescue / HFS on SSD, logical page map with duplicates
« Last post by peterpion on September 14, 2019, 17:08:44 PM »
Hi Elmar,

I have an interesting(ish) problem I have been working on for a while. I had a SSD with a hackintosh installed on it (IE OSX on PC hardware) and the SSD stopped working, probably because of a poweroff at a bad time. The drive still responds in engineering mode (default chipset firmware) and through this and the OpenSSD project which luckily was made for my chipset (barefoot) I have been able to create a physical image of the drive. In this I found many 16kb long pages of text like cached web pages.

Analysis revealed a few percent of the drive populated with what looks like logical page numbers in a very clear pattern so I have used them to create a translation table (logical to physical address). I then used the stackbd module which I modified to allow me to mount the image as a loop device and map OS block requests to the pages pointed to by the map file. Doing it this way allows me to quickly try different mapping options to see what works best.

Having mounted what I hoped would be a reassembled logical image I tried mounting it but with no joy (I used hfsrescue to determine the partition start block and losetup to mount a range of blocks). So I ran hfsrescue on it and quite a few files have been recovered to my surprise. Many of these files were photos around 10MB in size and since the physical page size is 16k it seems that many pages being correctly placed contiguously must mean my mapping is at least partially correct (your opinion on this would be appreciated).

The big problem (I believe) is that around 5% of the page LPNs are replicated. This must be where a page has been modified and rewritten in a different place on the disk but the original page containing out of date data  (and its LPN) is not yet erased. So I assume this makes 5% of my drive corrupt. Perhaps most of these pages are ones used for directory structures, it would seem to make sense since directories are likely to have changed much more than files in the last few weeks of the disks operation (I was moving things around a lot, reorganising ready for transfer to a new backup machine :-()

Although working with the firmware and c to extract the drive has been something I have experience of understanding HFS is a different matter and I am having difficulty with it. I wonder if you have a deep understanding of it perhaps you could suggest where to go from here. I suspect the image I have is correct apart from 'holes' in it, pages of incorrect data. The volume header is found at around 14MB offset (is that normal-ish?). For instance the page that a directory uses might be replaced with a chunk of an image file as an example (the ssd moves data around internally according to wear leveling etc). Ideally I would like to examine the initial parts of the disk IE find the root directory page(s) and follow the links (references to other pages) in it to subdirectories, and then try the various pages which might be valid to see which seems right (IE the situation I have is for 5% of the logical pages of 16kb size I might have 2 to 100 copies, only one of which is the correct one, and I don't know which to use).

BTW the terminology confuses me a bit, because in the SSD firmware code project blocks are sections of 2MB or so, pages of 16kb are the smallest data size it uses. Whereas in OS programming blocks seem to be 512 bytes etc. I hope you understand what I mean above.

Perhaps my mapping is totally wrong and your program is just reassembling randomly placed 16kb pages on the disk - is it capable of this? I am also working on discovering where the drive stores expired page information but so far I have not found it (this was of course my first choice but it just does not seem to be there, perhaps it uses a scheme too complicated for me to figure out by looking at bytes with no context).

I am wondering if I can figure out for a few blocks which are the correct ones manually, it might give me a clue as to how to identify valid from expired blocks.

My tools BTW are mainly c and hex editors, the easiest ways of working have seemed to be writing small c programs to do the searching etc.

Anyway thats it for now, your thoughts would be appreciated if you have the time!

Kind regards, Pete
23
HFS+ Rescue / Re: hfsprescue - stuck at step 2
« Last post by toto on September 14, 2019, 10:17:27 AM »
Maybe I have a solution:
I stopped step 1 after about 450000 files when the filecount did not seem to change any more.
Step 2 was successfull and now I am running step 3, which will take longer.

I will report the results soon.
24
HFS+ Rescue / hfsprescue - stuck at step 2
« Last post by toto on September 14, 2019, 09:52:30 AM »
Hello,

I am trying to recover a 2.7 TB harddrive of a workmate.
Step 1 was successfull (after 14 hours) but now at step 2 I have problems:
The process stucks at "Hashing file entries": the filesize of fileinfo.sha stopps at 16384 Bytes, the processor has 100% workload and I tried it now for more than 24 hours.
If I start step 1 and kill the process after e.g. a few minutes step 2 has no problems. I tested the other steps, too. So I could recover somer files. Now with the whole partition it does not seem to work.

Do you have any ideas?
Thank You
Thomas

Here is the log of step 1:
Code: [Select]
hfsprescue 3.4 2018/02/16 by Elmar Hanlhofer https://www.plop.at

Command: ./hfsprescue_x64 -s1 /dev/sda2

Start: 2019/09/12 14:24:57

Signature:                      0x2b48, H+
LastMountedVersion:             HFSJ, last mount by Mac OS X.
FileCount:                      607944
DirCount:                       100453
BlockSize:                      4096
TotalBlocks:                    732480620
AllocationFile StartBlock:      1
ExtentsOverflowFile StartBlock: 79700
CatalogFile StartBlock:         1035604
Total size:                     2794 GB

actual file sizes:
Code: [Select]
total 2629176
drwxr-xr-x 1 root root          9 Sep 14 07:33 .
drwxrwxr-x 1 1000 1000          7 Sep 14 07:32 ..
-rw-r--r-- 1 root root      16384 Sep 14 07:33 fileinfo.sha
-rw-r--r-- 1 root root 1205360006 Sep 13 04:52 filesfound.db
-rw-r--r-- 1 root root   10102325 Sep 13 04:52 foldertable.db
-rw-r--r-- 1 root root          9 Sep 13 04:52 parameter-s1
-rw-r--r-- 1 root root 1476780188 Sep 13 04:52 s1.log
-rw-r--r-- 1 root root          0 Sep 14 07:33 s2.log
-rw-r--r-- 1 root root          1 Sep 14 07:33 utf8len
25
HFS+ Rescue / Re: Can't find my files, wrong offset ?
« Last post by Elmar on September 13, 2019, 19:30:00 PM »
Difficult situation, especially I am not in front of your computer. I am sure, you would have said if it is the case, but anyway I ask.  Did you use any encryption or other security methods or another coding than UTF-8?

What OS version was running?

If you not already did, then buy an external USB drive and make a sector based copy of the defect drive. I will give you support for the copy process.
26
HFS+ Rescue / Re: Can't find my files, wrong offset ?
« Last post by malakov on September 13, 2019, 14:51:47 PM »
I wanted to save my whole disk, but I mistakenly formatted the source disk  ;D
So, the partition was formatted. Once I realized that, I just unplugged the disk. I haven't copy or installed anything on it, in order to be able to recover my files.
There is only one partition on the disk, that tooks all the available space, 3Tb. So I guess that invalidates the "wrong partition has been scanned" possibility.
so, remains :
- the partition table is defect and not the whole partition has been scanned : I think the whole partition was scanned, since your programs cleverly displays the amound of data scanned. And it scanned almost 3Tb, which should corresponds to all the disk.
- my program is not able to detect your files : maybe, but I really hope not  ;D. So far, your program is the most promissing, and seems the most serious software available for HFSP partitions. If yours can't, I guess none can. Which would be a pity cause it's not just some songs or party photo's, it's my work, my job on it. I erased it all be mistake, thinking I was formatting my new disk to save all my precious work.
27
HFS+ Rescue / Re: Can't find my files, wrong offset ?
« Last post by Elmar on September 13, 2019, 09:56:52 AM »
Okay, when other files have been found but not yours, then this means that either

the wrong partition has been scanned
or the partition table is defect and not the whole partition has been scanned
or my program is not able to detect your files


What was the reason for the defect file system?
28
HFS+ Rescue / Re: Can't find my files, wrong offset ?
« Last post by malakov on September 13, 2019, 09:45:30 AM »
I mean my personnal files :)
I find files on the drive, like usual working files from different softwares, but not my datas.
For example, I'm searching for some JPG files, but I can only find 4 JPG, all belonging to a software (background.jpg for example).
That's why I think I'm mis-using your soft and thought of a wrong offset.
29
HFS+ Rescue / Re: Can't find my files, wrong offset ?
« Last post by Elmar on September 09, 2019, 17:50:00 PM »
Do you mean with "my files" you personal files or any file on the drive?
30
HFS+ Rescue / Re: Can't find my files, wrong offset ?
« Last post by malakov on September 09, 2019, 15:37:20 PM »
Yes, that's what I did, that was my introduction sentence : "I've been throught the first and second step" :)
s1 took about 11 hours.
s2 was almost instant.
Then I used --list, and I can't find any of my files.
Pages: 1 2 [3] 4 5 ... 10