--- In rabbit-semi@rabb..., Nathan Johnston <nathanj@d...> wrote:
> 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...
THey could dump the RAM if they wanted.
Look at FS2_RAM_RESERVE option in the bios. That will allocate a fixed
area of RAM (4k blocks) that you can use.
I have seen copy protection done via an external PAL. This PAL
responds to a specific sequence. The PAL is programmed with the
security bit set so its equations can not be read. Your code would
send s random sequece of bytes to the PAL and read back the data. It
wuold verify the PAL "encrypts" the data correctly.
Forcing variables to fixed memory locations between programs
Started by ●March 4, 2004
Reply by ●March 5, 20042004-03-05
Reply by ●March 5, 20042004-03-05
Can't you just figure out what the highest valid xmem address is and
read/write it directly with a hard-coded xmem2root and root2xmem? As
long as your xallocs don't reach that address, you'll be fine.
--
Tom Collins - tom@tom@...
QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/
Info on the Sniffter hand-held Network Tester: http://sniffter.com/
read/write it directly with a hard-coded xmem2root and root2xmem? As
long as your xallocs don't reach that address, you'll be fine.
--
Tom Collins - tom@tom@...
QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/
Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Reply by ●March 5, 20042004-03-05
Yes that was one of my original suggestions. I may not be the person maintaining the code later on down the track, so there is an element of risk that the location could accidentally get overwritten (its effectively a data logger so we max out the xmem usage).
-----Original Message-----
From: Tom Collins
[mailto:t...@tomlogic.com]
Sent: Friday, 5 March 2004 5:03
PM
To: r...@yahoogroups.com
Subject: Re: [rabbit-semi] Re:
Forcing variables to fixed memory locations between programs
Can't you just figure out
what the highest valid xmem address is and
read/write it directly with a hard-coded xmem2root
and root2xmem? As
long as your xallocs don't reach that address,
you'll be fine.
--
Tom Collins -
t...@tomlogic.com
QmailAdmin: http://qmailadmin.sf.net/
Vpopmail: http://vpopmail.sf.net/
Info on the Sniffter hand-held Network Tester:
http://sniffter.com/
Reply by ●March 5, 20042004-03-05
I had a similar problem (If I understand yours right). This is how I
solved it.
Everytime my program starts, the first thing it does is allocating
memory for a fixed string, using xalloc. Then it
reads that memory location to see if it contains the string I'm
expecting. Since the startaddress of xmem is always the same (as it is stated
somewhere in the BIOS-files) I'm sure the program always looks at
the proper location.
It does not matter if the program changes or if you load a total
different program into flash. The startaddress should be
the same, as long as you don't modify the startadress in the BIOS
files and the xalloc for the password is the first alloc you
do.
long xMemPtrValidation;
char name[VALID_LENGTH];
char name[VALID_LENGTH];
xMemPtrValidation = xalloc(sizeof(char) * VALID_LENGTH); //
xalloc the area needed for storage
valid = 0;
if (xMemPtrValidation)
{
if(1 + xmem2root(&name, xMemPtrValidation, sizeof(char) * VALID_LENGTH))
{
if(!strcmpi(name, validationString))
valid = 1;
}
}
{
if(1 + xmem2root(&name, xMemPtrValidation, sizeof(char) * VALID_LENGTH))
{
if(!strcmpi(name, validationString))
valid = 1;
}
}
This way you don't have to figure out yourself which adresses you
want to use. And you don't have to worry it will be overwritten.
If any of the experts sees a problem / bug, please tell
me.
-----Oorspronkelijk bericht-----
Van: Nathan Johnston [mailto:n...@dominion.net.au]
Verzonden: vrijdag 5 maart 2004 7:02
Aan: 'r...@yahoogroups.com'
Onderwerp: RE: [rabbit-semi] Re: Forcing variables to fixed memory locations between programsYes that was one of my original suggestions. I may not be the person maintaining the code later on down the track, so there is an element of risk that the location could accidentally get overwritten (its effectively a data logger so we max out the xmem usage).
-----Original Message-----
From: Tom Collins [mailto:t...@tomlogic.com]
Sent: Friday, 5 March 2004 5:03 PM
To: r...@yahoogroups.com
Subject: Re: [rabbit-semi] Re: Forcing variables to fixed memory locations between programs
Can't you just figure out what the highest valid xmem address is and
read/write it directly with a hard-coded xmem2root and root2xmem? As
long as your xallocs don't reach that address, you'll be fine.
--
Tom Collins - t...@tomlogic.com
QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/
Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Reply by ●March 5, 20042004-03-05
Are you aware that when compiling to RAM, the flash is left untouched? A
simple program that writes to some battery backed RAM can be executed after
your main program is downloaded. Remove the programming cable and the
original program will still run. ----------
> From: Dave Moore <dmoore@dmoo...>
> To: rabbit-semi@rabb...
> Subject: RE: [rabbit-semi] Forcing variables to fixed memory locations
between programs
> Date: Thursday, March 04, 2004 5:35 PM
>
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: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 in advance,
Nathan
Nathan Johnston
Engineer
Dominion Electronics Pty Ltd
Tel: 02 9906 6988
Fax: 02 9906 7145
www.dominion.net.au <http://www.dominion.net.au/
_____
> .
simple program that writes to some battery backed RAM can be executed after
your main program is downloaded. Remove the programming cable and the
original program will still run. ----------
> From: Dave Moore <dmoore@dmoo...>
> To: rabbit-semi@rabb...
> Subject: RE: [rabbit-semi] Forcing variables to fixed memory locations
between programs
> Date: Thursday, March 04, 2004 5:35 PM
>
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: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 in advance,
Nathan
Nathan Johnston
Engineer
Dominion Electronics Pty Ltd
Tel: 02 9906 6988
Fax: 02 9906 7145
www.dominion.net.au <http://www.dominion.net.au/
_____
> .
Reply by ●March 7, 20042004-03-07
I hadn't really thought of this. Is this the very first code you run in main? While I haven't checked I would have thought there would have been some xalloc calls in premain (meaning it wouldn't necessarily be at the start), but that shouldn't effect what I'm trying to do.
Thanks,
Nathan
-----Original Message-----
From: Willie Conen
[mailto:w...@imac-oldenzaal.nl]
Sent: Friday, 5 March 2004
7:05 PM
To: r...@yahoogroups.com
Subject: RE: [rabbit-semi] Re:
Forcing variables to fixed memory locations between programs
I had a similar problem (If I understand yours right). This is how I solved it.
Everytime my program starts, the first thing it does is allocating memory for a fixed string, using xalloc. Then it
reads that memory location to see if it contains the string I'm expecting. Since the startaddress of xmem is always the same (as it is stated somewhere in the BIOS-files) I'm sure the program always looks at the proper location.
It does not matter if the program changes or if you load a total different program into flash. The startaddress should be
the same, as long as you don't modify the startadress in the BIOS files and the xalloc for the password is the first alloc you do.
long
xMemPtrValidation;
char name[VALID_LENGTH];
xMemPtrValidation = xalloc(sizeof(char) * VALID_LENGTH); // xalloc the area needed for storage
valid 0;
if
(xMemPtrValidation)
{
if(1 + xmem2root(&name, xMemPtrValidation, sizeof(char) *
VALID_LENGTH))
{
if(!strcmpi(name, validationString))
valid = 1;
}
}
This way you don't have to figure out yourself which adresses you want to use. And you don't have to worry it will be overwritten.
If any of the experts sees a problem / bug, please tell me.
-----Oorspronkelijk bericht-----
Van: Nathan Johnston [mailto:n...@dominion.net.au]
Verzonden: vrijdag 5 maart 2004 7:02
Aan: 'r...@yahoogroups.com'
Onderwerp: RE: [rabbit-semi] Re: Forcing variables to fixed memory locations between programsYes that was one of my original suggestions. I may not be the person maintaining the code later on down the track, so there is an element of risk that the location could accidentally get overwritten (its effectively a data logger so we max out the xmem usage).
-----Original Message-----
From: Tom Collins [mailto:t...@tomlogic.com]
Sent: Friday, 5 March 2004 5:03 PM
To: r...@yahoogroups.com
Subject: Re: [rabbit-semi] Re: Forcing variables to fixed memory locations between programs
Can't you just figure out what the highest valid xmem address is and
read/write it directly with a hard-coded xmem2root and root2xmem? As
long as your xallocs don't reach that address, you'll be fine.
--
Tom Collins - t...@tomlogic.com
QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/
Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Reply by ●March 7, 20042004-03-07
While this would be the best bet, I can't afford to lose half my RAM capacity for storing the code.
-----Original Message-----
From: Robert Richter
[mailto:r...@hildalecity.com]
Sent: Saturday, 6 March 2004 5:04
AM
To: r...@yahoogroups.com
Subject: Re: [rabbit-semi] Forcing
variables to fixed memory locations between programs
Are you aware that when
compiling to RAM, the flash is left untouched? A
simple program that writes to some battery backed
RAM can be executed after
your main program is downloaded. Remove the
programming cable and the
original program will still run.
----------
> From: Dave Moore
<d...@questcontrols.com>
> To: r...@yahoogroups.com
> Subject: RE: [rabbit-semi] Forcing variables
to fixed memory locations
between programs
> Date: Thursday, March 04, 2004 5:35
PM
>
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 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 in advance,
Nathan
Nathan Johnston
Engineer
Dominion Electronics Pty Ltd
Tel: 02 9906 6988
Fax: 02 9906 7145
www.dominion.net.au
<http://www.dominion.net.au/>
_____
>
.
Reply by ●March 8, 20042004-03-08
What I meant was something like this:
main() {
xsetint(----,----);
}
This simple code runs under "Compile to RAM". Your program on flash then
looks for the variables you have just written to RAM. My point was that a
small program in RAM doesn't affect flash; your large program is still
there after this program is run. I've done this a number of times to check
I/O or some other troubleshooting; when I am done, a simple power cycle
causes the main program to go back to work.
----------
> From: Nathan Johnston <nathanj@nath...>
> To: 'rabbit-semi@'rab...'
> Subject: RE: [rabbit-semi] Forcing variables to fixed memory locations
between programs
> Date: Sunday, March 07, 2004 3:18 PM
>
While this would be the best bet, I can't afford to lose half my RAM
capacity for storing the code.
-----Original Message-----
From: Robert Richter [mailto:robertr@robe...]
Sent: Saturday, 6 March 2004 5:04 AM
To: rabbit-semi@rabb...
Subject: Re: [rabbit-semi] Forcing variables to fixed memory locations
between programs
Are you aware that when compiling to RAM, the flash is left untouched? A
simple program that writes to some battery backed RAM can be executed after
your main program is downloaded. Remove the programming cable and the
original program will still run. ----------
> From: Dave Moore <dmoore@dmoo...>
> To: rabbit-semi@rabb...
> Subject: RE: [rabbit-semi] Forcing variables to fixed memory locations
between programs
> Date: Thursday, March 04, 2004 5:35 PM
>
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: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 in advance,
Nathan
Nathan Johnston
Engineer
Dominion Electronics Pty Ltd
Tel: 02 9906 6988
Fax: 02 9906 7145
www.dominion.net.au <http://www.dominion.net.au/
<http://www.dominion.net.au/>
_____
<http://docs.yahoo.com/info/terms/> > .
_____
> Service.
main() {
xsetint(----,----);
}
This simple code runs under "Compile to RAM". Your program on flash then
looks for the variables you have just written to RAM. My point was that a
small program in RAM doesn't affect flash; your large program is still
there after this program is run. I've done this a number of times to check
I/O or some other troubleshooting; when I am done, a simple power cycle
causes the main program to go back to work.
----------
> From: Nathan Johnston <nathanj@nath...>
> To: 'rabbit-semi@'rab...'
> Subject: RE: [rabbit-semi] Forcing variables to fixed memory locations
between programs
> Date: Sunday, March 07, 2004 3:18 PM
>
While this would be the best bet, I can't afford to lose half my RAM
capacity for storing the code.
-----Original Message-----
From: Robert Richter [mailto:robertr@robe...]
Sent: Saturday, 6 March 2004 5:04 AM
To: rabbit-semi@rabb...
Subject: Re: [rabbit-semi] Forcing variables to fixed memory locations
between programs
Are you aware that when compiling to RAM, the flash is left untouched? A
simple program that writes to some battery backed RAM can be executed after
your main program is downloaded. Remove the programming cable and the
original program will still run. ----------
> From: Dave Moore <dmoore@dmoo...>
> To: rabbit-semi@rabb...
> Subject: RE: [rabbit-semi] Forcing variables to fixed memory locations
between programs
> Date: Thursday, March 04, 2004 5:35 PM
>
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: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 in advance,
Nathan
Nathan Johnston
Engineer
Dominion Electronics Pty Ltd
Tel: 02 9906 6988
Fax: 02 9906 7145
www.dominion.net.au <http://www.dominion.net.au/
<http://www.dominion.net.au/>
_____
<http://docs.yahoo.com/info/terms/> > .
_____
> Service.
