Hacking New free homebrew entry point. FlashHax

[nino38]

I tried 4 times but it’s not working. It stops at 99%. Why????

Of course you have selected E, don't you?

 

[eric429]

Of course you have selected E, don't you?

I selected E.
I tried over 7 times, and my friend 5. No ome succeded

 

[Fullmetal5]

I tried 4 times but it’s not working. It stops at 99%. Why????

What region and screen type (50Hz vs 60Hz) are you on?

 

[eric429]

What region and screen type (50Hz vs 60Hz) are you on?

E, and 60hz

 

[Fullmetal5]

E, and 60hz

Well that explains some it. If you have 60Hz set use the U option if you have 50Hz set then choose the E option.
I'm search for a way around this issue but as of right now I haven't found one yet.

EDIT:
The website has been updated to make this more clear. Sorry about the confusion with it.

 

[TR4SHB04T]

A new version has been put up on the site that should support all regions and make the rop chain independent of the host region.
If nobody has any issues I will be releasing this later tomorrow or maybe tonight if I have time.

EDIT:
It would be really helpful if people could make sure this works for both E and J regions as well AND let me know it worked and what region in the thread so I can tell it's working rather than me assuming that everything is fine since no one complained.
I would test them more myself but Dolphin is being really glitchy and not working with things I KNOW work fine on console.

The same problem from before still happened to me. I'm starting to think it's something with my wii

 

[Fullmetal5]

The same problem from before still happened to me. I'm starting to think it's something with my wii

Can you try using the B button and moving the web page around as it loads.
I've encountered rendering bugs before that make it look like it's stuck as 0 even when it is still downloading. Although that doesn't explain why it isn't working for you.

 

[TR4SHB04T]

Can you try using the B button and moving the web page around as it loads.
I've encountered rendering bugs before that make it look like it's stuck as 0 even when it is still downloading. Although that doesn't explain why it isn't working for you.

I did what you said but nothing happened for me. There's definitely something wrong with my wii.

 

[Fullmetal5]

