Post by thread:Pic Self Destruct?

Having a client who's going to make me a LOT of $$$ who wants this, I've thought somewhat on this. Though it's somewhat silly (Unless you lock your PC up well, I'd just look on your PC for source code, if I were trying to get at secrets!), clients *do* get what they pay for... I figure that electrically blowing the Osc1 pin to shreds should do *serious* damage to the usability of the PIC, really; Probably better still would be the OSC2 pin, though, as (looking at the design of most PICs), that pin's an OUTPUT, and hard-wired to some circuitry that *I* wouldn't want to have take a 600VDC, 5000 Joule power hit <EG> If running off AC, just voltage quadruple off 120VAC into a nice high-voltage cap, make sure you safely pull down the gate of the "Fire!" SCR with a resistor, so that on startup the SCR doesn't fire by default. (Heck, just 160VDC or so off a half wave bridge will do it <G>) Probably a 30V nice large spike will do serious damage, if enough current capacity's there. Of course, if you can get squibs, could epoxy a squib (or blasting cap?) atop your PIC, and detonate it on command, and your PIC's a little damaged <G> This is what the military's done on Secure Crypto units, I understand. A black powder charge (those .22-like nail driver charge units) fired by an electrically tripped sear releasing a firing pin, would do nicely; throwing a concrete piercing nail through the PIC chip has to erase the chip fairly well! (Might want to put a safe backstop behind the PIC, like a 1/4" steel plate, for safety. That could hurt...) Or, for the truly MEAN, put 3.7 pounds of Thermite in there & fire that off. Your co-workers won't LIKE it if you do that, though <EG> Test this one outdoors, when the ground's DRY, folks... Not advocating breaking laws (including safety laws) here, o'course. Safety goggles are a good idea, I have enough blind friends already... Mark Darren King wrote: {Quote hidden}> > How could you get a PIC to totally fry itself when a certain instruction was > executed? I understand that it would probably require some external > hardware, but where is it most easy to burn it out. I think the chip can > handle alot of voltage most ways and I guess the best way would be to use a > charge pump circuit and when a gate is active it would send a jolt through > the MCU making it not function anymore. Even erasing the memory is good, > but that would probably require more parts. > > Whats the general idea on this? > > Darren King -- I do small package shipping for small businesses, world-wide.

In my case, the particular client of mine, wants to be sure no purchaser of their product has an easy time reverse-engineering their processing code; They've been 3+ years figuring out how to do this, and they would like less competition, instead of more. Just writing something to EPRom isn't going to destroy the program code. (Code protect:ALL should do them, I think, but we'll discuss it.) Imagine what security your PC would have if Windows 95 ran interpreted directly off the source code, and all that source was on your HDD, with just the comments stripped? BillG would have a small bomb glued to your hard drive, and it'd take a bomb squad WHEN Win95 crashed to disarm your PC <G> Mark Jinx wrote: > > Hi, what's the purpose of this proposed mayhem ? Are you merely > trying to disable a program in case a client doesn't pay by a certain > time or number of uses, in which case writing something to EEPROM > or similar would do, or are you trying to create a need for replacement > PICs in a product ? Just curious. > > Jinx -- I do small package shipping for small businesses, world-wide.

I think I'm beginning to understand but I haven't quite figured out the original question - how to destroy or incapacitate a PIC. Is it the intention to have a circuit which would "go postal" and fry the PIC if it was tampered with ? Realise you may not be able to be specific, but how do you make a PIC not behave like a PIC ? Or are you thinking more in terms of what stresses it will take electrically (and perhaps put it in a situation which any observer would rule out as the place for a PIC to be and therefore discount the chip as being a PIC) rather than endowing it with some exotic logical functions by stressing it ? Jinx > Really its not so much the code, but how the device works in certain > situations can really give away certain keys to everything. Who needs the > code when you could write code to make it do that anyhow... Inside a box > its not so obvious but reverse engineering is about 90% just figuring out > HOW it pulls of what it does. > > Darren King

On Mon, 22 Nov 1999 23:37:35 -0800, you wrote: >How could you get a PIC to totally fry itself when a certain instruction was >executed? I understand that it would probably require some external >hardware, but where is it most easy to burn it out. I think the chip can >handle alot of voltage most ways and I guess the best way would be to use a >charge pump circuit and when a gate is active it would send a jolt through >the MCU making it not function anymore. Even erasing the memory is good, >but that would probably require more parts. > >Whats the general idea on this? > >Darren King The Pic16F87x series have a self-program facility that would allow it to erase part of its own program memory.

I was thinking about it few days ago for another microcontroller that has e2prom. I thought to make all the important sequence of routines and links (hooks) at the e2prom. The regular code consult the e2prom to know what to do next. Another e2prom table with several numbers would make decision at the main code routines, as displacements for jumps and so on. It means that if the e2prom is blank the code got crazy and simply goes south. The intention is to disable the unit after some time or specific numbers of power on sequences... or else. Of course, a protected device *normally* could not allow the spook to read code or e2prom data, but... actual nasty microprobes can do miracles. Any external device as high voltage cap and so on can be removed and discharged much easily than to read the internal code via high technology. Don't fool yourself, the easier way to ensure protection is practicing very low price. Nobody is willing to work hard to copy a code that will produce $100 in total profit. By the way, people are not stupid anymore, The idea that if you protect your chip then *nobody* else over the world would be able to produce a similar code is at least from 20 years ago. I strongly believe that if you post here what your final product should do, at least 30 or more persons here will come up with the code in less than 2 days, and probably all of them will be working nice. Just be careful and don't go explode somebody else's fingers and get a nasty tribunal judge asking why you intentionally wanted to kill somebody.

On Tue, 23 Nov 1999 11:43:37 GMT, Mike Harrison wrote: >The Pic16F87x series have a self-program facility that would allow it >to erase part of its own program memory. > You can erase every location of program FLASH ROM, except for the loop of code doing the erasing. <G> The only thing they will find is the self-destruct code <G>. I found this out the hard way when I had a loop erasing an area of program FLASH that I was using to record debug data. The loop counter overflowed and erased the firmware. My robot had an instant brain aneurism! Froze dead in its tracks, it did! A *serious* drawback to this is that, in order for the program to be able to write to program FLASH, the block of flash being written to cannot be code protected. 8-( Dan

Darren Large relay and solenoids, shuch as a 12V automotive relay or solenoid valve will generate a very large CEMF spike (60-100V). a Diode is usually placed in parallel with the coil to prevent damage but if you could leave the diode out. Allowing the spike to go through the MCU core would be like buck shot going through a watermelon. Simply moving a value to port to turn the relay on then off would fry the chip. Have fun, don't start any fires. Scott Darren King wrote: {Quote hidden}> How could you get a PIC to totally fry itself when a certain instruction was > executed? I understand that it would probably require some external > hardware, but where is it most easy to burn it out. I think the chip can > handle alot of voltage most ways and I guess the best way would be to use a > charge pump circuit and when a gate is active it would send a jolt through > the MCU making it not function anymore. Even erasing the memory is good, > but that would probably require more parts. > > Whats the general idea on this? > > Darren King

Oh, come on, Sean. YOU ask that? I'd think you knew! "Explosives are more fun" <EG> Springs can be larger than powder driven devices, though. Probably not when you include the Caps etc., of course. We get to joke a little on the list, keeping it to a dull roar is an art, not a science <G>) And, it's probably illegal to self-destruct via powder charge in some areas. Mark Sean Breheny wrote: {Quote hidden}> > Why do you need explosives? > > Why not a simple spring-loaded device to chop the PIC in half? > > Sean > > At 08:31 AM 11/23/99 -0500, you wrote: > >Just be careful and don't go explode somebody else's fingers and get a > >nasty tribunal judge asking why you intentionally wanted to kill > >somebody. > > > | > | Sean Breheny > | Amateur Radio Callsign: KA3YXM > | Electrical Engineering Student > \--------------=---------------- > Save lives, please look at http://www.all.org > Personal page: http://www.people.cornell.edu/pages/shb7 > .....shb7KILLspam@spam@cornell.edu ICQ #: 3329174 -- I do small package shipping for small businesses, world-wide.

On Tue, 23 Nov 1999 10:57:46 -0800, Darren King wrote: >The PIC16F87x can reprogram itself... Ok, is this the lower power >programming option? >Can you give me an example of how it would be done cause that sounds like an >interesting idea. > ;Sure ... You can modify it to erase all memory, but you'll have to disable ;any interrupts before running this, otherwise when the interrupt occurs ;it will get stuck vectoring to erased program memory. ;If erasing all memory, the test at the end will not be needed because ;it will stop when it erases itself. Also, if you are erasing the ;whole memory, you will want your start address to be the first address ;after this routine. Oh, BTW, this is for a 16F877... ; ; Erase EEPROM area used for debug data from 1000h to 1FFFh BCF STATUS,RP0 ; BSF STATUS,RP1 ; Bank 2 MOVLW 0x10 ; start address MSB MOVWF EEADRH CLRF EEADR ; start address LSB CLRF EEDATA CLRF EEDATH BSF STATUS,RP0 ; Bank 3 BSF EECON1,EEPGD ; Point to PROGRAM memory LOOP: CLRWDT BSF STATUS,RP0 ; Bank 3 BSF EECON1,WREN ; Enable writes BCF INTCON,GIE ; Disable Interrupts MOVLW 0x55 ; Required Sequence MOVWF EECON2 ; Write 55h MOVLW 0xAA ; MOVWF EECON2 ; Write AAh BSF EECON1,WR ; Set WR bit to begin write ; ; ** For Rev B ES parts, replace these two NOP S with 16 lines of DATA 0x3fff NOP ; Instructions here are ignored by the ; microcontroller NOP ; Microcontroller will halt operation and wai ; a write complete. After the write ; the microcontroller continues with 3rd inst BSF INTCON,GIE ; Enable Interrupts BCF EECON1,WREN ; Disable writes BCF STATUS,RP0 ; Bank 2 INCF EEADR,F BTFSC STATUS,Z INCF EEADRH,F BTFSC EEADRH,4 GOTO LOOP BCF STATUS,RP1 ; Bank 0

Well a good method might be to use another (8pin & therefore cheap) PIC externally to send an erase command to an EEPROM device - that should do it. Alternatively the F87x series can erase themselves - in your application probably the best solution as at least the PIC is useable afterwards. Robin Abbott - robin.abbottKILLspamfored.co.uk ************************************************************************** * * NEW from FED - WIZPIC - visual PIC development * - see web site for more details ! * * Forest Electronic Developments * http://www.fored.co.uk * ************************************************************************** {Original Message removed}

"D. Schouten" wrote: > One thing that still isn't very clear to me, is if code protected OTP > devices > are more difficult to read out than the newer Flash parts with code > protect enabled. Actually any chip can have its code memory externally read, no matter what protection is used. Using special microprobes is possible to read every square micron of the silicon die, so your code is vulnerable. Of course, probably no one in this list have enough money to purchase such tools, but if your code worths enough, your competitors will have the code in the same day they put hands at your device... This tools are available at the market, chip manufacturers use them to run tests at their silicon wafers. I wonder why we don't have yet some kind of electric microscanners, so we could analyze buses and chips without physical contact... It would be funny to see the program counter register and the internal memory bus contents... how in the heck we will have protection for the common saturday afternoon pirate?

A black powder charge (those .22-like nail driver charge >units) fired by an electrically tripped sear releasing a firing pin, >would do nicely; throwing a concrete piercing nail through the PIC chip >has to erase the chip fairly well! (Might want to put a safe backstop >behind the PIC, like a 1/4" steel plate, for safety. That could >hurt...) > Now that everyone has a gotten a free simple education in explosives....Dont u t hink thats going a little overboarD???? mike ;/ On Mon, 22 Nov 1999 20:46:15 -0800 Mark Willis <.....mwillisKILLspam.....FOXINTERNET.NET> wrote: {Quote hidden}>Having a client who's going to make me a LOT of $$$ who wants this, I've >thought somewhat on this. Though it's somewhat silly (Unless you lock >your PC up well, I'd just look on your PC for source code, if I were >trying to get at secrets!), clients *do* get what they pay for... > >I figure that electrically blowing the Osc1 pin to shreds should do >*serious* damage to the usability of the PIC, really; > >Probably better still would be the OSC2 pin, though, as (looking at the >design of most PICs), that pin's an OUTPUT, and hard-wired to some >circuitry that *I* wouldn't want to have take a 600VDC, 5000 Joule power >hit <EG> If running off AC, just voltage quadruple off 120VAC into a >nice high-voltage cap, make sure you safely pull down the gate of the >"Fire!" SCR with a resistor, so that on startup the SCR doesn't fire by >default. (Heck, just 160VDC or so off a half wave bridge will do it ><G>) Probably a 30V nice large spike will do serious damage, if enough >current capacity's there. > >Of course, if you can get squibs, could epoxy a squib (or blasting cap?) >atop your PIC, and detonate it on command, and your PIC's a little >damaged <G> This is what the military's done on Secure Crypto units, I >understand. A black powder charge (those .22-like nail driver charge >units) fired by an electrically tripped sear releasing a firing pin, >would do nicely; throwing a concrete piercing nail through the PIC chip >has to erase the chip fairly well! (Might want to put a safe backstop >behind the PIC, like a 1/4" steel plate, for safety. That could >hurt...) > >Or, for the truly MEAN, put 3.7 pounds of Thermite in there & fire that >off. Your co-workers won't LIKE it if you do that, though <EG> Test >this one outdoors, when the ground's DRY, folks... > >Not advocating breaking laws (including safety laws) here, o'course. >Safety goggles are a good idea, I have enough blind friends already... > > Mark > >Darren King wrote: >> >> How could you get a PIC to totally fry itself when a certain instruction was >> executed? I understand that it would probably require some external >> hardware, but where is it most easy to burn it out. I think the chip can >> handle alot of voltage most ways and I guess the best way would be to use a >> charge pump circuit and when a gate is active it would send a jolt through >> the MCU making it not function anymore. Even erasing the memory is good, >> but that would probably require more parts. >> >> Whats the general idea on this? >> >> Darren King > >-- >I do small package shipping for small businesses, world-wide. > Send someone a cool Dynamitemail flashcard greeting!! And get rewarded. GO AHEAD! http://cards.dynamitemail.com/index.php3?rid=fc-41

Hi Wagner, They already have electron microscopes which can, IIRC, determine the voltage at various points on an object. I don't know what kind of sampling rate they can get,but it can probably already do what you are saying. It would be nice to be able to do this kind of fascinating thing on a Saturday in my own house, though! Anyone have a spare Scanning-Tunneling Microscope <G>? Sean At 07:41 PM 11/23/99 -0500, you wrote: >I wonder why we don't have yet some kind of electric microscanners, so >we could analyze buses and chips without physical contact... It would be >funny to see the program counter register and the internal memory bus >contents... how in the heck we will have protection for the common >saturday afternoon pirate? > | | Sean Breheny | Amateur Radio Callsign: KA3YXM | Electrical Engineering Student \--------------=---------------- Save lives, please look at http://www.all.org Personal page: http://www.people.cornell.edu/pages/shb7 EraseMEshb7spam_OUTTakeThisOuTcornell.edu ICQ #: 3329174

LOL, I should have been more in the PIC-humor spirit when I responded to that. Well, I fixed it, see my post about PIC-controlled ARMs <VBEG>. "Sir, I'm afraid you are under arrest. It is illegal to discharge your PIC within city limits." ;-) Sean At 10:31 AM 11/23/99 -0800, you wrote: {Quote hidden}>Oh, come on, Sean. YOU ask that? I'd think you knew! > >"Explosives are more fun" <EG> > >Springs can be larger than powder driven devices, though. Probably not >when you include the Caps etc., of course. We get to joke a little on >the list, keeping it to a dull roar is an art, not a science <G>) > >And, it's probably illegal to self-destruct via powder charge in some >areas. > > Mark > | | Sean Breheny | Amateur Radio Callsign: KA3YXM | Electrical Engineering Student \--------------=---------------- Save lives, please look at http://www.all.org Personal page: http://www.people.cornell.edu/pages/shb7 shb7spam_OUTcornell.edu ICQ #: 3329174

Mike M wrote: > > A black powder charge (those .22-like nail driver charge > >units) fired by an electrically tripped sear releasing a firing pin, > >would do nicely; throwing a concrete piercing nail through the PIC chip > >has to erase the chip fairly well! (Might want to put a safe backstop > >behind the PIC, like a 1/4" steel plate, for safety. That could > >hurt...) > > > > Now that everyone has a gotten a free simple education in explosives....Dont u think thats going a little overboarD???? > > mike ;/ Goes like this; Client has money. Mark wants money. Client says "Do this, and I'll pay you Mucho Money." Mark does what they want, even if not MY style, fairly often <G> Easy enough to do it all another way, but I don't tell ALL, just most <G> Mark -- I do small package shipping for small businesses, world-wide.

William Chops Westfield wrote: > > [explosive chip destruction] > Goes like this; > Client has money. > Mark wants money. > Client says "Do this, and I'll pay you Mucho Money." > Mark does what they want, even if not MY style, fairly often <G> > > Better find out how much it will actually cost to make any explosive > based destructive device legal. Money doesn't go far when you need > to pay lawyers to keep you out of jail. > > We have a crypto device that supposed to erase its keys if anyone tries to > tamper with it. I took one apart (very carefully, after noting no "danger: > explosive" stickers :-) It didn't contain anything more impressive than a > battery and some microswitches. > > BillW That's why the way I'm actually doing this is the way it is; I have to keep exercising my weird sense of humor, though ("Use it or lose it!")... Using external program memory & a backup battery with series microswitches (or similar) works pretty well. You can use the keys as part of program flow, or even have the PIC chip just run an interpreter, fairly easy to do (you want a good way to install the code to interpret, and not to have your laptop that code's on, to be stolen!) i.e. write your PIC code as a bunch of disconnected state machine routines, and have it choose the state table based on a battery-backed RAM table of how to decide which routine to run next. That's pretty fast, and fairly secure. That PIC chip could be non-code protected (you don't care if the competition knows how you code a "Raise this pin" or a "lower that pin" or "Compare these items" routine!), the RAM holds the decision-making data. Mark -- I do small package shipping for small businesses, world-wide.

On Mon, 22 Nov 1999, Mark Willis wrote: > In my case, the particular client of mine, wants to be sure no purchaser > of their product has an easy time reverse-engineering their processing > code; They've been 3+ years figuring out how to do this, and they would > like less competition, instead of more. Just writing something to EPRom > isn't going to destroy the program code. (Code protect:ALL should do > them, I think, but we'll discuss it.) I've had success by "blowing" the data pin out on PICs. Example: a 12C508. Ground every pin but pin 7, then put 10VDC on pin 7 for a second. Bond wire fried. You lose the use of pin 7 forever, but as it is the data I/O pin for programming, considerably hampers reading the rom save for those who can desurface the chip package and probe the die. Not strictly recommended for commercial apps, but I've never lost a PIC to this procedure yet. /**/

On Tue, 23 Nov 1999, Darren King wrote: > Really its not so much the code, but how the device works in certain > situations can really give away certain keys to everything. Who needs the > code when you could write code to make it do that anyhow... Inside a box > its not so obvious but reverse engineering is about 90% just figuring out > HOW it pulls of what it does. When I reverse-engineered a little PIC that later was to become known as the "Playstation Mod Chip", this is precisely how I did it. I did not care what code was inside the PIC, I just stuck my logic analyzer on the I/O pins and observed the timing tables the part generated. My first try at duplicating the function wasn't even written in PIC assembly, it was written in Z8 assembly. What then followed has long since passed into folklore... "What one man can invent, another man can discover." --Sherlock Holmes --Crow /**/