Homebrew 'ntrcardhax' / downgrading questions

[dark_samus3]

I made a little typo and said "The FIRM partitions on NAND are not quite the same" when I should have said "The FIRM CXI/BIN from CDN are not quite the same". I ninja edited that out after you had quoted me.

Haha, I got what you meant in any case... Still I think we should start stockpiling images... mainly we need 10.2, maybe 9.2 and a few others that are interesting, I'd totally like a hardmod solution that isn't patchable without a hardware revision (which is basically what we have now, we just don't really have any public info on how to exploit it properly)

 

[Kitlith]

Well, in any case, I don't plan to try to downgrade for a couple of days. Still sort of hoping that someone will be kind enough to find the interesting things that are needed and I won't have to downgrade to get this whole thing working.

How likely is that? Who knows. Who knows...

At least I know the additional tricks I should do before downgrading. That'll take me somewhere, even if this never does get fully documented... ._.

 

[dark_samus3]

Well, in any case, I don't plan to try to downgrade for a couple of days. Still sort of hoping that someone will be kind enough to find the interesting things that are needed and I won't have to downgrade to get this whole thing working.

How likely is that? Who knows. Who knows...

At least I know the additional tricks I should do before downgrading. That'll take me somewhere, even if this never does get fully documented... ._.

I mean ntrcardhax is arm9 on the latest FW (well at least a fiarly recent one), so there isn't exactly a need to downgrade other than for debugging purposes... Which I understand needing, but you COULD do without it.... once you have any sort of entrypoint figured out you could probably adapt brahma to it and have the rest of the work done for you really... once you have brahma, you can recompile anything to support ntrcardhax fairly easily and, suddenly, there's not a need to downgrade due to having arm9 kernel, you can backup NAND from there and do a bunch of other nice stuff

 

[Kitlith]

I mean ntrcardhax is arm9 on the latest FW, so there isn't exactly a need to downgrade other than for debugging purposes... Which I understand needing, but you COULD do without it.... once you have any sort of entrypoint figured out you could probably adapt brahma to it and have the rest of the work done for you really... once you have brahma, you can recompile anything to support ntrcardhax fairly easily and, suddenly, there's not a need to downgrade due to having arm9 kernel, you can backup NAND from there and do a bunch of other nice stuff

No, no, the point of downgrading would be to get a dump of Process9 so I can debug it on my computer, find out where it crashes when .bss is overwritten, and in general figure out how it ticks, so that a suitable payload can be made for the cartridge (however you decide to do that) and figure out where I need to place the code that ARM9 jumps too. Doing it without a debugger is going "I'm going to brute-force this! And hope I don't brick anything by jumping to code that accidentally writes to NAND!"

Though, as you say, Brahma probably already *has* the place the ARM9 code jumps to. So, I can see where that comes in handy. Still need the debugging for the first bit.

I'm also not going to *ask* for someone to give me a dump because that would be piracy. Or close enough. This forum wouldn't allow it.

EDIT: As a side note about arm9loaderhax: https://github.com/delebile/arm9loaderhax

 

[dark_samus3]

No, no, the point of downgrading would be to get a dump of Process9 so I can debug it on my computer, find out where it crashes when .bss is overwritten, and in general figure out how it ticks, so that a suitable payload can be made for the cartridge (however you decide to do that) and figure out where I need to place the code that ARM9 jumps too. Doing it without a debugger is going "I'm going to brute-force this! And hope I don't brick anything by jumping to code that accidentally writes to NAND!"

Though, as you say, Brahma probably already *has* the place the ARM9 code jumps to. So, I can see where that comes in handy. Still need the debugging for the first bit.

I'm also not going to *ask* for someone to give me a dump because that would be piracy. Or close enough. This forum wouldn't allow it.

Yeah, I see what you're saying. Going in blind would be impossible and, as you say, could result in bricks and many other things.... I think I need to go to sleep before I start saying stupid stuff again lmao

--------------------- MERGED ---------------------------

Also, yeah I've known about that repo for a few days now lol

 

[Aroth]

arm9loaderhax can work on an O3DS.

Pretty sure it can't since the arm9loader itself is a unique bit of software for the N3DS. Its pretty damn hard to exploit something that doesn't exist.

You might be thinking of NTRCardHax, which afaik IS workable on both O3DS and N3DS.

 

[dark_samus3]

Pretty sure it can't since the arm9loader itself is a unique bit of software for the N3DS. Its pretty damn hard to exploit something that doesn't exist.

You might be thinking of NTRCardHax, which afaik IS workable on both O3DS and N3DS.

Nope, arm9loaderhax can be implemented on the o3ds https://github.com/delebile/arm9loaderhax/blob/master/README.md

I think it has to do with the fact that arm9loader is actually built into the FIRM image and the bootrom is exactly the same between the o3ds and n3ds, so it tries to load the n3ds firm which loads arm9loader and then arm9loader can be exploited from there...

 

[Vappy]

Pretty sure it can't since the arm9loader itself is a unique bit of software for the N3DS. Its pretty damn hard to exploit something that doesn't exist.

You might be thinking of NTRCardHax, which afaik IS workable on both O3DS and N3DS.

arm9loader doesn't care if it's running on a N3DS or O3DS, it can be installed on and will run on both. Case in point, check delebile's github repo for it, "It works on both New and OLD 3DS."

 

[Aroth]

Alright, I'll help clear some stuff about downgrading up. Downgrading is fairly safe, what most users miss (and doesn't seem to be in any guides) is clearing the update nag BEFORE attempting the downgrade, the update actually puts the new titles in NAND but doesn't actually install them and they need to be cleared to properly downgrade... On the downgrading from 10.4/10.5 it is theoretically possible, since Ninty is nice enough to give us NATIVE_FIRMs to download right from their site you simply get the unencrypted (read: the not console specifically encrypted, the actual firmware is still encrypted though... Confusing I know) version of the firm you currently have installed and XOR it with the firm0 partition to generate an XORpad and then get the 10.2 firm and encrypt it with the XORpad that was generated and slap it back into the firm0 slot, you now have the, exploitable, 10.2 NATIVE_FIRM installed and can downgrade from that point on... Combine that with arm9loaderhax and we now have an unpatchable exploit since we can load whatever firmware we want from there. Good luck on your research

