Jtool2 -d Bug

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

Jtool2 -d Bug

Postby ccnut » Sat Jul 25, 2020 10:52 am

There is a simple bug in the pattern matching code in jtool2. For example, say I wanted to find the nested image for address 0x18085e000.

Code: Select all
$ jtool2 -a 0x000000018085e000 dyld_shared_cache_arm64
processLoadCommands: Not a Mach-O magic (0xd10103ff)
Address 0x18085e000 (offset 0x85e000) is in Foundation:__TEXT.__text..


Then try to disassemble

Code: Select all
$ jtool2 -d __TEXT.__text dyld_shared_cache_arm64:Foundation | head -n5
In shared cache - resolving dependencies (0x16fadd000, 0x16fe44000)
Disassembling 1616560 bytes from address 0x180368b70 (offset 0x1b70):
<redacted>:
180368b70       0xd10103ff  SUB         SP, SP, 64              R31 = SP - 0x40 (0xffffffffffffffc0)
180368b74       0xa90157f6  STP         X22, X21, [SP, #16]
180368b78       0xa9024ff4  STP         X20, X19, [SP, #32]

You'll notice this isn't the correct address base for Foundation. In fact, it's CoreFoundation

Code: Select all
$ jtool2 -l dyld_shared_cache_arm64 | grep 0x180368b70
        0x180368b70-0x1804f3620 CoreFoundation:__TEXT.__text    (1616560 bytes)


A workaround is to specify the full to the nested image (Foundation, in this case)

Code: Select all
$ jtool2 -d dyld_shared_cache_arm64:/System/Library/Frameworks/Foundation.framework/Foundation | head -n5
Note: 16877 symbols detected in this file! This will take a little while - generate a companion file or use '-q' for quick mode..
In shared cache - resolving dependencies (0x16b6ba000, 0x16bdfd000)
Disassembling 2474292 bytes from address 0x180744860 (offset 0x1860):
<redacted>:
180744860       0x140463ac  B           0x18085d710             <redacted>
<redacted>:
180744864       0x321b07e1  _ORR        W1, WZR, #0x60          R1 =  0x60
180744868       0x140442c2  B           0x180855370             _NSAllocateObject


It seems that the code is confusing CoreFoundation and Foundation, likely because one is a substring of the other. I noticed this only because I have a bash script that wraps jtool2 in various ways to provide at least the above functionality (search + disassemble + seek to pattern). But this breaks when disassembling the wrong nested image. I'm not sure of the code structure of jtool2, but a simple fix could also be to optionally export the fully qualified path of the nested image rather than its basename. Something like

Code: Select all
$ jtool2 -va 0x000000018085e000 dyld_shared_cache_arm64
processLoadCommands: Not a Mach-O magic (0xd10103ff)
Address 0x18085e000 (offset 0x85e000) is in /System/Library/Frameworks/Foundation.framework/Foundation:__TEXT.__text..


Currently the -v option does nothing when used with -a. This was tested on a 13.3.1 d10ap ipsw with the latest jtool2

Perhaps for now, the original jtool could also be used in place of jtool2 for this option.
Code: Select all
$ jtool -a 0x000000018085e000 dyld_shared_cache_arm64
Address 0x18085e000 falls in mapping 0, /System/Library/Frameworks/Foundation.framework/Foundation


Code: Select all
$ jtool2
Welcome to JTool 2.0-Final (SFO) compiled on Feb 10 2020 04:55:32. Try "--help" for help
ccnut
 
Posts: 12
Joined: Fri Mar 15, 2019 5:11 pm

Return to Tools

Who is online

Users browsing this forum: No registered users and 4 guests