2

I'm working on an embedded project. I need a place to store some filesystem-independent meta information on a storage device. The device has an MSDOS partition table. The device also may have unallocated space (depending on its size) but it will be TRIMmed (and also may be blown away by new partitions in the future).

I need a location on the device that is not unallocated and that has a low risk of being touched (outside of completely erasing the device). The device is only guaranteed to have an MBR at the point the meta data needs to first be written; meaning there are no EBRs/VBRs present that I could use.

There are 446 bytes at the very start of the device available for MBR bootstrap code. Currently my only idea is to store data at the end of this block. However, the device is bootable and I have no way of knowing if I'd be blowing away bootstrap code or not.

The sector size is 512 bytes and the MBR is the first sector, I'm pretty sure (correct me if I'm wrong) that that means the second sector is available for use by partition data, so I can't use that either.

Does anybody have any ideas? I need 4 bytes of space.

1

Windows NT uses a 32-bit disk signature to identify individual MBR-partitioned disks, and stores it as six bytes starting with 440 [01B8h] (four bytes containing the signature and two zero bytes). This leaves 440 bytes for the bootstrap code.

The disk signature was first introduced with Windows NT 4 (and became required on MBR disks starting with Windows Vista). Since then is also used in a similar way to GPT's "disk UUID" by non-Windows systems (Linux and GRUB support it).

Because of that, many bootloaders limit their bootstrap code in the MBR to 440 bytes, to avoid overwriting the disk signature. (I just verified that both GRUB and Syslinux do.)

There is a good chance that the bootloader used by your device also leaves the disk signature untouched. Check if the two bytes starting at 444 [01BCh] are 00 00 – if they are, then the other four are likely to remain unchanged unless the entire partition table is blown away, or unless new bootstrap code larger than 440 bytes is installed.

  • Ninja'd by @JasonC's own comment by two seconds. Damn it. – grawity Nov 1 '13 at 19:27
  • Thanks. Those two bytes are 00,00, and there is four bytes of nonzero data before it. 436-439 it is. Also thanks for the info about the signature requirements on Windows, I wasn't sure when that became common practice, good to know. – Jason C Nov 1 '13 at 19:28
  • 1
    @JasonC: Yes, and the disk signature is exactly where I'm suggesting to store your data. 436-439 is still part of the bootstrap code. – grawity Nov 1 '13 at 19:31
  • 1
    @JasonC: It won't (there still are many disks with the "disk signature" area filled with bootstrap code). However, if the signature changes, Windows may recognize the disk as a completely new device (although it might be ignored for removable storage, and is just a minor inconvenience at most anyway). ⫽ In that case, Naib's idea of using the actual bootstrap code area might be even better, if the device itself has different methods of booting. – grawity Nov 1 '13 at 19:36
  • 1
    @JasonC: …alternatively, set those final two bytes to something other than 00 00, which should make Windows think the disk has no NT signature at all and that the bootstrap code extends to the full 446 bytes. (I am not sure when the signature is written – perhaps only during OS installation, as Windows wouldn't want to corrupt the existing bootstrap code when someone merely plugged in the device.) – grawity Nov 1 '13 at 19:39
3

the MBR contains the partition table as well as the boot code

Bootcode: 446bytes Primary paritions: 64bytes Sig: 2bytes

Is the storage going to be used to boot from? it might be worth considering "corrupting" the bootcode within the MBR to store that metadata The bootcode is only really used at boottime

  • 1
    Thanks. That was my thought as well. It is booted from. However, I just realized that it's not being run on an x86 device and the bootstrap code is meaningless anyways, it is being run on an OMAP device and I just consulted the boot process documentation and confirmed that it skips the MBR bootloader and simply searches for the first FAT32 partition. Also according to en.wikipedia.org/wiki/Master_boot_record Windows sometimes uses bytes 440-446 as an optional device signature. I believe, then, I can safely use bytes 436-439 in the MBR to store my data without the risk of interfering. – Jason C Nov 1 '13 at 19:26
  • I'm marking grawity's answer as correct since he included info about the disk signature, but I wish I could accept more than one answer. Thanks again. – Jason C Nov 1 '13 at 19:30
1

The only truly safe way to store your data is in a partition of its own. Given your needs, the partition can be tiny (one sector). Storing the data outside of a partition runs the risk of it being overrun or of your data overwriting something important. Given that it's only four bytes, taking over the partition table's serial number, as grawity suggests, is probably the safest of the out-of-partition options, but I wouldn't recommend this, especially not without more context, because the serial number is used by some tools, so taking it over might conceivably cause problems if you rely on something that uses the serial number.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.