*OS Internals - The Forum

I think I'll make this a dedicated thread for all my (future) requests and bug reports for jtool, if that's ok.

This time only an aesthetic shortcoming, but symbol dumping aligns global undefined symbols with 8 spaces regardless of whether it's 32 or 64 bit:

Code: Select all

bash$ jtool -S -arch i386 /bin/sync 2>/dev/null
00001000 T __mh_execute_header
         U _exit
         U _sync
         U dyld_stub_binder
bash$ jtool -S -arch x86_64 /bin/sync 2>/dev/null
0000000100000000 T __mh_execute_header
         U _exit
         U _sync
         U dyld_stub_binder

Fixed. (Will be out in next public version of JTool) - and I'm adding the "nightly build" here..

Definitely, hit me with whatever you've got - big or small

An empty companion file seems to influence disassembling.

Using "joker -j" on an 64bit 8.4 kernel produces an empty companion file (0 bytes).
But the mere presence of the file seems to make jtool disassemble about 5 times faster and not create names like _func_ffffff8014d0b78c.
The full diff is about 10MB, but here are the first 100 lines:

Code: Select all

22c22
< ffffff8014c0304c   BL     _func_ffffff8014d0b78c   ; ffffff8014d0b78c
---
> ffffff8014c0304c   BL     0xffffff8014d0b78c
114c114
< ffffff8014c031a0   BL     _func_ffffff8014c50598   ; ffffff8014c50598
---
> ffffff8014c031a0   BL     0xffffff8014c50598
172c172
< ffffff8014c03284   BL     _func_ffffff8014c4ef90   ; ffffff8014c4ef90
---
> ffffff8014c03284   BL     0xffffff8014c4ef90
177c177
< ffffff8014c03298   BL     _func_ffffff8014cd5974   ; ffffff8014cd5974
---
> ffffff8014c03298   BL     0xffffff8014cd5974
246c246
< ffffff8014c0339c   BL     _func_ffffff8014cd5cd4   ; ffffff8014cd5cd4
---
> ffffff8014c0339c   BL     0xffffff8014cd5cd4
279c279
< ffffff8014c03420   BL     _func_ffffff8014cd5cd4   ; ffffff8014cd5cd4
---
> ffffff8014c03420   BL     0xffffff8014cd5cd4
284c284
< ffffff8014c03430   BL     _func_ffffff8014cd5e64   ; ffffff8014cd5e64
---
> ffffff8014c03430   BL     0xffffff8014cd5e64
290c290
< ffffff8014c03448   BL     _func_ffffff8014c2e578   ; ffffff8014c2e578
---
> ffffff8014c03448   BL     0xffffff8014c2e578
292c292
< ffffff8014c03450   BL     _func_ffffff8014cd5e64   ; ffffff8014cd5e64
---
> ffffff8014c03450   BL     0xffffff8014cd5e64
296c296
< ffffff8014c03460   BL     _func_ffffff8014c301cc   ; ffffff8014c301cc
---
> ffffff8014c03460   BL     0xffffff8014c301cc
360c360
< ffffff8014c03560   BL     _func_ffffff8014c4ef90   ; ffffff8014c4ef90
---
> ffffff8014c03560   BL     0xffffff8014c4ef90
375c375
< ffffff8014c03598   BL     _func_ffffff8014cd5e64   ; ffffff8014cd5e64
---
> ffffff8014c03598   BL     0xffffff8014cd5e64
379c379
< ffffff8014c035a8   BL     _func_ffffff8014cd5e64   ; ffffff8014cd5e64
---
> ffffff8014c035a8   BL     0xffffff8014cd5e64
416c416
< ffffff8014c03634   BL     _func_ffffff8014c72d74   ; ffffff8014c72d74
---
> ffffff8014c03634   BL     0xffffff8014c72d74
431c431
< ffffff8014c03670   BL     _func_ffffff8014c43db4   ; ffffff8014c43db4
---
> ffffff8014c03670   BL     0xffffff8014c43db4
437c437
< ffffff8014c03688   BL     _func_ffffff8014c43db4   ; ffffff8014c43db4
---
> ffffff8014c03688   BL     0xffffff8014c43db4
445c445
< ffffff8014c036a4   BL     _func_ffffff8014cd565c   ; ffffff8014cd565c
---
> ffffff8014c036a4   BL     0xffffff8014cd565c
555c555
< ffffff8014c0384c   BL     _func_ffffff8014c4ef90   ; ffffff8014c4ef90
---
> ffffff8014c0384c   BL     0xffffff8014c4ef90
561c561
< ffffff8014c03864   BL     _func_ffffff8014c2e750   ; ffffff8014c2e750
---
> ffffff8014c03864   BL     0xffffff8014c2e750
563c563
< ffffff8014c0386c   BL     _func_ffffff8014cd5974   ; ffffff8014cd5974
---
> ffffff8014c0386c   BL     0xffffff8014cd5974
567c567
< ffffff8014c0387c   BL     _func_ffffff8014c301cc   ; ffffff8014c301cc
---
> ffffff8014c0387c   BL     0xffffff8014c301cc
743c743
< ffffff8014c03b2c   BL     _func_ffffff8014c4ef90   ; ffffff8014c4ef90
---
> ffffff8014c03b2c   BL     0xffffff8014c4ef90
746c746
< ffffff8014c03b38   BL     _func_ffffff8014cd5974   ; ffffff8014cd5974
---
> ffffff8014c03b38   BL     0xffffff8014cd5974
757c757
< ffffff8014c03b64   BL     _func_ffffff8014f816b8   ; ffffff8014f816b8
---
> ffffff8014c03b64   BL     0xffffff8014f816b8
760c760
< ffffff8014c03b70   BL     _func_ffffff8014cd565c   ; ffffff8014cd565c
---
> ffffff8014c03b70   BL     0xffffff8014cd565c

