Homebrew 'ntrcardhax' / downgrading questions

[dark_samus3]

Pasta (and rxTools pastaMode) use firmlaunchhax to patch the signature checks, but they are not actually using the process we refer to as firmlaunch to load a firm from the sd card? That about right?

Well kinda... Firmlaunch is actually something built into the 3ds (like when booting into MHX or Smash, a firmlaunch is performed by the system, mainly to try to defeat CFWs from loading them as CIAs properly) so basically we firmlaunch the FIRM in NAND and go from there... The bricks come from either A. Gateway mode forces firm installations to be blocked or B. Using a higher firm version (the firmware.bin) than you're trying to install, resulting in a rejection and possible brick

 

[Aroth]

Well kinda... Firmlaunch is actually something built into the 3ds (like when booting into MHX or Smash, a firmlaunch is performed by the system, mainly to try to defeat CFWs from loading them as CIAs properly) so basically we firmlaunch the FIRM in NAND and go from there... The bricks come from either A. Gateway mode forces firm installations to be blocked or B. Using a higher firm version (the firmware.bin) than you're trying to install, resulting in a rejection and possible brick

Except its not just gateway. If you are using a cfw that loads a firmware.bin file from the sd card and you use it to access sysnand and update it (typically done to go from 4.x-8.x to 9.2) it will brick. rxMode sysnand will do this just the same as GWMode, because it uses firmlaunch to load the file from the sd card. Afaik this loading is what blocks the firm partitions form updating properly. When it goes to write the new data to them, the calls being hijacked by firmlaunch redirect the write attempt to the sd card instead of the firm0/firm1 partitions.

 

[dark_samus3]

Except its not just gateway. If you are using a cfw that loads a firmware.bin file from the sd card and you use it to access sysnand and update it (typically done to go from 4.x-8.x to 9.2) it will brick. rxMode sysnand will do this just the same as GWMode, because it uses firmlaunch to load the file from the sd card. Afaik this loading is what blocks the firm partitions form updating properly. When it goes to write the new data to them, the calls being hijacked by firmlaunch redirect the write attempt to the sd card instead of the firm0/firm1 partitions.

Well the update button in sysupdater assumes that you're not needing to downgrade anything, so if I, say, load a higher NATIVE_FIRM than the one I'm installing, it'll try to install it, fail because of the higher version, and result in a brick... Also I don't believe that firm loading is redirected to the SD card, I'm pretty sure (not 100%, so I could always be wrong) that the FIRM is just loaded into RAM from the SD and launched from there, after being patched ofc (the actual firmware.bin isn't touched on your SD card by any CFW, yet it is patched. Which pretty much confirms my theory there)

 

[Aroth]

Well the update button in sysupdater assumes that you're not needing to downgrade anything, so if I, say, load a higher NATIVE_FIRM and the one I'm installing it'll try to install it, fail because of the higher version, and result in a brick... Also I don't believe that firm loading is redirected to the SD card, I'm pretty sure (not 100%, so I could always be wrong) that the FIRM is just loaded into RAM from the SD and launched from there, after being patched ofc (the actual firmware.bin isn't touched on your SD card by any CFW, yet it is patched. Which pretty much confirms my theory there)

Actually yeah, the sysupdater thing make sense. It sees that the native_firm version is higher than the one being installed is so it skips it. Then the system "bricks" trying to launch 9.x titles with a 4.x-8.x native firm, causing the firm check in the exheaders to fail.

There is probably something more going on that explains why Cartridge Updates cause bricks in sysnand with GW Mode, but that is probably irrelevant to this discussion.

The question then is if running using the system update option in system settings (or performing a cartridge update) in rxMode sysnand will cause a brick. If so then there is more to it than just loading the firm into RAM and sysupdater screwing up the install because of mismatched version numbers.

Without a hard mod though I am not particularly inclined to test it myself.

 

[dark_samus3]

Actually yeah, the sysupdater thing make sense. It sees that the native_firm version is higher than the one being installed is so it skips it. Then the system "bricks" trying to launch 9.x titles with a 4.x-8.x native firm, causing the firm check in the exheaders to fail.

There is probably something more going on that explains why Cartridge Updates cause bricks in sysnand with GW Mode, but that is probably irrelevant to this discussion.

