32F417: can SWD be blocked by internal software? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: August 28, 2022, 09:55:16 am
content: The last post herehttps://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.

author: langwadt
author_rank: Super Contributor
timestamp: August 28, 2022, 10:07:19 am
content: and you can use the boot pin to start the bootloader

author: nctnico
author_rank: Super Contributor
timestamp: August 28, 2022, 10:58:44 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 28, 2022, 12:05:10 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2022, 04:09:31 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 28, 2022, 04:41:41 pm
content: 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 isnoway to achieve the subject - because a debugger does NRST=0 which resets the AF mapping, and prevents software access to the BOOTx pins?

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2022, 04:55:07 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 28, 2022, 08:29:29 pm
content: QuoteDepends 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

author: eutectique
author_rank: Frequent Contributor
timestamp: August 28, 2022, 10:17:12 pm
content: Quote from: ataradov on August 28, 2022, 04:55:07 pmSAMV70 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.QuoteAutomotive 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2022, 10:30:07 pm
content: Quote from: eutectique on August 28, 2022, 10:17:12 pmYes, 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.Quote from: eutectique on August 28, 2022, 10:17:12 pmSure, 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 29, 2022, 06:38:25 am
content: QuoteI didn't realise this. So on the 32F417 onecandisable SWDfor the purpose of examining memory, and it isreversible by internal software?QuoteYes - 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

author: ataradov
author_rank: Super Contributor
timestamp: August 29, 2022, 06:44:08 am
content: Quote from: peter-h on August 29, 2022, 06:38:25 amYes. 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.

author: wek
author_rank: Frequent Contributor
timestamp: August 29, 2022, 06:59:17 am
content: QuoteThe exact effects of RDP settings including Level1 are clearly described in RM0090, in FLASH chapter's subchapter aptly namedRead 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

author: peter-h
author_rank: Super Contributor
timestamp: August 29, 2022, 07:09:08 am
content: OK, but you can trigger a software feature which starts the mass erase, doesn't need to run throughout the erase process, andthenyou 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 29, 2022, 07:10:10 am
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: August 29, 2022, 07:19:55 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 29, 2022, 07:28:12 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 29, 2022, 07:51:36 am
content: QuoteOk, 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?QuoteThere is nothing secure in my boot loader. In fact I have probably already posted the source here, a while agoIt 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.QuoteI 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

author: ataradov
author_rank: Super Contributor
timestamp: August 29, 2022, 07:55:47 am
content: Quote from: peter-h on August 29, 2022, 07:51:36 amNo 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.Quote from: peter-h on August 29, 2022, 07:51:36 amThis 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 29, 2022, 08:34:29 am
content: Thishttps://stm32world.com/wiki/STM32_Read_Out_Protection_(RDP)shows an "stm32 cube programmer". Never seen that beforeIt is indeed a whole separate app, perhaps suitable for production programming.https://www.st.com/en/development-tools/stm32cubeprog.htmlQuoteHow is that done? I didn't find this bit.QuoteSure, but that's a lot easier than decapsulating and scanning the FLASH, which is apparently possible.

author: AndyBeez
author_rank: Frequent Contributor
timestamp: August 29, 2022, 08:35:23 am
content: 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?

author: peter-h
author_rank: Super Contributor
timestamp: August 29, 2022, 08:57:16 am
content: 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 priceand 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.

author: AndyBeez
author_rank: Frequent Contributor
timestamp: August 29, 2022, 11:26:28 am
content: 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 dayI2C example:https://www.maximintegrated.com/en/products/embedded-security/secure-authenticators/DS28C22.html

author: peter-h
author_rank: Super Contributor
timestamp: August 29, 2022, 11:42:08 am
content: I think you would need a chip which both- holds the key, and- does the crypto internallyShort 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 MaximFor 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 linesI 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 thoseSame on anything going out to China, etc.

author: darkspr1te
author_rank: Frequent Contributor
timestamp: August 29, 2022, 03:39:49 pm
content: Quote from: peter-h on August 29, 2022, 11:42:08 amIf you want to piss someone off in the design then here are a few tricks1. epoxy the the vpu caps by the xtal pins2. 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 packets4. 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 up6. 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 ram10.use a key cycle system between versions11. spread keys across multiple locations a in between mundane checks12. 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 steppingdarkspr1te

author: darkspr1te
author_rank: Frequent Contributor
timestamp: August 29, 2022, 03:45:52 pm
content: 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

author: hans
author_rank: Super Contributor
timestamp: August 29, 2022, 04:47:27 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 29, 2022, 05:30:33 pm
content: QuoteDoesn'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: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 */QuoteHow does that work when the debugger resets the CPU and can read memory immediately?I can see it would prevent stepping through the codeon the target.QuoteThat would also prevent debugging the project during developmentI guess one could do a #define for that.Your other points are all good stuff for obscuring code flow - thank you.QuoteAmazingly often there is a DLL entry point called "checklicense" or some suchQuoteTelemetry? Nasty...QuoteStops you debugging on the final board, too. Would work only with a BGA package.QuoteWith 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.QuoteObscurity 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 messageI am amazed that C (I use only basic C) can be decompiled that well. I wonder what the motivation was behind developing such tools.

author: ataradov
author_rank: Super Contributor
timestamp: August 29, 2022, 05:40:59 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 29, 2022, 06:26:59 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 29, 2022, 07:44:48 pm
content: 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.

author: hans
author_rank: Super Contributor
timestamp: August 29, 2022, 08:28:47 pm
content: Quote from: peter-h on August 29, 2022, 05:30:33 pmNo.. just that word spreads fast in small-mid sized companies where only 1-2 dozen people work in 1 office building.QuoteCould 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.QuoteI 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.QuoteI 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 29, 2022, 08:37:24 pm
content: Quote from: peter-h on August 29, 2022, 07:44:48 pmMost 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.Quote from: peter-h on August 29, 2022, 07:44:48 pmSure, 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.

author: AndyBeez
author_rank: Frequent Contributor
timestamp: August 29, 2022, 09:14:02 pm
content: Quote from: peter-h on August 29, 2022, 07:44:48 pmVery 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 businessIPpoint-of-view, you need customers AND theirtrustedthird 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: August 29, 2022, 09:40:54 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 30, 2022, 07:45:39 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 30, 2022, 07:56:07 am
content: Quote from: peter-h on August 30, 2022, 07:45:39 amNot 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.

author: peter-h
author_rank: Super Contributor
timestamp: September 01, 2022, 02:57:38 pm
content: Am I right that if I select Level 2 security, but still enable firmware updates (via a boot loader which runs in RAM), there isno wayto 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.

author: ataradov
author_rank: Super Contributor
timestamp: September 01, 2022, 04:29:26 pm
content: Quote from: peter-h on September 01, 2022, 02:57:38 pmIf 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.Quote from: peter-h on September 01, 2022, 02:57:38 pmThe running firmware can always read the flash. If CPU can execute it, it can be read.

author: eutectique
author_rank: Frequent Contributor
timestamp: September 01, 2022, 04:33:11 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: September 01, 2022, 05:19:52 pm
content: Quote from: eutectique on September 01, 2022, 04:33:11 pmHis 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 01, 2022, 06:23:56 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: September 02, 2022, 09:50:45 am
content: Yes, info missingThere are multiple angles which I don't want to go into.But if I let a customer load his own software module,hemay still want to set L2 afterwards (and carry the risk).