DllTest - sample code to call Runtime module in C# using VS 2002 and higher
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This project is written in Visual Studio 2002 but will work in more recent versions of Visual Studio
(they will upgrade the Project to the latest version. If prompted you should also upgrade the .NET
framework the project requires). If you are using .NET Core then please read the notes at the bottom
of this file. If you are using VS 2022 (or higher) then you will receive warnings when compiling this
code - use the VS 2022 project instead.
The main source files in the project are:
File name Description
Form1.cs main source code file for C#
dris.cs contains the DRIS structure and low-level functions to manipulate it.
The best approach is to compile the sample code and see how it works and then to take the appropriate code
and apply it to your own project. You should include the dris.cs file in your project and use/modify which
ever functions from form1.cs you feel are appropriate. The dris.cs file should not be modified.
The sample code contains 11 functions. You will not need to use all these functions in your code. Just use
which ever functions are most appropriate and customise in your own way. The sample code is just a guide.
You should implement the protection in a stronger way using the techniques described in the
"Increasing your Protection" chapter of the manual.
Code marked with !!!! are places where you should customise the sample code so that it will work properly:
* Change the MY_SDSN value to the value of your SDSN
* Change the MY_PRODCODE value to the Product Code in the dongle
* Change the MyAlgorithm code (if you call a user algorithm)
* Change the CryptDRIS code (if you encrypt the DRIS)
* Change the CryptApiData (if you encrypt Data you send to our API)
* Change the MyRWAlgorithm code (if encrypt Data you send to our API using the R/W algorithm)
You will also probably want to replace our error messages with your own. However, you should still
display or log any error codes returned by the protection check otherwise you will not be able to
identify the cause of the error. (You can look up error codes in our knowledge base: microcosm.com/kb).
For users of Visual Studio 2005 or higher, the default setting for projects is to compile for the Target
Platform "Any". This means that on 32-bit Windows, your code will run as 32-bit code (and needs to call
dpwin32.dll) and under 64-bit Windows your code will run as 64-bit code (and needs to call dpwin64.dll).
The sample code works this out automatically. If you select the target platform as "x86" then it will
always be 32-bit and so you only need to use dpwin32.dll. If you select "x64" then your code will be
64-bit and you only need to use dpwin64.dll.
Note - as you are using the API method in this sample you should protect dpwin32.dll and/or dpwin64.dll
and not your program. Because your program is linked to the DLL it is protected. You can also protect
your program with the Shell Method should you wish.
Note - if you are compiling for the Platform target "Any" (and therefore need to protect both dpwin32.dll
and dpwin64.dll) then you will probably want to protect these modules to the same licence so that they share
a common set of protection parameters.
Make sure you remember to do the following:
1) Insert the following namespaces in your code file:
using System.Runtime.InteropServices;
using System.Text;
2) Insert the dris.cs file in your project.
2) You need to output the protected dpwin32.dll (dpwin64.dll) to the folder that contains your assemblies.
Otherwise the System.DllNotFoundException error will appear when you run DllTest.
If you wish you can rename dpwin32.dll (dpwin64.dll) to a name of your choice. In this case you will need to
modify the dll name in the dris.cs file.
Note - CSharp is an interpreted language and so it is easier to decompile than other languages. You can
improve security if you use an obfuscator to obfuscate your code. Or - even better - you could use the
Shell Method to protect your assemblies. This encrypts your code (making it impossible to decompile).
Notes on Debugging 64-bit Code
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When you use the 64-bit runtime module (dpwin64.dll) to protect your software the anti-debug code is so
strong that if you are debugging your code, after the call DDProtCheck then it will crash with an SEH
exception. If you want to be able to debug your code then you can setup your project so that your code calls
the debug module (dpwin64debug.dll) in your "debug" build and the standard module (dpwin64.dll) in your
release build. You can do this by modifying the declaration of DDProtCheck64 in dris.cs like this:
class DDProtCheck64
{
#if DEBUG ' debug module
[DllImport("dpwin64debug.dll", CharSet = CharSet.Ansi)]
public static extern int DDProtCheck([In, Out, MarshalAs(UnmanagedType.LPStruct)]DRIS dris, byte[] data);
#else ' standard module
[DllImport("dpwin64.dll", CharSet = CharSet.Ansi)]
public static extern int DDProtCheck([In, Out, MarshalAs(UnmanagedType.LPStruct)]DRIS dris, byte[] data);
#endif
}
Note - the debug module has the following restrictions:
1) It will not correctly start a network user (network dongles only). However, other than that the protection
check will function correctly and return success.
2) You will not be able to encrypt the DRIS. (If you do encrypt the DRIS in your release build then you
should make sure that CryptDRIS does not get called in your debug build).
3) The protection check will take slightly longer than normal.
4) The DDGetNetUserList function will return error 428 (not implemented).
5) A temporary subprocess is created which may be (falsely) detected as malicious by anti-virus programs.
This behaviour does not occur in 32-bit code, so if you are using dpwin32.dll then you can debug your code.
Important Note for UWP app Developers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Universal Windows Platform (UWP) application (previously called Windows Store Apps or Metro Apps) are not
compatible with Lite or Plus dongles because the restrictions imposed by these applications. However, you
can protect these Apps with network dongles (because the restrictive access is performed by the non-UWP
DinkeyServer process). If you do this you will need to enable the "Private Networks (Client and Server)"
Capability in your package manifest.
.NET Core / .NET 5+
~~~~~~~~~~~~~~~~~~~
The sample code provided also works with .NET Core. However, .NET Core also supports Linux and macOS as well
as other platforms. If you want to support these OS then please replace dris.cs with dris_dotnetcore.cs.
The files are very similar but dris_dotnetcore.cs will load the relevant native runtime module (dpwin32.dll
under 32-bit Windows; dpwin64.dll under 64-bit Windows; dplin64.so under Linux OS; dpmac64debug.dylib under
macOS - unfortunately the release module is not compatible with the .NET Core framework so you have to use
the debug one. This also means that our solution is not compatible with ARM-based macOS - because the debug
modules do not exist).
If you are using .NET Core version earlier than 3.0 then Windows.Forms are not supported and you will have to
replace the MessageBox.Show lines with Console.WriteLine.
The Shell Method is compatible with .NET Core Console, Windows.Forms and WPF applications. It is supported
under Windows and Linux but not macOS. It is only supported for .NET Core version 3.0 or higher. If you are
using the Shell Method then you should protect your compiled dll and not the "appHost" (this is a native
executable which is just a stub program that loads the assemblies in your dll). Also do not use "dotnet run"
to launch your application - it will run the unprotected version. Either launch the executable or run using
"dotnet <program.dll>".
If you publish a "single-file executable" file then although this file can be protected we do not recommend
it because it is not secure. (The single-file executable just comprises a stub loader with your compiled
assemblies and configuration files appended to the end of the executable. These files are just considered as
data appended to the executable file in a custom format and therefore are not protected. When you shell
protect your executable you are just protecting the loader but not your assemblies). Instead you need to
build your code and then add protection before publishing. You should protect your assemblies in the obj
directory (and in the platform type you specified) e.g. obj/Release/net5.0/win-x64, because the publish
process takes your assemblies from this location when it builds the single-file executable. You will also
need to distribute all the extra files that DinkeyAdd generates. e.g. <file>.dp64.dll.
If you publish using the ReadytoRun compilation this will not work because it includes mixtures of .NET
assemblies and native code and the .NET Shell Method does not support that.
Mono
~~~~
The sample code provided also works with Mono. However, Mono also supports Linux and macOS, and so if you want
to support those OS then please replace dris.cs with dris_mono.cs. Note, dris_mono.cs is very similar to
dris_dotnetcore.cs (see above) but with Mono, 32-bit Linux and 32-bit Mac are also supported and you don't
need to use the debug modules (for release) under macOS.
Visual Studio Installer Projects Extension
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can use this extension to create a project in your solution that will create an installation program / msi
file. Please note that after your application has been built you need to protect it with DinkeyAdd before you
can invoke the installer project. You can do this manually by building your application project (not the entire
solution); then adding protection to your application using DinkeyAdd; then building your installer project.
Or you can automate this by executing DinkeyAddCmd as a post-build step. For example:
"c:\program files (x86)\Dinkey Pro 7.6.0\DinkeyAdd\DinkeyAddCmd.exe" c:\adir\mydapf.dapfj /a2
Note - if you specify "primary output" in your installer project then it will take the files from
obj\Release\net5.0 (for example), rather than bin\Release\net5.0. So, you need to add protection to your files
in this folder.
Note - if you use the API Method you will also need to include the protected runtime modules that you use
(e.g. dpwin64.dll). If you use the Shell Method you will also need to include in your installer project all
of the output files mentioned by DinkeyAdd. e.g. <application_name>.dp64.dll
