Posts: 2,272
Threads: 118
Joined: Dec 2013
PS: In the meantime, the most helpful thing everyone could be doing is mapping out the data segment. All you gotta do is make a test project. Say if you wanna find HP... make the player's starting HP some value, then run the game (or testmap if you have privileges to dump that) and once your in the game and your HP is clearly displayed, open taskmanager, and find the process, right click and choose dump (works that way with Vista at least)
The dumped file will be over 150MBs, so only try this if you're machine is pretty hearty. Now open it in your text editor, and go to the SoM data segment (Just look for Holy in the text, and page up a little ways until you see something (edited: for the record f037 will change depending on the game) like 0000 0000 f037 4000. That is where the initialized data segment officially starts for the record (theoretically it's possible these values might've been changed in your dump -- whatever they're used for, but not likely)
Anyway, search for the weird value you set your HP to in the data segment. And once you think you've found it (or a number of candidates) ...repeat the process with a diff HP, and see if one of your candidates reflects the change. If so you've found the HP. If we find out all of this stuff is in a very centralized area, that will be quite useful (and there might then be a way to more directly experiment with the running binary... but if not, we'll all know where to look  )
Chances are HP/MP and everything (including stuff we can't already get at!!) is all very close together, so please, if you have a second, try to find them for us~
Edited: Some notes...
The code segment in the exe starts at 1000... looks like 33c0 568b f189 4608. A disassembler I have puts it at 401000 (401000 is the virtual address, though I dunno what that is off the top of my head)
I'm sort of looking into code injection techniques
edited: This appears to be the sanest route to me ( https://www.programmersheaven.com/2/Inje...table-file)
Posts: 2,272
Threads: 118
Joined: Dec 2013
GUESS WHAT!
We now have the power to do this... I'm pretty sure I can load the counters no problem that is...
Just need to find out where the data we want to load from is now
My current plan is to fork off a thread that will check a predefined counter, to sync with it, that you should have an Always On event continuously add one to. Whenever that changes the thread will reload the predesignated counters.
I will setup a file that you can use to redefine everything to your liking, and even specify your own memory addresses to load from (and how/where to store to)
^That should give you infinite power counter wise without recompiling anything
We can do all of that without injecting any code into SoM's exe files at all. There however is still a lot we could do by injecting code, but for now let's just focus on this strategy...
Long Story Short: I now need everyone to pitch in and hunt down this data in the running exe image (edited: the dump file that is) ...This will be the biggest SoM mod yet. I've played my part, now I need everyone else to show they care enough to pitch in. Cause if I have to do everything myself, I might not feel too much like sharing :P
PS: The good news is, once you find one bit of data, it's likely the rest won't be too far away.
Posts: 2,272
Threads: 118
Joined: Dec 2013
^AND IF I GOTTA REMIND YOU HOW IMPORTANT THIS IS^
This will give us the power to do a lot of stuff... but just to begin with...
*You can determine anything about the player now, Ie...
--Any stat no matter how minute... the "fire" damage stat for instance -- or what equipment the player is wearing and where.
--What is the player's status (poison,dark,curse,etc.)
--Where are the stamina bars at?? (and probably we can manipulate the bars as well)
*Well, let's just say more stuff (for now)
That's just for starters. I think I'm also going to add a system that generates dialog boxes, so that you can give the player messages with numerical stats in them. Basically let you give the player messages with counter variables embedded in them. I just hope it works in fullscreen mode (eventually though, hopefully we can find the SoM function that displays messages and use that)
^SPEAKING OF WHICH: I wonder if I now have the power to put SoM into Window mode... that would be awesome
Posts: 1,813
Threads: 150
Joined: Nov 2008
Very awesome news.
Funny you mentioned windowed mode, I had just pinged John whether or not he had found a way to do it.
Anyways, what youre saying above is very cool indeed, I wish I were savvy enough with what youre doing to help you out, but Im just a dummy =/
- Todd DuFore (DMPDesign)
Site Founder
Posts: 2,272
Threads: 118
Joined: Dec 2013
It's really not so difficult to do. If you read this thread from beginning to end, I think you can get an idea of what is required. You don't need any special tools. Just maybe a hex viewer.
Posts: 2,272
Threads: 118
Joined: Dec 2013
One thing to add... I remember trying to run a diff over two dumps, and it turns out diff apps don't seem to be compatible with binary files 
So I imagine their probably are some programs that can do binary diffs, but I only saw some leads via Google. Good binary diffs could require some pretty heavy algorithms I suppose.
Anyway, I suggest trying to pin down numbers first. Like setting HP to a weird number (something big) and looking for every occurence of that number in the data segment that starts on a regular alignment boundary (Ie. not on an odd byte) ...and just hope most everything else is in that ballpark.
Btw, if you really feel daunted by the idea of handling dumps. You could still contribute by designing test map(s) that make it easy to test different variables I guess.
Posts: 1,649
Threads: 99
Joined: Jan 2009
My Windows XP doesn't have an option to do a dump for the process. Any ideas for an external tool that can do the same? I could probably track one down eventually.
Todd: It's really not as hard as it sounds (assuming I'm understanding correctly). Variables like HP and MP are stored as a number in a specific location (address) in memory. He's just trying to find out where those locations are so he can use them to trigger stuff in the game.
For instance, if your current HP was 999 you would search the dump for the number 03 e7 which in 999 in hex. Sometimes numbers will be reversed in a dump as in e7 03. There may be more than one location where that number appears in the dump so to confirm that it's actually HP's location, you change the HP then redump and look for the changed value in a location that previously had 999 in it.
Most people don't know that Windows default calculator can easily convert between decimal (normal base 10) numbers and hex (base 16). Just go to view>scientific. Type in a number and mark either Hex or Dec to convert a number back and forth.
If you (Todd) have Vista, you might be able to do the dump test better than me. The member IvanhoeHiltop here was writing to me a long while ago about creating cheat code by this same process so he might be of help in this procedure too.
Posts: 2,272
Threads: 118
Joined: Dec 2013
My XP can dump I'm fairly sure. Though my monitor seems like it might need replacing on that machine as of last night (don't worry I've plenty of monitors... just not in the mood atm)
The XP I'm running is Professional edition, so that might make a difference. Also it's possible the dump option isn't added until you install development software like Microsoft Visual Studio, but I doubt it. If that is the case though, there are very capable free versions of that you can download from Microsoft's website.
The option in the taskmanager in the popup menu over a process (not an application) is "Create Dump File". If you google that you can probably find out quick why it is or isn't available to you.
Posts: 1,649
Threads: 99
Joined: Jan 2009
I would expect it's one of Window's optional components that I didn't install; I tried to keep it minimal baceuse XP is so bloated. I'll look through the options or Google and see if I can get it working.
Posts: 2,272
Threads: 118
Joined: Dec 2013
I think the way I've decided to organize this for now, is...
Basically there is no reason at this time that the exe files other than som_db.exe and som_rt,exe (I think that's the name) need to run through this proxy ddraw dll.
If I name it ddraw.dll all the exe in the tools directory will try to use it, so I'm going to call i ddbug.dll, and you will need to hexedit your som_db.exe file, and replace DDRAW.dll with DDBUG.dll.
Once you make your runtime game, you will want to copy ddbug.dll into your game.exe folder, and hexedit your <your_game_name>.exe file to replace DDRAW.dll (if the some_db.exe file isn't just copied/renamed)
I think though to avoid confusion, the file name in the final distributed games should be changed to proxy.dll, and you should hexedit in PROXY.dll instead.
PS: Of course it isn't unforeseeable that two versions of the dll might emerge... one with debugging features, and one without (any future extensions will be loaded by the original module via other dll files)
|
