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: TM4C123GH6PZ

Part Number: TM4C123GH6PZ

Hi All,

I would like to find a way to secure the .bin file. Check all the security options before uploading the .bin file on the TI MCU TM4C123GH6PZT.

Is there any Security Tool either online from TI or from TI support team so that I can save .bin file with the added security option so that nobody can copy the code from the Micro or use it for other similar application.

This is mainly to protect the code (.bin file) from any other person who may intends to copy for using on other similar device or application.

Thanks & Best Regards,

Mohammad

 

 

  • Mohammad Khan82 said:
    This is mainly to protect the code (.bin file) from any other person who may intends to copy for using on other similar device or application.

    The actual binary file? No. You could use winzip or similar to protect it during transport but anyone programming it would need to have the password.

    If you mean protect the binary in the micro. Than answer is mostly no. There is a read protect bit but such bits are known to be vulnerable. Note that this weakness is not unique to TI, it is industry wide.

    Robert

  • Hi Robert,
    Thanks for your quick response. You are right as I need to protect the binary in the micro. How do you set read protect is it during creating binary file from the source code.
    Besides is there any other protection you may add on the binary file (.bin file) so that any other person can not copy the .bin file from the MCU.
    I would like to find some method so that after adding the security option this MCU can not be even reprogrammed.
    Do you know how this type of protection is possible for this MCU part number: TM4C123GH6PZT.
    Thanks & Best Regards,
    Mohammad
  • It proves wise to invest (some) effort in creating a Subject Line which, "Sell your post!"      (or - at minimum - clarifies your issue/objective)      Minus that awareness/effort - why would anyone (want) to respond?

    As to securing code in your MCU - NOT a prayer - all protection means vendor touts are "quickly/easily" defeated!     They are "illusory" at best - create false hope - at worst.

    If in (any) doubt - do request a "writing" from the vendor - which guarantees that such methods provide (real) security.    No such writing will be granted...

  • Mohammad Khan82 said:
    You are right as I need to protect the binary in the micro. How do you set read protect is it during creating binary file from the source code.

    Check the TIVAWare manual, I'm not sure it can be done in code. I've never been interested in it.

    Mohammad Khan82 said:
    Besides is there any other protection you may add on the binary file (.bin file) so that any other person can not copy the .bin file from the MCU.

    Not in the bin file . The best method is good design and meeting a demand for a reasonable price*. You could add physical protection in the device's case. And it's been suggested that submerging the board in molton iron and placing the resulting assembly at a deep oceanic subduction zone may be effective.

    There are ways of tying the binary to a particular board, but that's a jump in cost and effort. Really this all boils down to the cost of breaking the protection vs. the cost of the loss of the binary.  How much is your binary worth?  Answer that question and you'll know how much effort you can afford to add extra protection.

    Robert

    * Really you only have to concern yourself with two groups of people. With the ethical group you don't need protection they won't copy anyway. With the unethical group it won't matter.

  • There are ways to restrict the ability to read the code programmed into the TM4C123GH6PZ device, but Robert is correct, these means are not guaranteed to be 100% secure. One means is to mark sections of the code as "Execute Only". This requires using special compiler options to isolate literals from the rest of code (which can slow things down and complicate the link command file). This is described briefly in section 8.2.3.3 of the datasheet. A more severe action is to disable debug. This is described in section 8.2.3.5. Both of these methods involve programming non-volatile registers. This is done by executing code in the device as opposed to settings in the object (bin) file. This is described in section 8.2.3.10.

  • Hi Bob,
    Thanks for your detailed explanation on how to protect the TI firmware by using 8.2.3.3 "Execute only" and 8.2.3.5 "Permanently Disabling Debug" option. We still need to use 8.2.3.10 "Non Volatile Register Programming". Our developer will follow as per instruction and I will try if the security options functioning properly.
    I will let you know once I verify the result.
    Thanks & Best Regards,
    Mohammad Khan