GOOD NEWS UPDATE: The mother of all cracks!

[Holy_Diver]

I had a thought, about probably the single most effective code injection that could be achieved...

Basically the idea is, to locate the address of the counters in the executable image. Then reserve so many of the counters at the very end.

Then inject some very simple code that loads another address into each of the counters. The other addresses being wherever you think useful data is stored (that can be found later)

Basically in the simplest case, this could access integer values with the same specs as the counters directly into counters each event loop, so you can use an IF on that counter and do something, or set something to that value.

For stuff that might be stored as a floating point (with a decimal point) value, code could be injected to pre-convert those values (probably not hard to do once you get that far)

Same for data that might be stored in a bit vector (like your bad status state could be)

I'm assuming this is more or less how a Game Genie works. I've never done anything like injecting instructions into an executable image. I'm guessing it's very possible, and probably not too dangerous. If so there are probably websites dedicated to helping people do this sort of thing.

I'm not volunteering to do this... but I'm volunteering the idea, and again it would be an amazingly fruitful hack I think, and I would be very grateful for one

[Holy_Diver]

PS: You could theoretically do this in reverse (though not quite as safe) and load the values you put into some counters into the games address space each event loop.

^The reason this is not as safe, is because SoM might actually use a derivative of some variable to actually work on, so you'd either have to account for all of those.... or just try and see what happens, and hope for the best.

[dmpdesign]

Seems to me what youre talking about here would be similar to what the F1, F2 etc keys do during test mode through SOM.

It must have values somewhere in the program that operates the test mode to allow things like flying through walls, super speed, the menu to alter counters etc.

Maybe looking at the code for how the editor runs those hacks would be a good place to start.

[Holy_Diver]

I'll have to try out all those function keys I suppose. It's just an idea. I write code, but monkeying with existing binaries is not something I've any want to add to my repertoire. I know people do this sort of stuff however.

One thing I might look into, is I think the Windows runtime api has ways of working with executable images... I guess for compiler writers. It might be possible to use that to write a toolset that can safely rearrange the image (make room for new instructions)

[HwitVlf]

That would be a useful hack. Basically, it would let a person set any variable like 'poison= yes/no' into a counter slot.

HolyDiver, have you considered using a decompiler? You might rebuild enough of the source code to get a decent handle on how it works. I think SoM was written in C++
https://download.cnet.com/Delphi-and-C-B...94628.html

[Holy_Diver]

C++ is my bread and butter, but I dunno... a decompiler could shed a little light on the situation. I think I tried decompiling PS2 binaries once with what seemed like little results.... or maybe I just disassembled them... actually I think it was combination of the two (the decompiler left much in asm)

But yeah, it would be extremely useful (mother of all cracks) ...which is why I think if there is any effort in this direction, this should be top priority.

Anyway, I know it sounds bad, but I'm very busy (when I'm not indulging myself) ...so yeah, if someone wants to decompile the exe or whatever, and send me a copy of the results, I will look them over. If the process is more interactive than that, I might make a point of getting around to mucking about with a decompiler myself.

[Holy_Diver]

I actually burned a lot of time last night trying to find counter addresses after I noticed I could debug/dump a process directly from Taskmanager.

I never have any luck with this sort of thing. The counters sould be 16bit -- 65535 is their max setting. I setup an always on event to load ABACAB into three counters and a bunch of zeros in the next three, but I couldn't find any sequential addresses that reflected these values... so if I know what I'm doing, the counters aren't stored sequentially. Still digging around the dump in the general SoM region (it's full of other dlls) I didn't find anything that looked very suspicious (well yet)

I saw a lot of stuff that looked like it was probably multibyte character encoding, but my hexeditor dejour did not do non UNICODE multibyte output (so are there any untranslated stuff left in the latest translation??)

I tried to find some decompilers... but couldn't find anything too useful. I will try your link I guess (it was dead for me the other day -- but seems to be downloading atm)

[Holy_Diver]

The C++Builder tool just froze Vista good. I also noted it spawning a lot of "tmp" processes. I'd think it was some kind of malware except cnet seems to think it's ok. I will try it on a much slower XP machine if you think it's worth it.

[Holy_Diver]

Found the counter addresses in the dump at 001e59dc... now just need to figure out where that address actually is from inside the exe address space (dump has the entire wincrt runtime included)

Also the counters are stored on a 32bit stride (which I guessed might be the case -- though I assumed like 00AB00AC00AB, whereas they're AB00AC00AB00) Dunno if the intermediary bits are used for anything. They're all 00 in my dump.

Hopefully I can use this free trial download I have to find out what the start of the SoM's address space proper looks like...

[Holy_Diver]

The data segment starts at 000ea608 in the dump, which corresponds to 00459000 in the exe. Subtract, and the offset is fb3d4. Add that to the exe and you get 5543D4, which is byte #5587924.

I'm going to try writing over the exe at those addresses and see if the counters default to that. It's possible they get zeroed over, but most likely they don't...

edited: Turns out the exe data sector starts at 59000 in the file. But that is probably not where it's loaded into memory. So 1543d4 we'll try... which falls outside the exe, so this is probably uninitialized data (defaults to zero)

Where exactly to go from here, I dunno~