Luigi Auriemma

FredPJ · **Joined:** 12 Jul 2009 17:07 **Posts:** 4

Is anyone working on reversing this WMA Pro based Xbox 360 codec?

This Russian tool successfully decodes XMA files (and XMA files inside FSB containers), however it doesn't support Multichannel files:
http://www.ctpax-x.ru/index.php?goto=fi ... 24&lang=en

Interesting document with some general info:
https://devel.nuclex.org/external/svn/d ... xma2defs.h

XMA encoder .dll file from FMOD:
http://www.mediafire.com/?znwyy24z3mu

Decrypted FSB samples from GH:WT containing Multichannel XMA files (not supported by ToWAV):
http://www.mediafire.com/?zyzzm1mt1mv

aluigi · **Posted:** 12 Jul 2009 22:22

personally no.
the only thing I verified some months ago (only for curiosity) was that towav uses an official Microsoft library which looks very similar to wmapro.
that's all I know about this thing.

FredPJ · **Joined:** 12 Jul 2009 17:07 **Posts:** 4

Ok, thanks!

bnw33 · **Joined:** 19 Jul 2009 17:06 **Posts:** 4

Hey Fred, How did you decrypt the .xen format? How did you uncover the algorithm behind that?

nvm, i found the key. Is the .xma file in the .fsb encrypted somehow?

FredPJ · **Joined:** 12 Jul 2009 17:07 **Posts:** 4

No, the XMA files are not encrypted, they're (headerless) multichannel XMA files, so they need to be decoded as such. As you can read here, the data is interleaved:
https://devel.nuclex.org/external/svn/d ... xma2defs.h

Quote:

// MULTICHANNEL AUDIO: the XMA decoder can only decode raw XMA data into either
// mono or stereo PCM data. In order to encode a 6-channel file (say), the file
// must be deinterleaved into 3 stereo streams that are encoded independently,
// producing 3 encoded XMA data streams. Then the packets in these 3 streams
// are interleaved to produce a single XMA2 file, and some information is added
// to the file so that the original 6-channel audio can be reconstructed at
// decode time. This works using the concept of an XMA stream (see above).
//
// The frames for all the streams in an XMA file are interleaved in an arbitrary
// order. To locate a frame that belongs to a given stream in a given XMA block,
// you must examine the first few packets in the block. Here (and only here) the
// packets are guaranteed to be presented in stream order, so that all frames
// beginning in packet 0 belong to stream 0 (the first stereo pair), etc.
//
// (This means that when decoding multi-stream XMA files, only entire XMA blocks
// should be submitted to the decoder; otherwise it cannot know which frames
// belong to which stream.)
//
// Once you have one frame that belongs to a given stream, you can find the next
// one by looking at the frame's 'NextFrameOffsetBits' value (which is stored in
// its first 15 bits; see XMAFRAME below). The GetXmaFrameBitPosition function
// uses this technique.

ToWAV apparently doesn't work with multichannel files but if you stick a regular XMA header to it ( http://www.mediafire.com/?gitfmumgotj ), you can pass it through ToWAV ( http://www.ctpax-x.ru/index.php?goto=fi ... 24&lang=en ) and you'll actually hear some frames of the interleaved audio.

bnw33 · **Joined:** 19 Jul 2009 17:06 **Posts:** 4

The multi channel mp3 files in ghwt pc are sequentially interleaved. Kindof sucks that the xma streams aren't.

Is each frame supposed to have a 15 bit value for the size?, like the first 15 bits correspond to the size of the frame. The document also states that the 'nextFrameOffsetBits value is stored in the first 15 bits of the frame (see page 2, like halfway down.) So I don't know which one to believe.

hcs · **Posted:** 16 Aug 2009 19:55

I'd taken a look at toWav and came to the same conclusion as aluigi, it seems that a wmapro decoder (codec id 0x162, probably MS's due to the error codes) is set up with decode flags 0x10D6, but I never got much further than that. Here's the relevant disassembly:
http://hcs64.com/files/xma_setup.txt
The wma3dec stuff for ffmpeg doesn't support those flags yet. I wonder if it might be possible to take the header this thing builds and use it in an ordinary wmapro decoder, but I didn't get to trying it.

For those interested in the overall packet layout, I had put together a little XMA stream parser:
http://hcs64.com/files/xma_parse01.zip
All this does is parse to see if it works, though. It doesn't look for other streams, but if there is another stream and you start the decoding after the first packet you should have it.

Sorry for resurrecting this month-old thread, but someone just pointed it out to me today and I thought you folks might be interested to see what little progress I'd made.

