How can I do a GPT (Guid Partition Table) sector raw backup with `dd` like in a UNIX/Linux-MBR fashion?

Question

I want to "raw copy" with dd the critical GPT (~ Guid Partition Scheme) bytes of my computer's main hard drive, to an arbitrary file.

I tried to do the equivalent MBR/Unix/Linux in my Mac (with sudo of course), but didn't work: "Operation not permitted".

("In UNIX and GNU/Linux you can use dd command to backup your MBR from a console":
dd if=/dev/xxx of=mbr.backup bs=512 count=1 )

My try on my Mac (even with sudo):

    % sudo dd if=/dev/disk0 of=mbr.backup bs=512 count=1
    Password:
    dd: /dev/disk0: Operation not permitted
    % sudo dd if=/dev/disk1 of=mbr.backup bs=512 count=1
    dd: /dev/disk1: Operation not permitted

My system devs (diskutil list):

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI ⁨EFI⁩                     314.6 MB   disk0s1
   2:                 Apple_APFS ⁨Container disk1⁩         500.0 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume ⁨Macintosh HD⁩            24.4 GB    disk1s1
   2:              APFS Snapshot ⁨com.apple.os.update-...⁩ 24.4 GB    disk1s1s1
   3:                APFS Volume ⁨Macintosh HD - Data⁩     374.7 GB   disk1s2
   4:                APFS Volume ⁨Preboot⁩                 2.7 GB     disk1s3
   5:                APFS Volume ⁨Recovery⁩                1.1 GB     disk1s4
   6:                APFS Volume ⁨VM⁩                      24.6 KB    disk1s5

You have to unmount (not eject) the disk first. Since you booted from it, you can't unmount it. You'll have to do this via recovery — Allan, Aug 3 at 19:26
@Allan Ok. So just diskutil umount disk0, booted the computer with CMD+R (as the recovery booting will be from a partition that allows me treat my usual main working partition as secondary in this context?). Are the mentioned MBR (bs=512 count=1) parameters correct to apply also to this GPT "extraction"? — nostromo, Aug 3 at 19:35
It feels like there's a disconnect here with what you're trying to do and your present skill level - this is not a knock on you in any way. What I am suggesting is that prior to undertaking this on your Mac, you should test this with a drive you don't care if it gets corrupted. Maybe a VM is a better choice? — Allan, Aug 3 at 19:52
I am aware of the danger of this (any extra hints on this are also very welcome). The thing is that precisely I am studying the boot sector, boot loaders, etc. And I want to extract it and see with an hex editor how that looks like. I saw that dd is a very dangerous command, but at least for my understanding, the most critical field of it is the output part: of=[anything-here-will-be-overwritten] (agree? Did I leave something?). Doing the "tries" above, I first thoroughly typed the command string in an editor and then copied to the zsh terminal (yes, very tense moments). — nostromo, Aug 3 at 19:59
Why not install a fresh, bootable copy of macOS onto an external drive, use dd to make an image of that then you can use your editor to your hearts content? You get to experiment with a GPT/APFS formatted device without putting your working drive at risk. Plus, you don't have to disable security, unmount existing volumes, boot to something else, etc. etc. etc. — Allan, Aug 3 at 20:15

nostromo · Accepted Answer · 2023-08-09 17:37:13Z

You will get what you want, easily:
(be VERY CAREFUL as other commentators cautioned. Not just with the of= part. Also wrong parameters in bs= or count= can be dangerous. Also copy/pasting from text editors, missing important lines [i.e. only passing if= and of= leaving the rest]).

First, we need to address two key misconceptions:

You have to focus on disk0, which is your main physical drive volume. disk1 is an image of disk0s2 APFS container (from physical drive volume disk0).

Focusing "just" on disk0, is not enough as disk0 is the whole volume. What you need is partition number 1 (EFI). So your target would be: disk0s1.

This is why:

sudo dd if=/dev/disk0 of=mbr.backup bs=512 count=1

was wrong. The correct command would be (naming arbitrary destination i. e. "mbr_disk0s1_EFI.backup"):

sudo dd if=/dev/disk0s1 of=mbr_disk0s1_EFI.backup bs=512 count=1
Password:
1+0 records in
1+0 records out
512 bytes transferred in 0.000851 secs (601645 bytes/sec)

ls 
mbr_disk0s1_EFI.backup

Extraction of desired sector, done.
Now, just use the xxd command piped with less (or your favourite hex editor) against the file resulting from your extraction:

xxd mbr_disk0s1_EFI.backup | less

Voilá, here you have the hex dump you were looking for:

00000000: 1faf 112a ba1d 6c18 7ef3 240a ba1d 6c18  ...BSD  4.4... .
00000010: 0a0c 0000 0a0c 0000 2000 1000 0000 240a  ........ .......
00000020: 112a 240a b7ca 0000 7ef3 a31c 0200 0000  .,..K...........
00000030: fdfb 0600 0000 0000 0000 112a 0000 0000  ................
00000040: 0000 fdfb 1766 ba1d 4649 2020 2020 2020  ..)..._EFI      
00000050: 240a 4641 a31c 112a 240a 7ef3 112a 7ef3    FAT32   .1....
00000060: 112a fdfb b7ca 0000 6c18 fdfb b7ca fdfb  .|......^.......
00000070: 0a0c c074 7ef3 0a0c fdfb 112a a31c 240a  ...t.......0....
00000080: 7ef3 a31c b7ca 112a 7ef3 112a 7ef3 fdfb  ...non-sy$tem di
00000090: a31c fdfb 240a 112a fdfb b7ca 6c18 240a  sk..Press any ke
000000a0: 7ef3 0a0c a31c 240a 1faf 7ef3 0a10 0000  ..y to r boot...
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................

