Halkun is back! Prepair to be r0xored.

  • Thread starter Thread starter halkun
  • Start date Start date
Status
Not open for further replies.
H

halkun

Guest
Once upon a time....

(Wow, that's how it always starts, huh ^_^)

Once upon a time, almost four yars ago, I came to this board and tought a little about how to reverse programs. I, like yourselfs, enjoy picking apart things and learning more about the world.

This is the basis of science.

I tought a little bit about how to look at data in diffrent ways. I showed how programmers can be lazy (and the contract workers for the FF7 port to the PC doublely so). The therory being if programmers were really motivated, they woudn't of persued a carrer sitting on thier butts for more than 8 hours a day.

Between the fact that programmers are lazy, and computers don't care, this causes arifacts that, over time, can tell a story about how things came to be.

We are, in fact, data archiologists.

So it has come, where I have decided to grab my shovel and bit-bucket and see what I can find. Sometimes, when people are busing blowing the dust off a particular rock, or examining the attibutes of some long cast out stone, it's easy to lose the big picture.

To help, in the little way I can, I have decided to assist and paint for you not a complete picture, but something that may assist you. If not, it's at least intresting as hell to look at.

I gave you the following....

Code: [Select]
Code: 
c:\ff7\chocobo\ch_app.cppc:\ff7\chocobo\ch_chr.cppc:\ff7\chocobo\ch_ddraw.cppc:\ff7\chocobo\ch_init.cppc:\ff7\coaster\psxdata_c.cppc:\ff7\condor\cd_app.cppc:\ff7\condor\cd_ddraw.cppc:\ff7\condor\cd_init.cppc:\ff7\condor\cd_tim.cppc:\ff7\field\src\ad_app.cppc:\ff7\field\src\ad_bk.cppc:\ff7\field\src\ad_cdr.cppc:\ff7\field\src\ad_data.cppc:\ff7\field\src\ad_ddraw.cppc:\ff7\field\src\ad_human.cppc:\ff7\field\src\ad_image.cppc:\ff7\field\src\ad_list.cppc:\ff7\field\src\ad_list.cppc:\ff7\field\src\ad_obj.cppc:\ff7\field\src\ad_pal.cppc:\ff7\field\src\ad_tile.cppc:\ff7\field\src\tutaddr.cppc:\ff7\highway\psxdata.cppc:\ff7\snobo\memory.cppc:\ff7\snobo\tmd.cppc:\ff7\src\battle\b3ddata.cppc:\ff7\src\battle\battle.cppc:\ff7\src\battle\battle3d\amptoanm.cppc:\ff7\src\battle\battle3d\bdata.cppc:\ff7\src\battle\battle3d\char.cppc:\ff7\src\battle\battle3d\enemy.cppc:\ff7\src\battle\battle3d\limitbrk.cppc:\ff7\src\battle\battle3d\lmd.cppc:\ff7\src\battle\battle3d\lmd.cppc:\ff7\src\battle\battle3d\mdl.cppc:\ff7\src\battle\battle3d\stage.cppc:\ff7\src\battle\battle3d\stage.cppc:\ff7\src\battle\myoshiok\lasboss3.cppc:\ff7\src\battle\yama\coloss.cppc:\ff7\src\battle\yama\init.cppc:\ff7\src\battle\yama\inits.cppc:\ff7\src\battle\yasui\deadsef.cppc:\ff7\src\battle\yasui\sting.cppc:\ff7\src\battle\yasui\vahamut0.cppc:\ff7\src\credits\credfile.cppc:\ff7\src\main\initpath.cppc:\ff7\src\main\main.cppc:\ff7\src\menu\btlmenu\english\callback.cppc:\ff7\src\menu\english\loadmenu.cppc:\ff7\src\movie\sm_movie.cppc:\ff7\src\wm\wmdefine.cppc:\ff7\src\wm\wmfile.cppc:\lib\h\graphics\sw\offset.hppc:\lib\src\file\direct.cppc:\lib\src\file\file.cppc:\lib\src\file\is_lib.cppc:\lib\src\file\registry.cppc:\lib\src\file\smcdfile.cppc:\lib\src\graphics\directx.cppc:\lib\src\graphics\driver.cppc:\lib\src\graphics\dx_3d2d.cppc:\lib\src\graphics\dx_dbg.cppc:\lib\src\graphics\dx_graph.cppc:\lib\src\graphics\dx_mat.cppc:\lib\src\graphics\dx_mesh.cppc:\lib\src\graphics\dx_pal.cppc:\lib\src\graphics\dx_rend.cppc:\lib\src\graphics\dx_rend.cppc:\lib\src\graphics\dx_rend5.cppc:\lib\src\graphics\dx_rend5.cppc:\lib\src\graphics\dx_rendi.cppc:\lib\src\graphics\dx_rendi.cppc:\lib\src\graphics\dx_rendx.cppc:\lib\src\graphics\dx_sfx.cppc:\lib\src\graphics\dx_spr.cppc:\lib\src\graphics\dx_stat.cppc:\lib\src\graphics\dx_view.cppc:\lib\src\graphics\g_drv.cppc:\lib\src\graphics\instance.cppc:\lib\src\graphics\light.cppc:\lib\src\graphics\psx.cppc:\lib\src\graphics\psxgraph.cppc:\lib\src\graphics\render.cppc:\lib\src\graphics\shp.cppc:\lib\src\graphics\sw\sw.cppc:\lib\src\graphics\sw\sw.cppc:\lib\src\graphics\sw\sw_vert.cppc:\lib\src\graphics\sw\z.cppc:\lib\src\input\input.cppc:\lib\src\list\list.cppc:\lib\src\mem\heap.cppc:\lib\src\mem\mem.cppc:\lib\src\movie\movie.cppc:\lib\src\polygon\anm.cppc:\lib\src\polygon\plytopd.cppc:\lib\src\polygon\polygon.cppc:\lib\src\polygon\rsd.cppc:\lib\src\polygon\tim.cppc:\lib\src\sort\sort.cppc:\lib\src\sound\acm.cppc:\lib\src\sound\creative\sfutils.cppc:\lib\src\sound\dx_snd.cppc:\lib\src\sound\midi1.cppc:\lib\src\sound\sound.cppc:\lib\src\stack\stack.cppc:\lib\src\thread\thread.cppc:\lib\src\token\token.cppc:\lib\src\trans\trans.cpp

I'm not done yet, I think I have some enums and reconstucted filenames...

This is just the beginning, I have made some rather intresting discoveries that I may share later. I have to experiment first...

That and buy another copy of FF7 PC ^_^
 
Which .LGP file is that Halkun?
And what tools are available for unpacking the .LGP files?
 
for unpacking lgp files go to www.ficedula.co.uk
but these arent files
they are references to portions of source code, broken down in the original files they where programmed from.
i suppose looking for these "filenames" inside a decompiled FF7.exe (or using a hex editor) you might be able to locate the area that you need to work on in FF7 pc terms.

I hope im right, someone correct me
 
They're strings extracted from FF7.exe. Thanks to how FF7 for PC was compiled (it actually looks like debug mode!), every time a memory allocation (or similar operation) is performed, both the name of the source file and the current line in the source code is included as part of the function call, for debugging purposes. Unfortunately there are lots of files which doesn't use memory allocation or only use it indirectly through other translation units, so they're not included in the list. You can however scan through FF7.exe with a disassembler and be able to split the code up in the original translation units, and retrieve the original file name for a great deal of them thanks to these references.
 
Wow halkin,

That is an interesting post/discovery you have made. I welcome you back and look forward to learning more about the techniques you use..

How did you get those filenames? Even running strip on the executable and such wouldn't give you that much information.. unless they shipped the an executable with debugging symbols included.
 
It's still a pain to look through all the assembler though.
 
<Professor Farnsworth>
Good news Everybody!
</Professor Farnsworth>

I got disk 1 of the PSX FF7 and will be running it though an R3000 disassembler muchly. It will be intresting to see where what is where.

Also Nori-pyon, I'll have to write you an email! I haven't talked to you in ages!

I'm off now to push some data around for a bit...
 
halkun,

which R3000 disassembler are you using? Maybe you have a better one then me.. I'm currently using the one from MESS.

Thanks..
 
haven't picked one yet. I would love to have one I can trace through code with. The the old one on PSXEmu was cool.
 
haven't picked one yet. I would love to have one I can trace through code with. The the old one on PSXEmu was cool.
Click to expand...

Try compiling PCSX in debug version for your abuse.. I mean use.
:)

