Trek.exe: in-memory patching with C/C++

[Flocke]

I guess the simplest answer is to keep the loader program simple, and use LoadLibrary() to load plugin DLLs that do any heavy modding.

Hm, good point. A plain launcher with plugin system for all the modding.
That way dynamic loading should be fairly safe.

[Flocke]

If you tried to patch code in a running program, it would crash out. This is because the memory is protected from being overwritten. But we can change the properties in Trek.exe to make the code writable, so we can patch it while it's running. Basically, all we need to do is patch a single byte in Trek.exe. You could use special tools, like CFF Explorer, but I'll just tell you which byte to set in trek.exe:

Code: Select all

At offset 0x019f, change C0 to E0

You meant to change 60 to E0 (20 = executable, 40 = readable, 80 = writable), but CFF Explorer is a great tool, thx!

I now interated this with the mpr++ Extension Adapter I'm working on and it works perfect!
Beside "Monkey Patching" (funny term) the way described, which is great to completely replace a function, I also added to patch the actual call or jmp statement so other references to same old code location aren't affected.
I just hope all this won't result in troubles with anti-virus software or such.

Added your example for galaxy generation and it works fine.
Once, with UDM at max tech many races, it freezed on galaxy generation. But that's the usual trouble with not finding enough room for all starting systems I guess. Maybe some anomalies were placed aside home system or whatever.

This should allow for some interesting patches, with no need to modify Trek.exe.

Indeed, and it allows to switch features on and off again without fiddling with trek.exe all the time.
Any chance to see you back on this?

[QuasarDonkey]

Yeah, definitely.

I've spent the last few days working on a totally new version of the IDA database (there were some problems with the old one). I've already coded up all the old info into the new database. I'm identifying all the UI functions now. The more we know about Trek.exe, the more patches we can make.

And I'm still hopeful for full decompilation one day Or at least partial decompilation by patching the replacement code into Trek.exe.

Added your example for galaxy generation and it works fine.
Once, with UDM at max tech many races, it freezed on galaxy generation.

I never tested with minors. But it is not surprising that it froze, there's not a lot of space on that map

[thunderchero]

I've spent the last few days working on a totally new version of the IDA database

I was just thinking it was due for an update last time I used it.

thunderchero

[Flocke]

Yeah, definitely.

I've spent the last few days working on a totally new version of the IDA database (there were some problems with the old one). I've already coded up all the old info into the new database. I'm identifying all the UI functions now. The more we know about Trek.exe, the more patches we can make.

Hey, cool! Looking forward to even more key variables.
The list already is immense and yeah it helps alot to read the code!

And I'm still hopeful for full decompilation one day Or at least partial decompilation by patching the replacement code into Trek.exe.

I think chances for the latter aren't that bad. We just need to work from top to the ground.