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

  • Thread starter Thread starter d0k3
  • Start date Start date
  • Views Views 935,266
  • Replies Replies 4,476
  • Likes Likes 71
Just writing to let you know I've seen your edits. Well, I see you know how to test and verify this, and this stays a very bizarre error. Even if the SD card had (undetected) surface errors, it would be rather improbable the file would be on the same physical space again. And, this working with a 16GB format only serves to makes this even more strange. I have an idea what you could try though. Check what cluster size the FAT formating of this 32GB SD card uses, and format it with a different cluster size. Then see if it keeps on happening and tell me.

In any way, thanks for this information!

I would wish to report the same thing. When I followed that guide for A9LH, copying the BIN files to my PC sometimes will cause the card to unmount (disappear briefly). Once it happens it is very repeatable, same behaviour at the exact same point of the same file.
I was suspecting defective card but as I saw someone else reporting the same thing here, it may not be a coincidence. My card is a brand new Toshiba EXCERIA 64GB microSDXC, formatted to FAT32 with guiformat.
 
Last edited by gualala,
I would wish to report the same thing. When I followed that guide for A9LH, copying the BIN files to my PC sometimes will cause the card to dismount (disappear briefly). Once it happens it is very repeatable, same behaviour at the exact same point of the same file.
I was suspecting defective card but as I saw someone else reporting the same thing here, it may not be a coincidence. My card is a brand new Toshiba EXCERIA 64GB microSDXC, formatted to FAT32 with guiformat.
Did you press "Select" button before eject your mSD card from 3DS in Decrypt9; AND did wait wait a bit after reinsert the card before pressing "B"
 
Did you press "Select" button before eject your mSD card from 3DS in Decrypt9; AND did wait wait a bit after reinsert the card before pressing "B"
Yes for the first part.
For the second part (re-insert), I waited a second or so before pressing B.
The first time I encountered this error, I deleted the file thinking a bad dump and dumped again. But Windows still failed to copy at the similar (if not the same) location. I suspected bad sector on the card, so I dumped again with different file name without removing the previous dump and it works.
If it happens at the A9LH step where flashing 2.1 emu to sys I'd end up with a brick... However I am still not sure what caused the error (my card or the bad dump) as the failure location is very similar in my 2 tries.
 
Just writing to let you know I've seen your edits. Well, I see you know how to test and verify this, and this stays a very bizarre error. Even if the SD card had (undetected) surface errors, it would be rather improbable the file would be on the same physical space again. And, this working with a 16GB format only serves to makes this even more strange. I have an idea what you could try though. Check what cluster size the FAT formating of this 32GB SD card uses, and format it with a different cluster size. Then see if it keeps on happening and tell me.

In any way, thanks for this information!
Cluster size didn't seem to make any difference, but I decided I'd try to inject the NAND with 3DS Multi EmuNAND Creator, and it completed the operation successfully. At this point though I'm not sure if it'd be wise to use the SD card if it has some unknown problem.. But it's still a mysterious mercurial problem that not only isn't displayed in a surface test, only arises at anywhere from 15-21% of flashing an EmuNAND using Decrypt9 or Emunand9.. I'll update this post if anything noteworthy occurs on my 32gb windows flashed EmuNAND..


Edit:

Well, I was able to inject FBI into H&S and stuff, but when I try to make an EmuNAND backup it gets to around 7-14% and then says..
ERROR, SD card may be full!
EmuNAND Backup: failed!

so it's still being unmounted. I guess the SD card really is broken, then, somehow? It's just weird that tests wouldn't show it..

First failed dump stopped at 224mb. The second failed at 240mb. (edit edit: Sounds like the guy below me is having the same dumping problem as I am..... Curious..)

Edit2: Tested the SD card more thoroughly using a program called H2testw and another FAKEFLASHTEST designed to check faulty/fake flash memory.
FAKEFLASHTEST v1.1.1 [SSi]
DRIVE 2 - 28.9GiB Mass Storage Device
FFT - Quick Size Test (destructive)
F: (no label) DRIVE 2 - 28.9GiB Mass Storage Device

