Hacker News Reader

Comment by junon | Hacker News Reader

I remember when the entirety of your C# binary would include the source code, and back before the concept of Release or Debug was prolific enough, closed source C# binaries would be distributed in Debug mode erroneously, allowing someone to extract pretty much a 1:1 replica of the codebase.

Just a fun anecdote. I don't know if this is the case anymore.

View on HN

You’re probably thinking of debug symbols, i.e. the PDB file that is generated alongside the binary. You can generate this for both Debug and Release builds (should be on by default in fact). It’s super useful for debugging crash dumps from production, and for exception logging in web apps.

You can think of this like a source map, but only files and line numbers.

I don't think it ever included actual source code, but .NET IL is just so rich that it made it extremely trivial to decompile, no?

It indeed did, you could open up the .exe in notepad for example. It was all there.

This doesn't sound right. C# has always been a compiled language (to MSIL), from the earliest versions of .NET.

But that doesn't mean the source code wouldn't necessarily be exuded in a debug build.

I don't know the truth of the original statement, but it isn't too unbelievable.

This does sound unsurprising if you talk about a debug binary. It would allows you to debug it with the original source code. You are not supposed to run debug builds in production. But nothing will prevent you from doing it.

Production binaries of course doesn’t embed any source or debugging symbols.

It’s like erroneously shipping source maps files into your front end production build. It shouldn’t happen and it’s not necessary, but it’s just one configuration variable away so it happens a lot.

Never said the source was used to run the program. It was included for debug builds.

Sorry - I wasn't able to convey my thought. There was no reason for the C# compiler to include the source code into the binary. Into the debugging symbols (which is a separate file) - maybe..?

Anyway, I went ahead and compiled a debug app on .NET 1.1. The binary does not include the source code. And neither does the PDB. It includes a file path to the source though ("Visual Studio Projects\ConsoleApplication1\Class1.cs").

Back then things were different. I'm talking c. 2008.

.NET 1.1 is 2003, should be "back then" enough.

When compiled with VS 2008 and .NET 3.5, the binary does not include the source code either.

You might confuse readable parts in the binary with the metadata.

[0] https://stackoverflow.com/q/65699183

[1] https://stackoverflow.com/q/4700317

Nope. I explicitly remember the source code being there.

The cool thing about being in 2023 is that you don't have to believe me. Winding up a Windows XP virtual machine with Visual Studio of your choice takes 15-20 minutes.

This was likely ASP.NET code. In the early days many folks just FTP'd their whole ASP.NET project folder to IIS, including the source code (e.g. .aspx.cs code behind etc) when you didn't need to. There was a lot of misunderstanding about how to deploy ASP.NET applications, many folks were still working with a Classic ASP mindset. I speak from experience as my company's .NET go to engineer and developer for a shared hosting company back in the day and having to explain to customers how to deploy their apps sans the source code.

No, it wasn't lol. I wish people would stop telling me what I very clearly remember. I did a report on this in high school - how C# programs (desktop programs) could have their source recovered under certain build conditions.

> how C# programs (desktop programs) could have their source recovered under certain build conditions.

Yes, using a tool such as .NET Reflector, but the source was never embedded in the compiled binaries, or anywhere else if you were competent with the toolchain.

> It was included for debug builds.

I've worked with .NET since the pre-1.0 betas back in ~2001 (I know...appeal to authority). The source code was never included in .NET debug or production builds. You could however use tools such as .NET Reflector (now owned by RedGate) to decompile the IL and reconstruct code as C#, VB etc. If you had the PDB files then you also had the symbols and could decompile to a close representation (variable names) to the original source.

This was a very useful feature because the .NET Framework managed code DLL's were and still are shipped obfuscated. This meant you could in the early days use ILDASM, and then .NET Reflector to find out what was going on inside the .NET Framework code.

Of course this created a market for obfuscators so that commercial and paid for shipping code was more difficult to reconstruct (especially since you wouldn't have the PDB files available).

You could do pretty much the same thing with Java.

Now if your binaries were NGEN'd [0], your chances of reverse engineering were reduced considerably because the IL is now gone and you're working with pre-compiled machine code rather than pre-JIT'd IL.

[0]: https://learn.microsoft.com/en-us/dotnet/framework/tools/nge...

At least according to the format and specification since VS 2005, .NET 2.0, the assembly format has been consistent and doesn't have any section for source code.

It has always been trivial to load an assembly in something like dnSpy or another IL Disassembler and generate C# code and patch .NET assemblies. At least in the versions < 5.

https://learn.microsoft.com/en-us/dotnet/standard/assembly/f...

I remember this too. Actually I (maybe incorrectly)think release builds contained it too. You used to have to actively obfuscate to make sure it was protected. I definitely used decompilers and got great results with very readable code that felt very close to the original.

That could be, actually. I don't know if it was release or just debug, but I remember obfuscation tools definitely being a thing, in large part because of this.

MSIL is easily decompiled back to C# (or VB.NET if you prefer), it has always been a thing, yes. But binaries never included the source code.

I am perfectly aware of what IL decompilation is. I've written a decompiler before before. That's not what was happening.

There was never a time when the distinction between Release and Debug was not "prolific".

Yes, there definitely was.

Maybe if you started life as a VB6 developer.

But your original post especially doesn't make sense because the default Debug configuration has always put the debug symbols in a separate PDB file. So even if you were arguing that early C# developers didn't understand how to use their tools, they wouldn't have had the source embedded in the EXE.

I guess I'm lying then. :)

I think you may be miss-remembering.

I can't recall this from C#, though I only started using it when .Net 1.1 was released.

I do recall good old Visual Basic did this though, as it ran interpreted. The executable it generated was just a small loader with the source code appended.

Reply on news.ycombinator.com