• Code Protection vs License Management
  

• What About Concurrent User Licensing
  

• Free Demo Without Having to Issue Licenses
  

• What About Encryption and Export Control
  

• Does Zarqon Require the use of PureMVC?
  

• What About Automating the Process of Issuing Licenses?
  

Code Protection vs License Management

"I really have two needs as I understand it and they are closely integrated.  One is protection of the code and the other is license management.  I understand that Flex applications are fairly readily hacked, requiring some sort of encryption to protect them.  It seems the safest method would integrate with licensing and do decryption on the fly at run time.  Do you have or are you headed toward anything like that?"

Code protection is a legitimate concern that should be addressed in any Flash-platform software that you release. There is an inherent assumption in some of the products out there that these two issues must be solved by the same piece of software, when in fact they are two entirely separate problems.

As we do with Zarqon itself, we suggest combining Zarqon license control with a solid code protection solution such as Kindisoft's secureSWF, which we use and endorse.

In the field of object-oriented software, a primary tenet is Separation of Concerns. This principle allows us to approach a system in a modular fashion where dependencies between subsystems are minimized and re-usability is maximized. This is why modular stereo systems are better than mammoth 'all-in-one' units. When it's time to replace your DVD player with a Blu Ray Disc player, you just swap the component that needs optimizing.

Zarqon is focused on facilitating license management with the simplest, and most reliable approach. The additional scope required to encrypt and/or obfuscate source code comes with a price of complexity, performance and reliability and should therefore be attended to by hardened professionals in that specific discipline.

• A code-protection solution that involves, say, encrypting modules and decrypting them at run-time, comes with an obvious performance price in terms of the time necessary to decrypt a module and run it.
• Code obfuscation methods must ensure that the obfuscated code still performs the same as the original and that nothing is 'lost in translation', while still being obscure enough that hackers and their tools are unable to make sense of it.
• Solving two difficult problems optimally is much less likely (and more expensive) than solving one, meaning if you use an all-in-one solution, you'll pay more for it, and be unable to replace any of the parts with more suitable solutions.

The Spy-vs-Spy game of code obfuscation and decompilation is a continual battle that is being fought by the black-hats and white-hats of the world.

Considering that there are several mature solutions for code protection available, that problem is one that we don't see the need to solve with Zarqon (and continually update to fight the latest decompilers). We choose to leave the code protection problem to experts in that realm.

We suggest that you do your homework on the available code protection solutions as well as the leading dissemblers for AS3.  Demos are available for all the products below, so you can try each decompiler product against each protection product and see the results for yourself.

We did quite a bit of research on the matter in order to protect our own product and our finding was that Trillix is currently the best decompiler, but we were still able to stump it using secureSWF. Honestly, the others didn't stand a chance against Trillix. In fact we liked Kindisoft's secureSWF protection product so much we decided to partner with them in order to help raise awareness about the need for code protection and to actively work together to find ways to bring increased value to our mutual audience.

BLACK HATS: The Leading Flash Dissasemblers

• Trillix
  
• Sothink
  

WHITE HATS: Leading Standalone Code Protection

• Kindisoft secureSWF
  • ASGamer Review
    
  • Untold Entertainment Review
    
  • Gareth Jones Review
    
• DCOMSoft SWF Protector
  • CNET Reviews
    
  • Gareth Jones Review
    
• Amayeta SWFEncrypt
  • Gareth Jones Review
    

Back to Top

Concurrent User Licensing

"With corporate use (one of my main targets) I see the need for license pooling or multiple user licensing.  Managing individual licenses is doable, but gets more labor intensive as the number of licenses increases.  Do you have anything in place or intended toward that type of management such as a single "license" that would allow only a specified number of installations at one time?"

Definitely. This is a major item on the Zarqon roadmap.

The target audience for Zarqon in the initial release is developers who have applications that they can sell to individuals and stratify their features in such a way as to capture the broadest possible audience. However, concurrent user licensing is an obvious premium feature for Zarqon and we do plan to address it.

Much like the issue of code-protection, concurrency is a separate problem, but this one is closely-related enough for us to want to solve with Zarqon.

There are two issues with concurrency:

• You must be able to keep a running count of the users that are currently operating. This requires either server side software (which we eschewed by design in favor of simple-cloud storage and a smart client), or imbuing the client software with the credentials necessary to write into the S3 buckets, exposing your S3 account to hacking.
• Even if the client were able to write to the bucket, there is a problem of 'hung logins'. Where an app is started, the number of users incremented, and then the software or the machine crashes and never logs out. The parity of login/logout is therefore difficult to manage.

We have several ideas about how to solve this problem, but we didn't want to shoehorn it into the first release.

Back to Top

Free Demo Without Having to Issue Licenses

"I want to virally distribute a functionally limited but non-expiring demo of my application that requires little or no activating effort / user info. Since that is basically unmanaged free usage, issuing individual trial licenses would be time consuming and place an ongoing load on the servers that equates to storage and transfer costs for me."

