{"id":23849,"date":"2026-09-09T18:11:38","date_gmt":"2026-09-09T18:11:38","guid":{"rendered":"https:\/\/scannn.com\/decbench-scoreboard\/"},"modified":"2026-09-09T18:11:38","modified_gmt":"2026-09-09T18:11:38","slug":"decbench-scoreboard","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/decbench-scoreboard\/","title":{"rendered":"DecBench Scoreboard"},"content":{"rendered":"\n
\n
\n

leaderboard<\/h2>\n

Decompilers have advanced significantly over
\nthe last 30 years<\/a>, quickly approaching the
\npoint where they can recover the exact source code from various binaries. This
\nbenchmark ranks decompilers by their ability to recover exact source code,
\nmeasured across three metrics. All metrics are shown as the percentage of
\nfunctions on which a decompiler achieves a perfect score. Decompilers are
\ninitially ranked by Union \u2014 their ability to score perfectly on
\nat least one<\/em> of those metrics. Click a column to sort.<\/p>\n

AI can also compete on these metrics, as seen on the
\nsample-set leaderboard<\/a>
\nwhere Codex and Claude Code take on the traditional decompilers. You can find
\nmore information about these metrics, datasets, and methodology on the
\nabout page<\/a>. You can also view some sample results
\non the view page<\/a>.<\/p>\n<\/section>\n

\n

data<\/h2>\n

Benchmark-run data beyond the leaderboard’s perfect rates:
\ndistance<\/a> from perfection per metric,
\nhow often decompiled output compiles<\/a> again,
\npipeline health<\/a> (what our own tooling loses), and the
\ncost<\/a> of producing each decompiler’s output.<\/p>\n

distance<\/h3>\n

When a decompiler can’t yet achieve a perfect score on a function, it can be
\nhelpful to understand the distance<\/em> it is from perfection. For each
\nmetric, we measure distance as the number of edits required to convert that
\nform of data into its source-code equivalent. For GED<\/strong>, that
\nis the number of edits to control-flow structures. For
\ntypes<\/strong>, that is the number of type-flips needed to reach
\nground truth. For recompilation<\/strong>, that is the number of
\nassembly lines that must change to convert the recompiled assembly into the
\nground-truth assembly.<\/p>\n

Each cell shows the mean<\/em>, the median<\/em>, and how many functions
\nare already at distance 0 (perfect), averaged over the functions each
\ndecompiler was scored on.<\/p>\n

Over the selected dataset
\n (mean \u00b7 median \u00b7 #at-0 \/ #measured).<\/p>\n

compiles<\/h3>\n

The share of each decompiler’s byte_match-measured functions whose output
\nactually recompiled<\/em> after the uniform compilability-fixup pass \u2014 a
\nfairness control, not a metric (type recovery is scored separately). The
\ndenominator is per-decompiler: functions where byte_match was measurable, so
\nARM \/ PE targets with no host recompiler never count against it. This rate moves
\nwith the selected dataset, like the columns on the leaderboard.<\/p>\n

pipeline health (our own tooling)<\/h3>\n

GED depends on Joern parsing both the source and the decompiler output.
\nWhen Joern fails on the source<\/strong>, that’s our tooling \u2014 those
\nfunctions are excluded from GED for every decompiler (never counted against
\nthem). When Joern fails on a single decompiler’s output<\/strong>,
\nthat’s reported here (per decompiler), not folded into the headline score.<\/p>\n

cost<\/h3>\n

What each decompiler’s output costs<\/em> to produce. The two halves of the table
\nare not directly comparable<\/strong>: traditional decompilers are timed from
\nwhole-binary batch decompilation (a binary’s wall time divided by its function
\ncount), while the LLM coding agents are timed per function \u2014 one agentic call
\neach, including all their tool use (objdump runs, reasoning, retries). The
\ndollar figures are estimates<\/strong>: recorded token usage from the sample-set run,
\npriced at public list prices at render time \u2014 not billed amounts. -<\/code> means
\nnot applicable or no data (traditional decompilers have no per-token cost;
\nan unpriced model shows n\/a rather than $0.00).<\/p>\n<\/section>\n

\n

view<\/h2>\n

Original source next to a decompiler’s output. Difficulty<\/strong> is
\nderived from structural (GED) agreement across decompilers:
\neasy<\/strong> \u2014 most decompilers recover the control flow
\nperfectly; hard<\/strong> \u2014 the functions farthest from perfect
\nfor everyone (the old hall of shame); medium<\/strong> \u2014 in
\nbetween. Pick a difficulty, a decompiler, and a metric to highlight.<\/p>\n

\n