Post by thread:Re[2]: PICMaster Ideas - Cracking a 'thin' 16C84 I

The only thing that you will find in the undocumented codes are modes that allow us to load instructions in parallel over the A,B ports of the device. This is our primary test methodology. We load 12 bits of the 14 bit instruction and 2 of the bits are defaulted. There is a provision to vector to a start address and to revert to internal execution that allows port functionality again. We can then run the device from an external instruction stream to test. Rgds, Brian. ______________________________ Reply Separator _________________________________ Subject: Re: PICMaster Ideas - Cracking a 'thin' 16C84 ICE PIC Author: Scott Stephens <spam_OUTstephnssTakeThisOuTKIWI.PYROTECHNICS.COM> at Internet_Exchange Date: 10/2/95 9:09 AM I recently read about the Pentium's secret performance evaluation registers being hacked and posted at a web site. These registers were described in a confidential data book volume made available to Intel's prefered developers. This reminded me a posting a while back, in which someone suggested unpublished codes may exist that would allow data to be read out of a PIC's registers, for debugging. It is obvious from the data book, Programming Specification (pg 3-26, table 1.2.1.1) that many other codes exist, and may have benificial undocumented effects. If the special function and data registers can be read, the device put in an out of programming mode in-circuit, and the number of clock pulses controlled with a gated oscillator controlled by software to manage break-points (a concurrent simulation, maybe?) it would go half way to hardware emulation even if the programm would halt when the long-time serial data read out occured. And a long way in inexpensive, simple, in-ciruit debugging. I was thinking of issuing commands to the PIC in programming mode, and analyzing the state (high/low/high-Z) as clock pulses are applied. Running code on the pic to initialize registers, and testing the registers by running the PIC again after test commands are issued. Maybe someone has some C-source code for programming 16C84 or other PIC's, they could modify and share with others for a concerted, systematic assault on the programming-mode command code space. MPSIM's archaic interface's learning curve and the horror of multi-tasking have kept me busy and frustrated lately, so I havn't gotten around to it. I suppose its an ethical issue; a manufacturer's right to enable/disable features they see fit, and price accordingly. Like Intel's zapping FPU's on some 486 to sell them for less, and withhold information from all but they're favorite developers, to give them a performance edge And a customers desire to fully explore and exploit a product they have purchased. I don't think searching out undocumented features is the same as removing copy protection from or password cracking features on software, but rather like modifying a car or computer to increase its performance. Now, if I had the new & improved MP-LAB simulator, I would no doubt have better things to do ;->

BBoles@CCMAIL.MICROCHIP.COM writes: ... snip snip ... > The only thing that you will find in the undocumented codes are modes > that allow us to load instructions in parallel over the A,B ports of > the device. This is our primary test methodology. We load 12 bits of > the 14 bit instruction and 2 of the bits are defaulted. There is a > provision to vector to a start address and to revert to internal > execution that allows port functionality again. We can then run the > device from an external instruction stream to test. ... snip snip ... It may be a good idea that these modes stay undocumented. Otherwise one may be able to pull the old 8051 trick for reading protected code. I know that the 16C84 is not secure anyway, but it won't help much if one can load externaly instructions that then output the internal code through the ports... My 2 local cents worth (about USD 0.007). Richard Cape Town