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

[LoganK93]

What?
I think you quoted the wrong post.

Yeah I did, but the point still stands that once upon a time Gamecube loading worked exactly the way you seemed to think it didn't.

 

[dankzegriefer]

Yeah I did, but the point still stands that once upon a time Gamecube loading worked exactly the way you seemed to think it didn't.

And now I know you haven't read any shit I've said. Please, re-read what I said, compare it to what you think, and note the discrepancy.

 

[LoganK93]

And now I know you haven't read any shit I've said. Please, re-read what I said, compare it to what you think, and note the discrepancy.

Ok I'm sorry. Your argument was that the hardware is different, which indeed it is, and that Nintendon't did not patch or use the MIOS as it instead patches into the Wii OS for games. So replace what the other user was saying with DIOS MIOS instead. That patched the MIOS in order to run games from an sd card or usb drive and did not work on Wii U because it did not have the internal GC hardware and lacked an MIOS to patch.

They are simply hypothetically suggesting a similar situation on 3ds, though I believe a virtualization similar to Nintendont would likely work better/be easier, but before you get any angrier over this I'll admit to not having huge knowledge of how all the internals work, but it seems to be possible in theory as it is similar to how things started on the wii for GC loading.

 

[dankzegriefer]

Ok I'm sorry. Your argument was that the hardware is different, which indeed it is, and that Nintendon't did not patch or use the MIOS as it instead patches into the Wii OS for games. So replace what the other user was saying with DIOS MIOS instead. That patched the MIOS in order to run games from an sd card or usb drive and did not work on Wii U because it did not have the internal GC hardware and lacked an MIOS to patch.

They are simply hypothetically suggesting a similar situation on 3ds, though I believe a virtualization similar to Nintendont would likely work better/be easier, but before you get any angrier over this I'll admit to not having huge knowledge of how all the internals work, but it seems to be possible in theory as it is similar to how things started on the wii for GC loading.

Alright, now that you actually proven you can read, you can't do such a virtualization, ARM11 is too different from ARM9+ARM7 to be able to run things meant to run on BOTH an ARM9 and ARM7 at the same time. So that shoots the Nintendont virtualization theory (side note: STOP USING THE WORD VIRTUALIZATION, IT IMPLIES EMULATION FOR THE LOVE OF GOD). Now reverse engineering the code for launching TWL games is possible, but hard, and finding a way to patch NTR games to TWL is harder. Extremely hard. Which is too much effort for a developer to waste to actually create this when you can buy a $6 R4 and use TWL patches to fix it. It takes not even 5 minutes of effort.

 

[LoganK93]

Alright, now that you actually proven you can read, you can't do such a virtualization, ARM11 is too different from ARM9+ARM7 to be able to run things meant to run on BOTH an ARM9 and ARM7 at the same time. So that shoots the Nintendont virtualization theory (side note: STOP USING THE WORD VIRTUALIZATION, IT IMPLIES EMULATION FOR THE LOVE OF GOD). Now reverse engineering the code for launching TWL games is possible, but hard, and finding a way to patch NTR games to TWL is harder. Extremely hard. Which is too much effort for a developer to waste to actually create this when you can buy a $6 R4 and use TWL patches to fix it. It takes not even 5 minutes of effort.

Dude. Take a fucking chill pill. Seriously. This is not that serious.

 

[dankzegriefer]

Dude. Take a fucking chill pill. Seriously. This is not that serious.

Then don't put your misinformed BS on the internet.

 

[Deleted User]

This talks about how redirecting Slot-1 access would be to redirect the access to AGB_Firm. This was possible through DS flash carts long before because they ran from the GBA slot but they ran in DS mode.

Well you could rewrite parts of TWL_FIRM to create a virtual slot-2 in FCRAM (perhaps on SD if possible. But it may not be fast enough) and create a simple passme NTR CIA that will load a rom to it and boot it. Booting DS game off slot-2 was what the pre slot-1 flashcarts use to do, so you could do that on a 3DS if you can find a way of mapping unused FCRAM for the virtual slot-2.

It's feasible. AGB_FIRM loads the game rom into FCRAM as well so the process would be similar.

You'd have to work out how you'd load the rom into FCRAM in the first place. NTR mode titles don't normally have SD access. FCRAM is limited (though you'd have a bit more wiggle room with n3DS), so it may not be the best method.

Not to mention the serious changes you'd have to do to TWL_FIRM to allow this. It would probably be less overhead for Arm7/Arm9 then trying to load the roms directly from SD.

But the problem is finding a way of unlocking the extra FCRAM space normally disabled in TWL/NTR mode.

Good luck with that.

 

