Author Topic: Unused sections of the exe (Read 14555 times)

nfitc1 · « **on:** 2012-09-11 21:59:09 »

Someone recently (Don't know whom) asked for a list of sections of code that don't get executed in the exe. I would like to attempt to compile this information as my efforts to reverse some things constantly clue me into unused sections:

0x4079B8 - 0x40800F //starting off early and large, this looks like it used to be a large debug sub that simulated the loading and parsing of lgp files. Doesn't seem to get run.
0x7443E7 - 0x7443FF //related to the above, this was loaded after selecting the appropriate midi lgp file
0x40AC8E - 0x40AC99
0x40B276 - 0x40B27A //one of those winxfltr functions here that doesn't get called. I don't know why there are so many in this file....
0x40B373 - 0x40B3FF //Might have something to do with playing movies. Uses a range of static bytes that don't get used elsewhere.
0x7BB1D0 - 0x7BB377 //Range of values used by above function. Doesn't look like it does anything.
0x40F0C7 - 0x40F0CA
0x40F4F0 - 0x40F5CF
0x40F8F0 - 0x40F99F
0x40FF60 - 0x40FFBF
0x410056 - 0x41034F
0x410550 - 0x41080F
0x418DD4 - 0x41920F //might actually be used for software rendering. It's actually two functions. The first has to do with error messages related to D3D Devices. The second one is related, but I'm not sure how.
0x41AD4B - 0x41B092
0x41CD2D - 0x41CF09
0x41F1C3 - 0x41F39B //actually three different funcs called by a function above
0x41FB15 - 0x41FB1B \
0x41FA5A - 0x41FA6F | there are lots of these little do-nothing snippets that are easily overlooked.
0x41FB15 - 0x41FB1B /
0x430266 - 0x4302E7
0x430CE4 - 0x430CF9
0x5C1FBC - 0x5C206F
0x5C8C82 - 0x5C8CF9
0x5E1D93 - 0x5E23F5 //looks like PSX code residue. Morphing models and testing hrc files and the like
0x5E2908 - 0x5E2A0F
0x5F4C67 - 0x5F4CA5
0x5FA68B - 0x5FA6F4
0x5FA761 - 0x5FA781
0x60B6F3 - 0x60B9CF
0x6384B0 - 0x6384E5
0x64060D - 0x64085B
0x64179F - 0x6417D5
0x6417DE - 0x641950 (?)
0x64271C - 0x642ACC
0x64B16A - 0x64B562
0x663C2F - 0x66415F
0x6672A1 - 0x6672CF
0x68FFA4 - 0x690052
0x6E2E5B - 0x6E2FA8
0x703828 - 0x703ABC
0x75AADC - 0x75AB4F
0x76C3C1 - 0x76C57D
0x77F324 - 0x77F397
0x7B1997 - 0x7B1A3F

Not so sure about these:
0x6CBD54 - 0x6CBD64
0x71FF95 - 0x72007F
0x719D7A - 0x719DBD
0x71A6E6 - 0x71A7A8
0x71FF8B - 0x71FF94
0x71AAA3 - 0x71E1E6 //this one is HUGE (14,147 bytes!) g and calls 357 different subs, many of which are uniquely associated with this function.
I think this might have been part of the shop menu at one time seeing all the text that is associated with it. It would be executed if 0xCC0D89 had a value of 8, but that can't happen.
These are actually called if 0xCC0D89 has a value of 9, which can happen. I'm not sure what conditions cause it, but I'm striking these from the list.

That's all I have for now. I'll update this as I find more. Feel free to chime in and let me know of other places that aren't used and I'll add them to the list.

DLPB_ · « **Reply #1 on:** 2012-09-11 22:04:48 »

I use a large section at 00511d40 exe (I am currently up to 00512C36) for additional programming , although a much wider area is not used.

nfitc1 · « **Reply #2 on:** 2012-09-12 00:15:26 »

Wow. That is pretty large. I'll add it to the list. Where does it end?

DLPB_ · « **Reply #3 on:** 2012-09-12 00:26:22 »

God knows (although the header should say?). But it starts above that with all that debug crap. because this is all debug data that is unused. Make a note that I use this area so anyone who uses extra space doesn't use it. Lets say I have reserved 511d40 to 515000.

Changing 0000021C = 60
0000021F = E0

Makes the area R/W/Executable.

Although it has all gone memory edit now anyway from my side. Same difference.

Tenko Kuugen · « **Reply #4 on:** 2012-09-12 07:10:29 »

I wanted to know about extra space so I could exclude specific spells from the quadra magic function
You never got back to me on the addresses, NFITC1
I believe it was someone else who asked for a list though.

nfitc1 · « **Reply #5 on:** 2012-09-12 16:42:32 »

Quote from: DLPB on 2012-09-11 22:04:48

I use a large section at 00511d40 exe (I am currently up to 00512C36) for additional programming

I took at look at that and it seems that it would be used if 0xBE119A is either 6A or 3C. That could be a number of things. Are you sure that's unused?

syntax error · « **Reply #6 on:** 2012-09-12 16:47:02 »

funny code snippets! whats converted and renamed?
//----- (005E1D93) --------------------------------------------------------
int __cdecl sub_5E1D93()
{
...
sprintf(&Format, "CONVERTING ENEMY %d \n", i);
if ( i == 13 || i == 15 || i == 138 || i == 217 || i == 243 )
...
}
}

