Machine State

There are at least two ways to define machine state. One way based on a high-level understanding of a program is the collective values of all variables. Another based on a low-level understanding of a program is the collective values of all memory and all registers of all threads. Because Ghidra is primarily concerned with examining software at the low level, albeit to obtain a high-level understanding, we will generally stick with the low-level definition. One could argue that machine state also includes the underlying system and hardware, including peripherals. When debugging user-space applications, Ghidra cannot generally inspect the underlying system, except for a few things granted by the back-end debugger, e.g., the virtual memory map. Thus, as far as we are concerned, the machine state does not include the underlying system, but it is still something you must be aware of while debugging.

Note that we also treat registers as something separate from memory. While technically, one could argue registers are the closest and smallest memory to the CPU, we think of memory as an addressable array, e.g., DIMMs and flash ROMs. If applicable, memory-mapped registers are considered part of memory by Ghidra.

The Ghidra Debugger provides mechanisms for viewing and modifying machine state at both the low and high levels. The Dynamic Listing and Memory viewer provide access to memory, the Registers window provides access to registers, and the Watches window provides access to memory and registers via expressions. The only means of accessing high-level variables is through value hovers, which are available in all listings and the Decompiler.

The Dynamic Listing

Up to this point, we have only used the Dynamic Listing to display the instructions at the program counter. It can actually view and mark up any part of the machine state in memory, e.g., mapped images, heap pages, stack pages. Where the memory is mapped to images, Ghidra attempts to synchronize the Static Listing and, by extension, the other static analysis windows. The Dynamic Listing has most of the same features as the Static Listing.

Re-launch termmines and then navigate to rand. You may notice that the Static Listing has disassembly, but the Dynamic Listing does not. This is because Ghidra has not observed the program counter at rand yet, so it has not automatically disassembled it. To manually disassemble in the Dynamic Listing, place your cursor where you expect an instruction and press D, just like you would in the Static Listing.

This action differs in that it does not follow flow. It proceeds linearly, stopping at any control transfer instruction.

Now, we will examine the stack segment. Click the Track Location drop-down and select Track Stack Pointer. The window should seek to (and highlight in pale green) the address in the stack pointer. Since the target has just entered main, we should expect a return address at the top of the stack. With your cursor at the stack pointer, press P to place a pointer there, just like you would in the Static Listing. You can now navigate to that address by double-clicking it. To return to the stack pointer, you can use the back arrow in the global toolbar, you can click the Track Location button, or you can double-click the sp = [Address] label in the top right of the Dynamic Listing.

To examine a more complicated stack segment, we will break at rand. Ensure your breakpoint at rand is enabled and press Resume. Your Dynamic Listing should follow the stack pointer. In the menus, select Debugger → Analysis → Unwind from frame 0 or press U.

NOTE: We will cover the Stack window later in the course, which is probably a more suitable way to navigate stack frames. It is populated by the back-end debugger, which can usually unwind the stack more reliably than Ghidra. The Unwind Stack action is useful when you want an in-depth understanding of the actual contents of the stack, or when you are emulating.

Now, switch back to Track Program Counter. If you would like to track both the Program Counter and the Stack Pointer, click the Clone button in the local toolbar. Like the Static Listing, this clones an instance of the Dynamic Listing, which you can configure differently than the primary Dynamic Listing. Only the primary Dynamic Listing will synchronize, and it does so only with the primary Static Listing. NOTE: For the sake of disambiguation, we will use the term clone, not snapshot when referring to multiple instances of a Ghidra window. While this is inconsistent with the Ghidra Beginner course materials, it is necessary to avoid confusion with snapshots of the machine state, discussed later in this module.

The dynamic listing offers several additional features:

The Memory Viewer

Just as the Dynamic Listing is the analog of the Static Listing, the Memory viewer is the analog of the Bytes viewer. To open it, use Windows → Byte Viewer → Memory … in the menus. Its default configuration should be Auto PC, the same as the Dynamic Listing’s default. It has all the same additional Debugger features as the Dynamic Listing. Furthermore, bytes that have changed are displayed in red text.

Registers

The Registers window gives a view of all the registers on the target and their current values. The register set can be very large, so there are a few ways to sift and sort. As in most Ghidra tables, you can filter using the box below the registers table. Additionally, you can use the column headers to sort. The columns are:

• The Favorite column indicates which registers are your favorite. By default, this includes the instruction pointer and the stack pointer. You can quickly choose your favorite(s) by toggling the check boxes in this column. Because this column is sorted by default, your favorites are positioned at the top.
• The Number column gives the number assigned to the register by Ghidra’s processor specification. This is mostly just to make the default sorting deterministic.
• The Name column gives Ghidra’s name for the register. This usually matches the name given by the back-end debugger, but may not. For example, on x86-64, what Ghidra calls rflags GDB calls eflags.
• The Value column gives the register’s current value in hexadecimal. Values in gray are stale. Values in red have changed. Right-clicking this column will present options to Go To the address, as if the register were a pointer.
• The Type column allows you to assign a type to, i.e., create a data unit on, the register. This has more utility for float types than integers, but it may still help you record what you know about how a register is being used.
• The Representation column displays the register’s value according to its assigned type, if applicable. If the type is a pointer, then double-clicking this value will go to the address in the Dynamic Listing.

If you would like to adjust the list of registers in the table, use the Select Registers button in the local toolbar. This will present all the registers in Ghidra’s processor specification, including those which are just artifacts of Sleigh. Typically, this is not necessary, since the table will include all registers recognized by both Ghidra and the back-end debugger. Nevertheless, if you believe a register is missing, it is wise to check this selection.

Watches

The Watches window gives the values of several user-specified Sleigh expressions. This can provide an alternative to the Registers window when you are really only interested in a couple of registers. It can also watch values in memory. Furthermore, when a watch has a memory address, the expression will appear as an option in the Location Tracking menus of the Listing and Memory viewers. Selecting that option will cause the window to follow that watch as its address changes.

To add a watch, click the Add button. A new entry will appear. Double-click the left-most cell of the row to set or edit the Sleigh expression. For starters, try something like RDI. (Conventionally, this is the location for the first parameter on Linux x86-64 systems.) The context menus for the Listing and Registers windows include a Watch action, which adds the current selection to the Watches window.

The columns are:

• The Expression column is the user-defined Sleigh expression.
• The Address column is the address of the resulting value, if applicable. This may be in register space. Double-clicking this cell will go to the address in the Dynamic Listing.
• The Symbol column gives the symbol in a mapped program database closest to or containing the address, if applicable.
• The Value column gives the “raw” value of the expression. If the result is in memory, it displays a byte array; otherwise, it displays an integer.
• The Type and Representation columns work the same as in the Registers window, except they do not save the data unit to the database. This has more uses than the Registers window. For example, try *:30 RDI and set this to TerminatedCString. Whenever RDI is a string pointer, this will display the string up to 30 characters.
• The Error column reports any errors in compiling or evaluating the expression.

Sleigh Expressions

Watches and Go-To commands are expressed using Ghidra’s Sleigh language. More precisely, expressions are the sub-language of Sleigh for the right-hand side of assignment statements in semantic sections. If you already know this language, then there is little more to learn. Of note, you may use labels from mapped program databases in your expression. For example, to see how far a return address is into main, you could use *:8 RSP - main.

For the complete specification, see the Semantic Section in the Sleigh documentation.

Sleigh is a bit unconventional in that its operators are typed rather than its variables. All variables are fix-length bit vectors. Their sizes are specified in bytes, but they have no other type information.

Variable Hovers

You may have already used these if you completed the exercises in the Breakpoints module. If you hover over a variable in any listing or the Decompiler, the Debugger will attempt to evaluate it and display information about it. In some cases, evaluation may involve unwinding the stack. Unwinding proceeds until the Debugger finds an invocation of the function containing or defining the variable. If unwinding fails, the Debugger may disregard the stack. In dynamic windows, the Debugger generally disregards the stack. In static windows, the Debugger still uses dynamic information to unwind the stack and evaluate the variable. A variable may be any of the following:

• A register in the listing. In this case, the hover will report the register’s value in the function’s frame.
• A local or parameter in the listing. If the variable is allocated in a register, this behaves the same as hovering that register, except with additional information presented. If the variable is allocated in stack space, this only succeeds if unwinding succeeds.
• A global variable in the listing. Unwinding is unnecessary for these.
• A local or parameter in the Decompiler. This behaves similarly to hovering a variable in the Static Listing.
• A global in the Decompiler. This behaves similarly to hovering a global variable in the Static Listing.
• A field reference in the Decompiler. A field reference is essentially a C expression in terms of other variables. This will evaluate those variables and then evaluate the expression.

Depending on the particular variable and other circumstances, the hover will contain some combination of these rows:

• Name: The name of the variable
• Type: The type of the variable
• Location: The static location of the variable, e.g., Stack[0x4]
• Status: A progress indicator
• Frame: If evaluation required unwinding, a description of the frame used for context
• Storage: The dynamic, physical location of the variable, e.g., 7fffffffe618
• Bytes: The raw bytes currently stored in the memory allocated to the variable
• Integer: The “raw” integer value of the variable, rendered with varied signedness and radix
• Value: The value of the variable, according to its type
• Instruction: If the variable points to code, the target instruction
• Warnings: Warnings emitted during evaluation
• Error: If the value could not be evaluated, an explanation or the exception

The Name, Type, and Location entries are informational. They tell you about the variable and its static definition. The Status, Frame, and Storage entries are also informational, but tell you about the variable’s dynamic evaluation. The Bytes, Integer, Value, and Instruction entries tell you the dynamic value of the variable. Finally, the Warnings and Error entries provide diagnostics. If there are many warnings, then the value may not be accurate.