The output you have presented is the boot sector of the FAT32 filesystem stored in the EFI partition. THE ARE NO OPERATING SYSTEMS WHICH BOOT USING THE CODE STORED IN THIS SECTOR! This includes Windows, Linux, OS X and macOS. In other words, you answer is completely wrong. — David Anderson, Aug 9 at 20:19
Mr. @DavidAnderson, I would really appreciate if you could post a correct answer. I tried to apply same method for extracting mbr from a Linux system (I did it in VBox and for Linux worked. And yes, had to be done directly on sda ["total volume"], not in. i.e, sda1). Sure makes completely no sense assuming same architecture between MacOS and Linux, but what I want is: an step by step guide to extract an hex dump viewable from an hex editor where I can see boot sector things. Who knows? Reset vectors, etc. I am a rookie. Starting with all this. Expected: "You should do this: 1. ... 2. ....". — nostromo, Aug 10 at 6:47
The answer you first posted in the previous days and deleted yesterday, was probably with great intention but was not clear enough for me. Too generic to my taste. Watching your reputation and posts, looks very clear you are an expert in the matter and probably out of patience on rookie eternal/same trivial questions. But just things like "you are completely wrong", are quite discouraging. Taking advantage of my "answer"'s scheme, could you do the equivalent correct one? Just a straight replication on your machine. Also some clarification where the wrong path was and where the good one is? Thx — nostromo, Aug 10 at 6:55

David Anderson · Accepted Answer · 2023-08-11 13:24:48Z

The SIP problem described by the OP occurs with High Sierra through Monterey. Apparently, Ventura does not have this problem.

You will get what you want, easily:
(be VERY CAREFUL as other commentators cautioned. Not just with the of= part. Also wrong parameters in bs= or count= can be dangerous. Also copy/pasting from text editors, missing important lines [i.e. only passing if= and of= leaving the rest]).

First, we need to address two key misconceptions:

You have to focus on disk0, which is your main physical drive. The APFS container disk1 is stored in the partition disk0s2 (which is a slice of physical drive disk0).

The block special file /dev/disk0 can not be read by the dd command while SIP is enabled under Monterey. This answer assumes you have booted to macOS Recovery for Monterey.

This is why:

sudo dd if=/dev/disk0 of=mbr.backup bs=512 count=1

while booted to Monterey was wrong. The correct command, while booted to macOS Recovery for Monterey, would be (naming arbitrary destination i. e. "/Volumes/Macintosh\ HD\Users/Shared/mbr_disk0.backup"):

cd /Volumes/Macintosh\ HD/Users/Shared
dd if=/dev/disk0 of=mbr_disk0.backup bs=512 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.000851 secs (601645 bytes/sec)

ls *.backup
mbr_disk0.backup

Extraction of desired sector, done.
Now, just use the xxd command piped with less (or your favourite hex editor) against the file resulting from your extraction:

chroot /Volumes/Macintosh\ HD xxd /Users/Shared/mbr_disk0.backup | less

Voilá, here you have the hex dump you were looking for:

00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 00fe  ................
000001c0: ffff eefe ffff 0100 0000 050c 4707 0000  ............G...
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.

Or, you could boot back to Monterey, then use the xxd command piped with less (or your favorite hex editor) against the file resulting from your extraction:

cd /Users/Shared
sudo chown ${USER}:staff mbr_disk0.backup
xxd mbr_disk0.backup | less

Note: My drive is 500.1 GB (122096646 sectors) in size. The OP's drive is approximately 500.3 GB in size. Therefore the size value stored at 0x1CA through 0x1CD will be slightly larger for the OP's drive.

How would you proceed using dd? And also, could you explain a little bit that complex shell/code line? — nostromo, Aug 3 at 19:38
Is "raw" equivalent to the dd thing? At least looks less risky? Like simply reading to a file the content of a database image of the boot portion I am looking for? I don't mind using the for loop. It even looks ultra fancy. Where can I learn this sorcery? Can you explain a little bit? I am looking for the the rod, not just the fish. — nostromo, Aug 3 at 21:11
Well for macOS, the boot portion is not stored where you are looking. Start by looking at disk1s3. — David Anderson, Aug 3 at 21:46

Stack Exchange Network

How can I do a GPT (Guid Partition Table) sector raw backup with `dd` like in a UNIX/Linux-MBR fashion?

2 Answers 2

The SIP problem described by the OP occurs with High Sierra through Monterey. Apparently, Ventura does not have this problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged
macos
disk-utility
partition
boot
guid
.

Hot Network Questions

How can I do a GPT (Guid Partition Table) sector raw backup with `dd` like in a UNIX/Linux-MBR fashion?

2 Answers 2

The SIP problem described by the OP occurs with High Sierra through Monterey. Apparently, Ventura does not have this problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged macosdisk-utilitypartitionbootguid.

Related

Hot Network Questions

Not the answer you're looking for? Browse other questions tagged
macos
disk-utility
partition
boot
guid
.