• State Resolved
  • Locked Locked
  • Replies 22 replies
  • Subscribers 33 subscribers
  • Views 2289 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.

How to prevent code theft?

ROM_Jamie
Intellectual 810 points
Other Parts Discussed in Thread: UNIFLASH

It has become painfully obvious that a company we are working with will attempt to clone any Tiva they receive from us if it is trivial enough to do so. I would like to find a good way to prevent them from doing so as much as we can.

I read this thread http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/343078 but I don't think that will discourage them enough. i.e. they would just rewire the USB and unlock the JTAG interface. It would also be nice to leave that JTAG USB alone so that we can still update the device.

Are there any other ways to lock down the code? Like linking it to the serial number of the Tiva?

  • 0
    TI__Guru**** 244410 points
    Hello Jamie,

    TM4C123 does not have a unique serial number unlike TM4C129. However as per the post, if a unlock sequence is done then it would erase the flash and thereby any attempt to get to the code.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 810 points
    Perfect, I missed the part about erasing the flash. It seems the concerns further in the thread are more about preventing someone from injecting problematic code. I've got no problem with them trying to flash the hardware with their own code (if they want to void any warranty), they just can't be cloning mine! I suppose the risk is that a device in the field could still be sabotaged by some clever saboteur.
  • 0
    Guru 47900 points

    ROM_Jamie said:
    I would like to find a good way to prevent them from doing so as much as we can.

    I've not made time/effort to find/read that past thread - yet our clients have expressed their concern about their clients - attempting such mischief!   

    We use this method across multiple ARM MCUs from several vendors - so far - so good.

    a) employ a "switch-over" method similar to that described w/in "JTAG-GPIO.c."   This prevents "easy" access to JTAG.

    b) design your boards to include programmable FPGA/CPLD - increasing the time/cost/effort of (would be) crackers.   Such chips may add HW based logic functions and extend MCU's GPIO count - both worthwhile.   (when not sold to "dishonest" or when design does not require - simply "DNF" those parts)

    c) always create a check-sum - encrypt it - and then require its proper decode prior to any access/probe to MCU's memory.   (fends off (added) illegal code's attempt to "dump your code" via memory access and output - not managed via JTAG/SWD)

    Good fences make good neighbors - same may hold for electronic device security.   (know that if someone (really) wants your code - they will have your code...)

  • 0 in reply to ROM_Jamie
    Guru 27285 points

    ROM_Jamie said:
    I suppose the risk is that a device in the field could still be sabotaged by some clever saboteur.

     As from good CB1 post, this can be a legal question than technical, you have a secure way to prove your code is no more inside processor so you need some password activated never used on field so none can know to have access to memory...

     Without these secret necessary complex function you cannot prove your device got tampered and in case of malfunctioning devices, this is the only issue I can figure, you get disarmed in front of a judging court.

     We are experiencing embedded viruses too?

  • 0 in reply to Roberto Romano
    Intellectual 810 points
    The idea we came up with, in large part because it was one we knew how to implement, is to have a lock on the code that we immediately remove after programming the device, and save a flag in EEPROM to indicate it has been unlocked. I think this is what you are talking about?

    This way any clones will need to break that lock before they can do anything. This requires keeping the key and EEPROM lock location in the code however. Locking down the JTAG port should add a decent layer of security on top of this.
  • 0 in reply to Amit Ashara
    Intellectual 810 points
    As a follow up. Before I start disabling the Debug port, I need to figure out the best way to perform the unlock sequence.

    In the past I accidentally locked the device and was forced to switch over to a Windows machine to unlock it. I was wondering if their is a simpler solution for Linux users? I don't believe LM Flash Programmer has been ported to Linux yet. Will Uniflash 3.1 do the job?
  • 0 in reply to ROM_Jamie
    Guru 47900 points

    ROM_Jamie said:
    have a lock on the code that we immediately remove after programming the device, and save a flag in EEPROM

    That's not at all what this reporter described.

    Would not it be quick/easy to monitor transactions to the EEProm - and learn both the address and value of that, "lock."

    You're unresponsive to our suggestion of programmable, small, FPGA/CPLD - which studies have proven to reduce software theft.

    As Roberto advises - should you get to court - always wise to "cleverly embed" your name/ID - to "prove" your ownership of that code.

  • 0 in reply to ROM_Jamie
    Guru 27285 points

     Uniflash do the job too but I am also using LMFlash in a VBOx and it run flawless, LMFlash has some additional feature like dump flash is not present on Uniflash. I think it is time to port LMflash to Linux too or add the few missing features to Uniflash.

     About code no I don't think on eeprom but embedded in code permanent and unique, you can also do some crypt of TIVA serial number but I forever prefer a secret signature to have some comm channel to verify that is your firmware otherwise tampered device can answer as it is your. On hacking some device we got same behaviour observed from original adding our additional feature we needed. That was a dead company and revived devices, logic analyser and our mind can break everything we wish to do.. I don't figure someone breaking 2$ items thinking make money but when you wish have more feature on an expensive dead device sometime we start reverse engineering.

  • 0 in reply to cb1
    Intellectual 810 points

    Roberto Romano said:

    ...you have a secure way to prove your code is no more inside processor so you need some password activated never used on field so none can know to have access to memory...

    Is this not what I described?

    cb1- said:

    You're unresponsive to our suggestion of programmable, small, FPGA/CPLD - which studies have proven to reduce software theft.

    At this time, for this project, I can't really go into researching/developing this method. I do appreciate the suggestion and will attempt to implement it in the future.

    cb1- said:

    Would not it be quick/easy to monitor transactions to the EEProm - and learn both the address and value of that, "lock."

    I don't imagine it would be incredibly difficult. It's not a perfect solution, however combining with the locked Debug interface, simply knowing the EEPROM lock would not be enough. They would still need to attain a copy of the executable. They would need to do both to get a working clone.

  • 0 in reply to cb1
    Intellectual 810 points

    cb1- said:

    As Roberto advises - should you get to court - always wise to "cleverly embed" your name/ID - to "prove" your ownership of that code.

    I will most certainly do this.

  • 0 in reply to ROM_Jamie
    Guru 47900 points

    ROM_Jamie said:

    "...you have a secure way to prove your code is no more inside processor so you need some password activated never used on field so none can know to have access to memory..."

    Is this not what I described? 

    Fast/furious forum responses over-whelm many.   That's friend Roberto's remark - not mine - thus not my place to respond.

    Even if you've "locked down" JTAG/SWD - could not we extract your flash content via that operational I2C port - or thru any UART - via a small piece of code we place w/in - and then run - from your MCU's SRAM?  

  • 0 in reply to Roberto Romano
    Intellectual 810 points
    Let me make sure I understand fully.

    I have a text command interface to the Tiva, should I simply add a secret command "mysecretcommand" that will respond with "Author: ROM_Jamie"

    If my client obtained a copy of the executable, would it not be trivial enough for them to find the "Author: ROM_Jamie" and replace it with "Author: Some Guy"

    I suppose this would be where cb1's suggestion for a checksum would be helpful.
  • 0 in reply to cb1
    Intellectual 810 points

    cb1- said:

    Fast/furious forum responses over-whelm many.   That's friend Roberto's remark - not mine - thus not my place to respond.


    True, however what you had replied to was my response to Roberto, so I thought it fitting.


    cb1- said:

    Even if you've "locked down" JTAG/SWD - could not we extract your flash content via that operational I2C port - or thru any UART - via a small piece of code we place w/in - and then run - from your MCU's SRAM? 



    I suspect you are right, however I am by no means a skilled hacker, nor a hardware aficionado. What you are saying is locking down the JTAG/SWD is a much smaller hurdle than I had hoped. The checksum approach would prevent this?

  • 0 in reply to ROM_Jamie
    Guru 47900 points

    ROM_Jamie said:
    The checksum approach would prevent this?

    Having spent time in UCLA's hallowed law school - never a good idea to state, "Always, forever and/or prevents."

    We've seen, "decapped and xray'ed" MCUs - treated that way to (illegally) glean code.   There is NO defense!

    Thus - your presentation of multiple, different "stumbling blocks" forces the code-breakers to extra time/effort/expense.

    Should you read "deep" w/in MCU manuals - most makers will concede that their security efforts are not "foolproof" - and may be "broken."

  • 0 in reply to cb1
    Intellectual 810 points

    Yes, it's an unfortunate issue. I would personally love to make everything I'm doing open-source and forget about it, however it is hard to code from a refrigerator box.

    My question was more specifically on the workaround for the locked JTAG.

    cb1- said:

    could not we extract your flash content via that operational I2C port - or thru any UART - via a small piece of code we place w/in - and then run - from your MCU's SRAM

    Earlier you wrote.
    cb1- said:
    c) always create a check-sum - encrypt it - and then require its proper decode prior to any access/probe to MCU's memory.   (fends off (added) illegal code's attempt to "dump your code" via memory access and output - not managed via JTAG/SWD)
    This sounds to me like the solution you came up with for that problem?
  • 0 in reply to ROM_Jamie
    Guru 47900 points
    It's one means to (somewhat) limit or postpone code-break attempts.

    Solution - registers as yet another word to "avoid" by we, "providers of content."

    We note that you've Verify ticked a fast, brief response - nothing else. Appears other writings here deserve "equal" verification...
  • 0 in reply to cb1
    TI__Guru**** 244410 points
    Hello Jamie,

    Might I suggest self destruct as an option. Encase the device in a tamper box. User attempt to open the box for JTAG insertion causes an interrupt erasing the code and device faulting. Having two GPIO's (known only to you) with opposite external Pull Control also can be effective with the user replacing your device on to their board may not be aware of the same will cause the flash-ed code to erase itself.

    With inputs from cb1, Roberto, I think there is a round of Verified Ticks to all...

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

    Amit Ashara said:
    Might I suggest self destruct as an option. Encase the device in a tamper box. User attempt to open the box for JTAG insertion causes an interrupt erasing the code and device faulting. Having two GPIO's (known only to you) with opposite external Pull Control also can be effective with the user replacing your device on to their board may not be aware of the same will cause the flash-ed code to erase itself.

     Hi Amit, I appreciate a lot this Idea I can use in some case but from our poster it was perception someone tamper the code, good hack but leave you completely exposed to void proof of paternity. Yes you forever can use reverse of silicon but that cost at almost 3KUS$, having a good watermark is better and more simple to demonstrate. Theft don't know about, timed bomb is something I used on my early career, not erasing but stopping all system to work applying crypt to data on disks. That was because someone tampered my code and damage appeared few week after when they cannot imagine and only on full system. That time code where exposed from Eprom and disk, today more solid data protection exists like have some pieces of code enclosed on a crypt processor and execute part of code there.

     This exposure of code many time voided code protection exposing to hacking what is was doing.

     So if <<sabotager>> exists two point take place over tech ability and as also CB1 spoken about are loyal question on how to demonstrate damage to firm credit and that device where tampered and warranty voided. Both malfunctioning and usage of trademark are question I perceived from original post.

     About Amit Idea, I applied last time 10 Yr ago on a device programmer, I sold firmware programmer MSP430 based, finite programming number was applied to so every succesful verified programming of target was erasing one flash bit, when all bit where 0 programmer disabled itself erasing the "target firmware" part. Detaching the battery also was in a definitive voiding of code. So customer was alerted about and no warranty if come back with empty programmer, no excuses, end code proved it was lasted. After that customer was called to got away from my lab all his devices. Original theft is now dead (rest at hells burning forever!!) but many other where born...

  • 0 in reply to cb1
    Guru 27285 points

    cb1- said:
    Fast/furious

    [Fresh mode on]

     This family is NRND now, please check new Blizzard TIVA instead ;)

  • 0 in reply to Roberto Romano
    Guru 117855 points

    Roberto Romano said:
     [Fresh mode on] 

    Yes - [Fresh Mode is On] - but [Comprehension Mode] now (greyed out)...

    Who, what, where brought NRND family into view?  (certainement, pas moi)

  • 0 in reply to cb1
    Intellectual 810 points

    cb1- said:
    We note that you've Verify ticked a fast, brief response - nothing else. Appears other writings here deserve "equal" verification...

    The thing about the "verified answers" is that I should indeed first implement and test the methods before saying the answer is "verified".
    All I've done now is verify that it's a possible answer. I'm sure you know the answer is correct but I don't.
  • 0 in reply to ROM_Jamie
    Guru 117855 points
    Did not you (immediately) tick-Verify vendor's early response? Surely you hadn't time to fully/properly test/verify it...
    Your best bet - all things considered - is to roadblock JTAG pins (via special GPIO switch) and to employ our suggestion of programmable logic device. Often - that alone - will discourage (even) skilled MCU hackers as their "toolkit" may not include that programmable logic family...