32F417: can SWD be blocked by internal software?

[peter-h]

The last post here
https://www.eevblog.com/forum/microcontrollers/32f417-security-question-(disabling-swd-etc)/
wasn't answered because the poster making that suggestion didn't come back.

I don't think it is possible because a debugger does a Reset, and starts off by releasing the Reset, so your code doesn't get a chance to run at all if you set a breakpoint at the very start. And upon hitting any breakpoint the debugger has total memory space access.

[langwadt]

and you can use the boot pin to start the bootloader

[nctnico]

It should be possible by setting the read protection byte to the right value. Before anything else, the STM32 controllers run an internal bootloader to do some initial setup.

[peter-h]

I would quite like to block SWD access, because I have a really robust and fairly secure route for loading in signed/encrypted firmware via USB, or an HTTP server. But as I put in the other thread I don't want to set Level 2 security because you cannot reverse that.

Being able to bugger up SWD somehow, while preserving the ability to reverse it by loading new firmware via the above routes, would be nice.

I am sure others have been up this road because Level 2 is a big commercial liability. You need to have total confidence in your firmware, or at least total confidence in the boot loader process for uploading new firmware. Especially if selling to large companies who tend to enjoy screwing small suppliers and who will happily force you to scrap an entire build of a few k units.

There are hacks for a lot of these chips although the ones I have found were for the older F1xx ones, not the F4xx ones. Still, nothing is as easy as connecting an STLINK to a board, and blocking that is worth doing.

[ataradov]

You want contradicting things. L2 security is designed to disable SWD. But you say that you may want to have SWD back in some cases. This means you should not disable SWD.

You say that you have a robust bootloader, so sounds like "total confidence in your firmware" is not an issue.

[peter-h]

Nobody can be 100% sure; the commercial risk (dead stock, etc) remains. Large-customer balance of power issues are bad enough to bankrupt a small company.

I wonder why they made SWD disabling non-reversible.

Especially as all these chips seem to be hackable using the method of a very short reset just as they read the security fuses.

Anyway, am I right there is no way to achieve the subject - because a debugger does NRST=0 which resets the AF mapping, and prevents software access to the BOOTx pins?

[ataradov]

If it were reversible, then what would be the point? Anyone can reverse it then.

No, without completely locking the device it is impossible. Debugger can always intercept whatever firmware is doing. The only way to disable SWD is to prevent it being enabled in a first place though L2.

On more recent generation of devices there are more advanced features to control that. SAM L11, for example has a key you program before locking and the chip erase is only possible once you provide the key. Otherwise device is locked with no way to unlock it. But this is a relatively modern invention. I expect it to propagate to more devices in the future. And we need to see how this holds up to attacks, of course.

[peter-h]

If it were reversible, then what would be the point? Anyone can reverse it then.

Depends on what other protections can be selected, and whether they actually work. None of these do actually work, including Level 2.

But anyway, my Q has been answered. Thank you all

[eutectique]

If it were reversible, then what would be the point? Anyone can reverse it then.

SAMV70 has security bit which, when enabled, disables access to ETM and hence to SWD and internal flash. The bit can be reversed by asserting ERASE pin, which is very convenient.

On more recent generation of devices there are more advanced features to control that. SAM L11, for example has a key you program before locking and the chip erase is only possible once you provide the key. Otherwise device is locked with no way to unlock it. But this is a relatively modern invention. I expect it to propagate to more devices in the future. And we need to see how this holds up to attacks, of course.

Automotive Freescale/NXP MPC5674F has this feature for quite some time. Censorship password is 64 bits long, so brute force would hardly be practical. The problem though could be the single password used for all the items of the same product. Once cracked, it will open 'em all.

[ataradov]

SAMV70 has security bit which, when enabled, disables access to ETM and hence to SWD and internal flash. The bit can be reversed by asserting ERASE pin, which is very convenient.

Yes, but that's equivalent to RDP level 1 in STM32. Sure, SWD interface remains enabled, but you can't do anything via it other than erase. This is actually far better than a dedicated erase pin.

