The original path (file_name.exefsdir) is still supported, but alternatively users can choose to put exefs patches in the same place as LayeredFS files (`load/mods/<Title ID>/exefs`).
Only enabled for NCCHs that do not have an override romfs.
LayeredFS files should be put in the `load` directory in User Directory. The directory structure is similar to yuzu's but currently does not allow named mods yet. Replacement files should be put in `load/mods/<Title ID>/romfs` while patches/stubs should be put in `load/mods/<Title ID>/romfs_ext`.
This implementation is different from Luma3DS's which directly hooks the SDK functions. Instead, we read the RomFS's metadata and figure out the directory and file structure. Then, relocations (i.e. replacements/deletions/patches) are applied. Afterwards, we rebuild the metadata, and assign 'fake' data offsets to the files. When we want to read file data from this rebuilt RomFS, we use binary search to find the last data offset smaller or equal to the given offset and read from that file (either from the original RomFS, or from replacement files, or from buffered data with patches applied) and any later files when length is not enough.
The code that rebuilds the metadata is pretty complex and uses quite a few variables to keep track of necessary information like metadata offsets. According to my tests, it is able to build RomFS-es identical to the original (but without trailing garbage data) when no relocations are applied.
The BPS format allows distributing patches that are smaller and that do
not contain copyrighted content if data is relocated
(unlike non-trivial IPS patches).
This is essential for games such as MM3D that have three barely
different code revisions. Supporting all three versions would
demand an unreasonable amount of work; with BPS patches only one
version has to be supported.
This changes ApplyCodePatch to return a ResultStatus, which makes it
possible to determine whether patch applying has failed. Previously,
only a boolean was returned, and false was returned when no patch
was found OR when a patch was found but applying it failed.
This also changes AppLoader_NCCH to return an error if patching fails
because the executable is likely to be left in an inconsistent state
and we should not proceed booting in that case.
Fixes a regression from #4862, which caused the NCCH title ID checking
heuristic to be skipped whenever the exheader is replaced.
I was thinking the heuristic wouldn't be needed in that case, but it
turns out that many users still have pathological NCCHs that indicate
they are encrypted but are actually decrypted...
Now the original exheader is always read and used for the heuristic
to determine whether the NCCH is actually encrypted; only then do we
load a replacement exheader (if it exists) to avoid affecting the
heuristic.
Require and assume that override exheaders are decrypted for
consistency with Luma's loader behaviour and to ensure consistent
behaviour regardless of whether the NCCH is marked as encrypted or not.
Currently, exheader overriding with an encrypted NCCH would cause
the title ID checking heuristic to mistakenly disable encryption,
which would then make exefs loading fail.
This allows an IPS patch to edit .bss. This is useful for game patches
that need to add code, as putting things in .bss allows adding new code
*without* editing .code and thus without having to relocate everything.
Currently, having a replacement code.bin causes Citra to crash as it is
trying to load icon data from code.bin because of a typo. This commit
fixes that typo.
To eliminate System::GetInstance usage. Archive type like SelfNCCH and SaveData changes the actual reference path for different client, so archive backend interface should accept client information from the service interface. Currently we only pass the program ID as the client information.
This commit it automatically generated by command in zsh:
sed -i -- 's/BitField<\(.*\)_le>/BitField<\1>/g' **/*(D.)
BitField is now aware to endianness and default to little endian. It expects a value representation type without storage specification for its template parameter.
* FileSys/DelayGenerator: add missing #include and virtual dtor
Added the needed include so that it won't cause error if another file includes this without including the depended files
Deleting a virtual class via base type without virtual dtor is UB, which happens inFileBackend.
* FileSys/DelayGenerator: move function definition into cpp file/n/nTo avoid generating vtable in all units that includes the header file
* filesys/delay_generator: rearrange #include
Two functional change:
QueryProcessMemory uses the process passed from handle instead current_process
Thread::Stop() uses TLS from owner_process instead of current_process
* Service::HTTP_C: Add decryption of the ClCertA
* fixup! Service::HTTP_C: Add decryption of the ClCertA
* fixup! Service::HTTP_C: Add decryption of the ClCertA
* FileSys:: Add MakeNCCHArchivePath and MakeNCCHFilePath; Small fixes in HTTP_C::DecryptDefaultClientCert
* fixup! fixup! Service::HTTP_C: Add decryption of the ClCertA
* fixup! fixup! fixup! Service::HTTP_C: Add decryption of the ClCertA
* Add virtual SharedFont; Load if dumped is missing
* Move open_source_archives to externals; add readme and git hash to open_source_archives
* Updated shared font to newest version: m fixed, symbols fixed
These kinds of casts invoke undefined behavior, due to both the aliasing
rule, and from an alignment point-of-view. Use the way that's guaranteed
to always work instead.
By default, a regular copy requires an atomic increment and decrement. A
move avoids this from occurring, which makes sense when the constructor
is taking the shared_ptr by value.
The FS module overrides whatever value was in the saveid high dword with 0x48000 when trying to open the archive.
This fixes the problem where the Home Menu would create a few SharedExtData archives with 0x48000 as the saveid high, but then try to open them with 0 as the high value and fail.
