Runtime Antipiracy

[MSPJ]

Hi - I'm aware that this issue has been discussed before, but none of my searches have turned up any real thorough discussion of many of the specifics. So I'm hoping I can get some input from folks here.

I have a runtime solution I wish to distribute commercially to a consumer market. I would hope to have too many users for any kind of custom coded approach.

I am aware of the many 3rd party tools for protecting the exe part of the runtime, but the actual database file can of course still be opened in FM software. Removing admin access prevents someone from learning the structure, but does not prevent them from simply distributing it themselves.

I intend to use one of the software registration services (like Regnow) to handle the generation and delivery of keys, so creating code within the db itself to check for a key is not good since then I would need to handle generation of keys.

I have had a few thoughts on possible solutions, and wanted to get some feedback.

I believe it's possible to check that the db is being run within a runtime - is that correct? If so, how? That at least would keep someone from simply distributing the database file as is, or using it with their own copy of FMP.

BUt how would I keep someone with FMP advanced from creating their own runtime from my database and distributing that?

Can the db check the binding code that was used to generate the runtime and quit if it is incorrect? THen someone who did not know my binding code could not create a functional runtime.

Alternatively, is there any way to check something like a registry key from within a FMP pro solution?

Or, since dll's can be protected, is there any way to interact with a dll in some way that would allow the db to check whether it was properly activated?

Thanks for any help!

Michael

[MSPJ]

More from the topic starter:

I came across a possible way to accomplish this, though not as easily as I'd hoped. Wonder what you all think.

Software passport can set environment variables that are accessible to a VB or C++ program. You can also run a FMP script via VB or C++, I think.

So theoretically, you could write a small program in VB for instance that would check an environment variable, set by software passport to indicate if program was registered, and then the program would run one of two macros in FM - one that would set a global to say it was registered, and one to set it to unregistered or stop the program if expired , or whatever.

Does this sound reasonable?

I don't have any VB compiler - Visual Studio Express is free, but appears to require .net - I'm hesitant to require users to download and install .net framework just to check registration on my database.

Thoughts?

Thanks,

Michael

[MSPJ]

Hi -

I've seen people on the forum refer to being able to have FM check if it's running in a runtime or not. If this can be done, how does one do it? I didn't find a Get function that would provide information on whether running in FM software or standalone runtime.

Thanks,

Michael

[comment]

Check out the Get(ApplicationVersion) function.

[IdealData]

Don't you need the master password to run the developer tools to generate a runtime?

What's wrong with the licence code check? Won't you need your clients to register and PAY YOU. If there's that many customers then it's surely worth the effort now.

[MSPJ]

No - I just tested this - you can generate a runtime from the database without ever being prompted for a password of anykind.

Not sure what you mean about license code check - my plan was to use a 3rd party tool (Software Passport - Digital River Edition, with RegNow as distributor) to require registering (purchase) but it only works on .exe or .dll files. Nothing would prevent someone with FMP Advanced from generating their own runtime which would then not have any protection.

Of course I could have the license checking code in the database itself, but there doesn't seem to be any way to do that without my needing to handle the assignment of codes - I'm trying to avoid that.

Michael

[MSPJ]

Thanks comment - I assumed that only returned the version number - didn't realize it also returned the "flavor" of application software. That's what I needed.

[Carole Chaski]

What did you decide to do? I am facing same problems.

[MSPJ]

Hi Carole - Don't know if you're still monitoring this thread. Here's where I am so far:

I'm using Software passport to protect the actual .exe file. I'm not going to worry about hackers cracking that - there's only so much effort I'm willing to go to for an inexpensive program.

I have a script that checks to make sure my db is being run in a runtime - that would prevent someone from opening the db from their own copy of Filemaker. This script gets run periodically during normal program operation, so even if someone bypassed the open script, it would eventually close the program.

I still have not solved the issue of someone simply rebuilding their own runtime from my db. Despite what filemaker support claimed, the runtime generator does not balk at making a new runtime from a db that was previously bound with a different bind key. Granted, one would have to have the FM developer software to do this, which is way more expensive than my program, and probably most hackers don't have it - but it is still the weakest link for me. I'm looking at various clumsy options for checking things like filesizes, dates, environment strings - they are all easy to get around by someone who knows what they're doing, so I'm not sure it's worth worrying about.

I don't know why FM still hasn't addressed this even in version 9.0. It doesn't seem like it would be that difficult to have the developer program check for a previous bindkey.

That's where I'm at, however.

[Barrettb]

I was just contemplating the same issues and about to post for FM9....

I'll have to add this to my list of reasons to

It never ceases to amaze me how development managers not just at FM manage to leave out solid globally usable sensible functionality. Now to ice the cake they are usually such big operations you can't even get through all the layers past the script readers.

In this case it is obvious that FM should have included a built in licensing/demo anti-piracy feature no more complicated than setting up and Adobe pdf.

Common sense I say.

[whun450]

One thing I've done is hide the runtime like this. Let's say I have an application named "software". I will change the name to something official sounding like "dcomlink" and then compile using that name as the runtime name and the extension as dll.

After I compile, I will rename the exe as "software", and leave the dcomlink.dll alone.

I've never had a problem with the software opening and working the way it should.

Filemaker users know to open the 'usr' file to open your software, but they won't open every dll to open it. The key is doing it the way I said so that the .dll name is completely different than the exe name. I've never had trouble with using dll but you can use whatever extension you like but dll blends in well.

Hope that helps

William