Only comments and BL instructions seem to be affected.

Apart from that, the help page says that destructive options will write to /tmp, but they write to out.bin.
Also, --inplace seems to be broken entirely.

I) Ok. Let me explain how the companion file works:

If jtool detects a companion file, it doesnt attempt to parse LC_FUNCTION_STARTS *or* the symbol table, which indeed speeds up disassembly by orders of magnitude. It also provides for better decompilation (companion files can assign registers at certain addresses for example). But that means that if the companion file is empty, it doesn't load any symbols at all, leaving addresses in raw form, rather than at least the func_Xxxx which it gets from FUNCTION_STARTS.

II) Joker -j creating an empty companion file, now that's a bug. Thank you. Ill fix that. Ill also post a nightly build of joker here too.

--
III) The --inplace should work. I'm confused. I use it with --sign --inplace, and it overwrites the original file. If not, then yes, it creates out.bin. not /tmp. That's a bug in the description
--

And thanks a ton for this feedback. Honestly, it's all quick fixes - but these are things I simply didn't run into - when you code your own tool, something implicitly makes you work around your own bugs, I guess.

Keep it coming!

J

Administrator wrote:when you code your own tool, something implicitly makes you work around your own bugs, I guess.

Oh definitely, I've seen this with my own software as well.

For --inplace, I've tried to combine it with -pie and --rebase and jtool still wrote to out.bin both times.

Promptly fixed:

Code: Select all

case PIE:
                {

                        int rc = macho_toggle_PIE(mmapped, (int) whatToDoArg);
                        if (rc == 0)
                        if (!inPlace) saveFile("out.bin",mmapped, filesize);
                        else { 
                                close(fd);
                                saveFile (filename, mmapped, filesize);
                        }       

                        return 0;



                }


and likewise for REBASE (though I never properly debugged that one, caveat

and it should be something like:

bash-3.2# cp /bin/ls .
bash-3.2# jtool -h ls
Magic: 64-bit Mach-O
Type: executable
CPU: x86_64
Cmds: 19
size: 1816 bytes
Flags: 0x200085
bash-3.2# jtool -pie --inplace ls
Toggling Mach-O Header MH_PIE: off
Warning: Destructive option. Output (34640 bytes) written to ls
bash-3.2# jtool -h ls
Magic: 64-bit Mach-O
Type: executable
CPU: x86_64
Cmds: 19
size: 1816 bytes
Flags: 0x85

I'm doing a couple more things (including bringing back ARM32/Thumb!!!!!) so no nightly build yet .

But keep this coming, man. Thank you.

Oh wow, A32 disassembler support would certainly make diff'ing 64- and 32bit binaries a lot easier, so that's nice.

And sure, I'll keep them coming as I hit them.

I got some serious plans, my friend. JTool started with ARM/Thumb, then I gave up at some point, commented the whole $%$#% out, and did the ARM64 which is easier. I thought 64 was the future, but with Apple's insistence to keep ARMv7k around, I guess 32-bit is here to stay as well.

I'm truly grateful for your fixes - so even if you feel nitpicky at times, keep reporting. Sure as heck beats "I just use capstone". %#$%$#.

When using the -F option without a search string, jtool says "-f: Option requires a search string", but -f is a different option and doesn't actually require that.

And a question: is the A32 disassembler gonna have support for literal pool references?

We got it good if it's just typos now . Yeah. -f is otool(1) compatible fat headers, -F is for searching a string. Promptly fixed.

A32 will have the same capabilities as A64 - including strings, literals, register tracking, the whole package, yeah. (especially important since otool doesnt have that and IDA does it poorly)