ATMEGA328p Software Protection and Verification

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

Hello, 

 

I'm developing a product with an AVR (atmega328p). I'm using the optiboot bootloader. I'm using a windows machine.

 

My main goal is to protect our software as much as I'm able to (I know AVRs aren't 100% secure). 

 

To my understanding, using avrdude the .hex file can be read from AVRs unless the Data Memory Lock Bits (LB1 and LB2) are set to "0." Once set, the .hex file read will not be the true .hex file in flash memory.

 

I'd like to learn how to set these lock bits, and verify my code cannot be read back out. 

 

So I'm here to share what I've learned so far and to get everyone's feedback on how I can verify the lock-bits are doing their job.

 

Here's my steps so far:

  • Found that lock bits can either be changed in the bootloader, and the bootloader re-flashed, or by using avrdude.
  • Lock bits and fuse bits can be changed in the "boards.txt" file usually found in C:\Users\"YourUserNameHere"\Downloads\optiboot-master\optiboot-master\optiboot\boards.txt
    • optiboot32.bootloader.lock_bits=0x0F
  • If you can burn a bootloader onto AVR using "arduino as ISP", you can also use it with avrdude interaction (without having to buy a programmer)
    • Using arduino UNO as "arduino as isp" I am able to interact with atmega328p using avrdude.
  • I can read my .hex file out with the command "C:\Users\"YourUserNameHere">avrdude -P COM3 -b 19200 -c stk500v1 -p m328p -U flash:r:mySoftware.hex:r"
  • Next I burn the bootloader with lock_bits set to (0x0C : 0b1100 : 0b x x LB2 LB2)
    • Or using avrdude:    C:\Users\"YourUserNameHere">avrdude -c stk500v1 -p m328p -P COM3 -b 19200 -U lock:w:0x0C:m
  • Now the .hex file is blank (0KB of data).

 

Everywhere I read, people have said (and also Atmel) that when you try to read out the .hex file from an AVR with LB1 and LB2 set to "0" the .hex file will contain the "Low byte of the memory address" that looks like:

00 00 01 01 02 02 03 03 04 04 .. 0E 0E 0F 0F
10 10 11 11 12 12... and so on

But when my lock bits are active, when I read my .hex file, I get an absolutely empty file. 

 

Am i doing something wrong, or did the Atmel documentation change?

 

Please help!

 

JT

 

 

references:

 

atmega328p datasheet: http://www.atmel.com/Images/Atme...

In-System Programming application note: http://www.atmel.com/Images/Atme...

avrdude guide: https://learn.sparkfun.com/tutor...

Binary to hex converter: Frhed

 

 

This topic has a solution.
Last Edited: Wed. Oct 25, 2017 - 06:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Everytime I've read from a locked chip, it is always 0xFF for all locations.

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

Hi Alank, 

 

Thank you kindly for the reply.

 

Have you confirmed this statement with an atmega328p? 

 

Perhaps the format has changed?

 

FT

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

What's the correct lock bit setting to achive the highest software security without messing up the normal operation of the software? I'm assuming just LB1 and LB2 have to be set to "0"?

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

This was on a 324P, but I am pretty sure I got the same results with a 328P.  Yes, both LB1 and LB2 programmed which makes them 0's which makes the lockbits 0xFC.

 

I can test a 328, I've got one around here but I don't know if it is a 328 or 328P.  Do you get all 0xFF's when you read from yours with the lockbits set?
 

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

Hi Alank, 

 

What's the diff between 324P and 328P?

 

When I read the .hex file and look at it with a binary to hex converting program (Frhed) I see absolutely no data at all. 

 

Yes, please test 328p if you have it. 

 

Mind sharing your fuse and lock bit settings?

 

FT

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

FamousThompson wrote:
I'm assuming just LB1 and LB2 have to be set to "0"?

In this, and in your addition to the other thread, you seem to be implying that lock bits (LBn) and boot lock bits (BLB) are the same.  For your purposes on verifying the read-back, the distinction may be important.

FamousThompson wrote:
What's the diff between 324P and 328P?

Might I answer "4"?  I don't know what response you are looking for.  Some things are going to vary across different AVR8 model series.

 

If the responses are indeed 0xff bytes, then the tool is probably suppressing the store of all the trailing unused/erased space.  Not uncommon.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Hi theusch, 

 

