Protect Code by time

[Raphael Schwietering]

Hi, Did someone have Code snippet to make ea as Demo.. For now i use Hard coded expire time. But i need an idea how to make Demo like.. I put ea for download on server.. Than ea can work for 10 das for Example. So i dont want to change everytime the expire date.. Must be something with servertime plus 10 days than expire.. 

[Flavio Javier Jarabeck]

Raphael Schwietering:
Hi, Did someone have Code snippet to make ea as Demo.. For now i use Hard coded expire time. But i need an idea how to make Demo like.. I put ea for download on server.. Than ea can work for 10 das for Example. So i dont want to change everytime the expire date.. Must be something with servertime plus 10 days than expire.. 

You can write a file on the FILES global MT5 folder and put an obfuscated number/string which represents the user Registration Date. Then, on each OnInit() you check the current terminal date against this value.

Obviously if the user manages to find, identify and delete this file, he could run your demo again, but working with probabilities of this happening and if you, e.g. hard-block the Quote/Stock being tested in the EA, it could be an effective solution...

;)

[Stanislav Korotky]

Raphael Schwietering:
Hi, Did someone have Code snippet to make ea as Demo.. For now i use Hard coded expire time. But i need an idea how to make Demo like.. I put ea for download on server.. Than ea can work for 10 das for Example. So i dont want to change everytime the expire date.. Must be something with servertime plus 10 days than expire.. 

Register it on the server using WebRequest, then check days passed since registration again using WebRequest on every startup.

If your server is running Windows you can recompile your demo from source on every download (the source should #include a temp file generated from current timestamp).

Other time solutions will not work. So hard-coded time limit is the easiest one. Or choose other limitation for the demo, such as missing functions, minimal lot, specific work symbol(s)/timeframe(s), etc.

PS. There is also a solution with a helper script, but it's not so convenient for end users, so you do not want it probably. It only makes sense if you sell a large number of products and all of them use this script for registration.

[Anthony Garot]

I had a thought on this that does not specifically answer your question, but @Minions Labs and @Stanislav Korotky have already answered that.

My idea is to simply bite the bullet and re-compile the indicator periodically, but be less stringent with the timing. Do you really need to be so exact with 10 days?

For ease of example, say you want to give them a 30-day trial.

The month prior to that 30 days, you set the expiration date for twice that, approximately 60 days from the current date.

Thus, anyone who downloads day 1 actually gets 60 days instead of 30 days. They are surprised and elated at their good fortune! Maybe they tell their friends who also download a copy for evaluation.

Continuing, anyone who downloads on day 29 gets 31 days instead of 30 days. They were expecting 30, they got 1 day extra. They are still surprised and elated, even though they are getting only an extra day.

Then, on the first of the next month, you re-compile.

Thus, you only have to re-compile a new version 12 times a year, your potential customers are given a boon, the .ex4/.ex5 is totally unusable after a certain time, and you didn't have to put a lot of time and effort into creating a system to secure it.

[kypa]

Public key cryptography was invented for that.

[Flavio Javier Jarabeck]

I've been there in other projects not related to MT/MQL and I can say this, do not burn your eyebrows off thinking about the best method. Just be practical. The effort to hack your EA is directly proportional to the value of it. If we are talking about a 10USD product, I would put some Global Terminal Var and forget it... If we are talking about your Golden Egg of your lifetime, sure, I would go to have an full-redundant internet host to authenticate every single day the user would use it... And also send an alert with a gigantic Cease and Desist box showing the IP, whatever (account, maybe?) and scare the hell off of him/her.

In the end it is always the relationship of Hack Effort X Value(benefit) of a Product...

Cheers from Brazil!

;)

[nicholish en]

Stanislav Korotky:

Register it on the server using WebRequest, then check days passed since registration again using WebRequest on every startup.

If your server is running Windows you can recompile your demo from source on every download (the source should #include a temp file generated from current timestamp).

Other time solutions will not work. So hard-coded time limit is the easiest one. Or choose other limitation for the demo, such as missing functions, minimal lot, specific work symbol(s)/timeframe(s), etc.

PS. There is also a solution with a helper script, but it's not so convenient for end users, so you do not want it probably. It only makes sense if you sell a large number of products and all of them use this script for registration.

Don't forget that MQL has a built in macro for just this sort of thing. 

if(TimeLocal() > __DATETIME__ + PeriodSeconds(PERIOD_D1) * 10)
   return INIT_FAILED;

[Alain Verleyen]

nicholi shen:

Don't forget that MQL has a built in macro for just this sort of thing. 

I think Stanislav proposed WebRequest and server to avoid people playing with their computer's clock.

[Stanislav Korotky]

Alain Verleyen:
I think Stanislav proposed WebRequest and server to avoid people playing with their computer's clock.

Not only this. According to the initial requirement, WebRequest allows to implement fixed checkup (hense no need to recompile the product for every new time limit) and delegate all variable things to the server. But __DATETIME__ was suggested instead of #include I think, which is about the method with adhoc recompilation.