1

I have a Qt App which is running on a raspberry pi (Debian Wheezy).

The raspberry image is autogenerated via a python script:

- Get the latest version of the generic custom-raspi-image
- Mount the image
- Copy project specific program data into place
- Setup systemd services for automatic setup
- Unmount the image
- Write the image to a sd card

On first boot, the disk size is expanded and some startup settings are set. Now on this startup routine, I would like to "brand" my app into the sd card. So that no one can just copy the sd card and use it in another raspberry. I must have an automatism.

The idea is compiling a c++ dll (on startup routine) which has the internal CPU id as a constant. Afterwards delete the "create c++ dll" script and move the dll into the app folder. The app is calling a function in the dll file and submit the internal CPU Id. Depend on true or false, the app is starting or not.

Is this the right way or do you have a better solution?

1 Answers1

3

Someone with a debugger (like gdb, or anything else that can use the Linux Kernel's tracing capabilities and can utilize binaries) will have an easy time figuring out how to circumvent your copy protection.

You'd have to encrypt your binary (that's possible), and use some machine-specific secret (e.g. the CPU ID, TPM chip data) to decrypt it. Problem: you mustn't leak that info, otherwise anyone can decrypt the binary. And protecting a CPU ID of the ARM in the Raspberry Pi isn't really feasible if someone has the possibility to e.g. run a shell, or access any scripting language. Also, you'd need to be very careful – once decrypted to RAM, you can actually dump the unencrypted machine code and presume operation later on. So that's not secure, either.

Anyway, if you do this, and hand out these SD cards or RPis with such software, you're probably breaking the GPL and other licenses that you're using – many of these copyleft licenses require you to include or at least make accessible the source code of the software you're distributing, and allow them to copy that code and the software. Qt is dual-licensed under a commercial license (for which you'd have to pay, but which would possibly allow you to not distribute the source code) and GPL.


Your copy protection scheme is weak – it's based on a secret that is, in fact, not a secret.

I don't know about trusted platform modules (TPM) in the RPi class of devices – but effectively, if you want to bind some software to hardware, the hardware needs to have the ability to decrypt something based on a unique key that is actually, truely kept secret by the hardware. As far as I can see, your devices don't have such.

Marcus Müller
  • 5,843
  • 2
  • 16
  • 27
  • There should be ARM® TrustZone® on the Raspberry Pi 3. [This project](https://github.com/OP-TEE/optee_os) seems to support it, but they [say](https://github.com/OP-TEE/optee_os/blob/master/documentation/rpi3.md) that the Raspberry Pi doesn't provide the hardware to make that secure. So it seems impossible on that hardware – Josef Nov 29 '16 at 14:52