.NET Reactor 4.0-Metadata手動修復記
.NET Reactor 4.0(Beta)は以前のバージョンに比べて大きくアップグレードされており、最も一般的な「Suppress ILDASM」でも「Suppress Decompilation/Anti ILDASM」にアップグレードされている.本稿では,この機能を事例として,メタデータテーブル構造に対する認識を鍛える.1.暗号化ターゲットセットを探し、4.0で暗号化し、他のオプションを選択しないように注意し、「Quick Settings」の「Anti ILDASM」だけを選択すればよい.本明細書の目的は、解読プロセスを完了するためではなく、メタデータテーブルを手動で修復することです.私たちが使うとき.NET ReflectorまたはMono Cecilがこの暗号化されたプログラムを開くと、エラーが発生し、一定の防護能力があることがわかります.次に、私たちはそれに従います.NET Reflectorが与えたエラーメッセージは、手動修復プロセスを開始します.2.修復には、CFExplorer VII、ILDASM(修正版)、計算機(16進数計算)、情報を手当たり次第に記録する手帳など、対応するツールソフトウェアを用意します.(1) NumberOfRvaAndSizes
このエラーは、通常、Optional HeaderのNumberOfRvaAndSizesが修正されたものであり、実際の値は0 x 0000000(16)であるべきである.保存を変更し、Reflectorをリフレッシュして、次のエラーメッセージを続行します.(2) NumberOfStreams
これも比較的一般的な手段であり,誤ったMetaData Streamsをもたらすことによって干渉の目的を達成する.
偽のGUlDとBlopが1つ増えた.大丈夫です.後ろの正しいOffsetとSize値をパクリの位置にコピーし、Hex Editorで対応するOffsetの位置にジャンプして、この2つの偽物の名前を修正します.
もちろん、MetaData HeaderでNumberOfStreamsを0007から0005に変更することを忘れないでください.保存後、ターゲットファイルをCFExplorer VIIで再度開きます.MetaData Streamsを再参照すると、#Strings、#GUID、#US、および#Blobデータは正常に戻ります.(3)Multiple Assembly Definitionsが次のエラーメッセージを更新します.
めまい~~~これは変態すぎて、意外にも複数のプログラムセットが含まれています.これは明らかに#~Streamが動いた.
Tableで私たちはやはり多くの破壊分子を見た.どうしようかな?まずMetadataの構造知識を復習します.#~の上位24 bytesにはMetadata Header情報が格納されています.0 x 0000018(Offset 24)から格納されるのは、Rows情報、つまりTableで見た様々なタイプの統計値です.Rowsの長さは4*nです.
数えてみると、全部で15種類、つまり長さは60(0 x 3 c)、オフセット位置は0 x 0000018~0 x 0000053のはずです.Assemblyのインデックス番号は11(0から)で、オフセット位置は0 x 0000018+11*4=0 x 0000044です.CFExplorer VIIの#~右側16進エディタでRow値を02から01に変更します.
注意して、事は終わっていません.Rowsの後、つまり0 x 0000054から記憶され始めたのは様々な具体的なタイプの詳細情報のTablesで、Row値を修正しました.つまり、Tablesが連続的に読み取ったIndexとOffsetも変化することを意味します.そのため、後続のデータを4 byte前に移動し、除去された偽造Assemblyデータを上書きする必要があります.まず,偽造Assembly詳細のオフセット量を取得しなければならない.今回のオフセット計算は,異なる特定のタイプの情報の長さにかかわるため,ILDASMを用いて対応するデータを得た.ILDASMでターゲットファイルを開き、View->MetaInfoメニューからRaw:Header、Schema、Rows、Raw:Heapsの2つを選択します.その後、Ctrl+Mはメタデータ情報を表示します.
はい、いいです.04,80,000のマークがあります.この位置を見つければいいです.エディタで作業を続け、2番目のタグ位置(0 x 000003 AE)を見つけ、その後22(0 x 16)バイト(0 x 00003 AE~0 x 0000003 C 3)を数えます.これが上書きするデータです.0 x 0000003 C 4から始まるデータを選択し、Unicode方式でコピーし、Writeを0 x 00003 AEにします.コピー
書き込み
修正を保存します(ILDASMをオフにしてください.そうしないと保存できません).Reflectorを更新すると、エラーが修正されていることがわかります.(4)Multiple Module Definitionsという間違いは上と同じで,修復手段も同じである.
まずRows値を変更し、Moduleが第1項で、オフセット位置は0 x 0000000018で、それを01に変更すればよい(保存しないでください.そうしないとILDASMは開けません).
記録長が10(0 xa)である場合、2番目の記録のオフセット位置は0 x 0000054+0 xa=0 x 000005 Eである.10 bytes(0 x 00005 E~0 x 0000067)を数え、その後のデータを前の手法で前に移動して上書きする(ちなみにCFF Exploer VIIのエディタは使いにくいので、複数回コピーして上書きする必要があるかもしれませんが、前回上書きした終了位置を絶対に覚えて、エラーを避ける).変更を保存します.再びReflectorでプログラムセットをリフレッシュすると、元の姿が見え、修復作業が順調に完了したことを示します.------分割線----------最も簡単な修復手法はILDasm+ILAsmであるが,本稿の目的はメタデータに関する知識を復習することであるため,手作業で修復することで関連知識の理解を強化することができる.同時に、この文章は多くの高度に見える技術を示しており、その根本は基礎知識の掌握であり、もちろん忍耐と細心さが欠かせない.添付ファイルは修復前の元の暗号化ファイルで、この操作手順を練習することができます.Metadata構造定義については、ECMA C#and Common Language Infrastructure StandardsにMS PartitionIIをダウンロードできます.元の暗号化ファイルをダウンロードするにはクリックします(再暗号化され、上記のデモのデータとは異なります)
このエラーは、通常、Optional HeaderのNumberOfRvaAndSizesが修正されたものであり、実際の値は0 x 0000000(16)であるべきである.保存を変更し、Reflectorをリフレッシュして、次のエラーメッセージを続行します.(2) NumberOfStreams
これも比較的一般的な手段であり,誤ったMetaData Streamsをもたらすことによって干渉の目的を達成する.
偽のGUlDとBlopが1つ増えた.大丈夫です.後ろの正しいOffsetとSize値をパクリの位置にコピーし、Hex Editorで対応するOffsetの位置にジャンプして、この2つの偽物の名前を修正します.
もちろん、MetaData HeaderでNumberOfStreamsを0007から0005に変更することを忘れないでください.保存後、ターゲットファイルをCFExplorer VIIで再度開きます.MetaData Streamsを再参照すると、#Strings、#GUID、#US、および#Blobデータは正常に戻ります.(3)Multiple Assembly Definitionsが次のエラーメッセージを更新します.
めまい~~~これは変態すぎて、意外にも複数のプログラムセットが含まれています.これは明らかに#~Streamが動いた.
Tableで私たちはやはり多くの破壊分子を見た.どうしようかな?まずMetadataの構造知識を復習します.#~の上位24 bytesにはMetadata Header情報が格納されています.0 x 0000018(Offset 24)から格納されるのは、Rows情報、つまりTableで見た様々なタイプの統計値です.Rowsの長さは4*nです.
数えてみると、全部で15種類、つまり長さは60(0 x 3 c)、オフセット位置は0 x 0000018~0 x 0000053のはずです.Assemblyのインデックス番号は11(0から)で、オフセット位置は0 x 0000018+11*4=0 x 0000044です.CFExplorer VIIの#~右側16進エディタでRow値を02から01に変更します.
注意して、事は終わっていません.Rowsの後、つまり0 x 0000054から記憶され始めたのは様々な具体的なタイプの詳細情報のTablesで、Row値を修正しました.つまり、Tablesが連続的に読み取ったIndexとOffsetも変化することを意味します.そのため、後続のデータを4 byte前に移動し、除去された偽造Assemblyデータを上書きする必要があります.まず,偽造Assembly詳細のオフセット量を取得しなければならない.今回のオフセット計算は,異なる特定のタイプの情報の長さにかかわるため,ILDASMを用いて対応するデータを得た.ILDASMでターゲットファイルを開き、View->MetaInfoメニューからRaw:Header、Schema、Rows、Raw:Heapsの2つを選択します.その後、Ctrl+Mはメタデータ情報を表示します.
===========================================================
Metadata section: 0x424a5342, version: 1.1, extra: 0, version len: 12, version: v2.0.50727
flags: 0x00, streams: 5
Stream 0: name: #~, size 1040
Stream 1: name: #Strings, size 1448
Stream 2: name: #GUID, size 32
Stream 3: name: #US, size 216
Stream 4: name: #Blob, size 444
Metadata header: 2.0, heaps: 0x00, rid: 0x01, valid: 0x000003092000d557, sorted: 0x0000000000000000
Strings: 1448(0x5a8), Blobs: 444(0x1bc), Guids: 32(0x20), User strings: 216(0xd8)
=================================================
...
32(0x20): Assembly cRecs: 2(0x2), cbRec: 22(0x16), cbTable: 44(0x2c)
col 0: HashAlgId oCol: 0, cbCol:4, ULONG
col 1: MajorVersion oCol: 4, cbCol:2, USHORT
col 2: MinorVersion oCol: 6, cbCol:2, USHORT
col 3: BuildNumber oCol: 8, cbCol:2, USHORT
col 4: RevisionNumber oCol: a, cbCol:2, USHORT
col 5: Flags oCol: c, cbCol:4, ULONG
col 6: PublicKey oCol:10, cbCol:2, blob
col 7: Name oCol:12, cbCol:2, string
col 8: Locale oCol:14, cbCol:2, string
-------------------------------------------------
1 == 0:00008004, 1:0001, 2:0000, 3:0000, 4:0000, 5:00000000, 6:blob#0, 7:string#1, 8:string#0
2 == 0:00008004, 1:0001, 2:0000, 3:0000, 4:0000, 5:00000000, 6:blob#0, 7:string#6, 8:string#0
...はい、いいです.04,80,000のマークがあります.この位置を見つければいいです.エディタで作業を続け、2番目のタグ位置(0 x 000003 AE)を見つけ、その後22(0 x 16)バイト(0 x 00003 AE~0 x 0000003 C 3)を数えます.これが上書きするデータです.0 x 0000003 C 4から始まるデータを選択し、Unicode方式でコピーし、Writeを0 x 00003 AEにします.コピー
書き込み
修正を保存します(ILDASMをオフにしてください.そうしないと保存できません).Reflectorを更新すると、エラーが修正されていることがわかります.(4)Multiple Module Definitionsという間違いは上と同じで,修復手段も同じである.
まずRows値を変更し、Moduleが第1項で、オフセット位置は0 x 0000000018で、それを01に変更すればよい(保存しないでください.そうしないとILDASMは開けません).
...
0(0): Module cRecs: 2(0x2), cbRec: 10(0xa), cbTable: 20(0x14)
col 0: Generation oCol: 0, cbCol:2, USHORT
col 1: Name oCol: 2, cbCol:2, string
col 2: Mvid oCol: 4, cbCol:2, GUID
col 3: EncId oCol: 6, cbCol:2, GUID
col 4: EncBaseId oCol: 8, cbCol:2, GUID
-------------------------------------------------
1 == 0:0000, 1:string#2b, 2:guid#1, 3:guid#0, 4:guid#0
2 == 0:0000, 1:string#0, 2:guid#2, 3:guid#0, 4:guid#0
...記録長が10(0 xa)である場合、2番目の記録のオフセット位置は0 x 0000054+0 xa=0 x 000005 Eである.10 bytes(0 x 00005 E~0 x 0000067)を数え、その後のデータを前の手法で前に移動して上書きする(ちなみにCFF Exploer VIIのエディタは使いにくいので、複数回コピーして上書きする必要があるかもしれませんが、前回上書きした終了位置を絶対に覚えて、エラーを避ける).変更を保存します.再びReflectorでプログラムセットをリフレッシュすると、元の姿が見え、修復作業が順調に完了したことを示します.------分割線----------最も簡単な修復手法はILDasm+ILAsmであるが,本稿の目的はメタデータに関する知識を復習することであるため,手作業で修復することで関連知識の理解を強化することができる.同時に、この文章は多くの高度に見える技術を示しており、その根本は基礎知識の掌握であり、もちろん忍耐と細心さが欠かせない.添付ファイルは修復前の元の暗号化ファイルで、この操作手順を練習することができます.Metadata構造定義については、ECMA C#and Common Language Infrastructure StandardsにMS PartitionIIをダウンロードできます.元の暗号化ファイルをダウンロードするにはクリックします(再暗号化され、上記のデモのデータとは異なります)