MT5におけるMQLコードのオーサーシップ保護。 - ページ 7

[削除済み]

YuraZ:

例えば

買い手：インターネット上で情報を見つけ、買いたいと書き込む

販売者：決済の仕組みを説明します。決済の詳細を知らせたくない場合は、個人情報を入力するよう促されます。

購入者：支払い、キーとなる個人情報（口座番号 またはフルネーム）を送信します。

販売者：個人情報に割り当てられた商品を発送します。

そうこなくっちゃ

そんな事例もあり、少なからず

残念ながら、これでは一部のフリーランサー（被写体になっている人）の生活が複雑になってしまうのは仕方がないことです。口座へのバインディングはすべての問題の解決策ではありません。有能な「取引コピー機」はすべてのデータを他の口座に転送します（特にデータがMT5からMT5へコピーされる場合）。

エキスパートだけでなく、スクリプトやインジケーター、ライブラリなどのコードも保護されるべきだと私は考えています。私としては、こちらの方がより興味深く、重要なテーマだと考えています。

なぜ、より重要なのか？

ご存知のように、MQLを使って実装できるツールはすべて、自動化システム、半自動化システム、手動取引用のツールに分けられます。

また、システムには「ブラックボックス」「グレーボックス」「ホワイト」（オープンソースでロジックが明示されているシステム）という区分がある。

そのため、業務用として発表されるMTSは、ほとんどすべてブラックボックスかグレーボックスとなります。比重はそれほど大きくはないでしょう（30～40％を超えることはないと思います）。同時に、このようなソリューションは柔軟性に欠ける（本質的に1つの戦略しか実行できないから）。

個別のスクリプト、ライブラリ、インジケータは別問題です。これらのソフトウェア・ソリューションは、マニュアル取引と機械取引のすべての分野で存在することになります。同時に、コンストラクタの基本要素としても使用できるようになる。

追記

ここでは、開発者やユーザーの権利を侵害しないよう、最大限に保護することが必要だと考えています。この場合、最適な保護方法は？ 私の理解では、1つだけです - ハードウェアにバインドすることです。

[ir0407]

しかし、現時点では（十分に組織化されていれば）かなり効果的で信頼性の高い保護方法である。

自分ではどう考えても、ハードウェアに縛られるのはもはや有効な手段ではありません。ちなみに、アスマスをほとんど知らない人（その数ははるかに多い）にとって、このようなプロテクトの解除は数分のことです。そして、何に縛られるかは問題ではありません。プログラミング（ハッキングと読む）フォーラムを読めば、すべてが明らかになります。:)そして、「良い組織」はどうかというと、実験のために、量産品の一部をハードに縛り付けてみると、しばらくして（1～2ヶ月くらい）、私が伝えたかったことが理解できるようになると思います。

まるで他にプロテクションの選択肢があるかのように？

そんなことを聞くなんて、驚きです。もちろん、ありますよ。しかも、たくさん。単純なレコーダからライセンスジェネレータ、HASPなどのハードウェア・ソフトウェア保護方式まで。しかし、そのほとんどすべてが、コストや信頼性の宣言にかかわらず、とっくにクラックされており、クラックコードやキージェネなどのソフトがオープンアクセスでインターネット上を闊歩しています。そして、これらの保護方法は、単純にハードウェアに縛られるよりも数段信頼性が高いと言えるでしょう。

[михаил потапыч]

YuraZ:

MT4/MT5 MQL4/MQL5 + DLLのコンテキストでは、ハードウェアではなく、アカウント番号（番号）、実名および/または姓、代わりにミドルネームをバインドすることができます。

この方法は、セキュリティの面で最も簡単です（この特定の状況において） - モバイルであり、ハードウェアへのバインディングを必要としません。

アカウントに販売する瞬間のバインディングは誰が行うのですか？

[VonDo Mix]

このスレッドから、Metakwotsが発行する独自の証明書を（「それぞれ」！）入手しました。まだ、認証機関として認知されていないことは明らかです。しかし、4にはそのような認証機能があるはずなのに、このトピック（証明書の発行と管理）は停滞している。

したがって、著作権保護のためにハードウェアに縛られることは、「深い」逆行であると私は思います。

最初のページで紹介したアイデアは、ex5ファイルに対して「通常の」コンパイルアルゴリズムを実装することでした。

夢はおよそ次のようなものです。

プログラマーは、開発者のキーとユーザーのキーを複雑に連結したトレースサブ・キーが存在する場合にのみ、端末に正確に認識されるようにプログラムをコンパイルすることが可能である。

開発者キーの必要な署名は、プログラム内のユーザーキーと特定の端末のキーにあるのと同じように、プログラム内に配置される。

そうすると、この「license-subkey」があることで、使用することが可能になるのです。

この生成は、顧客からキーの一部を受け取ったメタエディタ、すなわち開発者自身が行う必要があります。

そこで想像されたのが...。

しかし、霧の中から何かが出てくるわけではありません。

開発者の鍵を認証局МТ5から生成し、その鍵とユーザーの鍵の一部を使ったex5の復号手続きを端末に存在させることができれば、その仕組みや妥当性についてはここでは全く論じられない「ネイティブサービス」よりも多くの問題を解決できると思われます。

;)

[Renat Fatkhullin]

もし、鍵の保護について話すなら、インターネット全体がまさにこれらの鍵で溢れかえることになります。つまり、保護ではなく、複雑な実装で購入者に鍵の管理を強いる見せかけのものになるのです。

