Table of contents



SoftwareShield is a cross-platform DRM (Digital Rights Management) solution for applications. Although it is developed with Game protection in mind, it is a generic DRM solution for all kinds of software. In this document, both game and application refer to the same thing --- the target software to be protected.


  1. Operating System Supported:
  • Windows: WinXP and above;
  • Mac OS: 10.6 (SnowLeopard) and above, Intel CPU 32bit/64bit;
  1. Native Code Performance: All modules (except SoftwareShield IDE in C#) are developed in native C++ / Pascal for maximum runtime performance;

  2. Non-intrusive Software Protection: No need to touch game source code, just specify the license model logic and wrap it!

  3. Extensibility: with SoftwareShield/SDK developers can develop any license model logic of their own and integrate with the software easily.

    SoftwareShield/SDK supports most commonly used languages (C,C++,C#,Object-C,Pascal,Java), the api interface is quite similar for different languages.

  4. High Security: Activates game with short string code (Serial Number, Activation Code) or DSA (Digital Signature Algorithm) based key file.

  5. Dual-Activation Mode: Games can be activated both on-line and off-line.

  6. SoftwareShield can protect software developed in C/C++/Pascal/java/Flash;

  7. SoftwareShield can protect software with multiple executables/dlls (Exe-Hopping);

  8. SoftwareShield can protect software all kinds of game data files thanks to its wrapping technology.


When developing a software product, SoftwareShield plays a role in your work flow as following:


  • Developers build the application; Usually SoftwareShield does not need access to your application source code; however, if you want to implement your own license logic, you can integrate SoftwareShield SDK with your application at source code level.

  • SoftwareShield protects and wraps the application; You create a license project in SoftwareShield IDE, specifying required license logic and build the project, the protected application binaries are generated in "ProjectDir\Release\Deploy" folder.

    Once your license project is created and verified to work fine, the SoftwareShield IDE building process can be automated by using SoftwareShield CLI (Command line interface)} in a post-build script.

  • Your QA team test the quality of the protected application to make sure the application works as expected and the license can be activated correctly.

  • Prepare application installer There are plenty of commercial or free software that can turn your protected application into a standard installer package, which can be distributed to your customers.

To protect your application in SoftwareShield, the internal data flow and detailed steps are as following:

SoftwareShield Overview

Source Preparation

Copy original game source (we mean the game binaries, not the game source code :) to a local disk folder;

Create License Project

Create a SoftwareShield project in SoftwareShield IDE, defining the entities, license models and most wrapping features in GUI;

Build License Project

After building the project in IDE, the IDE generates the following output in the project folder:

Project Folder Layout

  • XXX.lpj file: The project file. It is a plain text file in XML format;

  • Tmp/ directory: All temporary files are stored here, including wrapping script files (iw.xml, gsClean.xml, gsKeyGen.xml) and wrapping output log file (iw.log), also on Windows there is a batch file (iw.bat) that you can invoke it to re-wrap the game manually on command line without a full rebuild from IDE.

  • Release/ directory:

    1. License File (XXX.lic) and its corresponding KeyGen file (* The License file is a piece of binary data in an encrypted format containing all needed information at client side, it is wrapped later in the final protected game binaries in the wrapping process.

      The KeyGen file stores all needed information for key generation, it has two usages:

      • The IDE uploads the keygen data to CheckPoint server database; at runtime, it is used to generate activation code on game's demand.
      • IDE wraps the keygen data into KeyGenerator, so that the gsKeyGen utility can generate activation code manually for this game.
    2. Deploy/ directory: Keeps the protected game

      Only the content under Deploy folder can be delivered to public customers, all other stuffs under Release folder should be kept for internal usage only.

    3. KeyClean/ directory: Clean up local license storage

      This utility (gsClean) can be used to reset or clean up local license storage which is quite useful when QA a wrapped game. After gsClean runs, all of the existent license data for this game is erased, so that when the game runs, it runs as if it is a new installation on this machine.

      It is not recommended to ship this utility to public users; the official way of license resetting is applying a clean up action (\emph{ACT_CLEAN}), please refer to LMApp and Custom SDK Developing for details.

    4. KeyGenerator/ directory: Manual Key/Activation Generator for this game. It is a QT-based desktop utility to generate activation code for a valid request code for off-line activation. For on-line activation, it is not used at all, the activation code is transferred via internet web services.

  • Sys/ directory: Internal folder to keep project build history and backups (not implemented yet).

  • Src/ directory: Keeps a full copy of the original game source binaries.

Software Stack

The SoftwareShield product consists of multiple software components partitioned in stacked layers:

Software Module Stack

High Layer: Cross-platform Modules

  • gsCore: The Core library implements the SDK APIs.

    Developed in C++, \textbf{gsCore} implements all licensing logics and exports more than 100 apis to support other higher level modules. All operating system specific features are encapsulated in gsCore so that all software modules based on gsCore can be cross-platform.

  • gsRender: HTML User Interface Render

    gsRender implements a programming interface for HTML page rendering; it also exports SoftwareShield core objects (entity, action, license, variable, etc.) as Javascript objects so that you can access SoftwareShield features in pure cross-platform Javascript.

    Currently gsRender is Qt/WebKit based and is completely self-contained and cross-platform, maybe later SoftwareShield will provide OS-dependent gsRender version to avoid Qt runtime delivery with wrapped game.

  • Project IDE

    Basically the IDE (\textbf{Shield.IDE}) works as a XML editor and a high-level UI presentation layer, it creates / edits project file (*.lpj, a XML text file), specifies entities and licenses. The IDE comes with a set of built-in License HTML templates. The UI can be previewed (via gsRender) and the template settings can be customized.The IDE calls \emph{IDEConnect} library to compile project. You can also invoke a command line version (\textbf{Shield.CMD}) to build the project in a batch or script file.

  • LMApp (License Model Application)

    • gsLMRun: License Model Application (LMApp) execution engine. It parses the LMApp's configuration file (lmapp.config) and drives the UI pages for different system events. If your UI is not LMApp framework based, gsLMRun is not needed. You can install event listeners and implement your own event handlers and display UIs in your own way.

    • LMApp Framework It is a built-in XML/HTML/Javascript based framework that can be customized and previewed in IDE.

  • SDK (SoftwareShield Software Development Kit)

    It provides OOP framework to support API-based integration with application source code.

  • Desktop Utilities

    • gsManualActivator: Manual Key Generator

      A GUI utility to generate license code. When the user needs to activate or extend the accessibility of product features, a special magic string (called \emph{License Request Code}is generated automatically by built-in license UI, it is then transfered to software vendor or sales dealers who produce the corresponding \emph{License Response Code} for the customer with ManualActivator. The user then input the returned code to apply the change to local license status.

      If the project is pre-defined to use CheckPoint server, the above round-trip happens in background with less user interaction. The user needs to input a Serial Number then everything is processed automatically.

    • gsClean: License Cleaner

Ironwrapper Layer

  • Ironwrapper for Windows

    • gsLoader.dll: bridges C++ interfaces and Low-level interfaces from Ironwrapper kernel.
    • iw4win.exe: The low-level magic box consists of multiple coders, linker and loader. It accepts iw.xml and build the wrapped output binaries.
  • Ironwrapper for Mac

    Wrap standard application bundle on MacOS platform

Migration from old versions

SoftwareShield has a long history, before version 4 released on 2007, SoftwareShield v3 is a COM based Windows library with flexible license models, since version 4 SoftwareShield adds anti-cracking \emph{Ironwrapper} technology to protect application files. When Mac desktop application becomes more popular, SoftwareShield version 5 goes cross-platform and becomes more powerful and flexible for various kinds of applications.

There are many major feature differences listed as following:

Features SoftwareShield v5 SoftwareShield v3, v4
Working Platform Windows XP/sp3 to Win10; Mac v10.8 to v10.11 Windows Only, Win10 incompatible
Developing Tool-set C#, VC++ C++ Builder
SDK Integration OOP APIs support C++/C#/VB/Deplhi, no need for special setup or DLL registration SSCProt.dll and SSCProt.exe is COM component, must be registered before use and might cause version conflicts and compatibility issues (Thread-Model, user privilege, etc.)
Micro Transaction Unlimited entities can be licensed or protected in a single project Only single entity (aka the Application itself) is protected
Project File Format Portable XML Private binary format, very hard to extend and maintain backward compatibility
License File Format Private binary format, cross-platform portable, easy to extend and maintain binary compatibility Private binary format, very hard to extend and maintain
License Deployment License File can be deployed ReadOnly, compiled as part of application executable, or just embedded in AXS. License File must be deployed in ReadWrite mode and its access has to be synchronized carefully for multiple processes/threads.
KeyGen File Private binary format, its format is very stable and it is uploaded to CP server or embedded in ManualActivator, hence the possibility of server side upgrade or licenseCode format mismatch is minimized. N/A, the volatile Project File is used instead, so the server side always need to upgrade for each SoftwareShield version
Virgin Data and Alias Files obsolete in IDE/UI, it is implemented at the core level in a platform-specific safe manner Inappropriate virgin data settings might cause problem in Vista+ (permission issue)
Authorization Definition Depreacted by license Action The most hard to use UI part in IDE.
License Code Capacity SoftwareShield embeds unlimited license actions in a single license code. The ManualActivator is intuitive to use. The LicenseCode (aka ActivationCode) can only embed limited /pre-defined license operations (AuthDef), ManualActivator is hard to use.
License Code Algorithm Classical variable-length SN and modern DSA, the DSA-based licenseCode is extremely hard to crack in theory Fixed-length SN, easy to write a keygen by reverse-engineering.
Error Handling when license missing or corrupted Can always roll-back to the original license demo status. It's useful to copy games to friends to play in demo mode. Fails to launch or try to recover license manually or automatically. If all of the alias files and license file are corrupted, manual recovery is the only choice.
License Status Checking Checking the latest status first, if corrupted, fall-back to the previous copy. It is very stable and error-tolerant even in unexpected machine reboot / crash All alias files must be consistent with the master license file; The algorithm is pretty error-prone and likely to report false-positive if machine is rebooted unexpectedly or AV products interfere with the disk IO.
FingerPrint Error-tolerant by design. License is still valid if only small changes applied to hardware. Zero Error-Tolerant. A single change in hardware will invalid a license. Sometimes the fingerprint changes come from our internal algorithms or Windows OS behavior difference.

SoftwareShield v5 provides built-in tools to migrate license project from v4 to v5.