The question then is if running using the system update option in system settings (or performing a cartridge update) in rxMode sysnand will cause a brick. If so then there is more to it than just loading the firm into RAM and sysupdater screwing up the install because of mismatched version numbers.

Without a hard mod though I am not particularly inclined to test it myself.

Given that rxTools always loads the higher firmwares from firmware.bin (they pretty much always use the latest one) it'll brick, unless ofc you use either
A. The downgrade option in sysupdater
B. the proper firmware.bin

I should really get around to testing that with my hardmodded console (been meaning to for awhile)

 

[Aroth]

Given that rxTools always loads the higher firmwares from firmware.bin (they pretty much always use the latest one) it'll brick, unless ofc you use either
A. The downgrade option in sysupdater
B. the proper firmware.bin

I should really get around to testing that with my hardmodded console (been meaning to for awhile)

Well using sysupdater will obviously brick it, which is to be expected. My question is what would happen if you loaded up rxMode sysnand, then went into system settings and told it to update to 10.5? Granted no one in their right mind would do this unless they had a hard mod and were looking to test this very thing since they would lose access to their cfw and emunand.

The question though is does the official system update process do the same version check that sysupdater does? Or does it just assume that every title it downloads needs to be installed and overwrites them all, version be damned?

Thinking it through logically, the native_firm title DOES get "installed" to CTRNAND as it is present in all of my nand dumps inside the "titles" folder. Plus the system always reboots and then takes a little longer afterwards to get back to the home menu than it would normally. So after it installs the titles to CTRNAND it is probably doing a soft reboot into a mode that allows it to extract the contents of native_firm and write them to firm0/firm1, then reboots back into a normal mode and loads the home menu.

 

[dark_samus3]

Well using sysupdater will obviously brick it, which is to be expected. My question is what would happen if you loaded up rxMode sysnand, then went into system settings and told it to update to 10.5? Granted no one in their right mind would do this unless they had a hard mod and were looking to test this very thing since they would lose access to their cfw and emunand.

The question though is does the official system update process do the same version check that sysupdater does? Or does it just assume that every title it downloads needs to be installed and overwrites them all, version be damned?

Thinking it through logically, the native_firm title DOES get "installed" to CTRNAND as it is present in all of my nand dumps inside the "titles" folder. Plus the system always reboots and then takes a little longer afterwards to get back to the home menu than it would normally. So after it installs the titles to CTRNAND it is probably doing a soft reboot into a mode that allows it to extract the contents of native_firm and write them to firm0/firm1, then reboots back into a normal mode and loads the home menu.

sysupdater uses the exact same method as system settings does really... It just uses am:u and installs the titles and then installs NATIVE_FIRM, so given that we can currently downgrade NATIVE_FIRM using the "downgrade" button from sysupdater that, in theory, should properly update the NATIVE_FIRM and we can go from there... Again using the proper firmware.bin would allow us to use the update option from anywhere really...

EDIT: I didn't really answer your questions I realized... The versions checks are in the service AM:U and it basically checks and makes sure that the current version is < the version you're trying to install and AM:U is how the settings, cart updates and sysupdater install updates to titles... The check is simply bypassed by uninstalling the title so there is NO version number associated with it, and installing a new version of the title

 

[Aroth]

sysupdater uses the exact same method as system settings does really... It just uses am:u and installs the titles and then installs NATIVE_FIRM, so given that we can currently downgrade NATIVE_FIRM using the "downgrade" button from sysupdater that, in theory, should properly update the NATIVE_FIRM and we can go from there... Again using the proper firmware.bin would allow us to use the update option from anywhere really...

So in theory, running an update from system settings while firmlaunch is loading an updated firmware.bin into ram would result in the update seeing that the existing native_firm is the same as the one slated for install so it skips it? That would make sense considering updates that only change a few titles install MUCH faster than ones that update several titles. (Referring to installation time only, not the time required to download the update.) For instance updating my emunand from 10.4 to 10.5 took about half the time it did to go from 10.3 to 10.4, and there were only like 4 titles updated in 10.5, vs something like 12 or 13 in 10.4.

