Mick Pearson wrote: > First off, Hello! > > I remember a Nabble forum being quite helpful with these types of esoteric > dilemma back in the day. I hope this was one of those handy lists. > > I am in a kind of unusual situation, to which I hope there is a solution. > I'm part of a group that is interested in remaking (or simulating) this > product: > > http://www.fromsoftware.jp/main/soft/som.html > > While fixing a lot of bugs and DX7 stuff which hasn't held up well over the > years, but also extending it by adding some features that should have been > there in the first place while keeping as much as possible backwards > compatible with the original product via a number of software "manipulation" > techniques. If your Japanese is a little rusty, basically this product let's > people make their own stand-alone games (launch-able application) which also > comes with a license to tie in with some intellectual property (KING'S > FIELD) which has developed a bit of a cult following. > > Inside the game development kit there is an event processing system with a > number of basic instructions made available. The instructions can fetch a > number of parameters and change some others, but unfortunately what > parameters are available for read/write are fairly arbitrary, and we would > just like to extend what memory addresses are available within this > framework. The events store all data into registers, of which there are > plenty. So we thought we'd just reserve a number of these registers to load > with whatever information we can, and possibly reserve some of the registers > for data to be stored in the games' runtime exe's data segment. > > We can dump a running image of a game, and easily gleam what info is stored > at what offset into the writable data segment / where the segment starts. > And I pulled together a dll which appears to be directdraw.dll which DX7 > (DirectX7) uses for it's graphics interface. This dll intercepts the > routines imported by the exe and forwards them to real directdraw.dll. This > is a fairly common practice. > > As an experienced programmer I know I should have read/write access from the > dll instance to the exe's memory. But the wall I've run into is how to > reliably locate the start of that memory. I had not expected this part of > the plan to prove so daunting. I've tried everything I can think of without > investing too much time into serious research. So... now I'm hoping someone > could take my hand and help us on our merry way so to speak :) > > Thanks for reading, > > Mick
VirtualQuery() will give you access to the in-process chunks of RAM. If you know of a sequence of bytes to look for, you can find what you are looking for very quickly with that. Essentially what you are doing is what "game trainer" authors have been doing for years. Every program has a set of logical steps it takes to keep track of pointers to addresses it needs access to. To reliably do the same thing, you need to locate the unchanging code in RAM, determine what addresses point at what addresses until you get to the desired data. Since you can dump a running image of the game, you should be able to also use similar techniques to watch the addresses for access attempts or simply watch for the appropriate memory allocations. What you should try to locate is the master pointer to the data structure you wish to access. This is static even within games that use dynamically allocated memory that frequently shifts data structures around. The code itself has to know how to locate its own allocated memory, so in every game there is some variable somewhere you can use as the basis of finding that memory and then alter it accordingly. -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* MyTaskFocus 1.1 Get on task. Stay on task. http://www.CubicleSoft.com/MyTaskFocus/
