AVR128DA prevent reading out firmware?

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

 

Wondering if there is a way to prevent the firmware from being read out by a UPDI programmer?

Trying to mess around with the lock bits settings but programming anything there has an error - WriteRegister() failed to write at 1040

I am able to program the flash without issues.

 

 

Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


why do you make it hard?.....here is a snip from Atmel Studio...you just pick the lock bits you want & hit program

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

removed

Last Edited: Sat. Aug 1, 2020 - 02:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your reply but this is a AVR128DA which doesn't have those options - 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

did you try RWlock?   This is a 4809, assume you have drop down choices:

 

are you sure you have the latest device packs (TOOLS/DEVICE PACK MANAGER)?

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Aug 1, 2020 - 02:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I have the latest and yes the Lockbits are the same as that, except they are labelled "Key.Key". When changing to RWLOCK and then pressing Program that's when it has the error. Changing the key value and pressing Program also has the error.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

This is from the 128da datasheet...could it be yours is now actually locked?

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you program the key with any value other than the unlock value, the chip will become locked.

Probably the safest value (in terms of making life difficult for attackers) is to reverse all bits, i.e. 0xA33A3AA3.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

confirmed.
There seems to be a bug in the AS7 device programming tool.
RWLOCK cannot be written.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So is the chip unlocked after the "failure"  ...can you still read the code & fuses?

 

Was wondering if perhaps, the locking actually worked & the failure was due to the chip no longer being readable...just a far-out thought

Not sure if the key is always readable for verification, even when locked.

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This failure certainly does not lock.
All access remains available.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it the chip or the programming software?

 

West Coast Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It must be a software problem, I can lock an AVR128DA28 using jtag2updi. Here is an avrdude log in terminal mode:

 

PS C:\Users\JR\Documents\github\jtag2updi> avrdude -c jtag2updi -p avr128da28 -P com3 -t

avrdude.exe: jtagmkII_initialize(): Cannot locate "flash" and "boot" memories in description
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude.exe: Device signature = 0x1e970a (probably avr128da28)
avrdude> dump lock
>>> dump lock
0000  5c c5 c5 5c                                       |\..\            |

avrdude> write lock 0 0xa3 0x3a 0x3a 0xa3
>>> write lock 0 0xa3 0x3a 0x3a 0xa3

avrdude> dump lock
>>> dump lock
0000  a3 3a 3a a3                                       |.::.            |

avrdude> quit
>>> quit
avrdude.exe: jtagmkII_reset(): bad response to reset command: RSP_ILLEGAL_MCU_STATE

avrdude.exe done.  Thank you.

 

Note that you can still read the lock immediately after writing to it, it only becomes active after reset. But on exit you get the illegal MCU state error, this means it's locked. BTW, the ASCII representations of the lock and the inverse lock are interesting :)

 

To unlock the chip it has to be erased, and since (AFAIK) you can't even read the signature of locked UPDI chips, you need to force avrdude with -F:

PS C:\Users\JR\Documents\github\jtag2updi> avrdude -c jtag2updi -p avr128da28 -P com3 -t -F

avrdude.exe: jtagmkII_initialize(): Cannot locate "flash" and "boot" memories in description
avrdude.exe: jtagmkII_reset(): bad response to reset command: RSP_ILLEGAL_MCU_STATE
avrdude.exe: initialization failed, rc=-1
avrdude.exe: AVR device initialized and ready to accept instructions
avrdude.exe: Device signature = 0x656570
avrdude.exe: Expected signature for AVR128DA28 is 1E 97 0A
avrdude> erase
>>> erase
avrdude.exe: erasing chip
avrdude> dump lock
>>> dump lock
0000  5c c5 c5 5c                                       |\..\            |

avrdude> quit
>>> quit

avrdude.exe done.  Thank you.

 

P.S. I used the AVRgpp programmer that was kindly sent to me to run this test. It works ok but the firmware needs some polishing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to point out that if you set AVR locks then if I want to see your code and can scrape $500 together I can do it.
.
The lockbits will keep nosey, hobbyist snoopers out but not your commercial competitors who want to clone your design.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Still, a lock key with bit patterns of 0s and 1s is more difficult to crack than lock bits, at least when the method of shinning UV light on certain parts of the die to erase fuses is used.

 

So at least one common method (that probably works for many classic AVRs) is defeated. But there are other methods, for example, injecting well timed power glitches during the erase process, trying to prevent data erasure, but not lock reset.

 

Also note that each individual AVR-DA has an unique serial number, so you can key the firmware to this number, for example the first time the firmware runs, some kind of bootloader modifies the flash to key it to the serial, and then never runs again, in fact this bootloader should be erased in a subsequent step via UPDI, before locking the chip.

So if the firmware is simply extracted and copied to a new chip it won't run correctly (it's important to be devious, don't fail immediately, generate some glitches, fail after some time). The thieves will have to reverse engineer it -> more man-hours spent.

 

Another method I've seen recommended is to just burn out the programming pin zapping it with some overvoltage pulse... no idea if it actually works.

 

Anyway, the objective of protection is not really to absolutely prevent theft, but to increase the cost from $500 to $5000 or $50000, maybe to the point where it would be easier/cheaper to make your own firmware instead of stealing. That's how I see it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have seen some of the videos, but I am not sure what power glitching does; is it causing an area of the chip to latch-up (e.g., like CMOS latch-up but not across the chip). Since this chip is allowed to be used for safety-critical stuff, my hunch is that latch-up (at any scale) may be difficult to cause. Maybe those lock bits are also sprinkled around the chip, so a limited latch-up will not affect all of them.

 

update: Sprinkling also makes the UV erasing trick difficult.

my projects: https://github.com/epccs

Debugging is harder than programming - don’t write code you can’t debug! https://www.avrfreaks.net/forum/help-it-doesnt-work

Last Edited: Sun. Aug 2, 2020 - 06:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

It must be a software problem, I can lock an AVR128DA28 using jtag2updi. Here is an avrdude log in terminal mode

 

Nice! Thanks for confirming that. I wonder if there is any way to use Avrdude with the nEDBG board.

 

How should we contact Atmel/Microchip about this issue? What's the usual response times from them?

Edit: Found the Microchip support case request section so I will submit a request there.

 

 

clawson wrote:
The lockbits will keep nosey, hobbyist snoopers out but not your commercial competitors who want to clone your design.

 

Yeah, we're looking into reducing the low effort attacks on it as the product is pretty cheap it wouldn't really justify spending the $500 on it, better to make your own version at that point.

 

Last Edited: Mon. Aug 3, 2020 - 06:23 AM