ドミトリー・スクリャロフ：「注意力と少しの論理。 どのくらい複雑か。」

ロシアコードカップ2013の決勝大会のゲストのスピーチの概要を、Habrの住民と共有し続けます。本日、リバースエンジニアリングに関するDmitry Sklyarovのストーリーの概要をご紹介します。



ドミトリー・スクリャロフ-MSTU情報セキュリティ学部准教授。 BaumanおよびPositive Technologiesのアナリスト。 彼は情報セキュリティの分野で13年以上働いています。 Advanced eBook Processorのアルゴリズム開発者。



もちろん、逆転はIT分野で最も簡単な分野ではありません。 ただし、結果を取得するため、つまり、プログラムの機能を理解するために、コードの各行と各アセンブラーコマンドを常に分析する必要はありません。 いくつかの単純な論理的結論と「プログラマのように考える」能力で十分な場合もあります。 私の言いたいことを理解するために、私の実践から得られた分析の2つの例が役立ちます。

ブラックボックスの中身は何ですか？

CTFで最初の課題に直面しました。 CTFは一種のオリンピアードプログラミングであり、情報セキュリティの分野の専門家専用です。 ミッションはドンビーチと呼ばれていました。 だから、私たちは与えられます：

• プログラムで実装された「ブラックボックス」-入力シーケンスを出力に変換する実行可能ファイル
• 出力される値

入力に供給する12バイトのシーケンスを決定する必要があります。



明らかに、このタスクは単純な網羅的検索では解決されません。 プログラム内で何が起こるか、入力を出力に変換するもの、および特定の出力を得るために入力値を選択する方法を見つける必要があります。



もちろん、最初の段階で、プログラムは逆アセンブラにロードされます。 以下は、彼が発行した2つのコードです。











ここで、アセンブリプロセスから残っている行に簡単に気付くことができます。 ほとんどの場合、これらのメッセージは、何が議論されているかを推測しやすくするために、主催者によって特別に作成されました。 私の頭のvm_set_paramsとvm_get_outputの行を見ると、疑問がすぐに生じます：vmとは何ですか？ さらに、一般的に、仮想マシンのみが思い浮かびます。 したがって、ここで仮想マシンが使用されているとすぐに想定し、これに基づいてさらに分析を構築できます。











4つの連続した関数呼び出しがあります（それらの間のポイントはパラメーターの準備にすぎません）。 パラメータのロードと結果の抽出の間に何ができるのでしょうか？ 仮想マシンの初期化と起動があると仮定するのは論理的です。 VM初期化コードを逆アセンブルしてみましょう。







そのため、vm_initコードを確認すると、かなり多数の明確ではない操作が見られます。 インテルと互換性のあるコンピューターのアセンブリ言語にほぼ20年間精通しているという事実にもかかわらず、浮動小数点命令を分析することはめったにありません。 したがって、ディレクトリの助けを借りずにこのコードを見ただけでは、それが何をするのかを言えません。 このコードからどのような結論を引き出すことができますか？

• 64ビットMMXレジスタを使用します
• 機能コードは420個のコマンドで構成されています
• 何も明確ではありません

もちろん、ノートブックに座って420のチームすべてを分析し、それぞれのチームが何をしているか、したがって結果として何が起こるかを理解することができます。 しかし、これは最も効果的な方法ではないと思われたため、このタスクに別の方法でアプローチすることにしました。



初期データからレジスタを何らかの形でロードする関数vm_initがあります。 入力は8つの32ビット値です。 これらの値に定数を設定し、00から1Fまでのバイトをマークするとどうなりますか？











各バイトが1回コピーされたことがわかります。 単一の繰り返しや単一の新しい値はありません。異なる色で色付けするだけで、どのバイトがマッピングされているかを確認できます。



そのため、1行を解析することなく、単に入力と出力を比較するだけで、関数の機能を理解しました。 この方法でこれを行うことができると提案したのはなぜですか？ これは論理的であるため、これはまさに仮想マシンの初期状態のブート機能から期待されるものです。

その後、vm_runと呼んだ関数が何をするのか分析することにしました。 その中には次のものがあります。

• マルチメディアレジスタを操作するための膨大な数のコード
• 仮想マシンのコマンドストリームを解析するとき、各コマンドコードが1バイトを取り、1つの引数があることは明らかです（オプション）
• コマンドの各バイトには独自の処理機能があります
• 各処理関数の複雑さはvm_initの場合とほぼ同じです（したがって、それを分解したいというわずかな欲求はありません。これは難しく、おそらく最も効率的な方法ではありません）
• ほとんどの命令は実際には同じハンドラーにマップされます（おそらくこれはnop関数です）
• すべての処理が1サイクルで行われます

