convert MM levels to NSMBU
How many M's are in those abbreviations?
MM NSMBU
MM M
Confirmed
*ik this joke was stupid*
convert MM levels to NSMBU
MM NSMBU
MM M
To tide you over until the big reveal, we (MrRean, RoadrunnerWMC and I) also got the first custom level working (yay, I think?)
you can't tell that to a guy who's been waiting for like... 6 months? xDDoesn't work on 5.3.2 maybe you should wait before posting this stuff
@NWPlayer123 are you able to give us (me) an update on the 5.3.2 webkit exploit develpment progress ?
Thank you in advance
Things weren't looking good for E3 but now it seems possible again (if everything goes well)It seems the answer may have been in front of our faces all along more to come soon
I hope you guys are filming a documentary about this. Seems like a lot of antics in the background. Enough to have people tune in and watch you guys get stuck at things then get out of it. With a lot of scenes of driving through neighborhoods and voiceovers about "webkit bugs"Things weren't looking good for E3 but now it seems possible again (if everything goes well)
So, let me clear up the current status on the Wii U work so far.
We've been focusing on exploiting firmware 5.3.2, but the bug we have been looking into has proven to be quite tricky to exploit.
Regardless, I'm working on a full re-write of said exploit since it's original target is very different from the Wii U. As we stated several times, exploiting 5.3.2 is simply a matter of time, but it's hard to predict when we can finally see some results due to the nature of the bug and the fact that WebKit debugging takes a lot of time.
Now, regarding the IOSU, I've been tackling firmware 3.0.1 for a while. It's taking longer than expected because I based my assumptions on two false statements:
1 - comex's original exploit was leaked and uses CVE-2012-3748 -> Not true. This is not comex's exploit. Although the bug is present in firmware versions lower than 4.0.0, a separate condition exists that prevents it from working. WebKit version 534.52 didn't make use of optimized shift/unshift operations, so, while the race condition still exists, we can't modify the array and overwrite the length parameter without triggering a memmove operation that blows everything up.
2 - Porting the existing use-after-free bug is trivial -> Also false, the libraries suffered major changes in firmware 4.0.0. Previous firmware versions have a very different heap layout and without a devkit on firmware 3.x it's really though to re-calculate the addresses used by the exploit.
Now the good news, I finally managed to run code on firmware 3.0.1. It required combining the previous user-after-free as planned and a totally different exploit (CVE-2012-3683). The results are not optimal, but it works.
I finally managed to figure out where the coreinit library is located in memory with some brute-forcing and got execution to jump into OSFatal.
I apologize for the delay, but development will, hopefully, speed up now.
(...)the libraries suffered major changes in firmware 4.0.0. Previous firmware versions have a very different heap layout and without a devkit on firmware 3.x it's really though to re-calculate the addresses used by the exploit.
(...)
Are you saying that this will also work on 3.1.0 (provided the coreinit addresses are known) but 4.x+ will take seriously more work? Am I glad I never updated past 3.1.0 despite being told a hundred times that I should!
We've been focusing on exploiting firmware 5.3.2, but the bug we have been looking into has proven to be quite tricky to exploit.
So, let me clear up the current status on the Wii U work so far.
We've been focusing on exploiting firmware 5.3.2, but the bug we have been looking into has proven to be quite tricky to exploit.
Regardless, I'm working on a full re-write of said exploit since it's original target is very different from the Wii U. As we stated several times, exploiting 5.3.2 is simply a matter of time, but it's hard to predict when we can finally see some results due to the nature of the bug and the fact that WebKit debugging takes a lot of time.
Now, regarding the IOSU, I've been tackling firmware 3.0.1 for a while. It's taking longer than expected because I based my assumptions on two false statements:
1 - comex's original exploit was leaked and uses CVE-2012-3748 -> Not true. This is not comex's exploit. Although the bug is present in firmware versions lower than 4.0.0, a separate condition exists that prevents it from working. WebKit version 534.52 didn't make use of optimized shift/unshift operations, so, while the race condition still exists, we can't modify the array and overwrite the length parameter without triggering a memmove operation that blows everything up.
2 - Porting the existing use-after-free bug is trivial -> Also false, the libraries suffered major changes in firmware 4.0.0. Previous firmware versions have a very different heap layout and without a devkit on firmware 3.x it's really though to re-calculate the addresses used by the exploit.
Now the good news, I finally managed to run code on firmware 3.0.1. It required combining the previous user-after-free as planned and a totally different exploit (CVE-2012-3683). The results are not optimal, but it works.
I finally managed to figure out where the coreinit library is located in memory with some brute-forcing and got execution to jump into OSFatal.
I apologize for the delay, but development will, hopefully, speed up now.
I listened to NWPlayer's assurances too. Kinda pissed.while im kicking myself for listening to other's........ im on the latest firmware!!!
How many times will I have to quote this@NWPlayer123 are you able to give us (me) an update on the 5.3.2 webkit exploit develpment progress ?
Thank you in advanceThings weren't looking good for E3 but now it seems possible again (if everything goes well)It seems the answer may have been in front of our faces all along more to come soon
I'll believe it when I've used it.How many times will I have to quote this