Sounds like something that needs to be tested with a hard mod, just to be safe, in my opinion. Either way it would be good info to have on hand.

That said I am exhausted and its after 3am here (can't be much earlier where you are, and maybe even later lol) so why don't we shelve this discussion for now?

 

[dark_samus3]

So in theory, running an update from system settings while firmlaunch is loading an updated firmware.bin into ram would result in the update seeing that the existing native_firm is the same as the one slated for install so it skips it? That would make sense considering updates that only change a few titles install MUCH faster than ones that update several titles. (Referring to installation time only, not the time required to download the update.)

Sounds like something that needs to be tested with a hard mod, just to be safe, in my opinion. Either way it would be good info to have on hand.

That said I am exhausted and its after 3am here (can't be much earlier where you are, and maybe even later lol) so why don't we shelve this discussion for now?

Pretty much yeah (see my edit above regarding this) and also it's 4:30 am here haha (I just sleep in the daytime and do stuff at night because I can't seem to get on a regular sleep schedule for some reason ) anyways get some sleep, I'll be here tomorrow

 

[Kitlith]

Sounds like a nice theory going on, @dark_samus3 and @Aroth. Should there be another thread for this? I don't mind it, though.

Anyway... I'm planning on downgrading either today or tomorrow. After I do so, I'm either going to use this or Decrypt9 to attempt to dump Process9 so that I can debug it... somehow... ._. and find the offset from the beginning of the DS card header that needs to be used. One question I'm having is "What is the value of R2 in the assembly listed in the talk?" because it seems that would indicate the base address of the buffer that is being read into. Well, I guess I'll find out soon, along with any interesting stuff in the .bss section.

The plan of attack afterwards would be to make the payload loading bit of Brahma work with memchunkhax2, assuming I can get it to jump to the same place and do whatever extra required setup. Unfortunately, I don't think I understand what Brahma is doing well enough to do any porting myself... ._.

 

[dark_samus3]

Sounds like a nice theory going on, @dark_samus3 and @Aroth. Should there be another thread for this? I don't mind it, though.

Anyway... I'm planning on downgrading either today or tomorrow. After I do so, I'm either going to use this or Decrypt9 to attempt to dump Process9 so that I can debug it... somehow... ._. and find the offset from the beginning of the DS card header that needs to be used. One question I'm having is "What is the value of R2 in the assembly listed in the talk?" because it seems that would indicate the base address of the buffer that is being read into. Well, I guess I'll find out soon, along with any interesting stuff in the .bss section.

The plan of attack afterwards would be to make the payload loading bit of Brahma work with memchunkhax2, assuming I can get it to jump to the same place and do whatever extra required setup. Unfortunately, I don't think I understand what Brahma is doing well enough to do any porting myself... ._.

memchunkhax2 should work just fine with brahma (just replace the libkhax version in the folder with the one that supports memchunkhax2 and compile, there shouldn't be any errors... (there wasn't when I did this some time ago)) Also:

