HearseDev
commented
1 year ago since it was a code signing issue, I ended up disabling SIP temporarily until there is a solution.
Closed HearseDev closed 1 year ago
HearseDev
commented
1 year ago since it was a code signing issue, I ended up disabling SIP temporarily until there is a solution.
romainthomas
commented
1 year ago Well actually if the problem is a signature issue, you can compile yourself O-MVLL for your Apple Silicon right?
HearseDev
commented
1 year ago Well actually if the problem is a signature issue, you can compile yourself O-MVLL for your Apple Silicon right?
I did and I was encountered the same issue using the docker instructions. Also, there seems to be another issue, when enabling obfuscate_struct_access, it compiles fine for debug build, but for release build, an error occurs, also related to Code Signature. I can open a separate issue for this with how to reproduce this issue.
Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))
Exception Codes: UNKNOWN_0x32 at 0x0000000112b4c000
Exception Codes: 0x0000000000000032, 0x0000000112b4c000
Termination Reason: Namespace CODESIGNING, Code 2 Invalid Page
VM Region Info: 0x112b4c000 is in 0x10e54c000-0x116bf0000; bytes after start: 73400320 bytes before end: 67780607
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
shared memory 10e544000-10e54c000 [ 32K] r--/r-- SM=SHM
---> mapped file 10e54c000-116bf0000 [134.6M] r--/rwx SM=COW ...t_id=ab6a8e35
GAP OF 0xc210000 BYTES
MALLOC_TINY 122e00000-122f00000 [ 1024K] rw-/rwx SM=PRV
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x1a9c9adf0 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x1a9cac8d8 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x1a9ca3638 mach_msg_overwrite + 540
3 libsystem_kernel.dylib 0x1a9c9b16c mach_msg + 24
4 CoreFoundation 0x1a9db9bdc __CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x1a9db84c8 __CFRunLoopRun + 1232
6 CoreFoundation 0x1a9db78a4 CFRunLoopRunSpecific + 612
7 Foundation 0x1aacbfe58 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
8 Foundation 0x1aad38cf0 -[NSRunLoop(NSRunLoop) run] + 64
9 ReportCrash 0x104e95d28 0x104e78000 + 122152
10 dyld 0x1a99afe50 start + 2544
Thread 1 Crashed:
0 libdyld.dylib 0x1a9ce2550 dyld3::MachOFile::isMachO(Diagnostics&, unsigned long long) const + 40
1 libdyld.dylib 0x1a9ce242c dyld3::FatFile::isValidSlice(Diagnostics&, unsigned long long, unsigned int, unsigned int, unsigned int, unsigned long long, unsigned long long) const + 80
2 libdyld.dylib 0x1a9ce242c dyld3::FatFile::isValidSlice(Diagnostics&, unsigned long long, unsigned int, unsigned int, unsigned int, unsigned long long, unsigned long long) const + 80
3 libdyld.dylib 0x1a9cf6dac dyld3::FatFile::forEachSlice(Diagnostics&, unsigned long long, bool, void (unsigned int, unsigned int, void const*, unsigned long long, bool&) block_pointer) const + 328
4 libdyld.dylib 0x1a9ce4d40 dyld4::Atlas::Mapper::mapperForMachO(lsl::Allocator&, dyld4::FileRecord&, lsl::UUID const&, void const*) + 320
5 libdyld.dylib 0x1a9ce9668 Also, here are some tests on memory used(including background processes):
-> Always returning true on only obfuscate_constants -> 6GB average used (although gets stuck on some functions for several minutes)
-> Always returning true on only obfuscate_arithmetic -> 6.7GB average used (fairly quick)
-> Always returning true on only flatten_cfg -> 11GB+ average used (got stuck on a file, the memory kept increasing, the file was not at all large, around 100+ lines, never completed compiling, I ended it because it always taking too long)
-> Always returning true on obfuscate_constants and obfuscate_arithmetic -> Memory shot up to 14GB used instantly. (never finished compiled, was taking too long, I ended it)
-> Always returning true obfuscate_arithmetic and flatten_cfg -> Memory spiked to 13.5GB used gradually, was stuck on a file, I ended up ending it.
Also, at one point of time, the resulting binary came out in the size of 96+ mb, in comparison, it is usually because 3-5mb. I forgot which options I had enabled. but I will report.
Seems like using options in combination and returning True on them instead of specifically picking portions of code to obfuscate, it starts struggling. Is this to be expected? or is there a memory leak happening. If so, is there a certain way I can figure out and help you pinpoint where the issue might be?
In comparison: Hikari, with mostly all of it's checks enabled, compiles my binary with max 5.5GB ram used and also fairly quick
Would really love to help with this project any way I can, I believe it has immense potential.
Do you believe you could start a discord community server, etc so it is easier to communicate. I believe it could also be beneficial.
Sorry for cluttering the issue section.
romainthomas
commented
1 year ago Yes, I just created this server.
Random thoughts about your message and I think we can continue the discussion on discord.
You enabled the passes with the global option set to true which means that all the functions are obfuscated. Actually, O-MVLL is designed (and the Python API is here to serve this purpose) to be applied on a subset of (functions, c/cpp file etc) of what you compile.
If you can share the configure/source I'll be happy to help fixing these performances/memory issues.
romainthomas
commented
1 year ago The discussion moved to Discord. Waiting for the Docker image to reproduce the issue.
kucaca
commented
1 year ago add @lru_cache(maxsize=1)
Target: iOS O-MVLL Version: OMVLL Version: 1.1.0-86087c7 / 14.0.0git (d5f117e38620783fc095e5620416bdae08554588) Compilation of O-MVLL: CI Platform: M1 on MacOS Ventura 13.0.1, Apple clang version 14.0.0 (clang-1400.0.29.202)
Steps to reproduce: main.c:
Compile:
Output:
Crash log:
crash.zip