I was wondering if it is possible to read a program from the ATmega168. if it is how? Thank you!

It depends on what you are expecting to see and what protections if any the original programmer of the microcontroller envoked.

Yes you can read a "Program" off a microcontroller as long as the fuse bits to lock the program have not been set. If they have been set, it can't be done in a hobbiest environment.

If the fuses have not been set and the program read is successful, it will be a compiled program that would be raw assembly. You will not get the "C" version.

To read from flash, you need to issue the flash:r command like this:

avrdude -c avr109 -p m328p -b 115200 -P com1 -U flash:r:flash.bin:r

This would read the contents of the flash into a raw binary file called flash.bin.

Rick

Thank you Rick,

I tried this and got the following error:

avrdude: error: buffered memory access not supported. Mabe it isn't a butterfly/AVR109 but a AVR910 device?

so now what?

Ok, the last post was running the command while the chip was in run mode. I tried it again while the chip was set to receive instruction... it said the chip was initialized and that it expected a cetain signature for ATMEGA 328P (signature 1E 95 0F). I have ATMEGA 168. it says double check chip or use -F to overide check. what is this? should I do this? will this hurt the chip at all? I dont want to end up wipeing out the bootloader or something stupid like that.

Alright Rick,

I found the PDF file that came with my downloads describing this command line you gave me so that answers the above questions. Now here is the BIG question ;) How can I convert the flash.bin binary file to something legible... like mabe c?

What you would need to look for would be a disassembler. That would get the binary file into a rough assembly program.

To get it into C, I don't know if there is a, for lack of a better word, de-compiler, to do that.

Rick

Thank you Rick,

I have managed to get a hexidecimal format of the program from the chip using a disassembler called "Rec Studio 4 (beta)" it is supposed to be able to decompile to a c. representation of the code but, I have had little success with getting anything useful from it. I will investigate hex and hex editors a little further. Any further info that can be divulged on the subject would be greatly appreciated. Thanks again for the help!

And from what I see you won't get results from that. That is for computers not micro-controllers. You would need one written for the command set in an AVR not an i86 processor.

tchilzer2, may I ask exactly WHY do you want to "read" a program from the chip?

Don't you know what you loaded?

Or are you on a nefarious mission trying to hack, oops sorry trying to learn from someone else's program.

It just seems as if you must have better things to be doing with your time.

But I am willing to learn.

Ralph

This will give you assembly:

avr-objdump -j .sec1 -d -mavr src.hex > dst.S

I don't know if there are any tools to give you C.

well again I was able to get a hex file read. Your tip, treymd, makes things a lot easier on that note! thanks a bunch!

Ralph, to answer your question, there are a few things that have happened in the recent past to put me on this train of thought even though I already knew before I asked the question that my thoughts were probably going to stay just that... thoughts ;0 First, I have a laptop sitting here that I locked myself out of (throught the bios password) and have no access to my hard drive. It has been sitting here on mothballs because no conventional cmos reset works. Anyway after long hours of study on the subject (and many attempts at restoring it) I gave up. The othere day I was going through parts I have stored (from different stuff) to find diods and I found a chip. I looked up the data sheet and it is a lot like the one I am working with anyway thats what gave me the idea of reading from a chip. Yes its a little knowledge that may not be very usefull right away, but mabe after nerdkits turns me into an expert I might be able to do something with it! :) Yes I know whats on my chip, but what is on someone elses? right?

Isn't the bios password on your motherboard, not your harddrive?

If so you "might" be able to recover by pulling the battery from the motherboard and letting it set for awhile before plugging the battery back in.

Good Luck!!

Ralph

LoL,

Yes the bios password is on an unidentified eeprom on the motherboard. The hard drive is locked down behind the bios (mabe with the same password as the bios. Removing the cmos battery does default the bios but does not reset the bios password (because password is stored on a seperate chip.) This particular eeprom ( if Identified, from what I understand) must be sent in to be read...
and even at that there is no guarantee that it will be the same password to unlock the encrypted password on the harddrive (if I locked the hd). I have tried many things starting with buying a new windows installation disk (thinking I wiped out the hd). found out the hd was locked down because the installation recognized the drive but didnt have permission to access. It told me to make sure the driver was enabled in the bios settings. Thats when I discovered that I didnt remember the stupid password. I tried making a bootable flash drive to reflash the bios... It worked but no password reset. it did the same as removing the cmos battery. The best I have been able to get out of it at this point is a win 98 version of dos shell to boot from flash drive ( and I dont think that is even working like it should.) its a shame its a great computer. Better than any of my other ones. I made a habbit since I was young to password protect everything... Guess I will have to be more selective or at least write down :0 ya know I told my wife, this still dont make very much sense to me because l would not have used a password that is much different than what I always use... mabe a slight deviation. I tried everything I would have used. Oh well.

I found out that even if the read lock fuse bit is set via ISP, there is a way to retreive the hex file in the chip. I don't doubt it although some at other forums regard this as impossible. If that's the case why does Atmel make a secure chip with encryption?

Here is my question. What if once the chip is programmed you just physically cut the #1 pin off. A hardware safety measure of sort. What do you think? In order for the hacker to get at your code they would have to operate on the chip itself first.

Here's an excerpt of the following link found at Atmel (this goes for PIC too)

http://www.atmel.com/products/microcontrollers/avr/default.aspx

Flash Security ..... FlashVault code protection can carry software such as a math library or an encryption algorithm to potentially untrustworthy environments where the rest of the source code can be developed and debugged. All AVR microcontrollers contain lock mechanisms to prevent reading and copying the program stored in on-chip Flash.

If their chips are so secure why do they need "flashvault protection" via encryption?

Am I off base here?

Why am I looking in to this? Well, one of my good friends got an email from Singapore lately asking him about his cirtuit design on an electronic device he makes here in the good old USA. They tried to purchase his device from him as well. Yes, he suspects they want to copy and undercut his pricing. Fortunately he uses Atmel products so circuit design is not as crucial as the code, however, if code is vulnerable then it's back to square one. He proposed locking the chip but after I did research on this myself, well... the snip snip pin 1 method seems best. Am I off base here?

You can snip the reset pin, but a dremel and a little solder and you're back in business.

Rick