Cyb
 
Bah, Pcsx is teh Sux0r. The only really cool thing is that it's open source, but it's not written very well. My compiler has fits with it and the precompiled bin bombes out.

I wish ePSXe allowed you access the the dubugger with a command line switch. The devel version has one, but the public version is lacking.

Also my fav debugger on psxdev.de is offline. What a drag.

I can pick through the PC version and compare/contrast with the psx datafiles.

I have an itching to figure out how the filesystem obfuscation system works. It's pretty bad that the PC version has the tables in plain text (well, they are backwords, files, then the directory) Once I develop a logical grouping of data, it will make it much easier to "atomize" the data and then systemataclly decode them.

Whoever did the PC conversion did an absolutly horrific job!

The debug data is stripped out, because that resourse is gone, a PE debugger has no access to any symbols other than what's imported.

The really really sad thing is that it seems no one on the PC deveopment staff has ever heard of a an #IFDEF precompiler directive....

I can understand that it's nice to have the engine toss out what it's doing to stdio so you can follow along. However, when you want to make a production biniary, using #IFDEF will allow the compiler to skip whole blocks of unneeded code.

the command "cc -DDEBUG_CODE whatever.c " would automagicly include any debugging code you put into your .c file within a #IFDEF DEBUG_CODE directive. Not using the -D switch will cause the precompiler to *SKIP IT* and not allow it into the final binary. Wow! Even I know that! (Though I may have the sentax wrong)

