Search the Community

Greetings everyone, Some of you might be aware that a prototype build of the cancelled Ps2 game Fear Effect 3 Inferno has been made publicly available by Sega Dreamcast Info. I have recently started to dig through the game's .WAD files, in hopes of finding more leftover content that is not accessible through normal gameplay. This might be helpful to get a better understanding of how far the Devs actually got and, (with a lot of wishful thinking) open up the possibility, for people with the right kind of expertise to build upon this vertical slice of the game. Since the game is running on the, back in the day, very popular Renderware Engine, I am more than confident that some of you fine folks will be able to crack this one. As a first approach, I started with the PCSX2 0.9.8 Texmod Method, which allows you to capture the game's geometry and textures through PCSX. While being quite an awesome tool if you want to do some 3D modelling, this method only enables you to grab assets that are actually loaded in during gameplay. Therefore, you won't find anything that you haven't already seen when playing the game normally. So no new discoveries on that front. My next intuition was to use some of the tools that have been developed for other Renderware titles such as GTA: San Andreas or Sonic Heroes. It seems that in terms of file structure, the game is built quite similar to the Ps2 Version of Rockstar's The Warriors. With Nick7's Warriors Texture Exporter I have been able to extract all the TXD files found within the Prototype build, which is already quite the win. Nevertheless, these .WAD archives contain quite a few more things that are worth extracting: Mainly the game's 3D models (.DFF), animations (.ANM) and Level Geometry (.BSP). The game's audio files might also be stored in here, but since Sega Dreamcast Info stated that the developers created a custom Playstation 2 audio module for the game, I doubt that these will be of much use for now. In that regard, it should be mentioned that no other Renderware or Game Extractor Tool, that I came across yielded any kind of usable results. This is likely due to the fact that, for some reason, Fear Effect 3 Inferno does not seem to rely on a .dir file to structure its contents. Furthermore, the nomenclature .WAD can refer to a multitude of different archive systems with absolutely no internal similarities. So no Source Engine, Id Tech or otherwise common WAD Extractors were able to produce anything from these .WAD files. Since no directory based Tool was able to decrypt these .WAD files, the only viable option I see now is to use a program like QuickBMS and extract the files based on their hexadecimal properties. While there are thousands of BMS scripts out there, none of the ones made for WAD extraction or Renderware games were able to get anything substantial from these WADs. The only BMS script that came close was mx_simulator.bms which managed to pull some of the file names but none of the corresponding data. And this brings me to the current state of this project: Having to figure out how to write a BMS script specifically for Fear Effect 3 Inferno. Naturally, I tried to follow the tutorial provided Struggleton! but this didn't get me very far. As you can hopefully see with these two examples, the WADs seem to begin with a listing of all the files they contain. The actual data of the files appears to be located much further down in the Hex table. Therefore, I have no idea where I should even begin to search for indicators or how to adress them in the script. If anyone here in the forum is able to help me out on this one, it would be very much appreciated. You can find all of the game's .WAD archives and the BMS scripts that yielded at least some kind of readable result down here: BMS Scripts.7z WAD.7z

Hi. Today I've posted a new tutorial on my blog: https://ikskoks.pl/tutorial-what-is-quickbms-how-to-export-and-import-with-quickbms/

