lc command reference manual
Introduction
The lc executable provides a command-line interface to interact with a Lumina server and its contents.
NOTE: virtually all the commands described in this document, require administrator rights; "regular" users will typically not have the necessary privileges.
Command-line options
-h, --host HOSTNAME[:PORT] Lumina host name and port (if port is omitted, it defaults to 443)
-u USERNAME specify username
-p PASSWORD specify password
-v, --verbose verbose output
In order to connect to a Lumina server, lc must at least be provided with a hostname and a valid user-password pair.
In order to keep the various commands' syntax as clear as possible, we will omit the login options from commands for the rest of this manual.
Other options exists, specific to each lc command (see Commands).
Commands
The following commands are accepted by lc:
Operating with metadata
Commands in this section let users view metadata stored in the Lumina server and their history.
hist show
hist showhist show [OPTION]
Queries history of changes for function(s).
The following informations will be displayed for each change:
The ID of the change
The timestamp of the change
The ID of the push that contains the change
The name of the function at that change (+
(*)if it has been modified past this change)optional: The username of the user that pushed this change
optional: The name of the license associated with the push for this change
optional: The email of the license associated with the push for this change
optional: The ID of the license associated with the push for this change
optional: The ID of the function
optional: The effective address (EA) of the function in the input file for the change
optional: The hash of the function
optional: The path of the idb file where the change came from
optional: The hash of the file where the change came from
optional: The path of the file where the change came from
TIP: Wildcards can be used to facilitate the usage of options that take strings as input. See the appendix.
Options:
-a
--additional-fields LIST
Comma-delimited list of additional info to display (username, license_name, license_email, license_id, func_id, func_ea, calcrel_hash, idb_path, input_hash, input_path, all)
-d
--details
Show details (diff-like) for each change
None
--chronological
Display entries in chronological order (defaults to reverse-chronological).
-m
--max-entries NUMBER
maximum number of entries to fetch (defaults to 100)
-l
--license-id LICENSE
license ID (XX-XXXX-XXXX-XX format) to operate on
-r
--history-id-range RANGE
history ID range(s) to operate on (start0..end0 [...])
-i
--idb IDB
IDB name(s) to operate on
-f
--input FILE
input file(s) to operate on
-u
--username USERNAME
username(s) to operate on
-n
--func NAME
function name(s) to operate on
-h
--input-hash HASH
input file hash(es) to operate on
-p
--pushes-id-range RANGE
Pushes ID range(s) to operate on (start0..end0 [...])
-c
--calcrel-hash HASH
function hash(es) to operate on
Examples:
hist pushes
hist pusheshist pushes [OPTION]
Shows pushes to the Lumina server.
Options:
-a
--additional-fields LIST
Comma-delimited list of additional info to display (license_name, license_email, license_id, all)
-t
--time-range TIMESTAMP
timestamp
-u
--username USERNAME
username(s) to operate on
-l
--license-id LICENSE
license ID (XX-XXXX-XXXX-XX format) to operate on
-m
--max-entries NUMBER
maximum number of entries to operate on (defaults to 100)
None
--chronological
Display entries in chronological order (defaults to reverse-chronological).
Examples:
hist del
hist delhist del [OPTION]
Deletes history and metadata for functions.
Options:
-s
--silent
Do not ask for confirmation before deleting history
-l
--license-id LICENSE
license ID (XX-XXXX-XXXX-XX format) to operate on
-r
--history-id-range RANGE
history ID range(s) to operate on (start0..end0 [...])
-i
--idb IDB
IDB name(s) to operate on
-f
--input FILE
input file(s) to operate on
-u
--username USERNAME
username(s) to operate on
-n
--func NAME
function name(s) to operate on
-h
--input-hash HASH
input file hash(es) to operate on
-p
--pushes-id-range RANGE
Pushes ID range(s) to operate on (start0..end0 [...])
-c
--calcrel-hash HASH
function hash(es) to operate on
Examples:
Various information
info
infoinfo
Shows lumina connection information.
Example:
users
usersusers
Shows users.
Example:
stats
statsstats [OPTION]
Shows the numbers of functions, pushes, history records, IDBs and input files stored in the Lumina server database.
Options:
-u
--username USERNAME
username(s) to operate on
Examples:
Administrative commands
These commands require that the user executing them has admin privileges.
Managing users
User management will depend whether the Lumina server is configured to work with its own set of users, or delegating user management to the Teams server.
In the latter case, you should use the hv command-line tool to administer the Teams server.
Locally managing users
The following commands allow the administrator to manipulate users known to the Lumina server (provided of course the Lumina server doesn't delegate users management to the Teams server)
user add
user add USERNAME EMAIL IS_ADMIN LICENSE_ID
Adds a user.
The passwd command must be used after creating a user; otherwise the new user will not be able to login to the Lumina server and use it.
USERNAME
The username of the user.
EMAIL
The email address of the user.
IS_ADMIN
Should be 1 if the user is admin, otherwise 0.
LICENSE_ID
The license of the user.
Example:
user edit
user edit USERNAME EMAIL IS_ADMIN LICENSE_ID
Edits a user definition.
USERNAME
The username of the user to modify.
EMAIL
The email address of the user.
IS_ADMIN
Should be 1 if the user is admin, otherwise 0.
LICENSE_ID
The license of the user.
Example:
user del
user del USERNAME EMAIL LICENSE_ID
Deletes a user.
USERNAME
The name of the user to delete.
EMAIL
The email address of the user.
LICENSE_ID
The license of the user.
Example:
passwd
passwd PASS USER
Modifies the password for a user.
PASS
The new password.
USER
The username whose password should be changed Only admins can change other users' passwords.
Example:
Managing sessions
session list
session list
Lists the current connections to the Lumina server. For each connection, the currently executed query (if any) is shown. For each connection, the currently executed query (if any) is shown.
Example:
session kill
session kill ID
Kills an existing connection to the Lumina server.
ID
The connection to kill, as shown by the <<cmd_session-list>> command
Example:
Concepts
What is the Lumina server
The Lumina server is a "functions metadata" repository.
It is a place where IDA users can push, and pull such metadata, to ease their reverse-engineering work: metadata can be extracted from existing projects, and re-applied effortlessly to new projects, thereby reducing (sometimes dramatically) the amount of time needed to analyze binaries.
Functions metadata
The Lumina server associates "function metadata" to functions, by means of a (md5) hash of those functions: whenever it wants to push information to, or pull information from the server, IDA will first have to compute hashes of the functions it wants to retrieve metadata for, and send those hashes to the Lumina server.
Similarly, when IDA pushes information to the Lumina server, it will first compute hashes for the corresponding functions, extract the metadata corresponding to those from the .idb file, and send those hash+metadata pairs to the server.
Metadata contents
Metadata about functions can include:
function name
function address
function size
function prototype
function [repeatable] comments
instruction-specific [repeatable] comments
anterior/posterior (i.e., "extra") comments
user-defined "stack points" in the function’s frame
the function frame description and stack variables
instructions operands representations
Pushing & overriding metadata
When a user pushes metadata about a function whose md5 hash isn’t present in the database, the Lumina server will simply create a new record for it.
However, when a user pushes metadata about a function whose md5 hash (and associated metadata) is already present in the database, the Lumina server will attempt to "score" the quality of the old metadata and the quality of the new metadata. If the score of the new metadata is higher, the new function metadata will override the previous one.
Metadata history
The Lumina server retains a history of the metadata associated to functions. Using the lc utility, it is possible to dig into that history, and view changes (detailed diffs, too.)
File contents
It’s worth pointing out that when pushing metadata to the Lumina server, IDA will not push the binary file itself. Only the following metadata about the file itself will be sent:
the name of the input file
the name of the IDB file
a
md5hash of the input file
The Lumina server cannot therefore be used as a backup/repository for binary files & IDBs (that is the role of the vault_server)
Commands
String patterns
Options that take strings as inputs can be enhanced through wildcards. The following wildcards are available:
%
represents zero, one or multiple characters.
_
represents one character.
To use wildcards in a string, it must be prefixed with like: e.g. -n like:%main%.
Timerange formats
For timeranges, the following syntaxes are supported:
<ts>..<ts>(from timestamp to (but not including) timestamp)<ts>(only one timestamp)
Where <ts> can be of the form:
yyyy-mm-dd HH:MM:SS: e.g.,2022-09-12 11:38:22yyyy-mm-dd: e.g.,2020-03-12+|-<count><unit>: this is a "now-relative" timestamp, where<unit>must be one ofw,d,H,M,Sfor weeks, days, hours, minutes or seconds respectively. E.g.,-4d,+5w,-8H,+1H, …​
when using the <ts> syntax (i.e., only 1 timestamp is provided, not an actual range), the final range will be either "from now to <ts>", or "from <ts> to now", depending on whether <ts> is before, or after, the present time.
Speed of retrieving changes
Although it may seem like a simple operation, lc hist show is
actually a very demanding one: by default it will have to fetch
bits of information from multiple tables (e.g., in order to provide
information about which change was superseded by a later one.)
This can be significantly sped up through the use of --last-change:
this option lets the server issue a much simpler query, resulting in
significantly reduced processing time.
Last updated
Was this helpful?