Securing code?

Not if the code constantly changes.

A technique is to use a pseudo random number.

I have also seen a PIC put onto address lines and if the code is accessed sequentially for too long the PIC scrambles the addresses to confuse anyone reading the flash device. This was used on a chipped car ECU.

IDES wrote:
Still the exchange of data opens up the possibility of hacking and bypassing if you program another PIC to look for the original code and respond properly.

Think again.

The ultimate solution is to have all of the security one a single slice of silicon.

If you come up with a solutions in which you believe that it can not be broken, then send it to me and for a fee I will break the system and send you a duplicate system.
It will cost you!

Security keeps the honest people honest, but good security keeps the crooks out!

JIMA

np np wrote: You can use OTP parts, they are very cheap.

The PIC and rabbit talk to each other.
The rabbit polls the PIC and the PIC sends it a number.
The rabbit does a calculation on the number and replies with the answer to the PIC.
If the answer is wrong the PIC hangs stopping the rabbit from continuing.
The PIC could even hold the rabbit in reset.

IDES wrote:
The "security bit" on the PIC with flash is not a secure way to protect the program memory data.

Only the older OTP devices can be secure, if the developer has zeroed all of the unused memory locations to prevent the user from over laping a dump program.

But you still have a problem with the electrical link which exist between the PIC and the Core module which can be hacked.

The solution is to have Rabbit add the hardware encryption module internally to the Rabbit MPU, and to the Compiler.

It would not be that big a deal if done properly, and then Rabbit can sell the MPUs to DOD contracts.

JIMA

Scott Henion wrote: jmsardon01 wrote:
> I'm thinking that a single technique can be use the MAC address if you
> have a Rabbit Board with Ethernet. Every you compile, you can put a
> define with the MAC address, then in the program read the MAC and
> compare. Also you can 'obscure' the data to make more difficult to
> decrypt.
> If you don't produce much units it can be a useful technique, but
> not very very secure. I think, as another people in this list, that
> all encryption are vulnerable if you make the sufficient effort.
>
That will not work as the MAC is also stored in th flash. You can still
copy the entire flash. You would have a board with the same MAC address.

I like the idea of a PIC processor programmed to match the MAC and also
has its security bit set so it can not be copied.

------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
Having nothing, nothing can he lose.
-- William Shakespeare, "Henry VI"

Send instant messages to your online friends http://uk.messenger.yahoo.com

---------------------------------
All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. Start a New Thread

Still this method is a hackers dream, as is proof by the number of ECU
programmers and access interface devices on the market.



If this method is so good the system would not have been hacked by so
many.



Still it is a good idea to keep the honest people honest.



JIMA



np np wrote:

cite="m...@web27410.mail.ukl.yahoo.com"
type="cite">





__._,_.___

Rabbit	Microprocessor architecture	Microcontrollers
Embedded module

__,_._,___
Start a New Thread

This is just my point, the system was not hackable without a great deal of effort.
I suspect 99% would have given up. Who has a random address reader for a flash part rather than serial address reader?

I have hacked an addon that goes on the diagnostics port on a Ford Escort Cosworth.
It turned out in the end to be an ASIC and an eprom.
The ASIC gave parallel and serial access to the EPROM.
Just to make it even more complicated it had 2 16 bit counters inside as well seperately selectable.
It took 2 attempts to get the ASIC right but we got there in the end.

IDES wrote:
Still this method is a hackers dream, as is proof by the number of ECU programmers and access interface devices on the market.

If this method is so good the system would not have been hacked by so many.

Still it is a good idea to keep the honest people honest.

JIMA

np np wrote: Not if the code constantly changes.

A technique is to use a pseudo random number.

I have also seen a PIC put onto address lines and if the code is accessed sequentially for too long the PIC scrambles the addresses to confuse anyone reading the flash device. This was used on a chipped car ECU.

IDES wrote:
Still the exchange of data opens up the possibility of hacking and bypassing if you program another PIC to look for the original code and respond properly.

Think again.

The ultimate solution is to have all of the security one a single slice of silicon.

If you come up with a solutions in which you believe that it can not be broken, then send it to me and for a fee I will break the system and send you a duplicate system.
It will cost you!

