PEパッカーの開発

今日は、Windows用の独自のC ++実行可能パッカーの開発についてお話します。



むかしむかし、Windows XPがまだ存在していなかったとき、パッカーに関する情報を求めて、当時の若いUPXソースのジャングルに登りました。 しかし、脳内のアセチルコリンは必要以上に合成されなかったか、UPXはすでに非常に退屈でした-一般的に、これらのタイプからはほとんど何も抽出しませんでした。 マット・ピトレック、そして彼はもっと助けた。 情報が追加されたことで、はるかに簡単になりました。 ほとんどすべてがあります。 かなり普通の銀行のトロイでもダウンロードできます（ Zeus 2.0.8.9 ）。 はい、本当にそこにあるのは、Windowsの並べ替えが長い間公開されていることです（ Windows 2000 ）。
パッカーに関する情報もありますが、主に研究であり、私たちが望んでいる側面ではない開発に直接関連しています。 これの優れた例は、悪名高い教祖VolodyaとNEOxによって書かれた2つのパートの記事「前回のパッカーについて」です。
次に、ニーズに合わせて、最もシンプルでありながら簡単に変更可能なPEパッカーの開発に関する最も具体的で一貫した情報を提供しようとします。

アルゴリズム

たとえば、notepad.exeがあります。 通常の32ビット形式では、重量は約60 Kbです。 すべての機能を維持しながら、大幅に削減したいと考えています。 私たちの行動はどうあるべきですか？ まず、最初のファイルから最後のバイトまで配列にファイルを読み込みます。 今、私たちは彼と何でもできます。 そして、私たちはそれを絞りたいです。 それを取得して簡単なコンプレッサーに渡します。その結果、配列は60 Kbではなく、たとえば20 Kbになります。 これはクールですが、圧縮形式では、メモ帳のイメージは高いエントロピーを持つ単なるバイトのセットであり、実行可能ファイルではなく、ファイルに書き込んでクリックしても起動できません。 圧縮されたイメージを持つアレイの場合、メディア（ブートローダー）、非常に小さな実行可能ファイルが必要です。これにアレイを接続し、アレイを開いて実行します。 メディアを作成してコンパイルし、圧縮されたメモ帳の最後に追加します。 したがって、すべてのアクションの結果として取得されたファイル（サイズが単純に圧縮されたメモ帳のサイズよりもわずかに大きい）が起動されると、パッケージ化されたイメージ自体が検出され、アンパックされ、その構造が解析されて実行されます。
ご覧のとおり、あまり複雑ではないプロセスを自動化する必要があります。 ローダーと、実際にはパッカーという2つのプログラムを作成するだけです。
パッカー作業アルゴリズム：

• PEファイルを配列に読み込みます。
• ロスレス圧縮アルゴリズムを使用して配列を圧縮します。
• PE形式に従って、圧縮された配列をローダーテンプレートに追加します。

ブートローダーアルゴリズム：

• 圧縮されたPEファイルが最後にある配列を見つけます。
• それを広げる;
• PEファイルのヘッダーを解析し、すべての権限を設定し、メモリを割り当てて、最終的に実行します。

その後、パッカーによって操作されるため、ローダーから開発を開始します。

ブートローダー

したがって、ローダーが最初に行うべきことは、PEファイルの圧縮イメージを含む配列のアドレスを本体で見つけることです。 検索方法は、パッカーがこの配列をローダーにどのように移植したかによって異なります。
たとえば、データを含む新しいセクションを単に追加した場合、検索は次のようになります。

最後のセクションで圧縮画像を検索する

