Hacking Possible alternative to hacking 4.0

[fogbank]

Here is what I did:

SystemMenu 3.3Uv1 (so IOS30 is trucha patched).

No previous IOS16 on the system.

I obtained IOS16 v512 using NUS Downloader v1.1 and packed it into a WAD. Installed that:

Title=1-10 (IOS16) vers: 2.0 (512)

Using Sorg's modified WAD Manager 1.4 I attempted to install IOS16 v257 using IOS30 and got an error (-1035).

Using Nicksasa's FSToolbox I dumped the TMD from 0000000100000010 to my SD card.

Using a hex editor I changed the value at 0x1DC in the TMD to x0001.

With FSToolbox I wrote the modified TMD to the NAND:

Title=1-10 (IOS16) vers: 0.1 (1)

Using Sorg's modified WAD Manager 1.4 I attempted to install IOS16 v257 using IOS30. Success:

Title=1-10 (IOS16) vers: 1.1 (257)

This means I was able to successfully install IOS16 v257 on a system that already had IOS16 v512 using a trucha patched IOS.

I have no idea if this would work on a virgin 4.0 Wii, but it may be worth a try. Also since the LU64+ Wii's don't seem to have any trouble using IOS16 v257 this may be a way to install cIOS 4.0 systems without using the DVDX installer.

 

[KiiWii]

Nice work!

Any volunteers to test on a virgin 4.0?

 

[xTimmy]

Nice work!

Any volunteers to test on a virgin 4.0?

i would volunteer, but, it will have to wait until i get my fiancee a wii

 

[Deleted-171178]

I thought this was done before?

 

[sorgelig]

fogbank,
to install anything not from nintendo, you have to sign. Since you don't have nintendo's key to sign, you have to fool Wii by profiding trucha signature. In other words, there should be at least one IOS in system having trucha bug. Virgin 4.0 has no such IOS.

You need to dig inside wii more seriously than just move around known vulnerabilities. Do you really think that people with big experience who discovered vulnerabilities couldn't guess to what you did?

 

[chunan]

LU64+ can't use FSToolbox as it can't dump files from the nand to sd card

 

[fogbank]

fogbank,
to install anything not from nintendo, you have to sign. Since you don't have nintendo's key to sign, you have to fool Wii by profiding trucha signature. In other words, there should be at least one IOS in system having trucha bug. Virgin 4.0 has no such IOS.

You need to dig inside wii more seriously than just move around known vulnerabilities. Do you really think that people with big experience who discovered vulnerabilities couldn't guess to what you did?

IOS16 v257 is signed by Nintendo.

Comex's DVDX installer uses a similar mechanism to downgrade IOS35 (at least according to the available info).

I know plenty about how the Wii security works, thank you.

 

[fogbank]

LU64+ can't use FSToolbox as it can't dump files from the nand to sd card

In his post about his release, Nicksasa said FSToolbox should work with newer IOS versions. It's possible that it doesn't, and that was the one thing I could of think that would stop this from working

Also the real limitation would be writing to the NAND with FSToolbox, because you don't really need to dump the IOS16 TMD from the NAND on the Wii your working with.

 

[WiiPower]

I don't see much chances for this, FSToolbox requires a trucha IOS to write to nand. And that's not available on 4.0 and on 3.4 there's no IOS16. WiiGator's cBoot2 works from BootMii IOS and runs IOS without the need to install. And i heard that the next version of BootMii will allow to install BootMii IOS on Lu64+ Wiis.

 

[fogbank]

I don't see much chances for this, FSToolbox requires a trucha IOS to write to nand.

That's what I was unsure of. I imagine you are correct, but...

A trucha IOS is required to install fakesigned content to the NAND, but FSToolbox seems to be writing single files directly to the NAND, not using ES_AddContent calls (or is it?):

QUOTE(nicksasa @ May 22 2009, 01:56 PM) i dont use ES functions and not /dev/flash so it should work
i just use IOS_Open(path, ISFS_OPEN_RW); etc

When I write the modified TMD to the NAND it is not fakesigned, so where is the trucha bug being exploited in this scenario?

I would think that maybe the IOS_Open calls have been secured in 3.4/4.0, so FSToolbox would not work...?

 

[WiiPower]

It's worth a test on the new Wiis, but i expect from nintendo that they don't allow anybody to write to nand. And also i think Nicksasa's tool uses a Identify as SU, which requires trucha and ES_Identify which are both patched.

 

[fogbank]

It's worth a test on the new Wiis, but i expect from nintendo that they don't allow anybody to write to nand. And also i think Nicksasa's tool uses a Identify as SU, which requires trucha and ES_Identify which are both patched.

I expect you are right. Nicksasa stated that he didn't use ES functions, but the first output from his tool is "Informing the Wii that I am God..." (a la ATD), so I think that means he built on functions that already used ES_Identify to identify as SU.

I have a 3.4U Wii boxed up in storage, so I may give it a try when I have some time to break it out, but I suspect it won't work

Thanks for the input.

 

[ether2802]

you really need to test this on a 4.0 just to be sure it will work or not, cause guessing it is not really a good way to solve the thing out...!!

 

[WiiPower]

I still see the best chance at cBoot2 as it does not touch any installed IOS except BootMii IOS if BootMii could not be installed as boot2.

 

[sorgelig]

i just use IOS_Open(path, ISFS_OPEN_RW); etc

oh yeah.. try this and see how it will work and how many files you will able access even for just read.

Do u think, application working with NAND require super user authentification just for fun?

Take FSBrowser. This is good example of access rights. Try to authentificate as system menu and then as super user. See difference.

It's not a signing bug vilnerability, but it also have been fixed.
If you will try to athentificate as SU with CIOS then you will succeed. But if you will try it with for example IOS61, then you will fail.

 

[fogbank]

It's not a signing bug vilnerability, but it also have been fixed.
If you will try to athentificate as SU with CIOS then you will succeed. But if you will try it with for example IOS61, then you will fail.

Agreed. There is still an exploit out there that can accomplish this (used by Comex's DVDX installer), but the method I described would likely fail without being able to authenticate as SU.

Sounds like cboot2 may be a more viable solution anyway.

 

[sorgelig]

as far as i know lu64+ are too new to have vilnerable boot1. So, you will not able to install bootmii (and its modifications) as boot2.
to install it as IOS, you again have to use SU authentification.
I don't know if dvdx has something special to be able installed.. If so, then there is a chance.

Another problem for lu64+ is inability to run most homebrew. Screen goes black and nobody including bushing know whay it happens.

 

[WiiPower]

http://forum.wiibrew.org/read.php?25,16808
2nd post, it's about IOS not boot2 installation i guess.

 

[fogbank]

as far as i know lu64+ are too new to have vilnerable boot1. So, you will not able to install bootmii (and its modifications) as boot2.
to install it as IOS, you again have to use SU authentification.
I don't know if dvdx has something special to be able installed.. If so, then there is a chance.

I agree that LU64+ probably all have the newer boot1, however both the HBC/HackMii team and Comex must have another exploit at their disposal because they both seem to be able to add to or modify content on the NAND even on systems with the ES_Identify bug patched (3.4 and higher). Like I mentioned earlier, Comex's DVDX installer can modify IOS35 on 3.4 and 4.0 systems with no existing cIOS, and the HackMii installer can add HBC, BootMii as IOS, and DVDX on virgin 3.4/4.0 systems as well. I think the chances of this exploit being made public any time soon are "slim-to-none", but that is understandable.

My hope was that somehow Nicksasa's app used this exploit to read/write to the NAND (that's why I asked him if he used ES_Identify) but obviously I was wrong and he didn't realize that he was using it.

 

[chunan]

My hope was that somehow Nicksasa's app used this exploit to read/write to the NAND (that's why I asked him if he used ES_Identify) but obviously I was wrong and he didn't realize that he was using it.

I dont know if FSToolbox uses ES_Identify, but I got Error! ES_Identify (ret=-1017) once I load it on my LU64+.