Hacking Possible leadway to downgrade 10.5.0.30u

[VirusX2]

No one should be sharing Nand dumps your just asking for your SecureInfo_A to get ripped.

But once i get downgraded my whole sysNand will be flashed right?. Then old Nand.bin will be flashed too. nothings gonna happen after that right?

 

[Aroth]

10.2.0.28u and 10.3.0.28u have the same firmware revision in them , which is shown by the suffix '.28u' .

This is half wrong btw. The "-28U" is only updated when NVer and certain network related features, usually the browser, are updated. It has nothing to do with updating native_firm. If what you said was the case that would mean that native_firm was updated in 10.5.0-30, but it was not. 10.5.0-30 and 10.4.0-29 have the same native_firm.

That said, 10.2 and 10.3 DO use the same native_firm.

 

[princeken09]

Deleted Post.

 

[Raugo]

fbi check de native_firm installed in the fat16 partition not in the firm partition.

 

[Xenon Hacks]

But once i get downgraded my whole sysNand will be flashed right?. Then old Nand.bin will be flashed too. nothings gonna happen after that right?

The point just flew right over your head...

 

[Aroth]

It will not work, the native_firm partition in the emunand is not updated when you update it then the native_firm of your emunand is the native_firm of the version of your sysnand when you create it.

Again, this is half wrong.

Every time you install an update to emunand, it DOES in fact update ALL portions of the "nand" partition you created on your SD card. INCLUDING the native_firm files. What you are referring to the is the fact that cfw does not actually load the native_firm from your emunand partition, but rather from the firmware.bin file on your sd card (or inside the launcher.dat in the case of Gateway). What version this is depends entirely on your CFW of choice. For an O3DS on rxTools it is 9.6 and for Cakes it is 10.2 or 10.4 (not sure which) for N3DS users on rxTools it is 9.5 (i think) and for reinand it is 10.2. Cakes, again, uses 10.2 or 10.4 (not sure which). Gateway uses 10.2 for both.

Depending on whether the files in question are pulling/decrypting from the emunand partition on your sd card or from ram directly, you will either get the updated native_firm from your emunand partition (10.4's assuming your emunand is fully updated) or the one from your cfw's firmware.bin file.

 

[wormdood]

The point just flew right over your head...

i dont think he understands . . .

 

[VirusX2]

i dont think he understands . . .

Yup i don't understand.

 

[Raugo]

Again, this is half wrong.

Every time you install an update to emunand, it DOES in fact update ALL portions of the "nand" partition you created on your SD card. INCLUDING the native_firm files. What you are referring to the is the fact that cfw does not actually load the native_firm from your emunand partition, but rather from the firmware.bin file on your sd card (or inside the launcher.dat in the case of Gateway). What version this is depends entirely on your CFW of choice. For an O3DS on rxTools it is 9.6 and for Cakes it is 10.2 or 10.4 (not sure which) for N3DS users on rxTools it is 9.5 (i think) and for reinand it is 10.2. Cakes, again, uses 10.2 or 10.4 (not sure which). Gateway uses 10.2 for both.

Depending on whether the files in question are pulling/decrypting from the emunand partition on your sd card or from ram directly, you will either get the updated native_firm from your emunand partition (10.4's assuming your emunand is fully updated) or the one from your cfw's firmware.bin file.

No, when you update the emunand update all te cia files (include the native_firm in the fat16 partition) but no the firm0 partition, the firm_launch block the access to this partition. You can check it, create a emunand and extract the native_firm then update the emunand a extract another copy of the native_firm and compare.

 

[princeken09]

Deleted Post.

 

[Aroth]

No, when you update the emunand update all te cia files (include the native_firm in the fat16 partition) but no the firm0 partition, the firm_launch block the access to this partition. You can check it, create a emunand and extract the native_firm then update the emunand a extract another copy of the native_firm and compare.

Read my full post dude. I said you were HALF wrong. Your statement about it not updating the native_firm partition of EMUNAND is incorrect. Namely because firm0/firm1 partitions are separate from the fat16 partition that is dumped/copied by the various tools we use so there IS no "native_firm" partition to update. The native_firm files themselves get updated on the fat16 partition though, and they also never get referenced or used because the native_firm that is loaded into ram when you launch a cfw is the contents of the firmware.bin file your CFW uses.

 

[wormdood]

Yup i don't understand.

its not about the console and the info currently on it . . . its about what is "linked" to it

 

[Aroth]

In any case there seem to be a large number of people putting their devices at high risk in this thread with little to no presence from any of the established and trusted developers in the scene (aside from a single post from @Apache Thunder confirming that the concept behind the process is sound). Many of the people leading this activity seem to be working with a half-assed understanding of the way the 3ds, nand, emunand, firm0/firm1, and all their various updates work.

On top of that there is a LOT of talk of people needing to trade/share files that are against the rules of this forum to share or even request (like dumps of nand or firm partitions, which contain copyrighted files). Aside from all of the potential issues with sharing complete nand dumps (with things like SecureInfo_A, which can be used to clone systems and presents all sorts of issues), the legality of things in this thread is approaching a level where it might be best for it to be taken elsewhere.

 

[Raugo]

Read my full post dude. I said you were HALF wrong. Your statement about it not updating the native_firm partition of EMUNAND is incorrect. Namely because firm0/firm1 partitions are separate from the fat16 partition that is dumped/copied by the various tools we use so there IS no "native_firm" partition to update. The native_firm files themselves get updated on the fat16 partition though, and they also never get referenced or used because the native_firm that is loaded into ram when you launch a cfw is the contents of the firmware.bin file your CFW uses.

Maybe in CFW is different but with gw when you update the emunand the firm0/firm1 partition dont updated. That is why when you inject the updated emunand to the sysnand the console bricked.

 

[VirusX2]

its not about the console and the info currently on it . . . its about what is "linked" to it

I understand now.

 

[Xenon Hacks]

In any case there seem to be a large number of people putting their devices at high risk in this thread with little to no presence from any of the established and trusted developers in the scene (aside from a single post from @Apache Thunder confirming that the concept behind the process is sound). Many of the people leading this activity seem to be working with a half-assed understanding of the way the 3ds, nand, emunand, firm0/firm1, and all their various updates work.

On top of that there is a LOT of talk of people needing to trade/share files that are against the rules of this forum to share or even request (like dumps of nand or firm partitions, which contain copyrighted files). Aside from all of the potential issues with sharing complete nand dumps (with things like SecureInfo_A, which can be used to clone systems and presents all sorts of issues), the legality of things in this thread is approaching a level where it might be best for it to be taken elsewhere.

Booh! That's no fun

 

[duwen]

In any case there seem to be a large number of people putting their devices at high risk in this thread with little to no presence from any of the established and trusted developers in the scene (aside from a single post from @Apache Thunder confirming that the concept behind the process is sound). Many of the people leading this activity seem to be working with a half-assed understanding of the way the 3ds, nand, emunand, firm0/firm1, and all their various updates work.

On top of that there is a LOT of talk of people needing to trade/share files that are against the rules of this forum to share or even request (like dumps of nand or firm partitions, which contain copyrighted files). Aside from all of the potential issues with sharing complete nand dumps (with things like SecureInfo_A, which can be used to clone systems and presents all sorts of issues), the legality of things in this thread is approaching a level where it might be best for it to be taken elsewhere.

I think the lack of understanding goes further than that - it seems there's a lot of people here excited that they may get to downgrade their 10.5 consoles, without even realizing that they need a hard mod to do so.

 

[Aroth]

Maybe in CFW is different but with gw when you update the emunand the firm0/firm1 partition dont updated. That is why when you inject the updated emunand to the sysnand the console bricked.

This is why it is unsafe to update sysnand from inside gw mode (or rxmode, or any other "mode" with firm_launch enabled). Because it does not fully update the system. This is the same with either cfw or gw (and gw IS a cfw, regardless of what anyone might think). And this goes back to what I said about the "leads" on this "project" having a half-assed understanding of the way things work. You actually CAN restore an emunand backup to your sysnand. At most you will have a soft-brick that requires you to update with from safe_mode, but all of the files and extdata from your emunand will be present on your sysnand once it boots. You likely won't be able to use any of it since most of the games will have invalid tickets and require signature patches, and chances are your emunand was higher than 9.2 so you would have no way to patch the signature checks. We don't tell people not to restore emunand to sysnand because its unsafe. We tell people not to do it because it serves absolutely no purpose other than to cost you access to arm9 exploits.

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

I think the lack of understanding goes further than that - it seems there's a lot of people here excited that they may get to downgrade their 10.5 consoles, without even realizing that they need a hard mod to do so.

Exactly. This ENTIRE process revolves around being able to perform a modification that many people have broken their system trying. Hell someone did that very thing in this thread. Hardmods are NOT something that ANYONE can do. You need access to soldering tools and skills, and not just "i melted two wires together herrrr" but a level of skill with a soldering iron that most people do not get without a LOT of practice and training.The contacts on a 3DS (even an XL) are VERY small and it is VERY easy to short something by using too much solder or the wrong kind or too big of a tip, etc. Not to mention the risk of doing what the guy in this thread did and getting the board so hot that other components lift up and break their contacts.

That said, when done correctly and by someone with sufficient skill with a soldering iron, they are perfectly safe and extremely useful.

On top of all that we have people who think that the trailing part of the version number (currently -30U/E/J) refers to the native firm update. There are people who apparently think that native_firm is never updated beyond what your sysnand uses. They don't understand what is updated and when, or how it gets updated when it does get updated.

 

[Raugo]

This is why it is unsafe to update sysnand from inside gw mode (or rxmode, or any other "mode" with firm_launch enabled). Because it does not fully update the system. This is the same with either cfw or gw (and gw IS a cfw, regardless of what anyone might think). And this goes back to what I said about the "leads" on this "project" having a half-assed understanding of the way things work. You actually CAN restore an emunand backup to your sysnand. At most you will have a soft-brick that requires you to update with from safe_mode, but all of the files and extdata from your emunand will be present on your sysnand once it boots. You likely won't be able to use any of it since most of the games will have invalid tickets and require signature patches, and chances are your emunand was higher than 9.2 so you would have no way to patch the signature checks. We don't tell people not to restore emunand to sysnand because its unsafe. We tell people not to do it because it serves absolutely no purpose other than to cost you access to arm9 exploits.

No, when you updated the emunand all the system updated well except the firm0 firm1 partition, if you have a xorpad of your firm0/firm1 partition you can change the firm0/firm1 with a version valid for your emunand version and you can inject it to the sysnand without problems. @Apache Thunder can corrobarete it, he taught me this method long time ago

 

[EMKBRO]

If the decrypt 9 only runs on version 9.2 <, how i can decrypt the cia?
Sorry for the bad english