style="font-size: 10pt; font-family: Arial; color: navy;">Anything
can be copied. It’s just a case of how much effort needs to be put in
to
do it. It’s not hard to stop someone cloning the board (such as having
a
unlock code that is stored in battery backed ram) but stopping someone
analyzing
the flash contents and removing any copy protection (especially when
the flash
is external to the processor) is very hard. You have to look at the
amount of
effort involved to do the latter though. In most cases it’s probably
easier just to rewrite the application
face="Wingdings" size="2">
style="font-size: 10pt; font-family: Wingdings; color:
navy;">J
Reply by Nathan Johnston●November 5, 20062006-11-05
A R4000 powerpoint presentation I was given last year said that it had
32 bytes of internal battery backed RAM to store security keys. I have
not used one to personally verify this though.
We previously did a job for a customer where there was a fairly large
risk of it being copied. Before loading the production code we would run
a program that in addition to performing calibration of the ADC's etc it
also loaded a key that ultimately got stored in battery backed ram and
was checked at powerup. It worked quite well. In one case one of their
units in India stopped functioning after the "curious" owners decided to
open up the unit and remove the core module :-)
-----Original Message-----
From: r... [mailto:r...]
On Behalf Of IDES
Sent: Monday, 6 November 2006 9:24 AM
To: r...
Subject: Re: [rabbit-semi] Securing code?
Does the 3000 or 4000 contain any internal EEPROM or Flash memory where
a security code can be placed?
Or do they contain any SRAM which is battery backed up, which can be
used to store security information?
Jim Ashby
Nathan Johnston wrote:
Anything can be copied. It's just a case of how much effort
needs to be put in to do it. It's not hard to stop someone cloning the
board (such as having a unlock code that is stored in battery backed
ram) but stopping someone analyzing the flash contents and removing any
copy protection (especially when the flash is external to the processor)
is very hard. You have to look at the amount of effort involved to do
the latter though. In most cases it's probably easier just to rewrite
the application :-)
-----Original Message-----
From: r...
[mailto:r...] On Behalf Of hwrd389
Sent: Saturday, 4 November 2006 7:44 AM
To: r...
Subject: [rabbit-semi] Securing code?
An interesting question came up today in a meeting. If we
release a
product on a Rabbit 3000, what's to stop someone from snarfing
our
code out of it with a Rabbit cloning cable? Is there some
read-protect
setting in the hardware that I haven't found in the
documentation?
I'm not trying to keep someone from ever writing to the flash
again,
but I do want people to not read my code.
Thanks,
Howard
Reply by np np●November 5, 20062006-11-05
I was once asked to do a project for a compnay.
They had previously used another company to do the project but they fell
out.
We were given the software but it was in assembler and had every comment
removed.
After a short while it was obvious that we had to start from scratch.
Nathan Johnston wrote:
Anything can be copied. Its just a case of how much effort needs
to be put in to do it. Its not hard to stop someone cloning the board (such as
having a unlock code that is stored in battery backed ram) but stopping someone
analyzing the flash contents and removing any copy protection (especially when
the flash is external to the processor) is very hard. You have to look at the
amount of effort involved to do the latter though. In most cases its probably
easier just to rewrite the application J
-----Original Message-----
From: r... [mailto:r...] On Behalf Of hwrd389
Sent: Saturday, 4 November 2006 7:44 AM
To: r...
Subject: [rabbit-semi] Securing code?
An interesting question came up today in a meeting. If we release a
product on a Rabbit 3000, what's to stop someone from snarfing our
code out of it with a Rabbit cloning cable? Is there some read-protect
setting in the hardware that I haven't found in the documentation?
I'm not trying to keep someone from ever writing to the flash again,
but I do want people to not read my code.
If you want to stop people copying your system just use a very cheap PIC to hold
a security code but make sure the PIC code protect bit is set.
Nathan Johnston wrote:
Anything can be copied. Its just a case of how much effort needs
to be put in to do it. Its not hard to stop someone cloning the board (such as
having a unlock code that is stored in battery backed ram) but stopping someone
analyzing the flash contents and removing any copy protection (especially when
the flash is external to the processor) is very hard. You have to look at the
amount of effort involved to do the latter though. In most cases its probably
easier just to rewrite the application J
-----Original Message-----
From: r... [mailto:r...] On Behalf Of hwrd389
Sent: Saturday, 4 November 2006 7:44 AM
To: r...
Subject: [rabbit-semi] Securing code?
An interesting question came up today in a meeting. If we release a
product on a Rabbit 3000, what's to stop someone from snarfing our
code out of it with a Rabbit cloning cable? Is there some read-protect
setting in the hardware that I haven't found in the documentation?
I'm not trying to keep someone from ever writing to the flash again,
but I do want people to not read my code.
Reply by Nathan Johnston●November 5, 20062006-11-05
Yes but again it's a case of how much someone wants to copy the system.
You could connect a logic analyzer and monitor the exchange between the
PIC and Rabbit to work out what is happening...
-----Original Message-----
From: r... [mailto:r...]
On Behalf Of np np
Sent: Monday, 6 November 2006 9:06 AM
To: r...
Subject: RE: [rabbit-semi] Securing code?
If you want to stop people copying your system just use a very cheap PIC
to hold a security code but make sure the PIC code protect bit is set.
Nathan Johnston wrote:
Anything can be copied. It's just a case of how much effort
needs to be put in to do it. It's not hard to stop someone cloning the
board (such as having a unlock code that is stored in battery backed
ram) but stopping someone analyzing the flash contents and removing any
copy protection (especially when the flash is external to the processor)
is very hard. You have to look at the amount of effort involved to do
the latter though. In most cases it's probably easier just to rewrite
the application :-)
-----Original Message-----
From: r...
[mailto:r...] On Behalf Of hwrd389
Sent: Saturday, 4 November 2006 7:44 AM
To: r...
Subject: [rabbit-semi] Securing code?
An interesting question came up today in a meeting. If we
release a
product on a Rabbit 3000, what's to stop someone from snarfing
our
code out of it with a Rabbit cloning cable? Is there some
read-protect
setting in the hardware that I haven't found in the
documentation?
I'm not trying to keep someone from ever writing to the flash
again,
but I do want people to not read my code.
Copy protection is always a hot topic. You've already received some
good answers, but I thought I'd include my two cents for good measure.
I can speak broadly about the subject, but will try to keep this
discussion relevant to the Rabbit.
To quickly answer your question: There is no way to keep someone from
copying a program running on any Rabbit 2000 or 3000 core module in
production today. After a quick reading of the Rabbit 4000 manual (I
have yet to actually use one though), it appears the same might be
true for this processor.
The extended answer:
People will be quick to point out numerous methods for obfuscating
code or making it generally difficult to copy firmware from a system
through either physical or software means. On the Rabbit 2000/3000,
all of these means can be defeated, though doing so will require
varying levels of effort. Note that their implementations require
varying levels of effort as well. So, the very first thing to do when
considering copy protection is to evaluate your market, your
competitors, and your software's value. Figure out how likely someone
is to try to copy your code and how much you think it's worth spending
to protect it. To keep this discussion somewhat applied, let's assume
that your product contains no novel algorithms that are worth the
effort of actually disassembling a flash dump and studying the
contents enough to understand and extract your routines. Just assume
that the cost of doing that is prohibitive--it would be cheaper and
simpler to re-write your application from scratch. This may not be
true if you've developed a novel image recognition algorithm or some
other intellectual property whose value is potentially higher than an
individual product's. But, let's just assume you haven't.
You're just
worried about someone cloning your hardware and software and making a
cheaper knockoff with almost no development costs to support.
So, now the task is to determine how to keep people from dumping the
flash chip on the Rabbit 2000/3000 and using it to program their own.
As I've said, the short answer is: you can't. The Rabbit uses an
external flash, which means they can always desolder it and use a
standard programmer to dump its contents. If you've taken no steps to
protect it, they simply stick a programming cable on your system and
use Dynamic C to perform the dump. Very simple, very cheap...but they
still have to clone your hardware and manufacture a product. That
effort alone will keep most people from competing. But now let's say
you have a direct competitor whom you know is not above stealing your
product. You can play tricks such as glopping epoxy over everything,
storing and checking special codes in other chips (or "dongles"), or
even somehow encrypting your code. However, each of these can be
defeated due to the fact that the darned flash is still external on
the Rabbit. Epoxy can be removed with solvents, it's quite possible to
understand a disassembly of your code enough to nop out the dongle
checks, and even if you encrypt your code, there's no secure place to
store the decryption keys--they always have to cross a bus to get to
the Rabbit 2000/3000. But, implementing one or more of these methods
may be enough to keep your competitor's reverse engineering costs high
enough that it makes more economic sense for them to develop their own
product from scratch.
When I first skimmed through the Rabbit 4000 and saw the 32-bytes of
internal, battery backed encryption-RAM, I thought that this processor
might be a step in the right direction as far as industry-standard
copy protection is concerned--that is, copy protection that relies on
state-of-the-art encryption algorithms instead of "tricks" and is
inherently cost-prohibitive to reverse engineer for most applications.
The Rabbit 4000 offers a place to store stuff that doesn't have to
cross an external bus to get to the processor. In theory, you could
use an industry-accepted strong encryption algorithm to encrypt your
program and burn that along with a small, unencrypted loader program
into flash. The loader would be the first to execute and would place
itself in RAM. It would use the internally-stored keys to decrypt the
flash into RAM on the fly. This prevents unencrypted bytes or
sensitive keys from crossing any external busses. Those in the know
will point out that even internal busses can be snooped and chips can
be X-ray-d and whatnot; however those methods can be incredibly
expensive and very few algorithms would be worth the cost of using
them to retrieve. So this seems good. And the Rabbit 4000 even wipes
out this encryption-RAM if the SMODE pins are changed...which means
you can't use a Rabbit programming cable to download a quick little
program that will read the contents of that RAM and spit them out for
you. However, there's still the darned external flash. It seems like
you could (even with power applied to the board to back up that
internal RAM) desolder the flash and replace it with your own program
to retrieve the contents of encryption-RAM. You can even hold the chip
in reset while you do this. Please, please let me know if I missed
something in the Rabbit docs that precludes this method, but I'm
pretty sure it would work. I could think of several ways to thwart
this hack that involve code signing, but we'll probably have to wait
for the Rabbit 5000 or 6000 for that. Of course, you might wish to use
the Rabbit 4000's built-in place simply to store a number your code
could check upon boot up. I'm pretty certain it's not "secure" so
it's
probably not worth the development cost of actually encrypting your
code, but as I've discussed, just performing a simple check on this
internally-stored number (perhaps in combination with other
obfuscations) may be enough protection for many applications.
So, for those of you developing algorithms to factor very large
numbers in linear time, don't implement them on the Rabbit. Uhh...in
fact, if you're really factoring VLNs in linear time, don't ever
release a product at all. But, the rest of us whose products are more
likely integration projects than valuable, scientific, intellectual
property should make a moderate attempt to protect our code if we
think it's worth the investment. If you think your code warrants more
security than a moderate attempt on the Rabbit can provide, use a
different processor.
--Jerry
Jerry Ryle, Product Engineer
MindTribe Product Engineering - Engineering Moxie
119 University Ave., Palo Alto, CA 94301
Tel: 650.324.9432 x106
Fax: 650.324.9438 http://www.mindtribe.com/
Reply by IDES●November 5, 20062006-11-05
That is why it is best to keep the security data exchange internal to
the MPU.
Using one program to set the security code, and another program to load
the main program.
The security code could be as simple as an 8 bit char to XOR with a
block of memory which contains ascii data or lookup tables.
The conversion is done once during the startup/setup process.
This method is especially useful when applied to lookup tables, and ISR
jump tables.
I have used this process in the past.
But as said before, it all depends how badly you want to reverse
engineer a system, and how far you will go to do it.
It would be nice if Rabbit would add rotating code, hardware registers
to encrypt the contents of the external flash device based on a
segmented block format.
Then when a person reads the Flash device, they will get rotating
blocks of varying encoded data..
Making the flash data harder to decode.
In this hardware method, the hacker sees lots of encoded data, which
makes absolutely no sense at all.
Just copying the flash into another core module is useless, and results
in a core which will not operate.
You need the rotating code set and block size to be able to run the
code.
I have used this method in the past using an MPU IP coded into a Xilinx
FPGA device with external Battery Backed SRAM.
The agency which tested the encoding method took 8 months to attempt to
retrieve the memory code without success.
This method can be made very complex or very simple, but it is all
based on hardware, and results in a three MPU clock cycle delay reading
the FIRST program memory address, after which the system will run at
full speed.
This is a real time decoding method and is very reliable and secure.
This system was used to secure the programing of a voice and data
encryption device for law enforcement agencies.
But as said before, it all depends how badly you want to reverse
engineer a system, and how far you will go to do it.
Jim C. Ashby
III
ZWorld/Rabbit Semiconductors
Authorized Developer
IDE Solutions,
Inc.
Invention to
Prototyping
Service
715 Reynolds
Road
Printed Circuit Board
Design Service (Analog, Digital & RF)
Nathan Johnston wrote:
Yes but again its a case of how much someone wants to copy the
system. You could connect a logic analyzer and monitor the exchange between the
PIC and Rabbit to work out what is happening
-----Original Message-----
From: r... [mailto:r...] On Behalf Of np np
Sent: Monday, 6 November 2006 9:06 AM
To: r...
Subject: RE: [rabbit-semi] Securing code?
If you want to stop people copying your system just use a very cheap
PIC to hold a security code but make sure the PIC code protect bit is set.
Nathan Johnston wrote:
Anything can be copied. Its just a case of how much effort needs to
be put in to do it. Its not hard to stop someone cloning the board (such as
having a unlock code that is stored in battery backed ram) but stopping someone
analyzing the flash contents and removing any copy protection (especially when
the flash is external to the processor) is very hard. You have to look at the
amount of effort involved to do the latter though. In most cases its probably
easier just to rewrite the application J
-----Original Message-----
From: r... [mailto:r...] On Behalf Of hwrd389
Sent: Saturday, 4 November 2006 7:44 AM
To: r...
Subject: [rabbit-semi] Securing code?
An interesting question came up today in a meeting. If we release a
product on a Rabbit 3000, what's to stop someone from snarfing our
code out of it with a Rabbit cloning cable? Is there some read-protect
setting in the hardware that I haven't found in the documentation?
I'm not trying to keep someone from ever writing to the flash again,
but I do want people to not read my code.
---------------------------------
The all-new Yahoo! Mail goes wherever you go - free your email address from
your Internet provider.
Reply by Nathan Johnston●November 6, 20062006-11-06
...but then if you analyse enough occurrences you will work out the
sequence.
I think Jerry best said what I was trying to say originally. It's
impossible to make it copy proof but for most applications you can make
it hard enough for them not to bother...
-----Original Message-----
From: r... [mailto:r...]
On Behalf Of np np
Sent: Monday, 6 November 2006 12:39 PM
To: r...
Subject: RE: [rabbit-semi] Securing code?
Not if you make it a number sequence !
Nathan Johnston wrote:
Yes but again it's a case of how much someone wants to copy the
system. You could connect a logic analyzer and monitor the exchange
between the PIC and Rabbit to work out what is happening...
-----Original Message-----
From: r...
[mailto:r...] On Behalf Of np np
Sent: Monday, 6 November 2006 9:06 AM
To: r...
Subject: RE: [rabbit-semi] Securing code?
If you want to stop people copying your system just use a very
cheap PIC to hold a security code but make sure the PIC code protect bit
is set.
Nathan Johnston wrote:
Anything can be copied. It's just a case of how much
effort needs to be put in to do it. It's not hard to stop someone
cloning the board (such as having a unlock code that is stored in
battery backed ram) but stopping someone analyzing the flash contents
and removing any copy protection (especially when the flash is external
to the processor) is very hard. You have to look at the amount of effort
involved to do the latter though. In most cases it's probably easier
just to rewrite the application :-)
-----Original Message-----
From: r...
[mailto:r...] On Behalf Of hwrd389
Sent: Saturday, 4 November 2006 7:44 AM
To: r...
Subject: [rabbit-semi] Securing code?
An interesting question came up today in a meeting. If
we release a
product on a Rabbit 3000, what's to stop someone from
snarfing our
code out of it with a Rabbit cloning cable? Is there
some read-protect
setting in the hardware that I haven't found in the
documentation?
I'm not trying to keep someone from ever writing to the
flash again,
but I do want people to not read my code.
The all-new Yahoo! Mail
/*http:/us.rd.yahoo.com/evt@565/*http:/uk.docs.yahoo.com/nowyoucan.htm
l> goes wherever you go - free your email address from your Internet
provider.
Reply by IDES●November 6, 20062006-11-06
That is right np np.
The block would contain a sequence of codes the length of the encoded
block, and this sequences can change from block to block based on a
sequencer sequence of code.
It is all accomplished in hardware totally transparent to the MPU
reading the Program memory.
I do not want to disclose any more information about this secure
encoding method, so you all talk it over and have fun with it.
I might disclose something which I am under non-disclosure not to
disclose, thus far I am OK.
style="font-size: 10pt; color: navy; font-family: Arial;">Yes but
again it’s a case of how much someone wants to copy the system. You
could connect a logic analyzer and monitor the exchange between the PIC
and Rabbit to work out what is happening…
From:
rabbit-semi@yahoogroups.com
[mailto:rabbit-semi@yahoogroups.com]
style="font-weight: bold;">On Behalf Of np np
Sent: Monday, 6
November 2006 9:06 AM
To:
rabbit-semi@yahoogroups.com
Subject: RE:
[rabbit-semi] Securing code?
style="font-size: 12pt;">
style="font-size: 12pt;">If you want to stop people copying your
system just use a very cheap PIC to hold a security code but make sure
the PIC code protect bit is set.
style="font-size: 10pt; color: navy; font-family: Arial;">Anything can
be copied. It’s just a case of how much effort needs to be put in to do
it. It’s not hard to stop someone cloning the board (such as having a
unlock code that is stored in battery backed ram) but stopping someone
analyzing the flash contents and removing any copy protection
(especially when the flash is external to the processor) is very hard.
You have to look at the amount of effort involved to do the latter
though. In most cases it’s probably easier just to rewrite the
application
style="font-size: 10pt; color: navy; font-family:
Wingdings;">J
