Recent Posts

91

HFS+ Rescue / Re: HFS on SSD, logical page map with duplicates

« Last post by peterpion on September 30, 2019, 20:20:22 PM »

Hi Elmar,

No worries I appreciate you looking. I have made some progress since I posted last, now I can mount the disk, but I am unable to descend into some folders (because I assume their directory files are the wrong blocks).

BTW I am looking into finding the main translation table on the disk but if I don't find it, I wonder if there is an easier way.

My idea is to modify HFS rescue to let it choose the logical blocks that make sense to it. IE load it with an array (that I already have made) of the alternative data blocks, it can try them one by one to see if any 'make sense' to it.

You see the problem is that for 4% of the sectors on the drive, I have several possible blocks of data that might be the right ones. I don't know which to choose from. For instance sector 724557 (as the linux OS sees it) might actually be physical block 1298322, 932022 or 331922 in my image file. I have the 'spare' sectors saved in a different place. The 'wrong' copies will have been overwritten with other files, so in some cases I am sure it will not be possible to differentiate between right and wrong, but if I can do that for the file structure (directory information) that would be great.

The reason is that the drive can actually store 274GB of raw data but only shows 256GB of this to the operating system usually.

Anyway as I say as the author of HFS rescue I wonder if you could say if this would be possible. If not, it would save me time looking through the code and trying to make the modifications but if you say yes it would be possible and give me a couple of pointers as to where to code the modifications I will get working on this instead of working on finding the translation table, since it is proving very difficult.

Thanks again, Pete

92

Boot Managers / Re: Unable to mount SD card

« Last post by Elmar on September 30, 2019, 17:15:48 PM »

You don't have to compile a custom image.

Is '/boot' on an own partition?
What files are in '/boot'?

93

Boot Managers / Re: Unable to mount SD card

« Last post by Brettvan on September 30, 2019, 17:01:50 PM »

Hi Elmar,

Thanks for the reply.

I am using the plopkexec bootmanager to try and boot the SD card.  Based on another thread, it looks like it's possible.

https://forum.plop.at/index.php/topic,1892.0.html

I am just having troubles with understanding how to do the custom setup. like adding the bootup files to the /boot directory?  is that on the SD card or on the plopexec image?  Is this a custom image i have to compile?  Thanks,

here is the error message in the booting log:
Can not mount /dev/mmcblk0
...
Can not mount /dev/mmcblk0p1

94

Boot Managers / Re: Unable to mount SD card

« Last post by Elmar on September 30, 2019, 08:27:17 AM »

Hello,

are you sure that you talk about the Plop Boot Manager and not about PlopKexec? The Plop boot manager has no shell.

Best regards
Elmar

95

Boot Managers / Unable to mount SD card

« Last post by Brettvan on September 29, 2019, 16:36:49 PM »

Hi

I am trying to boot my Linux MX on my SD card using an old IBM Lenovo ThinkPad t410.

I problem is that when I load up plop boot manager it fails to mount the SD card. It looks like the SD card has a EXT 4 partition and should be mountable but fails. How do I work around this so I can boot SD card? Is there a way to do this within the shell and boot it in a roundabout way?

Thanks Brett

96

HFS+ Rescue / Re: hfsprescue - stuck at step 2

« Last post by Elmar on September 29, 2019, 11:40:21 AM »

Hello,

With the above mentioned way I could recover nearly everything of the partition.

Excellent

Best regards
Elmar

97

HFS+ Rescue / Re: HFS on SSD, logical page map with duplicates

« Last post by Elmar on September 29, 2019, 11:36:50 AM »

Hello,

unfortunately, I had no time to look at your files. Maybe next week.

Best regards
Elmar

98

Boot Managers / Questions about your project "New boot manager"

« Last post by Picobot on September 21, 2019, 01:06:10 AM »

Hi Elmar,

I have two questions about your new project:

Will the new manager contain it's own NVMe driver ? E.g. will it be possible to boot from a NVMe SSD, even if the system does not support NVMe at all or does support booting from NVMe only in UEFI mode ( and not in CSM / legacy mode ) ?

Will the GPT support include the possibility to "hide" not only MBR partitions, but also GPT partitions by setting the corresponding flag in the GPT entry ?

Thx in advance for your clarification and keep up the good work.

C.U. Picobot

99

HFS+ Rescue / Re: HFS on SSD, logical page map with duplicates

« Last post by peterpion on September 17, 2019, 18:08:22 PM »

