IDA 7.7 database

[emoose]

22/11/05: latest database can be found at #3 (comment)

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.

---

Alternately you could always look through the different releases of the game to find the symbols, it's all mostly public info after all.

Creating a decompilation of the UHD version isn't a great place to start since a lot of the new UHD code is still mostly unknown, working on the GC version that has near-complete function symbols available for it would be a better idea.

---

Original text:

Since IDA 7.7 is available now, decided to start a new IDB with it since it might analyse things better.

Also came up with some IDAPython scripts to mark some unreferenced code as functions, since that makes it easier to compare func positions with things like CRI SDK libs & some of the console builds - unfortunately this also bloated the number of unnamed functions quite a lot, making any comparison of named vs unnamed kinda useless now since a huge amount of the unnamed funcs are never even called by the game.

(there's thousands of functions in here that are never called, the VS2010 compiler they used seems to have inlined some funcs into other functions, but then left the inlined function as it's own separate thing, not called by anything - unfortunate since we can't really name the inlined portion, and naming the unused leftover code isn't really that useful to us, oh well)

Anyway here's current ver of my DB, this should have all the func names from my 7.6 DB along with some more I found, haven't moved over all the structs like GLOBALS etc yet though, nor all the variable names, will add all those back later on:
https://mirrorace.org/m/5Oz21 (choose 1fichier link for best speed)

[nipkownix]

Oh, nice! I'll test this out once I get my hands on IDA 7.7. Thank you!

[emoose]

Labelled a bunch more functions/variables, and added lots of structs like GLOBALS, Vec etc, also changed PSVEC/PSMTX funcs to make use of Vec where it could, should improve decompilation a little.

https://mirrorace.org/m/4sK85 (use 1fichier link)

[emoose]

Oh wow, just noticed RE4VR actually has descriptions for a ton of things inside:

ESPID_00: "Generic effect"
ESPID_01: "Triangle strip effect"
ESPID_02: "Muzzle flash effect"
ESPID_03: "Line effect"
ESPID_04: "Screen filter effect"
ESPID_05: "Flickering effect"
ESPID_06: "The effect of riding a pass"
ESPID_07: "Bouncing effect on the ground"
ESPID_08: "Texture sink effect"
ESPID_09: "tail lamp"
ESPID_0a: "Spotlight effect"
ESPID_0b: "Effect of displaying at a position closer to the camera by the specified radius"
ESPID_0C: "Call EST"
ESPID_0d: "Effect of being sucked in/parted from a part"
ESPID_0e: "Simple lens flare effect"
ESPID_0f: "Negative/positive reversal effect"
ESPID_10: "Effect on the ground position"
ESPID_11: "Light control"
ESPID_12: "strip to remember the previous coordinates"
ESPID_13: "Effect that disappears when approaching the camera"
ESPID_14: "Pseudo specular effect"
ESPID_15: "The effect of being always near the camera"
ESPID_16: "Adhesive strip"
ESPID_17: "Effects on the camera coordinate system"
ESPID_18: "Blur effect"
ESPID_19: "Laser pointer line"
ESPID_1a: "Effect of connecting indirect"
ESPID_1b: "4 point designated deformation effect"
ESPID_3f: "For memory allocation"
ESPID_40: "Black fog effect"
ESPID_41: "Fog-related special action effect"
ESPID_42: "Alpha blend test"
ESPID_43: "Flame effect that disappears when the player approaches"
ESPID_44: "Sound SE"
ESPID_45: "Spread blur effect"
ESPID_46: "Glare filter effect"
ESPID_47: "Repeat effect for texture rendering"
ESPID_48: "Shaking effect"
ESPID_49: "Effect that disappears when approaching the water surface"
ESPID_4a: "Screen shaking effect"
ESPID_4b: "Animation pattern designation effect"
ESPID_4c: "Water surface control effect"
ESPID_4d: "Water shaking effect"
ESPID_4e: "cloth set"
ESPID_4f: "Effect that disappears when entering the designated area"

EFF_EM10 "Ganado"
EFF_EM12 "Ganado Villager"
EFF_EM15 "Ganado Villager"
EFF_EM16 "Ganado Villager & Bella Sisters"
EFF_EM17 "Ganado Villager"
EFF_EM18 "Merchant"
EFF_EM19 "Ganado Priest - r20D Study"
EFF_EM1A "Ganado Priest - r209 Gallery"
EFF_EM1B "Ganado Priest & Garrador - r201 Grand Hall"
EFF_EM20 "Ganado Soldier"
EFF_EM22 "Colmillos"
EFF_EM23 "Crow"
EFF_EM24 "Snake"
EFF_EM25 "Plagas C - r20F"
EFF_EM26 "Cow"
EFF_EM27 "Piranha"
EFF_EM28 "Chicken"
EFF_EM29 "Bat"
EFF_EM2A ""
EFF_EM2B "El Gigante"
EFF_EM2C "Verdugo"
EFF_EM2D "Novistador"
EFF_EM2E "Child"
EFF_EM2F "Del Lago"
EFF_EM30 "No. 0 Sadler"
EFF_EM31 "No. 0 Sadler (after transformation)"
EFF_EM32 "U3"
EFF_EM34 "No. 1 Village head before transformation"
EFF_EM35 "No. 1 Village head after transformation"
EFF_EM36 "Regenerator & Iron Maiden"
EFF_EM38 "No. 2 After Salazar transformation"
EFF_EM39 "No. 3 Krauser before transformation"
EFF_EM3A
EFF_EM3B "Reconnaissance aircraft SEEKER"
EFF_EM3C "Armadura"
EFF_EM3D "helicopter"
EFF_EM3E ""
EFF_EM3F "Sadler Ada Scenario Boss"
EFF_EM4B ""
EFF_EM4E "Cannon"

Lots more than that too, the Bio4PrintUtils funcs seem pretty interesting.

E: Some of the EMs that were missing from there:

• Em00: Player
• Em03: Ashley
• Em04: Luis
• Em05: Ashley2
• Em06: Hunk
• Em07: Police
• Em0A: Krauser
• Em0C: Ashley3
• Em0D: Wesker
• Em0E: PlJetSki
• Em0F: PlBoat
• Em11/Em13/Em14/Em1C-Em20: Ganado
• Em21: Dog
• Em33: InsectBossEvent
• Em37: No2
• Em40-Em4B: Ganado
• Em4b: HoudaiCannon
• Em4e: HoudaiGatling

[nipkownix]

sub_859810() checks if both QTE keys are pressed in the Salazar statue section. Two instances: one inside the tower, and another when running on the bridge outside. Both look like this:

Not sure what they use for the other QTE sections, but I wonder why they created a separate func to use here. Might be worth naming it, maybe?

Edit: Seems the boulder QTE uses cActionButton::checkButton, which makes more sense. Maybe they created that other function for Salazar's QTE because cActionButton::checkButton has a random chance of picking either Trigger R + Trigger L or X + A, but they wanted to always use Trigger R + Trigger L on Salazar's QTE. Hmm.

[emoose]

Tried checking for a proper name for that func but couldn't find much, PS2/GC seems to have inlined it into the playerRunMoveXXX funcs instead, I guess maybe the WPadMode check that was added in Wii ver probably stopped it getting inlined, VR doesn't seem to have any trace of it though unfortunately, seems they changed playerRunMoveXXX to use something from UE4 instead.

Looks like it's only used specifically for r226_playerRunMoveXXX stuff, I guess something like r226_playerRunCheckQTE_maybe should be descriptive enough (_maybe to note that it's not actual name)

(btw I sent you an email about something, probably got caught in spam though)

[emoose]

Been a while since last update here, added a bunch more structs like cPlayer / cPlLeon / etc, named some more funcs, the usual: https://mirrorace.org/m/1L26i

Compressed size went from ~14MB to ~37MB so I guess there was quite a bit added, huh.

In case anyone here reading this missed it, I'm currently looking for any other RE4 dev builds that include symbols, might have something interesting in exchange, see #4

[emoose]

