I'm looking for a way to fix a
variables memory
location between programs. As a means of copy protection I want to store a
value in SRAM using a setup/calibration program, then have the main (separate)
program read this value and checking its valid.
I have thought of a couple of
methods but both have there
draw backs:
-Doing a memory dump and finding a
memory location in upper XMEM and hard coding the xmem2root/root2xmem to use
this location. The program here is that there is no "protection"
that a later software change may require more xmem
and use (overwrite) this space.
-Do anxalloc in the main program and recording the memory
location it allocated. Then hardcode this value in the setup program to write
to it. At least this way the memory location is "protected", but
means that potentially the setup software needs to get updated each time the
main program is updated.
Can anyone think of a smarter way of
doing this? The userblock is not an option in this
case because it uses flash.
Thanks in
advance,
Nathan
Nathan
Johnston
Engineer
Dominion Electronics Pty
Ltd
Tel: 02 9906
6988
Fax: 02 9906
7145
www.dominion.net.au
Reply by Tom C. Barker●March 4, 20042004-03-04
You might want to try this in your bios for a non-separate i&d
program.
int myNonPersistentInt;
#rvarorg myPersistentRootData apply
int myPersistentInt;
#rvarorg rootdata resume
int myNextNonPersistentInt;
And to test from compile to compile, you could use the
following or a warns, etc.
if(&myPersistentInt != ROOTDATAORG [I think] )
printf("myPersistentInt is not persistent!\r\n");
I hear there was an off-by-one bug in DC for this directive so give yourself
some padding to compensate for the bug fix.
Tom
-----Original Message-----
From: Nathan Johnston [mailto:nathanj@nath...]
Sent: Thursday, March 04, 2004 2:38 PM
To: 'rabbit-semi@'rab...'
Subject: [rabbit-semi] Forcing variables to fixed memory locations between
programs
I'm looking for a way to fix a variables memory location between
programs.
As a means of copy protection I want to store a value in SRAM using a
setup/calibration program, then have the main (separate) program read this
value and checking its valid.
I have thought of a couple of methods but both have there draw backs:
- Doing a memory dump and finding a memory location in upper XMEM
and hard coding the xmem2root/root2xmem to use this location. The program
here is that there is no "protection" that a later software change
may
require more xmem and use (overwrite) this space.
- Do an xalloc in the main program and recording the memory
location it allocated. Then hardcode this value in the setup program to
write to it. At least this way the memory location is "protected", but
means
that potentially the setup software needs to get updated each time the main
program is updated.
Can anyone think of a smarter way of doing this? The userblock is not an
option in this case because it uses flash.
Thanks for the reply. May I ask why it
would only work for non-separate i&d space
programs? I must admit I don't know much about separate i&d, but was forced into enabling it to get this
program (a port from a sloppy z180 program) to work.
Nathan
-----Original Message----- From: Tom C. Barker
[mailto:t...@qualstar.com] Sent: Friday, 5 March 2004 10:14
AM To:
'r...@yahoogroups.com' Subject: RE: [rabbit-semi] Forcing
variables to fixed memory locations bet ween programs
You might want to try this in
your bios for a non-separate i&d program.
int myNonPersistentInt; #rvarorg myPersistentRootData apply int myPersistentInt; #rvarorg rootdata resume int myNextNonPersistentInt;
And to test from compile to compile, you could use
the following or a warns, etc.
if(&myPersistentInt != ROOTDATAORG [I think] )
printf("myPersistentInt is not
persistent!\r\n");I hear there was an off-by-one bug in DC for this
directive so give yourself
some padding to compensate for the bug
fix.
Tom -----Original Message----- From: Nathan Johnston
[mailto:n...@dominion.net.au] Sent: Thursday, March 04, 2004 2:38
PM To: 'r...@yahoogroups.com' Subject: [rabbit-semi] Forcing variables to fixed
memory locations between programsI'm looking for a way to fix a variables
memory
location between programs. As a means of copy protection I want to store a
value in SRAM using a setup/calibration program, then have the main
(separate) program read this value and checking its valid.
I have thought of a couple of methods but both
have there draw backs:
-
Doing a memory dump and finding a memory location in upper XMEM and hard coding the xmem2root/root2xmem to use
this location. The program here is that there is no "protection"
that a later software change may require more xmem and use (overwrite) this
space. -
Do an xalloc in the main program and recording the memory location it allocated. Then hardcode this value in
the setup program to write to it. At least this way the memory location
is "protected", but means that potentially the setup software needs to get
updated each time the main program is updated.
Can anyone think of a smarter way of doing this?
The userblock is not an option in this case because it uses
flash.
There was a post a while back about xmem
allocation. Something about changing a BIOS constant to give more xmem to
the xalloc routine. I guess you could move that around also to leave your
specific location alone?
From: Nathan Johnston
[mailto:n...@dominion.net.au] Sent: Thursday, March 04, 2004 2:38
PM To: 'r...@yahoogroups.com' Subject:
[rabbit-semi] Forcing variables to fixed memory locations between programs
I'm looking for a way to fix a variables memory
location between programs. As a means of copy protection I want to store a value
in SRAM using a setup/calibration program, then have the main (separate) program
read this value and checking its valid.
I have thought of a couple of methods but both have
there draw backs:
-Doing a memory dump and finding a
memory location in upper XMEM and hard coding the xmem2root/root2xmem to use
this location. The program here is that there is no "protection" that a later
software change may require more xmem and use
(overwrite) this space.
-Do anxalloc in the main program and recording the memory
location it allocated. Then hardcode this value in the setup program to write to
it. At least this way the memory location is "protected", but means that
potentially the setup software needs to get updated each time the main program
is updated.
Can anyone think of a smarter way of doing this? The
userblock is not an option in this case because it
uses flash.
Thanks in advance,
Nathan
Nathan
Johnston
Engineer
Dominion Electronics Pty
Ltd
Tel: 02 9906
6988
Fax: 02 9906
7145
www.dominion.net.au
Reply by shdesigns2003●March 4, 20042004-03-04
--- In rabbit-semi@rabb..., Nathan Johnston <nathanj@d...> wrote: > I'm looking for a way to fix a variables
memory location between programs. > As a means of copy protection I want to store a
value in SRAM using a
> setup/calibration program, then have the main (separate) program read this > value and checking its valid.
Why not use the user block? That is how ZW stores its calibration
constants.
Reply by Nathan Johnston●March 4, 20042004-03-04
The purpose of this exercise is for copy
protection. Our clients product is in a very niche
market
and are paranoid about it being copied. The goal here is that once the core
module is lifted from the unit it will no longer work, as its "password"
in battery backed SRAM is lost. If a programming cable is connected while the
core module is still attached, then all they can do is dump the
flash...
-----Original Message----- From: shdesigns2003
[mailto:s...@shdesigns.org] Sent: Friday, 5 March 2004 12:46
PM To: r...@yahoogroups.com Subject: [rabbit-semi] Re: Forcing
variables to fixed memory locations between programs
--- In
r...@yahoogroups.com, Nathan Johnston <nathanj@d...>
wrote: > I'm looking for a way to fix a variables
memory location between programs. > As a means of copy protection I want to store
a value in SRAM using a > setup/calibration program, then have the main
(separate) program read this > value and checking its valid.Why not use the user block? That is how ZW stores
its calibration constants.
Reply by George Georgiev●March 4, 20042004-03-04
If your client is "paranoid", then cut off the programming port and put
the whole unit in an epoxy so it's harder to take the flash
off.
If you want to make it harder, you can still have a setup function into
your program, protected with some strong password checking.
But don't forget - there is nothing to stop somebody to steal your
code if he wants to.
-----Original Message----- From: Nathan Johnston
[mailto:n...@dominion.net.au] Sent: Friday, March 05, 2004 4:02
AM To: 'r...@yahoogroups.com' Subject: RE:
[rabbit-semi] Re: Forcing variables to fixed memory locations between
programs
The purpose of this
exercise is for copy protection. Our clients product
is in a very niche market and are paranoid about it being copied. The goal here
is that once the core module is lifted from the unit it will no longer work, as
its "password" in battery backed SRAM is lost. If a programming cable is
connected while the core module is still attached, then all they can do is dump
the flash...
-----Original Message----- From: shdesigns2003
[mailto:s...@shdesigns.org] Sent: Friday, 5 March 2004 12:46 PM To: r...@yahoogroups.com Subject: [rabbit-semi] Re: Forcing
variables to fixed memory locations between programs
--- In r...@yahoogroups.com, Nathan Johnston
<nathanj@d...> wrote: > I'm looking for a way to fix a
variables memory location between programs. > As a means of
copy protection I want to store a value in SRAM using a > setup/calibration program, then have the
main (separate) program read
this > value and checking its
valid.Why not use the user block? That
is how ZW stores its calibration constants.
Reply by Nathan Johnston●March 4, 20042004-03-04
Its common knowledge that if someone wants
to steal you code they will. We just want to make it
as hard as possible. Removing the programming port is likely to come back to
bite you as it rules out later software changes (bug fixes). I have
investigated all sorts of means of protection and proposed them, and the value
in SRAM is what has been selected by the client so I'm kind of stuck with
it.
Thanks for the suggestion
anyway.
Nathan
-----Original Message----- From: George Georgiev
[mailto:g...@sbcglobal.net] Sent:Friday, 5 March 20041:16 PM To: r...@yahoogroups.com Subject: RE: [rabbit-semi] Re:
Forcing variables to fixed memory locations between programs
If
your client is "paranoid", then cut off the programming port and put
the whole unit in an epoxy so it's harder to take the flash
off.
If you
want to make it harder, you can still have a setup function into your program,
protected with some strong password checking.
But
don't forget - there is nothing to stop somebody to steal your code if he
wants
to.
-----Original Message----- From: Nathan Johnston
[mailto:n...@dominion.net.au] Sent:Friday, March 05, 20044:02 AM To:
'r...@yahoogroups.com' Subject: RE: [rabbit-semi] Re:
Forcing variables to fixed memory locations between
programs
The
purpose of this exercise is for copy protection. Our clients product is in a
very niche market and are paranoid about it being copied. The goal here is that
once the core module is lifted from the unit it will no longer work, as its
"password" in battery backed SRAM is lost. If a programming cable is
connected while the core module is still attached, then all they can do is dump
the flash...
-----Original Message----- From: shdesigns2003
[mailto:s...@shdesigns.org] Sent:Friday, 5 March 200412:46 PM To: r...@yahoogroups.com Subject: [rabbit-semi] Re: Forcing
variables to fixed memory locations between programs
--- In
r...@yahoogroups.com, Nathan Johnston <nathanj@d...>
wrote: > I'm looking for a way to fix a variables
memory location between programs. > As a means of copy protection I want to store
a value in SRAM using a > setup/calibration program, then have the main
(separate) program read this > value and checking its valid.Why not use the user block? That is how ZW stores
its calibration constants.
Reply by Peter Clark●March 4, 20042004-03-04
Message
Remove the programming port and use a serial
downloader (like SHDesigns) to update the program in flash. That way
thieves can't get to the code unless they unsolder the
flash....
-----Original Message----- From: Nathan
Johnston [mailto:n...@dominion.net.au] Sent: Friday, 5 March 2004
3:21 p.m. To: 'r...@yahoogroups.com' Subject:
RE: [rabbit-semi] Re: Forcing variables to fixed memory locations between
programs
Its common knowledge
that if someone wants to steal you code they will. We
just want to make it as hard as possible. Removing the programming port is
likely to come back to bite you as it rules out later software changes (bug
fixes). I have investigated all sorts of means of protection and proposed them,
and the value in SRAM is what has been selected by the client so I'm kind
of stuck with it.
Thanks for the
suggestion anyway.
Nathan
-----Original Message----- From: George Georgiev
[mailto:g...@sbcglobal.net] Sent:Friday, 5 March
20041:16
PM To: r...@yahoogroups.com Subject: RE: [rabbit-semi] Re: Forcing variables to fixed
memory locations between programs
If your client is
"paranoid", then cut off the programming port and put the whole unit in an epoxy
so it's harder to take the flash off.
If you want to make it
harder, you can still have a setup function into your program, protected with
some strong password checking.
But don't forget -
there is nothing to stop somebody to steal your code if he wants
to.
-----Original Message----- From: Nathan Johnston
[mailto:n...@dominion.net.au] Sent:Friday, March 05,
20044:02
AM To: 'r...@yahoogroups.com' Subject: RE: [rabbit-semi] Re: Forcing
variables to fixed memory locations between programs
The purpose of this
exercise is for copy protection. Our clients product is in a very niche market
and are paranoid about it being copied. The goal here is that once the core
module is lifted from the unit it will no longer work, as its "password" in
battery backed SRAM is lost. If a programming cable is connected while the core
module is still attached, then all they can do is dump the
flash...
-----Original Message----- From: shdesigns2003
[mailto:s...@shdesigns.org] Sent:Friday, 5 March
200412:46
PM To: r...@yahoogroups.com Subject: [rabbit-semi] Re: Forcing variables to fixed memory
locations between programs
--- In r...@yahoogroups.com, Nathan Johnston
<nathanj@d...> wrote: > I'm looking for a way to fix a
variables memory location between programs. > As a means of
copy protection I want to store a value in SRAM using a > setup/calibration program, then have the
main (separate) program read
this > value and checking its
valid.Why not use the user block? That
is how ZW stores its calibration constants.
--- Incoming mail is certified Virus Free. Checked
by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.605 / Virus
Database: 385 - Release Date: 1/03/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.605 / Virus Database: 385 - Release Date: 1/03/2004
Reply by George Georgiev●March 4, 20042004-03-04
But it will be much easier for somebody to provide external power to
SRAM while removing the board from the socket. Moreover, a lot of RCM modules
have their serial ports AND SM1/SM2 pins on socket, so one can make programming
cable without using programming socket at all.
May be a year ago there was a long discussion on that subject, you
might want to check archives.
Regards, George
-----Original Message----- From: Nathan Johnston
[mailto:n...@dominion.net.au] Sent: Friday, March 05, 2004 4:21
AM To: 'r...@yahoogroups.com' Subject: RE:
[rabbit-semi] Re: Forcing variables to fixed memory locations between
programs
Its common knowledge
that if someone wants to steal you code they will. We
just want to make it as hard as possible. Removing the programming port is
likely to come back to bite you as it rules out later software changes (bug
fixes). I have investigated all sorts of means of protection and proposed them,
and the value in SRAM is what has been selected by the client so I'm kind
of stuck with it.
Thanks for the
suggestion anyway.
Nathan
-----Original Message----- From: George Georgiev
[mailto:g...@sbcglobal.net] Sent:Friday, 5 March
20041:16
PM To: r...@yahoogroups.com Subject: RE: [rabbit-semi] Re: Forcing variables to fixed
memory locations between programs
If your client is
"paranoid", then cut off the programming port and put the whole unit in an epoxy
so it's harder to take the flash off.
If you want to make it
harder, you can still have a setup function into your program, protected with
some strong password checking.
But don't forget -
there is nothing to stop somebody to steal your code if he wants
to.
-----Original Message----- From: Nathan Johnston
[mailto:n...@dominion.net.au] Sent:Friday, March 05,
20044:02
AM To: 'r...@yahoogroups.com' Subject: RE: [rabbit-semi] Re: Forcing
variables to fixed memory locations between programs
The purpose of this
exercise is for copy protection. Our clients product is in a very niche market
and are paranoid about it being copied. The goal here is that once the core
module is lifted from the unit it will no longer work, as its "password" in
battery backed SRAM is lost. If a programming cable is connected while the core
module is still attached, then all they can do is dump the
flash...
-----Original Message----- From: shdesigns2003
[mailto:s...@shdesigns.org] Sent:Friday, 5 March
200412:46
PM To: r...@yahoogroups.com Subject: [rabbit-semi] Re: Forcing variables to fixed memory
locations between programs
--- In r...@yahoogroups.com, Nathan Johnston
<nathanj@d...> wrote: > I'm looking for a way to fix a
variables memory location between programs. > As a means of
copy protection I want to store a value in SRAM using a > setup/calibration program, then have the
main (separate) program read
this > value and checking its
valid.Why not use the user block? That
is how ZW stores its calibration constants.
