Expected release Autumn 2026

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

Send an executable or a mobile package you own or are authorised to assess. Violet RE recovers readable source, then checks that source for known vulnerable patterns. Targets are never executed on the public tier. The analysis is static, start to finish.

  • Readable source. Decompiled and deobfuscated, with every proposed rename checked against a language-specific equivalence gate before it is accepted.
  • Vulnerability checks. Known weakness types, such as injection and path traversal, each finding with its conditions, confidence and limits. Guided by a database of CVE, NVD and CISA KEV records.

The service is not open. Uploads are not being accepted, and accounts cannot be created.

Validation

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.

original_source/zip_entry.py Decompiler output
violet_source/zip_entry.py Violet reconstruction
Gate applied
Python bytecode equivalence
Proposals accepted
6 of 7
Rejected by the gate
1, name unchanged
  • Obfuscated identifier, as emitted
  • Rename accepted by the gate
  • Rename rejected, original kept

In the example, six identifiers are renamed and the seventh, _0x3d, is left as the decompiler emitted it. Both files ship: the raw decompiler output and the Violet reconstruction are separate artefacts in the same package, alongside the transformation record and the rejection log. Diff them yourself.

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.

Vulnerabilities

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.
violet_source/libexample/device.c Recovered source
void load_device_name(const char *src)
{
    char name[64];
    strcpy(name, src);
    set_label(name);
}

int apply_config(const struct config *cfg)
{
    if (cfg->device_name == NULL)
        return -1;
    load_device_name(cfg->device_name);
    return 0;
}
report/findings/F-0007 Illustrative finding
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)
Rule
strcpy call (text pattern)
Confidence
Probable
Target executed
No

Illustrative only, not a customer result. The library, function and hash are placeholders. The finding is marked probable because a text-pattern rule matched strcpy. Destination size, callers and reachability were not established. It says so, rather than rounding up.

The vulnerability data behind it

Analysis is guided by a vulnerability database that is kept in sync with its sources. Nothing in it can raise a finding on its own.

Sources
CVE List V5, NVD and CISA KEV (Known Exploited Vulnerabilities), with the source of every record kept.
Past fixes
Past CVE fixes are studied as vulnerable and fixed code pairs, taken only from the exact fix commits named in advisories. The fix code is never checked out or run.
Similar cases
Similar past vulnerabilities are pulled in to guide analysis. Similarity alone never creates or confirms a finding.
New patterns
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 gain in detection is claimed until one is measured on held-out cases.
Exploit code
Exploit code is never downloaded or run.

A clean result is not a clearance. Zero matches do not mean zero vulnerabilities. On the free tier you see severity counts. Finding details, remediation and downloads require a paid plan. Analyse only what you have the authority to analyse.

The report

What you get back.

  1. Vulnerability findings, with their limits

    Weakness class (CWE), severity, a confidence level, the affected component, the conditions required to reach it, an impact assessment, remediation guidance and evidence hashes. Each finding also states what the analysis could not verify.

  2. Both source files ship

    Two files per unit: the raw decompiler output and the Violet reconstruction. Neither is the developer's original source code. Both are readable, and transformation records and rejection logs ship alongside them.

  3. Nothing is renamed quietly

    The report counts accepted proposals and rejected proposals, and names the gate that rejected each one.

  4. Browser, PDF, ZIP

    A browser report for triage, a PDF for people who were not in the room, and a content-addressed ZIP whose contents are fixed by contract: the report, the manifest, and the paired source trees. Nothing else is permitted inside it.

Scope

What you will be able to send.

  • PE
  • ELF
  • Mach-O
  • WebAssembly
  • APK
  • AAB
  • IPA
  • Archives

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.

Release

When you can use it.

Expected release

Autumn 2026

Violet RE is staged and closed. When it opens, this page is replaced by the product. These are the free-tier limits as designed today, not an open offer:

  • Two analyses per UTC calendar month, up to 50 MB per target.
  • Severity counts only on the free tier: critical, high, medium, low, info, plus the total number of findings.
  • Reports kept 24 hours on the free tier. Paid plans keep them longer.
  • No card required for the free tier.
  • Free use carries a data condition with no opt-out: independently validated, de-identified, generalisable structural patterns may be used in Violet's pattern library. Raw binaries, recovered source, source fragments, credentials, filenames, identifiers, report prose and customer-specific embeddings are excluded. Paid plans are isolated by default, and nothing from them enters general learning.

Prices, paid-plan allowances and the commercial terms are published at launch. Anything quoted before then is provisional.