Hacking Downgrading for 9.3+ Owners is now a reality!

[Zidapi]

Just wanted to bring this to everyone's attention.

This all started happening in a topic unrelated to downgrading, so it may have gone unnoticed by many.

The process is working fine for old3DS owners, but is a little less reliable for new3DS users.

Some have reported having to try up to 50 times before finally succeeding in downgrading their new3DS. It mostly seems to hang at step 8, if it does, hard reboot and start over until it finally gets passed step 8.

@TheStoneBanana has put together a tutorial here, and @Ptrk25 a quick tutorial specifically aimed at new3DS users here.


Enjoy your free Gateway-free CFW!

 

[Joeli53]

Would anyone be able to explain some of the steps that were linked to for N3DS? I realize I should receive a reply like "if you can't figure it out, then you shouldn't be doing it," but I'm taking a chance someone can provide a step-by-step explanation like this tutorial: https://gbatemp.net/threads/tutoria...including-emunand-coldboot-cia-manager.405589

Download the right n3ds cia files (or extract it from the ttp)
- What are these files and where do we get them?

Install the newest sysupdater homebrew
- Is there a tutorial?

Use menuhax
- Likewise, is there a tutorial?

 

[Aroth]

Does this actually downgrade the NATIVE_FIRM as well?

The homebrews for downgrading have been in a sort of testing phase for several hours, since early this afternoon, but inital attempts found that while the system reported as being on 9.2, no exploits beyond the homebrew entrypoints worked. Apparently process9 was running a version check on installation of NATIVE_FIRM and if the existing FIRM was newer it would skip the install, resulting in a 9.2 3ds with a 10.3 NATIVE_FIRM, and no CFW.

 

[Astoria]

Does this actually downgrade the NATIVE_FIRM as well?

The homebrews for downgrading have been in a sort of testing phase for several hours, since early this afternoon, but inital attempts found that while the system reported as being on 9.2, no exploits beyond the homebrew entrypoints worked. Apparently process9 was running a version check on installation of NATIVE_FIRM and if the existing FIRM was newer it would skip the install, resulting in a 9.2 3ds with a 10.3 NATIVE_FIRM, and no CFW.

Yes. The downgrade is completly functional and allows you to run CFW when you return to 9.2.

 

[Aroth]

Yes. The downgrade is completly functional and allows you to run CFW when you return to 9.2.

Out of curiosity, what was required to fix/bypass the process9 issue?

 

[Zidapi]

Out of curiosity, what was required to fix/bypass the process9 issue?

No idea, I can't read code.

The source is available here if you can (and then explain it for us?)

 

[Ryu Kenshin]

Could I downgrade 2DS? My little sister has a 2DS but there is no one confirm if it could work or not

 

[Zidapi]

Would anyone be able to explain some of the steps that were linked to for N3DS? I realize I should receive a reply like "if you can't figure it out, then you shouldn't be doing it," but I'm taking a chance someone can provide a step-by-step explanation like this tutorial: https://gbatemp.net/threads/tutoria...including-emunand-coldboot-cia-manager.405589

Download the right n3ds cia files (or extract it from the ttp)
- What are these files and where do we get them?

Install the newest sysupdater homebrew
- Is there a tutorial?

Use menuhax
- Likewise, is there a tutorial?

I haven't needed to do it as I've only had exploitable 3DSes. Best to ask in the "unrelated thread" I linked to in my opening post. You'll get plenty of help there

 

[Aroth]

Could I downgrade 2DS? My little sister has a 2DS but there is no one confirm if it could work or not

2DS is virtually identical to the O3DS in every way baring the lack of a 3D screen. Simply use O3DS files and avoid downgrading lower than 6.x and you will be fine.

 

[Ryu Kenshin]

2DS is virtually identical to the O3DS in every way baring the lack of a 3D screen. Simply use O3DS files and avoid downgrading lower than 6.x and you will be fine.

Thanks a lot, mate! I will follow o3ds guide and report later.

 

[Aroth]

No idea, I can't read code.

The source is available here if you can (and then explain it for us?)

So it looks like the fix involved replacing a single if/then qualifier with an extended if/else/then.

Basically the initial attempt would check the result of a AM service call for installing FIRM and based on the result would potentially throw an Exception and fail to install NATIVE_FIRM. The updated code now checks if the user is doing a downgrade first, and if not continues as before. If they are doing a downgrade it sends a slightly different set of info into the AM service call, more or less forcing it to install regardless of the result of the version comparison check done by process9.

 

[Tokiopop]

No idea, I can't read code.

The source is available here if you can (and then explain it for us?)

Edit: never mind, exact changes are here https://github.com/TuxSH/sysUpdater/commit/213aed9407f893c6a2bcc6f650e430b3b288636b?diff=split

 

[Aroth]

Edit: never mind, exact changes are here https://github.com/TuxSH/sysUpdater/commit/213aed9407f893c6a2bcc6f650e430b3b288636b?diff=split

Your initial post was sort of right. From what I can see, before they even do the part listed in that change they actually delete the NATIVE_FIRM from the system, which would most definitely solve the problem of process9 getting pissy about the existing FIRM being newer.

 

[Tokiopop]

Your initial post was sort of right. From what I can see, before they even do the part listed in that change they actually delete the NATIVE_FIRM from the system, which would most definitely solve the problem of process9 getting pissy about the existing FIRM being newer.

Ah, okay. I didn't bother looking up what the system titles were so i wasn't very confident in my assumption. But yeah, for anyone wondering I originally said it deleted a couple of system titles on the nand which I assumed were to do with NATIVE_FIRM, meaning Process9 would have nothing to compare the 'new' NATIVE_FIRM to, allowing it to be downgraded.

I guess they implemented the downgrade earlier but it didn't work until that small change

 

[Aroth]

Ah, okay. I didn't bother looking up what the system titles were so i wasn't very confident in my assumption. But yeah, for anyone wondering I originally said it deleted a couple of system titles on the nand which I assumed were to do with NATIVE_FIRM, meaning Process9 would have nothing to compare the 'new' NATIVE_FIRM to, allowing it to be downgraded.

I guess they implemented the downgrade earlier but it didn't work until that small change

Sounds like it. The titleIDs it tries to delete are 0x0004013800000002LL and 0x0004013820000002LL. 0004013800000002 is the Old 3DS (and 2DS) NATIVE_FIRM, while 0004013820000002 is the New3DS NATIVE_FIRM.

 

[kiryu1]

Does this mean I can now buy N3DSes that are 9.5 - 9.9 and just wait for a stable build?

 

[Aroth]

Does this mean I can now buy N3DSes that are 9.5 - 9.9 and just wait for a stable build?

You can buy ANY New3DS on the market atm and then just wait for a stable build. To my knowledge no new in box system should even have 10.3 yet and this method will work on any system with 10.3 or lower.

 

[Zidapi]

So it looks like the fix involved replacing a single if/then qualifier with an extended if/else/then.

Basically the initial attempt would check the result of a AM service call for installing FIRM and based on the result would potentially throw an Exception and fail to install NATIVE_FIRM. The updated code now checks if the user is doing a downgrade first, and if not continues as before. If they are doing a downgrade it sends a slightly different set of info into the AM service call, more or less forcing it to install regardless of the result of the version comparison check done by process9.

Thank you!

 

[Aroth]

Thank you!

To clarify, it looks like the original code involved grabbing the titleID and version info from the cia to be installed. It would then compare compare the version of the one to be installed to the one on the NAND, and if the NAND version was higher it would delete it, then install the cia in question.

For some reason the if/then statement for throwing an exception when installing NATIVE_FIRM was not working properly and resulted in it never actually installing NATIVE_FIRM. I suspect it was not possible to actually delete NATIVE_FIRM from the NAND, so process9 would then get pissy when you tried to install the new (older) version.

Without a more in-depth understanding of the AM service calls being used, I cannot say for certain what went wrong or why the change from an if statement to an if/else statement fixed it, but it appears to have been the change that solved the problem.

 

[tony_2018]

Good info on how on how the process came to be. Will definitely try to hunt down an n3ds of my choice with some insane high firmware on there.