仲間のプログラマーが最悪のプログラミング手法を使用した

言うのは奇妙に思えますが、職場の仲間のプログラマーは故意にいくつかの悪いプログラミング慣行を意図的に使用しました！説明します。まず、彼は知的な男であり、ほとんどの場合、彼はわかりやすいコードを書いていると言いましょう。

彼は、Javaで書かれたWebアプリケーションプロジェクトにライセンスを実装するよう求められました。Javaなので、本当に必要な場合は、おそらくjarファイルをハックして、内部に記述されたクラスとメソッドの名前を読み取ることができます。この問題に対する彼の解決策は、文字通り、新しいクラスを生成するのではなく、変数とメソッドをわかりにくい名前で不自然に呼び出し、すでに混雑しているクラス内にそれらを植え付けることでした。

彼の正当化は、ハッカーがライセンスチェックをバイパスするために特定のクラスを切り替えたい（したがって、製品の無料コピーを取得したい）場合、どの方法が明らかでない場合、それははるかに困難な時間になるだろうということでしたこれらの特定のタスクを実行します。彼がそれを行って初めて、私は彼に立ち向かったので、良いプログラミングの実践を維持しながら、何らかの難読化ライブラリを購入してそれを行うことができるかもしれないと示唆しました。彼は、その種のソリューションを検索する時間やリソースがなかったと主張しています。

..私はジレンマに陥ります。Javaで難読化ライブラリを探して、彼の古いコードを修正します（彼のコードを改造するのは少し面倒かもしれません）か、それをそのままにしておきますか？

難読化によるセキュリティは、決して優れたセキュリティではありません。あなたの知的財産を保護するより良い方法がなければなりません。そして、それはあなたとあなたの同僚があなたの上司との共同懸念として提起すべきものです。その後、経営陣がセキュリティの向上に時間やお金を費やしたくないと判断した場合、あなたとあなたの両方がその決定に沿って生きなければなりません（あなたの製品ではなく、会社の製品です）。これ以上の時間。

オリジナル：上司は何と言っていますか？調べる-それを行います。

上記について詳しく説明するように依頼されました。

まず、ジレンマは複数あると思います。

• 他の人のコードを「修正」する必要がありますか？
• 他の人の実装（ここからA）は、他の人に置き換えられるほど十分に悪いですか？
• この「アプリケーションにライセンスを埋め込む」には、難読化ツール（ここからB）が適していますか？

まず、問題はビジネスケースから見IS解決しました。Aは適切な場所にあり、ほとんどの場合、問題の「十分な」解決策です。あなたの会社は、基本的にそれを破壊するために意図的な努力が必要であるだけで十分に保護されていることに満足しているかもしれません。

これは、たとえあなたがそれを嫌っていても（そして、私を信じて、あなたのキャリアを通してずっと悪いことに気付くでしょう）、それが必要なことをすることを意味します。したがって、問題が解決されると、「ただそれを行う」のではなく、むしろあなたの仕事を担当する担当者に長期的に納得させるべきです。この実装の価格は、ロールバックと在庫難読化ツールの選択を保証するのに十分な高さになります。これには、かなりの準備が必要です。また、難読化ツールには、知っておく必要のある欠点もあることに注意してください（他の答えもこれに当てはまります）。たとえば、スタックトレースはすぐに使用できるわけではありません。すべては、著作権侵害を回避することがどれだけ重要かによって異なります。最も壊れにくいのは、ハードウェアドングルの実行が必要なものであり、顧客が望むよりも高価である可能性が高いことに注意してください。

したがって、あなたの会社はBに行くために追加のリソースを使用する必要があるため、この決定はあなたの意思ではありません。したがって、責任者に懸念を伝え、これと他の長期的な懸念を十分に説明して彼が理由を理解する必要がありますあなたはそれがあなたの提案に劣ると考えます。その後、彼に決定を下させ、結果がどうなるかに関係なく、それを尊重し、それに応じて専門家として振る舞います。オリジナルの作者は、おそらくそれを書いたときとにかくそれを維持しなければならないことに注意してください。もし彼がそれを去るか、それを望まないなら、あなたは問題を再び持ち出すことができます。

