Hacking [WIP] KARL3DS - Kernel access on N3DS via Ninjhax + Loadcode

  • Thread starter Thread starter Rokkubro
  • Start date Start date
  • Views Views 936,699
  • Replies Replies 4,457
  • Likes Likes 43
Status
Not open for further replies.
Well, we'd have to patch them for emuNAND, which we *might* be able to do if we intercept the function which loads it into RAM and prepatch it there I guess. Basically we'd have to also redirect NAND access not only in NATIVE_FIRM but in TWL_FIRM and AGB_FIRM as well.

EDIT: What Wulfy said, it's maybe possible but extremely painful.

BUT THINK OF ALL THE ROMZ! :yaysp:
 
Making the stuff functional from Home menu is the real challenge. But you could have pre-patched versions of TWL that loads specific games. Some specific things you'd have to code entirely in Arm9. So you'd boot your DS/GBA games from there instead of the home menu. It may be easier that way from a programming perspective then trying to make it work in the background from the home menu.

EDIT:

To elaborate, my idea is to have a separate menu to handle loading DS/GBA content. Call it Legacy Mode or something. You only have access to it during an early stage of booting up Karl3DS. You either boot Karl, or you go into Legacy Mode where you can select a DS, DSi, or GBA game you want to play. Your Arm9 homebrew can be coded to patch TWL to load that game (if that is required). Surely one could do so without breaking sig checks. To avoid piracy that is. But allowing DS/GBA stuff to boot might require breaking anti-piracy measures though. That's up to you if you want that in Karl or not. :P
 
Does that mean no DSi or GBA VC

I'd thought they weren't working with Gateway as a result of the DS profile exploit. Not so?

EDIT: lol never mind

It breaks because DSiWare gets installed to the TWL NAND partitions, in emuNAND. TWL_FIRM is loaded to run the game, but TWL_FIRM has not been patched for NAND redirection, just NATIVE_FIRM. So, it looks at sysNAND TWL NAND for the title, can't find it and dies.

Nothing is inherently broken about DSiWare games, it's just looking in the wrong place.
 
So that's the story with DSiWare. What's the reason GBA VC stuff not working? AGB_FIRM is in the same situation as well?


BUT THINK OF ALL THE ROMZ! :yaysp:


Give me a moment while I write a patch to delete the contempt I have for this post... .:P
 
  • Like
Reactions: Margen67
So that's the story with DSiWare. What's the reason GBA VC stuff not working? AGB_FIRM is in the same situation as well?

Yes. And it's also the reason why Smash initially failed in GW mode. It would reboot to sysNAND, look for a title, and find out that it didn't exist, so it just gave up and crashed.
 
What about cartridge loaded DS games? Curious as to why that breaks in emunand. At first I thought perhaps a Gateway specific issue given how they altered how that operated to allow their DRM device to operate. But I've tested it just now in rxMode which is pretty much a non patched clean emunand environment and my Mario 64 DS game doesn't boot. Just sits at a black-screen. Maybe at least fix this in Karl? :D
 
  • Like
Reactions: Margen67
What about cartridge loaded DS games? Curious as to why that breaks in emunand. At first I thought perhaps a Gateway specific issue given how they altered how that operated to allow their DRM device to operate. But I've tested it just now in rxMode which is pretty much a non patched clean emunand environment and my Mario 64 DS game doesn't boot. Just sits at a black-screen. Maybe at least fix this in Karl? :D

I think they're working? I mean I had DSiWare working before we added emuNAND. Not sure what the issue would be there. I'll test in a sec, doing some fun experiments. :P
 
Perhaps an issue specific to rxTools maybe. I had just now tried to boot Mario 64 while in rxMode emunand. It didn't boot. :P
Or maybe it's just because rxTools is just Gateway Classic which doesn't need a Gateway to work. No idea why it fails to work under GWs emuNAND, probably just Gateway being stupid with keys or something.
 
Yeah the one thing I did notice with rxTools is it's initial boot from the web browser exploit. It does a wipe screen animation pretty much the same as with Gateway's loader. Not sure if that really means anything or not. :P


EDIT: Currently I don't think rxMode even does region free yet. So it might not entirely be the same as Gateway's classic mode at the moment.
 
I don't think that making an EmuNAND patch for TWL_FIRM or AGB_FIRM would be that hard. The registers for NAND access in TWL mode are shared with the SD card. Change the device target and add an offset to the read address.
 
  • Like
Reactions: Margen67
It breaks because DSiWare gets installed to the TWL NAND partitions, in emuNAND. TWL_FIRM is loaded to run the game, but TWL_FIRM has not been patched for NAND redirection, just NATIVE_FIRM. So, it looks at sysNAND TWL NAND for the title, can't find it and dies.

Nothing is inherently broken about DSiWare games, it's just looking in the wrong place.

but dsiware does not work in sysnand gw mode... so why is that?
 
I don't think that making an EmuNAND patch for TWL_FIRM or AGB_FIRM would be that hard. The registers for NAND access in TWL mode are shared with the SD card. Change the device target and add an offset to the read address.

We know how to write emunand patches. It's likely a thing we'll include if we can get it working. Also your description of the eMMC registers applies to native mode too, except "change the device target" is honestly nowhere near how emunand works.
 
Or maybe it's just because rxTools is just Gateway Classic which doesn't need a Gateway to work. No idea why it fails to work under GWs emuNAND, probably just Gateway being stupid with keys or something.
As i already said, my code has nothing to do with Gateway one, even if the features are somehow similar.
It fails becouse i forced the reboot to stay in native_firm. I can change this, btw.
 
As i already said, my code has nothing to do with Gateway one, even if the features are somehow similar.
It fails becouse i forced the reboot to stay in native_firm. I can change this, btw.
Unrelated, but I like how you did your obfuscation on new rxtools. Without saying too much, it sort of goes back to the whole 'anyone who can hack gateway doesn't need community devs' work to make cfw' argument, hehe.
 
  • Like
Reactions: WhoAmI? and Roxas75
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum