Violet RE logo: two offset V glyphs on a dark tile Violet REStatic reverse engineering

seriesanalysispublished2 pieces

/analysis/

Reading defects out of compiled code, one binary at a time.

Each binary piece in this series takes a real, published, already-fixed vulnerability, states the exact builds examined, prints the commands, and stops where the evidence stops. Where Violet RE would not have found the defect, the piece says so and explains why. That is the more useful half of the writeup. Data pieces count the public vulnerability data itself, under the same rule: every count comes from a command printed beside it, and anything taken from elsewhere is cited.

Two pieces so far. This index lists what has been written and nothing else.

.index

Published.

  1. Finding a CVE's fix commit: one record in eight links a git commit

    27 September 2026 / 366,751 CVE records / public data, one script

    The quickest way to see what a fix changed is the commit that made it, and the obvious place to look for that commit is the CVE record. We counted how often the record names a commit at all. Of 366,751 published records in the official list, 45,067 link a specific git commit, 12.3 per cent. The Linux kernel links a commit in every one of its 15,002 records and supplies a third of the total. For everyone else it is 8.5 per cent.

    The piece breaks the count down by year, by numbering authority and by host, counts the near misses such as Subversion changesets and pull requests, looks at the exploited list, checks its own script against a seeded sample of 500 lines published with every verdict, and then counts the shapes it knows the rules get wrong, across the whole list.

    Read it

    inputs
    The CVE list bulk export of 27 September 2026 and CISA's KEV catalogue at a pinned commit, both checked by SHA-256.
    tools
    One Python script using the standard library, published beside the piece, plus curl, unzip and shasum. Every command is printed in full.
    and yet
    A commit link is not proof of a fix, and a record with no link may describe a bug that was fixed long ago. The piece counts links and says plainly what the count cannot tell you.

  2. CVE-2022-35737: reading the fix out of two binaries

    20 September 2026 / arm64 Mach-O / static analysis, nothing executed

    SQLite 3.39.1 and 3.39.2, compiled here from the released amalgamations, are the same length to the byte and carry the same symbol table, with one defined symbol between them. Two readable strings differ, and neither of them is the defect. The only way to tell the pair apart is to read the code.

    The piece locates sqlite3_str_vappendf in the stripped build by anchoring on a string only that function uses, confirms the hit against the format table and again against struct field offsets, then reads the published fix out of the disassembly. Sixty-eight per cent of the bytes differ; 0.29 per cent of the instructions do. The fix adds no bounds check: it widens four loop counters from int to i64, and one of the instructions that disappears is a sign extension inside a loop.

    Read it

    target
    SQLite 3.39.1 and 3.39.2, arm64 Mach-O, built from the released amalgamations. Not anybody's release artefact, and every address quoted is specific to those two files.
    tools
    radare2, Apple nm, otool, strings. Every command is printed in full.
    the record
    CVE-2022-35737, reported publicly and fixed by the SQLite project in July 2022. Violet RE played no part in finding, reporting or fixing it, and describes nothing undisclosed.
    and yet
    Fed this binary, Violet RE would not find it. The defect is a type width meeting an input of roughly two gigabytes, and the loop either side of the patch is the same loop, character for character. The piece closes on why a pattern check cannot see an arithmetic defect, which is worth more than a claim we cannot support.

.terms

What this series is, and is not.

  • published defects only Every piece works on vulnerabilities that were already reported and published, with the source cited. Nothing undisclosed appears here, and Violet RE claims credit for none of it.
  • nothing is executed The analysis is static, start to finish. No binary is run, no overflow is triggered, and no piece claims that a defect is reachable in any particular program.
  • no back catalogue This index lists what exists. There are no placeholder entries and no announced titles. More will appear as they are written, and the count in the masthead is the real count.
  • the limits are the point Each binary piece states what the product would and would not have found on the same target, and each data piece states what its count cannot show. A tool that only tells you about its successes is not much use when you are deciding whether to trust it.

Addresses, offsets and byte counts quoted in these pieces are specific to the exact builds named in them. A different compiler, architecture or optimisation level produces different output. Analyse only what you have the authority to analyse.

The front page sets out the rename gates, the shape of a finding, and the vulnerability data the analysis draws on, printed field by field with what each field actually records.