//    PE-    HMODULE hModule = GetModuleHandle(NULL); PIMAGE_DOS_HEADER pDosHeader = (PIMAGE_DOS_HEADER)hModule; PIMAGE_NT_HEADERS pNTHeaders = MakePtr(PIMAGE_NT_HEADERS,hModule,pDosHeader->e_lfanew); PIMAGE_SECTION_HEADER pSections = IMAGE_FIRST_SECTION(pNTHeaders); // ,      PIMAGE_SECTION_HEADER pLastSection = &pSections[pNTHeaders->FileHeader.NumberOfSections - 1]; // ,   LPBYTE pbPackedImage = MakePtr(LPBYTE, hModule, pLastSection->VirtualAddress); //   DWORD dwPackedImageSize = pLastSection->SizeOfRawData; 

しかし、私たちの意見では、ブートローダーのこのコードは犠牲になる可能性があります。 一般的に、パッカーができることはすべて、彼と彼だけができるようにします。 ブートローダーのアドレス空間内のイメージアドレスは、パッケージング中に事前に計算し、適切な場所に入力するだけです。 これを行うには、プログラムに2つのマークを残します。

 LPBYTE pbPackedImage = (LPBYTE) 0xDEADBEEF; DWORD dwPackedImageSize = 0xBEEFCACE; 

パッカーは、圧縮されたイメージを含む配列をローダーに埋め込むと、ローダーの本体で署名検索を実行し、0xDEADBEEFを配列のアドレスに、0xBEEFCACEをそのサイズに置き換えます。

アドレスの検索方法を決定したので、圧縮ツールの既製の実装を選択して、パッカーで使用できます。
適切なオプションはaplibを使用することです 。これは、Lempel-Zivアルゴリズム（LZ）に基づく圧縮を実装する、きれいで非常にコンパクトなコードを備えた小さなライブラリです。 そして、私たちは間違いなく他の日にそれを選択しますが、今日はさらにシンプルでコンパクトなソリューション、つまりWindowsに組み込まれた機能を求めています！

XPから、お気に入りのntdll.dllが2つの優れた機能のエクスポートを開始しました。

 NTSTATUS RtlCompressBuffer( __in USHORT CompressionFormatAndEngine, __in PUCHAR UncompressedBuffer, __in ULONG UncompressedBufferSize, __out PUCHAR CompressedBuffer, __in ULONG CompressedBufferSize, __in ULONG UncompressedChunkSize, __out PULONG FinalCompressedSize, __in PVOID WorkSpace ); NTSTATUS RtlDecompressBuffer( __in USHORT CompressionFormat, __out PUCHAR UncompressedBuffer, __in ULONG UncompressedBufferSize, __in PUCHAR CompressedBuffer, __in ULONG CompressedBufferSize, __out PULONG FinalUncompressedSize ); 

それらの名前は、圧縮のための機能と解凍のための機能の1つです。 もちろん、非常に真剣な製品を開発している場合、Windows 2000およびNT 4.0を搭載したコンピューターがまだ存在するため、これらの機能には触れませんでした;）
Platform SDKヘッダーにはこれらの関数がないため、静的にリンクできないため、GetProcAddressを使用する必要があります。

解凍する関数のアドレスを決定する

 //   RtlDecompressBuffer      DWORD (__stdcall *RtlDecompressBuffer)(ULONG,PVOID,ULONG,PVOID,ULONG,PULONG); //    RtlDecompressBuffer  ntdll.dll (FARPROC&)RtlDecompressBuffer = GetProcAddress(LoadLibrary("ntdll.dll"), "RtlDecompressBuffer" ); 

開梱するものがあり、開梱するものがある場合、最終的にすでにそれを行うことができます。 これを行うには、メモリを余裕を持って割り当て（解凍したファイルのボリュームがわからないため）、上記で定義した関数を実行します。

 DWORD dwImageSize = 0; DWORD dwImageTempSize = dwPackedImageSize * 15; //      LPVOID pbImage = VirtualAlloc( NULL, dwImageTempSize, MEM_COMMIT, PAGE_READWRITE ); //  RtlDecompressBuffer(COMPRESSION_FORMAT_LZNT1, pbImage, dwImageTempSize, pbPackedImage, dwPackedImageSize, &dwImageSize); 

