Decompile binaries. Read the code. Check it for known weakness types.

How a rename gets accepted.

Most deobfuscation tools guess identifier names and hope. Violet RE puts every proposal through a gate that is specific to the language, and records what happened.

The worked example below is one decompiled Python function, first as the decompiler emitted it, then after renaming. Seven renames were proposed. Six compiled to identical bytecode and were kept. One did not, so the original name stands and the report records which gate rejected it.

1  def _0x1a(v, k):
2      b = v[:4]
3      n = int.from_bytes(b, "little")
4      if n != 0x04034B50:
5          raise ValueError(_0x2c)
6      return _0x3d(v[4:], k)

1  def read_zip_entry(buffer, key):
2      header = buffer[:4]
3      magic = int.from_bytes(header, "little")
4      if magic != 0x04034B50:
5          raise ValueError(BAD_HEADER_MSG)
6      return _0x3d(buffer[4:], key)

Python

Bytecode equivalence. The renamed version must compile to identical bytecode.

C, C++, Java

Structural equivalence via Tree-sitter. The syntax tree after renaming must match.

every language

Per-proposal accept and reject tracking, surfaced in the report, including which gate rejected each proposal.

These are gates, not proofs. A gate checks equivalence under the rules of one language. It is not a claim of semantic understanding, and the report says where understanding stops.

Finding a function in a stripped binary.

A gate only has something to judge once you know what the function is. The name sqlite3_str_vappendf is in neither of the two SQLite builds we compiled for the published teardown. The function at 0x100002778 was identified three ways, and none of them needs the source.

one rare string

The %Q handler emits the literal (NULL), with parentheses, when the argument is null. That exact spelling occurs once in the file, and there is exactly one cross-reference to it, in the function beginning at 0x100002778.

the format table

The specifier scan loop is plainly visible in the disassembly: a counter of 23, a base address, and a stride of 6. Read the first byte of each of those 23 entries and they spell dsgzqQwcouxXfeEGin%pTSr, which is SQLite's fmtinfo[] table in order, byte for byte. A function that owns the format-specifier table is the printf implementation, whatever it is called.

struct field offsets

The first argument is an sqlite3_str*. The offsets the function loads from are 0x10, 0x14, 0x18, 0x1c and 0x1d, the last two as bytes. That is exactly nAlloc, mxAlloc, nChar, accError and printfFlags, laid out after a pointer to the database handle and a pointer to the text buffer.

One function, in one binary we built ourselves, argued by an analyst with every command printed. Violet RE does not do this part for you. What it does is the part above: once a name is proposed, the gate decides whether it survives, and the report says which gate rejected the ones that did not.

Check your own builds for known vulnerable patterns.

Shipped code is often code nobody on the team has read. Violet RE checks the recovered source for weakness types with a long public record: command and SQL injection, path traversal, template injection, unsafe deserialisation, server-side request forgery, hard-coded credentials, disabled TLS checks, unbounded string copies, and Android components exported without protection. No source code needed. Rule-based checks miss things.

A finding is a candidate, not a verdict. It names the weakness type (CWE), severity and confidence, the conditions required to reach it, the impact, the remediation, and what the analysis could not verify.

your releases

Check a build before it ships, from the binary rather than the repository.

mobile apps

APK, AAB and IPA. Android packages also get component export, WebView and cleartext traffic checks.

supplier software

Review a vendor binary you are authorised to assess, when there is no source to read.

1   void load_device_name(const char *src)
2   {
3       char name[64];
4       strcpy(name, src);
5       set_label(name);
6   }
7   
8   int apply_config(const struct config *cfg)
9   {
10      if (cfg->device_name == NULL)
11          return -1;
12      load_device_name(cfg->device_name);
13      return 0;
14  }

title        Unbounded C string copy
             requires a proven
             destination bound
cwe          CWE-120
severity     HIGH (CVSS 8.1)
confidence   PROBABLE
component    libexample.so,
             load_device_name
cve_ids      none claimed
conditions   copy is in a reachable
             build; src can exceed
             the destination
impact       memory past name may
             be overwritten
limitations  text-pattern rule;
             destination bound,
             callers, reachability
             not established;
             target not executed
remediation  bound the copy to
             sizeof(name)
evidence     sha256:0000...0000
             (placeholder)

Where the vulnerability data comes from, and what it is allowed to do.

Three public sources feed it: the CVE List V5 records maintained by the CVE Program, the enrichment NVD publishes on top of them, and the CISA Known Exploited Vulnerabilities catalogue. Every record keeps the source it arrived from and the date it was read. None of it is ours, and none of it is private.

Its job in an analysis is retrieval. Records and past fixes that resemble the code in front of the analyser are pulled in to steer where it looks, and that is the whole of the mechanism. Retrieved context carries no confidence effect: it cannot raise a finding, confirm one, or add a line to a report on its own. The counts below are an inventory of what is held. They are not a coverage claim, and your binary is not compared against them.

inventory as at 20 September 2026 -- counts move daily

guides, never concludes

Retrieval steers where the analyser looks. It carries no confidence effect, so a resemblance to a past vulnerability can never create a finding, raise its severity or confirm it.

no advisory matching

Jobs submitted through the website run a bounded static pass with advisory queries switched off in the job type itself. No CVE identifier and no advisory match reaches a customer report, because the customer manifest has no field to put one in.

read, never fetch

Repository URLs, patch references and proof-of-concept references are stored as metadata. Nothing in the table is cloned or downloaded while your job runs, and exploit code is never downloaded or run at all.

four gates, not one

Nominating a fix commit, verifying it, extracting a pair and promoting an aggregate pattern are four separate steps with four separate gates. The counts above show how many records survive each one, and the last gate has let nothing through.

the other patterns

A second and separate thing is also called a pattern: one promoted from a confirmed finding on a target rather than from the pairs above. A pattern from a confirmed finding is promoted only after the same weakness is confirmed independently in separate targets. Rerunning one target cannot confirm it. Free-tier patterns enter only under the data condition set out below, and paid work never does.

no uplift claimed

No gain in detection is claimed until one is measured on held-out cases. The model used to retrieve similar code is pretrained and pinned rather than trained here, and no uplift from any of this has been measured.

Your binary is not matched against every CVE in this inventory. Holding a record about a vulnerability is not the ability to find it in your binary, and the reverse holds too: the checks can match code that no record describes. Zero matches do not mean zero vulnerabilities.

The worked SQLite teardown in the analysis writeups takes a published CVE this service would not find, and says exactly why.

What you will be able to send.

Format and architecture detection is automatic. Supported extension labels are not guarantees that a particular target can be recovered, and the report says so when coverage is partial.

• not a sandbox Targets are never executed on the public tier. No dynamic analysis, no network callbacks, no sandbox escape surface. Public work is bounded and static.
• not an exploit generator Nothing is run, so nothing is proven exploitable. Findings state the conditions required to reach a weakness, and confirmation stays with you.
• not a name generator The deobfuscation engine is over 7,000 lines of dedicated code: bytecode-equivalence gates for Python, Tree-sitter structural validation for C, C++ and Java, and per-proposal accept and reject tracking.

When you can use it.