1

I'm learning about the /dev filesystem. I've begun with /dev/sd* (Linux) and /dev/disk* (OS X), and I've found some interesting behaviour. If I run:

$ sudo xxd -l 1024 /dev/disk0

I get the following output:

0000000: 33c0 8ed0 bc00 7c8e c08e d8be 007c bf00  3.....|......|..
0000010: 06b9 0002 fcf3 a450 681c 06cb fbb9 0400  .......Ph.......
0000020: bdbe 0780 7e00 007c 0b0f 850e 0183 c510  ....~..|........
0000030: e2f1 cd18 8856 0055 c646 1105 c646 1000  .....V.U.F...F..
0000040: b441 bbaa 55cd 135d 720f 81fb 55aa 7509  .A..U..]r...U.u.
0000050: f7c1 0100 7403 fe46 1066 6080 7e10 0074  ....t..F.f`.~..t
0000060: 2666 6800 0000 0066 ff76 0868 0000 6800  &fh....f.v.h..h.
0000070: 7c68 0100 6810 00b4 428a 5600 8bf4 cd13  |h..h...B.V.....
< ... >

A little Googling seems to identify this as the start of an MBR (I have Bootcamp installed).

However, the following doesn't work:

$ sudo xxd -l 1000 < /dev/disk0
-bash: /dev/disk0: Permission denied

My questions are:

  • Many applications hide critical sections of disks (e.g. MBR, file system inodes, partition boundaries, etc). Is the output from xxd a true low-level dump of a device? Am I seeing everything byte-by-byte on the device?
  • As /dev/disk0 clearly contains data, why can I not use it as a stdin stream?

3 Answers 3

4

Many applications hide critical sections of disks (e.g. MBR, file system inodes, partition boundaries, etc).

Which applications?

It's not an application thing; it's usually the operating system that deals with file systems and disk partitioning.

Is the output from xxd a true low-level dump of a device?

More like medium level, but yes. You're seeing the raw data exactly as the OS has written it, and exactly as the OS will read it back. There's usually a MBR in the first 512 bytes, often a GPT in the next few kilobytes, and somewhere at sector 63 (old) or 2048 (new) you'll see the filesystem structures of the 1st partition.

A true low level dump would mean data as the disk controller has written it: not just the OS-readable bytes, but also wear-leveling data, SMART failure records, perhaps encryption keys. But it's invisible to the OS, and you generally cannot access it directly using any program – only by using specialized data recovery hardware.

(That said, some flash devices are an exception; they have no disk firmware the OS does everything – e.g. the jffs2 filesystem manages flash wear-leveling at OS level.)

Am I seeing everything byte-by-byte on the device?

Yes, you're seeing it the same way an operating system sees it.

As /dev/disk0 clearly contains data, why can I not use it as a stdin stream?

Of course you can. In fact you did use it as a stream in your first example; the only difference is that in the first example xxd was the one calling open("/dev/disk0"); meanwhile, in your second example that was done by your shell (sh, bash, zsh).

But that difference is what causes the error message. But it has nothing to do with you trying to read a disk; the "Permission denied" literally means that you cannot open /dev/disk0 because you must be root to do so.

(This has been answered many times on this site. Here, here, here, here, here, and here.)

To expand on the previous, stdin/stdout redirection happens by having the shell open the file before it starts the program. So in your first example, sudo xxd /dev/disk0 first uses sudo to run xxd /dev/disk0 with root privileges.

But when you run sudo xxd < /dev/disk0, the redirection < /dev/disk0 is still processed by your unprivileged shell; sudo xxd hasn't run yet.

Use sudo sh -c "xxd < /dev/disk0" to have the entire command be processed as root.

3

I don’t know about your first question, but judging by the man page for xxd, it looks like that’s probably the case.

For the stdin question, you can indeed redirect /dev/disk0 to programs that accept stdin. The problem you're seeing is that sudo doesn't perform the redirection itself, so the access to /dev/disk0 is based on your regular user’s permissions.

See Stack Overflow and this question for options.

-2

for me, it is not clear what you want to do. PErhaps this might help you. If you want to access the disk raw data the program dd is the right way. With dd you can copy out the MBR or the whole disk.

ciao ryder

You must log in to answer this question.

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