ATMEGA can be unlocked

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

We can unlock:
ATMEGA8/ATMEGA8515/ATMEGA8535/ATMEGA16/ATMEGA128
TINY12/TINY15/TINY26

If you need more information, pls contact me.
katvlr@tom.com

Last Edited: Thu. Jun 29, 2017 - 01:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

By unlock you mean if someone gives you a locked AVR with code in it you can get that code out?

-Colin

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

YES .
AVR BUG

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

I still don't get it. I *think* you mean you can get the hex out of a locked (security fuses) AVR ? Otherwise, why not just use AVRStudio to read the flash/eeprom ?

D.

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

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

So do you expect us to be wildly excited about the fact that you can read a protected part? Personally I find it quite depressing to know that somebody else can copy the code that I work hard to write. Or are you involved in this grubby enterprise to "expose a security risk"? Doesn't sound like it to me.

Four legs good, two legs bad, three legs stable.

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

We can get the hex out of a locked (security fuses) AVR .

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

katvlr wrote:
We can get the hex out of a locked (security fuses) AVR .

How the heck this can be even possible? If entire flash memory can be readed from the locked device, then it is a catastophic to Atmel and firms that uses AVR-mcu's in their products. Is ATmega32 immune to this trick (if really exist at all :roll: )?

Every man dies, but not every man really lives.

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

My two cents....

to the one who redeems to be able to hack avrs :

No I am not intrested to let you hack my atmels and No I don't think anyone is intrested unless they have bad intentions and Yes i hope you bang your head to the wall hard enough to forget how to get them unlocked... am I crystalclear?? :evil:

to those from atmel who monitor this site :

So is this true or just bluff about a bug that can unlock an avr device? I want my code to be SAFE when I want it to be, and especially if the datasheet says so! so please if it is true , I urge you to do something about it, if not for me then for the other big ones using your products in their applications... and maybe if it is a built in backport to rescue or hack very important data then that information should never have left the atmel factory...

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

voxel79 wrote:
My two cents....

to the one who redeems to be able to hack avrs :

No I am not intrested to let you hack my atmels and No I don't think anyone is intrested unless they have bad intentions and Yes i hope you bang your head to the wall hard enough to forget how to get them unlocked... am I crystalclear?? :evil:

to those from atmel who monitor this site :

So is this true or just bluff about a bug that can unlock an avr device? I want my code to be SAFE when I want it to be, and especially if the datasheet says so! so please if it is true , I urge you to do something about it, if not for me then for the other big ones using your products in their applications... and maybe if it is a built in backport to rescue or hack very important data then that information should never have left the atmel factory...

I agree with voxel on both Cent 1 & Cent 2.

I'm hoping that we will see some kind of definitive follow-up on this claim from Atmel. If the claim is true, it is very disturbing.

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK - If I get an AtMega8 and load it with some of my code and program the lock bits, you could read the code out.

Would you be willing to try it? I don't have a Mega8 on hand, so next time I get one I'll program some code into it. If you can do it - you'd prove it IS possible. I can't pay you for this as it is really just an interest for me, but I'm sure it would improve your credibility.

If you get the code out - keep the Mega8.

Or if someone else has a Mega8 on hand they could do it (not sure when I'll be able to get a Mega8 in - I'm going to be away a lot in May).

Regards,

-Colin

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

Yes, I'm aware of that posting. There are a couple of things about it:
--it is fairly old, so Mega-generation AVRs are not included
--the new results, which should be imminent according to the link, are not available yet
--it never says "AVRs were broken into". It includes them in a list of architectures that are vulnerable to a certain class of attacks, IIRC.

In my mind, microsurgery & sophisticated techniques could probably break many locks, probably including AVR's. But for my industrial products with small flash sizes I don't worry too much about that--the effort and expense would not be justified. The program could be re-written from specs & manuals with that time & expense.

It's kind of like a bicycle lock. The determined thief could break even the toughest. But I'm not going to use a locking system that costs more and wieghs more than the bicycle.

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

AVR are not 100% secure, neither other similar microcontrollers (PIC et al). If you need a 100% secure microcontroller, get something like a SecureAVR , or the Dallas’s DS2252 :

Quoting from here :

"An example is Dallas’s DS2252, an 8051-compatible device that stores program code encrypted with a 64 bit key. The SDI pin, short for Self Destruct Input (no kidding!), will, if asserted, delete the key. A circuit that detects tampering can drive SDI, leaving the product brain-dead but reverse-engineering-resistant."

Quote:
It's kind of like a bicycle lock. The determined thief could break even the toughest. But I'm not going to use a locking system that costs more and wieghs more than the bicycle.

Agree with Lee. This is exactly the point. You get what you pay.

If someone is interested for a professional service (a real company with real name), and has deep pocket, look at http://www.chipwors.com .

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

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

Hi,

I also don't doubt that the AVR COULD be broken into - but the OP does make it seem like they've found an easy way to do it on the cheap.

