Searching \ for 'protection, how?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=protection+how
Search entire site for: 'protection, how?'.

Truncated match.
PICList Thread
'protection, how?'
1998\12\07@104908 by John Waters

picon face
Does anyone know how to protect the code (or even the circuit) in a PIC
PCB being cracked?

Thanks in advance!

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

1998\12\07@144156 by Mark Willis

flavicon
face
The way the military does this sort of thing is to blow the IC's up
with a small electrically detonated explosive charge, on their
Cryptographic systems, I've heard.  That tends to stop people from
poking in the innards of such systems, but it's hard to do for us
non-military designers!  There are a lot of tricks (I remember some, not
my area of expertise...)

 One common way to protect a circuit is to epoxy pot it;  The general
idea being that you'd break the circuitry apart in the process of
disassembling the circuit;  Epoxy can be dissolved, though.

 One common way to dig into a circuit is to x-ray it (dental x-rays are
cheap & pretty easy to arrange.)  I've heard of people using conductive
epoxy traces in multiple layers to protect against this, as apparently
the conductive traces aren't very X-Ray opaque.  And if someone
dissolves your epoxy to de-pot the circuit, those traces are now gone,
thus they're out of luck on what your wiring is (But they can now tell
what your components are!)

 It's one of those "Dance;  Counter-Dance" things, hard to say what's
best to do.

 Mark, spam_OUTmwillisTakeThisOuTspamnwlink.com

John Waters wrote:
>
> Does anyone know how to protect the code (or even the circuit) in a PIC
> PCB being cracked?
>
> Thanks in advance!
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

1998\12\08@150056 by Alex Kilpatrick

flavicon
face
> Initial (or re-) activation would require the RAM data to be loaded
> with a serial link or whatever. It would be VERY hard for anyone to
> get at this data - much harder than reading the protected code.
> If you want to protect an algorithm and had plenty of RAM to play
> with, you could break up the 'sensitive' part of the code into small
> sections, called from a jump table and sequenced by the data in the
> RAM. Or you could use a STAMP-like approach and interpret instructions
> from an external eeprom, which are encrypted by a RAM based key,
> Even if the potential hacker had all the code, they'd also need the
> RAM table to make any sense of it.

It seems like another option would be to creat a PIC assembly "obfuscator."
These are already in use for Java, which uses bytecode that is relatively
easy to disassemble.  From what I understand, the obfuscators replace all
symbol names with meaningless equivalents and scramble up the code a bit so
the flow is virtually impossible to trace.  I think the obfuscator can do
this without any performance penalty for the code.  It seems like you could
do the same thing with PIC assembler; in fact since the instruction set is
so small, it would probably be easier.  My guess is this would make any
meaningful reverse engineering very difficult.

1998\12\31@134732 by John Payson

flavicon
face
|It seems like another option would be to creat a PIC assembly "obfuscator."
|These are already in use for Java, which uses bytecode that is relatively
|easy to disassemble.  From what I understand, the obfuscators replace all
|symbol names with meaningless equivalents and scramble up the code a bit so
|the flow is virtually impossible to trace.  I think the obfuscator can do
|this without any performance penalty for the code.  It seems like you could
|do the same thing with PIC assembler; in fact since the instruction set is
|so small, it would probably be easier.  My guess is this would make any
|meaningful reverse engineering very difficult.

I don't think this would be very easy in the general case.  It
would probably be possible to engineer code obfuscation into a
compiler, but otherwise it would be very difficult for the ob-
fuscator to compute all the dependencies in the code and re-arr-
ange things so as not to break them.  I would also suspect that
it would probably be possible to undo many of the things that an
obfuscator might try to do.

Generally, the only way to make code be really obscure is to have
'interesting' code/data dependencies.  E.g. compute some bizarre
formulae and use the results of those formulae in 'computed goto's.
Even here, it's going to be hard to make the formula obscure with-
out it taking excessive execution time and without its observation
being clearly observable.

On the other hand, unless you're using the PIC for cryptographic
purposes, it's unlikely that most systems would be victimized by
reverse-engineering.  Most of the useful stuff the PIC does in
a typical system is easily externally visible.  If someone is,
e.g., examining a stepper motor controller with the intention of
mimicking its ramp-up/ramp-down curves, it's probably easier for
them to measure what the controller actually does than to try to
examine and reverse-engineer the code.  Cryptographic and compu-
tational systems are an exception to this principle, but they
represent only a fraction of applications for PICs.

1998\12\31@151848 by Keith M. Wheeler

flavicon
face
If you're doing *good* crypto, it shouldn't matter if anyone
has your algorithms or not.

and...

One classic obfuscation trick with code can't be done a PIC:
scramble the data and address lines.  Someone pulls your ROM,
reads it, and gets garbage.

and one more:

