Ubisoft MPEG files (Tonic Trouble)

[Droolie]

Hey there!

I'm looking to decode the Ubisoft MPEG files found in Tonic Trouble, and I'd be forever grateful if anyone could help.

Here are some examples of stereo Ubisoft MPEG files: https://app.box.com/s/4a8u0kbfe1izlewedqjl and download/file.php?id=6911
Here are 3 examples of mono Ubisoft MPEG files (they're voice tracks): https://app.box.com/s/qypjqe1pypd9dtmncern
The stereo files are likely a little harder to handle, as the channels in those files seem to be interleaved.

The tracks seem to be 16-bit 44100Hz files, and from what I've found, the format is a bit like this:

Code: Select all

0x4 - the amount of samples of the audio track. Seems to be used only for loop length.
0x4 - "2RUS" header for stereo, "1RUS" header for mono
0x??- frame header, starting with at least 8 "on" bits (11111111). This start is just like MPEG, but the rest of the header isn't...
[ frame ]
0x?? - frame header, not offset to a particular byte (as in, there can be 2 "on" bits at the end of one byte and 6 at the beginning of the following byte)
[ frame ]
etc.

If it can be of any help, these are the DLL files the game uses to play them: download/file.php?id=6928

Many thanks,
Droolie.

[kooz]

Sorry for necroing this super old thread, but I've had a recent resurgence of interest in decoding these streams. DecUbiSnd isn't recognizing them.

Maybe the MPX files are bigfiles containing segments of music, each of them with a header with "2RUS" in it? Just a guess.

Droolie is definitely correct; the MPX files are bigfiles, while the corresponding CSB file stores the stream offsets and seems to define an array for sample play order/volume/repeat info, etc. The CSB is in plain-text and describes individual segments as "SAMPLE_MPEG" but I can't seem to find any layer 1, 2, or 3 decoder that will play them.

Attaching the CSBs that should be paired with Droolie's earlier upload (which is still online), on the off-chance someone is willing to take a look at this.

[Droolie]

My apologies for again necroing this old thread, but could anyone please look at this? I've attached two files to my post that should each contain a small segment of a song. According to descriptions in the CSB and BNK soundbank files, they should be 44100Hz, 16 bits and stereo...

2RUS.zip

This is what I've managed to figure out about the format:
0x4 - The first 4 bytes are always larger than the amount of bytes in the file itself. Could the file be compressed somehow?
0x4 - "2RUS" header
0x??- block header, starting with a FF byte (or 11111111 if you like bits). The FF start is just like MPEG, but the rest of the header isn't...
[ block ]
0x?? - block header
[ block ]
etc.
That's what I have so far, but I could be wrong...

Can anyone help?

[Droolie]

Here's a quick bump, adding more files and hoping that someone might look at it: https://app.box.com/s/4a8u0kbfe1izlewedqjl
I also attached the DLL files that are used to play these MPEG audio files.

dll.zip

Will anyone take a look or am I doomed to search alone forever?

[Droolie]

I'm still looking at this and still quite stuck. I've started actually playing the game and trying to see how it plays the music. It seems if you change the "2RUS" to "1RUS", it attempts to play the tracks in mono, showing how the channels in these files are interleaved.

Any help please?

[Droolie]

My apologies for the constant necroing of this topic... but whoever helps with this will be my personal hero!

[Droolie]

I'm still looking for this, and any help at all would be fantastic.

I figured out a little more by doing some tests while playing and updated the first post with all the relevant details on the format I was able to figure out (not much).
I also added 3 examples of mono Ubisoft MPEG files (they're voice tracks): https://app.box.com/s/qypjqe1pypd9dtmncern
The stereo files I attached to my previous posts are likely a little harder to handle, as the channels in those files seem to be interleaved.

I'd be forever grateful if you could at least try to help figure it out!

[kooz]

Okay... I'm not sure if I'm getting anywhere here, but it feels like I'm on the right track. MPGMXBVR.DLL has several functions, but the most prominently interesting is SND_fn_lPlayMPEG, which I saw running in memory by using Cheat Engine.

That led me to experimenting with OllyDbg, which offered the very much enticing prospect of loading a DLL. Unfortunately, I hit some roadblocks when I discovered that SND_fn_lPlayMPEG wants 5 different integers passed to it, which I have yet to determine how to define...

Using IDA, I was able to get some pseudo-code which looks like it could possibly be the decryption method:

Code: Select all

signed int __stdcall SND_fn_lPlayMPEG(int a1, int a2, int a3, int a4, int a5)
{
  int v6; // [sp+4h] [bp-10h]@5
  int v7; // [sp+4h] [bp-10h]@16
  __int16 v8; // [sp+8h] [bp-Ch]@7
  __int16 v9; // [sp+8h] [bp-Ch]@18

  if ( !dword_10024CBC )
    return -1;
  if ( dword_10024CB8 )
  {
    sub_10006BA2(dword_10024CAC);
    dword_10024CB8 = 0;
  }
  if ( *(_DWORD *)(a1 + 40) )
  {
    v6 = sub_100046E3(a1 + 48, *(_DWORD *)(a1 + 64));
    if ( v6 )
    {
      if ( *(_DWORD *)(a1 + 24) )
        v8 = *(_BYTE *)(a1 + 12) * *(_BYTE *)(a2 + 4) >> 7;
      else
        v8 = *(_BYTE *)(a1 + 12);
      *(_BYTE *)(v6 + 146) = *(_BYTE *)(a1 + 12);
      *(_BYTE *)(v6 + 147) = v8;
      *(_BYTE *)(v6 + 148) = byte_100266A0[v8];
      *(_DWORD *)(v6 + 60) = *(_DWORD *)(a1 + 24);
      if ( *(_DWORD *)(v6 + 160) )
      {
        *(_BYTE *)(*(_DWORD *)(v6 + 160) + 146) = *(_BYTE *)(a1 + 12);
        *(_BYTE *)(*(_DWORD *)(v6 + 160) + 147) = v8;
        *(_BYTE *)(*(_DWORD *)(v6 + 160) + 148) = byte_100266A0[v8];
        *(_DWORD *)(*(_DWORD *)(v6 + 160) + 60) = *(_DWORD *)(a1 + 24);
      }
      if ( a4 )
      {
        *(_DWORD *)(v6 + 40) = a4;
        *(_DWORD *)(v6 + 36) = a5;
      }
      else
      {
        *(_DWORD *)(v6 + 40) = 0;
      }
      return v6;
    }
    return -1;
  }
  v7 = sub_100048A6(*(_DWORD *)(a1 + 48), *(_DWORD *)(a1 + 56));
  if ( !v7 )
    return -1;
  if ( *(_DWORD *)(a1 + 24) )
    v9 = *(_BYTE *)(a1 + 12) * *(_BYTE *)(a2 + 4) >> 7;
  else
    v9 = *(_BYTE *)(a1 + 12);
  *(_BYTE *)(v7 + 146) = *(_BYTE *)(a1 + 12);
  *(_BYTE *)(v7 + 147) = v9;
  *(_BYTE *)(v7 + 148) = byte_100266A0[v9];
  *(_DWORD *)(v7 + 60) = *(_DWORD *)(a1 + 24);
  if ( *(_DWORD *)(v7 + 160) )
  {
    *(_BYTE *)(*(_DWORD *)(v7 + 160) + 146) = *(_BYTE *)(a1 + 12);
    *(_BYTE *)(*(_DWORD *)(v7 + 160) + 147) = v9;
    *(_BYTE *)(*(_DWORD *)(v7 + 160) + 148) = byte_100266A0[v9];
    *(_DWORD *)(*(_DWORD *)(v7 + 160) + 60) = *(_DWORD *)(a1 + 24);
  }
  if ( a4 )
  {
    *(_DWORD *)(v7 + 40) = a4;
    *(_DWORD *)(v7 + 36) = a5;
  }
  else
  {
    *(_DWORD *)(v7 + 40) = 0;
  }
  return v7;
}

I am still having a really hard time making sense of it. I would love to have one of our many forum experts give a helping hand!

[daemon1]

You really should mention that these mpeg files come from special version of the game. I'm going to look into that now, if you still need it.

[kooz]

Yes, sorry, I forgot to mention, these are from the special edition (or beta) version of the game. Thank you so much for looking into it!

If you need any additional files I would be happy to provide them.

[daemon1]

No, I have all the files. Did some research. There are 2 possible ways to decode this.

1. reverse the decoding function. That code you provided is only one tiny part of it. The whole thing includes dozens of subroutines and floating point tables. You could expect that from mpeg-like codec. So reversing this will probably take months, and if its only for 1 game, its just not worth it.

2. find a way to call their DLL. This may be possible, but again, many troubles. They call many different DLLs one from another, and probably make callbacks. I have no idea yet how to do it.

[kooz]

That's really unfortunate. I thought I was on to something there.

On another note, I tried editing a CSB file to get it to load parts from another MPX and it completely ignored my changes. I am not sure if those are even used by the compiled game... they may just be remnants from source code.

[kooz]

Would it be possible to figure out the encryption/compression scheme if the file contained within is a known format?

See attached example - the header states that this is completely normal 44.1kHz 16-bit stereo wave file, yet it certainly doesn't play properly, and in a hex editor, the character distribution looks absolutely nothing like a wave file.

The game's CSB files indicate that these (as well as .MPX files) are stored/encrypted in a container: "SetZipFormat(SAMPLE_MPEG)"

[daemon1]

Would it be possible to figure out the encryption/compression scheme

No, they are not encrypted or compressed. This file is encoded into some kind of mpeg. The header doesn't mean anything. It's just information about the audio data.

[bsod49]

I asked for help on CTPAX, here's what I got:

"We tried to look into this format. It's more complex than it may look like.

Actual information about .MPX files stored inside .BNM files. Even more, .BNM files itself can have inside .WAV files, or packed ADPCM files.

By now we only can extact uncompressed .WAV files:
bnm_dump.zip (deleted for the group's request, I should have a copy, though).

We will look into .MPX decompression, but can't promise anything, since it's very complex and required .DLL files, it needs a lot of internal structures to be initialized properly to work."

I'll let you know on something new if I'll receive.