Re: replacing WinCryptoAPI in shareware protection scheme
Nate <misc <at> n4te.com>
2006-08-08 19:28:18 GMT
I see no one has been interested yet. Just in case someone is willing to
help me port the Window CryptoAPI to Crypto++, I have done my best to
simplify the code that needs to be converted into the below.
#define KEY_LENGTH 0x00800000
#define PROVIDER MS_ENHANCED_PROV
// acquire context "hProv"
if(!CryptAcquireContext(&hProv, CONTAINER_NAME, PROVIDER, PROV_RSA_FULL, 0))
if(!CryptAcquireContext(&hProv, CONTAINER_NAME, PROVIDER,
throw "Unable to acquire/create encryption context";
// get handle "hPrivateKey" from new random private key
CryptGenKey(hProv, CALG_RC4, KEY_LENGTH|CRYPT_EXPORTABLE, &hPrivateKey);
// write private key to "lpPrivateKeyBuffer"
CryptExportKey(hPrivateKey, 0, OPAQUEKEYBLOB, 0, lpPrivateKeyBuffer,
// get handle "hPrivateKey" from existing private key "lpPrivateKeyBuffer"
CryptImportKey(hProv, lpPrivateKeyBuffer, nSize, 0, CRYPT_EXPORTABLE,
// encrypt buffer "lpData" with private key
CryptEncrypt(hPrivateKey, 0, TRUE, 0, lpData, &nSize, nSize);
// get handle "hPublicKey" from existing public key "lpPublicKeyBuffer"
CryptImportKey(hProv, lpPublicKeyBuffer, nSize, NULL, 0, &hPublicKey)
// create license key in "lpLicenseKeyBuffer" using private and public key
CryptExportKey(hPrivateKey, hPublicKey, SIMPLEBLOB, 0,
// release key and context
CryptAcquireContext(&hProv, CONTAINER_NAME, PROVIDER, PROV_RSA_FULL,
> An article (linked below) on codeproject.com shows how to encrypt a
> code segment. When a valid license exists, the code segment is
> decrypted and patched in memory. This allows shareware features to be
> disabled until a valid license exists. I like this a lot, but I am
> less than excited that it uses the Windows Cryptographic API.
> Would anyone be interested in helping me replace the Windows CryptoAPI
> with Crypto++? I have a feeling it would be very straightforward for
> someone familiar with these APIs.
> Here is the article...
> Here is my version of the source (includes rebasing and some essential
> bug fixes)...
> Thank you much for any help or direction you can provide.
> Hoping to keep this thread on track, yes, I realize this is not a
> perfect solution. Someone with a valid key could patch the decryptor
> so it patches the segment on disk rather than in memory. However, this
> protection scheme is easy to implement, yet a reasonable amount of
> work for a cracker to break. Also it *requires* a valid key to crack.