Reverse Engineering: Law and Lawful Uses

Learning goal: Explain what reverse engineering is and why people do it, tell apart the boundaries set by Korean, US and EU law and by contracts, and carry out competitor product analysis and your own legacy decoding within lawful limits, verifying as you go.

A solo studio runs into reverse engineering too: when it studies a competitor's pricing, and when it has to reread its own code and data files that were left without documentation. This document covers the legal boundaries and lawful uses, not analysis techniques. Permissions to give an agent are in "Permissions, Sandbox, Hooks"; what to show the model in "Layers of AI Engineering: Prompt, Context, Harness"; the repeating structure that feeds verification back in "Loop Engineering"; and who owns outsourced code in "Contracts · IP · Open Source". Statutes and cases are as of 2026-09; items confirmed only through search results, because the original could not be opened directly, are marked in the references.

This document is general information, not legal advice. Legal interpretation depends on the facts and on timing. Consult a lawyer before analysing anyone else's software or service.

Key Concepts

Definition

Forward engineering goes from requirements through design and implementation to a finished product. Reverse engineering runs the other way. It starts from a finished product and recovers its design, structure and behaviour. A good output is not a copy of the original but an explanation with evidence. Sentences such as "the payment screen appears after the 7-day free trial" or "the first field of this save file is a version number", together with a way to check them again, are the result.

Why people do it

• Interoperability: to let your program exchange information with other programs or files.
• Maintaining your own legacy: to understand again your own code and data formats whose documents and authors are gone.
• Studying competitors' products: to learn onboarding, pricing and feature structure by using them as a normal customer.
• Security research: for authorised professionals to find and fix flaws.

Even with the same purpose, the target and the method decide whether it is lawful. The principles below cover that boundary.

Principles

Korea: reverse analysis of program code under the Copyright Act

• Definition (Article 2, item 34): copying or converting program code to obtain the information needed for an independently created program to interoperate with other programs.
• Conditions (Article 101-4(1), "Reverse Analysis of Program Code"): (1) a person using the program with legitimate authority, or a person they authorise, (2) where the information needed for interoperability cannot readily be obtained and obtaining it is unavoidable, (3) limited to the parts needed for interoperability.
• Limits on use (Article 101-4(2)): the information obtained may not be used for purposes other than interoperability or given to third parties, and may not be used to develop, produce or sell a program substantially similar in expression to the target, or for any other copyright infringement.
• Technological protection measures (Article 104-2, "Prohibition of Circumvention of Technological Protection Measures"): circumventing protection measures without legitimate authority is prohibited. The same article lists a few exceptions, including reverse analysis of program code for interoperability, but they are narrow. Do not decide on your own whether an exception applies.

Korea: trade secrets and information networks

• Trade secrets (Unfair Competition Prevention and Trade Secret Protection Act, Article 2, items 2 and 3): technical or business information that is not publicly known, has independent economic value and is kept secret is a trade secret. Acquiring it by theft, deception or other improper means, or using or disclosing what was acquired that way, is infringement.
• Reverse engineering and trade secrets (Supreme Court Decision 96Da16605, 1996-12-23): the Supreme Court set the injunction period on the premise that a trade secret can be acquired by lawful means such as independent development or reverse engineering. This reads as not treating the lawful purchase and analysis of a product on the market as an improper means in itself. Individual cases may still be judged differently.
• Network intrusion (Act on Promotion of Information and Communications Network Utilization and Information Protection (the Network Act), Article 48(1)): entering an information network without legitimate access rights, or beyond the access permitted, is prohibited, and a violation can be a criminal offence. This document does not settle which penalty article applies. The risk turns largely on whether an access control such as a login, token or signature exists (see 2021Do1533 below).
• The crawling case (Supreme Court Decision 2021Do1533, 2022-05-12): accommodation listings were collected from a competitor's app API server. All three charges ended in acquittal: network intrusion under Network Act Article 48, obstruction of business by computer interference, and infringement of a database producer's rights under the Copyright Act. According to commentary on the judgment, the grounds were these. Intrusion: the API server could be reached without sign-up or authentication, and the data it returned was already shown to app users, so there was no access control to get past. The Court said access rights must be judged from objectively visible circumstances such as technical protection measures and access methods stated in the terms. Database: the part copied could not be seen as a substantial part of the database. Obstruction: requests within the permitted command range were hard to see as improper commands, and it was not proved that the defendants caused the disruption. On the same facts, the civil first instance (Seoul Central District Court, 2021-08-23) reportedly ordered 1 billion won in damages for unfair competition by unauthorised use of another's work product (then Article 2, item 1(ka), and item 1(pa) after the amendment in force from 2022-04-20). The appeal outcome could not be confirmed.

