WOW, what a big picture, you could have put that in spoilers like i did above, this is much better for the eyes...and makes reading the thread much better.But my XenoX is little incomplete cuz
I can't download these file and DLC
WOW, what a big picture, you could have put that in spoilers like i did above, this is much better for the eyes...and makes reading the thread much better.But my XenoX is little incomplete cuz
I can't download these file and DLC
Oh rly sorry i am newbie using forum, sorry :LWOW, what a big picture, you could have put that in spoilers like i did above, this is much better for the eyes...and makes reading the thread much better.
Problem being, I couldn't even setup a Nintendo Network Id yet on my 2nd Wii U since it also requires you to update first
YesWow, really? Nintendo is the most anti-consumerist company (besides Apple) that I've seen.
Making more progress on eShop update bypasses. 105-4260 was the old error, which just said the network was "busy" (aka nn::nim::NeedsNetworkUpdate returned 1). This is what happens when you remove the call from the app .text. I'm willing to bet this is a return from NNID sign in, so maybe patching NIM directly will yield results.
True, I paused a random thread for fun and it already crashed so that's pretty retarded.The only downside is that pausing the wrong thread or at a wrong time it will crash your console, so testing this is really a pain.
Still not respondingYou have to use the unmodified codehandler:
If I can't do it in code my plan is to take a look at the SSL content by using cafiine or similar (maybe alter the .text to read from SD?) to change the pem to allow me to MITM the SSL on the Wii U while in eShop. I've done it on 3DS so I see no reason for it to fail there, especially with it as modular as it is (3DS needed a reassembled module and modified rodata). It could be a check somewhere which consequently fails it. Or, there's a check somewhere for the error, so even if the actual call returns 0 it'll also check for an existing error. How were you altering the NIM module?I already got to that point few days ago just using tcp gecko, but I could not still get to enter the eshop so I lost interest; my advice is to try messing around with the debug feture of tcp gecko, with which you can pause threads. There are some threads dedicated to update checking and maybe with a good timing you can go inside eshop (and maybe also online games). The only downside is that pausing the wrong thread or at a wrong time it will crash your console, so testing this is really a pain.
the devs said several imes SD acess will be very hard if possible with kernel tough.If I can't do it in code my plan is to take a look at the SSL content by using cafiine or similar (maybe alter the .text to read from SD?) to change the pem to allow me to MITM the SSL on the Wii U while in eShop. I've done it on 3DS so I see no reason for it to fail there, especially with it as modular as it is (3DS needed a reassembled module and modified rodata). It could be a check somewhere which consequently fails it. Or, there's a check somewhere for the error, so even if the actual call returns 0 it'll also check for an existing error. How were you altering the NIM module?
Not quite, Matt and NWPlayer got it workingcafiine works on 5.5.0, tcp is not so lucky
Man this thread was active for the past few weeks I was gone
Uhm... Anyone willing to, in a nutshell, wrap things up here? Did anything "special" or "awesome" happen for 5.3.2 the last... let's say 3 weeks?
Once the IOSU exploit is finished, file replacement will be permanent since it will allow for SD/USB file replacements (maybe...)File replacement is permanent using Cafiine?
A step closerSo I readjusted my patches so that it wouldn't get a chance to throw any errors, now it's not throwing an actual error but the update nags persist.
So I readjusted my patches so that it wouldn't get a chance to throw any errors, now it's not throwing an actual error but the update nags persist.
Is it a real firmware spoof, or is it a simple string edit?ALRIGHT, got kernel exploit on 3.1.0 working, turns out the memory mapping is quite different, for you guys it physically started at 0x31000000 which maps to 0, for me it starts at 0x30000000 which maps to 0x10000000, my 0 is actually located at 0x4C000000 so where you guys write to 0xA0000000 I need to write to 0xBC000000 now, but hey all that aside its working pretty good, coreinit can be written over quite easly now as I just tried out by patching MCP_GetSystemVersion: