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? Commented Jan 9, 2013 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" Commented Jan 9, 2013 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. Commented Jan 9, 2013 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
    Commented Jan 9, 2013 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
    Commented Dec 6, 2013 at 1:10

2 Answers 2


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. Commented Jan 9, 2013 at 6:27
  • 3
    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
    Commented Jun 25, 2015 at 2:37
  • @bobstro Checking the serial only becomes a privacy issue if (a) the results of the check are transmitted to a third party and processed to build a user profile, or (b) personal information such as the user's name were also collected and tied to the serial number, perhaps at the time of purchase. But in general I agree: changing any part of a free software is a basic freedom of GPL users which is not conditional on having a "good reason" to do so. Commented Oct 18, 2021 at 8:17
  • If I had to guess, I'd say the serial is hardwired within the CPU. That would imply the serial can never be modified. This answer explains exactly what Dom did, and nobody with the factual information will verify it due to the NDA'd nature of the chipset (Broadcom protecting its IP), and the closed-source nature of the low level firmware that handles it (for License protection). Commented Dec 4, 2021 at 22:06

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.

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