COMPRESSION_FORMAT_LZNT1パラメーターは、従来のLZ圧縮を使用することを意味します。 この関数は他のアルゴリズムで圧縮できますが、これで十分です。
これで、メモリ（pbImage）にPEファイルの生のイメージができました。 開始するには、ネイティブのWindows PEローダーが通常行う一連の操作を実行する必要があります。 リストを最も必要なものに減らします。

1. オプションのヘッダー（OPTIONAL_HEADER）のImage Baseフィールドで指定されたアドレスに、画像の先頭（ヘッダー）を配置します。
2. PEファイルのセクションをセクションテーブルに示されているアドレスに配置します。
3. インポートテーブルを解析し、関数のすべてのアドレスを見つけて、対応するセルに入力します。

当然、標準のPEローダーは他のすべてのアクションを実行し、それらを制限することにより、一部のPEファイルとのパッカーの互換性を制限します。 しかし、大多数の場合、これらのアクションで十分です-再ロック、fixap、およびその他のまれで厄介なゴミを修正することはできません。
突然、深刻な互換性が必要な場合は、クールなPEローダーを自分で作成するか、Webで最も完全な実装を見つけてください。 ;）切り捨てられた形式でも、PEローダーの機能は100行以下であるため、ここではプロトタイプのみを示します（完全なコードはディスク上にあります）。

 HMODULE LoadExecutable (LPBYTE image, DWORD* AddressOfEntryPoint) 

展開されたイメージへのポインタを取得し、ロードされたモジュールのハンドル（PEファイルがロードされたアドレスに相当）とエントリポイントのアドレス（AddressOfEntryPointポインタによる）を返します。 この関数は、画像をメモリに正しく配置するためにすべてを行いますが、すべてではなく、最終的に制御をそこに移すことができます。
事実は、システムはまだ私たちによってロードされたモジュールについて何も知らないということです。 圧縮プログラムの実行を開始するエントリポイントを今すぐ呼び出すと、多くの問題が発生する可能性があります。 プログラムは動作しますが、曲がっています。
たとえば、GetModuleHandle（NULL）は、展開されたプログラムではなく、ローダーモジュールのイメージベースを返します。 FindResource関数とLoadResource関数は、リソースがまったくないブートローダーを調べます。 より具体的なグリッチが存在する場合があります。 これをすべて防止するには、プロセスのシステム構造のあらゆる場所で情報を更新し、ローダーモジュールのアドレスをロードされたモジュールのアドレスに置き換える必要があります。
まず、古いイメージベースを示すPEB（Process Enviroment Block）を修正する必要があります。 PEBアドレスは非常に簡単に取得でき、ユーザーモードでは常にFSセグメントのオフセット0x30にあります。

 PPEB Peb; __asm { push eax mov eax, FS:[0x30]; mov Peb, eax pop eax } // hModule —      PE- Peb->ImageBaseAddress = hModule; 

また、PEBによって参照されるLDR_DATA構造内のモジュールのリストを修正しても害はありません。 合計3つのリストがあります。

• InLoadOrderModuleList-ブート順のモジュールのリスト。
• InMemoryOrderModuleList-メモリの場所の順番のモジュールのリスト。
• InInitializationOrderModuleList-初期化順のモジュールのリスト。

各リストでブートローダーのアドレスを見つけて、ロードされたモジュールのアドレスに置き換える必要があります。 このようなもの：

 //    ,   //       PLDR_DATA_TABLE_ENTRY pLdrEntry = (PLDR_DATA_TABLE_ENTRY)(Peb->Ldr->ModuleListLoadOrder.Flink); pLdrEntry->DllBase = hModule; ... 

これで、ロードされたモジュールのエントリポイントを安全に呼び出すことができます。 最も普通の方法で呼び出されたかのように機能します。

 LPVOID entry = (LPVOID)( (DWORD)hModule + AddressOfEntryPoint ); __asm call entry; 