As in most cases with the AVR, it would be pretty hard to justify an expensive reverse-engineering procedure, when you could just pay someone to write the same software for probably cheaper, and you get the source code.

-Colin

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

99.9% this is just a bluff. Anyone can claim that.
Let's see some proof !

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

The article "Tamper Resistance a Cautionary Note (1996)" describes various tampering methodes and gives a nice overview of the methodes 8 years ago. ( http://www.cs.rice.edu/~dwallach... )

Peter

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

That is the fact that I want to tell you. We rely on this
business to live. You can put it to the test to demonstrate the truth.

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

I shouldn't scold that unlocker guys. Yes this is definitely BAD business made by VERY BAD guys despite the fact that they are good engineers (any objections????????????). But let's try to look at it from another side. For those of us who wants our software to be locked securely, they offer an excellent test! Policemen often do the same when they compel criminals to do some work for them (that kind of work that can be done only by criiminal).

Cats never lie. At least, they do this rarely.

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

Hi,

Quote:
That is the fact that I want to tell you. We rely on this
business to live. You can put it to the test to demonstrate the truth.

So would you be willing to put it to the test to prove to this forum you can do it?

If so please contact me via e-mail or something...

Regards,

-Colin

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

Most of these guys are just scammers. Send me your chip and $1000 bucks and I'll unlock it. Bet you never hear back from the guy.

Get a real job, loser.

www.speechchips.com
SP0256-AL2, SpeakJet & Text to Speech IC's

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

1. OK so the OP says he can break into a locked AVR, burt apart from that has given no proof said anything that would make it plausible that he is right.

2. I can't see why the OP posted in the first place. Is he trying to sell this as a "service" or is he just a pityful creature trying to get attention, or maybe a fan of another architecture trying to mess with us (has happened in the past)?

3. If the OP is right in his claims, wants to sell his services and gets a "customer" through this site it is not likely that he or the "customer" will announce what they accomplished.

Just leave the poor soul on his island.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Once I worked on a project of pocket-size gamble machine. Naturally, high software security is a key feature for such device. And I was really interested, if there exists any possibility to unlock Mega128. If yes, all my project could be thrown out. Fortunately, I couldn't find any unlockers here in Ukraine. Famous Skorobogatov's articles didn't frighten me - those microprobing methods are so expensive that no one really could use them (except scientists in his univercity :) ). But if someone claims he can crack the AVR without dissolving plastic - this sounds interesting. If I was in gamble machine project right now, I'd give that guys a chance, BUT, of course, without any forward payments. :wink: Take my AVR and bring me the listing you got out from it, and give me back my AVR intact - then I'll pay. Or you dream to get money before, little fool :lol: ?

Cats never lie. At least, they do this rarely.

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

maybe what he meant by unlocking is just breaking the chip itself! hehe.. :twisted:

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

I've allready given my thoughts about this topic, but just out of pure curiosity, if you use microprobing, then unlocking an avr won't be cheap... Now how much do you ask for unlocking one and how much chance to succeed do you have?

No really If you make a living out of that, then you must be more than just a simple hacker that just learned how to unlock avrs... Besides I can't imagine that you get hundreds of requests to unlock avrs, so you must be working with PIC and other µC's too and charge high prices.
That makes me think you have come to the wrong place here since the majority of the people here are hobbyists, or professionals. The professionals will have their source code backed up (at least they really should have), and the hobbyist wont pay hundreds of dollars to unlock what they wrote in their free time (even they should have backups). I would rather place you with your yet unproven abbility in cooperation with the government or police forces etc, for example for hacking intercepted terroristic equipment. THEN you would get both my thumbs up! But in here, I don't give you any chance on cash, and as you can see, I am not alone with that opinion.

BTW, having thought about this topic way too much, from now on I will keep 5 backups of my code and build a mechaninal selfdestructsystem if I ever make something big and commercial :lol:

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

We should say there is no mcu is safe enough and can't be unlocked,AVR is the same.We can think about it in two ways.The application of AVR is more popular and that leads someone will try to unlock it like PIC.On the other hand,The unlock man can get your hex file. so we should pay more attention in the software protection to avoid your file been modified.
I hope all of you can give more info to protect the S/W in avr even if the lock bit is not safe enough.

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

By the way: if you want to increase considerably the security/secretness of your AVR code, there are efficient chemical/mechanical means to acieve that, too (of course, usable in addition to the lockbits).

One of my professors at the UNI I studied at, used to do a lot of freelance projects in switched-mode PSU and UPS. He used a strange concoction that would solidify on the PCB and envelope all the components. You could not melt it or remove it without considerably damaging the components.

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

hi,gianmario! Your suggestion sounds good but it's difficult to be used in some fields.do you have some other suggestion in software?
In some application,for example,low cost and high interests,the safe is very important.
I have some experiences to share with you.
1.To avoid the hex file been modified,we use crc.
2.We destroy the reset pin and so the ic can't be programmed.

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

Poor AVR! Hateable unclocker!

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

I have seen the solid plastic encased systems,looks pretty good and secure.Breaking the reset pin also seems a good idea.I find it unbelievable that you can make a living out of breaking AVR's only.It is like removing the Simlock from your phone...

Where is this guy from Anyway?

...
Tish

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

If you destroy the reset pin a re-programming is no more possible. I know you could use a bootloader, but if your aplication is so big, that you don't have space enough for a bootloader then you are lost. :twisted:
We are all writing software without errors arent't we. :lol:

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

I have no choice.Our porducts were unlocked and copies by someone several times.I choose AVR because I think it's safe enough and protect my products.But I am so disappointed when I get the information.We do much more in S/W to prevent being unlocked when we began our design.I think ATMET has known it and I wonder what ATMEL will do now.

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

What AVR are you talking about sonny_avr ?

As far as I know, NO modern AVR can be broken into, except using highly intrusive methods, with laser cutters and electron microscopes.

If you have a PROVEN breakin, which you YOURSELF have witnessed, please let us know.
NO secondhand stories please or false claims like the looser that started this thread. Neither is it interesting with old processors like the 2313 or 1200.

I'm pretty sure it's NOT possible, but if it is, I would really like to know.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

H Ijesper:
You are so lovely! I just want to tell all of you non of IC is safety,AVR is the same.
The stolen is anywhere and anytime. we should be stonger than the stolen if we want to live.
I have product to used TINY15,but it had been unlock!

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

Quote:
I have product to used TINY15,but it had been unlock!

How are you 100% that the Tiny15 was unlocked ? Maybe the source code leaked somehow.

(I am just wondering. Please don't take this like a personal offense or something like that. I am interested in this issue, and want to explore all the possibilities ).

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

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

Hi, guys
Idon't know process how
but AVRMega128 and ATmega8
some peoples can extract code without any problems
100% tested on "own neck"

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

The off the shelf AVR's provide 'moderate code protection', These are by no means high security devices, and should NEVER be considered as such. As a moderate device, the possibility always exists that the code can be retreived through various atacks, ranging from glitching to physical probing. The AVR and the way the fuse works, is relatively secure, in that it would be very difficult (but not necessarily impossible) to glitch the part so that the chip erase is skipped, but the fuse erase is not. I don't recall any claims form atmel that the AVR is highly secure. While the AVR's may be better than most, they are NOT totally secure.

If you require high code security, or are extremely paranoid, then you need to look at a secure micro, like secure AVR series. The secure devices contain more formidable barriers to protect your code, including ones to make physical probing very difficult. The fact is, that if you know your code was stolen, and you can prove someone is using it, the court system is powerful way to protect yourself.

For those that are talking about methods in the code itself to protect it, there is not much you can do here, since once they break down the barrier they get a raw binary image of your code, in it's entirety. Since the code is not running when the programming mode is used, there is nothing you can do in code itself to self destrct (on programmabe devices) or otherwise protect itself. All you can do is obfuscate the routines a bit to make disassembly and analysis a little more difficult, but this won't prevent them form making exact working copies.

Given enough samples and enough time, any chip can be copied. Though in many case reverse engineering the functionality would be quicker. Also remember that the art of breaking into chips is always evolving, so even todays secure micros may fail tomorrow. The art of protecting chips is also evolving, making it an endless game of cat and mouse.

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

katvlr wrote:
We rely on this business to live.

You suck!!, how many people here 'rely' on the business of writing code to live.

Your original post is kinda like Emailing Mr Gates and telling him you can generate keys for he's software....did you think anyone would actually use your service apart from proving it was all B.S.
To save face maybe you can offer 1 person a free demonsration.

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

this one bad bluf

i don like this bluf

you think user is crazy :x

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

I like this, I could call it "sex, lies and the AVR" Why sex? Well because of all the testesterone just oozing out.

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

I'm just interested in it.physically?Can we destroy the pin with software but keep the reset pin physically in good condition,hacking may be more difficult...haha,a joke

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

did anyone verify if this is true? Is the guy full of BS or what?

it would be devastating if it were true.

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

Hello

can somone explian me how to destroy reset pin or other pins for programming/reading atmel? It can be burned etc? If pins will be cutted then it can be still simple accessed . So how destroy reset pin is done ??

b.r

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

Oh, you just overvoltage the pin or reverse voltage or something like that.
Hopefuly nothing else is destroyed in that process.
If it works without hurting anything else, it's kind of a neat way to do this.
I heard that's how some people protect some Motorola DSPs too.

bob

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

to bobtransformer.

But how I can be sure if only reset pin will be burned ??
Do You know how many Volts and Ampers and Time I need to burn only Reset pin?
I need any good way to protect ATMEGA128 and others agains cracking.
I know that is simple to read Mega family chips (soon I'll get info) so I want to protect it better
thx

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

I have never done this intentionally.
I don't really know exactly how. You will have to
try some parts to see what the breaking point is.

bob

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

Trying to write a parallel fuse programmer a year ago, I mistakenly applied 18V instead of 12V to reset on a 90S2313.

that did it!!! reset pin burned, but the application still worked - you can never reprogram the chip again.

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

The cost vs gain is the issue.

So, CP, whould you extract the flash code from an ATMega8 for $1000?

How much then?

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

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

Maybe he is bored with his life...nothing more. Nees just some attention. Lot of words, nothing to prove. Just like always... :(

Every man dies, but not every man really lives.

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

he is not answering any emails

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

the guy hasent posted a reply in a while. i think he left for good. it def is a bluff. if it wasnt, he would have been back by now.

  • 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:

https://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

Four legs good, two legs bad, three legs stable.

  • 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

Four legs good, two legs bad, three legs stable.

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

Four legs good, two legs bad, three legs stable.

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

Hi @All,

i'm sorry for my english but i try my best!

I think, a consumer product that is shipped with all the Fuse-Bits are set correct! Is secure for me!

Because you sale it for 3 or 4 jears, then your next generation is on the start!
What sould i do with an redesign - it is 1 or 2 jears old i have to do the Schematic, board, the Software and so on! My company would always be to late for the marked!!!

Regards
Tassilo

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

Freaks,

Sorry, I mean no harm when I comment on other's English. I know many people born here in good ol' Australia at my school with English so bad it's almost unrecognisable. Anyway, I was reading with interest the latest posts (including Student_2's novel sized one) and I think it may be possible to write a program that deliberatly gives reverse-engineering people a hard time by messing with the routines at BASIC, C, FORTRAN, etc. level by adding as many unused variables, empty routines, routines that call other routines that call other routines, etc. so as to confuse any programmer when it is reverse-engineered back to ASSEMBLER language. With this, all remaining RAM could be put to a good use and protect your program somewhat (certainly not foolproof, but it should greatly increase the time required for reverse-engineering) and many engineers may give up, after finding that the "nifty" program that should be medium-sized is actually an 8K forest of incomprehensable jargon.

- Dean :twisted:

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

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

Quote:

Sorry, I mean no harm when I comment on other's English. I know many people born here in good ol' Australia at my school with English so bad it's almost unrecognisable. Anyway, I was reading with interest the latest posts (including Student_2's novel sized one) and I think it may be possible to write a program that deliberatly gives reverse-engineering people a hard time by messing with the routines at BASIC, C, FORTRAN, etc. level by adding as many unused variables, empty routines, routines that call other routines that call other routines, etc. so as to confuse any programmer when it is reverse-engineered back to ASSEMBLER language. With this, all remaining RAM could be put to a good use and protect your program somewhat (certainly not foolproof, but it should greatly increase the time required for reverse-engineering) and many engineers may give up, after finding that the "nifty" program that should be medium-sized is actually an 8K forest of incomprehensable jargon.

Nope. That's what a simulator is for. The problem here is most of you have your comfort level set in a higher language than the true language of the processor. Personally, I eat assembler level ones and zeros all day every day and never get headaches. I enjoy it.

Regards

Regards

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

abcminiuser wrote:

... adding as many unused variables, empty routines, routines that call other routines that call other routines, etc. ...

Yeah, like there is any SRAM, EEPROM, or flash left after '4433 and Mega8 apps are completed, and there are enough cycles available to run do-nothing routines. [And if there were, then you squeeze it into the next-smaller-sized AVR to save a buck a unit.]

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

To add to last comment-

My simulator writes a file containing the 'running code' of whatever I am simulating. As well, it builds a table to address executed, read or written too which helps track where an application went during a test.

I don't know if an attacker would be this complex but the person(s) could still use the AVR Studio to simulate with ease.

Regards

Regards

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

Hello everybody.

In my humble opinion, if somebody is able to extract the .hex code out of the chip, he is also capable of disassembling it.
He is also capable to ignore the chunk code pieces that do nothing! That just exist to hash the unexperienced cracker...

The AVR CPU core does nothing but executes binary expressions, such as "cli" (=0b_1001_0100_1111_1000), "ret" (= 0b_1001_0101_0000_1000), lds (=0b_1001_000d_dddd_0000_kkkk_kkkk_kkkk_kkkk), sbci (=0b_0100_KKKK_dddd_KKKK), lsl (=0b_0000_11dd_dddd_dddd), and so on.
Every descend disassembler such as IDA_Pro or any other similar, is able to ignore the irrelevant pieces of .hex code that are not being called, or even not been addressed...

This was the way that I tried to protect my first mental children, untill the day I really understood the CPU way of thinking, as always being a hardware guy...

Your real product protection is to be first out on the market, and to be quickly updated...
In Greece we call it "The first One, the One that teached the others" (In Greek: "Ο πρώτος Διδάξας" [Code_Page: Greek_Windows]).

Regards,
Giorgos.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

sxpilot450 wrote:
To add to last comment-

My simulator writes a file containing the 'running code' of whatever I am simulating. As well, it builds a table to address executed, read or written too which helps track where an application went during a test.

Huh, still using the old version then!
My simulator does all that and suggests five other ways of solving the problem. It also has a nice line in after dinner speaking. And writes the art criticism column for a national daily newspaper.

Quote:
Personally, I eat assembler level ones and zeros all day every day and never get headaches. I enjoy it.

Yeah, I used to eat that stuff. Then I found this great new octal breakfast cereal, six exciting new shapes.

Quote:
The problem here is most of you have your comfort level set in a higher language than the true language of the processor.

Well I don't, as it happens, but you should get together with Zainka (an occasional poster in these forums). He(she?) says that all assembler people are "mockups", whatever that means. Be warned, though, he(she) appears to be some sort of rabbit, judging from the Avatar, and they don't stick at zeroes and ones, they eat their own number twos.

Best wishes,

John Brown

Four legs good, two legs bad, three legs stable.

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

Freaks,

Well, it was just a suggestion - at least it has spurred new posts to this topic. Anyway, I'm very interested in known ways to protect my data for any future projects. I don't intend to mae it easy for hackers to replicate my hard work in an instant.

- Dean :twisted:

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

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

The easiest way to protect yourself from 99% of the attackers is to blow the serial readout pin. In the way, you can still program your device but cannot verify what you have written. You can then implement a checksum inside the program if you are paranoid to verify the code and have the ability of reading the checksum back etc.

The serial readout pin is also used in parallel mode. You can blow this pin spending under $10.00 USD.

Regards

Regards

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

What, you mean that if I spend over AU$16 on somthing at the shops, my chip will blow it's MISO pin?? Hmmm, talk about having a second mother.... :lol:

- Dean :twisted:

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

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

If you take 9 VDC and connect the positive (+) to GND and then the negative (-) to the pin of choice and hold it there for a second, you will blow out the poly-connection for this pin. You can also connect negative to VCC and then use positive on the pin of choice. This works too. It should not harm the rest of the circuit. If it shortens the life of the device or not is debatable but I don't believe it will.

I blew out selective pins on 2 different AVR's and the results are quite impressive. All that gets blown out is the poly junction around the base of each of the pads. If someone would like to see what this really looks like, PM me and I'll show you.

Regards

Regards

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

btw , I think mister hacker initiated the MOST VIEWED thread in the forum!! 10028 views.... wow. We should send him a prize or something :p

So apparently security lies very close to the hearth of the users... :)

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

Well I have a new story to add:

It started when I got an e-mail from someone saying they are able to unlock any 'Classic' AVR device very easily. They would be willing to prove it by unlocking an AVR of my choice and sending me the code inside it. They wanted to remain anonymose, and also said this was not a business for them. They had figured out some way to beat the AVR so the story goes.

Being skeptical, I took up the offer. I did the following on my Linux machine:

>>Mount a USB Key filesystem
>>Obtain 6 random files (from random.org) generated newly for me
>>Program one of those files as a binary file into an AT90S8515
>>Read the AT90S8515 back and save this file on the USB Key
>>Program the security bits
>>Confirm the AT90S8515 cannot be verified or read
>>Power cycle AT90S8515 a few times, use a different programmer, just to be SURE bits are programmed OK to prevent read/verify
>>Unmount USB Filesystem

(steps taken to ensure that the only spot with that file was on the AVR, and on a filesystem not connected to the internet)

I then mailed out just the AVR to a PO box that was provided. I also had an AT90S4433 in there, but it was not successful since the guy had never done one before, and in modifying the unlocking device to work with the AT90S4433 he erased the device. It is supposed to work with the AT90S4433 now though.

Well I got an e-mail back with a hex file attached. I converted the hex to a binary, and got the binary file that I read back from the AVR originally. The result of a diff?

[colin@localhost tmp]$ diff 8515.bin rand5.bin
[colin@localhost tmp]$

Thats right - NO difference between the two files. So the AVR Classic devices are unlockable - apparently with very little effort if someone knows how to do it. Since this was not a business the unlocker had not put a serious amount of time into unlocking the Mega devices, as so far there was no luck.

I can't say who this person is, and I don't have more details that I can provide. They said they aren't anyone who has posted to AVRFreaks claiming to be able to break the AVR, and they don't do this as a business.

Regards,

-Colin

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

None of them are complicated for someone if they have spare devices to examine and understand what they are looking for.

The newer devices are much more complex but still can be undone so to speak.

This is still by far the more secure processor family I have ever seen. They have gone extra steps to insure they are better than their close competition (whom I would believe is Microchip and Ubicom).

Regards

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

c_oflynn wrote:

Blaa blaa...
-Colin

Why didn't you send ATmegaXX(X) instead of AT90S8515?

Every man dies, but not every man really lives.

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

Blade! wrote:
c_oflynn wrote:

Blaa blaa...
-Colin

Why didn't you send ATmegaXX(X) instead of AT90S8515?

c_oflynn wrote:
It started when I got an e-mail from someone saying they are able to unlock any 'Classic' AVR device very easily.

He can unlock classic AVR's.

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

Most likely there was a bug in the erase logic or possibly in writing to fuses.

Example:

Atmel says that once lockbit one is blown you can no longer write to the device but may read from the device.

However, you can still program lockbit two when ready so this is not 100% accurate what they say.

It is possible that by increasing the voltage or lowering the voltage and messing around with writing a different state to the fuses they are changable else it's the erase and remove power type trick being used (doubtful though).

The classic avr's were 5v parts mostly. Then came lower voltage parts as they changed the internal voltage to 3.3v. If there trick is no longer working on newer parts then it is most likely a low-voltage type glitch attack.

All devices including the latest generations are attackable from power-analysis too. It is very possible the person has an SPA attack in use on older devices and just hasn't produced this for the newer ones but this is a whole new topic.

Regards

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

hi

power analysis may good for find whitch encryption method is used
and find key lenght and thing like that but im realy septical abot dump a wole
code by use power analysis ..

im realy more expect fault induction by optical or microprobing is more paratical
and have beast chance to recover whole code

personaly im just hope that is not a" bog" isue that may leack someday imto net ...

for now beast way to proteck is not use avr for verry secure produck and ofer
developmet kit for all produck made whit avr so competitor that have 5k to spend
for crack your code will buy it from you istead ....

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

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

alpha wrote:
hi

power analysis may good for find whitch encryption method is used
and find key lenght and thing like that but im realy septical abot dump a wole
code by use power analysis ..

You can read the bus using SPA attack if you make a board using ADC, resistor and an AVR or logic analyzer to sample your results.

alpha wrote:

im realy more expect fault induction by optical or microprobing is more paratical
and have beast chance to recover whole code

Best chance? It's a guarantee if the attacker knows how to analyze situations.

alpha wrote:

personaly im just hope that is not a" bog" isue that may leack someday imto net ...

for now beast way to proteck is not use avr for verry secure produck and ofer
developmet kit for all produck made whit avr so competitor that have 5k to spend
for crack your code will buy it from you istead ....

This is un-efficient. AVR's are secure for the most part. Just because a few people out there know how to get it out doesn't make them unsecure to the world. If you work is this sensative to you, get a patent or copyright on it.

Regards

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

Hi,

[beginning of blindingly obvious personal opinion and OT]

Patents and copyrights are only as good as the amount of money one has to enforce them.

[end of blindingly obvious personal opinion]

Regards,
Steve

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

[Another obvious personal opinion]
Yeah, I would think that anyone with enough money to spend on the expensive gear to microprobe the AVRs would have to own at the very least a small company. Companys are registered, so by hacking (and copying) code, they put themselves at risk of a VERY big lawsuit.
[End opinion]

Also, I propose that all user enclose "Blindingly Obvious Opinions" in lightglobes ( :idea: Opinion :idea: ) to make posting easier.

- Dean :twisted:

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

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

HI abcminiuser

not for breack your dream but reverse engenering is legit ..

and most of ther hacker live in contry were it have also not this king of law ..

also it made you sing a disclamer paper ....

last year im got similar problme and have try to fix it and unfortunately
it have noting to do if you finaly find the guy the gov of guy contry wil
totaly ingnore you bla bla bla ....

sxpilot450

as far that im knot power analysis is verry basic and easy thing to do ..
oly problme is that since all bit of a byre is loaded in parallel into registeror alu
you will abel to knot how many 1 or 0 you have on the op code but not it
specific position so you stil have alot of work for rebuil code and you have place
for alot of error

and until now im never hear abot a complete code bump whit this tecknique
personaly im dout that it may also used on comercial hacking for dump code

as soon as your setuped and die topograpy is made invasive atack is far beast reproductible and reliable that use poweranlaysis

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

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

Reverse engineering may be legit, but direct copying certainly isnt. My dad works for Orica (checmical tranding) and visited a china factory where they create some sort of synthetic food acid. The guy that invented the process has all the machinery behind locked doors (two keys turned simultaniously to enter) and hasn't pantented the process, because he knows the jerks in the world will copy it anyway.

Perhaps we should form an elite "Engineering Protection Squad" - "Protecting your ideas" to travel to foregn countries, find the hackers and suspend them by body parts that they don't want to be suspended by :twisted:

:idea: All hackers breaking others code for copying should be shot. :idea:

- Dean :twisted:

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

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

Hi,

With patents often what does occur is small company creates cool product. Big company with lots of lawyers steals idea. At this point small company really can't do a lot - Big Company will just make sure the court trial lasts long enough to bankrupt small company. Problem solved. So small company might just sell the patent...

As well patents are pretty overused IMHO - there are lots of very vague patents that you are probably already violating in some products.

On the topic of stolen stuff, there is a fairly interesting story about capacitors on some mother boards. See http://www.spectrum.ieee.org/WEB...

Regards,

-Colin

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

Alpha,

I understnad you ideas. Put them into your own SPA board and you'll see what I am talking about. You can tell the opcodes apart and if you can't because of your resolution, take it how you read it and you can logically conclude the outcome 99% of the time.

You can buy samples of the devices anywhere to practice with. Think outside the box of how you would do this. I'll give you one hint- you need to write some software with tables consisting of 256 values per table. You will have many tables so store them in files and the tables will need learned for different variants of the devices.

Regards

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

Hmmm, speaking of patents, I saw a LEGO Mindstorms (robotic LEGO - I own several sets) project that somone made. It involved "scanning" an object by dropping a rod over it in several key places (and measuring the distance dropped) to map out a three-d model on the computer. The maker of the model recieved a email from a company after posting it on the web, saying that he was breaking a patent.

My dad just got back from china, and he showed us a picture of some "knock" DVD's he saw. These were definetly pirates, but were FACTORY perfect - they has decent covers, the DVDs had perfect labels and the actual DVD surface was the aliminum layer that can only be written on in a factory (not a DVD-R). Incedible the legnths some people go to to pirate somone else's products.

- Dean :twisted:

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

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

Any new ideas? I'ts a pitty to see this thread fade into obscurity.

- Dean

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

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

Hi,

[flamebait]

To me it is a pity to see it brought back to life (and yes I am prolonging it... I know).

It seems obvious to me that a person with enough time and money can break into and steal code...period, without a doubt.

Throughout history, how many times have people claimed to have invented the "unbreakable code" only to have it broken. Whatever one person invents another person (or group or nation) can reverse invent or break or whatever. It is only a matter of motivation, will, time and money.

This subject has been bashed to death so, to me, it seems we have to accept that if the proper motive exists our work is vunerable to being stolen....PERIOD! Yes we can take the precautions mentioned in this (and other) thread(s) and those precautions will probably prevent 99% of the Joe Blow hackers from stealing your code.

So, why do we need to keep revisiting this thread. It is here for posterity for anyone to find and view. (and for the assholes out there that tell me to "deal with it", this is how I deal with it, by posting my opinions about it, so deal with that)

[/flamebait]

Regards,
Steve

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

Quote:
It seems obvious to me that a person with enough time and money can break into and steal code...period, without a doubt.

Yup - its nothing new. Just like they say what locks are for - To keep honest people honest.

Regards,

-Coolin

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

What about an eternity code? I doubt that it would work on the AVR's though. Anyway, point taken. This thread should be preserved for *cough* posterity.

- Dean

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

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

Slightly off topic, although relevant, many years ago I was able to read "protected" 8051 chips by reducing vcc to a point where the verify suddenly verifed...... I have also been able to do it with Microchip's 16F84's.... For anyone that want's a play. I have no idea how the thread starter has read proteted AVR's and I have never tried.
Modes may delete this if they find it "undesirable"

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

That old page that had info on hacking PICs - and suggested that AVR's were possible said that all the AVR's were hacked with "under/over voltage or voltage transients". This implys that using a brown-out detector chip could give some protecttion, at lest until the hacker removes it.

I say rig up your devices with a tamper switch (disabled via some ingenious method known only by you) that supplies a massive burst of current/voltage to the AVR when the device is opened in order to destroy all code that it contains.

Perhaps I should start playing with the posibility at home. Just be sure you don't short the power supply, or you could be in for a HEFTY lawsuit.

- Dean :twisted:

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

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

Brown out detector won't apply here cause the chip is in it's programming mode when the glitch is applied.

Regards

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

Quote:
I say rig up your devices with a tamper switch (disabled via some ingenious method known only by you) that supplies a massive burst of current/voltage to the AVR when the device is opened in order to destroy all code that it contains.

Some secure devices actually have this built-in - the "Self Destruct Input" that when activated will wipe all the memories of the chip clean.

If you really need this security, that would be a better way to go, rather than using the AVR for a more secure application than its really designed.

Regards,

-Colin

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

Devices Colin is referring too are for example a Dallas DS5000, DS5002, DS5250 uC.

I would never consider the DS5000,DS5002 as they each has security flaws of their own.

The DS5250 is new and has not been thoroughly examined by anyone to my knowledge to date. The DS520 requires an NDA for the documentation and they are tracking who they sell them too.

I believe Dallas wants to avoid the embarrasment's they have had over the 5000, 5002 in the past.

Any chip that cannot self-distruct within itself is no better than an AVR.

All these devices are missing is a code to bulk-erase their flash internally.

Again though, when you are in programming mode, your code is not executing so this does no good.

Regards

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

c_oflynn wrote:

Some secure devices actually have this built-in - the "Self Destruct Input" that when activated will wipe all the memories of the chip clean.

Regards,

-Colin

Yeah, I know of these "secure" avr(s). They arn't easily avaliable to me (or anyone?) and desteoying the AVR in a visual and abrupt manner due to unauthorized intrusion is a HELL of a lot more fun! Just imagine the (would be) tamperer's face when the whole thing goes up in smoke - literally! Would advise the potential customers that there "really are no user-servicable parts inside"...

- Dean :twisted:

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

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

sxpilot450 wrote:
Any chip that cannot self-distruct within itself is no better than an AVR.

All these devices are missing is a code to bulk-erase their flash internally.

Again though, when you are in programming mode, your code is not executing so this does no good.

Erasing Flash memory is a slow and tricky process. Removing all the data requires long time and proper implementation which very few hardware manufacturers do. As a result, very likely that after normal bulk-erase command the information will be still left inside the memory in the form of residual charge or whatever. It's not a question whether it's possible or not to extract the data from erased memory - it's question how difficult would it be and what would it involve.
Though, if you overwrite all the memory locations with '0'-state before bulk-erase that will make recovery virtually impossible provided you didn't use virgin cells in that instance.

Student

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

There comes a point where an off-the-shelf device will only do so much.

Sergei is absolutely correct however, we are referring to a device priced sometimes under $1.00 so there are limitations as to what the manufactuer will implement.

Not having a feature such as this is worse than at least trying by having the feature.

In reality, the nice alternative would be a key in sram to decrypt your flash code on the fly. Again however, we would pay a penalty in clock cycles with any type of algorithm. RC4 would require about 7 clock cycles per byte to execute on 8 bits. AES/DES require 16 and the chip's still need to be sellable to the average consumer.

Regards

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

Quote:
In reality, the nice alternative would be a key in sram to decrypt your flash code on the fly. Again however, we would pay a penalty in clock cycles with any type of algorithm. RC4 would require about 7 clock cycles per byte to execute on 8 bits. AES/DES require 16 and the chip's still need to be sellable to the average consumer.

You could probably do something by having the ability to decrypt say a few hundred or so instructions in advance. So if you know for example you will be in a loop waiting for an event to happen, you could go ahead and decrypt the next few instructions. Of course they you've got a point of weakness, since you now have a buffer full of decrypted instructions...

-Colin

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

Yes, but there come a point where hacking the device becomes completly uneconomical (like Atmel says). Setting the lockbits, destroying the markings and programming pins and using encryption would dissuade even the most determined hacker. Having said that, even the best ideas fail. Microsoft spent a lot of money to encrypt the conects of the XBox harddrive and components to prevent user tampering. On powerup, the CPU sends the decryption code to recieve the data.

The workround? Switch on the power, wait for the code to be sent and then connect the harddrive (with power still applied) to your computer. Now we have Linux running on a compact machine that is being sold by a universally hated company for less money than the individual parts are worth (the price of the games make up for the loss of money from the actual machine).

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

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

Quote:
On powerup, the CPU sends the decryption code to recieve the data

IIRC It actually had some pretty weak design, where it relied on a very fast databus for security. See http://www.itweek.co.uk/news/113... for example. The guy who broke it used an FPGA to interface with the HyperTransport bus and pretty quickly broke thier "encryption".

Regards,

-Colin

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

There is no honor in extracting someone else's code, (hex or otherwise) specifically if he went through the trouble of protecting it via lock fuse.
Here's one for the would be hacker out there, what if I just physically snipped off the #1 reset pin after it has been programmed? Try hacking that!!!

With honor! Kaplah!

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

There is even less honor in posting to an 8 years old thread :lol:

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

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

I think the best way to protect a standard AVR would be to convert it into something like an OTP device by zapping a pin (or two). I suspect pins are connected to the die via thin wires and at the end of these wires (on the die side) is the ESD protection. THis implies there are two diodes going from the pin (wire) to the Vcc and Gnd. These diodes are capable of carrying a fairly high current, so if one were to connect a battery from with the + at the Gnd and the minus at the required pin for a brief beriod of time, it should be possibel to blow the wire. This should not affect the rest of the chip as the current will flow only thru the diode and the wire (in thru ground and out thru the pin). So .... we could blow MISO for instance ....and render the chip physically unreadable. If this works its one easy step to create a "blower" that will pump a reversed biased current for a set period of time thru a pin.

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

make that "forward biased" thru the wrong pin (Gnd)

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

There was a thesis written about 10 or 15 years ago that described that process.
One of the MCUs was the original AVR IIRC.
But I don't have the URL in my pocket.
Oh, I should of read this thread (search on thesis).

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

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

Winners never cheat, cheaters never win.

It all starts with a mental vision.

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

Spam deleted from this old thread - as it is old I will lock it to prevent further traffic.

 

Cliff

Topic locked