15
\$\begingroup\$

I'm trying to protect whole flash from reading through ISP. It has bootloader, able to self program application section.

Setting lock byte to:

LB1/LB2 will not let user to use bootloader to upload new firmware.

BLB12/BLB11 and BLB01&BLB02 will not prevent reading flash through ISP, if I am not mistaken.

So there is no way to let user update firmware by custom bootloader and protect flash from reading at the same time?

\$\endgroup\$

2 Answers 2

Reset to default
18
\$\begingroup\$

You didn't specify a chip, the following is mostly geared to the 8 bit atmega devices, but it's general information. Read the 'Memory Programming' section for you specific chip's datasheet for more specific information!

That being said, and as you said, all AVR devices contain two Lock bits named LB1 and LB2. Programming these (to 0, low) will add protection to the contents written to Flash and EEPROM memories according to the table below. The level of protection is divided in three modes, where mode 1 offers no protection and mode 3 offers maximum protection. It is possible to move to a higher mode of protection simply by reprogramming the Lock bits.

The AVR allows changing "high" bits to "low", but not the other way around. It is not possible to change a "low" Lock bit to a "high", thus lowering the level of protection is not possible. To clear the Lock bits, a complete Chip Erase is required, which erase the Flash memory.

AVR lock bit table

These 2 lock bits alone (LB1 and LB2) when low will prevent 99.9% of people from stealing your firmware! Probably more than 99.9%. It would almost always be easier to reverse engineer your code.

So there is no way to let user update firmware by custom bootloader and protect flash from reading at the same time?

To the best of my knowledge (I could be mistaken but I think I would have had issue with this before,) on devices that have the bootloader protection fuses (BLB12 and BLB11), you can lock your custom bootloader section, disable SPI and be protected from 97-98% of people.

However when none of the Lock bits are programmed, there are no memory lock features enabled!!! The ISP disable is only enough to block 70% of people.

For some extra information, the Lock bits and Fuses are not located in the normal flash or EEPROM space, nor are they accessible from the software, except for Lock bits related to the Boot Loader in devices with the Self-Programming feature. Table 2 in this app note will help you identify what you can do for your particular device!

Atmel's AVR line are not high security devices (unless explicitly noted!) and as such they absolutely don't come with any code safety guarantee, nor should they! Like all non-secure devices (and sadly even some secure ones,) they are prone to common attacks!

Edit

I will put HV programming interface header onboard. But can someone use HV programmer to READ flash? I know HV programmer can make chip erase even ISP/Jtag are disabled.

I don't think you should include the HV programmer in your board design unless absolutely needed and you know for sure it won't cause problems with anything. HV programmer's (12 volt signals,) are available only as a safety measure to program locked (error locked, mostly) chips. In theory this is only meant to program the device not read anything. And I have never heard of an exploit that would allow reading.

For upgrading bootloader(occasionally) I will put HV programming interface header onboard. But can someone use HV programmer to READ flash? I know HV programmer can make chip erase even ISP/Jtag are disabled.

I think there may be a way to update the locked flash via bootloader, (something to do with an internal write flag and/or ISR maybe???) But I'll have to search my notes and maybe have to test it. I won't be able to do this for ~20 hours; so I highly recommend asking a new question focused on this only and for the processor you mentioned. It's a very good question!

\$\endgroup\$
8
  • \$\begingroup\$ +1 for last comment, if all else fails any bloke can just desolder the chip and stick it us an AVR debugger/programmer to reset the lock bits and your security is all gone. \$\endgroup\$
    – helloworld922
    Commented Jan 8, 2013 at 8:53
  • \$\begingroup\$ @Garrett Fogerlie: not sure what lead you to think I am trying to steal the code, plz let me know and I will correct my question so others will not think the same way. I am trying to give minimal protection of my own code, my own bootloader. Anyway, couple more questions on this. Chip is ATMega328, thought the family will have common lock bit usage. You've explained LB1 and LB2, which I also described in my question as limiting option to use bootloader for upgrade purposes. So it's not an option. As for BLB12 and BLB11 - that's what I don't understand. (to be continued) \$\endgroup\$
    – Pablo
    Commented Jan 8, 2013 at 9:04
  • \$\begingroup\$ Setting those bits will NOT prevent anyone to read the flash(application+bootloader) from outside. From datasheet it appears that those bits will just block LPM/SPM commands, but serial programmer is not using it. As for Disabling serial programming and jtag, this is another big question for me. For upgrading bootloader(occasionally) I will put HV programming interface header onboard. But can someone use HV programmer to READ flash? I know HV programmer can make chip erase even ISP/Jtag are disabled. \$\endgroup\$
    – Pablo
    Commented Jan 8, 2013 at 9:11
  • \$\begingroup\$ @pablo, sorry, I meant no offence. When I first saw your question, the theft idea didn't occurr to me; and I wrote wrote an answer that was somewhat focused on retrieving locked code. However I was at work and before submitting that answer I had an ~2 hour pause. Then when I came back, I noticed there was still no answer & was a bit surprised, then upon re-reading your question I thought that 'theft' may have been why. Not your fault at all, I now have removed the disclaimer. The processor model was needed because of the differences listed in that table & because there are 8/16/32bit AVR's... \$\endgroup\$
    – Garrett Fogerlie
    Commented Jan 8, 2013 at 13:39
  • 1
    \$\begingroup\$ ъGarrett Fogerlie: I didn't mean to put HV programmer onboard, just header :) But I figured out it's not neccessary because lock bits worked and just in case I can use ISP header to chip erase and re-write whole flash on device. So to summarize the answer to my original question - setting LB1 and LB2 will prevent anyone from reading whole flash area AND at the same time will not prevent me from writing program memory through bootloader. \$\endgroup\$
    – Pablo
    Commented Jan 8, 2013 at 14:03
3
\$\begingroup\$

You may use the lock bits on some ATMega devices and still update your code with the bootloader.

I programmed LB1 and LB2 on a ATMega 328. Then invoked the bootloader, updated the main program - all worked perfectly.

The ISP can neither read nor write any flash / eeprom / fuses but the bootloader can still write the application section.

A Chip Erase with the ISP will clear the lock bits (LB1 and LB2), but also erases the entire flash / eeprom, thus you may protect your code (however you have to assure your bootloader cannot be hacked)

\$\endgroup\$
2
  • 3
    \$\begingroup\$ How does this improve upon the currently accepted answer? \$\endgroup\$
    – Ignacio Vazquez-Abrams
    Commented Aug 14, 2015 at 17:59
  • \$\begingroup\$ Note that as long as you have a standard Arduino-style bootloader resident, locking readback would be nearly pointless as the bootloader itself has a readback capability unless you use the advanced 328P-only mode that disables bootloader LPM to application memory. Otherwise you'd need to modify the bootloader to remove that, at the cost of no longer being able to verify programming. (You could potentially create a different verification mechanism, but it would be non-standard requiring you to also modify/replace avrdude) \$\endgroup\$
    – Chris Stratton
    Commented Jul 27, 2019 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.