{
  "id": 11603190,
  "title": "What Obfuscation Breaks: Reflection, Serialization, and What to Exclude",
  "url": "https://urgent.news/2026/10/03/what-obfuscation-breaks-reflection-serialization-and-what-to-exclude",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-03T04:55:54.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/zero_heartbeat_06a3625d7a/what-obfuscation-breaks-reflection-serialization-and-what-to-exclude-2i13"
  },
  "original_language": "en",
  "account": "When you inject an obfuscator into a .NET application, it can cause previously working components to break. For instance, the JSON returned by an API might have fields named \"a\" and \"b\" instead of their original names. Calls to methods using reflection, such as Type.GetMethod(\"Process\"), may return null if the method name has been changed to something like \"a\". WPF or XAML bindings that rely on property names, such as {Binding CustomerName}, may also fail to bind correctly if the property name is renamed. Additionally, Dependency Injection may not find services if they are mapped by name instead of by interface.\n\nThe core issue behind these problems is that names are the weakest link in obfuscation. Renaming a member at runtime still refers to it by its original name, which no longer exists in the assembly. Any runtime code that tries to retrieve a member based on its name will fail if the name has been obfuscated.\n\nSerialization, reflection, data binding, and convention-based frameworks like Dependency Injection, Entity Framework Core, AutoMapper, and MVC model binding are all examples of code paths that rely on name resolution. When names are renamed, these components break, leading to failures in serialization, deserialization, reflection, data binding, and framework functionality.\n\nTo mitigate these issues, it is essential to exclude from renaming only the specific names that are resolved by string at runtime. These include serialized types (such as DTOs, settings files, message payloads), members reached through reflection, types and members referenced from XAML or other markup, and the public API surface of libraries that other assemblies compile against. This can be achieved using attributes or configuration rules to mark these types and members to be excluded from renaming.\n\nAnother approach is to decouple the wire names from the code names, so that serialization formats remain unchanged even if the member names are renamed. For example, explicitly specifying the JSON property names using attributes like [JsonPropertyName(\"total\")] allows the serialized JSON to use the correct names regardless of the member names in the IL.\n\nThe most crucial point is that exclusion from renaming does not mean the code is unprotected. Obfuscation can still apply to other transformations, such as control-flow flattening, encryption of string literals, and masking of constants. Exclusions are purely name-level, not protection-level.\n\nA reliable workflow involves obfuscating the code first and then running the complete test suite against the obfuscated build, not just the un-obfuscated version. Integration tests that serialize DTOs, hit APIs, or exercise plugins will immediately expose any issues caused by name resolution breakage. By fixing each failure by excluding the specific contract or pinning the wire names, rather than disabling renaming altogether, obfuscation becomes a one-time setup step rather than a recurring mystery, keeping the logic hard to read while preserving the integrity of the names your program depends on.",
  "summary": "You add an obfuscator to a working .NET app, build, run — and something that worked yesterday is broken. The JSON your API returns has fields named a and b . A Type.GetMethod(\"Process\") call returns null . Your WPF window binds to nothing. Dependency injection can''t find a service. None of this is a bug in the obfuscator; it is the single most common obfuscation mistake, and it always has the…",
  "key_points": [
    "Obfuscation breaks reflection calls, returning null for renamed methods.",
    "Serialization, data binding, and DI fail when names are renamed at runtime.",
    "Exclude only names resolved by string at runtime to preserve program integrity."
  ],
  "editors_take": "Excluding specific names from renaming during obfuscation allows developers to preserve critical functionality in components that rely on name resolution, such as serialization and reflection, without compromising code protection.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}