一番良い方法は、AppleのAppStore/iTunesの販売スキームが有効であることを見ることです。お客様は、キーの受け渡しや使用などの煩わしさがなく、クリックするだけでソフトを購入することができます。MQL5.comのアカウントをお持ちであれば、購入履歴を保持し、以前に購入したプログラムを再アクティブ化することができます。

プログラムを購入する際、ユーザーは特別に再コンパイル/再保護されたコピーを受け取るので、キーよりもはるかに良く販売者を保護することができます。購入時に個人保護の手続きが全て自動で行われます。

私たちの目標は、購入/売却のプロセスをできるだけ簡単にすることです。

[Sergey Kravchuk]

このスレッドには、もう一つ重要な機能、つまり試用期間やデモの制限が抜けていると思います。購入希望者は、まず自分が買うものを見たいと思うのは当然です。このため、購入された製品が制限なく動作する日付や時間に関する情報をどこかに隠さなければなりません（暗号化）。言語そのものに（pgpのような）いくつかのキーを持つ暗号化機構を埋め込むことで、この問題だけでなく他の多くの問題を解決できるように思います。

実際のアカウントで 作業している顧客だけに販売するのは理にかなっている（彼は購入する手段を持っている／持っていなければならないように）。この番号（多分、サーバー名やキーフレーズなど、さらにいくつかの情報を加えたもの）が、復号化のための鍵として使われます。ベンダーは、キーペアを生成し、それを使ってファイルを暗号化するメカニズムを内蔵している必要があります。

何を得るか？このファイルは暗号化されており、エキスパート/スクリプト/インジケータとともに購入者に渡されます。プラットフォームは、2番目のキーを受信し（顧客だけがアカウントにある）、暗号化されたファイルを読み取り、復号化します（チェックサムを確認することができ、キーが間違っていることが判明した場合は何も返しません）、Expert Advisor /スクリプト/インディケータに文字列としてそれを提供します。

また、EAの動作に関するパラメータを保存することもできます。 例えば、МАС交差 - アルゴリズムはデコンパイルしても明らかですが、これらのМАСが利益を上げている正確なパラメータは「秘密」かもしれませんし、これらのパラメータを知らずにEAをデコンパイルしても意味がありません。もちろん、多少の隙はあるし、妥協すべき点もあるだろうが、暗号化されたファイル内のデータ（Asmでは得られない）を知らない以上、すべては作者から製品とそのサポートを購入するよりもはるかに複雑になるのだ。

要するに、暗号化されたコンテナを提供し、そこに誰もが必要なデータを入れ、最も高度な保護を手配する必要があるのです。

[Renat Fatkhullin]

諸君、これがマスマーケットであることを忘れてはいけない。

買い手と売り手が一緒に交渉し、入札を交わし、鍵を送り合うという1：1の作業区分で考えているのですね。もちろん、こうするとあまり売れなくなります。一方、私たちは、売り手が販売のために指一本動かす必要のない、即売会を開催しています。そして、購入者は「購入」ボタンを押すだけで、アカウント番号や キー生成などの煩わしい作業は一切不要です。

すべてはすでに考え抜かれているのです。どのように動作するか知りたい場合は、AppStoreからiPhone/iPad用のソフトを購入して使ってください。

[Andrey Dik]

私個人の意見としては、ハードウェアに紐づくプロテクションという選択肢は、導入のしやすさ、使いやすさの両面で理想的だと思います。このバリアントについては、もうひとつの願いがあるのですが、それは後ほどお話しします。

口座番号/所有者名などとの 紐付けのオプションは、一見するとわからないが、不便である。買い手は毎週証券会社を変えて新しい口座を開くのが好きなのだから、そのたびに商品をコンパイルするのはどうだろう、しかもその商品のユーザーが何十人、何百人もいるとしたら......。キーはネット上で融合できる--という選択肢もない。

ハードウェアとのバインディングについてはどうでしょうか？ユーザーは複数のコンピュータで製品を使いたいかもしれないので、複数のハードウェアのバージョンにバインドする可能性を提供する必要があります。また、ユーザーがハードウェアのアップグレードを希望する場合、そのような場合には、アップグレードを実行する時間を例えば1時間程度にする必要があるかもしれません。で、その上で。これらの点について、私たちは考える必要があります。1台、2台、3台の機械に製品を永遠に縛り付けるのは間違っているし、お客様にとって不公平なことです。

[Renat Fatkhullin]

joo:

ハードウェアへのバインディングについては。ユーザーが複数のマシンで製品を使用したい場合、複数のハードウェアオプションにバインドする可能性を提供する必要があります。また、ユーザーが利用可能なハードウェアをアップグレードしたい場合、そのような場合には、ユーザーが新しいハードウェアに切り替える時間を、例えば1時間程度確保すべきかもしれません。で、その上で。これらの点について、私たちは考える必要があります。1台、2台、3台の機械に製品を永遠に縛り付けることは、お客様にとって正しくなく、公平ではありません。

ハードウェアを変更した場合、3回まで再利用できる自動的な権利は、十分に合理的で公平なものです。

[hrenfx]

Renat:
しかし同時に、保護されたEAをテスター（テスターエージェント）で実行できるようにし、ユーザーがテスターでEAのパフォーマンスを独自に検証できるようにし、豚を突いたような買い方をしないようにします。

歴史が縫い込まれているEAもあるんですよ。あるいは、ヒストリーベースから歴史を読み取ることができるもの。このようなダミーEAがテスターで顕著な結果を出しています。このような不正行為に対する保護はあるのでしょうか？特にExpert AdvisorがDLLと一緒に配信される場合は、注意が必要です。

MQL5-code＋悪意のあるDLL（スパイウェアからウイルスまで）の場合、サービスはどのように評判を守るのでしょうか？