The US and the EU

• US DMCA §1201(f): a person with the right to use a program lawfully may circumvent a technological measure solely to identify elements needed for an independently created program to interoperate, where those elements were not previously readily available. The condition is that this does not amount to copyright infringement.
• Sega v. Accolade (9th Cir. 1992): reverse analysis to make compatible games was fair use when it was the only way to reach unprotected elements and there was a legitimate reason.
• Bowers v. Baystate (Fed. Cir. 2003): a licence clause prohibiting reverse engineering was enforced. However, Judge Dyk dissented in part on preemption, and the earlier Vault v. Quaid (5th Cir. 1988) held that a state law allowing reverse-engineering bans was preempted by federal copyright law. It is not a settled US-wide rule.
• EU Directive 2009/24/EC: Article 5(3) lets a lawful user observe, study or test how the program works while loading or running it, to find the ideas and principles behind it. Article 6 lets a licensee or similar person decompile, when interoperability information is not readily available, only the parts needed, and bars using the information for other goals, giving it to others or developing a similar program. Article 8 makes contract terms contrary to Article 6 and to Article 5(2) and (3) null and void. The CJEU held in SAS Institute v World Programming (C-406/10, 2012) that the Article 5(3) right cannot be contracted away (under Article 9(1) of the earlier Directive 91/250/EEC).

Contracts: EULAs and ToS

Software EULAs and service terms of service (ToS) commonly prohibit reverse engineering, automated collection, unofficial clients, use for developing or benchmarking competing products, and publishing benchmark results. How far such clauses can narrow what Article 101-4 allows in Korea was not confirmed for this document. Apart from the legal answer, the practical risk is clear: account bans, loss of app store or API access, breach-of-contract claims and broken partnerships. For a solo studio, a single account ban can halt the business.

"May I do this?"

flowchart TD
    A[What you want to analyse] --> B{Is it your own code or data}
    B -->|Yes| C[Proceed: verify explanations with tests]
    B -->|No| D{Does it need bypassing protection or private server access}
    D -->|Yes| W{Is there written permission or a bug bounty scope}
    W -->|Yes| S[Proceed only within the permitted scope]
    W -->|No| X[Do not do it]
    D -->|No| E{Are you only observing as a normal customer}
    E -->|Yes| F{Do the terms prohibit this use: benchmarking and competing development included}
    F -->|No| G[Generally fine: internal reference only]
    F -->|Yes| L[Stop and consult a lawyer]
    E -->|No| H{Is it for interoperability with no other source of the information}
    H -->|Yes| L
    H -->|No| X

Applied: Lawful Reverse Engineering in a Solo Studio

Competitor teardown: use it as a customer and record

Sign up as a normal customer and pay if needed. Record only what a person sees while using the product, with no automation tools and no private paths.

1. Before signing up, look in the terms for clauses banning use for competing development or benchmarking and banning publication of benchmark results, and record them with the date. If one exists, follow the lawyer path in the flowchart above.
2. Collect the records in one table with dates and screenshots. Prices and terms change often.
3. Compare several competitors in the same columns and mark what everyone does and what nobody does.
4. Turn the gaps into customer problems, test them in interviews from "Market & Customer Research · Segmentation", and put them into "Discovery · Strategy · Roadmaps".
5. Turn the confirmed differences into a positioning statement using "Positioning · Messaging · Brand". Set prices with the framework in "Paid Sales, Subscriptions and Pricing".
6. Before naming a competitor in ads, read "Law · Ethics · Ad Disclosure". Keep screenshots and copy as internal material and do not publish them.

Reading your own legacy code and data files with an AI agent

When you need to understand your own undocumented code, or save files your own app produced, an AI agent is a fast assistant. But the agent's explanation is a hypothesis, not a fact. A plausible but wrong explanation is the most dangerous kind.

1. Confirm ownership: check by contract that the code is yours or that its rights were transferred to you.
2. Separate the workspace: work on a copy, not the original, and narrow the agent's write and network permissions ("Permissions, Sandbox, Hooks"). Use only sample files your own app produced, and anonymise them first if customer data is mixed in.
3. One question at a time: ask narrowly, such as "how does this function write the version field of the save file", rather than "what does this module do".
4. Record explanations as hypotheses: attach one line on how to check each agent explanation.
5. Verify by running: run the existing tests, add characterization tests that pin current behaviour, and compare the outputs of the old program and the new code on the same input. The golden file is produced by actually running the legacy program; never write it by hand from the agent's explanation. If it fails, revise the hypothesis and ask again ("Loop Engineering").
6. Document only what is confirmed: move only explanations that passed verification into the README or format documentation.

# Characterization test: pin today's behaviour before trusting any explanation
# The golden file comes from running the legacy program, never from the agent's explanation
import json
import subprocess

def test_new_reader_matches_legacy_output(tmp_path):
    out = tmp_path / "new.json"
    subprocess.run(["python", "new_reader.py", "samples/save_001.dat", str(out)], check=True)
    legacy = json.loads(open("samples/save_001.legacy.json", encoding="utf-8").read())
    assert json.loads(out.read_text(encoding="utf-8")) == legacy

Going Deeper

Where the lines blur

• No access control does not end the analysis: in 2021Do1533 the criminal court found no intrusion because there was no access control to get past. Yet the civil first instance on the same facts reportedly imposed liability on a separate theory, unfair competition by unauthorised use of another's work product, that is, free-riding on another's investment and effort. The absence of a technical access control does not end the analysis.
• Contract versus statute: the EU, through Article 8, does not let contracts remove the Article 5(3) right to observe, study and test or the Article 6 decompilation allowance, and the SAS ruling confirmed this. In the US, Bowers enforced a contractual ban, but with the dissent and Vault v. Quaid it is not a settled rule. Korea's position was not settled for this document.
• Services across borders: foreign services' terms usually set the governing law and jurisdiction. Something that looks lawful in Korea may be disputed under the law of the country the terms name.

When to call a lawyer

• When you plan to analyse someone else's software for interoperability
• When protection measures, licence checks or private servers are involved even slightly
• When you receive a warning letter or a notice of terms violation from a competitor
• When you plan to use analysis results in a product, an ad or a public post

Common Misconceptions

• "I bought it, so I can analyse it however I like." Ownership aside, the Article 101-4 conditions and limits on use, and the contract terms, still apply.
• "If the app is public, its private API is public too." Network Act risk turns on whether an access control such as a login, token or signature exists. Even without one, terms violations and unfair competition issues remain.
• "A criminal acquittal means no problem." Civil liability and account bans are separate.
• "Saying it is for interoperability is enough." What is examined is whether it was really limited to the parts needed and whether the information could not be obtained otherwise.
• "The AI explained it, so it is right." An unverified explanation is a hypothesis. Confirm it with tests and output comparison.

Self-Check Questions

1. Can you explain the three conditions in Article 101-4(1) and the limits on use in Article 101-4(2)?
2. In a competitor teardown, name one permitted observation and one action to avoid.
3. How did the criminal judgment in 2021Do1533 differ from the reported civil first-instance ruling, and what is the lesson for a studio?
4. How do EU Article 8 and the SAS ruling differ from Bowers v. Baystate and Vault v. Quaid on the effect of contract clauses?
5. When an AI agent explains a legacy file format, what would you use to verify that explanation before putting it in documentation?

References

• Copyright Act, Article 101-4 (Reverse Analysis of Program Code) — Korea Law Information Center, checked via search results 2026-09-29
• Copyright Act, Article 2 (Definitions) · Article 104-2 (Prohibition of Circumvention of Technological Protection Measures) — Korea Law Information Center, checked via search results 2026-09-29
• Unfair Competition Prevention and Trade Secret Protection Act, Article 2 (Definitions) · Reasons for enactment and amendment (2021-12-07 amendment, item (ka) to (pa)) — Korea Law Information Center, checked via search results 2026-09-29
• Act on Promotion of Information and Communications Network Utilization and Information Protection, Article 48 — Korea Law Information Center, checked via search results 2026-09-29
• Supreme Court Decision 96Da16605 (1996-12-23) — Korea Law Information Center, checked via search results 2026-09-29
• Supreme Court Decision 2021Do1533 (2022-05-12) · Supreme Court summary of major rulings — CaseNote · Supreme Court of Korea, checked via search results 2026-09-29
• News report on the Yanolja v. Yeogi Eottae civil first-instance ruling (2021-08-23) — Korea Economic Daily, checked via search results 2026-09-29 (judgment text and appeal outcome not checked)
• 17 U.S. Code § 1201 — Cornell LII, checked via search results 2026-09-29
• Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992) — Justia, checked via search results 2026-09-29
• Bowers v. Baystate Technologies, Inc., 320 F.3d 1317 (Fed. Cir. 2003) · Vault Corp. v. Quaid Software Ltd., 847 F.2d 255 (5th Cir. 1988) — Justia, checked via search results 2026-09-29
• Directive 2009/24/EC on the legal protection of computer programs · SAS Institute v World Programming, C-406/10 (2012) — EUR-Lex, checked via search results 2026-09-29