Leaderboard

Author: Myro Scope: Educational & research-oriented reverse engineering Status: Ongoing research Introduction: This thread documents an ongoing technical research project focused on analyzing the MPK container system used by Where Winds Meet (WWM). The goal is to understand the structure, behavior, and data flow of the game’s asset containers from a reverse-engineering and archival perspective, strictly for educational and analytical purposes. No proprietary assets, binaries, or tools will be distributed as part of this work. 1. Patch*#.mpk vs Resource*#.mpk — Structural Similarity, Semantic Differences At a container level, Patch#.mpk* and Resource#.mpk* share the same base format: Indexed via mpkinfo / mpkdb Entries contain: FileID Size Offset MpkIndex Use the same compression stack: LZ4 / ZSTD / LZMA EZST (AES-encrypted) However, despite this structural similarity, their extraction semantics differ significantly. 2. Patch*#.mpk — Partial Transparency, Direct Asset Access Patch MPKs behave primarily as delta / override containers: Assets retain near-original offsets Internal file structures remain largely recognizable Minimal indirection compared to Resource MPKs As a result: ~99% of audio assets can be recovered successfully A subset of Lua scripts becomes readable after decompression Non-audio assets (including some images) are present and partially accessible Testing on Patch3100.mpk confirmed that Patch archives are not limited to sound assets. Conclusion: Patch MPKs prioritize update efficiency and fast access, with limited transformation of payload data. 3. Resource*#.mpk — Indirection and Shared Data Resource MPKs represent the primary asset pool and introduce several additional complexities: The Size field often represents a logical or expanded size, not the physically stored payload Naïve extraction pipelines tend to: materialize padding and alignment blocks duplicate shared data blobs inflate archive size artificially (e.g. ~2 GB → tens of GB) This behavior explains why Resource MPKs appear far more “opaque” when extracted without validation. Important observations: Fixed headers such as 02 02 02 01 … frequently represent logical structures (e.g. texture containers with multiple mip blocks) Headers of the form size (4 bytes) + size × 20 bytes often describe lookup tables, not standalone assets Many assets are shared, aliased, or referenced indirectly Conclusion: While Patch and Resource MPKs share the same container format, they do not share the same extraction semantics. Resource MPKs require strict validation, deduplication, and asset-type verification to avoid false positives. 4. Audio Extraction & Tooling Initial testing with Ravioli Game Tools proved sub-optimal for this pipeline: Inconsistent parsing of Patch audio assets Unreliable WAV output in multiple cases Switching to vgmstream yielded significantly better results: Correct parsing of recovered audio data Clean, fully functional WAV output Proper handling of codec structures Current result: Audio extraction and conversion are fully verified and stable. 5. Resource.mpk Extraction – Current Progress Testing on Resources49.mpk (~740.9 MB) produced the following results: Successfully extracted: Audio assets → converted to valid .wav files Over 8,500 audio files identified in a single Resource MPK Video files (.mp4) → fully playable Lua scripts (.lua) → extracted but still encrypted / obfuscated Unresolved: Files detected as images (.png, .jpg, .bmp) Headers contain the string “messiah” Strongly suggests custom packing, encryption, or misclassification Currently not valid image data despite file extensions 6. Current Status ✔️All Patch*#.mpk, Resource*#.mpk, and lt*.mpk archives can be unpacked ✔ Audio assets fully recovered and validated ✔ MP4 video assets fully playable ✔ Lua scripts extracted but not yet readable 7. Next Steps Ongoing research will focus on: Reversing additional transformation layers in Resource*#.mpk Identifying: secondary encryption stages compression chaining block or stream reordering Investigating the custom image container format Further analysis of Lua encryption / obfuscation Automating Patch vs Resource handling as two distinct pipelines Notes on Tooling & Distribution All tools used in this project are: developed entirely from scratch created specifically for WWM research used strictly for educational purposes At this stage: no tools, binaries, or scripts will be released no proprietary assets will be redistributed Closing This thread is intended solely as a technical research and documentation log, not as a release, redistribution, or exploitation guide. In accordance with applicable intellectual property laws and forum policies, no tools, binaries, scripts, or extracted assets will be posted or shared, either publicly or privately. All game data, assets, file formats, and related materials discussed here remain the exclusive proprietary property of NetEase and the developers of Where Winds Meet. Any references to assets or file structures are made strictly for educational, analytical, and research purposes, with no intent to enable misuse, circumvention, or redistribution of protected content. Should any concerns arise regarding compliance or scope, I am fully open to cooperating with forum moderation and adjusting the visibility or content of this thread accordingly. Thank you for your understanding and for supporting responsible technical research. — Myro Below are a few illustrative screenshots and log excerpts from the current stage of the research, provided solely to contextualize the findings outlined above.

This looks correct. The palette is RGB5551, but is swizzled with the same method as the image (not the standard PS2 palette shift). Patrick should be able to confirm if that can be added to ImageHeat as a palette swizzle option.

I don't know if there are more models in that unpacked folder, you need to check that so examine each file there. Just remember that characters use shorts in vertices buffer, I think I saw other file with floats but maybe that file is not a character or maybe it is but with floats, I really don't know, lol. Here is the script if you want to test it: fmt_black_ps2_prototype_DB.py

You'd be better using ImageHeat, as it has more options for swizzling, etc. For these, the image is PS2 swizzled, but I can't work out the palette. It doesn't seem to use any of the standard PS2 palette formats, maybe a different swizzling method. This is from "t_compact_rockangelz_closed_00000003":

Drag and drop .md6mesh files into the script it will convert them into obj files. md6mesh.py md6mesh.zip

The "repeated offsets" pointing to new blocks indicate that the main BIGFILE.CAT is acting as a master container that holds smaller, self-contained archives inside it. The Master Index: Points to large chunks of data (e.g., "Level 1 Data", "Level 2 Data"). The "New Block": When you go to that offset, you find a new header (signature 01 00 01 00). The Inner Index: This new header has its own list of files. Because this block is treated as a standalone file by the game engine once loaded, its offsets start at 0 (relative to the start of that block), not relative to the start of the whole disc. [ MASTER CAT (BIGFILE) ] |-- Header |-- Index Entry 1: Offset 1000 -> Points to "Level 1 Block" |-- Index Entry 2: Offset 5000 -> Points to "Level 2 Block" | |... [Data at Offset 1000] ... | +-> [ NESTED CAT (Level 1) ] |-- Header (starts at Master Offset 1000) |-- Index Entry A: Offset 10 (Absolute: 1010) |-- Index Entry B: Offset 50 (Absolute: 1050) |-- Data... Why did developers do this? (The Logic) This approach was necessary due to the hardware limitations of the PlayStation 1 (PS1): RAM Constraints: The PS1 has only 2MB of RAM. It cannot keep a massive table of thousands of file offsets in memory at all times. Modular Loading: The game loads the "Master Index" to find the location of the current level's data. It then streams that specific "Block" (Nested CAT) into memory. Relative Addressing: Once the "Block" is loaded into a specific memory address, the game engine reads the inner offsets. Since these offsets are relative to the start of the block (0), the engine can easily calculate memory pointers without needing to know where the block was originally located on the CD.

