Homebrew Official [Download] Decrypt9 - Open Source Decryption Tools (WIP)

[hobbledehoy899]

What this guy said, anything after 1240 is just extra, empty, unused space, at least on n3ds, on o3ds anything past (iirc) 943 is empty and unused as well

You mean my baseless guess was correct??

 

[OLineGuy]

What this guy said, anything after 1240 is just extra, empty, unused space, at least on n3ds, on o3ds anything past (iirc) 943 is empty and unused as well

but i thought if you just pick the normal nand dump in decrypt9, you will dump the whole 1888, even if extra... if not, then i dont understand the difference between the nand dump and nand dump (min)

 

[Deleted member 117573]

Trying to understand the NAND validator. Did a sysNAND dump (full) with latest commit. Run it through the validator and get:

FIRM0 section2 hash mismatch
FIRM0 is corrupt (non critical)
Validate NAND Dump: succeeded!

I take it the hash mismatch is due to A9LH install. But is this dump valid to restore?

 

[d0k3]

@d0k3

Advance feature request: Installing/injecting A9LH through Decrypt9WIP, provided that we have delebile's arm9loaderhax data_output files (firm0.bin, firm1.bin, sector.bin, stage0x5C000.bin) present in the Decrypt9 work directory.

I'm not sure if it's possible, but you I have you do miraculous things with Decrypt9 already. It would be a nice feature to restore sysNand,exploitable or non-exploitable, followed by installing a9lh directly through the menu in 1 function. I think it would mostly benefit a9lh users who have a hardmod that regularly make backups of fully updated firmware images.

And yes, I'm also aware that D9WIP has options to keep the a9lh intact when restoring nand, and restoring ctrnand.

I see why this could be useful (to hardmod owners), but I'm not sure if I would want to open that can of worms. At the moment I rather not. There are people more knowledgeable in arm9loaderhax than I am, and these people are working on making the process as safe and painless as possible. A9lh is also still evolving, and adding that to D9 now would mean I'd have to keep this up to date. And, as you said, we already have that a9lh preserving NAND restore, so for basically everyone the a9lh installation is a one time affair. By the way: In theory you could install a9lh, on PC, directly to a NAND backup. I won't do it, but maybe someone wants to take up that as a side project later.

My nand is 1888, but both nand backup options (full and min) give 1240... any idea why?

but i thought if you just pick the normal nand dump in decrypt9, you will dump the whole 1888, even if extra... if not, then i dont understand the difference between the nand dump and nand dump (min)

If Decrypt9WIP reduces the size to dump, it also gives you the reason why it did so in the output. Is this a minimum size RedNAND? If so: we can't dump more data then there is. If this is not a RedNAND or even SysNAND, give me the exact output (via Decrypt9.log) and / or update to the latest version.

Trying to understand the NAND validator. Did a sysNAND dump (full) with latest commit. Run it through the validator and get:

FIRM0 section2 hash mismatch
FIRM0 is corrupt (non critical)
Validate NAND Dump: succeeded!

I take it the hash mismatch is due to A9LH install. But is this dump valid to restore?

You're asking: "is this dump valid to restore?", to which I have to reply that you have to know yourself. Although the NAND validator does check a lot, it can do only so much, and there are ways to corrupt a NAND image in a way that the validator still passes. For this to happen, you almost have to do this corruption deliberately. I still recommend you use common sense when restoring NAND backups. The warning message and the button sequence is there for a reason.

Anyways, as for the output. Yes, this is normal and expected for a9lh. Even if the detected corruption was not due to a9lh, it would still be safe to restore 99.999% (and this corruption never happens without a9lh). If the validator says it succeeded, that means there is no objection from D9s side to restore that NAND backup. Plus, the NAND restore options validates the dump, too, before even starting.

 

[Ripper00420]

