SSBB Snapshot files. We need to crack em!

[Ondo]

Someone is working on the images, and has gotten past the encryption, but the image format isn't -quite- JPEG. Here are some sample files from the .bin files posted in this thread that they have decoded:

http://rapidshare.com/files/94947097/brawlscreens.zip.html

Every other image is fine. 2_-_Snake_with_dog.out, 4_-_8_Ice_Climbers.out, and Colorful.out call all be read simply by removing the first 76 bytes (at least GIMP can open them as JPEGs).

The others are messed up, all in the same manner. My guess is it's due to somehow being decrypted wrong. It being every other one may be a clue, I don't know.

 

[Kakkoii]

Every other image is fine. 2_-_Snake_with_dog.out, 4_-_8_Ice_Climbers.out, and Colorful.out call all be read simply by removing the first 76 bytes (at least GIMP can open them as JPEGs).

The others are messed up, all in the same manner. My guess is it's due to somehow being decrypted wrong. It being every other one may be a clue, I don't know.

Yeah. You can convert them easily with the free RAD video tools.

I'm playing around with the other 3 images. The RAD tools converts them when i've removed the first chunk of bytes. But I end up with a black image.

Which means in the first chunk that's being delete from those 3 by us in the hex editor, has a major part of the coding needed to turn it into an image.

So hopefully playing around with it a bit i'll find what not to delete and get it working. Assuming this is the problem. Hopefully.

2_-_Snake_with_dog

4_-_8_Ice_Climbers

Colorful

 

[holizz]

Every other image is fine. 2_-_Snake_with_dog.out, 4_-_8_Ice_Climbers.out, and Colorful.out call all be read simply by removing the first 76 bytes (at least GIMP can open them as JPEGs).

Since I know nothing about JPEG, I took a look at the non-JPEG data.

Of the ones that work, those 76 bytes follow the same pattern: 4 bytes which differ per file, and then 72 bytes which are the same in all three of the files.

Possibly a checksum, maybe the creation time but that's stored in the filename usually (I'll have to test if changing the filename changes the creation time). Now I forget whether or not it's possible to add names and comments to photos. So that could explain those bytes which are identical.

 

[Kakkoii]

Since I know nothing about JPEG, I took a look at the non-JPEG data.

Of the ones that work, those 76 bytes follow the same pattern: 4 bytes which differ per file, and then 72 bytes which are the same in all three of the files.

Possibly a checksum, maybe the creation time but that's stored in the filename usually (I'll have to test if changing the filename changes the creation time). Now I forget whether or not it's possible to add names and comments to photos. So that could explain those bytes which are identical.

No there all jpeg images. I know that for a fact.

JPEG images start with either ÿØÿá or ÿØÿÛ when you look at them in a hex editor or notepad.
And jpeg's also contain the numbers 456789 fallowed by a bunch of letters in the alphabet near the start of the coding also.

These two characteristics aren't found in other file formats..


And if you look at each of those brawl images. They all have a starting point of either of ÿØÿá or ÿØÿÛ.. (Assuming youve removed the right amount of random bytes from the start.)

3:40am, i'm off to bed, ill continue on it in the morning.

 

[Ondo]

Yeah. You can convert them easily with the free RAD video tools.

I'm playing around with the other 3 images. The RAD tools converts them when i've removed the first chunk of bytes. But I end up with a black image.

Which means in the first chunk that's being delete from those 3 by us in the hex editor, has a major part of the coding needed to turn it into an image.

I don't think it's the first chunk that's the problem. I'm pretty confident those three weren't quite decrypted right.

The good ones all have 76 bytes, then well-formed JPEG info, starting with FF D8, then differnt sections marked as FF ?? and then two bytes for that sections length, as JPEGs are supposed to. The ones that don't work have FF 00 D8 31 bytes in, followed by stuff that looks like different sections but consistently contain more bytes than their length says they should have.

It looks like the decryption got the right number of bytes, and the right values for bytes, but put around 10% or so of them in the wrong spot in the file.

 

[holizz]

No there all jpeg images. I know that for a fact.

I meant I was looking at the data in the file that came _before_ the JPEG data. i.e. the first 76 bytes = not-JPEG, the rest = JPEG.

Edit: P.S.

Made by renaming a snapshot to: al_201337_aabb.bin

Note that inserting one too many digits (i.e. al_201337_13337.bin) causes it to take a long time to load the snapshot mode, and then clams there isn't an SD card.

When copying any snapshots, the time is reset to the current time and date, so it seems we cannot put our special snapshots onto the Wii's internal memory.

Edit:

0x61 (a) - 0x30 (0) = 0d49

49 + 490 = 539

 

[Heinermann]

So how does one go about decryption?

 

[Mic_128]

