Software Hacking via JTAG/SWD possible?

[manuel239955_stm1]

Posted on August 07, 2012 at 07:47

Hello all,

Is it possible to ''hack'' a products' software via one of the Debug interfaces JTAG/SWD? If yes, how is it possible to protect our products? Thanks!

[Tesla DeLorean]

Posted on August 07, 2012 at 16:10

Can people hack your device? Yes

Can you stop them? Probably not. Depends on who you're protecting it from, rank amateurs, or elite well equipped ones. You can disable the SWD/JTAG interface early in the reset handler, but changing the BOOTx pins can still bring it up enabled. You can hide the BGA pads. You can enable Read Out Protection (ROP), this makes using and updating difficult. Put critical data in memory cleared by the tamper input. Then again if you're willing to remove the parts, decapsulate and put them under a SEM/FIB you might be able to extract the details you need.

[emalund]

Posted on August 07, 2012 at 18:25

Just a comment

Can you stop them? Probably not. Depends on who you're protecting it from, rank amateurs, or elite well equipped ones.

This is basically the norm for embedded processors, not ''ST being easy to hack compared to others'' Erik

[Tesla DeLorean]

Posted on August 07, 2012 at 18:51

Indeed, pretty much any silicon device is going to be vulnerable to some form of analysis or attack by an IC QA department or companies that specialize in such things. Expensive equipment can be rented, or acquired on the secondary markets.

Even things that have lots of engineering effort to protect them have been broken. I always assume that hackers can out smart, or out think me, or have discovered a method that reduces the assumed complexity by a couple of orders of magnitude. They are generally curious and ingenious. Having a strong front door, with quality locks, will not stop someone willing to break a few windows, or kick in the back door.

[dannym]

Posted on August 08, 2012 at 00:14

Well it depends on what you mean by ''hack''.

The firmware itself can be protected ''well'' by setting code protection.  You will not be able to read that code memory back out, so they will not be able to copy your chip nor reverse-engineer the source from assembly.  No one can say it's ''impossible''- there are always ways to rip the chip apart and probe the memory bus to read the code.  But it's expensive to do this, it requires a lot of hardware, experience/skill, and time, and few projects are so unique, so valuable, and so critical that anyone with these resources would find it worth their time to do this.  And it only would yield assembly- paradoxically, if you knew enough about what the code needed to do to interpret the assembly in a meaningful way, you might have just coded the solution better on your own without probing the chip.  But an example of an exception might be highly sensitive crypto keys or methods.  A typical hacker cannot, no.  If you have properly utilized the STM32's code protection, it is highly unlikely that a user would be able to copy your code through the STLink.BUT, if you're talking about reflashing new firmware onto it so the device can be ''hacked'' to do something new, hmm, I don't know if the STM32 could be fused to disable the programming port forever.  Honestly it's an unusual thing to want to do, your hardware could never be upgraded and any bugs discovered would be permanent.  Even entering production with an SMD package would be troublesome, as it will not identical to the reprogrammable code you used for development, and you risk bricking device after device in a way that would require SMD rework to physically replace a bricked controller.  And I'm not sure how you'd use the JTAG to scan the pins- without JTAG, board integrity can't be verified so production quality could be poor.  It doesn't seem like a feature you'd actually want to use.You could simply fail to create board traces for the programming pins, this would mean you'd have to program the STM32 chip separately, in a clamshell- this can be a costly process for production.It's futile, however- whether the STM32 had a ''never-write-again'' feature, or you don't make traces for the STLink, all a ''hacker'' would need to do to install unauthorized firmware onto your board is buy an identical STM32 chip new, burn their own firmware, and SMD rework it onto the board.  That has indeed come up with people ''modding'' their game consoles to bypass enforcement against copied or region-protected games, they will actually SMD rework on a new BGA package with hacked functionality.  Whatever protection the old chip had against rewriting is made irrelevant.

[Tesla DeLorean]

Posted on August 08, 2012 at 02:25

While I agree with many of your points I think your image of a hacker is the hobbyist software and solder guys, while mine is one of industrialist/engineering guys who know IC QA, test and design.

ST once suggested that it would need $1M worth of equipment to break ROP, like that was some level of entry to break the design, people who think outside the box would suggest you merely need to know someone who has access to $1M worth of equipment. Check out your local university engineering labs some time. Ask yourself how many gates in the design enforce the ROP.

[manuel239955_stm1]

Posted on August 08, 2012 at 13:25

Hi Danny,

indeed i am talking about ''stealing'' the companies software to copy a product. The question is if it is easier to do that if SWD/JTAG is available, since these are debug interfaces.. If i activate read out protection, i should still be able to update the firmware (write to flash), am i correct? Thanks!

[Tesla DeLorean]

Posted on August 08, 2012 at 16:17

The question is if it is easier to do that if SWD/JTAG is available, since these are

debug interfaces.. If i activate read out protection, i should still be able to update the firmware (write to flash), am i correct?

It's clearly ''easier'' as you have an off the self interface that even a script-kiddie could use, however pulling out code via the USARTs and Boot Loader aren't that hard either. You can complicate things by not exposing interfaces, or using not standard connectors or using obfuscated test-points or edge connections/castalations or break-offs. ROP can provide a quite substantial wall, but it assumes that the rest of your design/code is air tight. It will significantly complicate your programming and test, and field programming options. Code running from FLASH/ROM can read the content, user code can dump the content. The boot loader uses software based checks to enforce ROP. JTAG/SWD can be used to run code in RAM on protected devices.

[pmoore]

Posted on August 15, 2012 at 01:09

While I generally agree with Clive1's points regarding hacking into someone's IP stored in flash, I think by the time someone is willing to go that level of effort to get at complied assembly code, they are equally willing to put forth the effort to hack into the environment with the original source code.

If their only goal is to clone your product, with modern serialized processors and hardware encryption, there are ways to provide reasonable cloning protection. If you put up good barriers to IP theft and product cloning, you'll protect your IP from those you can protect yourself from.  There is no need to worry about those you cannot protect yourself from, as the only 100% safe option is to avoid IP creation in the first place...and what's the fun in that? -Patrick

[manuel239955_stm1]

Posted on August 15, 2012 at 07:30

Hi clive,

So using the read-out-protection is the first step to increase security of my processor.. Ive read quite a lot in the last days and it seems that the read-out-protection does not provide sufficient security since it is still possible to write code in SRAM which deactivates the ROP from there.. is that true? If this is the case, will my flash program be mass erased? (some sources say yes, others doesnt say anything bout that at all) Are there any further steps i can do to provide security? If ROP is enabled, how difficult is it to update software? should not be more difficult since its no problem if my ''old'' flash software gets erased, isnt it? Thanks guys for your help, have a nice day!