Once cracked, it will open 'em all.

Sure, but it is on you to make sure that codes are unique. Device vendors can only do so much to help you.

In this case power glitching attacks become more viable. No point in cracking the lock bits if you can make your firmware to dump itself on an external port.

[peter-h]

that's equivalent to RDP level 1 in STM32. Sure, SWD interface remains enabled, but you can't do anything via it other than erase

I didn't realise this. So on the 32F417 one can disable SWD for the purpose of examining memory, and it is reversible by internal software?

The bit can be reversed by asserting ERASE pin, which is very convenient.

Yes - can save you scrapping a load of boards. Manually replacing a QFP-100 is quite a job. Done that sort of thing hundreds of times

[ataradov]

I didn't realise this. So on the 32F417 one can disable SWD for the purpose of examining memory, and it is reversible by internal software?

Yes. You don't disable SWD, but you disable debug port access to the memory to ensure firmware security. And MCU without that would not make it far on the market.

But it is not reversible without chip erase. So, internal software may trigger the process, but it would also be erased in the process.

[wek]

I didn't realise this.

The exact effects of RDP settings including Level1 are clearly described in RM0090, in FLASH chapter's subchapter aptly named Read protection (RDP).

As decreasing RDP level from 1 to 0 implies mass erase, the only practical way to utilize this (except "suicide") is to run the recovery software (bootloader) *entirely* from RAM.

JW

[peter-h]

OK, but you can trigger a software feature which starts the mass erase, doesn't need to run throughout the erase process, and then you can load new firmware via SWD, presumably.

This avoids scrapping the board.

You just need a rock solid means of triggering the mass erase (L1 to L0) "suicide feature"

I should read the RM but I find this quite confusing, and background knowledge is very useful.

[ataradov]

With RDP1 you can just erase the device via SWD, you don't need software for that. And it is as rock solid as it gets.

[abyrvalg]

A whole bunch of easy-to-do-at-home attacks abuses side effects of this “nice” idea of blocking just the flash access and leaving SWD working for other “useful” things (observable CPU regs on nRF51, flash “firewall” race condition on older ST M0s, forced exceptions leaking vector table contents on ST M3s, DMA attack on GD32 etc), not mentioning the “official” ability to dump RAM (which can lead to interesting discoveries in peter-h’s case with RAM-resident bootloader). That’s just too big attack surface to control IMO.
I liked the approach of old SAM7S where setting the protection was disabling JTAG completely, leaving the only way out thru a mass erase by asserting a dedicated pin.

[ataradov]

It is always a compromise. It is absolutely possible to do it securely (as compared to a disabled interface) with just the SWD.

And the dedicated erase pin can also be abused, especially on SAM7S where it does not erase the SRAM. This was fixed on SAM V7x/S70/E70, where SRAM is also erased before the unlock happens.

[peter-h]

With RDP1 you can just erase the device via SWD, you don't need software for that. And it is as rock solid as it gets.

Ok, sorry, I forgot that. I get it now. Where is the Erase function in Cube? I can't see one - apart from an erase happening when a new program is loaded. But that erase seems to be done sector by sector. Does one need to use e.g. the Segger tool, which has a command line interface?

which can lead to interesting discoveries in peter-h’s case with RAM-resident bootloader

There is nothing secure in my boot loader. In fact I have probably already posted the source here, a while ago It took a lot of work to get it going... working out the linkfile commands for relocating the execution address, etc and then jumping to it. The boot loader can call functions in the CPU FLASH, which presumably cannot be examined via SWD.

A whole bunch of easy-to-do-at-home attacks abuses side effects of this “nice” idea of blocking just the flash access and leaving SWD working for other “useful” things

I like the one on the chinese "32F407" which uses a separate FLASH chip next to the CPU. You remove enough resin to expose four bonding wires between the two chips, and read out the code at startup

[ataradov]

Where is the Erase function in Cube?

No idea, never used it. I assume it is just on the part where you set RDP level in a first place. The erase is not a separate function, it is just a side effect of changing RDP 1 -> 0.

