• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 494 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123GH6PZ: Protecting the software on flash

Nadav Bahana
Intellectual 440 points
Part Number: TM4C123GH6PZ

Hello,

We are creating a device using the TM4C123 processor,

I noticed in LM flash programmer that there is an option to "upload the flash contents to a.bin file".

This is unwanted because I don't want anyone to have access to our software.

Is there a way by software for me to prevent the flash from being extracted off the device?

Thanks

  • 0
    TI__Guru*** 135355 points
    Hello Nadav,

    To prevent LMFlash Programmer from accessing Flash, there are DBG0 and DBG1 bits in the BOOTCFG register which prevent JTAG access. However, this can be undone by the LMFlash Programmer while also mass erasing Flash. If all you want is to prevent software to be read, that is a partially effective approach as the Flash would then be erased (more on why it's partial shortly). To keep LMFlash programmer from being able to clear the BOOTCFG register + perform Flash mass erase, you would need to disable JTAG on your board by turning the JTAG pins into inputs or have some other means to prevent LMFlash from communicating with the JTAG interface.

    Now then for the partial part... it sounds like your total goal is to prevent Flash from being extracted off the device. If that's so, please keep in mind this isn't a high security device. There are roadblocks you can put up to make life harder such as preventing JTAG being used, but it's impossible to fully secure device from all forms of Flash extraction, so just be aware of that.
  • 0 in reply to Ralph Jacobi
    Guru 27665 points

    Ralph Jacobi said:
    Now then for the partial part... it sounds like your total goal is to prevent Flash from being extracted off the device. If that's so, please keep in mind this isn't a high security device. There are roadblocks you can put up to make life harder such as preventing JTAG being used, but it's impossible to fully secure device from all forms of Flash extraction, so just be aware of that.

    It's good to see this pointed out. I would add, in emphasis, that having this done is likely to be quite inexpensive. Doing so also restricts your capability to access a programmed micro.

    Robert

  • 0 in reply to Robert Adsett
    Intellectual 440 points
    Okay, thanks.
    Another layer of protection might be adding a unique key to each device that would be linked to the value in DID0 and DID1 registers.
  • 0 in reply to Robert Adsett
    Guru 117855 points

    And may this "late arriving" reporter - ADD to "outsider joy" - that vendor agent has not, Perpetrated the FOLLY that, "a sub 10 (USD) device may be fully protected from "prying eyes!"

    This class MCU - from this vendor and ALL OTHERS (importantly - this is NOT a "Vendor Weakness") is able to "throw up" only,  "fairly meager, code-security  defenses!"    

    Just as Financial regulators on "Wall Street" - attempt to, "Insure Regulatory Compliance" - such task (near identical to yours) faces this reality:

    • those being regulated (code breakers - in your case) are (usually) Far Smarter than the "Regulators" - or "would be" code protectors.   (i.e. small volume, MCU users - sorry!)
    • those being regulated are  Far "better motivated" than the "work-a-day" (drone) regulators.    Code breakers usually are (very) well rewarded - thus motivation PEAKS.
    • those being regulated are often Far "better equipped" than are the regulators.    In your case - do what you will - I can "decap" your MCU - X-Ray  if needed - your code then, "stands naked!"

    Disabling the JTAG (or other "bandaids") may impede the efforts of a, "Not fully equipped junior high student" - but are quickly/easily overcome - by one, "Skilled, Equipped, Experienced and Motivated!"

    Should you, "Review the security attempts of users here" (via forum's Search Box) - you will note a, "High occurrence" of users ... "Locking (only) themselves out!"    Delightful - and poetic...

    Thus - your "product's success" should result - NOT from "security" - but INSTEAD:

    • Quickness to Market - he who arrives early - reaps highest profit - greatest benefit
    • Reasonable number of desired features
    • Attractive Pricing
    • Clear operating manual
    • Above average user support
    • Proper Quality Control
    • Innovative Distribution
    • Effective Promotion & Advertising

    None of these will "prevent" your chip's "hacking."     Yet - in concert - they provide the best chance for, "that which you (perhaps unwisely) seek to secure" to GO FORTH  and Succeed w/in the Marketplace!

    And it is that Sales Success - and sustainability - which proves a far more "proper" and (perhaps) attainable goal!       Securing a sub 10 (USD) chip - Not so much...

  • 0 in reply to cb1_mobile
    Intellectual 440 points
    It seems that you are right,
    We don't have a chance in securing the software from hackers.

    BTW I read some more and saw that the DID0 and DID1 are not unique to each MCU, so that wont even help me in making it harder.
  • 0 in reply to Nadav Bahana
    Guru 117855 points

    Thank you - it is "not" that I am right - instead my goal is to present  "reality."     Working for a similar semi-giant - we (sometimes) "lost our minds - and our code" - thus were forced to be able to recover code by, "less than conventional means."

    Accept too - that unless your development is "especially unique & inspired" it is unlikely that (anyone) will "Care much - for your code!"  (*)

    Thus - you are ordering up, "Inefficient Protection" - for an "unseen" - and more likely - a non-existent attacker!       Such does not make much sense - does it?
    And - as noted - the person(s) most delayed, de-focused, and most "locked-out" - will be YOU!

    Bullet-points w/in the earlier post present those tactics which enabled, "3 cohorts & I to found - then take tech firm Public!."     Has the content w/in that post - not proved worthy of  "Resolved?" 

    With adequate "effort, focus, experience, good-fortune and "admission of reality" - you may reach such heights - as well... (but NEVER via "security!")

    (*)   In the case that you/firm are providing product - in some volume - to, "One or very few clients" - then they (the client(s)) very well "may" have an interest, "in your code!"    (as - armed w/your code - and a "board-copy" - they are (operationally) free to, "Remove you/firm - from the picture!")      A properly drawn contract - and software copyright + "special features" - may reduce/discourage such eventuality.