Security and code handling

You are being asked to upload compiled software to a server you do not control. That deserves a straight answer about what happens to it.

What happens to an uploaded file

Uploaded files may be buffered in temporary server files while the request runs. The obfuscation engine reads the assembly into memory, rewrites it, and returns the protected copy in the response. Temporary request buffers are released when the request ends. We do not maintain an upload archive or keep assembly copies for debugging.

We also do not keep a name mapping. On Pro you can ask a build to include a rename map so you can decode a crash stack trace back to your original names — but that map is generated in memory, handed to you in the download, and never written to our storage. There is nothing on our side that could reverse your obfuscation or leak your original symbol names; the only copy of the mapping is the one you keep.

The honest caveat. Your assembly does leave your network to reach us. If you work under classification, a regulatory regime, or a contract that forbids sending build artifacts to third parties, use a tool that runs on your own machine instead — the comparisons cover local options including free ones. We would rather you pick the right tool than the convenient one.

A first-party answer is on the way: we're building a native Windows desktop app that runs this same obfuscator entirely offline, so nothing ever leaves your machine. It isn't released yet — until it is, a local tool remains the right call for code you cannot upload. We'll post it on the changelog when it ships.

What we record

Usage is counted as daily aggregates — how many obfuscations succeeded or failed on a given day, by plan and by entry point. These counters do not include filenames, file contents, symbol names or user identifiers.

Application logs record errors so faults can be diagnosed. When obfuscation fails, logs can include exception details, filenames and account identifiers. Assembly contents are not deliberately logged. You receive a generic error message so internal details are not exposed in the response.

Accounts and payment

  • No account is needed to use the free tier. You can obfuscate a file without telling us anything about yourself.
  • Registered accounts have an email address, a password hash and an account creation date. For billing we also store Stripe identifiers, subscription status, renewal/cancellation details and an API key when one is issued.
  • Card details never reach our servers. Payment runs entirely through Stripe. We receive billing identifiers and subscription status updates.
  • API keys are shown only to the account that owns them, are masked by default in the interface, and can be rotated at any time from your account page. Rotation invalidates the previous key immediately.

Transport and application security

  • All traffic is served over HTTPS, with HSTS enabled.
  • X-Content-Type-Options, X-Frame-Options and a Referrer-Policy are set on every response.
  • Diagnostic pages that expose infrastructure detail require authentication; they are not publicly reachable.
  • Oversized uploads are rejected on the request headers, before any file data is buffered.
  • Concurrent obfuscation is bounded, so a burst of traffic degrades into a queue rather than exhausting the server.

What this tool does not do

Being clear about the limits matters more on a security page than anywhere else:

  • Renaming, string encryption, control-flow obfuscation, call-reference proxying, and optional method virtualization. Each is opt-in. There is no anti-debugging, the only anti-tamper is an optional integrity check on virtualized methods, and nothing here is a licensing system.
  • String encryption is opt-in. With it on, string literals are encrypted and no longer readable in a decompiler. It removes the plaintext, but a determined reader can still run the decryptor — so it is not a substitute for keeping real secrets out of a client binary and on the server.
  • Protection raises cost, it does not make code unbreakable. Anything that runs on a machine someone controls can, with enough effort, be reversed. These transforms are about turning a five-minute decompile into a job few will bother with — not about a guarantee we cannot honestly make.
  • It is not a licensing system. A check running on a machine the user controls can ultimately be defeated; obfuscation raises the cost, and server-side validation is what changes the outcome.

What obfuscation actually protects against goes through the threat model properly.

Who operates this

FreeObfuscator is built and run by Richscripts Inc., which has been shipping developer tools since 2003 — editors, upload components, live chat and obfuscation products used by development teams worldwide. This is not an anonymous utility that appeared last month.

More on that in about us, and the privacy page covers data handling in policy terms.

Reporting a security issue

If you believe you have found a vulnerability, email [email protected] with enough detail to reproduce it. We will confirm receipt and keep you informed. Please give us a reasonable window to fix an issue before disclosing it publicly.