There is the tool PS2JunjouUnpacker-decompressor.zip

I've just released new version of ImageHeat 🙂 https://github.com/bartlomiejduda/ImageHeat/releases/tag/v0.39.1 Changelog: - Added new Nintendo Switch unswizzle modes (2_16 and 4_16) - Added support for PSP_DXT1/PSP_DXT3/PSP_DXT5/BGR5A3 pixel formats - Fixed issue with unswizzling 4-bit GameCube/WII textures - Added support for hex offsets (thanks to @MrIkso ) - Moved image rendering logic to new thread (thanks to @MrIkso ) - Added Ukrainian language (thanks to @MrIkso ) - Added support for LZ4 block decompression - Added Portuguese Brazillian language (thanks to @lobonintendista ) - Fixed ALPHA_16X decoding - Adjusted GRAY4/GRAY8 naming - Added support section in readme file

The textures are compressed with ZSTD - just that type 0 means the whole file is not compressed. But there doesn't seem to be any encryption once decompressed - looks something like ETC format:

It's been a while since this topic is up and i have found a way to deal with this: -Step 1: From the .farc files, use either the tool mentioned at the first post of this thread, or download QuickBMS and use the virtua_fighter_5 bms script i included in the zip file below to extract them into bin files. -Step 2: Download noesis and install the noesis-project-diva plugin (https://github.com/h-kidd/noesis-project-diva/tree/main , or in the included zip file) in order to view and extract the textures/models and use them in Blender or a 3d modeling software of your choice. KancolleArcade.zip

https://github.com/bartlomiejduda/ImageHeat/releases/tag/nightly

The game has a debug mode, maybe this will help in some way.

Wait, I think I did something wrong, lol. I can see other unknow block or buffer before UVs. I thought that was the start of UVs but no! So Uvs have the same count as verts after all. The format is: verts/normals buffer: 3 shorts verts, 1 short flag, 3 shorts normals, 1 short flag. unk buffer: ?? UVs buffer: 2 shorts UVs, 4 bytes unk(maybe vertex colors?) Well, it looks like that but I am not sure. About the meshes with floats is: verts/normals buffer: 3 floats verts, 1 short flag, 1 short pad, 3 floats normals, 1 short flag, 1 short pad UVs buffer: 2 shorts UVs, 4 bytes unk(maybe vertex colors?) So meshes with floats don't have that unk buffer. And like always, each buffer has a 4 bytes tag, Here is the last part of the 1st submesh, you cn see that unk buffer before UVs:

Sometimes there's a 2nd uv channel. Do you mean that? (In another case one could also double special vertices to get the same amount like uvs but I forgot how to do that... iterate through faces, somehow. edit: found it, answer from Daniol Dan, ""thus each vertex has its own single UV coord"" Not sure whether this will apply to your problem, though.

i suspect the tool would require some minor modification but yes more or less.

Hello! Out of boredom, I decided to replace texture from a Godot game, in this case Slot or Not, by using Python but failing and failing over again exhausted me. My script has data and their MD5 hash code replacement, and data header change. I doubt that something doesn’t work or they are others data somewhere. I also think even if both WebP data from Godot and PIL are working, their data processing are different thus incompatible. Not even replacing them with PNG data works. I suspect there is a checksum for PCK somewhere. I compared its PCK file with Super Mario 127’s. Although the WebP data for CTEX and STEX are the same, the data pointers in SM127 are at the start of the file, after the header; SoN are at the bottom. The PCK for V1 is documented in Xentax wiki but not for V3. It may be small but this comparison shouldn’t be dismissed. What I need: If there is a checksum for PCK, where it is? The Bytes leading to the data header thus making the Python script adaptable If the WebP data is the issue, a better understanding of Godot’s WebP data Feel free to reply if you find anything! Slot or Not (PCK File V3) son PCK File.zip Godot Picture Replacer Script (Work in progress) Godot Pictures Replacer Script.py Note for the creator of Slot Or Not, you don’t have to turn it into an moddable game. The game need its own resource to be good game. I do this because why not and for research purpose. Knowledge GODOT PCK FILE FORMAT (Little Endian) (From Slot or Not) HEADER (112 Bytes) 4 Bytes = Signature ("GDPC") 4 Bytes = 03 00 00 00 (Engine Version) 4 Bytes = 04 00 00 00 (Major) 4 Bytes = 05 00 00 00 (Minor) 4 Bytes = 00 00 00 00 (Revision) 4 Bytes = 02 00 00 00 4 Bytes = 70 00 00 00 (First File Pointer) 4 Bytes = 00 00 00 00 4 Bytes = File Numbers 4 x 19 Bytes = 00s (Reserved) DATA HEADER (Found at the last part of the file) 4 Bytes = Length of Path, Including the 00s X Bytes = Path Name + 00s (If not divisible by 4) 8 Bytes = Data Pointer - 112 8 Bytes = File Size 16 Bytes = Data MD5 Checksum 4 Bytes = 00 00 00 00 GODOT CTEX FILE FORMAT (Little Endian) For WebP Format { 4 Bytes = String GTS2 4 Bytes = Use Alpha or Not (01 = Yes; 00 = No) 4 Bytes = Height 4 Bytes = Width 4 Bytes = 00 00 00 0D 4 Bytes = FF FF FF FF 4 x 3 Bytes = 00s (Reserved?) 4 Bytes = 02 00 00 00 2 Bytes = Height 2 Bytes = Width 4 Bytes = 00s 4 Bytes = 05 00 00 00 4 Bytes = Data Size after this Byte 4 Bytes = String RIFF 4 Bytes = WebP Data Size after this Byte 8 Bytes = WEBPVP8L / Tag for Loseless Encoded Image Data 4 Bytes = Data Size (or Data Size - 1 if WebP Chunk ends with 00) (Rest of the File) X Bytes = WEBP VP8L Chunk (On Python, the settings are Loseless = True, EXIF = False) 0-15 Bytes = 00 for Fill Up if the CTex Data Size isn't a divisible of 16 } [NOTE: You can get the WebP data by removing the GTS2 Header.] For PNG Format { X Bytes = PNG File Data 0-15 Bytes = 00 for Fill Up if the CTex Data Size isn't a divisible of 16 } X Bytes = String for [Remap], Settings, Path, Texture, Vram X Bytes = 00s (if the length the String isn’t a divisible of 16)

