Hacking Virtual Console (ambassador games) ROM injection

[Nintynuts]

Now we have 10 NES and 10 GBA games with emulators we can copy to our SD cards and we know what the ROM data should be, might it be possible to work out the encryption key so we can decode the data and inject different ROMs to play on our 3DSs?

I know it's not quite as simple as that, as there's the emulator data that will have an overhead (probably at the start) as well as the per-game metadata so if it's encrypted with it's own md5 hash or something that will throw it all off. It was just a thought and i wondered if it was at all feasible?

Looking forward to hearing some thoughts from people who know what they're talking about

 

[Tsukurimashou]

That would be great but I really don't know how it works so I can't help, sorry.

 

[Snailface]

I think you're supposed to have posted this here:
http://gbatemp.net/topic/307018-awesome-3ds-hacking-theories/

 

[Nintynuts]

I could have, but firstly I was unaware of that thread was stickied for use rather than a reference, but also that every time I've ever posted something in a long running thread like that no-one ever takes any notice.
This whole forum is 'Hacking & Homebrew' so I don't see why I shouldn't be allowed to make a new thread. I'm not an expert but I have some idea what i'm talking about so I wanted it to get some proper attention.

But anyway, are there some people about who have played with reverse engineering encryption before?

 

[Tom Bombadildo]

I could have, but firstly I was unaware of that thread was stickied for use rather than a reference, but also that every time I've ever posted something in a long running thread like that no-one ever takes any notice.
This whole forum is 'Hacking & Homebrew' so I don't see why I shouldn't be allowed to make a new thread. I'm not an expert but I have some idea what i'm talking about so I wanted it to get some proper attention.

But anyway, are there some people about who have played with reverse engineering encryption before?

Well then I'd like everyone to pay attention to the fact that I strongly disagree with you and quite frankly don't care whether or not you wanted attention or not. Stickies are there for a reason, if no one pays attention to your idea, your idea is shitty. Deal with it.

On topic: There is some sort of encryption and nobody has been able to reverse engineer or crack the encryption or inject ROMs or anything. I remember various threads about this same thing and still nothing has been reported.

 

[Rydian]

That thread is made for situations where all somebody has are theories.

 

[ferofax]

you don't even know where in the files these VC titles are, much less know how to decrypt them.

until then, ROM injection has nothing to go on with, and therefore no real reason to discuss it other than just to have something to say about it..

 

[totalnoob617]

well it wouldnt be hard to find ,all you would need to do is copy your sd card to your pc ,then download one of the games and see what new data is added and how the 2 sd backups dont dont match, the new added files are obviously the game, but we dont know if they use emulation at all i doubt they do ,they are most likely ports no?

 

[Clydefrosch]

its not as easy, since its all encrypted. you'd need to decrypt it first, to be able to compare things. (considering one download consists of a rom and the needed emulator data?)

if there was overlapping data on the files, it could be possible to determine where the rom would be and stuff, but im guessing someone who knows better already got that idea

 

[celcodioc]

I could have, but firstly I was unaware of that thread was stickied for use rather than a reference, but also that every time I've ever posted something in a long running thread like that no-one ever takes any notice.
This whole forum is 'Hacking & Homebrew' so I don't see why I shouldn't be allowed to make a new thread. I'm not an expert but I have some idea what i'm talking about so I wanted it to get some proper attention.

But anyway, are there some people about who have played with reverse engineering encryption before?

Only save files from cartridges have been decrypted before.

you don't even know where in the files these VC titles are, much less know how to decrypt them.

until then, ROM injection has nothing to go on with, and therefore no real reason to discuss it other than just to have something to say about it..

We could probably just search for the ROM header... but since we don't know how to decrypt the apps, we can't do that ^^

well it wouldnt be hard to find ,all you would need to do is copy your sd card to your pc ,then download one of the games and see what new data is added and how the 2 sd backups dont dont match, the new added files are obviously the game, but we dont know if they use emulation at all i doubt they do ,they are most likely ports no?

