SSBB Snapshot files. We need to crack em!

Can someone convert my videos for me?

I've tried everything with the converter but it doesn't work.


edit: nevermind.

So from what I understand, instead of a converting program being made, it's just a little more complicated fix where someone would have to make a program with the physics and whatnot of Brawl along with all other data that could be found in a Replay. Of course, that would pretty much end up meaning that they'd have to pretty much remake a completely working game (from what I understand) simply to convert the Replays.

Which is silly and nearly impossible...

The answer to that is, unfortunately, going to be hardware based...

Helping compile a mac version

I was wondering if there was anything I could do to help make a mac binary of bindecrypt.

From the site:
(Mac binaries?): I'm not sure if I'll be able to make a bindecrypt for Mac, but I'll see.

So far I have downloaded the source and attempted to compile it using the GCC4 compiler that comes with Apples dev tools.

I got some kind of error about signedness. I'm currently taking a programming course and know some light C++ but I'm not good enough to figure out what the fix might be.

If I paste up my compiler's output could someone help me move forward?

Well, it really is a good thing I don't really care to convert replays. My main interest (and quite the reason I joined this forum) is in custom stage decryption and encryption.

Which is what I'm currently working on, a Stage Builder for PC.
Well, don't expect a release in near time, since I'm writing A-Levels next month. :<

Awesome idea; keep us posted.

You can't convert replays. Unless you can emulate Brawl perfectly on a PC, then you can't.

Replays are stored actions that are reproduced in the game. When you press a button, the button press and ONLY the button press is stored in the replay data. This is why some replays can become corrupted.

So, for example. When you record a replay in Home run contest, and all you do is grab the bat and use your smash attack on the sandbag, then this would be the replay:

Stage ID
Stage Music
Stage Flags
Stage etc
Character 1 ID
Character 1 Controller
Character 1 Flags
Character 1 etc
Character 2 ID
Character 2 Controller
Character 2 Flags
Character 2 etc
Character 3 ID
Character 3 Controller
Character 3 Flags
Character 3 etc
Character 4 ID
Character 4 Controller
Character 4 Flags
Character 4 etc
Character 5 ID
Character 5 Controller
Character 5 Flags
Character 5 etc
Character 6 ID
Character 6 Controller
Character 6 Flags
Character 6 etc
Character 7 ID
Character 7 Controller
Character 7 Flags
Character 7 etc

wait 500 ms
Left
wait 200 ms
A
wait 100 ms
Right
wait 240 ms
Right+A

Would be interesting to be able to break that down into a scripting type setup. For combo testing and whatnot.

That's not actually an error, but rather a warning. It's just letting you know that it was written on a machine with a different architecture than yours. The "out2jpg" source compiles just fine under UNIX, but do be aware that it is only latter half of the conversion process (ie. reassigning bits of a decrytped file using the LZSS algorithm).

To compile a source of the entire conversion process would require Nintendo's digital signatures, which is why such a file will not be released into the public domain.

I'll be launching a project that will make the help make the process easier for everyone in the near future, likely within a fortnight.

For the stage builder, would custom backgrounds ever be possible?

Not at all. That's built into the game.

God freaking ****it my programs keep crashing. Most probably a segmentation fault. Anyone knows how to fix this?

http://www.multiverseworks.com/tplconv/tplconv-crash.rar
http://www.multiverseworks.com/tplconv/stringextract.rar

Also, Heinermann, if you add 0xEFBBBF at the beginning of the text file, the text file automatically becomes UTF-8 formated. That way, you wouldn't need to convert the Japanese text to spaces at all, therefore saving some bytes and a few lines of code. Right now no Japanese characters are shown. I've made an attempt at it, but my code keeps crashing at a certain point.

Finally, Kirby was supposed to have a Giga Bowser hat, according to the sound files still present in the game. The sounds contain nothing, but they were there.

Ah thanks!
BTW can you have a look at the LZ77 compressed files in the ISO?

Sure, although so far I hadn't been able to do anything with them except getting myself to the point of crawling in a fetus position and crying in a corner.

I tried it with Animal Crossing: Wild World. If I can pull this off, I can finally decrypt that game. Tee hee!

Also, do you know why my programs keep crashing? Or should I just ditch Dev-CPP and go with Visual Studio?

Can anybody help me?

From what I hear, .bin files are images.

But when I transfered the files to my sd card, they were matches.

Anybody care to explain?

They were obviously not images then.

BIN files aren't just SSBB format, you know, it only stands for Binary, and even that isn't always true. BIN files can have all sorts of data, just like DAT files. Are DAT files exclusive to SSBB? No. The same goes for BIN files. BIN files aren't "just images". They are binary files. They can have anything, even porn can be saved as BIN files.