As per i am a good for nothing in 3d model issues., i can´t tell if te unpack works, but studying DB, i can see 2 types of TOC. Attached the py script, if someone wants to take a look. just drop the files DB or bins in .py or double click in .py black_ps2_unpack.py

Hi i was wondering if there is a way to open the .arc files for The Sims on the original Xbox I'm curious to see if the archived files are in .IFF format i tried using The Sims 2 .arc QuickBMS script but to no avail EDIT: Found a script that work ironically it was a Hulk .arc script. Thank You ikskoks

Ok, thanks. You rule that format (besides the anims). I'll check the files tomorrow. (If I can't help maybe someone else can, with all the files provided.) Good night. edt: well, being more the "simple analyzer" I focussed on the skeleton (21 bones?) in the dff file and the gar.rws.dec_be_-15_anim_27.rwanm: I think the 5th column here could be the frame time in msec with translation and rotation values to follow: address 0x1b6: 30486 29945 63488 29628 58856 65209 0 0 51393 54393 57171 30685 30720 63488 29628 58856 65209 0 0 32768 32768 59982 30502 59743 63488 29628 58856 65209 34953 15752 0 0 0 30720 63488 63488 29628 0 0 34953 15624 61841 59913 29289 27424 63488 30459 59522 24 0 34953 15624 22619 21982 18934 30704 58259 63488 29628 48 0 34953 15624 30430 60362 20288 17433 25922 63488 29628 72 0 34953 15624 30136 28721 52832 21347 59344 63488 29628 96 0 34953 15624 48489 62528 16374 29259 25922 63488 29628 120 0 34953 15624 60085 59294 26987 30152 58965 63488 29628 144 0 34953 15624 0 0 62248 29560 24551 63488 29628 168 0 34953 15624 15843 53973 27979 30346 23143 63488 29628 192 0 34953 15624 53430 29725 53792 29292 25922 63488 29628 216 0 34953 15624 26788 24635 22352 30525 58965 63488 29628 240 0 34953 15624 0 0 61788 29946 24551 63488 29628 264 0 34953 15752 22777 25316 22954 30638 23143 63488 29628 288 0 34953 15624 61008 30170 26220 address 0x316: 13303 63488 63488 28399 312 0 34953 15624 0 0 27758 30398 29945 63488 29628 336 0 34953 15624 7522 11482 59715 30545 30720 63488 29628 360 0 34953 15752 32768 32768 59982 30502 59743 63488 29628 384 0 34953 15624 61466 29974 59213 57464 63488 63488 30720 408 0 34953 15624 0 0 28454 30232 29945 63488 29628 432 0 34953 15624 51986 54325 58411 30640 30720 63488 29628 456 0 34953 15752 32768 32768 59982 30502 59743 63488 29628 480 0 34953 15752 59840 61645 28387 29176 63488 30184 63488 528 0 34953 15752 21331 23096 25805 30620 58259 63488 29628 552 0 34953 15752 30629 58637 21582 16964 25922 63488 29628 576 0 34953 15752 30156 28689 53876 51939 59344 63488 29628 600 0 34953 15752 47599 62461 15165 29336 25922 63488 29628 624 0 34953 15752 59092 59464 28203 30010 58965 63488 29628 648 0 34953 15752 0 0 62825 28859 24551 63488 29628 672 0 34953 15752 52057 53845 27997 30341 23143 63488 29628 696 0 34953 15752 55057 29609 55317 address 0x476: 29406 25922 63488 29628 720 0 34953 15752 56171 26016 20052 30608 58965 63488 29628 744 0 34953 15752 0 0 61930 29839 24551 63488 29628 768 0 34953 15752 29497 62179 58598 22637 63488 63488 28399 816 0 34953 15752 0 0 28323 30266 29945 63488 29628 840 0 34953 15752 7817 11470 59999 30499 30720 63488 29628 864 0 34953 15752 29655 61689 27187 25651 63488 63488 30720 912 0 34953 15752 0 0 29009 29954 29945 63488 29628 936 0 34953 15752 52130 54326 59350 30587 30720 63488 29628 960 0 29287 16404 44589 16658 52439 //49164 29287 16404 44589 16658 9 16448 21 0 1 2 I checked 40 blocks with a size of 22 bytes but none of the point clouds resembled an animation curve (although you can get some points in a line sometimes).

I am uploading all animations for the character gar here. I should have done that in the previous post but it slipped my mind. So now you have a complete set of animations for one character. gar.rws.dec_be_-15_extracted.rar

The armature is with the model. When you import the DFF using DragonFF in blender it will have the armature with it. The bones are very small. You can use the side menu GUI to better find the bones. Models and Skeletons are 100% workable. It is the custom renderware animation format that is the problem here. In the files I uploaded in the topic post, there should be two rwanm files. Those are some of the animations. If you have the game I can give you one of my scripts that will extract everything for you so you can go through all the files for testing. I tried figuring this out through the elf file. Let me know if you want my script so you can poke at all the animations in the game. There are two different sets of animations per character even if they don't have a weapon. The animations specific for weapons would be much easier to look at since they are smaller. There are mot files that give some additional information but for the most part they are irrelevant. Mot files for this game is more of a listing of animations and positioning for static model pieces. Not the main animations. I am uploading the mot file so you can see it is mostly just for static pieces. The txt file for the character abbreviated with gar that states all the files for him and the gmobj data base text for it as well. I used a renderware tool "forgot the name of it" that allows me to look at how the files are structured. Sending you a section_tree.txt that was made by that program. I was offered a job to make a modding tool for this game that would include editing animations..... As it stands, I don't believe I will be able to finish it. Will just make everything I have for this game public if that happens. Adding two scripts as well. The gar_rws_test.py script does a simple test on the files for the correct compression to decompress the files so you can get everything basically. The garou_rws_extractor is a slightly upgraded version that needs work and is for extracting the models/animations. On aluigi's website there is a bms script called ougon_kishi_garo. That would be your first step to getting all the files out. Then you will have to use the scripts I posted here. The unfinished one will have errors. The test one will work better. gar_mot.rar gar_files_txt.rar gmobj_DB_Files_txt.rar Section_Tree_txt.rar gar_rws_test.py Garou_RWS_extractor.py

