MQL code authorship protection in MT5. - page 6
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
First, please describe in detail your mechanism with keys and all mechanism of buyer-seller relations. It will turn out to be an over-complicated thing that no one wants to support. Not to mention the fact that the keys will be lying all over the internet. I'm sure none of you have thought through the whole system in detail, but only made superficial assumptions.
We have developed a very easy, automatic and fairly reliable system for buying/selling MQL5 programs with protection:
- the seller puts his code for sale and specifies the price
- The buyer downloads the repackaged demo and tests it in the tester, but cannot use this code physically in the terminal
- The buyer purchases the program hardcovered to fit his hardware, it will run only on his computer (a few clicks are enough to purchase)
- Seller checks sales reports and calculates profit
- We do all calculations and payments
As a result, the seller doesn't bother, all the security work is done automatically. The buyer gets the program in a few clicks and doesn't bother with generation, transmission, key assignment. If the licence gets reset, he can reactivate the previously purchased software on new hardware up to 3 times.First, please describe in detail your mechanism with keys and all mechanism of buyer-seller relations. It will turn out to be an over-complicated thing that no one wants to support. Not to mention the fact that the keys will be lying all over the internet. I'm sure none of you have thought through the whole system in detail, but only made superficial assumptions.
We have developed a very easy, automatic and fairly reliable system for buying/selling MQL5 programs with protection:
- the seller puts his code for sale and specifies the price
- The buyer downloads the repackaged demo and tests it in the tester, but cannot use this code physically in the terminal
- The buyer buys the program repackaged to his hardware, and it only runs on his computer (a few clicks to buy it)
- the seller watches the sales reports and calculates the profit
- We do all calculations and payments
As a result, the seller doesn't bother, all the security work is done automatically. The buyer gets the program in a few clicks and doesn't bother with generation, transmission, key assignment. If the license gets out of order, he can reactivate a previously purchased program on the new hardware up to 3 times.let's hone in.
After all, this is serious.
The more details you give us, the more peace of mind we will have.
What is built by one can be broken by another.
Strictly speaking, there is no absolute protection and it will never be implemented.
That's why I wrote "In general, I'm quite sceptical about EA/indicator decompilation protection. I think it's probably an unattainable dream."
If you go deep into the wilderness, there is of course ASM, code...
But with the current volumes, few people will sit down and parse the logic, translating from asm to C++ or at least get an algorithm
e.g. the option of getting Microsoft Office into source code !
just if you start on version 2007 , when version 2057 comes out ( by year ) might be ready
especially if there is only one person to do it !
as a rule it is easier to write your own algorithm
We already have a number of protections specifically for expert developers. We will announce them later.
Your idea is a good one and can be implemented.
Everyone is welcome to give their feedback on the desired security methods.
one way, the code is hidden e.g. on a server which outputs some data, receiving some data as input
You don't get the code in your hands! Only the results.
"Selling advisers..." - for those who do not know how to use MT for its intended purpose - trading.
"And here are all sorts of tools to make life easier for the trader-..." should be standard in the terminal.
It's impossible to solve EVERYTHING! It is unrealistic to solve EVERYTHING that can be useful in the terminal!
3. the customer buys the software repackaged to his hardware, it will only run on his computer (a few clicks are all it takes to purchase)
If the license becomes invalid, he/she will be able to reactivate the previously purchased program on the new hardware up to 3 times.
The experience of using binding to hardware has shown the ineffectiveness of this approach. Especially if the number of re-activations is limited. Practice shows that this dramatically limits the freedom of users to upgrade, update or modify their hardware. And this, in today's rapidly changing world of computer technology has a negative impact on paid software developers (increases the number of errors associated with the legal activation, increases the number of calls to support, increases costs, both financial and moral support of the product). All in all, those who have already done such binding to hardware know how much hassle this will add...
As an option, it is possible to organize in the compiled code a protected locked section, which can only be accessed with a user trusted certificate from the code developer, tied to a specific account, DC and/or something else. In this case, MQ is no longer obliged to take measures to protect MQL code. This will be the developer itself writing something in MQL. MQ will now be engaged only in checking the certificates and dispatching access to the closed part of the MQL code. If there is a certificate, the entire code or part of it will be unavailable, if there is no certificate, the entire code will be in the open section. Well, in the MQL compiler we will have to embed a mechanism, which will close the code with a developer's certificate. As they say "simple and tasteful"... :) Currently this is one of the most reliable and affordable methods of software protection I know. Where can you get certificates? Yes the same VerySign or similar services (wherever is more convenient or profitable), professionally engaged in this craft.
Experience with hardware tethering has shown the ineffectiveness of this approach. Especially if the number of re-activations is limited. Practice shows that this dramatically limits the user's freedom to upgrade, update or modify their hardware. And this, in today's fast-changing world of computer technology has a negative impact on paid software developers (increases the number of errors associated with the legal activation, increases the number of calls to support, increases costs, both financial and moral support of the product). In general, those who have already done such binding to hardware know how much hassle this will add...
As an option, it is possible to organize in the compiled code a protected locked section, which can only be accessed with a user trusted certificate from the code developer, tied to a specific account, DC and/or something else. In this case, MQ is no longer obliged to take measures to protect MQL code. This will be the developer itself writing something in MQL. MQ will now be engaged only in checking the certificates and dispatching access to the closed part of the MQL code. If there is a certificate, you can close part of the code or the entire code at all, if there is no certificate, the entire code will be in the open section. Well, in the MQL compiler we will have to embed a mechanism, which will close the code with a developer's certificate. As they say "simple and tasteful"... :) Currently this is one of the most reliable and affordable methods of software protection I know. Where can you get certificates? Yes, from the same VerySign, or similar services (whichever is more convenient or profitable), professionally engaged in this craft.
1. Binding to hardware leads to some inconvenience. But at the moment (if well enough organized) it is quite effective and reliable way of protection.
The only question is what to bind it to. I also suggest increasing the number of "installations" from 3 to 10 (at least).
2. I am sure that just the opposite, all protection work must be done by MQ. Perhaps there should also be a link to the trading account and a time limit for use (but this is an additional option, as desired by the developer).
As if there were other ways of protection?
If we look at it from the point of view of a programmer writing for traders in MQL
mql5 - will probably last longer - maybe a very long time - but it's not a fact that they don't make a decompiler.
mql4 - unfortunately, there is no code protection - only some methods give a small safety margin
It is possible not to bind to the iron in some cases,
For example creating a site on the type of function on the site - the code appeals to the site - which gives a ready solution, but not everyone will want to use this solution.
There is a dependency on some hardware and software, usually on someone else, usually the person who sold the product.
----
another option
In the context of MT4/MT5 MQL4/MQL5 + DLL binding can be done not to the iron and to the account number (numbers) , for real money and/or full name, alternatively middle name
This way is the easiest in terms of protection (just for this specific application) - it is mobile and does not require any connection to hardware.
And the boys with fauspatron (in the form of MT4 decompiler) fall away.
The only remaining are more serious guys who know ASM and can break down at debugger level, various loggers, decompilers and other advanced schemes,
and there are fewer of them and their services are more expensive.
First, please explain in detail your mechanism with the keys and the whole mechanism of buyer-seller relations. ...
for example
Buyer: finds information on the Internet, writes wants to buy
Seller: describes the payment mechanism - if you don't want to publish your details, ask for personalisation
Buyer: pays and sends the personalization data, account number or name, which are the keys.
Seller: sends the goods linked to your personal details.
ideally this is it!
I have such cases, and not a few