Thanks (finally officially) this really got us back on the right track. It actually turned out the correct address was the same as I had originally or would have expected it to be anyway, but VirtualQuery and crew helped make everything straight forward.
I remember expecting the program strings to be in the readonly or text sections of the PE image, but they turned out to be deeper in the data section. I'm not sure why I didn't just trust my instincts, just lazy I guess. Mick Thomas Hruska wrote: > > 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/ > > > -- View this message in context: http://old.nabble.com/Would-like-to-find-an-exe%27s-data-segment-from-inside-a-linked-dll.-Any-thoughts--tp25667267p26296777.html Sent from the C-prog mailing list archive at Nabble.com.
