Hacking [hypothetical question] RedTWL: Would it be possible with system access granted by current exploits?

[zhdarkstar]

DISCLAIMER: My technical knowledge of how 3DS hacks function is minimal and my coding ability is practically nonexistent. This thread was created with the intention of finding out if the proposed idea is possible with the system access granted by current exploits, not as a declaration of creating such a project. Please treat this thread as an attempt to start an intellectual discourse on the feasibility of the concept, not as a "I want this! Someone code it for me!" thread.
-------------

Now that my qualifications have been laid out on the table, let's get to the meat & potatoes of this thread.

RedTWL. What is it? Is it even possible? What obstacles stand in its way?

RedTWL is an idea that came to mind after perusing various threads about running DSiWare on the 3DS. The basic idea is essentially taking the concept of RedNAND and applying it exclusively to TWL_NAND. Instead of installing DSiWare titles to SysNAND, it would be done to a designated partition of the SD card.

What purpose might such a concept serve? It could possibly overcome the current problem of limited TWL_NAND size. There are two applications of RedTWL that come to mind as being ways to overcome this problem. The first way could be easier to implement than the second. However, the second affords greater convenience in the long-term, if it can be developed.

1. Multiple RedTWLs: We already have CFW capable of selecting between multiple RedNANDs. Therefore, it shouldn't be too difficult to adapt CFW to being able to select from different RedTWLs. Not the most elegant solution, but it could function as a stopgap measure while the second idea is in development.

2. Expandible RedTWL: This is by far the more complex application, but it has been done before on another Nintendo console as SNEEK/UNEEK on the Wii. This is the application that really made me bring the thoughts about whether or not current exploits would allow for such an idea to work. My first intuition tells me that modifying the TWL bootloader might be both required and an issue with current exploits; however, the optimist in me would rather discuss this idea with the community before simply dismissing it as a pipe dream. My second hunch is that in order to load titles installed in RedTWLs larger than the default size, a custom loader like WiiFlow might be necessary.

That's pretty much everything that I could think of regarding the subject, given my limited technical knowledge. If something I posted isn't currently feasible, please feel free to explain why. Doing so will serve to better my understanding of the inner workings of the 3DS.

 

[Temarile]

Interesting.. I am going to follow this thread. Unfortunately I am also not very qualified to discuss these things, I am interested to see what happens.

 

[PaiiNSteven]

I could see this happening. Nice.

 

[DinohScene]

@Apache Thunder

This should make it a bit easier.

Personally, I don't think you'll succeed in this without a lot of hacking.
It might be easier to figure out a way to completely seperate RedNAND/EmuNAND from the system (including GBA/DSi launching and other things that reboot the console).
Then again, please, prove me wrong.

 

[mid-kid]

So, you're talking about NAND redirection for TWL?
Okay, first thing you should know is that TWL_NAND lives in the regular NAND, as a partition, see http://3dbrew.org/wiki/Flash_Filesystem#NAND_structure. All DSiWare titles are installed in said partition.
So, since the whole TWL NAND is inside the NAND, a Red/emuNAND has a copy of the TWL NAND.
In fact, when you install DSiWare titles on emuNAND, they're installed there.
So, what's stopping us from applying NAND redirection for TWL? Not much.
Thing is, the reason why we have to install DSiWare to both sys and emuNAND right now, is that if you launch a DSiWare title, the title ID is passed to TWL_FIRM (and the console rebooted), BUT, unlike NATIVE_FIRM, that isn't patched for NAND redirection. So instead of trying to load the title from emuNAND it will try to load it from sysNAND.
There's no publicly known method for doing NAND redirection from TWL_FIRM.
However, this will not fix the problem with the size you have in the TWL NAND, just the location where it's stored.

Since the TWL_NAND is just a MBR with a FAT16 and FAT12 partitions, I guess it'd be possible to store them elsewhere, expand them, and patch the TWL_FIRM to load the data from there, it'd just require a bunch of work.

 

[dankzegriefer]

You COULD, but why would you?

 

[Deleted member 370671]

You COULD, but why would you?

Unlimited DSiWare installs, and possibly any DS game install (if we find a way to install them in the future)

 

[dankzegriefer]

Unlimited DSiWare installs, and possibly any DS game install (if we find a way to install them in the future)

You can already do that.

 

[Froster]

Following this to see how far it goes-

 

[dankzegriefer]

Following this to see how far it goes-