AddressOfEntryPointは、エントリポイントの相対仮想アドレス（RVA、相対仮想アドレス）であり、LoadExecutable関数のオプションヘッダーから取得されます。 絶対アドレスを取得するには、ベースアドレス（つまり、新しくロードされたモジュール）をRVAに追加するだけです。

ダウンローダーのサイズ

VS 2010でデフォルトフラグを使用してブートローダーをコンパイルおよびビルドすると、2キロバイトのプログラムキャリアではなく、10 Kbを超えるモンスターが取得されます。 スタジオは不要なものを大量に構築するため、そこからすべてを引き出す必要があります。
したがって、ローダープロジェクトのコンパイラプロパティ（C / C ++タブ）では、次のことを行います。

• 「最適化」セクションで、「最小サイズ（/ O1）」を選択して、コンパイラーがすべての機能をよりコンパクトにするようにします。
• また、速度よりもサイズの優先順位を示します（フラグ/ Os）。
• 「コードの作成」セクションでは、C ++例外をオフにし、それらを使用しません。
• また、バッファオーバーフロー（/ GS-）をチェックする必要もありません。 これは良いことですが、私たちの場合はそうではありません。

リンカー（リンカー）のプロパティ：

• マニフェストから地獄を変える。 それは大きく、そのため、ブートローダに.rsrcセクションが作成されますが、これは絶対に必要ありません。 一般に、PEファイルのすべての追加セクションは、アライメントのおかげで、少なくとも512の完全に不要なバイトです。
• デバッグ情報の作成をオフにします。
• [詳細設定]タブに移動します。 「ベースアドレスへのランダム性の導入」（/ DYNAMICBASE：NO）をオフにします。そうしないと、リンカーは再配置セクション（.reloc）を作成します。
• ベースアドレスを指定します。 0x02000000など、非標準の上位を選択してみましょう。 GetModuleHandle（NULL）がブートローダーに返すのはこの値です。 ハードコーディングすることもできます。
• CRT-shnuyu：/ ENTRY：WinMainではなく、エントリポイントを指定します。 一般に、コードから直接プラグマディレクティブを使用してこれを行うことに慣れていますが、プロパティに到達したので、ここでできます。

リンカーの残りの設定は、コードから直接設定されます。

 #pragma comment(linker,"/MERGE:.rdata=.text") 

ここでは、読み取り専用データ（行、インポートテーブルなど）を含む.rdataセクションと.textコードセクションを組み合わせました。 グローバル変数を使用した場合、.dataセクションをコードと組み合わせる必要もあります。

 #pragma comment(linker,"/MERGE:.data=.text") //    .data    , //        #pragma comment(linker,"/SECTION:.text,EWR") 

上記はすべて、1.5 Kbローダーを取得するのに十分です。

パッカー

与えられたファイルを圧縮し、ローダーにアタッチするコンソールユーティリティを開発することは残ります。 記事の冒頭で説明したアルゴリズムに従って最初に行うべきことは、ファイルを配列に読み込むことです。 学生が対処するタスク：

 HANDLE hFile = CreateFile(argv[1], GENERIC_READ,FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); DWORD dwImageSize = GetFileSize(hFile, 0); LPBYTE lpImage = new BYTE[dwImageSize], lpCompressedImage = new BYTE[dwImageSize]; DWORD dwReaded; ReadFile(hFile, lpImage, dwImageSize, &dwReaded, 0); CloseHandle(hFile); 

