Decryption of .3ds leaves some encrypted junk in exefs about godmode9 HOT 3 CLOSED

Non-issue, actually, cause these areas are actually padding. Xorer does not set anything, that's why you see zero there, which means standard crypto.

Can you try this and tell me if that solves your problem?
https://transfer.sh/HKLqy/GodMode9-20170502-231926.zip

from godmode9.

Thanks. That seems to work perfectly. NCSD's fully decrypt to match D9's output. If leaving the padding encrypted was intentional (quicker?), perhaps include a quick decrypt option and full decrypt. That way end users would be aware of the difference, as it stands I think it is fair to assume that people will expect it is already a full decrypt. Though as you state, it may not be an issue but I think a full decrypt is cleaner.

0x00 means standard crypto? 3DBrew only mentions 0x01, 0x2, 0x04 and 0x20 as possible flags here

from godmode9.

Well 0x00 is not documented, because it is the standard... because for a long time it was the only flag that existed in NCCHs (there are no unencrypted, legit NCCHs, neither from eShop, neiter in NCSD rom dumps).

And no, the difference in performance is negligible. This will become the new standard. Closing this now...

from godmode9.