Homebrew [RELEASE] OTPHelper - OTP dumping & downgrade helper

[Purge]

Incomplete downgrade, I guess. Or rather an incomplete cleanup afterwards. In the standard update process, all new files are first written, then the old ones are deleted and the 'internal links' rewritten to point to the new ones.

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


You need to try the Downgrade Validator, not the NAND Validator

Oh my bad. So should I downgrade sysnand back to 2.1 or should I just test emunand?

 

[liomajor]

@d0k3

Confirmed, it's a leftover .tmd and .app inside from Firmware 9.0.

00000001.tmd is former 9.0 with sha256: 9B016F7F5ACF1C96BAFB16C77DB890925772CF774E0357C7466ED9CE86F482E2

Downgrading doesn't delete older data (only overwrites same filenames),
thats what i know since my work with @cearp

 

[d0k3]

Oh my bad. So should I downgrade sysnand back to 2.1 or should I just test emunand?

Just test on EmuNAND.

@d0k3

Confirmed, it's a leftover .tmd and .app inside from Firmware 9.0.

00000001.tmd is former 9.0 with sha256: 9B016F7F5ACF1C96BAFB16C77DB890925772CF774E0357C7466ED9CE86F482E2

Downgrading doesn't delete older data (only overwrites same filenames),
thats what i know since my work with @cearp

That's interesting! So, downgrades always use 00000000.tmd? Maybe @cearp can tell us more?

 

[liomajor]

@d0k3

We swapped regions and i've told him after comparing it that the old region
still had files inside, cearp wrote a tool to clean up (i did it manualy).

Let's see if cleaning thoose 4 will get me a success after inserting fat16.

 

[Purge]

Validation Stage 1:   SUCCESS
Validation Stage 2:   SUCCESS
#   TWL titles     :     4
#   TMD success     :     108
#   TMD not found     :     0
#   TMD hash mismatch     :     0
#   APP success     :     108
#   APP fragmented     :     0
#   APP hash mismatch     :     0

Validate EmuNAND Downgrade:   succeeded!

 

[d0k3]

Validation Stage 1:   SUCCESS
Validation Stage 2:   SUCCESS
#   TWL titles     :     4
#   TMD success     :     108
#   TMD not found     :     0
#   TMD hash mismatch     :     0
#   APP success     :     108
#   APP fragmented     :     0
#   APP hash mismatch     :     0

Validate EmuNAND Downgrade:   succeeded!

That's what I wanted to see

@d0k3

We swapped regions and i've told him after comparing it that the old region
still had files inside, cearp wrote a tool to clean up (i did it manualy).

Let's see if cleaning thoose 4 will get me a success after inserting fat16.

Cleaning it up manually means deleting all TMDs but 00000000.tmd? If we knew this for sure, handling this would be very easy.

 

[liomajor]

@d0k3

To clean we have to think a little bit different since we don't know
if the user did a downgrade.

If the folder contains multiple .tmd files > remove inside the folder
not matching .tmd / .app / .cmd.

If the folder only has one .tmd and hash doesn't match > failed

This has to be done very carefully, every folder should only have
one .tmd, but could have more than one .app.

Since we know what 2.1 provides, it makes things a little bit
easier to allow only the downgraded files.

To clean this, i did compare my former 9.2 to 2.1:

Checking title 0004013000002702...
TMD hash mismatch

Removed: 00000001.tmd / 00000008.app / 00000002.cmd

Checking title 0004013000002B02...
TMD hash mismatch

Removed: 00000001.tmd / 00000012.app / 00000002.cmd

Checking title 0004013000002F02...
TMD hash mismatch

Removed: 00000001.tmd / 0000000a.app / 00000002.cmd

Checking title 0004013000003402...
TMD hash mismatch

Removed: 00000001.tmd / 00000020.app / 00000002.cmd

Everyone who did a downgrade is detectable for having extra files in certain folders.

I need to redo the compare, bcuz by accident i removed two .tmd, but the others matched, so i guess its a success

Validation Stage 1: FAILED
Validation Stage 2: FAILED
# TMD success : 112
# TMD not found : 1
# TMD hash mismatch : 0
# APP success : 112
# APP fragmented : 0
# APP hash mismatch : 0

 

[d0k3]

@d0k3

