Recent content by comex

you could probably get rid of the smash service stages by clearing vault data. Of course, that will also get rid of snapshots and replays.

Here are two Python scripts to convert from a decrypted stage .bin to a more human-readable format + a jpg, and back... (but you will need to do the decrypting, encrypting, and de-lzssing yourself). They don't do names correctly. Music works if you have musicSFX_ID.txt in the current...

So guys... guess what I found (with the help of crediar and a lot of other people) To calculate the checksum of a decrypted replay/snapshot/stage, take the number at 0x1c (big-endian). Add 0x20 to that and take that much of the file from the beginning (should be most of the file, except for...

Here is a link explaining everything. EDIT: Word filter :O

OK, my Wii is now officially unable to read the SSBB disc, and packed off to Nintendo for that purpose. In the meantime... if someone could possibly make a zip with (a) a few identical stages, and (b) some stages that are identical, but with one character in the title changed (c) one other...

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.

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...

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...

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.

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...