ROM Hack [Release] 3DS_CTR_Decryptor-VOiD

  • Thread starter Thread starter Relys
  • Start date Start date
  • Views Views 649,172
  • Replies Replies 2,226
  • Likes Likes 30
Are you using the version 2 of the padgen?
http://gbatemp.net/threads/release-3ds_ctr_decryptor-void.370684/page-20#post-5088036

I've had 0 issues with that one, other than having to reboot a few times occasionally before it starts working.
No, I was using the first version. Thanks, that solved the issue!



Okay, I extracted EncryptedRomFS.bin with getromfs and xored it with the xorpad using padxorer. So what do I do now? I'm supposed to use ctrtool to extract its contents, right? Can somebody tell me the syntax I should use? I've tried the following:

ctrtool -x RomFS.bin

But it only makes the program show the file's info (ie: the header, the id, etc).
 
No, I was using the first version. Thanks, that solved the issue!



Okay, I extracted EncryptedRomFS.bin with getromfs and xored it with the xorpad using padxorer. So what do I do now? I'm supposed to use ctrtool to extract its contents, right? Can somebody tell me the syntax I should use? I've tried the following:

ctrtool -x RomFS.bin

But it only makes the program show the file's info (ie: the header, the id, etc).

ctrtool -t =romfs --romfsdir=OutDir RomFS.bin

that's what I used just now. Anyone know anything about "CRAR" files? Google fails me.
 
Nevermind, I figured out the problem. I incorrectly thought that RomFS.bin had to be in the folder specified at romfsdir, but since I simply wrote "RomFS.bin" at the end of the syntax (as opposed to "output/RomFS.bin"), the program was looking for it in the same folder where ctrtool.exe was :shy:

As always, thanks for your help peeps!
 
a/0/0/7: pokemon models
Since the public essentially has the means to get the decrypted X/Y rom data, I added some new pastes on my pastebin that you might want to check out. Back months ago when Slashmolder & Bond697 dumped the data we (bond,slash,magical,zhorken,myself,?) noted what was what.

They use the GARC container format for X/Y. I made a quick&dirty GARC unpacker to pull out the files (it doesn't handle DARCs, which have to be used with a program that SciresM made). Here's a link to compiled versions.

Could you take a look at Harmoknight files? The game was also made by Gamefreak, and it's folder layout is very similar(a/x/x/x). The files seems to have a GARC header, but your unpacker says there are zero files in each one.


Edit:Just looking through the header of the file and your source, I already see the header part before 'OTAF' is 4 bytes shorter than what you look for.

Here's a pic of the header for file 'a\0\0\0': http://i.imgur.com/gCf4AKb.png
File size is 60,474,816 bytes
 
I tried to extract the audio from Luigi's Mansion. Sadly Next Level Games used https://www.audiokinetic.com/ to pack all the sounds into annoying .bnk and .pck formats.

However, the audio in these files seems uncompressed, but in a weird format.

All look like wav files, but according to their RIFF headers it's adpcm and it plays a lot of static in foobar2000. When I speed it up and increase the pitch a bit, it almost sounds like something. In one it sounds like Luigi humming. In another, I can clearly here that spooky theremin instrument I don't know the name for. If anyone knows anything about audio stuff, PM me.


Edit: I stuck the "wav" data into a bcstm file and it sounds a lot less painful. Wwise has been known to spoof audio containers, although they did mark the wav container as ADPCM, which the b*stm format uses so I don't know. Again someone with more audio knowledge than me PM me.
 
  • Like
Reactions: cearp
Just decrypted Persona Q (the Japanese release) and the voices are there as expected.

The data is compressed into a cpk format and cpk_unpack (Google it) is required to unpack it. It has obviously loads of files. However there is a funny folder there named "Transrate" which is probably meant as "Translate" for the translation team. That folder has a few icons inside it, but I'd need to figure out how to read them to get any information out of them in that case.

The files are mostly compressed with CRIWare proprietary software and is quite easily extracted if you know what software to use. Pretty much all the file compressions have been found out previously when CRIWare software has been used in other games

The voices are inside the sound folder. They're all over the place and have no good names. They're packed into the awb (AFS2) format which as mentioned is CRIWare stuff. Quickbms can unpack these with a simple script and will usually produce more than one ".hca" files that again has no good name. These files can be played using the CriAtomPlayer which is licensed software that is illegal to spread around, so no links to that.

The BGM is first packed in awb like the voices and the actual music is in adx and hca format. They're usually unpacked into loads of .dat files, but only some of them contain the music as the other ones starts at wrong sectors and are likely either excessive data or are unpacked wrong(?). They can also be played with CriAtomPlayer. The OST is out though so it brings little to the table. I did find some music that isn't in the OST though like some eerie background atmosphere stuff (00000103.dat).

I have no idea what the "lip" stuff is in sound or "comse". There seems to be a "editor" folder inside the effect folder. It contains a lot of test stuff.

I've attached the file tree if anyone is interested in looking at the file hierarchy. All it tells you are the file names and their type, so it should be perfectly fine to post here.

Too bad the western release of PQ will most likely be encrypted with the 7.x encryption making it (currently) impossible to edit out the voices and undub the game by using the Japanese game's voices. All we can do is pray that they decide to use the 6.x encryption like the Japanese release for some weird reason. Unfortunately that's most likely wish thinking.
 

Attachments

Hi, I've refactored/improved the tool. Now it shows a percentage and it's a little bit faster.
Launcher.dat: https://www.dropbox.com/s/g0znm6uyikawy74/Launcher.dat?dl=0
Launcher_noGW.dat: https://www.dropbox.com/s/orxl5befn5adfko/Launcher_noGW.dat?dl=0
Source code: https://bitbucket.org/xerpi/3ds-ctr-decryptor-refactored/src
Code:
Original version by VOiD
Refactored by xerpi
 
Many thanks to Ryanrocks462, planetarian, Vappy and everyone else who helped me testing :P
Also thanks to megazig for the crypto lib.

Hope you like it!
 
Hi, I've refactored/improved the tool. Now it shows a percentage and it's a little bit faster.
Launcher.dat: https://www.dropbox.com/s/g0znm6uyikawy74/Launcher.dat?dl=0
Launcher_noGW.dat: https://www.dropbox.com/s/orxl5befn5adfko/Launcher_noGW.dat?dl=0
Source code: https://bitbucket.org/xerpi/3ds-ctr-decryptor-refactored/src
Code:
Original version by VOiD
Refactored by xerpi
 
Many thanks to Ryanrocks462, planetarian, Vappy and everyone else who helped me testing :P
Also thanks to megazig for the crypto lib.

Hope you like it!



Awesome work, testing now :)
 
  • Like
Reactions: Ryanrocks462
What tool are you guys using
Hi, I've refactored/improved the tool. Now it shows a percentage and it's a little bit faster.
Launcher.dat: https://www.dropbox.com/s/g0znm6uyikawy74/Launcher.dat?dl=0
Launcher_noGW.dat: https://www.dropbox.com/s/orxl5befn5adfko/Launcher_noGW.dat?dl=0
Source code: https://bitbucket.org/xerpi/3ds-ctr-decryptor-refactored/src
Code:
Original version by VOiD
Refactored by xerpi
 
Many thanks to Ryanrocks462, planetarian, Vappy and everyone else who helped me testing :P
Also thanks to megazig for the crypto lib.

Hope you like it!


Cool, although it still seems to experience the same issue the original version does, of occasionally freezing upon launch.
 
Thanks. Ok this one shows 100% in the corner, but it shows the output filename as "/" (no other characters), and no file is created, so it looks like my ncchinfo.bin might be knackered after all? I checked against the spec someone posted earlier, think the problem is the filenames aren't coming out as proper utf16, I'm getting 4 bytes per character (1 recognisable ascii character followed by three null (00) bytes) whereas I assume it should be two (can someone confirm that?). Will try to figure out how to fix that for my mac build of ctrKeyGen, suggestions very welcome, and in the meantime will try to use the windows .exe to test.
 
  • Like
Reactions: Ryanrocks462
Thanks. Ok this one shows 100% in the corner, but it shows the output filename as "/" (no other characters), and no file is created, so it looks like my ncchinfo.bin might be knackered after all? I checked against the spec someone posted earlier, think the problem is the filenames aren't coming out as proper utf16, I'm getting 4 bytes per character (1 recognisable ascii character followed by three null (00) bytes) whereas I assume it should be two (can someone confirm that?). Will try to figure out how to fix that for my mac build of ctrKeyGen, suggestions very welcome, and in the meantime will try to use the windows .exe to test.

Yeah, UTF16 chars should take 2 bytes not 4.
 
  • Like
Reactions: Ryanrocks462
I'm getting stuff like that with ALBW image files. Strange image formats. probably weird tiling.
Have you had any luck?
I started writing my own program to decipher the file, but I can't figure out how the colors work. They are obviously 16bpp and they have transparency.
I've never programmed before, so this was already a task for me to get to.
lXDlsiF.png


If anyone knows how I can figure out the colors and transparency, It would be appreciated. Some kind of documentation or something would be great. Thank you.
 
  • Like
Reactions: cearp
Cheers, yeah experimenting with it now. Google suggested swapping the wchar_t definition for unsigned short, so I did that, and the ncchinfo.bin looks right now, I can see the full filenames in what looks like standard unicode (ascii + 00). However this time the Launcher.dat seems to have stopped at "Opening sd:/ncchinfo.bin ..." - no percentage or output filename.
 
Have you had any luck?

2 things i can think of. does the image offset seem right might be a byte or so off.
Is there an image pallet
you might be reading the colors in the wrong order ex argb , rgba or any order of those.
 

Site & Scene News

Popular threads in this forum