Page 1 of 1

jtool feedback

PostPosted: Tue Oct 17, 2017 7:06 pm
by 6b7615028f0b476a64cd
I've been using jtool version "Last 1 before 1.0!" (Home Sweet Home) (SHA1 155e68323df7139da68a474943b5800c4447e75d) on the shared cache from iPad_64bit_11.0.2_15A421_Restore.ipsw, and I've encountered some bugs/missing features.
  1. jtool thinks some short backwards jumps are long forward jumps instead
    For example,1 address 0x180a5b6a0 (CoreFoundation) contains b7fffe74, which jtool disassembles to "TBNZ X20, #63, 0x180a6b66c". The branch target should actually be 0x180a5b66c.
  2. jtool mis-decompiles TBNZ instructions
    For example, address 0x180a5b668 (CoreFoundation) contains "TBZ X20, #63, 0x180a5b6a4" but the decompilation above it says "if (R20 & 0x80000000 != 0)" instead of "if (R20 & 0x80000000 == 0)"
  3. jtool does not deal well with the stack pointer being adjusted via other registers
    For example, address 0x180a64908 (CoreFoundation) contains
    Code: Select all
    ADD     X8, SP, #0           ; ___R8 = R31 (0x180a6490c) + 0x0 =
    SUB     X4, X8, #16       ; X4 = 0xaabbcccfffffff0 -|
    ADD     X31, X4, #0       ; Hmm... SP not based off itself or FP?
    Then the decompiler thinks that all subsequent offsets from X8 are at SP+0.
  4. jtool displays register 31 as the first argument of STUR
    For example, address 0x180a64914 (CoreFoundation) is disassembled as "STURB W31, [X8, #-16]" even though the decompiler knows that W31 means WZR in this case.

Also, it would be nice if jtool silently skipped blank lines in the companion file instead of complaining that they are malformed.

Re: jtool feedback

PostPosted: Wed Oct 18, 2017 9:55 am
by morpheus
No sweat! Most of these are easy fixes when I output the strings - I knew of some but kind of grew oblivious and just ignored them.. Glad to see other people are using jtool that deeply - and Expect them all resolved soon!

Thank you!That's the exact kind of bug reporting I am looking for!