deREferencing, an IDA Pro plugin for register and stack views that resolve pointers

What the plugin adds to the debugger

deREferencing is an IDA Pro plugin that implements new registers and stack views, adding dereferenced pointers, colours and other useful information. The README compares the result to what GDB plugins such as PEDA, GEF and pwndbg provide, which tells you the intent clearly: this is the IDA equivalent of a feature those tools have made standard.

The problem it addresses is specific to reverse engineering in a graphical disassembler. IDA's built-in register and stack windows show you the raw value in each register and on the stack. In a stripped binary with no symbols, that value is very often a pointer, and reading it means looking up an address in the disassembly by hand, repeatedly, for every register. A view that resolves the pointer and shows what it points at, with colour to distinguish the cases, turns that into something you read at a glance.

The colour part is not decoration. When a register holds a code address, a stack address, a heap address or a small integer, those four cases mean very different things about the state of the program, and distinguishing them by eye takes longer than distinguishing them by colour.

Two views are provided, and both are opened from the Debugger menu under Debugger Windows, or by keyboard shortcut. The registers view is Alt-Shift-D and the stack view is Alt-Shift-E.

The stack view is the more interesting of the two for a lot of work, because the stack is where a function's arguments and locals live, and a frame pointer chase through it is otherwise manual.

The architecture support list is x86, x86-64, ARM, ARM64, MIPS32 and MIPS64, and the requirement is IDA Pro 7.1 or newer, so the plugin works across both the current IDA releases and the older 7.x line that a lot of people still analyse binaries with.

Installation and the two plugin directories

Installation with the Hex-Rays command line tool is a single command:

hcli plugin install dereferencing

The alternative is a manual install, which means dropping the dereferencing.py file and the dereferencing folder into IDA's plugin directory. Both files are needed, since the top-level module is the entry point and the folder holds the implementation.

The README gives the user-local plugin paths per operating system, which is the detail that matters for a manual install:

| OS | Plugin path | | --- | --- | | Linux and macOS | ~/.idapro/plugins | | Windows | %AppData%\Hex-Rays\IDA Pro\plugins |

The macOS and Linux path is the one in the home directory that IDA 7.1 and later look at, and the Windows path is under the roaming AppData for the Hex-Rays folder. Getting this wrong is the usual reason a manual install appears to do nothing, since the plugin loads silently and the menu entries simply do not appear.

For configuration, the README says the options can be modified via the dereferencing/config.py file. That is a Python file in the plugin directory rather than a setting inside IDA, which is a reasonable choice for a plugin that wants to be configured once and keep the configuration across projects.

Two usage conveniences are worth noting. The debugger windows can be opened from the Debugger menu under Debugger Windows as well as by shortcut, which matters when you have rebound keys. And you can save the desktop layout with the Windows, Save desktop option, so that the plugin's windows open automatically in other debugging sessions rather than needing to be opened each time you start the debugger.

Why the register and stack views are worth a plugin

It is worth being precise about what the plugin saves you, because a debugger already shows you registers and stack values and it would be reasonable to ask why that is not enough.

The answer is that the built-in windows show values, and the values in a stripped binary are almost always addresses. A register holding 0x00401230 is not information until you know what is at 0x00401230, and finding that out means switching to the disassembly window, scrolling to the address, and reading what is there. In a function with six arguments and a stack frame, that is a dozen round trips between two windows for one function's state.

The plugin collapses that into a single view. Each row shows the register, its raw value, and the dereferenced result, with colour to classify what the value points at. The classifications that matter in practice are a code address, a stack address, a heap address and a small integer. A small integer is worth its own colour because it usually means a flag, a length or a count rather than an address at all, and confusing it with a pointer sends you chasing the wrong thing.

The stack view carries the same idea one level deeper. A stack frame for a function with arguments and locals is a contiguous block of values, and the plugin resolves them together rather than one at a time. When you are reversing a function that takes a structure pointer, seeing the fields of that structure in the stack window rather than as a raw address is the difference between understanding the call and hunting for it.

There is a second reason this is plugin territory rather than a configuration option. Resolving a pointer safely depends on knowing which regions of the process are mapped, and IDA's debugger knows that because it is the one running the process. Any external tool would have to query the target separately, which is why the equivalent features on the GDB side are implemented as plugins that live inside the debugger rather than as scripts that talk to it.

The result is a workflow difference rather than a feature difference. A view that resolves pointers lets you read a debugger session the way you read source, and for a long reverse engineering session that is worth more than any single new command.

Where it fits against the GDB-side plugins

The README names its counterparts on the terminal side, and comparing them explains the design choices rather than just listing features.

PEDA, GEF and pwndbg are extensions to GDB that add a nicer register view, a stack view with dereferencing,.

An IDA plugin works inside IDA's own widget system, and that has both a cost and a benefit. The cost is that you are constrained by the widget model and the configuration surface, so a plugin that wanted to add a command that behaves like a GDB command has nowhere to put it. The benefit is that the view sits next to the disassembly and the graph, and it updates as the debugger moves, so the pointer resolution appears in the same application as the code it points at. For some analysts that single-application advantage outweighs the loss of scripting freedom entirely.

There is also the licensing consideration, which affects which tool a team can afford. GDB and the plugins on top of it are free software, while the plugin only runs inside IDA Pro. A team that has not bought IDA cannot use this plugin, and a team that has, often already has a debugger workflow built around it.

The third alternative, for completeness, is a different kind of tool: writing your own IDAPython script. IDAPython gives full access to the debugger state, so anything the plugin does can be done by hand. What you lose is the persistent view, since a script that prints to the output window still costs you a window switch. The plugin is essentially that script, packaged so it is always there.

Repository layout, release cadence and the wider debugger toolchain

The repository is small and follows the standard shape of an IDA plugin. There is a dereferencing.py module at the root, a dereferencing/ directory holding the implementation, an ida-plugin.json manifest describing the plugin to IDA and the package manager, a LICENSE and the README.

The manifest is the piece that makes the hcli install work, since that is how IDA's plugin manager knows the name and where to fetch it. A plugin without one can only be installed manually.

The release naming is a date, v2026.09.03 and before that v2025.10.31, which is a reasonable convention for a plugin that has no users pinning a version number and that is deployed to individual analysts rather than to a build pipeline. The last push was on 2026-09-03, matching the most recent release, and the project is not archived.

The licence is GPL-3.0, which for a plugin means that if you fork it and distribute the fork, the fork stays GPL. For an internal plugin in a security team that is not usually a constraint; for a commercial product that bundles IDA tooling it is.

The credits section names a colleague, roman_soft, who gave the author some ideas during development, which is a small indicator of how much of the design came from other people in the same field.

The comparison the README invites is with the GDB-side plugins, PEDA, GEF and pwndbg. The difference in approach is that those are debugger extensions in a terminal, where you can script them freely, while an IDA plugin works on IDA's own widget model and inherits IDA's interface. A reverse engineer who uses both will find the register presentation familiar, and the difference will be in the ergonomics of scripting rather than in the information shown.

The broader question of whether to reverse engineer in IDA at all is worth mentioning for a team starting out. The licence of IDA Pro is commercial and per-user, and the open source alternatives have improved considerably. A plugin like this is most valuable in a team that has already decided IDA is its tool, because the value is in the workflow rather than the code.

Editorial conclusion

Adopt deREferencing if you spend your days in IDA Pro's debugger and the plain register and stack windows leave you reading raw pointer values. Skip it if your workflow is in GDB with pwndbg or GEF, since the README positions this plugin as the IDA equivalent of those. Verify first by installing it with hcli plugin install dereferencing, opening the Registers view with Alt-Shift-D, and confirming the dereferenced column matches what you expect on a target you already understand.

Frequently asked questions

Official sources

1. danigargu/deREferencing on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases