Hacking Possiable ways to softmod the Wii

[hjfbv1]

wow, looks like all that ffccmlaak hacking could prove usefull in more ways than moding chime, or did you move to a diffrent method of loading?

 

[teq]

wow, looks like all that ffccmlaak hacking could prove usefull in more ways than moding chime, or did you move to a diffrent method of loading?

No, it still seems about the best/easiest way, as it requires very little reverse engineering for a great payout.

 

[killplaystation]

I was reading the last thread, and the idea that nitrotux had about re-writing the firmware of the drive. I know this can be done on the 360, but that's because it has an actual PC interface (IDE)... since the Wii doesn't have that, we have to make a work around.

THe 360 drive uses SATA

 

[denzil]

As Erant said before, probably in one of the "lost" threads: the necessary debug commands will not reach the drive, but get blocked by some yet unknown mechanism in Hollywood.

Perhaps not Hollywood, but IOS?
I am not going to pass off other people's findings as my own, so read his answer for yourself. As for whether IOS or Hollywood, I am quite certain I remember him saying in a recent conversation, that it is indeed Hollywood, but I am not absolutely certain.

QUOTE

The modified IOS released patches /dev/di to /dev/do, presumably so that Starlet doesn't impose the limit on DVDUnencryptedRead.

No, this is just a weird and unneccessary "failsafe" nitrotux put in, presumably so one can tell a patched IOS5 from a "real one".

 

[zidane_genome]

Ok, I'm trying to reverse GeckoOS, trying to get some viable source code or something... not looking too good...

What about, instead of injecting the fake sig into GeckoOS, can't we just toss it into an IOS? Even with Hollywood... Getting Gamecube backups working would be a step in the right direction...

 

[denzil]

Ok, I'm trying to reverse GeckoOS, trying to get some viable source code or something...
Why bother? You don't need to reverse anything to try to send the necessary debug commands.

QUOTEWhat about, instead of injecting the fake sig into GeckoOS, can't we just toss it into an IOS? Even with Hollywood... Getting Gamecube backups working would be a step in the right direction...

I quote Erant again, and I sincerely hope you understand the consequences of this one sentence: "Issuing an 0xFF or a 0xFE command from the starlet (or the PPC, with the Starlet in DI legacy mode, for that matter), will actually send a very nice 0x00 command, which is gibberish to the drive."

To put it in even more direct words: Even directly from IOS, or in Gamecube mode, debug commands will not reach the drive. They get blocked by a yet unknown mechanism inside Hollywood. So unless someone reverse engineers the Hollywood hardware and finds a way around that, it is quite moot to discuss the possibility of inserting patch code into the drive using debug commands. Sorry.

 

[harrybuttox]

There's only one problem with all of this: Implementing this via homebrew will be hard to do, as IOS reloads after any homebrew is exited.

But, don't fret! Because I have an alternative: Final Fantasy CC: MLaaK. The entire game is written in uncompiled C.

This provides an entrypoint that should allow the D2x to retain memory.

teq, but can't the new custom IOS be modified to cut the reloading?

 

[teq]

To put it in even more direct words: Even directly from IOS, or in Gamecube mode, debug commands will not reach the drive. They get blocked by a yet unknown mechanism inside Hollywood. So unless someone reverse engineers the Hollywood hardware and finds a way around that, it is quite moot to discuss the possibility of inserting patch code into the drive using debug commands. Sorry.

It's my understanding that Starlet is a key component of Hollywood, instead of a seperate entity. Just so we're on the same page, Erant's reference to "Hollywood" was probably more specifically implied to be "Starlet". This only helps take away one level of abstraction, because we know we aren't dealing with an unknown entity.

I'm assuming Erant had a method of reading data coming from Starlet or being recieved by the drive, but the question is which.

If it's Starlet, then that should mean we can intervene via IOS. If it's the drive, then it's probably that the drive controller has mapped these registers to a NOP(which would return 0x00, equally).

QUOTEteq, but can't the new custom IOS be modified to cut the reloading?

Probably, but considering every method of using homebrew causes the system to restart after, it would be more convinient to deal with something native to the Wii.

 

[Dack]

I'd be interested in finding out how the newer mod chips work - as they seem to use a different mechanism for enabling the read of DVD-R and don't connect to the same pins as the older chips. This would seem to imply there is another backdoor into the chip.

 

[teq]

I'd be interested in finding out how the newer mod chips work - as they seem to use a different mechanism for enabling the read of DVD-R and don't connect to the same pins as the older chips. This would seem to imply there is another backdoor into the chip.

There's a common set of pins that are identical for all drivechips. Additional ones are added to accomodate for power/grounding requirements and add extra features.

 

[denzil]

If it's Starlet, then that should mean we can intervene via IOS.

Sorry to be blunt here, but which part of "Issuing an 0xFF or a 0xFE command from the starlet [does not work]" eludes you? This is the IOS itself issuing the command, and it is getting blocked. How can you possibly influence something with a modified IOS that the IOS cannot do itself in the first place?

You, as well as everyone else, seem to cling on to the idea of a magical patch to IOS that will issue or enable debug commands. Erant already tried that, and it doesn't work.

 

[teq]

If it's Starlet, then that should mean we can intervene via IOS.