FlashHax V3 has been released and is also now available on github (https://github.com/Fullmetal5/FlashHax)

 

[Brawl345]

Worked for me with "U" on a European console with 60 Hz on the fourth try

 

[Chadderz]

Thanks for the updates @Fullmetal5. MrBean35000vr and I were looking into removing the need for the menu options, in particular to save people having to work out if they're 50Hz or not (to lower the barrier to entry even further!). We got a version working today by adding 0x120 bytes of garbage to the end of the 'hax' string in loader.as. The reasoning is that at present the 'hax' strings are spaced 0xc50 apart in memory, so with the padding the strings are now placed 0xd70 apart. This then allows the 50Hz StringBaseAddress to work for all versions because the gap between the 60Hz and the 50Hz addresses is 0x35c00 = 0xd70 * 0x40. As long as at least 0x40 consecutive strings are placed at StringBaseAddress it will work for 60Hz.

As for removing the Japanese menu option, I believe this can be done very simply in JavaScript by detecting the system locale by checking navigator.language.

We've not moved beyond this experiment yet, but I thought I'd share the ideas here so they can be implemented into the official version if you wish.

 

[Fullmetal5]

Thanks for the updates @Fullmetal5. MrBean35000vr and I were looking into removing the need for the menu options, in particular to save people having to work out if they're 50Hz or not (to lower the barrier to entry even further!). We got a version working today by adding 0x120 bytes of garbage to the end of the 'hax' string in loader.as. The reasoning is that at present the 'hax' strings are spaced 0xc50 apart in memory, so with the padding the strings are now placed 0xd70 apart. This then allows the 50Hz StringBaseAddress to work for all versions because the gap between the 60Hz and the 50Hz addresses is 0x35c00 = 0xd70 * 0x40. As long as at least 0x40 consecutive strings are placed at StringBaseAddress it will work for 60Hz.

As for removing the Japanese menu option, I believe this can be done very simply in JavaScript by detecting the system locale by checking navigator.language.

We've not moved beyond this experiment yet, but I thought I'd share the ideas here so they can be implemented into the official version if you wish.

Awesome idea, I never looked at the spacing so I never thought to check whether the string could be aligned like that. Since that solved the 50 vs 60Hz issue and jp is already detectable from the user agent like you said I'll go ahead and make this part of the official version and remove the menu as soon as possible.

 

[Fullmetal5]

Thanks for the updates @Fullmetal5. MrBean35000vr and I were looking into removing the need for the menu options, in particular to save people having to work out if they're 50Hz or not (to lower the barrier to entry even further!). We got a version working today by adding 0x120 bytes of garbage to the end of the 'hax' string in loader.as. The reasoning is that at present the 'hax' strings are spaced 0xc50 apart in memory, so with the padding the strings are now placed 0xd70 apart. This then allows the 50Hz StringBaseAddress to work for all versions because the gap between the 60Hz and the 50Hz addresses is 0x35c00 = 0xd70 * 0x40. As long as at least 0x40 consecutive strings are placed at StringBaseAddress it will work for 60Hz.

As for removing the Japanese menu option, I believe this can be done very simply in JavaScript by detecting the system locale by checking navigator.language.

We've not moved beyond this experiment yet, but I thought I'd share the ideas here so they can be implemented into the official version if you wish.

Unfortunately after finally getting some time to work on this I've been unable to replicate your success with this method. There appear to be a couple allocations made between the two points, even running the same page twice resulted in the hax string being in random locations by the time it got that high.

If you have a working example I would love to see it, maybe I'm just screwing something up.

 

[Chadderz]

Interesting. I admit we didn't play with it for very long, so perhaps the consistency is lower than I believed, but we definitely got it to work and saw many repetitions of the string well aligned as expected. I suppose one thing to consider is the fact that you append i to the string in the array, that could mess with the lengths.

Unfortunately I couldn't find a free flash compiler, so we did the edit by editing the flash assembly code directly. I believe our edit would be the equivalent of adding the line 'ROPChain = ROPChain + "\u4141\u4141\u4141\u4141\u4141\u4141";' 24 times after the line 'ROPChain += NumToUniString(PayloadStart);'. It was the simplest way I could think to do it.

 

[nino38]

Can you implement it by 4/15?

 

[xplicid_yt]

It's been a while since any new entry points have been introduced and even though the Wii might be pretty much dead I thought it was still worth having another free entry point.

Wii Mini: Unfortunately the Wii Mini doesn't have an internet connection so there is no way to use this exploit on it.

This is an exploit in the Wii's Internet Channel which can still be freely downloaded from the shopping channel.
This exploit is entirely loaded over the internet so you don't even need an SD card for this.
The goal in the future is to have a little app store where you can launch any homebrew app without having to go through the Homebrew Channel or mess around with preparing files on an SD card.

Unfortunately this doesn't work for the vWii since Nintendo doesn't allow you to download the Internet Channel on the vWii. Although if you install the channel through homebrew it should in theory work (untested tho).

Currently the only payload that is prepared is the HackMii Installer (v1.2) so you can install homebrew on a Wii that has a broken SD card reader.
Although good luck trying to get any homebrew apps to play nice without their SD card support.

Here is the current guide to FlashHax.

WARNING: A good Internet connection is highly recommended to increase the success rate of the exploit.
EDIT: Internet connection speed should no longer matter but I can't say for 100% sure I got all the randomness out of it so a good speed might still help.
1. Download the Internet Channel if you don't already have it from the store.
2. In the Internet Channel go to flashhax.com
3. When the page loads it should select your region and when the site prompts you bookmark the page.
If you get this far then you can start from here if the exploit fails.
4. Click the page label "FlashHax" that just got added in the favorites menu.
You should be booted into the HackMii installer after a few seconds.
If you get stuck at 95%+ on the download then hold down the power button on your Wii to try again.

From now on all you have to do is click the Exploit page from the favorites menu to be launched into the installer.
As I said above this isn't that useful to do multiple times however I hope to have a landing page where you can select what app you want to launch. (Coming soon... maybe... I haven't really started on this yet)

Questions people will probably ask
>So if this isn't available to the vWii and we already have an entry point that works without any channel and isn't patched then what's the point of this?
This was just a fun project that I decided to work on. There wasn't really a need for this, it's just a project to teach me more about PowerPC and how to exploit it.

