Building a robust malware analysis lab often relies on virtualization to manage snapshots, allowing investigators to start from a clean state or revert after critical steps. However, this convenience comes with a significant risk: reverting a virtual machine to a previous snapshot results in the total loss of all changes applied during that session. For analysts using Ghidra, where work is stored in local project files containing renamed functions, comments, and structures, this means hours of analysis can vanish instantly if the VM encounters issues or is reset.
To mitigate this data loss, experts recommend deploying a local Ghidra Server, a component included in the standard distribution that requires no additional license. This server transforms local projects into shared repositories backed by a central location outside the volatile virtual machine. The primary benefit is persistence; analysts can revert their VMs as frequently as needed while keeping annotated programs safe on the server. Additionally, the system provides versioning capabilities similar to Git, allowing users to track changes with comments, compare different states of an analysis, and restore previous versions.
The architecture supports multiple clients, enabling an analyst to start work on one machine and continue it on another, such as a laptop or a colleague's workstation. It also facilitates collaboration by allowing several analysts to work on the same samples with granular permissions, including read-only, read/write, or admin access. Crucially for incident response engagements, this setup ensures confidentiality by keeping all samples and customer-related binaries within the lab network, avoiding the need to push data to third-party services.
From a technical standpoint, the server is lightweight and can run on a small Linux VM or container separate from analysis machines. Recommended specifications include two CPU cores, 4GB of RAM, and 8GB of storage, running JDK 21 or newer. It is essential to align the Ghidra version between the server and clients to avoid incompatibility issues. Network configuration requires that TCP ports 13100 and 13101 be reachable from client machines, and clients must be able to resolve the hostname announced by the server.
Security considerations are paramount when deploying this service. Since the server hosts repositories containing raw bytes of malicious code, it must be treated as hosting live malware and kept strictly within the malware analysis lab network. It should never be exposed to the Internet. The setup involves creating a dedicated system account, unpacking the Ghidra distribution, and configuring the server.conf file to define the repository directory, authentication method, and announced hostname. Authentication modes include local passwords, PKI with client certificates, or JAAS integration with LDAP or Active Directory.
Once installed, users create repositories through the Ghidra client by selecting "Shared Project" and connecting to the server. While shared projects still generate local .gpr files and .rep directories for caching and connection settings, binaries remain private until explicitly added to version control. The workflow mirrors standard source control systems: analysts check out programs to work on them, check in changes with comments to create new versions, and manage access lists for other team members. If a VM is reverted and local data is lost, analysts can recover their work by connecting to the existing repository, though private files never added to version control and uncommitted changes will remain unrecoverable.
Sources: SANS Internet Storm Center.