Leaderboard

INVESTIGACIÓN COMPLETA: ANÁLISIS DE SCRIPT.PTD - `SLES_526.07.ELF` (ejecutable del juego PS2) - `SCRIPT.PTD` (1,728,512 bytes) PASOS REALIZADOS: 1. ANÁLISIS INICIAL DEL ARCHIVO: ``` hexdump -C SCRIPT.PTD | head -50 ``` - Primeros 32 bytes: cabecera desconocida - Bytes 0x20-0x11F: 256 bytes de tabla - Resto: datos encriptados 2. BÚSQUEDA EN EL EJECUTABLE: r2 -A SLES_526.07.ELF afl | grep -i "read\|fopen\|file" - Encontrada función en 0x0010da30 (manejo de archivos) 3. TRAZADO DE LLAMADAS: 0x0010da30 → 0x10ccf0 → 0x10a3f8 → 0x0010d850 4. ANÁLISIS DE LA FUNCIÓN DE DECODIFICACIÓN (0x0010d850): Código MIPS encontrado: lui $a0, 0x001a addiu $a0, $a0, -0x0a00 ; buffer destino move $a1, $s1 ; puntero a datos li $a2, 0x120 ; offset inicial move $t1, $zero ; t1 = 0x00 move $t3, $s3 ; t3 = 0x04 (de s3) ALGORITMO DESCUBIERTO: Para cada byte en input[a2++]: t1 = (t1 - 1) & 0xFF t7 = t1 XOR byte_actual t7 = (t7 + t3) & 0xFF output = tabla[0x20 + t7] t3 = memoria[s0] (actualización dinámica) 5. TABLA DE DECODIFICACIÓN (offset 0x20): ``` 00000020: 89 7c 3a f1 4d e2 b0 55 92 47 18 6d a3 fe 29 8b 00000030: 74 31 9f d6 58 c3 67 b4 e5 12 4a 7f 36 98 d1 6a ... (256 bytes total) ``` 6. IMPLEMENTACIÓN EN PYTHON: def decode_script(data): table = data[0x20:0x120] # 256 bytes encrypted = data[0x120:] # datos encriptados t1 = 0x00 t3 = 0x04 output = [] for byte in encrypted: t1 = (t1 - 1) & 0xFF t7 = t1 ^ byte t7 = (t7 + t3) & 0xFF decoded = table[t7] output.append(decoded) # t3 se actualiza de memoria[s0] - pendiente return bytes(output) 7. RESULTADOS DEL DESCIFRADO: - Tamaño descifrado: 1,728,224 bytes - 12,026 cadenas de texto japonés encontradas - 3,733 ocurrencias del byte 0x9C - 1,949 ocurrencias del byte 0xA8 - 865 ocurrencias del byte 0xA2 8. ESTRUCTURA DEL BYTECODE DESCUBIERTO: [0x9C] [OPCODE] [parámetros...] [texto japonés] [0x9C] [OPCODE]... Opcodes identificados: - 0xA8 = 惠 (más común) - 0xA2 = 悗 - 0x5E = 弯 - 0x8A = 怺 - 0xDF = 憑 - 0xF2 = 懿 - 0xC8 = 慂 - 0xDA = 憇 9. PATRONES DETECTADOS: - Secuencias: `9C A8 9C A2 9C A8 9C 24...` - Byte 0x24 aparece como separador - Texto entre comandos en codificación Shift-JIS 10. LO QUE FALTA POR DESCUBRIR: - Funciones que procesan cada opcode (A8, A2, etc.) - Tabla de dispatch en el ejecutable - Significado de los primeros 32 bytes - Actualización exacta de t3 durante decodificación - Estructura completa de parámetros por comando

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.

Today I am gonna discuss on how we can reverse engineer the extraction of the game archives, sit back because this is where it starts to get interesting... +==== TUTORIAL SECTION ====+ But how do those files store game assets like 3D Models, Textures, Sounds, Videos and etc... Well, the anwser is simple, they usually bundle them, they pack them close together in their eighter compressed or even encrypted form (Rarely). The packed file usually contains compressed data and a small separator/padding between them, hover it doesn't tell us the name and the path of the file we want to com press, whch is a problem. Heck, we don't even know which compression method was used and which "flavour/version" and how the decompressed file should look like... That's where QuckBMS comes to help. =| QuickBMS |= QuickBMS has one very specific function I wanna talk about, it's "comptype unzip_dynamic" it supports millions methods and their "flavours/versions". It has also a very fast perfomance and is good for extracting the multiple files out of the package at once. There are also already lots of QuckBMS scripts out there for extracting specific archives, but I'll talk about that later. =| PRACTICAL STEPS |= As said previously, the block separators/markers are very usefull to identify but turns out most of the compression methods have their own headers and magic numbers, here are few of them: Magic numbers: ZLIB: 78 01 (NoComp) 78 5E (Fastest) 78 9C (Default) 78 DA (Maximum) LZ4: [No Magic Numbers] LZ4 Frame: 04 22 4D 18 (Default) LZW: [No Magic Numbers] LZO: [No Magic Numbers] BZIP/BZIP2: 42 5A 68 GZIP: 1F 8B 08

