Decryption of WXA files results in only audio

[XBrav]

Environment

jPSXdec version: 0.99.8rev3788 Operating system: Windows 10 x64 Java runtime environment: Unsure

PlayStation Game (if applicable)

Name: ReBoot Region code (e.g. SLUS-1234): SLUS-00274

Description

When trying to decrypt the WXA videos, which appear to be XA with video wrapping, the application only detects the audio layer. The audio sectors seem to span the entirety of the file, so I am unsure where the video would be wrapped within the file.

EA.zip

[m35]

There is indeed video in there, but it breaks some of the rules so it's not detected :/

[XBrav]

Unfortunately I have had little luck in unwrapping the video data. Is there a way we can strip out the detected audio to decode the video payload, or is it wrapped within the audio?

[m35]

I don't know if you're up for it, but the layout of FMVs is described in chapter 1.2. How the PlayStation reads data from the disc of https://github.com/m35/jpsxdec/blob/readme/jpsxdec/PlayStation1_STR_format.txt You can view the sector layout of your disc or files using the command java -jar jpsxdec.jar -f EA.WXA -sectordump ea.txt The video sectors could be easily identifiable by looking for Submode:-R----V- (R=real time, V=video) But the 32 byte video sector headers of this game are not conforming to the standard STR sector header described in :: STR Frame Sector Header ::, so jPSXdec doesn't know what to do with them. However, the 32 byte header format is close. We'd need to check what values are used in all the video sector headers so we can add the necessary support for the unique video sector type. The new sector type would look much like https://github.com/m35/jpsxdec/blob/readme/jpsxdec/src/jpsxdec/modules/strvideo/SectorStrVideo.java

[XBrav]

Ok. I have a good chunk of videos, so I'll have a look and see if the headers are common for this game. Thanks!

[XBrav]

So far, the only major deviation I can see is with the magic "0x3800" fields. I haven't decoded the actual video data (too lazy to re-write it if I don't have to), but it seems to align with the spec otherwise on quick glance. For whatever reason, the magic field on this one seems to be 0x0064 as per the attached report I generated.

Sorry, I'm really not a java guy. Could you try compiling with a flag to switch the magic number to 0x0064? test.txt

EDIT Want to try 0x0064 for this test, but each file seems to change that magic number a bit, but it remains the same for the entire WXA file. I'm curious if the rule is truly required...

EDIT 2 So editing the magic numbers in didn't allow the app to translate it. Here's what I can see:

1) Frames start at 0. 2) The first video frame is usually on the 2nd sector, preceded by an audio frame 3) Number of MDEX frames required is always 0x0000.

[m35]

Yeah finding the patterns is the most time consuming part. I'd ultimately write a little program to dump the first 32 bytes and sector number of every video sector into a text file and run some analysis on all the values. Edit which is exactly what you did! (sorry missed the link). It's also important to understand as many values as possible since they may be important when replacing frames.

[XBrav]

I realized I blended that text file into the post a bit, so no worries.

I wrote a little python app to do just that, assuming the entire disk is Mode 2 (which it appears to be for all the videos). I can compile a report for you tonight, but so far the above mentioned deviations seem common. Each WXA file seems to have a unique value in the 0x3800 field, which is consistent for all frame data.

Have you determined how the 0x3800 corresponds to the decryption, or is it just a payload validation? I'm wondering if it's just easier to add an options menu to enable / disable the frame and 0x3800 checks.

[XBrav]

Ok, uploading so we can both look at this:

https://drive.google.com/file/d/1qAoK292wW3Uy1dwwX3Gnkhkd6xfet7Vh/view?usp=sharing

This is the report of all the WXA files in the game's MOVIES directory. It looks as if what I said above remains true.

[XBrav]

WHEW! That was a furious night of coding.

Although I couldn't adapt the app to actually read the files, I was able to modify the original payloads to do so!

To get the videos to read under the STR format, you need to modify the following bytes:

1) MDEC 32 bytes block needs to be 1 or greater, so I wrote 0x1. 2) Magic 0x3800 needs to be present, so I overwrote the registers with 0x3800 3) Frame Version is 0x0000 in these files, so I set it to version 2. 4) Quantization needs to be greater than 0, so set to 1.

Doing this causes all the videos to play with zero errors.

Not sure if it's worthwhile to write a new rule into the parser, but if you can somehow write in above tolerances, the app can open the files natively.

[m35]

Absolutely brilliant! Thanks a ton for sticking with it. Understanding all the fields that are different gives me what I need to add handling for this new video variation. I'll add the handling and put together a build for you this weekend to try.

The way 0x3800 is different, but consistent across the whole video, it reminds me of other video variations that put the video frame count in the header for some reason. I don't know if you can find some kind of correlation about the videos and the 0x3800 values. But in any case, I think we're good to go.

[XBrav]

On first guess looking at the first file, the magic number partially correlates to the number of frames in the video. For my first video, instead of 0x0038 (decoded), it's 0x03D0. The last Frame Number is 0x03C9. For the EA one above, the magic number is 0x0064, and the last frame is 0x005E

It seemingly has no impact on this payload at least.

[m35]

Here's the build, give it a try jpsxdec_v0-99-8_reboot_bin_src.zip

[XBrav]

Works great! I'll check the PAL ISO in a bit, but it worked with zero errors on the mdf image. Thanks!

[m35]

Incorporated into this release https://github.com/m35/jpsxdec/releases/tag/v0.99.9