Settings provides a way to define and access settings in a hierarchical fashion.

The value of a setting can be defined for each hierarchical level, where each level overrides the preceding level. The backing-store for setting values at each level is also configurable. This allows for ephemeral or platform-independent persistent settings storage for components within Binary Ninja or consumers of the Binary Ninja API.

Each Settings instance has an instanceId which identifies a schema. The schema defines the settings contents and the way in which settings are retrieved and manipulated. A new Settings instance defaults to using a value of default for the instanceId . The default settings schema defines all of the settings available for the active Binary Ninja components which include at a minimum, the settings defined by the Binary Ninja core. The default schema may additionally define settings for the UI and/or installed plugins. Extending existing schemas, or defining new ones is accomplished by calling RegisterGroup() and RegisterSetting() methods, or by deserializing an existing schema with DeserializeSchema() .

Note

All settings in the default settings schema are rendered with UI elements in the Settings View of Binary Ninja UI.

Allowing setting overrides is an important feature and Binary Ninja accomplishes this by allowing one to override a setting at various levels. The levels and their associated storage are shown in the following table. Default setting values are optional, and if specified, saved in the schema itself.

Settings are identified by a key, which is a string in the form of <group>.<name> or <group>.<subGroup>.<name> . Groups provide a simple way to categorize settings. Sub-groups are optional and multiple sub-groups are allowed. When defining a settings group, the RegisterGroup method allows for specifying a UI friendly title for use in the Binary Ninja UI. Defining a new setting requires a unique setting key and a JSON string of property, value pairs. The following table describes the available properties and values.

Note

In order to facilitate deterministic analysis results, settings from the default schema that impact analysis are serialized from Default, User, and Project scope into Resource scope during initial BinaryView analysis. This allows an analysis database to be opened at a later time with the same settings, regardless if Default, User, or Project settings have been modified.

Settings that do not impact analysis (e.g. many UI settings) should use the "ignore" property to exclude "SettingsProjectScope" and "SettingsResourceScope" from the applicable scopes for the setting.

Example analysis plugin setting:

Getting a settings value:

Sets the file that this Settings instance uses when initially loading, and modifying \ settings for the specified scope.

Note

At times it may be useful to make ephemeral changes to settings that are not saved to file. This can be accomplished \ by calling LoadSettingsFile without specifying a filename. This action also resets settings to their default value.

Parameters

Returns

True if the load is successful, False otherwise

Determine if the active settings schema is empty.

Parameters

scope

the settings scope to check, defaults to SettingsAutoScope

Returns

True if the active settings schema is empty, False otherwise

template<typename T>

Get the current settings value for a particular key, as a JSON representation of its value.

Parameters

key	Key for the setting
view	BinaryView, for factoring in resource-scoped settings
scope	Scope for the settings

Returns

JSON value for the setting, as a string

template<typename T>

template<>

template<>