rvthtool: An Introduction

rvthtool: An Introduction

In January 2018, while browsing eBay, I saw two listings for Nintendo devkits: an RVT-R Reader, and an RVT-H Reader. On a whim, I decided to buy them. Searching around for information on how to use the RVT-H Reader, I found some posts on ASSEMbler Games that indicated the RVT-H Reader used a proprietary encryption that no one had been able to crack. As I soon found out, this was not the case.

On receiving the RVT-H Reader, the first thing I did was a full disk image backup using the ddrescue utility. This particular unit has an 80 GB HDD (early models came with 40 GB), but since the RVT-H Reader usually only allows for eight 4.4 GiB disk banks, only ~35.2 GiB is used. (I suspect the 40 GB HDD they were using went out of production, and the 80 GB model was used as a substitute.)

A word of advice: If connecting an RVT-H Reader to a Windows computer, make sure Windows does *not* try to “initialize” it. Doing so can overwrite data on the HDD. This won’t brick the system, but it could destroy prototypes.

Windows Disk Management attempting to create a new MBR or GPT on a Nintendo RVT-H Reader.
No. Bad Windows. Don’t wipe my fancy Wii devkit’s hard drive because you don’t recognize it. Perhaps this is why people thought it was “super encrypted”?

I decided to load up Nintendo’s official rvtwriter program to see how it handled the drive. (These screenshots were taken with the RVT-H Reader’s original disk image.)

rvtwriter showing information about my RVT-H Reader.
This RVT-H Reader has four occupied banks. Green indicates it’s actually two dual-layer Wii images. (GameCube images would be cyan; single-layer Wii images would be blue.)
rvtwriter listing bank information from my RVT-H Reader.
Same bank listing, but now with the actual title and modification timestamps.

rvtwriter doesn’t appear to have any way to extract an image from a console, though it can definitely read what’s on the HDD, since it shows the titles and has a verify function.

On examining the HDD contents, I found the bank table at $60000000, followed by disc images. One disc image (a copy of “The Last Story” JP final, debug-signed) was encrypted using the debug common key used by RVT-R Readers (and also RVT-H and NDEV). The other two disc images (two PAL localization protos of “The Last Story”) were not encrypted at all, but *were* debug-signed. This is apparently supported by development units and is used by the NDEV’s optical disc emulator to reduce overhead. Support for unencrypted disc images was added to the Dolphin Emulator in May 2018.

After manually extracting disc images from my RVT-H Reader, I started writing a program to automate this task, as well as importing new disc images (with automatic re-signing to convert retail games to dev-signed) and undeleting disc images that were “deleted” from the system. rvthtool was initially only a command-line tool, but after the release of v1.1.1, I started writing a Qt-based GUI. That GUI is almost ready for prime-time and v2.0 will be released sometime “soon”.

qrvthtool showing my RVT-H Reader, which has been modified to have 14 banks instead of the usual 8.
My RVT-H Reader. Banks 2/3 and 4/5 were originally present on this system, and bank 8 was undeleted. The rest of the disc images were imported onto the system using rvthtool.

You might notice the RVT-H Reader shown above has 14 banks, instead of the usual 8 banks. The RVT-H Reader’s ODEM is actually quite flexible and has a value indicating the total number of banks, which can be adjusted. More on this in a later post.


Leave a Reply

Your email address will not be published.

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.