Hacking Possiable ways to softmod the Wii

teq said:
I believe I'm on to something. This was found in the source of Open Wii:


CODE// 10:37 Anyway, anything above 0xD00000 isn't accessable directly from the
//ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂproc, so what you do is write to 0x40006C
//ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂand it'll mirror that address in 0x430000


Whether or not this will work with Starlet, too, I'm not certain, but my train of thought is as follows:

+Use FFCC's "main_en_us.nut" and replace it with OpenWii code.
+Execute the game via channel.
+Hopefully, it'll patch the drive.
+Exit to Wii Menu.
+Run backup game from Disc Channel or GeckoOS.

What address 0xD00000 is Erant referring to? DI on PPC or Wii DVD memory?
 
Christen said:
Darn, so many great ideas, but no one with the means to implement them.
frown.gif

Well, I'd rather not kick a dead horse.

It's most likely that the exploit Bushing came up with is a rarity, and probably took Infectus to figure out.
 
nitrotux said:
Erant is talking about the Wii DVD's CPU memory map. This is only relevant if you can already execute your own code on the Wii DVD.

I don't see why you think this is relevant for the Starlet.

I was trying to find a correlation between 0xFF being blocked in Starlet and the memory map of the G2X chip, as Starlet is the only other physical access we have to the drive.
 
Let's specify the current situation.


The DVD drive with standard firmware will not authenticate any DVD besides a GC or Wii disc.
In order to bypass that, you need to modify the DVD firmware on-the-fly, by patching the authentication check.

Modifying the DVD firmware is possible, by sending the 0xFF matshita dvd-game debug command. Then you can write anything you want to the DVD firmware's RAM.

However, sending these specific commands from Starlet or PPC is not possible because Starlet blocks these outgoing commands. It replaces command 0xFF with 0x00.

So, there are only 2 possible ways around this problem (with some luck atleast 1 will be found):
- Find an exploit in one of the DVD commands that are allowed to be sent from Starlet, which will trigger something like a buffer overflow
- Find a register which disables the Starlet block. It is possible that somewhere along the Wii bootstrap init code, it enables the command block, and can never be turned off again (unless you prevent the block enable from happening at the beginning).

EDIT: Noone has a Wii DVD firmware dump for me to take a look at? This would really help!
 
nitrotux said:
Let's specify the current situation.


The DVD drive with standard firmware will not authenticate any DVD besides a GC or Wii disc.
In order to bypass that, you need to modify the DVD firmware on-the-fly, by patching the authentication check.

Modifying the DVD firmware is possible, by sending the 0xFF matshita dvd-game debug command. Then you can write anything you want to the DVD firmware's RAM.

However, sending these specific commands from Starlet or PPC is not possible because Starlet blocks these outgoing commands. It replaces command 0xFF with 0x00.

So, there are only 2 possible ways around this problem (with some luck atleast 1 will be found):
- Find an exploit in one of the DVD commands that are allowed to be sent from Starlet, which will trigger something like a buffer overflow
- Find a register which disables the Starlet block. It is possible that somewhere along the Wii bootstrap init code, it enables the command block, and can never be turned off again (unless you prevent the block enable from happening at the beginning).

EDIT: Noone has a Wii DVD firmware dump for me to take a look at? This would really help!

It's probably hardcoded into Starlet... maybe there's another command besides 0xFF that works?
 
teq said:
It's probably hardcoded into Starlet... maybe there's another command besides 0xFF that works?
I was thinking of that, but that thought was short since i would think any other command would do the same as that. Like 0x"XX" would always go 0x00. I might not be right but thats how i think it works.
 
rishard10212 said:
teq said:
It's probably hardcoded into Starlet... maybe there's another command besides 0xFF that works?
I was thinking of that, but that thought was short since i would think any other command would do the same as that. Like 0x"XX" would always go 0x00. I might not be right but thats how i think it works.

Probably... if only we had some Japanese developers working on it... they don't have a problem with piracy.
 
if someone can find the software to dump the firmware, I'll do it... (maybe even the tutorial on how to connect the drive to the PC too)

I'm willing to try anything for the softmod to work!
 
I was about to ask the same thing rishard10212 just asked. In any case, most of them can be found online, so there's no dumping required right now. If it were specified which ones you are looking for, I could provide some links. I'm assuming it's along the lines of boot0, boot1, and IOS30.
 
nitrotux said:
Let's specify the current situation.


The DVD drive with standard firmware will not authenticate any DVD besides a GC or Wii disc.
In order to bypass that, you need to modify the DVD firmware on-the-fly, by patching the authentication check.

Modifying the DVD firmware is possible, by sending the 0xFF matshita dvd-game debug command. Then you can write anything you want to the DVD firmware's RAM.

