Open emoose opened 2 years ago
Named a few more funcs, filled out GLOBALS
struct types quite a bit, & added EM_LIST
struct:
Download: pc-1.1.0_enum - Copy.7z.zip
Still quite a lot to do inside GLOBALS
though, need to find accesses to gapXXXX
fields & name/type them properly (most of the remaining ones seem to be accessing structs instead of raw fields though, maybe PS2/VR version can give us names of those structs)
Had a small breakthrough: turns out the Steam release actually contains .rel files for a debug GC/Wii build for some reason!
Sadly these aren't that useful since we don't have the main executable to go with them, but it does give us debug st3_X.rel files to look at, which are pretty close to the st3_X.SYM symbols files that were included with the GC debug build (that for some reason didn't include the st3_X.rel files itself)
The SYM doesn't match up exactly, but comparing sizes of functions in the SYM against the REL does let us name some things, then it's pretty simple to port the names over to PC :) Will hopefully have an updated IDB to post here soon.
E: ahh, just realized that the st3_X files are on a second disc on GC, sadly doesn't seem that the released debug build included disc 2 with it, too bad. Maybe the GC retail second disc will match up closer to the .sym though, hm...
Updated with st3_X names (R3XXInit etc), bringing it up to ~68% named 😄
Download: pc-1.1.0_enum - Copy.7z.zip (remove .zip extension)
Seems some of the R3XX funcs call into some main.dol funcs that currently aren't named here, and since we don't have symbols for the main.dol for non-debug GC it'd be hard to work out what the name for those funcs are :/
Maybe PS2 version could give some info there, need to add support for imports to the PS2 rel loader, but not really sure how they work yet.
(would be great if debug disc 2 appears some day, would make things so much easier...)
Ah, just saw this! Nice work with those IDB files.
Named a bunch of Criware funcs (still a ton to go though >.>), fixed up the cSofdec class (also made a cSofdec struct with some fields inside, might be useful at some point), named some more memory/heap related stuff, and probably a bunch more stuff I forgot about too: pc-1.1.0_enum_latest.7z.zip (remove .zip extension)
Added some extra structs & names around the CameraBinocular
/CameraScope
/FocusAnimation
etc classes, named some of the gamepad input fields (need to try looking into how M+KB is translated though), and some more Criware crap:
pc-1.1.0_enum - Copy_latest.7z.zip
E: some more adds, started filling out PAD
struct, added PAD_BTN
enum, named some DInput8 GUIDs & related funcs:
pc-1.1.0_enum_newest.7z.zip
Oh whoops, messed something up with the Joy
/ Key
structs...
So there's (AFAIK) an array of 4 JOY
structs (0x270 bytes each) at 0xC63008, some symbols call that array Joy
, and game code seems to reach into Joy[0]
to check for inputs (I guess maybe debug build might check the other Joy indexes)
However just before the Joy[4] array, there's also some more fields related to inputs at 0xC62EF0, RE4VR seems to call this area Bio4Key
, and GC just calls it Key
- I thought this was just another JOY
struct, but it's actually too small for that, difference between start of Key
& Joy[0]
is only 0x118 bytes - in the IDBs above I just had it set as JOY
, meaning the Joy[4]
array ended up being swallowed up into the Key
field...
Weird thing is that even with it swallowed up like this, the fields didn't seem that messed up - eg. accesses to Joy[0].buttonsOn_XXX
just ended up being Key.pc_buttonsOn_XXX
, since the stuff after 0x118 in the JOY
struct seems to mostly just be a repeat (pc_
is just a guess, seemed like those fields are only set if using mouse/keyboard)
Anyway for now I've just made a separate KEY
struct with only the fields in the first 0x118 of JOY
, seems fine like this, but still not sure what's going on here... maybe Joy
is actually meant to be part of the KEY
struct (not sure why Joy
would have been exposed in symbols if so though), or maybe JOY
struct is actually something like
struct JOY {
KEY controller; // 0x118 bytes
KEY pc; // repeat, only set for lastDevice = 2?
KEY wiipad; // maybe not full KEY struct, but seems to have some similarities
}
instead, not sure yet though.
Here's fixed IDB anyway: pc-1.1.0_enum - Copy_latest.7z.zip
E: will probably start a new IDB soon with IDA 7.7, maybe has better analysis than 7.6 did.
Posted IDA 7.7 db here: https://github.com/emoose/re4-research/issues/3
(E: IDA 7.7 database at #3, will probably only update that from now on)
License: The annotations included in the IDA database, such as names, structures, and comments, are made available to you under the following terms:
You may use the information contained in the provided database/PDB/pseudo-code files to assist with game research, game modifications, and other similar projects, provided that such projects do not involve the public release of substantial parts of the provided information in another form. This restriction includes, but is not limited to, decompilation projects based on the included information, or the conversion of the provided files into a different format.
Any improvements made to the included annotations, such as newly named functions or variables, new structures, or fixes to the existing annotations, should be forwarded back to this repository whenever it is convenient to do so.
Usage of this database is restricted to individuals who hold a legal license to the UHD edition of the game on Steam.
Please note that this license only applies to the information contained in the provided files, and does not necessarily apply to any derived works or modifications that you create using this information.
These license terms can be modified upon request, please feel free to get in contact.
Figured it'd be better to link new IDBs at one place instead of posting different comments everywhere.
IDB can be found here: pc-1.1.0_enum - Copy.7z.zip (old version see posts below for latest) (remove .zip extension so that it ends with .7z, as github doesn't allow 7z uploads for some reason...)
This names ~60% of functions in the bio4.exe, and I also made a start on a struct for
pG
/Globals
(seems that struct is 0x8000+ bytes long though so would take a lot of work to label everything there... right now I'm just trying to get the correct field types inside it, haven't really named many fields yet)(if anyone has done any work on naming any vars between
bio4.exe+0x85A760
-bio4.exe+0x862E00
(1.1.0), or made any trainer that acts on that range or anything like that, please consider posting what you have, that range holds the GLOBALS struct, so any info would be appreciated!)Unfortunately there are some things that are currently unnamable: