Open jslegendre opened 2 years ago
Possibly related to https://github.com/DerekSelander/dsdump/issues/30#issuecomment-982910139. Basically, dsdump
fixed allocated offset gets to some edge-case where the app offset yields the same or bigger value, such overlapping the dsdump bin allocation.
-oc works for me but -sc seg faults
dsdump -sc /usr/libexec/sharingd -a x86_64
WARNING: couldn't find address 0x46f8f0b76 (0x46f8f0b76) in binary!
zsh: segmentation fault dsdump -sc /usr/libexec/sharingd -a x86_64
macOS 12.3 M1 Air dsdump Version: 0.8.0 Built: (12:52:07, Feb 8 2022)
It seems that somehow for dsdump, the next closest VM region after (0x400000000
) now is with a protection of (vm_prot_t)0x03
(rw-
) when running on Monterey. Examined with Instruments, it was MALLOC_NANO
.
MALLOC_SMALL 0x101000000 - 0x103000000 rw-/rwx
MALLOC_NANO 0x600000000000 - 0x600020000000 rw-/rwx
Stack Guard 0x7ff7bbf00000 - 0x7ff7bf700000 ---/rwx
And bypassing this protection check does not work indeed. mmap
would return -1
with error Invalid argument
.
https://github.com/DerekSelander/dsdump/blob/74ee2c35205bc3a176c58b72c4ec4fbaa313145e/dsdump/XRMachOLibrary.mm#L143
P.S. run dsdump
(0.8.3, 74ee2c3, with patched) with environment variable DEBUG=1
, we could see some debug log printed like this:
...
mem for 0x000400000000-0x000408000000 in dsdumpstruct vm_region_basic_info_64 {
vm_prot_t protection : 3
vm_prot_t max_protection : 7
vm_inherit_t inheritance : 1
boolean_t shared : 0
boolean_t reserved : 0
memory_object_offset_t offset : 0
vm_behavior_t behavior : 0
unsigned short user_wired_count : 0
}
mem for expected file 225200
mmap failed! Invalid argument 22, will try an address
...
Then, dsdump will fallback to another trial of mmap
, and this time it seems success ~but actually not. The address return by mmap is not -1
but invalid either~*, dsdump will hit segmentation fault
once it starts reading Mach-O upon this address.
...
mmap mapped to addres 0x400000000
[1] segmentation fault
*Correction: the fallback mmap
(which is without MAP_FIXED
flag) did succeed, which would map file to higher address like 0x00007FF7_BFF00000
, but dsdump
falsely truncated its higher order bits to 0x000007F7_BFF00000
(7FF7->7F7
) when reading, and that results to segmentation fault
.
https://github.com/DerekSelander/dsdump/blob/74ee2c35205bc3a176c58b72c4ec4fbaa313145e/dsdump/payload.hpp#L40
The clues above inspired me.
For Monterey, running the old stable release (dsdump_compiled.zip, 1a8857e) with env MallocNanoZone=0
should work to some degree.
# Use the old dsdump from stable release.
$ dsdump
Version: 0.1.0 Built: (16:31:02, Jul 5 2020) dsdump [option..] <mach-o-file>
# Normally, it refused to do job on Monterey.
$ dsdump --objc dsdump
0x400000000 is mapped to existing memory, exiting
# To make it work, run it with MallocNanoZone=0.
$ MallocNanoZone=0 dsdump --objc dsdump
@protocol NSObject
-[NSObject isEqual:]
...
...
Note: This trick does not work for beta version. Related discussions: https://stackoverflow.com/a/69861354/9164600, https://reviews.llvm.org/D114825
macOS Version: 12.3 (21E230) Mapped cache: /System/Library/dyld/dyld_shared_cache_x86_64h Current cache slide: 0x15015000 (not sure if it helps)
When running:
dsdump -oc /System/Library/Frameworks/Foundation.framework/Foundation
Result:
From LLDB:
When running:
dsdump -sc /System/Library/Frameworks/Combine.framework/Combine
Result:
From LLDB:
When running:
dsdump -a x86_64 -oc /System/Applications/Calculator.app/Contents/MacOS/Calculator
Result:
When running:
dsdump -a x86_64 -sc /System/Library/CoreServices/ControlCenter.app/Contents/MacOS/ControlCenter
Result:
After
NOP
ing thejne
instruction at0x010000da5d
(skipping the check that leads to the above)When running:
dsdump_patched -a x86_64 -oc /System/Applications/Calculator.app/Contents/MacOS/Calculator
Result:
Works as expected
When running:
dsdump_patched -a x86_64 -sc /System/Library/CoreServices/ControlCenter.app/Contents/MacOS/ControlCenter
Result:
From LLDB:
Hope this provides you with enough information. If you need anything else please let me know and if you ever decide to push the source for this version I am fairly confident I could fix it myself.
Thanks again for taking the time!