How to decompile?

[Kohan]

Sorry if this is an insanely stupid question, but how do I decompile FF7's source files?  Better yety, how do I access them?  First, where are they located?  In the .lgp's or the .exe?  What language are they in?  In they're in the .lgp's, what filetype are they?  Any help is greatly apprectiated.
My reasons for knowing how to do this are because I wish to see what is inside the walls for myself.  It's not that I don't trust Qhimm's gears FAQ, but if I saw the original code, then I would be able to understand it better, and perhaps even make a more understandable FAQ for personal purposes.  Thanks in advance.

 

[dziugo]

(...)First, where are they located?

Square HeadQuaters?

I believe, that no decompiling (to C/C++) had taken a place. It was most likely a disassebly of ff7.exe. Just get a good disassebler/debugger. Good luck.

dziugo

 

[Kohan]

Well that was a real help xD.  Since you seem to be sort of unknowing of that stuff, I am hereby directing these questions towards DA QHIMM HIMSELF.  Thanks for your input though ^^.

 

[Cyberman]

Sorry if this is an insanely stupid question, but how do I decompile FF7's source files?  Better yety, how do I access them?  First, where are they located?  In the .lgp's or the .exe?  What language are they in?  In they're in the .lgp's, what filetype are they?  Any help is greatly apprectiated.
My reasons for knowing how to do this are because I wish to see what is inside the walls for myself.  It's not that I don't trust Qhimm's gears FAQ, but if I saw the original code, then I would be able to understand it better, and perhaps even make a more understandable FAQ for personal purposes.  Thanks in advance.

Ummm I don't think Eidos or Square have the original code anymore.  Even the windows port was done with backups that weren't correct from what Halkun explained.  Simple word NO SOURCE EXISTS for the game anymore likely. The second legal issue is .. it's not yours to have
As for decompiling the executables, ummm unless you have experience doing this I see lots of frustration in your future.
FF7 for windows was written in Microsoft VC++ version 6.0.
FF7 for the playstation was written using Sony's developement kit for the PS1 (PsyQ libraries).
As for 'personal reasons' for decompiling it, I think you are trying to climb Mount Everest without even knowing it.

Cyb

 

[L. Spiro]

Just because his answer didn’t meet your criteria doesn’t mean he isn’t knowledgeable regarding “that stuff”.

how do I decompile FF7's source files?

You don’t decompile source files.  You decompile the compiled code generated from the source files.  What do you get when you do that?
Usually a bunch of garbage that won’t compile and won’t glean you any more information than you would get by doing as dziugo suggested: getting a good disassembler/debugger.
In fact, using debuggers and disassemblers will get you more information because with them, you can step through the code as it happens and follow everything.

Better yety, how do I access them?  First, where are they located?

You don’t access the source files.  As dziugo said, they are probably locked away in SquareEnix, if even there.  And Eidos might have a copy.

In the .lgp's or the .exe?

LGP files contain game resources.  The .EXE file contains the compiled game code.  Compiled from the source files which are locked away in a place you can’t access.

What language are they in?

C originally, but some C++ was added later.

My reasons for knowing how to do this are because I wish to see what is inside the walls for myself.

No offense, but from the questions you are asking, I don’t think you would be able to get that information even if you could get the source code.
And you do have the compiled source (the .EXE file) right in front of you, as we all, do, and the information you get on this site isn’t guesswork.
People who knew what they were doing used the resources they have already been given (and you too!) to get the raw facts behind how the game works.
Anything that is guesswork is noted as such.  Anything not explicitly stated as guesswork should be assumed to be facts based off research by looking inside the walls.


L. Spiro

 

[Kohan]

Well, at least I now know that .lgp files are not source files, compiled or not.  That answers a few questions.  But if it's coded in c/++, why would you use a disassembler?  Oh, right.  Well, I'm not going to even attempt to recompile it anyway, I just want to see all of the code and piece it together in my mind; that's how it works; linking everything together makes it work.  Relativity.  For a crap example, when I see 9*4, I don't think 9+9+9+9, I see "4-1 is 3, and 9-3 is 6, so it's 36".  Anyhow, now is not so much the time to be explaining my brain's thought propcesses.

So what I want is to know how to decompile the .exe (however many steps it might take) into readable code, whether or not I can recompile it.  If anything, I would make a game that uses the same mechanics, so it doesn't really matter anyway.