//----- (005E21D7) --------------------------------------------------------
int __cdecl sub_5E21D7()
{
...
sprintf(&Format, "RENAMING BATTLE FILES \n");
sub_664E30(&Format);
...
sub_5E22BB("*.T0*");
sub_5E22BB("*.P*");
sub_5E22BB("*.W*");
sub_5E22BB("*.A*");
..
}

//----- (005E22BB) --------------------------------------------------------
void __cdecl sub_5E22BB(const CHAR *a1)
{
...
Memory = sub_68FBDC(0, a1);
if ( Memory )
{
for ( i = 0; i < *(_DWORD *)Memory; ++i )
{
sub_5E2908((const char *)(32 * i + *((_DWORD *)Memory + 1)), (int)&NewFilename);
sprintf(&Format, "RENAMING %s TO %s \n", 32 * i + *((_DWORD *)Memory + 1), &NewFilename);
sub_664E30(&Format);
if ( rename((const char *)(32 * i + *((_DWORD *)Memory + 1)), &NewFilename) )
{
sprintf(&Format, "ERROR: RENAMING %s TO %s \n", 32 * i + *((_DWORD *)Memory + 1), &NewFilename);
...
}
}
sub_68F9AA(Memory);
}
}

Aali · « **Reply #7 on:** 2012-09-12 17:49:01 »

Most, if not all of the code that converted PSX data to PC format is still in there.

DLPB_ · « **Reply #8 on:** 2012-09-12 18:06:17 »

Quote from: NFITC1 on 2012-09-12 16:42:32

I took at look at that and it seems that it would be used if 0xBE119A is either 6A or 3C. That could be a number of things. Are you sure that's unused?

I think it can be turned on. But that's probably the flag to turn debug mode on. I can't see it being turned on in normal game. I'm sure I asked dziugo at one point. If it were turned on in normal game, someone would have reported serious crashes by now since I use that area for a lot of different things.

nfitc1 · « **Reply #9 on:** 2012-09-12 19:31:20 »

Quote from: syntax error on 2012-09-12 16:47:02

funny code snippets! whats converted and renamed?

Renamed is likely renaming the battle.lgp files from their four letter file name to give them appropriate extensions.
Converting looks like it's changing the model from one to another. A little farther down from that code you snipped mentions "converting player" and "frog.dat" so that's my guess.

Quote from: DLPB on 2012-09-12 18:06:17

I think it can be turned on. But that's probably the flag to turn debug mode on. I can't see it being turned on in normal game. I'm sure I asked dziugo at one point. If it were turned on in normal game, someone would have reported serious crashes by now since I use that area for a lot of different things.

