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 Start a New Thread

There is a define in the bios u can move around to prevent cloning. I think
there's also something preventing cloning a clone or something like that.

> -----Original Message-----
> From: r...
> [mailto:r...] On Behalf Of hwrd389
> Sent: Friday, November 03, 2006 12:44 PM
> 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 Start a New Thread

hwrd389 wrote:
> 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
>
Anyone with a copy of DC can dump the flash to a .bin file. There is now
way around it

------
| 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" Start a New Thread

Ahhhhhh.... The wonderfull world of Copy Protection...

You could look at the whole 'dongle' angle where as you have some
coded piece of hardware in your design and a coded binary that looks
for the hardware to match it before it runs.

I guess it all depends on how much you want to put into it versus
the real risk of someone copying your .bin files to another RCM.

Dan...
On 11/3/06, Scott Henion wrote:
>
> hwrd389 wrote:
> > 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
> >
> Anyone with a copy of DC can dump the flash to a .bin file. There is now
> way around it
>
> ------
> | 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"
>
>
> Start a New Thread

Scott-

Thanks for confirming that. I've been through the Rabbit 4000 docs
too, and it looks like the 4000 won't do it either. Our CFO is
concerned about people cloning our device, and his biggest concern is
someone figuring out the serial protocol for our cool peripheral. He
was crushed when I told him that serial data analyzers are pretty good
and easy to come by, and I showed him the DataBoy I have that someone
made out of a GameBoy Color. I think protecting the code would make
him feel better, but even that can't happen. :(

Howard

--- In r..., Scott Henion wrote:
>
> hwrd389 wrote:
> > 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
> >
> Anyone with a copy of DC can dump the flash to a .bin file. There is now
> way around it
>
> ------
> | Scott G. Henion| shenion@... |
> | 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"
> Start a New Thread

We could pop a dongle on the board, but I'm not sure it's worth it.
Our code features a website that has our logo rather prominently
displayed. If someone is going to clone the thing, they'll have to
neuter enough code to kill off our logo. While they're doing that, it
wouldn't talke much to kill off the dongle code. Dallas and others
make some pretty nice random security chips though.

The guy had two concerns- one was someone copying the code out of the
ROM and the other was someone reverse engineerig the serial protocol
to our device peripheral. I don't think we can stop either.

Howard

--- In r..., "Dan Allen" wrote:
>
> Ahhhhhh.... The wonderfull world of Copy Protection...
>
> You could look at the whole 'dongle' angle where as you have some
> coded piece of hardware in your design and a coded binary that looks
> for the hardware to match it before it runs.
>
> I guess it all depends on how much you want to put into it versus
> the real risk of someone copying your .bin files to another RCM.
>
> Dan...
> On 11/3/06, Scott Henion wrote:
> >
> > hwrd389 wrote:
> > > 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
> > >
> > Anyone with a copy of DC can dump the flash to a .bin file. There
is now
> > way around it
> >
> > ------
> > | Scott G. Henion| shenion@... |
> > | 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"
> >
> >
> Start a New Thread

No you can't stop either... So you take the Micro$oft route... you
ignore it till it becomes a problem and the sue who ever did it... :-
).. Oh and make sure you talk to Intel about how well that worked
against AMD... :-)

Quite honestly now you see half the reason for creating 'new'
versions that are incompatible with the old ones.. you just have to
keep your ball moving forward so fast that reverse engineering isn't
worth the trouble... and as said previously, sue the cloners....

Good luck...

--.- Dave
--- In r..., "hwrd389" wrote:
>
> We could pop a dongle on the board, but I'm not sure it's worth it.
> Our code features a website that has our logo rather prominently
> displayed. If someone is going to clone the thing, they'll have to
> neuter enough code to kill off our logo. While they're doing that,
it
> wouldn't talke much to kill off the dongle code. Dallas and others
> make some pretty nice random security chips though.
>
> The guy had two concerns- one was someone copying the code out of
the
> ROM and the other was someone reverse engineerig the serial
protocol
> to our device peripheral. I don't think we can stop either.
>
> Howard
>
> --- In r..., "Dan Allen"
wrote:
> >
> > Ahhhhhh.... The wonderfull world of Copy Protection...
> >
> > You could look at the whole 'dongle' angle where as you have some
> > coded piece of hardware in your design and a coded binary that
looks
> > for the hardware to match it before it runs.
> >
> > I guess it all depends on how much you want to put into it versus
> > the real risk of someone copying your .bin files to another RCM.
> >
> >
> >
> > Dan...
> >
> >
> > On 11/3/06, Scott Henion wrote:
> > >
> > > hwrd389 wrote:
> > > > 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
> > > >
> > > Anyone with a copy of DC can dump the flash to a .bin file.
There
> is now
> > > way around it Start a New Thread

