Note: Issues with Runtime distribution and demos

[GaryRockley]

Re: Note: Issues with Runtime distribution and demos

Hi Chet,

Jeff pointed me to this and I think you raise a very good point.

I'm also glad that I'm not the only paranoid dev who looks for quirky ways to circumvent things.

Just a quick thought, I saw a post from, (I believe Dave M) suggestiing that command line args can be included in a vb.exe wrapper - which seems like a very good idea.

So..., can vb.exe propogate or create the runtime.exe on app load and destroy it immediately after?

For example, user clicks on exe that is essentially a vb wrapper for the launch & startup commands, also copying [whateverfilename] to 'runtime.exe' prior to running the app start. So, you would ship the vb.exe, along with [whateverfilename] - renamed runtime.exe when vb.exe is launched.

I'm treating this more as a logic/thought experiment than any effective test but seems that, unless runtime.exe must reside on disk, once the rt.exe is loaded into mem to run the app, it's physical presence is no longer required.

If this is true, and I'll test for it once I download and install A5, then runtime.exe can be called anything within the ship files, and only created/destroyed on app load. This avoids the problem of any user just starting runtime.exe (because it doesn't exist) and seeing the RT lic key via the about screen.

Thinking further, the vb.exe wrapper could write the runtime license key to the registry, copy whateverfilename to runtime.exe, launch the app, kill runtime.exe (if allowed), kill/rename the license # in the registry.

Should all happen before a use could interrupt....

But, just a thought.

Regards,

Gary

[DaveM]

Re: Note: Issues with Runtime distribution and demos

Gary,

My exe is no wrapper. It simply starts Alpha with the proper switches that I choose. If you change the name of Alpha5.exe to something else, the start.exe has to be remade so it knows what to do..

My operation is in a bootstrap adb. On start, it runs it's autoexec and does whatever I want and then destroys itself. On second run, the actual adb is used. bootstrap.adb runs, renames itself or destroys itself after starting another file that simply renames a shipped adb to the name needed for the app.

Bootstrap destroys the runtime installer if it had to be sent with the install. Not my exe.

I also have my runtime and the app in the same folder. For me, this makes sense and is easier. Others may do it differently.

Using astrum installer, i send the needed registry entries, register some dll's, set the hidden files that I need, run any other exe files I sent with the app, and start the program.

The app has the registration built in so if you move it to another computer, it needs to be re-registered. There are three checks now(newest way for me), then it builds it's reg code and I have to supply an answer. The code is always different now making the answer always different. I also just moved it so the answer code given can give a 15, 30, 60, 90 day demo time or make it unlimited.

There is only one way to get to the back of my app. So far as I know, it has not been beaten yet. I did have it tested by a couple of hackers I know that can open MS stuff like a tuna can with a built in can opener. They open other really big stuff too when they want.


Make sense?

It just all depends how far you want to go with it and how much time you want to spend on it.


.

[GaryRockley]

Re: Note: Issues with Runtime distribution and demos

Hi Dave,

Interesting reply, & thanks for that.

I meant no insult by referring to your suggestion as a 'wrapper'. Just thought your previous post was a good idea - to encapsulate in that manner.

As I move forward, I'm certainly interested in installers that can also include in the build, required dlls etc.

I'm always interested in anything as it relates to security.

fyi, for users cloning and moving from one PC to another, we trap a lot of h/w id stuff at install but, as you know, when it comes to security, nothing is foolproof.

I like A5's ability to use Win APIs. This is very useful because one of the most effective methods we have discovered in preventing license abuse is using what we call 'active licensing'. With this, we can allow users to 'share' a license - even if one user is in London and the other in New York.

But we can also absolutely determine if multiple users are accessing the same license (say via VM, Roaming Profiles, T/S, cloned copies etc.)

In this regard, I believe I may be able to offer some useful suggestions regarding preventing licensing abuse, as we move forward.


Regards,

Gary

[CALocklin]

Re: Note: Issues with Runtime distribution and demos

Hi Cal,

I'm curious, and don't want you to give away any secrets, but how does VM-Ware in this regard factor in?

Sorry, I didn't see this until just now.

My original routine only worked with locally run apps on a network. However, I ended up creating a modified version to work with Terminal Server - just don't ask too many details right now because it's been so long I don't remember them. I'm pretty sure it just limits how many users can access the app at one time. I don't think there's any limit on where they can access it from.

Those are the only two situations I've addressed so far because I'm very sure none of my users has anything else and nobody that has purchased it has asked for anything else. (In fact, none of my users have TS but someone that purchased the registration routines asked me to add that capability.) I'm not sure if the requirements for VMWare would be the same as those for Terminal Server or not.

[GaryRockley]

Re: Note: Issues with Runtime distribution and demos

Hi Cal,

Thanks for the response.

fyi, MS changed the protocols for startup of TS.

Used to be that start command: %windir%\system32\mstsc.exe /console would load TS with the active desktop (as if it were the active sesion)

With newer versions of TS, you need to use %windir%\system32\mstsc.exe /admin to see the active admin desktop. Otherwise, a seaparte session is reated which will load a clone of the admin account - assuming permissions approved.

I mention it because:

* ms never made it generally known that they did this.

* It could be important if you have a client running newer versions of TS and your code had specific params.

Beyond that, my concern, and I'm sure anyone else who has apps delivered on a 'per seat' basis', is that the cloned admin account delivered by TS essentially allows multiple users to access the same app, but isolated from the other accounts.

VM works in a similar way but handles each user as a separate and isolated instance, requiring a user logging in to start any apps from scratch. (although still isolated from other sessions).

Either scenario allows multiple instances of a single licence, VM just handles the start-up differently. But, the ramification is that even if the license is per seat,. it is possible for say 20 users to access a single license, which is obviously not beneficial to any dev who licenses on a per seat basis.


Regards,

Gary

[DaveM]

Re: Note: Issues with Runtime distribution and demos

Gary,

FYI
When I send an app out as a 5 user, I have buried code in the app that limits all to 5 users. I read the muff files to determine how many users are on the application and if it exceeds the 5, then it will not open the 5th instance.

Another app that uses a nodes type of control, each computer name is used along with some other stuff to stop a new node from starting up.

Ok: let us say a user is on the nodes system and drops a new computer on a lan and copies the runtime from another or reinstalls from one of the disks. The app gets shut dow on start up even after they call me for the startup code they need for that computer.

make sense?

Remember, I only do desktop apps and all of them are using shadowed even if there is only 1 computer involved.

.