次に、パッカーは結果のファイルを圧縮する必要があります。 これがPEファイルかどうか、ヘッダーが正しいかどうかなどはチェックしません。すべてをユーザーの良心に任せ、すぐに圧縮します。 これを行うには、RtlCompressBuffer関数とRtlGetCompressionWorkSpaceSize関数を使用します。 最初に説明した最初のもの-バッファを圧縮し、2番目は圧縮エンジンの動作に必要なメモリ量を計算するために必要です。 （ブートローダーのように）両方の機能を既に動的に接続していると仮定し、それらを実行するだけです：

 DWORD format = COMPRESSION_FORMAT_LZNT1|COMPRESSION_ENGINE_STANDARD; DWORD dwCompressedSize, dwBufferWsSize, dwFragmentWsSize; RtlGetCompressionWorkSpaceSize(format, &dwBufferWsSize, &dwFragmentWsSize); LPBYTE workspace = new BYTE [dwBufferWsSize]; RtlCompressBuffer(format , //     lpImage, //    dwImageSize, //   lpCompressedImage, //    dwImageSize, //   4096, //  ,   &dwCompressedSize, //       workspace); //    

その結果、圧縮されたバッファーとそのサイズがあり、ブートローダーに固定できます。 これを行うには、まず、ローダーのコンパイル済みコードをパッカーにビルドする必要があります。 これをプログラムに入れる最も便利な方法は、 bin2hユーティリティを使用することです。 任意のバイナリを便利なヘッダーに変換し、その中のすべてのデータは次のようになります。

 unsigned int loader_size=1536; unsigned char loader[] = { 0x4d,0x5a,0x00,0x00,0x01,0x00,0x00, ... 

bin2hによるヘッダー作成を自動化できます

私たちは彼女にローダーでファイルを送り、さらなる倒錯に必要なものすべてを手に入れます。 ここで、記事の冒頭で説明したアルゴリズムに従う場合は、ブートローダーに圧縮イメージを添付する必要があります。 ここでは、90年代と私たちのvirmakerの過去を思い出さなければなりません;）。 事実、サードパーティのPEファイルにデータまたはコードを埋め込むことは、純粋にバイラルなトピックです。 実装はさまざまな方法で構成されていますが、最も単純で一般的な方法は、最後のセクションを拡張するか、独自のセクションを追加することです。 私たちの意見では、追加はアライメント中に損失を伴うため、ローダーに圧縮イメージを埋め込むために、最後のセクション（ローダー）を拡張します。 むしろ、唯一のセクション-余分なものはすべて取り除きました。 ;）
アクションのアルゴリズムは次のとおりです。

• ブートローダーに唯一のセクション（.text）があります。
• その物理サイズ、つまりディスク上のサイズ（SizeOfRawData）を変更します。 これは、古いサイズと圧縮イメージのサイズの合計に等しく、同時にファイルの配置（FileAlignment）に従って配置する必要があります。
• 仮想メモリサイズ（Misc.VirtualSize）を変更し、それに圧縮イメージのサイズを追加します。
• 古代の式[最後のセクションの仮想サイズ] + [最後のセクションの仮想アドレス]に従って、値をFileAlignmentに揃えることを忘れずに、ブートローダーイメージ全体（OptionalHeader.SizeOfImage）のサイズを変更します。
• 圧縮された画像をセクションの最後にコピーします。

ちょっとしたトリックがあります。 実際のところ、スタジオは、コード（.text）を含むセクションの仮想サイズ（Misc.VirtualSize）を、コードの実際の非整列サイズに等しくします。つまり、物理サイズよりも小さいことを示します。 そのため、最大511バイトを節約できる可能性があります。
つまり、整列ゼロの束の後にデータを書き込み、チップを知っていれば、これらのゼロを上書きできます。
これが、コードでのすべての思考の見え方です。

コードセクション拡張

 //          PBYTE pbLoaderCopy = new BYTE[simple_packer_size + dwCompressedSize + 0x1000]; memcpy(pbLoaderCopy, (LPBYTE)&simple_packer, simple_packer_size); //    PIMAGE_DOS_HEADER dos = (PIMAGE_DOS_HEADER)pbLoaderCopy; PIMAGE_NT_HEADERS nt = MakePtr(PIMAGE_NT_HEADERS, pbLoaderCopy, dos->e_lfanew); //   PIMAGE_SECTION_HEADER text = IMAGE_FIRST_SECTION(nt); //         memcpy(&pbLoaderCopy[text->PointerToRawData + text->Misc.VirtualSize], lpCompressedImage, dwCompressedSize); //   ,    Misc.VirtualSize text->SizeOfRawData = ALIGN(text->Misc.VirtualSize + dwCompressedSize, nt->OptionalHeader.FileAlignment); //   (    )  text->Misc.VirtualSize += dwCompressedSize; //    nt->OptionalHeader.SizeOfImage = ALIGN(test->Misc.VirtualSize + test->VirtualAddress, nt->OptionalHeader.FileAlignment); //     DWORD dwNewFileSize = pSections->SizeOfRawData + test->PointerToRawData; 

ああ、ブートローダーに残っている0xDEADBEEFおよび0xBEEFCACEラベルを実際の値に置き換えるのを忘れていました！ 0xBEEFCACEは圧縮イメージのサイズに変更され、0xDEADBEEFは絶対アドレスに変更されます。 イメージアドレスは、[イメージアドレス] + [セクションの仮想アドレス] + [セクションの先頭からのイメージオフセット]の式で計算されます。 Misc.VirtualSizeの値を更新する前に置換を行う必要があることに注意してください。そうしないと、結果のファイルが機能しません。
非常に単純なループを使用してタグを検索および置換します。

 for (int i = 0; i < simple_packer_size; i++) if (*(DWORD*)(&pbLoaderCopy[i]) == 0xBEEFCACE) *(DWORD*)(&pbLoaderCopy[i]) = dwCompressedSize; else if (*(DWORD*)(&pbLoaderCopy[i]) == 0xDEADBEEF) *(DWORD*)(&pbLoaderCopy[i]) = nt->OptionalHeader.ImageBase + text->VirtualAddress + text->Misc.VirtualSize; 

実際、それがすべてです。 これで、メモリにパッケージ化された作業準備ファイルができました。CreateFile/ WriteFile関数を使用してディスクに保存するだけです。

OllyDbgの太字ファイルをデバッグするプロセス

結論

notepad.exeの例で、UPXとパッカーの圧縮効率を比較すると、UPXの48 128に対して46 592バイトで約1 Kbを獲得します。 しかし、私たちのパッカーは完璧にはほど遠いです。 そして、これは非常に顕著です。
実際のところ、リソースの転送などの重要なことを意図的に無視しました。 結果の圧縮ファイルはアイコンを失います！ 不足している機能を自分で実装する必要があります。 この資料から得られた知識のおかげで、あなたはこの問題に関して何の困難もありません。

記事のソース 。

packerはUPXよりnotepad.exeを圧縮しました！

---

暗号に変換

実際、私たちのパッケージは暗号とはかなり異なります：暗号化とアンチエミュレーション技術の欠如。 すぐにできる最も簡単なことは、ブートローダーで解凍した直後にイメージ全体を追加することです。 しかし、アンチウイルスエミュレーターが窒息するには、これだけでは不十分です。 タスクを何らかの形で複雑にする必要があります。 たとえば、ブートローダー本体にxorキーを登録しないでください。 つまり、ブートローダーはコードを解読するために必要なキーを認識せず、私たちが定義したフレームワークでそれを反復処理します。 アンチウイルスとは異なり、これには時間がかかる場合があります。
また、キーをエミュレートされていない機能または構造に依存させることもできます。 彼らだけを見つける必要があります。
ブートローダーコードが署名によって焼き付けられないように、高度なウイルスエンジンをパッカーに固定して、Webに大量にあるため、ガベージやあらゆる種類のコード変更を生成できます。

---

ブートローダーでLoadExecutable関数を実行した後、アンパック用に割り当てられたメモリを解放するとよいでしょう。これはもはや役に立ちません。

---

ハッカーマガジン、 2月（02）157
ピーターとオオカミ 。

ハッカーを購読する

• 1 999 p。 12枚の用紙オプション用
• 1249 RUR iOS / iPadの年間サブスクリプション（Androidリリースは近日公開予定！）
• Androidのハッカー