Index
DescriptionSSD SDK stands for "Secure Software Distribution SDK", and it offers several tools and code which will stop most cracking activities over your software. But first, we'll have a look on the most typical shareware schemes: X Days/Uses trial scheme:This scheme prevents your software to be used more than a defined number of days (usually 30) or executions. This kind of protection is easy to defeat because your software has to store the number of remaining days or uses in a secure place, and there is no secure place in any computer. These values can be encrypted or stored in "strange" locations, but it will only delay the inevitable, your trial period will be reset or extended to infinite. Incomplete software releases:It is very common to release two versions of the software, the full and the incomplete version. The full version is the one given to every user who has paid for the software. The incomplete version is freely released to the world, without caring about crackers, because they can't do anything against an incomplete software (well, they can write the absent pieces of code, but it would be a bit stupid...). Another issue is that malicious registered users can "lend" it to other users, violating the one-license-one-user distribution concept. Unlocking software:This kind of software has all the full-version characteristics but they are not available to the user, unless the user pays for an unlock code which unleashes all the power of the software. Under the commercial perspective, this is great, you only have to distribute a copy of the software, and wait till the unlock requests arrive. One simple e-mail with the unlock code will be enough to deliver your full software to any part of the world. Under the security and programming perspective, this is a hard problem... advanced tools such as low level-debuggers and disassemblers can be used to trace and analyze your applications and get the unlocking code generation algorithms, and also patch your application code to avoid the unlocking code protection. SSD SDK has been developed to enhance the security of the applications using the third technique. It encrypts the non-public parts of your programs using strong cryptographic algorithms, and prevents the key sharing via asymmetric encryption. WorkflowWell, you have in your hands the result of a lot of programming and debugging months... the final version of your software is ready, and you want to release it across the world through the World Wide Web. But you will not give it for free, what you want to do is to release it with a reduced functionality, and allow users to extend this functionality if they consider (after testing your program) that it is useful for them. It's time to think a bit... when you create a software which unlocks itself, it only allows access to portions of code which have been there in every moment, so anybody can patch your software to avoid the security issues and run that code as usual. No matter if you use an external packer-compressor-protector... the program data and code will be in memory when it executes, so it can be dumped and rebuilt by an experimented cracker in a relative small amount of time. But... how can I protect my code in that case?!?!?!. The solution is to encrypt the code making it available only to registered users. The encryption algorithms should be very carefully chosen. This will be discussed in the Algorithms and key lengths section. Let's return to the first step, you have the software in your hand, for example, a MPEG compressor. This compressor features high speed compression and a fine audio/video quality, due to it's variety of compression algorithms, based on multiple hardware acceleration tricks, such as MMX, 3dnow! and SSE extended instruction sets. You want to release your software allowing the user to take advantage of the MMX-based algorithms, but those who want to accelerate the compression using 3dnow! and SSE should upgrade to the full version. What you have to do, is to release your software with the extended algorithms encrypted. I will discuss later (in the Tools included section) about how to create a secure private key and encrypt your code using it. Once your users have tested your software and know that they *need* 3dnow! and SSE extended algorithms, they should get the key to decrypt the code. This can be done in many ways, but the most common takes advantage of the public cryptography scheme, which allows to share private data between users without using secured channels to transmit private keys. Resuming, your user contacts you, sending a public key, which will be used to transmit the unlocking key. Finally, his "license file" is installed in the program directory and the security code verifies it and decrypts the code in memory. Every user has a different random public/private key pair. This ensures that your license will not be shared between different computers. CompatibilityYour code is protected from the moment in that the executable file is processed and the code is encrypted. This step is done by an external tool which opens your executable file and looks in its section table for a section called .secure; this section contains your "protected" code and is fully encrypted. This means that your compiler/linker should be able to place any code you want in a separate section with any name you want. At the moment of writing this article, only a compiler with this ability has been found, and it is Visual C++. If your know other compilers which can do this, please notify it to me. Due to export restrictions, some encryption algorithms will not work in determinate countries. For example, a computer located in France using Windows 95, 98 or NT 4 will not encrypt data under some circumstances. The API used (CryptoAPI 2.0) is available in Windows 95 OSR2 and later, so this code must work in "any" Microsoft 32-bit operating system. Package contents
Tools includedThe SSD SDK contains three tools. Quotes are required only when using spaced paths (i.e. c:/my docs/target.exe).
ReferenceThere is a final question to answer: How do my software create user keys, and validate licenses?... Don't worry about it, all this stuff is coded in a separate .dll file, you only have to call one of its simple functions to verify the security context. The functions are declared and implemented in a file contained in the same SDK package, so you only have to add these files to your project and include the header file everywhere you need it. The function specs are the following:
Finally, you should know how to store your protected code in a separate section with a specified name. In the Visual C++ compiler/linker, this is done through the #pragma code_seg(push, r1, ".secure") void CMyApplication::DoExtendedFunction() { // Do something cool ;) } #prgama code_seg(pop) You can also store all the protected code in a separate file to avoid redundancy of Algorithms and key lengthsAll the tools and stub code described in this article have been coded using CryptoAPI 2.0. This API offers symmetric and asymmetric encryption routines, and also features key management, hashing and signing techniques. Used algorithms and key lengths are described in the following table:
As described in the excellent book "Handbook of applied cryptography", a secure encryption system bases its security in the key used to encrypt the message, and not in the privacy of the algorithm. In other words, no matter if the chosen algorithms have been published and tested for the scientific community around the world, its security resides in the extensive number of keys which can be used when encrypting. This ensures that it is necessary a large amount of resources (computer memory and clock cycles) to find a key which decrypts the message correctly. NotesThis small SDK has been developed to show that it is not necessary to spend a lot of money to distribute our software under a good protection scheme. It is not perfect, but minor (or major) leaks and bugs will be covered in the future with other users' help. About Emilio Guijarro |
A Secure Software Distributon SDK
最新推荐文章于 2021-11-20 10:16:31 发布