EDIT:

Small update on LZ77 cracking:

I've compared the extracted files from char_bust_tex_lz77.pac in the menu\selcharacter\ folder with the (uncompressed) buste data found in menu\common\char_bust_tex\, and I've come to the conclusion that bytes 1-4 ( with 0 being the first byte of course ) form the uncompressed data in little-endian. I'm not sure about the first byte though.

For the rest it seems a little bit strange. I still can't figure it out.

EDIT2:

Okay, this just hit me while waiting for Garry's Mod to be loaded.

After the header of five bytes you'll have the normal data. Each time after eight bytes of data you'll find something I'd call a pointer. It's actually a flag byte which determines after which bytes in the next round the copy byte lies.

Example:

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12

You'll see that the copy bytes themselves don't get counted with the pointers. So far it seems right. I only need to figure out now how the copy bytes themselves work.

EDIT3:

It could also possibly be that these copy bytes are paired in two, which would make it:

00 01 02 03 04 05 06 07 08 09 0A 0B 0C [0D 0E] 0F 10 11 12

EDIT4:

I'm now confident it is indeed the latter.

EDIT5:

Okay, try this.

For [xx yy] in copy pair do
Move yy positions left from position [xx yy]
Copy <- 2 * yy + 1 bytes
Replace [xx yy] with Copy
End

Example:

FF FF FF FF FF FF FF FF 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C [02 0E] 0F 10 11 12

First we encounter the flag byte. We remember which set is a pair. In this case there are no pairs ( 0x00 = 0000 0000 ). We move on to the next flag byte.

FF FF FF FF FF FF FF FF 00 01 02 03 04 05 06 07 08 09 0A 0B 0C [02 0E] 0F 10 11 12

In this case the fifth set is a pair ( 0x08 = 0000 1000 ).

FF FF FF FF FF FF FF FF 00 01 02 03 04 05 06 07 09 0A 0B 0C [02 0E] 0F 10 11 12
Remember 08

Go trough each set until we get to the position that corresponds with the bit of the flag byte. In this case it's the fifth set. This set is a byte ( also denoted in lime green ). We now count from that position back. This counting is done starting with zero. Then from there, count forward 2 * the first byte value, plus one. This is the copy set ( denoted in deep sky blue ).

FF FF FF FF FF [FF FF FF 00 01] 02 03 04 05 06 07 09 0A 0B 0C [02 0E] 0F 10 11 12

Finally, replace the copy bytes with the copy set.

FF FF FF FF FF [FF FF FF 00 01] 02 03 04 05 06 07 09 0A 0B 0C [FF FF FF 00 01] 0F 10 11 12

This goes on. The copy bytes will copy from the edited version, any alterations will also be used for counting.

Nice progress, Gary.
I'm really looking forward to get all the textures of the stage editor blocks. xD

Little waiting never killed me. Heck, if there was simply a program with a 'Load' Button, a 'SaveAs' Button, a 'Decrypt' Button, an 'Encrypt' Button, and a Hex Viewer/Editor (Optional), I'd be happy...and I'd probably have more fun editing it like that, ironically.

They're already ripable.

In fact, here are all the tiles:

http://www.multiverseworks.com/StageEditor.rar

No, he meant the actual stagebuilder textures. Not the stagebuider menu textures. (the ones designed for a 3D surface). He already has the thumbnail graphics.

Anyway good job on the LZ77 research. Will you write a program for it?


Anyone working on that checksum?

Just posting with some more info about this:

A stage file (but screenshot files are similar!) starts with 16 bytes of stuff (usually starting with 'o'), 4 bytes of more stuff, and then a ! and data. Nothing after the ! is changed when I take a stage and resave it immediately.

What does change is the 4 bytes at 0x10, which change to some completely random value, and anywhere from 4 to 6 of the bytes before that, depending on how long the period between the saves was.

This can't be a straight md5 because in that case it would change completely or not at all, and you would never see some of the bytes only changing sometimes. It also can't be a hash that only depends on the rest of the document since it changes even when the rest has no change. But it must depend on the document somehow, because changing the stage while keeping the header intact makes the file unreadable.

Of course, if any of those bytes is messed with you get a corrupted file.

The checksum has nothing to do with the date/time because saving the same file with a different filename causes it to show up with a different time, but no corrupted error.

Sorry, unless I can find a way to make my programs stop crashing I won't be able to do that.

