security - Golang バイナリがエラーに関するファイルと行の情報を表示する方法と理由

Question

私は go sync グループで遊んでいて、完了とマークするよりも多くのグループを追加するとどうなるかを試しました。そして、私は以下に投稿したランタイムエラーを受け取ります。 したがって、ここでの質問は、go が java や c# とは異なり、真のマシン コードにコンパイルされているかどうかです。ファイル情報がバイナリに保持されている場合、簡単に逆コンパイルできると思います。私は何か間違ったことをしていますか?製品ビルド用に何らかの環境変数を追加する必要がありますか、それともc#のようにコードを非表示にする真の方法はありません

Answer 1

そこで、ちょっとした楽しみとして、panic() を実行するだけの簡単な Go プログラムを作成し、objdump と objcopy を使ってこの情報がどこにあるかを調べてみました。Linux (おそらくその他) では、Go は関連情報を ELF セクション .gopclntab に貼り付けます。削除すると、実際のプログラム ソースへの参照は消えますが、ランタイムはクラッシュします。そして、そのセクションには、より多くの runtime.* への参照があります (おそらくリンケージとイントロスペクションのため)。この情報が完全になくなった状態で Go プログラムを現実的に実行できる可能性は低いと思います。

SO の他の場所で述べられているように、セキュリティのために DWARF 情報を削除すると、ELF セクションの束が消えますが、本当に心配な場合は、コンパイル前にソースを前処理して識別子とファイル名を難読化することをお勧めします。しかし、そうするための既製のツールはないようです。

私は Go の設計者の 1 人ではありませんが、イントロスペクション (たとえば C ではできないこと) などのために、さらに先に進むことは非現実的だと思います。upx のようなコンプレッサーは、保存されているファイルをわずかに難読化します (そして、コンパイル済みの Go で問題なく動作するように見えます - そこに 1 つまたは 2 つの警告があるかもしれません)。私がそれについて言及したことで、私の開発者のライセンスを離れてください）。

現実には、あなたが現実的にできる最善のことは、あなたのコードをいじることに本当に興味を持っている人々をスピードバンプすることです. ソースを難読化するのは、本当にやる気があるのであれば、最善の策です (ただし、十分に決心した攻撃者にとっては最終的には無駄です)。