Hacking Old 3ds device Demo

[d0k3]

I think it would be good to get more people to verify this, so sure. I'll share it as soon as I get ahold of it. You don't mind me sharing these files, do you @enes eyibil?

At this rate, it seems the 2GB of information might take a very long time to upload (I guess they just have really slow internet speed). I'll message you if everything goes as planned, but I would estimate another 8 hours before we can get it.

2GB file ends in 8 hours

it's loading so slow

damn

after you install the files, want to share it with everyone ?

Just a quick hint (if it helps you): The extracted NAND.FAT16.img compresses much better than the full NAND image or the XORpads. Same for TWLN and TWLP, but they don't matter much.

 

[CrispyYoshi]

will they arrest me ? ))

It depends where and how you got that system, and what Nintendo chooses to do if they find out who owns it... I would not post that information out in the open, and only share it with those who know how to use them.

Ofc, I always meant by private message. I would be very surprised if it is a valid image after all.

Indeed, I suspect it isn't a valid image, but I'm hoping we can at least get the important information we're looking for. However, after we get it, we'll want to do a bit of testing/verifying before attempting to flash it back to the system.

Just a quick hint (if it helps you): The extracted NAND.FAT16.img compresses much better than the full NAND image or the XORpads. Same for TWLN and TWLP, but they don't matter much.

Is that so? Then we could probably .zip/.rar/.7z the file so it uploads faster. I don't think we're in much of a rush for these files, though, but thanks for the heads up!

 

[Deleted-379826]

will they arrest me ? ))

Give it to them by private message and your fine

 

[enes eyibil]

Give it to them by private message and your fine

It depends where and how you got that system, and what Nintendo chooses to do if they find out who owns it... I would not post that information out in the open, and only share it with those who know how to use them.


Indeed, I suspect it isn't a valid image, but I'm hoping we can at least get the important information we're looking for. However, after we get it, we'll want to do a bit of testing/verifying before attempting to flash it back to the system.


Is that so? Then we could probably .zip/.rar/.7z the file so it uploads faster. I don't think we're in much of a rush for these files, though, but thanks for the heads up!

upload ready

 

[Normmatt]

My old tool used the same filename for the nand backup when dumping the encrypted nand and when doing the dump partitions option. So if you did the partition dump last which you probably did then you dont have a valid encrypted nand backup.

 

[enes eyibil]

My old tool used the same filename for the nand backup when dumping the encrypted nand and when doing the dump partitions option. So if you did the partition dump last which you probably did then you dont have a valid encrypted nand backup.

wouldn't that be the solution ?

the browser error is not resolved?

 

[CrispyYoshi]

Well, then use 3DSFAT16tool with the old NAND dump, dump the NAND FAT16 partition, and mount it in OSFMount. Then check the partition (f.e. via chkdsk). If there are no errors, you can just pad the dump with all zeroes to the correct size.

The NAND.img is 792,606,208 bytes, and after decrypting the FAT16 partition from that NAND using your 3DSFAT16tool.exe, it gave me a FAT16 file at 587,202,560 bytes (It seems to force-close itself after it hits 73%). The partition will not mount properly, and chkdsk doesn't want to touch it because' it's supposedly a "RAW File System".

The SysNand.bin dump from 6.x looks valid and produced a FAT16 partition at 794,624,000 bytes. Mounting this one works just fine, and it's detected as a DOS3.31+FAT16 file system.

It's worth mentioning that attempting to mount the NAND.img itself results in a 755.9 MB Size and DOS3.31+FAT16 File System, which matches up perfectly with the 6.x FAT16 dump.

 

[Urbanshadow]

It's worth mentioning that attempting to mount the NAND.img itself results in a 755.9 MB Size and DOS3.31+FAT16 File System, which matches up perfectly with the 6.x FAT16 dump.

Are you implying the first NAND.img is decrypted?
(Also, did you forget to pass me the fat16 xorpad?)

 

[CrispyYoshi]

Are you implying the first NAND.img is decrypted?
(Also, did you forget to pass me the fat16 xorpad?)

It could be decrypted actually, but you can check for yourself (Sorry, I forgot to send you the FAT16 Xorpad. I'll do that right now)

 

[enes eyibil]

It could be decrypted actually, but you can check for yourself (Sorry, I forgot to send you the FAT16 Xorpad. I'll do that right now)

?

 

[CrispyYoshi]

?

I am currently examining the NAND with someone, and won't be able to give you further instructions until we find out more about your situation. Please continue to keep your system on: Sorry for the inconvenience!

 

[enes eyibil]

I am currently examining the NAND with someone, and won't be able to give you further instructions until we find out more about your situation. Please continue to keep your system on: Sorry for the inconvenience!

thanks I'm waiting

 

[Urbanshadow]

It could be decrypted actually, but you can check for yourself (Sorry, I forgot to send you the FAT16 Xorpad. I'll do that right now)

I have just peeked into the file with an hex editor. It surely has some part in clear as you can find strings referring to firmwares below 1.0. Interesting.

Edit: I am not able to find the FIRM header (the one stored in CTRNAND, at least), so I assume that part is actually encripted.

 

[Suiginou]

The NAND.img is 792,606,208 bytes, and after decrypting the FAT16 partition from that NAND using your 3DSFAT16tool.exe, it gave me a FAT16 file at 587,202,560 bytes (It seems to force-close itself after it hits 73%). The partition will not mount properly, and chkdsk doesn't want to touch it because' it's supposedly a "RAW File System".

The SysNand.bin dump from 6.x looks valid and produced a FAT16 partition at 794,624,000 bytes. Mounting this one works just fine, and it's detected as a DOS3.31+FAT16 file system.

It's worth mentioning that attempting to mount the NAND.img itself results in a 755.9 MB Size and DOS3.31+FAT16 File System, which matches up perfectly with the 6.x FAT16 dump.

It could be decrypted actually, but you can check for yourself (Sorry, I forgot to send you the FAT16 Xorpad. I'll do that right now)

>NAND.img: , code offset 0x0+3, OEM-ID "CTR ", sectors/cluster 32, root entries 512, Media descriptor 0xf8, sectors/FAT 189, sectors/track 63, heads 64, hidden sectors 357, sectors 1547931 (volumes > 32 MB) , serial number 0x12345678, label: " ", FAT (16 bit)

NAND.img is a decrypted CTRNAND.

 

[d0k3]

The NAND.img is 792,606,208 bytes, and after decrypting the FAT16 partition from that NAND using your 3DSFAT16tool.exe, it gave me a FAT16 file at 587,202,560 bytes (It seems to force-close itself after it hits 73%). The partition will not mount properly, and chkdsk doesn't want to touch it because' it's supposedly a "RAW File System".

The SysNand.bin dump from 6.x looks valid and produced a FAT16 partition at 794,624,000 bytes. Mounting this one works just fine, and it's detected as a DOS3.31+FAT16 file system.

It's worth mentioning that attempting to mount the NAND.img itself results in a 755.9 MB Size and DOS3.31+FAT16 File System, which matches up perfectly with the 6.x FAT16 dump.

Okay. I'll explain to you what this means, and your options. What you got here is not a full NAND backup, but rather the decrypted CTRNAND partition only. See here (also called the CTR-NAND file system). This does not mean the FW 1.0.0 state is lost, but it will make things difficult. What you don't have at this point is the contents of the TWLN partition (which is not critical) and the FIRM0 / FIRM1.

If you want to try to go back, try this, but keep in mind there's a bricking risk with this:

• Use the valid 6.x NAND backup as base
• Inject the 1.0.0 NAND.img as FAT16 partition, using 3DSFAT16tool
• Get the 1.0.0 FIRM from somewhere (it is identical over all regions)
• Inject the FIRM to both, FIRM0 / FIRM1 via either 3DSFAT16tool or 3DSFIRMtool. Latter one is recommended
• Ignore TWLN for now (you may fix this at a later point by injecting another same region 1.0.0 3DS' TWLN)
• Restore via D9

If you do this, keep in mind, bricking risk. Also, if you do this, make sure you don't lose the XORpads, you may need them at a later point, too.

 

[Droyd]

what can you do with a nand backup and no xorpads?!!!!
he still needs a way to update to 4.1-4.5 , then he can install run rxtools devmode and update to 9.2

Didn't know mitroux was on gbatemp too

 

[enes eyibil]

Keep us

Okay. I'll explain to you what this means, and your options. What you got here is not a full NAND backup, but rather the decrypted CTRNAND partition only. See here (also called the CTR-NAND file system). This does not mean the FW 1.0.0 state is lost, but it will make things difficult. What you don't have at this point is the contents of the TWLN partition (which is not critical) and the FIRM0 / FIRM1.

If you want to try to go back, try this, but keep in mind there's a bricking risk with this:

• Use the valid 6.x NAND backup as base
• Inject the 1.0.0 NAND.img as FAT16 partition, using 3DSFAT16tool
• Get the 1.0.0 FIRM from somewhere (it is identical over all regions)
• Inject the FIRM to both, FIRM0 / FIRM1 via either 3DSFAT16tool or 3DSFIRMtool. Latter one is recommended
• Ignore TWLN for now (you may fix this at a later point by injecting another same region 1.0.0 3DS' TWLN)
• Restore via D9

If you do this, keep in mind, bricking risk. Also, if you do this, make sure you don't lose the XORpads, you may need them at a later point, too.

do I have to do this process ?

 

[d0k3]

do I have to do this process ?

I guess it is better to let @CrispyYoshi handle this, or at least do it with his assistance. There are some things that you could do wrong in the process.

 

[Just3DS]

Well considering he got somewhat valid 1.0 firmware it can be used as reference for devs. As for this member kindly help him get back to CFW route, as he seems more interested for it to be useable for such.

 

[Deleted-379826]

Well considering he got somewhat valid 1.0 firmware it can be used as reference for devs. As for this member kindly help him get back to CFW route, as he seems more interested for it to be useable for such.

From what I see your almost able to turn it back off