0

I'm developing a WPF application that I deploy with ClickOnce to a network share on the intranet from which clients can install it.

I need to make sure that the user can't modify any of the application files (especially DLLs and the main executable) on their machine. That is, if any of the application files have changed, the application should refuse to run. I was under the impression that, when using ClickOnce, this was available out of the box and that the application would refuse to start if the file hashes didn't match the manifest.

However, I tried to manually replace the executable or a DLL with a slightly different version after installation and the application still ran fine (executing the modified code).

  1. Does ClickOnce provide what I'm looking for?
  2. How can I enable the functionality?

I'm using a level 2 StartSSL code-signing certificate to sign the application manifest if this matters.

P.S.: just to be sure: I'm talking about the installed application files, not the installation files.

Andre Loker
  • 8,368
  • 1
  • 23
  • 36
  • _replace the executable or a DLL with a slightly different version_ How did you sign it? Did you try to replace the primary executeable compiled and signed by a different machine and a different certificate? – Stefan Over Aug 27 '14 at 12:37

2 Answers2

2

I think it will be a fairly manual process.

Doesn't look like the VS2013 deployment tools handle code obfuscation but they do support signing and app permissions. Start with that, then you might have to get the generated manifest as a starting point to build your own with obfuscated assemblies.

MS docs break it into 3 steps: 1. obfuscate, 2. build manifest, 3. manually publish

Here is what MS docs say...

Securing ClickOnce Applications

Deploying Obfuscated Assemblies You might want to obfuscate your application by using Dotfuscator to prevent others from reverse engineering the code. However, assembly obfuscation is not integrated into the Visual Studio IDE or the ClickOnce deployment process. Therefore, you will have to perform the obfuscation outside of the deployment process, perhaps using a post-build step. After you build the project, you would perform the following steps manually, outside of Visual Studio:

  1. Perform the obfuscation by using Dotfuscator.

  2. Use Mage.exe or MageUI.exe to generate the ClickOnce manifests and sign them. For more information, see Mage.exe (Manifest Generation and Editing Tool) and MageUI.exe (Manifest Generation and Editing Tool, Graphical Client).

  3. Manually publish (copy) the files to your deployment source location (Web server, UNC share, or CD-ROM).

IntStarFoo
  • 765
  • 8
  • 14
  • Thanks for your answer. Obfuscation indeed makes it harder to manipulate a part of the application. I was more interested in an approach for the application to detect manipulation, though. But I'll probably add obfuscation as an additional build step before deployment. – Andre Loker Aug 29 '14 at 09:41
  • Ah, yes. You'll also need to Strong Name the assemblies. http://msdn.microsoft.com/en-us/library/xwb8f617.aspx "Assembly B has a guarantee that Assembly A's bits have not been tampered with and that these bits actually come from the developers of Assembly A." – IntStarFoo Aug 29 '14 at 13:30
2

You can sign AND strong name each one of DLLs to prevent tampering but then, doing so has its own pain points when it comes to upgrades and distribution in general. Note that even doing so, doesn't entirely prevent someone from injecting code into your running process. It's a sticky subject.

I recommend going thru this question which already discusses these points in detail. Does code-signing without strong-naming leave your app open to abuse?

Community
  • 1
  • 1
Mrchief
  • 75,126
  • 20
  • 142
  • 189