>Is the source code available?
Yes. See the attached file source.zip

>What's the success rate of the exploit (e.i not having the Wii hang loading it)
Currently the success rate is around 90%-95%. Which is REALLY good for a heap spray that can't include any type of nop-sled and needs to be hit at an exact location. (This is also why launching from the favorites menu is a must since it has a much stabler heap layout when the page loads.)

TODO no particular order:
1. Getting this to work with other regions of the Internet Channel should be easy. I just have to download that version of the Internet Channel and tune the exploit for it.
2. Add that app store I was talking about
3. Attempt to get success rate higher/stop having to use a heap spray. Unfortunately this is very difficult I have spent a few weeks on trying to get this to not have to use a heap spray to no avail. At this point in time it just doesn't seem possible without using a different exploit.

How to build your own payload into a webpage:
This requires your payload to be in an elf format. It should be possible to convert it from dol to elf however the tools to do that aren't in this.
1. If you are running on Windows then you need to install Cygwin to run some of the build commands. DevkitPro will also need to be installed IN THE CYGWIN CONTAINER!
(Optional as of V2.1) 2. You will also need an application that can compile the fla into a flash swf file. I use Adobe Flash Professional CS5.5 (11.5.1). Just open the fla and click File->Publish. This should create exploit.swf in the same folder.
3. Once you have the swf files just double click the exploit.bat file to copy it into the server folder.
4. In Cygwin make sure you have installed the devkitpro ppc toolchain as well as a native toolchain for your system and Python.
6. Copy your boot.elf file of choosing to the payload folder!
5. Open a Cygwin terminal and navigate to the payload folder and run the buildNdump.sh file.
6. At this point the server folder should have been populated with the swf files and payload.bin along with the index.html and start.sh that were already there.
7. Run the start.sh file from Cygwin to start a temporary server on port 8080 that you can test with.
8. To navigate to this on your Wii's Internet Channel go to http://YOUR LOCAL IP HERE:8080/
9. You can now continue like normal from step 3 on the current guide to flashhax section to launch the payload.
If these steps fail after testing with a normal boot.elf (like the HackMii installer one) then please leave comment with what is going wrong. This hasn't been tested very much so there are likely to be a couple problems with the instructions.

Technical explanation for the exploit:
This is actually a fairly recent flash exploit that was discovered by Google's Project Zero team and patched in early 2016. (CVE-2016-0974) (https://bugs.chromium.org/p/project-zero/issues/detail?id=667)
If you look at the source for the exploit "exploit.fla" and check the actionscript on frame 0 you will find the attack there.