Hi, I'm first time here, so there may be omissions in this article, sincerely apologise. The game I'm facing with is named "Wizardry Variants Daphne", a mobile game you can download from Google Play Store. I'd like to extract some files from it, so I tried to locate its exact whereabouts, and here is what I have - The core files of this game can be found under this path: --- internal storage/Android/data/jp.co.drecom.wizardry.daphne/files/assetcache and they are in common Unity Game structure (while the version stays unknown). However, unfortunately, those files seem to be encrypted by official with some algorithm I don't recognise; thus, I'm stuck here, and this is what I'm here for. If someone knows how to deal with it, could you lend me a hand please(⋟人⋞)? A QuickBMS script is recommended, and if it is possible, a detailed procedure how to solve this kind of problem as well. (And if you are interested in this, I've uploaded some sample files in Attachment, or you can download them from this site - https://www.dropbox.com/scl/fo/u5e4bv0boowmuibhgbbk6/AHSytI8US1xa_jY-HEoIZDw?rlkey=siwslrlacj1a6v2e2ndzidk5x&st=ahp13vt3&dl=0) Daphne.zip

Hello, I am new to the ResHax community, and I'm having trouble with extracting assets from the game "Bob the Builder: Festival of Fun" for the Nintendo Wii by Blast! Entertainment. I tried to create my own Noesis plugin that would import the ".h3m" (models) and ".h3t" (textures) files, and then I also used QuickBMS to extract the h3m files by creating my own script, but no matter how hard I tried, it just wouldn't work. If anyone who knows about and uses Noesis and/or QuickBMS a lot, would you help me create a plugin/script suitable for that game, please? https://drive.google.com/drive/folders/1Ew1VPEODvMS9wlxoWvNi-9_FNrellCzw Also, I wish to convert the models and textures into OBJ and PNG respectively.

Original poster great aluigi A real example/tutorial about a not-so-simple archive format. I think this is a bit advanced for beginners but I wanted to do something based on a recent file format I analyzed. The sample is attached: talk_Vat_00.zip Tools: QuickBMS http://quickbms.aluigi.org Hex editor if you don't have idea of what to take, try XVI32 Read hex, speak hex, eat hex: forget the decimal notation and think only to 0xNUMBER, it's what will help you during reversing... so 10 is 0xa. Things to notice: Do we have a magic number? It's a string/signature or number that is usually used to identify a file format, for example ZIP archives have "PK". In this case we have a 0x00 "CAP" which looks just like a magic. What is the endianess? The endianess is the direction of the numbers stored in the archives. Big endian of 0x11223344 is 11 22 33 44 Little endian of 0x11223344 is 44 33 22 11 The secret is watching the data as blocks of 4 bytes (32bit) so in this case after " CAP" we have: 00 00 00 00 00 00 00 0c That second field looks just a 0xc, so a big endian. Doesn't have sense to be 0x0c000000 in little endian We don't know yet what is this 0xc, let's check it later. Then we have another 00 00 00 00, skip the fields set to zero. And now 00 00 00 e0, so 0xe0. We are at the beginning of the format so it may be an offset, or the size of a section or the number of files or maybe nothing important. Go in your hex editor and press CTRL-G, select hexadecimal and type e0: The data at that offset looks just like a DDS image, take it in your notes. We can notice that it's a non-compressed file because there are many zeroes and the file is easily identified. The next field is 00 4e db 38, so 0x4edb38. Repeat the same operation as before and at that offset you will see a sequence of complete filenames (path + name): Now go back to the beginning of the file because there are still a lot of fields between that DDS image and the current position: 00 43 41 50 00 00 00 00 00 00 00 0c 00 00 00 00 .CAP............ 00 00 00 e0 00 3e db 38 00 00 00 00 00 00 00 00 .....>.8........ 00 00 00 00 00 10 00 80 00 00 00 00 00 00 00 2f .............../ 00 10 00 80 00 10 00 80 00 00 00 30 00 00 00 24 ...........0...$ 00 20 01 00 00 01 cc a8 00 00 00 58 00 00 00 1c . .........X.... 00 21 cd a8 00 00 6a 5f 00 00 00 78 00 00 00 1c .!....j_...x.... 00 22 38 08 00 02 a9 11 00 00 00 98 00 00 00 1c ."8............. 00 24 e1 1c 00 04 13 83 00 00 00 b8 00 00 00 1c .$.............. 00 28 f4 a0 00 04 70 93 00 00 00 d8 00 00 00 1c .(....p......... 00 2d 65 34 00 03 85 79 00 00 00 f8 00 00 00 1c .-e4...y........ 00 30 ea b0 00 04 e2 dc 00 00 01 18 00 00 00 1c .0.............. 00 35 cd 8c 00 01 8b 5a 00 00 01 38 00 00 00 1c .5.....Z...8.... 00 37 58 e8 00 07 7a 40 00 00 01 58 00 00 00 14 [email protected].... 00 3e d3 28 00 00 07 2f 00 00 01 70 00 00 00 2b .>.(.../...p...+ 44 44 53 20 7c 00 00 00 07 10 00 00 00 04 00 00 DDS |........... If you watch carefully you can notice a certain "pattern", from offset 0x20. Basically a sequence of fields that gets repeated, like 4 32bit numbers, 4 numbers, 4 numbers... So let's try to identify this pattern splitting the fields in our mind: Now it's time to make some math operations. We have the number 0xc at the beginning of the file that is also the number of these patterns composed by 4 fields each one, so probably that 0xc is the number of files. The first field is zero so if it's an offset it's for sure a relative offset: OFFSET + 0xe0 = file offset. The second field seems related to the first one. For example: OFFSET 0x00 and second field 0x100080 OFFSET 0x100080 (previous offset + previous size) and second field 0x100080 OFFSET 0x200100 (previous offset + previous size) and second field 0x1cca8 and so on. So let's say it's a SIZE. When we work with archives we need at least 3 parameters: OFFSET SIZE NAME The missing one is NAME and considering the ascendant number (0, 0x30, 0x58, 0x78) it may be a relative offset for the names table we have seen at the beginning of the analysis at offset 0x3edb38. Check it: 0x3edb38 + 0x30 = "BattleRes/talk/st_bg/screen_bg02.dds" 0x3edb38 + 0x58 = "se/talk/07Vat/Vat00_0001.msf" 0x3edb38 + 0x78 = "se/talk/07Vat/Vat00_0002.msf" Ok we have the NAME relative offset And what may be the last one? It's not important, but if you check it you will notice that it's related to the incremental name offset, it's the name size. The reversing of the file format is finished, we can extract all the files with their original filenames Let's check the relative script: http://aluigi.org/papers/bms/others/uniel.bms And in the next post we will see how to write the script from scratch with these parameters.