Zugg Software :: View topic

Posted: Thu Apr 21, 2005 1:26 am

Good news (for a change). The Code Office "Bind2Exe" software that theNerd pointed me to actually works with PECompact. Specifically, I can bundle a ZXL file along with the *compressed* zAppLite.exe program, and rename it to something else, like MYAPP.EXE.

Then, when you run the EXE file, the ZXL file is extracted automatically and the application runs with that zApp program. The ZXL file is only extracted if it doesn't already exist, or if the MYAPP.EXE timestamp is later than the existing ZXL file timestamp.

So, what does this mean? Exciting news for developers! Let's say you want to create a zApp program called "EDITOR.EXE" and distribute it to people who don't have zApp. Follow these steps:

Create your EDITOR.ZML text file (obviously)
Run zAppPro IDE and encrypt your ZML file to a binary ZXL file
Make sure you have a copy of zAppLite.exe in your zApp directory (previously this was called the zApp Runtime edition)
Use the new "Compile" menu option in zAppPro and select the EDITOR.ZXL file that you created in step 2
A new EDITOR.EXE file will be created. This is actually the zAppLite.EXE with your EDITOR.ZXL file bundled with it
OK, now copy EDITOR.EXE to some computer and run it. When you run it, it will automatically extract EDITOR.ZXL and will then run it. Viola, it looks like a normal application with a small data file

Now, the real beauty is when it comes to updates. To update your application, just make the new EDITOR.ZXL file available to your users. They can download the tiny EDITOR.ZXL file, overwriting their current file. Now when they run EDITOR.EXE, zApp will load the new file and will not extract the original version.

This gives you the best of both worlds. A single file for users to download the first time, which looks like a simple application EXE file, and which is nice and small (min size currently is 2.7MB). For updates, the users just download the tiny ZXL file (which in the case of the editor demo is 8.4 KB).

I think this is a really cool addition to zApp functionality. I know that theNerd is going to be really happy about this ;) I'm amazed that the Bind2Exe program works with the PECompact program (given that their own PEBundle program *doesnt*). And since I was able to buy the source code for Bind2Exe, I was able to incorporate it into the zAppPro IDE.

Cool stuff! This will all be available in the next release, although I'll also need to update the zAppPro stuff for you to play with it. Hopefully tomorrow. I still need to finish the event handlers...got a bit sidetracked with this bundling stuff when I discovered that it actually could work.

Enchanter Joined: 10 Oct 2000 Posts: 698

This is a beautiful thing! I can't imagine developers not having to have zApp. Pure sweetness. Thanks Zugg.

Adept Joined: 01 Mar 2005 Posts: 277

AWESOME!!

Adept Joined: 01 Mar 2005 Posts: 277

Is this new technique compatible with eLicense?

Posted: Thu Apr 21, 2005 11:03 pm

Nope, unfortunately not. eLicense thinks the EXE has been hacked (which in a way it has). So this bundle will only work with zAppLite.

Adept Joined: 01 Mar 2005 Posts: 277

Posted: Thu Apr 21, 2005 11:21 pm

Oh, yes you can certainly do that. However, I can't see where you'd ever want to do this. All it would take is someone to upload your ZXL file to the Internet and then anyone could run your app with a normal version of zAppLite (or even the full version of zApp) without needing to buy your license.

The proper way to handle licensing for 3rd party applications is to create a DLL file that contains important code and then eLicense that.

I've still got an item on my "back burner" to think about how zApp could help with creating such a licensing DLL.

Also remember that I'm always going to be trying to encourage end-users to buy the full version of zApp in order to customize their applications. If you wrapped the zAppLite and ZXL file with eLicense, then you are essentially forcing the end-user to always use the zAppLite version rather than the full zApp version, which goes against the basic idea of zApp I think.

Were you thinking of something specific that you needed this functionality for, or were you just asking a generic question?

Adept Joined: 01 Mar 2005 Posts: 277

You made a good point that all they needed to do is copy the ZXL file. I must have been thinking with half a brain (in my defense my allergies have kicked in real bad the past two days.) Obviously, my intentions are not to prevent end-users from writing their own plug-ins, just to have some model for selling software.