However, sending these specific commands from Starlet or PPC is not possible because Starlet blocks these outgoing commands. It replaces command 0xFF with 0x00.

So, there are only 2 possible ways around this problem (with some luck atleast 1 will be found):
- Find an exploit in one of the DVD commands that are allowed to be sent from Starlet, which will trigger something like a buffer overflow
- Find a register which disables the Starlet block. It is possible that somewhere along the Wii bootstrap init code, it enables the command block, and can never be turned off again (unless you prevent the block enable from happening at the beginning).

EDIT: Noone has a Wii DVD firmware dump for me to take a look at? This would really help!
This is all going via the IOS right? If that's blocked try it to connect it to the PC like the Xbox... Is only necessary 1 time...
 
Forcystos said:
I was about to ask the same thing rishard10212 just asked. In any case, most of them can be found online, so there's no dumping required right now. If it were specified which ones you are looking for, I could provide some links. I'm assuming it's along the lines of boot0, boot1, and IOS30.

He's referring to the D2X chip, which is the only viable firmware the drive has.



EDIT: I believe the D2C team released a dump of the D2C a while back.
 
nitrotux said:
Let's specify the current situation.


The DVD drive with standard firmware will not authenticate any DVD besides a GC or Wii disc.
In order to bypass that, you need to modify the DVD firmware on-the-fly, by patching the authentication check.

Modifying the DVD firmware is possible, by sending the 0xFF matshita dvd-game debug command. Then you can write anything you want to the DVD firmware's RAM.

However, sending these specific commands from Starlet or PPC is not possible because Starlet blocks these outgoing commands. It replaces command 0xFF with 0x00.

So, there are only 2 possible ways around this problem (with some luck atleast 1 will be found):
- Find an exploit in one of the DVD commands that are allowed to be sent from Starlet, which will trigger something like a buffer overflow
- Find a register which disables the Starlet block. It is possible that somewhere along the Wii bootstrap init code, it enables the command block, and can never be turned off again (unless you prevent the block enable from happening at the beginning).

EDIT: Noone has a Wii DVD firmware dump for me to take a look at? This would really help!

Congratulations. I was actually able to understand all of that.

I like you, I hope you will be able to end up figuring something out.
 
nitrotux said:
EDIT: Noone has a Wii DVD firmware dump for me to take a look at? This would really help!

you should ask here (aberant's post #11)

IDA modules here and here


but the gamecube/wii drive firmware is very well known today, I don't think you will find any new exploit in there
 
why are you willing to INJECT code in a channel? or modify geckoOS? now you have full acces to PPC.. you can writte your own DISC loader...

Im sure the weaknes is in Starlet.. im looking into the IOS.. and i found DVD video "aSDiioctlVideoE --> (%s) (diIoctl) Video enable returning security error - callerUid" .. and aInitializedriv "initializeDriveRegisters"

So we have access to some drive registers... and theres a function to make the wii able to read DVDvideo (that do not have the security ring).. so we can se how the ignoring of the ring is enabled

maybe the code that filters the debug commands is in IOS... or is there a way to get the commands mirrored to the right commands..

Edit: For teq... you can not replace Dvd firmware.. what you can do is patch it on the fly.. Erants tool does it, but instead of doing it with a chip, is the computer that patches the drives ram.
 
kikekakik said:
why are you willing to INJECT code in a channel? or modify geckoOS? now you have full acces to PPC.. you can writte your own DISC loader...

Im sure the weaknes is in Starlet.. im looking into the IOS.. and i found DVD video "aSDiioctlVideoE --> (%s) (diIoctl) Video enable returning security error - callerUid" .. and aInitializedriv "initializeDriveRegisters"

So we have access to some drive registers... and theres a function to make the wii able to read DVDvideo (that do not have the security ring).. so we can se how the ignoring of the ring is enabled

maybe the code that filters the debug commands is in IOS... or is there a way to get the commands mirrored to the right commands..

Edit: For teq... you can not replace Dvd firmware.. what you can do is patch it on the fly.. Erants tool does it, but instead of doing it with a chip, is the computer that patches the drives ram.

Okay, first of all.... what the hell are you smoking?

Adding code to a channel is just as viable as adding code to an IOS, with one minor facet: It has the option of being accessed from the Wii menu and operated on the fly. In fact, modifying an IOS in any way can create unexpected results and even lead to damaging the system menu IOS, if you aren't careful.

The "DVD video" instruction was removed a long time ago.

As far as where Debug Mode is rejected, Erant already confirmed that Starlet does this via hardware security... or have you not been keeping up?

Finally, I really don't know what drugs you're on, but nobody suggested flashing the GC-D chip(which IS the only viable firmware).
 

Site & Scene News

Popular threads in this forum