Add Original SDK
This commit is contained in:
@@ -0,0 +1,155 @@
|
||||
DllTest - sample code to call Runtime module in C# 8 using VS 2022 and higher
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This project is written in Visual Studio 2022 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 an older version of Visual Studio please use the
|
||||
Visual Studio 2002 sample. The code in this project is written in C# version 10. If you are using an
|
||||
older version of C# then please use the Visual Studio 2002 project.
|
||||
|
||||
This sample is a Console application but the code can be easily adapted to be used for other types
|
||||
applications.
|
||||
|
||||
This sample is very similar to the Visual Studio 2002 sample - however the C# code has been updated
|
||||
to prevent possible Null reference exceptions - introduced in C# version 8.
|
||||
|
||||
The main source files in the project are:
|
||||
|
||||
File name Description
|
||||
program.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 program.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).
|
||||
|
||||
Note - as you are using the API method in this sample you should protect the correct Dinkey Pro runtime
|
||||
(e.g. dpwin64.dll) and not your program directly. Because your program is linked to the DLL it is protected.
|
||||
You can also protect your program with the Shell Method should you wish.
|
||||
|
||||
You need to protect the appropriate runtime module for the Platforms you support.
|
||||
Windows x64 - dpwin64.dll
|
||||
Windows x86 - dpwin32.dll
|
||||
Linux x64 - dplin64.so
|
||||
macOS x64 - dpmac64debug.dylib
|
||||
If you are using "Any CPU" then include all of the modules. The protected runtime module should be in the
|
||||
same directory as your compiled assemblies. e.g. bin\release\net6.0.
|
||||
|
||||
Note - if you need to protect multiple runtime modules 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;
|
||||
|
||||
2) Insert the dris.cs file in your project.
|
||||
|
||||
2) You need to output the protected runtime modules(s) (e.g. dpwin64.dll etc) to the folder that contains your
|
||||
assemblies. Otherwise the System.DllNotFoundException error will appear when you run DllTest.
|
||||
|
||||
If you wish you can rename the runtime module(s) 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 Windows Store 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.
|
||||
|
||||
Other Notes
|
||||
~~~~~~~~~~~
|
||||
|
||||
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/net6.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.
|
||||
|
||||
|
||||
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 - you will also need to include in your installer project all of the output files mentioned by DinkeyAdd.
|
||||
e.g. <application_name>.dp64.dll
|
||||
Reference in New Issue
Block a user