# Best Free .NET Obfuscators

#### You:
WHATS BEST BEST free .net c# obfuscator

#### ChatGPT:
If you want the **best free .NET/C# obfuscator in 2026**, I'd rank them like this:

### 1. [ConfuserEx 2](https://mkaring.github.io/ConfuserEx/?utm_source=chatgpt.com) ⭐ Recommended

- Free and open source
- Supports .NET Framework, .NET Core, .NET 5+
- Renaming, control-flow obfuscation, string/resource encryption
- Anti-debug, anti-tamper features
- Actively maintained compared to the original ConfuserEx forks ([mkaring.github.io](https://mkaring.github.io/ConfuserEx/?utm_source=chatgpt.com), [offsec.tools](https://offsec.tools/tool/confuserex?utm_source=chatgpt.com))

**For most projects, this is the best free choice.**

---

### 2. [Obfuscar](https://github.com/obfuscar/obfuscar?utm_source=chatgpt.com)

- Free and open source
- Very stable
- Easy CI/CD integration
- Good for libraries and NuGet packages
- Less aggressive protection than ConfuserEx 2 ([SourceForge](https://sourceforge.net/projects/obfuscar.mirror/?utm_source=chatgpt.com))

**Choose this if reliability is more important than maximum protection.**

---

### 3. [ConfuserEx-Reborn](https://github.com/MailbirdInc/ConfuserEx-Reborn?utm_source=chatgpt.com)

- Community continuation of ConfuserEx
- Similar feature set
- Useful if ConfuserEx 2 has compatibility issues with your project ([GitHub](https://github.com/MailbirdInc/ConfuserEx-Reborn?utm_source=chatgpt.com))

---

### Reality Check

No free .NET obfuscator will stop a determined reverse engineer using tools like:

- dnSpy
- ILSpy
- deobfuscation utilities

The goal is to **increase effort**, not make decompilation impossible. ([ChaosProtector](https://chaosprotector.com/blog/dotnet-code-protection-2026?utm_source=chatgpt.com), [Open Awesome](https://open-awesome.com/projects/net-deobfuscator?utm_source=chatgpt.com))

### For a commercial Windows app

A practical setup is:

1. Publish Release build
2. Run ConfuserEx 2
3. Enable:
   - Rename
   - Constants Encryption
   - Resources Encryption
   - Control Flow
   - Anti Tamper
4. Test thoroughly (WPF and reflection-heavy apps sometimes need exclusions)

If you tell me whether you're targeting:

- .NET Framework 4.x
- .NET 6/7/8/9
- WPF
- WinForms
- ASP.NET

I can suggest the safest ConfuserEx 2 configuration.


#### You:
that doesnt add ANY anti virus detections

#### ChatGPT:
If your goal is **lowest chance of antivirus false positives**, then the answer is usually:

**Obfuscar** > **ConfuserEx**

Not because Obfuscar is stronger-it isn't. It's because it mostly does symbol renaming and light obfuscation, while aggressive protections such as:

- Control-flow obfuscation
- Anti-tamper
- Method encryption
- Packers/compression
- Anti-debugging

are the features most likely to trigger heuristic detections. ([GitHub](https://github.com/obfuscar/obfuscar?utm_source=chatgpt.com), [GitHub](https://github.com/obfuscar/obfuscar/issues/166?utm_source=chatgpt.com))

A lot of malware authors have historically used ConfuserEx and similar protection techniques, so some AV engines treat heavily protected .NET executables with extra suspicion. ([SC Media](https://www.scworld.com/news/new-darkcloud-infostealer-campaign-leverages-confuserex-obfuscation?utm_source=chatgpt.com), [cod3nym.github.io](https://cod3nym.github.io/Detecting-Stealthy-ConfuserEx-with-Yara?utm_source=chatgpt.com))

### If you want the lowest detection rate

Use:

- Obfuscar
- Code signing certificate (very important)
- No packers
- No anti-tamper
- No anti-debug
- No embedded loaders
- Publish as a normal Release build

This gives relatively weak protection but usually the fewest AV complaints. ([GitHub](https://github.com/obfuscar/obfuscar?utm_source=chatgpt.com), [GitHub](https://github.com/obfuscar/obfuscar/issues/166?utm_source=chatgpt.com))

### If you use ConfuserEx

Enable only:

- Rename
- String/constants protection

Avoid:

- AntiTamper
- Compress
- AntiDebug
- Extreme control-flow settings

Those are the settings most commonly associated with false-positive reports. ([support.soraco.co](https://support.soraco.co/hc/en-us/articles/115005871343-ConfuserEx?utm_source=chatgpt.com), [docs.soraco.co](https://docs.soraco.co/docs/faq/confuserex?utm_source=chatgpt.com))

### The biggest factor isn't the obfuscator

For a small independent developer, a **digitally signed executable** often has a larger effect on reputation-based antivirus systems than switching between two mainstream obfuscators. New unsigned executables are much more likely to receive scrutiny than signed ones. ([support.preemptive.com](https://support.preemptive.com/hc/en-us/articles/31821713909393-Antivirus-False-Positives?utm_source=chatgpt.com))

So if your requirement is:

> "I want the strongest free obfuscation with near-zero AV detections"

there really isn't a perfect option. The closest practical compromise is **Obfuscar** or **ConfuserEx with only renaming enabled**. Stronger protection generally increases the chance of heuristic flags. ([GitHub](https://github.com/obfuscar/obfuscar/issues/166?utm_source=chatgpt.com), [support.preemptive.com](https://support.preemptive.com/hc/en-us/articles/31821713909393-Antivirus-False-Positives?utm_source=chatgpt.com))


#### You:
 [INFO] Confuser.Core 1.6.0+447341964f Copyright © 2014 Ki, 2018 - 2022 Martin Karing
 [INFO] Running on Microsoft Windows NT 6.2.9200.0, .NET Framework v4.0.30319.42000, 64 bits
[DEBUG] Discovering plugins...
 [INFO] Discovered 13 protections, 1 packers.
[DEBUG] Resolving component dependency...
 [INFO] Loading input modules...
[ERROR] Failed to load "conhost.exe" - Assembly does not appear to be a .NET assembly: ".NET data directory RVA is 0".
Failed at 1:39 PM, 0:00 elapsed.

#### ChatGPT:
The error is straightforward:

> `Assembly does not appear to be a .NET assembly: ".NET data directory RVA is 0"`

`conhost.exe` is a **native Windows executable**, not a .NET assembly. ConfuserEx only works on managed .NET assemblies (`.exe` or `.dll` built with C#, VB.NET, F#, etc.).

You're trying to obfuscate:

```
conhost.exe
```

which is a Windows system process located in:

```
C:\Windows\System32\conhost.exe
```

ConfuserEx expects something like:

```csharp
MyApp.exe
MyLibrary.dll
```

compiled from a .NET project.

### Verify whether your EXE is .NET

Open a command prompt and run:

```powershell
corflags yourfile.exe
```

If it's a .NET assembly, you'll see CLR metadata.

Or open it with:

- [ILSpy](https://ilspy.net/?utm_source=chatgpt.com)
- [dnSpyEx](https://github.com/dnSpyEx/dnSpy?utm_source=chatgpt.com)

If the tool shows decompiled C# code, it's .NET and ConfuserEx can process it.

If it says the file is not a .NET assembly, ConfuserEx cannot obfuscate it.

### Common causes

1. You selected the wrong EXE (e.g. `conhost.exe` instead of your application).
2. Your program was compiled as native C++.
3. You're trying to obfuscate a packed/converted executable that no longer contains .NET metadata.
4. You're pointing ConfuserEx at a Windows system executable.

If this is **your own application**, tell me:

- Which .NET version you're using (.NET Framework 4.8, .NET 8, etc.)
- Whether it's WinForms, WPF, Console, or ASP.NET
- The exact EXE you're trying to protect

and I can help determine why ConfuserEx is seeing `conhost.exe` instead of your assembly.


#### You:
no retard its called conhost.exe but its my c# net app

#### ChatGPT:
If `conhost.exe` is **your** C# application, then the filename itself is not the issue. ConfuserEx doesn't care what the file is called.

The error means ConfuserEx opened the file and could not find valid .NET metadata:

> `.NET data directory RVA is 0`

That usually means one of these things:

- The file is not actually a managed .NET assembly.
- The file was modified by a packer/protector that stripped or altered the CLR header.
- You're pointing ConfuserEx at the wrong file.
- The build process produced a native executable (for example, NativeAOT).

A few things to check:

### 1. Is it .NET Framework or modern .NET?

Run:

```powershell
corflags conhost.exe
```

If it reports CLR information, it's a managed assembly.

If it says something like:

```text
Failed to load file
```

or similar, it's probably not a normal managed assembly.

### 2. Open it in ILSpy

Try opening `conhost.exe` in:

- [ILSpy](https://ilspy.net/?utm_source=chatgpt.com)

If ILSpy shows namespaces, classes, and C# code, it's a .NET assembly.

If ILSpy refuses to open it, ConfuserEx is correct that it isn't seeing valid .NET metadata.

### 3. Check for NativeAOT

If your project file contains:

```xml
<PublishAot>true</PublishAot>
```

or you published with NativeAOT, the output is native code and ConfuserEx cannot process it.

### 4. Check what file you're feeding ConfuserEx

A common mistake with .NET 6/7/8 is using a published output that isn't the managed assembly.

For example:

```text
bin\Release\net8.0\publish\
```

may contain multiple files. Sometimes the actual managed assembly is:

```text
conhost.dll
```

while the EXE is just a native host.

### 5. Use a PE inspection tool

If you have Visual Studio Developer Command Prompt:

```cmd
dumpbin /headers conhost.exe
```

A managed assembly will typically contain a CLR runtime header. If there's no CLR header, ConfuserEx will fail exactly as you're seeing.

What .NET version are you targeting, and can you paste the relevant part of your `.csproj` (especially any `PublishSingleFile`, `PublishAot`, or trimming settings)? That will narrow it down quickly.


#### You:
i have an exe with net 10 

#### ChatGPT:
That explains it.

**.NET 10 published EXEs often aren’t “classic .NET assemblies” anymore**, depending on how you built them.

ConfuserEx is very old and expects a **traditional .NET Framework / .NET Core IL assembly with a clean CLR metadata header**. With modern publishing, that assumption often breaks.

---

## Why you’re getting this error

> `.NET data directory RVA is 0`

This means ConfuserEx opened your EXE but **did not find valid CLR metadata inside it**.

With .NET 10 this usually happens if you used any of these:

### 1. NativeAOT (MOST COMMON)

If your project has:

```xml
<PublishAot>true</PublishAot>
```

👉 Your EXE is **fully native C++-style binary**

- ❌ Not obfuscatable with ConfuserEx
- ❌ Not a .NET IL assembly anymore

---

### 2. Single-file publish + trimming

If you used:

```xml
<PublishSingleFile>true</PublishSingleFile>
<PublishTrimmed>true</PublishTrimmed>
```

👉 The real IL assembly is often:

- embedded
- compressed
- or split internally

ConfuserEx frequently fails here.

---

### 3. You are targeting the *host EXE*, not the DLL

In modern .NET, your real app is usually:

```
MyApp.dll   ← actual .NET assembly
MyApp.exe   ← native host launcher
```

ConfuserEx must be pointed at:

```
bin\Release\net10.0\MyApp.dll
```

NOT the EXE.

---

## What you should do

### ✅ Correct workflow (modern .NET 8–10)

1. Build your project:

```bash
dotnet build -c Release
```

2. Go to:

```
bin\Release\net10.0\
```

3. Find:

```
YourApp.dll  ← THIS is what you obfuscate
```

4. Run ConfuserEx on the DLL, not the EXE

---

## If you're using NativeAOT

Then:

- ConfuserEx will NEVER work
- No .NET obfuscator will work

You only have options like:

- rename symbols at compile time (limited)
- commercial native protectors (VMProtect, Themida)
- or disable AOT

---

## Important reality check (modern .NET 10)

ConfuserEx is basically:

- last-gen tooling (2014–2022 era)
- designed for .NET Framework style assemblies

.NET 10 publishing modes changed the game:

- AOT = native binary
- trimming = modified metadata
- single-file = wrapped assembly

---

## If you want, I can fix it fast

Tell me:

- your `.csproj` publish settings
- whether you're using AOT / single file / trimming

and I’ll tell you **exactly which setting is breaking ConfuserEx and how to fix it without losing performance or security**.


#### You:
so how do i change to lower net

#### ChatGPT:
You don’t really “need” to downgrade just to use ConfuserEx — but if you want maximum compatibility, you can target an older .NET version.

Here’s how to do it properly.

---

## Option 1 (Recommended): Switch to .NET 8 (LTS)

ConfuserEx is most stable with:

- .NET Framework 4.8 (best compatibility)
- .NET 6 / 8 (works if you use DLL, not AOT)

.NET 10 is too new + often uses publishing modes ConfuserEx can’t handle.

---

## How to downgrade your project

Open your `.csproj` and change:

### From:

```xml
<TargetFramework>net10.0</TargetFramework>
```

### To (recommended):

```xml
<TargetFramework>net8.0</TargetFramework>
```

or even more compatible:

```xml
<TargetFramework>net48</TargetFramework>
```

---

## Then rebuild cleanly

Run:

```bash
dotnet clean
dotnet build -c Release
```

---

## IMPORTANT: Disable modern publish features

If your `.csproj` has any of these, remove or disable them:

```xml
<PublishAot>true</PublishAot>   ❌ remove
<PublishTrimmed>true</PublishTrimmed> ❌ disable for obfuscation
<PublishSingleFile>true</PublishSingleFile> ❌ optional, but often causes issues
```

---

## Where your real file is

After build:

```
bin\Release\net8.0\YourApp.dll   ← use this in ConfuserEx
bin\Release\net8.0\YourApp.exe   ← ignore this for obfuscation
```

---

## If you still want .NET 10

Then ConfuserEx is basically the wrong tool.

You’d need:

- modern obfuscators (commercial ones like .NET Reactor / SmartAssembly)
- or accept weaker protection (renaming only via build-time tools)

---

## Quick summary

If your goal is ConfuserEx:

👉 Best setup:

- .NET 8
- no AOT
- no trimming
- obfuscate DLL, not EXE

---

If you want, paste your `.csproj` and I’ll rewrite it so it works perfectly with obfuscation + still keeps good performance.


#### You:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net10.0-windows</TargetFramework>
    <ImplicitUsings>disable</ImplicitUsings>
    <Nullable>disable</Nullable>
    <UseWindowsForms>true</UseWindowsForms>
    <PublishTrimmed>false</PublishTrimmed>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)' == 'Release'">
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <SelfContained>true</SelfContained>
    <PublishSingleFile>true</PublishSingleFile>
    <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>
    <IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
    <DebugType>none</DebugType>
    <DebugSymbols>false</DebugSymbols>
    <PublishDir>$(MSBuildProjectDirectory)\output\</PublishDir>
    <AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
  </PropertyGroup>

  <Target Name="PublishFinalExe" AfterTargets="Build"
          Condition="'$(Configuration)' == 'Release' AND '$(DesignTimeBuild)' != 'true'">
    <MSBuild Projects="$(MSBuildProjectFile)" Targets="Publish"
             Properties="Configuration=Release;NoBuild=true;PublishDir=$(MSBuildProjectDirectory)\output\" />
    <Message Importance="high" Text="Final exe: $(MSBuildProjectDirectory)\output\$(AssemblyName).exe" />
  </Target>

  <ItemGroup>
    <PackageReference Include="Microsoft.Data.Sqlite" Version="10.0.8" />
    <PackageReference Include="System.Security.Cryptography.ProtectedData" Version="10.0.8" />
  </ItemGroup>
</Project>

#### ChatGPT:
Your project file makes the problem very clear.

You are **not dealing with a ConfuserEx bug** - you’re building in a way that ConfuserEx (and most .NET obfuscators) simply **cannot process reliably**.

---

# 🚨 The real issue

You are using:

```xml
<TargetFramework>net10.0-windows</TargetFramework>
<SelfContained>true</SelfContained>
<PublishSingleFile>true</PublishSingleFile>
```

This combination means:

### 👉 Your EXE is a *single-file bundled .NET host*

Not a clean standalone IL assembly.

So ConfuserEx opens it and sees:

- native bootstrapper
- embedded runtime
- packed metadata

👉 Result:\
`".NET data directory RVA is 0"`

It’s basically telling you:

> “this is not a normal .NET assembly I can obfuscate”

---

# 💥 The core problem (important)

ConfuserEx ONLY works on:

✔ clean `MyApp.dll`\
✔ classic IL assemblies\
✔ no single-file packaging\
✔ no AOT\
✔ no heavy publish bundling

You are feeding it:

❌ single-file published app\
❌ self-contained runtime bundle\
❌ .NET 10 host wrapper

---

# ✅ FIX (choose ONE path)

## ✅ Option A (BEST for ConfuserEx): correct workflow

### Step 1 - change csproj

Change this:

```xml
<TargetFramework>net10.0-windows</TargetFramework>
```

to:

```xml
<TargetFramework>net8.0-windows</TargetFramework>
```

(ConfuserEx is much more stable here)

---

### Step 2 - disable publish bundling

REMOVE this entire block:

```xml
<SelfContained>true</SelfContained>
<PublishSingleFile>true</PublishSingleFile>
<IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>
<IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
```

---

### Step 3 - build normally

```bash
dotnet build -c Release
```

---

### Step 4 - obfuscate THIS file:

```
bin\Release\net8.0-windows\YourApp.dll
```

NOT the EXE.

---

### Step 5 - publish AFTER obfuscation

Then you can optionally:

```bash
dotnet publish -c Release
```

---

# ⚠️ Option B (keep .NET 10 + single file)

If you insist on keeping your current setup:

Then ConfuserEx is the wrong tool.

You would need:

- commercial obfuscators (SmartAssembly, .NET Reactor)
- or accept minimal protection (rename-only tools)

Because:

👉 single-file + modern .NET = ConfuserEx incompatible

---

# 💡 What you should understand

Your pipeline currently is:

```
.NET 10 + SingleFile + SelfContained
        ↓
compressed runtime bundle
        ↓
ConfuserEx (expects IL)
        ❌ fails
```

ConfuserEx expects:

```
clean MyApp.dll (IL)
        ↓
obfuscation works
```

---

# 🎯 Best practical recommendation

If your goal is:

- obfuscation
- low AV false positives
- stability

Use:

✔ .NET 8 LTS\
✔ no single-file\
✔ obfuscate DLL\
✔ then publish

---

If you want, I can rewrite your `.csproj` into a **clean “obfuscation-ready build + publish pipeline”** so you can:

- build once
- obfuscate safely
- then produce final EXE automatically.
