ATMEGA can be unlocked

Go To Last Post
149 posts / 0 new

Pages

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

I am back.
The key reason of your problems because of the AVR' s designer is too bright.

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

So Katvir
Are you now saying you can not unlock AVR'S?
Mike

Keep it simple it will not bite as hard

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

@all

We have done ATMega 128-16AI and ATmega 16-8AI with www.semiresearch.com long time ago...Service terms was about 1 day !! This guys work fast and very reliable !!!

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

Hi Mike
My meaning is the guys of ATMEL avr are all foolish!
They didn't learn anything from 51 series that been unlocked.I think why they don't invite me to become their avr superviser.

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

I still don't get it. katvlr, can you or can you not unlock an AVR ? If someone were to send you an AVR, say a Mega8, could you return that AVR unharmed, and provide a hexfile from it ?

Yes or No ?

What exactly does this mean ?

katvlr wrote:

The key reason of your problems because of the AVR' s designer is too bright.

What problems ? You're saying that the AVR designers are very good at what they do - that's what they are too bright usually means.

But then you say

katvlr wrote:

My meaning is the guys of ATMEL avr are all foolish!
They didn't learn anything from 51 series that been unlocked.I think why they don't invite me to become their avr superviser.

So you think that the AVR designers are foolish, not smart at their design ? You imply here that you have also unlocked the Atmel *51 series.

So again, the question remains, can you or can you NOT unlock an AVR ? Make an offer to us - allow one of us to send you a locked AVR, then you post the hexfile from that AVR.

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

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

katvlr wrote:
Hi Mike
My meaning is the guys of ATMEL avr are all foolish!
They didn't learn anything from 51 series that been unlocked.I think why they don't invite me to become their avr superviser.

Are you actually that dumb to think that Atmel would hire you to manage one of their divisions, just because you can get around it's security measures? You must be joking! You haven't proveded any reason for them, or anyone, to hire you, you have provided no credentials. Simply circumventing a chips basic security, hardly qualifies you to run a chip design/manufacturing division. Without proper credentials, I wouldn't even hire you to clean my toilets!

As for calling them dumb, you should look in the mirror. You'd be hard pressed to present me with ANY standard micro (non-hardened) that isn't suseptable to various attacks that can result in access to the software stored on the chip. Even the hardened micros will fall to attack over time, as the attack technology advances, so will the protection technologies. These hardening techologies can be very expensive to implement, and thus are rarely included in the standard models, but hardend versions are often available, at a price premium.

There are never any guarantees for how long a chips protection scheme will work. The AVR was never meant to be high security device. It offers a comperable level of protection as any other standard micro on the market today. Nobody should expect any more from it.

If you need true security, then spend the extra money for a secure controller, there are no cheap shortcuts to this. There is alaways a risk that when you release a product that someone will steal your code. You just need to keep your eyes open to competing products, and analyse them to see if they may be violating your copyrights. Protectiong your IP is a difficult and expensive proposition. You have to carefully weigh the costs vs benefits, and sometimes stolen code has to be considered an acceptable loss.

BTW the cheapest way to protect your code is to use a ROM masked version of the micro. You will need high quantities to do this, since it requres the factory to make themask and program the chjips at the factory. Since it is ROM based, the micro will not have an external programming interface, and therefore will be immune to external attacks to get the code via a programming interface. Thsi will not protect your code from attacks that cause your program to misbehave and dump itself out a serial port or some other interface. The onlyother thing you need to worry about then is a physical attack where the die is exposed and probed, this is very expensive, and can be quite time consuming. (just be sure that interfaces like jtag are also suitably isolated form the ROM on the chip)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

glitch wrote:

The onlyother thing you need to worry about then is a physical attack where the die is exposed and probed, this is very expensive, and can be quite time consuming. (just be sure that interfaces like jtag are also suitably isolated form the ROM on the chip)

Not quite true: extracting code from mask rom device would require only nitric acid, acetone and a microscope - hence the (initial) cost of such a "protection" is far higher than the cost of breaking it.

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

im a little confused by what he said.

just one simple question. can you or can you not read a locked AVR?

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

hi

if some one realy what your code and pay for yes
atmel like 90% of other chip is not secure again invasive atack

but this need specialised lab equipemt for unpacking and expose the silicon die ..
it also need microprobing probe so it need verry specialised equipemt
(some is aviable now on ebay for 10K $ "Item number: 3818601750")

but unfortunately seem that it have some lab in the world that do code
recovery for cash and not ask to many question ...

the oly good news is that code recovery cost many $$ and the bad boy need
to find were send chip ;-) it also need ot copy hardware ect ect ..

so use uncommon avr chip ,remove chip part number ,use multilayer pcb whit top and pottom gnd plane ,use encrypted bootlaoder ,and not forgot to copy right it
this rule is not 100% safe but it may discourange bad guy and permit to put
lay on your side whit copyright ..

