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

Ghidra reverse engineering tool

  • 12 Replies

Online philmoz

  • *****
  • 3136
    • 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

  • ******
  • 12208
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.


Offline reyalp

  • ******
  • 12208
Re: Ghidra reverse engineering tool
« Reply #12 on: 03 / November / 2019, 18:34:10 »
Ghidra 9.1 has been released

I haven't upgraded yet.

A few other general notes (based on 9.04):
Setting up the memory map well improves and speeds up analysis. In particular
* initialized data (copied to 0x1900 or 0x8000)
* split the ROM into code and data, with only the code parts set to executable. Generally code is the main ROM start to _ctypes, plus romstarter if you want it. This avoids analyzing copied code at the incorrect source location, as well as time spent analyzing data
* I'd really like a way to automatic this, but it's not obvious how to script memory map manipulation. Maybe it should be an "Importer"

After initial analysis, running "Auto analysis" with just "scalar operand references" selected can be helpful.

If you define function prototypes in the data type manager, you can apply them by dragging/dropping on to functions in the disassembly view. I haven't found a good way to share prototypes and type definitions between programs (theoretically, "Parse C source" should allow you to import)
Don't forget what the H stands for.


Related Topics