Hi guys/girls,

I have an exe that has been written in C# using visual studio

Is there a was I can de-compile it back into the C# code - It seems to be some what protected

exe files I've created myself using Visual Studio and C# I can see the code when I "Disassemble" using Reflector

However all i seem to get is things like this when I de-compile the exe I want to:

There is a lot of [DebuggerNonUserCode] within it and I'm not sure what that is

// Fields
    private  ;
    private  ;
    private DataRelation ;
    private SchemaSerializationMode ;

    // Methods
    public  ();
    public  ();
    [DebuggerNonUserCode]
    private bool ();
    public DataRelationCollection ();
    public DataTableCollection ();
    [DebuggerNonUserCode]
    internal void ();
    [DebuggerNonUserCode]
    internal void (bool );

When I "Disassemble" my exe I get real code like this:

private void cmdFind_Click(object sender, EventArgs e)
{
    this.lblMatch.Visible = false;
    this.lblNoMore.Visible = false;
    try
    {
        if (this.txtSearch.Text == "")
        {
            this.lblMatch.Visible = true;
        }
        else
        {

you get the point


I'm not trying to pirate anything or anything like that because I know something like that will go through someones head haha

All I'm trying to do is get a look at the code so I can see how it works before I start working


Any help would be appreciated

Thanks

Dani AI

Generated

As suggested, the symptoms you showed - lots of [DebuggerNonUserCode] plus blank or garbled member names - point strongly at an obfuscator or mangled metadata, not a normal compile. The attribute itself is harmless and commonly applied to designer-generated code (typed DataSets, WinForms/WCF generated classes) so its presence alone is not a problem; the red flag is the missing or unreadable identifiers and the decompiler failing to emit clear types and names.

Quick, practical diagnosis and next steps:

  • Confirm the EXE is still managed IL: open it in a metadata/PE viewer or a .NET decompiler (ILDASM, ILSpy, dnSpy, dotPeek). If there is a CLR header and method IL, it is managed; if not, it may be native or packed and C# decompilation will fail.
  • Inspect the manifest and resources in the decompiler. Widespread unreadable names, nonprintable characters, or odd attributes usually means a renaming obfuscator was used.
  • If it is only renamed, try a deobfuscation pass (tools like de4dot exist) then re-open in a decompiler; that often restores readable identifiers.
  • If you see string encryption, control-flow obfuscation or a VM/virtualized method, expect significant manual reconstruction: follow call graphs, rename by behavior, and reimplement critical routines rather than recovering everything verbatim.
  • If the assembly is signed, packed, or native-wrapped, you may need the original signing key or to unpack the embedded managed assembly first.
  • If you have legit rights, ask the vendor for unobfuscated symbols or source — that is usually the fastest, cleanest way.

Final notes: focus on public APIs and data flow if your goal is understanding behavior rather than perfect recovery. Also respect licensing and IP: only reverse engineer when you have permission. For , start by loading the EXE into dnSpy or ILSpy and checking the manifest and method bodies; that single check will tell you whether you have a realistic path to C# source or you are dealing with advanced protection.

It looks like they ran it through an obfuscator so you can't easily decompile it to get the source code. You can still get the source code, but you'll have to read what was decompiled, figure out what it is doing and substitute your own variable names/procedure names into the code. Not fun, easy or fast :)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.