Ghidra Gang

Ghidra allows you to save your tool in its current configuration so you can keep everything the same each time you use it. This is what my setup looks like currently:

Aside from the default views, I always keep 2 additional windows visible on my screen: function call trees and bookmarks. Function call trees are great because they give you the fastest overview for the contents within the function you're currently viewing. While you might not see much benefit to this in a smaller program, being able to filter through functions reachable from the function you're currently in is a great feature for finding ways of reaching vulnerable code. I'll typically use this to show all paths reaching a function of interest and then iterate through each path to understand their behaviour. Bookmarks are always good to have right up front for encouraging you to add annotations to your code (which you should do often!). As I'm going through an interesting code path I'll typically drop bookmarks at key points so I can always come back quickly.

There's also some other useful views you might want to have up:

Also, in case you didn't notice, I'm using a custom dark mode patch for Ghidra to get a dark color theme. I help maintain an Arch User Repository package for installing Ghidra with this theme (which you can easily copy if you're not on Arch) and my entire color layout can be installed by adding this file to your Ghidra config via Ghidra main window->tools->import tool... (or this one for the debugger).

Keybindings are an important part of productivity within Ghidra. Most of the defaults are pretty good and I'm looking to give more advice and tips than a tutorial, so I'll skip the defaults and instead mention the keybindings I have that I find useful. One of my favorite custom bindings is to map "Next Function in History" to ">" and "Previous Function in History" to "<". It makes navigating back and forth through decompiled code more convenient than the default binding. I mostly use defaults outside of that, along with "Alt+P" to access my command palette plugin where I can reach most functionality in Ghidra from.

Using correct types is the biggest hint you can give to a decompiler when it comes to improving the decompiler output, and Ghidra's type creation is one of the nicest basic features it has. This is even more true if you came from IDA and had to deal with its extremely rigid structure editor. While Ghidra's UI will sometimes give you an option to auto-create a structure for a variable, it can only create a structure as accurate as the information it infers. It also can't figure out when multiple variables are actually part of the same structure, as most binaries won't have any information indicating this. Luckily there's a simple and easy-to-use structure editor for creating new types and then setting them on variables yourself. You can access the structure editor when Ghidra isn't giving the option by going to Data Type Manager -> <current project> -> right-click -> New -> Structure.... I recommend keeping the window open so you can quickly jump back and make changes to structures when you need to. Word of advice: always start creating types early and start from the inner functions that are used the most. If you start from the top and try to reverse out the entire state container without knowing the sizing of the structures it contains, you'll probably find yourself having to change parent structures you already configured in order to fix errors.

One of the key features I think is missing from Ghidra's scripting system is the lack of attention put on experimentation. There's more of an emphasis on writing scripts so that they can be used for extending Ghidra, when in reality you'll probably just want to run some quick queries or one-time changes that are difficult to do from the UI. The best way I've found to write scripts is to use a Jupyter notebook attached to Ghidra, as that lets me test and get my results quickly. There are two good extensions for adding a Jupyter kernel to Ghidra (depending on whether you prefer Python or Kotlin):

• ghidra jupyter kotlin: full functionality but somewhat unstable and you gotta learn Kotlin

• ghidra python bridge: you get python3 but you have to use slightly different syntax for long-running commands or face a performance penalty

I personally use the python bridge with Jupyter notebook or org-mode in Emacs like so:

Note that your most important resource when writing scripts is by far looking at the flat program API docs on Ghidra's official website. From there you can the most common functionality - pray that you don't need much more because you'll probably have to scour the Ghidra API documentation or (if you're really unlucky) nested Java hell to find what you want.

While experimenting or making one-off changes to a program in Ghidra are nice, there are also some good scripts that are worth adding to Ghidra and reusing. Here's a very small list of some scripts I've found were helpful in the past:

• rabbit_hole.py: A script that appends cyclic complexity of functions to their name so you can tell what functions are more complex at a glance (and more accurately than just checking their size).

• DefineUndefinedFunctions.java: takes all known undefined functions in Ghidra and defines them. This is actually FindUndefinedFunctionsScript.java from the core scripts that come with Ghidra but I modified it slightly to make it define the functions instead of just listing them.

• memcpy2stack.py: generates decompiled code for all functions within the current program and then searches for calls to memcpy with a stack buffer as an argument (though really this could be used for searching decompiled code for anything). You can achieve a similar but less automated functionality by exporting the program as C/C++ and then searching through those files yourself.

  from ghidra.app.decompiler import DecompInterface
  import re
  
  memcpy_symbol = getSymbols("memcpy", None)[0]
  memcpy_refs = getReferencesTo(memcpy_symbol.address)
  
  for ref in memcpy_refs:
    try:
        fn = getFunctionContaining(ref.fromAddress)
        decompInterface = DecompInterface()
        decompInterface.openProgram(currentProgram)
        res = decompInterface.decompileFunction(fn, 30, monitor)
        if res.decompileCompleted():
            decomp_fn = res.getDecompiledFunction()
            # check if decompiled code contains a stack buffer as input
            if re.search("memcpy\(.*?[sS]tack.*?,.*,", decomp_fn.getC()):
                print("memcpy with stack dst found near: {}"
                      .format(ref.fromAddress))
    except Exception as e:
        print("error:", e)

• HighlightBlock.py: highlights blocks of the list of addresses you provide (goes nicely with a trace from a different tool like Unicorn)

  def color_block(block):
    if service:
        color = service.getBackgroundColor(block.getFirstStartAddress())
        if color and color.getBlue() == 128:
            clearBackgroundColor(block)
        else:
            clearBackgroundColor(block)
            setBackgroundColor(block, Color.GRAY)
  
  
  def highlight_blocks(model, addrs):
  
    for addr in addrs:
        print addr
        b = model.getCodeBlockAt(addr, monitor)
        print "block: ", b
        if b:
            color_block(b)

I recommend taking a look through the scripts provided within Ghidra as well so you know what's already available to you. You can also find many more useful scripts on different online sources, like this aggregate repo of extensions for Ghidra.