I would like to use the Raspberry Pi in a commercial product, but I would like to prevent reverse-engineering of the software on the device. The software in question would be written in Ruby. I assume that the end-user has physical access to the SD card and is smart enough to gain root access to the Pi.

As I see it, options may include:

  • Encrypt part (or all) of the SD card
  • Obfuscate the Ruby code or compile it down to bytecode (JRuby or Rubinius)

Encryption would be the best solution, but I can't think of a way to decrypt without asking the user for the key. Code obfuscation is definitely possible, but less secure in my mind.

Is it possible to encrypt a portion of the SD card without prompting the user for a key to decrypt it? Or is there a better way to make sure the code is only accessible on the desired device?

  • I am looking for a similar solution. The best answer I got is to mount a image(partition) that is encrypted after boot using certain conditions (perhaps ajax call like DRM to provide dynamic decryption key, a serial number with locking algoruthym ( (SN * date - 1) ) - Only other way is to use a code that can compile your code into binaries- like c++ or .net (mono) and hope good software crackers wont target your software- you know cause like Microsoft has not had this problem for eons.. and still not solved it.. Good luck!
    – Piotr Kula
    Commented Oct 22, 2012 at 22:40

9 Answers 9


Of course it's possible to decrypt encrypted file/containers/etc. without asking for a password. It's sufficient to store the (encrypted) password on the SD card and use it to decrypt your data. For example, an easy openssl demo could be:

openssl enc -a -e -salt -aes-256-cbc -pass pass:abc123 -in /tmp/plaintext.txt -out /tmp/ciphertext.enc

openssl enc -d -a -aes-256-cbc -pass pass:abc123 -in /tmp/ciphertext.enc

The encryption would be performed while installing the software on the Pi, and the decryption would be performed at runtime, possibly in RAM. For example, the password could be a combination of some pseudorandom sequence number (known to you) and the specific Pi's serial number obtained from a cat /proc/cpuinfo. Then you have to find a suitably hidden location to store this pseudorandom number that is to all intents and purposes "the password" and thus the weak point of the whole encryption mechanism. For example a spare sector on the SD would be the typical choice, but you can even embed it into one of your executables.

In any case, your best option is to both encrypt and compile your software, to add different layers of obfuscation to your software.

Finally, if your software needs an internet connection, you can even make the Pi ask for the password every time. You'll still need to hide the password inside the connection, you will also have to use https and you'll have to protect against reply attacks, using the current time as salt for the encryption.

You have a lot of (cheap) options to make you software secure. But you have to know that if your software hits some well defined popularity threshold, it will be cracked for sure, even if you invest substantial amounts of money in its protection.

  • 1
    I can log in as root in safe mode, read the key file and decrypt all his hard work and sell it to the Russians for millions. Good try.. but not bullet proof. Even https can be tricked with DNS redirects and fake certificates all within a managed network.. oops
    – Piotr Kula
    Commented Oct 22, 2012 at 22:41
  • 1
    @Avio: First of all, the sector is not unknown. It has to be known, it's just not obvious where it is. But since you need to find it out with some decryption script/application, one can find it. You have to put the code that will do decryption somewhere. Where would you put it? In initramfs, some SD card partition or other not protected place. Anyone can see the applications/scripts that are used to decrypt encrypted partition and/or just change them to get some kind of access before they are executed. Commented Oct 23, 2012 at 9:43
  • 1
    All your encryption methods are fine -except the key is stored on the SD card. The op most likely wants to sell SD cards for/with the Pi to an end user. Then I can take the SD card, brute hack it, exploit, safe mode into root- read the key file and infiltrate all the other devices communication and source code. That is the conundrum. I am sure the OP know how to encrypt stuff. He asks how to protect his software from getting decrypted, while letting the system automatically decrypt it.
    – Piotr Kula
    Commented Oct 23, 2012 at 10:05
  • 1
    @Krzysztof Adamski: It seems that you just read a half of what I said: «Of course nothing is bullet proof and system security is only a matter of time and money». All the owner of the system can do is make it uneconomic, in time or effort, for someone to crack its product.
    – Avio
    Commented Oct 23, 2012 at 10:08
  • 1
    @Avio: No, not really. But since you asked 'how?', I answered to that. Didn't know it's a rhetorical question. You wrote that implementing your idea is enough to start distributing application but I believe OP (and others reading this) should just be aware of the weak sides of this approach. That being said, I don't believe there exist much better solution for Raspberry Pi. The only thing one can do is to just obfuscate even more. Maybe OP application is just too precious to take the risk and he decides to use something other than RPi, where he can create better protection mechanism. Commented Oct 23, 2012 at 10:20

Whether or not obfuscation or protection is worth it depends on several factors.

Is it worth it?

When looking at whether to protect software, we first have to answer a number of questions:

  1. How likely is this to happen?
  2. What is the value to someone else of your algorithm and data?
  3. What is the cost to them of buying a license to use your software?
  4. What is the cost to them of replicating your algorithm and data?
  5. What is the cost to them of reverse engineering your algorithm and data?
  6. What is the cost to you of protecting your algorithm and data?

If these produce a significant economic imperative to protect your algorithm/data then you should look into doing it. For instance if the value of the service and cost to customers are both high, but the cost of reverse engineering your code is much lower than the cost of developing it themselves, then people may attempt it.

So, this leads on to your question

  • How do you secure your algorithm and data?



The option you suggest, obfuscating the code, messes with the economics above - it tries to significantly increase the cost to them (5 above) without increasing the cost to you (6) very much. The research by the Center for Encrypted Functionalities has done some interesting research on this. The problem is that as with DVD encryption it is doomed to failure if there is enough of a differential between 3, 4 and 5 then eventually someone will do it.


Another option might be a form of Steganography, which allows you to identify who decrypted your data and started distributing it. For instance, if you have 100 different float values as part of your data, and a 1bit error in the LSB of each of those values wouldn't cause a problem with your application, encode a unique (to each customer) identifier into those bits. The problem is, if someone has access to multiple copies of your application data, it would be obvious that it differs, making it easier to identify the hidden message.


SaaS - Software as a Service

A more secure option might be to provide the critical part of your software as a service, rather than include it in your application.

Conceptually, your application would collect up all of the data required to run your algorithm, package it up as a request to a server (controlled by you) in the cloud, your service would then calculate your results and pass it back to the client, which would display it.

This keeps all of your proprietary, confidential data and algorithms within a domain that you control completely, and removes any possibility of a client extracting either.

The obvious downside is that clients are tied into your service provision, are at the mercy of your servers and their internet connection. Unfortunately many people object to SaaS for exactly these reasons. On the plus side, they are always up to date with bug fixes, and your compute cluster is likely to be higher performance than the PC they are running the user interface on.

This would be a huge step to take though, and could have a huge cost 6 above, but is one of the few ways to keep your algorithm and data completely secure.

Software Protection Dongles

Although traditional Software Protection Dongles would protect from software piracy, they wouldn't protect against algorithms and data in your code being extracted.

Newer Code Porting dongles (such as SenseLock) appear to be able to do what you want though. With these devices, you take code out of your application and port it to the secure dongle processor. As with SaaS, your application would bundle up the data, pass it to the dongle (probably a USB device attached to your computer) and read back the results.

Unlike SaaS, data bandwidth would be unlikely to be an issue, but performance of your application may be limited by the performance of your SDP.

† This was the first example I could find with a google search.

Trusted platform

Another option, which may become viable in the future is to use a Trusted Platform Module and Trusted Execution Technology to secure critical areas of the code. Whenever a customer installs your software, they would provide you with a fingerprint of their hardware and you would provide them with a unlock key for that specific system.

This key would would then allow the code to be decrypted and executed within the trusted environment, where the encrypted code and data would be inaccessible outside of the trusted platform. If anything at all about the trusted environment changed, it would invalidate the key and that functionality would be lost.

For the customer this has the advantage that their data stays local, and they don't need to buy a new dongle to improve performance, but it has the potential to create an ongoing support requirement and the likelihood that your customers would become frustrated with the hoops they had to jump through to use software they have bought and paid for - losing you good will.


Only you can answer whether the economics of discouragement or protection are appropriate for your situation. But the more protection you go for, the more expensive it will be, and thus the more you need to stand to lose to justify it.

  • SaaS may be an option, but you have to be aware that you will need to recheck points 1 to 6 for every server you put online. You also expose to DDoS attacks.
    – Avio
    Commented Oct 23, 2012 at 10:48

I have recently invented very elegant solution to this unsolvable problem. It was inspired by this xkcd comic:

enter image description here

So the solution is called super glue. If one superglue SD card to the PI It will be almost impossible to extract the card without damaging it.

You can even use external SSD disk, encrypted with a password stored on SD and feel safe!

enter image description here

  • Someone could easily create an image file (dd) from it though, and use it accordingly!
    – Vassilis
    Commented Jun 20, 2019 at 15:03
  • @Vassilis its impossible without login, or not? Commented Jun 21, 2019 at 15:36
  • Anyone with a live linux image can do it! It's not necessary to be the root of your system.
    – Vassilis
    Commented Jun 22, 2019 at 10:27
  • @Vassilis may I ask you to point at any article explaining this procedure please Commented Jun 24, 2019 at 10:35
  • 1
    boot from usb is disabled by default on raspberry, therefore you will not be able to boot from live cd and run commands. This is what i mean, how you can boot from live cd without any config changes... Commented Jun 25, 2019 at 13:44

Compilation to bytecode would be the best repellent. As for encryption, software could be stored in TrueCrypt volume, but only if user did not gain root access; there is just no way to securely store password as memory/disk can be dumped at any time for inspection. Even the help of secure devices (smart cards) would not do much, if software runs where the user has a plethora of linux utilities. As far as I know secure boot is not an option on R-Pi which would prevent user tinkering inside OS.

  • 1
    Encryption during boot is not as secure as you would have thought. You just need to access/bypass the normal system boot and it is all mince meat. Not even Blurays got this right.. dammit!
    – Piotr Kula
    Commented Oct 22, 2012 at 22:44
  • Only totally closed systems can protect your application. I know only one such thing which is somewhat programmable - a Java Card. Commented Oct 23, 2012 at 0:04
  • 1
    Yes- but you always have to put a PIN in - the PIN is NEVER stored on the card.
    – Piotr Kula
    Commented Oct 23, 2012 at 10:06

If you want to make a true Commercial application, then the Pi , as it is in its end user form is no good to you!

You will have to design your own PCB, use the processor that is on the Pi for example and embed a flash memory onto the PCB.

  1. Write a propriety firmware for the BCM that generated a single log on code based on some top secret algorithm that can only be used within the next 10 seconds.
  2. Compile your own kernel with your propriety software and enable some Linux features that allow you to mount root from an encrypted file on the flash, that contains another encrypted partition with your software.(double protection)
  3. Your BCM firmware will generate a top secret once off auth key based on some clever algorithms or public keys and pass it to your custom linux kernal, which will load the encrypted root partition and do some more cryptographic stuff during boot to load your encrypted software drive within the encrypted image.


  • Good auth keys are not 8-16 characters long.It is important to supply 256/512 bytes long auth keys using system more system symbols(HEX) and less characters (ASCII)
  • Do not use AES, TKIP as it is easily cracked
  • As of today- Whirlpool encryption is amongst the most complicated to crack using 256/512 keys
  • Even if a hacker can remove the flash drive or dump the contents. your software is is encrypted twice.
  • If they intercept the auth key it that will be very difficult to get out from the firmware (because the BCM can prevent firmware dumps)
  • Some clever flash rom's also have a feature to prevent full memory dumps.
  • If you are designing a PCB you will implement (like Dell and Apple) a security chips that provides all your encryption data and keys and prevent bruteforce attempts. Some Dell's have a self destruct for Military use. If you put in BIOS password incorrect 2 times it wipes the drives with scatter bombs. You could implement the same if you detect auth key manipulations.

End of the day. The Raspberry Pi is intended for Educational purposes for children to learn how to use Linux and write some programs.

It is not fit for high profile commercial use. You need to make your own device and come up with your own protection systems. Because if only you and nobody else knows how you protect your propriety information then the chances of somebody hacking it using a known exploit or brute.. is 0.001%


  • Write your software so it can be compiled and deployed to the target system in a binary format. Example EXE for windows that runs on .NET, JAR for Java or (Not sure in linux, C++?)
  • Remember, the better the security you want- The more money you are going to have to spend on it. There are no exceptions.

One of the solutions is to use the MAC address of the RaspberryPi which is almost unique for a given Pi. Verify this address inside your code and provide the compiled version. This will make reverse engineering difficult.

For people who blindly copy the SD card to a new one, it won't work for them on another Pi. This will put away the large majority of people stealing your software. Other who are smart enough to break this may be smart enough to remake the software, their are not numerous and I don't think they will hurt your sales.


You can use a piggy-back based solution: Software Serial Protection for Raspberry Pi

  • 2
    Correct me if I'm wrong but this device doesn't seem not add any protection against reverse engineering. A simple hardcoded check on the CPU serial number would do the same.
    – EDP
    Commented Sep 4, 2015 at 13:18

Why not add an SPI based flash to your carrier board and store your code on it? I am considering this option for my own product. In case the SD gets corrupted I want the end user to be able to write a new one, which includes a custom raspbian, and the code to mount the SPI flash and run the executable.

Another option is storing an encryption key in your RTC. Most RTC chips have some storage and they could be preprogrammed with the key which allows to unlock and mount the executable from SD or from SPI flash.


I believe that all of the CPUs used in the range of Raspberry Pi support a secure boot of their own. I believe it requires 12 volts to reflash the 4,8,16,32 or 64K of internal flash or EEPROM which the pi itself doesn't have. From their, you can setup the Trustzone with your code so all the good stuff cannot be seen. I also understand that both forms of static RAM are only stable for a given number of rewrites. My first step would be to have a spare CPU and try reflashing this secure boot memory for a few hours or days. Eventually, all of the bits become fixed so nobody else can modify your code and depending on the actual product, you can periodically ask for a 2-factor identification (like banks) so the product spits out a code & the reactivation code is sent to the E-mail address. If you mod the pi a little, I believe that ARM also has a CPUID so their are a number of levels of security you can go for. I mean, you could also offer an SMS to a specific number. Lots of ways.

  • 1
    Hello and welcome. There's a lot of guessing and believe in that post. Before recommending people to apply 12 V to the Pi it would be highly advisable to provide a more detailed answer and back it up by appropriate references.
    – Ghanima
    Commented Sep 2, 2016 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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