• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 35 subscribers
  • Views 1018 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.

Regarding Flash

surendra malampati
Intellectual 960 points


 I have a small technical doubt regarding Flash in the Tiva C series Controller.
My objective is i need to protect the code (bin file) which is  will not extract or read by the hackers from the Flash.For this i need give the READ PROTECT 
The conditions which i have to follow:
1) I should only  have to write the bin file multiple times in the flash and it should be executed but not read by others(i.e not read b hackers).
What are the rules i have to follow.Please give me suggestions how can i do this in software and how can i do this hardware?
Thank u....... 
  • 0
    Guru 86765 points
    Hi Surendra,

    See, "Flash Memory Protection Policy Combinations" at your Tiva MCU Datasheet.

    - kel
  • 0 in reply to Markel Robregado
    Intellectual 960 points
    Is it need to write the program in software or have to do any changes in the CCS compailer() .
  • 0 in reply to surendra malampati
    Guru 86765 points
    Hi,

    Most probably you need to write a code to set Flash Protection. I have not tried to set my Tiva MCU Flash Memory Protection, so I am not that knowledgeable about it.

    See FlashProtectSave() and FlashProtectSet() at Tivaware Peripheral Driver Library User's Guide.

    - kel
  • 0 in reply to Markel Robregado
    Intellectual 960 points
    Please help me whose have the knowledge on this.I am new with this.
  • 0
    Guru 117855 points

    surendra malampati said:
    I have a small technical doubt

    Just a "small" one?    Did you not ask near identical question - right here - just yesterday?    And was that not answered?

    It's not our job to, "Answer to your hopes/dreams" but to what we believe (and know) to be correct.   Don't you agree?

    As clearly stated - just yesterday - you cannot "protect" your code on this class of MCU.   You may make it a bit harder - take bit longer - but a determined hacker can (relatively) quickly - defeat your defense mechanisms.   As a "doubt remover" - it's not hard to "decap" any MCU - and via x-ray - expose each/every byte of your (not well protected) code!

    MCU vendors most always include "disclaimers" which disavow any guarantee that your code can be, "protected."    At some point - you might come to accept this...   (and release that "small" doubt...)

  • 0 in reply to cb1_mobile
    Intellectual 960 points
    As clearly stated - just yesterday - you cannot "protect" your code on this class of MCU.

    @cb1.You told me that it cannot possible to protect.Then what about these function calls FlashProtectSave() and FlashProtectSet().
  • 0 in reply to surendra malampati
    Guru 117855 points

    As past stated - and now repeated here - those functions are emplaced to force, "bit harder & more time consuming hurdle" in front of an "amateur hacker."

    A skilled, serious, determined hacker (i.e. a "pro") can quickly/easily pull every byte of your code - even if (and especially if) you provide all those "protections" and blow the JTAG fuse (or otherwise disable JTAG.)

    As elsewhere stated - search for "Secure MCU" to see - how far more expensive MCUs "attempt" to deal w/such issues.

    As one further "reality check" - if Governments cannot adequately secure their data - do you believe that a sub 10 (USD) MCU can be "protected?"

    Note that MCU vendor's use of "protect" does not extend to, "Degree of protection!"     Reality is sometimes harsh - 10 (USD) cannot come close to, "Protecting!"

  • 0 in reply to cb1_mobile
    Intellectual 960 points
    @cb1.Ya now tell me how can i protect code my self?
  • 0 in reply to surendra malampati
    Guru 47900 points

    Reread my earlier post - which suggested "protection" as a "false God" - and offered other methods to (far better) rebuff such attacks.

    If you're really interested - books exist - Google should yield days of reading - there is NO quick/easy (effective) "protection" strategy...

  • 0 in reply to surendra malampati
    Guru 27665 points
    cb1- is correct. absolute protection is an illusion, a will o' wisp. If you do a search on secure microcontrollers you may find a paper from a decade or so ago that tested a number of these devices and found even they were very vulnerable to being read by people with the knowledge, tools and desire.

    It is a trade-off between cost to protect and the value you are protecting. Most of the cases where a great deal of effort is expended are protecting data not code, (think bank cards, pay TV receivers etc...).

    For many embedded devices for the SW to be of any use you need to copy the HW as well. For simple designs, it's cheaper to reproduce a design than to copy outright (and I've noticed many of the most concerned are trying to protect designs that are easy to reproduce w/o copying) Both may enjoy additional legal protection such as copyright.

    Protection ranges from relying on copying being too much effort for the gain to the simple code protection available on most micros to secure micros to cryptographic processors.

    What the protection on the micro does give you is evidence that you have tried to protect the code which may bring you under the protection of the anti-tampering provisions of some legislation (DMCA?). It also raises the bar of effort to copy.

    A far more serious reason to use it is not to prevent copying but as part of a scheme to prevent users overwriting working code in a controller. Not an issue for blinky lights in a toy. A big issue for something that is network connected, imagine overwriting the control for a network connected drive feeding fuel into a blast furnace or adding a patch on top of an HVAC control that provided access to the network it was on without affecting its normal existing functionality.

    There certainly are cases for using the protection bits, just don't expect too much from it. Metaphorically it's a simple front door lock, not an armed hardened fortress.


    Robert
  • 0
    TI__Guru**** 244440 points
    Hello Surendra,

    When you write a bin file note that you need to check if it downloaded correctly. That will involve a read. You may temporarily disable the read protection but that gives the "hacker" a good chance to see your image.

    The 1st level of protection is JTAG disable to avoid a user reading in the direct path
    The 2nd level of protection is Read protect to prevent a rogue code to read in the program.
    The 3rd level of protection is Encryption of the download code as the user may not even need to look into the flash but snoop on the download interface.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    @ Robert & Amit,

    I've clicked "Like" for both of your posts.

    Amit provides great TM4C detail - and it's general enough to apply across many MCUs - many vendors. It should be stated that this is by NO MEANS any limitation of the TM4C - it is a very common limitation of most all MCUs. (but for those specially hardened - and as Robert notes - those too may be "broken.")

    Robert's post is simply terrific - more patient than mine - yet my "Fool's Gold" analogy appears to hold - even sanctioned by these two forum "experts."

    Reality is indeed harsh at times - "protection" stemmed more from vendor's marketing dept. than from its engineering or "fact check" division...

    One may (later) examine the degree of "launch" provided by a small pcb which does not properly "group" serial ports/pins - provides only one "level converter" (none for RS232/485, CAN, nor default pull-up Rs for I2C, nor UART to USB converters for all ports beyond Port A.)   Econo - surely - launch - not so much!

    We do love our marketing dept...   And - might your "small technical doubt" now - have been resolved?