Wibu-Systems Blog

Wrapper or API to Improve Secure Licensing

Posted by John Poulson on May 7, 2013 12:57:00 PM

First a bit of history

Wibu-Systems’ API’s “secret sauce” will securely protect your softwareAs many of you reading this know, Wibu-Systems has been in business since 1989, developing secure license management tools that enable software monetization options for ISVs and embedded systems developers. From the early days we provided our customers with the option of implementing our technology through the use of our API or by using an automatic wrapper tool. We told our customers that the automatic wrapper option provided a “quick and dirty” way to get a protected program to market; but that the most secure way to deploy was through the clever use of our sophisticated functions and API calls. We spent considerable effort in improving those functions and creating new ones that improved the overall security of our licensing solution. For over a decade, our “best practices” advice was to use the API and not the wrapper.

After several years we began to notice that illegal copies of our customers’ “protected” programs were appearing on various hacker sites on the Internet. This was distressful to us as a company and we wanted to find out what we were doing wrong. Upon analysis, we discovered that the vast majority of our customers were using the API in a way that resulted in a simple challenge / response dialogue between the protected program and the hardware dongle. All of our sophisticated function calls and suggested implementation methodologies were not being used. The engineers at Wibu-Systems had spent several years creating API functions that were being left on the shelf.

Where to put our secret sauce

Once we realized our “secret sauce” was not being implemented we had to change direction with the advice we gave to our customers. And we had to improve the wrapper tools. For several years now, we have worked hard to enhance and improve the security and performance of our encryption utilities and now emphasize that customers who want a quick and secure implementation should utilize the wrapper. And for those who require the most security we suggest they implement both automatic encryption and API functions.

The result? The powerful tool many of you know today as AxProtector.

AxProtector — The right recipe

Wibu-Systems’s AxProtector is a smorgasbord of secure software protection for everyoneFrom debugger detection to sophisticated code encryption, AxProtector provides anti-tampering and reverse engineering protection. It is no longer a simple wrapper. Why? Because AxProtector encrypts and rearranges your executable, DLLs, data, media, or video files with minimal effort on your part. In most cases, you don't even have to change your source code. On program load, the program starts only if the required CodeMeter license is available.

And AxProtector is a smorgasbord to meet everyone’s requirements. Use it with software activation codes (CmAct) or hardware dongles (CmDongle).Use it with Windows, MacOS, Linux, .NET (also Mixed Mode), even VxWorks, and in the near future… Android.

The end result

As a result of our change in philosophy, we no longer put the bulk of our development effort into just creating API functions. We concentrate instead on improving AxProtector. And, it is true… part of that improvement process includes creating more sauces, improving existing sauces and changing the recipe. It is a constant process to stay one step ahead of the global hacking community. Now… Our “best practices” advice is to use the AxProtector wrapper along with the API.

Watch the 3 minute demo!

john poulsonJohn Poulson has worked in the software protection industry since 1988 and has been with Wibu-Systems since 2000. He is an expert in license authentication best practices and deep powder skiing.

Topics: CodeMeter, software copy protection, AxProtector, secure licensing

CodeMeter 5.0 released!

Posted by Kevin Browne on Mar 18, 2013 11:37:00 AM

Ready for spring 2013, Wibu-Systems presents the new CodeMeter 5.0 which provides new amazing features:

CmSticks now support HID and MSD interface

CodeMeter 5.0 released!In addition to the traditional MSD (Mass Storage Device) interface, newer CmSticks can also be used on Windows, Mac OS and Linux with the HID (Human Interface Device) interface. The CmStick no longer appears as a memory drive but integrates as a USB input device such as a keyboard or mouse does. Every CmStick with a Serial Number in the 2-xxx format can be switched between either interface variants. One requirement is that the CmStick is updated to firmware 2.02 or higher (see below) and CodeMeter RunTime 5.0 is installed (see below). By design, CmCards and CmStick/M do not support the HID interface and are restricted to the MSD interface.

The biggest advantage of the HID interface against the MSD interface is that CmSticks no longer appear as memory sticks with non-writeable memory which may be confusing for end users. HID-activated CmSticks can also be used now in areas where the mass memory interface at USB is deactivated due to security reasons. On the other hand the MSD interface is fully compatible with the CmStick/M which can be used as real writable memory at USB. In the future the ISV and the end user can decide which interface they prefer.

New CodeMeter Runtime 5.0

connectedplanet 257pxCodeMeter 5.0 RunTime automatically detects HID and MSD CmSticks and provides all CodeMeter features to both interface variants. The command line tool CMU32 enables end users to make the switch of an existing CmStick from MSD to HID and back.

