I have an idea. (Hacking)

[Wutai Clan]

We know quite a bit about how the game operates internally, and lot's of stuff is part of the .exe,..

I'm not sure how viable this idea is, and I haven't slept yet, so it may be a very bad, ill thought out idea.

Regardless, what I'm thinking, is, could we maybe make an .ini file, and hack the .exe to read known static values from this .ini making edits much easier for the common folks who can't debug\hack. (ie, I believe I just read that the amount of health tents restore is hardcoded in the .exe, so this could be exposed, and easily changed.)

Basically, hack in a function to read from an .ini file at startup, and load these values in place of hardcoded values. (This could be part of Aali's graphic driver, for example.)

It wouldn't be very flexible in terms of numerous mods using it, and I can see where it could mess with mods that expect certain values, however for ppl who customize there own copies, it would be invaluable, and much easier than needing to hack the game to make these changes.

As you can see, this is a very rough idea, but it does have potential if something can be done with it.

Thoughts?

 

[Vgr]

Making a Wall Market-like program that can edit the ff7.exe would be somthing better I believe, altough your idea is very good.

 

[nfitc1]

You're proposing a Game Genie-like effect on the exe? Not likely. The way to go is more like using a virtual IPS patcher.

Hmm. I might be able to cook up something like that, actually. Load the base .exe, then the ips, then it would create a *ips.exe file and run it. Should work that way.

Either way it works, patching the exe to read an ini file isn't easy. You'd need a loader to do it on the fly.

Making a Wall Market-like program that can edit the ff7.exe would be somthing better I believe, altough your idea is very good.

Someone else is welcome to try that, but that would involve a lot of asm hacking knowledge in the first place. Tents and other items aren't handled even remotely close to the way other attacks are.

 

[Wutai Clan]

Yeah, well the main idea, is to expose known values, and make them easier for the average user to change, and give us more options for customizing our playthroughs .

Plus, having them labeled with something logical, like Tent_HealthRestore, would be a lot easier to understand than, 0x0000111, or whatever it looks like in ASM. (I haven't played around in the .exe too much, so I can't post any better examples.)

Glad to hear my idea wasn't completely useless, I am very tired, so I was on the fence about posting it.

Btw, the game reads from files like .cfg type files doesn't it, if so it should already have a mechanism for reading files, you just need to hook it, and use it for your own purposes. (Even if it doesn't have that exactly, I'm fairly certain most games already have basic file reading capabilities imported from C++, so it shouldn't be hard to hook. I'm guessing Aali is already doing this, or already has his own function setup for reading data, I know he reads from a .cfg file to change graphic settings(his limit break patch comes to mind), etc, on the fly. He may be able to help.)

 

[Armorvil]

Yes, this is a great idea. Countless mods that tweak FF7.exe are available, but you can't really use one or the other without having many different copies of FF7.exe. I'm not complaining because the mods are great, but it's not very practical.

 

[Bosola]

I'm not sure how viable this idea is, and I haven't slept yet, so it may be a very bad, ill thought out idea.

Regardless, what I'm thinking, is, could we maybe make an .ini file, and hack the .exe to read known static values from this .ini making edits much easier for the common folks who can't debug\hack. (ie, I believe I just read that the amount of health tents restore is hardcoded in the .exe, so this could be exposed, and easily changed.)

If I'm reading you correctly, what you want is a system whereby mods can be applied on top of each other, even if one mod displaces other parts of the executable.

If this is true, doesn't the Unix utility DIFF more or less support this? Pretty sure you can create 'contextual patches', will still work if other parts of the file grow / shrink.

Can a seasoned *nix user confirm this?

 

[Wutai Clan]

Well, what I'm suggesting is, having a file(ie, Game Settings.ini), the file will contain entries..

Tent_HealthRestore = 250
Potion_HealthRestore = 100
etc,.

Then the game(or a .dll like Aali's), can read this file, and dynamically patch the game to use the values stored in the file, rather than their hardcoded values.

This would expose a ton of modding possibilities to anyone who can open and edit a .txt file.

 

[nfitc1]

If I'm reading you correctly, what you want is a system whereby mods can be applied on top of each other, even if one mod displaces other parts of the executable.

That's what YAMP was all about. Pity it wasn't customizable and I haven't seen dziugo in a long time.

 

[Wutai Clan]

See, I think you are misunderstanding.

I'm not talking about patching the .exe, I'm talking about patching the code once it's in memory, like a trainer, or memory editor does. (But based on an easy to edit file, rather than complex options in some program. Or worse, having to hex edit, and hack to do so, which is also not easily reversible\modifiable, like my solution would be.)

 

[Vgr]

I think you should make a txt file called settings.ini (or something else) and write a dll file called settings.dll (or something else) and put them both in the same folder, then the driver will load settings.dll and settings.dll will load settings.ini which contains all the information. I hope you understand what I mean

 

[Bosola]

See, I think you are misunderstanding.

I'm not talking about patching the .exe, I'm talking about patching the code once it's in memory, like a trainer, or memory editor does. (But based on an easy to edit file, rather than complex options in some program. Or worse, having to hex edit, and hack to do so, which is also not easily reversible\modifiable, like my solution would be.)

Ok. Anything that edits executables on the fly are probably going to raise lots of red flags to anti-virus applications. And on WinXP plus, I'm pretty executable segments are read-only by default (can someone confirm this?).

However, a dedicated patching application that took a definitions file (eg 0x0056FF3 = tent restore value) and a config file, both written in XML, would provide newbies a quick and easy way to make simple edits to the executable.

Be wary, though, that some things will be more involved than changing this or that hex number. If you wanted tents to recover only half HP, for instance, you'd have to rewrite the Inn function completely. You'd probably need some help with that.

 

[Wutai Clan]

I think you should make a txt file called settings.ini (or something else) and write a dll file called settings.dll (or something else) and put them both in the same folder, then the driver will load settings.dll and settings.dll will load settings.ini which contains all the information. I hope you understand what I mean

Yeah, this is what I've been talking about.

 

[Vgr]

Yes, but isn't better an ini file? Something like this :

0x0056FF3 (Tent restore value) = MHP * (32 [VAR]/32) + MMP (32 [VAR]/32)

Things in (parenthesis) are descriptions and things in [brackets] are precisions. I don't really know much about that, but Aali/kranmer might know.

 

[Wutai Clan]

Ok. Anything that edits executables on the fly are probably going to raise lots of red flags to anti-virus applications. And on WinXP plus, executable segments are strictly read-only.

However, a dedicated patching application that took a definitions file (eg 0x0056FF3 = tent restore value) and a config file, both written in XML, would provide newbies a quick and easy way to make simple edits to the executable.

Be wary, though, that some things will be more involved than changing this or that hex number. If you wanted tents to recover only half HP, for instance, you'd have to rewrite the Inn function completely. You'd probably need some help with that.

Yeah, I think we should get Aali on board with this, most everyone uses his patch, and it already has all the functionality necessary, he would just need to add another .ini file to house the settings, and a simple function to actually apply the changes.

It might be beyond my C++ skill level, if it were C#, no problem, but it's going to take someone more skilled than me in C++ to pull this off.

 

[Bosola]

I don't think it would matter. I don't think DLLs have the privilege levels to modify an executable.

 

[Vgr]

Yeah... and btw Aali made a driver, not a patch. We can apply patch by this driver. I believe that even by making a trainer, you'll need to patch a dll into the exe to apply to changes to everybody

@Bosola : Yes, DLLs can modify executables, think to kranmer who implemented a DLL ^^

 

[Kranmer]

sounds like a good idea,
yeah a DLL can patch memory, you could use Aali's "Load_Library" function and make a DLL that will work from his driver that will load a CFG/XML/INI/TXT and patch with those bytes (i do this with my ff7anycd DLL but i dont use any kind of INI file i just have the values in the DLL itself).
Also if its patching the memory what would you do in the case that it loads a file into a different part of the memory ? (for example the window.bin is loaded into a different part of the memory on my PC then it is on DLPB's PC).

 

[Wutai Clan]

I don't think it would matter. I don't think DLLs have the privilege levels to modify an executable.

I could be wrong, but it's not something you could work around without making your AV's klaxons flare. Or causing a BSOD (which is usually down to something executing or modifying memory that it shouldn't).

The limitation I'm thinking of is less an understanding of the executable than how the OS handles memory and keeps itself secure. Because malware often injects executable code into non-executable space, and edits executables themselves, most modern operating systems strictly control which memory can be executed, and which can be edited / read. As I say, I could be mistaken, but I don't think a linked DLL has the 'rights' to modify executable segments.

You don't need to modify the .exe itself, you are editing memory. (That's how trainers work.)

Now, for more complex stuff, I don't yet, I'm too tired, and don't have enough info on the internals to guess, but I'm sure it's not as difficult as you are thinking it is.

 

[Wutai Clan]

sounds like a good idea,
yeah a DLL can patch memory, you could use Aali's "Load_Library" function and make a DLL that will work from his driver that will load a CFG/XML/INI/TXT and patch with those bytes (i do this with my ff7anycd DLL but i dont use any kind of INI file i just have the values in the DLL itself).
Also if its patching the memory what would you do in the case that it loads a file into a different part of the memory ? (for example the window.bin is loaded into a different part of the memory on my PC then it is on DLPB's PC).

You have to find the pointer to the real value.

There is always a pointer to the real value, and it should always be the same for everyone, or else trainers wouldn't work. (Unless I'm misunderstanding what you are asking, I am very tired right now.)

---

Edit: Actually this is a bad description, let me try again.

Basically, even though the data is in a different place in memory, there is an offset you can find, and value that relates, that will always point to the proper place in memory.

 

[Bosola]

yeah a DLL can patch memory, you could use Aali's "Load_Library" function and make a DLL that will work from his driver that will load a CFG/XML/INI/TXT and patch with those bytes (i do this with my ff7anycd DLL but i dont use any kind of INI file i just have the values in the DLL itself).

Thanks for confirming this. I stand corrected.

Also if its patching the memory what would you do in the case that it loads a file into a different part of the memory ? (for example the window.bin is loaded into a different part of the memory on my PC then it is on DLPB's PC).

Thinking back to DIFF, I'm fairly sure it uses 'contextual patching' - eg 'patch in this value at the point preceded by this stuff and followed by that stuff'. Could we exploit a similar method? Or maybe intercept things when the executable header orders the OS to start copying bits of the .exe into various segments?

In any case, I think a lot of people are missing an important point: things like items don't take their power and effect from a few hex values. They use executable functions, and making them do different things is likely more involved than changing a few digits.

You don't need to modify the .exe itself, you are editing memory. (That's how trainers work.)

Whilst I was incorrect, I *was* talking about memory. Don't confuse the 'persistent' .exe file with executable segments, portions of RAM which contain the executed binary.

Basically, even though the data is in a different place in memory, there is an offset you can find, and value that relates, that will always point to the proper place in memory.

Going out on a limb, but II think Kranmer is suggesting the segments aren't always contiguous (ie don't follow the same order) on different machines. I could be misunderstanding him, though.