Posted by Syphurith

Thanks. I could test it with a newer release of FBI first.

Posted by Syphurith

Thanks. I could test it with a newer release of FBI first.
Read its batch file it seems.. i should use a decrypted CXI of H&S to test it?
The fixtmd should take in a decrypted CXI as its APP.
Well, i would execute all those commands manually..

Posted by Syphurith

Eh.. Have you already tested it yet?
Since the ctrtool packaged won't run for me.. Could you get me a link to its source?
Yes, it might not work for N3DS now. However it should not be too hard to do so.
Anyway, please give me some time to let me test injection of newer FBI first..

EDIT:: NVM. i would try to do all those line by line.
EDIT:: I made a huge mistake, fixtmd needs an encrypted file.

Posted by Syphurith

Quite sorry, but the .app file size: H&S(O3DS,JPN,2050): 812KB, generated: 804KB.
I should have done it no harm.. Since the ctrtool in package won't run for me, I used mine, and replaced the "*" mark with the actual file name.
Note: Not all programs would recognize the "*" mark.

And for FixTmd, I highly doubt how to calculate the hashes for multiple contents. NVM.
Content Hash: 0xB04 + A*0x30 + 0x10. The SHA-256 hash of the whole content.
Stage2 Hash: 0x204. SHA-256 hash of 0xB04-EOF.
Stage3 Hash: 0x1E4. SHA-256 hash of 0x204+0x900.

In short current FixTmd would not break a N3DS content, when it only uses the content #0.

Posted by Syphurith

You might want to use my dumped JPN APP to test if size matches..

For the HASH of the Content Table. You might want to just update this:

//Calculate Hash of third part of TMD.
printf("[INFO]Update hashes #2..");
sha2(fctmd + 0xB04, fltmd - 0xB04, fh, 0);
memset(fx,0,256);
sprint_sha256(fx, fh);
printf("0x0208:0x0B04-0x%04X:\n%s\n",fltmd,fx);
memcpy(fctmd+0x0208, fh, 32);

And i tried the tool again, it could generate a same TMD, using APP and TMD extracted from decrypted CIA of N3DS H&S.
However it still deserves a fix. Parameters order of it would be changed.

Posted by Syphurith

Good news for you.
Your generated app was finally injected into my emuNand (surely i re-encrypted it)
and it does load into FBI 1.4.14, over my old H&S 2050 JPN.

I would try another CIA, then.

Posted by Syphurith

I had just figured out a faulty re-encryption script.
Just now I had injected the DevMenu620 which i tried many times before - just its first success.
Have you looked at some posts this page? You can even build a xorpad without the actual encrypted file.
Now the next step for this tool, maybe a porting to other script.. or maybe not.

And.. For the N3DS, you may have to use NAND dumps for that, cause it may have multiple APP files.
RxTools only handle the single app ones, so no injection for N3DS now.

Posted by Syphurith

Let me take a note
1.The file size had better be the same.. (May be the cause of what the NAND recorded?)
2.You should have it decrypted first, and remember to reencrypt it.
3.FixTMD should be called to use the encrypted APP/CXI, and this is what this tool missed.
And yes, Batch script is dirty and quick. And much of those might be done in a better way (i mean, python/nodejs/..) At least batch is really a bad language.. You might know what i mean.

Posted by Syphurith

Eh.. Yes if that is added to decrypt9 that could be super convinient.
However i think release a easy-to-use PC edition with xorpad decryption/encryption may be a starter kit for guys.
At least 3dstool did quite a bulk of dirty work.. Ha.
Still, i don't know if you have finally succeeded in the injection to your N3DS..
So i think using this PC edition to be a alpha/beta, and the code could be taken to decrypt9.

Posted by Syphurith

I've found a relationship to a common error.
As you know sometimes injected the generated app, the H&S shows no banner.
This is actually caused by a wrong crypto mark. To be used there, you have to made the injection app Encrypted. However, in NCCH file, 0x01BF. The mark should be cleared to "Crypto:Secure(0)" or else it would show "Crypto:None". This is due to 3dstool implementation, it sometimes just throws this mark away. I know how you might think about it. Oh no. It wouldn't load a wrong crypto, nor a decrypted one. And, even it is without the romfs.bin it could still run - if the original injection app requires no romfs.bin. So dummy romfs.bin is not really that needed.

Finally I've got some correct injection apps. The tool is here: NodeJS version

Posted by d0k3 on GBAtemp.org

... AND IT WORKS!!!

Decrypt9 now includes two new features, one for dumping the H&S app, the other for injecting it. You need to compile from source, there's no binary release yet. And I suggest you use my last batch script to generate the inject .app (yup, .tmd / .xorpads not required), because the .app to inject needs to be the exact same size as the original H&S app (that requirement will most likely be removed later), and I'm not sure if @Syphurith's script makes sure of that.

I will most likely refine some of how this works now. And, btw, we can easily inject to other system apps, too, but I'm unsure if that would be a good idea.

Now, although the Decrypt9 way might be the more noob friendly in the long run, we still need @Syphurith's script - because only with Syphuriths method, the .app to inject can be bigger than the original H&S app (that would never work in Decrypt9). If @Shadowtrance makes that GUI, it best includes both ways (with / without D9).


Advantages of the Decrypt9 method:

Faster, needs only 3 steps (dump hs.app via D9, create inject app on PC, inject hs.app via D9).
You only need to handle the .app file, no .tmd or .xorpads.
Less room for error, much more noob friendly.
Also, safer. Injecting files into FAT images using tools like OSFmount might lead to fragmentation, which in turn might lead to unexpected results. With Decrypt9 that will never happen, as it will leave everything untouched but the actual files space.

@Syphurith, could you add the Decrypt9 method to your nodeJS script (as an alternative). It is the same as the other one, just with an already decrypted hs.app, no .tmd and no xorpads.

Posted by idgrepthat on Github

Don't recommend. Power functions are unstable and can potentially brick.

Posted by idgrepthat on Github

Reboot has never caused problems for me, but homebrew and Gw's power-off functions can cause 3ds's to behave strangely. Like return 0 causing a full power-off in dsi mode instead of the homemenu grey screen that's expected. Yellows8 bricked his 3ds while researching these registers.

Maybe it's something you still feel is worth it, but I think it's an unnecessary risk given the small reward. I'm not that concerned about it because I never use homebrew power off any more. Your call.

Posted by plutoo

I'm pretty sure it's safe. There are two things that can cause a brick with MCU pokes (afaik). They are as follows:

1. Power cycle from ARM11 when ARM9 has things left that it hasn't yet written to NAND. This could corrupt the file-system, internal files could become out-of-sync, and whatnot.
2. Poking around with LED pattern registers (this was how Yellows8 bricked his 3DS).

In this case neither applies so I'd say go for it.

Posted by Dazzozo

Yes. The FixedCryptoKey bit is set. See http://3dbrew.org/wiki/NCCH#NCCH_Flags

The key used (fixed / zero) depends on whether its a system title. This is all explained at http://3dbrew.org/wiki/NCCH#Encryption

Posted by Dazzozo

-- Snip --

Posted by Syphurith

Indeed there are more homebrews using the XML and perhaps with arguements..
Such as CHMM2, ftbrony, installer, menuhax_manager, qtm.. For example?
However i do suggest you to ask smea or others on #3dsdev for help on this.
BTW, what you suppose to do with the arguements? RxTools just loads a static payload and it's fine.
Yes if this could be loaded using CN or other *hax, those 8.1 users may have a way for xorpads..