Security & Responsible Disclosure.

How CRY keeps you safe

CRY makes CRY Optimizer, a free Windows utility that reads and writes registry keys, configures services, and runs system commands. The design constraints that limit blast radius:

• A System Restore point is created first. Before CRY applies anything, it makes a restore point, so a whole session can be rolled back in one step.
• Every change is shown verbatim. Each tweak card shows the exact registry key, service, or command, old to new, before anything runs. No hidden actions.
• Per-tweak revert. Every change is journaled and reversible from History, per tweak, per session, or all at once; undo restores the exact prior state.
• A local, append-only changelog. Each applied tweak and its previous value is recorded under %LOCALAPPDATA%\CryOptimizer. It never leaves your PC.
• No telemetry. No self-telemetry, no phone-home. There is no remote configuration channel and no analytics endpoint to compromise.
• It launches non-elevated. CRY requests Administrator only when you apply a change that needs it, and you can cancel with no side effects.

CRY is currently v1.1 BETA. There will be bugs. Report them.

Reporting a vulnerability

Please report security issues privately by email to realwilari@gmail.com. Do not open a public issue, post details on social media, or share a working exploit before we've had a chance to fix the problem.

If you'd like to encrypt your report, a PGP key is available on request — email us at the address above and ask for it before sending sensitive details. For routine, non-sensitive reports, plain email is fine. This page is also referenced from our machine-readable security.txt file.

What to include

The more of the following you can give us, the faster we can confirm and fix the issue:

• A clear description of the vulnerability and the security impact (what an attacker could actually do).
• Step-by-step instructions to reproduce it, ideally from a clean Windows 10 or 11 (64-bit) install.
• The affected version (for example v1.1 BETA) and which surface is affected — the app, the portable build, or this website.
• Any proof-of-concept, screenshots, logs, or a short screen recording. Please redact your own personal data.
• Your assessment of severity, and how you'd like to be credited if we publish a fix.

Please do not include real personal data or other people's data in your report, and don't run tests against systems that aren't yours.

Scope

The following are in scope for a security report:

• The CRY Optimizer desktop application — including how it applies, journals, and reverts changes, and how it handles the Administrator elevation step.
• The portable build distributed as a .zip — for example integrity, tampering, or unsafe handling of imported cryset: preset codes.
• This website (al1.gg) and its content.

If you're unsure whether something is in scope, email us and ask — we'd rather review a borderline report than miss a real one.

Out of scope

The following generally fall outside this policy. Reports limited to these are unlikely to be treated as security issues:

• Social engineering of CRY, our users, or anyone else (phishing, pretexting, vishing).
• Physical attacks, or attacks requiring physical access to a victim's unlocked machine.
• Volumetric denial-of-service (DoS/DDoS), traffic flooding, or resource-exhaustion attacks.
• Output from automated scanners with no demonstrated, exploitable impact.
• Missing security headers, best-practice suggestions, or version banners without a concrete, demonstrable vulnerability.
• Issues that require an already-compromised system, malware already running with Administrator rights, or an attacker who can already write to protected system locations.
• Reports about the behaviour of Windows itself or third-party software that CRY merely configures.

This list isn't exhaustive. When in doubt, ask.

Safe harbor

We support good-faith security research. If you make a genuine, good-faith effort to follow this policy, we will not pursue or support legal action against you for your research, and we will treat your activity as authorized. To stay within safe harbor, please:

• Only test against your own systems and your own copy of CRY — never another person's machine or data.
• Avoid privacy violations, data destruction, and any disruption to others.
• Access only the minimum data needed to demonstrate the issue, and stop once you've confirmed it.
• Give us a reasonable opportunity to fix the issue before disclosing it publicly.

This safe harbor applies to the extent permitted by the applicable law of the jurisdiction in which CRY is established; nothing here authorizes activity that is unlawful or that targets third parties. If in doubt about whether an action is permitted, ask us first.

Response process & timelines

CRY is a small effort. The process below is what we can commit to, not a service-level guarantee:

• Acknowledgment. We aim to confirm we've received your report within a few business days.
• Triage. We'll work to reproduce the issue, assess its impact and severity, and let you know whether it's in scope.
• Fix. We'll coordinate a fix and keep you reasonably informed of progress. Timelines depend on complexity and severity — higher-impact issues are prioritized.
• Resolution. Once a fix ships, we'll confirm with you and, where relevant, note the change in the changelog.

If you don't hear back in a reasonable time, it's fine to send a polite follow-up to realwilari@gmail.com — messages occasionally get missed.

Coordinated disclosure

We ask that you give us a reasonable window to investigate and release a fix before any public disclosure, and that you don't publish details or working exploits that would put users at risk in the meantime. In return, we'll work the issue in good faith and keep you in the loop. Once a fix is available, we're happy to coordinate timing on any write-up or advisory, and to credit you if you'd like. We don't currently run a paid bug-bounty program, so reports are handled on a coordinated-disclosure basis rather than for a reward.

Acknowledgments

We're grateful to the researchers who report issues responsibly. If you report a valid vulnerability and would like public credit, tell us how you'd like to be named (handle, name, or a link) and we'll acknowledge your contribution when the fix is published. If you'd prefer to remain anonymous, that's completely fine — just say so.

security.txt reference

For automated tooling, the canonical contact details live in our machine-readable policy file at /.well-known/security.txt, following the security.txt convention. It points back to realwilari@gmail.com and to this page. If the two ever disagree, the most recently updated version of this page takes precedence.