While the hardware exploit in question cannot truly be patched, Nintendo CAN make it functionally useless to us by simply updating native_firm (and thus firm0/firm1) with a new minor version number any time they patch an exploit like mch2. They would also need to update a single system title (like the home menu) to check for the updated firm version. The ONLY reason it is of use to us atm is because for some odd reason they only updated the revision number when they patched mch2, which isnt checked by the exheader of titles.

--------------------- MERGED ---------------------------

Nope, arm9loaderhax can be implemented on the o3ds https://github.com/delebile/arm9loaderhax/blob/master/README.md

I think it has to do with the fact that arm9loader is actually built into the FIRM image and the bootrom is exactly the same between the o3ds and n3ds, so it tries to load the n3ds firm which loads arm9loader and then arm9loader can be exploited from there...

arm9loader doesn't care if it's running on a N3DS or O3DS, it can be installed on and will run on both. Case in point, check delebile's github repo for it, "It works on both New and OLD 3DS."

Atm I am going to have to assume he is slightly misinformed as it also says "which provides ARM9 code execution directly at the console boot, exploiting a vulnerability present in 9.6+ version of New3DS arm9loader.", which is in line with the comments made by smea and company at 32c3.

I maintain that is is functionally impossible to exploit a process that does not exist, and the arm9loader process DOES NOT EXIST on the O3DS.

 

[dark_samus3]

While the hardware exploit in question cannot truly be patched, Nintendo CAN make it functionally useless to us by simply updating native_firm (and thus firm0/firm1) with a new minor version number any time they patch an exploit like mch2. They would also need to update a single system title (like the home menu) to check for the updated firm version. The ONLY reason it is of use to us atm is because for some odd reason they only updated the revision number when they patched mch2, which isnt checked by the exheader of titles.

Not really... The NATIVE_FIRM is the first thing that loads on boot (well after bootrom ofc), if we exploit it before the home menu and all of the services start we can then do a firmlaunch and launch whatever (patched) firm we like

--------------------- MERGED ---------------------------

Atm I am going to have to assume he is slightly misinformed as it also says "which provides ARM9 code execution directly at the console boot, exploiting a vulnerability present in 9.6+ version of New3DS arm9loader.", which is in line with the comments made by smea and company at 32c3.

I maintain that is is functionally impossible to exploit a process that does not exist, and the arm9loader process DOES NOT EXIST on the O3DS.

OK after a reread of the github link, we actually can inject arm9loader into the o3ds (see the part about injecting 0x96 area of NAND) and since the bootrom is exactly the same (you can find that on 3dbrew) it stands to reason we can inject arm9loader into NAND and make the o3ds use it (imagine that, using arm9loader, the thing that was made to provide more security, against them)

 

