Collaborating with Ghidra Server

Why Use Ghidra Server

Ghidra Server is the stock collaboration system that ships with Ghidra. It gives a team a shared project repository where programs are versioned, checked out, checked in, updated, and merged over time. Each analyst still works in a local Ghidra project, but the authoritative versions live in the server repository.

That model fits reverse engineering work well. One person can name functions and recover types while another traces cross-references, cleans up strings, or annotates protocol handlers. The server records versions and comments, so the team can see how the analysis changed instead of passing around exported projects or overwriting each other's work.

The Stock Workflow

A shared Ghidra project uses the same version control actions as a private project, with one important difference: the repository is remote and can be used by multiple people at the same time.

1. Add to Version Control when a binary or imported program is ready to share.
2. Check Out before making analysis changes.
3. Save locally while working.
4. Update to bring in newer server-side versions from teammates.
5. Check In with a short comment that describes the analysis change.
6. Use Version History when you need to inspect earlier analysis states.

Ghidra also supports exclusive checkouts for changes that should not be concurrent, such as memory map edits or language changes. For ordinary annotation, renaming, comments, data types, and function cleanup, analysts can usually work concurrently and let Ghidra merge on check in.

Prepare the Server Host

Start from an unmodified Ghidra install on the machine that will host the repository. The server files live under the installation's server/ directory. Before starting it, edit server/server.conf and set the server command-line parameters for your environment.

The most important setting is the repositories directory. Keep it outside the Ghidra installation directory and use an absolute path so upgrades are easier and repository data does not live inside a disposable application folder.

# Edit <GhidraInstallDir>/server/server.conf
# Configure the wrapper.app.parameter.# lines for:
# - repository storage location
# - authentication mode
# - network hostname or interface, when needed
# - base port, when not using the default
#
# Prefer an absolute repository path outside the install tree.
# Example repository root:
# /srv/ghidra/repositories

By default, Ghidra Server uses base port 13100 and consumes three TCP ports starting at that base port. If clients connect across subnets, VPNs, or NAT, check the -ip and -i options in the stock server README so clients receive the address they can actually reach.

Start Ghidra Server

For a quick diagnostic run on Linux or macOS, start the server in a terminal from the stock server/ directory:

cd <GhidraInstallDir>/server
./ghidraSvr console

On Windows, use the corresponding batch file:

cd <GhidraInstallDir>\server
ghidraSvr.bat console

Console mode is useful while validating configuration because logs are visible immediately. For a long-running team server, install it as a service with the stock svrInstall or svrInstall.bat script, then control it with ghidraSvr start, ghidraSvr stop, ghidraSvr restart, and ghidraSvr status.

Add Users and Grant Access

Server administration is handled by the stock svrAdmin script. Every user must be known to the server before they can connect. With local Ghidra password authentication, a newly added user receives the initial password changeme unless the administrator supplies one interactively.

cd <GhidraInstallDir>/server

# Add users
./svrAdmin -add alice
./svrAdmin -add bob --p

# Grant repository permissions
./svrAdmin -grant alice +a firmware-audit
./svrAdmin -grant bob +w firmware-audit

# Inspect users and repositories
./svrAdmin -list --users

Repository grants use read-only, write, and admin permissions. A practical convention is to make one or two project leads repository admins, give active analysts write access, and reserve read-only access for reviewers who only need to inspect analysis state.

Share the Project with Your Team

In the Ghidra GUI, create or open a shared project that points at the server and repository. Teammates connect from their own Ghidra clients using the server host, port, repository name, and their assigned credentials. Once connected, the shared project shows server-backed files in the Project Window.

The shareable details are simple:

• Server hostname or IP address
• Base port, commonly 13100 unless changed
• Repository name
• Authentication mode and user ID
• Project conventions for check-in comments and exclusive locks

For command-line and headless workflows, stock Ghidra tools also understand repository URLs in the form ghidra://<server>[:<port>]/<repository-name>/<folder-path>. The repository must already exist on the server.

Run this from each machine's Ghidra installation directory, with the server configured, the team repository created, and analyst granted write access. Replace the example hostname and binary path with your own.

# Ghidra server
./server/ghidraSvr start
./server/ghidraSvr status

# Ghidra client
./support/analyzeHeadless ghidra://ghidra.example.com:13100/team \
  -connect analyst -import ./firmware.bin \
  -commit "Import and analyze firmware"

Team Habits That Keep Repositories Useful

The server gives you the mechanism; the team still needs a workflow. The best results come from small, understandable check-ins. Treat check-in comments like commit messages: explain the analysis change, not the amount of time spent.

• Check in after a coherent unit of analysis: renamed command handlers, recovered packet structures, imported symbols, or cleaned function boundaries.
• Update before starting a new block of work, especially when several people are touching the same binary.
• Use exclusive checkouts for structural edits that should not be merged casually.
• Do not leave files checked out indefinitely; undo stale work or ask an admin to terminate obsolete checkouts when needed.
• Keep private scratch imports separate from the shared repository until they are ready for the team.

Operations Checklist

A small amount of operational discipline prevents most collaboration problems.

• Back up the repositories directory, not just the Ghidra installation.
• Run only one server instance against a repository directory.
• Keep repository storage on a local filesystem with reliable filesystem event support.
• Use a stable Java path for service installs, especially on Linux systems with Java package updates.
• When upgrading Ghidra, copy only the relevant app parameters into the new server.conf; do not blindly copy the entire old file.
• Check wrapper.log and the repository server.log when startup or admin commands behave unexpectedly.

Closing Thoughts

Ghidra Server is intentionally plain: repositories, users, permissions, checkouts, check-ins, updates, and history. That is enough to turn reverse engineering from a pile of local projects into a shared body of analysis. Start with the stock server, agree on small check-ins and clear comments, and let the repository become the team's running memory of the target.