Adam, if any part of the chip is code protected, that is, 50% or 256 bytes, then ICSP writes are disabled. Only ICSP reads can be done on the open half. The only way to get the memory dump of the code protected upper half is to crack the proprietary bootloader that uses the same protocol. But like I said, if you can do that, you can have it. I've got no problems with that. The real problem is that the 77A can disable ICSP reads and all internal flash reads, but still keep the chip 100% flashable. So it's easy. And then the only way at the code is to crack the bootloader, and then you'll only get that fragment of code that is in the given update. With internal flash reads disabled, you're locked out every which way. So the 77A, which was supposed to be out a looooooong time ago, was sidelined for the exact reason I said previously: Microchip couldn't care less about you or the security of your code. At least for the next half a year. They gave this no priority even though they were aware 2 years now. Microchip was aware of the problems, I spoke to many in the company and raised hell about it from the first time I saw the data sheet. Even way back then, I was told "We are aware, we respect your code, there's no higher priority for us, we're on the problem, it's already designed out, the first revision will fix it shortly. We here at microchip make it the highest priority to protect the code that our customers write, so have no fear, the 77A is on it's way". Look, I'll have my workaround at massive expense of effort and energy, almost crippling the chip to make a difficult workaround that still has the weakness of a memory dump past my bootloader. That's why a 2k flash update is going to be a several-hour conversation with the chip. In fact I may even write bogus code 3 times before writing the real code, and dot the real code in with the garbage. If I hit every location 3 time, I still get 333 flash updates of that 2k before the flash loses its adhesion. THE WHOLE SITUATION STINKS MAN!!!!!!!!!!! MICROCHIP, FINE -- TAKE MY MONEY -- BUT AS SOON AS I CAN MIGRATE, I'M GONE! And what's with no hardware USB built into these chips????? How long has USB been out? 3 years now!!!!!!!!!! Hire some more engineers. I think you guys are ridiculous in your lotalty: Here's the latest quote: http://finance.yahoo.com/q?s=mchp&d=c P/E 26.18 Mkt Cap 4.308B -- for those who don't get the "B" part, that's FOUR THOUSAND THREE HUNDRED AND EIGHT MILLION DOLLARS Last year Microchip earned a profit of 165 million dollars. You telling me they couldn't have spent what it took to add hardware USB to their flash line by now? At 26.18 times earnings????? Hell every time I buy one single chip they make at least $75 in market cap at 26+ P/E. Look, I like the 77, but the fact is the chip has non-existent protection. It's a JOKE, on you or me or anyone else who buys the chip. And I'm so disgusted by it that I have to sit here and overcome it fifty-miles-wide gaping hole with tons of code, and on top of that, page flips EVERYWHERE, to ram and flash, and then to bank 3 to read and write. Yes the 18F is good, but it's half a year away. And the 77A? Later than hell. Guys, I give up. The 77 is a perfect chip, i love writing cryptic and mind numbing code for no reason other than some wealthy buffoon who's on the board making a business decision to leave our code wide open. The dumb wealthy bastard. Couldn't care less. -----Original Message----- From: pic microcontroller discussion list [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of M. Adam Davis Sent: Thursday, July 26, 2001 8:49 AM To: PICLIST@MITVMA.MIT.EDU Subject: Re: [PIC]: FINAL WORD: A great solution for the PIC16F877 problems (code protect,bootloader) I'm somewhat confused here... Are you saying that you are still going to leave a portion of the code unprotected? Not only that, but the lower portion? This means that I can write, oh, a 10 word program that I can place at the beginning of memory to read code out of your entire chip. Since the start is unprotected, I can simply read out the program I overwrote, and I've got the code on the entire chip. I still don't see how this method will prevent anyone from getting your code - perhaps you could enlighten me. I have two more questions for you, which you'll perhaps not answer (you haven't answered them before, but I didn't ask them outright) 1) What is your product (or) what about your product requires a free, secure, field-upgrade? 2) You state boldly and outright several times that Microchip "...made some horrendous design decisions and committed them to silicon with the 77..." "[was] aware that their chip architechture was fundamentally flawed..." "...made a business decision to delay the fix..." "...[payed] no heed whatsoever to the fact that their very customers are put at severe risk of code copying." "...did not give a sh*!*t." Now, IIRC, they came out with the f877 as an answer to our prayers for a larger better version of the f84 - we weren't even hoping for the ability to self read and write the program memory in code, and when they released the preliminary data sheet we were ecstatic! The f877 was designed, and the community was happy with it. I don't ever remember Microchip releasing a sheet which showed better code protection, or discussing better code protection with anyone. It was *never* in the original design. Quite frankly I think that the reason many are defending Microchip instead of you is the old man mentallity. "We ate dirt for breakfast and we *liked* it!" We knew the f877 didn't have *everything* we could possibly ever want, but it had so much of what the other chips lacked that we were content with it and the knowledge of the soon-to-come 18 series, and the knowledge that Microchip was aware of another *want* (namely better code protection). You make the case that Microchip purposefully made decisions which they knew were 'wrong' - but I don't see any evidence of that at all, and you have not spent any time backing up your statements, only to say that it is 'obvious', it's a 'fact', and to use (what many see as) rather caustic phrasing and wording. What I would like to see are documents you have that show that Microchip had orignially considered greater code protection but threw it out knowing it was the worst possible thing to to to this chip, any document signed by an executive of Microchip that gives promises pertaining to the availability of the newer 77a, or any document which shows the chip having the better code protection which does not say "preliminary" or "this document contains forward looking statements...". In short, I'd like to see you back up your statements with more than your word. I honestly do not see where Microchip has made a misstep, or 'screwed' its customers. I'm sorry if you feel that way - and I hope you're not offended by us or our defense of Microchip. Just look forward to the happy day when either your project is complete, or microchip /finally/ releases the chip that will allow you to have your cake and eat it too. ;-) However, I'd at least like an answer to my first question (how does your current scheme protect your code?) Thanks! -Adam Ron Anthony wrote: >David, with all due respect, and to be perfectly and objectively factual, >with no reasonable debate about it, Microchip TOTALLY BLEW IT on the flash >part. Case closed. They blew it so badly that between the 77 and 77A, they >completely revamped their fundamentally flawed design. They made some >horrendous design decisions and committed them to silicon with the 77. It's >a flash part, but if you want it flashable, it must be naked. If you want >it secure, you must turn the flash into OTP. This couldn't be a worse >situation. > >Now don't get me wrong, it is a great chip. As far as designing for the >wrong part, this could not be further from the truth. It is what was >available, and we designed for it. However, to overcome the chip's >weakness, I'm at this very moment spending hour after hour on a >mind-numbingly complex kernel that every thread must jump into code >protected space and out again, to keep the code secure. And the encrypted >bootloader? Unbelievably complex. All this wasted effort to overcome a >very bad design decision by Microchip. And that the 77A was slated for >release more than 7 months ago? Inexcusable. Basically, Microchip was >aware of the code protect flaw but determined that a part that was selling >well (the 77) didn't have pressure on the revision A to come out, what's the >big deal if it slipped and people's code gets whacked by their respective >mortal enemies? By the time the 77A ships, AFTER the 18F series, it will >have been more than a year late. Why?? For a die shrink? Come on. > >And, beyond that, you can't even flip pages reliably with a single >instruction, so it takes massive code space over the course of the code just >to handle the flips. I will say thay by the time I'm done, at least 25% of >the code space will be the page flipping instructions, and another 25% will >be the mind numbing encryption algorithms. So my 8k chip is now a 4k chip, >with only half of the lower 4k (open and naked flash memory) available for >flash updates, which will be naked to ICSP reads once they land on the chip. >So instead of 8k secure flash memory, 100% updatable, I get 2k of flashable >memory that is naked to ICSP reads, and 6k of flash that is no longer flash, >but is OTP. > >And I've got to grind off the chip markings to throw one more road block at >some unknown hacker who may not even exist. What a joy! > >The fact remains that little old me is picking up the slack of a >multi-billion dollar company that gave **no consideration whatsoever** to >the fact that the ONLY part of their chip that is not a commodity is the >code that resides inside. > >Defend that? NEVER!!!! > >-----Original Message----- >From: pic microcontroller discussion list >[mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of David Dunn >Sent: Wednesday, July 25, 2001 10:12 AM >To: PICLIST@MITVMA.MIT.EDU >Subject: Re: [PIC]: FINAL WORD: A great solution for the PIC16F877 >problems (code protect,bootloader) > > >i still think you're taking a fringe view on this. very few people use a >bootloader in a production environment, so >for 99% of everybody out there, including myself, thier code on a 16F877 is >perfectly safe from all these evil >hackers you refer to with the available-right-now code protection features. > >i'm sure since it won't do what *YOU* want it to do, and that's all *YOU* >care about, it seems like it's a bad part, >but i think you are out of line posting things like this. back in the real >world, *YOU* are probably the only one >having a problem because *YOU* failed to design with parts that are >available. > >dld > > >>So, if anyone is using the F877, you are stuck with the copyable flash and >>memory-dumpable code protected region from pirate code getting past your >>bootloader. Basically the chip is very, very weak and unfortunately is a >>poor design. They've fixed it in the 77A and 18Fxx2, but it took forever, >>and is stil not fixed for another 5 months. And, if weak chips get into >> >the > >>stream, you can't close pandora's box. >> >>So, do your best, but know you are delaing with a weak chip. Darn!!!!! >> >And > >>to think the 18F gave me that glimmer of hope, just to take it away again. >>That was a mind screw I didn't need. The 16F877: great little chip, even >>better for hackers and reverse engineers and code copyers. >> >>Ron >> > >-- >http://www.piclist.com hint: To leave the PICList >mailto:piclist-unsubscribe-request@mitvma.mit.edu > >-- >http://www.piclist.com hint: PICList Posts must start with ONE topic: >[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads > > > > > -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads