Ghidra reverse engineering tool - page 2 - General Discussion and Assistance - CHDK Forum

Ghidra reverse engineering tool

  • 11 Replies

Online philmoz

  • *****
  • 3123
    • Photos
Re: Ghidra reverse engineering tool
« Reply #10 on: 30 / May / 2019, 05:50:29 »
Ghidra 9.0.4 available -
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)


Offline reyalp

  • ******
  • 12059
Re: Ghidra reverse engineering tool
« Reply #11 on: 01 / June / 2019, 18:25:50 »
I played with the versioning tool a bit more.

As expected, manually selecting and configuring the "correlators" seems like the better approach. This is done with the + icon on the toolbar, after starting a version tracking session.

You can run additional correlators later. Some benefit from having accepted matches.

Two good ones to start with seem to be "Exact Function Mnemonics Match" and (if you've already named symbols with e.g. with the stubs script) "Exact Symbol Name Match". After you've selected correlators, there's a wizard interface that lets you set options

"Exact Function Mnemonics Match" has an option "Function minimum size". The text is truncated in the UI on my system, but I think it's in bytes. This seems useful to reduce the number of duplicates for very simple functions.

There is also a "Limit source and destination address sets" option, which could be used to exclude non code regions, or areas that are copied to RAM. You can even use the selection in the disassembly views.

On a410 vs a540, running the two correlators above on address ranges 0xffc00000 to the "start of data" string, with minimum function length 40 takes a few seconds and finds ~10k matches.

Note the the "function" matches appear to only apply to things that are defined as functions, not labels on disassembled code (since it can't know the start/end otherwise). It could be useful to make stub load script try to create functions, but this can cause incorrect results when there's a tail call b ... at the end, and a few things in stubs aren't functions. There might included scripts which could help.

The obvious CHDK use case for the is porting. It's quite similar to what the sig finders do, but applies to the entire firmware. So if you know where something is referenced in a known firmware, finding it in the new one should be very quick.

The version tracking tool (and single program disassembly / decompiler) pay attention to which memory regions are marked as executable. So loading the parts of the ROM known to contain code separately will likely give better / faster results, though for version comparison, you can do this with the address range instead. A script to automatically set up the memory map could be quite useful, but the API documentation doesn't make it easy to discover how to do things like this.
Don't forget what the H stands for.


Related Topics