Discussion of article "Securing MQL5 code: Password Protection, Key Generators, Time-limits, Remote Licenses and Advanced EA License Key Encryption Techniques" - page 2
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
I think it's the only option at the moment.
There is no other way to prove a trader's skill. Only monitoring your trading. And it is great that it will be on this site. There is no need for any Onyx and so on....
Only at the moment there is not much information on this topic. For example, what types of accounts can be connected to this service? More precisely, will it be possible to connect demo accounts as well? Or only real ones? Of course, the real ones will be more trustworthy. Both demo and real accounts are more trustworthy if there will be a stable result for a long time (for example, from half a year). There may be many more questions ...
P.S. In general, the topic is about something else, so I'm leaving. :)
By the way, we will soon release a big rating system for all users. It will be a very interesting innovation - "give me a trader of level 80!".
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.
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 can also add a variable related to hardware properties (HDD serial number or CPUID information). In this case, an additional generator using hardware binding will have to be run to run the Expert Advisor.
The result can serve as an input parameter for the generator and the generated password will be correct only for a specific hardware. This limits those who have changed their computer configuration or use a VPS to run the Expert Advisor, but this can be solved by giving out two or three valid passwords. This method is used in the Market service."
Where can I learn more about binding to hardware or find an example of the source code? And what does it mean -" This method is used in the " Market" service."? That is, if I post a compiled Expert Advisor file for sale in the "Market" service, does it automatically include binding to hardware? Or do I have to give the source code and Metaquotes employees additionally include binding to the hardware there?
Is it possible to implement the binding to hardware in MQL4? (Most brokerage centres still work on MT4).
Where can I find out more about binding to hardware or find an example of the source code? And what does it mean - "This method is used in the "Market" service."? That is, if I post a compiled file of an Expert Advisor for sale in the "Market" service, then the binding to hardware is automatically included in it? Or do I have to give the source code and Metaquotes employees additionally include the binding to the hardware there?
Can hardware binding be implemented in MQL4? (Most brokerage centres still work on MT4).