Goアプリケーションを販売したい。クライアントにシリアル番号を提供します。アプリのクラックをもう少し複雑にする方法はありますか?
私は、C アプリをクラックするのは複雑で、Java アプリをクラックするのは簡単だと言います。Go アプリのクラック作業を C アプリのクラック作業と同じくらい困難にするツールはありますか? またはいくつかのチュートリアル?少なくとも、プロジェクトを少し保護するためにできること。超重防御は問いません。
Goアプリケーションを販売したい。クライアントにシリアル番号を提供します。アプリのクラックをもう少し複雑にする方法はありますか?
私は、C アプリをクラックするのは複雑で、Java アプリをクラックするのは簡単だと言います。Go アプリのクラック作業を C アプリのクラック作業と同じくらい困難にするツールはありますか? またはいくつかのチュートリアル?少なくとも、プロジェクトを少し保護するためにできること。超重防御は問いません。
バイナリ自体を取得すると、難読化はかなり困難になります。人々は以前に Go バイナリからシンボルを取り除こうとしたことがありますが、特定のリフレクション操作にはシンボルが必要であるため、通常は不安定で予測不可能な動作につながります。
静的にリンクしているライブラリを必ずしも難読化できるわけではありませんが、コンパイル前に変数、型、および関数の名前を意味のない名前に変更することで、/own/ コードを確実に難読化できます。さらに一歩進めたい場合は、使用しているライブラリのソース コードを取得してみてください (標準ライブラリのソース コードは利用可能であり、ほとんどの Go インストールに含まれています)、この難読化をライブラリ ソースに適用します。コードも。
コンパイル後のバイナリ変更に関しては、前述したように、おそらく避けたほうがよいでしょう。
joshlf13 の回答を追加するには: Go バイナリを削除することはお勧めしませんが、リンカに渡してデバッグ シンボルをずっと省略できるフラグがあります。
「-s」フラグをリンカーに渡して、デバッグ情報を省略します (たとえば、go build -ldflags "-s" prog.go)。
コンパイル後のシンボルの削除に関する警告のような警告は見たことがないので、これは少なくともより良い方法であるはずです。
別のオプション、Go 1.16+ (2021 年 2 月:
burrowers/garble
通常のビルドと同じように機能するが、元のソース コードに関する情報ができるだけ少ないバイナリを生成します。
このツールは、次のように設計されています。
- と組み合わせて
cmd/go
、モジュールをサポートし、キャッシュを構築します- 同じ初期ソースコードを前提として、決定論的で再現可能
- パニックスタックトレースの難読化を解除するために、元のソースを元に戻すことができます
これは必要に応じて十分に難読化されていない可能性がありますが、良い出発点です。