# Examining Machine State: Memory, Registers, and Variables

This module assumes you know how to launch `termmines` in Ghidra using GDB, and know where to find the basic Debugger GUI components.
It also assumes you know the basic control commands, e.g., Resume, Step, and Interrupt; as well as some basics for breakpoints.
If not, please refer to the previous modules.

This module will address the following features in more depth:

* Dynamic Listing window
* Dynamic Bytes (Memory) window
* Registers window
* Watches window
* Sleigh expressions
* Variable value hovers

## 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.

### Patching

Many of the features allow you to edit the values, i.e., *patch* the live target.
The windows that are adaptations of their static counterparts work more or less as expected.
Edits in any *dynamic* window will attempt to patch the live target.
Edits in any *static* window will **not** patch the live target; they modify the program database as usual.
Some dynamic windows may present tables with editable cells.
These will often include a *write-lock* toggle, like the static Byte viewer, to avoid accidental patching.
Furthermore, you must use the ![control mode](images/record.png) Control Mode toggle in the global toolbar (next to the control actions) to enable patching throughout the Debugger tool.
For now, please only use the **Control Target** and **Control Target w/ Edits Disabled** options.
The write toggle is included here so that actions like copy-paste do not lead to accidental patching.

## 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.

![The dynamic listing after a call to rand](images/State_ListingAfterCallRand.png)

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 ![location tracking](images/register-marker.png) 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](images/register-marker.png) Track Location button, or you can double-click the "sp = ..." 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](images/resume.png) Resume.
Your Dynamic Listing should follow the stack pointer.
In the menus, select **Debugger &rarr; Analysis &rarr; Unwind from frame 0** or press **`U`**.

![The dynamic listing of the stack after a call to rand](images/State_ListingStackAfterCallRand.png)

**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](images/camera-photo.png) 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:

### Cache Status Indication

The listing's contents are read from a live target, which may become unresponsive or otherwise temperamental.
The Debugger uses a trace database, which acts as a cache separating the GUI from the live target.
The UI requests memory pages from the target, the target asynchronously retrieves those pa