Introduction This question is probably the most asked one and it makes total sense why, the answer unfortunatelly is pretty generic in it's nature, it depends but if we dive deeper turns out it's not as hard as you think might be here is why I personally think this way... Reverse engineering the game, specifically for asset extraction, requires 4 different steps to create: 1. Extract Game Archive, (Reverse enigneer game's extractioon method, spot a compression method, decrypt xor keys (Rarely)) 2. Reverse Enigneer Binary 3D model files 3. Reverse egnineer Binary Texture files 4. Reverse egnineer the Binary Audio files While those are not extreamly hard to topics to learn, it can took some time to figure them out yourselfe. There are numereous ways to reverse engineer those tasks, you can do it manually via binary inspection, or by using, exploits or even by using leaked Beta Builds or reloaded versions, that often are packed with .PDB files (debug symbols) that can be loaded into Ghidra for near source code, code debugging experience. While the best one is still a binary inspection, there are already dedicated tools for this, for inspecting and extracting manually sample by sample, but currently in time being there aren't any automated programs for this so you must choose to rely on Python scripts. For extracting game archives I recommend QuickBMS for model extraction Model Researcher for Textures Raw Texture Cooker and Audacity for Audio... By extracting all of the game content don't forget about the Headers and Magic Numbers, No matter how Payload loos like, the headers are always the same and often contain super usefull info with them. Graphic Debuggers vs Reverse Engineering This is hot topic is the most intersting one, since yes, Dumping 3D Models and Textures + Recording the Audio's using Graphic Debuggers like RenderDoc, nvidia Nsight Graphics and NinjaRipper Exploit obviously way, way easier than any reverse engineering the proprietary files, it can be done in few minutes vs it can took a few days to mounths in Reverse Engineering so the difference is huge sometimes, hovewer after you reverse engineered the binary files you have access to extreamly fast asset "ripping" speeds without relying on the drawcalls and of course you have access to all of the cut contents and very very easier and faster Map/World "ripping". There are obviously upsides and downsides in both of the methods, I personally recommend using exactly what you need for, if there are already scripts for extracting and maybe even converting some binary proprietary assets then go for it!

My first try on this .lwo format.

My best bet: edit: fail, at 0x1d934 there's only a copy of the mesh

Drag and drop .resources files into the script this will extract all of it's content from there. Next Steps: BMD6MODEL/BMODEL - https://reshax.com/topic/18566-wolfenstein-the-new-order-wolfenstein-the-old-blood-bmd6modelbmodel-files/#comment-101213 BIMAGE - https://reshax.com/topic/18567-wolfenstein-the-new-order-wolfenstein-the-old-blood-bimage-files/#comment-101214 STREAMED.RESOURCES - https://reshax.com/topic/18568-wolfenstein-the-new-order-wolfenstein-the-old-blood-streamedresources/#comment-101215 VIRTUALTEXTURES - https://reshax.com/topic/18569-wolfenstein-the-new-order-wolfenstein-the-old-blood-pages-virtualtextures/#comment-101216 wolfesntein_resources.py wolfesntein_resources.zip

You could check the MakeH2O_log.txt. If you find a structure like 12 4 4 4 4 4 (for example) the last "4 bytes block" might be alpha uvs (just a wild guess). edit: it's 16 8 8 4 4 here Try using 82ea3, 4 for uvs. Looks promising.

I've been trying to work on Jon Jones hair (beard) file and was able to export it with the beard diffuse UV, but I'm struggling to get the proper UV for the alpha texture. Any suggestions? hair_jon_jones_model.mcd(decompressed).7z

I think you've already set up the aes-key and the correct version of Octopath Traveler 0 (5.4) on fmodel. You need to add the usmap file, which I attached. To do this, go to Settings->Mapping File Path and select the game's usmap file. Then, in Fmodel, navigate to the correct folder (e.g., Content/Local/DataBase/GameText/Localize/EN-US/SystemText/GameTextUI.uasset) and export the file to .json, with right-click and then Save properties (.json).

I am attaching the fmodel json file. With uassetgui, what procedure did you follow to obtain that result? Maybe I'm missing something, as this is the first time I've used uassetgui. Edit: Ah ok, thanks, with .\UAssetGUI tojson GameTextUI.uasset GameTextUI.json VER_UE5_4 Mappings.usmap I can get the base64 code, but it is unreadable: ����������m_DataList�d��m_id��m_gametext��No data.�������������m_id�m_gametext��Held�������������m_id �m_gametext��None�������������m_id! GameTextUI_fmodel.rar

Yeah, the DWord face indices totally don't fit but I have a déjà vue of this picture, maybe on former Xentax? edit: correct vertex start is 0x144

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