I've come across license systems that are somehow tied to the storage medium. While basing this on the UUID on the filesystem is fairly straightforward, I do not believe this is the case (see below). A typic example of this behaviour goes as follows:

  1. On each boot, an id-file is generated.
  2. The system will check a key-file for a license. If the key matches the id, then all good.
  3. If no key, or if the key doesn't match the id (as in, copied from a different system), the license is not valid.

I've observed the following behavior:

  • Completely wiping the CF card and reinstalling results in the same id file being generated, thus no new key file is required.
  • Using the same key on a different CF does not work, as it does not match the contents of the new id file.

This leads me to conclude that there is a way of getting a unique id of the CF card somehow. How can one achieve this in linux?

PS: I've purposefully left out any details of the product itself, as I'm wondering more in general terms how a system like this can build a unique id of the CF card.

  • 2
    Typically, wiping the CF card will not change the UUID so your experiment isn't complete (if I'm understanding your post) without changing the UUID (you can use gparted to easily do this from the r-click menu). As for other ways to generate this information, MS uses the hardware configuration, iirc. Also, it's feasibly easy to embed keys, etc. in device firmware (read privacy concerns about embedded firmware). – nonzyro May 18 '16 at 10:09
  • Your answer may be here : Reading Internal SD Card Information. Look for the internal card registries in /sys/block/mmcblk0/device/ (YMMV). – harrymc Sep 7 '16 at 11:54
  • As nonzyro said, it may yet by the UUID. Could it be tied to the drive's serial number? – Adam Wykes Sep 9 '16 at 4:18

The card will have lots of information registered in a read-only manner.

The article Reading Internal SD Card Information has this to say :

Internal SD Card Information

Information about an SD card is encoded in its internal card registries. One of these is the Card Identification (CID) Register, a 16 byte code that contains information that uniquely identifies the SD card, including the card serial number (PSN), manufacturer ID number (MID) and manufacture date (MDT). The CID register is set when the card is manufactured and cannot be changed after it is set. (According to SD card specification the information is only to be written once, however if a card does not conform to the specification this information could be changed!)

How to read the CID from an SD card

One way to read the CID is to use a laptop with an SD card slot. Card readers in laptops are usually connected directly through the PCI bus (or IDE bus). This will not work through a USB card reader because the command to retrieve the card information is intercepted and not understood by card readers. Not all computers with built-in card slots will work, some internal card readers are connected through a USB bus.

Assuming you have the proper hardware, there are several methods you can use to get the card information. With Linux, reading the internal SD card information is simple. Insert the card and look under /sys/block/mmcblk0/device/ (this location may change depending on your device). You will see several attributes available that include the CID register and the information inside it.

  • Some cards' CID can be changed - see this and this – itsho Sep 4 '18 at 13:51

As others have commented, it could be related tot he way the CF card has been erased, but more likely the software is identifying the CF card based on firmware in the card -

This information cab typically be read using "udevinfo" - for example, if the CF card is /dev/sdb udevinfo -a -p $(udevinfo -q path -n /dev/sdb) - this will most likely include enough information to uniquely identify the card.

Note: on debian based distros udevadm info replaces udevinfo :

udevadm info -a -p $( udevadm info -q path -n /dev/sdb )

  • 1
    On some distros (Ubuntu here) replace udevinfo with udevadm info, e.g. udevadm info -a -p $( udevadm info -q path -n /dev/sdb ). That said, it just did not provide expected CF card ID information through my two USB card readers. – Stéphane Gourichon Jun 23 '17 at 9:10

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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