aluigi · **Posted:** 19 Sep 2009 19:03

the libraries for decoding the xma files are contained in the xbox development kit sdk

FredPJ · **Joined:** 12 Jul 2009 17:07 **Posts:** 4

aluigi wrote:

the libraries for decoding the xma files are contained in the xbox development kit sdk

Great, but are they documented/usable? I still haven't taken a look at the SDK.

aluigi · **Posted:** 28 Sep 2009 09:36

there is a small documentation about the XMA* APIs, the only thing missing seems the library but that's all I know

OrangeC · **Joined:** 13 Sep 2009 17:33 **Posts:** 11

bnw from the scorehero forums updated his guitar hero tools and it includes xma extract which seperates the multichannel xma's works very good :).

aluigi · **Posted:** 03 Oct 2009 18:45

uhmmm are you sure you are not talking about mp3extract?
(it's a quick search I did with google so maybe I'm wrong, I don't know that forum or guitar hero or anything else related)

bnw33 · **Joined:** 19 Jul 2009 17:06 **Posts:** 4

yeah, xmaextract extracts the streams, but no dice for decoding =(.

I took a look at the white papers in the sdk, but none of them reveal much about the encoding/decoding process.

tx802 · **Joined:** 18 Oct 2009 19:42 **Posts:** 7

bnw33 wrote:

yeah, xmaextract extracts the streams, but no dice for decoding =(.

I took a look at the white papers in the sdk, but none of them reveal much about the encoding/decoding process.

bnw33, Could you please tell me how to run/use your xmaextract. I need to seperate some multichannel xma's.

Thanks.

crzdrum · **Joined:** 06 Nov 2010 14:42 **Posts:** 20

hcs · **Posted:** 06 Nov 2010 15:44

You may wish to take a look at the discussion of mutlichannel XMA in this other thread: viewtopic.php?f=3&t=1174
I suggest using the methods described in this post: post8749.html#p8749
using the latest version of xma_parse found here: http://hcs64.com/vgm_ripping.html

crzdrum · **Joined:** 06 Nov 2010 14:42 **Posts:** 20

crzdrum · **Joined:** 06 Nov 2010 14:42 **Posts:** 20

hcs · **Posted:** 06 Nov 2010 22:05

I'm not sure what xmaextract does but it's probably not going to result in clean streams. I suggest:
1,2. as before
3. fsbext to extract the raw 6-channel XMA2 stream
4. xma_test three times, with offsets 0, 800, and 1000, to rebuild each stereo stream as XMA1
5,6. as before

crzdrum · **Joined:** 06 Nov 2010 14:42 **Posts:** 20

hcs · **Posted:** 06 Nov 2010 22:39

oh, last one would be at 1800, I guess

crzdrum · **Joined:** 06 Nov 2010 14:42 **Posts:** 20

crzdrum · **Joined:** 06 Nov 2010 14:42 **Posts:** 20

aluigi · **Posted:** 07 Nov 2010 16:49

I have analyzed that file and the problem is that it reports a file offset which is wrong, watch here:

Code:

- 00000000 fr_FSOUND_FSB_HEADER_FSB4:
  fh->id         FSB4
  fh->numsamples 00000001
  fh->shdrsize   0b011d10
  fh->datasize   f6d2da00
  fh->version    00040000
  fh->mode       00000000
- FSB4 version 4.0 mode 0
- names offset  00000030
- files offset  0b011d40

as you can see the file offset can't be 0x0b011d40 because the file is only 0xd2f740 bytes so fsbext can't work on it because it's not standard.

in my opinion the data of the first file (the "soooo" one) should start from offset 0x740 but obviously without exact informations in the header is not possible to "guess" it or maybe in this case it's possible because it's only one file but not in general

crzdrum · **Joined:** 06 Nov 2010 14:42 **Posts:** 20

crzdrum · **Joined:** 06 Nov 2010 14:42 **Posts:** 20

aluigi · **Posted:** 07 Nov 2010 18:50

it's that "10 1d 01 0b" at offset 8.
it becomes 0x0b011d40 because it's a relative offset so you must add the header of 0x30 bytes

crzdrum · **Joined:** 06 Nov 2010 14:42 **Posts:** 20

crzdrum · **Joined:** 06 Nov 2010 14:42 **Posts:** 20

hcs · **Posted:** 07 Nov 2010 23:12

It looks like the decryption screwed up on those. Maybe try guessfsb to find another key and decrypt it manually with decfsb (which is in with guessfsb). (at http://hcs64.com/vgm_ripping.html )