I suppose, to restate my purpose for doing this, a damage formula and an explanation of all the status effects isn't enough for me :wink:.

 

[Sukaeto]

But if it's coded in c/++, why would you use a disassembler?

Quite simple answer:  the C/C++ is LONG gone.  When the compiler generates its intermediate code (which is then handed off to the back end for assembly generation) it throws away the spelling and symbol tables because they are no longer needed.  Also, unless you actually knew what compiler was used to create the binary AND you knew exactly how it generated code, you'd never be able to get the exact original structure of the program, anyway.

 

[halkun]

Not only that, the compiler acually changes the code such as unrolling loops and doing hedious things with the CPU registers to make the system faster...

Here, let me show you something from my object dumper

Code: [Select]

ff7.exe:     file format efi-app-ia32ff7.exearchitecture: i386, flags 0x0000010a:EXEC_P, HAS_DEBUG, D_PAGEDstart address 0x000000000040b6a0 Characteristics 0x10f        relocations stripped        executable        line numbers stripped        symbols stripped        32 bit words

Now, let me show you how to read this...

"relocations stripped" means that the data to relocate the code to another memory address has been deleted from the file and can not be done.

"executable" means that the program can run.

"line numbers stripped" means that the order the commands have been written have been deleted from the file. The program just runs things "one right after another" anyway so it's not required.

"symbols stripped" means that all filenames, command names, function names, and variable names have been deleted. Computers don't use names to refrence things anyway, just numbers. So to us we call "do damage" and subtract "damage power" from "armor value". To a computer just calls function 27328 and then subtracts variable 37392 from variable 8765.

It doesn't care what anything is called, as long as it's the right one.

"32 bit words" means it's uses 32 bit registers. (It's a 32 bit program)

We learn by experimenting. We use the scientific menthod to find things. it works like this.

1) State an hypothesis on how you think something works.

2) Run the program normally.

3) Observe.

4) Back up your original program/data (This is the control, the one "that works")

5) Change something that tests your hypothesis.

6) Run the program again

7) observe the changes

8) Is your hypothesis correct?
a--- If it is, record your theory and go to step 1
b--- If not, change your hypothesis and go to step 1

The thing is we don't *KNOW* how it works. It's all an educated guess that is supported by experimentation. That's really it.

 

[Kohan]

So you're saying that figuring out that, when using a Pepio Nut in breeding, if the Max Dash is less than 4000, there is a 1/128 chance of making it 4000, 1/128 chance of making it 4100, 2/128 of making it 4200, 3/128 of making it 4300, 1/128 of making it 4500, and 20/128 of leaving it alone, setting Dash to Max Dash, and then subtracting 6 random byte values, that was all based on our incredible powers of deduction, and not a peep was made at the code of which theoretically does not exist?  Not trying to be picky or anything, but it seems kind of difficult that you could make such a precise assumption.

Boy this sure ain't like the good old FF V days, when it was in ASM 65816, which was hardly dis/assembled at all (the assembled syntax was very simple).  That stuff was easy to work with.  Why, oh why couldn't FF VII be made in assembly xD.  It probably would have made it smaller anyway, not to mention faster (not that speed really matters with computers of today).  If they could do it in V, they could do it in 7.

...!!!  I should SO make a mod to V that changes all the formulae to VII's.  The only problem is figuring out hit and magic formulae...  which was all I really wanted to figure out in VII'sw source anyway  

 

[L. Spiro]

But if it's coded in c/++, why would you use a disassembler?

It doesn’t matter what the language was in which it is coded; that code gets “compiled” into nothing but a list of instructions that the computer can read and understand in its own language.

C++ code means nothing to a computer.  C++ is for humans to read and understand.

You need a disassembler because that code, during the compilation process, gets thrown away and translated into machine code that the computer can quickly and easily understand.

Once this happens, nothing is left.  You don’t get variable names; you get addresses.
Values no longer have types; they can be accessed as either single bytes, two bytes, or four bytes, and can be accessed in signed or unsigned ways, and they can be accessed by the floating-pointer registers to be used as floats rather than ints, (I am purposely excluding tbytes and qwords for reasons that should be obvious).


If you want an example of how things get lost in translation, go to http://babelfish.altavista.com/ and translate something from English to Japanese, then back to English.

English is C++.
The computer only reads Japanese.
We use a translator (the compiler) to translate from our language to the computer’s.
If you want to come back from the computer to our language, you can expect a lot of information to be missing.  Since computers work entirely with numbers, the information missing from C++ to machine code is MUCH greater than the information missing from Japanese to English.
The disassembler is the tool that translates back from Japanese to English, by the way.


I hope that makes everything clear.


L. Spiro


[EDIT]In regards to the post you made while I was making this post, any peeps inside the game were made using the disassembler I mentioned above.
The point is, if you plan on looking inside anything, you best get fluent in Engrish.[/EDIT]

 

[halkun]

So you're saying that figuring out that, when using a Pepio Nut in breeding, if the Max Dash is less than 4000, there is a 1/128 chance of making it 4000, 1/128 chance of making it 4100, 2/128 of making it 4200, 3/128 of making it 4300, 1/128 of making it 4500, and 20/128 of leaving it alone, setting Dash to Max Dash, and then subtracting 6 random byte values, that was all based on our incredible powers of deduction, and not a peep was made at the code of which theoretically does not exist?  Not trying to be picky or anything, but it seems kind of difficult that you could make such a precise assumption.

Oh you will love how we were able to do this... As I helped with the inital discovery.

One of the thories we had was that every field file had a script attached to it... We never saw this script, but we knew that it was there because if we were programmers, we would have something like this. We also thought that this script might be not machine code, but a special language that Square made up to help the event programmers make the characters do what they want.

So, one day I found this cute program that DUMPED the PSX FF7 field scripts. commands like WINDOW and GOLD++ were in it's config file along with a token number and how many arguments. Alot of the commands were odd like AKIO that took seven arguments.

I admit, this was a lucky find.

So what I did was looked at the data pool that this script dumper was reading from and guessed (rightly) that that must be the field script in it's pure binary form.

When I posted this, others realized that Square probably used the same exact field script for the PC version (As the scene didn't change from the PC to the PSX one) and looked in the field files in the LGP files, and there was the exact same information.

Cool, we now found the fieldscript *DATA* in the PSX and PC versions, but didn't know how to manipulate it very well.

What I did was, using a PSX emulator, did a savestate, changed the datapool, and saw what happened.

To get the chocobo info, someone dumped the chobo farm file and read what it said..

That's it.

Simple huh?

 

[Kohan]

I understand the whole thing what with C++ being compiled making it Japanese and crap, I already knew that.  But when you say disassembler, it makes me think that it becomes Assembly language.  Does it?  Or Are there just multiple types of disassemblers that disassemble more than just x86 or 6502 or 65816 or whatever?

Cool beans with the chocobo stuff  :wink:

 

[L. Spiro]

But when you say disassembler, it makes me think that it becomes Assembly language. Does it?

It’s assembly without symbol names.  Instructions reference addresses instead of names.
Calls are made to addresses instead of function names


L. Spiro

 

[Kohan]

That's how it works just assembling Assembly, as far as I know, but perhaps I'm just used to 65816.  SNES ROM images must not have symbols and stuff ^^.  Okay, cool.

...but that doesn't answer one thing; Assembly is supposed to be faster than C/++, so if it becomes assembly after compiling it, why is it still slower?  Is it just because computers are less efficient than the human mind, organization-wise or what?

 

[L. Spiro]

Yes.


L. Spiro

 

[dziugo]

I know that I seem (seem? I am) to be "sort of unknowing of that stuff", but...

Assembly is supposed to be faster than C/++, so if it becomes assembly after compiling it, why is it still slower?

And how are you planning to run a program written in C/C++ NOT converting it to assembly (well.... machine code to be precise) first?

There will be a difference if you write a program in C/C++ and then write it again in Asm. In the first case, the compiler (a machine) is used to convert it. In the second case, it's you and your brain who will "convert" a code into assembly. And that's why the program written in Assembly language is supposed to be faster - because the machine don't know what you were trying to program and can't optimize your code that much (like changing your algorithm to some faster one) while you (probably :roll can.

Simply: You just can't assume that while writing some highly not-optimized code, the compiler will recognise your program, search for the information on the internet and find some better algorithm to make your program faster.

dziugo

 

[Kohan]

Aha, okay.  ...Sorry about the 'unknowing' thing...