言い換えれば、あなたの上司は何と言っていますか？調べる-それを行います。

また、Aの実装に費やした時間の無駄遣いが少なくなるように、以前に問題を提起していた場合、これは異なっていたことに注意してください。言い換えれば、AとBの間の選択が行われることになったとき。

最後に、「他の人のコードを修正する」というあなたの質問にコメントしたいと思います。これは、既存のコードに対する小さな修正ではありません（特にテストが実施されている場合は、これが問題なく推奨されます）。これは破壊的なロールバックと再実装であり、コードの所有権が共通のチームであっても、事前の承認なしでは、少なくとも私にとってはこれは受け入れられないことです。

うまくいけば、これが私の見方を明確にする。

Javaで難読化ライブラリを探して、彼の古いコードを修正します（彼のコードを改造するのは少し面倒かもしれません）か、それをそのままにしておきますか？

いいえ、誰かの後ろに戻って、彼らが担当するコードを変更することは、最初に疑わしいコードを書くよりも悪い犯罪になるでしょう。

プログラマーと一緒に持ち出しました。次のステップは、鼻を出さないようにするか、管理者と一緒に持ち出し、鼻を出さないようにすることです。

あらゆる種類の公式のコードレビューがありましたか？あるいは、あなたが非公式の「コードレビュー」を受けた対立がありましたか？これはセキュリティやライセンスなどのデリケートで重要なテーマであるため、これを連鎖的に引き上げる必要があると思います。最初の部分、つまりプログラマーとの対決を完了しました。しかし、彼が聞いていないので、あなたはそれを取り上げることができます/すべきです。そうでない場合は、問題の一部である可能性があります。

私は彼にあなたがそれをやろうとしていると言います-これは彼の心を変えるかもしれません。そうでない場合は、状況について非常に政治的に正しいが、正確で簡潔なメールを上司に書き、プログラマーにCCします。電子メールで、3人または他の参加者の間でミーティングを依頼します。

常にこれらのことを真正面から満たしてください。しかも政治的で友好的な方法で。

クラスのシグネチャ（メソッド名など）を難読化できる難読化ツールを見つけられる場合は、それを購入して使用することを提案してください。

それまでは、それと一緒に暮らさなければならないかもしれません。最近のGrailsプロジェクトで似たようなことをすることは認めています。ライセンスチェックは既に大きなログインメソッドに意図的に組み込まれているため、チェックをバイパスするためにメソッドを置き換えるのはかなり困難です。

彼はそのようなハッキングが実行可能であることを実証できますか、それとも彼がちょっと心配しているのは単なる仮説シナリオですか？彼はこの作業のライブデモを提供できますか？彼は試してみてください。真剣に。動作する場合は、管理者に提示し、難読化ツールを入手することを提案する必要があります。

難読化ツールのセキュリティが十分でない場合、JARをセキュリティで保護する他の方法（暗号化、ネイティブコードへのコンパイルなど）を検討しましたか？

RE：コードの修正：名前を変更するだけの問題ですか？多くのIDEには、これを非常に簡単に実行できるリファクタリングツールがあります。

IPがどれほど価値があるかに関係なく、ハッカーを混乱させることを期待してコードを破壊することは賢明なことではありません。前進を続けることは悪夢であるという事実は別として、それは実際には問題を解決しません。それは単に難しくしますが、不可能ではありません。したがって、それは実際には解決策ではなく、副作用は悪いです。それは効かない薬を服用しているようなもので、副作用があります。

あなたの問題は、IPを保護する方法です。そのためのソリューションを見つけてください：難読化ツール、ライセンスサーバーなど。

