Previously we have “upgraded” the .NET framework of an EXE by modifying/creating the <EXE name>.config file
<supportedRuntime version=”v4.0″/>
As per here: http://msdn.microsoft.com/en-us/library/w4atty68(v=vs.110).aspx
Now we will cover an alternative method. This technique is easy with a simple executable that only loads in-built .NET libraries. If the EXE loads 3rd party DLLs compiled to an older .NET framework the process may become complicated.
First we dump our IL code with ILDasm, included with Visual Studio:
Default dump options are OK.
In this case we have a .NET 2.0 app, so in the .assembly extern sections we replace .ver 2:0:0:0 with .ver 4:0:0:0 and leave other versioned DLLs alone.
We then compile the IL file:
C:\Windows\Microsoft.NET\Framework\v4.0.30319>ilasm <path to filename>
OK exe is now running .NET v4.0 version. We can see this with Process Explorer:
What about .NET v4.5?
To do that we need to perform the above changes, but also insert within the assembly definition
.assembly <name of assembly>
{
}
The following line:
.custom instance void [mscorlib]System.Runtime.Versioning.TargetFrameworkAttribute::.ctor(string) = ( 01 00 1A 2E 4E 45 54 46 72 61 6D 65 77 6F 72 6B // ....NETFramework 2C 56 65 72 73 69 6F 6E 3D 76 34 2E 35 01 00 54 // ,Version=v4.5..T 0E 14 46 72 61 6D 65 77 6F 72 6B 44 69 73 70 6C // ..FrameworkDispl 61 79 4E 61 6D 65 12 2E 4E 45 54 20 46 72 61 6D // ayName..NET Fram 65 77 6F 72 6B 20 34 2E 35 )
OK what about a .NET 1.1 app?
Like the Delphi 8 Borland Pascal .NET Compiler:
This takes me to site:
But only has downloads for .NET 3.5 and later…
Examining EXE we can see it is not a MSIL based executable, but instead uses CorBindToRuntimeEx (http://msdn.microsoft.com/en-us/library/99sz37yh(v=vs.110).aspx) to load the .NET runtime.
From the documentation we can see a string is passed with .NET version to load. Using a Hex editor (A good one for Windows here: http://hexedit.com/ Just be careful you download the actual program not the ADware )
In this case upgrading to v4.0.30319 is problematic as the string is longer than the original, and is challenging to insert longer string into binary. However luckily for us immediately following the version text is the “wks” value, which is also passed into the function. Our patching job is made much easier due to the fact A NULL value for this parameter will default to wks.
Leaving our patched bytes looking like this:
I also search for a UNICODE version of same string, and also update it, finishing with double 00 at end of string.
chentiangemalc 