I am saying this with all due modesty as I am not a professional programmer
and haven't touched a programming language in more than 15 years, and please
nobody mistake this for attempted wisecracking, but AFAI remember when I was
still playing around with programming languages (and that's all I ever did)
you could specify _relative_ addresses (offsets) which the linker would
either resolve at linking time or at program loading time.
Therefor, I had thought Bill was referring to using such within limits
varying random offsets for the respective data / objects / arrays /
structures which the linker would resolve to different actual offsets from
the respective start address of the program or data area.
I don't remember though and therefor have to ask - is it possible to keep
the code and data areas separate, and to give the data area a different
internal layout at each program start in terms of switching the data /
objects / arrays / structures to different positions based on perhaps a
random keycode generated at startup time?
I also wondered whether, if that is possible but the internal structure of
an array is known, a RAM sniffer couldn't re-detect the data pattern no
matter where it is in RAM? If that's the case, the above relative offsets
wouldn't suffice and one would have to actually change the internal
structures of the data objects / structures / arrays to prevent a RAM
sniffer from redetecting the pattern - one would have to morph the data
containers themselves into different shapes to prevent such sniffers from
redetecting the patterns?
Sorry if I'm talking nonsense, the topic is interesting and I'd really like
to know, so despite being a non-expert, I'm bringing the question up...
Achim
> specify where in memory (a "base" address) to start an allocation. You
> can however, create randomly sized arrays both before AND after
> allocating the real arrays, objects, or structures. I have tested this
> and it seems to work fine. The real data's offset from the process's
> base address in memory changes each time the program is run.
> The beauty of it is that it only has to change by a few bytes each time.
> That's all it takes to keep a ram cheat program from working.
> > Rather than using "set" areas of memory each time the program (N2002) is
> > run, it should use random areas. That wouldn't entirely prevent the
current
> > cheat, but make it much more difficult. Of course that would require
> > someone to WORK on the program. Considering what kind of BS I have
seen,
> > this lack of cheat detection doesn't surprise me at all. Heck, they
> > couldn't/can't even fix the darn wall bugs, improper drafting and the
arcade
> > physics. This is all about what SELLS, not what is GOOD.
> --
> =========================================================
> Redneck Techno-Biker & "programming deity"
> http://www.racesimcentral.net/
> DeMONS/1 for Nascar Racing 3 & Nascar Legends
> http://www.racesimcentral.net/
> DeMONS/2 for Nascar Racing 4 and 2002 Season (in development)
> http://www.racesimcentral.net/
> RASCAR Roster
> http://www.racesimcentral.net/
> Barbarian Diecast Collector (490+ cars and counting)
> http://www.racesimcentral.net/
> If you want to send me email, go to the first URL shown
> above & click "Send Me Mail" in the contents frame.
> =========================================================