There are many PIC based systems out there that would suffer from
intense reverse engineering.  Yeah, a lot of the projects most folks
that hang out here involve nifty little sensors, motors, data logging type
stuff, but does the phrase "toll fraud" ever come to mind?  Weren't there
a lot of PICs used in some descrambling set top boxes and so forth?

-Keith Wheeler
ARMA Design                             http://www.ARMAnet.com/

At 12:48 PM 12/31/98 -0600, John Payson wrote:
{Quote hidden}


'protection, how?'
1999\01\04@172025 by John Payson
flavicon
face
|If you're doing *good* crypto, it shouldn't matter if anyone
|has your algorithms or not.

True, but keys have to be stored somewhere.  If a protected chip
can be unprotected without erasing its contents, the keys will
probably be exposed.

|One classic obfuscation trick with code can't be done a PIC:
|scramble the data and address lines.  Someone pulls your ROM,
|reads it, and gets garbage.

Address/data scrambling is sometimes a useful means of simplifying
a board layout.  Unscrambling the bus is trivial using a continuity
tester, however.  Even when a continuity tester is not available
and the address/data buses are fully encrypted, the system may be
compromised if all reads/writes are encrypted independently (as is
the case in non-caching CPU's).

|There are many PIC based systems out there that would suffer from
|intense reverse engineering.  Yeah, a lot of the projects most folks
|that hang out here involve nifty little sensors, motors, data logging type
|stuff, but does the phrase "toll fraud" ever come to mind?  Weren't there
|a lot of PICs used in some descrambling set top boxes and so forth?

Any system which is succeptable to fraud should use encryption.  As
I said, systems involving encryption are one of the few cases where
reverse-engineering may be particularly harmful to the creator of the
system.

1999\01\08@211444 by Mark A Moss

picon face
On Mon, 4 Jan 1999 16:19:17 -0600 John Payson <.....supercatKILLspamspam@spam@CIRCAD.COM>
writes:
>
>Address/data scrambling is sometimes a useful means of simplifying
>a board layout.  Unscrambling the bus is trivial using a continuity
>tester, however.  Even when a continuity tester is not available
>and the address/data buses are fully encrypted, the system may be
>compromised if all reads/writes are encrypted independently (as is
>the case in non-caching CPU's).

I'm sure if you wanted to buy enough of them and were willing to pay
enough for them, you could get the manufacturer to scramble the
data/address lines in the chip between the pins and the die.

It would sure take a lot more ingenuity to figure that one out than was
demonstrated by the guys who were caught playing around in our dumpsters.
:)

Mark Moss
Amateur Radio Operator, Technician, and General Tinkerer

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1999\01\12@122152 by John Payson

flavicon
face
On Mon, 4 Jan 1999 16:19:17 -0600 John Payson <supercatspamKILLspamCIRCAD.COM>
writes:
>
>Address/data scrambling is sometimes a useful means of simplifying
>a board layout.  Unscrambling the bus is trivial using a continuity
>tester, however.  Even when a continuity tester is not available
>and the address/data buses are fully encrypted, the system may be
>compromised if all reads/writes are encrypted independently (as is
>the case in non-caching CPU's).

|I'm sure if you wanted to buy enough of them and were willing to pay
|enough for them, you could get the manufacturer to scramble the
|data/address lines in the chip between the pins and the die.

What would be the point of that?  Given a hex file that was
scrambled by a permutation of address and data wires, I could
probably unravel it in less than an hour if I had a little bit
of background on what it was (e.g. what CPU, etc.)  Without
such background I could try different assumptions until I found
one that worked.

If you were to have the manufacturer change the instruction decode
logic somewhat, decoding would be correspondingly harder.  If you
added a few new instructions which had no equivalent on the original
CPU, it could be made much more difficult for any would-be cracker
who didn't have data on the new instructions.  In both cases, how-
ever, if the hacker has access to the CPU itself (as opposed to just
the ROM) things become much easier, since he can write code to test
out what the different instructions do.

[note: In the case of address/data scrambling, someone with access
to the CPU need only put a NOP (all zeroes) on the data bus and watch
the order of the wiggling address pins.  Unraveling the data bus is
a tiny bit harder, but not much).]

Incidentally, I believe Ford's 68HCxx-based engine controllers use a
slightly-altered instruction set.  From what I heard, this was to keep
cost down (eliminate any unnecessary instruction logic) but I suspect
it was also to discourage reverse-engineering since a scanning electron
microscope can easily read out masked rom contents.

It would sure take a lot more ingenuity to figure that one out than was
demonstrated by the guys who were caught playing around in our dumpsters.
:)

Many of the more serious security risks stem not from high-tech att-
acks (though Microsoft's lax attitude about their customer's security
is deplorable) but from low-tech ones; a security audit firm hired by
a major corporation tried an amazingly simple blunt approach: call up
employees, claim to be the IT department, and ask for their passwords.
An amazing percentage of employees willingly gave their passwords to
a complete stranger!

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...