cgsecurity.org

Hi folks,

I have a precautionary question! I have bought a new external SSD (1 terabyte) and I am thinking of using a GPT partition table instead of the MBR partition table. Since my SSD has less than 2 terabytes of capacity, I could use both MBR and GPT. I read my way into the subject and saw that GPT has special security advantages over MBR, namely it has a primary and a backup GPT header, the integrity of which can be checked with CRC32 checksums.

But now I'm just wondering what happens if the GPT header was destroyed. Would an automatic repair then take place? For example, would Windows or Linux automatically restore the GPT header from the backup if my external SSD has a defective GPT header, or how should I imagine that? Could the hard drive firmware even do the repair itself? Or would you have to start the repair manually in the event of a GPT damage, for example with TestDisk?

Is TestDisk more likely to restore a GPT partition table than a MBR partition table? Does the choice of the partition table also have an impact on the security of the integrity of the file system (like NTFS), or is there no connection here?

MBR would have the convenient advantage that my smart television can also access it, unfortunately not GPT. So I wonder if GPT is so much safer that it's worth using GPT instead of MBR?

Thank you very much in advance!

mediax wrote: 24 Aug 2021, 13:50 Hi folks,

I have a precautionary question! I have bought a new external SSD (1 terabyte) and I am thinking of using a GPT partition table instead of the MBR partition table. Since my SSD has less than 2 terabytes of capacity, I could use both MBR and GPT. I read my way into the subject and saw that GPT has special security advantages over MBR, namely it has a primary and a backup GPT header, the integrity of which can be checked with CRC32 checksums.

But now I'm just wondering what happens if the GPT header was destroyed. Would an automatic repair then take place? For example, would Windows or Linux automatically restore the GPT header from the backup if my external SSD has a defective GPT header, or how should I imagine that?

I don't know. I guess there is no automatic repair. You can test that yourself by zeroing out the GPT header area.

Could the hard drive firmware even do the repair itself?

It could, be that is not its job. The job of the hard drive firmware is to mainly manage reading and writing of sectors and management of unreadable sectors. GPT repairs would require interpreting the on-disk structure. This is reserved to a higher level entity above firmware such as the operating system.

Or would you have to start the repair manually in the event of a GPT damage, for example with TestDisk?

Yes.

Is TestDisk more likely to restore a GPT partition table than a MBR partition table?

If the backup header is still readable, yes. Otherwise both operations rely on recognizing partitions correctly.

Does the choice of the partition table also have an impact on the security of the integrity of the file system (like NTFS), or is there no connection here?

No.

MBR would have the convenient advantage that my smart television can also access it, unfortunately not GPT. So I wonder if GPT is so much safer that it's worth using GPT instead of MBR?

There is one issue in favor of GPT:
Once the number of partitions grow MBR requires a chain of partition tables all over the drive between each partition. Each one requires a sector.
When a MBR style partition table is destroyed the repair requires writing partition tables between the partitions. If the beginning and end of each partition is not identified correctly Testdisk will write those partition tables into the partitions and overwriting content.
As there is no backup function in Testdisk for that operation you so that you will loose data.
But you are better off anyway to duplicate a logically broken drive even if it has no hardware defects such as unreadable sectors.

Some advantages of GPT that came to my mind:
There is no CHS data anymore. Sectors are identified by one wide numerical number, the logical sector number.
There are no complicated rules anymore that exist with MBR what the reference point is when address information has to be interpreted as relative offset.

Thank you so much for your answer!

recuperation wrote: 24 Aug 2021, 18:37 I don't know. I guess there is no automatic repair. You can test that yourself by zeroing out the GPT header area.

Ah, okay. Don't really know how to do that (which software can do that). I thought this might be documented somewhere.

recuperation wrote: 24 Aug 2021, 18:37 It could, be that is not its job. The job of the hard drive firmware is to mainly manage reading and writing of sectors and management of unreadable sectors. GPT repairs would require interpreting the on-disk structure. This is reserved to a higher level entity above firmware such as the operating system.

Thank you for clearing things up! That makes sense!

recuperation wrote: 24 Aug 2021, 18:37 There is one issue in favor of GPT:
Once the number of partitions grow MBR requires a chain of partition tables all over the drive between each partition. Each one requires a sector.
When a MBR style partition table is destroyed the repair requires writing partition tables between the partitions. If the beginning and end of each partition is not identified correctly Testdisk will write those partition tables into the partitions and overwriting content.

Ok, that's good to know. You are probably talking about the problem with extended MBR partitions? In my case, however, I would only set up a single partition, namely over the entire storage space of the SSD. So in the event of damage, TestDisk would only have to rewrite the MBR at the very beginning, if I understand correctly. Shouldn't TestDisk always be able to restore the MBR if there is only one MBR partition that extends from the beginning to the end of the storage space?

recuperation wrote: 24 Aug 2021, 18:37 As there is no backup function in Testdisk for that operation you so that you will loose data.

Since I don't intend to change the partitioning on my external SSD in the future, couldn't you somehow manually create a backup of the MBR and, in an emergency, restore it with TestDisk (or other software)? Wouldn't it be just as secure as a GPT if I were to back up the MBR?

Thank you so, so much for your support!

mediax wrote: 27 Aug 2021, 12:20 Ok, that's good to know. You are probably talking about the problem with extended MBR partitions? In my case, however, I would only set up a single partition, namely over the entire storage space of the SSD. So in the event of damage, TestDisk would only have to rewrite the MBR at the very beginning, if I understand correctly. Shouldn't TestDisk always be able to restore the MBR if there is only one MBR partition that extends from the beginning to the end of the storage space?

No. Testdisk has to find partition information like a boot sector or a backup boot sector in order to correctly restore the partition. If that information cannot be read Testdisk has no data basis to write a partition table.
The problem that it may have to write an extended MBR with a risk of writing that incorrectly right into the middle of an existing partition is a different one.
If you solve that by just using one partition on a drive you have not yet solved the first problem stated above.

recuperation wrote: 24 Aug 2021, 18:37 As there is no backup function in Testdisk for that operation you so that you will loose data.

Since I don't intend to change the partitioning on my external SSD in the future, couldn't you somehow manually create a backup of the MBR and, in an emergency, restore it with TestDisk (or other software)? Wouldn't it be just as secure as a GPT if I were to back up the MBR?

This is a very smart idea.
Use the backup function in Testdisk that appears after selecting "Analyse". This will write a file named "backup.log" If you look inside with a text editor you find all the relevant partition information of the drive you selected. Do not forget to repeat this step with each drive in your system.