LeafLabs Garden » Topic: Locking Code

LeafLabs Garden » Topic: Locking Code http://forums.leaflabs.com/topic.php?id=9661 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:06:46 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php gbulmer on "Locking Code" http://forums.leaflabs.com/topic.php?id=9661#post-21464 Tue, 04 Dec 2012 21:21:16 +0000 gbulmer 21464@http://forums.leaflabs.com/ ala42 - A very interesting thread. I am with the user 'lanchon', there should be a clear explanation of how things work. I struggled to get a clear picture from PM0075. I thought it was me not thinking hard enough, so it's a bit of a relief it's not just me :-) PM0075 does state some things are prevented. My reading of that thread is it's inadequate. There are plenty of edge cases which are unclear (from PM0075) and no explanation of how protection is achieved to give the user confidence in the assertions. I struggle to imagine how anything can be protected if JTAG/SWD is available. To protect a device those pins need to be disabled. For a physical attack that'll be hard. Also, USART1 and with appropriate settings of BOOT pins will load and boot from RAM. So USART1 and the boot pins need disabling too. @tmbomber - could you encapsulate the board, e.g. in a block of epoxy, to make physical attack difficult and detectable? Or is that inadequate? I struggle to believe that a program in RAM is blocked from copying Flash to RAM under all circumstances. The ARM doesn't have "load in-line literal value" instructions, it uses 'constant pools' which are read using an addressing mode (offset from a memory address in a register). So for code executing in Flash, those addressing modes must still work. It'd take several days work to determine that simple attacks don't work, and that wouldn't prove the device is secure, just you couldn't find a successful attack. ala42 on "Locking Code" http://forums.leaflabs.com/topic.php?id=9661#post-21461 Tue, 04 Dec 2012 19:27:54 +0000 ala42 21461@http://forums.leaflabs.com/ According to this thread <a href="https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FProtection%2C%20Is%20my%20code%20in%20Flash%20really%20secure&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=8182" rel="nofollow">https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FProtection%2C%20Is%20my%20code%20in%20Flash%20really%20secure&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=8182</a> you can load code into the internal RAM and start it. RAM code can read the protected flash rom. I have not tried that myself. gbulmer on "Locking Code" http://forums.leaflabs.com/topic.php?id=9661#post-21456 Tue, 04 Dec 2012 14:39:36 +0000 gbulmer 21456@http://forums.leaflabs.com/ Yea, finding stuff is becoming dreadful. We're drowned in noise. The only way to make a living in search is advertising, and advertising and detailed, factual accuracy are not strongly aligned :-( I've sometimes tried duckduckgo too. It seems very 'hit and miss' - sometimes it is better, sometimes much worse. Even with "site:www.st.com f:pdf" neither google nor duckduckgo could find an appropriate document with "stm32f103 flash protection", or even "stm32f103 protection". I imagine it might be because ST have broken their web site. When I searched on ST.com, I couldn't find anything better than the "AN3429" Application note, which isn't really what is needed. It is almost easier to download all of the application notes, user manuals, data sheets, technical notes, programming manuals, reference manuals, and errata then let Mac's Spotlight have a search. feurig on "Locking Code" http://forums.leaflabs.com/topic.php?id=9661#post-21454 Tue, 04 Dec 2012 14:13:29 +0000 feurig 21454@http://forums.leaflabs.com/ My web developer friends highly recommend duck duck go as a potential workaround to googles increasing commercial noise to usable data ratio. Its getting harder and harder to just find what you need these days. gbulmer on "Locking Code" http://forums.leaflabs.com/topic.php?id=9661#post-21440 Mon, 03 Dec 2012 21:31:43 +0000 gbulmer 21440@http://forums.leaflabs.com/ tmbomber - I found something a little more helpful. Section "2.4 Protections" and "2.5 Option byte description" <a href="http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/PROGRAMMING_MANUAL/CD00283419.pdf" rel="nofollow">http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/PROGRAMMING_MANUAL/CD00283419.pdf</a> IIRC, you also need to disable JTAG/SWD, or option bytes can be changed through that route. [Irritatingly, I had more luck with Spotlight on my Mac than (the increasingly pathetic) google, so it took longer to find the on-line originals that it might if google had just found stuff.] feurig on "Locking Code" http://forums.leaflabs.com/topic.php?id=9661#post-21439 Mon, 03 Dec 2012 20:44:39 +0000 feurig 21439@http://forums.leaflabs.com/ Thanks gbulmer! I knew it was out there but I really didn't have time to rtftn's and field this one. gbulmer on "Locking Code" http://forums.leaflabs.com/topic.php?id=9661#post-21436 Mon, 03 Dec 2012 18:20:33 +0000 gbulmer 21436@http://forums.leaflabs.com/ I have dug around and only found: <a href="http://www.hitex.com/fileadmin/pdf/insiders-guides/stm32/isg-stm32-v18d-scr.pdf" rel="nofollow">http://www.hitex.com/fileadmin/pdf/insiders-guides/stm32/isg-stm32-v18d-scr.pdf</a> <a href="http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/DM00033344.pdf" rel="nofollow">http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/DM00033344.pdf</a> IIRC this data has been available, but the second (ST) document recommends "For more details about the complete solution, please contact your local ST sales representative. " ! tmbomber on "Locking Code" http://forums.leaflabs.com/topic.php?id=9661#post-21370 Fri, 30 Nov 2012 18:45:41 +0000 tmbomber 21370@http://forums.leaflabs.com/ Folks, I said it might be a silly question, but it was a serious one. Any thoughts on this out there??? tmbomber on "Locking Code" http://forums.leaflabs.com/topic.php?id=9661#post-21202 Tue, 20 Nov 2012 16:47:23 +0000 tmbomber 21202@http://forums.leaflabs.com/ Hi Everybody, This may be a silly question, but it's something that I'd like to know... Is there a way to hand out a programmed Maple without having to worry about someone sucking the code out of it, disassembling it, and reverse engineering my source code? Say I have a bit of code loaded onto a Maple, and for the time being I wanna keep that code private. I'd like to pass the board around to a couple people for them to play with, but I'm not ready to let them have the code. In days gone by I've done just that on other processors. But I'm unsure if it's possible with the Maple's processor. (lets assume that the people I'm giving the board to are resourceful enough that if your answer is "difficult, but possible" you'd actually be say "yes, they can") I know there's lock bits in the fuses of the ATMEGA processors, but I'm unsure what those actually do. For the Maple board I've never played around with anything other than the standard IDE so I'm unsure what options are available.