BTW today I did a little sanity checking, to see if there is evidence my LBA translation seems reasonable. I searched in the translated disk (the virtual device that is the remapped raw disk, translated by the logical mapping I just described above). I looked for the string HTML and choose a good looking one, taking the byte offset. Dumping the next 16384*16 bytes showed what seems to me to be a contiguous block of 256 kb of text which I attach. It reads fine and at the transitions from block to block (at byte offset 16384*n) there is no hiccup - ie it seems to be a faithful replication from what I have read so far of a large original file. Looking at the physical block numbers this came from they are jumbled up considerably:

Physical block numbers:
5213129
12801290
9342987
3414209
384582
1935015
2493452
4813293
12883118
11505071
4423568
3267107
6689989
384646
11505103
5988372

So in other words the mapping scheme I have described above is able to take these physical block numbers and organise them properly, so with 16 contiguous blocks arranged correctly from completely jumbled up original orders I am fairly sure this is correct and working.

Still the problem is for some of the LBAs I have more than one potential physical address it could be meant to point to. None in the above example but I find 700k or so during the creation of the physical to logical mapping.

As an example LBA 12345 might be mentioned 5 times in the LBA identification blocks scattered around various superblocks. So I end up with having to choose from these 5 possible physical addresses - at some point in the past every one of them will have been used as LBA 12345 but which is the latest I don't know.

One intriguing thing is that after the list of 128 LBAs in the LBA identification block there is another list of 32 bit values which are in the range of physical or logical block addresses. This list varies in length, sometimes there are very few, sometimes there are 128 32 bit words. However the last LBA identification block in each superblock never has this. I did wonder if it might be a list of physical addresses that the current block supersedes, but the problem is if that is the case how come the last LBA identification block never contains it? Because of this I have not bothered yet trying to use it to identify stale LBAs but I think I probably should try to code it and see whether it does resolve many of the duplicates. It also shares the 128 bit validity header I mentioned in the previous post.

Cheers, Pete

100

HFS+ Rescue / Re: HFS on SSD, logical page map with duplicates

« Last post by peterpion on September 17, 2019, 17:48:57 PM »

OK so this file comes from what I call 'superblock' 37. A 'superblock' is 16384*32*128 bytes. The superblock is broken into 32 subunits around 2MB each in size. Each of these has its 16384 byte LBA identification block at the end, preceded by 127 blocks of data each 16384 bytes in size.

So you will see that if we print the initial 100 bytes of the last 16384 byte block (the LBA block) the first 2 bytes are 0x2500. The order is reversed so this is 0x0025 or 37 (for superblock 37). I check this to identify data blocks, blocks without this contain junk.

xxd -s $((16384*127)) -l 100 elmarsfile
01fc000: 2500 7f00 7f00 0000 ffff ffff ffff ffff  %...............
01fc010: ffff ffff ffff ff7f 4d06 da00 5d06 da00  ........M...]...
01fc020: d25d 9c00 065e 9c00 0a5e 9c00 205e 9c00  .]...^...^.. ^..
01fc030: 305e 9c00 4a5e 9c00 5a5e 9c00 635e 9c00  0^..J^..Z^..c^..
01fc040: 785e 9c00 8b5e 9c00 915e 9c00 ab5e 9c00  x^...^...^...^..
01fc050: ae5e 9c00 d85e 9c00 9e60 9c00 c360 9c00  .^...^...`...`..

After this we have 7f00 7f00 - I have not found a meaning for this yet.

Then we see ffff ffff ffff ffff ffff ffff ffff ff7f which make more sense if we convert it to binary and reverse each 8 bit byte after doing this:

1111 1111  1111 1111  1111 1111  1111 1111  1111 1111  1111 1111  1111 1111  1111 1110 

It turns out that if a LBA appears twice in the subsequent list (which I describe next) then the first occurrence of it is marked here by a 0. So if LBA no 1234 is at position 5 and then also 10 in the subsequent list, bit 5 will be 0.

After this 16 bytes, the list of LBAs starts and is 512 bytes long, consisting of 128 32 bit words. Each work is again backwards, as I see it anyway, so the first one you see in the above print out '4d06 da00' is 0xDA064D or 14288461. This is the logical block number for the first 16384 byte data block in the bin file I posted, from byte offset 0 to 16383.

The next 4 byte word in the print out is '5d06 da00' = 0xDA065D = 14288477. This is the logical block number of the next 16384 data block in the posted bin file from byte 16384 to byte 32767.

And so it goes on for 127 * 16384 byte blocks, with block 128 being the identification block.

Then this repeats a total of 4096 times for the entire disk.