Skip to main content

Architectural Overview

Ghidra is built as a layered framework with clear separation of concerns. Each layer builds upon the services provided by lower layers, creating a modular and extensible architecture.

Framework Layer

The framework layer provides core infrastructure services that all higher layers depend on.

Project Management Module

Location: Ghidra/Framework/Project/ The Project module manages the lifecycle of projects, tools, and domain files:
Key Components:
  • DefaultProject - Main project implementation
  • ProjectData - File system abstraction for domain files
  • ToolManager - Manages tool instances and configurations
  • DomainObjectAdapter - Base implementation for persistent objects

Database Module

Location: Ghidra/Framework/DB/ Provides a custom file-based database optimized for Ghidra’s needs:
Features:
  • Buffer Management - Efficient paging of database content
  • Versioning - Built-in version control with undo/redo
  • Transactions - ACID transaction support
  • Indexing - B-tree indexes for fast lookups
  • Schema Evolution - Handles database schema changes
From ghidra/framework/model/DomainObject.java:472-484

Docking Module

Location: Ghidra/Framework/Docking/ Provides the windowing system for Ghidra’s user interface:
  • ComponentProvider - Base class for dockable windows
  • DockingWindowManager - Manages window layout and persistence
  • ActionContext - Context for executing user actions
  • DockingAction - Represents menu items and toolbar buttons

Generic Module

Location: Ghidra/Framework/Generic/ Common utilities and infrastructure:
  • Application - Application lifecycle management
  • TaskMonitor - Progress monitoring and cancellation
  • ClassSearcher - Dynamic class discovery via ExtensionPoint
  • Options - Configuration and preferences system

Software Modeling Layer

The software modeling layer provides the program model and analysis infrastructure. Location: Ghidra/Framework/SoftwareModeling/

Program Model

The central abstraction for representing executable programs:
Managers and Services:
Manages memory blocks, address spaces, and byte access
From ghidra/program/model/mem/Memory.java:30-79
Manages symbols, namespaces, and labels
  • Labels and function names
  • Namespace hierarchy
  • Symbol references and scope
  • External symbols
Tracks functions and their properties
  • Function boundaries
  • Parameters and return values
  • Local variables
  • Call relationships
Tracks memory references and cross-references
  • Code and data references
  • Stack references
  • External references
  • Reference types and offsets

Address Model

Addresses in Ghidra are multi-dimensional:
Address Spaces: From ghidra/program/model/address/AddressSpace.java:28-46
Address spaces allow Ghidra to represent different contexts within a program:
  • RAM - Physical memory
  • REGISTER - Processor registers
  • STACK - Stack-relative addressing
  • OTHER - Non-loaded data (headers, debug info)
  • EXTERNAL - External library references
From ghidra/program/model/address/AddressSpace.java:68-89

Language System

Processor specifications define instruction semantics:
  • SLEIGH - Domain-specific language for instruction encoding
  • Processor Definitions - Located in Ghidra/Processors/
  • P-code - Intermediate representation for analysis
  • Compiler Specifications - Calling conventions and ABI details

Features Layer

The features layer provides user-facing functionality built on the framework.

Base Module

Location: Ghidra/Features/Base/ Core analysis features and the CodeBrowser tool: Analysis Services:
Built-in Analyzers:
  • Disassembly and instruction analysis
  • Function discovery and boundaries
  • Stack analysis and parameter detection
  • Reference discovery
  • Data type propagation
  • Symbol demangling
From ghidra/app/services/Analyzer.java:28-44

Decompiler Module

Location: Ghidra/Features/Decompiler/
  • C++ Native Engine - High-performance decompilation
  • Java Integration - Bridge between native and Java layers
  • High P-code - Simplified intermediate representation
  • Type Recovery - Infer data types from usage

File Formats Module

Location: Ghidra/Features/FileFormats/ Binary format parsers and loaders:
  • PE (Windows executables)
  • ELF (Linux/Unix executables)
  • Mach-O (macOS executables)
  • COFF archives
  • Android formats (DEX, VDEX, ART)

Component Interactions

Here’s how components work together during typical operations:

Opening a Program

1

Load Domain File

ProjectData retrieves the DomainFile from the file system
2

Open Database

DBHandle opens the underlying database file
3

Initialize Program

ProgramDB instantiates managers (Memory, Symbol, Function, etc.)
4

Register Listeners

Tools register for domain object events

Performing Analysis

1

Start Transaction

AutoAnalysisManager begins a transaction
2

Queue Analyzers

Analyzers are queued by priority
3

Execute Analysis

Each analyzer processes address ranges
4

Propagate Events

Changes trigger events to update UI
5

Commit Transaction

Transaction completes, changes are saved
From ghidra/app/plugin/core/analysis/AutoAnalysisManager.java:57-63

Extension Points

Ghidra provides multiple extension mechanisms:

Plugin Extension

Analyzer Extension

Loader Extension

Custom file format loaders implement the Loader interface.

Language Extension

New processor support via SLEIGH specifications.

Performance Considerations

Key performance characteristics to understand:
  • Database operations are cached but can still be slow for large programs
  • Address sets use efficient range representations
  • Event notification is buffered to reduce overhead
  • Analyzer priorities determine execution order for optimal performance

Module Dependencies

The dependency hierarchy ensures clean layering:

Next Steps

Projects

Learn about project organization and version control

Programs

Deep dive into the program model

Analysis

Understand the analysis pipeline

Overview

Return to framework overview