Views: 613,933 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 11-22-17 07:11 PM

Main - Posts by d0k3

Pages: 1 2 3 4
Posted on 07-09-15 04:12 PM, in Accessing the NAND (via fopen / opendir) Link | #252
Okay, one last question about that code: Does it decrypt the AGBSAVE correctly? It's difficult to test if it does. A comment in the rxTools source code says it (decrypting AGBSAVE) doesn't work that way. Personally, I'd have suspected that it requires the same method as the TWL partitions, not the same as the CTR partitions.

Posted on 07-10-15 04:22 AM, in Accessing the NAND (via fopen / opendir) (rev. 2 of 07-14-15 09:45 AM) Link | #254
I never ran a GBA game, so it's all zeroes in there, and if I try to decrypt I essentially get a xorpad :). Anyways, testers say it's fine, too!

Posted on 07-14-15 09:25 AM, in Accessing the NAND (via fopen / opendir) (rev. 2 of 07-14-15 10:49 AM) Link | #258
Alright, back again. I've got some trouble accessing the NAND CID via the GW browser method. In short, I can not access that memory (0x01FFCD80) without the 3DS freezing. Works fine on Brahma though.

Is there any alternative method of retrieving the NAND CID that could work?

More info (but maybe nothing too useful) here:

And more info... I already searched for information, and there seems to be a GetNandCid() function somewhere:
... but how to access this? No idea.

Posted on 07-20-15 05:05 PM, in Getting the NAND CID via GW Launcher.dat (rev. 2 of 07-20-15 05:05 PM) Link | #275
Hi everyone,

is there any way to get the NAND CID via the GW Launcher.dat (browser / O3DS) method?

Via Brahma it is pretty easy:
memcpy(nand_cid, (u8*) 0x01FFCD80, 16)
See also here.

However, the exact same line of code leads to a crash, if ARM9 access is gained via the GW Launcher.dat method.

There also seems to be a GetNandCid() function somewhere:
... but how to access it? No idea.

This is for my Decrypt9 fork, if you wonder.

Any ideas?

Posted on 07-21-15 06:01 AM, in Getting the NAND CID via GW Launcher.dat Link | #277
Posted by megazig
check that iTCM is enabled for access from your mode.

Thank you! I'm almost sure it is not. Otherwise it shouldn't freeze.

Is there any way to check that manually or even manually enable access?

Posted on 09-22-15 07:19 PM, in Decrypting CIA contents directly? (rev. 3 of 09-22-15 07:22 PM) Link | #423
I know, CIAs can be decrypted via just installing them and then decrypting the extracted contents. However, this is not what I want to do... What I want to do is to decrypt CIA files (such as stuff downloaded from CDN) directly.

3DSbrew has this information:
Posted by http://3dbrew.org/wiki/CIA
The contents (NCCH/SRL) are encrypted using 128-bit AES-CBC. The encryption uses the decrypted titlekey from the ticket, and the content index from the TMD padded with zeros as the IV.

The ctr (or iv) is pretty simple, and it seems the titlekey has to be used as key. But which? NormalKey, KeyX or KeyY? And what keyslot to use? Maybe 0x3F because that seems to be unused for anything else?

profi200's GitHub repo of makerom has some code showing the decryption of a CIA:

However, that doesn't help me much in understanding how to do it on 3DS, because there seems to be only one key in that code (which is based on polarssl).

Can anyone help?

Posted on 09-23-15 04:19 AM, in Decrypting CIA contents directly? (rev. 2 of 09-23-15 04:23 AM) Link | #425
Posted by Dazzozo
It can obviously only be a normal key, if this crypto can be performed on a PC.

Which keyslot you use is up to you, and how much you care depends on what you're doing. If you're not FIRM launching and just MCU-rebooting (on exit) it doesn't really matter outside of slots you want to use elsewhere.

Edit: 0x11 is a good slot for temporary work. Nintendo also uses it for this purpose.

Thank you! I forgot to say, makerom from Project CTR cannot decrypt untouched CIAs (from CDN), so there must be more to it. If the decryption could really be done on PC in all cases, this would already be in makerom. It might still be possible the 3DS hardware is only needed to decrypt the titlekey, though, which would make things a lot easier.

Posted on 10-01-15 09:27 PM, in Decrypting CIA contents directly? Link | #441
Posted by Dazzozo
Yeah, you got it. Only the encryption of the title key uses a "special" key pair (hardware key generator). The title key itself is a normal key.

Posted by profi200
You can't do everything on the PC because the title key needs to be decrypted through the AES engine. If you have the decrypted title key however it's easy to decrypt the contents of titles.

Thanks a ton, both of you! After some fiddling around (and noticing my crypto lib is even more broken than I thought it was :/), I finally managed to properly implement full CIA decryption in my WIP version of Decrypt9.

Posted on 10-20-15 06:55 AM, in SHA hash functions via 3DS registers? Link | #524
Browsing around 3Dbrew, I stumbled upon this:

I'm pretty sure, using these registers to calculate the SHA-256 instead of a SHA-256 software implementation would be much faster, but I'm also careful with the low level stuff.

So, I wonder, is there already some small and working library available for this? Anyone know something?

Posted on 10-20-15 06:01 PM, in SHA hash functions via 3DS registers? Link | #527
Posted by profi200

No access from ARM11 usrland. This uses the SHA directly.

Already coded my own routines based on that and working :). Thank you, again!

Posted on 10-29-15 07:07 AM, in Injecting other apps over Health & Safety? Link | #599
I'm currently thinking about adding a universal app injector (to Health & Safety) to Decrypt9, but I can't find a starting point.

There's the 3DS FBI NAND Inject Generator by Riku. It will not work for N3DS and source code is not available. I did some reverse engineering, though, and it looks like Riku's tool doesn't really generate a fitting FBI inject, but rather identifies the H&S version via the TMD and selects from a range of "precompiled" FBI injects to dump.

So, how to actually generate a fitting inject? This is how I think I'd have to go about it:
1. Have a .3DS or .CIA of the app to inject & a dump of the 3DS H&S .TMD and NCCH ready.
2. Fully decrypt and dump the ExeFS from the app to inject.
3. Replace the ExeFS in the H&S NCCH with the one just dumped. That means all files, code, banner & icon.
4. Encrypt the ExeFS in the same way as the ExeFS in the original H&S app was encrypted. Alternatively, leave it unencrypted and set the NCCH header accordingly (2. option would be easier).
5. Pad the new H&S NCCH with zeroes so it has the exact same size as the old one or use a dummy file in RomFS to reach the desired size (1. option would be easier).
6. Recalculate the SHA-256 hashes in the NCCH and the .TMD.
7. Done! (of course, the new H&S inject would only work when signatures are patched)

Maybe I missed something, any ideas? Also, this would of course not work when the app to inject has a bigger ExeFS than H&S.

Posted on 10-29-15 06:17 PM, in Injecting other apps over Health & Safety? Link | #612
Thanks! I'll take a deeper look tomorrow. Just a few remarks for now... I do think the CXI for the inject has to be the exact same size as the H&S app. No problem doing this, Rikus injects have a variable size dummy file inside the RomFS for this reason, I think... Also, almost all of the code for properly reencrypting the inject app (if that is required) and building the TMD is already in Decrypt9.

What would help me a lot would the H&S app files for various FW versions, so that I can compare them to Rikus FBI inject files. Any idea how I can get them?

Posted on 10-30-15 05:55 AM, in Injecting other apps over Health & Safety? Link | #617
Posted by Syphurith
I'm glad to see you have already know how to build the TMD..
Do you mean that where to get precompiled and ready-for-use app and tmd files for injection? If so you can just take a look at rxTools release package, there is /tools/fbi_inject// app and tmd in it. Most of those should be correctly created.
But i wonder how exactly to build a valid .app file. I've tried to replace the exefs (so banner, icon, logo would be changed also), and repacked and re-encrypted it back. However once i tapped it in EmuNand, it just show a black screen and poped out an error. I should have some faults while creating the CXI..
Hope you can get a valid tool, either for Decrypt9, or for PC.

I'm pretty sure we'll get this to work :). I already knew about the valid inject files from the rxTools archive. What I'm searching for is the original, untouched H&S app & tmd, best for multiple regions/version. I can't get it from my own system, cause there are no valid injects available for N3DS.

Posted on 10-30-15 03:47 PM, in Injecting other apps over Health & Safety? (rev. 2 of 10-31-15 07:02 AM) Link | #625
Posted by Syphurith
Oh now I understood. I would upload a H&S app from my decrypted NAND, from 9.8 and 4.1, JPN.
Could i post those links? I mean it might be illegal? Note that the xorpads for different versions are different - cause different names.

Oh yes, anyway, I've packaged it. 2050 (9.8) and 1024(4.1) included. Password for that zip file is its filename, NO extension, NO spaces.
Please tell me once you get this file, and let it purge it off. Banned from 3dsdev, i can not deliver you the link more secured.
I think you should read all those content of this single post carefully. Thanks. Hope it helps you, even a little.

Alright, thanks a ton! Got it, so you can remove it. Which single post do you mean? I'll look over the files and will see what I can say about them later!

Posted on 10-30-15 04:14 PM, in Injecting other apps over Health & Safety? Link | #626
Alright, after a quick first look....

ExeFS in a proper inject only has the .code replaced (when compared to the original H&S app). RomFS just contains a dummy file to make sure that the inject app has the exact same size as the original one. Both easy to handle. Encryption of the .app and modification of the .tmd, we can handle, and adapting the NCCH header should not be a biggie either.

The ExHeader looks to be coming from FBI. The only think adapted between different proper injects is the remaster version (1 byte), which is easy to adapt ourselves.

Not completely sure now, but I think we can do this. What would help a lot, would be knowing which FBI version Riku's Converter uses. Finding this out ourselves would be as simple as injecting, running and looking for the version number. Can't do, though, as I only own a N3DS.

Posted on 10-31-15 08:46 AM, in Injecting other apps over Health & Safety? (rev. 4 of 10-31-15 08:49 AM) Link | #630
Posted by profi200
Don't link or share copyrighted content here.

Sorry, won't happen again. To be honest, I've been unsure wthere this falls under the copyrighted category. We both removed the links (even from quotes) now.
Posted by Syphurith
Well i was hoping for your getting the file, and now link is removed.
Wait a minute for me to inject it in.. Confirmed to be 1.3.8. However minor version isn't known. This inject app git version: 876adcfcadda127be7dc292c5f21c07bcb11cd48, 1.3.8 release on May 3rd, 2015. code.bin matches. Compared FBI.cia to fbi_inject.app.... And you're right, exheader is nearly same from fbi. code.bin the exactly same. banner.bin and icon.bin are same as original H&S, while romfs is empty.

The generated inject app and tmd for 2050 JPN O3DS, is exactly the same file from rxTools..
Wait WTF? the app file and rxtools one are the same, and xorpads are all the same, however those code.bin lengths mismatch!
Loaded the code.bin into ida, and it shows all data.. Confused.. However it works.. lol.
Problem solved, due to wrong behavior of ctrtool. Once used 3dstool to unpack the file, the code.bin matches the one from rxTools fbi_inject.app.
Anyway, forget about it.. Just use 3dstool when ctrtool goes wrong.

Eh.. Maybe the exe contains some interesting things too, cause it request a tmd.

Well, I can explain why it is identical with the one from rxTools - that's because rxTools uses Riku's inject files :). Also, RomFS is not empty - it contains a dummy file to reach the desired file size (same size as H&S).

The remaining mystery now is the ExHeader - when comparing the proper inject ExHeader with the one gained from the FBI 1.3.8 CIA content 0 ExHeader, this is what is different:
0x000 - Application title ("safe" instead of "FBI", from H&S)
0x00E - Remaster version (has to be same as .app/.tmd number)
0x1C8 - Jump ID (has to be same as ACI program id, see below)
0x200 - Access control info (ACI) program id (taken from H&S)
0x248 - ACI file system access info (FBI + H&S permissions combined)
0x600 - ACI2 program id (taken from H&S)
0x648 - ACI2 file system access info (FBI + H&S permissions combined)

Info taken from here. Mystery solved? I think so! We need to try this, though, and coding this won't be simple.

Posted on 11-01-15 09:50 AM, in Injecting other apps over Health & Safety? (rev. 3 of 11-01-15 10:20 AM) Link | #637
Posted by Syphurith
Eh.. I get a purely legal way for you to get those .app file next time. You don't need to install them!

1. Get your Decrypt9 compiled and set up.
2. Get the packed cia version of the title via 3dnus.
3. Place those encrypted ones into your sdmc:/D9Decrypt.
4. Use decrypt9 to decrypt the cia! with a deep method.
5. Use ctrtool to extract those contents from the decrypted cia. You can extract the TMD too.
6. Note that the 0000 part of the contents might be a NCCH.
7. Now as you've get the decrypted NCCH, and TMD. Jobs done.
Yes so it could be done in this way.. Haven't check extracted ones against the decrypted normal ones..
I don't care about this any more. Since you can check it yourself if you wish.
You can get those EUR/USA/KOR/CHN ones. Well older title might be found in that ISO site.
Thanks for this guy in this post for this, i don't know that could before. Hope the progress goes smoothly.

Continuing from yesterday... The actual NCCH header only has the offsets, sizes and hashes for ExeFS and RomFS modified (which is understandable) + the hash for the ExtHeader.

Now, what do we need to do?
1. Build new (valid, hashes need to be correct) ExeFS with .code from FBI, all other files H&S
2. Build new (valid, hash needs be correct) RomFS with a dummy file (this is so that the resulting app is the exact same size as H&S
3. Create the ExtHeader as I wrote above
4. Adapt the NCCH header from H&S as I wrote above
5. Take plain region & logo region from H&S
6. Adapt the hashes in the H&S .TMD
7. Put all that stuff together

I guess CTRtool & Makerom will be able to do a lot of that stuff, and for the remainder, a small program I'll code will do. I didn't get your fix TMD code to work, though. Any more ideas?

Posted on 11-01-15 10:59 AM, in Injecting other apps over Health & Safety? Link | #640
Posted by Syphurith

Continuing from here... If we had a tool (or two) that could inject ExeFS, RomFS and ExtHeader into an existing CXI (while also taking care of the hashes/offsets/sizes in the NCCH header AND touching the rest as little as possible), I think the rest would be manageable. Is there anything such as this?

Posted on 11-01-15 12:05 PM, in Injecting other apps over Health & Safety? (rev. 2 of 11-01-15 12:05 PM) Link | #644
Posted by Syphurith
For this purpose, you might try DecryptedReplacer (or dd?). Its theory is quite plain, and it only replace the same sized content from A to B. Just padding all those binaries size first, all parts should be smaller than original. You would still have to create a valid tmd and exheader and hashes.
I was thinking of using 3dstool/ctrtool/makerom to do its unpack/repack. And after that all we need to do might be to recreate the exheader and tmd.
Well indeed 3dstool is best for NCCH/CXI. However i didn't tested the other files it generated, that the ncchheader.bin. It could always generate a valid CXI if proper material is given, cause the tool is invented for tranlation purpose. Yes, not always the exefs.bin and romfs.bin could be the same for them..

Alright, good! It looks like 3DStool does the trick. I unpacked the H&S CXI, then repacked it and got the exact same file. We're a good step closer now. ExeFS building and RomFS building can be done via either 3DStool or CTRtool. The only things left are adapting the ExtHeader and getting the TMD fixer to work. Is the TMDfixer written by you? I can't compile it because it complains about missing files, and I can't just run it because there are .dll files missing.

Posted on 11-01-15 12:13 PM, in Injecting other apps over Health & Safety? (rev. 2 of 11-01-15 12:29 PM) Link | #645
... but I have trouble building the new ExeFS.bin via 3DStool. It simply doesnt work, I get garbled output:
ERROR: open file exefs/»“AÍMM W6Q–€‰Cˆ®ïd‰«Ç@™ž¹£Ðø/ røQ¹ÏìAPWë2œ©ü<ﲸu’[æÈCMB÷Ug`-néJ_1ÔÄrsÉq&vn*}’.bin failed

ERROR: open file exefs/®ïd‰«Ç@™ž¹£Ðø/ røQ¹ÏìAPWë2œ©ü<ﲸu’[æÈCMB÷Ug`-néJ_1ÔÄrsÉq&vn*}’.bin failed

ERROR: open file exefs/røQ¹ÏìAPWë2œ©ü<ﲸu’[æÈCMB÷Ug`-néJ_1ÔÄrsÉq&vn*}’.bin failed

ERROR: open file exefs/ﲸu’[æÈCMB÷Ug`-néJ_1ÔÄrsÉq&vn*}’.bin failed

ERROR: open file exefs/`-néJ_1ÔÄrsÉq&vn*}’.bin failed

ERROR: open file exefs/&vn*}’.bin failed

ERROR: open file exefs/í¾4Ë
S>a ·æ/;0.bin failed

ERROR: create file failed

Any ideas?

EDIT: Nevermind, got it! But, can you help me get the TMDfixer to work?
Pages: 1 2 3 4

Main - Posts by d0k3

Page rendered in 0.019 seconds. (2048KB of memory used)
MySQL - queries: 22, rows: 99/99, time: 0.010 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2017-11-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.