Another great feature of CodeMeter 5.0 is the first integration of CmWAN. CmWAN is the CmLAN equivalent for Wide Area Networks (WAN) and is based on the HTTPS protocol, which permits easy communication around the world through firewalls, point-to-point encryption and client/server authentication. Beyond that, CmWAN supports all the concurrent licensing features of today’s CmLAN. CmWAN is an important component of the Wibu-Systems cloud licensing strategy.

Data in CmActLicense containers can now be modified at the user site without license update, identical to CmDongles: This includes the unrestricted writing of UserData PIO (Product Item Options) and the password controlled updates of HiddenData and SecretData PIO through the WupiWriteData function.

To simplify integration of the CodeMeter Runtime in Windows installation files, the new standard CodeMeter installer file supports 32 and 64 bit Windows simultaneously. There is no longer a need to distinguish between two versions in dependence of the Windows variant and provide two separate installer files.

CodeMeter for Mac: CodeMeter 5.0 requires as a minimum Mac OS X version 10.6.

CmDongles: New Firmware 2.02

Firmware 2.02 is required to permit the switch of CmSticks between HID and MSD. It can be downloaded to any CodeMeter CmStick with 2-xxx Serial Number.

AxProtector 8.40: More automatic protection features

The new AxProtector is included in the CodeMeter SDK 8.40. The most important new feature is the enhanced obfuscation of .NET code including .NET mixed mode: Human-readable information as class, method and field names are replaced by cryptic machine-created names, increasing the difficulty to understand the .NET code beyond our leading-edge MSIL code encryption. The range of the obfuscation (private/internal/protected/public) can be specified. It is also possible to control the protection through the obfuscation attribute of the System.Reflection namespace.

AxProtector 8.40 now also supports the automatic encryption of ELF ARM binaries for VxWorks and allows the configuration of the new CmWAN protocol (see above). By default, network license access includes both CmLAN and CmWAN protocol variants.

Topics: CodeMeter, AxProtector, Wibu-Systems news

AxProtector 8.20 Released

Posted by John Browne on Jul 18, 2012 10:30:00 AM

Following up on yesterday's post on CodeMeter 4.50, here's some information about the rest of the release.

Swiss Army Knife

AxProtector has some new features and fixes, including the following:

  • You can use WUPI (Wibu Universal Protection Interface) API calls with .NET now when programming in mixed mode. WUPI was always available for .NET and other languages, but mixed mode wasn't supported before 8.20. 
  • You can also use individual method encryption in mixed mode using IxProtector. This is also new in 8.20. Note: this is currently done using an XML file; support for specifying individual methods in the graphical user interface will come in a subsequent release. The XML file is only used when you are doing mixed-mode programming; for native .NET or C++ you can still use the GUI as before.
  • If you select the "-cac" option (System Time Check) we will only check the Certified Time Server if the license uses a time restriction (e.g., Expiration Date or Usage Period).
  • You can now add code integrity checking to your executable, DLL, or dylib (Windows and MacOS X) by checking the "-cav" option. This creates a signature on the code which is verified at runtime. This replaces the old "virus check" option.
  • Bug fixes and general security improvements. These are detailed in the release notes.
AxProtector is still your best choice for undefeated software protection against piracy, inadvertent license abuse, reverse-engineering, and tampering. If you haven't tried it yet, be sure to click on the link to get your copy of the evaluation system. 

Topics: AxProtector

Yet more software license management flexibility

Posted by John Browne on Jul 12, 2012 4:55:00 PM

Time for some how-to.

You don't have to use an API to implement CodeMeter--in fact, you can just use AxProtector (Automated Executable Protection) and wrap your whole executable (or dll or file or what have you, but we'll focus on executables in this blog post) with strong encryption that needs a valid license at runtime. Badda bing, badda boom. You're done.

That was easy.

And you can get a lot of flexibility in your software license management with no more work. Time based licenses, usage-based, network, concurrency, all those things and more are available with no source code changes--just protect with AxProtector and then set the licensing rules when you create the license.

So why mess with the source code? Good question. There are two reasons:

1. You can turn on or turn off individual functions or methods with separate licenses, thus enabling a pay-per-feature business model. This can be really cool if you think about all the possibilities (more later).

2. You can increase the security of your application, since multiple licenses with multiple separte keys are needed for it to run. While cracking CodeMeter is no small feat, this will just make it that much tougher.

