Overview

AssemblyLockbox includes components that are used by your software development team and shipped with your software. The files shipped with your software must simply be present in the same path as your application to work. They do not require their own installation process. An application called AssemblyLockboxBuilder comes with AssemblyLockbox. This application is used by software developers to integrate AssemblyLockbox with your software and automate the process of preparing the protected files for shipment or distribution to a web server.

·         Software developer(s) create a .Net application.

·         Reference to AssemblyLockbox library is added to application.

·         A call is made to the AssemblyLockbox library to add references to your DLLs that are encrypted with AssemblyLockbox.

·         Encrypt all your DLLs that you want protected.

·         Replace your DLLs with the encrypted versions.

·         Ship your software with AssemblyLockbox.dll and your lock core dll(s)[2].

AssemblyLockbox at runtime

When your DLLs are protected by AssemblyLockbox they cannot be de-compiled. How is this? This is possible because your entire DLL is encrypted into a file that no longer exposes the meta data needed to use reflection to inspect the file. This means even .Net itself can no longer load your library. This is why you must reference AssemblyLockbox.dll in your application. This class library waits for .Net to fail an attempted load of your DLL and then it loads your DLL for .Net. This is no flimsy hack into .Net. This ability is provided by .Net as yet another of .Nets flexibility features. AssemblyLockbox cannot simply load your DLL however. It first calls the lock core dll that you used to encrypt your DLL(s) to decrypt the DLL and then loads the library into .Nets runtime. Just like with locks sold at hardware stores you can create different types of “cores” for your locks so that there is no “universal key” that can be used to get access to all software protected with AssemblyLockbox.

·         Your application references AssemblyLockbox.dll which in turn hooks into the .Net runtime.

·         When the .Net runtime fails to load your DLL AssemblyLockbox loads it instead.

·         AssemblyLockbox uses a lock core dll to decrypt your DLL(s).

·         The ability to make different kinds of lock core dlls increases the number of possible combinations and adds other restrictions that a hacker must try to over come to get at your software.

Further your protection with Lock Cores

If all locks worked with a single key then the very idea of a lock wouldn’t be very valuable. The same applies to AssemblyLockbox lock cores. This is why a primary feature of AssemblyLockbox is the ability to create more lock cores with varying protection methods. The AssemblyLockbox technology also allows for more types of variations to be added in the future as they are developed. Some of the types of lock core variations possible are listed below… [3]

·         Re-encryption of your DLLs on the client computer using local information such as network MAC address or hard drive volume id.

·         Decryption only in the presence of a USB hardware device.

·         Decryption only in the presence of a local license file or some other kind of text file containing a specific series of characters.

·         Decryption only if the calling application itself possesses certain attributes.

·         Decryption only if the calling application does not have reflection rights.

·         Decryption only upon verification by Microsoft Digital Rights Management API.

What makes the lock cores more secure than a .Net file

All of the decryption and verification is performed inside the lock core dlls themselves. The reason this is more secure is because these lock core dlls are unmanaged C++ files. They contain no meta data themselves to be reflected and are compiled directly into native executable form. This makes them very difficult to decompile by anyone… including programmers that are good at raw assembly language and that use memory scraping techniques to try to decipher what your application is doing as it is running. In addition various counter measures are used to disguise how the C++ works to help frustrate hackers that do go so far as to attempt to reverse engineer the runtime execution of the assembly commands. To create lock core dlls you must have VC++ installed on your PC. AssemblyLockboxBuilder will call the VC++ compiler to create the lock core.

Adding protection without adding a lot of extra work for the software developer

To make it easier to use AssemblyLockbox, integration for Visual Studio and features for automatically updating your code that calls AssemblyLockbox.dll has been added. AssemblyLockboxBuilder has two types of files that are associated with it upon installation. The first has an extension of .LBS and the second has an extension of .LCS. LBS files contain the setup information needed for one or more of your DLLs. This includes information such as paths to your DLLs, .Net information about your DLLs (version/full name), encryption keys, path to lock cores, paths to code files that call AssemblyLockbox.dll, and instructions for how to modify that code. LCS files contain all the settings needed to reproduce a lock core that you have previously created with the AssemblyLockboxBuilder.

To add an LBS or LCS file to a project you simply tell Visual Studio you want to add a new item to your project and in the list of choices that Visual Studio presents you pick either an LBS or LCS file. Then when you double click this file in your project tree AssemblyLockboxBuilder will launch and will automatically look for your debug/release folders so that it can put your encrypted DLLs and their lock cores into the same folder as your application.

Automatically updating your code when you make changes to your DLLs is equally easy. When you integrate your application with AssemblyLockbox, one of the tasks you perform is adding a reference to the AssemblyLockbox.dll and then adding a few lines of code at the beginning of your application. These few lines of code tell the AssemblyLockbox.dll what DLLs you have encrypted and how you want them loaded. If you create a new version of one of your protected DLLs AssemblyLockboxBuilder can automatically detect this and update its internal records about that DLL as well as go into your code file and update those lines of code that refer to that new DLL by updating the version that is expected to be loaded. This helps make the process of shipping your application much easier since AssemblyLockboxBuilder attempts to detect and automatically fix everything for you.