'Re: 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.
______________________________ Reply Separator _________________________________
Subject: Re: PICMaster Ideas - Cracking a 'thin' 16C84 ICE PIC
Author: Scott Stephens <KIWI.PYROTECHNICS.COM> at Internet_Exchange stephnss
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 220.127.116.11) 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
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 ;->
... 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 Ivanov <PLESSEY.CO.ZA>, forgetting that the PICs use a DIVANOV
strict Harvard architecture, wrote:
>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...
Impossible, Richard... 16C84 programs can't read from code space,
protected or not.
Andrew Warren - ix.netcom.comfastfwd
Fast Forward Engineering, Vista, California
> >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...
> Impossible, Richard... 16C84 programs can't read from code space,
> protected or not.
Perfectly correct, Andy. No DPTR's in PICs. However, EEPROM contents
(those 64 bytes) of the '84 would still be insecure. If I recall
correctly, the lock bits protect that as well.
More... (looser matching)
- Last day of these posts
- In 1995
, 1996 only
- New search...