After a time with the Raspberry Pi 2 Model B v1.1., i have the following concerns?

  1. I know it is focused to enhance vulnerable educational sectors, but it is possible to sell a product, based on the RPi?. To make money with it?. Become zillionaire with it?.
  2. How should i protect a development, let's say, i dont want somebody to take my RPi SD Card, duplicate it, and have their own replicas?. My current alternative is to fill the SDCard port with superglue :). Another choice could make the RPi to ping a license server online, which of course would require a WiFi connection. Or a Hardware HASH ID (This should be a better answer i guess...)
  3. I've checked there are also mechanisms to recover the installation even if you do not have the root, by mounting the SD Card. Again, my best solution is the superglue approach....

Thanks in advance.

  • 2
    This is a general embedded Linux question. It is a complex problem both technically and legally. – Craig Apr 1 '15 at 17:27
  • 2
    Hello and welcome to RaspberryPi.SE! This is too many questions in one. Some issues are also very broad and not Pi-specific. You need to consider that given time and effort all copy protection systems can be circumvented. Especially so if your system is deployed and you've got no way preventing the "bad guy" from using all available tools to break your protection. – Ghanima Apr 1 '15 at 19:23
  • @craig: Is there an Embedded Linux Community? – Brethlosze Apr 2 '15 at 0:42
  • WRT #2: You can't prevent piracy technically on any platform, all you can do is fight it legally. I think you have the cart before the horse here. By the time you have a pi-based software project where this is a concern, you will recognize there is no pi-based project that is really bound to the pi. It's just a general purpose device, and the community is development oriented. – goldilocks Apr 2 '15 at 1:23
  • 2
    It's not "their platform", application development wise, and they know that and do not care. That is not "their purpose". It's a Broadcom SoC implementing an ARM architecture. There's nothing anyone is going to do with a pi that couldn't be trivially ported to a very wide range of other devices. So, once again: You have the cart before the horse. By the time you get to the point where your concern with intellectual property has any meaning or significance, you will understand what I am trying to say to you... – goldilocks Apr 2 '15 at 3:06

If you are really concerned about protecting your intelectual property then you can combine your Rapberry Pi based application with some external custom made micro controller (MCU like AVR, PIC, 8051...) based hardware key (connected to Pi via USB, RXTX, I2C, SPI, 1wire...). For example, Pi side application generates a random number which is sent to MCU, decoded and sent back as an unlock key to decrypt something important. Then additionally you have some important function executed directly in MCU (you just pass parameters and get the result from MCU). You can imagine how that would raise cracking difficulty for a hacker in order of a magnitude, since his knowledge would have to be much wider then usual. There isn't a perfect protection, but if you really want to make it a challenge then this could be a way to go.

  • 1
    This is a nice solution indeed.... I will have it a try to this concept.... – Brethlosze Apr 12 '15 at 19:42
  • 1
    Unfortunately the solution to a hardware key is the same as a software key - just remove the offending part of the code, build in the right answer, etc. So the same skills will work against a hardware key. – tomnexus May 17 '15 at 19:36
  • 2
    Not if you put some important function into hardware key, and make it's result critical for your Pi application functionality. Since function exist only in a micro controller, there is nothing to remove on Pi side. This is not impossible to break, but many, many times more difficult since it demands much higher skills then usual code cracking. – avra May 18 '15 at 8:25
  • 1
    While these external circuitry indeed does add protection these things cost a lot of money: research, prototyping, manufacturing, testing, implementing, maintaining. What if something happens along the line? What if Raspberry change their interface(s) in future models? If it's a short lifespan or a hobby project, go for it. If it's a industrial/commercial product, perhaps OEM is a safer bet. – EDP Sep 5 '15 at 9:31
  1. I think that was the idea with the compute module all along. It should not be a problem to turn a profit.

  2. / 4. The superglue option is probably a good tradeoff. Ultimately you cannot defeat an attacker with physical access to the device. Have a look at game consoles which have probably millions invested in DRM infrastructure and they all eventually fall. In a different spirit, you could also embrace openness and sell a development version of your product and include some kind of SDK. The feedback you get from a technical focused user group might valuable and work in your interest.

  • The superglue option is probably completely nuts, but you make some other good points here. ;| – goldilocks Apr 2 '15 at 1:25
  • Actually, I was thinking on some hardware ID from the Raspberri Pi, in order every RPi software could be programmed for every RPi card, and thus, if i clone the software, the system will not work. Old uProcessors, were simply programmed on board, thus you cannot unplug it :). – Brethlosze Apr 2 '15 at 1:38
  • 1
    Even if you had a hardware ID anyone else with physical access could read it. Processors that are programmed on board of course also provide debugging interfaces, so you actually can read them. In more sophisticated systems the SOC will probably take care of only executing signed code. I wouldn't be too surprised if the Broadcom chip has some functionality in that direction, but you don't have documentation for it. If you want plan to sell millions on units, they might talk to you about that ;) – user1217949 Apr 2 '15 at 12:39
  • LOL.. no, i guess i will sell a really minor quantity of them!. So, if i have a code running under Raspbian, any other could take the SD card, and read it? debug it? crack it?. I am totally sure, the answer is of course yes. Will the best choice be to have a Hardware Keysuggested by avra, and bury the SD card with SuperGlue inside its connector? – Brethlosze Apr 18 '15 at 6:50