Writing marker blocks to drive 2
5% complete - 0 min 57 sec remaining
10% complete - 0 min 45 sec remaining
15% complete - 0 min 34 sec remaining
20% complete - 0 min 32 sec remaining
25% complete - 0 min 24 sec remaining
30% complete - 0 min 24 sec remaining
35% complete - 0 min 19 sec remaining
40% complete - 0 min 20 sec remaining
45% complete - 0 min 16 sec remaining
50% complete - 0 min 15 sec remaining
55% complete - 0 min 13 sec remaining
60% complete - 0 min 12 sec remaining
65% complete - 0 min 10 sec remaining
70% complete - 0 min 8 sec remaining
75% complete - 0 min 6 sec remaining
80% complete - 0 min 5 sec remaining
85% complete - 0 min 4 sec remaining
90% complete - 0 min 3 sec remaining
95% complete - 0 min 2 sec remaining
100% complete - 0 min 1 sec remaining
Reading back marker blocks...
5% complete - 0 min 19 sec remaining
10% complete - 0 min 9 sec remaining
15% complete - 0 min 6 sec remaining
20% complete - 0 min 4 sec remaining
25% complete - 0 min 6 sec remaining
30% complete - 0 min 5 sec remaining
35% complete - 0 min 4 sec remaining
40% complete - 0 min 3 sec remaining
45% complete - 0 min 4 sec remaining
50% complete - 0 min 3 sec remaining
55% complete - 0 min 3 sec remaining
60% complete - 0 min 2 sec remaining
65% complete - 0 min 2 sec remaining
70% complete - 0 min 2 sec remaining
75% complete - 0 min 2 sec remaining
80% complete - 0 min 1 sec remaining
85% complete - 0 min 1 sec remaining
90% complete - 0 min 1 sec remaining
95% complete - 0 min 1 sec remaining
Test took 26 seconds.

Device quick test was OK *** PASSED ***

NOTE: Drive filesystem has been erased - please partition and format it, and then test with H2TESTW for thorough test.

INFO: This device is classed as a Removable Disk by Windows.
Unplug and re-connect the drive, then reformat it using Windows or RMPrepUSB.
Warning: Only 29651 of 29652 MByte tested.
Test finished without errors.
You can now delete the test files *.h2w or verify them again.
Writing speed: 10.7 MByte/s
Reading speed: 21.2 MByte/s
H2testw v1.4
Completed with no problems at all. Really scratching my head here. I'll try formatting the sd card for EmuNAND one last time and dumping that raw EmuNAND to see if I encounter the same problems.. If I don't then I'm going to assume that Decrypt9/EmuNAND9 have issue with some particular part of my NAND.

Man this is frustrating as hell.


Final update: Raw EmuNAND fails to dump as well, though SysNAND is cloned to it in the first place with no errors whatsoever. Giving up, given that the poster below me has the same problem when dumping at the same filesize, I'm going to hope that the problem is on your end. Ball is in your court, hope to hear back from you.
 
Last edited by Spoober,
Hi, I just downloaded the latest version of Decrypt9, and I'm trying to follow this guide https://github.com/Plailect/Guide/wiki/Part-4-(Getting-the-OTP)
When it comes to the part of dumping the emuNAND, it stops at around 21% and says that my SD card is full. Tried with Emunand9, still no luck. The filsezie is always arround 221mb.
Does anyone know what is causing this?
 
Hi, I just downloaded the latest version of Decrypt9, and I'm trying to follow this guide https://github.com/Plailect/Guide/wiki/Part-4-(Getting-the-OTP)
When it comes to the part of dumping the emuNAND, it stops at around 21% and says that my SD card is full. Tried with Emunand9, still no luck. The filsezie is always arround 221mb.
Does anyone know what is causing this?
How much space do you have on your Sd card do you have left
 
hey i keep getting hp_emu.app and need just hp.app ??? what am I doing wrong
That's just the name it gave it. Before you dump it press up on the d pad and you can change it.

--------------

As for the people with the unmounting/sd full error. Try making a folder for decrypt9 to work out of. I had this issue until I made a working folder for it.
 
Last edited by pbanj,
'CIA Decryptor (CXI)' is useless now? So, the Gateway flashcard is useless too now!
That was a typo. The 'CIA Encryptor (CXI)' is useless now. I'd still recommend CFW over GW any time :P.

I would wish to report the same thing. When I followed that guide for A9LH, copying the BIN files to my PC sometimes will cause the card to unmount (disappear briefly). Once it happens it is very repeatable, same behaviour at the exact same point of the same file.
I was suspecting defective card but as I saw someone else reporting the same thing here, it may not be a coincidence. My card is a brand new Toshiba EXCERIA 64GB microSDXC, formatted to FAT32 with guiformat.
Wait, if I get that right, you are saying the same issue that happens on Decrypt9 also happens on PC with a card reader? Just wanting to confirm. If it could be a hardware problem, there would be nothing much we can do.

Also, @Spoober, @Some1CP that issue seems to be more common than I thought. Maybe you can help me find things common between you three?
  • This happens only for EmuNAND reading / writing, right, not for SysNAND right?
  • Not sure if I got that right, but does it always happen at around 20%?
  • What entrypoint did you use? (3DSX / BIN / DAT / Launcher.dat / A9LH / ...)
  • What console type (O3DS / N3DS / 2DS) do you have, what region and what FW?
  • If I got that correctly, EmuNAND9 has the same issue, right? If you have not tested yet, please do!
  • Was that issue always there? Ie. did it work properly with an earlier version?
  • We could try if it has to do with moving around large files on the SD card. To test, just put a large (~2GB) file onto your SD card and make a copy of it to another folder, using my GodMode9 alpha. (don't worry btw, NAND writing is disabled in this tool). Just to be safe, you could repeat the same test on my CTRXplorer.
I hope we'll get behind this.
 
  • Like
Reactions: Februarysn0w
What I remember from mine.
N3ds u region 10.5 emunand(maybe 10.6). Entry point was the 3dsx from my 9.2 sysnand. It failed every time right around the 700MB mark. I don't remember what nand I was dumping though. It happened like last week or so when I was doing the otp stuff. It worked fine in the ver I was using before(used it maybe a month before when I did my downgrade and what not). I got around the issue by making a decrypt9 folder for it to work out of. My sd card is a 64gb one and has over half free.
 
What I remember from mine.
N3ds u region 10.5 emunand(maybe 10.6). Entry point was the 3dsx from my 9.2 sysnand. It failed every time right around the 700MB mark. I don't remember what nand I was dumping though. It happened like last week or so when I was doing the otp stuff. It worked fine in the ver I was using before(used it maybe a month before when I did my downgrade and what not). I got around the issue by making a decrypt9 folder for it to work out of. My sd card is a 64gb one and has over half free.
You mean, it worked after you made a Decrypt9 folder and let it work from that?
 
Hi,

I have in issue when injecting the FBI_inject_with_banner. All the messages from decrypt9wip are of suceed injecting the new app to emunand but when booting the emunand the H&S app is unchanged. Same banner and H&S app when launching. My emunand is 9.8, unlinked and very stuffed with apps (32GB card).
Anybody with the same problem or any clue?

Regards.
 
GodMode9 works very well. I successfully copied emunand firm.bin(00000000.app) to sd card.

edit:
sysnand too.

.3dsx version works fine too. on my sysnand 9.0 firm launch.

video for poc. sorry for my shitty camera.
 
Last edited by Februarysn0w,
  • Like
Reactions: Sev501 and d0k3
That was a typo. The 'CIA Encryptor (CXI)' is useless now. I'd still recommend CFW over GW any time :P.


Wait, if I get that right, you are saying the same issue that happens on Decrypt9 also happens on PC with a card reader? Just wanting to confirm. If it could be a hardware problem, there would be nothing much we can do.

Also, @Spoober, @Some1CP that issue seems to be more common than I thought. Maybe you can help me find things common between you three?
  • This happens only for EmuNAND reading / writing, right, not for SysNAND right?
  • Not sure if I got that right, but does it always happen at around 20%?
  • What entrypoint did you use? (3DSX / BIN / DAT / Launcher.dat / A9LH / ...)
  • What console type (O3DS / N3DS / 2DS) do you have, what region and what FW?
  • If I got that correctly, EmuNAND9 has the same issue, right? If you have not tested yet, please do!
  • Was that issue always there? Ie. did it work properly with an earlier version?
  • We could try if it has to do with moving around large files on the SD card. To test, just put a large (~2GB) file onto your SD card and make a copy of it to another folder, using my GodMode9 alpha. (don't worry btw, NAND writing is disabled in this tool). Just to be safe, you could repeat the same test on my CTRXplorer.
I hope we'll get behind this.

Thank you! @Spoober, @Some1CP could you try creating the work folder on your SD card ("/Decrypt9/"), then try again? It would be more than strange if that worked, but if it does we have a strong lead.

I found what the problem was. Even if I tried to backup the emuNAND using the computer, it would give me an error at the exact same spot. I injected my sysNAND backup into it, updated, and now it backups just fine.
I think something got corrupted along the way, because the first time I tried to update the emuNAND, I shutdown the system on the black screen it shows for a while after updating.

Thanks for trying to help.

EDIT: I left sysupdater running the emuNAND downgrade to 2.10. When I looked, the 3DS rebooted into sysNAND. Does it mean it completed successfully?
 
  • Like
Reactions: d0k3
Hi,

I have in issue when injecting the FBI_inject_with_banner. All the messages from decrypt9wip are of suceed injecting the new app to emunand but when booting the emunand the H&S app is unchanged. Same banner and H&S app when launching. My emunand is 9.8, unlinked and very stuffed with apps (32GB card).
Anybody with the same problem or any clue?

Regards.
There was some guy a while before. Are you by any chance using multiple EmumNANDs? If not, what EmuNAND type is displayed in the menu?
 
Just got finished doing my homework, @d0k3

In all cases I've been using the 3dsx entrypoint through Homebrew Launcher through Menuhax. (also tried through Browserhax a couple of times)

N3DS with, naturally, SysNAND 9.2u, Emunand 10.6 (though it happens as well with EmuNAND 9.2). If reading the SysNAND and writing it to the EmuNAND partition is a problem though I don't see how it could be copied successfully to a fresh EmuNAND in the first place, though.. Making dumps of the NANDs fails at 7-~15%, and injecting a NAND dump .bin into EmuNAND fails at 14-22%. On both Decrypt9 and EmuNAND9. (only on the 32gb card, even with the same dumps.)

My SysNAND dump fails as well, at the same point using EmuNAND9 and the 32gb SD card.

Copying the same NAND.bin using GodMode9 failed. (From Root of 32gb SD to a folder within the same partition)(was I supposed to copy it directly from my NAND?). The resulting file was 0 bytes (to windows anyhow), though from rough estimation the progress bar showed about the same as I can expect with the other apps. The SD card is, once again, unmounted after the fail, so obviously that's what's causing the failure.

And, much to my dismay. The Decrypt9 work folder trick does not work either. Dumping SysNAND to it stopped at 20%. The file was 395mb. I tried to dump EmuNAND twice. The first failure was almost instant and stopped at 4mb. The second went to 10% and stopped at 202mb. The points at which it unmounts seem totally arbitrary.

To summarize:
Writing SysNAND to EmuNAND using EmuNAND9 initial setup works fine.
Dumping SysNAND or EmuNAND regardless of app fails at arbitrary points anywhere from (4mb?!)170mb to 395mb.
Entrypoint is 3dsx in all cases.
N3ds XL with 9.2u SysNAND, 10.6 EmuNAND, and 9.2 EmuNAND.
Earlier versions were not tested.
Godmode9 fails as well, by visual estimation, at the same percentages.

Edit:
I'm going to try filling the SD card up with a bunch of files to approximately 50% capacity and try this again.
Edit 2:
After loading up the card with a bunch of files (over 50% capacity) the dumps still fail within the same frame. (215mb EmuNAND dump and a 121mb SysNAND dump)
GodMode9 failed very quickly when attempting to copy any large files (tested with a complete dump and a 2gb mkv file) after loading the card up.
Dumps will also occasionally fail nearly instantly but if they don't they reach the lower end of the average size stated above. (9-13%) So there's some part of my SD card (or rather, the partition?) that either these apps or my n3ds do not like.

important note: cloning SysNAND to EmuNAND still works fine even after filling the SD card up.

So if it is really a failed card, why haven't any of the intensive tests shown it? Why doesn't windows have the same write errors?

I'd hate to think that the problem could be my 3ds's hardware.. (brand new as of 3 days ago..)

p.s. sorry for the massive posts all the time

Exact model of card:
Sony SR-32UY2A
 
Last edited by Spoober,
There was some guy a while before. Are you by any chance using multiple EmumNANDs? If not, what EmuNAND type is displayed in the menu?
Hi d0k3,

Thanks for answering.
No, i'm not using multiple emunands. In the attach is the info when injecting the app.

Regards
 

Attachments

  • hs injection.jpg
    hs injection.jpg
    127.9 KB · Views: 275

Site & Scene News

Popular threads in this forum