別の開発者は、当社の暗号化/復号化ルーチンを命名するとき、私は同様の問題に遭遇したstr__copyとstr__delete（第2アンダースコアに注意してください）。それは不十分であり、もっとうまくやることができたので、ライセンスの更新が必要になるという話が出るまで待ちました。経営陣は、「ライセンスを取得するときにクリーンアップするので、時間がかからず、より安全になる」と説明したため、余分な数時間の問題はありませんでした。問題は解決しましたが、痛みはありません。

最初に考えたのは、そのコードのメンテナンスです。コードがすでに難読化されており、彼が先に進んでいる場合は、そのコードを処理しようとして頑張ってください。その後、コードを解読しようとするハッカーになります。

代わりに、コードをクリーンアップし、難読化ツールを使用してすべてのハードワークを行うことをお勧めします。長期的には、多くの管理可能なコードがあり、ライセンスをハッキングしたい人にすべての複雑な複雑さを任せます。

完璧な難読化者はいないことを忘れないでください。また、非常に熱心なハッカーは何でもリバースエンジニアリングできますが、少なくとも彼だけです。さらに、難読化ツールは、ある人がおそらくできるよりもはるかに複雑さを増します。

私はあなたが上司に問題について尋ね、彼が言うことをするべきであるという答えに非常に同意します。

ただし、これらの回答に対する非常に重要な補遺は、セキュリティと保守性の両方に関する懸念を文書化することです。コードを変更するかどうかにかかわらず、人々があなたが心配していることとその理由を知ることが重要です。これは、積極的に（上司が行う必要があることさえ知らない上司に決定を下すことはできません）および防御的に（ハッカーがセキュリティが不十分なライセンスシステムに穴を開けた場合、彼らを責めることはできません）重要です間違い。）

「問題を知るための最も優れた専門家にならないでください」。

言い換えれば、あなたの上司に言って、そこから行きましょう。あなたが静かに保ち、あなたがその秘密のトトマポールのトップなら、プッシュが突き出るようになると、あなたは責任を負います。上司に合格を伝えて、上司にアプローチする方法を決めさせます。そうすれば、選択の負担から解放されます。

多くのマネージャーは技術的ではないかもしれないので、単に上司に話してはいけません。しかし、私たちはいつもやっていることをやってください。その後、彼らに決定させ、それを流した。マネージャー/リーダーが大金を支払われるのはそのためです！

明白な真実は、十分な時間とリソースがあれば、何でも解読できるということです。これは、アプリの人気度の単純な関数です。人気が高いほど、それが引き付けるスキルの高いハッカーであり、それを破るためにより多くの時間が費やされます。コードの難読化はまさにそれを提供します-暗号化と同様に、それを破るのに必要な時間を増やす手段。したがって、コードが難読化されている場合、攻撃者は熟練し、時間を割く必要があります。そうしないと、攻撃者は絶望してあきらめます。あなたのアプリが両端のトラブルに見合う価値があるかどうかを自問する必要があります。

実際、難読化されたコードをクラックするのがどれほど困難になるかは驚くべきことです。難読化により、簡単な10行のCプログラムを100行のアセンブリに簡単に変換できます。デバッグしようとすると、コードを無意味に飛び回ってしまい、ステップスルーするのが本当にイライラする可能性があります。最終的には壊れますが、それは本当に難しくなり、本当に不可能なことはないので、それがポイントです。コードの難読化は、それを破ることができる人の数を減らします。

もちろん、クラッカーではなくデバッガーを混乱させようとするなど、より良い方法がありますが、これは安価で効率的な方法です。しかし、不自然に名前を付けても、それは完全にはカットされません。コード全体に対して実際には何もしない制御フロー呼び出し関数を変更する必要がありますが、サイズと複雑さを増します。戻り値がどこでも使用されないダミー関数を、実際に何かを行う関数内から呼び出します。あなたはすでにこれがどのように本当に混乱するかを見ることができます。

攻撃者にはないものがあります。元のソースコード。自分で整理する方法を見つけてください。