See https://github.com/Plailect/Guide/wiki/Hardmod-Downgrade

 

[piratesephiroth]

Why use 10.2 NATIVE FIRM?
Why not cut out the middle man and use 9.2 NATIVE FIRM?

I don't think all firms are compatible. Remember the bricks from incomplete downgrades.

 

[vb_encryption_vb]

Try replacing ctrtool with the one from here: https://github.com/profi200/Project_CTR/releases/download/0.15/makerom_015_ctrtool.zip

I did that, but later down the line I encountered the error again at xor.exe it was dll related, once I swapped the .dll with the correct one all issues were solved and it patched properly.

Why use 10.2 NATIVE FIRM?
Why not cut out the middle man and use 9.2 NATIVE FIRM?

Can only change in small increments, someone with better understanding will come along and explain I bet.

 

[dankzegriefer]

I don't think all firms are compatible. Remember the bricks from incomplete downgrades.

If you can get this level of NAND injection, why not just replace everything with the 9.2 version?

 

[DarkFlare69]

I did that, but later down the line I encountered the error again at xor.exe it was dll related, once I swapped the .dll with the correct one all issues were solved and it patched properly.



Can only change in small increments, someone with better understanding will come along and explain I bet.

Yeah, i did that to and am getting the same xor.exe error as you. Mind sending me your xor.exe file?

 

[Plailect]

Why use 10.2 NATIVE FIRM?
Why not cut out the middle man and use 9.2 NATIVE FIRM?

NATIVE_FIRM is updated to both different versions and different revisions. This can only take us between revisions, not versions, so we can only go between smaller updates like from 10.5 to 10.2, then we let memchunkhax2 do the rest.

 

[piratesephiroth]

If you can get this level of NAND injection, why not just replace everything with the 9.2 version?

I think this is only possible becuase NATIVE_FIRM is in a different partition, in a fixed place, and its encryption method is known.

 

[Plailect]

If you can get this level of NAND injection, why not just replace everything with the 9.2 version?

Basically, the FIRM partitions in your NAND are encrypted specifically to your console and we can't edit them. Fortunately for us, Nintendo's implementation of this is flawed and allows us to compare the decrypted 10.4 NATIVE_FIRM (which we can get using decrypt9 on any 3DS below 9.2) with the encrypted 10.4 NATIVE_FIRM in your NAND.bin in order to then reencrypt the decrypted 10.2 NATIVE_FIRM before injecting it into the NAND.

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

I think this is only possible becuase NATIVE_FIRM is in a different partition, in a fixed place, and its encryption method is known.

Yes. For more info, read the "FIRM partitions known-plaintext" part here: https://www.3dbrew.org/wiki/3DS_System_Flaws

 

[Plailect]

I have updated the post with the DLL @vb_encryption_vb used to hopefully fix some issues people were having.

 

[vb_encryption_vb]

I have updated the post with the DLL @vb_encryption_vb used to hopefully fix some issues people were having.

Might wanna put a comment next to it saying to leave it in the directory that autofirm is in. I put it in system32 / syswow64 like you normally would and it wouldn't register. Video is almost published to youtube as well.

 

[Plailect]

Might wanna put a comment next to it saying to leave it in the directory that autofirm is in. I put it in system32 / syswow64 like you normally would and it wouldn't register. Video is almost published to youtube as well.

That's step 6.
"6. Place the msvcr120d.dll file in the autofirm folder"

 

[Aroth]

@dankzegriefer

The only thing we can actually alter/inject is the firm0/firm1 partitions. @Plailect does a decent enough job explaining this in the post above mine, but basically the decrypted contents of firm0/firm1 are completely identical between any two O3DS/2DS systems that are on the same system version and between any two N3DS systems on the same system version. However the remaining contents of the NAND chip, particularly CTRNAND (which is the other part you would need to replace to affect a complete downgrade), differ from console to console. Each console contains unique data for several files in the CTRNAND partition (files like movable_sed, secureinfo_a, title.db, among others) which make it impossible to do a direct inject of a CTRNAND partition from another console. You can inject an old (say 9.2) CTRNAND dump from your console with minimal issues assuming you have a hardmod or other method for writing to the NAND chip. The purpose of this, however, is for people who do not have such a NAND dump to begin with.

As for why we can't just inject a 9.2 firm0/firm1 dump, that is because of the way the version updates for native_firm are handled. As @Plailect said (again, dude is pretty well informed) native_firm updates can be one of 3 kinds. A MAJOR version change (1.x-x to 2.x-x, which has never actually happened as the initial factory FIRM was 2.3-0), a MINOR version change (2.49-x to 2.50-x, like the update from 9.5 to 9.6) or a REVISION change (2.50-9 to 2.50-11, like the update from 10.2 to 10.4)). Using this method we can actually inject any version of the firm we want, but if we jump between MAJOR or MINOR versions we will cause the system to brick and fail to load the CTRNAND properly. This is because every title on the system does a simple kernel/firm version check on launch and if the check fails then the system hands on the 3DS logo. This version check ONLY looks at MAJOR and MINOR version numbers, while completely ignoring REVISION numbers. The 10.5 titles will launch perfectly fine even if the firm being used is 2.50-1 (the 9.6 version), but if we jump to 2.49-0 (9.5's firm) any system title that has been updated since 9.6 will fail to boot. Since the Home Menu is typically updated in conjunction with updates to native_firm, this means that the home menu will fail to load on boot and you will be stuck with a black screen (aka a bricked system).

I strongly suspect that since we are flashing both firm0 AND firm1, we are probably overwriting the safe_mode native_firm as well, meaning it won't just be a soft brick that you can escape from by updating while in recovery mode. That said since this entire process requires a hard mod for dumping/injecting the contents of the NAND chip, the VERY first step after making the modification should be to create SEVERAL dumps of the chip to compare against each other and ensure proper functioning of the mod, as well as to have a clean backup if you manage to fuck something up.

 

[Apache Thunder]

Why use 10.2 NATIVE FIRM?
Why not cut out the middle man and use 9.2 NATIVE FIRM?

That wouldn't work. That would only be good at making a brick. Remember how most of the last year we couldn't boot a 9.5+ emunand? Because we couldn't use a 9.6+ native_firm. Imagine that scenerio on sysnand. A 9.2 FIRM will not boot a 10.4/10.5 system for the same reason. The crypto changed and too many of the system titles rely on it. You might be able to downgrade FIRM to 9.2, but the console won't boot anymore and you need to be able to boot it if you want to properly downgrade it.

 

[DarkFlare69]

Might wanna put a comment next to it saying to leave it in the directory that autofirm is in. I put it in system32 / syswow64 like you normally would and it wouldn't register. Video is almost published to youtube as well.

Can I have the right xor.exe?

 

[vb_encryption_vb]

Can I have the right xor.exe?

Put the dll file in the same directory and it should work with no issues. DLL can be found on first page as of a few mins ago in the directions.

 

[DarkFlare69]

Put the dll file in the same directory and it should work with no issues. DLL can be found on first page as of a few mins ago in the directions.

I did that before even downloading the new ctrtool. Still get 0xc000007b.

 

[Aroth]

That wouldn't work. That would only be good at making a brick. Remember how most of the last year we couldn't boot a 9.5+ emunand? Because we couldn't use a 9.6+ native_firm. Imagine that scenerio on sysnand. A 9.2 FIRM will not boot a 10.4/10.5 system for the same reason. The crypto changed and too many of the system titles rely on it. You might be able to downgrade FIRM to 9.2, but the console won't boot anymore and you nee to be able to boot it if you want to properly downgrade it.

The crypto change was why we couldn't use a 9.6+ firm. We couldn't use a 9.6+ system update because we couldn't use the 9.6+ firm and several important system titles (including the home menu) were checking against the new firm when launched and would then fail to launch upon seeing a lower firm. This is the same thing that would happen if someone injected a 9.5 or lower firm partition to a 10.4/10.5 system.

 

[vb_encryption_vb]

I did that before even downloading the new ctrtool. Still get 0xc000007b.

Hmm I'm not sure than, once I put that file in the root directory all my errors went away. I'm on win7 64bit. I also rebooted my pc.

 

[Plailect]

@dankzegriefer

The only thing we can actually alter/inject is the firm0/firm1 partitions. @Plailect does a decent enough job explaining this in the post above mine, but basically the decrypted contents of firm0/firm1 are completely identical between any two O3DS/2DS systems that are on the same system version and between any two N3DS systems on the same system version. However the remaining contents of the NAND chip, particularly CTRNAND (which is the other part you would need to replace to affect a complete downgrade), differ from console to console. Each console contains unique data for several files in the CTRNAND partition (files like movable_sed, secureinfo_a, title.db, among others) which make it impossible to do a direct inject of a CTRNAND partition from another console. You can inject an old (say 9.2) CTRNAND dump from your console with minimal issues assuming you have a hardmod or other method for writing to the NAND chip. The purpose of this, however, is for people who do not have such a NAND dump to begin with.

As for why we can't just inject a 9.2 firm0/firm1 dump, that is because of the way the version updates for native_firm are handled. As @Plailect said (again, dude is pretty well informed) native_firm updates can be one of 3 kinds. A MAJOR version change (1.x-x to 2.x-x, which has never actually happened as the initial factory FIRM was 2.3-0), a MINOR version change (2.49-x to 2.50-x, like the update from 9.5 to 9.6) or a REVISION change (2.50-9 to 2.50-11, like the update from 10.2 to 10.4)). Using this method we can actually inject any version of the firm we want, but if we jump between MAJOR or MINOR versions we will cause the system to brick and fail to load the CTRNAND properly. This is because every title on the system does a simple kernel/firm version check on launch and if the check fails then the system hands on the 3DS logo. This version check ONLY looks at MAJOR and MINOR version numbers, while completely ignoring REVISION numbers. The 10.5 titles will launch perfectly fine even if the firm being used is 2.50-1 (the 9.6 version), but if we jump to 2.49-0 (9.5's firm) any system title that has been updated since 9.6 will fail to boot. Since the Home Menu is typically updated in conjunction with updates to native_firm, this means that the home menu will fail to load on boot and you will be stuck with a black screen (aka a bricked system).

I strongly suspect that since we are flashing both firm0 AND firm1, we are probably overwriting the safe_mode native_firm as well, meaning it won't just be a soft brick that you can escape from by updating while in recovery mode. That said since this entire process requires a hard mod for dumping/injecting the contents of the NAND chip, the VERY first step after making the modification should be to create SEVERAL dumps of the chip to compare against each other and ensure proper functioning of the mod, as well as to have a clean backup if you manage to fuck something up.

Excellent writeup. I was trying my best to stay at least a little legible to the less technically inclined, but if anyone wants more info I'll definitely link them to this.

 

[DarkFlare69]

Hmm I'm not sure than, once I put that file in the root directory all my errors went away. I'm on win7 64bit. I also rebooted my pc.

Well i downloaded one from dll-files and it worked.

But now i did all steps and my fucking nand is unmodified. I did as file compare in HxD and the "new" nand with "10.2 native firm" is the exact same as my original one.

 

[Xenon Hacks]

Well i downloaded one from dll-files and it worked.

But now i did all steps and my fucking nand is unmodified. I did as file compare in HxD and the "new" nand with "10.2 native firm" is the exact same as my original one.

Try running things as admin and disabling UAC