You're in luck, this couldn't be easier! It is entirely up to you how your app behaves when it is not licensed. Complete denial of operation is only one option.

When you start your application, all you need to do is check to see if a license is present and if not, create a license object internally that has only the features you wish to expose. Then use that license object in place of the fetched and decrypted license of a paying user.

How do you know if there is a license that needs to be validated?

• In the case of a desktop application, you will have stored the user's license in a local encrypted format if they have one. (i.e. the AIR Encrypted Local Store)
• In the case of a web application, you will check the parameters of the embedded object (i.e. FlashVars for a Flex app).

So, if your app starts up and finds there is a license in place, you can go validate it. Otherwise, it might nag for the user to sign up, or just provide a link to purchase. You could have an ad-supported free version that displays advertisements unless it is licensed.

You can even make your demo expire if you're writing a desktop application by storing your issue and expiry dates in an encrypted local store (such as AIR's ELS). Use these values when you create your internal demo license, and if the license is expired, you can downgrade or deny functionality until a valid license is obtained and entered (as the Zarqon Desktop Control Center does.

Back to Top

Encryption and Export Control

"I understand that the Zarqon API uses encryption. Doesn't the US government regulate the export of encryption products? How is Zarqon classified and how does it affect my product with respect to Export Control?"

Zarqon ( and apps using it that have no other reason for export control ) can be self-classified under the US Export Control Office's  regulations as ECCN 5D002 "Software designed or modified to use cryptography employing digital or analog techniques to ensure information security." Under ENC rules, export licenses, as well as review and reporting are not required.

• ECCN 5D002 lists EI (Encryption Items - Part 742.15) as a reason for control, and paragraph (b)(3)(iii) defines "Ancillary Cryptography" as an exlusion from review requirements.

• This is also reflected in License Exception ECN (Encryption Commodities, Software and Technology - Part 740.17) and applies to Zarqon. Here again, paragraph 740.17 (b)(4)(iv) "Ancillary cryptography." excludes Zarqon from review requirements.

• "Ancillary cryptography" is defined in Part 772.1. "Examples of commodities and software that perform 'ancillary cryptograpy; are items specifically designed and limited to: piracy and theft prevention for software, music, etc; games and gaming; household utilities and appliances, printing, reproduction or playback (but not video conferencing); business process modelling and automation (e.g. supply chain management, inventory, scheduling and delivery)... Commodities and software included in this description are not limited to wireless communiation and are not limited by range or key length."

A lot of research was required to arrive at this classification. The above citations back up our findings, and the following is the specific paragraph that summarizes:

Export Administration Regulations (EAR) Commerce Control List
Supplement No. 1 to Part 774
Category 5 Information Security
Paragraph 5D002.a
December 11, 2009

The following are countries where sales of strong encryption technology are prohibited.

• Cuba, Iran, North Korea, Sudan, Syria

The U.S. Departments of State, Treasury, and Commerce maintain lists of companies, organizations, and individuals with which U.S. companies are prohibited from trading. Futurescale is required to screen all export sales against these lists. Orders may be cancelled based on screening results.

If you do not live in the US, be aware that Zarqon may be subject to import/export control laws in your country and may be subject to export or import regulations in other countries. You agree to strictly comply with all such laws and regulations and acknowledge that you have the responsibility to obtain such licenses to export, re-export or import as may be required. Licensor cannot be held responsible for uses which may be illegal in the Licensee country.

Back to Top

Does Zarqon Require the use of PureMVC?

"Futurescale is best known for it's PureMVC framework. What if I don't use PureMVC? Does it play nice with other frameworks like Cairngrom, Mate, Swiz, RobotLegs, etc?"

Beyond Flex and AIR,  Zarqon doesn't depend on any framework.

Of course, the Zarqon Desktop Control Center is built on PureMVC and uses the Zarqon API for license control, but you are free to use whatever frameworks you like to base your application on. Zarqon has been specifically designed to work with any Flex or AIR application. The design is so generic, we are planning to release versions of the API for other major platforms soon, and the same will be the case.

Back to Top

What About Automating the Process of Issuing Licenses?

"Any plans to expose the issuing of license thing? I'd love to automate that process."

Not as such. The Zarqon desktop application is protected and the process of creating a license is not exposed, nor is the data. What a cracker wants is the ability to create a valid license. That's far easier than hacking the program itself.

What is being considered is the idea of implementing a 'watch file' queue that allows you to leave the desktop client running unattended and have it read the queue periodically looking for license requests. It would then create and issue the license. It might be a special AIR app that runs in your system tray rather than an update to the client. 

The problem becomes the format of the watch file. Since Zarqon licenses can be pretty complex, (with multi-level expiration, features and feature sets, etc) you will need to be able to specify all that in this file. And of course there'll need to be a lot of work in the client to support the automation process.

Regardless of the implementation, there'll be no server side version because that defeats the whole purpose of using S3 for cloud storage and a smart client to issue licenses. It negates the need for the server component and all the security and uptime issues that come with it.

Back to Top