I couldn't find the UVs.

I fear there's not too many who dealed with PS2 animations in this forum, me included. Do you have skeleton data? I checked the dff mesh, looks doable, but usually I don't like to work from scratch:

Drag and drop .resources files into this script, it will extract all of the assets from there (.texdb files not implemented yet). Nest steps: .MD6MESH - https://reshax.com/topic/18614-wolfenstein-the-new-colossus-md6mesh-files/ .BIMAGE/.TGA - https://reshax.com/topic/18617-wolfenstein-the-new-colossus-bimage/#comment-101572 .PACK (.WEM .BNK) - https://reshax.com/topic/18618-wolfenstein-the-new-colossus-pack-containers-wem-and-bnk-files/#comment-101573 wolfenstein_2_resources.py wolfenstein_2_resources.zip

there is a lot of overlap, in fact the Kameo alpha uses the exact same CAFF version as the Conker Demo. the lvl files are just an archive/container of sorts while the assets themselves are packaged inside individual "CAFF" containers. for example: the file struct is fairly basic for the LVL container itself(for imhex): struct LVL_ENTRY { u32 unk_00; u32* address : u32; }; struct LVL_FILE_TABLE { u32 count; LVL_ENTRY array[count]; }; LVL_FILE_TABLE table @ 0x00; they're similar in a sense that Conker stores the assets inside a "ZPackage" CAFF container instead of using an external container(.LVL) to store the individual CAFF assets. unlike the earlier games like GBTG kameo also stores a lot of data inside pushbuffer commands including things like the triangles/shaders/shaderparams. but as far as models go theyre very similar (as thats what i've spent the most time on) not sure about the other assets tho.

i used retool to get the files out, here are the raw files and textures sample.rar

=== Available bones in motion file === 2: waist - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 3: chest - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 6: eye_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=68] 7: eye_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=62] 8: shoulder_r_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=67] 9: arm_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=101] 10: forearm_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=34] 11: wrist_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=101] 12: pinky_r_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=89] 14: pinky_b_r - Other[type=0x01, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 15: pinky_c_r - Other[type=0x01, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1] 16: ring_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=84] 20: middle_a_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=96] 21: middle_b_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=89] 22: middle_c_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 23: index_a_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 24: index_b_r - Other[type=0x01, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 25: index_c_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 26: thumb_r_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=90] 28: thumb_b_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=92] 29: shoulder_l_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=78] 30: arm_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 31: forearm_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=52] 32: wrist_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=52] 33: pinky_l_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=52] 35: pinky_b_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 36: pinky_c_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 37: ring_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=52] 41: middle_a_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=92] 42: middle_b_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 43: middle_c_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 44: index_a_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=84] 45: index_b_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=84] 46: index_c_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 47: thumb_l_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 49: thumb_b_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=76] 51: thigh_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=101] 52: leg_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 53: foot_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=68] 54: toe_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 55: thigh_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=77] 56: leg_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=38] 57: foot_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=72] 58: toe_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] === Bones in skeleton but not in motion (static) === 0: root 1: upperbody_jo 4: neck 5: head 13: pinky_a_r_jo 17: ring_a_r 18: ring_b_r 19: ring_c_r 27: thumb_a_r_jo 34: pinky_a_l_jo 38: ring_a_l 39: ring_b_l 40: ring_c_l 48: thumb_a_l_jo 50: lowerbody_jo

SLES_526.07.ELF (PS2 game executable) SCRIPT.PTD (1,728,512 bytes) 1. INITIAL FILE ANALYSIS: hexdump -C SCRIPT.PTD | head -50 First 32 bytes: unknown header Bytes 0x20-0x11F: 256-byte table Rest: encrypted data With Radare2, I examined the ELF a bit: Found function at 0x0010da30 (file handling?) 3. CALL TRACING: 0x0010da30 → 0x10ccf0 → 0x10a3f8 → 0x0010d850 4. DECODING FUNCTION ANALYSIS (0x0010d850): 🔓 ALGORITHMS FOUND: 1. LZSS DECOMPRESSION: def yklz_lzss_decompress(data): param_byte = data[7] # Always 0x0A shift = param_byte - 8 # 2 mask = (1 << shift) - 1 # 3 decompressed_size = int.from_bytes(data[8:12], 'little') # ... standard LZSS implementation 2. DECRYPTION ALGORITHM (0x0010D850): def junroma_decrypt_exact(data): if len(data) <= 0x120: return data result = bytearray(data) t1 = 0 # Initialized to 0 base_ptr = 0 # Base pointer (t3 in code) for i in range(0x120, len(data)): encrypted_byte = data[i] # t7 = (t1 XOR encrypted_byte) + base_ptr t7 = (t1 ^ encrypted_byte) + base_ptr # decrypted_byte = TABLE[(t7 + 0x20) & 0xFF] idx = (t7 + 0x20) & 0xFF decrypted_byte = SUBSTITUTION_TABLE[idx] result[i] = decrypted_byte # t1 = (t1 - 1) & 0xFF t1 = (t1 - 1) & 0xFF return bytes(result) 3. SUBSTITUTION TABLE (0x0055F7A0): SUBSTITUTION_TABLE = bytes([ 0x82, 0x91, 0x42, 0x88, 0x35, 0xBB, 0x0F, 0x85, 0x96, 0x2C, 0x56, 0xFF, 0x8E, 0x3C, 0x7C, 0x0D, 0x61, 0xBF, 0xB8, 0xEF, 0xD1, 0x16, 0x07, 0xEE, 0x4F, 0x09, 0xCB, 0x0C, 0xE2, 0xB1, 0xDD, 0x12, 0xFB, 0x08, 0x89, 0x8B, 0x03, 0xC9, 0x27, 0x19, 0x6A, 0x32, 0x5D, 0xCD, 0x98, 0x17, 0xF4, 0xE7, 0x9F, 0x1A, 0xF9, 0x1B, 0x6C, 0x5C, 0x44, 0x3B, 0x6E, 0x3E, 0x60, 0xD5, 0x4D, 0x21, 0x43, 0x4E, 0x65, 0xFD, 0x0B, 0x92, 0x8C, 0x2B, 0x41, 0xED, 0x76, 0x22, 0xC1, 0x74, 0xA3, 0x47, 0x14, 0x67, 0xE0, 0xDE, 0x0A, 0xE3, 0x1E, 0x5F, 0x1C, 0x84, 0xEA, 0xA0, 0x02, 0x69, 0x52, 0xB9, 0xC5, 0x20, 0x6D, 0xC8, 0x79, 0xD0, 0x05, 0x77, 0xB3, 0xDA, 0x7F, 0xBA, 0xF1, 0xB2, 0x72, 0x9E, 0x9A, 0xB5, 0x6B, 0x1F, 0x58, 0xD2, 0x11, 0xA6, 0xD8, 0x80, 0x23, 0x46, 0x73, 0xB6, 0x2E, 0xE4, 0xAD, 0x81, 0xC6, 0xDB, 0x57, 0x95, 0x01, 0xEC, 0xC4, 0xF2, 0xEB, 0xDF, 0xC0, 0x28, 0x49, 0xE9, 0x37, 0x15, 0x5E, 0x34, 0x31, 0x00, 0xA8, 0x8D, 0x9C, 0xBC, 0xA2, 0x62, 0x90, 0xCA, 0x66, 0x3D, 0x70, 0x4C, 0x24, 0x48, 0xBE, 0xA9, 0x5A, 0x94, 0xD4, 0xF5, 0x1D, 0x38, 0x25, 0x8F, 0x26, 0xB4, 0x83, 0x45, 0x8A, 0x5B, 0xFC, 0x63, 0xA4, 0xFA, 0xAF, 0xF8, 0x10, 0xAB, 0x53, 0x54, 0x2F, 0xDC, 0xF6, 0xD3, 0x0E, 0x68, 0xE1, 0x59, 0xAA, 0x30, 0xC2, 0x51, 0xD7, 0xE6, 0xB0, 0xBD, 0x6F, 0x06, 0x93, 0x7D, 0x3A, 0xF7, 0x04, 0x78, 0x2D, 0x55, 0xA5, 0x2A, 0xA7, 0x40, 0x71, 0x9B, 0x7A, 0xC3, 0xD6, 0xFE, 0xCF, 0xE5, 0x4A, 0x7B, 0xC7, 0x99, 0xF0, 0xCC, 0x3F, 0xAC, 0xB7, 0x87, 0x7E, 0x33, 0x13, 0x97, 0xE8, 0x75, 0xCE, 0xA1, 0x50, 0x4B, 0x39, 0xD9, 0x86, 0x64, 0x9D, 0x29, 0x36, 0x18, 0xAE, 0xF3 ]) EXTRATION CODE (PYTHON) import os import struct # ==================== SUBSTITUTION TABLE ==================== SUBSTITUTION_TABLE = bytes([ 0x82, 0x91, 0x42, 0x88, 0x35, 0xBB, 0x0F, 0x85, 0x96, 0x2C, 0x56, 0xFF, 0x8E, 0x3C, 0x7C, 0x0D, # ... (same as above, shortened for brevity) 0xE8, 0x75, 0xCE, 0xA1, 0x50, 0x4B, 0x39, 0xD9, 0x86, 0x64, 0x9D, 0x29, 0x36, 0x18, 0xAE, 0xF3 ]) # ==================== LZSS DECOMPRESSION ==================== def yklz_lzss_decompress(data): if len(data) < 16: raise ValueError("File too small (smaller than the 16-byte header).") # Extract header parameters param_byte = data[7] shift = param_byte - 8 if shift < 0: shift = 4 mask = (1 << shift) - 1 # Decompressed size (uint32, little-endian) decompressed_size = int.from_bytes(data[8:12], 'little') # LZSS decompression src_pos = 16 output = bytearray() while len(output) < decompressed_size and src_pos < len(data): flags = data[src_pos] src_pos += 1 for bit in range(8): if len(output) >= decompressed_size or src_pos >= len(data): break is_reference = (flags & 0x80) != 0 flags = (flags << 1) & 0xFF if not is_reference: # Literal byte output.append(data[src_pos]) src_pos += 1 else: # Reference (match) if src_pos + 1 >= len(data): break b1 = data[src_pos] b2 = data[src_pos + 1] src_pos += 2 length = (b1 >> shift) + 3 offset = ((b1 & mask) << 8) | b2 offset += 1 start_index = len(output) - offset for i in range(length): idx = start_index + i if idx < 0: output.append(0) else: output.append(output[idx]) return bytes(output) # ==================== JRS DECRYPTION ==================== def junroma_decrypt_exact(data): """ EXACT implementation of the decryption algorithm (0x0010D850). Confirmed by debugger analysis. Initial t1 = 0 t3 (base_ptr) = 0 for our data Start offset: 0x120 """ if len(data) <= 0x120: return data result = bytearray(data) # Initial t1 = 0 (confirmed by debugger) t1 = 0 # base_ptr = 0 (t3 = base pointer to data) base_ptr = 0 for i in range(0x120, len(data)): encrypted_byte = data[i] # t7 = (t1 XOR encrypted_byte) + base_ptr t7 = (t1 ^ encrypted_byte) + base_ptr # decrypted_byte = TABLE[(t7 + 0x20) & 0xFF] idx = (t7 + 0x20) & 0xFF decrypted_byte = SUBSTITUTION_TABLE[idx] result[i] = decrypted_byte # t1 = (t1 - 1) & 0xFF t1 = (t1 - 1) & 0xFF return bytes(result) # ==================== JRS FILE EXTRACTION ==================== def extract_jrs_files(data): """Extracts individual .JRS files from decrypted data.""" jrs_magic = b'\x8F\x83\xDB\xCF' # JRS Magic: "純ﾛﾏ" files = [] pos = 0 while pos < len(data): idx = data.find(jrs_magic, pos) if idx == -1: break # Determine size (find next magic or use header size) next_magic = data.find(jrs_magic, idx + 4) if next_magic != -1: file_size = next_magic - idx else: file_size = len(data) - idx file_data = data[idx:idx + file_size] files.append({ 'offset': idx, 'size': file_size, 'data': file_data, 'is_jrs': True }) pos = idx + file_size return files # ==================== COMPLETE EXTRACTOR ==================== def extract_all_yklz_sections(): """Extracts and processes all YKLZ sections from SCRIPT.PTD.""" print("=== JUNJOU ROMANTICA PS2 EXTRACTOR ===") # Read file try: with open('SCRIPT.PTD', 'rb') as f: raw_data = f.read() print(f"File SCRIPT.PTD read: {len(raw_data):,} bytes") except FileNotFoundError: print("❌ ERROR: SCRIPT.PTD not found") return # Search for YKLZ sections yklz_signature = b'YKLZ' positions = [] pos = 0 while True: idx = raw_data.find(yklz_signature, pos) if idx == -1: break positions.append(idx) pos = idx + 1 print(f"YKLZ sections found: {len(positions)}") if not positions: print("❌ No YKLZ sections found") return # Create directories os.makedirs('EXTRACTED', exist_ok=True) os.makedirs('EXTRACTED/JRS_FILES', exist_ok=True) total_jrs = 0 # Process each section for i, pos in enumerate(positions): print(f"\n--- Processing section #{i:03d} (offset 0x{pos:08X}) ---") # Extract YKLZ data if i + 1 < len(positions): next_pos = positions[i + 1] yklz_data = raw_data[pos:next_pos] else: yklz_data = raw_data[pos:] try: # 1. Decompress LZSS decompressed = yklz_lzss_decompress(yklz_data) print(f" Decompressed: {len(decompressed):,} bytes") # Save decompressed version decomp_filename = f'EXTRACTED/section_{i:03d}_decompressed.bin' with open(decomp_filename, 'wb') as f: f.write(decompressed) # 2. Apply decryption (except section 0) if i == 0: # Section 0 is ASCII text without encryption decrypted = decompressed print(f" Section 0 (metadata) - not decrypted") else: decrypted = junroma_decrypt_exact(decompressed) print(f" Decryption applied (from offset 0x120)") # Save decrypted version decrypted_filename = f'EXTRACTED/section_{i:03d}_decrypted.bin' with open(decrypted_filename, 'wb') as f: f.write(decrypted) # 3. Extract JRS files if decrypted[:4] == b'\x8F\x83\xDB\xCF': print(f" ✅ Contains JRS file(s)") jrs_files = extract_jrs_files(decrypted) for j, jrs in enumerate(jrs_files): filename = f'EXTRACTED/JRS_FILES/section_{i:03d}_file_{j:03d}.jrs' with open(filename, 'wb') as f: f.write(jrs['data']) print(f" JRS file #{j}: {jrs['size']:,} bytes") total_jrs += 1 # Analyze JRS header if len(jrs['data']) >= 0x40: version = int.from_bytes(jrs['data'][4:8], 'little') declared_size = int.from_bytes(jrs['data'][12:16], 'little') print(f" Version: {version}, Declared size: {declared_size:,}") # 4. For section 0, show ASCII content if i == 0: try: text = decrypted.decode('ascii', errors='ignore').strip() if text: print(f" ASCII content: {text[:100]}...") # Save as text text_filename = f'EXTRACTED/section_000_metadata.txt' with open(text_filename, 'w', encoding='utf-8') as f: f.write(text) except: pass except Exception as e: print(f" ❌ Error: {e}") import traceback traceback.print_exc() print(f"\n{'='*60}") print("EXTRACTION COMPLETED!") print(f"Total JRS files extracted: {total_jrs}") print(f"Everything saved to: EXTRACTED/") # ==================== EXECUTION ==================== if __name__ == "__main__": extract_all_yklz_sections() NOW, THE RESULTING FILES ALL HAVE A HEADER WITH THE MAGIC NUMBER "JUNROMA" AND APPEAR TO BE ENCRYPTED. TRYING THE SAME ALGORITHMS OR APPLYING SHIFT-JIS JAPANESE DIDN'T WORK.

