Editing Binaries with Suggestions

Sidekick can automatically repair and annotate your binary around the current cursor position. Each suggestion-style operation examines the local code or data, determines what improvements to make, and applies them directly to the binary database.

There are four suggestion-style operations:

Operation	Menu Label	What it does
Suggest Repairs	Suggest Repairs	Repairs inaccurate local analysis around the current address so function boundaries, signatures, xrefs, and control flow are trustworthy
Suggest Types	Suggest Types	Recovers structure definitions, applies field types, and updates function signatures and variable types
Suggest Names	Suggest Names	Renames default-named functions, variables, and data variables with meaningful names
Suggest Comments	Suggest Comments	Adds comments that clarify non-obvious code patterns, magic numbers, and complex logic

Running a suggestion-style operation

All four operations are invoked the same way:

1. Place your cursor at the address you want to analyze. This can be inside a function (code context) or on a data address (data context).
2. Open Plugins > Sidekick from the main menu.
3. Select one of: Suggest Repairs, Suggest Types, Suggest Names, or Suggest Comments.

The operation runs as a background task. While it runs, you can continue working in Binary Ninja. The status bar at the bottom of the window shows progress.

Note

Suggestion-style operations apply changes directly to the binary database. You can undo any changes using Binary Ninja's undo feature (Ctrl+Z / Cmd+Z).

Suggest Repairs

Suggest Repairs is the operation to run when the decompilation output itself looks wrong. It focuses on the accuracy of Binary Ninja's local analysis around the current address — use it when function boundaries look misplaced, a function should exist but does not, imported or local signatures are clearly incorrect, cross-references are missing, or indirect control flow has not resolved correctly.

What it repairs

Depending on the local symptom set, Suggest Repairs may:

• Create or remove user functions when the current code is partitioned incorrectly
• Correct local or imported signatures, calling conventions, and stack cleanup
• Recover indirect branch targets, jump-table targets, and missing code or data references
• Repair symbols, data variables, stack variables, and other local type information
• Apply bounded analysis steering when Binary Ninja's conservative local analysis needs help

How it works

1. Context: Reads the current function or data region around the target address
2. Symptom detection: Identifies concrete local reasons the current analysis appears inaccurate
3. Remediation: Applies bounded repairs centered on the current location
4. Verification: Re-reads the local region and confirms that the substrate improved enough for downstream work

Tip

Run Suggest Repairs first when the decompilation itself looks wrong. Type, naming, and comment suggestions are much more reliable once the local substrate is stable.

Suggest Types

Suggest Types recovers structure definitions and applies type information around the current address. This operation is useful when you see pointer arithmetic with fixed offsets (e.g., *(arg1 + 0x10)) or void* casts that indicate underlying structure types.

Before Suggest Types applies any type recovery, it checks whether the current analysis substrate is trustworthy. If local analysis is clearly broken, it runs the same bounded remediation workflow as Suggest Repairs first and only proceeds after re-reading the repaired region.

What it analyzes

When invoked on a code address, Suggest Types examines the decompiled code to identify:

• Pointer arithmetic at fixed offsets -- these indicate structure field accesses
• Void pointer casts and raw integer-to-pointer conversions -- these indicate typed pointers
• Allocation sites (malloc, calloc, realloc return values) -- these indicate structure allocations
• Library function parameter types -- these constrain buffer sizes and field types

When invoked on a data address, Suggest Types examines the data listing to identify:

• Pointer chains (consecutive pointer-sized values) -- these indicate vtables or function pointer tables
• Repeated structures (regular byte patterns at fixed intervals) -- these indicate arrays of structures
• Scalar arrays (consecutive uniform-size values) -- these indicate offset tables or index arrays

What it changes

Suggest Types may apply the following modifications to the binary database:

• Define new structure types with named fields
• Define enumeration types when fields take on small sets of integer values
• Update function signatures with recovered parameter and return types
• Set variable types to recovered structure pointers
• Type data variables as arrays, structures, or function pointer tables

How it works

The operation follows a multi-phase workflow:

1. Context: Queries the function or data region around the target address
2. Analysis: Identifies type-recovery patterns and groups related accesses by base pointer into candidate structures
3. Expansion: Examines callees, callers, or data variables that share candidate structures to complete the type definitions
4. Definition: Defines structure types, enumerations, and unions with correctly sized fields
5. Application: Groups all modifications into a single atomic batch and applies them
6. Verification: Retrieves the updated decompiled code to confirm types were applied correctly

Tip

Run Suggest Types before running Suggest Names. Recovered structure types provide important context that helps Suggest Names produce higher-quality names.

Suggest Names

Suggest Names gives meaningful names to default-named functions, variables, and data variables around the current address. This operation is useful when you see identifiers like sub_401000, var_8, or data_404000 that obscure the purpose of the code.

Before Suggest Names applies any renames, it checks whether the local analysis substrate is trustworthy. If local analysis is clearly broken, it runs the same bounded remediation workflow as Suggest Repairs first and only proceeds after re-reading the repaired region.