そのため、仮想マシンのコマンドを解析する標準プロセスがあります：オペランドを指すコマンドコードとその引数を取得し、1つまたは別のオペレーションコードを実装する関数を通じて実行してから、次のオペレーションコードに進みます。



小さなデバッガーを作成しましたが、プログラムが何をするのかを段階的に見るのではなく、各ポイントですべてのMMXレジスターのステータスをトレースすることにしました。 その結果、ログファイルが作成され、現在の各コマンドについて、実行の前後にVMの状態が記録され、操作コードと1バイトが追加され、操作コードを認識してロジックを復元できるようになりました。



ここに私が得たものがあります：







レジスタR0の値は入力に送られ、出力ではスタックに置かれます。 レジスタR6の値が減少し、逆にR7が増加することがわかります。



このことから、R6はスタックへのカウンターポインターであり、データをスタックに追加すると減少し、R7はコマンドへのポインターであると結論付けることができます。 この場合、オペレーションコード0D-00のコマ​​ンドは、ゼロレジスタからスタックに値を転送しました。







R4レジスタにあった値は再びスタック上にあり、コマンドコード0D04は引数のみが前のものと異なります。 このことから、プッシュオペレーションコードである0Dはスタック上のデータの配置であり、オペレーションコードの後の最初のバイトの値は、このオペレーションで使用されるレジスタ番号へのポインタであると想定できます。







実行前後のレジスタの状態は1つのレジスタでのみ異なります。これを命令ポインタ（Instruction Pointer）と呼びます。これは、変更が発生していないことを意味します。 したがって、オペレーションコード06は何もしないnopであると想定できます。







この場合、引数はFFの値であり、スタック上にあり、スタックポインターは減少しました。 このコマンドは、引数にあった値を32ビット値としてスタックにロードするという仮定を立てるのは簡単です。







このコマンドが実行されたとき、スタックの値は2番目のレジスタにありました。 したがって、オペレーションコード4Cはスタックからの抽出であり、それに続く引数はレジスタ番号です。 このような仮定は、単純に入力と出力のペアを見るだけで行うことができます。



プロトコルが完全に分析され、不要な行が失われた後、この仮想マシンでは少数のコマンドが使用されていることが判明しました。 nopコマンドがあります。これは、レジスタからスタックにデータを配置し、スタックからデータを取得し、レジスタ間を移動し、追加し、論理演算し、xorをシフトするコマンドです。







movや左シフトなどの一部の操作は、2つまたは3つの異なる方法で実装されますが、重要ではありません-それらが何をしているのかは既にわかっています。 そのため、プロトコルを減らした後、この仮想マシンの言語でプログラムのリストを取得しました。 それを単純に分析し、元に戻すことが残っています。







残念ながら、テスト時間の終了15分後にこの問題を解決しました。つまり、なんとか合格することはできませんでしたが、ソリューションプロセス自体は非常に興味深いものでした。 なんでこんなにシンプルになったの？ タスクの作成者は、プロセッサのMMXレジスタに仮想マシンの状態全体を実装したためです。



内部で発生した他のすべては、仮想マシンの完全に論理的な操作です。 単純な仮想マシンの作成を開始した場合、ほぼ同じ方法で作成します。 レジスタがMMXレジスタに一意の方法でマップされ、この一意のマッピングを簡単に識別できるという唯一のアイデアを使用して、アセンブラコードの分析に頼ることなく問題を解決しました。

それはとても信頼できますか？

すでに実際に発生した2番目の問題は、逆アセンブラをまったくロードせずに解決できました。 システム機器の安全性の分析に携わっている同僚が私のところに来て、テストが必要な新しいハードウェアを受け取ったと言いました。



この部分では、設定で何らかの値に変換されるパスワードを設定できます。 値は文字列で、ある種のハッシュのように見えますが、どれが明確ではありません。 私の仕事は、利用可能な構成を分析することにより、同僚がデバイスをどの程度保護するかを評価するために必要なアルゴリズムの詳細をすべて見つけることでした。



9人のユーザーのパスワードを生成しました。







一目で見えるものは何ですか？ すべてのパスワードの最後の文字は同じであり、最初の文字は大幅に変更されていることがわかります。 さらに、ハッシュは常に24文字であり、最後の13文字は変更されず、合計50の異なる文字、句読点および数字が使用されることは明らかです。



残念ながら、これは明らかに、パスワードをハッシュに変換するアルゴリズムの内部で何が起こっているかについての有意義な結論には十分ではありません。



私はこれらのパスワードをもっと必要とし、みんなにそれをするように頼みましたが、それは一日の終わりであり、私はすぐにパスワードを受け取りませんでした。 しかし、新しいデータが登場する前に、いくつかの推測をすることができました。