D:\88>py mot_rotation_extractor.py CHARA_POSE_SVT_0088_S01.mot arm_r 0 4.889439125475239e-10 0.5407554599817733 1.4406841468094752e-05 0.8411798453911885 1 -6.857191399194769e-10 -0.6332053752420114 -1.7710689242085512e-05 0.7739838192436295 2 9.680781275471423e-10 0.7419904178008506 2.197732230619127e-05 0.6704104857538526 3 1.168805020248789e-09 0.7357420612946057 2.3368850020973145e-05 0.6772618538614599 4 1.949070875265381e-09 0.9986487356304239 3.447117855729147e-05 -0.05196827527918962 5 1.8955871688974175e-09 0.7756976401807586 2.9743424602522006e-05 0.6311047220020868 6 2.5455886772310853e-09 0.878827057772032 3.542967924363111e-05 0.4771404418748128 7 3.226245697914568e-09 0.9417279975589877 3.9870071014519985e-05 -0.3363753513917405 8 4.099035407402478e-09 0.999881701599271 4.486528620122835e-05 -0.015381183116150696 9 4.475697367806648e-10 0.09022508301908228 4.352295069325249e-06 0.9959213996974146 10 -9.900496580111543e-11 -0.016108207506788277 -8.63153966278132e-07 0.9998702544081274 11 6.059799266392733e-09 0.8019628892165832 4.840268748269343e-05 0.597373854446753 12 -5.033915462308732e-09 -0.550395433826452 -3.5755896897761944e-05 0.8349041053585182 13 5.053784333516648e-09 0.4450858715305767 3.1563178794486055e-05 0.8954878926974015 14 8.419066313234432e-09 0.5885535705971041 4.6467524984686766e-05 0.8084582193151163 15 8.90557735051792e-09 0.48400980850508935 4.3647539557974e-05 0.8750625711146369 16 1.705888293133057e-08 0.739653758245311 7.467434392777951e-05 0.6729876019194776 17 5.1572109382203555e-09 0.18538461353349664 2.0212396550665652e-05 0.9826660392302642 18 -2.328339814495478e-08 -0.6828563164678986 -8.178477919607272e-05 0.7305526978741114 19 -3.913764879296982e-08 -0.916708464375864 -0.0001236022330290307 -0.39955672446366336 20 -5.154739810461322e-08 -0.9363174368121112 -0.0001465770889527342 0.35115471808983634 21 1.9941416689432306e-08 0.30514574357555446 5.101391250695028e-05 0.9523056613164191 22 7.665103345684452e-08 0.9660344250734825 0.00017489193652521154 -0.2584133490858223 23 7.134766782413641e-08 0.7025958983240921 0.0001410635188906553 0.7115890553959081 24 -3.6214565545341617e-08 -0.27067645581828326 -6.240843221417008e-05 0.9626703757625655 25 5.1790279998520676e-08 0.31343069120738587 8.093030035361684e-05 0.9496110757881587 26 9.76471751687859e-08 0.48348140665826506 0.00013865182460356674 0.8753546196778808 27 2.4320931108231546e-07 0.9660679133066328 0.00031516943800675713 -0.2582879934250419 28 -5.760116220776852e-09 -0.01787397162264415 -6.858465480027745e-06 -0.9998402477853122 29 -3.6387090286711984e-07 -0.9183475143749914 -0.0003981115505918134 -0.39577478993530635 30 8.160074093917339e-08 0.1715509171534115 8.22720490679595e-05 -0.9851752514426693 31 5.819853717302611e-07 0.9980718776550587 0.0005416464023315233 -0.06206636490839266 32 2.1510279639614338e-07 0.29228983646104745 0.00018557380336221306 0.9563297637655598 33 7.59445645377239e-07 0.8474814676856007 0.0006068034885069383 0.5308246355609446 34 3.5690964072418125e-07 0.33639013436576054 0.0002642112401393917 0.9417226808852375 35 -4.091057811462368e-07 -0.3193635112840012 -0.0002813906752493844 0.94763224326712 36 -7.546453676244599e-07 -0.47343991028694626 -0.0004824099506598264 0.8808259865759857 37 -1.8906289688167591e-06 -0.982952229475143 -0.0011231856476135507 0.183857697745491 38 -2.1105062508406607e-06 -0.9390839443880565 -0.0011623317184248968 0.3436858949289188 39 -2.5853066957476077e-06 -0.9646240712325369 -0.0013513238739472448 0.2636258240686401 40 -2.548795549486021e-06 -0.7758524791739349 -0.0012792661159138326 0.6309130637666075 41 -3.1615860075804858e-06 -0.8029301935402714 -0.0015291192910664463 -0.5960711082459713 42 -4.322600984749709e-06 -0.953658460734394 -0.0020134870391519846 -0.3008845062826679 43 -5.25241455552712e-06 -0.988412035710498 -0.002360985304159304 0.15177639270794138 44 -4.161603802056902e-06 -0.6521624127905219 -0.001807772378551133 0.7580771196157773 45 -6.4076487092003816e-06 -0.8348013728080191 -0.0026990522530703945 0.5505446240167313 46 -7.580466976304793e-06 -0.8733343844600407 -0.003096347434863975 -0.4871113481483479 47 -9.462704350659117e-07 -0.09508303543407069 -0.00037510524919442804 -0.9954692740952882 48 8.425608187935311e-06 0.7236249853299245 0.0032503281231428655 -0.690185711169369 49 1.3974775863233788e-05 0.9967865728728194 0.005250760229253485 0.0799309543429847 50 1.0252517924129751e-05 0.6522193732200672 0.003760479792529784 0.7580209415860742 51 7.079466725136183e-06 0.4028542154397706 0.002540938285457269 0.9152606321070067 52 3.595970832695169e-06 0.18027461327948976 0.001262493988347378 0.9836155091817782 53 9.582308647070628e-07 0.04164757493191193 0.00032967767325522203 0.9991323089631344 54 3.0435151035103606e-06 0.11275994047819692 0.0010266722975638299 0.9936217297131157 55 2.9213899144023735e-05 0.9943722786079471 0.009681902328738926 -0.10549896421237603 56 4.16363697258811e-06 0.12927425161304473 0.0013598656852372205 0.9916079460239664 57 -3.495453234750954e-05 -0.9799068872688088 -0.0112615781923993 0.1991373092063645 58 -1.19122282820623e-05 -0.2979602519629299 -0.003812380482884125 -0.9545706646777596 59 4.098904589922595e-05 0.8996510312258749 0.013230551163297976 -0.436409180529046 60 4.5509829644210436e-05 0.9224974013820024 0.014836853340391197 0.38571804489194406 61 2.5386896899756216e-05 0.4819785870349148 0.008372019390152027 0.8761429964832588 62 -7.74043605304678e-06 -0.13710430629077341 -0.0025848694109572466 0.9905532431862206 63 -4.197002811754517e-05 -0.6905692943694501 -0.014249406220070262 0.7231258551144275 64 -6.446179774219989e-05 -0.9784274441560907 -0.022294390233699647 0.20538425580108186 65 -6.738314184076315e-05 -0.9344167343406218 -0.02371722618609395 -0.3553911299199207 66 -5.318598254396075e-05 -0.6860462826797571 -0.019139229784659265 -0.727306115109579 67 -3.8073695903130686e-05 -0.4746078275031473 -0.01399468271587061 -0.8800861079910411 68 -2.0410335231135395e-05 -0.2460513518917346 -0.007675809464634084 -0.9692263996428959 69 -1.2414483692513633e-06 -0.014420071326659416 -0.0004768556868665043 -0.999895911657832 70 1.8390372862545596e-05 0.20651283622780844 0.0072618292052958125 -0.9784169428068659 71 3.720258570931797e-05 0.40298122945248555 0.015066659318015195 -0.9150842163986469 72 5.4747583197640296e-05 0.5694511849406998 0.02265236859910118 -0.8217129761475023 73 7.145976821520378e-05 0.7041115041467583 0.0298058800041412 -0.7094635960631596 74 8.65754632068576e-05 0.8079792090272402 0.036359064406225806 -0.5880880960535662 75 0.00010014190563846156 0.8858057159534748 0.042406154240265545 -0.4621146412291018 76 0.00010775037244367866 0.9231688063963739 0.04585370721855432 -0.381650076406211 77 0.0001119465641689991 0.9431990123522885 0.047940303828193226 -0.3287511792138469 78 0.00011522374207694951 0.9580387962502455 0.049692902280489296 -0.28229818820851793 79 0.00011812670846677753 0.9687373316043265 0.05115606062490537 -0.24275713349673386 80 0.00012029059110273124 0.9757962307228829 0.05223183248698172 -0.2123523894667537 81 0.00012149859992430558 0.9800959610243474 0.0529662230739378 -0.19132817783884565 82 0.000122493452797258 0.982595143704861 0.053448177709211446 -0.17790463980049037 83 0.00012276327248308762 0.9836103161533365 0.05364896424336061 -0.1721409873374937 84 -5.960464477538421e-07 -5.364418029784578e-07 -5.9604644775384206e-08 -0.9999999999996767 85 -4.172325134277023e-07 -5.364418029784743e-07 -0.0 -0.9999999999997691 86 -0.498829392620764 -0.09178566173618598 -0.860177822755763 -0.05327985169278694 87 -0.7640124337551579 -1.0923536302676896e-08 -0.0 -0.6452015197343542 88 -1.6689300537085817e-06 -0.0 -2.3841857910122597e-06 -0.9999999999957652 89 -0.0 -3.09944152831535e-06 -0.0 -0.9999999999951967 90 -3.814697265602702e-06 -0.0 -4.529953002903208e-06 -0.9999999999824638 91 -0.0 -5.2452087402103235e-06 -0.0 -0.9999999999862439 92 -5.960464477503769e-06 -0.0 -0.0 -0.9999999999822364 93 -5.960464477539059e-08 -0.0 -0.0 -0.9999999999999982 94 0.1485628140697129 1.683760545851179e-05 6.091795376621932e-13 -0.988902972991882 95 -5.960464477539059e-08 -0.0 -0.0 -0.9999999999999982 96 0.3462483126415183 4.290287474297634e-06 -2.1494426223936043e-09 -0.9381429027469615 97 -5.960464477539059e-08 -0.0 -0.0 -0.9999999999999982 98 0.36087411019359966 -0.00038851728707961855 -6.715246250684779e-09 -0.9326144571291479 99 -5.960464477539059e-08 -0.0 -0.0 -0.9999999999999982 100 0.0 0.9540857816096563 2.1230699129955274e-07 -0.29953350618961844

Please don't publish tutorials until you finish them. Also, Raw Texture Cooker is outdated. It's better to use ImageHeat https://github.com/bartlomiejduda/ImageHeat It supports more pixel formats etc.

Got a point cloud character and some normals, edit: got rid of them:

Skeleton deformations for the character creator is probably a more accurate term for Veilguards “morph targets” (DAO/DA2 use straight up targets while I/VG use the skeleton to deform morphs with different bone positions) But I’m not a game dev. 😉

The script has been updated and is now output in Lua format whenever possible. format_hotfix_data.py

here you go : 0x09D01B34E843AC6BE08BD854B3CEDA0C4CA52281C08B02BF827F3ADA77173BCA

When you choose "uncompressed" the file size should be bigger than for a DXT5 file. I'd try some other tool, maybe Gimp, for testing.

ImageHeat v0.39.2 (HOTFIX) https://github.com/bartlomiejduda/ImageHeat/releases/tag/v0.39.2 Changes: - Fixed hex input - Changed endianess and pixel formats bindings (required for hex input fix)

LZ4 is supported in ImageHeat.

O.K. so here's script for ps4 format. Inside unpacked file is texture width/height and pixel format all in 6 bytes. Rest is image data. Also i don't know about pixel fomat so you must figure out. get BaseFileName basename comtype lz4 getdstring Sig 0x8; get Unknown_0 uint32 get Unknown_1 uint32 getdstring Platform 0x4 get TextureCount uint32 get Unknown_2 uint32 get UnknownCount uint32 get TotalCompressedSize uint32 get TotalDecompressedSize uint32 get Unknown_6 uint32 get Unknown_7 uint32 for i = 0 < TextureCount getdstring TextureName[i] 0x40 getdstring Unknown_0 0x10 get CompressedSize[i] uint32 get Offset[i] uint32 # + BaseOffset get Unknown_3 uint32 get DecompressdSize[i] uint32 get Unknown_4 ushort get Unknown_ ushort get Unknown_6 uint32 get Unknown_7 uint32 get Unknown_8 uint32 savepos WidthHeightPos[i] get TextureWidth ushort get TextureHeight ushort get Unknown_9 uint32 savepos PixelFormatPos[i] get PixelFormat ushort get Unknown_10 ushort get Unknown_11 uint32 getdstring Unknown_12 0x4 get Unknown_13 uint32 get Unknown_14 ushort get Unknown_15 ushort get Unknown_16 uint32 getdstring Null 0x10 next i math UnknownCount * 40 getdstring UnkInfo UnknownCount savepos BaseOffset for i = 0 < TextureCount math Offset[i] + BaseOffset string FileName p= "%s/%s.dat" BaseFileName TextureName[i] append 0 log FileName WidthHeightPos[i] 4 log FileName PixelFormatPos[i] 2 clog FileName Offset[i] CompressedSize[i] DecompressdSize[i] next i

I don’t know if this has any effect. https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=3547

Decided to extract some key frames. from that .mot file I shared earlier. Wonder if there is any insight. The NaNs are interesting tho.

fmt_FGOArcade_mot.py Still incomplete

I made a blender addon to import models, textures and animations for dolphin wave and other games that used the same engine. it can import lzs and lza files as is. You don't need to decrypt or decompress the files https://github.com/Al-Hydra/blenderBUM

car_ambulance, extracted using hex2obj (after decompressing pxc with simplified bms from ky123):

For this format it's not as hard as you may think of. It's just a matter of persistent search which some people lack of and leave it to guys like me... Be that as it may, here's a H2O example, copy the 6 lines into notepad, for example, and save as ch0001_01_whatever. Rename the .txt file to .H2O then and load the model and the H2O file into hex2obj. Press the 'mesh' button. 0x951408 11085 Vb1 32 99 0x8F8A68 5239 021010 0x0 255 ch0001_01 obj.bin seems to contain different meshes: And the start address of the concerning FI block is unknown: Being bored by this annoying FIs' start address search for each sub mesh I used meshlab again:

Hello, although the file is recognized as .wav format by the system, it is actually a .wem format commonly used by the Messiah Engine. Of course, the .bnk format may also appear. You can use this tool to download a version suitable for your system. You can use the command Lines convert it to standard .wav audio or other audio formats https://github.com/vgmstream/vgmstream Of course you can also use the following exe program. I have used it before and can be converted in batches. Before using it, you should modify the file name to .wem. If the file header is BKHD, you should also modify and expand to .bnk RavioliGameTools_v2.10.zip

zlib_DeCompressor.pyHere the DeCompressor update, now works with every file

I wrote a VSF UNPACK/PACK program and a new decompressor/compressor for zlib. Now, it accepts large files and there's no need to use QuickBMS anymore. The .vfs file can now be larger than the original. I did a test, and it worked with the image below, maybe you can put music and soundeffects as well, If the .py file doesn't work, you must install tkinter via pip. VFS_PackUnpack_Tool.py zlib_DeCompressor.py