Changes

With this in mind, a sequence of bytes can be crafted to meet the needs stated above. First, there needs to be a chain of 3 pointers that point forward to the next. After this, the address to be overwritten must be present, which is the thread context, and the last pointer in the previous chain points to this pointer. When the pointer is overwritten, it points directly at the target address, meaning the rest of the thread context, after the trash bytes, need to be placed there. Finally, after the thread context, the ROP chain is present, which the first two ROP gadgets from the thread context load.

With this in mind, a sequence of bytes can be crafted to meet the needs stated above. First, there needs to be a chain of 3 pointers that point forward to the next. After this, the address to be overwritten must be present, which is the thread context, and the last pointer in the previous chain points to this pointer. When the pointer is overwritten, it points directly at the target address, meaning the rest of the thread context, after the trash bytes, need to be placed there. Finally, after the thread context, the ROP chain is present, which the first two ROP gadgets from the thread context load.

Now that a hax sequence is built, there needs to be a way to place it directly in memory. Flash does not keep array elements together in memory, so an array is not an option. The other option is a string, which is available, but it has its own issues. Similar to C strings, Flash strings are terminated by null characters, but unlike in C, characters are 2 bytes wide in Flash, meaning strings are terminated by double null bytes. There are several points in the hax string that require padding, such as between the garbage collector iterations, that would normally be set to 0. Since this is not possible here, the [code]\u4141[/code] and [code]\u4242[/code] characters are used instead. These values are also placed into all of the unused registers in the thread context to prevent the string from terminating prematurely.

Now that a hax sequence is built, there needs to be a way to place it directly in memory. Flash does not keep array elements together in memory, so an array is not an option. The other option is a string, which is available, but it has its own issues. Similar to C strings, Flash strings are terminated by null characters, but unlike in C, characters are 2 bytes wide in Flash, meaning strings are terminated by double null bytes. There are several points in the hax string that require padding, such as between the garbage collector iterations, that would normally be set to 0. Since this is not possible here, the <code>\u4141</code> and <code>\u4242</code> characters are used instead. These values are also placed into all of the unused registers in the thread context to prevent the string from terminating prematurely.

While the Wii itself does not do any ASLR, Flash does not place its variables in deterministic points in memory. To get around this, a heap spray must be done, which seems like something that will not consistently work. Luckily, when the bookmark bar in the Internet Channel is used to load a page, there is a location in memory that is almost always used, so the exploit must be run from the bookmarks bar. To detect whether the page was loaded using the bookmark bar or another way, a `#stop` parameter is put onto the URL. The Wii removes this tag when adding it to the bookmark bar, so detecting the absence of the `#stop` parameter is enough to make sure the exploit can run consistently.

While the Wii itself does not do any ASLR, Flash does not place its variables in deterministic points in memory. To get around this, a heap spray must be done, which seems like something that will not consistently work. Luckily, when the bookmark bar in the Internet Channel is used to load a page, there is a location in memory that is almost always used, so the exploit must be run from the bookmarks bar. To detect whether the page was loaded using the bookmark bar or another way, a `#stop` parameter is put onto the URL. The Wii removes this tag when adding it to the bookmark bar, so detecting the absence of the `#stop` parameter is enough to make sure the exploit can run consistently.