Reverse Engineering and Decompilation
When a modder encounters a behavior in Unturned™ that is not explained in the official documentation, the instinct to look at the source is understandable. Unturned™ ships as a compiled .NET assembly — specifically Assembly-CSharp.dll — and decompilation tools exist that can reconstruct a reasonable approximation of the original C# source code from that compiled binary. The tools are not obscure: dnSpy, dotPeek, and ILSpy are widely used, actively maintained, and freely available.
The legal question — whether a modder may use these tools on Unturned's assembly, and what they may do with the resulting output — is governed by a specific intersection of copyright law, the Digital Millennium Copyright Act (DMCA), and the documented stance of Smartly Dressed Games (SDG) on modder research practices. This article explains that intersection in detail and documents the 57 Studios™ policy on decompilation within the modding workflow.
Disclaimer
This article is informational documentation from 57 Studios™ about how decompilation and reverse engineering law is commonly understood to apply to the Unturned™ modding context. It is not legal advice. A modder who faces a specific dispute or legal question should consult a licensed attorney in their jurisdiction. Nothing in this article creates an attorney-client relationship or constitutes legal counsel.
What decompilation produces and why modders need it
Compiled .NET assemblies are stored in the Common Intermediate Language (CIL) — a bytecode format that is not human-readable but is substantially more recoverable than native machine code. Decompilation tools analyze the CIL bytecode and reconstruct C# (or VB.NET, F#, or IL) source code that, when recompiled, produces behavior equivalent to the original.
The reconstruction is imperfect. Variable names that were stripped during compilation cannot be recovered — the decompiler generates placeholder names like param_1 or localVariable_0. Method names defined in the original source are generally preserved in the PDB-absent build that SDG ships. Comments are lost. Compiler optimizations may produce decompiled code that is structurally different from the original source while being functionally equivalent.
Despite these limitations, decompiled output is useful to modders for specific purposes:
| Purpose | What the modder extracts from decompiled output |
|---|---|
| Understanding event signatures | Method parameter types and return types for events that mods can subscribe to |
| Understanding field relationships | Which fields on ItemGunAsset, UseableGun, and related classes are read at what point in execution |
Identifying undocumented .dat fields | Fields parsed in ItemAsset.Read() that are not documented in the official reference |
| Debugging animation events | Method signatures that animation event callbacks must match |
| Understanding server-client authority | Which operations are server-authoritative and which are client-predictive |
| Identifying API extension points | Methods marked virtual that a derived class could override |
None of these purposes require the modder to recompile the decompiled output or to redistribute it. The value is in reading and understanding — not in reusing the code.
Copyright protection of compiled assemblies
A compiled assembly is protected by copyright. Copyright in software attaches to original creative expression — in the case of software, the original expression in the source code. When that source code is compiled, the resulting binary is a derivative work of the source and receives the same copyright protection.
Smartly Dressed Games retains copyright in Assembly-CSharp.dll. A modder who copies, distributes, or reproduces substantial portions of the decompiled output is copying protected expression and may be infringing that copyright.
The copyright analysis has two components:
The act of decompilation itself — loading the DLL into a decompiler and viewing the output — is a form of copying because the decompiler must load the file into memory and transform it. Whether this act infringes copyright depends on whether a legal exception applies.
The use of the decompiled output — taking the reconstructed code and incorporating it into a mod, redistributing it, or publishing it — is a more direct form of copying and is more clearly within the scope of copyright protection.
The DMCA § 1201 anti-circumvention provision and its interoperability exception
The Digital Millennium Copyright Act, enacted in 1998, includes provisions that prohibit circumventing technological protection measures (TPMs) used to control access to copyrighted works (17 U.S.C. § 1201). These provisions were intended to prevent bypassing copy protection, encryption, and access controls on software and media.
Section 1201(f) — the interoperability exception — carves out a significant space for reverse engineering. It provides that a person may circumvent a technological protection measure for the purpose of enabling interoperability of an independently created computer program with the protected program, provided:
- The person lawfully obtained the program (purchased a legitimate copy of Unturned™ through Steam).
- The circumvention is necessary to achieve interoperability of an independently created computer program.
- The information obtained is used only to enable interoperability of the independently created program.
- The information is not made available to third parties except as necessary to enable interoperability.
What "interoperability" means in the modding context
A mod for Unturned™ is an independently created program that must interoperate with Unturned's runtime. Understanding the API surface of UseableGun, ItemGunAsset, PlayerInput, and related classes is directly necessary to create code that interoperates with those classes. Decompilation to understand that API surface falls within the interoperability exception's scope — the goal is to create compatible code, not to copy the original.
What the interoperability exception permits
Under 17 U.S.C. § 1201(f), a modder who has lawfully purchased Unturned™ on Steam may:
- Load
Assembly-CSharp.dllinto dnSpy, dotPeek, or ILSpy for the purpose of understanding the API surface necessary to write compatible mod code. - Study the class hierarchy, method signatures, field names, and execution flow relevant to the mod's intended interoperation point.
- Use the understanding gained from that study to write original, independently authored mod code that calls or extends the Unturned™ API.
- Document findings about the API in original prose documentation (wiki articles, internal notes, mod readme files) provided the documentation does not reproduce substantial portions of the decompiled source verbatim.
What the interoperability exception does not permit
The interoperability exception does not create a general license to copy software. The exception does not permit:
- Redistributing the decompiled source or substantial excerpts of it — in a repository, a forum post, a Discord message, or any other channel.
- Recompiling the decompiled output to produce a modified assembly and distributing that modified assembly.
- Extracting code for use in a mod's own codebase (as opposed to understanding the API to write compatible original code).
- Sharing decompiled source with third parties "except as necessary to enable interoperability" — and a public forum post or repository upload is not necessary to enable interoperability.
The "4th factor" constraint
The most commonly misread constraint in § 1201(f) is the fourth factor: the information obtained from decompilation "shall not be made available to third parties." This means that the raw decompiled output — the reconstructed C# code — may not be shared publicly or with other modders, even if the decompilation was lawful under the interoperability exception. The exception's purpose is to enable the decompiler to write compatible code, not to create a de facto source release.
SDG's documented stance on modder decompilation
Smartly Dressed Games and Nelson Sexton have communicated a documented tolerance for modders examining the Unturned™ assembly for the purpose of mod development. This tolerance is rooted in SDG's consistent stance that Unturned™ is a mod-friendly title and that the modding community's technical understanding of the game engine is a legitimate and valued activity.
Nelson Sexton has stated in public modding community forums and communications that he supports modders who need to inspect the assembly to understand how the game's systems work. This is consistent with the broadly held developer norm in the Unity modding community, where inspecting compiled assemblies to understand API surface is common practice for modding support.
However, SDG's tolerance comes with constraints that are consistent with the legal framework above:
- The assembly may be inspected for the purpose of understanding how to write compatible mods.
- Decompiled source is not to be publicly redistributed.
- Recompiling the assembly to produce a modified version of the game's runtime is not permitted.
- The modder's use must be for mod development, not for creating competing products or extracting game content for other purposes.
No substitute for reading the official docs first
The Smartly Dressed Games modding documentation at docs.smartlydressedgames.com documents a substantial portion of the API surface relevant to modding, including the .dat field specifications for items, vehicles, barricades, and structures. Decompilation is a resource of last resort — the first step should always be the official documentation. The official docs are more accurate (they reflect the intended behavior, whereas decompiled output reflects the compiled behavior, which may include compiler artifacts), more stable across versions, and unambiguously within the permitted use space.
The decompilation tools: dnSpy, dotPeek, and ILSpy
Three decompilation tools are in common use in the Unity modding community:
| Tool | Developer | License | Primary strength |
|---|---|---|---|
| dnSpy | dnSpy project (now maintained by community fork) | GPLv3 | Integrated debugger — can attach to running Unity process for live inspection |
| ILSpy | ICSharpCode | MIT | Clean, actively maintained; strong .NET 6+ support |
| dotPeek | JetBrains | Proprietary (free for personal use) | Deep integration with JetBrains toolchain; good for C# project navigation |
All three tools are legitimate decompilers maintained by reputable development communities. Using them to inspect Assembly-CSharp.dll for the purpose of understanding the Unturned™ API surface is within the scope of the DMCA § 1201(f) interoperability exception, subject to the constraints described above.
The practical decompilation workflow for a modder:
- Locate
Assembly-CSharp.dllin the Unturned™ install directory. On a default Steam Windows install, the path is<Steam>\steamapps\common\Unturned\Unturned_Data\Managed\Assembly-CSharp.dll. - Open the tool of choice (dnSpy, ILSpy, or dotPeek).
- Open or load
Assembly-CSharp.dllin the tool. - Navigate to the relevant class using the assembly browser (e.g.,
SDG.Unturned.UseableGun,SDG.Unturned.ItemGunAsset). - Read the decompiled output. Take notes in your own words. Do not copy-paste code into shared documents or repositories.
- Write original mod code that interoperates with the API surface you have understood.
- Close the decompiler when the research session is complete. Do not retain decompiled source in project repositories.
Session hygiene: do not commit decompiled output
A common accidental violation of the 57 Studios™ decompilation policy is committing decompiled code to a project repository. Modders who take notes during a decompilation session and accidentally paste decompiled excerpts into a file that is later committed to a shared repository are creating a distribution of decompiled source. Keep decompilation sessions and their notes separate from project files that enter version control.
What you can legally do with decompiled output
The following activities are within the permitted scope under the DMCA § 1201(f) interoperability exception and SDG's documented tolerance:
| Activity | Permissible? | Notes |
|---|---|---|
| Load Assembly-CSharp.dll into dnSpy/ILSpy/dotPeek and read the output | Yes | Core interoperability research activity |
| Study class hierarchy, field names, method signatures for a specific API surface | Yes | Purpose must be writing compatible mod code |
| Take notes about API behavior in your own words | Yes | Original prose documentation of findings |
| Write original mod code that calls or extends the understood API | Yes | This is the end goal of interoperability research |
| Document API findings in a wiki article in original prose | Yes | As long as you do not reproduce decompiled code verbatim |
| Share a text description of a method's behavior with another modder | Yes | "The OnFireStart animation event expects no parameters" is a factual description, not a code reproduction |
| Use decompiled output to understand why a bug occurs | Yes | Debugging aid — still must not redistribute |
| Create an alternative implementation of a method that achieves the same effect | Yes | This is the essence of "independently created program" — write your own code |
What you cannot legally do with decompiled output
| Activity | Permissible? | Notes |
|---|---|---|
| Publish decompiled source code in a forum, GitHub repository, or Discord server | No | Violates DMCA § 1201(f)(4) — not to be made available to third parties |
| Recompile and redistribute a modified Assembly-CSharp.dll | No | Distribution of modified copyrighted work; outside exception scope |
| Copy decompiled method bodies into your mod's codebase and redistribute | No | Direct copyright infringement of the compiled expression |
| Post screenshots of decompiled code in public forums | No | A screenshot of decompiled code is distributing decompiled code |
| Include decompiled excerpts in a public tutorial | No | Public availability violates the fourth factor of § 1201(f) |
| Use decompiled output to create a competing game or tool outside the mod context | No | Outside interoperability exception scope |
The 57 Studios convention on decompilation
57 Studios™ modders are permitted to use decompilation tools for API research within the framework described above. The 57 Studios™ decompilation convention establishes the following binding practices for all contributors to 57 Studios™ commercial and non-commercial mod projects:
Convention: permitted use
Decompilation is permitted as a research tool when:
- The modder has a legitimate, specific technical question about Unturned's API that is not answered by the official SDG documentation.
- The goal is to write original mod code that interoperates correctly with Unturned's runtime.
- The session produces notes in the modder's own words, not verbatim decompiled code.
Convention: prohibited outputs
Regardless of whether the decompilation was conducted lawfully, the following outputs are prohibited under the 57 Studios™ convention:
- Publishing decompiled code in any 57 Studios™ repository, Discord server, forum, or publicly accessible document.
- Including decompiled code in a pull request, commit, or code review.
- Sharing decompiled excerpts in any communication channel where third parties have access — including private Discord channels with more than two participants.
- Attributing mod code to decompiled source ("I wrote this by reverse engineering the original method") in any public communication.
Convention: documentation of research
When a modder's research via decompilation produces findings that benefit the 57 Studios™ team, those findings should be documented in original prose in the internal wiki or in comments within original mod code. The documentation should describe what the modder learned, in the modder's own words, without reproducing decompiled code.
Example of permissible documentation:
Inspected UseableGun.fire() to understand the sequence. The game first reads firemodeIndex to determine the current firemode, then calls into the projectile spawn logic at MuzzleFlash.position, then applies recoil via PlayerLook. The animation trigger is fired before the projectile spawns — this means a very short fire animation will complete before the muzzle flash visual is visible if spawn is delayed.
Example of prohibited documentation:
Here is the decompiled fire() method:
[decompiled code excerpt]
The software-interoperability case law context
The legal framework for software reverse engineering has been shaped by a series of court decisions that predate the DMCA and that the DMCA's interoperability exception was partially designed to codify:
| Case | Holding | Relevance to modding |
|---|---|---|
| Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992) | Disassembly of Sega's console software to achieve interoperability was fair use under copyright law | Established that disassembly/decompilation for interoperability can be fair use |
| Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000) | Reverse engineering of PlayStation BIOS to create an emulator was fair use because the goal was interoperability | Supported Sega; transformative purpose matters |
| Bateman v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996) | Disassembly of firmware for interoperability was fair use | Further reinforced interoperability doctrine |
| Oracle America, Inc. v. Google, Inc., 141 S. Ct. 1183 (2021) | Copying of Java API declarations for reimplementation was fair use | Strongest recent support for the principle that using an API surface to create compatible software is protected |
These decisions collectively support the proposition that decompilation of a commercial application for the purpose of achieving interoperability — which is what a modder writing compatible mod code is doing — is within the space of permissible conduct under copyright law. The DMCA § 1201(f) interoperability exception codifies this principle in the anti-circumvention context.
Oracle v. Google (2021)
The Supreme Court's 2021 decision in Oracle v. Google is the most significant recent copyright decision affecting software interoperability. The Court held that Google's copying of the Java SE API declarations — the method names, parameter types, and return types that form the "declaring code" of the API — for the purpose of creating an independently implemented compatible system was fair use. The decision strongly supports the proposition that studying and using an existing program's API surface to write compatible code is protected activity.
DRM and obfuscation considerations
Some Unity games ship their assemblies with additional protection layers: IL code obfuscation (using tools like Obfuscar, ConfuserEx, or Eazfuscator) or code encryption. Unturned™ ships without significant obfuscation of its primary gameplay assembly — Assembly-CSharp.dll is readable without additional circumvention beyond the decompilation step itself.
If a future version of Unturned™ ships with obfuscated or encrypted assemblies, the legal analysis changes:
- Obfuscation that scrambles names and control flow but does not encrypt the bytecode is generally not a "technological protection measure" under DMCA § 1201, because it does not control access to the work — it merely makes the work harder to read.
- Encryption that prevents the decompiler from loading the assembly at all is more likely to constitute a TPM. Circumventing it would require affirmative reliance on § 1201(f).
As of the publication date of this article, Unturned™ does not employ bytecode encryption. The standard decompilation workflow with dnSpy, ILSpy, or dotPeek functions without additional circumvention steps.
Jurisdiction notes
The DMCA § 1201 analysis described in this article is US law. Equivalent legal frameworks exist in other jurisdictions:
| Jurisdiction | Relevant statute | Notes |
|---|---|---|
| European Union | Directive 2009/24/EC on legal protection of computer programs, Article 6 | Permits decompilation necessary to achieve interoperability; constraints similar to DMCA § 1201(f) |
| United Kingdom | Copyright, Designs and Patents Act 1988, s. 50B | Permits decompilation for interoperability; not to be used for other purposes |
| Canada | Copyright Act, s. 30.61 | Permits reproduction for interoperability of computer programs |
| Australia | Copyright Act 1968, s. 47D | Permits reproduction for interoperability purposes |
In each jurisdiction, the core constraint is the same as in US law: decompilation is permitted for the purpose of achieving interoperability of an independently created program, but the information obtained may not be redistributed beyond what is necessary for that purpose.
Modders based outside the United States should consult their own jurisdiction's law, but the international consensus around software interoperability exceptions is broadly consistent with the US framework described here.
Frequently asked questions
Is it legal to use dnSpy, ILSpy, or dotPeek to open Assembly-CSharp.dll?
Under the DMCA § 1201(f) interoperability exception, a modder who has lawfully purchased Unturned™ on Steam may decompile Assembly-CSharp.dll for the purpose of understanding the API surface necessary to write compatible mod code. The act of opening the file in a decompiler and reading the output is within the scope of that exception. It is not permitted to redistribute the decompiled output.
What is the practical difference between "studying" decompiled code and "using" it?
Studying decompiled code means reading it to understand how the API works — which parameters does a method accept, what fields does an asset class expose, in what order does execution proceed. Using decompiled code means copying it into your mod's codebase. The former is protected by the interoperability exception. The latter is copyright infringement. The line is whether original code you authored appears in your mod, or whether copied code from the decompiled output appears.
Can I post a screenshot of decompiled code in the 57 Studios Discord to ask a question?
No. A screenshot of decompiled code is a reproduction of decompiled code. Posting it to a Discord server with multiple participants constitutes making the decompiled source available to third parties, which is outside the scope of the interoperability exception and outside the 57 Studios™ convention. Describe the behavior in your own words instead: "the method accepts two float parameters and I'm not sure what the second one controls — the field name was stripped."
Has Nelson Sexton (SDG) said anything publicly about decompilation for modding?
Nelson Sexton has communicated via community forums and modding discussions that he supports modders examining the assembly for mod development purposes. SDG's overall stance on modding is expansive — Unturned™ is designed as a moddable title and SDG invests in modding documentation and API exposure. However, SDG's tolerance does not override the legal constraints on redistribution of decompiled source. SDG's position is consistent with: decompile to learn, don't redistribute what you learned as code.
If I find an undocumented .dat field by decompiling, can I publish the field name and description in a wiki article?
Yes. Documenting a field name and its behavioral description in original prose is not reproducing decompiled code. "The field Ballistic_Steps is read in ItemGunAsset.Read() as a uint8 and controls the number of trajectory simulation steps per projectile" is a factual description of an API field. Publishing that description in a wiki article is original documentation of API behavior — precisely what the interoperability exception is designed to enable. Do not include the actual decompiled code that reads the field.
Can I share a decompilation finding privately with one other modder on my team?
DMCA § 1201(f)(4) permits information obtained from decompilation to be shared "with others" only "as necessary to enable such interoperability." A private communication with a co-author of the same mod, directly relevant to the mod's development, is closer to the permissible end of that spectrum than a public post. However, the safest practice is to document the finding in original prose and share the documentation rather than sharing decompiled excerpts.
What should I do if I accidentally committed decompiled code to a repository?
Remove it immediately with a force-push or a history-rewrite (e.g., git filter-branch or BFG Repo-Cleaner) to remove the commit from history. Notify the 57 Studios™ project lead. The fact that the commit was accidental does not eliminate the legal exposure — the code was made publicly available during the period the commit was in the repository's history.
Is it legal to use the decompiled source of a method as the basis for an identical reimplementation?
No. Writing a method that is identical to or substantially similar to a decompiled method — even if you type it character by character rather than pasting — constitutes copying protected expression. The interoperability exception permits using your understanding of the API to write independently authored compatible code, not to reproduce the original implementation. An independently authored implementation would look structurally different from the original, even if it produces the same behavioral output.
Does the DMCA anti-circumvention analysis change if Steam DRM is involved?
Steam's DRM (Steamworks, DRM wrapper) controls access to the game executable through license verification but does not encrypt the game's Unity assemblies post-launch. Once Unturned™ is installed and running under a valid Steam license, the assembly files are present on disk in an unencrypted state. The DMCA § 1201 analysis for the assembly decompilation is therefore not complicated by Steam DRM — the decompiler accesses the already-accessible file rather than circumventing an access control. If SDG were to add assembly-level encryption requiring circumvention to access, the § 1201(f) exception would still apply to that circumvention, subject to its constraints.
What happens if 57 Studios receives a DMCA notice related to decompilation?
57 Studios™ will immediately comply with any valid DMCA takedown notice. Decompiled code will be removed from any 57 Studios™ repository, website, or distribution channel. 57 Studios™ will cooperate fully with SDG in any investigation of how decompiled content came to be published. Contributors who published decompiled content in violation of the 57 Studios™ convention may be removed from the contributor team.
Are the decompilation tools themselves legal to use and distribute?
Yes. dnSpy, ILSpy, and dotPeek are legal tools with legitimate uses in software development (debugging, interoperability research, legacy code recovery). The tools are not themselves illegal; the question is how they are used and what is done with their output. Using them to decompile software for which you have no authorization is illegal. Using them to decompile software you have lawfully purchased, for the purpose of interoperability research, under the constraints of § 1201(f), is lawful.
Does this analysis change if I am modding a game other than Unturned?
The legal framework (DMCA § 1201, copyright fair use, the case law) applies to .NET game assemblies generally — not specifically to Unturned™. However, each game developer's documented stance on modder decompilation may differ from SDG's. Before applying this analysis to another game's assembly, verify whether that game's developer has a documented position on modder decompilation and whether the game employs assembly protection that would complicate the § 1201(f) analysis.
What is the 57 Studios policy if a team member decompiles SDG's code for a non-modding purpose?
The 57 Studios™ decompilation convention is scoped to modding research for Unturned™ mod development. Decompiling SDG's code for any other purpose — competitive analysis, feature extraction, creating a competing game — is outside the scope of the convention and outside the scope of the DMCA § 1201(f) interoperability exception. 57 Studios™ prohibits such use.
Appendix A: US statutory text excerpts relevant to modder decompilation
17 U.S.C. § 1201(f) — Reverse engineering
The following is an excerpt from the relevant statutory provisions:
(f) Reverse Engineering. (1) Notwithstanding the provisions of subsection (a)(1)(A), a person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs, and that have not previously been readily available to the person engaging in the circumvention, to the extent any such acts of identification and analysis do not constitute infringement under this title.
(4) For purposes of this subsection, the term "interoperability" means the ability of computer programs to exchange information, and of such programs mutually to use the information which has been exchanged.
The full statutory text is available at the US Government Publishing Office (govinfo.gov).
Subsection (a)(1)(A) vs. (a)(1)(B)
Note that § 1201(f)(1) references "subsection (a)(1)(A)" — the access-control provision. The interoperability exception applies specifically to circumventing access controls, not to circumventing copy controls (§ 1201(a)(1)(B)). This distinction is relevant only if SDG employs encryption that separates access control from copy control — which Unturned™ currently does not.
17 U.S.C. § 107 — Fair use (copyright)
The fair use doctrine remains available as a defense to copyright infringement claims arising from decompilation, independent of the DMCA § 1201(f) exception. The four factors:
- Purpose and character of the use, including whether commercial or nonprofit educational
- Nature of the copyrighted work
- Amount and substantiality of the portion used
- Effect of the use upon the potential market for the copyrighted work
Decompilation for interoperability research (non-commercial, for the purpose of writing compatible code, using only what is necessary to understand the API, with no market effect on SDG's sales) would score favorably on all four factors. This provides a parallel copyright defense to the DMCA § 1201(f) exception.
Appendix B: 57 Studios decompilation compliance checklist
Before and after each decompilation research session, a 57 Studios™ contributor should verify:
| Checkpoint | Confirmed? |
|---|---|
| I have a lawfully purchased copy of Unturned™ via Steam | — |
| I have checked the official SDG documentation first and it does not answer my question | — |
| My goal is specifically to understand the API surface for writing compatible mod code | — |
| My notes are in my own words, not verbatim decompiled code | — |
| No decompiled code appears in any project file, repository commit, or shared document | — |
| No decompiled code has been posted to Discord, forums, or any other channel | — |
| My mod code is independently authored, not copied from decompiled output | — |
| I am not using decompilation for any purpose other than Unturned™ mod development | — |
Appendix C: External resources
- Unturned on Steam — the official Steam listing for Unturned™.
- Smartly Dressed Games Modding Documentation — the official SDG modding documentation; always check here before decompiling.
- US Copyright Office — DMCA — official US Copyright Office DMCA resource.
- EU Directive 2009/24/EC — the European software protection directive including the interoperability exception.
Decompilation and the modding ecosystem: a broader perspective
Decompilation is not unique to Unturned™ or to game modding. It is a standard practice in software interoperability research, security auditing, bug reporting, and legacy system recovery. The legal framework described in this article reflects decades of court decisions, legislative action, and industry practice that have collectively established decompilation for interoperability as a legitimate and protected activity.
What makes the modding context specific is the relationship between the modder and the game developer. Unlike a security researcher who may have an adversarial relationship with a software vendor, most Unturned™ modders are part of a community that SDG has actively cultivated and supported. Nelson Sexton has expanded the modding API over time in response to modder feedback, publishes documentation specifically for modders, and has a documented history of being accessible to the modding community. This relationship does not change the legal analysis — legal rights exist independently of the parties' relationship — but it does mean that modders who operate within the community's established norms are working in a context of mutual respect rather than adversarial tension.
The 57 Studios™ decompilation convention is designed to honor that relationship. Decompilation for genuine API research, producing original mod code, with no redistribution of decompiled source, is entirely consistent with SDG's documented expectations for the modding community.
Version differences and assembly evolution
Unturned™ receives regular updates, and those updates change the compiled assembly. A modder who conducts decompilation research against one version of Assembly-CSharp.dll may find that the same class or method behaves differently in a later version. The following practices reduce the impact of version-specific decompilation findings:
| Practice | Rationale |
|---|---|
| Note the game version against which each research session is conducted | Allows the team to re-verify findings when the game updates |
| Prefer documented API over decompiled findings | Official documentation reflects intended behavior across versions; decompiled output may reflect version-specific implementation details |
| Test mod behavior after every game update | Behavioral changes in the assembly can break mods that relied on undocumented behaviors |
| Do not hardcode values extracted from decompilation | Values (e.g., internal constants) may change across versions; prefer .dat fields where the documented API provides them |
| Track SDG's changelog and release notes | SDG publishes notes on API changes relevant to modding; these notes are the authoritative source on what changed |
Assembly changes between game versions
When Unturned™ updates and Assembly-CSharp.dll changes, any decompilation findings from the previous version should be treated as potentially stale. Field names may be renamed, method signatures may change, and behavioral sequences may be reordered. The official SDG documentation is updated more consistently for documented API changes than for internal implementation changes.
The relationship between decompilation and assembly modding frameworks
The broader Unity modding community uses runtime patching frameworks such as BepInEx and HarmonyX (a successor to Harmony) to apply patches to compiled assemblies at runtime. These frameworks allow modders to intercept method calls, prefix or postfix method execution, and alter return values without recompiling or redistributing the original assembly. Unturned™ modding does not primarily use these frameworks — Unturned™ has a documented modding API that handles item, vehicle, and map content — but understanding them is useful context for the decompilation discussion.
Harmony and HarmonyX patching
Harmony-style patching works by identifying target methods in the compiled assembly (using their fully-qualified names) and injecting delegate calls at the prefix (before the method runs), postfix (after the method runs), or transpiler (modifying the IL instructions themselves) positions. A modder who uses Harmony-style patching needs to know the full name of the method to patch — which decompilation can provide.
| Patching approach | What decompilation provides | Legal considerations |
|---|---|---|
| Prefix/postfix patching | Target method's fully-qualified name, parameter types | Understanding the API signature is within interoperability exception scope |
| Transpiler patching | Internal IL structure of the method | More invasive; transpilers that reproduce substantial IL structure may raise copyright questions |
| Replacement patching | Complete method substitution | Modder's replacement must be original; cannot be derived from decompiled source |
SDG's position on runtime patching
SDG has not, as of this article's publication, documented an official position on runtime patching of Unturned™ specifically. Modders who use runtime patching frameworks for Unturned™ should treat the decompilation-for-interoperability analysis as applicable, and should consult SDG's community guidelines for any additional constraints.
Plugin development and server-side mods
Unturned™ has a plugin API that allows server-side code to be loaded at runtime (through Rocket or OpenMod plugin frameworks). These plugins are independently compiled assemblies that interact with the Unturned™ runtime through its public API. Plugin development is a primary use case for decompilation research — a plugin developer needs to understand the Unturned™ API surface to write compatible plugin code, and that API surface is often more detailed than the official documentation covers.
The decompilation convention applies to plugin development in the same way it applies to content mod development: decompile to understand the API, write original plugin code, do not redistribute decompiled source.
Metadata and the PDB question
Program Database (PDB) files are debug symbol files that provide the mapping between compiled binary code and source code — including original variable names, method names, and line numbers. Applications compiled with debug symbols and published with PDB files are substantially more readable when decompiled because the symbols restore original naming.
SDG does not publish PDB files for Unturned™'s assemblies. This means decompiled output uses SDG's original method and field names (which are preserved in the assembly's metadata) but uses compiler-generated placeholder names for local variables. This is the expected state for a release build without symbols.
The absence of PDB files does not change the legal analysis — the DMCA § 1201(f) exception does not distinguish between symbol-available and symbol-absent decompilation. But it does mean that decompiled Unturned™ output is more readable for method signatures (because method names are in the assembly metadata) than for method internals (because local variable names are stripped).
Assembly identification: what files to inspect
The Unturned™ install directory contains multiple managed assemblies. A modder conducting API research should understand which files contain which content:
| Assembly file | Contents | Relevance to modding |
|---|---|---|
Assembly-CSharp.dll | SDG's primary gameplay code — the main target for API research | Primary decompilation target |
Assembly-CSharp-firstpass.dll | Pre-compiled Unity plugins and SDG utilities | Occasionally relevant for specific API surfaces |
UnityEngine.dll and siblings | Unity engine runtime — well-documented separately | Check Unity docs before decompiling |
Newtonsoft.Json.dll | JSON serialization library — open source | Check official Newtonsoft docs |
SDG.NetPak.dll | SDG's network packing library | Relevant for understanding network replication |
Modders should focus decompilation research on Assembly-CSharp.dll and the SDG-specific assemblies. Unity engine assemblies and third-party library assemblies have their own documentation and licensing terms, and decompilation research on them may produce findings that have no direct application to Unturned™ modding.
Unity has extensive public documentation
Unity's C# scripting API — including MonoBehaviour, Transform, Animator, AudioSource, and all other built-in Unity components — is publicly documented at the Unity documentation site. Decompiling Unity engine assemblies is unnecessary for understanding Unity's API; the official documentation is more accurate and more stable. Decompilation research should be reserved for SDG's own code.
The 57 Studios internal documentation standard for decompilation findings
When a 57 Studios™ contributor conducts a decompilation research session that produces findings relevant to the broader team, those findings must be documented according to the following standard before they are shared internally:
Standard format for documented findings
DECOMPILATION FINDING
Date: [date of research session]
Game version: [Unturned version at time of research]
Researcher: [contributor name or handle]
Question: [the specific question the research was intended to answer]
Finding: [description of the finding in original prose — no decompiled code]
API surface: [the class.method or class.field that the finding relates to, by name only]
Confidence: [High / Medium / Low — based on how clearly the decompiled output answered the question]
Follow-up: [whether official documentation should be checked against this finding after the next game update]This standard ensures that findings are:
- Attributed and dated (so they can be re-verified when the game updates)
- Described in original prose (compliant with the no-redistribution rule)
- Scope-limited (the finding is about a specific API surface, not a general dump of decompiled content)
- Marked with confidence level (so future readers assess the finding appropriately)
Documented findings in this format are stored in the 57 Studios™ internal team wiki and are not published externally.
Responding to a request to share decompiled code
57 Studios™ contributors will occasionally receive requests from community members, other modders, or technical forums asking them to share decompiled source from Unturned™. The following response framework applies to all such requests:
| Request type | Appropriate response |
|---|---|
| "Can you share the decompiled UseableGun code?" | Decline. Explain that redistributing decompiled source is outside the DMCA § 1201(f) exception's scope. Offer to describe the relevant API surface in original prose. |
| "Can you post a screenshot of what ILSpy shows for ItemGunAsset?" | Decline. A screenshot is a reproduction of decompiled code. Describe the field names and types in plain text instead. |
| "Can you tell me what parameters OnFireStart expects?" | This is a request for an API description, not decompiled code. Describe the method signature in original prose: "OnFireStart takes no parameters" or "the animation event expects a float parameter representing elapsed time." |
| "Can you share your notes from reverse engineering the caliber system?" | Share only original-prose notes that describe the behavior without reproducing decompiled code. |
Helping the community within legal limits
Declining to share decompiled code does not mean declining to help other modders. Describing API behavior in original prose, pointing to official documentation, and sharing working mod code that demonstrates API compatibility are all permissible and valuable contributions to the modding community.
Copyright ownership and moral rights
Copyright in Assembly-CSharp.dll belongs to Smartly Dressed Games. This is straightforward in the US, where copyright in a commercial software product belongs to the legal entity that published it. However, individual contributors to the codebase may have moral rights claims in jurisdictions that recognize such rights (EU member states, Canada, and others).
Moral rights — the right of attribution and the right of integrity — are generally not assignable and cannot be waived in most EU jurisdictions. For modding purposes, moral rights are largely irrelevant because the interoperability exception applies at the copyright ownership level, not at the moral rights level. A decompilation conducted for interoperability research does not violate a programmer's moral right of integrity; it is not modifying the work, only reading it.
This is primarily relevant for modders who are themselves software developers and who are concerned about the interaction between their own code and the copyright framework. For the standard modding use case, moral rights analysis does not change the practical conclusions.
Practical timeline: what to do when you hit an undocumented API surface
The following workflow represents the 57 Studios™ recommended process for a modder who encounters an API surface not covered in the official documentation:
Step 1: Exhaust the official documentation (time: 30–60 minutes)
Check the Smartly Dressed Games documentation at docs.smartlydressedgames.com for the specific API surface in question. Check the item, vehicle, barricade, structure, and event documentation sections. If the documentation mentions the behavior but is unclear, try multiple searches using different terminology before concluding that the documentation does not cover the question.
Step 2: Check community knowledge (time: 30–60 minutes)
Search the SDG modding forums, the official SDG Discord, and community wikis for the specific behavior. Experienced modders in the community may have already encountered and documented the same API surface without needing to decompile. Community knowledge is often more current than official documentation for recently added API features.
Step 3: Conduct a targeted decompilation session (time: 30–120 minutes)
If the official documentation and community knowledge do not answer the question, open Assembly-CSharp.dll in ILSpy, dnSpy, or dotPeek. Navigate directly to the specific class and method relevant to the question. Read the decompiled output for that specific surface. Take notes in original prose. Do not read beyond what is necessary to answer the specific question — broad exploration of decompiled code creates more exposure than targeted reading.
Step 4: Document the finding (time: 10–20 minutes)
Create a finding record in the format described in the 57 Studios™ documentation standard section of this article. Include the game version, the specific API surface, the finding in original prose, and a confidence rating. Store the finding in the internal team wiki.
Step 5: Write original mod code (time: varies)
Write the original mod code that uses the API surface you have now understood. Ensure that the code is independently authored and does not incorporate decompiled logic — only the understanding gained from reading the decompilation output.
Step 6: Verify behavioral consistency across game updates (time: 15 minutes per update)
After each Unturned™ game update, verify that mod behaviors that relied on decompilation-derived API understanding still function correctly. If a behavior has changed, conduct a new targeted decompilation session for the updated assembly.
Understanding the SDG modding API as a legal boundary
The SDG modding documentation defines the set of API surfaces that SDG has explicitly chosen to expose for mod use. When SDG documents a method, field, or event in the official documentation, they are implicitly communicating that this surface is intended to be stable across versions, accessible to modders, and supported. When something is not documented, it is either undocumented for practical reasons (the documentation team has not gotten to it yet) or intentionally not exposed (SDG prefers that modders not rely on it).
The interoperability exception under DMCA § 1201(f) is specifically scoped to "identifying and analyzing those elements of the program that are necessary to achieve interoperability." This language implies that the necessity of decompilation decreases as the official documentation becomes more comprehensive. Decompiling to answer questions that the documentation already answers is not necessary and therefore not within the cleanest interpretation of the exception.
This is a nuanced point that does not significantly affect practical risk in the typical modding context, but it does reinforce the importance of checking official documentation first. Decompilation is the last-resort research method, not the first.
SDG's expanding documentation
Smartly Dressed Games has progressively expanded the official modding documentation over the history of Unturned™. API surfaces that were undocumented in early versions are now documented in the current reference. Modders who encounter undocumented behavior should submit documentation requests or questions to SDG's official modding channels — improving the documentation benefits the entire community and reduces the need for decompilation research.
The 57 Studios convention applied to external contributions
57 Studios™ occasionally collaborates with external modders and receives contributions from community members. The decompilation convention applies to all contributions, whether from core team members or external contributors:
| Contributor type | Convention applies? | Enforcement mechanism |
|---|---|---|
| Core 57 Studios team member | Yes — full convention | Internal team policy |
| External collaborator on a specific mod pack | Yes — must acknowledge convention in contribution agreement | Contribution agreement |
| Community contributor via pull request | Yes — PR review will reject decompiled code | Code review process |
| External modder who references 57 Studios documentation | No — they are not a 57 Studios contributor | Cannot enforce externally |
External collaborators who contribute to 57 Studios™ commercial mod projects are required to acknowledge the decompilation convention in a brief written contribution agreement. The agreement documents:
- The contributor has read and understood the convention.
- The contributor's contribution does not contain decompiled code from Unturned™ or any other copyrighted software.
- The contributor's code is original work or properly licensed third-party code.
This agreement protects 57 Studios™ from liability arising from a contributor's decompilation activity that 57 Studios™ did not authorize or know about.
Source-available and open-source projects in the Unity ecosystem
A parallel consideration for modders who draw on the broader Unity modding ecosystem: some modding frameworks and libraries in the Unity space are distributed as source-available or open-source projects. The licensing terms for these projects vary substantially, and a modder who incorporates code from these projects into a commercial mod must comply with those license terms.
Common open-source licenses encountered in Unity modding tools:
| License | Attribution required? | Commercial use permitted? | Modification permitted? | Share-alike required? |
|---|---|---|---|---|
| MIT | Yes — include license text | Yes | Yes | No |
| GPLv3 | Yes | Yes, but derived works must be GPLv3 | Yes | Yes — GPLv3 copyleft |
| Apache 2.0 | Yes — include notice | Yes | Yes | No |
| LGPLv3 | Yes | Yes | Yes | Limited — library linkage |
| BSD 2-Clause | Yes — include license text | Yes | Yes | No |
| Proprietary (free for personal use) | Check license | Often no | Check license | N/A |
The GPLv3 "copyleft" requirement is the most consequential for commercial modders: if a modder's plugin or mod incorporates GPLv3-licensed code, the derivative work may be required to be distributed under GPLv3 as well, which means making the source code available. Commercial mod packs built on GPLv3 frameworks should have this reviewed by an attorney before publication.
BepInEx and HarmonyX licensing
BepInEx is distributed under the LGPLv3, and HarmonyX is distributed under the MIT license. If a modder's Unturned™ plugin builds on BepInEx or HarmonyX, they should review the respective licenses before commercial distribution. LGPLv3 generally permits using the library without triggering copyleft requirements for the containing application, but the analysis depends on how the library is integrated.
The distinction between clean-room implementation and decompilation-derived implementation
A clean-room implementation is a software implementation that achieves compatibility with an existing system without using the existing system's source code or decompiled output in the new implementation. The classic example is IBM PC-compatible BIOS implementations created by companies who had their engineers reverse-engineer the observable behavior of the IBM BIOS (without reading IBM's source code) and then had a separate team implement a compatible BIOS from the behavioral specification.
Clean-room implementation is the gold standard for interoperability: it achieves compatibility through observation and behavioral documentation rather than through decompilation. For Unturned™ modding, a clean-room approach would mean:
- Observing the game's behavior through play and testing.
- Documenting the observed behavior in specifications.
- Writing mod code that produces the specified compatible behavior.
In practice, clean-room implementation is rarely necessary for game modding because the interoperability exception under DMCA § 1201(f) already permits decompilation for interoperability research. Clean-room implementation is primarily relevant when a developer wants to create a legally impeccable reimplementation — for example, when the target of the reimplementation is a system with aggressive IP enforcement posture and the interoperability exception's constraints are too narrow.
For 57 Studios™ modding, the practical approach is simpler: use the interoperability exception for API research, write original code, do not distribute decompiled source. Clean-room formalism is not required.
Future developments: AI-assisted decompilation
Decompilation tools have begun incorporating AI-assisted code analysis that produces more readable and contextually meaningful decompiled output. Tools that use machine learning to predict original variable names (based on naming conventions common in the relevant framework), infer code intent from control flow, and generate explanatory comments are becoming increasingly capable.
The legal analysis for AI-assisted decompilation follows the same framework as standard decompilation: the output is still derived from the copyrighted original, and the same constraints on redistribution apply. The fact that the output is more readable does not change its legal status. The interoperability exception applies equally to AI-enhanced decompilation output as to standard decompilation output, and the prohibition on redistribution applies equally.
The "clean" output problem with AI decompilers
AI-assisted decompilers may produce output that looks more like original source code and less like machine-generated reconstruction. A modder who incorporates AI-decompiled code into their mod may be less aware that they are incorporating decompiled code, because it no longer looks like placeholder-variable reconstruction. The 57 Studios™ convention applies to AI-decompiled output equally — if the code you are copying into your mod came from a decompiler, it is decompiled code regardless of how clean it looks.
Summary: the decompilation decision framework
The following summarizes the complete decision framework for a 57 Studios™ modder facing an API research question:
| Question | Answer | Next step |
|---|---|---|
| Is the behavior documented in SDG's official docs? | Yes | Use the documented API |
| Is the behavior described in community forums or wikis? | Yes | Use the community knowledge, verify against docs |
| Is decompilation necessary for interoperability? | Yes — no other source answers the question | Proceed with targeted decompilation session |
| Have I purchased Unturned™ lawfully via Steam? | Must be yes | Verify before proceeding |
| Am I reading only what is necessary to answer my specific question? | Must be yes | Limit scope to the specific class/method |
| Will I take notes in original prose? | Must be yes | No verbatim code in notes |
| Will any decompiled code appear in any distributed output? | Must be no | Review all files before commit/publish |
| Will I document the finding with version and confidence? | Must be yes | Create finding record in team wiki |
| Will I write original code based on my understanding? | Must be yes | No code copying from decompiled output |
This framework produces a conservative posture that keeps 57 Studios™ contributors within the clear safe harbor of the DMCA § 1201(f) interoperability exception while still enabling the API research that effective mod development sometimes requires.
Frequently asked questions — extended set
Does the interoperability exception apply if I use decompilation to understand game balance values rather than API structure?
The DMCA § 1201(f) exception is specifically scoped to "identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program." Decompiling to understand how the API is structured — which methods to call, which parameters to pass — is within this scope. Decompiling to extract balance values (damage numbers, range parameters, spread values) that could be replicated in a .dat file without decompilation is a closer question. The safer approach: use observable in-game testing to derive balance values rather than reading them from decompiled constants.
Can I use decompiled understanding to write a modding tutorial for other modders?
Writing a tutorial that explains how Unturned's systems work, based on your understanding gained through decompilation, is generally permissible — provided the tutorial expresses that understanding in original prose and does not reproduce decompiled code. A tutorial that says "UseableGun processes fire input by checking the current firemode index and then invoking projectile spawn at MuzzleFlash.position" describes behavior. A tutorial that includes decompiled code alongside that description is reproducing protected expression.
What if I decompile Assembly-CSharp.dll and find a security vulnerability? Can I disclose it?
Security vulnerability disclosure is a specific context with its own legal norms, separate from interoperability research. Responsible disclosure — reporting a security vulnerability privately to SDG before public disclosure — is the community standard for game security research. The DMCA § 1201(f) exception may not cleanly cover security research (the exception is about interoperability, not security). A modder who finds a security vulnerability through decompilation should report it to SDG privately and allow a reasonable period for remediation before any public disclosure. SDG's community has a direct communication channel with Nelson Sexton, which makes responsible disclosure practical.
Does modifying and redistributing a custom version of a modding framework count as decompilation?
A modding framework like OpenMod or a custom plugin loader that modders distribute as a modified fork of an existing open-source project is governed by the license of the original project — not by the DMCA decompilation exception. If the original framework is MIT-licensed, the modder can redistribute a modified version under MIT terms. If the original is GPLv3-licensed, the modder must release the modified version under GPLv3. This is a license compliance question, not a decompilation question.
What happens to decompilation-derived knowledge when a modder leaves the 57 Studios team?
Decompilation-derived knowledge that a modder carries in their head — their understanding of how the Unturned™ API works — does not become prohibited when they leave the team. Knowledge in a person's head is not "made available to third parties" in the sense of the DMCA § 1201(f)(4) constraint. However, any documentation of decompilation findings that was created during the modder's time on the team should be treated as 57 Studios™ internal documentation and not taken or redistributed when the modder departs.
Is it ever acceptable to share a small snippet of decompiled code for a very specific technical question?
The DMCA § 1201(f)(4) prohibition on making decompiled information available to third parties does not have a "small amount" exception. Sharing a small snippet of decompiled code publicly — even a single method body — is making decompiled information available to third parties. The 57 Studios™ convention is that no decompiled code, regardless of size, is shared publicly. Describe the behavior in original prose instead.
Can automated tools scan our mod repositories for accidentally committed decompiled code?
Yes. Code pattern matching tools can be configured to detect CIL-like patterns or characteristic decompiler output (e.g., specific placeholder naming patterns, characteristic IL instruction sequences in reconstructed code). 57 Studios™ can add a pre-commit hook that scans for characteristic decompiler output patterns as a quality control measure. This is not currently implemented in all 57 Studios™ projects but is a recommended practice for repositories with multiple contributors.
What is the legal status of using Unturned's own modding tools that load and read the assembly?
SDG's own modding tools — the Unity editor integration, the asset export tools, and related SDK components — may internally read the Unturned™ assembly to provide modding support. Using SDG's official tools for their intended modding purpose is clearly within the scope of the modding license that SDG grants to all Workshop participants. This is distinct from using third-party decompilers for API research, which is governed by the DMCA interoperability exception. Using official SDG tools is the safest legal posture for any modding activity.
Cross-references
- Trademark and Brand in Mods — the previous article; trademark interaction with mod content.
- How to Install Unturned Mods — the next article; mod installation workflow.
- Gun Mod Tutorial — the primary authoring guide that uses the API knowledge decompilation research informs.
- Steam Workshop Submission — publishing workflow and community content policies.
- Server Configuration — server-side plugin development context.
Document history
| Version | Date | Author | Notes |
|---|---|---|---|
| 1.0 | 2025-05-18 | 57 Studios | Initial publication. DMCA § 1201(f), SDG stance, 57 Studios decompilation convention. |