Leaderboard

I'm trying my best to make it load somehow

Actually the LZSS provide above, is wrong, for the files. I did the reverse enginner of the algorithim, Try the tool, see if the image get right TenchuWoH_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:

Thanks for some info from here and made a tool for unpacking and packing localize map files, if someone is interested in it. https://github.com/dest1yo/wwm_utils

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

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.

here you go : 0x09D01B34E843AC6BE08BD854B3CEDA0C4CA52281C08B02BF827F3ADA77173BCA

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)

hi need help ripping and reverse engineering the Geekjam, Toejam, and the Earl models from Toejam and Earl III for a animation. below are the .funk files (which is located in the bdl folder for some reason idk) and .bmt files for each character. files for toe jammin and fateral.zip

Found a bug with the python script. To the left is the wrist_r data from the .mot file. To the write is the data I got from exporting the .mot file to .csv. Maybe they are actually SUPPOSED TO BE this. I could be wrong. But am curious.

So here's pixel format for ps4. PF_DXT5 = 7 PF_DXT1 = 13 PF_BC7U = 22 PF_UNKNOWN = 2 not sure but can be RGBA

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

tool.py Here a working script that will output json file with { hash: text, ... }

Here my analysis: Header: 24 bytes: [ Int64 EntryCount Int64 ValueCount Int32 Timestamp Int32 Padding ] Buckets: [24-528] bytes, based on allocated bucket TableEntries: EntryCount * [ 8 Bytes Hash(or id?), Int32 RelativeOffset, (formula: text_start = current_entry_offset + 8 + value) Int32 TextLength ] Values: ValueCount * [ Byte[ValueLength] Data ] Null value have zero length and no hash. Successfully unpack and pack, the game load new text normally.

thanks 2001_800xcsled.zip 1999_440xcrsled.zip

make some ajustments! now its working

Hello Ikskoks! Thank for the solution. I have seen most of your links long ago but because it says nothing about the "mysterious bytes" after the string "grid", I fall in the conclusion that SOL Files isn't documentation enough. Crazy though, I wouldn't care about where the AMF format bytes data is, as long as the script reproduces a SOL file format and work on the Flash game in question is what matter, like I did with DS-nitro-files-builder. Regardless, this is clearer now. So, there are SOL Editors. My Python project is useless!

In the ..var01.st2 csv data is contained: edit: and xml data: <!-- ______________________________________________________________________________ Copyright 2004 The Collective, Inc. DISMEMBERMENT DEFINITION Character: Clone Trooper Author: Baback Elmieh Date: 01/07/2004 ______________________________________________________________________________ --> <!-- HEAD --> <DismemberablePart Name="Head" Hitpoints="25"> <!-- The Materials section is a list of materials in the original mesh that are to be turned off when the part is dismembered --> <!-- <Materials> <Material Name="headSG"/> </Materials> --> <!-- ReactionProcessing defines the chunks and particles to be spawned when a reaction dismemberment is processed for the character the definition requires a Bone from which a chunk should be spawned and the name of the chunkmesh. The ChunkMesh definition in turn can have several values set such as GravityScale and UseGinFile. GravityScale greater than 1.0 pulls a chunk down faster, UseGinFile will look for a bounding box with the same name as the chunkmesh in the damage mesh's gin file, if the bound is found, it is used instead of the default rendering bound which can help artists orientate chunks so that they land on their correct side --> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="neck_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <!-- <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="neck_g"> <Param Name="ChunkMesh" Value="head"/> <Param Name="GravityScale" Value="1.4"/> <Param Name="RandomVelocityScale" Value="0.2"/> </Param> </Chunk> --> </ReactionProcessing> <!-- The Capsules section provides a list of capsules that should affect the hitpoint of the part and should be disabled once the chunk has been dismembered --> <Capsules> <Capsule Name="Dneck_g"/> </Capsules> </DismemberablePart> <!-- LEFT SHOULDER --> <DismemberablePart Name="Left Shoulder" Hitpoints="25"> <Materials> <Material Name="Shoulder_LSG"/> </Materials> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="shoulder_L_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="shoulder_L_g"> <Param Name="ChunkMesh" Value="Shoulder_L"/> <Param Name="GravityScale" Value="1.8"/> <Param Name="RandomVelocityScale" Value="0.1"/> </Param> </Chunk> </ReactionProcessing> <Capsules> <Capsule Name="Dshoulder_L_g"/> </Capsules> </DismemberablePart> <!-- RIGHT ELBOW --> <DismemberablePart Name="Right Shoulder" Hitpoints="25"> <Materials> <Material Name="Elbow_RSG"/> </Materials> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="shoulder_R_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="shoulder_R_g"> <Param Name="ChunkMesh" Value="Elbow_R"/> <Param Name="GravityScale" Value="1.8"/> <Param Name="RandomVelocityScale" Value="0.1"/> </Param> </Chunk> </ReactionProcessing> <Capsules> <Capsule Name="Dshoulder_R_g"/> </Capsules> </DismemberablePart> </DismembermentDefinition>

