you got a response right under your question....also your quotes in your signature are very distractingSo let me ask again since no one responded:
you got a response right under your question....also your quotes in your signature are very distractingSo let me ask again since no one responded:
So let me ask again since no one responded:
I don't believe it does, endian mismatch. the only thing i've gotten to work with extracting the SZS files is wszst.
No, I was using the first version. Thanks, that solved the issue!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).
"error: could not open input file!"ctrtool -t =romfs --romfsdir=OutDir RomFS.bin
"error: could not open input file!"
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.
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.
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!
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.
Have you had any luck?I'm getting stuff like that with ALBW image files. Strange image formats. probably weird tiling.
Have you had any luck?