MQL code authorship protection in MT5. - page 7
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
for example
Buyer: finds information on the Internet, writes want to buy
Seller: describes the payment mechanism - if you don't want to give out the payment details, you will be asked to provide your personalized information.
the buyer: pays and sends the personalisation data, account number or full name, which is the key
Seller: sends the goods assigned to the personal data.
ideally that's it!
I have such cases, and not a few
Unfortunately, this does not make life more complicated for some freeloaders (people who are in the subject). Binding to an account is not the solution of all problems either, any competent "transaction copier" will transfer all the data to any other account (especially if the data is copied from MT5 to MT5).
In my opinion not only experts but also scripts, indicators, libraries and other code should be protected. In my opinion, this is a more interesting and important theme.
Why is it more important?
As we know, all tools that can be implemented using MQL are divided into: automated systems, semi-automated systems, and tools for manual trading.
There is also a division in systems: "black boxes", "gray boxes" and "white" systems (systems with open source and explicitly described logic).
So, almost all MTS presented in the commercial sector will be black or grey boxes. Their specific weight will not be so large (I think it will not exceed 30-40%). At the same time such solutions will be rather inflexible (because they implement in essence only one strategy).
Separate scripts, libraries and indicators are another matter. These software solutions will be available in all areas of manual and mechanical trading. At the same time, they will be able to be used as basic elements of the constructor.
PS
Here in my opinion it is necessary to maximize protection, and so as not to infringe on the rights of developers and users. The only optimal way of protection in this case? As I understand it, there is only one - Bind to the hardware.
Whatever you may think to yourself, binding to hardware is no longer an effective method of protection. By the way, for a person barely acquainted with Asmus (and there are far more than a few of them) removal of such protection is a matter of minutes. And it does not matter what you will bind to. Read programming (read hacking) forums and everything will become clear to you. :) And what about "good organization", try for the sake of experiment to bind some of your mass production to the hardware and I'm sure that after a while (about a month or two) you will understand what I wanted to tell you.
As if there were any other protection options?
I'm surprised you're asking that. Of course there are. And lots of them. From simple recoders, to license generators, to hardware-software protection methods such as HASP, etc. But almost all of them, regardless of their cost and declared reliability, have long been cracked, and crack codes, keygenes and other softwares are walking around the Internet in open access. And I dare say these methods of protection are several orders of magnitude more reliable than simple binding to hardware.
In the context of MT4/MT5 MQL4/MQL5 + DLL binding can be done not to the hardware, but to the account number (numbers), for real and/or family name, alternatively middle name
This way is the easiest in terms of security (for this specific situation) - it is mobile and does not require binding to the hardware.
Starting this thread we had ('each'!) our own certificate issued by Metakwots. It is clear that this is not yet a well-recognised certification authority. But this topic (issuing and maintaining certificates) has stalled, although 4 supposedly has such an authentication capability.
Therefore a binding to hardware for authorship protection is, I believe, a "deep" regress.
The idea (about it in first pages) was to implement the "normal" compilation algorithm for the ex5 file.
The dream is approximately the following.
The programmer is able to compile his program so that it could be accurately perceived by the terminal only in the presence of a trace subkey - a complex concatenation of the developer's and user's key.
The necessary signatures of the developer key would sit in the program as well as the user key in the program and in the key on the specific terminal.
Then the presence of this "license-subkey" would make it possible to use it.
The generation should be done by Meta-editor, i.e. the developer himself - having received a part of the key from the customer.
So it was imagined...
But something doesn't come out of the fog.
It seems to me that the possibility of generating the developer's key from the certificate authority "МТ5" and the presence in the terminal of ex5 decryption procedures using that key and a part of the user's key would solve more problems than that "native service" - the mechanisms and adequacy of which can not be discussed here at all.
;)
If we are talking about key protection, the whole internet will be flooded with these very keys. In other words, instead of protection, it will be a sham with a complex implementation forcing the buyer to manage the keys.
The best way is to look at Apple's AppStore/iTunes sales scheme that works. The customer simply clicks in and purchases the software without the hassle of having to transfer or use keys. A customer just needs to have an MQL5.com account to retain his/her purchase history and re-activate previously purchased programs.
When purchasing a program, the user receives a specially recompiled/reprotected copy, which protects the seller much better than keys. The whole process of personal protection will be automatic at the time of purchase.
Our goal is to make the buying/selling process as easy as possible.
I think there is one more important feature missing in this thread - trial period or demo restrictions. Potential buyers justifiably want to see what they are buying first. For this purpose, somewhere must be hidden (encrypted) information about the dates and/or time during which the purchased product will operate without restrictions. It seems to me that embedding an encryption mechanism with a couple of keys (a la pgp) into the language itself can solve not only this but many other problems.
It makes sense to sell only to a customer working on a real account (like he has / must have the means to buy). This number (maybe + some more information like server name, key phrase or something else) is used as a key for decryption. The vendor should have a built-in mechanism for generating a key pair and encrypting files with it.
What do we get? The developer creates a file with the initial data: e.g. containing the account number and two dates from and till which it works on this account. this file is encrypted. and is given together with the expert/script/indicator to the buyer. for him (and only for his account), the platform receives a second full key for the account number, reads and decrypts the encrypted file (you can check the checksum and do not return anything if the key turned out to be wrong) and gives it as a string to the Expert Advisor / Script / Indicator.
The code itself receives this data and decides whether it works in demo or normal mode. It can even store parameters of EA's operation: for example, МАС crossing - the algorithm will be evident even after decompiling, but the exact parameters these МАС are working with in profit may be "secret", and there is no sense in decompiling an EA without knowing these parameters. Of course, there are some gaps and there will be something to compromise, but not knowing the data in an encrypted file (which you can't get with Asm), everything becomes much more complicated than just buy the product and its support from the author.
Bottom line: you need to provide an encrypted container, and then everyone can put the data they need into it and arrange for the most sophisticated protection.
Gentlemen, don't forget that this is a mass market.
You think in 1:1 work categories, that the buyer and seller will negotiate together, exchange bids and send each other the keys. Of course, this way you won't be able to sell much. We, on the other hand, offer a quick-selling shop where the seller doesn't even have to lift a finger for sales. And the buyer just has to press the "buy" button and not bother with any account numbers or key generation.
Everything has already been thought out. If you want to know how it will work, try an iPhone/iPad, buying software for it from the AppStore.
In my humble opinion, the option of protection tied to the hardware is ideal, both in terms of implementation and ease of use. There is another wish about this variant, but I will tell you about it below.
The options of linking to account numbers/owner 's name and others are not convenient, although this is not obvious at first glance. The buyer likes to change brokers and open new accounts every week, so what about compiling a product for him every time, and if there are dozens or hundreds of users of the product? The keys can be fused on the net - not an option either.
What about binding to hardware? A user may want to work with the product on several computers and then the possibility of binding to several hardware versions should be provided. And if the user will want to upgrade the hardware available, then maybe in such cases, you will have to give him, say, 1 hour during which the upgrade will be performed. So on. We need to think about these points. Binding the product to one/two/three machines forever is wrong and unfair to the customer.
As for binding to hardware. The user may want to use the product on several machines, then the possibility of binding to several hardware options should be provided. And if the user wants to upgrade the hardware available, then maybe in such cases, you should allow for, say, 1 hour during which the user switches to the new hardware. So on. We need to think about these points. Binding a product to one/two/three machines forever is not right and fair to the customer.
But at the same time, we will allow to run protected EAs in tester (tester agent), so that users could independently verify the performance of the EA in the tester and not to buy a pig in a poke.
There are EAs that have history sewn into them. Or which are able to read history from history base. Such dummy EAs show remarkable results in the tester. Will there be any protection against this kind of fraud? Especially if the Expert Advisor is delivered together with a DLL.
How will the service fight for its reputation in case of MQL5-code + malicious DLL (from spyware to viruses)?