To clean we have to think a little bit different since we don't know
if the user did a downgrade.

If the folder contains multiple .tmd files > remove inside the folder
not matching .tmd / .app / .cmd.

If the folder only has one .tmd and hash doesn't match > failed

This has to be done very carefully, every folder should only have
one .tmd, but could have more than one .app.

Since we know what 2.1 provides, it makes things a little bit
easier to allow only the downgraded files.

To clean this, i did compare my former 9.2 to 2.1:

Checking title 0004013000002702...
TMD hash mismatch

Removed: 00000001.tmd / 00000008.app / 00000002.cmd

Checking title 0004013000002B02...
TMD hash mismatch

Removed: 00000001.tmd / 00000012.app / 00000002.cmd

Checking title 0004013000002F02...
TMD hash mismatch

Removed: 00000001.tmd / 0000000a.app / 00000002.cmd

Checking title 0004013000003402...
TMD hash mismatch

Removed: 00000001.tmd / 00000020.app / 00000002.cmd

Everyone who did a downgrade is detectable for having extra files in certain folders.

I need to redo the compare, bcuz by accident i removed two .tmd, but the others matched, so i guess its a success

Validation Stage 1: FAILED
Validation Stage 2: FAILED
# TMD success : 112
# TMD not found : 1
# TMD hash mismatch : 0
# APP success : 112
# APP fragmented : 0
# APP hash mismatch : 0

Alright! I won't remove anything, cause that doesn't make sense - it works with the additional files. From what you wrote above, it does look a lot like a downgrade always writes TMD files called "00000000.tmd". Is this correct?

 

[liomajor]

Alright! I won't remove anything, cause that doesn't make sense - it works with the additional files. From what you wrote above, it does look a lot like a downgrade always writes TMD files called "00000000.tmd". Is this correct?

Not always, the name depends on the cia.

Without deletion, you can compare hash and either one of the checked files in folder has to match or failed if there are two .tmd.

 

[d0k3]

Not always, the name depends on the cia.

Without deletion, you can compare hash and either one of the checked files in folder has to match or failed if there are two .tmd.

But, isn't the name of the CIA 0004013000002F02.cia or something like that? And we can't use these names in these internal folders. Keep in mind, we know what downgrade packs users are using for that.

 

[naivegirl2411]

If you have a clean 9.2 downgrade backup (confirmed with downgrade checker) but your current downgrade has extra titles is it then ok to flash your backup and update the system as it says later on in the guide? Does updating automatically fix title errors or do these errors persist so that it'll always be part of the sysnand and show up if I ever downgrade again?

 

[d0k3]

If you have a clean 9.2 downgrade backup (confirmed with downgrade checker) but your current downgrade has extra titles is it then ok to flash your backup and update the system as it says later on in the guide? Does updating automatically fix title errors or do these errors persist so that it'll always be part of the sysnand and show up if I ever downgrade again?

It's not my downgrade... Maybe ask @Plailect ?

BTW, @liomajor, you should join us in freenode #Cakey .

 

[liomajor]

But, isn't the name of the CIA 0004013000002F02.cia or something like that? And we can't use these names in these internal folders. Keep in mind, we know what downgrade packs users are using for that.

Using the names from the cia is also ok, but its still not always 00000000.

Inserted missing .tmd and i'll check again simply to see 'success'

 

[innercy]

i've 9.2 (us region) n3ds upgraded from stock japan n3ds. will i be able to downgrade successfully?

 

[FenrirWolf]

Don't see why not. Just use the files that match the current region for your 3ds, not the region it originally came as.

 

[cearp]

@d0k3 - the tmd thing - i don't know what and or why, at least i can't remember now, but the filename of tmd files increases (always?) when the app gets updated.
and the tmd filename might not always matter, i'm not too sure
but i think it doesn't have to be 00000000.tmd to make the downgrade work

 

[d0k3]

Everyone, we have a new release - this is the 'not quite 0.8' release, here's what's new:

• All critical features (NAND dump / restore / clone and unbrick) are the same as the tested 0.71 features.
• New experimental 'One Click Setup' feature
• Added multiple validation features (to check if everything is alright, see below)
• SysNAND / EmuNAND validator checks the basic integrity of your NAND
• SysNAND / EmuNAND downgrade validator checks if your downgrade went right
• A new fallback solution for when a broken SysNAND is detected (you are given the possibilty to restore another dump)
• Ability to dump and inject the CTRNAND partition (that's a partition inside your NAND)
• Numerous smaller fixes and improvements

I said it and I'll say it again, there will never be complete safety with this procedure. The new Downgrade Validator, (must be selected and ran from the menu, not part of the standard features) however, makes bricks almost impossible. Note that there can be false alerts with this - a stage 2 validation failure for example won't mean any trouble in basically all cases, and in some cases even a stage 1 validation failure is a false alert.

Now, about the new 'One Click Setup' - this automates the full procedure from bricked (or unbricked) downgraded EmuNAND to v2.1 SysNAND, with multiple validation steps in between. In theory, this should be even safer than the current 'semi-automatic' procedure, as it will stop at the slightest hint of something going wrong. As the One Click Setup is also untested, use it with caution, or don't use it at all. If you do have a hardmod and / or are feeling bold, try it and give me feedback . The first three testers (at least one N3DS tester) to try this will get a mention on the opening post.

Also, adhere to the guide written by @Plailect. While OTPHelper tries to make stuff as safe as possible, mistakes might still happen, especially if you don't pay attention. Read the warning on the op, too!

Update: One Click Setup has already been succesfully tested by @al3x_10m on O3DS. Still awaiting more feedback.

 

[naivegirl2411]

Everyone, we have a new release - this is the 'not quite 0.8' release, here's what's new:

• All critical features (NAND dump / restore / clone and unbrick) are the same as the tested 0.71 features.
• New experimental 'One Click Setup' feature
• Added multiple validation features (to check if everything is alright, see below)
• SysNAND / EmuNAND validator checks the basic integrity of your NAND
• SysNAND / EmuNAND downgrade validator checks if your downgrade went right
• A new fallback solution for when a broken SysNAND is detected (you are given the possibilty to restore another dump)
• Ability to dump and inject the CTRNAND partition (that's a partition inside your NAND)
• Numerous smaller fixes and improvements

I said it and I'll say it again, there will never be complete safety with this procedure. The new Downgrade Validator, (must be selected and ran from the menu, not part of the standard features) however, makes bricks almost impossible. Note that there can be false alerts with this - a stage 2 validation failure for example won't mean any trouble in basically all cases, and in some cases even a stage 1 validation failure is a false alert.

Now, about the new 'One Click Setup' - this automates the full procedure from bricked (or unbricked) downgraded EmuNAND to v2.1 SysNAND, with multiple validation steps in between. In theory, this should be even safer than the current 'semi-automatic' procedure, as it will stop at the slightest hint of something going wrong. As the One Click Setup is also untested, use it with caution, or don't use it at all. If you do have a hardmod and / or are feeling bold, try it and give me feedback . The first three testers (at least one N3DS tester) to try this will get a mention on the opening post.

Also, adhere to the guide written by @Plailect. While OTPHelper tries to make stuff as safe as possible, mistakes might still happen, especially if you don't pay attention. Read the warning on the op, too!

Update: One Click Setup has already been succesfully tested by @al3x_10m on O3DS. Still awaiting more feedback.

Could the downgrade validator be used to check the integrity of any .bin files you may have? Had a problem on 0.6 where it said my backup was invalid (it was my fault). 0.6 OTP Helper also said my 9.2 backup made with emunand9 was invalid as well.

If it was possible to get info on why backups are invalid and especially info such as when the backup was made/FW of backup (and at a stretch, info on any mismatched titles on 9.2) OTP Helper could have more widespread use, just my noob input

 

[d0k3]

Could the downgrade validator be used to check the integrity of any .bin files you may have? Had a problem on 0.6 where it said my backup was invalid (it was my fault). 0.6 OTP Helper also said my 9.2 backup made with emunand9 was invalid as well.

If it was possible to get info on why backups are invalid and especially info such as when the backup was made/FW of backup (and at a stretch, info on any mismatched titles on 9.2) OTP Helper could have more widespread use, just my noob input

You can only check it if it is restored to your EmuNAND (or SysNAND, but don't do it ), so there is an extra step involved.

 

[DarkwingDuck]

I just wanted to pop in and say that i used 0.71 and everything worked great on my N3DSXL. Thanks!