Locking Code « LeafLabs Garden

LeafLabs Garden » Development

Locking Code

(9 posts) (4 voices)

Started 3 years ago by tmbomber
Latest reply from gbulmer

tmbomber
Member

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.

Posted 3 years ago #
tmbomber
Member

Folks, I said it might be a silly question, but it was a serious one.

Any thoughts on this out there???

Posted 3 years ago #
gbulmer
Moderator

I have dug around and only found:
http://www.hitex.com/fileadmin/pdf/insiders-guides/stm32/isg-stm32-v18d-scr.pdf
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/DM00033344.pdf

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. " !

Posted 3 years ago #
feurig
Member

Thanks gbulmer! I knew it was out there but I really didn't have time to rtftn's and field this one.

Posted 3 years ago #
gbulmer
Moderator

tmbomber - I found something a little more helpful. Section "2.4 Protections" and "2.5 Option byte description"
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/PROGRAMMING_MANUAL/CD00283419.pdf

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.]

Posted 3 years ago #
feurig
Member

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.

Posted 3 years ago #
gbulmer
Moderator

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.

Posted 3 years ago #
ala42
Member

According to this thread 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
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.

Posted 3 years ago #
gbulmer
Moderator

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.

Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.