Personified Announces J2EE License Management Tools


News: Personified Announces J2EE License Management Tools

  1. Personified Announces J2EE License Management Tools (18 messages)

    Personified Technologies today announced the availability of GetEngaged License Management for Java. GetEngaged allows you to break J2EE apps into multiple editions, read strongly encrypted license files directly from EAR, WAR or JAR resources through JNDI lookups, manage which features contained in which editions are active at runtime, and more.

    Checkout Personified Technologies.

    Read the Press Release

    More info
    GetEngaged allows a J2EE Application Developers or ISV to

    - Break an entire J2EE application into multiple editions

    - Read strongly encrypted license files directly from EAR, WAR or JAR resources through JNDI lookups

    - GetEngaged manages which features contained in which editions are active at runtime

    - Distribute one JAR with every edition of your J2EE application and do that from just one code-line

    - In place upgrades from edition to edition without any need to ever redeploy your application. Customers simply enter a new Package ID and GetEngaged handles the upgrade

    - Built in Ant tasks generate source libraries, license files, and Package ID's easily integrating into your existing build and deploy scripts.

    Threaded Messages (18)

  2. I don't know anything about the product yet, but I like the attitude:


    Cameron Purdy
    Tangosol, Inc.
  3. This product seems geared to demo/feature-based licensing. Although the docs at this site provide an example of how you could detect the number of times an application has been run, I am looking for something closer to generalized metering (e.g., your user buys a license allowing the creation of x objects). I have written code for that in the past - just wondering if anybody has experience with something similar in a commercial product.
  4. John,

    Metering can be handled by the use of our Engagement Rules Engine. A rule has access to persist and read any value directly from the license file.

    This is exactly what our evaluation edition is doing. Our evaluation edition only creates licenses that can be executed 10 times. We count each execution, and persist the data into the license file itself.

    Our Professional Edition due in Q4 will include some pre-built rule packs including time based metering as well.

    Dave Wolf
    Personified Technologies LLC
  5. Sceptical about metering solution[ Go to top ]


    You claim that you are saving the usage (e.g. number of times program was run)
    in the license file itself. Let's say I create a copy of the license file
    after the first run, and then after I quit I always replace your newly saved file with the original license file.

    How does your software get around that?
  6. Can you also use this product with Swing-based applications? I think so, but I just want to make sure before I dig any deeper...
  7. Yes. The GUI tool we provide is a swing based GUI and we lock it down using GetEngaged. We actually protect GetEngaged and its tools with GetEngaged itself. We're eating our own dogfood :)

    Dave Wolf
    Personified Technologies LLC
  8. <Dave>
    We're eating our own dogfood :)

    Looks a lot tastier than dog food. :)

  9. The product may look nice, but can you tell us, how safe it is and where is the proof for that?

    How exacly, encryption of the license may prevent the software piracy?
  10. Please feel free to do a few things.

    1) We host our own discussion forums for support. You can find those at

    We'd be glad to go into incredible detail about our license encryption technology, as well as other innovations we have in protecting the security of license keys. Those discussions are best had there and not on the TSS front page :)

    2) You should feel free to download our documentation available at

    We believe firmly that any security or encryption vendor MUST document and describe their security models and algorithms. We use both asymetric as well as symetric key encryption, constantly shifting symetric keys, crytographically secure psudeo-random number generation, hashing and check sums to assure that neither the license file nor the runtime classes are manipulated.

    You might enjoy reading this site

    A few points brought out here.

    "If the vendor won't tell you exactly and clearly what's going on inside, you can be sure that they're hiding something, and that the only one to suffer as a result will be you, the customer. "

    We are extremely comfortable with our use of symetric and asymetric algorithms, so much so that we fully disclose on the professional edition how our engagement techniques work.
    "Avoid software which uses secret algorithms."

    We don't use secret algorithms. We rely on a combination of secure hashing, symetric, and asymetrical cryptography.
    "Beware of any vendor who claims to have invented a ``new type of cryptography'' or a ``revolutionary breakthrough.''"

    We don't make any such claims. We rely on trusted and very well researched algorithms and models.
    "Some vendors will claim their software is ``unbreakable.''"

    No software is unbreakable. We don't claim that our software is unbreakable. Genough time and money, nothing is impenetrable. But realize it doesnt need to be unbreakable. It needs to simply cost more to break the system then it costs to acquire the software through legal channels.

    Finally, this is why we created our TrustedSource(tm) program. This program provides access to our source code to government and university researchers to provide code and security review of our approaches and algorithms.

    If there is a problem, we'll be all over it.

    Dave Wolf
    Personified Technologies LLC

  11. Dave Wolf

    >Personified Technologies LLC

    Not The Scupper Group? Moved again, Dave?
  12. David

    We have had a similar licensing product available for over a year now.


    Your product certainly seems better in the fields of license management and in being more "J2EE aware".

    However I'm less convinced about your security.

    You quote from:

    An excellent article, and when designing security software it is advice with which I would 100% agree. However, as you quite rightly point out, licensing software is never "secure", at least not in the cryptographic sense. Unless you have an option to always force users to provide a password, or some other cryptographic token then the keys used to perform your decryption and signature verification, or the algorithms used to derive them, must be held in the clear either somewhere in your code or in the license file itself. They may be obfuscated in some way, but they must be accessable.

    Normally it is the strength of the key along with the use of proven algorithms which protects security software. However I would argue that using standard algorithms for licensing software just presents the attacker with one less hurdle to jump over, and that after all is all that licensing software is: a series of (hopefully) difficult obstacles to bypass. For example, suppose you are using RSA to encrypt your licenses. If I can locate your public key in your code (say), then I can easily substitute my own public key and use the corresponding secret key to generate licenses to do whatever I want. If the algorithm was proprietary then I would find it much harder to generate acceptable keys and would probably require the skills of a professional cryptographer (which I am not) to help me.

    Regardless of this though, it is not the strength of the encryption algorithm which protects licensing mechanisms. None of those who have successfully attacked our own product have attempted to do so using brute force methods. They have always looked for weaknesses in our code. For example suppose an attacker finds a line in your licensing code that reads:

    if (license.invalid()) throw XYZException.

    The attacker won't bother with the encryption keys any more, they'll simply comment the above line out. If the licensing classes are signed in order to detect such changes, then the line of code which verifies the signature will simply get commented out as well. More likely than not though, an attacker won't even bother with the licensing libraries themselves, they'll simply find the application code which invokes your libraries and disable it there.

    Like you, we do not claim to be bullet proof. As you're clearly aware, that is impossible for this class of components. However our own product goes to extensive lengths to protect both the code base and the various keys used both within that code and within the licenses. We obfuscate and encrypt the licensing classes uniquely for each customer. This makes it more difficult for the casual users of decompilers to see what our code does and makes it harder for attackers to find the license verification code within the customer's application.

    Even if an attacker successfully bypasses this, we also include a serious of challenges which our customers can use to verify that a valid license for their product has been successfully validated. This means that simply bypassing the initial license verification would not give the attacker the access that they desire. They would also have to detect and bypass the various challenges or successfully decrypt one of the license files in order to respond to those challenges. I see no mention of any of these type of counter measures in your current product (or am I simply missing something?).

    In short, given that licensing schemes can never be cryptographically secure anyway, I believe that this is one case where secret and proprietary code is actually better than public code that uses standard algorithms.

    Would you care to comment?


    Peter Hearty
    CEO phWorks

    Tel: +44 (0) 20 7511 0737
    Fax: +44 (0) 870 458 1627
  13. Hi Peter,

    I'd be glad to comment :)

    We have had a similar licensing product available for over a year now.

    Actually our products don't really compete. GetEngaged is not just "license checking". GetEngaged allows ISV's to break up their single code line and application into multiple editions. Sell those targeted editions to targeted customers. Allow those customers to upgrade from one edition to another edition without ever re-installing. In the end, the goal is not to simply prevent stealing of the bits (although this is VERY important) but to also make it fundamentally easier for customers to pay for their software. The combination of stopping losses from piracy, reducing development and maintenance costs while increasing revenues from upgrade attach is in our minds paramount.

    Unless you have an option to always force users to provide a password, or some other cryptographic token then the keys used to perform your decryption and signature verification, or the algorithms used to derive them, must be held in the clear

    A few thoughts here. First, remember this is J2EE, and therefore server applications. It is not quite reasonable to "challenge" users for a credential. In all likely hood the system is running on a headless server box in some small dank dark closet. We cant have password boxes popping up for people to verify the server (not to be confused with J2EE security) It is also very important to understand that the EJB and therefore J2EE spec forbids the use of custom class loaders. To quote the EJB 2.0 spec

    "The enterprise bean must not attempt to create a class loader; obtain the current class loader;"

    So loading of obfuscated "challenge classes" such as phWorks is not only illegal, but would fail in most every J2EE container.

    algorithms used to derive them, must be held in the clear either somewhere in your code or in the license file itself

    Our encryption of the keys is based on symmetric encryption. The symmetric key is based on a static 'portion' and a dynamic 'portion'. The static portion is stored anywhere the ISV chooses. This could be protected with PKI, PBE or simply obfuscation. However the dynamic portion is a constantly shifting pseudo random value that changes at every read/write of the license. (I would refer you to FIPS 140-2) That key is stored in an encrypted fashion itself, so in this case the key encrypts the key.

    In our Professional Edition due in Q4 of this year (not a shameless plug for me it was my news article <wink>) we will include an XML web service which acts as an online and automatic "challenge" server. We will use strong but well documented and public encryption schemes to further protect that exchange.

    Realize that it doesn’t need to be impossible to hack the licenses. It needs to cost more to hack it then it costs to legally license the bits AND it needs to cost that much every time. We believe we have a design which can accomplish that.

    The attacker won't bother with the encryption keys any more, they'll simply comment the above line out.

    Modification of the code is always a concern with every J2EE app. There are a few solutions

    1) We digitally sign our JAR file to reduce tampering with them

    2) We implement our own hashing routines to prevent the modification of our code. If we detect a checksum violation we will shutdown the system. In the Professional edition we will destroy the license file when we detect that either a dictionary attack or a checksum violation.

    3) We recommend our customers use well described obfuscation technology.

    In short, given that licensing schemes can never be cryptographically secure anyway, I believe that this is one case where secret and proprietary code is actually better than public code that uses standard algorithms.

    Here is how I feel about it. Sitting in universities all over the world are PhD's with 1.7 zillion times better math skills then me. They have bet their careers and reputations on the algorithms they publish. I feel a lot more secure betting my reputation on their published research then assuming my "secret and proprietary" solution is better then theirs. I used to hold a Faculty Research Associate position at the Univ of MD. Those people at the UMIACS super-computer center are a ton smarter then I am :)

    This is another reason why we created TrustedSource. To allow university and government researchers to review and comment on our designs and algorithms.

    Yes, someone is going to hack our product. And we are going to fix it. Every time. But in the end, we provide serious value that no other license management solution on the market today provides, with our standard edition. Our professional edition is due this fall and will take our innovation places no license management product in the java space can touch.

    I hope you enjoy the Evaluation Edition bits you downloaded. :)

    Dave Wolf
    Personified Technologies LLC

  14. <andrew>
    Not The Scupper Group? Moved again, Dave?

    Actually not really "another" move. Simply didnt want to put advertise Personified until we were live. I've been with PTLLC since moving back from WA state. There is nothing more fun then driving a 30 foot truck hauling your own truck 2900 miles across the country in 6 days :)

    Dave Wolf
    Personified Technologies LLC
  15. I'm still waiting for the answers on my questions. Here you are talking with the developers, but not managers. Please use our language then.

    I'm pretty sure, that any software that uses "if( lic.featureIsAvalialbe())..." can be broken in a few seconds and any licence encryption not going to help for that case.

    I've seen the "success story" when some company released the new version of their product that uses the expensive FlexLM license manager... You will not believe, but pirates release the "patch" for demo version just one week later. And the sad thing is that "pach" turns that demo into the complete enterpise version of that pretty expensive product.
  16. Using encryption to secure software licenses will never work. Encryption is based on the assumption that you have a secure source and sink for you information, and with software you simply can't trust you user. The only way to protect software is to not give it to your user, which means keeping it on the server or sending them an iButton that runs your core (stuff you would leave on the server). Given that you plan on distributing your software, you are left with making it more expensive (in time) to crack your software then it costs to buy it flat out. The problem with Java is that it is way to easy to decompile (I bet almost everyone reading this list has decompiled Weblogic to fix some bugs). Game Developers Journal has a quite a few good articles on making software very difficult to crack.

  17. Dain

    I know I'm being lazy here, but do you have a link to Game Developers Journal. I'd like to read some of the articles you mention.


  18. Eugen,

    We have posted a document on our site which we think will help step through many of your concerns and questions. Please take a moment to review it at

    Dave Wolf
    Personified Technologies LLC
  19. This is a great product idea. I feel one of the main reasons the J2EE component marketplace hasn't exploded is because of the dilemma of developers/companies fronting money for black box components. As a developer it is very difficult to decide to spring a few grand for a set of components that will 'hopefully' fullfill a projects needs and are 'hopefully' developer friendly when, of course, I could code the same functionality in a couple of days :) . Certainly the smaller component vendors will not release their components for trial based on the honor system either. With products such as this vendors who produce reusable components and get them into the hands of developers for a limited free trial so the ROI of such components is discovered by use rather than marketing propaganda.