Lumen is a private Lumina server for IDA Pro, written in Rust and released under the MIT licence, that lets a reverse-engineering team run its own function-signature and comment database instead of sending that data to Hex-Rays' public Lumina service.

What it is

Lumen is a self-hosted replacement for the server side of IDA Pro's Lumina feature. It lives in the IDA Pro ecosystem: the client is IDA Pro 7.2 or newer, and Lumen answers the Lumina protocol requests that IDA normally sends to Hex-Rays' hosted infrastructure. The project is written in Rust, is backed by PostgreSQL, and ships precompiled Docker images alongside instructions for building from source with a Rust toolchain. A public instance runs at lumen.abda.nl, and the protocol research behind the implementation is documented separately by the author. Configuration lives in a TOML file, and the binary is started with a single command.

The concrete problem it solves is data ownership and sharing within a team. IDA's built-in Lumina features let an analyst quickly identify functions that were reversed in the past, but the stock service is a shared public pool. A private Lumina server puts that signature store behind a fence the team controls, while still working through IDA's native Lumina interface. The README is explicit about what IDA may transmit to a Lumen server: the IDA key, hostname, IDB path, original file path, file MD5, function signature, stack frames, and comments. Lumen therefore replaces both the public Lumina endpoint and any ad-hoc practice of sharing recovered names and comments by hand.

Key capabilities

• Stores function signatures so an analyst and their team can identify functions found in the past using IDA's built-in Lumina features.
• Persists data in PostgreSQL, with schema managed through Diesel migrations run via diesel --config-file common/diesel.toml.
• Provides an experimental HTTP API for querying the database for comments by file hash or function hash.
• Supports mixed transport on separate listeners, where a [[lumina.listeners]] entry is plain TCP unless its tls table includes a certificate, allowing TLS on one port and plain TCP on another.
• Handles IDA's pinned-certificate requirement by generating a hexrays.crt for the IDA install directory, since adding a self-signed certificate to the system root store does not work.
• Accepts custom TLS material through a PKCS#12 file (.p12/.pfx) with its password supplied as PKCSPASSWD in .env.
• Runs from a config.toml supplied at startup with ./lumen -c config.toml.

Who uses it and how

• Reverse-engineering teams that want signature and comment sharing scoped to their own group rather than the public Lumina pool.
• Malware analysts and incident responders working in environments where IDB paths, hostnames, and file MD5s must not leave the organisation's own infrastructure.
• Teams running a mixed IDA client base, configuring TLS-capable clients against port 1234 and plain clients against port 1235 with LUMINA_TLS = NO.
• Organisations that prefer a containerised deployment, using the provided docker-compose.yml with a ./dockershare directory for custom configuration and certificates.
• Analysts on IDA Pro 8.1 or newer, who must remove existing LUMINA settings from ida.cfg or idauser.cfg before pointing IDA at a private server.

Getting started

The recommended path is Docker: install docker-engine and docker-compose, optionally drop a custom config at ./dockershare/config.toml and a PKCS#12 key at ./dockershare, then run docker-compose up. Building from source instead requires a Rust toolchain, a PostgreSQL instance, and diesel migrations before cargo build --release.

How it compares

The facts provided name no comparable tools, and no list of paid products that Lumen replaces is included, so no like-for-like contrast can be drawn from the available material. On the evidence given, it stands alone in this registry.

When to use it — and when not to

A self-hoster must operate PostgreSQL, run Diesel migrations, and manage TLS material, including the pinned-certificate override that requires placing hexrays.crt in every IDA installation directory. Anyone unwilling to run a database and a certificate workflow, or who needs a managed service with support, should not choose it. The README excerpt is also truncated mid-configuration, so parts of the TLS and setup guidance are not fully verifiable from the material available here.

./lumen -c config.toml

#!/bin/sh
export LUMINA_TLS=false
$1

set LUMINA_TLS=false
%1

LUMINA_HOST = "192.168.1.1";
LUMINA_PORT = 1234

// Only if TLS isn't used:
LUMINA_TLS = NO

[lumina]
server_name = "lumen"

[[lumina.listeners]]
bind_addr = "0.0.0.0:1234" # TLS
[lumina.listeners.tls]
server_cert = "lumen.p12"

[[lumina.listeners]]
bind_addr = "0.0.0.0:1235" # plain TCP

# create a certificate
openssl req -x509 -newkey rsa:4096 -keyout lumen_key.pem -out lumen_crt.pem -days 365 -nodes

# convert to pkcs12 for lumen; used for `lumen.tls` in config
openssl pkcs12 -export -out lumen.p12 -inkey lumen_key.pem -in lumen_crt.pem

# export public-key for IDA; Copy hexrays.crt to IDA installation folder
openssl x509 -in lumen_crt.pem -out hexrays.crt