Textures I can find, but I've got other priorities at the moment. Not to mention Garry's Mod and Audio-Surf keep me busy, especially now that I'm working on a remix of some songs I wrote.

Are you sure you're looking at the 8-byte checksum that binDecrypt DOESN'T produce?

Then I might as well have a go at it.

Wouldn't it be fun to convert Brawl to Garry's mod? xP
Making fighter SENTs, enemy SENTs and item SENTs. 8)

bindecrypt just skips over the first 16 (not 8) bytes of the decrypted file. DeLZSS then skips over 16 more bytes before it actually decompresses anything. What I refer to as changing is both the last 6 bytes of the first part that bindecrypt skips, and the first 4 bytes after that.

D'OH! I actually forgot about the first part of the copy byte. Apparently the amount of bytes copied isn't x * 2 + 1, but it's more 3 + x. Way more simple. Any less and it wouldn't even be useful.

Ok, since the development of the Stage Builder will be set on hold for the next couple of weeks due to A-Levels, I provide you some screenshots of it's current state.
Mostly renders of random stages.


Please note that this is just a preview, nothing shown is in it's final state - it's far from being finished.
Changes may and will occur, there's much left to do.
Right now it's only able to load and render stages with "Nature"-Background blocks.

Kakkoii, thanks a lot for your posts and links, very helpful.
I have a question though: could you identify the exact codec that is needed to play those THP videos? I see no reason why MPlayer or the fan made THP player would be the only two players to read those files as long as you have the proper codec installed on your computer (THP player can't be made to fill the whole screen as far as I know).. I am a fan of Media Player Classic and I have a lot of codecs on my system (the almighty ffdshow included) and those THP videos still fail to open. I have a lot of the content of that XP Codec Pack you linked to earlier in the thread, so installing it would conflict with several codecs that I already have.
Could you try to play those THP files in Media Player Classic, if you have it, after the installation of that XP codec pack? I would really appreciate if someone could help me identify which exact codec I need to install to make it work on Media Player Classic.

dude, it looks awesome! Ican't wait to download it
keep up the good work!

My bad. >.>

You should see the animations, which are even more impressive.

Xane got a lot done since I was able to show him all fixed pieces and all sizes of those pieces, as well as figure out moving platform mechanics with him(yes there is an equation that determines where platforms start at the beginning of the match).

OOO NICE STAGE BUILDER, I can't wait!

(Stage building in wile in school = W000000T)

I wonder for the stage editor.. first of all.. looks cool. Well, I might have passed out some time (final tests at university for this semester) and as I am interested in technical things: is the 16 byte checksum now actually cracked? I did brute force MD5 attacks cutting together files and even just checked whether the correct digits were in the checksum (ignoring their order). But well, I didn't have much time to look closer - is it cracked by now (I checked the last pages but I didn't see it - if I missed - sorry )

And seeing stuff in GMod would be epic but I guess noone would be capable to do such a major LUA mod and SENTs and whatever to make a real Brawl in GMod - still it would be nice to see ^^

Nope. But I suspect that, since the six bytes out of the first 16 change in a way correlated with time, they're arbitrary and the checksum is actually the 4 bytes after that (0x10 - 0x13).

So I'm currently trying (by means of bruteforce) to see if it might be a crc32 of the entire file with some kind of "blanker" analogous to the md5 blanker for gamesaves applied. To be honest, though, I'm doubtful that I'll get a result.

About the stage builder.. Have you determined what will be possible to customize and what isn't? For instance, backgrounds, music, etc?

Just a note: The guy who helped me decrypt the .bin files acted like he had an additional 16 bytes before the stuff that bindecrypt and any other decryptors produce. I'm not sure if that was just the key, or the encoded key, or what, but I should probably try to check with him some time if I can.

Well, if you happen to be using unix, this is the entirety of what i'm using to decrypt:

<?php

$sd_key = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"; // secret value here
$sd_iv = "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"; // here too

echo mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $sd_key, file_get_contents('php://stdin'), 'cbc', $sd_iv);
?>

It produces 16 bytes at the beginning that bindecrypt does not. The same result is produced by this online decryptor.

Do you, or anyone, happen to know why? I don't know the details of AES like I should, to know why the bytes might be different.

Nor do I, but Wikipedia tells me that AES like any block cipher outputs the same amount of stuff that it inputs. Bindecrypt produces a file 16 bytes shorter than the input, so for whatever reason it is literally just skipping bytes.

EDIT: It's not a straight crc32, so I'm pretty much stuck.

Totally off topic but check out this video guys lol. Soooo amazing.

http://www.youtube.com/watch?v=xT7mH_4aNNY