JTool II: Testers wanted

Used for discussing the various tools in the book as well as encouraging members to share tools

Re: JTool II: Testers wanted

Postby morpheus » Wed Jun 05, 2019 3:57 am

MacOS kernelcaches ("immutablekernel"s in /S/L/PrelinkedKernels) are malformed and break otool. Just saw this on MacOS 14 and 15b kernels, and since for CLI-folk otool -tV is a necessary evil, I brought back jtool's -rc feature to remove load commands. This can also strip signatures, if directed at the lc number of the LC_CODE_SIGNATURE.
Screen Shot 2019-06-04 at 11.27.38 PM.png
Screen Shot 2019-06-04 at 11.27.38 PM.png (626.04 KiB) Viewed 1265 times
morpheus
Site Admin
 
Posts: 694
Joined: Thu Apr 11, 2013 6:24 pm

Re: JTool II: Testers wanted

Postby Wenbo » Wed Jun 05, 2019 4:39 am

Hey, starting my WiFi trip again with jtool2, wanted to extract the MobileWiFi from shared_cache, got 3 Warning and an "Unable to open output!" message, any idea how to set a proper output to jtool2? Thanks!

Code: Select all
ywbdeMacBook:jtool2 ywb$ sw_vers
ProductName:   Mac OS X
ProductVersion:   10.13.6
BuildVersion:   17G4015
ywbdeMacBook:jtool2 ywb$ ARCH=arm64 ./jtool2 --version
This is 2.0 (beta 2, 我❤️ 上海) compiled on Jun  4 2019 08:51:03
ywbdeMacBook:jtool2 ywb$

ywbdeMacBook:jtool2 ywb$ ARCH=arm64 ./jtool2  -e MobileWiFi dyld_shared_cache_arm64 > output.txt
Warning: File is likely truncated (or header corrupt?) Binding opcodes falls outside file
Warning: File is likely truncated (or header corrupt?) Binding opcodes falls outside file
Warning: File is likely truncated (or header corrupt?) LC_FUNCTION_STARTS falls outside file
Unable to open output!
ywbdeMacBook:jtool2 ywb$
 


The output.txt is something like:
Code: Select all

0x1000-0x4a71c libcorecrypto.dylib:__TEXT.__text   (300828 bytes)
   0x30a7c-0x30bc0 libSystem.B.dylib:__TEXT.__text   (324 bytes)
   0x30bc0-0x30d88 libSystem.B.dylib:__TEXT.__stubs   (456 bytes)
   0x30d88-0x30f68 libSystem.B.dylib:__TEXT.__stub_helper   (480 bytes)
   0x30f68-0x30fa8 libSystem.B.dylib:__TEXT.__const   (64 bytes)
   0x30fa8-0x31000 libSystem.B.dylib:__TEXT.__unwind_info   (88 bytes)
... ...
~33,000 lines of dump
... ...
   0x3af9d898-0x3afa2098 Symbol Table   (18432 bytes)
   0x3d15f1c8-0x3d15f5f0 Function Starts   (1064 bytes)
   0x3d420280-0x3d4202f0 Data In Code   (112 bytes)
   0x3d61e4f0-0x3ea6f8fc String Table   (21304332 bytes)