Hmm... I'm wondering if the arm9loader can be updated, I'm guessing it can (how else would they have made 9.6+ emuNAND not work for so long) though I may be wrong. And if they CAN update it, can we use the same trick as with the firm to get an XORpad (I'm guessing Ninty was smart enough not to use that type of encryption, though I may be wrong) and plop the old version into NAND? THAT would be the truely unpatchable exploit

still wondering about that, though that's probably best for another thread...

 

[Aurora Wright]

I guess a way to test this with an hardmodded console would be using my ReiNand mod by holding L+R on boot, this decrypts the FIRM0 from NAND, loads it into RAM, patches signature checks and then firmlaunches it. This would rule out firmlaunch being at fault and would confirm the darm_samus3 theory.

 

[dark_samus3]

I guess a way to test this with an hardmodded console would be using my ReiNand mod by holding L+R on boot, this decrypts the FIRM0 from NAND, loads it into RAM, patches signature checks and then firmlaunches it. This would rule out firmlaunch being at fault and would confirm the darm_samus3 theory.

I really need to get my 3ds back up and running so I can test this out... my console still needs to be updated to 9.2 so it would be the perfect opportunity to test, though I'm not sure when I'll get it running again :/

 

[Aroth]

I guess a way to test this with an hardmodded console would be using my ReiNand mod by holding L+R on boot, this decrypts the FIRM0 from NAND, loads it into RAM, patches signature checks and then firmlaunches it. This would rule out firmlaunch being at fault and would confirm the darm_samus3 theory.

Sounds like the sysnand mode in your reinand mod functions exactly like miniPasta in that regard. In which case there should be no bricks on an update attempt. What needs to be tested is booting into rxMode sysnand (with rxTools) and updating sysnand to 10.5 via system settings. Obviously you should ONLY attempt this with a hardmod.

Sounds like a nice theory going on, @dark_samus3 and @Aroth. Should there be another thread for this? I don't mind it, though.

Not really sure how we got onto a discussion about arm9loader in a thread about ntrcardhax.

 

[Aurora Wright]

Sounds like the sysnand mode in your reinand mod functions exactly like miniPasta in that regard. In which case there should be no bricks on an update attempt. What needs to be tested is booting into rxMode sysnand (with rxTools) and updating sysnand to 10.5 via system settings. Obviously you should ONLY attempt this with a hardmod.



Not really sure how we got onto a discussion about arm9loader in a thread about ntrcardhax.

No, MiniPasta gains ARM9 access, patches signature checks in RAM the currently running FIRM and then returns control to it (no firmlaunch at all)

 

[Kitlith]

Not really sure how we got onto a discussion about arm9loader in a thread about ntrcardhax.

I think because I mentioned the possibility of downgrading from 10.5 using hardmod, which someone replied with the possibility of setting up a permanent arm9loaderhax. I think that's how.

Entertaining, really. Though, I don't really want to see a "how far off topic can we be while still being 'on topic'" contest. That would just take it too far.

ANYWAY, Been looking at arm9 simulators, which I'm not sure would work because the 3DS has hardware that these programs probably can't work with, but I found SkyEye, which at least looks neat. Also looks like lioncash was looking at it last year. *shrugs*

I don't know what I need for debugging Process9, I just hope I find it soon.

 

[Aroth]

No, MiniPasta gains ARM9 access, patches signature checks in RAM the currently running FIRM and then returns control to it (no firmlaunch at all)

In that case it would probably work to test the theory then.

I think because I mentioned the possibility of downgrading from 10.5 using hardmod, which someone replied with the possibility of setting up a permanent arm9loaderhax. I think that's how.

Entertaining, really. Though, I don't really want to see a "how far off topic can we be while still being 'on topic'" contest. That would just take it too far.

ANYWAY, Been looking at arm9 simulators, which I'm not sure would work because the 3DS has hardware that these programs probably can't work with, but I found SkyEye, which at least looks neat. Also looks like lioncash was looking at it last year. *shrugs*

I don't know what I need for debugging Process9, I just hope I find it soon.

Out of curiosity, wouldn't an arm9 simulator be the core of any efficient 3ds emulator?

 

[Kitlith]

Out of curiosity, wouldn't an arm9 simulator be the core of any efficient 3ds emulator?

Most efficient 3ds emulators use high level emulation, emulating the behavior of the system rather than requiring you to dump Process9, arm11 kernel, any thing else that may be necessary...
NINJA EDIT: which means that it simulates arm11 userspace, sure, but I don't think it touches arm9. Could be wrong.

 

[Aroth]

Most efficient 3ds emulators use high level emulation, emulating the behavior of the system rather than requiring you to dump Process9, arm11 kernel, any thing else that may be necessary...

Hmm good point.

 

[zoogie]

I think because I mentioned the possibility of downgrading from 10.5 using hardmod, which someone replied with the possibility of setting up a permanent arm9loaderhax. I think that's how.

Entertaining, really. Though, I don't really want to see a "how far off topic can we be while still being 'on topic'" contest. That would just take it too far.

ANYWAY, Been looking at arm9 simulators, which I'm not sure would work because the 3DS has hardware that these programs probably can't work with, but I found SkyEye, which at least looks neat. Also looks like lioncash was looking at it last year. *shrugs*

I don't know what I need for debugging Process9, I just hope I find it soon.

There's xds, which supposedly can boot up with a decrypted nand image or something.
https://github.com/ichfly/XDS
https://gbatemp.net/threads/xds.405121/