Hacking Bushing's DVD Exploit (Part 2)

[teq]

If that's the case you can't just use OpenWiis commands. You will have to use the IOSs commands, but with them you could upload OpenWiis or YAOSMs (better) drivecode to the drive. And that should be it. At least for D2A/DMS/D2B, for D2C the drivecode would have to be modified, but it should also work.

Sounds like a plan... let's do it.

 

[Slowking]

There was a lot of subjunctive in my post and before bushing discloses specifics (or someone else finds it) nobody can do anything.

 

[Lazycus]

Hmmm, so am I allowed to post in this topic or does it have to be proofread by a self-proclaimed "Wii know-it-all".

The secret is in the MIOS.

 

[zant]

whoa! 2 hours and we already have a plan! lemme get this straight:

we are gonna try to replace the drive code with the YAOSM code?

I am definitely gonna keep an eye on this....


lol, bushing is watching us................. BOO!

 

[teq]

Hmmm, so am I allowed to post in this topic or does it have to be proofread by a self-proclaimed "Wii know-it-all".

The secret is in the MIOS.

MIOS you say?

And you know this how?

 

[linkinworm]

whoa! 2 hours and we already have a plan! lemme get this straight:

we are gonna try to replace the drive code with the YAOSM code?

I am definitely gonna keep an eye on this....


lol, bushing is watching us................. BOO!

dudes just intrested in the community, see if we have anything intresting, so bushing are any of us close? dont have to say what method is close, just a yes someone has it, or no your all dumb asses

 

[Jacobeian]

Hmmm, so am I allowed to post in this topic or does it have to be proofread by a self-proclaimed "Wii know-it-all".

The secret is in the MIOS.


could you elaborate ?
we'd love to know more

so MIOS could be patched in the same way as the gamecube ipl have full access to the dvd drive firmware ?
it seemed to me that this particular IOS (and BC too) were still relative unknown areas, maybe he just found something about them that could lead to what you know, seems plausible

edit: iwas searching info about IPL replacment and found this:

QUOTEThe included file "Anaconda04.S" is a full documented application source which
results in a run-able core for booting DVD-Rs. The steps it performs are as
follows:

- Initialize the diskdrive into a reset state (by setting HW register cc003024)
- Unlock the drives' debug feature by sending two special commands named
"ff 01 MATSHITA 02 00" and "ff 00 DVD-GAME 03 00"
- Sending some small codeblock into the drives' memory by using a command named
"fe 01 01 00 "
- Starting this codeblock by hooking it into a system call within the drive
resulting in the known (?) states of the bootphase of Cobra04
(laser off, motor off, delay to swap, motor on, laser on)
- Unlocking the drive by performing a ReadDiscID command (A8000040) to be able
to read sectors
- Enable audio streaming depending on the setup of the DiscID
- Reading , parsing and starting the apploader of the swapped disc , resulting
in booting the application on it

is this the way drivechips and modchip firmware worked on the cube ? could it be possible to use MIOS to unlock this "debug" feature again ?

or is is something new ? still wondering, this is damn interesting

 

[linkinworm]

Hmmm, so am I allowed to post in this topic or does it have to be proofread by a self-proclaimed "Wii know-it-all".

The secret is in the MIOS.

so its either something to do with the buffer, hashs, or the memset? yes?

EDIT sorry the buffer in the memset.

 

[teq]

Dumping MIOS doesn't give you much to work with.... but I'll poke around.

 

[zant]

good luck!

 

[linkinworm]

Dumping MIOS doesn't give you much to work with.... but I'll poke around.

you know how to dump the MIOS? details? in here or PM.

 

[nitrotux]

[...snip...]

- Initialize the diskdrive into a reset state (by setting HW register cc003024)
- Unlock the drives' debug feature by sending two special commands named
"ff 01 MATSHITA 02 00" and "ff 00 DVD-GAME 03 00"
- Sending some small codeblock into the drives' memory by using a command named
"fe 01 01 00 "
- Starting this codeblock by hooking it into a system call within the drive
resulting in the known (?) states of the bootphase of Cobra04
(laser off, motor off, delay to swap, motor on, laser on)
- Unlocking the drive by performing a ReadDiscID command (A8000040) to be able
to read sectors

As told by tmbinc in his Console Hacking 2006 presentation, he says the MATSHITA DVD-GAME still works for the Wii DVD drive, except it is lower case.
So the commands to send would be "ff 01 matshita 02 00" and "ff 00 dvd-game 03 00".

If I understood the presentation correctly, this will unlock debug mode and you can read/write the DVD drive's RAM.

You could then exploit the DVD drive by writing something to its RAM and make it authenticate any DVD.
Sending the debug commands and "exploit data" to RAM would have to go through a hacked IOS.

I've heard from the wiidev side this is not possible; Ofcourse, they might just say this to stop even more piracy.

Other possible exploits might be something really silly, like sending an A8 command to the drive with the read-back length set to something like 0xFFFFFFFF.

 

[linkinworm]

[...snip...]

- Initialize the diskdrive into a reset state (by setting HW register cc003024)
- Unlock the drives' debug feature by sending two special commands named
"ff 01 MATSHITA 02 00" and "ff 00 DVD-GAME 03 00"
- Sending some small codeblock into the drives' memory by using a command named
"fe 01 01 00 "
- Starting this codeblock by hooking it into a system call within the drive
resulting in the known (?) states of the bootphase of Cobra04
(laser off, motor off, delay to swap, motor on, laser on)
- Unlocking the drive by performing a ReadDiscID command (A8000040) to be able
to read sectors

As told by tmbinc in his Console Hacking 2006 presentation, he says the MATSHITA DVD-GAME still works for the Wii DVD drive, except it is lower case.
So the commands to send would be "ff 01 matshita 02 00" and "ff 00 dvd-game 03 00".

If I understood the presentation correctly, this will unlock debug mode and you can read/write the DVD drive's RAM.

You could then exploit the DVD drive by writing something to its RAM and make it authenticate any DVD.
Sending the debug commands and "exploit data" to RAM would have to go through a hacked IOS.

I've heard from the wiidev side this is not possible; Ofcourse, they might just say this to stop even more piracy.

Other possible exploits might be something really silly, like sending an A8 command to the drive with the read-back length set to something like 0xFFFFFFFF.

i thought the wii read from a offset for the 1st sector, 0x8000000, or something like that

 

[teq]

<!--quoteo(post=1280908:date=Jul 17 2008, 06:51 PM:name=linkinworm)--><div class='quotetop'>QUOTE(linkinworm @ Jul 17 2008, 06:51 PM) <a href="index.php?act=findpost&pid=1280908"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec--><!--quoteo(post=1280878:date=Jul 18 2008, 02:41 AM:name=teq)--><div class='quotetop'>QUOTE(teq @ Jul 18 2008, 02:41 AM) <a href="index.php?act=findpost&pid=1280878"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Dumping MIOS doesn't give you much to work with.... but I'll poke around.<!--QuoteEnd--></div><!--QuoteEEnd-->
you know how to dump the MIOS? details? in here or PM.
<!--QuoteEnd--></div><!--QuoteEEnd-->

Well, you can dump the FS, where parts interface with BC. Some files are labeled MIOS.


Here's the dvd driver: <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->FatalError....initDvdDriverStage2.commandResultToIoctlReturn..commandResultToIoc
lReturn..setupRunOpenPartTmdTicketOrView.setupRunOpenPartition...setupRunGetNoDi
cBufferSizes....setupRunGetNoDiscOpenParams.setupRunGetNoDiscOpenParams.setupRun
oDiscOpenPartition.setupRunNoDiscOpenPartition.ÂÂ..ÂÂ.~ÂÂ.~ÂÂ.~ÂÂ.~ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ.rDiIoctl.
..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ.vÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..ÂÂ..dvd_driver..(%s)
Fatal error in DI driver: %s.Exiting...(%s) Can't register to handle IOS_EVENT_DI..Permission denied...
Invalid event or queue..Unknown error...(%s) (%s) Unhandled command result is: 0x%x.....
commandResultToIoctlReturn: Default case reached....(%s) Driver calling clearDriveErrorInterupt on own..
(DiIoctlVec) Outer default case reached.(%s) (%s) Vector counts are incorrect...(%s) (%s) Vector size is incorrect..
(%s) (%s) Misaligned input parameter....IOCTLV CMD MISMATCH.(%s) (%s) Vector #%d is NULL....(%s)
Note: IOCTL command (0x%x) doesn't match block command (0x%x)..(%s) Note: This is normal for DVD software before 6-24..(%s)
(DiIoctl) Size of input (%u) != size of diCommand_t; command =0x%x.....(%s) (diIoctl) ioctlMesg->cmd is DI_READ_CMD....(%s)
(diIoctl) command->theCommand is DI_READ_CMD...(%s) OPEN_PARTITION done through Ioctlv, not Ioctl..(%s) (diIoctl)
Video enable returning security error - callerUid = %u; inLen = %u...(%s) Driver's call to clear error FAILED!...18:17:09....
JunÂÂ8 2007.###! Starting DI driver (built %s %s).../dev/di.(%s) ERROR: Unknown message type (0x%x) received....
DI: Stack overrun!..Receiving message on DVD in queue failed....Can't create DVD resource manager queue.
Can't register DVD resource mananger....Can't allocate space for dvd resource manager queue.....
Can't create command timeout timer..Can't create DVD transaction queue..Can't allocate space for dvd transaction queue..
IOS_CreateHeap failed for protected heap....IOS_CreateHeap failed for open heap.dvdMemFree returned an error....(dvdOpenFree)
IOS_Free returned value %d....(dvdOpenFree) IOS_Free returned an [email protected]...............~...........clearQueue..checkStateB
foreTransaction.startSleep..startSleep..initializeDriveRegisters....handleDiComm
nd.handleDiCommand.ÂÂ.,ÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.
VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ
.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ
.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ..ÂÂ.hÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.bÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.JÂÂ.<ÂÂ..ÂÂ..ÂÂ..ÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ..ÂÂ..ÂÂ.
zÂÂ.dÂÂ.VÂÂ.VÂÂ.XÂÂ.LÂÂ.>ÂÂ.8ÂÂ.2ÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ..ÂÂ.VÂÂ.VÂÂ.VÂÂ.zÂÂ.VÂÂ.VÂÂ..ÂÂ.VÂÂ
.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ..ÂÂ..ÂÂ.|ÂÂ
.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ.VÂÂ..ÂÂ.TÂÂ.LÂÂ.DÂÂ..ÂÂ.VÂÂ..ÂÂ.rÂÂ.JÂÂ..ÂÂ..ÂÂ..doWaitForCoverClose.doWaitForCoverClose.(%s) (clearQueue)
IOS_ReceiveMessage returned %d....(%s) Error interrupt mask and interrupt are off - correcting....(checkState...)
Can't clear TC interrupt bit....(%s) ERROR: TC intr mask off - fixing...(checkState...) Can't enable TC interrupt mask..(checkState...)
Error interrupt mask and interrupt are on...(%s) (%s) - message on sleep queue isn't the sleep expired message..(startSleep)
Stopping sleep timer failed....(%s) IOS_RestartTimer failed: %d....(startSleep) Restarting sleep timer failed..(startSleep)
receiveMessage(#2) failed..(startSleep) receiveMessage(#1) failed..(%s) **** Error interrupt cannot be cleared after reset ****....(%s)
***** Trans complete interrupt cannot be cleared after reset ****..Error: Transfer started, but TC INTR is off.....(startTimedTransfer)
Stopping commandTimeoutId timer failed.(startTimedTransfer) Restarting timer failed....(%s)
Unknown drive command '0x%x' encountered in handleDiCommand....(%s) !!!!! (%s) Unhandled message case (message = 0x%x)....
.(handleDiCommand) Found GAMECUBE or other disk..(%s) DI_SET_SPINUP_FLAG_CMD should have been executed in the PPC shim layer only...
.Should have been handled in DiIoctl!....(writeDIDmaDestAddr) Writing non-32 byte aligned address to DMA dest register - exiting.....
(handleDiCommand) Receiving message on DVD in queue failed..(handleDiCommand) Found REVOLUTION disk.....(handleDiCommand)
IOS_StopTimer(2) failed...(%s) DI_READ_DISK_ID_CMD given non-32 aligned ptr...(%s) DI_READ_CMD given non-32 aligned ptr...(%s)
Trying to read a non-multiple of 32 bytes..(handleDiCommand) IOS_StopTimer(1) failed...(%s) Read Disk ID called while in reset.(%s) (%s)
Received unknown message type %d..unhandled timer errorId.thread cannot access message queue..invalid message queue...
no more IOS timers left.Can't allocate space for dvd sleep queue....Can't create DVD sleep queue....Can't create sleep timer....
@@@@@@@@@@@@ Stack overflow error @@@@@@@@@@@@@@ ...Stack overflow value: 0x%x..(initStack)
Coding error: Stack looks overrun, but isn't....Current stack usage: %d bytes/%dK bytes.....
Maximum stack usage: %d bytes/%dK bytes.....%02x.......................................................................
.rvlRe
dInitialize...doBlockRead.doReadHashEncryptedState....readPartition...readTmd.re
dAndVerifyH3Hashes...dupToSharedAligned..ES_DiVerifyWrapper..commonOpenPartition
checkOpenPartInitConditions.getNoDiscBufferSizes....getNoDiscBufferSizes....getN
DiscOpenParams.getNoDiscOpenParams.noDiscOpenPartition.noDiscOpenPartition.(%s) #### (RvlReadInitialize)
diskReadBuffer isn't NULL - it should be..Can't allocate diskReadBuffer...(%s) RvlReadInitialize called more than once - ignoring.....(%s)
Allocating %u bytes from the shared region failed......Allocation failed...Address of array to be hashed is not 64 byte aligned....
Number of bytes to be hashed must be >= 64..First call to IOSC_GenerateHash not a multiple of 64)...
(AESdecryptHW) input array length must be multiple of 16....(AESdecryptHw) Decrypt array address is not 16 byte aligned.
Input to AES is not 32 bytes aligned....(AESdecrypt) HW decrypt returned false..(%s) Data subblock %d failed to verify against H0 Hash..
Data failed to verify against H0 Hash...(%s) H2 Hashes failed to verify.....H2 Hashes failed to verify..(doBlockRead) diskReadBuffer is NULL....(%s)
H1 Hashes failed to verify.....H1 Hashes failed to verify..(%s) H0 Hashes failed to verify.....
H0 Hashes failed to verify..'data' element of globalBlockCache is not aligned...doNonConformingDiskRead: memory allocation failed...
(dRHES) Encryption is: . ON.....(dRHES) Hashing is: .... OFF....(%s) disk read failed...Alloction of diskInfo failed....(%s)
Error - freeing partition and returning NULL...(%s) ERROR - Disk read error when reading partition.....(%s)
ERROR - the offset to the TMD on disk is 0.....(%s) ERROR - the offset to the certs on disk is 0...Alloction of partition structure failed.(%s)
Error - freeing tmd and returning NULL.....(%s) ERROR - Allocating %u bytes for the TMD failed.....(readH3Hashes) diskReadBuffer is NULL...(%s)
DI Error: encrypted area is not 32K aligned....(%s)ÂÂÂÂÂÂÂÂÂÂ partition offset = 0x%x, encrypted offset = 0x%x, total offset = 0x%x....(%s)
Error: diskInfo encrypt is on, but disk image is not encrypted.....(%s) Verifying H3 hashes against H4 hash failed.....
Verifying H3 hashes against H4 hash failed..One and only one of ticket and ticket view should be NULL...Freeing shared ticket view failed...
E-ticket services initialize failed.....Freeing shared hash failed..Freeing shared title key failed.Freeing shared tmd failed...
Freeing shared certs failed.(%s) Allocating %u bytes from the protected region failed...Freeing shared ticket failed....Code botch!.....(%s)
openPartition called before readDiskId.....(%s) Error: diskInfo encrypt is off, but disk image is encrypted....(%s) openPartition called with partition open...(%s)
ES_DiVerify failed: code is: %d....(%s) TMD not supplied for disc/nand game....certBlob memory alignment failure...(openPartition)
rvlReadInitialize wasn't called.....(%s) %s called before readDiskId....(getNoDiscBufferSizes) rvlReadInitialize wasn't called..(%s)
Hash array size: %u....(%s) %s: dataWordOffset is not 32K aligned..IOSC_DeleteObject did not return IOS_ERROR_OK......T....
$IOSVersion: DIP: 06/08/07 18:17:09 64M $...main....%s..(%s) ****** This should never be printed *******....(null)..(nil)...ÂÂ:.ÂÂ
:@ÂÂ:@ÂÂ:@ÂÂ:@ÂÂ:@ÂÂ:@ÂÂ:0ÂÂ:.ÂÂ:@ÂÂ:$ÂÂ:@ÂÂ:@ÂÂ:*;.ÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ:.ÂÂ<.ÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ=rÂÂ
=rÂÂ=r;.ÂÂ=rÂÂ=rÂÂ:.ÂÂ=rÂÂ<.ÂÂ=rÂÂ=r;./dev/es................*....................ÂÂ.@<!--c2--></div><!--ec2-->

 