1. いくつかのビットをより少ないビットにエンコードするエンコードが使用されます。 おそらく、これらはBase16、Base32、Base64などの標準エンコーディングです。
2. 文字数> = 50ですが、50文字はどういうわけかクールではなく、2の累乗ではありません。 一方、エンコーディングテーブル内の64文字は、かなり良い推測です。 なんで？ Base64は、1文字が6ビットをエンコードすることを意味するため、合計で64の状態があります。
3. パスワードは24文字で、13文字は変更されず、11文字は可変です。 それらのそれぞれが6ビット、つまり66ビットの変化を表す場合、これはすでに2の累乗および8バイトブロックに十分に近いです。
4. 明らかに、mime64は使用できる文字を明確に定義し、提供されたパスワードハッシュは無効な文字を使用したため、mime64を扱っていません。
5. したがって、mime64以外のエンコードテーブルを使用して、Base64に類似したエンコードが行われます。 さらに、ハッシュは明確に見える2つの部分に分割され、一方は変化し、もう一方は変化しません。 これは、おそらく暗号化が64ビットブロックで使用され、各ブロックが個別に暗号化されることを示唆しています。

入力素材がない間に他に何ができますか？ 検索を使用できます。 一定の行を探すと、検索エンジンはこの行が言及されている約43,000ページを見つけることがわかります。 これは驚くことではありません。機器は広く普及しており、人々はドキュメントや構成ファイルの一部を使用して問題を説明することがよくありました。 この行が見つかったページをスクロールして、そこにリストされているハッシュの断片を収集しました。 正確に64文字が使用されていることが判明しました。 ここにあります：



！ "＃$％＆ '（）* +、-。/ 0123456789 :; <=> @ A