I see why this could be useful (to hardmod owners), but I'm not sure if I would want to open that can of worms. At the moment I rather not. There are people more knowledgeable in arm9loaderhax than I am, and these people are working on making the process as safe and painless as possible. A9lh is also still evolving, and adding that to D9 now would mean I'd have to keep this up to date. And, as you said, we already have that a9lh preserving NAND restore, so for basically everyone the a9lh installation is a one time affair. By the way: In theory you could install a9lh, on PC, directly to a NAND backup. I won't do it, but maybe someone wants to take up that as a side project later.



If Decrypt9WIP reduces the size to dump, it also gives you the reason why it did so in the output. Is this a minimum size RedNAND? If so: we can't dump more data then there is. If this is not a RedNAND or even SysNAND, give me the exact output (via Decrypt9.log) and / or update to the latest version.


You're asking: "is this dump valid to restore?", to which I have to reply that you have to know yourself. Although the NAND validator does check a lot, it can do only so much, and there are ways to corrupt a NAND image in a way that the validator still passes. For this to happen, you almost have to do this corruption deliberately. I still recommend you use common sense when restoring NAND backups. The warning message and the button sequence is there for a reason.

Anyways, as for the output. Yes, this is normal and expected for a9lh. Even if the detected corruption was not due to a9lh, it would still be safe to restore 99.999% (and this corruption never happens without a9lh). If the validator says it succeeded, that means there is no objection from D9s side to restore that NAND backup. Plus, the NAND restore options validates the dump, too, before even starting.

Could it be possible for my EmuNand to boot every time, but still be corrupted. I'm having an issue with any HB app or Computer app detecting my EmuNand, so I can't make any backups at all of my EmuNand.

 

[d0k3]

Could it be possible for my EmuNand to boot every time, but still be corrupted. I'm having an issue with any HB app or Computer app detecting my EmuNand, so I can't make any backups at all of my EmuNand.

It is much more possible that ReiNAND boots into SysNAND without you noticing. Just saying. Give me those 2kB and I'll tell you for sure.

 

[OLineGuy]

I see why this could be useful (to hardmod owners), but I'm not sure if I would want to open that can of worms. At the moment I rather not. There are people more knowledgeable in arm9loaderhax than I am, and these people are working on making the process as safe and painless as possible. A9lh is also still evolving, and adding that to D9 now would mean I'd have to keep this up to date. And, as you said, we already have that a9lh preserving NAND restore, so for basically everyone the a9lh installation is a one time affair. By the way: In theory you could install a9lh, on PC, directly to a NAND backup. I won't do it, but maybe someone wants to take up that as a side project later.



If Decrypt9WIP reduces the size to dump, it also gives you the reason why it did so in the output. Is this a minimum size RedNAND? If so: we can't dump more data then there is. If this is not a RedNAND or even SysNAND, give me the exact output (via Decrypt9.log) and / or update to the latest version.


You're asking: "is this dump valid to restore?", to which I have to reply that you have to know yourself. Although the NAND validator does check a lot, it can do only so much, and there are ways to corrupt a NAND image in a way that the validator still passes. For this to happen, you almost have to do this corruption deliberately. I still recommend you use common sense when restoring NAND backups. The warning message and the button sequence is there for a reason.

Anyways, as for the output. Yes, this is normal and expected for a9lh. Even if the detected corruption was not due to a9lh, it would still be safe to restore 99.999% (and this corruption never happens without a9lh). If the validator says it succeeded, that means there is no objection from D9s side to restore that NAND backup. Plus, the NAND restore options validates the dump, too, before even starting.

There was no reason given in the log... all it says is:
Dumping SysNAND. Size (MB): 1240
Use arrow keys and <A> to choose a name
NAND_sys.bin
Creating NAND_sys.bin ...
NAND Backup: succeeded!

 

[d0k3]

There was no reason given in the log... all it says is:
Dumping SysNAND. Size (MB): 1240
Use arrow keys and <A> to choose a name
NAND_sys.bin
Creating NAND_sys.bin ...
NAND Backup: succeeded!

Are you really sure your NAND is a 1.8GB one? You can use the new system info feature (in maintenance) to check that.

 

[OLineGuy]

Are you really sure your NAND is a 1.8GB one? You can use the new system info feature (in maintenance) to check that.

Yes. I have dumped my 1.8gb with previous versions, and system info in maintenance says it is. But latest decrypt9 only does 1240. Rls from march does the full 1.8

 

[MoonLamp]

Yes. I have dumped my 1.8gb with previous versions, and system info in maintenance says it is. But latest decrypt9 only does 1240. Rls from march does the full 1.8

Came here to report I am having this issue as well.

Previous version of decrypt9 dumped my nand as full 1.8. The newest version it will only dump 1240 (same size for both full dump and min dump)

 

[d0k3]

Yes. I have dumped my 1.8gb with previous versions, and system info in maintenance says it is. But latest decrypt9 only does 1240. Rls from march does the full 1.8

Came here to report I am having this issue as well.

Previous version of decrypt9 dumped my nand as full 1.8. The newest version it will only dump 1240 (same size for both full dump and min dump)

Okay, found it. You have a minimum size RedNAND on the SD, right? Now, either compile from newest GitHub source or wait until the next release (which will be soon, too).

 

[OLineGuy]

Okay, found it. You have a minimum size RedNAND on the SD, right? Now, either compile from newest GitHub source or wait until the next release (which will be soon, too).

Only updated sysnand, no emu/rednand

 

[MoonLamp]

Only updated sysnand, no emu/rednand

Same with me. I started with a brand new SD card on a clean 9.0 sysnand. Installed a9lh, updated to 10.7, decrypt9 would only dump 1240mbs.

 

[d0k3]

Only updated sysnand, no emu/rednand

Same with me. I started with a brand new SD card on a clean 9.0 sysnand. Installed a9lh, updated to 10.7, decrypt9 would only dump 1240mbs.

So what, I did a new release. This is new:

• Fixed size of SysNAND dumps when there is no EmuNAND present of the SD card
• More through checking for already set up keys during initialization

Also, take note that minimum size dumps are as valid as full sized ones.

Can you two try again with this one?

 

[OLineGuy]

So what, I did a new release. This is new:

• Fixed size of SysNAND dumps when there is no EmuNAND present of the SD card
• More through checking for already set up keys during initialization

Also, take note that minimum size dumps are as valid as full sized ones.

Can you two try again with this one?

looks like it is fixed. thanks for the quick fix. dumping full nand now.

 

[MoonLamp]

So what, I did a new release. This is new:

• Fixed size of SysNAND dumps when there is no EmuNAND present of the SD card
• More through checking for already set up keys during initialization

Also, take note that minimum size dumps are as valid as full sized ones.

Can you two try again with this one?

Just finished a full dump and it is the correct size (1.8).

Really appreciate the quick fix on this one!

 

[Ripper00420]

It is much more possible that ReiNAND boots into SysNAND without you noticing. Just saying. Give me those 2kB and I'll tell you for sure.

My Nands are not linked and SysNand is blank with no theme, just FBI installed. Trust me it's not booting SysNand. I'm getting that for you right now though sir, and thanks again.

 

[morph95]

I used 3DSBuilder to rebuild an eShop game without manual and used 3DS Simple CIA Converter to convert to cia file.
Import CIA is OK with BBM, but I have an error with option CXI Only in Decrypt9WIP:

Opening /D9Game ...
Processing CIA "Shingeki.cia"
Probably not a CIA file
Failed!
CIA Decryptor (CXI Only): failed!

Press B to return, START to reboot

 

[driverdis]

does anybody know if d9logo.bin is the standard RAW BGR that https://xem.github.io/3DShomebrew/tools/image-to-bin.html can produce?

 

[Shadowtrance]

does anybody know if d9logo.bin is the standard RAW BGR that https://xem.github.io/3DShomebrew/tools/image-to-bin.html can produce?

It should be.