Redownload it? Unless you wanted to hack it or something and put the crypto back on, but that's pointless really...
That isn't an option as the game I downloaded has been cryptofixed & there aren't any other versions available so I need to remove the CF
Why though? Cryptofixed games are just decrypted to a state where we can make them playable.... Not sure why you'd need a way to re-encrypt them
Yeah as @dark_samus3 said, probably only way is to redownload it to get a "clean" copy. But you'd obviously need the title id and decrypted titlekey to redownload from CDN. I think that would work anyway.
D9 does have cia decryption / encryption now though...
What does that mean? are we now able to make "Legit" CIAs out of normal CIAs? That would be Great especialy with the Cubic Ninja.CIA
No! Legit cia's are only those that come preinstalled on the system. You can't just turn any game into a legit one.... period.
That's in fact one of the biggest problems of the 3DS rom dumping / release scene: (1) roms are available in a multitude of formats (eShop download, CIA, 3DS) and (2) sceners want their releases in one unified format. That's also the reason why eShop stuff gets converted to 3DS (instead of CIA, which would be a closer relative of the eShop download format), despite you being able to run it in that format only with one very certain piece of hardware. That thing only gets more complicated if you add encryption, unique headers, etc to the mix.
There is no such thing as a regular rom for eShop stuff - regular roms exist only for cartridge releases. If you meant reencrypting the rom to make the signatures match again - that's possible (Decrypt9 contains the code to do that) only for individual NCCH headers (CXI, emanual, DLP data, included updates are NCCHs), but not for the NCSD (NCSD is the container containing NCCHs) header - the NCSD has been hacked from the beginning and there is no legit version of it. This is also the reason why eShop roms never work on Sky3DS without CFW / signature patching.
Additional remark: Conincidentially, the above is also the reason why we can't build legit CIAs.
TL;DR: Use fully decrypted CIAs plus a proper CFW instead of GW, cause that's what I'm assuming is the reason behind your question. Everything else is just an ugly hack.
Last edited by d0k3,
I have a clean copy now from another source so I'm good now. I couldn't download another clean copy from CDN though, once an eshop rom has been decrypted & a cia is made the key that is generated is usually bad & the title won't download again, that is why I wanted to get the .3ds I had back to it's original clean state
The key is 'bad' if you used Riku's converter to convert it - that uses the same key for everything. Preserving the key should be possible, though, I think FunkyCIA can do this. Can it @cearp ?
yeah FunkyCIA doesn't decrypt anything at all, it's ugly and annoying having to decrypt stuff, when you just want to play games.
the title key is kept/real/used by the 3ds to decrypt the cia on install as it should
the reason i created FunkyCIA was to try and give normalcy and a proper, good method to eshop dumps
Last edited by cearp,
Decrypt9 With MultiNAND Ver.2
You can select emunand easily
If there is just one emunand, it works same as original Ver.
https://github.com/LinkeneitoR/Decrypt9/releases
You can select emunand easily
If there is just one emunand, it works same as original Ver.
https://github.com/LinkeneitoR/Decrypt9/releases
There's a partition that stores GBA saves, that just dumps it, so yeah all of them will be stored in that file
- Joined
- Oct 7, 2007
- Messages
- 4,468
- Trophies
- 3
- Age
- 36
- Location
- Levelland, Texas
- Website
- www.mariopc.co.nr
- XP
- 6,901
- Country
I believe the AGBSAVE partition contains the save of the last GBA game that is played. It simply writes it to SD first, then reads the save for the game you are about to play. There's not enough space there to store multiple saves. 
I really want to have a 2nd emunand on my sd card. but multi emunand tool never detect my emunand that created by emunand9 tool.
@d0k3 Do you have a plan to add a create 2nd emunand function on your tool? Is it technically possible?
sorry. I posted wrong thread. sorrt for this.
@d0k3 Do you have a plan to add a create 2nd emunand function on your tool? Is it technically possible?
sorry. I posted wrong thread. sorrt for this.
Last edited by Februarysn0w,
That already looks a lot cleaner. I will consider adding this to the main release, will have to look into it, though.
Correct!I believe the AGBSAVE partition contains the save of the last GBA game that is played. It simply writes it to SD first, then reads the save for the game you are about to play. There's not enough space there to store multiple saves.
If Multi EmuNAND Creator doesn't detect the EmuNAND, Multi EmuNAND Creator does something wrong there - write in the Multi EmuNAND Creator thread! It is technically possible to add Multi EmuNAND format to EmuNAND9, but at the present time there are no plans to do so. There are just not enough users who actually use multiple EmuNANDs, and it would make things more complicated. By the way, adding EmuNANDs means a full format of the SD card.
@baesup
I had a look at your changes, and it already looks pretty clean to me. I especially appreciate that you kept the changes to the required minimum, cause the more the functionality gets interconnected, the more difficult it is to maintain the code.
There are a few things I'd do differently, and I might introduce some changes on top of your changes at a later point (for example, the EmuNAND selector should be displayed after the warning, not before), which you should be okay with if you do the pull request.
One question, though - the layout used for Multi EmuNANDs in your modifications - is this some kind of recognized standard? If so, can you show me a link?
Other than that, if you want to, you may send me a pull request. You might still want to do some cleaning up and / or modifications before, so take your time.
I had a look at your changes, and it already looks pretty clean to me. I especially appreciate that you kept the changes to the required minimum, cause the more the functionality gets interconnected, the more difficult it is to maintain the code.
There are a few things I'd do differently, and I might introduce some changes on top of your changes at a later point (for example, the EmuNAND selector should be displayed after the warning, not before), which you should be okay with if you do the pull request.
One question, though - the layout used for Multi EmuNANDs in your modifications - is this some kind of recognized standard? If so, can you show me a link?
Other than that, if you want to, you may send me a pull request. You might still want to do some cleaning up and / or modifications before, so take your time.
Do it manually. That means dumping the CTRNAND partition via Decrypt9, mounting that on PC via OSFmount, then get the app from there. I can't possibly include a comfortable option for everything in Decrypt9.
Similar threads