-->>BUT THIS IS TRUE FOR NEAR ALL MICROCONTROLER NOT OLY ATMEL<<--

MLalonde C.I.D
IPC Certified PCB Designer
WWW.Alphatronique.COM

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

gizmo wrote:
Not quite true: extracting code from mask rom device would require only nitric acid, acetone and a microscope - hence the (initial) cost of such a "protection" is far higher than the cost of breaking it.

Note that this discussion was about exploits not involving physical access to the chip die itself.

In either case, visual recovery is a well known attack, and is quite often addressed now through various inexpensive techniques. Also while the chemicals to expose the chip die may be inexpensive, the potential human cost in handeling those chemicals is very high. The fumes form nitric acid are incredibly toxic, thus it should never be handeled outside of a properly equipped lab. Unless of course you put very little value on your own life.

If the hacker has access to such a lab, that puts them in a class above the average hacker, working in their garage. Having access to such a lab, can put the hacker at par with the corporation or governemnent entity from which they are stealing those resources form in order to attack the chip. So the cost is still high, just not paid for by the hacker themself.

Also, as the feature size of the chips decreases, the difficulty of visually reading the code off the chip increases, as does the cost, since higher power microscopes are required.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

?????? :?:

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

I don't think katvir is bluffing. However, why would anyone believe that anything in life is 100% foolproof? Of course there will be security issues with any microcontroller. Any 'formalized' security design (like a fuse) will have a vulnerable workaround somehow.

And really, are we just kidding ourselves if we believe our 'idea' is so important it must be kept secret for eternity? Besides, if someone spends more time and effort protecting their IP than advancing it, then their priorities are out of order.

OK, so it's good to be a little paranoid that someone is trying to steal your code. But don't let it stop your innovation.

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

Sonos wrote:
I don't think katvir is bluffing. However, why would anyone believe that anything in life is 100% foolproof? Of course there will be security issues with any microcontroller. Any 'formalized' security design (like a fuse) will have a vulnerable workaround somehow.

And really, are we just kidding ourselves if we believe our 'idea' is so important it must be kept secret for eternity? Besides, if someone spends more time and effort protecting their IP than advancing it, then their priorities are out of order.

OK, so it's good to be a little paranoid that someone is trying to steal your code. But don't let it stop your innovation.

I might comment that a security leaks are far more likely to come from the design team rather than a hacker on the outside. For larger companies with today's multiple outsourcing trends, the number of 'hands' that touch the design process increase proportionally with time to market. If security is really an issue for your project, keep the design team small, assign responsibility for IP to one person, and proceed slowly. Burn the reset button and erase chip markings with acetone. Keep written description of the project to a minimum. Then put your project on the market and make sure you have the next generation of IP on your bench ready for the next cycle.

I found this discussion of vulnerability analysis with a simple google search, and thought the discussion about the hardware interesting. Although I do not know the specifics of hacking like katvlr does, I suspect that not a whole lot has changed in the microchip security division since 1972 when it comes to 8 bit MCUs.

http://csrc.nist.gov/publication...
Early Computer Security Papers, Part I
This list of papers was initially distributed on CD-ROM at NISSC '98. These papers are unpublished, seminal works in computer security. They are papers every serious student of computer security should read. They are not easy to find. The goal of this collection is to make them widely available. This list was compiled by the Computer Security Laboratory of the Computer Science Department at the University of California, Davis.

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

hi sonos ..

all this was good for the 1990 year .... now welcome to the 2004

now it have some lab that invoice 5k or less for doing code recovery ..
ther lab is a verry recent thing that have apear in the last 2 year and we
must expect the it will continue to grow a down price ...

for your competitor or hacker it cost less to send chip for opening it
that louse it time doing social ingenering whit your staff or spy your doc ..

normal R&D project cost far over the 5k $ that is need for recover your code

even if you erase chip marking not forgot that chip part number is still marked
on the chip silicium DIE itself so it dosend mather ..

im realy hope that someday atmel will offer a version of the avr
whit passivation layer over lock bit or even beter over wole flash
atmel have alredy tecknologie for do this since it used on other chip

it may also may put a separate set of permanet lock bit ;-)

personaly im will happy verry happy to paid 1$ or 2$ over normal price
for a avr version that is more secure :-)
all that it need is presure and demand from the user ;-))

once again im precise that this kind of atak afect all micro (pic ,avr ,8051 ect ect )
but im hope that atmel was the first to nade micro whit pasivation layer

MLalonde C.I.D
IPC certified PCB designer
www.erictronick.com

MLalonde C.I.D
IPC Certified PCB Designer
WWW.Alphatronique.COM

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