Sorry to be blunt here, but which part of "Issuing an 0xFF or a 0xFE command from the starlet [does not work]" eludes you? This is the IOS itself issuing the command, and it is getting blocked. How can you possibly influence something with a modified IOS that the IOS cannot do itself in the first place?

You, as well as everyone else, seem to cling on to the idea of a magical patch to IOS that will issue or enable debug commands. Erant already tried that, and it doesn't work.

Starlet is an entire SoC, programmable to the extent that it could possibly run an operating system like Linux. If some registers are static, it has to do with either security or IOS, because I believe Starlet starts out a blank slate.

I don't claim that IOS is the answer, but there are certainly other core components of the entire boot process that could influence Starlet, many of which become more accessible the more we know about IOS.

 

[Dack]

I'd be interested in finding out how the newer mod chips work - as they seem to use a different mechanism for enabling the read of DVD-R and don't connect to the same pins as the older chips. This would seem to imply there is another backdoor into the chip.

There's a common set of pins that are identical for all drivechips. Additional ones are added to accomodate for power/grounding requirements and add extra features.

Not for the Wasabi etc. They connect using a different set of pins to the norm - thats why you don't need to grind back the legs on the IC for a cut legs D2B. It's still only 5 wires on it but on different pins.

 

[teq]

Not for the Wasabi etc. They connect using a different set of pins to the norm - thats why you don't need to grind back the legs on the IC for a cut legs D2B. It's still only 5 wires on it but on different pins.

Hm... maybe they found that there are more I/O pins...

 

[Erant]

I'm assuming Erant had a method of reading data coming from Starlet or being recieved by the drive, but the question is which.

Starlet puts 0xFF000000 into it's 0x0D006008 register, sends the command, and gibberish arrives at the drive. All the drive ever sees is 0x00 arriving. This is a protection in HARDWARE. You cannot unlock this, or remove it in any way. You can't "h4x0r" out a check or anything, this is silicon security.

In VHDL:

if(DI_COMMAND = x"FF") THEN
DI_COMMAND

 

[teq]

Starlet puts 0xFF000000 into it's 0x0D006008 register, sends the command, and gibberish arrives at the drive. All the drive ever sees is 0x00 arriving. This is a protection in HARDWARE. You cannot unlock this, or remove it in any way. You can't "h4x0r" out a check or anything, this is silicon security.

In VHDL:

if(DI_COMMAND = x"FF") THEN
DI_COMMAND

 

[arctic_flame]

Not for the Wasabi etc. They connect using a different set of pins to the norm - thats why you don't need to grind back the legs on the IC for a cut legs D2B. It's still only 5 wires on it but on different pins.

Hm... maybe they found that there are more I/O pins...

That's exactly what they did.

Why is the drive security so poor...

 

[night_chrono]

QUOTE(nitrotux @ Jul 18 2008, 01:30 PM) *
OK, someone with some authority on Wii hacking (sorry, I promised not to say who) recently confirmed the debug command theory.

I don't know how to say it so that everyone understands, but here goes:



THE KEY TO PLAYING BACKUPS WITHOUT DRIVECHIP IS BY UPLOADING YOUR OWN EXPLOIT CODE INTO THE DVD FIRMWARE BY SENDING THE DEBUG COMMANDS.


If you take a look at libOGC, at the function DVD_LowUnlockDrive, this is how to put the drive into debug mode:
CODE
static u8 __dvd_unlockcmd$221[12] = {0xff,0x01,'m','a','t','s','h','i','t','a',0x02,0x00};
static u8 __dvd_unlockcmd$222[12] = {0xff,0x00,'d','v','d','-','g','a','m','e',0x03,0x00};

s32 DVD_LowUnlockDrive(dvdcallbacklow cb)
{
#ifdef _DVD_DEBUG
printf("DVD_LowUnlockDrive()\n");
#endif
u32 i;

__dvd_callback = __dvd_unlockdrivecb;
__dvd_finalunlockcb = cb;
__dvd_stopnextint = 0;

for(i=0;i

 

[podunk1269]

QUOTE(nitrotux @ Jul 18 2008, 01:30 PM) *
OK, someone with some authority on Wii hacking (sorry, I promised not to say who) recently confirmed the debug command theory.

I don't know how to say it so that everyone understands, but here goes:



THE KEY TO PLAYING BACKUPS WITHOUT DRIVECHIP IS BY UPLOADING YOUR OWN EXPLOIT CODE INTO THE DVD FIRMWARE BY SENDING THE DEBUG COMMANDS.


If you take a look at libOGC, at the function DVD_LowUnlockDrive, this is how to put the drive into debug mode:
CODE
static u8 __dvd_unlockcmd$221[12] = {0xff,0x01,'m','a','t','s','h','i','t','a',0x02,0x00};
static u8 __dvd_unlockcmd$222[12] = {0xff,0x00,'d','v','d','-','g','a','m','e',0x03,0x00};

s32 DVD_LowUnlockDrive(dvdcallbacklow cb)
{
#ifdef _DVD_DEBUG
printf("DVD_LowUnlockDrive()\n");
#endif
u32 i;

__dvd_callback = __dvd_unlockdrivecb;
__dvd_finalunlockcb = cb;
__dvd_stopnextint = 0;

for(i=0;i

 

[Christen]

This is basically useless anyways until someone compiles it into something that's useful for a person without advanced coding knowledge.