I want to learn here

[Metaliturtle]

I'm learning (or trying to learn) programming (have a post in OT)  any .exe modification basics you could point me to?


(I get that it's in C++ and will be over my head but I've got smattering of knowledge in Python, Java, JS, and learning some VBA)

[Yitzi]

Actually, if you want to modify an existing .exe without source code, you'd need to do it in assembly.

As for basics...all I used was Ollydbg and the manual here.  The rest was just looking at the results and figuring out how it worked.  (If you want to go that way, two of the early breakthroughs I made were realizing the importance of breakpoints, and using plaintext stuff as a "handle" to start figuring out what's going on where.)

[DrazharLn]

Disclaimer: I have not been following any developments in exe modification over the last year or so.

Editing the .exe itself isn't C++ or C, it's machine code.

The too long, didn't read version is that low level languages are much more fiddly to use than higher level ones, and in this usage, C++ counts as high level, python and java are stratospheric. If you wanted to, you could learn how to do it, and it's not too hard to make small changes. Making larger changes requires a hard won familiarity with the machine code and, depending on exactly what the change is, an expertise that, AFAIK, only PlotinusRedux possesses in this community

It is possible, with specialist tools, to resolve this machine code back to x86 Assembly Language, which is just about human readable. To do this, you should look at ollydbg and IDAFree.

It is not really possible to resolve the code back to the original C++, though it is possible to "decompile" bits of the machine code to something plausibly similar to the original. This decompilation process is not wholly automated and is difficult and error prone.

Scient, Kyrub and Yitzi have all edited SMAC/X by running the game in a debugger and watching the flow of control through the machine code (resolved to assembly). This is a time consuming operation that eventually results in them gaining enough understanding of the system they want to modify.

Once they know what they want to do and how the current system works, they edit the machine code at that point (writing direct to assembly) to effect their change.

PlotinusRedux has taken a slightly different approach: he has found various systems in the machine code that he would like to change and has inserted machine code to call an external "dynamic linked library" (dll) for those functions.

He can then write the dll's source code in C++ and compile it to machine code. Overall, this allows more broad changes (namely his complete reimplementation of the drawing engine) but requires some more initial expertise (I tried to do something conceptually similar a while ago and failed). It is not so suitable an approach for lots of the bugfixing work that the others have been doing but could be used there if the tool chain and use of it was explained (I'm not familiar enough with assembly or the windows executable format to get it).

If you are still interested in learning .exe modding, a logical start point would be to ask Yitzi for a build of his patch before some fix and the save file used to isolate that fix and then ask him to give you some pointers on where to start.

There's probably a tutorial on ollydbg somewhere as well (this is the tool that Yitzi uses, or at least used to use).

If you'd like some help learning a high level language I'd be happy to chat to you sometime (IRC/xmpp/VoIP/Skype) to gauge your experience and goals and recommend some material to you.

[Buster's Uncle]

I'll add that I learned everything I know about SMACX graphics modding by figuring out how to make minor alterations and getting better (and better - and I'm still learning) at it as I persevered, and getting more ambitious as my skillset expanded with practice.  Young Mr. harLn definitely has a point, above.

So the first thing you do is try to figure out how to make the game say "METALITURLE!" somewhere and work up from there.

[Yitzi]

Disclaimer: I have not been following any developments in exe modification over the last year or so.

Editing the .exe itself isn't C++ or C, it's machine code.

The too long, didn't read version is that low level languages are much more fiddly to use than higher level ones

Not really; in assembly you don't have to worry about forgetting a semicolon.  There are definitely aspects that are harder than in higher-level languages, but "fiddly" isn't really one of them.

It is possible, with specialist tools, to resolve this machine code back to x86 Assembly Language, which is just about human readable. To do this, you should look at ollydbg and IDAFree.

It is not really possible to resolve the code back to the original C++, though it is possible to "decompile" bits of the machine code to something plausibly similar to the original. This decompilation process is not wholly automated and is difficult and error prone.

Well, it's possible, but would be a major project done a small portion at a time.

Scient, Kyrub and Yitzi have all edited SMAC/X by running the game in a debugger and watching the flow of control through the machine code (resolved to assembly). This is a time consuming operation that eventually results in them gaining enough understanding of the system they want to modify.

Actually, I'd guess that my primary analysis method is by reading the assembly; actually watching control flow is a major tool as well, but I think it's secondary.

There's probably a tutorial on ollydbg somewhere as well (this is the tool that Yitzi uses, or at least used to use).

I still do.

[Metaliturtle]

Woah, thank you all, this is crazy how good of a response this is.

It may be way ambitious to think about it now, but I would like to learn.  If there's a better place to start I would be all ears.