alpha wrote:

personaly im will happy verry happy to paid 1$ or 2$ over normal price
for a avr version that is more secure :-)
all that it need is presure and demand from the user ;-))

once again im precise that this kind of atak afect all micro (pic ,avr ,8051 ect ect )
but im hope that atmel was the first to nade micro whit pasivation layer

MLalonde C.I.D
IPC certified PCB designer
www.erictronick.com

I would also gladly pay extra for a 'secure version'.

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

Here is an article that discuss this issue.

Regards,
Alejandro.
http://www.ocam.cl

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

Can anyone proove that they have unlocked an AVR?

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:
Can anyone proove that they have unlocked an AVR?

Why don't you ask ATMEL? and tell us the answer.

You could contact by avr@atmel.com

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

Why does this thread remind of the argument so loved of old as to how many angels can dance on the head of a pin.

Keep it simple it will not bite as hard

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

sutton wrote:
Why does this thread remind of the argument so loved of old as to how many angels can dance on the head of a pin.

It has to do with the quantum conservation of charm and strangeness!
C.H.

C. H.
-------------------------------------------------------------------
It's only waste if you don't use it!

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

Here's the email i've sent to Atmel:

Quote:
Greetings Atmel,

I come on behalf of many users on the avrfreaks.net forums. Latley, there have been a lot of discussion (over 70 posts) about the posibility of unlocking HEX programs from the MEGA (or any AVR, for that matter) by the use of software or physical tecniques by unscrupulous persons.

I (and fellow users) would like to know if it is possible to unlock any of the AVR microcontrollers using any method after all the lockbits have been set. You can view the posts about this topic at:

http://www.avrfreaks.net/phpBB2/...

Regards,
Dean Camera

--------------------------
Dean Camera
En-Tech
www.en-tech.i8.com
-------------------------

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

May 5 to June 24, and still no direct answer or response to the request for a demonstration.
I have no doubt someone could crack the protection, however this is starting to sound a little like FUD/extortion type of thing. Go to the biggest Atmel related site and start talking about cracking AVR protection, blah blah blah.

Or just looking to drum up business. Guess the economy must really be sucking over there.

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

Hi Dean Camera

Did ATMEL reply you?
I think ATMEL knew this cas,but they need time to solve the problem.

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

once i did by mistake put an atmega32 to a 5 V reverse voltage by mistake for about 5 seconds.. it made some strange sounds, then quickly unplugged... after this trying to read the avr via the SPI always failed... but the program still runned correctly and any program I wrote from then on, but always got the message write failed after verification of the program... i don't have any means of programming the device over the other programming interfaces but it might have done the same to them too, someone could try it with the least expensive micro if he has more ways of programming an avr.
It's worth a try i say.

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

hi

come one guy did you realy think that atmel will reply and said "yes it posible" ??

it even not abel to said truth abot some of knot bog .....

atmel like near all other chip is vulnerable to invasive atack
so wly refuse to open your eys on this fack ??

the invasive atck was knot for abont decade now many many paper
was write on the suject http://www.cl.cam.ac.uk/~sps32/

and as far that im knot avr is sensitive to "Optical Fault Induction Attacks"

atmel was never claim to made avr chip secure to invasive atack ....

so the problme is not atmel or atmel chip the problme is now some conpany that
have material for do this kind of invasive atack will made it for relative cheap price
and not ask question oly made you sing a disclamer sheet ..

so wly ask atmel abot a problme that cover near all chip for near all mfg ???

p.s. if you look one of my previous post on this tread im have demontrated that
you abel to got all that you need for made invasive atack right on ebay for under 20K$
this and many many paper write on that subject may considered as a prouf that it posible ?

MLalonde C.I.D
IPC Certified PCB Designer
WWW.Alphatronique.COM

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

Yo Alpha,
I'm betting your last post took the crown for the most typos/grammatical errors ever written in a collective statement, but anyway you make some good points.

I wrote that message to Atmel two days ago, and assuming the avr@atmel.com address was correct, they got it. So far, they've ignored me - they never replied to another one of my questions about the dataflash and that was several months ago.

Alpha's right, if it was vulnerable to attack, why would they advertise it and lose business? Better to ingnore us....

If they don't reply within two weeks, why doesn't everyone on this thread post the same message to them (but change the name from mine) bause I can't stand it when comanies ignore cusomers.