Keep up the awesome work guys!

 

[CengizMan]

[gone][gone][gone]

 

[Xane]

(...)
The others are messed up, all in the same manner. My guess is it's due to somehow being decrypted wrong. It being every other one may be a clue, I don't know.

Yea.. I tried to delete some of the 0x00 and 0x01 chunks, which followed a 9-offset pattern, and somehow recreate the image.. with no success. :x
( http://xane.gamez-interactive.de/Pub/Downloads/TEST.out )
The offset changes all in a while, which made it more complicated~

I'm really interested in the source of decrypting the images, or at least knowing the process.
I'd like to have some more screenshots to play with and look for certain patterns, besides removing the first bytes.

 

[VerTex]

i was trying to look at a video file on my computer yesterday until i noticed it was .bin
good job on the cracking and keep it up :]

 

[GTCoder]

No there all jpeg images. I know that for a fact.

JPEG images start with either ÿØÿá or ÿØÿÛ when you look at them in a hex editor or notepad.
And jpeg's also contain the numbers 456789 fallowed by a bunch of letters in the alphabet near the start of the coding also.

These two characteristics aren't found in other file formats..


And if you look at each of those brawl images. They all have a starting point of either of ÿØÿá or ÿØÿÛ.. (Assuming youve removed the right amount of random bytes from the start.

Yes, the 456789 is part of the quantization table, I think. One possible thing I found is that maybe the Wii process is "optimizing" out certain bytes. I also noticed the weird 00's getting insert at places (like ff00d8 instead of ffd8), sometimes. But if you search through the files (yay HxD) for FFC0, which is like an information section, only a couple of the images have it. ...BUT, the other images still have a basically identical section, starting with just C0. You can tell it's the same because it has the 640x480 width in it (hex 280 by 1E0). So I'm wondering if there's a way to insert tags and figure out which data got added.

Edit:

0x61 (a) - 0x30 (0) = 0d49

49 + 490 = 539

Holizz, what were the numbers relating to? I didn't follow that part. =P

And what exactly did you do...make an image solely on the computer, and copy it to a Wii? Or copy someone else's bin onto the Wii?

I don't think it's the first chunk that's the problem. I'm pretty confident those three weren't quite decrypted right.

The encryption is basic, simple AES using a key. Unless there's another way to do AES, or more information is required, I imagine they're decrypted correctly, since AES and such are designed such that even a small key/decryption problem results in a totally different file. (anyone who knows AES better, feel free to correct me on that). And I kind of feel like the others were decrypted correctly since they have so much similar data...unless it's really a fluke. I highly doubt Nintendo would do a custom decryption algorithm if other people have been able to use normal AES on other parts.

I'd like to have some more screenshots to play with and look for certain patterns, besides removing the first bytes.

I agree...it might be helpful to have some more pictures. The ones with smaller filesizes seem especially strange. Thanks for the work, guys!

 

[holizz]

Holizz, what were the numbers relating to? I didn't follow that part. =P

And what exactly did you do...make an image solely on the computer, and copy it to a Wii? Or copy someone else's bin onto the Wii?

I got a snapshot on Brawl, and changed the file name. Simple as that.

The numbers relate to the image and the filename. With the image being named "al_201337_aabb.bin", the date/time is 2008/13/37 539:550.

The hour section is made up of two "a"s.

Notice that in ASCII, the byte that represents "a" is equal to the byte that represents "0" (zero) plus 49. i.e. "a" = 97 and "0" = 48.

So since "a" is equal to "0" + 49, the "number" "a" is equal to the value 49.

In the decimal system, with a two-digit number, the first digit is multiplied by ten, and added to the second digit. Thus, 49*10 + 49 = 539.

This is the method by which the date/time is extracted from the filename.

Unfortunately, I don't think it will be of any particular use, but it's an amusing diversion.

 

[LoginError]

Great job guys, keep up the good work, when I get brawl I would be interested in helping crack the stagebuilder files. I like the Idea of a flash/Java stagebuilder that can output the files. And if we figure out the file format, I'm curious as to how Brawl will react to a file that specifies "illegal" stages. eg .a stagebuilder file with two blocks in the same spot...Depending on how Brawl reacts this could result in even more creative stages :D

 

[T-major]

I noticed that the pictures you've managed to crack look rather rough around the edges. would there be a possible way around that once you find out more about how this works?

 

[smasher32]

I'm curious to know how far this will go so...

tag </gamefaqs>

 

[GTCoder]

I noticed that the pictures you've managed to crack look rather rough around the edges. would there be a possible way around that once you find out more about how this works?

I wish it was something other than lossy compression. For anyone who has Brawl, do the screenshots look better when you view them there? And if so, are you sure it's not just the screen?

 

[T-major]

I wish it was something other than lossy compression.

if I had to guess, it almost looks like the image is getting squished together to make it fit... like trying to fit a 5-by-5 inch photo into a 4.8-by-4.8 inch frame... but what do I know...

 

[Kakkoii]

if I had to guess, it almost looks like the image is getting squished together to make it fit... like trying to fit a 5-by-5 inch photo into a 4.8-by-4.8 inch frame... but what do I know...

Or perhaps Brawl runs on 2x or 4x AA. (Anti-Aliasing)

So on the TV it looks smoother. But when it pauses to take a snapshot.. Perhaps for some reason the AA isn't used on the screenshot?

 

[GTCoder]

Or perhaps Brawl runs on 2x or 4x AA. (Anti-Aliasing)

So on the TV it looks smoother. But when it pauses to take a snapshot.. Perhaps for some reason the AA isn't used on the screenshot?

After digging through the internet, I found to my disgust that Gimp 2.0 apparently doesn't HAVE an antialiasing filter, and I can't find one. So, I just resized the image up and down slightly (looks about the same as doing a blur). Is this better?

 

[Wiwiweb]

HOLY CRAP ! That's my "Snake's dog" photo ! You did it !
I did not really follow the thread these days. I'm gonna read all of this.


Edit :
So, what I understand is, only three images have been correctly decrypted, while the others are messed up ? Strange. Oh, and I don't get how you decrypted the images without the key.
By the way, it seems my "Ice Climbers" photo was not the correct one. I made a mistake while renaming


Oh, and if you want to check out stage decryption after that, feel free to give me experiments to do.

 

[T-major]

After digging through the internet, I found to my disgust that Gimp 2.0 apparently doesn't HAVE an antialiasing filter, and I can't find one. So, I just resized the image up and down slightly (looks about the same as doing a blur). Is this better?

the edges look a LOT smoother now! but the blur could be a problem... I'm sure sharpening it would fix it. let me try.

:EDIT:

ok, I sharpened the picture, and it the edges still look a lot smoother than the original.

so... what does that tell us?

 

[Ageman20XX]

Guys, I think it's worth noting that 99.9% of the nice, clear images we see on the DOJO are about half the size that you're showing there. Try using a program that actually knows how to resize appropriately (Paint.NET, Irfanview (recommended), or Photoshop) and you'll see they're of similar quality to the DOJO.

Blurring/Sharpening and all that junk just makes the images look messy and poor quality. Also, and more importantly - every single time you save the image as a JPEG, or RE-save it, you loose more and more quality. Keep them as PNGs...I promise they will always look tons better.

Here's a little resize I did with Irfanview - not as perfect as the DOJO but I blame that on the actual screenshot rather than the resize.

-Age

 

[djgwiz]

So we have extracted image files from the bins but were just trying to make them look better, yes?

 

[GTCoder]

Keep them as PNGs...I promise they will always look tons better.

Here's a little resize I did with Irfanview - not as perfect as the DOJO but I blame that on the actual screenshot rather than the resize.

For what it's worth, I'm pretty sure this is data directly from the game, and that they're stored as JPG (or very similar) data. Perhaps the Dojo used a high-quality TV/capture card instead of a translated screenshot?

 

[Ondo]

The encryption is basic, simple AES using a key. Unless there's another way to do AES, or more information is required, I imagine they're decrypted correctly, since AES and such are designed such that even a small key/decryption problem results in a totally different file.

I'm not real familiar with AES, but just in this thread I've seen people discussing different modes for it. It is, obviously, the right key.

Knowing little about it, here's my best guess: Every file is an even multiple of 16 bytes, but not 32 bytes. My guess is that to work correctly it needs to consider the first 16 bytes to be the second half of a 32-byte pair, so (assuming it was fed the 7 files together) the first, third, fifth, and seventh files didn't work but the second, fourth, and sixth did.

Hopefully whoever did the decryption can check?

 

[T-major]

For what it's worth, I'm pretty sure this is data directly from the game, and that they're stored as JPG (or very similar) data. Perhaps the Dojo used a high-quality TV/capture card instead of a translated screenshot?

I think thats the case...

although, they small pictures DO look better. even so, it would be better to find a way to make them clearer right off the bat (if it's possible), because I'm sure people will want larger pictures.

 

[Surgo]

Every file is a multiple of 16 bytes because AES has a block size of 128 bits (16 bytes). If a file is ever short of a 16 byte multiple, it needs to be padded until it's a multiple of 16 bytes. Otherwise, AES cannot operate.

I've never heard of anyone padding on the front before (usually you pad the last block), but it's possible I guess. Maybe that's your non-jpeg data.

If it's AES, it's AES with no variation. AES is the name of a government standard (the cipher itself is called Rijndael). If you deviate from that standard even slightly, you aren't using AES.

 

[djgwiz]

How far away do you guys think we are from a converter?

 

[GTCoder]

Could someone please provide us with 2-4 more .bin images? Maybe a couple with normal/lots of colors, and a couple with few colors? As was probably sort-of pointed out, the images so far fall into two categories:

1. A correct JPG starts at 0x4C (76) bytes in. Byte 0x10 (16) of these files is 0.
2. Weird JPGish data starts at 0x1F (31) bytes in. Byte 0x10 (16) of these files is 11. 11, incidentally, is the offset to the odd 0x00 that appears in the middle of the normal 0xFFD8 start-of-image marker, in these files. I don't know if this is cooincidence or not.

I'd hope we're not far away from figuring it out. I feel close, but it's annoying...

 

[djgwiz]

Could someone please provide us with 2-4 more .bin images? Maybe a couple with normal/lots of colors, and a couple with few colors? As was probably sort-of pointed out, the images so far fall into two categories:

1. A correct JPG starts at 0x4C (76) bytes in. Byte 0x10 (16) of these files is 0.
2. Weird JPGish data starts at 0x1F (31) bytes in. Byte 0x10 (16) of these files is 11. 11, incidentally, is the offset to the odd 0x00 that appears in the middle of the normal 0xFFD8 start-of-image marker, in these files. I don't know if this is cooincidence or not.

I'd hope we're not far away from figuring it out. I feel close, but it's annoying...

http://www.megaupload.com/?d=SCDN3GZC
Holizz was kind enough to supply me with this screenshot. It should be Pikachu in the Melee DK stage. I hope it helps.

edit: gave credit to the wrong person, sorry.

 

[Kakkoii]

I've made a little progress with the messed up images.

This is the mewtwo image.

Basically for this image. I copied over the first roughly 1200bytes of the snake image. Onto the mewtwo image.

This gave the image all the right coding to be viewed as an image. And as you can see in the image, you can sort of see the snake image starting to show at the top.

So it continues on loading the rest of the image after the snake coding is done.


Which is why my conclusion is, that the files are most likely corrupted.

 

[GTCoder]

I've gotten some more info. Update later tonight, hopefully!

 

[Heinermann]

Can someone please post some decrypted stages or explain how to go about decrypting the bin files?

 

[Firestorm88]

For quality, it's because the shape of pixels on your TV and the shape of pixels on your monitor are different iiirc. The screenshots look both badly compressed and are in a "weird" resolution that makes it look stretched. I honestly hope it's for a reason other than Nintendo using really, really crappy compression and that it can be fixed. You should be ADDING detail when saving screenshots, like Halo with it's additional antialiasing =/

Heinermann, stages work completely differently. And can't you just upload stages for others to download easily? There's no point in having stages on a PC....

 

[Ondo]

Heinermann, stages work completely differently. And can't you just upload stages for others to download easily? There's no point in having stages on a PC....

There are a couple advantages we would get from knowing the stage format. It would be possible to automatically generate screenshots for a stage database, for example. Most interesting would be to see if you could create stages on the PC that would play in Brawl that can't be designed in the Stage Builder.

 

[Indignant]

Just out of curiosity, what if we changed the data on the computer? How does it change the display on the Wii? This most likely won't help...but it's an idea.

Oh, I e-mailed Nintendo about an "official" decrypted, and they said, in one sentence, "There is nothing like that planned at this time." Shortest e-mail from them I've ever gotten.

 

[Heinermann]

Heinermann, stages work completely differently. And can't you just upload stages for others to download easily? There's no point in having stages on a PC....

It's possible to write an advanced stage builder for the PC, as well as generate full snapshots. Additionally there are many functions in the stage builder that aren't available, There are several things I want to check out, such as the possibility of:
- Unused blocks (including invalid[overflow] blocks)
- Background overflow
- Changing stage size (possibly have even larger stages than the largest setting there is now, or rectangular sizes)
- Even more music selections
- Placing blocks outside of the fixed range given in stage builder

I just want to extend the creativity that people can have with stage building, as well as bring possible exploits to the surface.

 

[GTCoder]

Can anyone upload a stage .bin? If I missed it, I'm sorry. I'll see if it can be decrypted.

Update: I think I'm super close to the image decryption. It's like, some crazy form of LZSS. I sorta...found segher surprisingly helpful, and he's been explaining the algorithm to me in pieces. Which is funny since he apparently already did it himself before losing interest. XD

Basically, some images are AES encrypted JPEGs. But others (with a flag to indicate whether or not) are ALSO compressed using a LZSS or similar algorithm, which is, I guess, why the black and white images are so ridiculously small.

 

[GTCoder]

*oops, multipost, can someone delete this?*