> 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.