2

I would like to protect my .bin ( squash fs ) file after compiling process in order to avoid reverse engineering techniques ( i.e. binwalk could simply unsquash my .bin firmware and see all the file system )

Could you recommend any tools for crypting the .bin file or other techniques?

Hope my question is clear

Thanks

Improve this question
8
  • 58
    Publishing the source code protects from reverse engineering by making it pointless. :)
    – Esa Jokinen
    Commented Jul 23, 2020 at 11:21
  • 21
    Why not just design your firmware to be secure? It will not matter who reads it.
    – john doe
    Commented Jul 23, 2020 at 16:11
  • 22
    The only winning move is not to play. Look up the failure modes of the Xbox 360 and the Xbox One.
    – Joshua
    Commented Jul 23, 2020 at 19:15
  • 5
    It's easier to let folks read but resist modification than it is to be unreadable by someone who, by definition, has posession of the hardware that itself must be able to read and decrypt the content. There absolutely are ways to make the life of a RE harder, and there also absolutely are ways to circumvent those; I've seen some very fun power-glitching attacks to get around mechanisms intended to make functionality inaccessible after early boot, f/e. So you need to think about what your threat model is, and what your engineering effort budget is.
    – Charles Duffy
    Commented Jul 24, 2020 at 4:10
  • 7
    ...but really, what is the threat model? Are you worried about people who can just desolder your flash chips, for example? Are you locked into specific hardware (that may or may not have TPM support or local equivalents?) Can you afford a higher per-unit price for the sake of being able to seal keys to only be accessible with hash-append-only registers in a specific state? Do you need to worry about an attacker with a logic analyzer who's probed the traces on your board?
    – Charles Duffy
    Commented Jul 24, 2020 at 4:11

3 Answers 3

Reset to default
27

@Marcus is completely correct about using encryption, and how the key has to be stored somewhere safe and possibly used in conjunction with secure boot. As far as tools go, there are many symmetric and asymmetric encryption schemes that may be suitable for your use case.

However, you can't protect 100% from someone obtaining your firmware. You can only increase the difficulty of reverse engineering such that the effort required outweighs the potential reward of obtaining it. Of course, this will depend on the type of adversary; a casual user may give up immediately after seeing that it is encrypted, but a professional outfit may spend much more time and money until access is gained.

So, you can tailor your defenses to what level of threat you anticipate and balance that with what you are able/willing to spend. If you only want to protect against a casual user, it may be sufficient to only encrypt the firmware in transit, and have the firmware decrypted upon receipt using a key stored in firmware. This method requires very little investment on your part, but it also may fall over pretty quickly for someone who is more determined.

Of course, you can step up to using secure boot with a hardware security module, using the keys to decrypt firmware only on boot, but as mentioned, this is an architectural decision and will possibly incur more time/cost.

The problem is, even if you store the firmware encrypted in the best way possible and make the keys extremely hard to recover from the hardware, you also have to do everything else right. All it takes is one vulnerability in your software for a user to get a shell on your system, from where they could dump the firmware. Or, maybe there are debug ports (JTAG/SWD/UART) left on the board itself that could allow access with a little hardware hacking.

The point is, once your system is physically in someone else's hands, it's a losing battle from there. So maybe it's time to ask; what is it that you are really worried about being reverse engineered? If it's for security purposes, consider searching for and fixing vulnerabilities internally instead of hoping to hide them with security through obscurity. If you are trying to protect proprietary code, you could protect it through legal means instead of hoping nobody recovers it.

Improve this answer
12
  • 12
    +1. "Code security" is an extremely black-and-white topic in the age of the Web: if one person anywhere in the world manages to reverse-engineer your system and posts a crack online, it's cracked for everybody, forever. So your security is either perfect or it's worthless... and it's never perfect. The only winning move is not to play.
    – Mason Wheeler
    Commented Jul 23, 2020 at 18:04
  • 2
    @MasonWheeler The only wining move is not to write software? That's not practical. Perhaps, by publishing the source code and encouraging an active community around it, you can convince folks to notify you of bugs before other folks exploit them.
    – jpaugh
    Commented Jul 23, 2020 at 18:05
  • 10
    @jpaugh No, the only winning move is to not even try to protect software you distribute into the hands of third parties from cracks. It's a fools errand and always has been.
    – Mason Wheeler
    Commented Jul 23, 2020 at 18:08
  • 4
    @MasonWheeler I wholeheartedly disagree. You're also using a very black&white picture of reality: The reality is that people will sell counterfeits of mass products. These people usually don't have the greatest engineers (their's higher-margin jobs for great engineers than cloning a bluetooth headphone). Not being the manufacturer that has the easiest to read firmware is a boon. You don't realize how low a bar can hang and still make a lot of commercial difference.
    – Marcus Müller
    Commented Jul 23, 2020 at 19:21
  • 3
    @MarcusMüller So you pick the low-hanging fruit - disable your JTAG ports, and so on. You don't make it trivially easy. But when it gets to someone spending serious time with a memory analyser or anything like that, you have to accept that you're going to lose that battle. As MasonWheeler says, the answer then is not to play, because you're just falling into a money pit. Put the same money into designing new features, and the reverse-engineers will always be on the back foot because you're constantly upgrading your firmware.
    – Graham
    Commented Jul 24, 2020 at 9:42
18

What you want is impossible; there's no "tool" that can do that.

When you encrypt your file, and then only someone in ownership of the key can get the contents – that's the point of encryption. Since you still want to use it, you, however, need to supply that key to the device that will use your image. Can't include the key anywhere unencryptedly in a file, otherwise everyone will trivially be able to decrypt your image.

The only way encrypted images work is with hardware support for securely hardware-stored keys from the boot away. That's not a "tool", that's an architectural choice with quite big consequences for your overall boot process.

You'll probably want to look into what "Secureboot" is.

Improve this answer
1
  • You can do that if your target platform has unique hardware keys, for example like iPhones did or some baseband controller blobs do. But it requires key management, additional enrollment/specialization and hardware trust anchors. And of course additional development and validation costs, not to mention the processing resources. Speaking of iPhones, Secure Enclave Firmware decryption keys have been published before.
    – eckes
    Commented Jul 24, 2020 at 8:14
6

In order to prevent reverse-engineering of their Management Engine, Intel used:

  • An obscure CPU architecture (not their own)
  • an exotic compression algorithm with hardware-backed dictionary
  • a less-known OS framework

Ultimately, they failed (well, almost). But they kept secret the internals of the ME for ~10 years.

Improve this answer
2
  • I don't know if you want to call Minix lesser known :)
    – eckes
    Commented Jul 25, 2020 at 20:27
  • 1
    It became Minix later (and this, exactly this, made Minix "the most installed OS", it was rather niche product beforehand). Up to v10 (? not sure) it was ThreadX (as per wiki).
    – fraxinus
    Commented Jul 25, 2020 at 20:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .