ROM Hack [Release] 3DS_CTR_Decryptor-VOiD

  • Thread starter Thread starter Relys
  • Start date Start date
  • Views Views 648,856
  • Replies Replies 2,226
  • Likes Likes 30
Damn, I wish the tool didn't need 4.5 3DS. Hopefully this will work with SSSPWN. That, or someone will extract the soundtrack/share xorpad from ALBW (as everything on the net is incomplete, like usual)
 
xorpad 622,592kb vs encrypted romFS 622,268kb

I got every single xorpad, by the way.


Wait, if the xorpad is bigger, the decryptor on the SD card may have added data to it. Please take a screenshot of the beginning and end of the xorpad in a hex editor I need to see this. :unsure:
 
Wait, if the xorpad is bigger, the decryptor on the SD card may have added data to it. Please take a screenshot of the beginning and end of the xorpad in a hex editor I need to see this. :unsure:

There you go:
Beginning
1.png
End
2.png
 
Thanks for the release, I'm excited to see what comes out of this.
If somebody could try to use this ncchinfo.bin with the 3DS application and share the results with me (via PM) I'd be really grateful since I currently don't have a 4.5 3DS but would like to toy around with this. http://www11.zippyshare.com/v/99738484/file.html
 
Just a reminder to all users that it's forbidden to ask or share files extracted from a game, or encryption keys.
The Xorpad is part of this restriction. It's a data/key extracted and decrypted from the game by the console. If you need this file, you have to do it yourself.

You can share the ncchinfo.bin though, it's only game's header information, like game size and partitions locations. no data from the game's partitions are provided. But it's the easiest step and anybody can create a header information file from the ROM, there's no interest in sharing it to users without the ROM file.
 
How do I use ctrtool to extract the files from the decrypted RomFS?
./ctrtool.exe -t romfs --romfsdir=out romfs.bin

lol they call it Release I call that copy past. They wrote about 3 lines themselves great. The rest is copyed

I wrote all of main() in ctrKeyGen and SB wrote all if main() in padgen. All libs we used were copied from public sources. As Cyan mentioned I also included all source code. Released to everyone, free as in beer. The way it should be. Enjoy! :)
 
xorpad 622,592kb vs encrypted romFS 622,268kb

I got every single xorpad, by the way.

Given I actually took the time to read main.c:

The createpad() method generates XORpads in megabytes -- 622,268kb is not an integer number of megabytes (it's 607.68 mb), so the program continues generating XORpad data until it hits 622,592 kb (608 mb).

So the size difference is totally expected, just ignore/delete the bytes in the XORpad that are after the end index of the romFS.

Of course, I'm also not convinced that this thing actually works...has anyone gotten it to work? At all? It seems copy/pasted.
 
  • Like
Reactions: kyogre123
Given I actually took the time to read main.c:

The createpad() method generates XORpads in megabytes -- 622,268kb is not an integer number of megabytes (it's 607.68 mb), so the program continues generating XORpad data until it hits 622,592 kb (608 mb).

So the size difference is totally expected, just ignore/delete the bytes in the XORpad that are after the end index of the romFS.

Of course, I'm also not convinced that this thing actually works...has anyone gotten it to work? At all? It seems copy/pasted.

Yes you are correct.

I wrote all of main() in ctrKeyGen and SB wrote all if main() in padgen. All libs we used were copied from public sources. As Cyan mentioned I also included all source code.
 
In this case delete, since my xor.exe only works if the xorpad has the exact same size as the encrypted romfs.
 
lol they call it Release I call that copy past. They wrote about 3 lines themselves great. The rest is copyed

Yes, because reusing public and confirmed working code is such a bad practice. /sarcasm

Anyways, thanks for the release, and for sharing the source. :) Not everyone here on gbatemp is clueless about this stuff and actually want to learn more. Creds for releasing what others won't to share with the "retards on failtemp".
 
Given I actually took the time to read main.c:

The createpad() method generates XORpads in megabytes -- 622,268kb is not an integer number of megabytes (it's 607.68 mb), so the program continues generating XORpad data until it hits 622,592 kb (608 mb).

So the size difference is totally expected, just ignore/delete the bytes in the XORpad that are after the end index of the romFS.

Of course, I'm also not convinced that this thing actually works...has anyone gotten it to work? At all? It seems copy/pasted.

So, do you think that if I deleted everything past... 637,202,432bytes, the output file will be corrected or it will just be pretty much the same thing but with extra data at the end?
 

Site & Scene News

Popular threads in this forum