ATXmega128A4U Read lock bits does not protect against external code reading

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

Hello folks,

 

I have developed a commercial equipment that uses an ATXmega128A4U. We have produced 60 units of such equipment, and, to protect against copy we have set the reading lockbits (0x56), but then I realized that they do not protect against external reading at all.

 

We have already sent to the marked about 20 product samples without the proper protection...

 

The only wait to avoid the reading is to block the Read and Write process (0x00), what makes a lot harder to update the software!!!

 

Do you guys have any idea why it is happening?

 

Regards, Felipe.

Regards!
FS.

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

What do you mean by "does not prevent reading?". You can ALWAYS read some hex file from a locked AVR but the question is whether it's an exact image if the code you programmed in. Some AVRs just return FF FF FF FF in the hex you read and some return 00 00 01 01 02 02 ...

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

My bad, maybe I did not made myself clear. I know you can always read. The problem that I would like to point it out is that the HEX DOES reflect the real code.

I even tried to burn the microcontroller to check if it would run properly, and it DOES!

Regards!
FS.

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

I don't have an X128A4U to test.

 

How do you write the Fuses?

Manually, or through an ELF File?

 

I'll just mention to make sure that if you are writing the Fuses manually to make sure that your programming tool doesn't require a separate, extra, "write Fuses", button press.

Some software interfaces will write the Fuse as you tic the box, for others you set all the Fuses as desired, and then hit the "Write Fuses" button.

 

If your production person forgot / missed the last step, then you might THINK you had set the Fuses properly, when in fact you didn't.

 

JC

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

Hi DocJC, the production guy burn the fuses using the .elf file through an Atmel Ice.

 

I also have suspected that the problem could be in the process, but the lock bits do read correctly (0x56). Then I tried myself to burn it manually, but the only way to really protect the code is to burn 0x00 lock bits, not allowing reading and writing.

 

That is a shame and I feel very unprotected having those 20 units in the market without code protection...

Regards!
FS.

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

F Schneider wrote:
That is a shame and I feel very unprotected having those 20 units in the market without code protection...
A code protection anyone can break for $500 anyway (lots of unscrupulous labs in the Far East that will take your money to remove the lock on AVR code and read out an image of the code inside)

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

F Schneider wrote:
That is a shame and I feel very unprotected having those 20 units in the market without code protection...

For those 20 units, one may be able to get a hex dump but it is very difficult if not impossible to go from hex dump to C source code.

So a determined hacker may be able to recover the assembly code the compiler produced and from that gleam the intent of the source or use it directly to clone the device, but would require a fair amount of effort, most people are not that determined or skilled.

 

You could always issue a recall notice and ask for the units back and offer to send out free replacements!

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

Thanks for pointing, I have now read manual carefully.

 

What you've done is

Now we read datasheet and find out, that 6 MSB provide protection for CPU commands SPM and LPM.

Flash protection from EXTERNAL access is covered with 2 LSB, named here LB, which is in your case WLOCK (write protect).

 

Good to know, I was always setting all 4 options to RWLOCK, which is not necessary

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

By the way: what do you mean by harder to update?

 

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

Reported that same problem once. Reported it to the FAE of a distributor.
It was on a Moto part.
He told me there was a problem with the product and it might be fixed at some later date.
I applied my self to finding an answer as the product had to go to market.
After I found it I called the FAE and he came around and told me that he couldn't see how it could be done.
He also told me that if I supplied a chip his head office couldn't read then he was authorised to take me to lunch at place of my choice.
I supplied him with a chip they couldn't read and they reneged on the lunch, how low Is that.
So I wouldn't tell them how I did it.
Here it is - I found that buy applying a particular voltage through a particular resistor for a particular time I could blow up the pin on the device so it couldn't be read and rest of device was still operational.
Never had one product come back as faulty either!

Last Edited: Wed. Nov 27, 2019 - 10:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

These xmega, like many other AVR, have a "production signature row" that is unique for each individual chip.

People that are so worried about their software being stolen, should dedicate some time to writing a protection algorithm that uses this signature, so that the firmware can only run on the specific chip that is hosting it.

 

As mentioned, someone can pay a few hundred $ and obtain a firmware image from a locked chip. But when they find out that this image doesn't work on other identical chips, they will have to crack the protection algo, increasing the cost from 100s to 1000s; 90% of them might give up at this point.

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

It is simple to guess the economics.

 

If you crack the security for a mass market device,   it might be profitable.    But you still have to make the hardware and sell at below market price.

 

The OP has a run of 60.    It is not worth the time or money to crack a device with limited sales.

The criminal also has to find enough punters to buy her cracked device.

 

Proper use of the correct Lock Bits should be sufficient to protect your device.

 

David.

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

I have to erase the device to update it.

So at the lower end, I must teach my operator or technician how to do the correct update.

Regards!
FS.

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

mccrtay wrote:

Good to know, I was always setting all 4 options to RWLOCK, which is not necessary

 

My point is exactly that you must set RWLOCK to avoid undesired flash read.

Regards!
FS.

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

F Schneider wrote:

I have to erase the device to update it.

So at the lower end, I must teach my operator or technician how to do the correct update.

You can use an encrypted bootloader.

There is an Atmel App Note.

 

David.

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

El Tangas wrote:

These xmega, like many other AVR, have a "production signature row" that is unique for each individual chip.

People that are so worried about their software being stolen, should dedicate some time to writing a protection algorithm that uses this signature, so that the firmware can only run on the specific chip that is hosting it.

 

And also increase the production costs?

 

El Tangas wrote:

As mentioned, someone can pay a few hundred $ and obtain a firmware image from a locked chip. But when they find out that this image doesn't work on other identical chips, they will have to crack the protection algo, increasing the cost from 100s to 1000s; 90% of them might give up at this point.

 

If it is so easy, why then do we have lock bits at all.

Even though you state that, it does not explain why something that should be functional is not.

Regards!
FS.

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

david.prentice wrote:

F Schneider wrote:

I have to erase the device to update it.

So at the lower end, I must teach my operator or technician how to do the correct update.

You can use an encrypted bootloader.

There is an Atmel App Note.

 

David.

 

I know that, but if you can directly read the application section, then the encryption is gone... 

Regards!
FS.

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

F Schneider wrote:
If it is so easy, why then do we have lock bits at all.
It's "eye candy". A toy to keep folks entertained. It will certainly prevent your best mate down the pub from working out how your clever gadget operates but a cut throat commerical rival will think nothing of dropping $500 to "break in" and then clone your design.

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

F Schneider wrote:
And also increase the production costs?
Indeed

Secure Boot with ATECC608A - YouTube (11m12s)

CryptoAuthLib Supported HAL Layers | cryptoauthlib/lib/hal at master · MicrochipTech/cryptoauthlib · GitHubcryptoauthlib/lib/hal at master · MicrochipTech/cryptoauthlib · GitHub

...

xmega_a3bu

...

 

edit :

5.1 Firmware validation (Secure Boot) Prototyping:

Microchip Simplifies Hardware-Based IoT Security with the Industry’s | Microchip Technology

Microchip Simplifies Hardware-Based IoT Security with the Industry’s First Pre-Provisioned Solutions for Deployments of Any Size

With a minimum orderable quantity of 10 units, Microchip’s Trust Platform provides hardware-based secure key storage for low-, mid- and high-volume deployments

...

The second tier in the program, TrustFLEX, offers the flexibility to use the customer’s certificate authority of choice while still benefiting from pre-configured use cases. These use cases include baseline security measures such as Transport Layer Security (TLS) hardened authentication for connecting to any IP-based network using any certificate chain, LoRaWAN authentication, secure boot, Over-the-Air (OTA) updates, IP protection, user data protection and key rotation. This reduces the time and complexity involved in customizing the device without requiring customized part numbers. 

...

  • TrustFLEX (ATECC608A-TFLXTLSx): $0.845 with a MOQ of 2,000 units*

...

  • *uDFN (x = U) or SO8 (x = S)

...

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Nov 27, 2019 - 05:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for those links gcharpman. I will study them.

Regards!
FS.

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

F Schneider wrote:

I have to erase the device to update it.

So at the lower end, I must teach my operator or technician how to do the correct update.


You have to erase your device before update independant of your lock fuses.
So I don't see any sense in requested read-only protection

Last Edited: Thu. Nov 28, 2019 - 12:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


But your lock bits (0x56) give you:

 

 

 

 

 

The first three are actually inappropriate for a device without a bootloader (you didn't mention one, so I assume you're not using one?).  With those lock bits, you run the risk of your application failing to work as expected if it grows larger than the target's application section (remember the the BLS can be used by the application if no bootloader is used).

 

The fourth one is applicable to your case.  How did you ever expect that a write lock would prevent reading?

 

As for using a read/write lock (as RWLOCK provides), that is no impediment to future re-programming.  You must only issue a chip erase command, which is normally the first step in (re)programming anyway.  Failing to do a chip erase before reprogramming will fail anyway, as any previous '0' bits in flash will remain '0' even after programming them to 1.  An erase operation (either chip or page) is the only way to change a flash bit from '0' to '1'.  Additionally, the chip erase also resets all lock bits to factory defaults.

 

 

 

"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."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

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

"Fast.  Cheap.  Good.  Pick two."

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