While this practice definitely is loosing coverage, you'd be astonished by the amounts of USB connectors that have been glued down on desktop machines in corporate office environments. And I'm talking large multinational corporations here.

But now on topic...

For commercial projects where the IP protection is a major factor, the Pi is good for early prototyping / proof of concept at best. Even if protection would not be an issue, deployments of the Pi on a larger scale is IMHO not the best solution - for a number of reasons I described in an earlier thread on this forum.

There is no system safe against reverse engineering / hacking / reproducing. Any system is exploitable. Every system however has a penetration score. With its open approach and external SD card, the Pi has a very low one. A custom designed military-approved hardware board with custom SoC, sandwiched components and multi layered PCB in combination with a custom bootloader, hardware encryption will have a higher score.

On top of that there is the deployment factor. The wider your market is, the more interesting it will become for people to break in and steal your technology.

If the hardware is your piece of resistance in the whole setup and protecting your technology is a major factor, I don't think the Pi is the product for you. If your hardware is a facilitator for selling services, perhaps protecting technology should be done on the server side rather than on the client side.

We use the Pi for selling such services. Our software on the Pi does have a raised level of protection, we're using a compiled C application, locked on MAC and/or CPU serial number. But at the end, without our server side, even the source code is virtually useless.


You can use a piggy-back inside raspberry with an encrypt key. There are a couple commercial devices on market. I used this Software Serial Protection for Raspberry Pi, which works very well.

  • 2
    This will not help you to protect the system from cloning - the hackers will remove the check for the HW key from your binary if they want... HW key will provide only a certain level of protection (maybe to stop the first-level hobby hackers). – Kozuch Sep 6 '15 at 16:23

Make it open-source

Seriously don't try to copy-protect it. Make it open-source. If possible, let others join your project.

Then charge for services. You can make buckets of money if you do that right.

Red-had does it like this and a few other companies. They are all doing well and are growing.

  • 1
    No, this is a product, not a project, neither a big project neither a very interesting programming project. Sounds pretty, but again, no. – Brethlosze Mar 12 '17 at 22:48
  • 1
    I disagree. From my experience every program I've written which was shipped and actively used by the client would have support calls, requests for enhancement and, of course, bug fixing. The only software that didn't have any of those was software which, after shipping it, was never used. – MadMike Mar 16 '17 at 0:07
  • That is the point, this is for a product, a device. there is not art at all in the software but, the way in which the variables are processed has to be protected, just like any smart controller. You are not intending to open source your developments in that sense, that is out of the question, that is another kind of work. Maybe you are in a company and you are pissed off when the client calls you, when actually it gives you more billing to your bosses, and gives you the post sales service, which in the long term is good. In any case, the open source is good for humanity, not for make profit. – Brethlosze Mar 17 '17 at 18:21
  • 1
    Again this is the utopic discussion of gifting all your work for human benefit or charging everyone for everything you do. – Brethlosze Mar 17 '17 at 18:29

Few cents of mine:

  1. Never create a solution around scripts which can be directly read.
  2. Breakdown functionalities in terms of multiple software/processes and hardware.
  3. Add some read hardware "functional" dependency.
  4. Add smart card reader and sell "enabler" smart card with your product.
  5. Have a license server
  6. Have a usage counter in EEPROM!!! And there should be some way to "recharge" online.. ;-)



As an entry-level protection, there's a unique SD card ID found under /sys/block/mmcblk0/device/ which is not cloned by typical disk image cloning software. This has the advantage of not requiring a separate device to hold the unique ID and works pretty well as a second layer of protection after the superglue. It will at least stop people who are capable of simply cloning the SD card.

Another tip regarding protection using IDs is to avoid using a simple check, i.e.

if(readID() != 0xDEADBEEF) exit();

Simple checks like that are easy to discover (either by searching for the known ID or by monitoring calls to exit()) and remove. A much better approach is to involve the ID as a constant in calculations. That is, instead of i++ somewhere in your code you will write

i = i + readID() - 0xDEADBEEF + 1;

This will be much more difficult to discover, as the exact ID will not appear in your code verbatim (0xDEADBEEF + 1 == 0xDEADBEF0), and inspecting all calls to exit() also won't reveal the location of your protective code. Instead, your code will simply crash on a system with the wrong ID, and the attacker will have to debug your application's logic to understand and fix the problem.


Using an external component, I meant security component would solve that issue. If you really think your idea is great and worth extra cost to do so, I would suggest you to use some professional MCU/CPU to do so. Like Broadcom BCM58101 series, not really cost effective and not friendly to a new user but high security level can also protect your idea/design.

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.