True enough, but then that opens a lot more functions from being "junk" and I'm mainly listing ones that really just don't have any links to them (can't be accessed internally). Disabled functions might be a separate list. Still, I'm only ~5% through the exe and still found a lot of junk here and there. Small snippets mostly, but still plenty to work with if we want new functions like item behaviors or field commands.
After going through this we should get together and coordinate which other funcs are disabled.

Edit:
Just found an example of this. 0x5C904D is listed as Command function 1A, but isn't used by any working command. It is the only func that calls 0x4333C4. That's two disabled functions. They're still valid and accessible even though they aren't executed during normal play.

Quote from: Aali on 2012-09-12 17:49:01

Most, if not all of the code that converted PSX data to PC format is still in there.

That's strange. Did Eidos compile the conversion library in with the executable? Maybe they were originally going to convert on the fly but it took too long and didn't remove the conversion functions.
Still, your graphics driver is really throwing off my xrefs.

I see references to 0x100XXXXX addresses and it acts like it can jump to that, but it obviously won't.

DLPB_ · « **Reply #10 on:** 2012-09-12 19:45:49 »

I like the idea, let's see how small the exe could have been if all junk and debug was removed.

InuRa · « **Reply #11 on:** 2012-09-12 20:21:45 »

Well, let 'us players' know when it's all filtered, and we'll go through the whole thing trying to find stuff that shouldn't have been removed after all. Nothing like a brute-force test.

This is definitely an interesting topic!
It's however definitely disappointing to see how little attention Square put into this conversion, from mistakes to old code...
Guess I shouldn't expect a re-release for Windows ARM at all at this rate. /S

nfitc1 · « **Reply #12 on:** 2012-09-12 20:44:29 »

Quote from: DLPB on 2012-09-12 19:45:49

I like the idea, let's see how small the exe could have been if all junk and debug was removed.

Considering there are 9895 mapped functions I would appreciate some help.

There was a program once upon a time that compressed executables in such a way that made them smaller and they still ran as if nothing happened. I tried it on several progs with no error and was astounded how small some of them got. I think this is the kind of thing it did. It cleaned up all the ridiculous compiler fluff and removed unlinked code while updating the addresses accordingly. I can't for the life of me remember what it was called, but I remember hearing that zsnes used it back in the day.

Jenova's Witness · « **Reply #13 on:** 2012-09-12 23:37:28 »

DLPB_ · « **Reply #14 on:** 2012-09-12 23:42:42 »

Unfortunately my help isn't coming, I am far too busy with numerous things at mo

Bosola · « **Reply #15 on:** 2012-09-13 10:26:48 »

Quote from: NFITC1 on 2012-09-12 20:44:29

There was a program once upon a time that compressed executables in such a way that made them smaller and they still ran as if nothing happened. I tried it on several progs with no error and was astounded how small some of them got. I think this is the kind of thing it did. It cleaned up all the ridiculous compiler fluff and removed unlinked code while updating the addresses accordingly. I can't for the life of me remember what it was called, but I remember hearing that zsnes used it back in the day.

Are you thinking about DeadStrip?

DLPB_ · « **Reply #16 on:** 2012-09-13 13:28:43 »

How does upx compare?

nfitc1 · « **Reply #17 on:** 2012-09-13 13:45:14 »

UPX! That's it! Man. It's been forever since I even thought about that.

Looking at their official website it sounds like it does just compress the executable and wrap it in a special function that can read and execute the compressed data.
Back before multi-Gigabyte hard-drives this would have been helpful when disc space was limited. Now not so much.

Quote from: Bosola on 2012-09-13 10:26:48

Are you thinking about DeadStrip?

No, but that's the kind of function I was thinking UPX had. I am glad that something like that exists, at least.

DLPB_ · « **Reply #18 on:** 2012-09-13 13:46:42 »

UPX does get rid of SOME unused data but certainly not all or anywhere near from what I can see.

Bosola · « **Reply #19 on:** 2012-09-13 21:35:34 »

Quote from: NFITC1 on 2012-09-13 13:45:14

Back before multi-Gigabyte hard-drives this would have been helpful when disc space was limited. Now not so much.

Whilst hard drives have become larger, hard drive bandwidth hasn't improved much, so UPX can still prove useful when the time taken to copy the extra data into RAM is less than the time taken to perform the decompression. Many people report that this technique improves Firefox startup times, though I've never tried it myself.

DLPB_ · « **Reply #20 on:** 2012-09-15 03:34:36 »

https://docs.google.com/spreadsheet/ccc?key=0AlJH_wU1qqN4dGtGdDIzMmxUSHJDZXBlSzM3X05XUmc#gid=0

Things marked in red arent used. Not really sections, but unused entries. See key.

syntax error · « **Reply #21 on:** 2012-09-16 20:59:55 »

I find the fact interesting that the PC version has a malloc() macro that is given the filename and line.

Aali · « **Reply #22 on:** 2012-09-16 21:49:03 »

FF7PC has a whole automated heap debugging mechanism, thats hardly surprising though as many if not most applications and games do that to some extent.

halkun · « **Reply #23 on:** 2012-09-16 23:25:43 »

Quote from: syntax error on 2012-09-16 20:59:55

I find the fact interesting that the PC version has a malloc() macro that is given the filename and line.

Used that little fact to dump some of the source tree.

http://wiki.qhimm.com/FF7/Technical/Source

Could use some cleanup though