Security keeps the honest people honest, but good security keeps the crooks out!

JIMA

np np wrote: You can use OTP parts, they are very cheap.

The PIC and rabbit talk to each other.
The rabbit polls the PIC and the PIC sends it a number.
The rabbit does a calculation on the number and replies with the answer to the PIC.
If the answer is wrong the PIC hangs stopping the rabbit from continuing.
The PIC could even hold the rabbit in reset.

IDES wrote:
The "security bit" on the PIC with flash is not a secure way to protect the program memory data.

Only the older OTP devices can be secure, if the developer has zeroed all of the unused memory locations to prevent the user from over laping a dump program.

But you still have a problem with the electrical link which exist between the PIC and the Core module which can be hacked.

The solution is to have Rabbit add the hardware encryption module internally to the Rabbit MPU, and to the Compiler.

It would not be that big a deal if done properly, and then Rabbit can sell the MPUs to DOD contracts.

JIMA

Scott Henion wrote: jmsardon01 wrote:
> I'm thinking that a single technique can be use the MAC address if you
> have a Rabbit Board with Ethernet. Every you compile, you can put a
> define with the MAC address, then in the program read the MAC and
> compare. Also you can 'obscure' the data to make more difficult to
> decrypt.
> If you don't produce much units it can be a useful technique, but
> not very very secure. I think, as another people in this list, that
> all encryption are vulnerable if you make the sufficient effort.
>
That will not work as the MAC is also stored in th flash. You can still
copy the entire flash. You would have a board with the same MAC address.

I like the idea of a PIC processor programmed to match the MAC and also
has its security bit set so it can not be copied.

------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
Having nothing, nothing can he lose.
-- William Shakespeare, "Henry VI"

Send instant messages to your online friends http://uk.messenger.yahoo.com

---------------------------------
All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you.

Send instant messages to your online friends http://uk.messenger.yahoo.com Start a New Thread

As stated before, it all depends on how far you are willing to go!



JIMA



np np wrote:

cite="m...@web27409.mail.ukl.yahoo.com"
type="cite">





__._,_.___

Rabbit	Microprocessor architecture	Microcontrollers
Embedded module

__,_._,___
Start a New Thread