BCDEFGHIJKLMNOPQRSTUVWXYZ [\] ^ _ `a



そこで、文字セットを復元しました。 しかし、キャラクター自体に加えて、あなたは彼らがどの順番で行くかを知る必要もあります。 すべての文字が次々に進む統計的なシーケンスがありますが、「？」はありません。最後に、指定されたすべての文字の中で最大のコードを持つ文字「a」があります。 ただし、どの順序で進むべきかは明確ではなく、インターネットはこの問題を解決できません。



インターネットで見つかったドキュメントから他に何が得られますか？ パスワードが16文字以下の場合、24文字の文字列で暗号化されるという記述があります。 パスワードが16〜63文字の場合、88文字の行になります。 さらに、このような数の文字は非常に簡単に説明できます。



24 * 6 == 144 == 18 * 8 ==（2 * 8 + 2）* 8



88 * 6 == 528 == 66 * 8 ==（8 * 8 +2）* 8



24個の6ビット文字を使用すると、144ビットが得られます。これは、2つの8バイトブロックとさらに2バイトに簡単に分割できます。 88文字も同様に8つの8バイトブロックと2バイトに分割されます。 入力文字を週末の文字に変換するための論理的で予測可能なスキームがあります。 パスワードの文字数が16文字未満の場合、それぞれが暗号化された2つの8バイトブロックを取得し、最後に2バイトを追加します。これはすべてエンコードされます。



最後に、私の同僚は私のために511個のパスワードを生成しました。 さまざまな長さのパスワード、空のパスワード、16を超えるパスワードを要求しました。この特定のデバイスは16文字を超えるパスワードのハッシュを作成できず、空のパスワードを設定できないことがわかりました。 ただし、0000から0510の値を持つパスワードハッシュが生成されました。



予想どおり、これらのハッシュはすべて最後の13文字を変更せず、0〜9の位置で、以前にインターネット検索で見つけた64文字のバリアントがすべて見つかりました。



10番目の位置では、下の画像で赤で強調表示されている文字のみがありました。







記号がピリオド4と交互になっているのは容易にわかります。文字「a」の領域では、交代が中断され、さらに交代が最後に再び中断されます。 文字「a」がその場所に再配置され、行方不明の「？」が立っていた場合はどうなりますか？ 結果は非常に美しい画像であり、4文字の明確な期間を観察します。







これは、文字がエンコードされるとおりに正確に移動する正しいテーブルであると想定できます。 これをもう1つ確認します。長方形で強調表示されている最後の4文字は、異なる長さのパスワードのハッシュを示す次の図で赤で強調表示されています。







このリストから、パスワードは8文字以下ですが、ハッシュの右半分は一定であることがわかります。 パスワードに8文字以上が含まれている場合、最後の2文字も変更されず、最初の10文字は定数であり、11番目は4つの状態を取り、11文字のブロックが混oticとして変化します。



どのようなスキームの下で、この変化の論理を調整できますか？

• pwd [0：8]はout [0:10] + 4ビットout [10]に影響します
• pwd [8:16]は2ビット出力[10] +出力[11:21] + 2ビット出力[21]に影響します
• out [22:24] ==“ !!”

以前に取得したアルファベットに従ってBase64エンコードが行われる機能を説明することは非常に可能です。 内部には、2つの8バイトブロックの連結があります。これは、パスワードの前半と後半からの関数の計算であり、最後に2つのゼロバイトが追加されます。これは、同じエンコードテーブルを使用して感嘆符に変わります。



Base64（fn（pwd [0：8]）+ fn（pwd [8:16]）+“ \ 0 \ 0”）



回路は美しいですが、未知の要素が1つあります。この関数が何であるかはわかりません。 関数はパスワードの8文字を出力に正確にどのように変換しますか？ わかっているのは、64ビットから64ビットに変換されていることだけです。 理論的には、これはハッシュ関数かもしれませんが、第一に、頻繁に使用される良い64ビットハッシュ関数を知りません。第二に、入力のサイズが出力のサイズに等しいことはなんとなく疑わしいです。 パスワード全体をハッシュ関数の入力に送信し、出力で指定された長さの値を取得する方が簡単です。



おそらく、これは64ビットブロックを使用した暗号化アルゴリズムです。 私はアルゴリズムが何であるかを調べることにしました。そして、多くのオプションがあり、それらは多かれ少なかれ人気があることが判明しました。 さらに、アルゴリズムを知っていても、最も重要な要素である暗号化キーは謎のままです。



その結果、「暗号化アルゴリズムをどのように見つけ、どこでキーを入手するか」という質問に直面します。合理的なアイデアは、ファームウェアを調べることです。 ファームウェアを逆アセンブラにロードしようとしましたが、すぐにプロセッサアーキテクチャを知らないことが明らかになりました。 多くのアーキテクチャがあり、私が使用している逆アセンブラは約50種類のアーキテクチャをサポートしており、世界にはさらに多くのアーキテクチャがあります。 バイトコードによって、どのアーキテクチャを扱っているかを常に判断することはできません。 ファイルにヘッダーがある場合、.exeファイルまたはELFである場合、1つです。 しかし、私の目の前には20メガバイトより大きいバイナリファイルがありました。 このファイルの分析を短時間で開始できなかったため、別のアイデアを試すことにしました。



しかし、8バイトブロックの最も一般的な暗号化アルゴリズムが使用されていると仮定するとどうなりますか？ これはおそらくDESアルゴリズムです。



2番目の質問は、「暗号化キーはどこにありますか？」です。 そのような英語の単語があります-ハードコードされています。 多くのセキュリティシステムでは、機密性の基本となる要素が実行可能ファイルにハードコーディングされています。 しかし、ファームウェアで暗号化キーを探すとどうなりますか？



その結果、20行のプログラムが書き込まれ、ファームウェアでファイルを開き、メモリに読み込み、最初の8バイトを取得し、上記の関数で暗号化キーとして解釈しようとしました。 次に、ファイルの最後まで1バイト、2バイトのオフセットで8バイトのブロックを取りました。 必要な一致があった場合（つまり、Base64のエンコードおよびエンコード後に、受信する予定の行が表示された場合）、対応するメッセージが表示されました。



キーはファイル内で12回検出され、完全に論理的なバイトシーケンスを表していることが判明しました。



01 02 03 04 05 06 07 08



このシーケンスがキーの一部であるかどうかさえわかりません。 おそらくキーは複雑で複雑な方法で生成されますが、この行はDESに適したキーであり、必要な変換を行う関数を取得できます。



その結果、pyDesライブラリを使用してPythonでこれらのハッシュ（ハッシュではなく、暗号化された可逆パスワードであることが判明した）を復号化するためのコードは10行に収まります。

from pyDes import * charset = """!"#$%&'()*+,-./0123456789:;<=>a@""" \ + """ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`""" def numFromHash(s): return reduce (lambda v, c: (v << 6) + charset.index(c), s, 0L) def restorePwd(s): v = ("%036X" % numFromHash(s)).decode("hex") k = des("0102030405060708".decode("hex")) pwd = k.decrypt(v[0:8]) + k.decrypt(v[8:16]) return pwd.rstrip('\0')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

道徳

コード分​​析がとても簡単なのはなぜですか？ コードは、コードの効率、一貫性、および理解に重点を置いているプログラマーによって作成されているためです。 たとえば、2番目の例で非標準だったものは何ですか？ Base64変換テーブルは標準ではありませんが、同時にテーブル自体は統計に基づいて要素的に復元されます。 それ以外はすべて、典型的な学生ラボのアプローチです。 ここでは、復旧プロセスを複雑にするようなハイライトはありません。 開発者はそのようなタスクを設定しなかったかもしれませんが、一般に、情報セキュリティの分野で作業している場合、要素を開発するときに、できるだけ単純で理解しやすいものにしようとしないでください。 相手はプログラマーとして論理的に考えようとし、あなたが決定に入れたすべてのメカニズムを非常に迅速に明らかにしようとするので、これはあなたにとって横向きになるかもしれません。