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/>
_____
>
.
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/
-----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/
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/
-----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 programsIts 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 2004 1: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, 2004 4:02 AM
To: 'r...@yahoogroups.com'
Subject: RE: [rabbit-semi] Re: Forcing variables to fixed memory locations between programsThe 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.
-----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 programsIts 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 2004 1: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, 2004 4:02 AM
To: 'r...@yahoogroups.com'
Subject: RE: [rabbit-semi] Re: Forcing variables to fixed memory locations between programsThe 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.
---
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