Currently the summary view does not know when a gadget is a double jump so it will only display the first jump. Need to find a way for it to know. Possible solution is to include a flag in the bookmark ('d', 'double', etc) so it knows to get the next gadget as well.

When trying to save signatures from a PS2 ELF, located in a shared project, the script appears to run for a while then crashes with the following error :

RizzoSave.py> Running...
Building Rizzo signatures, this may take a few minutes...
Traceback (most recent call last):
  File "C:\Users\CreepNT\ghidra_scripts\RizzoSave.py", line 15, in <module>
    rizz = rizzo.Rizzo(currentProgram)
  File "__pyclasspath__/utils/rizzo.py", line 290, in __init__
  File "__pyclasspath__/utils/rizzo.py", line 612, in _generate
  File "__pyclasspath__/utils/rizzo.py", line 589, in _hash_function
  File "__pyclasspath__/utils/rizzo.py", line 556, in _hash_block
AttributeError: 'NoneType' object has no attribute 'isData'
RizzoSave.py> Finished!

As I would expect, no signature files are exported after this crash.

Ghidra Version : 9.2.2
Scripts located in C:\Users\CreepNT\ghidra_scripts

Any idea what could be cause this failure ? Maybe I'm missing a library ?

Check return of var.getSymbol(). It can be None and this will cause an exception when attempting to get the references.

Add processor checks to scripts that only work on certain architectures. Scripts such as MipsRopX that only support the MIPS processor should not be allowed to run against an ARM binary.

ARM binaries seem to not create them. Find a different way to discover code vs data.

I found myself scrolling through disassembly looking for functions that gave me control of more registers with a small stack displacement. Would be nice to have a script that displays all the function epilogues with a user configurable number of registers that could be used as the first gadget in a chain. Should display gadget start (epilogue start) and the amount of stack space used. Maybe other information that seems important when the script is actually written.

I noticed you're using Pointer32DataType in 96ecab2. This is a fixed size pointer and might only work on processors with a 32-bit pointer size. Initializing it like so may solve this restriction.

pointer_type = PointerDataType(None, currentProgram.getDefaultPointerSize())

Passing in None or null as the DataType in the PointerDataType constructor will construct a default pointer without a DataType.

You might need to watch out for data existing between the currentAddress and the length of the default pointer size. Sticking to the pointer size alignment may help with this. It may be retrieved via
pointer_alignment = currentProgram.getDataTypeManager().getDataOrganization().getDefaultPointerAlignment()

I have a CLI along with some modifications to the rizzo.py script that I would like to open-source. Would you all prefer to take the CLI as a pull request in a different directory in this repository, or would you rather take the rizzo CLI application in a different repository?

If the base address is set to 0 this can introduce a lot of false positives when fixing up pointers. Add a check to alert the user or disable fixing up pointers. Adding an alert is more ideal because failure to fix up pointers can kinda jack up the data sections, especially if there are function tables.

Hey.

Can Codatify convert bytes to letters and assemble them into words?

Here's an example

`sub_6B54 ; CODE XREF: .text:0000910C↓p

var_140 = -0x140
var_138 = -0x138
var_134 = -0x134
var_130 = -0x130
var_7 = -7

            PUSH    {R4-R7,LR}
            ADD     R7, SP, #0xC
            SUB     SP, SP, #0x134
            MOV     R6, SP
            ADDS    R1, R6, #7
            ADDS    R1, #0xD
            STR     R1, [R6,#0x140+var_140]
            ADDS    R4, R6, #7
            ADDS    R4, #0xA9
            STR     R4, [R6,#0x140+var_134]
            LDR     R2, =(_GLOBAL_OFFSET_TABLE_ - 0x6B6E)
            ADD     R2, PC          ; _GLOBAL_OFFSET_TABLE_
            LDR     R0, =(__stack_chk_guard_ptr - 0x41EEC)
            ADDS    R0, R0, R2      ; __stack_chk_guard_ptr
            LDR     R0, [R0]        ; __stack_chk_guard
            LDR     R0, [R0]
            STR     R0, [R1]
            MOVS    R3, #0
            STR     R3, [R6,#0x140+var_130]
            STR     R3, [R4,#4]
            STR     R3, [R4]
            ADDS    R0, R6, #7
            ADDS    R0, #0xB9
            MOVS    R1, #0x63 ; 'c'
            STRB    R1, [R0]
            MOVS    R1, #0x6C ; 'l'
            STRB    R1, [R0,#1]
            MOVS    R1, #0x61 ; 'a'
            STRB    R1, [R0,#2]
            MOVS    R1, #0x73 ; 's'
            STRB    R1, [R0,#3]
            STRB    R1, [R0,#4]
            MOVS    R2, #0x65 ; 'e'
            STRB    R2, [R0,#5]
            STRB    R1, [R0,#6]
            MOVS    R1, #0x2E ; '.'
            STRB    R1, [R0,#7]
            MOVS    R1, #0x64 ; 'd'
            STRB    R1, [R0,#8]
            STRB    R2, [R0,#9]
            MOVS    R1, #0x78 ; 'x'
            STR     R1, [R6,#0x140+var_138]
            STRB    R1, [R0,#0xA]
            STRB    R3, [R0,#0xB]
            MOVS    R1, #0x4D ; 'M'
            STRB    R1, [R0,#0xC]
            ADDS    R1, R6, #7
            ADDS    R1, #0xA9
            ADDS    R2, R6, #7
            ADDS    R2, #0xAD
            BL      sub_11F84
            STR     R0, [R4,#8]
            LDR     R0, =0x48472359
            B       loc_6BC6`

Current formatting is hard coded to default column lengths when printing the output table. Makes this dynamic because function names can be really long and throw off the whole table.

This is a really great idea for a project.

I'd like to propose an addition: PowerPC ROP scripts along the lines of the MIPS ROP scripts. I can try to do the work and create a pull request but I'm not certain how long it will take me. Just creating a ticket for the future.

Thanks again for all your hard work on converting these scripts over!

Add structure parsing and function table renaming to the fixup data portion of codatify. While not very useful on Linux based binaries this is a very useful feature on RTOS.

Just a question in regards to the example image for Fluorescence with the indirect jr t9 call to time. Does it show up as a call to time in the decompiled output or only in the disassembly reference?

Hello,

Here:
https://github.com/tacnetsol/ghidra_scripts/blob/master/utils/rizzo.py#L349
Why is the last char removed?
hex() returns a string like 0x..., not ...h which would warrant the [:-1].
If i take out the [:-1], I get lots more matches in my project.

Was this always a bug? But this would be very weird because, I've been using Rizzo successfully for many months now. How did it work previously then?
Perhaps it was caused recently by Ghidra 9.2.2 or something. A Python change perhaps.

Edit: Submitted a PR. Please let me know if it's correct / why it worked this way.

Codatify tramples over pointers when it is making everything in the data section a DWORD. Make them pointers before the mass DWORD massacre happens.