リバース エンジニアリングがどこで使用されているかを自問します。私はそれを学ぶことに興味があります。しかし、それを履歴書に記載できる/すべきかどうかはわかりません。
新しいチーフに、私を邪悪なハッカーだと思わせたくありません。:)
- それで、それは価値がありますか?
- 私はそれを学ぶべきですか、それとも他の場所に力を注ぐべきですか?
- そこに良い本やチュートリアルはありますか? :)
リバース エンジニアリングがどこで使用されているかを自問します。私はそれを学ぶことに興味があります。しかし、それを履歴書に記載できる/すべきかどうかはわかりません。
新しいチーフに、私を邪悪なハッカーだと思わせたくありません。:)
私の意見では、リバース エンジニアリングのスキルが役立つ可能性のある分野の 1 つは、たとえばウイルス対策業界です。ただし、履歴書に「リバース エンジニアリング」を記載するのではなく、さまざまな逆アセンブラー/デバッガー (IDA、SoftIce、OllyDbg など) やその他の関連スキルを使用して、アセンブリ言語での経験を書き留めます。
リバース エンジニアリングは通常、やりたいからではなく、やらなければならないために行うものです。たとえば、単に製品をリバース エンジニアリングすることには法的な問題があります。ただし、必要な場合があります。たとえば、サプライヤーがなくなって存在しなくなったり、連絡が取れなくなったりする場合です。良い例は、質問を入力した WMD エディターです。SO チーム/コミュニティは、難読化されたソースからこれをリバース エンジニアリングして、いくつかのバグ修正を適用する必要がありました。
私はリバース エンジニアリング プロジェクトに携わってきましたが、それらはハッキングとはまったく関係がありませんでした。私たちはそのようなすべてのプロジェクトのソース コードを (合法的に) 持っていましたが、プロジェクトの 1 つについては、コードが舞台裏で何をしているのか、他のシステムとどのように相互作用するのか、実際には誰も知りませんでした。その情報は長い間失われていました。別のプロジェクトでは、ソース コードといくつかのドキュメントがありましたが、ドキュメントが最新ではなかったため、ソースをリバース エンジニアリングしてドキュメントを更新する必要がありました。
履歴書にそのようなプロジェクトを書いてもかまいません。実際、その過程で多くのことを学んだと思います。
ドキュメントが失われたり、ドキュメントが存在しなかった場合は常に、リバース エンジニアリングが必要です。ソースは役に立ちますが、元のロジック、フロー制御、バグをリバース エンジニアリングする必要があります。
(私の経験では) 古いコードに欠陥があるか、要件の変更により古くなったか、またはその両方に遭遇することは非常に一般的です。不十分なドキュメントがあり、元の開発者が利用できなくなっていることがよくあります。そのコードをリバース エンジニアリングして、その仕組みを理解する (場合によっては、修復するか置き換えるかを決定する) ことは重要なスキルです。
ソースがある場合は、多くの場合、慎重に計画され、厳密に範囲を限定した少量のクリーンアップを行うのが合理的です。(私は、これが貴重な開発者の時間の陥没穴になることを許してはならないことを大声でほのめかしています!)
テストベッドでコードを実行できることも非常に役に立ちます。コードが期待どおりに機能することを確認したり、欠陥を特定、文書化、分離、修復したりできます。
安全に行うには、慎重な作業が必要です。このようなコードをテストするための実践的なガイダンスとして、Michael Feathers の書籍Working with Legacy Codeを強くお勧めします。
RCE は、セキュリティ担当者 (研究、エクスプロイト、IDS、IPS、AV など) にとって優れたスキルですが、対象について深く低レベルの理解があることも証明します。
サードパーティのライブラリを使用する場合も、簡単に道を見つけることができます。
セキュリティ業界で働いていない場合や、ASM が苦手な場合は、わざわざ学習する必要はありません。一般に、ASM は習得が難しいものです。
書籍
搾取の技術をハッキングすることは、セキュリティの観点から主題について語っています。
また、Ollydbg と IDA Pro に関する本を読むこともできます。