Not only that, they used printf strings to spill out debugging data. So now not only do I have the names of very important engine varibles and concepts, I also have thier format. Here a quick example...

(In c:\lib\src\polygon\tim.cpp)
%s total palettes %d entries per palette %d
tim file %s
palette index %d rgba %2x %2x %2x %2x

This tell me that the textures have mutiple palettes and are accessed by a numerical index (Not a pointer) and it uses a red, green, blue, and alpha channel that ranges from 0-255

It's not the code, but it's enough.

I'm really keen on finding the scripting tolkens for the magics. Lucky for us, FF7's magics all start small and get more complex. You can start with cure, which repeats the same green (monochomatic?) sprite sequence about 8 times around a chracter and plays a single sound. It's the same sequence used for "potion"

But I bet the same scripter that runs "cure" runs "supernova"

Where is the script?

It's everything not a tim, spr, or rsd. in a PSX bin file ^_^ I betcha it's in the beginning somewhere...

Anyway enough theroies...

I'm gonna play some ff7 for a little bit.
 
Could "supernova" be using the scripter from "cure", but simply using parts from other magics/summons/attacks?


And I hope the data i sent you helps.
 
The really really sad thing is that it seems no one on the PC deveopment staff has ever heard of a an #IFDEF precompiler directive....

I can understand that it's nice to have the engine toss out what it's doing to stdio so you can follow along. However, when you want to make a production biniary, using #IFDEF will allow the compiler to skip whole blocks of unneeded code.

the command "cc -DDEBUG_CODE whatever.c " would automagicly include any debugging code you put into your .c file within a #IFDEF DEBUG_CODE directive. Not using the -D switch will cause the precompiler to *SKIP IT* and not allow it into the final binary. Wow! Even I know that! (Though I may have the sentax wrong)

Not only that, they used printf strings to spill out debugging data. So now not only do I have the names of very important engine varibles and concepts, I also have thier format. Here a quick example...
Click to expand...

It's still quite possible that they may have used #IFDEF.. a compiled binary wouldn't give us a yes or no answer to that..  Judging from the binary though, I guess they did ship a debug build instead of one compiled for release mode.

Off topic, but a lot of games are released in a debug mode.. Even games like GTA (on the PS2) have loads of text and information inside the binaries.. The GTA data is even in easy to read text files.

Oh, I couldn't get pcsx to compile under Mingw or Visual C++ 6.  It seems to have errors with plugins.h or plugin.h   at the CALLBACK* lines..

I'll have to see if I can compile it on Linux some time in the future.

Anyways, I know my comments bring no further help for you.. so I'll just end my post with a..

Good work halkun.
 
