Make it understandable.

The problem

Stripped and obfuscated binaries remove the landmarks you usually rely on. Names are gone. Vtables show up as pointer arithmetic. Sections and segments can point analysis away from the code that matters. Encoded payloads stay as bytes until someone recovers them. Simplification has to cover both the decompiler output and the binary underneath it.

How Sidekick simplifies

Sidekick handles both layers. In the decompiler, it recovers types, names, calling conventions, class relationships, vtables, and comments from context. In the binary, it inspects segment and section layout, repairs bad metadata, decodes or decrypts payloads, writes recovered bytes back into the BNDB, creates functions, and decompiles the recovered code.

The result is a BNDB you can keep working in: corrected layout, recovered bytes, named functions, useful structure, and notes showing what changed and why.

For a concrete malware reversing walkthrough, read Trouble, Revisited: AI-Assisted Malware Reversing.

Worked examples

Recover structure types and field names

Before

• Generic function signature and variable names
• No recovered structure definitions or field names
• Pointer arithmetic instead of typed field access

After

• Recovered structure and field names
• Typed function signature and local variables
• Structure member access rendered directly in the decompilation

Decompilation repair with recovered control flow and inline reasoning

Before

• No names for the function or variables
• Indirect jump through a computed address value
• Incomplete control flow recovery

After

• Recovered names
• Function comment
• Jump targets resolved and rendered as switch-case statements
• Complete decompilation

What you get

Decompilation that reads like annotated source, backed by a BNDB that reflects the recovered binary. Types, names, functions, layout repairs, decoded bytes, and comments stay in the database with the reasoning preserved.