I like the one on the chinese "32F407" which uses a separate FLASH chip next to the CPU. You remove enough resin to expose four bonding wires between the two chips, and read out the code at startup

This is much harder than it sounds, since you need access to the micro-probing equipment.

It is also more than 4 wires. And you can't really probe the bonging wires, you need to get access to the die pads. And as was mentioned, on those devices there are other exploits in RDP1. With RDP2 extracting the die may be a good option, but not trivial.

Although it looks like some attacks do use bonding wires.  It still does not look easy, especially given other holes in those devices.

And of course, all of those things are vulnerable to power glitching attacks during the protection bit readout. And ST is not the worst here, as you need to spoof all 8 bits to unlock the device. But lowering RDP2->RDP1 is much easier. It does not buy you much as far as firmware extraction goes. May be if combined with other exploits.

[peter-h]

This https://stm32world.com/wiki/STM32_Read_Out_Protection_(RDP)
shows an "stm32 cube programmer". Never seen that before It is indeed a whole separate app, perhaps suitable for production programming.
https://www.st.com/en/development-tools/stm32cubeprog.html

And ST is not the worst here, as you need to spoof all 8 bits to unlock the device.

How is that done? I didn't find this bit.

since you need access to the micro-probing equipment.

Sure, but that's a lot easier than decapsulating and scanning the FLASH, which is apparently possible.

[AndyBeez]

Stepping back, what is the attack surface you are concerned with? Physical security maybe enough; ball arrays with the uC preflashed before placing and no PCB tracks to the SWD lines. This frustrates casual hackers but  otherwise, if you ard building a crypto wallet of a voting machine for examples, how about using a microcontroller designed for secure/banking applications? Such as the ST31H family. Decapping would be pointless. I know that's an dxpensive redesign, but what level of security are you designing too?

[peter-h]

Good Q.

I am just trying to do a reasonable level of diligence - it is debatable what that may be. The reason is this: this product may be sold to someone who does a bit of code for it (the dev kit will be free) and sells it on. Sometimes for 20x the price and that creates an incentive for the person paying that price to get the custom program out, while buying the 1/20th-priced one from me directly.

I've been in this business for over 30 years... I did some products, a long time ago and vastly less powerful than this 32F417 one, where the only protection was to prevent somebody doing the most obvious thing: unsoldering and duplicating the TSOP-28 28C256 EEPROM storing the custom program. That was sufficient, because the next step would have been extensive disassembly. Maybe somebody did it (many thousands were sold back then, often to users who never contacted us) but I doubt it. With this new box, I want to do a bit more, especially as firmware updates may be deployed online, and there is a limit on how secure that can be. My box would start up an HTTP/S client and call up a private server to grab whatever file it is entitled to, based on its serial number or whatever, and flash it.

This isn't a crypto wallet or anything like that. I was sort of involved with that stuff many years ago (google Siemens 44C200 - I still have a whole reel of them) so I know the issues there. Smartcard chips were always attacked and usually successfully. I also started on a product using the Capstone chip, which died an early death.
https://en.wikipedia.org/wiki/Capstone_(cryptography)
Today's smartcard chips are probably pretty good but the idea of a chip holding cash has been pretty well killed, due to the potential for tax evasion.

Unless the CPU security is good enough, a smartcard is the only way but it is another thing to pay for and not worth it in this case.

[AndyBeez]

Nice to see you are doing due diligence by design.

There are secure elements that can protect microcontroller deployments: often secure 'S'EEPROMs used as AES key stores. Offering crypto authentication and code encryption would be a big plus to your value added customers, maybe?

I'm sure there are experts here who deal with this stuff every day

I2C example: https://www.maximintegrated.com/en/products/embedded-security/secure-authenticators/DS28C22.html

[peter-h]

I think you would need a chip which both

- holds the key, and
- does the crypto internally

Short of that, all you are getting is half the job. The proper solutions still require a physically tamper-proof design (encapsulation, various features to detect tempering, self-erase if attempted, etc). BTW I think most people are designing-out anything from Maxim

For what I am doing, it isn't needed. I just need to piss somebody off for a few days. I am not going to discuss what I am doing in detail but you certainly won't be able to disassemble any OTA update. Unfortunately somebody who is very clever can probably crack a 32F4 in minutes and get the FLASH out, with the right equipment. They will need much more time to work out other aspects of the product, however.

Many years ago, in the days of Z80 etc and EPROMs, I used to jumble up the address and data lines I had a utility written which jumbled them in reverse for the EPROM programmer. One customer, the usual kind of wide-boy opportunist chancer from a certain country, who used to run the corporate IT business in London in the 1980s, told me he spent days on trying to work out why my EPROMs disassembled to junk and eventually gave up, believing they were "encrypted"

One can also use security selectively. When a new product comes out, the first orders tend to be from competitors, and will never be actually deployed. So you can set Level 2 on those Same on anything going out to China, etc.

[darkspr1te]

I think you would need a chip which both

- holds the key, and
- does the crypto internally

Short of that, all you are getting is half the job. The proper solutions still require a physically tamper-proof design (encapsulation, various features to detect tempering, self-erase if attempted, etc). BTW I think most people are designing-out anything from Maxim

For what I am doing, it isn't needed. I just need to piss somebody off for a few days. I am not going to discuss what I am doing in detail but you certainly won't be able to disassemble any OTA update. Unfortunately somebody who is very clever can probably crack a 32F4 in minutes and get the FLASH out, with the right equipment. They will need much more time to work out other aspects of the product, however.

Many years ago, in the days of Z80 etc and EPROMs, I used to jumble up the address and data lines I had a utility written which jumbled them in reverse for the EPROM programmer. One customer, the usual kind of wide-boy opportunist chancer from a certain country, who used to run the corporate IT business in London in the 1980s, told me he spent days on trying to work out why my EPROMs disassembled to junk and eventually gave up, believing they were "encrypted"

One can also use security selectively. When a new product comes out, the first orders tend to be from competitors, and will never be actually deployed. So you can set Level 2 on those Same on anything going out to China, etc.

If you want to piss someone off in the design then here are a few tricks
1. epoxy the the vpu caps by the xtal pins
2. put half the key in the rtc and the other half in the irq vectors that match 10-13 (old sega trick )
3. crc any update packets
4. randomly set and unset debug pins (even in debug mode you can set the pins and cause issues)
5. build into the design finger prints that can be checked by software (a trick used by DELPHI OBD2 boxes ) , separate the checks into single lines across many normal routines using multiple vars and add in one based on a timer (they dont show up in calls often) to mix it up
6. dont use standard libs in the boot loader (eg cube mx)
7. use the debug pins in the main stay of the design to further hamper step by step.
8.control the source of updates and have version checking routines different to your crc routines.
9. ensure keys are FLASH marked and not loaded into ram
10.use a key cycle system between versions
11. spread keys across multiple locations a in between mundane checks
12. learn the compilers issues when the design switches between various settings eg debug/O1,O2 etc , some speed ups will overide prior "keep in flash" options.
14. confuse the reverse engineer by using strange stepping



darkspr1te

[darkspr1te]

And yes, it would only take me a few to dump the stm32Fx device.
I can go into more details on how you implement the above and more tricks using the stm32 and still have security despite the flaws but it would bore people.



darkspr1te

[hans]

The motivation for this security sounds very similar to what I've encountered. I was working as an electrical designer at a company that had field computers with GUI/control software written in C#. It had node locked licenses with several optional activations, of course, as that's what the sales team likes nowadays.

One day I was working on an I/O module that required testing, and so I asked the field tech engineer to help me out putting it on the machine.. He said sure, picked up the company's test field computer.. only to found out he didn't have the proper license option with the new beta version. The software dev that wrote the module and was also responsible for handing out license keys happened to be on holiday.. so in order to stay moving.. let's say a common C# disasembler tool was used to find function along the lines of "CheckLicense", and it's source was edited to unconditionally "return True;". Literally within 15min the 'problem was solved'.

