revanced-patcher feat: Native Library patching and File Handle provider for arbitrary files

Feature description

It would be extremely useful to support binary patching native libs as well as the ability to obtain a file handle to any file in the APK

This would be especially useful for patching more advanced applications, ie: Google Photos, or patching games, such as Unity games where patching the native libraries could allow for code changes whilst arbitrary file patching would let you modify asset bundles at ease

I think it would be important to provide a file handle rather than the traditional patched API as it may be important to include a custom parser or the ability to create and delete files as needed

Motivation

This feature should be implemented because it would allow a significant number of apps and games to be patchable through Revanced than otherwise and would allow for further changes to apps than otherwise, especially for games

Acknowledgements

[X] This issue is not a duplicate of an existing feature request.
[X] I have chosen an appropriate title.
[X] All requested information has been provided properly.

Dec 21 '23 23:12 ThatHackerDudeFromCyberspace

In regards:

ReVanced Patcher MUST check if a library patch is involved and MUST read/write them JIT. This action is taken for efficiency reasons.
A new LibraryPatch MAY be added, and if implemented, the ReVanced Patcher MUST offer a LibraryContext : Context as a parameter. This context MUST allow reading and writing libraries in the /lib path. Reading is accomplished by opening a stream directly to the ZipEntry, and writing is done by opening a stream to the disk.
```
context["/lib/some.lib"].let { file: File -> 
    // Can open an input stream to read from ZipEntry
    // Can open an output stream to write/cache to disk
}
```
Additionally, the ReVanced Patcher MUST record a list of written libraries in the writing stage and provide them with the patch result to the caller.
Operations that depend on each other SHOULD share read operations, but write operations MUST be locked. If a patch opens a write stream without closing it, and another patch depends on it, an exception MUST be raised when attempting to open a write stream. A patch can lock write operations for another patch if it implements the Closeable interface. Here's how it works:
1. Patch A depends on Patch B.
2. Patch B is executed and happens to implement Closeable.
3. In the PatchB#close method, Patch B closes a write stream to a file.
4. After Patch B executes, Patch A is executed and tries to write to the same file.
5. This operation fails because Patch B still holds the lock on the write stream.
6. Patch A raises an exception.
7. Since no other patch depends on Patch B, the PatchB#close method is called.
8. This action frees the lock, allowing other patches to write to that file.
A FilePatch MUST be added for arbitrary files, including libraries if NO LibraryPatch is added. However, NO write access to resources or dex files SHOULD be granted, as these are meant to be modified by other kinds of patches. Read access MUST be granted.
Due to similarities in behavior between resource patches and the requested patch, refactoring classes regarding OOP patterns MAY be necessary. Consideration MUST be given to OOP principles, and a common interface or abstract class MAY be introduced.

Dec 22 '23 00:12 oSumAtrIX

You mention a possibility that LibraryPatch is not implemented, how would patching libraries work in this case?

Dec 22 '23 00:12 ThatHackerDudeFromCyberspace

If no LibraryPatch is added, FilePatch will be able to read and write libraries:

A FilePatch MUST be added for arbitrary files, including libraries if NO LibraryPatch is added. However, NO write access to resources or dex files SHOULD be granted, as these are meant to be modified by other kinds of patches. Read access MUST be granted.

Dec 22 '23 00:12 oSumAtrIX

That's actually not a bad idea to be honest, and LibraryPatch will probably inherit from FilePatch, though long-term it would be interesting to expand upon it by adding convenience functions specific to libraries, such as locating a symbol in a library and such

Dec 22 '23 00:12 ThatHackerDudeFromCyberspace

A FilePatch MUST NOT be open for inheritance for a LibraryPatch as it already offers all implementations that a LibraryPatch would need.

Dec 22 '23 00:12 oSumAtrIX

Oh right that makes sense It would just be a copy of it then (but with library specific checks ofc)

Dec 22 '23 00:12 ThatHackerDudeFromCyberspace

Couldn't I just implement this by mostly modifying ResourceContext and ResourcePatch and having it so that it just reads/writes to the streams directly rather than using DomFileEditor? (or probably just an alternative to DomFileEditor that provides direct access to the streams?)

The whole closing mechanism is somewhat confusing to me tbh, it seems that it only actually writes out the file on a "close" and the file is otherwise held in memory?

Jan 01 '24 07:01 ThatHackerDudeFromCyberspace

It will be held in memory unless you do not close the stream. The reason for the closing mechanism is that two patches may attempt to write to the same file which can be a problem.

Jan 01 '24 08:01 oSumAtrIX

Fair, however, I can see this potentially being problematic when trying to patch large files/libraries

Especially stuff like Unity bundles which can exceed sizes in the gigabytes