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

新しいコメント
 

EX4に関しては、デコンパイルされたEditorである可能性が高いです。

しかも、プロテクトからして裸のようです。そこには、金融の流れはありません。

また、保護された コンポーネント（クライアントとエディタ）の両方がキーで操作できるのであれば、成功への望みはさらに高まります。

;)

 

5セント...


1.ほとんどの製品（すべてではないにせよ）は、使用するために接続が必要です。

2.このように、ネットワーク上（作者のウェブサイト上）に置かれた「サービス」という形の「鍵」。

ターミナルを起動すると、その上で動作しているインジケーターやExpert Advisorが「使用」される...

そして、その結果、デコンパイルの問題が発生しなくなりました。


カテゴリーから外れる。よほど面白い製品なのでしょう。

超秘密のアルゴリズムを "根拠 "に販売された製品のレビュー

は、何も面白くないし、さらに役に立たないことを示した...。然り


原理的には、アルゴリズムそのものが超ド級なので、作者がそう思えば、サイトに載せることができる。

Expert Advisor は、たとえ公開されていても秘密ではない取引プロセスのみを処理し、実行する必要があります。

- EA がリクエストを送信する（サブスクリプションによる）。

- 受信値

- 工程

- トレード

- が同時に描かれることがあります。

//

トレーディング以外のインジケーターも同様


アカウント番号 でサブスクリプション自体を整理する...


一般的には、ローマ皇帝がよく言ったように、「分割して征服せよ！」です。

 
circlesquares :


実は、デコンパイルはまだまだ問題なのです。必要なコードがすべてEA内にある場合、既知の作業キーでEAを逆コンパイルすると、EAのソースコードとその結果がすべて得られます。

しかし、コードの一部がウェブサイト上にある場合、これは非常に信頼性の低い解決策です。サイトに障害が発生した場合、お客様の金銭的損失は計り知れないものになります。

 
api :

また、以前どこかで、MQL5のコードはCPUのネイティブコードにコンパイルされるという話を見たことがあります。本当にそうなのか、そうでないのか：わからないが、もしそうなら、分解保護の重大な穴だ。

また、それによってどのようにセキュリティが低下するのでしょうか？

コードの追加は、非対称暗号を使うことで防いでいます。鍵が十分に長ければ、署名を偽造することは不可能でしょう。

もし、デコンパイルのことであれば、機械語ではその自動化は非常に困難です。自動デコンパイル（http://www.hex-rays.com/）の試みはありますが、主にコンパイラが生成したコードの可能な限りの選択肢を分析することに還元されます（私の理解では、機械語への変換はメタコード側で行われるので、これは全く些細な作業ではなくなります）。コード生成器を月の満ち欠けに縛り付けると（つまり、構成要素を様々な方法でコンパイルすると）、デコンパイルの自動化が非現実的になってしまうのです

 
lea :

また、それによってどのようにセキュリティが低下するのでしょうか？

コードの追加は、非対称暗号方式で防いでいます。鍵が十分に長ければ、署名を偽造することは不可能でしょう。

デコンパイルということであれば、機械語ではその自動化は非常に難しい。自動デコンパイル（http://www.hex-rays.com/）の試みはありますが、主にコンパイラが生成したコードのすべての可能なバージョンを分析することに還元されます（私の理解では、機械語への変換はメタコード側で行われるので、これはまったく些細な仕事ではなくなります）。コード生成器を月の満ち欠けに縛り付けると（つまり、構成要素を様々な方法でコンパイルすると）、デコンパイルの自動化が非現実的になってしまうのです


確かに、分解という意味です。私は、誰にでもよくあることですが、自分の能力で判断していました。ほとんどの場合、アセンブラテキストからアルゴリズムを簡単に再構築できるので、私にとっては逆コンパイルに似ています。もちろん、ポリモーフィック・ウイルスのアルゴリズムを利用すれば、このプロセスは非常に複雑になりますが、結局、アンチウイルスが存在する以上、この方法も完全な保証にはなりません。

 
api :


確かに、分解という意味です。誰にでもよくあることですが、私は自分の能力で判断していました。ほとんどの場合、アセンブラコードからアルゴリズムを簡単に再構築できるので、私にとっては逆コンパイルと同じです。もちろん、ポリモーフィック・ウイルスのアルゴリズムを利用すれば、このプロセスは非常に複雑になりますが、結局、アンチウイルスが存在する以上、この方法も完全な保証にはなりません。

大きなファイルを（idaでも）逆アセンブルし、手作業でアルゴリズムを再構築するのは、大変な時間と労力がかかります。この方法を実践する人が多いかどうかは疑問です。しかし、開発者が何らかの方法で生成されるマシンコードを複雑化させることに成功すれば、将来的にマシンコード・ファイルに可能な唯一の方法となるようだ。
アンチウイルスは、特別なアルゴリズムを使うことはほとんどありません。アンチウィルスは、ファイルや命令配列の特異性に固執します。私は、直列和で円周率を計算することに文句を言うアンチウィルスに遭遇しました（私はfpuを使う訓練をしていました）。デコンパイルは根本的に違う作業です。コード生成時に不可逆的なコード変異を行った場合、特徴的なコード変異による逆コンパイルは原理的に不可能です（コードをエミュレート/トレースして、どこから読み込まれたか、何をどこで書かれたか、何をどんなパラメータで呼ばれたか、など「高いレベル」で何が起きているかを監視する必要があります。アンチウイルスも同様のアプローチをとっていると考えられますが、彼らは様々なシステム機能の呼び出しシーケンスを監視するだけです）。

不可逆的な突然変異について、私はおそらくいくつかの記事へのリンクを投げるだろう（このようなリンクに運営と読者が気にしないことを望みます）。

 

MQL5でのコードの散逸/難読化だけに、各関数に特別なモディファイアを指定することができます。

void MyFunc(int val) trash
  {
   Print("Val: ",val);
  }

今のところ、ゴミと 呼ばれていますが、プロテクトに 変更する可能性が高いです。


その結果、コードが深く散乱し、指定した関数の動作が遅くなります。


また、MQL5コンパイラは最適化を多用しており、逆コンパイルの可能性を劇的に低減しています。

 
Renat :

MQL5でのコードガーベッジ/難読化のためだけに、各関数に特別なモディファイアを指定することができます。

それはいいことだ :) ゴミコードの割合を調整することは可能ですか？ 関数は呼び出し位置によって埋め込まれるのでしょうか？

 
lea :

それはいいですね :) ゴミコードの割合を調整することは可能でしょうか？ 関数の埋め込みは、呼び出しの時点で行われるのでしょうか？

ゴミの内容は毎回異なります。パーセンテージをカスタマイズすることはできません。コンパイラの判断に委ねられます。


自動インライン関数は以前から動作しています。関数の大きさや複雑さに応じてコンパイラ自身が判断しています。つまり、大きな関数はインライン化されない。

 

え...なんて生きやすいんだろう...。

ハッキングする気もないし、当面は何かを売るつもりもない。

それが人の悩みの種...。

:)))

123456789...17
新しいコメント