Psst! Pointers on exe-modding?

[Buster's Uncle]

scient talked to ANYone five months ago and I'm only hearing about it now?

Like Rumpelstiltskin just say my name and I appear (maybe with a bit of delay haha). I'll do a more in-depth post in one of other threads related to my work on SMACX.

For learning RCE, I suggest writing small basic programs in C/C++ and then popping the compiled debug binary into IDA/debugger. OllyDbg is great debugger for beginners. For disassembly, IDA is industry standard. There are some others like Hopper for mac. IDA also had a great decompiler plugin that is quite helpful with SMACX code. This way you have your own original source code and can see what's going on under the hood.

Great books under Reverse Engineering section here:
http://dfir.org/?q=node/8

The x86 binary (windows) was compiled with an older version of Microsoft Visual C++ (5 or 6).

So I've been talking with DrazharLn about sharing the database like a week ago. He reached out to me via email, my life has been hectic. I have a little bit of time before things get busy again so I'm currently working on cleaning a few things up and merging notes into the database. There is much do to with understanding data structures as well as what certain globals or enums do. I have tried to identify as much as I can as I work on it. Either way, it makes it a lot easier to say find specific combat, base or diplomacy code than blindly look around. Want to understand something related to global map? Just see all references to g_MAP in database. Things like this. It makes finding patterns and understanding code flow more manageable.

Once I finish a draft ready for public, I will host it on here as reference and maybe if people identify more stuff merge that info in future draft. If I run out of time and don't finish want I wanted to, will post it anyway. Either way, it will get posted by first week in June.

Glad you're not dead, sir.

Sooner is better than later - just sayin'.

[DrazharLn]

Hi, Scient

Well, there's no big rush, BUncle. Scient's done most of the work, so he should be free to release at his own pace.

[scient]

Have you had a chance to look at draft db? I'm half way through doing the class functions. Some of big ones like Win and Buffer really suck but slogging through them all.

[DrazharLn]

I've only had a brief look: I was away from home this weekend. I'd like to build compilable versions of bits of the code, but I don't know how feasible that is yet.

Idea would be to gradually replace the interesting bits of the code with compilable versions in a library.

Any idea how feasible that is?

The db is a lot more usable than my own one. Good job

[scient]

That is actually how I wanted to start having live code to test while debugging. You would have to understand the data structures that are being passed as parameters. Then you could compile your new code and inject a dll along with a patch to the original function to redirect to the new dll. That way, you could slowly shift function by function into the new dll.

Also, if there is anything in your database that I missed let me know so I can merge them.

[DrazharLn]

My database has no manual annotations - I had some annotations of my own years ago, but they probably didn't cover anything you don't have.

Do you have any idea how much work it takes to turn the pseudo-c into c? Presumably lots of work for the 12MB dump of the whole file, (though possibly a load of that is statically linked library stuff we can strip out), but I was hoping that generated c for a smaller section might be quite easy to clean up for an injector library.

[scient]

It is quite easy for simple functions. I think I put up a few on github awhile ago. That's usually what I'd use as a guideline as well as looking over the assembly logic. Once you start getting into the custom data structures it gets more complex translating that over to c. You could probably hack together some code with inlining but it wouldn't be pretty.

[Yitzi]

scient talked to ANYone five months ago and I'm only hearing about it now?

Like Rumpelstiltskin just say my name and I appear (maybe with a bit of delay haha). I'll do a more in-depth post in one of other threads related to my work on SMACX.

For learning RCE, I suggest writing small basic programs in C/C++ and then popping the compiled debug binary into IDA/debugger. OllyDbg is great debugger for beginners. For disassembly, IDA is industry standard. There are some others like Hopper for mac. IDA also had a great decompiler plugin that is quite helpful with SMACX code. This way you have your own original source code and can see what's going on under the hood.

I actually did it in assembly for some time before even learning C, never mind C++.  Assembly is actually a fairly straightforward language if you're up for a bit (or a lot) of detective work figuring out what does what.

I'm wondering, what makes IDA better than Ollydbg?

[DrazharLn]

photalysis, RCE = reverse code engineering, by the way.

Yitzi, I like that IDA gives you a list of functions in the code and other helpful tools for understanding program flow. scient will use it better, I'm sure.

[scient]

For simple code or simple analysis, Olly is fine. For more complex code where you are figuring out structures, enums, globals and functions then this is where IDA shines. Along with the ability to have a database where you can save persistent changes. I can't count the number of times I've lost quick notes I've made in Olly to point where I only use it as a quick and dirty debugger. Most of the debugging I do is with lldb CLI so having any sort of GUI is a bonus haha. I have started to use IDA's debugger and it's great. Especially if you start to mark up the database.

[scient]

I have made leaps and bounds working on the database over the past two weeks. I really am starting to get an idea of all the different classes for the game and how they work together. Well, at least in my head. I've been trying to mark up and identify as much as possible in the database, especially related to the interface code and how it interacts with logic and structures. I have merged 95% of what was in the PPC binary into my database related to function names and custom variable parameters. As of now, my database is more complete along with the huge amount that I have identified on my own. I have tried to keep the same naming conventions so everything stays fairly uniform.

I've decided on a cut off and release date, 6/15. I have done most of what I wanted to accomplish for a public release and should finish up the rest by then.