[Swiftloke]

Then don't put your misinformed BS on the internet.

Aaaand here's why I'm calling you a troll. Here's the problem: you're wasting people's time and energy on a thread that could actually get somewhere with DS games. Even my post, calling you out, is a waste of space in what could otherwise be something great. So I'll just contribute something to make up for that:
DS read/writes are hardcoded into the ROM, right? And editing ROM's would be too impractical. So let's think about this: How do we use what little capability the ARM11 has in TWL_FIRM to trick the cart into thinking it's reading from the cartridge, when it's in the SD card? Though the SD Card is disabled from DS mode, I'll assume that it isn't from the Arm11 side. Could we modify TWL_FIRM to give ARM11 it's full capability, or set it up as a supervisor to R/W? Could we have all commands be going through the ARM11 so it can pick out the commands to R/W, and modify them in real-time? So many attack vectors, so little really done...

 

[Wolfvak]

Aaaand here's why I'm calling you a troll. Here's the problem: you're wasting people's time and energy on a thread that could actually get somewhere with DS games. Even my post, calling you out, is a waste of space in what could otherwise be something great. So I'll just contribute something to make up for that:
DS read/writes are hardcoded into the ROM, right? And editing ROM's would be too impractical. So let's think about this: How do we use what little capability the ARM11 has in TWL_FIRM to trick the cart into thinking it's reading from the cartridge, when it's in the SD card? Though the SD Card is disabled from DS mode, I'll assume that it isn't from the Arm11 side. Could we modify TWL_FIRM to give ARM11 it's full capability, or set it up as a supervisor to R/W? Could we have all commands be going through the ARM11 so it can pick out the commands to R/W, and modify them in real-time? So many attack vectors, so little really done...

Easy & Short Answer (TM) : 'No'

Long answer: wtf are you even talking about? The ARM11 is completely disabled when it launches, and it isn't disabled by the TWL_FIRM, it disables itself. And please, I'm begging you, read this http://3dbrew.org/wiki/ARM7_Registers

And again: DS games read directly from the cart port, using the ARM9. SD / NAND access is provided by the ARM7. Newer DS -> DSi recompilations probably get away with buffering (I mean, they have 12MB free, they gotta do something with them), and as such don't lag. However, if we could, by some black magic get our own DSi recompilations we would not only have to patch the read / write functions, we would also have to integrate some sort of disk (I mean SD / NAND, you get the idea) cache so that they don't lag heavily / crash. Some games actually rely on read timings, and will fail if they don't get their data on time.

BTW @dankzegriefer isn't a 'troll', at least in the most strict of definitions. In any case he's the one bringing some facts in here, so he'd be an anti-troll of sorts. His attitude was due to the simple fact that people don't know how to read and rush their conclusions.

 

[prototech]

BTW @dankzegriefer isn't a 'troll', at least in the most strict of definitions. In any case he's the one bringing some facts in here, so he'd would be an anti-troll of sorts. His attitude was due to the simple fact that people don't know how to read and rush their conclusions.

Some people on this forum need to learn to just stop talking when another isn't acting to their standards, rather than spread toxic crap. If somebody is being stupid, not informing themselves, etc, just ignore them. There is no need to spread negativity and make yourself and the forum look bad.

 

[GerbilSoft]

1- We don't even know whether TWL_FIRM is the one responsible for this. Maybe the DSi games themselves have hardcoded offsets for TWL NAND, which would require DSiWare patching. And trust me, emunand patches aren't the 'Easiest to do'. They require complex modifications, and even then we can't make sure it works.

I meant "relatively" easy compared to the other options. I know that reverse-engineering stuff like this is hard, especially considering it took over 4 years for A9LH to happen.

 

[mid-kid]

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?