Since they seem to run much like DS games (no StreetPass, no SpotPass, hold START or SELECT to play them in their native resolution, etc), I'd guess they are run natively + a few minor additions for bottom screen and HOME button support.



[/thread]?

 

[Nintynuts]

I'm 99% sure the virtual console games are emulated, the 3DS doesn't have an arm7 chip in it like the GBA-DS Lite had (removed from DSi) so there has to be an emulator somewhere, if not embedded in each package then in the firmware. On Wii, which is the nearest comparison in terms of power, each game had it's emulator built in, which is why some ROMS only worked when injected into particular emulators because of optimization. I would have thought the structure of these new Virtual console games is probably the same as the Wii ones, Nintendo don't like re-inventing the wheel. Again, it would be nice to hear some comments from someone who has worked with anything I've mentioned to confirm/deny whether any of this sounds plausible.

EDIT: I suppose it's remotely possible these games have been recompiled to run on the PICA and new CPU with a wrapper for scaling and new button handling, but it seems unlikely considering Nintendo's track record.

 

[spinal_cord]

The files are probably encrypted AFTER the rom is combined with the emulator, so comparing rom images will get you nowhere. Someone would have to decrypt the files before ANY progress is made in ANY area of 3DS homebrew. (yes I know rom injection is different, but the point is the same).
Also, the NES games have been around for a while now, if anyone had made any progress, you would have heard about it already.

[edit] - yes, the games are emulated, you can tell in a couple of areas, such as random screens of garbled gfx during fades in yoshis island.

 

[wchill]

I'm 99% sure the virtual console games are emulated, the 3DS doesn't have an arm7 chip in it like the GBA-DS Lite had (removed from DSi) so there has to be an emulator somewhere, if not embedded in each package then in the firmware. On Wii, which is the nearest comparison in terms of power, each game had it's emulator built in, which is why some ROMS only worked when injected into particular emulators because of optimization. I would have thought the structure of these new Virtual console games is probably the same as the Wii ones, Nintendo don't like re-inventing the wheel. Again, it would be nice to hear some comments from someone who has worked with anything I've mentioned to confirm/deny whether any of this sounds plausible.

EDIT: I suppose it's remotely possible these games have been recompiled to run on the PICA and new CPU with a wrapper for scaling and new button handling, but it seems unlikely considering Nintendo's track record.

Which track record would this be? I see emulation as unlikely; just have GBA code run using a hypervisor with the appropriate calls to 3DS functions instead of GBA functions where necessary (ie. the bottom info screen). Why reinvent the wheel and try to emulate something you can run pretty much natively?

Not saying that ROM injection is likely anytime soon, as spinal_cord mentioned.

As for graphical glitches, that does not necessarily mean an emulator - it could just be the 3DS screen and/or the code used to drive it.

(If it wasn't clear, the 3DS's ARM processor is backwards compatible with ARM7 code, just like it is with ARM9 code, which is used in the DS. The Nintendo 1048 0H ARM processor is really a System on Chip with a version of the ARM11 and the Pica200 in one chip. Since ARM11 implements ARM7 and ARM9 instructions, it is backwards compatible.)

 

[heartgold]

[edit] - yes, the games are emulated, you can tell in a couple of areas, such as random screens of garbled gfx during fades in yoshis island.

Not really, NES games have been draining more battery life than GBA games, IMO this isn't 100% emulation and ARM11 core is able to run native ARM7/9 codes.

 

[Roxas75]

I saw a little the structure, so i think that the games are emulated.
The file 00000001.app is a little bigger than the GBA rom, so i think it's a package that contains emulator and rom.
The only way is to decrypt them...

 

[wchill]

I saw a little the structure, so i think that the games are emulated.
The file 00000001.app is a little bigger than the GBA rom, so i think it's a package that contains emulator and rom.
The only way is to decrypt them...

Please refer to this post on the subject.

Allright, so we have an encrypted ROM, which consists of: 1. a Header, 2. a Bootloader, 3. the Actual Game. Would it be possible to keep the current Header and bootloader encrypted and in place, while replacing the code segment to which the bootloader points to with some decrypted (or unsigned custom) executable?

