Experts: Adding password protection to your Indicator / Expert Advisor
congratulations
nice works
keep the same great posts
:)
congratulations
nice works
keep the same great posts
:)
Thanks (again) Mohammad!
Cheers!
Thanks (again) Mohammad!
Cheers!
Hi Claude Beaudoin
so much thanks for your great efforts and sharing it to public.can you explain it more in a different situations,generally it will be add inside code (indicator/EA) you provide to client/user,and that indicator/ea will be work only with the client according his ID (terminal information's + account number/s) if differ,it will not work,right ?
regards
Hi Claude Beaudoin
so much thanks for your great efforts and sharing it to public.can you explain it more in a different situations,generally it will be add inside code (indicator/EA) you provide to client/user,and that indicator/ea will be work only with the client according his ID (terminal information's + account number/s) if differ,it will not work,right ?
regards
Hi mntiwana,
Yes that is correct. Let me give you an example...
You created an EA that you've included the code I provided from the Password_Check.mq4 and you have Password defined as an input string to the EA.
Your client that has just purchased your EA runs your program without entering a password. He'll get a unregistered dialog informing him to contact you and provide the registration displayed in the dialog. (See Password_Check picture attached).
Now you run the Password_Generate program and enter into the Client field his name and account number. In this case it was "Claude G. Beaudoin / 1215949". This program displays a dialog with the registration password generated that your client needs to input into your EA. The password generated in this example was "C8oFREz5Po42kiONPw/mJ/aCmuw21vaBRgs3DrWL4ZI=" (see Password_Generate picture attached).
If the client makes a mistake when entering the password, your program will not run (as it will return INIT_FAILED in the OnInit() function).
If the client changes account number it will not work either.
I hope this helps you better understand it now.
Cheers!
Dear Claude Beaudoin
so much thanks for explained reply,may i ask more for to better understand things ...... how we can limit the time usage of some indicator/EA (let us assume,we are talking about some EA) is there any option for time limitation,such as trial period or rent for 1 month or 6 month.
regards
Dear Claude Beaudoin
so much thanks for explained reply,may i ask more for to better understand things ...... how we can limit the time usage of some indicator/EA (let us assume,we are talking about some EA) is there any option for time limitation,such as trial period or rent for 1 month or 6 month.
regards
Hi mntiwana,
Yes there is a way but it is not with the source code I've provided here.
We need to have three pieces of information to accomplish this;
1) A base date
2) An activation start date
3) A time period for the activation
Well, we have #1 answered. You program compile date. You can access this variable with global variable __DATETIME__. This variable holds the date and time your program was last compiled.
#2 is, I presume today's date. The date you are activating a time period for your customer.
#3 is the duration of the activation, be it in days, weeks, months.
So if we take the activation date (today) minus the program compile date (using a datetime variable) we end up with an elapsed time since your last compile. Now, we add to this elapsed time the number of days we want the trial period to be and we get a future date when the trial will expire. This value we encode using an encryption method of your choice and the result we provide to our customer.
The customer enters this password and we decode it to get a datetime when the trial period will end. You simply add the decoded elapsed time, add it to your program compile date and if we are past that date, the trial period has expired.
Best regards,
-Claude.
Hi mntiwana,
Yes there is a way but it is not with the source code I've provided here.
We need to have three pieces of information to accomplish this;
1) A base date
2) An activation start date
3) A time period for the activation
Well, we have #1 answered. You program compile date. You can access this variable with global variable __DATETIME__. This variable holds the date and time your program was last compiled.
#2 is, I presume today's date. The date you are activating a time period for your customer.
#3 is the duration of the activation, be it in days, weeks, months.
So if we take the activation date (today) minus the program compile date (using a datetime variable) we end up with an elapsed time since your last compile. Now, we add to this elapsed time the number of days we want the trial period to be and we get a future date when the trial will expire. This value we encode using an encryption method of your choice and the result we provide to our customer.
The customer enters this password and we decode it to get a datetime when the trial period will end. You simply add the decoded elapsed time, add it to your program compile date and if we are past that date, the trial period has expired.
Best regards,
-Claude.
Dear Claude Beaudoin
so much thanks for detailed answer,unfortunately i am not coder,lol........ but i think this feature is basic for such activities..... also i read your today post in which you warn about few possible problems within MT4.....i hope you will be find solution.
regards
mntiwana
Dear Claude Beaudoin
so much thanks for detailed answer,unfortunately i am not coder,lol........ but i think this feature is basic for such activities..... also i read your today post in which you warn about few possible problems within MT4.....i hope you will be find solution.
regards
mntiwana
LOL!
No problem mntiwana. If you need a coder for this, post it in the freelance area and we member me when I submit a quote :)
As for the issue I had with the CryptDecode() function, the problem was of course a coder (me) error. Alain was kind enough to point out what I was doing wrong.
Cheers!
smart idea...
Hi Claude,
i like the idea very much, but is it really smart to store the "masterkey" open in the client expert?
Just hypothetically someone get's the expert decompiled: he only needs the other part of your (published) script to get access to the expert (ok, what he allready have in this case), but also to all other experts you may have published with the same masterkey, and that without decompiling them.
If you have some different experts to publish, you should be very carefull with that.
But it's a great startscript for further developing, thank you for your excellent work!
best regards,
Wolfgang
Hi Claude,
i like the idea very much, but is it really smart to store the "masterkey" open in the client expert?
Just hypothetically someone get's the expert decompiled: he only needs the other part of your (published) script to get access to the expert (ok, what he allready have in this case), but also to all other experts you may have published with the same masterkey, and that without decompiling them.
If you have some different experts to publish, you should be very carefull with that.
But it's a great startscript for further developing, thank you for your excellent work!
best regards,
Wolfgang
Hey Wolfgang,
First, thanks for you comment because it brings up several points which I did not talk about in the code I published.
The methodology I proposed is pretty secure, even if the master key is in the open (by open we mean in the compiled code provided to the client and/or released to the public), because the .EX4 code is now encrypted and MetaQuote is not about to tell us how they do it. I'm not sure since which version they've done this, but if you take a hex editor and look at the smallest code you have with plain text in it, you will not find it. So putting the "masterkey" in the code does not represent a potential security risk in my opinion.
As for having the same masterkey for several EAs is, without saying, not too bright! If you know what I mean :)
Next would be to use code obfuscation to add another layer of security to your code. You can check here for several good methods on code obfuscation. Obfuscation refers to hiding something from plain sight. So instead of having a line of code that reads:
string MasterKey = "NotDemo";
You could build your MasterKey from several parts of the program. For example, take the first 7 characters of the CopyRight line of your program, XOR those values with the program compile date and use that as your MasterKey. Again, it's not in plain text and requires several operations to get to it.
The next thing you could do is to hide the call which does the decryption. Meaning, instead of having a function return TRUE/FALSE, like my Password_Check() function does, simply declare it as a void function, store the resulting decrypted message in a global variable and check it else where in the program after a certain event (new candle, time period, number of ticks received) and call ExpertRemove() if the check fails. Now you're adding confusion to resulting code and it's not a simple matter of 'bypassing' that function call to avoid getting kicked out.
So in general, the code I published was to stimulate creativity on the developer's side and encourage further development.
I still stand by my saying the code is pretty good, as is, for 99.9% of coders who want to add security to their program. Remember to ask yourself the question "What's at risk?". We're not talking about millions and millions of dollars here. We're talking about a couple of weeks, or perhaps months of coding if somebody makes a huge effort in trying to crack this security scheme.
Cheers!
-Claude.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Adding password protection to your Indicator / Expert Advisor:
Several methods of protecting your code have been proposed over the past, but were either too simple (less secure), required re-compilation of your code for each new customer (ok if you only plan on having a dozen or so customers) or far too complicated involving a remote host to validate the client terminal.
Here I propose a simple password verification scheme which uses MT4's built in security engine providing DES/ECB encryption and does not require code re-compilation for each new customer.
Author: Claude Beaudoin