SSBB Snapshot files. We need to crack em!

[Firestorm88]

I'd rather not get this thread too overloaded with images. I like reading the development of the product. One of the reasons I haven't really posted thanks or anything is I like how structured this topic is and don't want it to turn into pages of "I LOVE YOU GUYS" and then into basically a postcount++ topic where I can't see the work too easily

But seriously, awesome work. Am I right in thinking that some people are going to try and see what's up with the compression and see if we can get better IQ?

 

[GTCoder]

I'd rather not get this thread too overloaded with images. I like reading the development of the product. One of the reasons I haven't really posted thanks or anything is I like how structured this topic is and don't want it to turn into pages of "I LOVE YOU GUYS" and then into basically a postcount++ topic where I can't see the work too easily

But seriously, awesome work. Am I right in thinking that some people are going to try and see what's up with the compression and see if we can get better IQ?

I agree about the images. Some images are nice, but maybe another thread could be created for them. (that was inevitable anyway) And I appreciate people saying thanks (apparently this is already being linked at random places on the internet), but no need to say it too much.

About image quality, you basically get one of two things.
1. Encrypted data, containing an uncompressed, normal JPG.
2. Encrypted data, containing a JPG compressed with a non-lossy LZSS algorithm.

Unfortunately, any image quality loss is the result of the game, I'm almost certain. The JPG's are explicitly 640x480, so if they look better on the Wii (no one has really verified this yet, though I assume it's the case), it's probably because of the Wii stretching them/anti-aliasing them/whatever as appropriate. So compression-wise, I doubt we can improve. Filterwise, we may be able to find something that makes the images look less jaggy.

 

[dmauro]

Could you please post the two non-working .bin files? It might be helpful. Thanks!

http://www.dmauro.com/pub/stickers_failed.bin
http://www.dmauro.com/pub/screen_failed.bin

 

[Ondo]

Here's my best guess as to the issue.

When there's encoded data where the first nibble is 0, so we have 3 bytes total, the second nibble is currently being interpreted as the first 4 bits of the number of bytes to copy. I think the first two bits of that nibble are something special we're not handling properly, and only the last two bits are part of the number of bytes to copy.

 

[RupeeClock]

The tool works VERY well most of the time, but there are a few exceptions, understandably so.

This screenshot is supposed to be of a sticker of Sonic, Tails and some Chao, I have a camera photo of how it should look.

However, this sticker picture with Tingle and Co came out just fine...

Just Snorlax's face close up.
For some reason, it has only corrupted at the bottom of the image.

Here's the real issue, the Electroplankton stage.

Like the Game and Watch 2 stage, characters are rendered completely flat, and the tool doesn't seem to agree with this.

Although this screenshot taken on the G&W stage is just fine.

And finally, there's this one.

...Don't be fooled, that actually came out perfect except for the little bit in the corner.
That's a completely grey screenshot that happened at the exact moment Lyn launched her attack, and someone dropped their smash ball.

I hope you find this useful, this is an otherwise SUPERB tool. :D

 

[Senor Crouch]

When you guys do finally get the converter from the format of the Brawl snapshots to JPEG could put the link in the OP? Oh, and good job guys. I would love to help, but I am a total noob when it comes to stuff like this. I have no idea what you guys are saying.

 

[celebi23]

If you want a Linux version of the decryptor, I may be able to provide that.

That would be awesome. That way I could compile it with xCode & make it run on Mac OS X THANK YOU GTCODER!!!

 

[Indignant]

I hope this is you! It appears you have some 'net fame!

http://www.nintendowiifanboy.com/2008/02/28/brawl-screenshot-decrypter-use-it-for-good/

 

[TheBigBadCow]

I hope you don't mind, GT, but I posted your work (giving you credit, of course) over at IGN's smash board.

http://boards.ign.com/super_smash_bros_/b5213/159789063

 

[GTCoder]

The tool works VERY well most of the time, but there are a few exceptions, understandably so.

...

I hope you find this useful, this is an otherwise SUPERB tool. :D

Thanks, though I can't really figure out what happened just by the output, without the input .bin files. I'm sorry you found so many corrupted screens! Basically, things with few colors seem to often have problems, and I still need to figure out why.

Ondo, that's probably the best suggestion I've heard yet. I was reading something somewhere about LZSS, and that might just be related...I'll take a look!

 

[Firestorm88]

I must say the reporting on this is horrible. When I wrote for QJ I always followed the links until I found the original source =/ For some reason gbatemp is receiving the credit whenit should be GTCoder and the others in this thread who I think started off the research. Or did you do it all individually?

 

[RedMage8BT]

How do you use it?

 

[TheBigBadCow]

How do you use it?

Here's what you do. Take some pictures, put them on an SD card and get them on your computer. Download the .zip file here and extract everything to a single directory. Put the screenshots in the same directory and run bin2jpgall.bat. It will convert them.

 

[GTCoder]

I must say the reporting on this is horrible. When I wrote for QJ I always followed the links until I found the original source =/ For some reason gbatemp is receiving the credit whenit should be GTCoder and the others in this thread who I think started off the research. Or did you do it all individually?

Eh, that's life when you release something openly. I wanted it to spread anyway, and I don't care too much. It'd be nice if someone gives credit, but hey. If I claimed I was super smart and hacked everything to make this, then maybe Nintendo would decide to pay me a visit. ;p

Honestly, I was lucky enough to profit from others' (segher, someone else) work so I didn't have to do any Wii reverse engineering to get data. And segher, and others on his team, are outside the USA anyway.

If someone is claiming to have programmed the thing, that would be kind of annoying, but really, it's just a decoder (based on BSD license AES code I found online), and a decompressor based on experimentation and segher's info. I'll try to have a better version in a day or two, or maybe early next week if school doesn't suddenly eat me.

On that note, I need to add this to my distribution, I suppose. License thingy for the AES code:

"
---------------------------------------------------------------------------
Copyright (c) 1998-2007, Brian Gladman, Worcester, UK. All rights reserved.

LICENSE TERMS

The free distribution and use of this software is allowed (with or without
changes) provided that:

1. source code distributions include the above copyright notice, this
list of conditions and the following disclaimer;

2. binary distributions include the above copyright notice, this list
of conditions and the following disclaimer in their documentation;

3. the name of the copyright holder is not used to endorse products
built using this software without specific written permission.

DISCLAIMER

This software is provided 'as is' with no explicit or implied warranties
in respect of its properties, including, but not limited to, correctness
and/or fitness for purpose.
---------------------------------------------------------------------------
Issue Date: 20/12/2007"

That's for the AES decoding code I used.

 

[RedMage8BT]

Here's what you do. Take some pictures, put them on an SD card and get them on your computer. Download the .zip file here and extract everything to a single directory. Put the screenshots in the same directory and run bin2jpgall.bat. It will convert them.

K, I'll test it when I get Brawl. I have to basically put all files in the same folder with the screenshot files after I extract it right?

 

[Heinermann]

We already have that: http://holizz.googlepages.com/st.zip

Are you sure that's EXACTLY what it is? Which stages contain what, specifically? It's important to know these things to understand the format successfully.

Goal: Before North American release.

Also, I'm not sure if stages are being decrypted properly? I mean, 0xFF separators in a string? Also a non-ASCII charset...

 

[Ondo]

Ondo, that's probably the best suggestion I've heard yet. I was reading something somewhere about LZSS, and that might just be related...I'll take a look!

I think I've got it, I'm just working on coding it to check.

For the length, it checks if the first nibble is 0 - if it's not, that nibble is the length, if it is, the next 2 nibbles are the length.

Then it does the *same thing* for the backwards offset - if the next nibble was 0 (which it is, most of the time) it reads the next byte to get the backwards offset, but if its not 0 then it is the backwards offset, rather than the first of 3 nibbles comprising the backwards offset.

Code soon, if I can get it to work.

EDIT: My brain is fried, because this is not even close to right.

 

[lfox12]

Thanks so much for this program :D I have been taking screenshots with my TV capture card.. this is so much better. no errors on over 50 screenshots of Zamus
Here is a comparison

 

[GTCoder]

Thanks so much for this program :D I have been taking screenshots with my TV capture card.. this is so much better. no errors on over 50 screenshots of Zamus
Here is a comparison

Thanks. As far as I can tell, it's just anti-aliasing/blurring.

 

[DMurr]

wow! this, more than anything at the moment, makes me want the game right now.

 

[paOol]

heres another example of the difference.

 

[SycoFreak]

I hate to break up the incredible magic that is this thread with another "thank you" kiss-up, but GTCoder, this is amazing work you do. Thanks 100 for taking the time out to work on this-- you really deserve credit for this (of course with segher). Definitely appreciated with the utmost and highest regard to your abilities. Thanks again, ^^.

 

[perro]

Not to be rude, but the source for decryption will not be forthcoming. Someone was very kind to provide necessary information, and that information is not going to be spread by me.

If you want a Linux version of the decryptor, I may be able to provide that.

As for the image decompression, I'd be glad to let someone else look at it since maybe they can figure out the issue with certain images not working. My code is sloppy, of course, so put on your style goggles.

Anyway, maybe I'll get time to post the image decompression code tomorrow, along with what I've found out/been told about the compression. I hope it will be helpful.

I'm sorry but you must distribute the source code to the programs, by linking to Cygwin your program is bound to the GPL. If you don't release the source code you are violating the GPL license.

So you've got two choices, stop distributing the program or give us the source.

 

[Ichida]

My only issue is that even the decrypted pics look kinda low-qual. No .png?

 

[Yoshara]

I really hope that this will still work with the NTSC version of Brawl.

 

[Surgo]

I'm sorry but you must distribute the source code to the programs, by linking to Cygwin your program is bound to the GPL. If you don't release the source code you are violating the GPL license.

So you've got two choices, stop distributing the program or give us the source.

You're a true idiot. You'd try to force him via license to stop distributing the program (he already said why he wouldn't release the source), so no one could decrypt their Brawl screenshots? Good to see you really thought that one through!

 

[holizz]

Are you sure that's EXACTLY what it is? Which stages contain what, specifically? It's important to know these things to understand the format successfully.

Good point. I'll make a well-documented set of files one day, maybe when I can run bindecrypt to decipher the .bin files myself.

You're a true idiot. You'd try to force him via license to stop distributing the program (he already said why he wouldn't release the source), so no one could decrypt their Brawl screenshots? Good to see you really thought that one through!

It's true though. GTCoder must either release the source code, or cease distribution until it no longer links with Cygwin. I didn't realise that Cygwin was GPL (I thought it might have been LGPL), nor did I realise before that linking to GPLed code required GPLing one's own code.

According to http://cygwin.com/licensing.html:

This means that unless you modify the tools so that compiled executables do not make use of the Cygwin™ library, your compiled programs will also have to be free software distributed under the GPL with source code available to all.

 

[GTCoder]

Thanks for pointing the Cygwin issues out. Program license: Copy it if you want. Edit the source if you want. Don't sell it. Don't claim you made it.

Merry Christmas, have a non-GPL, non-Cygwin (and much smaller) version. Also, the source code for the out2jpg program was provided a few pages back.

http://rapidshare.com/files/95829441/bin2jpg.zip.html

 

[h1roshi]

so have we gotten anywhere with this yet? and how about cracking them video files?...peace

-hiro

 

[holizz]

Edit the source if you want.

But you haven't released the source. Unless this only applies to out2jpg...?

 

[GTCoder]

But you haven't released the source. Unless this only applies to out2jpg...?

That's what you can do with the source you have, out2jpg. The license to the other code is "use it if you want".

 

[Ondo]

I've figured out where the problem is.

Every bad file has something to decode where the first nibble is 1 before any errors. We're not handling those right. (The current method would have those be a length of 2, which saves you one bit, so probably not worth encoding.)

After some experimentation, it looks like the ones where the first nibble is 1 are a total of 4 bytes long; simply skipping the 0x10 byte lets me get an obviously corrupted but viewable version of stickers_failed.

 

[2nd Stamp]

I've figured out where the problem is.

Every bad file has something to decode where the first nibble is 1 before any errors. We're not handling those right. (The current method would have those be a length of 2, which saves you one bit, so probably not worth encoding.)

After some experimentation, it looks like the ones where the first nibble is 1 are a total of 4 bytes long; simply skipping the 0x10 byte lets me get an obviously corrupted but viewable version of stickers_failed.

But in all seriousness, there couldn't really be a way to make these "Images" JPG or anything, since they arn't image file. Maybe they are something different in a way that they're still 3D, but given the 2D stale image like they do in some stages? (Electroplankton). It could be Nintendo's way of handling "snapshots" and imagery.

 

[GTCoder]

I've figured out where the problem is.

Every bad file has something to decode where the first nibble is 1 before any errors. We're not handling those right. (The current method would have those be a length of 2, which saves you one bit, so probably not worth encoding.)

After some experimentation, it looks like the ones where the first nibble is 1 are a total of 4 bytes long; simply skipping the 0x10 byte lets me get an obviously corrupted but viewable version of stickers_failed.

Thanks for the work. I still haven't figured anything out...I tried looking at individual bits, I did notice that for the 3-byte decoded portions, you can only use the third byte as the backwards reference length, and ignore the second half of the second byte...I could still decode 24 image files with no errors. That could just be because nothing uses a backwards reference that long, though.

As for your approach, it's definitely worth looking into. The two problems encountered are yours (image corruption), and the fact that some successfully decoded images have plenty decoded first nibbles that are 1. I suspect that if I changed the number of bytes grabbed then something strange would happen.

If you have the white.bin/white.out file posted very early on in this thread, you can look at hex offset 0xD84 in the decoded white.jpg. To me, that's where it looks like weird data starts that doesn't match the overall pattern. segher suggested that there might be some pattern that triggers four bytes being used, like you said, but I don't know if that's right or not. There could also be a one-byte sequence somewhere, I guess, but I feel that's less likely.

 

[GTCoder]

But in all seriousness, there couldn't really be a way to make these "Images" JPG or anything, since they arn't image file. Maybe they are something different in a way that they're still 3D, but given the 2D stale image like they do in some stages? (Electroplankton). It could be Nintendo's way of handling "snapshots" and imagery.

Actually, they are image files. Basically, Nintendo just wrote a normal JPG image into a weird format, and stuck it in memory/an SD card.

 

[Ondo]

Got it!

If the first nibble is 1, then the next 4 nibbles are length, then 3 position.

It now works on stickers_failed and screen_failed, as well as black and white (though black gives a light gray screen and white a black one...)

It also nows gives extra long padding after the ones that work.

Replace these lines:

                // if the first nibble is 0, get a third byte
                if((tempbuffer[0] & 0xF0) == 0) {

with this:

                if((tempbuffer[0] & 0xF0) == 0x10) {
                    tempbuffer[2] = fgetc(fp_i);
                    tempbuffer[3] = fgetc(fp_i);
                    num_bytes_to_copy = (((unsigned int) (tempbuffer[0] & 0x0F)) * 0x1000) + (((unsigned int) tempbuffer[1]) * 0x10) + (tempbuffer[2] >> 4) + 0x111;
                    backwards_offset = (((unsigned int) (tempbuffer[2] & 0x0F)) * 0x100) + tempbuffer[3] + 1;
                }
                // if the first nibble is 0, get a third byte
                else if((tempbuffer[0] & 0xF0) == 0) {

Also, black and white gave buffer errors - I just increased the inital size by a factor of 10.

 

[miller483]

Well, It seems someone figured it out. (maybe?) :

"An amazing new tool has been created for use with Super Smash Brothers Brawl on Windows PCs, it allows you to decrypt files from your SD card.

It's called the SSBB Screenshot decrypter.
Thanks to recent exploits found in the wii, it's been found that the .bin files are actually encrypted jpeg files!
Using this tool, you can take your snapshots and make pictures, isn't that wonderful?

http://www.4colorrebellion.com/arch...t-mercy-me-i-do-believe-im-gettin-the-vapors/
http://rs217.rapidshare.com/files/95587164/bin2jpg.zip

The program is dead easy to use, put the .bin files in the same folder as the program files, and simply run the "bin2jpgall.bat"

I've taken a number of screenshots already! It's fantastic!

http://img141.imageshack.us/img141/8193/al08022900292binoutgb1.jpg
http://img141.imageshack.us/img141/6901/al0802290026binoutae3.jpg
http://img141.imageshack.us/img141/7016/al08022900351binoutph7.jpg
http://img141.imageshack.us/img141/1984/al0802290023binoutbj4.jpg
http://img141.imageshack.us/img141/9930/al08022900201binoutgu7.jpg
http://img505.imageshack.us/img505/6010/al08022301457binoutvi2.jpg
http://img505.imageshack.us/img505/2056/al08022301453binoutlm2.jpg
http://img505.imageshack.us/img505/3277/al08021615361binoutla2.jpg
http://img442.imageshack.us/img442/188/al0802161530binoutib0.jpg "


-Credit goes to mtpfreak from GameFAQS

 

[GTCoder]

Got it!

You, sir, are BRILLIANT. I can't thank you enough! That makes a ton of sense, especially with the 0x111 thing you added. I'll edit this after I try it myself.

I guess the question now is whether the original black and white images were given backwards (that guy mixed up two of his other screenshots). Can someone try to make a nearly-solid black image (final destination background) and nearly solid white (sticker platform, or elsewhere)?

Did you ever have errors with trying to reach just before the data? segher said he had a slightly different decryption that gave 16 extra bytes at the start of the .out file, but I don't think they really mattered since we're starting decompression later anyway.

About the buffer size, that makes sense since they're giant blocks of copy data. The 0 padding also makes a ton of sense if it works out right...segher thought something like that was the case, and I'll try to check that.

*edit*
Looks like it works perfectly on the "black" image, though it's light-colored like you said. Odd. Before it was a partly dark gray image. But, it's a perfectly-formed JPG now so I'm not complaining.

Trying to work on buffer stuff now. Man, I was going to bed, and you had to figure it out.

 

[roguebanshee]

Well, It seems someone figured it out. (maybe?)

You haven't been following this thread at all, have you?

The tool you linked originated here.

 

[2L84U]

You, sir, are BRILLIANT. I can't thank you enough! That makes a ton of sense, especially with the 0x111 thing you added. I'll edit this after I try it myself.

I guess the question now is whether the original black and white images were given backwards (that guy mixed up two of his other screenshots). Can someone try to make a nearly-solid black image (final destination background) and nearly solid white (sticker platform, or elsewhere)?

Thanks for all the effort you and fellow boarders put in !!
I can only help by posting screenshots
here they are:
(Hope I didn't get them mixed up)

Complete black (from 75m)
http://rapidshare.com/files/95865064/Black.bin.html
Sticker
http://rapidshare.com/files/95864756/Sticker.bin.html
it came out like this

Promptly waiting for your decoder ver. 2.0

You haven't been following this thread at all, have you?

The tool you linked originated here.

Can't agree more.