And I always thought the Microsoft route was to make products that
perform so poorly that no one wants to clone them.

Seems like an effective strategy to me.

Howard

--- In r..., "Dave August" wrote:
>
> No you can't stop either... So you take the Micro$oft route... you
> ignore it till it becomes a problem and the sue who ever did it... :-
> ).. Oh and make sure you talk to Intel about how well that worked
> against AMD... :-)
>
> Quite honestly now you see half the reason for creating 'new'
> versions that are incompatible with the old ones.. you just have to
> keep your ball moving forward so fast that reverse engineering isn't
> worth the trouble... and as said previously, sue the cloners....
>
> Good luck...
>
> --.- Dave
> --- In r..., "hwrd389" wrote:
> >
> > We could pop a dongle on the board, but I'm not sure it's worth it.
> > Our code features a website that has our logo rather prominently
> > displayed. If someone is going to clone the thing, they'll have to
> > neuter enough code to kill off our logo. While they're doing that,
> it
> > wouldn't talke much to kill off the dongle code. Dallas and others
> > make some pretty nice random security chips though.
> >
> > The guy had two concerns- one was someone copying the code out of
> the
> > ROM and the other was someone reverse engineerig the serial
> protocol
> > to our device peripheral. I don't think we can stop either.
> >
> > Howard
> >
> > --- In r..., "Dan Allen"
> wrote:
> > >
> > > Ahhhhhh.... The wonderfull world of Copy Protection...
> > >
> > > You could look at the whole 'dongle' angle where as you have some
> > > coded piece of hardware in your design and a coded binary that
> looks
> > > for the hardware to match it before it runs.
> > >
> > > I guess it all depends on how much you want to put into it versus
> > > the real risk of someone copying your .bin files to another RCM.
> > >
> > >
> > >
> > > Dan...
> > >
> > >
> > > On 11/3/06, Scott Henion wrote:
> > > >
> > > > hwrd389 wrote:
> > > > > 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
> > > > >
> > > > Anyone with a copy of DC can dump the flash to a .bin file.
> There
> > is now
> > > > way around it
> Start a New Thread

Thanks for the laugh, I have been coding 18 hour days 7 days a week,
and I really needed it.



I am glad that we do not find the need to reboot the rabbit modules
every 48 hours to keep the buffers clear, like MS-XP-Home.



JIMA





hwrd389 wrote:

And I always thought the Microsoft route was to make products that

perform so poorly that no one wants to clone them.



Seems like an effective strategy to me.



Howard



--- In rabbit-semi@yahoogroups.com,
"Dave August" <august@...> wrote:

>

> No you can't stop either... So you take the Micro$oft route... you


> ignore it till it becomes a problem and the sue who ever did it...
:-

> ).. Oh and make sure you talk to Intel about how well that worked

> against AMD... :-)

>

> Quite honestly now you see half the reason for creating 'new'

> versions that are incompatible with the old ones.. you just have
to

> keep your ball moving forward so fast that reverse engineering
isn't

> worth the trouble... and as said previously, sue the cloners....

>

> Good luck...

>

> --.- Dave

>

>

> --- In rabbit-semi@yahoogroups.com,
"hwrd389" <hwrd389@> wrote:

> >

> > We could pop a dongle on the board, but I'm not sure it's
worth it.

> > Our code features a website that has our logo rather
prominently

> > displayed. If someone is going to clone the thing, they'll
have to

> > neuter enough code to kill off our logo. While they're doing
that,

> it

> > wouldn't talke much to kill off the dongle code. Dallas and
others

> > make some pretty nice random security chips though.

> >

> > The guy had two concerns- one was someone copying the code
out of

> the

> > ROM and the other was someone reverse engineerig the serial

> protocol

> > to our device peripheral. I don't think we can stop either.

> >

> > Howard

> >

> > --- In rabbit-semi@yahoogroups.com,
"Dan Allen" <MaeSoftGroup@>

> wrote:

> > >

> > > Ahhhhhh.... The wonderfull world of Copy Protection...

> > >

> > > You could look at the whole 'dongle' angle where as you
have some

> > > coded piece of hardware in your design and a coded
binary that

> looks

> > > for the hardware to match it before it runs.

> > >

> > > I guess it all depends on how much you want to put into
it versus

> > > the real risk of someone copying your .bin files to
another RCM.

> > >

> > >

> > >

> > > Dan...

> > >

> > >

> > > On 11/3/06, Scott Henion <shenion@> wrote:

> > > >

> > > > hwrd389 wrote:

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

> > > > >

> > > > Anyone with a copy of DC can dump the flash to a
.bin file.

> There

> > is now

> > > > way around it

>

__._,_.___

Rabbit	Microprocessor architecture	Microcontrollers
Embedded module

__,_._,___
Start a New Thread

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 Start a New Thread