Sorry for the late response. Saw your post just before going to bed.
First question, I've looked into AGB_FIRM (which has the same arm9 code as TWL), and it seems the read/write functions for the NAND are the same, so emuNAND should be doable. I have, however, been unable to locate the sdmmc struct for it, which is vital if we want to chang the pointer to the nand struct to the sdmmc one.
CakesFW and AuReiNAND patch TWL_FIRM and load it through the reboot patches (which are applied to the NATIVE_FIRM code that's in charge of rebooting into different FIRMs). You should look at the code for both CFWs, but it's just a regular firmlaunch like we do for NATIVE_FIRM. Hell, if the environment is set up correctly, it could be possible to autoboot into TWL_FIRM, skipping NATIVE_FIRM and home menu completely.

 

[Wolfvak]

I meant "relatively" easy compared to the other options. I know that reverse-engineering stuff like this is hard, especially considering it took over 4 years for A9LH to happen.

First off, 4 years only for true coldboot ACE is an insanely low number, which keeps popping up now that consoles have huge OS' behind them. But that's just my little rant on newer gen consoles (long live PS2 / GC!)

Secondly, yeah, reverse-engineering stuff is *really* hard, especially when there's no one really interested in this. Personally I'm not interested in DS romz but I was on some DSi enhanced homebrew, like cQuake or GameYob(better than the 3DS one tbh).

Short term answer: Get a cheap flashcart to play your romz
Long term answer: Wait until more stuff is RE'd

 

[RednaxelaNnamtra]

Easy & Short Answer (TM) : 'No'

Long answer: wtf are you even talking about? The ARM11 is completely disabled when it launches, and it isn't disabled by the TWL_FIRM, it disables itself. And please, I'm begging you, read this http://3dbrew.org/wiki/ARM7_Registers

And again: DS games read directly from the cart port, using the ARM9. SD / NAND access is provided by the ARM7. Newer DS -> DSi recompilations probably get away with buffering (I mean, they have 12MB free, they gotta do something with them), and as such don't lag. However, if we could, by some black magic get our own DSi recompilations we would not only have to patch the read / write functions, we would also have to integrate some sort of disk (I mean SD / NAND, you get the idea) cache so that they don't lag heavily / crash. Some games actually rely on read timings, and will fail if they don't get their data on time.

BTW @dankzegriefer isn't a 'troll', at least in the most strict of definitions. In any case he's the one bringing some facts in here, so he'd be an anti-troll of sorts. His attitude was due to the simple fact that people don't know how to read and rush their conclusions.

the arm11 should not be disabled completely, it is doing the framebuffer coping. I think it was smealum who said this in the dsi hacking thread some time ago. But its limited what the arm11 is possible to do in twl mode.

 

[Wolfvak]

the arm11 should not be disabled completely, it is doing the framebuffer coping. I think it was smealum who said this in the dsi hacking thread some time ago. But its limited what the arm11 is possible to do in twl mode.

Yeah you're right, smealum said it performed all GPU-related operations (copying + scaling). However it is extremely limited as to what it can access.

 

[zhdarkstar]

Sorry for the late response. Saw your post just before going to bed.
First question, I've looked into AGB_FIRM (which has the same arm9 code as TWL), and it seems the read/write functions for the NAND are the same, so emuNAND should be doable. I have, however, been unable to locate the sdmmc struct for it, which is vital if we want to chang the pointer to the nand struct to the sdmmc one.

So would this be a fair analogy of the current situation? We know how a road is built from Point A to Point B. We want to build a road that goes from Point A to Point C instead. Without discounting construction time, the biggest problem is that we don't know where to find Point C on the map.

CakesFW and AuReiNAND patch TWL_FIRM and load it through the reboot patches (which are applied to the NATIVE_FIRM code that's in charge of rebooting into different FIRMs). You should look at the code for both CFWs, but it's just a regular firmlaunch like we do for NATIVE_FIRM. Hell, if the environment is set up correctly, it could be possible to autoboot into TWL_FIRM, skipping NATIVE_FIRM and home menu completely.

What would be the purpose of being able to autoboot into TWL_FIRM like that?

 

[mid-kid]

So would this be a fair analogy of the current situation? We know how a road is built from Point A to Point B. We want to build a road that goes from Point A to Point C instead. Without discounting construction time, the biggest problem is that we don't know where to find Point C on the map.

Pretty much.

What would be the purpose of being able to autoboot into TWL_FIRM like that?

None, just explaining how it's booted by giving an example.

 

[RednaxelaNnamtra]

Yeah you're right, smealum said it performed all GPU-related operations (copying + scaling). However it is extremely limited as to what it can access.

Also people need to keep in mind that we even in ctr mode can't access everything from arm11, for example file access is only possible over arm9.

So would this be a fair analogy of the current situation? We know how a road is built from Point A to Point B. We want to build a road that goes from Point A to Point C instead. Without discounting construction time, the biggest problem is that we don't know where to find Point C on the map.



What would be the purpose of being able to autoboot into TWL_FIRM like that?

this would allow you to start the ds slot gamecards, without the need to boot into the home menu, which would safe much time.

 

[dankzegriefer]

Some people on this forum need to learn to just stop talking when another isn't acting to their standards, rather than spread toxic crap. If somebody is being stupid, not informing themselves, etc, just ignore them. There is no need to spread negativity and make yourself and the forum look bad.

Or some people need to have a small read on 3dbrew. Ignorance is not a good thing.

 

[mgrev]

this seems pretty interesting. good if something comes out of it