At 12:51 AM 1/10/97 +0200, you wrote:
>Kelly Marquardt wrote:
>>
>> Hi,
>>
>> I'm new to this list (and female for whoever was keeping track :)).
I've used
>> the 16C57 on a previous project and I'm looking into using the 17C44 on
a new
>> project.
>>
>> I'm concerned about the security of the PIC's code protection feature.
From
>> what I understand, after the code protect fuse is blown, a scrambled
version
>> of the code can still be read from the part.  The scramble is an
exclusive-nor
>> of the most and least significant bytes of the opcode (16 bit program
words).
>>
>> The question is, just how much information would this give to an adversary
>> who wanted to reverse engineer the algorithm that was implemented by the
code?
>> Clearly it would be a difficult problem.  I more or less believe that it is
>> difficult enough to provide for adequate security, but its difficult to
>> quantify this in any meaningful way.
>>
>> Has anyone else struggled with this?  Any thoughts?  I'm trying to get a
>> response from Microchip, but wondered if this group had any ideas for me.
>>
>> Thanks,
>>
>> Kelly Marquardt
>
>The first thing to do is to fill the unused memory with code snippets
>from
>old projects, or random junk. This way, your code cannot be discovered
>by XORing with retlw 255.
>
>--
>Friendly Regards
>
>Tjaart van der Walt


And keep in mind the locations from 0 to 3Fh inclusive are not secure as
they can be determined via "incremental programming."

If you are really concerned about code security, use a 16Cxx"A" part or
("A-type" 16c63/66/67, 16C72/76/770, any 16Cxxx part) and not a 16C57.

Jim

--------------------------------------------------------
Jim Robertson
NEWFOUND ELECTRONICS
Email: newfound@ne.com.au
http://www.labyrinth.net.au/~newfound

PHOENIX Shareware Picstart 16B upgrade coming.
For more details, send email to newfound@ne.com.au with
"subscribe phoenix mail list" in the BODY of the message.
--------------------------------------------------------