Also, I remember those bulky LPT cables, which were connected to large dongles, in which we could slide a GBA-cartridge sized flash cart. Then, we'd use software to flash the NAND of that cart with a single game, which we then could play as if it were a real cartridge. (Fooling even the GC Gameboy Player, and a vareity of GC Games with linking ability, like HM:AWL. I believe The same can be done with 3DS games, as developers use a nintendo branded flashable cartridge to test games on regular 3DS consoles. Of course, a more usable USB connected dongle to Dump Original games and Flash the Flashcart would be nice... Then again, even if this would be pulled off, we'd still not have a way of running unsigned code.

However: There's still a possibility we can do stuff with the downloadable content of the 3DS. For the sake of research, I've been meddling around with some of the GBA titles only obtainable for participants of the "3DS Ambassador Programme". These are my findings: (mind you, I have no way of knowing this for certain, as all files are encrypted, and I have no way to decrypt most of them.)

For the GBA "emulated" games (I'll explain later why emulated is encapsulated by quotes), this is the file structure on the SD card after download and playing at least once:

|- 
|- 
|- 
|- 
|- 
|- 
|   |- 00000001.sav
|- 
|- 
|   |- 00000001.cmd
|- 00000000.tmd
|- 00000002.app
|- 00000003.app

My explanation:

00000001.sav: obviously, this would be the Game's saved data. Encrypted, probably unsigned due to checksums or CRC.

00000000.tmd: Seems to be the ticket file, telling the 3DS if this console is eligable to use this title, using the unique console ID. Encrypted and most definitly Signed, as this would be the key point to distribute "3DS-Ware".

00000001.cmd: I suspect this to be a bootloader to tell the 3DS to disable some hardware, go into some hardware assisted virtual mode and presumably sandbox the game and memory used by it. Encrypted, probably signed.

00000002.app: This appears to be the ROM file, but encrypted and probably signed.

00000003.app: Due to the huge file size differences from GBA game to GBA game (from ~1200kB to ~1800kB) I doubt this is an emulator (hence my quotes by emulated above). I have yet to see an encryption algorithm to cause such huge file size differences. I suspect it to be merely a "converted function file", to assist the 3DS hardware to run code native to the GBA. Especially thinking about how Nintendo at this time claims the GBA games probably won't be made publicly available, I suspect them to be game-specific, as in only functions this game needs are in there. This defeats the probability of ROM injection, and would be a Nintendo way to block such attempts.

IMHO, to get somewhere, we first need to crack the ticket file. This would give us insights how to make the 3DS accept custom code. But then again, I could be completely off...

*edited: copy and paste made a number of unnecessary linebreaks

That's not that far off. One of the best posts I've seen in this thread. However, as you say yourself, the signature checks have to be defeated. Tickets are not as important, though of course the 3DS will need one to be authorized to install whatever software that ticket corresponds to. You are correct in thinking that the GBA games are not emulated (why do it when the ARM processor in the 3DS can handle GBA code natively?). Those support libraries you talk about in 00000003.app would probably be for modified timing/graphics/sound routines that would differ from the 3DS and GBA, whereas the DS had an ARM7 processor and GBA-specific hardware that could just kick in when a GBA game was run.

However, because certain 3DS functions are disabled in GBA hypervisor mode (such as the 3D as well as cameras, possibly wireless as well as any other unnecessary functions), injecting code into these will not help us too much. We'd still be missing a lot of things. I'm guessing that the HOME button works by setting a software interrupt when the button is pressed, triggering the appropriate action, which would make sense (DS games run in a hypervisor - HOME pauses the game and launches a menu asking whether to return, 3DS games are paused and suspended when going HOME, trying to go HOME while playing online in MK7 is not allowed - most likely a flag to disable the HOME interrupt). The functions that are disabled would then only be re-enabled when returning HOME, as the code that handles the interrupt would also be handling the hardware and would be running at a lower layer than the game/hypervisor.

(This is speculation, I'll admit, but I think this is pretty accurate)

If you flip the wireless switch on and then off while in a VC/GBA game, does that do anything? Just curious. Too lazy to do it on my own 3DS.

So I totally didn't read up on 3DS security, but what if we have a cart, that takes a retail 3DS card for authentication, then using a timer, routes data from some sort of external memory as the game data? The authentication step is similar to what the original PassMe did.

Isn't this what current DSi carts in DS Mode do? They basically have a retail game in the bootloader that's been modified to jump to the flashcard's menu.
Of course, we can't modify 3DS software or even DSi software to do this yet (damn the lack of keys). The iEvo uses a save game exploit, which is different from how the original PassMes worked. Correct me if I'm wrong, but Martin Korth's successful crack of the encryption on DS games allowed us to modify said games for whatever purpose (leading us to the NoPass, since the DS didn't perform enough checking to make sure that a "game" really was a game instead of relying on just the encryption itself - now we have signature checking and such).

 

[DiscostewSM]

[edit] - yes, the games are emulated, you can tell in a couple of areas, such as random screens of garbled gfx during fades in yoshis island.

I would have to disagree with you there. That can easily be caused by the motion blur, using a low ratio of the retained frame mixed with a high ratio of the current frame. That capability itself is an operation built-in to the GPU. Even the DS had a capture unit for such an effect.

As has been said already, GBA games on the 3DS have shown to have less power consumption than both the NES and GB games because the ARM11 is capable of interpreting ARM7 and ARM9 code natively. While I say the games aren't fully emulated, I won't rule out the possibility that it is partially emulated. From the original GBA to the DS Lite, each of the devices included a Z80 co-processor, partly for backwards compatibility, but GBA games used it for the audio tone generators alongside it's own 2 8-bit DACs to make up the audio system. From the DSi on, GBA compatibility was removed, which included the removal of anything that wasn't being used by DS games, which included that Z80 co-processor.

 

[Nintynuts]

Well, I now know a couple of things hadn't initially realized, firstly that ARM11 was backwards compatible with 9 AND 7 and secondly that AES encryption (which nintendo has used in the past, so i guess probably for this too) is so damn complicated, so there's no way of injecting without the key(s) first. I also agree that it's likely that the overhead on the app file is probably per-game compatibility related as it varies in size so much. I would say it's actually simulating the GBA games rather than emulating or running them natively, but that may just be me. However, I don't think this will completely prevent Injection, we may just find some games work better in some of the containers than others; we have 10 to play with.

I bow to the knowledge of those few who have contributed the most in this thread, and unless people want to continue discussing theories, a mod can go ahead and close this now.

Thanks everyone

 

[totalnoob617]

i will say 1 thing the emulation and emulator is kinda shitty ,i mean i know the resolution is much better than nesds but when i run metroid on nesds it runs fine no matter how many sprites are on the screen ,and even i can fast fwd and rew with l and r and its flies, when i play the ambassador version the game slows down considerably even when there are even that many sprites on the screen, i have not tried the wi vc or emulated one but curious how metroid vc runs next to it on a wii nes emulator and how the 2 emulators differ on the 2 systems in terms of performance ,i wonder if the vc metroid slows down too

 

[DiscostewSM]

i will say 1 thing the emulation and emulator is kinda shitty ,i mean i know the resolution is much better than nesds but when i run metroid on nesds it runs fine no matter how many sprites are on the screen ,and even i can fast fwd and rew with l and r and its flies, when i play the ambassador version the game slows down considerably even when there are even that many sprites on the screen, i have not tried the wi vc or emulated one but curious how metroid vc runs next to it on a wii nes emulator and how the 2 emulators differ on the 2 systems in terms of performance ,i wonder if the vc metroid slows down too

One emulator is made by homebrewers. The other is made by Nintendo. The homebrew emulator, while having nice extra features, does not have something that Nintendo's emulator has. The ability to execute the game with everything it requires at 100%. Even if the game slows down, that is because it would do so on the actual hardware too. Might seem silly, but keeping it in sync like that allows it to stay accurate (and stable I might add).