Super Stack Smash Bros

[Igglyboo]

http://www.youtube.com/watch?v=4YAXKjWBA9k

blah blah COMEX blah blah EXPLOIT blah blah STACK SMASH blah blah SSBB blah blah VERY HARD TO PATCH blah blah RELEASE SOON blah blah irc.efnet.net #usbgecko
"Many thanks to
- svpe for discovering the bug, and
- segher for the savezelda code.
I'm just the guy in between. "--comex

[Link]

That exploit is so awesome!

While it kinda is less good than banner bomb on one side: because it only works on users with SSBB, I see this absolutely difficult to fight for Nintendo!

A way would be: Brawl uses IOS36.. IOS36 is real time surveilling Brawl.. they could release an IOS36 upgrade which overviews Brawl and could stop the stack smash. Indeed even Gecko Cheat codes could probably make this exploit unusable.

However, this would add a new level of competition even for Nintendo.. it's more likely they destroy all entry methods of installing homebrew on the Wii. We could then still run homebrew directly using the exploit.

[brkirch]

This exploit does indeed look promising, hopefully it will be more stable than Bannerbomb too since the loader is based off the Twilight Hack loader code.

While it kinda is less good than banner bomb on one side: because it only works on users with SSBB, I see this absolutely difficult to fight for Nintendo!

A way would be: Brawl uses IOS36.. IOS36 is real time surveilling Brawl.. they could release an IOS36 upgrade which overviews Brawl and could stop the stack smash. Indeed even Gecko Cheat codes could probably make this exploit unusable.

I find it unlikely that modifying IOS 36 would be the best solution for them; the IOS is not really designed in such a way that it would easily be able to prevent this sort of thing.  If Nintendo was to ever try to block this exploit they would likely patch the game when it is being preloaded - it would probably be done through the system menu.  The problem with that though is that these games weren't designed to be patched; Nintendo would be taking a huge risk by patching it since they could easily introduce bugs into the code - especially since each region of SSBB would probably require a slightly different patch.

[Austin]

Guys guys, stop discussing how nintendo can prevent this
let them figure it out themselves XD joking
this will be an awesome exploit by the way

[Romaap]

I'd love to see an attempt to patch this, they will probably fail again

[wvwp06]

Looks kinda fake. . .
I mean, where is the disc that should be in the left side of the disc channel. Mine looks just like that when I use bootmii to move the disc channel and replace it with my SSBB channel for my usb loader. I don't know. . .
I no nothing about this kind of stuff, so I could be compleatly off base here.
If I am sorry. My bad

[Link]

Looks kinda fake. . .
I mean, where is the disc that should be in the left side of the disc channel. Mine looks just like that when I use bootmii to move the disc channel and replace it with my SSBB channel for my usb loader. I don't know. . .
I no nothing about this kind of stuff, so I could be compleatly off base here.
If I am sorry. My bad

The disc you're talking about has been introduced with 3.2 if I remember correctly.. as this is obviously not 4.0 (has no SD menu) I guess this video has been taken on 3.0 and 3.1 - these platforms are still popular when it comes to test development!

[milw0rm]

i don't get it, how they FIND those exploits/stack smashs..... how they search for it? IDA? How they can "exercise" it?? It would be great, if someone knows it. somewhere must be a guide or tutorial on how to exploit bugs, because hacker were noobs in the beginning, too ^^

[svpe]

The first thing i normally do in order to find such stuff is to understand (at least) parts of the file format. You then try to modify it in unexpected ways (e.g. the name of some character suddenly become really long) and watch what happens when you load that modified file. You normally only use objdump, IDA or any other disassembler to figure out checksums, encryption and compression algorithms and similar stuff used in the file you are modifying. If you now notice that your game shows unexpected behavior (i.e. it crashes) you start to patch the game binary so that you can get more information about the exception (you'd use a debugger when you would do this on a pc but we don't have a real debugger for wii games).
You have won if you get a "Invalid instruction at address %p" and %p becomes some value from your savegame. You just need to figure out some constant address in memory which contains the savegame then by dumping the whole RAM after loading it (you can use WiirD to do this). You put your own code there (normally some machine cleanup (stop audio, video, interrupts,...) and a chainloader)  and put this address in the savegame.
When the game now loads your modified file some parts of the stack will be overwritten with parts from your savegame. The stack also contains saved return addresses which are your target. This address was originally overwritten by some random value from your savegame because you e.g. increase the length of some string. This is what appeared at "%p" in the exception debug information. After modifying this value to a real address with your own code the game will now return from some random function to your own code.

[milw0rm]

First of all, thank you VERY much, for taking the time and registering here and answering my question in such a long and intensive text, svpe ^^ But altough i have a few questions...

The first thing i normally do in order to find such stuff is to understand (at least) parts of the file format. You then try to modify it in unexpected ways (e.g. the name of some character suddenly become really long) and watch what happens when you load that modified file. You normally only use objdump, IDA or any other disassembler to figure out checksums, encryption and compression algorithms and similar stuff used in the file you are modifying.

So, I saved a savegame (f.e. Super Mario Galaxy) to my sd card. it's a data.bin. i open it up in ida as (binary file? ppc? which assembler type?). Should i look into pure hex code and start to look for "myterious" headers (ELF, ZIP have special headers, like gunzip indicator; or MZ in Microsofts PE file )? This is impossible, isn't it? How can i look for encryptions? Do you mean special hashes (like in blowfish i think; in Win32 RE PEiD, a krypto analyzer, looks for special hashes etc., too and can tell you, which encryption(s) are (is) used... And how to figure out (= reverse engineer?) checksums? on win32 platforms this is very difficult, but which platform in a disassembler should i chosse (a data.bin file isn't a PE file...). Furthermore i cannot replace a pice of "hex" (aka code, crypted, compressed maybe) with some bogus hex, can I? Can i brick my wii, by playing around in this way? What will happen? objdump is a disassembler and debugger.... ppc(l?) plugins are needed, aren't they? Are they any guides etc. you know/read/can recommend?

If you now notice that your game shows unexpected behavior (i.e. it crashes) you start to patch the game binary so that you can get more information about the exception (you'd use a debugger when you would do this on a pc but we don't have a real debugger for wii games).

-> i replaced some hex values by 0xFFFFFFFFF. What can (could) happen? A crash? A brick?!

"Invalid instruction at address %p"

-> a message by my wii on the screen?


Sorry for asking SOOO many things, but i cannot find a page, about wii and exploiting.... It's the first time, someone is asking things like that - and definetly the last ^^

[Chocolate Pi]

Any development on this?  It really is an awesome hack.  I look forward to the release!

One thing I don't get though... why did Stage Builder automatically check the SD card instead of system memory?  Is this normal behavior if the system save contains no stage?

[paprika_killer]

not a clue, but if we knew WHY sakurai made brawl like this we would probably still not understand