ROM Hack Dumping ROMs with R4i SaveDongle

[Kyohack]

I'd like to point out that the R4i SaveDongle has ROM dumping potential. It reads the ROM title from a game cart, and displays this as the "Game Info". With some research into the USB protocol that the SaveDongle uses, I believe it may be possible to dump the entire ROM. So far, I have grabbed a program called USBTrace, and I have made a small capture of the USB transmissions to the SaveDongle device. In this capture, I have located the unecrypted ROM title that I mentioned earlier:

Spoiler

I just wanted to point this out. I have absolutely no experience replaying USB traffic (in fact, this was the first time I've recorded any USB traffic), so don't expect any ROM dumping programs from me. Perhaps another member who is more knowledgeable about USB traffic, can look into this.


EDIT:
Here's how I set up the USB traffic dump:

Spoiler

1. I opened device manager, and began disabling USB devices until the save dumping software said that the dongle was disconnected.
2. I viewed the properties of the disabled USB device, and grabbed its hardware ID, which was: USB\VID_04D8&PID_003F&REV_0002.
3. I Re-enabled the USB device.
4. Then I opened USBTrace, and looked for a USB device with the same hardware ID. After that, I clicked "Start Capture".

EDIT2:
So far, I've been able to modify elisherer's source code to dump ROM headers, instead of save data. I simply changed lines 31 and 32 of the R4ISaveDonlge.cs file to:

private static readonly byte[] Get512Bytes = { 0x22, 0x22, 0x00, 0, 0, 0, 0, 0, 0, 0, 0 };
private const byte Get512Response = 8;

 

[signz]

Hm, would be kinda cool if the dongle could dump ROMs (like the neoflash SMS4 or something).

 

[kerneldev]

Nice! I was about to post a new topic on this one. Indeed, it can dump *anything* from the cartridge. I have decompiled the .NET tool and looked at the managed code (it has native code components).
For example this is the initialization routine for the reader:

_SP_DEVICE_INTERFACE_DATA* ptr = .@new(28u);
uint num = 0;
uint num2 = 0;
string text = "Vid_04d8&Pid_003F";
void* deviceInfoSet = .SetupDiGetClassDevsUM(&gUID, null, null, 18);
*(int*)ptr = 28;
if (.SetupDiEnumDeviceInterfacesUM(deviceInfoSet, null, &gUID, 0, ptr) != 0)
{
while (259 != Marshal.GetLastWin32Error())
{
_SP_DEVINFO_DATA sP_DEVINFO_DATA = 28;
.SetupDiEnumDeviceInfoUM(deviceInfoSet, num, &sP_DEVINFO_DATA);
uint num3;
uint num4;
.SetupDiGetDeviceRegistryPropertyUM(deviceInfoSet, &sP_DEVINFO_DATA, 1, &num3, null, 0, &num4);
byte* ptr2 = .malloc(num4);
if (ptr2 == null)
{
.SetupDiDestroyDeviceInfoListUM(deviceInfoSet);
this.listBox1.Items.Clear();
this.label_size.Text = "GAME SAVE SIZE:	";
this.label_info.Text = "GAME INFO:	";
this.button_pc_to_card.Enabled = false;
this.button_card_to_pc.Enabled = false;
this.button_pc_to_card.Visible = false;
this.button_card_to_pc.Visible = false;
this.listBox1.Items.Add("No card detected! Please insert card!");
.MCU_BUSY--;
return;
}

I sent the Save Dongle people an e-mail and got no response. I had trouble getting the dongle to dump Pokemon Diamond (US cartridge) saves (they were filled with 0s/NULL data).

With custom software the dongle could be used to dump ROMs (I guess). Certainly a faster method than using any of the wifi-based backup homebrew tools.

Update: Please try to get an organized USB trace dump and paste the different requests/responses. It might be easy to figure out the protocol with that. I don't have much time to put on this but if it's simple enough I might be able to produce something.

 

[kerneldev]

One more thing: It seems the software "authenticates" with the dongle using TEA. The key is definitely static, though I would have to debug the application to retrieve it:

private unsafe void TEA64bit_decode(uint* v, uint* k)
{
uint num = 32;
uint num2 = *(int*)v;
uint num3 = *(int*)(v + 4 / sizeof(uint));
uint num4 = 69732896;
uint num5 = *(uint*)(k + 4 / sizeof(uint));
uint num6 = *(uint*)k;
do
{
num--;
num3 -= (num2 * 16 + num6 ^ (num2 >> 5) + num5 ^ num4 + num2);
num2 -= (num3 * 16 + num6 ^ (num3 >> 5) + num5 ^ num4 + num3);
num4 += 534691759;
}
while (num != 0);
*(int*)v = num2;
*(int*)(v + 4 / sizeof(uint)) = num3;
}

This is used in the Connect_btn_Click function:

this.ToggleLED_btn_Click(this, e2);
if (.AUTHORIZED_FLAG)
{
this.GetPushbuttonState_btn_Click(this, e2);
}
else
{
MessageBox.Show("Product is not authorized!");
}

The AUTHORIZED_FLAG variable is a boolean, and it is determined apparently in ToggleLED_btn_Click. There it refers to a g_key variable holding the key information.
It's reasonable to think they used TEA either because the manufacturer of the IC supports it or just because it's simple and effortless. Either way it's more of an annoyance than any sort of real protection.
After finding the key we only need to know how the API/ABI operates and voila. The cheapest NDS ROM dump tool in the market.

 

[Fishaman P]

So, would the key then be illegal to distribute, like the Wii Common Key?

I hardly use my SaveDongle, so I would be happy to test any firmware mods!

 

[kerneldev]

Not really, nobody has signed any EULA for the Save Dongle. TEA is patent free and public domain.The key is stored/distributed with the software. Technically and legally nobody here is doing anything they arent doing already ;-)
I believe they didn't open up the system because they are concerned about the dongle being labeled a piracy tool. I'm trying to identify the IC they use. They have wiped out the labeling from the chip surface... will put up a photo later.

 

[Kyohack]

Kudos for discovering the source code, kerneldev!

Fishman, the key (if found) would be perfectly legal to redistribute, because no licensing agreement exists between the manufacturer and user.



Not sure if this could be useful, but I'll pass it around anyways. Here is the USB traffic dump I previously made: http://db.pokestation.net/savedongle.utl

 

[kerneldev]

I'm reverse engineering the sorry thing. I just confirmed they used a PIC from Microchip Technology Inc. (or ripped off their sample GenericHIDSimpleDemo program) right away.
The original project files are a managed 2005 MSVC++ project/frankenstein.

If I brick the thing I'm not sure I will be accepting hardware donations, but I would consider it an option

Confirmed parts:

1. AMS 1117 3.3 (1A LOW DROPOUT VOLTAGE REGULATOR) http://www.advanced-.../pdf/ds1117.pdf
2. PIC18F/LF1XK50 20pin Microchip Technology Inc. USB HID IC (see http://ww1.microchip.com/downloads/en/DeviceDoc/41358a.pdf)
3. 12,000 MHz crystal oscillator, unknown manufacturer

Sorry about the poor quality, it's a scan since I don't have my camera handy. All components are Chinese, and the soldering is kind of sloppy. You will notice the voltage regulator is slightly displaced on mine.

The blurry section of the PIC is the blank spot they left after removing/wiping the part # and any other labeling coming originally with the PIC.

Update: looks like the IC is a PIC18F/LF1XK50. I think I can test with their software/IDE (Microchip's). Datasheet at:
http://ww1.microchip.com/downloads/en/DeviceDoc/41350E.pdf

 

[loco365]

This is interesting. I'll be willing to test anything people come up with. I wouldn't mind dumping my own Roms.

 

[Zerosuit connor]

This supports 3Ds Saves correct? Hello dumping tool

 

[kerneldev]

Just a quick post, since I think I'm done for today. It might be a good idea to create a separate post for these:

- I've managed to get both the boot loader and normal connection devel. software to work with the Microchip PIC18F IC.
- I can start reversing the format used by the R4 people to push firmware updates. Once that is done I believe it will be possible to customize the firmware of the dongle and open source the whole bunch.
- Any skilled people with electronics willing to design and develop an open source dongle would be also welcome. It seems the Microchip USB ICs are well suited for the job.
- Cross-platform support is perfectly possible! (R4 didn't bother to take Microchip's SDK and reuse their sample applications for Linux like they did with Windows).

I can't promise completion because this is very low priority for me but I think we could have a reusable dongle to dump and store DS and perhaps 3DS roms in the near future.

---

 

[elisherer]

Hi kerneldev..

Have you seen this...I made it a while ago...http://code.google.com/p/r4isavemore/
It was just recently I was notified of your efforts...

 

[kerneldev]

Hm, would be kinda cool if the dongle could dump ROMs (like the neoflash SMS4 or something).

Forgot to reply... I think it's outrageous that people are paying a premium for something which merely involves an IC worth two bucks, some capacitors, etc. The software and firmware at the very least should be available for review.

---

 

[Kyohack]

If that oscillator is rated at 12 mhz, then we definitely won't be dumping 3DS roms with this (assuming the 3DS rom protocol will eventually be leaked to the public). DS lite and DSi eproms will work, as they are clocked at 4.2 mhz and 6.7 mhz respectively. But the 3DS eproms are clocked at 16 mhz (which is too high for the dongle).

 

[loco365]

Hi kerneldev..

Have you seen this...I made it a while ago...http://code.google.com/p/r4isavemore/
It was just recently I was notified of your efforts...

Well, all you'd need to change is that it reads from the Rom as opposed to the save chip. And BAM. Instant Rom Dumper utility.

 

[kerneldev]

If that oscillator is rated at 12 mhz, then we definitely won't be dumping 3DS roms with this (assuming the 3DS rom protocol will eventually be leaked to the public). DS lite and DSi eproms will work, as they are clocked at 4.2 mhz and 6.7 mhz respectively. But the 3DS eproms are clocked at 16 mhz (which is too high for the dongle).

Thanks for pointing that out, I didn't know it. However the PIC has an internal oscillator too. I think the datasheet said it was around 6Mhz though. Meh. We should probably test it.

Hi kerneldev..

Have you seen this...I made it a while ago...http://code.google.com/p/r4isavemore/
It was just recently I was notified of your efforts...

Well, all you'd need to change is that it reads from the Rom as opposed to the save chip. And BAM. Instant Rom Dumper utility.

Yeah, oversimplifying the process... that's what we need to do I hope it will be that easy. If not, we may need to modify the PIC firmware as well.
You're welcome to contribute and help if you want to.

I'm done for the day, was trying to debug comfortably the R4i SaveDongle V1.4.exe executable to find the TEA key. Reflector.NET sucks these days, the Pro version isn't working for me to do source-less debugging for MC++ projects.

 

[Kyohack]

So far, I've been able to modify elisherer's source code to save the ROM header to a file, instead of the save data. I simply changed lines 31 and 32 of the R4ISaveDonlge.cs file to:

private static readonly byte[] Get512Bytes = { 0x22, 0x22, 0x00, 0, 0, 0, 0, 0, 0, 0, 0 };
private const byte Get512Response = 8;

But I've never programmed in C# before, so this is probably as far as I will get.

 

[loco365]

Yeah, oversimplifying the process... that's what we need to do I hope it will be that easy. If not, we may need to modify the PIC firmware as well.
You're welcome to contribute and help if you want to.

If I knew how to code in C or any other language for that matter, I'd love to contribute.

Edit: Oversimplifying. That's what I do.

 

[loco365]

So, has anything happened lately? I wouldn't mind backing up all my games. Without Wifi.

 

[signz]

Hm, any updates? Or is it even still being worked on?