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 5452 times
morpheus
Site Admin
 
Posts: 717
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: 102
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: 9
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: 717
Joined: Thu Apr 11, 2013 6:24 pm

Re: JTool II: Testers wanted

Postby morpheus » Fri Jul 19, 2019 3:38 pm

07/07/19 - ABQ:
---------------

Features:
---------

- jtool2 --ent -v now shows entitlements blob in simPLISTic format (MUCH nicer to read!)
- jtool2 --sig -vvv recognizes null page hashes for both sha1 and sha256. If anyone needs sha384 let me know.
- Warning icons I ripped from fileproviderctl(1) - What a great idea, AAPLytes!
- System instructions (DC, IC, etc) now disarmed. Also: "RETAB", not "RETAAB"...

BugFixes:
---------
- Also support x86_64h through ARCH= (thanks, inoahdev!)
- LC_DYLD_ENVIRONMENT (MacOS webinspectord)

Jokerlib:
---------
- Gets 9,000+ symbols from iOS 13 kernelcaches, including all IOKit metaclasses
morpheus
Site Admin
 
Posts: 717
Joined: Thu Apr 11, 2013 6:24 pm

Re: JTool II: Testers wanted

Postby johncoates » Sat Jul 20, 2019 6:08 pm

morpheus wrote: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.


Really looking forward to this! Pulling this off would be amazing.
johncoates
 
Posts: 4
Joined: Thu Aug 31, 2017 2:34 am

Re: JTool II: Testers wanted

Postby shifman » Thu Jul 25, 2019 12:08 pm

morpheus wrote:07/07/19 - ABQ:
---------------
Jokerlib:
---------
- Gets 9,000+ symbols from iOS 13 kernelcaches, including all IOKit metaclasses


Im using jtool2 version (beta 3, ABQ) compiled on Jul 19 2019....
When trying to kextract any kernel extension, for example when used over kernelcache from ios 13 Beta, using the command (with JDEBUG flag):
Code: Select all
jtool2 -K com.apple.driver.AppleIDAMInterface kernelcache.release.iphone10b`

I Get the following output:
Code: Select all
This is a kernelcache
__PRELINK_INFO.__info has been stripped of PrelinkExecutableLoadAddress.. Trying Method #3
Entry point is @0xfffffff007004000, Exit is 0xfffffff007183ff0
Kextracted com.apple.driver.AppleIDAMInterface from 0xfffffff00900c290


No file created from this command containing the wanted kext.
Also when im using the command with the flag "-Ke", still jtool seems to recognize that this is a new style kext but still kext files are not extracted :(

Moreover I have tried using it on ios 11 kernelcache and only got the following output:
Code: Select all
This is a kernelcache


Should jtool2 create the kext files? If not is there an alternative for doing such a thing?

Note:
I have tried using joker, but it seems to not work over kernelcache of ios 13 :(
shifman
 
Posts: 1
Joined: Wed Jul 24, 2019 1:36 pm

Re: JTool II: Testers wanted

Postby pwm » Tue Jul 30, 2019 9:52 pm

morpheus wrote:07/07/19 - ABQ:
---------------
Jokerlib:
---------
- Gets 9,000+ symbols from iOS 13 kernelcaches, including all IOKit metaclasses


As of iOS 13b4 this seems to no longer be the case. It appears that Apple has removed symbols from iPhone 8 and X devices, so I only get 4584 symbols. I suspect some or most of this is due to the lack of symbols.

However, I am also noticing that some symbols are not reported correctly. In particular, hw_lock_lock_contended is being reported as mach_msg_send_from_kernel_proper. I had a list of others, but I need to go back and verify which ones are which.

Edit: It also looks like _exec_*_imgact, _kmod, _devfs_vfsops, _pmap_object_store, and_routefs_vfsops are not being decoded correctly. It looks like they're chained pointers now and jtool prints them as such rather than decoding to their correct pointer values. This is on iPhone X 13b4 BTW.
pwm
 
Posts: 2
Joined: Sun Aug 14, 2016 5:19 am

PreviousNext

Return to Tools

Who is online

Users browsing this forum: Bing [Bot] and 1 guest

cron