There's a button called "Watch Thread", rather than making an annoying useless post, press that.

 

[Froster]

There's a button called "Watch Thread", rather than making an annoying useless post, press that.

no.

 

[dankzegriefer]

no.

Then keep being a parasite.

 

[zhdarkstar]

So, you're talking about NAND redirection for TWL?
Okay, first thing you should know is that TWL_NAND lives in the regular NAND, as a partition, see http://3dbrew.org/wiki/Flash_Filesystem#NAND_structure. All DSiWare titles are installed in said partition.
So, since the whole TWL NAND is inside the NAND, a Red/emuNAND has a copy of the TWL NAND.
In fact, when you install DSiWare titles on emuNAND, they're installed there.
So, what's stopping us from applying NAND redirection for TWL? Not much.
Thing is, the reason why we have to install DSiWare to both sys and emuNAND right now, is that if you launch a DSiWare title, the title ID is passed to TWL_FIRM (and the console rebooted), BUT, unlike NATIVE_FIRM, that isn't patched for NAND redirection. So instead of trying to load the title from emuNAND it will try to load it from sysNAND.
There's no publicly known method for doing NAND redirection from TWL_FIRM.
However, this will not fix the problem with the size you have in the TWL NAND, just the location where it's stored.

Since the TWL_NAND is just a MBR with a FAT16 and FAT12 partitions, I guess it'd be possible to store them elsewhere, expand them, and patch the TWL_FIRM to load the data from there, it'd just require a bunch of work.

I think I get the gist of what you're saying. Is it safe to assume that the similar coding tricks to those that allow NAND redirection with NATIVE_FIRM can't be applied to TWL_FIRM? If so, what are the differences between NATIVE_FIRM and TWL_FIRM that precludes it from happening?

Do we have enough system access to be able to patch TWL_FIRM? Which entrypoint would be the best to work with? Considering that the DSi and 3DS modes share the ARM9, perhaps an a9lh payload would be the way to go. Does the a9lh entrypoint occur when the console reboots to DSi mode? Would there need to be something else done to accommodate for the TWL_FIRM ARM11 process?

You can already do that.

To which part? Unlimited DSiWare installs or the DS game installation?

 

[dankzegriefer]

I think I get the gist of what you're saying. Is it safe to assume that the similar coding tricks to those that allow NAND redirection with NATIVE_FIRM can't be applied to TWL_FIRM? If so, what are the differences between NATIVE_FIRM and TWL_FIRM that precludes it from happening?

Do we have enough system access to be able to patch TWL_FIRM? Which entrypoint would be the best to work with? Considering that the DSi and 3DS modes share the ARM9, perhaps an a9lh payload would be the way to go. Does the a9lh entrypoint occur when the console reboots to DSi mode? Would there need to be something else done to accommodate for the TWL_FIRM ARM11 process?



To which part? Unlimited DSiWare installs or the DS game installation?

Unlimited DSiWare installs, DS game installation NEVER EVER.

 

[Deleted member 370671]

You can already do that.

Aren't DSiWare installs limited by the size remaining on sysNAND?

DS game installation NEVER EVER.

"The 3DS' security is impossible to break!"
- Some people in 2012

"We will never be able to play any custom GBA game in native mode!"
- Some people in 2013-2014

"There will never be any kernel exploit on 9.3+!"
- Some people in 2015

"MenuHax is the closest thing to an autoboot we're ever going to get!"
- Some people in 2015

"DS game installation NEVER EVER."
- You in 2016

 

[dankzegriefer]

Aren't DSiWare installs limited by the size remaining on sysNAND?


"The 3DS' security is impossible to break!"
- Some people in 2012

"We will never be able to play any custom GBA game in native mode!"
- Some people in 2013-2014

"There will never be any kernel exploit on 9.3+!"
- Some people in 2015

"MenuHax is the closest thing to an autoboot we're ever going to get!"
- Some people in 2015

"DS game installation NEVER EVER."
- You in 2016

It's possible. But nobody is going to do it. It's a waste of effort when people can do something else with their damn time. Like making CFW better. Spend $6 on a classic R4 and use TWL firm patches.

 

[LoganK93]

It's possible. But nobody is going to do it. It's a waste of effort when people can do something else with their damn time. Like making CFW better. Spend $6 on a classic R4 and use TWL firm patches.

Not to be that guy, but that was the same logic behind not having GC from USB being worked on on the Wii. "No one" wanted to do it then three seperate groups of "no ones" did it and now look. Just because no one wants to today doesn't mean they won't try and possibly succeed in the future.

 