What it targets

Suggest Names only renames items that currently have default names:

• Functions with names like sub_XXXX
• Local variables with names like var_XX or var_XX_1
• Data variables (globals) with names like data_XXXX

Items that already have meaningful, user-assigned names are left unchanged.

Naming conventions

Suggest Names follows these conventions:

Item type	Convention	Examples
Functions	snake_case verb phrases	parse_header, init_connection, validate_input
Local variables	snake_case noun phrases	buffer_size, config_ptr, loop_counter
Data variables	g_ prefix with snake_case	g_config, g_connection_count, g_vtable

What it analyzes

When invoked on a code address, Suggest Names examines the decompiled code and derives names from:

• The operations a function performs and the library functions it calls
• How variables are used -- assignments, function call arguments, comparisons, return values
• Strings referenced in the code
• The calling context (who calls this function and why)

When invoked on a data address, Suggest Names examines data variable types, values, pointer targets, and cross-references to determine appropriate names.

How it works

The operation follows a multi-phase workflow:

1. Context: Queries the function or data region around the target address
2. Identification: Finds all items with default names
3. Expansion: When a default-named callee's purpose cannot be determined from context alone, examines its code to understand what it does
4. Application: Groups all renames into a single atomic batch, applying only high-confidence names

Tip

Run Suggest Names on a function after its callees have already been named. Sidekick produces better names for variables and the function itself when the surrounding context uses meaningful identifiers.

Suggest Comments

Suggest Comments adds targeted comments that clarify non-obvious code patterns around the current address. Unlike the other suggestion types, this operation is intentionally selective -- it comments only the parts of the code that would confuse a reader without additional context.

Before Suggest Comments adds any comments, it checks whether the local analysis substrate is trustworthy. If local analysis is clearly broken, it runs the same bounded remediation workflow as Suggest Repairs first and only proceeds after re-reading the repaired region.

What it comments

When invoked on a code address, Suggest Comments looks for:

• Magic numbers and bitmasks -- constant values whose meaning is not self-evident (e.g., flags & 0x80, status == 3)
• Non-obvious control flow -- error-handling patterns, fallthrough logic, early returns with specific conditions
• Opaque library calls -- calls where the purpose is not clear from the function name and arguments alone
• Complex pointer arithmetic or casts -- operations that would confuse a reader without context
• Security-relevant code -- bounds checks, authentication gates, cryptographic operations, permission checks
• Algorithm implementations -- loops or sequences that implement a recognizable algorithm (hashing, sorting, encoding)
• Function-level summaries -- when the function's purpose is not obvious from its name

When invoked on a data address, Suggest Comments adds comments that describe:

• The purpose of data variables based on their type, value, and cross-references
• The structure of data regions (e.g., "vtable for class X", "dispatch table for handler lookup")
• The meaning of specific constant values stored in data

Comment quality

Suggest Comments follows these principles:

• Explain "why", not "what" -- comments do not restate the code in English
• Be concise -- one line when possible, two at most
• Be selective -- obvious code is left uncommented; over-commenting is avoided
• Stay local -- when examining a callee to understand a call site, the comment goes on the call site in the original function, not on the callee itself

How it works

The operation follows a multi-phase workflow:

1. Context: Queries the function or data region around the target address
2. Pattern identification: Reads through the code and identifies non-obvious patterns that warrant comments
3. Expansion (rare): Only when a default-named callee is central to understanding the current function and its behavior cannot be inferred from context
4. Application: Groups all comments into a single atomic batch

Reviewing applied changes

All modifications made by suggestion-style operations are recorded in the Sidekick Transaction Log sidebar. Each operation creates one or more transactions that you can review after the operation completes.

To view the Transaction Log:

1. Open the Sidekick Transaction Log sidebar from the right sidebar panel in Binary Ninja.
2. Select a transaction to view its details, including the target URIs and property values that were modified.
3. Double-click a modification row to navigate to the affected address in the binary.

Undoing suggestions

If an operation produces results you do not want, use Binary Ninja's undo feature (Ctrl+Z / Cmd+Z) to revert the changes. Each operation's modifications are grouped as a single undo action, so one undo step reverts all changes from that operation.

Tips for effective use

1. Start with substrate repair if the decompilation is wrong. Run Suggest Repairs first when boundaries, signatures, xrefs, or indirect control flow look incorrect.

2. Then types, then names, then comments. Structure recovery and type information provide context that improves naming quality, and meaningful names improve comment quality.

3. Run suggestions on well-connected functions. Functions that call many other functions or are called from many places provide more context for Sidekick to work with.

4. Use Suggest Names after naming callees. Sidekick produces better names for a function's variables when the functions it calls already have meaningful names.

5. Combine with Chat. If an operation does not produce the result you want, use the Chat sidebar to ask Sidekick for a more targeted analysis or to explain what a specific function does.

6. Review the Transaction Log. After running an operation, check the Transaction Log to see exactly what was changed and navigate to the affected locations.