November 2, 2011

Remotesoft Protector Runtime Error – yet to handle multiple .NET framework runtime

Filed under: Development — Tags: , , — Darrin Maidlow @ 9:07 pm

Remotesoft protector is one of the out there.  In fact, its pretty much the only one that really works.  Since I moved to .NET 4.0 I’ve been getting an annoying error when attempting to protect my binaries using the 4.0 suite of tools (with the ).  Everything still runs – it just pops up nasty alert boxes on load which is no good :)

Remotesoft Protector Runtime Error – yet to handle multiple .NET framework runtime

One other symptom of this was that .exe files would just blow chunks.  I’ve finally figured out what was causing this!  Most of our products are protected during the nightly builds.  This error however is specific to assemblies protected using the the Remotesoft .NET Explorer UI.  When using this application for the protect or obfuscate functionality it is really just a front end around the protector.exe/obfuscator.exe.  The UI is building the following command line string and tonight it finally dawned on me:Remotesoft .NET Explorer

Command: C:\Program Files (x86)\Remotesoft\Protector\bin\protector.exe -neutral -resource -string -cctor -clrversion v2.0.50727 "C:\temp\SmartInk for Kahua\SmartInk.UI.exe"

The UI was forcing the clr version to .NET 2.0 – when my assemblies are all built against .NET 4.0.  Oops…

After a bit of digging I found that you can set the CLR version in .NET Explorer from the Action / CLR Version menu item.  Unfortunately it has not been updated to support .NET 4.0 – and so has been rendered pretty much useless as a front end for protector.

The Fix

The only solution is to use the command line to execute your protection.   The updated command line ended up looking pretty similar:

"C:\Program Files (x86)\Remotesoft\Protector\bin\protector.exe" -neutral -resource -string  -clrversion v4.0.30319 "C:\temp\SmartInk for Kahua\SmartInk.UI.exe"

There you have it – I can’t believe I missed that…

November 24, 2008

.NET 3.5 “Attempted to read or write protected memory” Caused by Remotesoft Protector

Filed under: Development — Tags: , — Darrin Maidlow @ 11:25 pm

Months ago, I started getting the “Attempted to read or write protected memory” error.  In hindsight (as always) its all clear.  In short, it seems .NET 3.5 SP1 and v2.x do not play nicely resulting in this error.  Either stop using Protector, or upgrade to the latest version.

In long – for a number of reasons there was not a strait line between upgrading my machine to SP1 and noticing the problem.  This made diagnosing the problem significantly more complicated because I had no idea when it actually started.  At the time, I was dealing with .  This had prompted me to start doing all my dev in an XP virtual machine.  Eventually, the slowless of developing in a VM drove me insane and I just had to get my machine working again.  So I got Oracle dealt with – but that left this annoying error.

It was a complete fluke that I noticed this.  The stars aligned, and I manually compiled some assemblies, instead of pushing the big green button on my build system.  This resulted in my assemblies not being run through the Remotesoft Protector.  All of a sudden the problem went away.  At the time I had been using Protector 2.x which would not support .NET 3.5 SP1 fully. So, either stop using Protector, or upgrade to the latest version which resolves this problem =)

May 30, 2008

Implementing Remotesoft .NET Protector using MSBuild

Filed under: General — Tags: — Darrin Maidlow @ 4:02 pm

RADE has grown significantly in size and complexity over the past four years.  What started off as a relatively simple classic ASP application has grown to 8+ .NET assemblies, with numerous 3rd party DLL references.  Current R&D is going to further increase the size of the build. In addition to that, we’ve developed several vertical products on top of RADE which need to be updated as new revisions of the base framework are completed.

It’s come to the point where I need to get to a one step build.  The first move in here was to implement in my build process as protecting the assemblies ended up being one of the bigger pains in the butt when building.

So to kick things off, we need to work with MSBuild a little bit.  Originally, I tried using the <exec> call from MSBuild.  This didn’t give me the flexibility to loop through the files being generated.  So I started writing a custom build task.  Please read this on building custom tasks if you are new to this.

In summary, I defined a number of get/set methods for the globals I wanted the build engine to set, and in the Execute function I set it up to loop through the passed .DLL files, and execute Protector on each.  After the dlls were processed, they were moved out of the protected folder and the protected folder was removed.  If you are having problems getting your task running, check out this article on .

RADE uses a Visual Studio 2008 to deploy all of the files on build, so to implement the new task we need to do some editing in the project.  Open the project either with a text editor, or in Visual Studio by a right click on the project and choosing "Open Project File".  This part is quite simple.  First ensure that the assembly generated by building your task is in the same folder as the web deployment .wdproj file.  Next we need to add a line near the top of the web deployment project:

   1: <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
   2:     <UsingTask TaskName="Landor.Deploy.BuildTasks.RemoteSoftProtector" AssemblyFile="Landor.Deploy.Buildtasks.dll"/>
   3:     <PropertyGroup>...

Here we point the UsingTask call to both the namespace and class of our protector code, as well assembly.  One more change to make.  Scroll to the end of the project and you should see a number of empty <Target> tags.  We need to add some code to the Name="Afterbuild" tag.

   1: <Target Name="AfterBuild">
   2:         <ItemGroup>
   3:             <DLLFiles Include="$(MSBuildProjectDirectory)\Release\Bin\*.dll"/>
   4:         </ItemGroup>
   5:         <RemoteSoftProtector
   6:             Files="@(DLLFiles)"
   7:             ProtectorEXEPath="C:\Program Files (x86)\Remotesoft\Protector\bin\protector.exe"
   8:             ProtectorParams="-neutral -string -cctor -clrversion v2.0.50727"
   9:             BinFolder="$(MSBuildProjectDirectory)\Release\Bin\"
  10:             Exclusions="AjaxControlToolkit.dll;Microsoft.Xml.Schema.Linq.dll;ZedGraph.Web.dll"
  11:         />
  12: </Target>

 

Two things occur here.  First, in the <Itemgroup> tag we are initializing a variable called DLLFiles, and it’s getting all the .DLL files in the project’s Release\Bin build folder.   Note that this process creates a semi-colon delimited list of full paths and files.

The next thing that occurs is actually calling the build task using the <RemoteSoftProtector> tag.  The tag name should/must match the name of the build tasks’ class.  Within this tag, we are setting all of the defined public properties, using the same name as those defined with our build task class.

This concludes a day of fun learning how MSBuild and custom tasks work.  Hopefully it helps you out a bit.  Bugs or comments, let me know.

Technorati Tags: ,,

Powered by WordPress

Switch to our mobile site