This could make it much easier to handle files like NCCH which use various different encryption settings. The current method is kinda crappy and inefficient.
The idea of this would be to create multiple CTRFileIO objects (or anything, really, as long as it's a file-like object) to provide decrypted access to a part of the NCCH/ExeFS, one for each section where the crypto settings changes (e.g. between NCCH header, ExtHeader, logo/plain, ExeFS header, ExeFS .code, ExeFS other files, RomFS). Then combine them all and provide access to it as if it was one large file.
This would especially make the ExeFS part much easier to implement due to its weird crypto requirements.
Another idea for this is to provide a decrypted version of a CCI. This wouldn't work so well for CIA due to the hashes in the tmd.
This could make it much easier to handle files like NCCH which use various different encryption settings. The current method is kinda crappy and inefficient.
The idea of this would be to create multiple CTRFileIO objects (or anything, really, as long as it's a file-like object) to provide decrypted access to a part of the NCCH/ExeFS, one for each section where the crypto settings changes (e.g. between NCCH header, ExtHeader, logo/plain, ExeFS header, ExeFS .code, ExeFS other files, RomFS). Then combine them all and provide access to it as if it was one large file.
This would especially make the ExeFS part much easier to implement due to its weird crypto requirements.
Another idea for this is to provide a decrypted version of a CCI. This wouldn't work so well for CIA due to the hashes in the tmd.
This is already mostly implemented in ninfs for use with Switch NAND backups: https://github.com/ihaveamac/ninfs/blob/fc50af10930c41fec37d7b99051121fb07f2c2db/ninfs/mount/_common.py#L219 but it only takes file paths.