Discussion of article "Securing MQL5 code: Password Protection, Key Generators, Time-limits, Remote Licenses and Advanced EA License Key Encryption Techniques"
Excellent implementation! The Datetime expire script would just be placed in the code of the EA correct and if so, how would one be able to make a predefined expiry based on a timelimit e.g. 2 weeks from first placing on chart?
datetime allowed_until = D'2012.02.11 00:00'; int password_status = -1; //+------------------------------------------------------------------+ //| Expert initialization function | //+------------------------------------------------------------------+ int OnInit() { //--- printf("This EA is valid until %s", TimeToString(allowed_until, TIME_DATE|TIME_MINUTES)); datetime now = TimeCurrent(); if (now < allowed_until) Print("EA time limit verified, EA init time : " + TimeToString(now, TIME_DATE|TIME_MINUTES)); //--- return(0);
to
double allowed_tf = 7; // in days int password_status = -1; //+------------------------------------------------------------------+ //| Expert initialization function | //+------------------------------------------------------------------+ int OnInit() { //--- printf("This EA is valid until %s", TimeToString(allowed_until, TIME_DATE|TIME_MINUTES)); datetime now = TimeCurrent(); datetime allowed_until = TimeCurrent() + allowed_tf; if (now < allowed_until) Print("EA time limit verified, EA init time : " + TimeToString(now, TIME_DATE|TIME_MINUTES)); //--- return(0);
??
good article...
Sorry to be scathing but what was presented in the article is not security, it is obscurity. Copy-protection is an exceedingly difficult problem, hence the efforts of the music/film industry with DRM and their repeated failures.
At best, the information here will waste some peoples' time; at worst you may have given the reader a false sense of security. If they then decide to "protect" a product using your advice, they may be somewhat surprised when their consumer strips out the protection within a matter of hours and resells it for a fraction of the price.
An seriously - base64 encoding is not related to encryption. Base64 encoding was designed to allow 8-bit data to be transmitted safely using protocols that consider data encoding to be 7-bit. You can trivially reverse base64 encoding - and it is designed for that purpose!
The only solution I can see of securely distributing MQL5 software is either via the broker's limited power of attorney provisions, or installing an instance of MQL5 with the .ex5 files on a server somewhere and allowing the customer access using a thin client (so they cannot download the .ex5). And yes, I've worked in information security for over 15 years, so have a fair idea of what I'm talking about.
To be honest, I'm rather surprised that Metaquotes published the article.
- www.mql5.com
The article gives some clues on how to deal with the issue. In reality the issue should be solved by the mt5 client. There are many platforms out there that use encription within the client software so the software and not the coder solves the issue.
The article gives some clues on how to deal with the issue. In reality the issue should be solved by the mt5 client. There are many platforms out there that use encription within the client software so the software and not the coder solves the issue.
Even for the MetaQuotes client software to implement that functionality is a difficult problem: the software will have to either contain or download a decryption key, which implies it is possible to compromise said key. If a tamper-proof hardware device is used then unless the .ex5 is run *on* the tamper-proof hardware, it is still vulnerable as it must be decrypted at some point to be executed. While I may not be able to implement such attacks, I know a fair number of people that can do it without much trouble at all.
In the threat model of an end user having access to the .ex5 that they can run, there is *no* secure solution.
This is the generic class of problem - in other words content protection - that companies/institutions use thin-client models for: that way the sensitive content cannot be downloaded but only used on the company/institution's servers.
You should know that all EX5-prorgrams are encrypted by strong keys. It is first point.
And second one - don't forget about Market -
A Market of Expert Advisors for MetaTrader 5. All products in Market are encrypted by additional key for buyer. It means that nobody except legal user can launch such EX5-program.
You should know that all EX5-prorgrams are encrypted by strong keys. It is first point.
And second one - don't forget about Market -
A Market of Expert Advisors for MetaTrader 5. All products in Market are encrypted by additional key for buyer. It means that nobody except legal user can launch such EX5-program.
You could also replace your front door with reinforced steel but it won't to anything to prevent entry if you leave the key on the doormat. The protection you have described is fine to deter the casual coder but certainly not against a motivated attacker.
The question here is not the encryption - that's the easy part - but rather how you handle keys and the decryption process.
In the scenario where an attacker, in the classic parlance we'll call her, Mallory, wishes to copy and distribute an EX5 she has the key to then surely she can do by:
i. running the EX5 with the key;
ii. monitor the process as it is running, say by attaching a DLL to the process, and dumping the contents of the EX5 immediately after it is decrypted;
iii. reassemble the now plaintext EX5 (and potentially disassemble into source if can be bothered).
If your first point protection involves signature verification then all that the attacker need do to distribute files is distribute a different MQL executable with relevant public keys replaced. If MQL5 uses a cryptographic API to verify cert then that can be ripped out the binary. This continues ad infinitum.
This is all before you start considering the nightmare that will be your key management.
While this sort of binary analysis is out of my capabilities these days, I know several people that could accomplish it without hassle. So it is not the strength of the encryption you should be concerned about but rather that you have an invalid security model. It isn't a particular problem per se, as nobody expects MetaTrader to solve that problem - there are other very usable solutions to this problem, specifically having the owner of MQL5/EX5 code run it on a separate sever they control and license access/signals to buyers.
So, I'm at a loss to understand why people are requiring this facility when it is so difficult to implement properly, at least without tamper proof hardware.
You could also replace your front door with reinforced steel but it won't to anything to prevent entry if you leave the key on the doormat. The protection you have described is fine to deter the casual coder but certainly not against a motivated attacker.
The question here is not the encryption - that's the easy part - but rather how you handle keys and the decryption process.
In the scenario where an attacker, in the classic parlance we'll call her, Mallory, wishes to copy and distribute an EX5 she has the key to then surely she can do by:
i. running the EX5 with the key;
ii. monitor the process as it is running, say by attaching a DLL to the process, and dumping the contents of the EX5 immediately after it is decrypted;
iii. reassemble the now plaintext EX5 (and potentially disassemble into source if can be bothered).
If your first point protection involves signature verification then all that the attacker need do to distribute files is distribute a different MQL executable with relevant public keys replaced. If MQL5 uses a cryptographic API to verify cert then that can be ripped out the binary. This continues ad infinitum.
This is all before you start considering the nightmare that will be your key management.
While this sort of binary analysis is out of my capabilities these days, I know several people that could accomplish it without hassle. So it is not the strength of the encryption you should be concerned about but rather that you have an invalid security model. It isn't a particular problem per se, as nobody expects MetaTrader to solve that problem - there are other very usable solutions to this problem, specifically having the owner of MQL5/EX5 code run it on a separate sever they control and license access/signals to buyers.
So, I'm at a loss to understand why people are requiring this facility when it is so difficult to implement properly, at least without tamper proof hardware.
allicient brings up a lot of valid points. For any real protection, I recommend the following:
For basic protection of the source code, stuffing as many functions as possible into a dll should do the trick. Minimal code to interface between MT5 and programming is ok. I would not trust the complete source code in ex4/ex5, unless you are giving your software away. But this article is about protecting your intellectual property for paid/commercial products or free products where source code is not given.
For licensing, the best protection is having separate demo and live versions of the ex4/dll combination. The tradeoff is that it is a bit more of a hassle for the developer and client, as the developer has to maintain/compile two versions of their own software. But you lessen the chance of someone gaining hacked access to full version of software; they only can use the demo version. A lot depends on the goal of the demo. If you want to offer the client full functionality, then
Also, implement licensing that may require that a small piece of essential code be run remotely before the local software can be run. CNS SaaS (Software as a Service) has actually done just this, and it is called CCoHS (Call code on hosted server) functions. You can place a limited portion of code needed for your EA to run properly in a hosted fashion. Then even if someone runs off with the EA, or cracks the licensing dll somehow, it would still render the dll useless. There is latency between the hosted code server and the EA and/or licensing servers, but you can work around that. The implementation isn't too difficult, but the user does have to find a way to implement CCoHS on his/her own servers. When you are small, you can do this on a a budget server or wherever, and then scale up when your subscriber base grows.
Hosted functions, while the most expensive of all the options offers real protection in case someone were in fact able to decompile your dll, which is very unlikely. They would most likely 'crack' the dll to get your software to work. But without the required hosted functions, it would still be useless. Unless I missed something here.
Hi,
Thanks for the Article. Please advice me for Password protection, how to make when type the password, the input display as asterisk ("*") or a dot ("•")
I am not good programer.
Thanks
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article Securing MQL5 code: Password Protection, Key Generators, Time-limits, Remote Licenses and Advanced EA License Key Encryption Techniques is published:
Author: investeo