The difficult thing with using an ActiveX DLL for eLicensing is that it's okay if your routines are very complicated and can't otherwise be easily by-passed, otherwise they can be hacked. In VB I can make a reference to any ActiveX DLL and explore its interface. Perhaps a built-in registration system (time limited that would require a key to be entered in order to unlock it.) True it would not work with eLicense but it could work with PayPal and Regit among others.

Posted: Fri Apr 22, 2005 2:10 am

Maybe we can all put our heads together and come up with some sort of protection scheme that would work. If there was something zApp could look for in a DLL that would protect it, then it wouldn't need complex code. Seems like there must be some sort of public/private key that could be used.

Maybe zApp needs a way to run a special kind of ZXL file that is embedded into a DLL, but doesn't work "standalone" without the DLL. Then you protect the DLL with eLicense.

I need to give this more thought, but it seems like between the eLicense protection and the encryption that I can do in zApp that we can come up with some sort of algorithm that is reasonably secure.

None of the built-in protection schemes for ActiveX controls actually work very well, and as you said, the ActiveX control would need to do something that the user really needed or else they would just delete your DLL file.

Anyway, let's brainstorm this some more.

Adept Joined: 01 Mar 2005 Posts: 277

If the ZXL file was added as a resource to the zAppLite and the zAppLite was wrapped using eLicense, could hackers still access the ZXL file?

GURU Joined: 10 Oct 2000 Posts: 867 Location: USA

Posted: Fri Apr 22, 2005 5:38 am

You can't add ZXL files as a resource to zAppLite. You can only link them using the Bind2Exe functionality in zAppPro, and when this is done, the ZXL file is extracted to the disk as soon as you run zArrLite.

You can add a ZXL file to a DLL as a resource, but it would be trivial to use any resource hacking program to extract that resource to a ZXL disk file.

Tarn is mostly right. I do think there will still be some non-trivial programs that can be completely written using zApp without having any additional compiled code in a DLL, and that's the case we are trying to figure out a way to protect. It's not just the controls that ship with zApp, it's the scripting code that tie them together. It would be nice if there was some way to license that scripting code. A ZXL file provides a nice encrypting method so that people can't see your scripting source code, but right now there is no way to "license" a ZXL file so that 3rd party developers can make money writing applications.

GURU Joined: 10 Oct 2000 Posts: 867 Location: USA

Adept Joined: 01 Mar 2005 Posts: 277