My main goal is to (1) prevent the software being read back out of the AVR, and (2) to confirm it's working somehow.

 

My method for confirming is to (1) read the .hex file when lock bits are not set, then (2) to read .hex file when lock bits are set correctly to see "00 01 02 03......." in the .hex file. 

 

I understand that the "Data Memory Lock Bits" are comprised of the Boot-loader lock bits and lock bits, as described in tables 31-1 through 31-4 in the atmega328p datasheet.

 

 

  

 

FT

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

I guess, the correct question is:

 

What is the correct setting for the "Data Memory Lock Bits" so software cannot be extracted from an Atmega328p uC using nonInvasive methods while maintaining normal program operation?

 

And how can I verify it's working?

 

FT

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

Put some flash on it.

Program the lockbits 0xFC.

Read it back to hex.

Look at the contents.

 

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

Hi Alank, 

 

Same result: .hex is an empty file.

 

Maybe I have to set BLB bits appropriately?

 

FT

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

Another Q:

 

If the lock bits LB1 and LB2 are set to "0" should I be able to upload new software to the AVR using arduino IDE?

 

If so, does that mean the arduino IDE is issuing the "Chip Erase" command? If it is, wouldn't the lock bits LB1 and LB2 be set back to their "1" state?

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

If you program flash and DON'T set the lockbits, does the retrieved HEX show your code?

 

If so then the test is good - lockbits set = 0xFF's, lockbits not set = your code.

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

Hi Alank, 

 

When the lockbits LB1 LB2 are NOT set "1" , the .hex file shows data.

 

The .hex file I read from my atmega328p does not match the temperary .hex file generate by the arduino IDE:

avrdude: 23116 bytes of flash written
avrdude: verifying flash memory against C:\Users\"YourName"\AppData\Local\Temp\arduino_build_530489/ACS_10.ino.hex:
avrdude: load data flash data from input file C:\Users\"YourName"\AppData\Local\Temp\arduino_build_530489/ACS_10.ino.hex:
avrdude: input file C:\Users\"YourName"\AppData\Local\Temp\arduino_build_530489/ACS_10.ino.hex contains 23116 bytes

But the expected (and documented) result for the .hex file when LB1 and LB2 set "0" is supposed to be the last byte of the memory address..... so I'm digging further to fully understand.

 

FT

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

It sounds like it is working - lockbits set = code protected.  Not that I've read flash back much on locked AVR's, but when I have it is always 0xFF's.  I'll test the 328 here in a moment.

 

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

I just read a 328 (not 328P) and it returns all 0xFF's with the lock bits set.

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

Hi Alank, 

 

Can you please describe your setup so I can replicate? I think i'm doing something wrong.

 

FT

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

I'm developing a product with an AVR (atmega328p). I'm using the optiboot bootloader.

You should probably forget about using a bootloader (at least optiboot) and doing "code protection" at the same time.

 

Here's my steps so far:
Found that lock bits can either be changed in the bootloader, and the bootloader re-flashed, or by using avrdude.

Lock bits and fuse bits can be changed in the "boards.txt" file

You can't use optiboot to change the lock bits.  In Arduino-land, the "burn bootloader" command also sets the lock bits, but it only works when you're using the programmer that can burn the bootloader, and essentially it's done with a separate avrdude command.   The "burn bootloader" Arduino process also erases anything else that is in flash.

 

