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.
- 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.
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;
}
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.
-
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.
-
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.
-
Nothing is renamed quietly
The report counts accepted proposals and rejected proposals, and names the gate that rejected each one.
-
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.