Indeed.
If I can help with my still 2.1.0E Wii U, I wield my iron, and write my codex with great Qapla'! (Meaning: I can solder and code just fine )
Edit:
Again, though, how and at what moment do you guys make a memory dump, to port/create the ROP chain?
Don't worry, I'm porting the UAF bug to firmwares 2.x.x as well. All I need is coreinit's and libwkc's base addresses, which I've already requested to someone who has a unit on the exact same firmware.
Either way, I would really appreciate if you could give it a try on your 2.1.0 after I implement it since not many people are still on such a low firmware version.
Regarding your question, the memory dump is almost always the first step. From firmware 4.0.0 to 5.1.0 we went straight to ROP chain building thanks to analyzing crash logs from a devkit.
However, back porting the bug to 3.x.x was not that straightforward since I couldn't find anyone with a devkit on that firmware range. Luckily, using a combination of blind exploitation (guessing the addresses of several functions by analyzing the binaries from NUS) and a heap-overflow exploit (similar to comex's) I could analyze just enough of the memory to find the base addresses of the modules needed for the ROP chain.
The whole process required combining a total of 3 different exploits: 2 use-after-frees and 1 heap-overflow.
You won't have to go through this tedious process since the WebKit source code used on 3.x.x is the same in use on 2.x.x. Which means, the same exact exploit plan can be applied and the UAF bug can be ported in hours (specially if the same ROP gadgets still exist, which is unlikely).
what's the size of the OTP, in case anyone knows? been wondering how many attempts it'd take to get the keys judging by the size of the otp
so when do we get a release :** lol
i'm asking because i'm in talk with Hykem and he said he's in the OTP part. the function can read 0x20 bytes of the OTP, but he doesn't know the exact size of it, hence why i asked. we believe it's 0x200, but we're not sureWe already have every key except for the vWii common key and the ARM ancast key. Both of those are AES128 (16-byte) keys, which are very implausible to brute-force the hashes of.
i'm asking because i'm in talk with Hykem and he said he's in the OTP part. the function can read 0x20 bytes of the OTP, but he doesn't know the exact size of it, hence why i asked. we believe it's 0x200, but we're not sure
Hahahahahaha! Omg hahahahahahahah!!!
Sooner than the 3ds exploit I think. Gateway was closed source and that slowed it down so much I expect. Since this exploit will be open source iirc, then I presume we will have some nice pace on it but I still think it will take awhile for itAfter a kernel/iosu exploit for a particular version (lets say 5.3.2) is released, how likely is it that something like Emunand will be released soon after? I'm sure most people want USB loading etc but something like emunand should be high priority because it will allow people to still enjoy the console whilst waiting for other stuff to be developed for the older firmware.
Emunand will also be nice because assuming there's no way to downgrade, the people who updated for 5.4 or beyond will presumably be able to just buy new consoles and do a system transfer to emunand on one of the splatoon 5.3.2 native consoles.
My laughtiung was exactly about this...You realize that even after the exploit is released, backup loaders are still like 6 months away. There is no IOSU exploit yet, and of course, no loader software.
Yes, but it might take a while to get out. Also, 1.X firmware is pretty useless as it doesn't even have a usable browser for easy exploitation. I admire your dedication though Could probably trade in one and just get a Japanese one if you really wanted. All our stuff is targeted to be as high of a firmware as possible (which at this moment is 5.4.0), Hykem's just on a lower version for the moment because there is proven stuff on that version that he's using to get info for the latest versions.I'm thinking of buying a Japanese WiiU after playing taiko no tatsujin on it at a convention last weekend. I've wanted a japanese WiiU for a long time, but I've been waiting ( and hoping ) that someday a Region Exploit would be released. I already own 1 US console on the latest firmware and 1 Pal console on the latest firmware, 1 pal console on firmware 1.0.0E and 1 pal console on 1.0.3E. I've kept 1 since launch, hoping for a region hack ( the firmware 1.0.0E version).
My question is, could this hack lead anywhere near a region hack, or should I just import a Japanese WiiU ( which I rather don't, because importing one to the Netherlands would cost me around 400 euros).
Thanks!
Yes, but it might take a while to get out. Also, 1.X firmware is pretty useless as it doesn't even have a usable browser for easy exploitation. I admire your dedication though Could probably trade in one and just get a Japanese one if you really wanted. All our stuff is targeted to be as high of a firmware as possible (which at this moment is 5.4.0), Hykem's just on a lower version for the moment because there is proven stuff on that version that he's using to get info for the latest versions.
Well considering how much all of you complained about how we don't even have code execution, I'm gonna just say stay on 5.3.2 until we tease you with a 5.4.0 Webkit exploitSo is 5.4.0 still a firmware we should avoid, i.e. still confirmed as unsafe to update to?
Well considering how much all of you complained about how we don't even have code execution, I'm gonna just say stay on 5.3.2 until we tease you with a 5.4.0 Webkit exploit