How hard is this source code intergration? Pretty basic. We have a low-level API (the "Core API") which you don't repeat do not want to use. If in doubt, please give us a call to ask if you should use this. Normally our customers only use it when they need to implement CodeMeter on a platform we don't yet support. 

These are not the functions you are looking for...

The one you want is WUPI (Wibu Universal Protection Interface). WUPI is a high-level encapsulation of the Core API and by using it you will avoid shooting off your toes the way you can with the Core API. WUPI will do most anything you need to do.

WUPI only needs 15 functions to cover the whole gamut of stuff:

  1. Accessing: allocate and free a license; get a handle to a license
  2. Encryption: Encrypt and decrypt code
  3. Manage: Decrease Unit Counter; Get License Type; Query info; Read/write data
  4. Security: Debugger check and license check
  5. Errors: Get last error

That's it. Most of it you don't need to worry about. All the functions return either a BOOL or an INT, which makes them easy to use in a number of programming languages.

Parking meter

Integration couldn't be easier. There's an include file (we're talking C++ now), and you have to point your linker to some libs. The CodeMeter API guide (accessed from the CodeMeter Start Center, which is part of the Evaluation System) gives you sample code to cut & paste.

Here's an example:

#include <WibuIxap.h>
 int iWupiResult = WupiCheckLicense(0);
 if (!iWupiResult)
// License check failed.
// Successfully checking license.

That's it. Pretty simple--you just need to wrap these kinds of calls around the code that does stuff inside your application. 

Suppose, for example (and I know this is a trivial example) you wanted to meter printing. You could wrap your print function with a call to decrease the CodeMeter Unit Counter:

#include <WibuIxap.h>
int iWupiResult = WupiDecreaseUnitCounter(0, 0);
if (!iWupiResult)
// Unit Counter reached 0.
// License isn´t available or already allocated.
// Successfully decreased Unit Counter by the specified units.
// No Units remaining.

 If you use some counter in your code for the number of pages as a parameter to the WupiDecreaseUnitCounter() function, you can meter things exactly. Unit Counter values are set at license time, so this would require you to sell "blocks" or pages to be printed; when they get low on available pages (ie UnitCounter value) the system will let them know that they might want to buy some more. When they are gone, no more printing.

Printing is trivial (well, perhaps not if you're a printer) but there are plenty of other things you could wrap in this kind of protection. Perhaps you want to have Bronze, Silver, and Gold versions of your product. The normal way you'd do that is to branch your code or use conditional compiles. But it's a lot of work. With WUPI you can build one monolithic application, wrap that Bronze, Silver, and Gold functionality in separate license calls, and ship the whole thing to everyone. They get the product they paid for (because the correct license turns things on). Nothing more.

One last thought. This API stuff is not needed if you use .NET; because it's managed code you can actually protect individual .NET methods from inside AxProtector. 

photo credit: lakewentworth via photo pin cc

Topics: CodeMeter, License Management, AxProtector, Software Development

New release for AxProtector

Posted by John Browne on Jun 12, 2012 4:47:00 AM

AxProtector Version 8.10  is now shipping and available for download.

Not a major update, but there are a nice grabbag of goodies. Changes include:

  • Protection of mixed mode programming (.NET and C++) is now enhanced. If your IP is in your .NET code, select the Mixed Mode option from the AxProtector GUI and each individual method will be encrypted separately. If your IP is in the C++ code, select the standard AxProtector for Windows. If it's pure .NET (no native code) use the AxProtector .NET option. Please check with tech support if you are interested in this feature to make sure your implementation has maximum security.
  • Java servlets protected with AxProtector can now run on Apache Tomcat with no server-side decryption code. This simplifies implementing protected web services.
  • Also on Linux: full support for method-level encryption with IxProtector (this is now on par with the Windows implementation).
  • AxProtector GUI shows new and extended project types with new icons: separate tabs show options for AxProtector or IxProtector. 32- and 64-bit versions are now combined into single options.
  • Improved support for VxWorks for embedded systems allows for simultaneous use of CmDongle and CmActLicense. Digital signatures (integrety checking) is now implemented for VxWorks as well.
  • Plus many more: improved security, better support for multi-threaded applications, and improved Java support. See the change log for full details.

Topics: Copy Protection, AxProtector

Is software copy protection worth the trouble?

Posted by John Browne on Mar 22, 2012 6:00:00 AM

In a word--yes.

In a few more words:
  • It doesn't have to be a lot of trouble.
  • It doesn't have to be expensive.
  • The ROI can be enormous.
Let's take these in inverted order. What's the ROI on effective software copy protection? Potentially millions of dollars. For a minute, forget about the kid who gets a cracked copy of an app from a bit torrent site. I'm talking about criminal enterprises who crack software and sell it as authentic. To (mostly) unsuspecting customers. These are people who buy your software but you don't see any revenue from the transaction. We know customers who came to us after 3rd party audits disclosed just how massive these losses were each year. The investment required to prevent this theft is trivial compared to the eventual return by thwarting thieves.

It doesn't have to be expensive: AxProtector is free, and you really don't need to expend developer resources to have good software copy protection because no source code changes are needed. In fact, you can add copy protection after your software release candidate is done in a matter of minutes. Even if you need dongles, they are relatively cheap compared to getting ripped off.

Software copy protection doesn't have to be hard.It doesn't have to be a lot of trouble: Good protection tools let you write your code without being concerned about software copy protection or license models. Those can come later. Now in the interest of full disclosure there are some situations where you might want to wrap a function or method with a specific call to the API to decrypt that function with its own license. It can, for example, allow that function to have a separate license model such as pay per use or pay per feature. But most licensing options are available with the basic software copy protection offered with AxProtector, which takes only a matter of a few minutes to add.

Topics: CodeMeter, software copy protection, Copy Protection, Anti-piracy, AxProtector

Announcing CodeMeter 4.30

Posted by John Browne on Apr 28, 2011 12:57:00 PM

This week we released CodeMeter® 4.30 and AxProtector 7.11 on all platforms to improve your software protection, include Win 32 and 64, Mac OS, Linux, and more. There is a ton of new stuff in these two components, so I urge you to download the updates to our SDK and try it out. Some highlights:

  • Maintenance Periods: I wrote about these in my post "A Unique Solution for License Management" but now they are real with this release. It does require a minimum CmStick firmware of 1.18 or better (1.18 is the current version). Maintenance Periods can save you money because (among other reasons) you can ship software without doing license updates to the key.
  • SmartBind™ is an improvement (for those of you who want to use activations for software protection and licensing) over how CmAct figures out whether the PC it's bound to is the right one or not. We now use heuristics to calculate an internal value and you can merely set parameters of "tight, medium, or loose". We'll have a bit more explanation of this later but some of the details we will understandably keep under our hats so crackers can't get a leg up.
  • The runtime now supports the CmStick /C and /T variants. The Compact version (/C) is now available in quantities (subject to backorder, however, since demand has exceeded our expectations) and in eight colors. More pics coming soon.
  • We now have full support for protecting Microsoft Silverlight apps. Our goal is copy protection on all popular platforms.
  • We now support Linux on PowerPC processors.

Read more about this release here.

Topics: CodeMeter, AxProtector, dongles, Corporate News

How does copy protection work?

Posted by John Browne on Mar 22, 2011 6:56:00 AM

We all know software piracy is a Bad Thing. But how can you prevent it?

The answer isn't quite as simple as you would expect. The easy way, of course, is to rely on CodeMeter to protect your software absolutely. Using AxProtector and a CmStick, your software is rendered effectively uncrackable. How uncrackable is that? We designed it from the beginning to have no universal crack (because there's no single key to decrypt the code). And we've tested it against hacking contests where we invited all the bad guys to take a swing at the protection with big bucks if they could break it. So far no one has.

So CodeMeter is the gold standard. How does it work? How do you keep people from stealing your creation? How do other systems work?

Let's start with CodeMeter. Our protection system, like a stool, has three legs: encryption, key storage, and debugger detection.

Encryption: We use AxProtector to encrypt your executable (.exe) using AES 128-bit algorithms. Since it's encrypted, the compiled assembly language is now meaningless drivel to your CPU until it's decrypted. Encryption is used all the time--every time you log onto Amazon.com and use a credit card to make a purchase that credit card info is being encrypted at your computer, transferred over the 'net, and decrypted in Amazon's server. AES 128-bit is recognized as sufficiently "strong" enough that no brute-force attack is possible.

Key Storage: The beauty of the CmStick is that it stores the key necessary to decrypt your software so it will run. The CodeMeter runtime turns the encrypted meaningless drivel back into assembly language via decryption. The key is stored inside the CmStick in an area that can't be accessed—even trying can cause the stick to permanently lock itself. And the key generation is dynamic with up to 4,000,000,000 different keys possible, eliminating the possibility of a "master crack."

Debugger Detection: Of course, once the application has been decrypted and loaded into memory, a cracker could just take a "picture" of the contents of the computer's memory and use that to create a cracked version of the application, right? No. Here's why:

First of all, CodeMeter never completely decrypts the entire application at any one time. Some critical pieces are left encrypted until called, then decrypted individually until they are no longer needed. So if you take a snapshot of memory you only get a partial decryption of the application, which is not a crack. Second, you can optionally turn on debugger detection: when you choose this, the license is locked if a debugger is detected on the computer. This works well to prevent reverse engineering or theft of algorithms. It can be unlocked, but it would require someone to call you up and say, "Uh, hmmm, gosh, I tried to crack your license and now my license is locked. Could you please unlock it so I can try again?"

What do other systems do? Many rely on encryption and hardware-based key storage like we do. Some take a simpler route, using code obfuscation or just checking for the existence of a dongle. These simpler methods are extremely easy to crack, and should never be used for high-value software. In future posts I'll describe how simple these are to crack.

Topics: CodeMeter, software copy protection, AxProtector, software piracy

A unique solution for license management

Posted by John Browne on Mar 17, 2011 12:16:00 PM

We've recently added a feature to CodeMeter that can be a real money-saver for you if you sell software maintenance contracts. Let me explain.

A lot of software companies that sell to the enterprise (mid to large customers) use maintenance contracts. The maintenance contract (often priced at about 20% of the license cost) guarantees the customer support and all updates during the contract period (often a year). The big customers like it because it makes procurement simple and simplifies keeping all their users on the most recent version of a product. The ISV likes it because it's an additional 20% in revenue on a sale.

But the fulfillment side of the ISV can come to hate maintenance contracts. They have to figure out how to handle the licensing for customers who have maintenance contracts and those who don't. It can be a nightmare.

Enter Maintenance Periods for CodeMeter. The Maintenance Period is a time period (end time is required; start time is optional) during which all releases protected with CodeMeter will have valid licenses. The date in the license is checked against a Release Date that is set with AxProtector when you protect your software. As long as the Release Date is within the Maintenance Period, the release runs on the customer's computer. If the Release Date is outside the Maintenance Period, the customer needs a new license.

Really simple, no?

Let's take an example. You have two customers with maintenance agreements: BigCo has a maintenance agreement through Dec. 31, 2011. MediumCo has one that expires June 30, 2011. Now supposed you release software this week and set the Release Date in AxProtector to Mar. 18, 2011. Both BigCo and MediumCo get the release; the runtime compares the Release Date to the Maintenance Period of the license and sees everything is good to go. The software runs and the customer didn't have to update any licenses on any machines.

Now it's a few months down the road and you put out another release with the Release Date set to July 15, 2011. Again you send out the protected executable. At BigCo the software will run because it's still within the Maintenance Period. But MediumCo  has let their maintenance contract lapse, so the end date of June 30, 2011 for their Maintenance Period is past. Their software won't run without a new license.

Why is this better than time-based keys? Because you can have multiple releases within the Maintenance Period and never touch the licenses. With time-based licensing you'd have to be issuing new licenses and the customer would have to update all those keys. Even if they used SOAP/XML connectors to License Central it's still less work to use the Maintenance Period and have things Just Work.

And that makes things nice for everybody.

Topics: CodeMeter, License Management, AxProtector, Corporate News

Why lock software?

Posted by John Browne on Dec 21, 2010 11:29:00 AM

I keep my car locked and use a key to unlock it. The same key allows it to start and run. It probably wouldn't last long parked downtown if it didn't need a key to drive it away.

My house has a key; so does my mailbox. People lock their cars, boats, airplanes, houses, safe-deposit boxes, storage lockers, bathroom doors, gun cabinets, gym lockers, even suitcases. My computer has a lock so when I'm not around no one can snoop on it. I've seen keys on band saws, lawn mowers, tractors, and back hoes.

So why all the fuss about locking software?

Locking programs or data is easy: you just encrypt it. We all use encryption all the time, we just don't think about it. Anytime your browser says "https" instead of plain old "http" you're running an encrypted session. When you encrypt software, it can't be run without decryption, and the only way to decrypt is with the right key.

The key can be stored in a file on your computer, or it can be stored in a separate device (usually called a dongle). Dongles are inherently more secure for key storage than files (also known as machine binding) for lots of really technical reasons.

AxProtector from Wibu-Systems can encrypt an executable (lock it) in just a couple of minutes. You don't need to make any source code changes. And then that executable is completely useless without the right key. Just like my car is merely a roadblock without the right key.

Topics: CodeMeter, software copy protection, AxProtector, FAQ, Evangelism