The first thing to explain is what happens if you just trigger the PoC from Google (see link above).
This will actually crash the Wii. But what is interesting is if you enable panic handlers in Dolphin you will see it crashes trying to read memory at an address like 0x00740065. Hmm, that looks like a weird address and if we run the exploit several more times we consistently get this address over and over.
So lets take a closer look at that address 0074 0065. Those numbers are valid ascii letters and if it's unicode that might actually be a string!
Sure enough if we translate those addresses to characters in ascii we get "te". Now where do we see "te" in our exploit?
Right, the string returned from the function that removes its parent (func) starts with te! So lets confirm this by changing those characters to AA.
Sure enought we get a invalid read at address 0x00410041. (The addresses read might be +- 4 depending on what it's trying to read so it might be a little off but still), this confirms that we control where it is read from. Now how do we turn this into an exploit?

Well the first thing we need to do is get it to actually read something that doesn't start with 00. Luckly flash lets us include almost any uncode characters we want in a string if we just use escape charaters. So putting in "\u4242\u4242" will result in a two character unicode string that in memory looks like 0x42424242. Perfect!
Run the exploit again and sure enought we now crash on 0x42424242. So now we control where we now need to know what this thing is actually doing with these addresses.

To spare you from the hours of reverse engineering that this took I'll just explain what's going on.
The object we are overwriting with our use-after-free is cleared when garbage collection happens (I think, no way to really confirm tho).
This object has a very simple layout when going forwards:

0x(pointer to next object)

However after it reads this pointer the object is initialized like this:

0x00000002 (some small number)
0x(pointer to previous object)
0x00000000 (might get changed to pointer to something)
0x00000000 (might get changed to pointer to something)
0x00000000 (might get changed to pointer to something)
0x00000010

This is a pretty bad primitive if you just look at it like this. You can see a pointer to the previous object is written to +4 from where ever the next object is so there is some hope for this to be useful.
This means that we just setup a pointer to an address we want to point back to us then subtract 4 so that the back link will point to our object.

Unfortunately this primitive has a major downside. Flash will continue to follow this chain of pointers to objects and after every follow it will read the next address then overwrite it with the second layout I described.
This has the side effect that if you don't take control before flash reads the next object and it turns out to be an invalid pointer then the Wii will just crash referencing it.

Somehow we need to either stop it from reading anymore objects in the chain, be the last link in the chain, or somehow break that code that is looping this without crashing the Wii.

Unfortunately after some more reverse engineering it turns out it isn't possible to stop the chain prematurely as our pointer is never check before being dereferenced and none of the other fields in our string are even read so there isn't even a chance that it is looking for some other end of chain marker.

This means we have either the code method or finding out how many times this thing loops and being at the end of it. After looking at the code to see if there was some way to break the loop with the write I have concluded that it just doesn't seem feasible without more direct control over what is being written. The best I could get with this method was a single instruction from a limited list being executed before a guaranteed crash.

This leaves us with somehow being the end of the chain. Spoiler alert this method ends up working however it comes at the cost of having to do a heap spray with little to no chance of using any type of nop-sled. The first thing to try is finding out how many times the loop is called so we know when the last link in the chain will be and won't have to worry about it's pointer at that location being a bad address. For example if the last link in the chain is pointed at 0x80003400 then flash will overwrite 0x80003404 with a pointer back to the last object but WON'T follow the pointer it found at 0x80003400, This is great because it means that the Wii has time to do a context switch to another thread which involves following pointer to find saved thread contexts.

So how do we find out how many times the function is called? Well if you just set a break point at the function you will actually see it called hundreds of times a second. This might make it seem like there is no way we could predict when the last chain is however, taking a closer look we see that r4 is dereferenced to obtain the pointer that it saves before it initializes the object. Only looking at the times that our chain is the one being iterated over we see that r4 actually is the same address each time while a different address for other chains. (Note that this doesn't mean r4 is a static address just that determines what chain we are following). If we just pay attention to our chain then we quickly see that it is only iterated over 6 times before stopping. This is the key we need to take control without crashing the Wii!

At first you might think that we can just overwrite a saved stack pointer. Unfortunately this doesn't work since don't know where these threads stacks are. If you investigate the function which is looping over the objects you will find that it's sp is pointed at an address in MEM2 and each time you run it the stack will be at a different location. Fortunately there is a static address that contains a pointer to a thread context that we can overwrite with out primitive.

Lastly since we know we are going to have to guide the loop ourselves this means we can't just use one string to do the exploit since we need to predict its location. After searching in the heap for a while I was able to find a location that we always allocated when the favorites menu was used to load a webpage and when a heap spray occurred there was a high chance that just after this allocated area would be our target string. I really didn't think that this would ever work reliably since we need to count the number of loops that chain has to do so no nop sled but somehow this little statically allocated (not really static but very likely) region saves the whole thing.

With all of this in mind we can now craft out exploit chain.

First we create a string that will guide the garbage collection loop through our chain the correct amount of times.

StringBaseAddress:
0: 0x(StringBaseAddress+0x18)
4: 0x41414141
8: 0x41414141
c: 0x41414141
10: 0x41414141
14: 0x41414141
18: 0x(StringBaseAddress+(0x18*2))
1c: 0x41414141
20: 0x41414141
24: 0x41414141
28: 0x41414141
2c: 0x41414141
30: 0x(StringBaseAddress+(0x18*3))
34: 0x41414141
38: 0x41414141
3c: 0x41414141
40: 0x41414141
44: 0x41414141

Assuming that we start reading at 0 then this chain will guide the collection routine 3 times before reaching the next pointer. At this point we will actually have used up 4 loops since the initial pivot to this string will have taken one.
Next we need to decide where we are writing our address to. As I stated above there is a nice pointer in the thread swapping function that we can overwrite and will be used when the next thread switch happens and is suppose to point to the stored thread state. This means we control most of the registers when the thread switches. Since this is our 5th iteration in the loop when it goes around for the last time it will overwrite the pointer with the back link to our string and stop after that.

Once a thread switch occurs with out string as the stored thread context we control most of the registers. (See the fla file for the exact layout of registers stored in a thread context)

Unfortunately since we clobbered the next couple bytes in our string this makes it impossible to directly control the sp register with this since it is loaded from offset 4 which is in the middle of the clobbered region. We do however control registers 6 and up as well as all the special purpose registers such as lr, ctr, and pc. This means that with some rop trickery we can use a value stored in one of our registers we do control and swap it with sp.
The exact chain isn't really interesting but you can take a look at the addresses in the file. At this point since we control sp we can build a rop chain that will write a payload to somewhere in MEM1 which is mapped as executable in the BAT registers and jump to it. From there it is game over. The rop chain in this exploit writes an egg hunter that looks for the payload downloaded earlier by flash and copies it to MEM1 before jumping to it. This allows us to get around the annoying no unicode null restrictions on flash strings.

That about does it for this exploit. Just to note this is by far the worst exploit primitive I have ever successfully used and man was it such a pain. Definitely worth it in the end to get it working tho .

Source: https://github.com/Fullmetal5/FlashHax

All code is under the GPL-V3 unless otherwise stated.

Changelog:
All change logs from here on are on github (https://github.com/Fullmetal5/FlashHax)

V2.1.2:
Forgot that the payload is now payload.bin instead of payload.jpg so don't keep naming it that in the builder.

V2.1.1:
Take out some accidentally included code and fix javascript callback

V2.1:
Split the exploit off into it's own file that can be maintained easier.
Made menu more presentable and cleaned up lots of the loader.
Added arguments that can be passed to the loader from flash or javascript.
Made html file sane again. Unfortunately breaks bookmarks again. (sorry)

V2.0.1:
Fixed some formatting and fixed broken embedded payload address check.
Updated index.html to minified version. (This will break previous bookmarks)

V2:
Added instructions on how to add your own boot.elf

It is nearly 2019, fans of the wii with an unmodified wii will have to start downloading the internet channel from the shopping channel before closure the deadline is January 30th, 2019.
If you already have this channel then you have no worry, but if you do not then download the channel before the deadline. If missed the deadline then follow this link for more entry points fro the homebrew channel.
http://wiibrew.org/wiki/Homebrew_Channel#Pick_an_exploit

Choose your exploit accordingly to your wii preferences (menu version)

Good Luck

 

[GreyWolf]

It is nearly 2019, fans of the wii with an unmodified wii will have to start downloading the internet channel from the shopping channel before closure the deadline is January 30th, 2019.
If you already have this channel then you have no worry, but if you do not then download the channel before the deadline. If missed the deadline then follow this link for more entry points fro the homebrew channel.
http://wiibrew.org/wiki/Homebrew_Channel#Pick_an_exploit

Choose your exploit accordingly to your wii preferences (menu version)

Good Luck

? This really didn't need a bump, and why not just use Letterbomb?

 

[Kirbeast]

It keeps freezing at 98-100%, I've tried clearing cookies, changing resolution, screen size, unplugging plugging back in, unplugging all controllers and USB devices, retrying the entire process, have tried over 20 times, still nothing.
Many other people are also having this problem. How do I get this to work? My console's region is U

 

[FancyNintendoGamer567]

@Kirbeast FlashHax also didn't work for me. The only FlashHax thing that was worked for me was the Wiimmfi one.
If FlashHax doesn't work, then move on to Smash Stack or another game related exploit, or use Letterbomb.

 

[Fullmetal5]

Currently the success rate is really low partly due to changes that made it work for all regions. Since the e-shop is closing down soon rather than fixing flashhax I've been working on something else that I hope to release soon. (It works but there is still one hurdle left that I just haven't had time to work on due to classes/work.)
This new method has a MUCH higher success rate. (It can still fail but much less likely in the tests I've done so far) (Bonus it works the same across all regions without any change at all.)