It's in one but you do have to run it twice. It succeeds at installing large updates tho. Took about 25 minutes for SSBU.
I took a look at the code changes and urgh removing code to fix stuff is a terrible way to fix something.
Especially apparently not understanding the code and changing a whole code block instead of changing a return type to int?
The changes to the installer code itself come down to four lines:
So what does this do?
The first block changes:
OSFatal("Install OK");
to
OSFatal([whatever is in CPU register 3]);
In this case this code part can only be reached when register 3 is zero so he is basically changing the code to pass a zero pointer and passing a zero pointer instead of string usually ends in a crash.
The second part changes this:
__os_snprintf( allocated_buffer, 32, "Error:%08", ErrorValue );
to
__os_snprintf( allocated_buffer, 32, [whatever is in CPU register 5], ErrorValue );
register 5 at this point holds a pointer to the returned data from MCP_InstallTitleAsync.
This probably causes __os_snprintf to crash.
So how the hell does this fix work when the code crashes?
The install function is asynchronous so even if the code stops or crashes it will continue since the whole installing part is run on ISOU.
I certainly wouldn't use such a butchered version that pretty much only "works" by coincidence.
Especially apparently not understanding the code and changing a whole code block instead of changing a return type to int?
The changes to the installer code itself come down to four lines:
Code:
/* //Related to the previous Error and Success methods we disabled above, so should be disabled too.
//err str address, r5
*(vu32*)ADR(base_addr+0x128) = 0x3CA00000 | (err_str>>16);
*(vu32*)ADR(base_addr+0x12C) = 0x38A50000 | (err_str&0xFFFF);
//suc str address, r3
*(vu32*)ADR(base_addr+0x10C) = 0x3C600000 | (suc_str>>16);
*(vu32*)ADR(base_addr+0x110) = 0x38630000 | (suc_str&0xFFFF);
*/So what does this do?
The first block changes:
OSFatal("Install OK");
to
OSFatal([whatever is in CPU register 3]);
In this case this code part can only be reached when register 3 is zero so he is basically changing the code to pass a zero pointer and passing a zero pointer instead of string usually ends in a crash.
The second part changes this:
__os_snprintf( allocated_buffer, 32, "Error:%08", ErrorValue );
to
__os_snprintf( allocated_buffer, 32, [whatever is in CPU register 5], ErrorValue );
register 5 at this point holds a pointer to the returned data from MCP_InstallTitleAsync.
This probably causes __os_snprintf to crash.
So how the hell does this fix work when the code crashes?
The install function is asynchronous so even if the code stops or crashes it will continue since the whole installing part is run on ISOU.
I certainly wouldn't use such a butchered version that pretty much only "works" by coincidence.
Hey now, people were waiting for you to take the time to address why it wasn't working on 5.4, if you had then this wouldn't have had to be made. People were waiting on you to fix it, but there was no sign of you, so I did what I could and it worked, and I stressed that this was not a proper fix and that someone like you would hopefully do it right... Until then, what works, works, without Soon™
This is a learning process for me, I'm a C# guy and a lot of this is foreign to me. I've since changed the return type and have that code block compiling.
Last edited by Kakkoii,
Is crediar updating the main build then? I've had success with mario maker using crediar's installer, but this one I've tried several larger updates and let the console sit for over an hour and on reboot nothing even there, no corrupt data or anything. After crediar's comments I think I'll hold out on trying the 1.2 version. Although if anyone else has success with the mod version 1.2 I'd like to hear about it.
Where did you let the console sit? Did you press the Wii U Menu button after the black screen? Everyone else that has been using my version has been having success.
Crediar has yet to update the master build with a fix, and the version in the 5.3.2/5.4 thread is simply a build of that same old master version from a month ago.
Also, make sure you' installing the title update and not the title, sometimes people get the codes mixed up. A title update should have the first part of the Title ID should be 0005000E-
If you try to install something that is not certified for your system, with incompatible keys, it just won't install and won't show any corrupt data or anything.
Last edited by Kakkoii,
Kakkoii could you please build a payload version for 5.3.2? Splatoon/Smash updates don't install on normal wupinstaller and I don't think browserhax (MP4) works for 5.3.2. At least it's always crashing after player controls appear, and I've tried hosting it locally as well.
I tried the modified wupinstaller I dont know if it worked or not as I dont see the update file under data management I think its time to toss this Wii U out while the kernel and everything works I cant launch any games now as ssb wont update and I am stuck with unnecessary data that wont delete
At a quick glance of code, I tend to agree with @crediar on this front. There isn't anything that you've done to "fix" any problems with what crediar did in the master to make things work initially. Its much more likely that changes made to the way the race for ksploit is handled changed timings that make it more stable. Still though, I appreciate the effort to the scene.
The changes to the race exploit only allow for more likely success of ksploit itself, the addresses are still the same. The problem on 5.4 is the error code he hooks doesn't function properly, as soon as you hit a button, an OSFatal is thrown, halting the installation. By preventing this from happening so a person can get to the home menu, this fix allows the WiiU's background install process to continue. It's obviously not an ideal solution, but it's at least something until he can fix it properly.
Last edited by Kakkoii,
I have hosted this modified version of code532.bin locally. I am getting an Error Code: 112-1209 - Unable to load file. I am hosting with WAMPSERVER and can see the files within the root directory of my server, but when I click the .bin file I get this error. Can someone please help me figure out why I am getting this error on my 5.3.2 U spoofed to 5.5.1 system?
I'm not familiar with wamp server, does it have Apache enabled? You should be able to just use the MP4 version too.
In all honesty, many of us wouldn't have been able to install their updates without you. The modification of @crediar 's work, regardless if the check block was removed, helped us temporarily.
Believe me, the scene is lucky to have someone like you who at least has a bit of courage to try and fix something broken. You also said it yourself that it isn't the best fix and is a temporary solution until the author of WUPInstaller - the one who has better experience since he created it himself, fixes it.(similar to how dimok is trying to fix loadiine v4 or release v5 on 5.4.0). You have my gratitude and I'm sure the others appreciate what you've done for us! Keep up the good work!
Well, all hosting the yellow8 exploit itself will do is generate that same MP4 and load it. So you'd just be adding a step. You can give these two mp4's a try, I forced them to compile differently. Lemme know if they work.
Similar threads
-
- Portal