Sales got ahold of this event literally when they came back from their coffee break ( ), and that some large OEM resellers also have some clever software guys around.... so they were hastily checking the books to see if those guys were still buying all the licenses they needed.. and they demanded that this issue would be "fixed" (which perhaps would start at using an C# obfuscator, or not use a high-level IL in the first place).

I believe the software dev was not very amused by these findings and the motivation of this engineering process, because apparently the whole software project was like his first born child. But then again you also cannot stop anyone when he/she is motivated enough. Because admittedly, the whole license key arithmetic and checks was done in a C++ DLL without debug symbols, just the C#/C++ bridge was very poor. But in the end, everything can/will be reverse engineered when given enough time... as there are communities of people that make it a sport to be the first upload a .nfo-annotated piece of kit.

But given that you use a common off the shelf, and in particular a popular and well studied MCU, I think it's virtually impossible to have a 'bullet proof' infosec without tradeoffs. Disabling SWD port, going to BGA with unrouted SWD tracks, hard grounding SWD pins, etc. all sounds like pretty severe but reasonably effective ways of stopping someone to tinker with remaining SWD commands to uncover piece of the firmware.
Sometimes it's not even that they need the whole firmware. If an encrypted image leaks somewhere, then you only need to uncover the few bytes that hold the key to have a decent go at decrypting it (unless you can use creative tricks to obfuscate it, like @darkspr1te mentions) .

I wonder how much mutable function pointers would do to any reverse engineer process. Sure many decompilers will understand C++ vtables, but if you implement your own function pointer stuff where you access the function pointer through a pointer with the address computed in-place, then I'm not so sure how well a decompiler will be able to automagically put 1 and 1 together.

[peter-h]

put half the key in the rtc and the other half in the irq vectors that match 10-13 (old sega trick )

Doesn't that need the RTC battery to be charged/working?

I looked around to see what 10-13 might mean. Is this in the vector table?

Code: [Select]

Vectors:
  .word  _estack
  .word  main /* was Reset_Handler */
  .word  NMI_Handler
  .word  HardFault_Handler
  .word  MemManage_Handler
  .word  BusFault_Handler
  .word  UsageFault_Handler
  .word  0
  .word  0
  .word  0
  .word  0
  .word  SVC_Handler
  .word  DebugMon_Handler
  .word  0
  .word  PendSV_Handler
  .word  SysTick_Handler

  /* External Interrupts */
  .word     WWDG_IRQHandler                   /* Window WatchDog              */
  .word     PVD_IRQHandler                    /* PVD through EXTI Line detection */
  .word     TAMP_STAMP_IRQHandler             /* Tamper and TimeStamps through the EXTI line */
  .word     RTC_WKUP_IRQHandler               /* RTC Wakeup through the EXTI line */
  .word     FLASH_IRQHandler                  /* FLASH                        */
  .word     RCC_IRQHandler                    /* RCC                          */
  .word     EXTI0_IRQHandler                  /* EXTI Line0                   */
  .word     EXTI1_IRQHandler                  /* EXTI Line1                   */
  .word     EXTI2_IRQHandler                  /* EXTI Line2                   */
  .word     EXTI3_IRQHandler                  /* EXTI Line3                   */
  .word     EXTI4_IRQHandler                  /* EXTI Line4                   */
  .word     DMA1_Stream0_IRQHandler           /* DMA1 Stream 0                */
  .word     DMA1_Stream1_IRQHandler           /* DMA1 Stream 1                */
  .word     DMA1_Stream2_IRQHandler           /* DMA1 Stream 2                */
  .word     DMA1_Stream3_IRQHandler           /* DMA1 Stream 3                */
  .word     DMA1_Stream4_IRQHandler           /* DMA1 Stream 4                */
  .word     DMA1_Stream5_IRQHandler           /* DMA1 Stream 5                */
  .word     DMA1_Stream6_IRQHandler           /* DMA1 Stream 6                */
  .word     ADC_IRQHandler                    /* ADC1, ADC2 and ADC3s         */
  .word     CAN1_TX_IRQHandler                /* CAN1 TX                      */

randomly set and unset debug pins (even in debug mode you can set the pins and cause issues)

How does that work when the debugger resets the CPU and can read memory immediately?

I can see it would prevent stepping through the code on the target.

use the debug pins in the main stay of the design to further hamper step by step.

That would also prevent debugging the project during development I guess one could do a #define for that.

Your other points are all good stuff for obscuring code flow - thank you.

let's say a common C# disasembler tool was used to find function along the lines of "CheckLicense", and it's source was edited to unconditionally "return True;". Literally within 15min the 'problem was solved'.

Amazingly often there is a DLL entry point called "checklicense" or some such

Sales got ahold of this event literally when they came back from their coffee break

Telemetry? Nasty...

hard grounding SWD pins,

Stops you debugging on the final board, too. Would work only with a BGA package.

If an encrypted image leaks somewhere, then you only need to uncover the few bytes that hold the key to have a decent go at decrypting it

With any half decent crypto e.g. DES, 3DES, AES256, no amount of known plaintext gets you anything. Even ciphertext of ECB over 16 bytes of known-0x00 won't get you the key, in any reasonable time (clickbait website claims aside). That part is actually easy.

I wonder how much mutable function pointers would do to any reverse engineer process. Sure many decompilers will understand C++ vtables, but if you implement your own function pointer stuff where you access the function pointer through a pointer with the address computed in-place, then I'm not so sure how well a decompiler will be able to automagically put 1 and 1 together.

Obscurity buys you time, but only time. In the old days one would execute the copyright message. On the z80, ASCII chars were mostly reg-reg moves etc, nothing explosive, and counterfeiters would often edit the copyright message

I am amazed that C (I use only basic C) can be decompiled that well. I wonder what the motivation was behind developing such tools.

[ataradov]

This all has been discussed to death. For a really interesting product you will waste more time trying to do all of this, than it would take to reverse-engineer that. You are alone (or a small team). Interesting product has a lot of people looking at it.

The easiest way to prevent clones is to do a good job and keep the price reasonable.

All those physical (epoxy) and software (encryption) stuff is good, but does not do much to protect against differential power analysis and other side channel attacks. And those are made reasonable cheap and easy by some tools on the market. They still require skill, but if your product has a lot of demand, then there will be someone skilled enough.

You can add countermeasures, of course, but remember, it makes your product more expensive, making it less attractive to the customers. And at the same time it makes it more attractive as a copy target.

[SiliconWizard]

Is still think doing a minimum for protection is necessary just to prevent your product from being cloned too quickly. Lets you time to at least break even for your dev costs. Just don't go too far as it's indeed a lot of work for little added protection and may annoy your customers depending on what exactly you did or add unnecessary costs.

After that, I think providing excellent support, after-sales and good build quality will make cloned products a lot less attractive especially for your business customers.

Also, don't overestimate the probability of your products getting copied as long as it's not completely trivial to do so, or unless you sold millions of them, which frankly would be good news for you.

In this weird shortage period, the interesting thing is that it's becoming more common to see customers going after cloned components, and even cloned products, not to save a few bucks, but just to get ahold of them if they are otherwise unavailable. So I think that if you manage to offer enough stock for your customers, you have an edge and you can more or less forget about clones for a while. And how long this is gonna last is anyone's guess, but I don't see this ending any time soon.

[peter-h]

I am not doing anything which will be visible to customers.

I wondered about some points made by darkspr1te above. Could not really understand them.

Some "obscurity" features are easy e.g. run bits of code out of timer ISRs, or use DMA to move data into the right place.

[hans]

Telemetry? Nasty...

No.. just that word spreads fast in small-mid sized companies where only 1-2 dozen people work in 1 office building.

Stops you debugging on the final board, too. Would work only with a BGA package.

Could feasibly only be used if you use a different production/engineering board. But I agree it very much complicates design to the point it's probably not worth doing.

With any half decent crypto e.g. DES, 3DES, AES256, no amount of known plaintext gets you anything. Even ciphertext of ECB over 16 bytes of known-0x00 won't get you the key, in any reasonable time (clickbait website claims aside). That part is actually easy.

I meant via a physical attack. There may/will be tricks to snoop/read bytes from FLASH via various methods, but they can be painfully slow or unreliable. However if you know the location of the key, then you only have to try to get those dozen-odd bytes.
Of course this(position) is all hard to get at if the whole image is encrypted. But typically hacking does not have a single straight forward path to success, where every bit or hint of information can help. E.g. what @darkspr1te has said "6. dont use standard libs in the boot loader (eg cube mx)" could be generalized to any kind of library or code. Security by obscurity should not be an end target but can help in 'pissing someone off for a couple days', or like you've mentioned about the swapped bus data lines of a ROM chip.

For example, several years ago I had a go at reverse engineering a file container format for a racing simulator video game. I wanted to use my own code to automatically parse the track layout file to render a track map. Manual extraction of the file could be done with a modding tool, but it was closed source and couldn't be (easily) automated. Getting the file list of a resource file was easy as it was plaintext.. however the file data was not. It was a binary mess whereas the file was plaintext. Had they encrypted the data? Compressed? Obfuscated with an unknown XOR mask? Combination of all? The answer was a combination of XOR and compression.. The clue was looking for 'copyright' strings in the modding tool.. that uncovered a reference to the classic deflate library that is used for ordinary ZIP compressions, and then painstakingly following the deflate library code calls back to the location of the secret XOR mask.

Obscurity buys you time, but only time. In the old days one would execute the copyright message. On the z80, ASCII chars were mostly reg-reg moves etc, nothing explosive, and counterfeiters would often edit the copyright message

I am amazed that C (I use only basic C) can be decompiled that well. I wonder what the motivation was behind developing such tools.

I agree. So that's the question if the product must be unbreakable by some specific requirement (e.g. if you want to take GPS L2 M codes with you), or it needs to be very unattractive to clone it, or the product must be a competitive enough that people don't buy the clones.

I think decompilers exist for research purposes (like seeing what a malicious rootkit, driver or virus is doing) and aforementioned reverse engineering purposes. In some jurisdictions, it's not illegal to reverse engineer software (even though the EULA makes you believe it is) if the purpose is to increase intercompatibility with different products [after having negotiotated a support ticket with the OEM/if the OEM not around anymore/probably a dozen more reasons that best to contact a lawyer]. Making a competing or counterfeit product, however, is often outside (we know which ones view it as inside) the allowed realms.

[ataradov]

I wondered about some points made by darkspr1te above. Could not really understand them.

Most of it is obscurity at various points (in the firmware, in the protocols). All this really does is make it harder for you to maintain the firmware.

Those things may prevent direct copy-paste, but it may not even matter. If getting rid of all the checks turns out to be annoying, it may be easier to extract relevant algorithms and recreate the rest from scratch.. I don't need to sit there and reverse-engineer LwIP code.

This may delay most obvious clones for some time, but it is not a long-term solution. 

Some "obscurity" features are easy e.g. run bits of code out of timer ISRs, or use DMA to move data into the right place.

Sure, but they don't do anything. If the firmware binary is leaked, you are done regardless of how obscure it is. And in the worst case scenario you will be made fun of or put forward as an example of pointless attempts with obscurity.

Also, don't forget that there are people that like reverse-engineering and have developed pretty advanced tools to help with that.

[AndyBeez]

I am not doing anything which will be visible to customers. I wondered about some points made by darkspr1te above. Could not really understand them. Some "obscurity" features are easy e.g. run bits of code out of timer ISRs, or use DMA to move data into the right place.

Very well obscurating binaries, for example behind an AES enabled bootloader that's inside hack proof hardware, but what happens when your customer deliberately [or accidentally] open sources their code with libraries on a public domain repo?

Possibly from a business IP point-of-view, you need customers AND their trusted third parties to enter into a strict Non-Disclosure Agreement whereby, none of their code enters the public domain. Not ever. If you're using an open source bootloader and/or RTOS, you've already conceeded a handle to the reverse engineers.

Maybe step back and ask, what expectations will your customers have developing their implementation with your product? For example, if I purchase a Broadcom development kit, I am doing so as a serious OEM who knows the NDA I signed is there to protect both my product line as well as the vendor's IP interest. If I buy an Arduino Nano clone, I expect to rip it to pieces and share that on Github and Youtube.

[abyrvalg]

Note that obfuscation tricks, like those mentioned by darkspr1te, are meant to protect from analysis, not from cloning. If a full flash image of one device flashed to another device just works fine, a cloner wouldn’t care analyzing it. If you want to push the attacker to deal with your obfucsation - you need to have something important to obfuscate in the first place, i.e. some binding to MCU UID that prevents full flash copy to run on another device as is.

[peter-h]

Quite a few chips have a unique S/N. The 32F417 has one, the Adesto SPI FLASH chips have another, and some of these have an OTP area which can be programmed only once. Then there are various "unique random S/N" chips, although most of them seem unobtainable right now. So there is plenty of potential for pissing off somebody who just transplants the CPU, or transplants one chip, or transplants a CPU FLASH image. All that is very easy to block. Getting around it does then need disassembly.

[ataradov]

So there is plenty of potential for pissing off somebody who just transplants the CPU

Not really. If you are making a clone of a product, you sort of expect something like this. And it is not too hard to find places where UID is read and just substitute a fixed value.

It would affect people trying to fix a legitimate device. But without a binary, this scenario is not valid anyway.

If the binary is available, there is nothing you can do to prevent clones of a standalone device.

[peter-h]

Am I right that if I select Level 2 security, but still enable firmware updates (via a boot loader which runs in RAM), there is no way to prevent one of the firmware updates from reading my boot block (bottom 32k)?

I am sure the answer is that this cannot be prevented. Any installed software module has total access.

I wonder if there is some obscure way e.g. storing data on an SPI chip and blocking the SPI somehow.

[ataradov]

Am I right that if I select Level 2 security, but still enable firmware updates (via a boot loader which runs in RAM), there is no way to prevent one of the firmware updates from reading my boot block (bottom 32k)?

If your firmware chooses to dump itself over some serial interface, then no, there is no way to prevent this. But why would you release a firmware that does this?

EDIT: Ah, I remember now that you let users upload any firmware they make. There is no way to prevent a user firmware from reading the bootloader. Newer devices, especially ones based on Cortex-M23/M33, have what you need. But for the older designs there is nothing you can do.

I wonder if there is some obscure way e.g. storing data on an SPI chip and blocking the SPI somehow.

The running firmware can always read the flash. If CPU can execute it, it can be read.

[eutectique]

From what I read in the 32F4 RM, you are right, the code can access any legal memory address (I worked with 32L4 devices, their RDP is the same).

You can have off-MCU storage, but the communication must be encrypted. And the keys would be stored in your bootloader. So, there is no point.

What data do you want to protect? If it is level 2 RDP, the only way into your device would be with FOTA, which is encrypted, methinks. With level, 2 breaking in is the matter of budget/skills/equipment. Level 1 is reversible, you can find a report.

[ataradov]

What data do you want to protect?

His product is essentially a bootloader that lets users build and upload custom firmware. This firmware can do whatever it wants.

There is no point in setting any protection here.

[SiliconWizard]

Well, since the whole business model seems to revolve around allowing customers to write and upload custom firmware, I don't really see the point of this protection either. It's weird.
Or maybe the OP is expecting his *true* customers to be nice and never leak any code, why he's afraid of some non-customers trying to clone the product? Hey they can invest in one of his products if they want access to source code. Not that much of a problem.

And yes, this is a tough model per se. I would not be very keen on selling that myself.

Probably there's something we are missing here. Dunno. Does the OP want to open part of the firmware to allow customization while hiding another part of it that users would just call as a black box? That sounds a bit optimistic as far as the "black box" concept goes. So, yeah, dunno.

[peter-h]

Yes, info missing

There are multiple angles which I don't want to go into.

But if I let a customer load his own software module, he may still want to set L2 afterwards (and carry the risk).