Legal Disclosures

Purpose and Scope

Actyra Open is a research and educational platform. All binary analysis, decompilation, and reverse engineering activities documented on this site are conducted solely for the purposes of security research, interoperability analysis, and consumer education.

Our goal is to provide transparency about what software actually does at the code level, enabling consumers, researchers, and regulators to make informed decisions.

Legal Basis for Reverse Engineering

Reverse engineering for the purposes described herein is protected under multiple legal frameworks:

• U.S. Copyright Act, 17 U.S.C. § 107 (Fair Use) — Analysis is transformative in nature, used for commentary, criticism, and research purposes, and does not substitute for the original works.
• U.S. Digital Millennium Copyright Act (DMCA), 17 U.S.C. § 1201(f) — Permits reverse engineering of computer programs for the purpose of achieving interoperability and identifying security vulnerabilities.
• U.S. Computer Fraud and Abuse Act (CFAA) Exemptions — Good faith security research conducted on lawfully obtained software is protected under DOJ policy and recent case law.
• EU Directive 2009/24/EC, Article 6 — Permits decompilation for the purposes of achieving interoperability, provided conditions are met.
• EU Trade Secrets Directive 2016/943, Article 3(1)(b) — Observation, study, or testing of a product made available to the public is a lawful means of acquiring trade secrets.

Relevant Case Law

Courts have consistently held that reverse engineering for research, interoperability, and consumer protection purposes is defensible when conducted in good faith:

• Sony Computer Entertainment v. Connectix Corp. (2000) — The Ninth Circuit ruled that reverse engineering a proprietary system for the purpose of developing a compatible product constituted fair use, even though the process involved copying.
• Sega Enterprises v. Accolade (1992) — The Ninth Circuit held that disassembly of object code to gain access to unprotected functional elements is a fair use when it is the only means of access.
• Google LLC v. Oracle America (2021) — The Supreme Court held that copying portions of a software interface for a transformative purpose was fair use, reinforcing the principle that context and purpose matter in software copyright analysis.

Conversely, courts have found reverse engineering unlawful when conducted to circumvent protections for commercial gain or to enable piracy (e.g., Blizzard v. BnetD, 2005). Our work falls squarely in the research and consumer education category.

Terms of Service Considerations

Many software vendors include clauses in their End User License Agreements (EULAs) or Terms of Service that purport to prohibit reverse engineering. We acknowledge these provisions but note:

• Statutory reverse engineering rights (DMCA § 1201(f), EU Directive 2009/24/EC Art. 6) cannot be overridden by contract in many jurisdictions.
• Fair use is a federal right that generally preempts conflicting contractual terms when the purpose is security research or public interest commentary.
• Consumer protection and public interest considerations weigh in favor of transparency research that reveals undisclosed data collection practices.

Methodology Statement

All software analyzed is lawfully obtained through official, publicly available channels (vendor websites, app stores, direct downloads). We download and retain legitimate copies of the software we analyze. Our analysis is limited to:

• Static analysis of publicly distributed binaries using open-source tools (primarily Ghidra)
• String extraction and API call identification
• Network endpoint and data flow analysis
• Comparison of observed behavior against published vendor policies

We do not distribute decompiled source code in its entirety. Published evidence consists of limited excerpts necessary to support specific findings, consistent with fair use principles.

What We Do Not Do

To be explicit about the boundaries of our work:

• We do not circumvent license activation, copy protection, or DRM systems
• We do not distribute, redistribute, or make available any proprietary software, modified binaries, or patched executables
• We do not create tools to bypass software licensing or enable piracy
• We do not inject malicious code into software or create derivative malware
• We do not steal or misappropriate proprietary algorithms for commercial use
• We do not publish complete decompiled source code — only limited excerpts necessary to substantiate specific findings
• We do not exploit discovered vulnerabilities — we follow responsible disclosure

Ethical Guidelines

Beyond legal compliance, we adhere to the following ethical principles:

• Lawful acquisition — We only analyze software that has been lawfully obtained through official distribution channels.
• Responsible use of findings — Findings are published to inform and protect consumers, not to enable exploitation or harm to vendors.
• Respect for intellectual property — We respect that the software we analyze is the intellectual property of its creators. Our work is limited to documenting observable behavior, not reproducing or competing with the original works.
• Proportional disclosure — Evidence excerpts are limited to the minimum necessary to support each finding. We do not publish more than is needed for verification.
• Good faith engagement — We welcome corrections from vendors and will update or retract findings when presented with credible evidence of error.
• No redistribution — We never redistribute analyzed software, modified binaries, or tools designed to circumvent vendor protections.

No Affiliation

Actyra is an independent research organization. We are not affiliated with, endorsed by, or sponsored by any of the software vendors whose products are analyzed on this platform. All trademarks, product names, and company names referenced are the property of their respective owners and are used solely for identification purposes.

Accuracy and Currency

Findings reflect the state of the software at the specific version and date of analysis, as noted in each report. Software vendors may update their products at any time, and current versions may differ from analyzed versions. We make reasonable efforts to ensure accuracy but do not guarantee that findings are free from error.

If you are a software vendor and believe any finding is inaccurate, please contact us at hello@actyra.com. We are committed to factual accuracy and will promptly review and correct any verified errors.

Responsible Disclosure Policy

When our analysis identifies a security vulnerability that could pose risk to end users, we follow a structured responsible disclosure process:

1. Vendor notification — We make reasonable efforts to contact the affected vendor through official security channels (security@, bug bounty programs, or published security contacts) with full technical details of the vulnerability.
2. 90-day remediation window — Vendors are given 90 days from initial notification to address the vulnerability before public disclosure.
3. Extension for active remediation — If the vendor is actively working on a fix and can demonstrate progress, we may extend the disclosure timeline beyond 90 days.
4. Expedited disclosure — If a vulnerability is being actively exploited in the wild, or the vendor is unresponsive after repeated contact attempts, we may shorten the disclosure timeline to protect affected users.
5. Publication — After the remediation window, findings are published with sufficient detail to inform users of the risk and any available mitigations.

Note: The majority of our published findings relate to data collection and privacy practices rather than exploitable security vulnerabilities. These transparency findings are published as part of our standard research without a remediation window, as they document existing, publicly observable behavior rather than disclosing novel attack vectors.

CVE and Vulnerability Classification

Actyra participates in the global vulnerability disclosure ecosystem. When our research identifies findings that meet the criteria for formal vulnerability classification:

• CVE submission — Security vulnerabilities identified during our analysis are submitted to the CVE Program (operated by MITRE) for formal CVE ID assignment. This ensures our findings are cataloged in the global vulnerability database and accessible to the wider security community.
• CWE classification — Findings are tagged with relevant Common Weakness Enumeration (CWE) identifiers to categorize the type of weakness observed (e.g., CWE-798 for hard-coded credentials, CWE-359 for exposure of private personal information, CWE-319 for cleartext transmission of sensitive information).
• Coordinated disclosure — CVE requests are submitted only after the vendor has been notified and the remediation window has elapsed, consistent with our responsible disclosure policy above.

Not all findings warrant CVE assignment. Our reports include two categories:

• Security vulnerabilities — Exploitable flaws that could compromise user security (eligible for CVE assignment). Examples: hard-coded API secrets, missing signature verification, cleartext credential storage.
• Privacy and transparency findings — Undisclosed data collection practices, excessive fingerprinting, or policy discrepancies. These are documented with GDPR/CCPA article references rather than CVE IDs, as they represent regulatory compliance concerns rather than exploitable vulnerabilities.

Published CVE IDs are referenced alongside our internal finding IDs (e.g., ccl-hw-001) in each report where applicable.

Limitation of Liability

The information provided on this platform is for research and educational purposes only and does not constitute legal advice. Users should consult qualified legal counsel for advice on specific legal matters. Actyra makes no warranties, express or implied, regarding the completeness, accuracy, or reliability of any information published herein.

In no event shall Actyra, its officers, employees, or agents be liable for any indirect, incidental, special, consequential, or punitive damages arising from the use of or reliance on information published on this platform.

GDPR and Privacy Analysis

Where our reports reference GDPR, CCPA, or other privacy regulations, these references represent our technical assessment of observed software behavior in relation to published regulatory requirements. They do not constitute a legal determination of compliance or non-compliance. Regulatory enforcement is the sole authority of the relevant supervisory bodies.