Yea, I'm working on BHD but mostly focused on the JO/DFX2 engine which is slightly newer and a different format. I'll post here when/if I get BHD usable.

.ilv.txth: codec = PSX channels = 2 sample_rate = 44100 interleave = 0x4000 num_samples = data_size

Hi Shak-otay, yes it's me, I never imagined you would remember me 😄. I found this texture in the file.

Bumping this again because I really don't want this thread to quietly die, as it seems the edits to my message are not enough to constitute a bump. Every single possible 16 bit float format I've tried does not work. Indicating this is some proprietary cursed format. Maybe a LUT. Maybe encrypted. Maybe something else. Which probably explains why the .mot files still have not been decrypted all these years. I do suspect what certain bits mean but I am really unsure. I have the model .bin and some other examples of .mot in hand as well so if you would like me to send it I will gladly do so. Just note I do need these files decrypted for a project so I would like this done as fast as possible it would be nice. What I do know is that this is little endian. Z-Y-X order. I have no clue what else. Help is much appreciated please 🙏 (I am not sure what y'all want but I am interested in a way to export the .mot to .csv with a Frame # column. For my application, that is enough.)

Well, I did a little research on Flash Cookies (SOL files) and I put it all together in the article on RE Wiki https://rewiki.miraheze.org/wiki/Flash_Cookie_SOL I saw notes on your github and you were sligthly wrong with some fields, so you can compare it with my article on the wiki and make some corrections in your tool. The most important thing is that you should understand that SOL file is an Adobe format and payload (data block) follows AMF file format documented by Adobe https://web.archive.org/web/20220122035930/https://www.adobe.com/content/dam/acom/en/devnet/pdf/amf-file-format-spec.pdf So anything after data block header is a payload section that needs to be properly serialized by your tool. There are many tools that allow you proper serialization like: minerva, SOL Editor, Adobe AIR SDK, JPEXS Free Flash Decompiler etc. Some code for serializing is available on JPEXS github page: https://github.com/jindrapetrik/jpexs-decompiler/tree/master/libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/sol https://github.com/jindrapetrik/jpexs-decompiler/tree/master/libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/amf/amf3 You can test this code by going to Tools > Sol cookie editor in JPEXS Free Flash Decompiler: So you shouldn't ask "what are those three bytes". You should ask "how can I properly parse AMF3 serialized data" 🙂 There are lots of information (articles) about this, for example on wikipedia: https://en.wikipedia.org/wiki/Local_shared_object https://en.wikipedia.org/wiki/Action_Message_Format Good luck. 🙂

I did the descompressor and compressor but in c++, need to test the compressor thought, because is compressing better than the original. Test in game and show the results, if works. MACROSS_PS1_TOOL.zip

What I'm trying to do is create a new texture and trying to add an alpha channel while hex editing. The Zip File I provided is mostly for demonstration purposes. I'm trying to edit NINJA_FACE_DAMAGE_000, NINJA_FACE_DAMAGE_001, and NINJA_FACE_DAMAGE_002. My biggest problem is that the textures I'm trying to add an alpha channel to is different than it's original textures and is swizzled differently thus the alpha channel will be different. I am aware the image data will always start at 592 (0x250) and palette data differs depending on the size of the texture 64x64 (0x12A0), 128x128 (0x42A0), 256x256 (0x102D0). Anyways, I was able to use ImageHeat to get an alpha channel from the original textures with PAL8 pixel and RGBA8888 palette and exported it. Also, was able to use the ReverseBox Demo 2 to export and import the original textures just to get familiar with it. These are just a few textures that I'm trying to insert into the game and the alpha channels. MKD Texture Edit.zip

Here's a sample model for one of the enemies in the game. Notice that "*_div.msb" can't be view/export properly for some reason, but the base one did just fine. PSVitaSample.zip

fmt_psaVita_ValkyrieDrive.py Here's a old noesis plugin to view and export most of the mib, msb and mab of the PSVisa version of the game.

by the way if you need names of audio files put thesescript.zip in AetherGazerLauncher\AetherGazer\AetherGazer_Data\StreamingAssets\Windows folder , run process.py then it will change every audio .ys files to proper names.

rename it to .awb files then use the lastest vgmstream, works well

They are still pck files. I can find many wwise .bnk files in AA462ABBFEC319B665666E14585F97D9_EndfieldBeta with ravioli explorer , RavioliGameTools_v2.10.zip (if you need)and I think quickbms also work. By the way I guess the really wem audio files are in another pck files. there are over 5000 bnk files in AA462ABBFEC319B665666E14585F97D9_EndfieldBeta. That means the bnk files may not store any actual audio files

I have one as an example I notice in this section Ran XXD with groups of 12 and noticed a pattern. This is the pinky intermediate joint. It is known that the pinky intermediate joint has one degree of freedom. meaning that movements in the other two DoF should be minimal. The second set of each float is stable. 16 bit floats. Little endian likely. Meaning that [3f], [00], [ff], etc. is the major bits. Given the ffs I do not think it is Big Endian with an offset. I have attached the file in question so you can look yourself EDIT: These are signed LE numbers. Circular angular floats (not IEEE 754 standard) so ffff/0000, 3fff/4000, 7fff/8000, bfff/c000 are each 90 degrees apart. EDIT 2: It could also be a LUT. But then I checked for any tables and I can't find any useful. EDIT 3: I have no clue anymore. These are proprietary obfuscated numbers using some cryptic format and if anyone knows how to decode them it would be absolutely amazing. SVT_0015_S01_ATK_A01.zip

Anybody could share mot, tex_db.bin and a model file .bin of a character

I've been doing a Noesis script for the beta of Once Human. Still got a few things to do on it, but it should work for most of the models so far: Edit: Read the notes at the start of the script regarding the various files needed. once_human_mesh.zip

in the end, I did it, thanks to everyone who posted on this topic.

My script for another game should work with these GSB files: https://github.com/DKDave/Scripts/blob/master/QuickBMS/GameCube/Legend_Of_Spyro_New_Beginning_(GameCube)_GSB.bms

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

Bumping this, if anyone would be an absolute unit to solve the animations it would be greatly appreciated! 🙃

use my plugin for Noesis arc_zlib_plzp_lang_vfs.py (which I mentioned earlier) it recursively unpacks all files, at the output you will get *.png, *.wav, *.pm3, *.vram, *.text, *.pvr and e.t.c You can also find a link to the plugin for 3D models *.vram above in the same topic. (*.pvr can open in PVRTexTool)

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

The WAVE files just use XBox ADPCM (not that obscure) and you can play and convert them with Foobar + vgmstream (note: some files don't contain audio). You don't really need to do anything else.

Maybe you should open a new thread and ask in there, not here, because this thread is for discussing the motion file.

I'm still not sure how to run it, unless I'm doing something wrong, it doesn't seem to be working

for fgo's script, you just need run this: python FGOArcade-FARC.py "your farcfile path" for farcpack tool, Run it in the shell to see the cli commands.

How exactly should I use it? First I have to decrypt the farc files, right? To decrypt the 3D Models I was using quickbms and the script that was on XeNTaX, but that script can't decrypt the farcs from the trading cards

yeah i guess so. but I think we need to find something to differentiate between rotate data or transform data, and it's hard to find that, so we need something reverse work

https://github.com/h-kidd/noesis-project-diva AFAIK this uses the same (or highly relevant - Virtua Fighter 5 based) engine as other arcade games such as Project DIVA Arcade or Fate Grand Order I guess the animation format would be relevant (and hope this be helpful for REing)