IDES wrote:
>
> As stated before, it all depends on how far you are willing to go!
>
> JIMA
>
> np np wrote:
>
>> This is just my point, the system was not hackable without a great
>> deal of effort.
>> I suspect 99% would have given up. Who has a random address reader
>> for a flash part rather than serial address reader?
>> I have hacked an addon that goes on the diagnostics port on a Ford
>> Escort Cosworth.
>> It turned out in the end to be an ASIC and an eprom.
>> The ASIC gave parallel and serial access to the EPROM.
>> Just to make it even more complicated it had 2 16 bit counters inside
>> as well seperately selectable.
>> It took 2 attempts to get the ASIC right but we got there in the end.
>> */IDES /* wrote:
>>
>> Still this method is a hackers dream, as is proof by the number
>> of ECU programmers and access interface devices on the market.
>>
>> If this method is so good the system would not have been hacked
>> by so many.
>>
>> Still it is a good idea to keep the honest people honest.
>>
>> JIMA
>>
>> np np wrote:
>>> Not if the code constantly changes.
>>> A technique is to use a pseudo random number.
>>> I have also seen a PIC put onto address lines and if the code is
>>> accessed sequentially for too long the PIC scrambles the
>>> addresses to confuse anyone reading the flash device. This was
>>> used on a chipped car ECU.
>>>
>>>
>>> */IDES /* wrote:
>>>
>>> Still the exchange of data opens up the possibility of
>>> hacking and bypassing if you program another PIC to look for
>>> the original code and respond properly.
>>>
>>> Think again.
>>>
>>> The ultimate solution is to have all of the security one a
>>> single slice of silicon.
>>>
>>> If you come up with a solutions in which you believe that it
>>> can not be broken, then send it to me and for a fee I will
>>> break the system and send you a duplicate system.
>>> It will cost you!
>>>
>>> Security keeps the honest people honest, but good security
>>> keeps the crooks out!
>>>
>>> JIMA
>>>
>>> np np wrote:
>>>> You can use OTP parts, they are very cheap.
>>>> The PIC and rabbit talk to each other.
>>>> The rabbit polls the PIC and the PIC sends it a number.
>>>> The rabbit does a calculation on the number and replies
>>>> with the answer to the PIC.
>>>> If the answer is wrong the PIC hangs stopping the rabbit
>>>> from continuing.
>>>> The PIC could even hold the rabbit in reset.
>>>>
>>>>
>>>> */IDES /* wrote:
>>>>
>>>> The "security bit" on the PIC with flash is not a
>>>> secure way to protect the program memory data.
>>>>
>>>> Only the older OTP devices can be secure, if the
>>>> developer has zeroed all of the unused memory locations
>>>> to prevent the user from over laping a dump program.
>>>>
>>>> But you still have a problem with the electrical link
>>>> which exist between the PIC and the Core module which
>>>> can be hacked.
>>>>
>>>> The solution is to have Rabbit add the hardware
>>>> encryption module internally to the Rabbit MPU, and to
>>>> the Compiler.
>>>>
>>>> It would not be that big a deal if done properly, and
>>>> then Rabbit can sell the MPUs to DOD contracts.
>>>>
>>>> JIMA
>>>>
>>>> Scott Henion wrote:
>>>>> jmsardon01 wrote:
>>>>> > I'm thinking that a single technique can be use the
>>>>> MAC address if you
>>>>> > have a Rabbit Board with Ethernet. Every you
>>>>> compile, you can put a
>>>>> > define with the MAC address, then in the program
>>>>> read the MAC and
>>>>> > compare. Also you can 'obscure' the data to make
>>>>> more difficult to
>>>>> > decrypt.
>>>>> > If you don't produce much units it can be a useful
>>>>> technique, but
>>>>> > not very very secure. I think, as another people in
>>>>> this list, that
>>>>> > all encryption are vulnerable if you make the
>>>>> sufficient effort.
>>>>> >
>>>>> That will not work as the MAC is also stored in th
>>>>> flash. You can still
>>>>> copy the entire flash. You would have a board with the
>>>>> same MAC address.
>>>>>
>>>>> I like the idea of a PIC processor programmed to match
>>>>> the MAC and also
>>>>> has its security bit set so it can not be copied.
>>>>>
>>>>> ------
>>>>> | Scott G. Henion| s...@shdesigns.org
>>>>> |
>>>>> | Consultant | Stone Mountain, GA |
>>>>> | SHDesigns http://www.shdesigns.org
>>>>> |
>>>>> ------
>>>>> Rabbit libs: http://www.shdesigns.org/rabbit/
>>>>>
>>>>> today's fortune
>>>>> Having nothing, nothing can he lose.
>>>>> -- William Shakespeare, "Henry VI"
>>>>>
>>>>
>>>> Send instant messages to your online friends
>>>> http://uk.messenger.yahoo.com
>>>
>>>
>>>
>>> All New Yahoo! Mail
>>>
>>> Tired of Vi@gr@! come-ons? Let our SpamGuard protect you.
>> Send instant messages to your online friends
>> http://uk.messenger.yahoo.com
>>
>
Hi

Just to add my two cents..
I designed a custom board with the Rabbit on it. On the board I used two
CPLDs.
Thereafter there was no point in hacking my code as it ran on custom
hardware.

Ended up with people copying my idea but having to develop their own
hardware. At least this forced them to go through the hardware and
software development cycle too.

Alexis Start a New Thread

Jerry-

Yes, many of the suggestions have been excellent. The problem I can
see with some of them is they require a hardware dongle as protection
against running pirated copies (someone who reverse engineers the code
is just going to pull that section out) or the dongle provides an
encryption key (someone looking at the code will see how that works
and snag the code anyway). I do that sort of thing from time to time
as a technical expert in legal cases, so I do know how it's done and
I'm pretty good at it. Others are better at it, I'm sure.

Anyway, using the internal storage in the Rabbit 4000 may be our best
bet for a future product. I'm not exactly sure how yet. We do plan to
use Scott Henion's DLM, and if we add a little encyrption based on the
key in this 32 byte area, that would give us a little anti-copying
security. As you point out though, physical access to the data in a
simple system such as this is a recipe for copying. The only way is to
have something like the security fuse or bit in the Microchip and
Cypress processors, or the security code scheme used in the Motorola
chips.

The current system in test is based on a BL2600 board which uses a
3200 processor. We need the programming pins to program it ourselves,
so even something as simple as removing those to annoy hackers
wouldn't work. When we redo the system and do the board ourselves, we
were planning on replacing that connector with a nonstandard one which
would slow down a few people here and there.

So it seems that the answer for now is there is no way of securing
anything. There is certainly some IP in the code, but the bigger
concern is that we communicate with a serial device that has a
proprietary protocol. We don't want anyone to know the details of that
but it's a 9600bps standard async device. One of the company execs
asked me if there was any way at all of getting that protocol out of
the code. When I explained to him that you didn't need the code - a
data anaylzer would let you monitor the communication and watch the
protocol - he was stunned and a little unhappy. That may be our bigger
problem anyway.

As for cloning the entire machine, you have to build it and that would
take some doing.

I agree with you. Based on what I believed to be true and what's been
confirmed here, if you want you code to be hacker-resistant, don't use
a Rabbit.

Thanks,

Howard

--- In r..., "Space Cat" wrote:
>
> Howard,
>
> 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/
> Start a New Thread

Juan-

I've done something similar in the past, but it makes it difficult to
handle production. The production guys aren't going to want to
manually compile the code for each board.

Thanks,

Howard

--- In r..., "jmsardon01" wrote:
>
> I'm thinking that a single technique can be use the MAC address if you
> have a Rabbit Board with Ethernet. Every you compile, you can put a
> define with the MAC address, then in the program read the MAC and
> compare. Also you can 'obscure' the data to make more difficult to
> decrypt.
> If you don't produce much units it can be a useful technique, but
> not very very secure. I think, as another people in this list, that
> all encryption are vulnerable if you make the sufficient effort.
>
>
> Juan M. Sard
> Ponis SA.
> www.ponis.com.ar
> jmsardon@...
>



Start a New Thread

"The solution is to have Rabbit add the hardware encryption module
internally to the Rabbit MPU, and to the Compiler.

It would not be that big a deal if done properly, and then Rabbit can
sell the MPUs to DOD contracts."

Jim-

I had spoken with a manufacturer using Rabbits in a military device,
and their solution (they had two, actually) was to have the Rabbit
self-destruct if the case opened. One approach was a spring- or
gunpowder-powered hammer that smashed the chip if you opened the case.
The other approach was the board charged up a 1000 volt capacitor
which discharged into the board if you opened the case.

We're not going to do either, but it seems there are DoD-approved
methods of using Rabbits. I can just imagine the tech support calls
we'd get.

"Uh, hi, tech support? My nifty new thing i just bought from you made
a loud banging noise and sparks flew out. Is that bad? I tried
rebooting it but it didn't work."

Howard Start a New Thread

LOL Howard!



JIMA



hwrd389 wrote:

"The solution is to have Rabbit add the hardware encryption module

internally to the Rabbit MPU, and to the Compiler.



It would not be that big a deal if done properly, and then Rabbit can

sell the MPUs to DOD contracts."



Jim-



I had spoken with a manufacturer using Rabbits in a military device,

and their solution (they had two, actually) was to have the Rabbit

self-destruct if the case opened. One approach was a spring- or

gunpowder-powered hammer that smashed the chip if you opened the case.

The other approach was the board charged up a 1000 volt capacitor

which discharged into the board if you opened the case.



We're not going to do either, but it seems there are DoD-approved

methods of using Rabbits. I can just imagine the tech support calls

we'd get.



"Uh, hi, tech support? My nifty new thing i just bought from you made

a loud banging noise and sparks flew out. Is that bad? I tried

rebooting it but it didn't work."



Howard

__._,_.___

Rabbit	Microprocessor architecture	Microcontrollers
Embedded module

__,_._,___
Start a New Thread

Nathan,

Doesn't taking this approach mean that if the module runs out of
battery it would stop working? The variable containing the key would
get a random value after the battery is removed or runs out, I imagine.

--- In r..., "Nathan Johnston"
wrote:
>
> 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 :-) Start a New Thread