[Aroth]

Not really... The NATIVE_FIRM is the first thing that loads on boot (well after bootrom ofc), if we exploit it before the home menu and all of the services start we can then do a firmlaunch and launch whatever (patched) firm we like

Keep in mind that if you launch a firm with a major/minor version number lower than the one being checked for in the exheaders, you will have titles that do not load. This is why we can only use it to replace firm0/firm1 with different REVISIONS, but not different VERSIONS. Firmlaunch will not let you load a 9.6+ set of system titles and modules using a firm with a version of 2.49-0, period. 9.6+ titles will ONLY load if the firm being loaded has a version of 2.50-x.

 

[dark_samus3]

Keep in mind that if you launch a firm with a major/minor version number lower than the one being checked for in the exheaders, you will have titles that do not load. This is why we can only use it to replace firm0/firm1 with different REVISIONS, but not different VERSIONS. Firmlaunch will not let you load a 9.6+ set of system titles and modules using a firm with a version of 2.49-0, period. 9.6+ titles will ONLY load if the firm being loaded has a version of 2.50-x.

So... Launch the correct firm (using a CFW and a firmware.bin) when doing a firmlaunch...

 

[Aroth]

OK after a reread of the github link, we actually can inject arm9loader into the o3ds (see the part about injecting 0x96 area of NAND) and since the bootrom is exactly the same (you can find that on 3dbrew) it stands to reason we can inject arm9loader into NAND and make the o3ds use it (imagine that, using arm9loader, the thing that was made to provide more security, against them)

Fair enough, if they are somehow injecting the arm9loader thread into an O3DS then it could, in theory, work. Seems kinda iffy though.

--------------------- MERGED ---------------------------

So... Launch the correct firm (using a CFW and a firmware.bin) when doing a firmlaunch...

You misunderstand how firmlaunch works. The firmware.bin file that a cfw loads using firmlaunch is functionally the same as the contents of the firm0/firm1 partitions. In no way does firmlaunch allow you to to bypass the firm check done by the exheader of a title. The only way you could even manage firmlaunch that early in the boot cycle is by exploiting the arm9loader process, which would negate the entire point of the firm0/firm1 downgrade process since you have unsigned arm9 code execution.

 

[dark_samus3]

Fair enough, if they are somehow injecting the arm9loader thread into an O3DS then it could, in theory, work. Seems kinda iffy though.

--------------------- MERGED ---------------------------



You misunderstand how firmlaunch works. The firmware.bin file that a cfw loads using firmlaunch is functionally the same as the contents of the firm0/firm1 partitions. In no way does firmlaunch allow you to to bypass the firm check done by the exheader of a title. The only way you could even manage firmlaunch that early in the boot cycle is by exploiting the arm9loader process, which would negate the entire point of the firm0/firm1 downgrade process since you have unsigned arm9 code execution.

My point is, we can keep the system on a 10.2 firm, that way we don't have to worry about changing the partition out (since it has our payload in it) then use arm9loaderhax to perform a firmlaunch (already possible since it uses an adapted version of Brahma) and boot whatever firm we want, that way we can have an updated sysNAND on the latest firmware, yet keep the arm9loaderhax intact... Not to mention that arm9loaderhax adds a layer of protection (since even if whatever important system title is screwed up because of fiddling you can still boot into an emuNAND)

 

[Aroth]

My point is, we can keep the system on a 10.2 firm, that way we don't have to worry about changing the partition out (since it has our payload in it) then use arm9loaderhax to perform a firmlaunch (already possible since it uses an adapted version of Brahma) and boot whatever firm we want, that way we can have an updated sysNAND on the latest firmware, yet keep the arm9loaderhax intact... Not to mention that arm9loaderhax adds a layer of protection (since even if whatever important system title is screwed up because of fiddling you can still boot into an emuNAND)

That is not the same as "an exploit that can never be patched". That is simply staying on an exploitable firmware, which is no different than what we have been telling people to do since gateway first announced their flashcart years ago.

There are a number of problems with your idea of keeping the firm on 2.50-11 (the 10.2 version) while allowing the system itself to update. Namely that any update to the system will invariably update the firm0/firm1 partitions with the newer version of the firm unless you have firmlaunch enabled and if firmlaunch is enabled the update will brick.

