Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When an exception occurs in a .NET application, the exception output also includes the path and file name of the code file that resided on the developer's machine. This shares some information that is useful in debugging, but also may present a security issue as shown in the following example:

D:\talks is private

In the above image the directory D:\talks comes from the developers machine and not the end user's.

Suppose I have a Visual Studio Solution file that has a PFX file with the password part of the name:

Example:  d:\my secret project\Obscure FOSS project\Signer-PW-Is-test123.pfx

Of course test123 isn't the real pfx password, but what if it was a more sensitive password that was used for other purposes (say domain admin).


Where is this string "Signer-PW-Is-test123.pfx" stored in the .NET DLL or exe?

Is it stored in the OBJ file?

How can I purge this data, or anonymize the information so that I don't leak what's unnecessary but still make it possible for engineers to debug the application.

share|improve this question
Please explain what a "more secret" password is exactly? – Ramhound Jun 22 '12 at 14:59
It should be in EXE and if you have any components done yourself it will be in that DLL. – Andrew Smith Jun 22 '12 at 17:54
You could simply "eat" the exception messages. If you catch all exceptions and handle them silently the unhandled exception dialog is never shown. How is a path on a computer a security concern? – Ramhound Jun 22 '12 at 19:49
It's not just .NET, Visual Studio has always compiled in paths used on the developer machine. I've used it when analysing malware to help determine who was responsible for writing it (or tie up two samples to the same source). – bobince Jun 23 '12 at 10:19

I'm a little confused as to how you have this set up.

What makes you think that file path is stored in either assemblies at all? Are you using that PFX to sign the assemblies? If so, there's a pointer in the assembly attributes.

There is no way to obscure the filename at that level because the compiler needs to know the full path. You could possibly run it through obfuscation software, but that would still likely result in the string being present.

Another option is to make sure you compile in RELEASE so the debug bits aren't added. This will remove the pdb files and remove most of the entries to code file paths.

The only other option really is to compile the thing from a non-sensitive path, e.g.: d:\builds\1, and to remove all sensitive information from the file paths. Simply put: don't store the password in the filename.

share|improve this answer

You need to implement exception handling. For all system and API calls, check the documentation for a list of exceptions the method may throw. Then, properly account for those exceptions and you won't have problems such as these.

share|improve this answer
Well, that doesn't quite solve the problem as the assembly itself will still contain pointers to file paths. – Steve Jun 23 '12 at 0:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.