The jtool seems OK with the same shared_cache file:
Code: Select all
ywbdeMacBook:jt ywb$ ./jtool --version
This is jtool v1.0 (Amsterdam) - with code signing support for keychain identities (on MacOS only), compiled on Apr 14 2018 22:22:37
ywbdeMacBook:jt ywb$ ARCH=arm64 ./jtool -v -e MobileWiFi dyld_shared_cache_arm64
/System/Library/PrivateFrameworks/MobileWiFi.framework/MobileWiFi located in mapping 0, address        18c218000
Extracting
extractImage: Got Mach-O 64 header...
Extracting /System/Library/PrivateFrameworks/MobileWiFi.framework/MobileWiFi at 0xc218000 into dyld_shared_cache_arm64.MobileWiFi
extractImage: Got segment: __TEXT @ c218000, 3e000 VMSize: 0x3e000 - Moving to 0
extractImage: Patching Section: __TEXT.__text from 0xc219108 to 0x1108
extractImage: Patching Section: __TEXT.__stubs from 0xc24c658 to 0x34658
extractImage: Patching Section: __TEXT.__stub_helper from 0xc24d0c0 to 0x350c0
extractImage: Patching Section: __TEXT.__cstring from 0xc24db40 to 0x35b40
extractImage: Patching Section: __TEXT.__const from 0xc2549b0 to 0x3c9b0
extractImage: Patching Section: __TEXT.__oslogstring from 0xc255253 to 0x3d253
extractImage: Patching Section: __TEXT.__objc_classname__TEXT from 0xc255634 to 0x3d634
extractImage: Patching Section: __TEXT.__objc_methname from 0xc255673 to 0x3d673
extractImage: Patching Section: __TEXT.__objc_methtype from 0xc255774 to 0x3d774
extractImage: Patching Section: __TEXT.__unwind_info from 0xc255860 to 0x3d860
extractImage: Writing out 3e000 (253952) bytes from c218000 (RC: 253952)
extractImage: Got segment: __DATA @ 366c6750, 1e0 VMSize: 0x1e0 - Moving to 3e000
extractImage: Patching Section: __DATA.__objc_selrefs from 0x366c6750 to 0x3e000
extractImage: Patching Section: __DATA.__objc_superrefs__DATA from 0x366c67c8 to 0x3e078
extractImage: Patching Section: __DATA.__objc_ivar from 0x366c67d0 to 0x3e080
extractImage: Patching Section: __DATA.__data from 0x366c67e0 to 0x3e090
extractImage: Patching Section: __DATA.__bss from 0x0 to 0xc99778b0
extractImage: Writing out 1e0 (480) bytes from 366c6750 (RC: 480)
extractImage: Got segment: __DATA_CONST @ 303f9090, a0b0 VMSize: 0xa0b0 - Moving to 3e1e0
extractImage: Patching Section: __DATA_CONST.__got from 0x303f9090 to 0x3e1e0
extractImage: Patching Section: __DATA_CONST.__la_symbol_ptr from 0x303f91c8 to 0x3e318
extractImage: Patching Section: __DATA_CONST.__const from 0x303f98c0 to 0x3ea10
extractImage: Patching Section: __DATA_CONST.__cfstring from 0x303fa7e8 to 0x3f938
extractImage: Patching Section: __DATA_CONST.__objc_classlist__DATA_CONST from 0x30402f48 to 0x48098
extractImage: Patching Section: __DATA_CONST.__objc_protolist__DATA_CONST from 0x30402f50 to 0x480a0
extractImage: Patching Section: __DATA_CONST.__objc_imageinfo__DATA_CONST from 0x30402f58 to 0x480a8
extractImage: Patching Section: __DATA_CONST.__objc_const from 0x30402f60 to 0x480b0
extractImage: Writing out a0b0 (41136) bytes from 303f9090 (RC: 41136)
extractImage: Got segment: __DATA_DIRTY @ 384f1830, 10c VMSize: 0x10c - Moving to 48290
extractImage: Patching Section: __DATA_DIRTY.__objc_data from 0x384f1830 to 0x48290
extractImage: Patching Section: __DATA_DIRTY.__data from 0x384f1880 to 0x482e0
extractImage: Patching Section: __DATA_DIRTY.__bss from 0x0 to 0xc7b56a60
extractImage: Writing out 10c (268) bytes from 384f1830 (RC: 268)
extractImage: Got segment: __LINKEDIT @ 38908000, 61678fc VMSize: 0x61678fc - Moving to 4839c
extractImage: Writing out 61678fc (102136060) bytes from 38908000 (RC: 102136060)
extractImage: Patching LC_DYLD_INFO
extractImage: Patching LC_SYMTAB
extractImage: Patching LC_DYSYMTAB
Patching .. from dataoff 0x3d15f1c8 to 0x489f564
Patching .. from dataoff 0x3d420280 to 0x4b6061c
Wenbo
 
Posts: 1
Joined: Wed Jun 05, 2019 3:13 am

Re: JTool II: Testers wanted

Postby darkknight » Sun Jun 09, 2019 5:50 am

yep I'm not able to extract dylibs either....I get Unable to open output!....
darkknight
 
Posts: 99
Joined: Mon Apr 18, 2016 10:49 pm

Re: JTool II: Testers wanted

Postby jonios » Thu Jun 13, 2019 1:22 am

jtool2 doesn't show the available architectures in a universal binary.
Code: Select all
$ uname
Linux
$ jtool
Welcome to JTool 2.0 (beta 2, 我❤️ 上海) compiled on Jun  7 2019 07:41:21. Try "--help" for help


Code: Select all
$ jtool MyApp
Fat binary, little-endian, 2 architectures:


But then setting ARCH works.
Code: Select all
$ ARCH=arm64 jtool -l MyApp
LC 00: LC_SEGMENT_64             Mem: 0x000000000-0x100000000   __PAGEZERO
LC 01: LC_SEGMENT_64             Mem: 0x100000000-0x101848000   __TEXT
...


J Says: Fixed. Thank you
jonios
 
Posts: 8
Joined: Tue May 01, 2018 10:11 pm

Re: JTool II: Testers wanted

Postby objc » Wed Jun 19, 2019 5:27 pm

This doesn't work when trying to extract a dylib from the dyld iOS shared cache:
Code: Select all
$ jtool2 -v -e SwiftUI dyld_shared_cache_arm64

It simply prints nothing to the screen and nothing is extracted, as far as I can tell. Is this the correct command?
objc
 
Posts: 1
Joined: Wed Jun 12, 2019 10:09 pm

Re: JTool II: Testers wanted

Postby morpheus » Wed Jun 19, 2019 6:39 pm

I'm rewriting the extraction logic to do a complete reconstruction of the original dylib (so that it may be reused). During this time, -e on the shared cache is disabled. Bear with me. When -e comes back for SLCs, it will be a fully working decacher.
morpheus
Site Admin
 
Posts: 694
Joined: Thu Apr 11, 2013 6:24 pm

Previous

Return to Tools

Who is online

Users browsing this forum: No registered users and 3 guests

cron