Having the lock bits set so that the bootloader can still write code, but not read it back, may be possible, but will break the normal Arduino upload process (which reads back the code to verify correct upload.)  (and it needs a programmer anyway.) (and it's not at all secure because someone could upload a small sketch that writes out the rest of memory, and get most of your protected coed.) You might as well consider work flows that use an "upload using programmer" methocology...

 

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

I don't know much about arduino or optiboot.  I am just using Atmel Studio 7 with an Atmel Ice with a mega328...

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

Hi West, 

 

I didn't learn much from your comments. 

 

I don't have to have a bootloader, I just have it setup that way because I don't know how to upload sketches another way.....

 

I'm using a Arduino Uno to burn the bootloader. Yes, you can update the fuse and lock bits in the boards.txt file when you burn the optiboot bootloader.

 

I'm aware the "burn bootloader" command issues the "Chip Erase" command in avrdude.

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

    So much praise for Arduino while it creates so much confusion by hiding important things that are running under the hood.

I guess, the correct question is:

 

What is the correct setting for the "Data Memory Lock Bits" so software cannot be extracted from an Atmega328p uC using nonInvasive methods while maintaining normal program operation?

    This is still not the correct question. Plus, you keep talking about bootloader and asking only about LB0 and LB1. You need to read that section of the datasheet until you understand the whole picture.

 

    LB0 and LB1 are with respect to ISP and parallel programming. If you do not have a bootloader installed in the micro then this is enough. Set them to 0 both and this is what you can get. No read back, no further programming unless you erase the chip.

 

    If you want to use a bootloader than you need to look at BLB 00, 01, 10 and 11. But you leave somehow a back door open. Normally, after you program your micro you want to verify if everything went correctly by reading back what you wrote. Another option, safer, is to have your application to do a CRC on the application section and let you know somehow that things did not go well so you need to retry.

 

    If the bootloader verifies the application section, it means that it is reading it back. If you read it back, then someone else could read it back too. I don't see a reason for a bootloader to allow you to read the application section. This is an open back door. The verification can be made by sending again the flash data and the comparison to be made inside the microcontroller or page by page after it is programmed. You need to look at your bootloader to see how it works.

 

    In conclusion, you need to set the bootloader lock bits in a way that the application section can not read / write the bootloader section and the bootloader section can only write the application section and use the CRC method to verify the application section.

 

    And by the way, a bootloader can not unlock the fuses. It can only set them to a stricter value. Arduino bootloader does not erase the micro. A full earse would erase the bootloader as well, something that you don't want.

 

    Also, your compiler / assembler would write to the hex file only what is needed to be programmed. When you read back, you read the entire flash section, so the two files does not match. It is possible that your bootloader reads the lock bits first and if it sees that the memory is protected against reading it may even not bother to read anything, so it will give you an empty file. Use an ISP programmer instead.

 

Edit:

    EasyBootAVR does not allow you to just read the application section from the micro. the verification process is performed page by page right after writing.

    Here is an extras from http://www.sofgel.ro/vechi/langu...

When a page is erased, the Z register is saved in one double register, in case the page needs to be verified after being written. In this way, it is possible to read (for verification purposes) only pages that have just been erased and written. This means, it is not possible to read back the application firmware before to erase and write it.

..

If the 'VerifyFlash' check box is checked, then only pages present in the hex file provided will be verified after have been erased and written. So the status bar that shows the progress, will not start from the beginning to show the verification progress, since the verification is done page by page as it is erased and written.

    Cheers.

Last Edited: Wed. Oct 25, 2017 - 02:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Angelu, 

 

Thank you kindly for your reply. 

 

So it looks like I'll need to learn how to program AVRs independently from Arduino IDE?

 

I'll look into how to upload an arduino sketch without a bootloader using an ISP programmer, then I dont have to worry about BLB bits.

 

FT

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

angelu wrote:
And by the way, a bootloader can not unlock the fuses. It can only set them to a stricter value.

 

Are you sure?  I didn't think a bootloader could alter fuses in any way.  I was looking through a 328 data sheet and it says:

 

Note that the fuses cannot be changed by the MCU itself in the 27.6 "entering the boot loader program"...

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

alank, 

 

He means when the you burn the bootloader AVRDUDE sets the fuses and lock bits. The actual bootloader(when running) can't access or change any fuse or lock-bit settings. 

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

Note that the fuses cannot be changed by the MCU itself in the 27.6 "entering the boot loader program"...

    That one refers to the bootloader section size. I was talking about lock bits. Look at section 24.9.1 SPMCSR register bit 3.

 

    This is needed when initially you have a production test version burned in, and want to burn the final version and to disable any further bootloader activity, so you block the bootloader to act again.

 

    XMEGA datasheet uses this term "a stricter" value if I remember correctly.

Last Edited: Wed. Oct 25, 2017 - 02:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So it looks like I'll need to learn how to program AVRs independently from Arduino IDE?

 Yes.  IMO, that's easiest.  It's not too difficult; the Arduino IDE has an "export compiled binary" option, and then you burn that .hex file using commands very similar to burning the bootloader.

 

The boot section lock bits become irrelevant once you throw away the bootloader, which will significantly simplify things.

The BLB would be important if you were writing some sort of "secure bootloader", but none of the arduino bootloaders are even close.

 

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

From XMEGA AU datasheet:

 

 

which is the same thing for MEGA328.

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

Hi All, 

 

I created a sequence of avrdude commands which I believe to completely protect the software by (1) not using a bootloader (uploading binary via parallel programmer), and (2) setting all lock bits disabling further programming and verification.

 

Please verify my work. 

 

## avrdude commands for: Secure AVR software via programming w/o bootloader & memory lock enabled

## for help with fuse settings use: http://www.engbedded.com/fusecalc/

## ToDo: eventually make this a batch file

## erase chip
avrdude -c arduino -p m328p -P COM3 -b 19200 -e

## Program Fuses
avrdude -c arduino -p m328p -P COM3 -b 19200 -U lfuse:w:0xE2:m

avrdude -c arduino -p m328p -P COM3 -b 19200 -U hfuse:w:0xdf:m

avrdude -c arduino -p m328p -P COM3 -b 19200 -U efuse:w:0xff:m

## Or a combination works as well
avrdude -c arduino -p m328p -P COM3 -b 19200 -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m


## Upload arduino-exported binary (Sketch >> export compiled binary)
avrdude -c arduino -p m328p -P COM3 -b 19200 U flash:w:ACS_10.ino.hex

## Read Software
avrdude -c avrisp -b 19200 -P COM3 -p atmega328p -U flash:r:true_software.hex:r

## Lock Memory (set all lock bits since there is no bootloader and we don't want read or verification access of memory)
avrdude -c arduino -p m328p -P COM3 -b 19200 -U lock:w:0x00:m

## Attempt to Read Software
avrdude -c avrisp -b 19200 -P COM3 -p atmega328p -U flash:r:mystery.hex:r
	## .hex file should now be a blank file.

## Now the only way to reprogram or access memory is by issuing the "Chip Erase" command, erasing software in memory, then resetting lock bits.


 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

And further condensed into one avrdude command

 

avrdude -c arduino -p m328p -P COM3 -b 19200 -e -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0x07:m -U flash:w:ACS_10.ino.hex -U lock:w:0x00:m

If only someone could have posted this solution earlier.... wink

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

(uploading binary via parallel programmer)

You don't need to go that far.  I don't think ISP/SPI programming is any "less secure" that parallel programming (though I guess you can completely turn off ISP response, confusing anyone who tries to read it.  But it seems to me that needing a parallel programming is quite a bit off pain to put up with just for that.)  (Note that ArduinoISP is not a parallel programmer.)

 

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

Westfw, 

 

I disagree, you can turn arduino UNO (running arduinoISP) into a parallel programmer. 

 

I've been using it all day to run avrdude....

 

FT

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

But parallel needs 20 of the AVR pins to be "free" - almost impossible with a device "in circuit". (and to top it all it squirts +12V into the _RESET pin).

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

BTW in another thread (now locked) you said you only got a "blank file" when reading from a locked device. Perhaps that is some feature of avrdude that it can recognise "locked" data and then does not create a file? But read this thread:

 

http://www.avrfreaks.net/forum/p...

 

As you can see, in interactive mode, there's no question that you see 00 00 01 01 02 02... etc.

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

If avrdude reads nothing but 0xFFFF from flash, it returns an empty file, because it interprets that as unprogrammed flash on a 'virgin' device.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

When I've done the experiment in the past I've got an 00 00 01 01 02 02... file not ff ff ff ff??
.
Do some models of AVR behave differently to others when locked? Or is it a different setting of LBs that causes different results?

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

Good question.  I may try an experiment later, but I only have m328P and t85 with me.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

clawson wrote:
Do some models of AVR behave differently to others when locked?

That is what I'm getting out of the anecdotal evidence above.  A venerable Mega32 will give 00 00 01 01 02 ...  As a guess, any of the P/PA model lines will give you ff.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Wonder if they changed it because people were getting "something" and creating endless "I locked it but I can still read it" support requests? (they clearly never stopped to examine WHAT they were reading).

 

And yes, when I did this experiment (probably 10 years ago now), it would have been a venerable mega16 I was trying it with.

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

 

Hi Clawson, 

 

Thanks so much for that post!

 

Using the terminal mode was the key!

 

In terminal mode, I was able to read 0xFFs in all memory locations with lock bits set!! I think this is enough verification for me!

 

C:\Users\"YourName">avrdude -c arduino -p m328p -P COM3 -b 19200 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude> dump flash
>>> dump flash
0000  0c 94 5c 00 0c 94 6e 00  0c 94 6e 00 0c 94 6e 00  | .\. .n. .n. .n.|
0010  0c 94 6e 00 0c 94 6e 00  0c 94 6e 00 0c 94 6e 00  | .n. .n. .n. .n.|
0020  0c 94 6e 00 0c 94 6e 00  0c 94 6e 00 0c 94 6e 00  | .n. .n. .n. .n.|
0030  0c 94 6e 00 0c 94 6e 00  0c 94 6e 00 0c 94 6e 00  | .n. .n. .n. .n.|

avrdude> quit
>>> quit

C:\Users\"YourName">avrdude -c arduino -p m328p -P COM3 -b 19200 -U lock:w:0x00:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "0x00"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.03s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x00:
avrdude: load data lock data from input file 0x00:
avrdude: input file 0x00 contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

C:\Users\"YourName">avrdude -c arduino -p m328p -P COM3 -b 19200 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e950f
avrdude> dump flash
>>> dump flash
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

 

Thanks everyone for your help! This is why I use AVRs!!!

 

FT

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

I saw something called BLBSET in the 328 datasheet.  Does this mean that a bootloadet CAN set the lockbits programmatically?  Can it also clear them, or is this the only more restrictive thing angelu was talking about?

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

clawson wrote:
When I've done the experiment in the past I've got an 00 00 01 01 02 02... file not ff ff ff ff??
.
Do some models of AVR behave differently to others when locked? Or is it a different setting of LBs that causes different results?

When I try to read locked working AVR what I got is scrambled hex not the real one.
.
None of them give all 0xFF.
.
I use AVRISP mk II and CVAVR or Studio.
.
MG

I don't know why I'm still doing this hobby

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

Does this mean that a bootloadet CAN set the lockbits programmatically?

You can only >>program<< a lock bit, i.e. change from 1 to 0.  If you look at the different lock bit modes, each bit controls an aspect of the lock functionality.  When that lock bit is '1', then that aspect is not locked.  When it is '0', then that aspect is locked.

 

So software can only ever enable a lock, not disable it.

 

To disable a lock, you must execute a chip erase from one of the external programming interfaces i.e. ISP or HVPP/SP.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

MicroGyro wrote:
I got is scrambled hex not the real one
But I don't think it was "scrambled". We seem to be proving that "old" AVRs return 00 00 01 01 02 02 03 03... when locked and read while "modern" AVRs return just all FF FF FF FF FF FF...

 

Neither is really "scrambled".

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

clawson wrote:
But I don't think it was "scrambled". We seem to be proving that "old" AVRs return 00 00 01 01 02 02 03 03... when locked and read while "modern" AVRs return just all FF FF FF FF FF FF...
 
Neither is really "scrambled".

Aahh you are right sir Clawson
.
My brain must be scrambled while I'm looking at it
.
MG

I don't know why I'm still doing this hobby

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

Hello, 

 

Can someone confirm my fuse/lock bit settings and bootloader-less firmware download as the most secure method for software protection? Please confirm my work. Is there a better way?

 

FT

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

Good question.  I may try an experiment later, but I only have m328P and t85 with me.

Confirm that the t85 reports all 0xFF for locked flash and EEPROM.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

FamousThompson wrote:
and bootloader-less firmware download as the most secure method for software protection?
I don't understand that bit. For it to be secure you HAVE to use a bootloader not "bootloader-less". To be able to keep the binaries you are going to program into the AVR secure they have to be encrypted so somewhere there has to be some "intelligence" to decrypt it. I guess one could envisage an ISP/JTAG programmer that contained decryption intelligence but then at the last moment the ISP or JTAG wires would pass decrypted binary to the chip and could be intercepted. To keep it secure the decrypt has to happen "inside" the AVR and the only way to accomplish that is to use a decrypting bootloader. Atmel have examples of both AES and triple-DES bootloaders in application notes.

 

Note that all of this is probably "moot" anyway. The fact is that a dedicated hacker sends a copy of your chip and $500 to a shady operation in the Far East and they break the lockbits and extract the code and send him back a decrypted copy to use in clones of your product. So don't expend more than $500's worth (what? 5..10 hours?) of your life on this as it's all a bit of a gimmick anyway.

Last Edited: Fri. Oct 27, 2017 - 08:22 AM