We already have a number of protections specifically for expert developers. We will announce them a little later.
Your idea is a good one and it can be implemented.
Please let us know if you would like to have a say in the way you would like to be protected.
We already have a number of protections specifically for expert developers. We will announce them a little later.
Your idea is good and it can be implemented.
Please let us know how you would like to implement it.
Thank you!
I think that if you create a mechanism to create such a certificate on the basis of a cross between a publisher's info-certificate and a user's certificate, there would be less questions about the protection of commercial products.
The main problem is the theoretical possibility of decompilation. If this problem is solved, then all the complex security methods do not need to be implemented. Only the tools built into the MQL will be enough.
Unfortunately, F4 has been decrypted and the decompiler is freely walking around on the web. The same thing can happen to the fifth one, if the developers haven't implemented the corresponding protection. I mean the protection of the terminal from debugging and decompilation. In addition, I've seen somewhere that MQL5 code is compiled into native CPU code. I don't know: is it really so or not, but if it is, it's a serious hole in decompilation protection.
Generally, I'm quite sceptical about EA/indicator decompilation protection. I think it's probably an unattainable dream.
Debugging protection is not needed if the script code is encrypted with a (strong) key issued to the specific purchaser of the script. The algorithms of PGP, for example, are open-source.
Another thing is that an unscrupulous buyer may publish his key. A centralized online database of commercial scripts and their purchasers, accessible through a special web service or MT server, could probably help prevent such things, but there is a lot to think about.
You don't need debugging protection if the script code will be encrypted with a (strong) key written out to the specific buyer of the script. The algorithms of the same PGP, for example, are open source.
Another thing is that an unscrupulous buyer may publish his key. A centralized online database of commercial scripts and their purchasers, accessible through a special web service or MT server, could probably help prevent such things, but there is a lot to think about.
You obviously didn't read the post about "cross-breeding". An unscrupulous buyer will be forced to give his bill as well. and in one hand only. ;)
We are talking about EX5 files, after all.
Debugging protection is not needed if the script code is encrypted with a (strong) key issued to the specific purchaser of the script. The algorithms of PGP, for example, are open-source.
Another thing is that an unscrupulous buyer may publish his key. A centralized online database of commercial scripts and their purchasers, accessible through a special web service or MT server, is likely to help prevent this sort of thing, but it's something to think about.
You have clearly written without thinking.
The decompiler for quadruple was written as a result of analyzing, debugging and decompiling the MT4 terminal. And if only true professionals of programming could cope with this task, then how to use the decompiler is clear to any beginner. No encryption will give any reliable results precisely because a "dishonest customer" can use the keys he has when decompiling the EX5 file.
For example, if you have purchased the right to use an Expert Advisor for a month, downloaded a utility decompiler from the Internet, launched it and pointed out the key you have... and got the source code of the Expert Advisor. You removed all the protection from it and use it for life, plus sell it from your website.
Terminal decompilation protection will at least make it difficult to write a utility to decompile EX5 files.
You clearly wrote without thinking.
Russell's paradox, though.
;)
That's hilarious.)
What is Russell's paradox here?
What is the Russell paradox here?
Protection against decompilation of the terminal in a Windows environment is also impossible according to your logic.
Decompiling protection in a Windows environment is also impossible, following your logic.
What is built by one can be broken by another.
Strictly speaking, absolute protection does not exist and will never be implemented.
That's why I wrote "In general, I am very skeptical about protection against decompilation of EAs/indicators. I think it's probably an unattainable dream."
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
The problem of protecting MQL programs has been raised many times on the forum.
Why don't the developers include verification (decryption or something else) in the language tools, using the user certificate issued by the application's author.
For example, by expanding the list of #PropertySecurity certificates <......>.
MQL code with this property could be translated into a usable form only by a certificate issued by the owner of the source code.