Investment Technologies (makers of the ABCmini and MAXI boards which I own, based upon the 8353 chip) have done the same thing, they just ignore every request I send to them unless it revolves around purchasing their boards (a request for bulk-prices for a project my dad's friend asked me to do recieved a swift reply of only two or so days).

Perhaps i'm just cynical, but where's the customer service? Another thread regards a fault in on of the MEGA chips, where the Avcc and Vcc were internally connected - resulting in digital noise on the analogue circuitry - and Atmel only acnowleged the problem after many people complained.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Ya know, money talk$.....

I have found a simple way to get companies to reply.

1. Try to get a number of people to email them asking for clarification. Hint, some consider it out of line, but Googling for V.P., COO, and other -current- VIP's at a company, and emailing them seems to do it for me most of the time.

2. If there is still no response, I will occasionally post it where someone in the company's Executive or BOD will definately see it, and thats like, here: http://finance.yahoo.com/q?s=ATM...

Most Exec's and higher-ups spend a decent amount of time every day looking at their companies stock.

While I think the original poster and his bud's have some other reason for trying to drum up bad news, 'twould be nice if Atmel were to reply.

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

While Katvlr created this thread for the wrong reasons (people shoudn't steal other's work), I think most of the people now on this thread are just curious as to the level of protection that the internal fusebits offer.

Money DOES talk, perhaps someone should rephrase my email to:

Quote:
Dear Atmel,

My name is (insert name here) and I am a (insert age) year old (insert gender) living in (insert country). I am interested in purchasing (delete where appropriate) a number/a large quantity/one of your ATMEGA (insert chip type) chips for a project. After reading a post at AVRFreaks.net, I have conserns relating to the security of the aformentioned chip. I do not want to purchase the secure version as I am sure that the standard versions will be adequate for my purpose. Before buying, I would like to know your standpoint on the issue; If I put complex code into the chip and activate the "lockbits" I have been hearing about, will my code be adequatly protected?

I have heard good reviews of your devices, and am sure you take security seriously, as do I. As the development cycle for my project has been quite leghthy, and the device is aimed at the commercial market, I need a maximum security level at minimum price. Can you guarantee that the ATMEGA chip cannot be unlocked by unscrupulous persons? I would also like to know if there have been any past issues where these devices have been unlocked and the code stolen.

Regards,
(insert name here)

Not bad, huh? Dangle the possibility of money and they'll come running...

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

By the way, Sonny_AVR, how could ATMEL fix the vulnerability? I bet they'll just tell users to purchase the more expensive "secure" AVR's, but perhaps i'm just being cynical.

They should make two new additions to the chip:
1) Add a pin that will destroy the programming pins internally when a voltage is applied
2) Add a photosensitive/oxygen sensitive oxidising layer that will corrode the chip when exposed to air/light

The second Idea would be great, make a final stage of production in a light-sealed box that coats the chip dye layer in a compount that oxydises when exposed to light, so that anny attempts to physically access the chip's internals will destroy all the circuitry/memory. It might be impractical, but at least somone's coming up with new ideas.

This brings a new topic, but lets keep it under this whole "unlocking" thread (now a saga), can anyone think of any way to protect the chip (both practical, impractical and the downright impossible). I look forward to other's ideas.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

hi

ya sorry for all my typo english is not my natural language

for atmel user helpdsk , atmel have made this forum if you whois this forum
you will see that doman name is ornered by atmel ;-) so atmel guy read this forum to

also im have made or participed on some project for gov and even military
an we have used avr chip on secure produck .. the oly thig is that you may knot
ther kind of atack and you may buil your project whit this fack in mind
so you made to made case temperprouf like all chip erase if case open ...

dallas and atmel have also secure memory chip that is more secure to atack
you may also use java smart card for hold part ot your secret algo ..

personaly im realy hope that atmel someday made a "NDA less" at90sc version
of it secure avr based smartcard

MLalonde C.I.D
IPC Certified PCB Designer
WWW.Alphatronique.COM

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

It is true that any Atmel AVR can be read even if locked. The method someone else mentioned in an earlier page suggests that the AT90 series is vaulernable to the same programming glitch present in the older AT89 series devices.

I do not believe the AT90 series is suceptable to this attack. Atmel knew about this problem and corrected it in later versions of the devices.

The 2 post person claimed he could crack a few of the many devices. Sounds alittle strange.

Does a glitch on power exist during 'chip erase' to leave the memory alone with the lockbit reset? I don't know but you could always ask Atmel which comes first (bulk erase or lockbit erase).

In regards to the Skoborgov guy, the entire article from the url someone posted was copied word-4-word from Kommerling's paper with Kuhn.

In regards to his optical attacks he performed on PICs (the worlds most insecure processor I might add, the AVR is 5x more secure!), doesn't he know what a photo-transistor is? Everyone has been aware of light exposure to transistors since it's invention! Second generation AVR's are not easilly susseptable to this attack. In fact, it's useless to really try this.

Just my two cents.

Regards and the AVR rules!

Regards

Last Edited: Fri. Aug 13, 2004 - 02:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sucess! Atmel have replied to my original email. Here is their official reply:

Quote:
Dear customer,