In theory for what you are suggesting to work, we would have to ALWAYS use firmlaunch, regardless of whether we are booting into sysnand or emunand. Any updates would then fail to overwrite the firm partitions, which results in a brick. If I understand the way firmlaunch works though the brick is a result of the system trying to load updated system titles with an out of date firm. If you replace the firm file being loaded by firmlaunch with the updated one that was supposed to be installed to the firm partitions... that SHOULD work. In theory.

Actually in this scenario you would probably be using firmlaunch to patch out signature checks as well and would essentially have no need for emunand as everything would run form the fully updated sysnand with the patched firm being loaded via firmlaunch. And since you would have to have a hard mod to enable the direct flashing of firm0/firm1 in the first place (not to mention its all but required to obtain the unique OTP register of your console), you have an easy way to fix things if a problem occurs.

edit:

Actually the more I look at it, the closer this sounds to being the closest thing to a TRUE custom firmware (akin to what we had on the psp/ps3) than anything else we have had in the past. Too bad it requires dumping the console unique OTP register. Which for a N3DS requires downgrading to 1.0. Which, from what I understand, is a VERY noob unfriendly process.

 

[dark_samus3]

That is not the same as "an exploit that can never be patched". That is simply staying on an exploitable firmware, which is no different than what we have been telling people to do since gateway first announced their flashcart years ago.

There are a number of problems with your idea of keeping the firm on 2.50-11 (the 10.2 version) while allowing the system itself to update. Namely that any update to the system will invariably update the firm0/firm1 partitions with the newer version of the firm unless you have firmlaunch enabled and if firmlaunch is enabled the update will brick.

In theory or what you are suggesting to work, we would have to ALWAYS use firmlaunch, regardless of whether we are booting into sysnand or emunand. Any updates would then fail to overwrite the firm partitions, which results in a brick. If I understand the way firmlaunch works though the brick is a result of the system trying to load updated system titles with an out of date firm. If you replace the firm file being loaded by firmlaunch with the updated one that was supposed to be installed to the firm partitions... that SHOULD work. In theory.

Actually in this scenario you would be using firmlaunch to patch out signature checks as well and would essentially have no need for emunand as everything would run form the fully updated sysnand with the patched firm being loaded via firmlaunch. And since you would have to have a hard mod to enable the direct flashing of firm0/firm1 in the first place, you have an easy way to fix things if a problem occurs.

Well, maybe I got a little carried away with the "unpatchable" thing haha, however the update thing would mean we stop updating via system settings and use sysupdater and a CIA pack without the NATIVE_FIRM cia which keeps the firm where it is and updates the rest of the system... And yeah I do see your point about emuNAND not needing to be accessed since the user has a hardmod, kinda forgot about that one (doh!) Also, firmlaunch doesn't disable updating the firm partitions, it was actually done that way on purpose by gateway (case in point, pastaCFW uses firmlaunch and is still able to update the sysNAND just fine)

 

[Aroth]

Well, maybe I got a little carried away with the "unpatchable" thing haha, however the update thing would mean we stop updating via system settings and use sysupdater and a CIA pack without the NATIVE_FIRM cia which keeps the firm where it is and updates the rest of the system... And yeah I do see your point about emuNAND not needing to be accessed since the user has a hardmod, kinda forgot about that one (doh!) Also, firmlaunch doesn't disable updating the firm partitions, it was actually done that way on purpose by gateway (case in point, pastaCFW uses firmlaunch and is still able to update the sysNAND just fine)

In regards to firmlaunch, my understanding was that pastaCFW (which does not support emunand at all) does not actually use firmlaunch. In fact whenever the topic of updating sysnand comes up, the big thing is "don't do it with something that uses firmlaunch, or you will brick". Granted I am unsure how someone would patch the signature checks out of firm without firmlaunch, but going by what everyone else seems to say/suggest, this is probably what is going on.

 

[Vappy]

Granted I am unsure how someone would patch the signature checks out of firm without firmlaunch

firmlaunch =/= firmlaunchhax. You can perform the latter without the former (which is what miniPasta https://gbatemp.net/threads/need-hax-2-x-pasta-loader.400752/#post-5756850 does, firmlaunch with sigchecks and nothing else).

 

[dark_samus3]

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

 

[Aroth]

firmlaunch =/= firmlaunchhax. You can perform the latter without the former (which is what miniPasta https://gbatemp.net/threads/need-hax-2-x-pasta-loader.400752/#post-5756850 does, firmlaunch with sigchecks and nothing else).

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?