3 ms·

I mean, you still have root and APEX packages aren't doing anything tricky specifically to stymie modifications - they're just mounted file systems. You're stil

by chc4 3y ago

I mean, you still have root and APEX packages aren't doing anything tricky specifically to stymie modifications - they're just mounted file systems. You're still going to be able to modify system certificates, it's just going to be less convenient and need something more than dropping a single file to a folder. Hell, the code is even still falling back to the old file system path if the APEX mount doesn't exist, so you could just delete the entire module and go back to the old method.

pimterry 3y ago
> Hell, the code is even still falling back to the old file system path if the APEX mount doesn't exist, so you could just delete the entire module and go back to the old method. That's covered in the article - no, you can't do this. If you entirely unmount the apex module from the filesystem from a root shell, so the CA certificates aren't visible anywhere on the filesystem, apps will still read them successfully. And the OS blocks RW mounting of APEX modules so you can't delete the cacerts directory within the module either. It looks like apps have separate namespaced mounts, managed by the OS itself from boot. Effectively they're containerized, and as part of launching all applications the OS is mounting the certs directly into the process's view of the world. If you can find a way to modify the filesystem the apps see from a root shell, that would be great! I'd love to hear about it. But believe me that I've tried quite a few of the obvious things already.
- chc4 3y ago
  APEX namespace membership is managed by the ld.txt config file for the dynamic linker, iirc. You can probably just remove the com.android.conscrypt line, or remove the entire conscrypt APEX package from the system and unpack the libs into /system/lib64 instead. Or patch the linker not check APEX signatures, and repack it without the CA folder. Or unmount the conscrypt APEX mount and replace it with a FUSE mount that proxies everything else the CA folder. Or...a bunch of different other methods.

by chc4 3y ago

pimterry 3y ago

> Hell, the code is even still falling back to the old file system path if the APEX mount doesn't exist, so you could just delete the entire module and go back to the old method. That's covered in the article - no, you can't do this. If you entirely unmount the apex module from the filesystem from a root shell, so the CA certificates aren't visible anywhere on the filesystem, apps will still read them successfully. And the OS blocks RW mounting of APEX modules so you can't delete the cacerts directory within the module either. It looks like apps have separate namespaced mounts, managed by the OS itself from boot. Effectively they're containerized, and as part of launching all applications the OS is mounting the certs directly into the process's view of the world. If you can find a way to modify the filesystem the apps see from a root shell, that would be great! I'd love to hear about it. But believe me that I've tried quite a few of the obvious things already.

chc4 3y ago
APEX namespace membership is managed by the ld.txt config file for the dynamic linker, iirc. You can probably just remove the com.android.conscrypt line, or remove the entire conscrypt APEX package from the system and unpack the libs into /system/lib64 instead. Or patch the linker not check APEX signatures, and repack it without the CA folder. Or unmount the conscrypt APEX mount and replace it with a FUSE mount that proxies everything else the CA folder. Or...a bunch of different other methods.