add helper tool to fix `mremap_encrypted: Operation not permitted` error

[dlevi309]

Disclaimer: I’m not sure where this issue begins and ends, I’ve been dealing with it on iOS 14.4

To make it brief, I think it may be more productive to share a shell session of the mremap_encrypted: Operation not permitted error and how this fixes it. So this is the first run at attempting to decrypt a process that hasn’t been launched

D12:~ root# fouldecrypt -v "/var/containers/Bundle/Application/A120BD82-53B7-4D8F-9C95-2BB139D08CA1/Adguard Pro.app/PlugIns/ProTunnel.appex/ProTunnel" test
00:15:24.381401	mapping input file: /var/containers/Bundle/Application/A120BD82-53B7-4D8F-9C95-2BB139D08CA1/Adguard Pro.app/PlugIns/ProTunnel.appex/ProTunnel
00:15:24.385785	mapping output file: test
00:15:24.386348	copying original data of size 0x1368b0...
00:15:24.390752	    not fat binary, directly decrypting it!
00:15:24.390777	    finding encryption_info segment in slide...
00:15:24.390781	        found encryption_info segment at offset f68
00:15:24.390812	    decrypting encrypted data...
00:15:24.390815	        Going to decrypt crypt page: off 0x4000 size 0xd8000 cryptid 1, cpuType 100000c cpuSubType 0
00:15:24.390911	        Already 16k aligned, directly go ahead :)
00:15:24.390953	-->> 16k-aligned mmaping(0x0, 0xd8000, 5, 0x2, 3, 0x4000)
00:15:24.391020	<<-- 16k-aligned mmaping(0x0, 0xd8000, 5, 0x2, 3, 0x4000) = 0x1050d8000
00:15:24.391028	<<-- unprotect mremap_encrypted(0x1050d8000, 0xd8000, 1, 0x100000c, 0x0)
mremap_encrypted: Operation not permitted
00:15:24.399268	-->> unprotect mremap_encrypted(0x1050d8000, 0xd8000, 1, 0x100000c, 0x0) = -1

This is the second and third command:

D12:~ root# my_dlopen "/var/containers/Bundle/Application/A120BD82-53B7-4D8F-9C95-2BB139D08CA1/Adguard Pro.app/PlugIns/ProTunnel.appex/ProTunnel"
D12:~ root# fouldecrypt -v "/var/containers/Bundle/Application/A120BD82-53B7-4D8F-9C95-2BB139D08CA1/Adguard Pro.app/PlugIns/ProTunnel.appex/ProTunnel" test
00:15:46.015517	mapping input file: /var/containers/Bundle/Application/A120BD82-53B7-4D8F-9C95-2BB139D08CA1/Adguard Pro.app/PlugIns/ProTunnel.appex/ProTunnel
00:15:46.016055	mapping output file: test
00:15:46.016332	copying original data of size 0x1368b0...
00:15:46.017886	    not fat binary, directly decrypting it!
00:15:46.017904	    finding encryption_info segment in slide...
00:15:46.017908	        found encryption_info segment at offset f68
00:15:46.017946	    decrypting encrypted data...
00:15:46.017950	        Going to decrypt crypt page: off 0x4000 size 0xd8000 cryptid 1, cpuType 100000c cpuSubType 0
00:15:46.017991	        Already 16k aligned, directly go ahead :)
00:15:46.018019	-->> 16k-aligned mmaping(0x0, 0xd8000, 5, 0x2, 3, 0x4000)
00:15:46.018063	<<-- 16k-aligned mmaping(0x0, 0xd8000, 5, 0x2, 3, 0x4000) = 0x1038f0000
00:15:46.018086	<<-- unprotect mremap_encrypted(0x1038f0000, 0xd8000, 1, 0x100000c, 0x0)
00:15:46.018149	-->> unprotect mremap_encrypted(0x1038f0000, 0xd8000, 1, 0x100000c, 0x0) = 0
00:15:46.018156	            copying 0x11b20c000 to 0x1038f0000, size d8000
00:15:46.020957	        copying enc pages, size: 0xd8000..
00:15:46.021088	        cleaning up...

foulwrapper works great, but on iOS 14 fouldecrypt/flexdecrypt fail with any processes that haven’t been catalogued into recent memory, using dlopen seems to alleviate this issue without having to launch the process (which is great for plugins, extension, etc.). With this, the success rate of foulwrapper decrypting everything has been 100% of the time (for me)

[HenryQuan]

I also had the same issue on iOS 16.7. The solution works great for the main exectuable, not with extensions. Not sure if there are future changes in iOS 15 or 16.

[dlevi309]

I also had the same issue on iOS 16.7. The solution works great for the main exectuable, not with extensions. Not sure if there are future changes in iOS 15 or 16.

I think there may have been changes introduced in iOS 16 that restrict dlopen'ing executables, although I wasn't sure

[dlevi309]

@HenryQuan hey, I didn’t think I would be taking this any further, but are you willing to test something out that may potentially work on extensions while running iOS 16?

switch out the code in my_dlopen.c with this:

#include <stdio.h>
#include <dlfcn.h>

int main(int argc, char **argv)
{
    void *(*sym_dlopen)(const char *, int) = dlsym(RTLD_DEFAULT, "dlopen");
    for (int i = 1; i < argc; i++) {
        void *handle = sym_dlopen(argv[i], RTLD_NOW);
    }
    return 0;
}

it’s a simple method of redirection that filters dlopen through a layer of dlsym

[HenryQuan]

@dlevi309 I can have a try later. I guess it should also work also with Swift right with dlsym.