[zhdarkstar]

Unlimited DSiWare installs, DS game installation NEVER EVER.

Unlimited DSiWare installs, how so? Sure, you can store DSiWare to the SD card, but you can't run them from it. The idea of RedTWL is to be able to run the DSiWare right off of the SD card. If it could be made expandable, then you'd only be limited by the amount of space that you dedicate for RedTWL.

As for DS game installation, it may not be entirely impossible, but probably not like you'd think. Going for the DSiWare route is probably not going to work, unless research of the Advance Wars: Days of Ruin cia file yields some new breakthrough. Instead, I think that the answer lies in the virtualization processes that control DSiMode, and possibly lies outside of the scope of our current exploits. I have no doubt that it would be a herculean effort like DIOS MIOS or Nintendont, but those apps were able to load games larger than DS roms with less RAM than a 3DS.

The idea is to tap into unused processing potential to create a virtual flashcart for the virtual DSi. The only thing that I could foresee posing a performance problem would be total available processing speed, so such a DS rom loader would have the possibility of being N3DS-exclusive to make use of the extra cores. I also think that any such loader might have a better chance of initial success if focusing on getting unpacked DS games to run before attempting to get .nds file support. It might end up adding steps to the end-user setup, but could save in processing power by not having to decrypt the .nds file on the fly.

It's possible. But nobody is going to do it. It's a waste of effort when people can do something else with their damn time. Like making CFW better. Spend $6 on a classic R4 and use TWL firm patches.

What do you define as "making CFW better" at this point in time? We're pretty much at the endgame stages of CFW development. A9lh pretty much signified that we've reached zenith of the primary goal of booting into a CFW. Now is the time where we're going to see more branching development than straightforward, aka the Bells & Whistles Phase. The wireless video streaming that we saw previewed yesterday is an example of that. Not every new development will be viewed as something that objectively makes CFW better, but we're likely to see forks that bring new options to the table for those who want them.

 

[dankzegriefer]

Unlimited DSiWare installs, how so? Sure, you can store DSiWare to the SD card, but you can't run them from it. The idea of RedTWL is to be able to run the DSiWare right off of the SD card. If it could be made expandable, then you'd only be limited by the amount of space that you dedicate for RedTWL.

As for DS game installation, it may not be entirely impossible, but probably not like you'd think. Going for the DSiWare route is probably not going to work, unless research of the Advance Wars: Days of Ruin cia file yields some new breakthrough. Instead, I think that the answer lies in the virtualization processes that control DSiMode, and possibly lies outside of the scope of our current exploits. I have no doubt that it would be a herculean effort like DIOS MIOS or Nintendont, but those apps were able to load games larger than DS roms with less RAM than a 3DS.

The idea is to tap into unused processing potential to create a virtual flashcart for the virtual DSi. The only thing that I could foresee posing a performance problem would be total available processing speed, so such a DS rom loader would have the possibility of being N3DS-exclusive to make use of the extra cores. I also think that any such loader might have a better chance of initial success if focusing on getting unpacked DS games to run before attempting to get .nds file support. It might end up adding steps to the end-user setup, but could save in processing power by not having to decrypt the .nds file on the fly.



What do you define as "making CFW better" at this point in time? We're pretty much at the endgame stages of CFW development. A9lh pretty much signified that we've reached zenith of the primary goal of booting into a CFW. Now is the time where we're going to see more branching development than straightforward, aka the Bells & Whistles Phase. The wireless video streaming that we saw previewed yesterday is an example of that. Not every new development will be viewed as something that objectively makes CFW better, but we're likely to see forks that bring new options to the table for those who want them.

What the fuck did I just read?

 

[Deleted member 370671]

It's possible. But nobody is going to do it. It's a waste of effort when people can do something else with their damn time. Like making CFW better. Spend $6 on a classic R4 and use TWL firm patches.

Well, IMO it's everything but a waste of time.
Having this would mean we have control over basically everything the average user could want, without the need of extra meterial.
And maybe it's just me, but I don't want to spend 6 bucks on a DS flashcart. Well, I "don't care" about the 6 dollars in themselves (whether it is 20$ or 1$ is the same for my point), but what's bothering me is that I need extra hardware and / or money to do this.
This is basically the reason I use CFW instead of GW. Simple (no red card, only what was included in my 3DS' box) and free.