19

On the official raspberrypi.org forum, "Dom" - a moderator wrote:

I've fudged my board to have your serial number

How do I edit the serial number of a Raspberry Pi?

  • 5
    1. Why? Why not? Isn't learning things the whole point of the PI? – Another Simon Jan 9 '13 at 1:10
  • 4
    2. Re stealing - my time is worth more than the 2 pounds I would save, but I'm sure you meant the generic "You" – Another Simon Jan 9 '13 at 1:16
  • 3
    3. Dom isn't magical, but is very knowledgable. Did he use a Pi version of the old HP setsys boot floppy, or write data to one of the GPIO pins, or something else? That is my question. – Another Simon Jan 9 '13 at 1:21
  • 3
    I've updated my answer and added an apology. We're not here to discuss the morality of things. We're here to ask questions and get answers. Also upvote as it's a very good question. – Vincent P Jan 9 '13 at 5:48
  • 2
    Why not compile a custom kernel that returns whatever serial you like at /proc/cpuinfo? Not sure if that would help with decoder blobs though .. – oberstet Dec 6 '13 at 1:10
9

I'm copying this from this forum thread.

Dom has access to all the source code, the Videocore debugger and many closed VC specific tools. And releasing any information to allow you to change the serial number would break the mechanism for codec licencing, so will never happen.

Additionally as posted in the thread. The only reason for changing the serial would be to copy someone else's MP4 licence and use it. As that is the security around the licensing. Your unique serial is linked to the MP4 licence, so even if someone got your licence key, they will be unable to do anything with it (unless they could change the Raspberry Pi's serial number.

UPDATE: To answer the actual question. I'd say that as Dom has the source for the actual low level firmware. I'd imagine that he is really just changing the source code that reads the serial and forcing it to return a different value. I honestly doubt that it was actually changed (on the CPU I mean), more like he changed some of the firmware code to return a different serial. Also apologies to the asker, we all just gave you a "Why? Thats not nice. Your stealing" instead of answering the question. My bad.

  • 2
    Thank you for your apologies and your attempt at answering the question. "I'd imagine that he is ..." type answers are great for discussion purposes, but the accepted answer will hopefully be in the form of "It is done via the xyz utility which is only available to Broadcom employees..." etc. – Another Simon Jan 9 '13 at 6:27
  • 2
    I'm a little surprised that the assumption that the serial number would only be changed for nefarious purposes is so prevalent on a Linux device. I'd like to switch it around to "why should I allow a 3rd party to identify my system uniquely"? I see it as, among other things, a privacy issue. Why? That's my business. – bobstro Jun 25 '15 at 2:37
6

As far as userspace programs are concerned, it's pretty easy to fool them and fake the contents of just about any file. For example, suppose a C program is using /proc/cpuinfo file to verify the serial number. The program is copy-protected and tied to the serial, and I don't have the source code. However, I can still run strace program 2>&1 | grep cpuinfo, which will reveal something like:

open("/proc/cpuinfo", O_RDONLY) = 3

At this point, I can create a small library, cpuinfo.so with the following function:

int open(const char *file, int flags) {
    static int (*real_open)(const char *file, int flags);
    if(!real_open) real_open = dlsym(RTLD_NEXT, "open");
    if(!strcmp(file, "/proc/cpuinfo")) file = "/tmp/cpuinfo";
    return real_open(file, flags);
}

As you can see, I'm checking if the user of the library tries to open /proc/cpuinfo, in which case I open /tmp/cpuinfo instead.

Then I will run the original copy-protected program as LD_PRELOAD=/path/to/cpuinfo.so program, and it will happily read my fake file thinking it's /proc/cpuinfo, while working correctly with the rest of the files.

Note that if the copy-protected software includes kernel objects, it will be much harder to fool, as it could access hardware directly. However, such software will also only work with the kernel for which it was built, making it quite impractical to distribute.

protected by goldilocks Dec 21 '16 at 22:39

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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