Hacking Priiloader 0.6 final released

[thesund0g]

This version still contains the same potentially-bricking bug that caused v5 to be taken down.

Thanks for pointing this out. I can't recommend anyone without Bootmii in boot2 updating until Daco gets his shit together.

 

[zizer]

what's about wifi update?

 

[XFlak]

my 2 cents, if u have a good ahbprot enabled forwarder channel (obviously not containing the HBC network init. bug) u can use that to launch the installer (prolly changing the apps folder name from priiloader to usbloader or w/e). Then, there should be no risk of a HBC network init error

forwarder channels like these can be found in my top wii channels thread, or the usbloader forwarder channel from ModMii, or if u can manage to install one of Tantric's forwarder WiiMC/emulator or forwarder channels using his official installer that'll work too (however, his installers are susceptible to the same HBC bug, but if the channel installs fine then using it afterwards is not going to have the HBC problem either)

but generally speaking, this doesn't bring any more brick protection over priiloader v0.4, so why bother.

TBH, I don't see why he doesn't revert to the old installation method, or at least allow the option of using the HBC no_ios_reload argument or choosing a patched IOS. Anyways, I'm not in a hurry to update my priiloader, but if loaded properly (ie. without using the HBC), i would say it should be safe.

 

[lulwut]

It is, that's why he's incorrect to claim that it's been fixed.

and libogc blocked the reply from ipc meaning it wouldn't crash anymore.

i dont see how it would crash now if no internet settings is set

let alone that i myself tried it and it worked just fine

EDIT: btw, if you disable AHBPROT in the meta.xml (remove the line) the installer will still work fine cause its forced to use IOS36 then. however, i have no shitting idea where tueidj got the idea AHBPROT/Dvd Access given by hbc isn't fixed yet cause w/e i try it works FINE for me, Daco, F_God & anyone else that tried it while 0.6 was in the making

 

[tueidj]

Maybe if you tried reading the code comment in libogc that has been there forever you would see why:

// NOTE: we really want to find out if this ever happens
// and take steps to prevent it beforehand (because it will
// clobber memory, among other things). I suggest leaving this in
// even in non-DEBUG mode. Maybe even cause a system halt.
// It is the responsibility of the loader to clear these things,
// but we want to find out if they happen so loaders can be fixed.

There are 2 reasons for crashing:
1) libogc tries to handle an IPC reply leftover from HBC trying to init the network. This has been fixed, but...
2) When IOS sends the reply it reuses ("clobbers") the area of memory that HBC originally used to send the request, possibly the new app is using this memory for something important.

If IOS decides to reply to HBC's orphaned IPC call there is nothing an app can do to stop it from clobbering random memory, unless it is specifically written to not use the section of memory that HBC uses for IPC transfers (and I can guarantee you Daco isn't that smart).

 

[Teton]

1) libogc tries to handle an IPC reply leftover from HBC trying to init the network. This has been fixed, but...

HBC hasnt been recompiled with the latest libogc

 

[lulwut]

Maybe if you tried reading the code comment in libogc that has been there forever you would see why:

// NOTE: we really want to find out if this ever happens
// and take steps to prevent it beforehand (because it will
// clobber memory, among other things). I suggest leaving this in
// even in non-DEBUG mode. Maybe even cause a system halt.
// It is the responsibility of the loader to clear these things,
// but we want to find out if they happen so loaders can be fixed.

There are 2 reasons for crashing:
1) libogc tries to handle an IPC reply leftover from HBC trying to init the network. This has been fixed, but...
2) When IOS sends the reply it reuses ("clobbers") the area of memory that HBC originally used to send the request, possibly the new app is using this memory for something important.

If IOS decides to reply to HBC's orphaned IPC call there is nothing an app can do to stop it from clobbering random memory, unless it is specifically written to not use the section of memory that HBC uses for IPC transfers (and I can guarantee you Daco isn't that smart).

but even if the app starts using that memory
it should (afaik) either resolve in ios acting odd (which should all be handled by the app if an ios command goes wrong), ios freezing/crashing (which is indeed something we can't do anything about; but for this reason the installer now first writes to /tmp) , or memory blocks getting corrupted which should also be np since the only memory blocks created by the installer are fstats & data to be written which get verified to have been written correctly using a SHA1 hash...

and again, the tests of 0.6 & the installations for now have all been fine; with or without network settings.

so i'd say the installer isn't touching the (very high in mem1 because of the entrypoint or just in mem2?) ipc transfer memory of HBC


and if you dont trust the tests i said the bypass above

 

[Kamiyama]

Is this safe to install if you got preloader 0.29 installed?

 

[chop]

I've been having some issues that I describe in this thread

I've discovered that enabling 'Block disc updates' freeze's my Wii on the system menu when there's a retail disc in the drive.

THis was present on ver6 beta3 and also on ver6 final

 

[Burton]

@Chop:

I have a similar problem in my 4.2 when I used priiloader 0.6 beta 3 it freezes the system menu when using block disc update hack and the hacks_hash.ini. To solve this problem I turned on the option to use old hacks style and I placed a hacks.ini for 4.2 instead of the hacks_hash.ini. I don't know if the final release still have that option.

 

[chop]

@Burton

Thanks I'll try that

 

[thesund0g]

Is this safe to install if you got preloader 0.29 installed?

Is your install of Preloader already working ok? If so, don't worry about updating; you already have [working] brick protection. Unless you see something in the changelog that you absolutely have to have, don't bother updating.

I used to update everything frequently, but my opinion has changed over the months:

IF IT AIN'T BROKE, DON'T FIX IT!

 

[DoctorWhosThat]

I have a problem installing Piiloader v0.6 something about cIOS infected or something. :/

 

[ShineStar]

I have a problem installing Piiloader v0.6 something about cIOS infected or something. :/

That's because priiloader 0.5+ removed support for Darkcorp/cioscorp

 

[DoctorWhosThat]

I'll stay put on v0.4 then.

 

[gaojiugao]

Good such a long time waitting.

 

[ShineStar]

I'll stay put on v0.4 then.

I'm in the same boat unfortunately.

 

[IronMask]

Is this safe to install if you got preloader 0.29 installed?

Is your install of Preloader already working ok? If so, don't worry about updating; you already have [working] brick protection. Unless you see something in the changelog that you absolutely have to have, don't bother updating.

I used to update everything frequently, but my opinion has changed over the months:

IF IT AIN'T BROKE, DON'T FIX IT!

Very good point indeed.

 

[XFlak]

I have a problem installing Piiloader v0.6 something about cIOS infected or something. :/

That's because priiloader 0.5+ removed support for Darkcorp/cioscorp

huh? how did priiloader ever support darkcorp?

 

[lulwut]

I have a problem installing Piiloader v0.6 something about cIOS infected or something. :/

That's because priiloader 0.5+ removed support for Darkcorp/cioscorp

huh? how did priiloader ever support darkcorp?

by not refusing it when installing on a cios/darkcrap infected ios (let alone have the B option to use cios)