Found something interesting out, seems the RE4 engine was shared with a bunch of Capcom early-00 titles, P.N.03 & Haunting Ground both seem to use similar rXXX / EmXX / EspXX names, and God Hand (Clover Studio) also seems to share similarities too.

There's a proto of PN03 that does contain a pretty detailed .map file, but a lot of functions don't seem to match addrs properly... good chance the map might be for a different build, too bad. (there is a .sym file similar to RE4 GC debug .sym, but format is slightly different so haven't checked that out yet.)

God Hand seems to contain similar data to RE4 PS2 build, with a .sndata section in the elf with symbols for some funcs, sadly doesn't seem to contain any kind of structs though.

Haven't looked at Haunting Ground yet, I'll update this once I do. (E: doesn't seem like the proto has .sndata section, from the strings I can see it looks pretty different to the other RE4-engine games, so maybe this isn't actually based on it)

Overall kinda interesting but not that useful, was mostly hoping to find something that contains structs with it, maybe there's other titles I didn't list here that also share the engine though, will have to try looking around some more (if anyone knows any others please let me know!)

[nipkownix]

The Wii version of Dead Rising also uses the RE4 engine, if I'm not mistaken.

(Sent you an email btw, not sure if you received it)

[laymonage]

Does the first Devil May Cry use the same engine? I mean, that was originally going to be RE4, so maybe there's something in it.

[emoose]

Oh wow, seems Viewtiful Joe PS2 is also partly based on the same engine - and the Jul 1 2004 proto actually contains structs inside 😱

Not sure how much is similar between them though, looks like some lower level things are shared, but doesn't look like it has stuff like cModel / cPlayer / etc ...

Here's what I got out of it, it used an ancient way of storing symbols inside .mdebug section, not many tools around that support it, eventually got something working though:
ViewtifulJoe-2004-07-01-mdebug.zip

Does the first Devil May Cry use the same engine? I mean, that was originally going to be RE4, so maybe there's something in it.

Oh yeah will try looking into that soon, probably worth checking all the early-00 PS2 Capcom games really, always a chance they left stuff in the retail versions too.

E: oh sweet, viewtiful joe 2 proto also contains .mdebug data inside, maybe a little closer to RE4:
ViewtifulJoe2-2004-04-30-mdebug.zip

(E: found a later proto with more symbols: ViewtifulJoe2-2004-08-06-mdebug.zip)

Haven't checked the retail of either of those yet, will look into it later.

E2: if anyone wants to help look for other games, searching "tagMOTION_INFO" in the executable/ISO should be a good way to tell if symbols are included or not.

[emoose]

Been a while since last update, can't remember everything that's been added, there's PlayerType & ActBtn enums here which should help reverse stuff related to them (cActionButton::set etc), the def of those is below for anyone interested.

Named a few more funcs recently as well, here's latest IDB: https://mirrorace.org/m/15vhb
Some reason this compressed much smaller than the last one I posted, weird.

PlayerTypes came from GC debug which had a table for them, not sure if later ports might have added anything to it, the ones that are here mostly seem to match up with code for those charas though.

enum PlayerType : unsigned __int8
{
  PlayerType_Leon = 0x0,
  PlayerType_Ashley = 0x1,
  PlayerType_Ada = 0x2,
  PlayerType_Hunk = 0x3,
  PlayerType_Krauser = 0x4,
  PlayerType_Wesker = 0x5,
  PlayerType_LeonAshley = 0x6,
};

enum ActBtnText : unsigned __int8
{
  ActBtn_Talk = 0x0,
  ActBtn_Check = 0x1,
  ActBtn_JumpOut = 0x2,
  ActBtn_JumpIn = 0x3,
  ActBtn_JumpDown = 0x4,
  ActBtn_JumpOver = 0x5,
  ActBtn_Push = 0x6,
  ActBtn_Kick = 0x7,
  ActBtn_ClimbUp = 0x8,
  ActBtn_ClimbDown = 0x9,
  ActBtn_KnockDown = 0xA,
  ActBtn_RaiseUp = 0xB,
  ActBtn_Jump = 0xC,
  ActBtn_Look = 0xD,
  ActBtn_LookDown = 0xE,
  ActBtn_BackToTheWall = 0xF,
  ActBtn_Open = 0x10,
  ActBtn_Swim = 0x11,
  ActBtn_JumpOver2 = 0x12,
  ActBtn_Crouch = 0x13,
  ActBtn_Operate = 0x14,
  ActBtn_Help = 0x15,
  ActBtn_Piggyback = 0x16,
  ActBtn_Throw = 0x17,
  ActBtn_Sprint = 0x18,
  ActBtn_Climb = 0x19,
  ActBtn_Jump2 = 0x1A,
  ActBtn_SlideDown = 0x1B,
  ActBtn_Catch = 0x1C,
  ActBtn_PullUp = 0x1D,
  ActBtn_Wait = 0x1E,
  ActBtn_StandBack = 0x1F,
  ActBtn_Hide = 0x20,
  ActBtn_FollowMe = 0x21,
  ActBtn_GiveMeAHand = 0x22,
  ActBtn_GetOn = 0x23,
  ActBtn_GetOff = 0x24,
  ActBtn_Dodge = 0x25,
  ActBtn_Hide2 = 0x26,
  ActBtn_Crawl = 0x27,
  ActBtn_Take = 0x28,
  ActBtn_Cut = 0x29,
  ActBtn_Rotate = 0x2A,
  ActBtn_ShakeOff = 0x2B,
  ActBtn_Suplex = 0x2C,
  ActBtn_Dummy = 0x2D,
  ActBtn_Begin = 0x2E,
  ActBtn_Save = 0x2F,
  ActBtn_Unk48 = 0x30,
  ActBtn_Accelerate = 0x31,
  ActBtn_Accelerate2 = 0x32,
  ActBtn_SendAshley = 0x33,
  ActBtn_QuestionMark = 0x34,
  ActBtn_KnockOver = 0x35,
  ActBtn_Respond = 0x36,
  ActBtn_Infiltrate = 0x37,
  ActBtn_FanKick = 0x38,
  ActBtn_BackKick = 0x39,
  ActBtn_Knee = 0x3A,
  ActBtn_NeckBreaker = 0x3B,
  ActBtn_ThrustPunch = 0x3C,
  ActBtn_ChikyoChagi = 0x3D,
  ActBtn_Jump3 = 0x3E,
  ActBtn_Ring = 0x3F,
  ActBtn_HopDown = 0x40,
  ActBtn_Fire = 0x41,
  ActBtn_Rotate2 = 0x42,
  ActBtn_HookShot = 0x43,
  ActBtn_aaaStart = 0x44,
  ActBtn_MessageStart = 0x80,
  ActBtn_Dummy2 = 0x88,
  ActBtn_Zoom = 0x95,
  ActBtn_Look2 = 0xA3,
  ActBtn_MessageEnd = 0xB6,
};

[emoose]

Added ~346 funcs, ~108 structs/enums 😄

(bringing us up to 17466 out of 24603 funcs named)

Download (use 1fichier link): https://mirrorace.org/m/59I07

[emoose]

Another update, added 1094 funcs, 61 structs/enums (and ~3200 win32/xaudio related structs)

18560/24784 funcs named (82% of in-use funcs 😄)

Download (use 1fichier link): https://mirrorace.org/m/4tR98

Large part of the new names are just Criware internal stuff, but there's a couple new game func names added too, added some structs for a few cEmXX classes as well, and did a little work on the audio related code.

The X3DAudio_UpdatePan_mb func seems interesting, looks like they're only setting position of the listener based on something, the emitter is just left as default, wonder if it could be improved at all.

[nipkownix]

@emoose, how correct is the KEY_BTN enum, btw?
I wanted to use the game's own functions for key trig check/press check, but it doesn't seem to be working reliably here.

My code:

static uint32_t* ptrKey_btn_on;
static uint32_t* ptrKey_btn_trg;

auto pattern = hook::pattern("a1 ? ? ? ? 33 c9 83 e0 ? 83 3d");
ptrKey_btn_on = *pattern.count(1).get(0).get<uint32_t*>(1);

pattern = hook::pattern("a1 ? ? ? ? 25 ? ? ? ? 0b c1 74 ? 88 0d");
ptrKey_btn_trg = *pattern.count(1).get(0).get<uint32_t*>(1);

--__--__--

int Key_btn_on_lo()
{
	return *(int*)(ptrKey_btn_on);
}

int Key_btn_trg_lo()
{
	return *(int*)(ptrKey_btn_trg);
}

KEY_KAMAE does show up as 0x10, which seems to be correct, but KEY_RELOCKON shows up as 0x40020, not 0x20. I might be doing something wrong, though, since I never tried to do anything like this.

Gotta say I also don't understand the difference of the .hi and .lo stuff, so that might have something to do with it.

[emoose]

The keys are treated as bitfields, so I guess 0x40020 would be 0x40000 | 0x20 (KEY_B | KEY_RELOCKON), you should be able to check it like if((Key_btn_trg_lo() & KEY_RELOCKON) == KEY_RELOCKON)

The hi/lo stuff is a hack really, IDA doesn't seem to work with 64-bit bitfields properly, so had to split them into two 32-bit ones to get it to display things right, probably better to ignore the hi/lo stuff in our code and use uint64_t to access them instead.

[nipkownix]

Ahhh, that makes sense! Thanks!

[emoose]

Another update, added ~77 structs (mostly cEmXX - almost all the cEm* structs are added now, including the awful cEm10, only 1 or 2 missing now AFAIK), and a couple extra functions, DB size increased by 60MB 😸 : https://mirrorace.org/m/16heg

Should probably mention but the structs are mostly just skeletons, tried to map out the correct field types for them (short/int/pointer etc), but haven't actually named that many fields yet, if anyone works out any names for anything feel free to post it!

[nipkownix]

Not very important, but SYSTEM_SAVE's field_B is keyConfigType_B. Can be 0, 1 or 2, based on the user's config for the controller (xinput only, I believe).

[emoose]

BTW here's a PDB generated with https://github.com/Mixaill/FakePDB, Cheat Engine seems to load it in fine, and VS when debugging too, pretty sweet!

bio4_110_fakepdb_220712.zip

(if it doesn't load in you might need to set relocations stripped flag so EXE always loads at 0x400000, haven't tried it without that yet)

[nipkownix]

Ah, cool! I tried FakePDB a couple of days ago, but I wasn't aware about the stripped flag thing. Without it, functions are named incorrectly. Seems the flag is needed.

[emoose]

Time for another update, massively improved a bunch of structs with actual field names now, and managed to find names for some more functions too (mostly unused ones, but even unused ones can tell us something!)

Pretty much all the non-numbered cEm classes should be detailed (and luckily also cEm10), some of the cObj classes are filled too, but still a few I need to add in.

19119/24804 funcs named (83% of in-use funcs) - afaik the main parts missing now are either PC/X360 port related, or code for rooms added in PS2+ releases (sadly we don't really have good symbols for the PS2 REL files ;_;)

Download: https://mirrorace.org/m/16r5b (use 1fichier for best speed)

Also includes a full HexRays .c output file for those without IDA/HexRays, a FakePDB .pdb file, and an IDAPython script that can be used to remove unused functions if you just want to focus on things that are actually used.

There are still a few mysteries I haven't figured out here though:

• what data is loaded from the REL files? saw some mentions that changing REL data does affect game, but can't be code since REL just contains PowerPC stuff (and code was mostly all moved into main EXE), looks like MODULE_DAT struct (filled by readEm / readEmData) does contain something to do with bss section data, haven't found where that gets used though.
• I've seen a bunch of places providing a cObj instance to something that takes in a cEm parameter, would make sense if cObj inherited from cEm, but seems that it doesn't, both are separately inheriting from cModel, so providing cObj to something that expects cEm doesn't make sense - if the function expecting cEm wanted to access a cEm-only field, it wouldn't exist in the cObj instance, and would just end up reading random data. Not sure what's going on there.

Many thanks to MeganGrass for huge assistance with this!

[FutonGama]

Nice to see this good discoveries! You are inteligent asf.

[emoose]

Hosting an IDArling server to help sync stuff between us, see #16 for how to set it up :)

[emoose]

Been a little while since last update here, was mostly posting updates to IDArling server for a while, the way it syncs stuff can be really slow tho, so ended up going back to how I did it before (if you changed anything on IDArling in past month or so it won't be in this DB, sorry)

On the bright side, managed to name a bunch more functions/structs/variables (19392/24991 funcs named), and also looked into the QLOC kb/mouse code a little too, seems they added 3 classes for handling it which weren't too hard to map out, so now PadRead and other kb/m code should be a little easier to read.

Added params/sigs to a bunch of funcs from the symbols too so hex-rays should be a lot more accurate now, still a ton of functions left to update though...

There's also a lot more names still to add as well, seems some of the Seperate Ways r5xx rooms (and some weird r12x rooms) almost perfectly duplicate code from earlier rooms, we don't have symbols for r5xx rooms unfortunately, but hopefully can copy the names from the original room they based it on, need to look into that some more.

Anyway, latest IDB+PDB+C can be found here: https://www.mediafire.com/file/ahwu2jpremmyqdi/bio4-220918.zip/file

[emoose]

Just found out something about how UDAS data gets loaded in, when you see something like:

pOption_50 is pointing to near the start of a UDAS file (it can be any block of memory though, pOption_50 is just the data for plXX.udas, can usually find the DvdReadN call that reads the data in to find what file it uses)

It's actually pointing to the start of the UDAS offset table, in pl00.udas that's at 0x400, but I think it can vary between files.

You'd think the [0x62] / [0x63] would mean it's loading the 0x62/0x63rd file from that table (fortunately UDAS extractors do usually include the file index in the extracted filenames too, at least SoP extractor does) - but that 0x62/0x63 is actually indexed from the exact start of the offset table, which starts with a 0x10 byte header that just includes file count inside it (AFAIK)

0x10 byte header means 4 uint32s, so to find the actual file index you need to remove 4 from the index in the code, so 0x62 - 4 = 0x5E / 94, 0x63 - 4 = 0x5F / 95 - then if you look at the extracted UDAS contents, pl00_094 & pl00_095 contains the data that the code was reading :)

(alternatively, the asm that accesses it gives you the offset into the table, so you could just remove 0x10 from that and then divide by 4 to get the index - some hex rays code might also only show the offset instead of index too, so it's good to know :p)

I think the 0x10 byte header could change size between UDAS files though, so you might need to check the UDAS data itself first - does seem the code that reads from the UDAS is pretty tightly coupled to each UDAS itself, since it's using actual file indexes instead of filenames, I'm guessing the tool that creates the UDAS maybe spits out a header that has all the indexes (#define DAS_PLAYERFACE0_BIN 0x5E or something), and the EXE build includes that header.

This could maybe be done in reverse to search for code that uses a certain file too, just multiply index by 4, add 0x10, then use alt+b to search for the result (endian-swapped), might work for some unique indexes, or maybe try searching the hex-rays .c.

[emoose]

Another update, nothing too major though, mostly just been updating function prototypes with the proper names/types from PS2 symbols (processed ~140 out of ~256 .cpp files we have symbols for so far), should help clean up the decompiler output a bit.

Still need to go through the extra campaign room (r5xx etc) funcs that were based on rooms in the main campaign and copy func names over though (if anyone happens to have a list of room numbers that were copied from main campaign + room number they were copied from it'd really help a lot, haven't played much of the bonus campaigns myself...)

Download: (see below post)

[emoose]

Very minor update, improved some stuff around cEmXX funcs: https://www.mediafire.com/file/o23w1aywz8a3cji/bio4-221007.zip/file

[emoose]

Been meaning to post new update for a while, finally got through all the PS2 function prototypes (AFAIK at least, may have missed some by accident), so now the main engine parts of the EXE should mostly have full function signatures/parameters set up (along with any structs they use), also documented some of the sound engine stuff a bit more too.

PS2 symbols didn't contain anything about rooms/weps/Ems/etc though, so there's still a lot of unnamed things there, was able to copy across names for R5XX/R6XX rooms which were clones of rooms we already had names for though.

Also added Rxxx_WORK_mb structs for all the rooms too, seems to be some kind of struct that holds data about the rooms state (allocated by the rooms RxxxInit func), seems each room stores different things there, took a while but been able to work out most of the types for the fields inside, haven't really added names for those fields yet though.

Also was able to find some global var names from RE4VR too which filled in a few unknowns.

E: read the license terms mentioned in the first post before downloading: #3
20181/25110 funcs named (80% of total, or 86% of in use funcs)
Download (IDB+PDB+C): https://www.mediafire.com/file/4t4l7xo7rjrrh6a/bio4-221105.zip/file

[nipkownix]

Got two more funcs names from Separate Ways:

sub_7A1BE0 = r502_OpenCloseCover (modified version of r108_openCover, but this one also has code to close it)
sub_7A3D40 = r502_execPuzzle (modified version with r108_execPuzzle with a bunch more stuff)

[GaryFrazier]

Hi, sorry if this is the wrong place, I think I got the remove unused funcs script working in ghidra, unsure if it fully worked though. I don't have IDA Pro so I'm using what I can in ghidra.

# Get the current program
currentProgram = state.getCurrentProgram()

offs_section_text = 0x401000
offs_section_psfd00 = 0xB08000
offs_section_rdata = 0xB0C000
offs_section_rdata_st = "0xB0C000"
offs_section_data = 0xBF3000
offs_section_idata = 0x171079C

offs_thunks_end = 0x41D7E0
offs_thunks_end_st = "0x41D7E0"

startAddress = currentProgram.getAddressFactory().getAddress(offs_thunks_end_st)
endAddress = currentProgram.getAddressFactory().getAddress(offs_section_rdata_st)

# Iterate through all functions within the given address range
functionManager = currentProgram.getFunctionManager()
functionIterator = functionManager.getFunctions(startAddress, True)

for funcea in functionIterator:
    if funcea.getEntryPoint().compareTo(endAddress) < 0:
        xref_count = 0
        thunk_addr = 0
      
        refList = currentProgram.getReferenceManager().getReferencesTo(funcea.getEntryPoint())
        
        # Do something with the references
        for xref in refList:
            print("Function", funcea.getName(), "is referenced by", xref.getFromAddress())
            xref_count = xref_count + 1
        
            if xref.getFromAddress() < offs_thunks_end:
              # this xref is just a thunk, remove it from count
              xref_count = xref_count - 1
              thunk_addr = xref.getFromAddress()
          
            refList2 = currentProgram.getReferenceManager().getReferencesTo(xref.getFromAddress())
            for xref2 in refList2:
              xref_count = xref_count + 1
        
        if xref_count == 0:
            functionManager.removeFunction(funcea.getEntryPoint())
            if thunk_addr > 0:
                function = functionManager.getFunctionAt(thunk_addr)
                functionManager.removeFunction(function.getEntryPoint())

[Mister-Curious]

I know I am late to the party on this Database, but it seems all the links for this are now gone. We haven't seen or heard from you in quite some time now. Are you still lurking around?

[emoose]

The links all seem to work on my side, they're on my mediafire acct so shouldn't expire any time soon, think I remember you had issues with the mediafire links before though, maybe something is blocking your access?

I'm still interested in working on RE4, but think re4make & the crashing issues re4_tweaks started having have deflated a lot of the motivation around it, for me at least anyway...
Really I'm a little wary of adding any more to it now in case even more issues show up.

[nipkownix]

I've been a bit absent due to work, but are these crashes really caused by us? Maybe simplifying things a bit could help. Removing the entire dxvk stuff from the project, for example, isn't something I'm against if that could help make things a bit more stable.

[Mister-Curious]

@emoose nice to hear you are still around! Thanks for the speedy reply. Do you mind sending a link for that on here. All the links I had weren't media fire.

Cheers!