First of all, we don’t know about any occurrences or proof that it is
possible to read the Flash or EEPROM content out of a locked AVR device.

Many of the suggestions in the discussion thread you refer to are clever,
but often expensive and/or already thought of and protected for by design.
It will probably be less expensive to bribe the system designer in a project
and get the source code compared to some of the methods suggested.

I also want to warn you about trying to fry the reset pin (as one suggests
in the mail thread). Even though this might seem to disable the programming
interface, other functions in the device may also be damaged.
Characteristics of the device, like power consumption, life time or ESD
structures, may change in the process.

Second, we always answer all e-mails sent to avr@atmel.com except spam and
e-mails stopped by spam filters. If you don’t get a reply within 3 working
days, please try to resend your question with no attachment and ask what is
happening. We experience lots of mails with attachments disappearing in spam
filters both inside and outside Atmel. The avr@atmel.com technical support
service is open for anyone. We receive and answer questions from both multi
million dollar customers and students and hobbyists every day.

At last, thank you for contributing to the AVR Freaks community. In the AVR
group at Atmel Corp we are proud looking at all the activity our design
efforts is creating. We feel the free discussion and open resources at
Freaks is an important addition to the support we can provide.

Interesting...
- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

interesting

Regards

Last Edited: Fri. Aug 13, 2004 - 02:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I can make life because AVR can be unlocked and that will lead ATMEL do more in their technical promotion. :D Also I doubt if AVR can be unlocked so that they can sell more ic. :wink:

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

Hmmm, Katvlr seems to have been shunted from his own thread.....

Anyway, I was very interested in the background info posted by sxpilot450. I feel much more secure entrusting my future programs to my trusty 8535 and MEGA (if I decide to buy some MEGAs).

You said that the "Chip erase is a logic function". Does this mean that the lockbits and memory are simultaniously wiped during a erase? If not, perhaps it is possible to shut the device's power off after it has wiped the lockbits but not the memory. It would take some carfull timing (an extreamly tiny duration) and this is assuming that the lockbits are erased first.

It's nice to see that sxpilot450 has some common sense not to release details to the forum, although frustrating as I like to know everything. Still better to remain ignorant than have every twit in the world copying other's code like in PC software. Perhaps the AVR's could implement a cryptographic algorithm, liek in the XBox? If the coding was internal, it would not suffer the same flaws as the XBox - some guy worked out how to bypass the security by turnign the XBox on, waiting for the crypto-keys to be sent to the processor and then disconnecting the HD (leaving the power on and thus the crypto-code) and then altering the HD's contents. There goes another couple of million dollars in code investements...........

But I digress. I'm still waiting for people to post their comments on possible, impossible, uneconomical and interesting ways to protect the AT code.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:

You said that the "Chip erase is a logic function". Does this mean that the lockbits and memory are simultaniously wiped during a erase? If not, perhaps it is possible to shut the device's power off after it has wiped the lockbits but not the memory. It would take some carfull timing (an extreamly tiny duration) and this is assuming that the lockbits are erased first.

I am not sure if they performed both functions together or not. There's no reason why they couldn't because ever 'fuse' they refer too is actually 1 single cell of eeprom type memory. This could be verifed I suppose. Timing attack on erasure if this exists (I really don't think it does because they offered something like $50k usd back in 1998 to anyone who could crack them non-invasively) is easilly performed and could be done with precision using the current configuration inside the stk500.

Quote:

It's nice to see that sxpilot450 has some common sense not to release details to the forum, although frustrating as I like to know everything.

I love Atmel's products. I have used the AVR since 1997 starting with the 8515. When I stumbled onto this thread, I thought it was owed some explination. For all you know, maybe that guy was just lying because I don't know of anyone else who can do this.

Quote:

Perhaps the AVR's could implement a cryptographic algorithm, liek in the XBox?

I wish the AVR could allocate an area of ram that could become or always be executable. Then, you could keep a key in the ram to decrypt important routines to your code that only could execute once decrypted inside the ram. In the event of power-loss, the key is destroyed and the secure routines would be gone. This has been done for years and Dallas did this in the 5002 and newer replacement devices.

The trick would be that Atmel woudl not design this chip as having battery-backed ram, you would design your design to keep the avr powered up at all times and known when to sleep etc to conserve power.

Regards

Regards

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

Quote:
But I digress. I'm still waiting for people to post their comments on possible, impossible, uneconomical and interesting ways to protect the AT code.

- Dean

If you want to enhance the security of an application, compile it in Forth without
"headers". The object module will have some chunks of recognizable machine
code, but as a whole, will just appear to be gibberish. Ultimately, your protection
against copying etc. is to sell as many as you can as quickly as you can,
because in general, it is easier and faster to simply redesign a product than it is
to unravel someone else's program.

Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

tpappano wrote:
If you want to enhance the security of an application, compile it in Forth without
"headers". The object module will have some chunks of recognizable machine

code, but as a whole, will just appear to be gibberish. Ultimately, your protection
against copying etc. is to sell as many as you can as quickly as you can,
because in general, it is easier and faster to simply redesign a product than it is
to unravel someone else's program.

Tom Pappano
Tulsa, Oklahoma

If you believe that, you are operating under a false sense of security. The code will not be any more secure than any other object code. Object code is the same, no matter what compiler generated it, it can always be disassembled and analysed back into some source form. While you will not get the source in it's original form, you will get enough to be able to re-create the application. And if it's simply copying that you're worried about, there is nothing you can do in the source to prevent that, since people can make binary copies to their hearts desire, without ever knowing anything about the source code.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Quote:
If you believe that, you are operating under a false sense of security. The code will not be any more secure than any other object code. Object code is the same, no matter what compiler generated it, it can always be disassembled and analysed back into some source form. While you will not get the source in it's original form, you will get enough to be able to re-create the application. And if it's simply copying that you're worried about, there is nothing you can do in the source to prevent that, since people can make binary copies to their hearts desire, without ever knowing anything about the source code.

I suppose there are, or could be Forth compilers that generate simple machine language
output, in which case it would be as simple to unravel as any other machine code
output, but I have never seen or used one. Such a method would negate one of Forth's
main advantages, program compactness. What I intended to convey was that
the security of your program's logical flow is enhanced. The output of a Forth compiler
is only partially assembly language, the bulk of the application's code appears as
just random data. Running a machine code disassembler on a Forth object module
won't get you that much. One can machine-decompile Forth, if the decompiler was
a creation of the original compiler, but doing it by hand would be quite a PITA.

Obviously, you can always simply copy an object module and run it on copied
hardware, but that's what the "lock bits" are supposed to be for 8-)

I still maintain that it does not matter that much in the end anyway, because a
competent designer should be able to redesign the hardware and software
faster than unscrambling someone else's, and improve on it to boot.

Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

Hi,

Here is one thing I have always wanted to try to get code out of an AVR:

Remember the AVR erases first all the program memory, then the security lock bits.

It may be possible to have a system whereby you issue the erase command. Then drop the power to the AVR a lot - so much that the erase would fail. Partway through the erase you raise the power again to levels that can perform erases, thereby erasing the security lock bits.

It would be a long shot, but could work. Or has this already been suggested/tried? There is lots of text referenced so I may have missed it.

Regards,

-Colin

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

tpappano,

The AVR is a state machine that interprets codes which when disassembled return to a mneumonic to help a human better remember how to write the codes to produce a desired result.

Where you write in ADA, Fortran, C, or Basic on the AVR. The AVR doesn't understand this nor care. It can only interpret fetches of 16 bits and then switch states to perform what you asked of it.

The bottom line is Fortran in = assembler output when disassembled. There are many among us who only write in assembler for the AVR. I am one of those many.

I believe C is for the PC and ASM is for embedded processors.

c_oflynn,

Atmel is no dummy. Their time for learning was in the AT89 series. The AVR belongs in the Lueve! For example- all of the devices contain more fuses than the datasheets explain. Why?? I have never explored why but I do know that if you open an AVR and expose it to UV, you will make the chip no longer ID properly and it does other strange things when talking to a programmer. Also- UV sets the lockbits, it does not erase them so don't go this route.

Regards

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

sxpilot450 wrote:
tpappano,

The AVR is a state machine that interprets codes which when disassembled return to a mneumonic to help a human better remember how to write the codes to produce a desired result.

Where you write in ADA, Fortran, C, or Basic on the AVR. The AVR doesn't understand this nor care. It can only interpret fetches of 16 bits and then switch states to perform what you asked of it.

The bottom line is Fortran in = assembler output when disassembled.

sxpilot450(if that IS your real name), you appear to have missed the point of tpappano's observations. Yes, Forth will "compile" into assembler, but Forth is a threaded interpreted code, the assembler you end up with consists of a series of addresses which point to either code fragments performing primitive functions or to another series of addresses which point to either code fragments performing primitive functions or another series of addresses..... you probably get the idea by now. Without access to the dictionary, which is produced at compile time, it is very tedious to say the least to make sense of compiled Forth. Trust me, I've tried it.

John Brown

Quebracho seems to be the hardest wood.

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

Hi to All!

I have been reading this topic for a long time and I think I should express my opinion here.

Firstly, I'm writing up my PhD thesis. It's going to be exactly about all the aspects of the hardware security in microcontrollers. It'll have some references to CPLD, FPGA and smartcard designs but without much information and details. The thesis will summarise my achievements in hardware security analysis upto the end of year 2003. The latest results will not go and will be reported and published later. The thesis will be much more informative than my old well known article (http://www.cl.cam.ac.uk/~sps32/m...) which is well out of date as it was based on the work done up to year 2000.
Some microcontrollers provide really good security protection. The question is how to test and compare the security in microcontrollers and choose the right one for your application. The ideas on posible ways of such security evaluation will be given in my thesis.
I'm too busy at the moment so please do not send me emails asking for more information. Just wait until my thesis are public available and most of the questions arose here will be answered. I still hope to submit my thesis by the end of August, so if all goes well I'll make them available later in October-November.
The thesis will not contain any information on hacking the AVR microcontroller products, not because they are super secure. Atmel has done a good job in making their products very good protected against non-invasive attacks. There is a huge progress from an old AT89 chips, through AT90S chips to the latest ATmega chips (mega8...128, mega162 etc with mask marking 35xxx). I don't know about the existance of any non-invasive attacks on these latest products. At the same time, any microcontroller can be broken with invasive methods. The question is in time and cost.

My research proposal for the next academic year will come up shortly on my homepage. It'll outline what I'll be up to during the first year of my postdoctoral research.

Now I'll look back through all the postings and express my opinion.
1. Old Atmel microcontrollers (before year 1999) had some problems and it was possible to erase the security fuse without disturbing the main memory. Atmel fixed this problem and since 1999 their microcontrollers are much more secure.
2. Invasive methods can give the result but the initial investments into equipment is enormous (around $100K) plus highly skilled engineer to operate it and perform the attack is required.
3. I don't know any microcontroller that can withstand if an attacker wish to spend $20K to get the code out of the chip. The question is whether it's economically reasonable as he'll have to invest a lot to reverse engineer the code and build his own product. It might be cheaper to do it on his own from scratch.
4. Latest AVR microcoontrollers (mega8...128, mega162 etc with mask 35xxx) provide moderate security and they probable have the best security amoung all standard microcontrollers. If someone needs higher security he should look on secure microcontrollers and smartcards like AT90SCxxxx. But better security means extra cost for the design and might be not economically reasonable.
5. Nothing is absolutely secure. No one manufacturer would even guarantee the security for any silicon chip. Even smartcards can be reverse engineered in high-end labs if several million dollars budget for the attack isn't an issue.
6. Mask ROM chips usually offer better security than EEPROM and Flash based chips. Firstly, chips with Mask ROM normally don't have any programming interface at all. Secondly, only old types of Mask ROM can be read optically under a microscope (something like 10 years old Motorola and Microchip chips). Modern chips (0.5-micron and smaller) requires veryt sophisticated chip preparation techniques to make the Mask ROM transistors optically visible. More information with diagrams, layouts and pictures for different ROM types will be in my thesis.
7. Having all the equipment isn't enough. One could spend $10M on buying everything available on the market but without knowledge and experince he won't get any results. Where another could get very far with only $100K investment and lots of home-made equipment.
8. None of the semiconductor manufacturers will confirm that their products are insecure. They'll take time, solve the problem and manufacture new chips.
9. I agree on most "sxpilot450" says. He knows surprisingly lot about the security in AVRs. I agree that my old article (http://www.cl.cam.ac.uk/~sps32/m...) doesn't have any extra information on attack technologies apart from what was published before (i.e. Tamper Resistance paper). It just summarises the results and overview the problems that might take place in microcontrollers. The article is dated 2000 and I didn't have much results that time.
10. I agree with "expilot450" that AVRs are much more secure than PICs. But I don't agree that my optical attacks can't be used for AVRs. They were tested on 6 metal layer 0.18-micron chip and it was possible to switch registers inside the chip through the mesh of metal "spaghetty" full of wires and intermetal space fillers. Does "expilot450" know about refraction, reflection and diffraction? They all help a lot. Only a large metal plane can prevent from these attacks but even in this case they can be applied from the back side. My attacks are not useless for AVRs. Why not to try them? The question is: Why someone should bother if using invasive attacks is much easier and relatively straightforward to perform.
11. I don't agree with "sxpilot450" that ATmega128 is less secure than ATmega32. Why? Same technology, same security protection scheme and very similar design was used for the whole family of ATmega8/16/32/64/128. Why one should be less secure than another? ATmega162, for example, has different design of the security protection. It's slightly better on my own opinion.

That seems to be all. Please do not send me emails as I simply don't have time to reply on them. Just keep visiting my home page for updates (http://www.cl.cam.ac.uk/~sps32/).
Thanks
Sergei

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

At last some answers or statements have arrived that raise the level from mindless uninformed ramblings, with more than a touch of ego rubbing.

Interesting to read the point on the nature of compiled FORTRAN. So much to learn. I do have the impression that C, when compiled with a high level of code compression, will also exhibit scrambled code to the point the code writter could find debugging at assembler level a bit difficult.

Oh Dean please do not mark anothers use of English! A lot of the users of this forum do not have English as their first or second language.

Keep it simple it will not bite as hard

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

Sutton,

Unless I've missed the point (it could happen), it was FORTH and not FORTRAN to which tpappano was referring. It was the sxpilot450 who added FORTRAN to the mixture. Certainly my comments relate to FORTH, I've never even seen a FORTRAN.

John Brown

Quebracho seems to be the hardest wood.

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

John
You have not missed the point I used the wrong language :oops:
But I still stand by my comment on C compilers when producing compact code.
But yet again a drift off from the topic (guilty as charged)

Keep it simple it will not bite as hard

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

Quote:

10. I agree with "expilot450" that AVRs are much more secure than PICs. But I don't agree that my optical attacks can't be used for AVRs. They were tested on 6 metal layer 0.18-micron10. I agree with "expilot450" that AVRs are much more secure than PICs. But I don't agree that my optical attacks can't be used for AVRs. They were tested on 6 metal layer 0.18-micron chip and it was possible to switch registers inside the chip through the mesh of metal "spaghetty" full of wires and intermetal space fillers. Does "expilot450" know about refraction, reflection and diffraction? They all help a lot. Only a large metal plane can prevent from these attacks but even in this case they can be applied from the back side. My attacks are not useless for AVRs. Why not to try them? The question is: Why someone should bother if using invasive attacks is much easier and relatively straightforward to perform.

I did some checking this weekend and you have a good point on optical access to the ram in the newest designs. You can access the memory of the sram easilly but touching the register file is alittle more tricky as it's really buried.

Quote:

11. I don't agree with "sxpilot450" that ATmega128 is less secure than ATmega32. Why? Same technology, same security protection scheme and very similar design was used for the whole family of ATmega8/16/32/64/128. Why one should be less secure than another? ATmega162, for example, has different design of the security protection. It's slightly better on my own opinion. chip and it was possible to switch registers inside the chip through the mesh of metal "spaghetty" full of wires and intermetal space fillers. Does "expilot450" know about refraction, reflection and diffraction? They all help a lot. Only a large metal plane can prevent from these attacks but even in this case they can be applied from the back side. My attacks are not useless for AVRs. Why not to try them? The question is: Why someone should bother if using invasive attacks is much easier and relatively straightforward to perform.

In a way, you are correct. They all flawed by simularities however, there is something diffrerent on all 2002-present devices which makes life more complicated for an attacker. Take a look when you have a chance.

Regarding Fortran or Forth, I think you are missing the point. You can write your code in whatever language you want. You can make an RTOS inside. It's all the same inside the core to a hacker. It's pure binary being represented to the attacker in a language he can understand that directly translates into English for him (Assembler).

The AVR has no type of Forth emulator inside. If you wrote one that fetched your compiled forth code from external memory or EEPROM or the rest of the flash, the attacker would have the code too.

Thread would appear to be dead I think but who knows.

Regards

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

Hi Freaks,
while reading the long list of postings here one point becomes very clear:
There is no absolutly security for code. But this would be not necessary if programmers would write open source software. Nobody would hack devices any more...

All of us should take three minutes to think about that.

---
Quix01

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

Quix01 wrote:
Hi Freaks,
while reading the long list of postings here one point becomes very clear:
There is no absolutly security for code. But this would be not necessary if programmers would write open source software. Nobody would hack devices any more...

All of us should take three minutes to think about that.

---
Quix01

It did not take me the three minutes.

We take about 6 person-months, give-or-take, for a small AVR industrial design. There are a number of customers and distributors and competitors that would grab it and make a clone in a New York minute if there were no protection. Our expertise in putting together near-single-chip designs using the high integration of the AVR microcontrollers would go down the toilet. Without amortizing the design the devices can be cloned at less than our cost-to-produce. I would be out of a job almost immediately, and my family would starve.

Ever been out in the real world, Quix, or are you still planting your feet under your parent's dinner table?

Lee

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

Quote:
Regarding Fortran or Forth, I think you are missing the point. You can write your code in whatever language you want. You can make an RTOS inside. It's all the same inside the core to a hacker. It's pure binary being represented to the attacker in a language he can understand that directly translates into English for him (Assembler).

Please go back and actually READ the comments that I made. Now try to understand them. Yes, it's still assembler code! You can still copy it verbatim! But if you want to follow the program flow and understand it in order to make modifications or improvements, it's a damn sight harder than understanding dis-assembled C code. As I said, I know because I've done it. It takes a lot of patience, in fact I think I used up my entire lifetime supply.

Quebracho seems to be the hardest wood.

Pages

Topic locked