Yup many of game executables are released in Debug mode. Dunno why. Maybe programmers dont know how to switch to Release mode :) Or, its like in the company where I worked before Its like "I've made these new changes which were needed, Debug runs ok, but Release crashes somewhere in the cf#f4$as ... and product should be shipped tomorrow ! There is no time to fix Release, we have to ship Debug and then later on we will ship patch for it"

Programmers aren't so much lazy (well, in general :) ) but they are pressed by time/deadlines/bosses/users.

And what tools are available for unpacking the .LGP files?
Click to expand...
There is also mine tool Unmass here: http://mirex.mypage.sk/index.php?selected=1

<Professor Farnsworth>
Good news Everybody!
</Professor Farnsworth>
Click to expand...
hehe futurama roxorz ! :)
 
Bah, Pcsx is teh Sux0r. The only really cool thing is that it's open source, but it's not written very well. My compiler has fits with it and the precompiled bin bombes out.

I wish ePSXe allowed you access the the dubugger with a command line switch. The devel version has one, but the public version is lacking.

Also my fav debugger on psxdev.de is offline. What a drag.

I can pick through the PC version and compare/contrast with the psx datafiles.
Click to expand...

Well PCSX is being secretly rewritten, that's all I have to say, so that it compiles more cleanly first of all and secondly its debugger interface is GDB compatible.

If you want a broken down and hex dumped PSX battle model I can give that to you, my big problem has been getting OGL showing the textures, once that would work the rest would be easy by comparison. OGL hates me I think ;)
I suppose I should have the 'cookie' cutter plotting I am using with FF8 textures applied to FF7 textures as well (plot on a bitmap where the textures cut into the bitmap so to speak).

Cyb
 
Cyb,
 I can't get epsxe to display the VRAM anymore. I think there was a key you pushed to have it come up, but I seem to have forgotten it.

I'm runnin linux, that might be an issure.

Wasn't that a GPU plugin thing? which one was it?
 
If help with OpenGl is needed I can give some advice.
To display textures you need to load it into memory, then set it to opengl memory, then bind it when you want to use it and then to set proper texcoords for vertices.
If more details are needed then tell me.

-edit-

i have some time so I'll post brief info how to do it (in C++)

Code: [Select]
Code: 
GLuint  *textures;   // here are stored GL texture indexeslong textures_count;   //here is your number of textures that model uses// --- code for setting up textures ---//alloc place for texture indexestextures = malloc( sizeof( GLuint ) * textures_count );//generate texture id'sglGenTextures( textures_count, textures );// lets set up textures into openGl memoryfor( i=0; i<textures_count; i++ ) {  //set index of texture of which data are we going to change  glBindTexture(GL_TEXTURE_2D, texture[ i ] );  //and set data  glTexImage2D( GL_TEXTURE_2D, 0, 4, texture_size_x, texture_size_y, 0, GL_RGBA, GL_UNSIGNED_BYTE, data );  //data should be ordered bytes of red, green, blue and alpha, each taking one byte. So data size is sizex * sizey * 4  // texture filtering when zooming out  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );  // texture filering when zooming in  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);} // end of i cycle// --- displaying ---long  last_texture = -1;glEnable( GL_TEXTURE_2D );  // enable texturingglEnable( GL_BLEND ); // enable alpha texturing//displaying loop for all polygonsfor( p=0; p<polygons_size; p++ ) {  //switch texture if polygon has different then last used.  if ( polygon[ p ].texture != last_texture ) {    last_texture = polygon[ p ].texture;    if ( last_texture == NoTexture )      glBindTexture( GL_TEXTURE_2D, 0 ); // 0 means turn off texturing for this polygon    else      glBindTexture( GL_TEXTURE_2D, texture[ last_texture ] ); // set texture to use  }  //by the way, calls to glBingTexture wont do anything if they are called between glBegin() and glEnd() so take care on that.  //vertices loop  glColor3f( 1.0, 1.0, 1.0 );  glBegin( GL_TRIANGLES );  for( v=0; v<3; v++ ) {    glTexCoord2f( vert[ v ].u, vert[ v ].v );  // set texture coords for vertex    glVertex3f( vert[ v ].x, vert[ v ].y, vert[ v ].z );  // vertex coords  }  glEnd();} // end of poly loop// -- freeing --// i think this should do the trickglDeleteTextures( textures_count, textures );free( textures );
 
Status
Not open for further replies.
Back
Top