[abort_user]

theres no way nintendo is going to take this lying down. good news though.

im still glad im getting a modchip though. because as i said. nintendo will bump back much harder than they did against homebrew.

 

[nitrotux]

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:
CODEstatic 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

 

[ProdigySim]

Nitrotux, sometimes I think you're smart, then you go and do stuff like this.

That function, DVD_LowUnlockDrive, comes from dvd.c. DVD.c is part of the Gamecube portion of libogc.

You didn't tell us anything. That code doesn't do anything for us. You sound like you don't understand how any of this works. Seriously.

That code runs on PPC on the gamecube, using gamecube registers, and access to the DVD via ppc.

On the Wii, it's done through the starlet, ARM, IOS, and we don't even know what the interface is able to do or what it is like. That Code in libogc has NOTHING to do with the Wii! It's almost completely irrelevant. You haven't discovered anything.


Also, your statement in red is basically a description of what mod-chips do. And did on the gamecube. You're a few years too late.

 

[nitrotux]

The libOGC code runs from gamecube and is using gamecube registers. You are 100% correct.

However, you are unaware that this same code can be run in IOS, in ARM code.
Yes, the register base for DI is different, but you can easily find this when you disassemble the DI part in IOS21 for example.

The DI interface is EXACTLY the same as on gamecube, except it's now mapped to Starlet.

I think you're part of the nice "wiidev" crew who wants this "bug" never to be found

.

 

[ProdigySim]

The DI interface is EXACTLY the same as on gamecube, except it's now mapped to Starlet.

I think you're part of the nice "wiidev" crew who wants this "bug" never to be found

.

What makes you so sure it's "exactly the same?"

And I'm the one who posted that this was the correct method a few pages back that started teq and you looking into it.

 

[nitrotux]

I have disassembled the routines IOS does to send commands and read/write status/irq bits.

They are a very good match with what is in libogc.

But you only need to know how to send commands... because that's the only thing needed.