Here is another possible solution: Create a generic DLL that has the ZXL file as a resource. Use a hash algorithm like MD5 (or actually something better; MD5's been broken) and imbed the "fingerprint" in the encrypted ZXL file. When the ZXL file is loaded compare the imbedded "fingerprint" with the DLL in the directory and if it doesn't match up or is non-existent then throw an error. This would work hand-in-hand with a simple DLL that would contain a token function to be used (for example Tarn's idea of using the ProgData().) A token function is still important because if we are using something like eLicense we want the license DLL to load each time the ZXL file is run.

The nice thing about this is the Bind2Exe can still bundle this DLL with the with the zAppLite.

Edited to Add: Just for clarification, this is a standard DLL created by Zugg. This should be optional and an end user could still make an ActiveX DLL but the "fingerprint" idea should still be implemented for these. It should also be implemented to work with plug-ins, also.

GURU Joined: 10 Oct 2000 Posts: 867 Location: USA

Adept Joined: 01 Mar 2005 Posts: 277

Tarn, the DLL would have to be eLicensed before the hashing algorithm works. The function ProgData() loads the resource internally and returns the encrypted ZXL file to zAppLite so it will not appear as a hacking attempt. Also, a good hashing algorithm is not the same thing as CRC32. Some of the advanced hashing algorithms are guaranteed uniqueness for every file it checks. If you look at some major Open Source endeavors like FireFox the builds also include the hashed value. If it does not match up after its compiled them it's not the code they released. There are other hashing algorithms such as SHA512 that are guaranteed unique and have not been broken. It is not enough to be binary compatible. If *anything* right down to a single bit is remotely different it will return a different fingerprint.

Adept Joined: 01 Mar 2005 Posts: 277

Okay, I just caught my "catch-22". Embarassed

It sounded good up until the point of eLicensing it before creating the hash value. Rolling Eyes

I still think I am on the right track though.

Adept Joined: 01 Mar 2005 Posts: 277

Zugg, does eLicense prevent others from seeing the resources? I am of the understanding that the resources can still be read externally. I don't think it actually protects those.

Also, for clarification to others that may read this thread not understanding what is being discussed here: We are trying to look for ways to enable developers who have purchased zApp Pro to distribute ZXL files (compiled zApp programs) and be able to effectively sell them using a system like eLicense (which is what Zugg uses for his applications and seems to work quite well.) The eLicense system requires either an EXE or DLL in order to work. In addition, we are trying to prevent hacking and piracy.

The whole problem is not for those instances where there is a legitimate need for code in an external DLL. It's for those cases where the ZXL is self-sufficent. If I have to put all my code in a DLL and forget the scripting then the whole philosophy of zApp is lost. I have been promoting zApp to people I know encouraging them that if they can develop a web page they can develop real applications in zApp. These are people who will not be creating an external DLL and wouldn't even know how to. Also, I have ideas that have no real need for external DLL's either.

I haven't had the best ideas so far but I think all ideas may help. Very Happy

Posted: Fri Apr 22, 2005 7:30 pm

OK, I've been thinking about this some more and I think I have an idea that might work.

First, let me add some constraints to this situation.

It should not require a "special" version of zApp. You want the DLL file that contains the 3rd party application to work with the standard versions of zApp, both the zAppLite and regular zApp versions. I can't support multiple versions of zApp, and I want to make sure that end-users of the 3rd party program can always still buy zApp in order to write plugins and customize your application. That's one of the main features of zApp.

What I would do is add a second type of "ZXL" data that zAppLite and zApp could both load, but a format that only works when loaded from a DLL resource. Essentially it would still be encrypted, but I'd just use different encryption keys. So, lets call this new kind of data "ZZL" for discussion purposes.

ZZL data would only be processed when it is loaded from a resource in a DLL file. If someone was able to write this data to a normal disk file, zApp wouldn't load it. So that's the first step...it forces the ZZL data to be embedded into a DLL file.

Now, how do we keep someone from moving this data to a different DLL file? First, you wrap the DLL file with eLicense. To wrap a DLL file with eLicense you use a "ProductID" value which tells eLicense which product it is. This ProductID is used when eLicense contacts it's registration server to check and generate reg codes.

If zApp embedded this ProductID as part of the information encrypted into the ZZL data, then when zApp loads the ZZL data, it could extract this ProductID, and then call the eLicense API to see if this ProductID is licensed on the computer. If not, zApp displays the normal trial screen, or if eLicense is not installed on the system or the DLL is not wrapped with eLicense, then zApp just fails to load the ZZL data.

So, a hacker can't just take the ZZL data and add it to some other unprotected DLL file. When zApp checks the ProductID it would find that the DLL isn't wrapped correctly and would fail. They can't just write the ZZL data to a disk file since zApp won't load it from there. And any attempt to break eLicense would also cause it to fail.

The only way to get around it would be to patch the zApp code directly that is performing the eLicense checks. But since zApp itself is compressed, and parts of zApp are already encrypted to prevent tampering, this should be fairly difficult. In fact, I could even put part of the code into the DLL file itself, which is then protected with eLicense again (since the free version of zApp is not protected).

What I would do is provide this "clean" DLL to 3rd party developers. They would then use zAppPro to convert their application (or part of it) to ZZL data that gets embedded into this special DLL file. Then, they either wrap the DLL with eLicense themselves (if they are an eLicense customer already), or they send me their DLL file and I wrap it for them.

I am currently working with eLicense to put together an affiliate relationship where I can wrap DLL files on behalf of 3rd party zApp developers. I'd end up charging a small percentage of sales for this affiliate relationship. Because of the volume I currently do with eLicense, I can probably get an arrangement where the cost is less (or equal) to if you paid the price for your own eLicense contract. For smaller developers, it would be cheaper (or at least easier) to just have me handle the eLicense stuff for them. But big developers can bypass me and go to eLicense directly if they want.

Once I have some specifics from eLicense on pricing, I'll post more details. But I think the above method sounds pretty secure, so I'll let you guys try and figure out how someone might try to break it.

Adept Joined: 01 Mar 2005 Posts: 277

Can you at least hash SOMETHING to help my self-esteem a little? J/K Laughing

Your suggestion sounds very reasonable.

Posted: Fri Apr 22, 2005 10:57 pm

OK, I just finished a long phone discussion with the folks at eLicense and I've gotten permission to talk about more specifics. I personally think this is very exciting stuff, but I'll let you be the ultimate judge.

First, I should explain how eLicense works for "normal" developers. When a normal developer wants to sign up to use eLicense technology (like I do with zMUD, for example), you first pay a setup fee of a few hundred dollars (negotiated directly with eLicense). They ask you a bunch of questions, like the number of products, the cost of each product, your existing sales volume, etc, to try and judge how big of a customer you will be. They then quote you a rate of somewhere up to 20% which is the percentage of sales they will take as their fee. In addition, they typically charge a yearly fee of about $200 per product.

For these fees you are allowed to wrap your product using eLicense, and eLicense agrees to handle all of the ecommerce, including credit card fees, chargebacks, refunds, customer support (lost reg codes), etc. They collect all of the sales for your product, and on a monthly basis, they send you a check for your percentage of the sales. You have to meet a minimum of $100 fee before they send you a check. So, for example, if your negotiated fee is 10%, then you have to sell $1000 worth of your product before they send you a check for $900.

They *will* negotiate special deals, so you should take everything I've just said as a "typical" example. In the case of zMUD, for example, they deposit money directly into my own Cybercash (Verisign) merchant account and I pay *them* their fee on a monthly basis. This allows me to collect money daily without worrying about their $100 minimum fee. However, it also means that I'm paying the credit card fees, processing refunds myself, and dealing with lost reg codes myself.

So yes, it *can* be expensive for a small developer to get started with eLicense. They are really geared for larger companies and don't want to be sending out lots of checks for $20 a month to a bunch of small developers.

Because we were an early adopter of eLicense, Zugg Software has been their customer almost since their beginning and we have developed an excellent relationship. Thus, even though Zugg Software isn't a huge customer when it comes to money, we can get some special deals with them. We have contributed a lot to the improvement of eLicense over the years (those zMUD hackers have really helped eLicense improve their system ;)

OK, now on to zApp. For zApp, I obviously want to make it easier for small developers to protect their software. I think the inclusion of native support for copy protection like eLicense could be a bit selling point for zApp. eLicense isn't the only copy protection company out there, but the good ones are *all* expensive. And you don't see *any* development environment giving you built-in support for copy protection.

So here is how it would work for zApp 3rd party developers. First, you would need to register with eLicense to create a Developer account with them. They have agreed that for zApp developers, they are willing to waive their setup fee for this. However, I will probably still charge a setup fee of something like $50 to prevent casual people from doing this. I'm going to end up doing some administration for each 3rd party developer and I want to make sure that only serious developers sign up for this eLicense stuff.

OK, so you pay your setup fee and are now a recognized/registered 3rd party developer with eLicense support enabled. Now you write your application. You use zApp Pro as described before to embed your application into a supplied DLL file. You go into your own eLicense account on their web site and use their tools to create a new "Product". You give the product a name and a Product ID and you set a price. In their tools you set "Zugg Software" as the "Distributor" of your product.

Next, you send me your DLL file with the zapp file embedded in it. You tell me what your Developer name in eLicense is, and what the Product name is that you have assigned to Zugg Software. I go into my own eLicense tools and set up your product for wrapping. I then wrap your DLL with the appropriate information, encode some extra information into the DLL that zApp can use to make sure the DLL isn't hacked. Then I send you back the DLL, which you can then bundle with zAppLite and you put it on your web site, or sell it how ever you want to sell it.

Now, when a potential customer runs your application, they will get the eLicense trial screen. They can run it as a demo, or they can buy it. When they buy it, the money goes to eLicense. As the registered Developer of this product, you will collect 80% of the total price. The remaining 20% is split between eLicense and Zugg Software. The normal yearly fee of $200 per product will be waived. The minimum fee collected by eLicense before they send you a check (or wire transfer, or whatever) will be reduced from $100 to $50. You will get your money directly from eLicense (not from Zugg Software). Using the reporting tools in your own eLicense web account, you can track your own sales to make sure you are getting the correct amount of money and to keep track of your customers. eLicense handles all of the eCommerce stuff, including credit card fees, chargebacks, refunds, lost reg codes, etc.

All of this is subject to change, or course. I'd actually like to find someone interested in being a test case for this (grins at theNerd). I'm even willing to waive the $50 setup fee for someone that is serious about working with me on this. It might take a few interations to work out the nitty-gritty details and get all of it working properly. eLicense still needs to look into a few details on their end also.

So, to summarize, the advantage of using zApp with built-in eLicense support is:

Small one-time setup fee (about $50, just to keep away the kids and people who aren't really serious). Also, this fee can potentially be refunded once your software starts selling a lot.
Fixed 20% fee for handling all aspects of copy protection, ecommerce, chargebacks, refunds, lost reg codes, elicense customer support, and zApp interaction
No yearly charges
Minimum $50 in fees collected before sending each check (or you can get whatever money you have collected at any time by just paying this $50 minimum)

I've researched many different copy protection companies over the year and I think this is pretty reasonable. Also, if you start selling a lot of software, there is nothing stopping you from getting a normal eLicense account and negotiating a smaller fee percentage and getting Zugg Software out of the loop.

Also, keep in mind that this isn't just an ecommerce solution. The copy protection is an important part. Obviously if you just want to sell your software without any protection then you can just sell it via a PayPal account or something. But ecommerce services such as ShareIt or RegNow typically take anywhere from 10%-20%, or have a fixed fee per transaction. So I think this eLicense deal is pretty competitive.

How does this sound to everyone?

Posted: Fri Apr 22, 2005 11:08 pm

Very exciting :D ^^

1 question... what about the serious kids *looks innocently about himself*

Adept Joined: 01 Mar 2005 Posts: 277

That sounds terrific! My serious development efforts begin tonight and continue with your next weekly build (looking forward to that Cool

.)

Adept Joined: 01 Mar 2005 Posts: 277

Question: What if the developer wishes to update their DLL (bug fix, whatever?)

Posted: Sat Apr 23, 2005 2:55 am

If the code in the DLL changed, then you'd need to re-embed the "ZZL" data using zAppPro and then send it to be to have it rewrapped with eLicense.

Yeah, that can be a bit of a pain. It's the main reason I set up a special relationship with eLicense so that I can wrap stuff myself because in the early days of zMUD I needed to rewrap a new version almost every 2 weeks, and at least at that time, eLicense charged each time they wrapped an app for you (I think they still do), so they set up my account so that I can wrap stuff myself.

But yes, it is assumed that you don't wrap your application with eLicense until you are ready for a "real" release, and that you don't need to change the DLL very often.

I think one good strategy is to embed the core application into the DLL file, then have a separate ZXL file that contains most of the code for your program. Then, in your "main program" within the DLL you just do simple stuff and call the code in the external ZXL file. Since both the DLL code and the ZXL file are encrypted, nobody should be able to figure out what you are doing in the DLL file to call the main application code.

Or, to put it more simply, put the code that is likely to change in the ZXL file, and the code that is stable in the DLL. Then you don't have to release a new DLL all the time and can just send updates for your ZXL file.

It's possible that we will be able to set this up so that developers can wrap their own applications. I'm waiting to see exactly what is involved with that. If it requires that you know the secret vendor ID and vendor security information for the distributor (Zugg Software in this case), then I won't be able to allow you to wrap it yourself since I won't want to give out this information. However, if you can wrap it with your *own* vendor information with eLicense and still get the distributor stuff to work, then it should be easy to allow you to wrap it, and I can add a function to zAppPro where you enter your product information for embedding with the ZXL file into the DLL.

This is just one of the little details that we'll need to figure out when actually trying to make this all work the first time.