🍎 💃🏻 🍞 自己修正コード ⏩ 🙎🏻 🚃

この記事では、自己修正コード（QMS）と、プログラムでの自己修正コードの使用方法について詳しく説明しています。例は、組み込みアセンブラを使用してC ++で記述されています。また、スタックでコードを実行する方法についても説明します。これは、QMSを作成および実行する際に不可欠な切り札です。

1.はじめに

さあ、行きましょう。この記事は長くなることを約束します。なぜなら、あなたが質問をしないようにそれを書きたいからです。 QMSトピックに関する記事はすでに100万件ありますが、ここで問題に関する私のビジョンを示します。QMSを何百時間も書いた後...ここですべての作業をプッシュしようとします。これですべて、トマトジュース（またはそこで飲みたいもの）を手に入れ、音楽を大きくして、アプリから初心者のクラッカーを取り除く方法を学ぶ準備ができました！その過程で、Windowsのメモリや、あなたが疑わないその他のことについてお話しします。

2.自己修正コードの簡単な歴史

最近では、プログラマーは、自己修正コードを好きな場所で使用することができました。 10〜20年前、プログラムを保護するための多かれ少なかれ深刻な試みはQMS（自己修正コード）を使用していました。いくつかのコンパイラでさえ、メモリ内のコードで動作するQMSを使用しました。

その後、90年代半ばに何かが起こりました。これはWindows 95 / NTと呼ばれるものです。突然、私たちプログラマーは、前にやったことすべてがでたらめであるということを理解するようになり、新しいプラットフォームを学ぶ必要がありました。以前に発明されたすべてのトリックは忘れられる可能性があります。メモリ、ハードウェア、およびオペレーティングシステムを必要とせずにプレイできなくなったためです。ほとんどの人は、VxDを使用しないとQMSを書くことはできないと考えていました。そのため、Windowsに一般的であるように、多かれ少なかれ有能なドキュメントはありませんでした。しばらくして、プログラムで引き続きQMSを使用する場合があることが判明しました。 1つの方法は、Kernel32ライブラリによってエクスポートされたWriteProcessMemory関数を使用することです。もう1つの方法は、コードをスタックに配置してから変更することです。

記事の残りの部分は、主にMicrosoft Visual C ++および32ビットサブシステムに当てられています。

3.そのままのWindowsメモリ

WindowsでのQMSの作成は、私たちが望むほど簡単ではありません。ここでは、Windowsの作成者によって注意深くレイアウトされたいくつかの落とし穴に遭遇します。なんで？はい、それはマイクロソフトだからです。

ご存じのとおり、Windowsは各プロセスに4ギガバイトの仮想メモリを割り当てます。このメモリに対処するために、Windowsは2つのセレクターを使用します。 1つはCSセグメントレジスタにロードされ、もう1つはDS、SS、およびESレジスタにスローされます。それらはすべて同じベースアドレス（0に等しい）を使用し、4ギガバイトのスペースに制限されています。

プログラムは、コードとデータの両方を含む1つのセグメントと、1つのプロセススタックのみを持つことができます。 MIDDLEプロシージャコールを使用するか、スタックにある制御コードに切り替えることができます。後者の場合、SSを使用してスタックにアクセスしないでください。 CSレジスタの値はDS、SS、およびESと一致しませんが、MOV dest、CS：[src]、MOV dest、DS：[src]、およびMOV dest、SS：[src]コマンドはすべて同じメモリロケーションにアクセスします。

データ、コード、およびスタックを含むメモリ領域（ページ）には、いくつかの属性があります。たとえば、コードページでは、読み取りと実行、データページ-読み取りと書き込み、スタック-読み取り、書き込みと実行を同時に行うことができます。

これらのページには、多くのセキュリティ属性もあります。それらについては、必要なときに少し後で説明します。

4. WriteProcessMemory-新しい親友

（私の意見では）プロセス内の数バイトを変更する最も簡単な方法は、WriteProcessMemory関数を使用することです（保護フラグが設定されていない場合）。

このために最初に行うことは、アクセス属性PROCESS_VM_OPERATIONおよびPROCESS_VM_WRITEを使用してOpenProcess関数を使用して、メモリにロードされたプロセスにアクセスすることです。以下は、簡単なQMSの例で、これについて説明します。 C ++では、このメカニズムを実装するには、言語の組み込み機能がいくつか必要です。もちろん、これはすべて他の言語でも実行できますが、これについては改めて説明します。さらに、他の言語では、これはすべてはるかに複雑に見えます。

リスト1. QMSサービスのWriteProcessMemory

int WriteMe(void *addr, int wb) { HANDLE h=OpenProcess(PROCESS_VM_OPERATION| PROCESS_VM_WRITE, true, GetCurrentProcessId()); return WriteProcessMemory(h, addr, &wb, 1, NULL); } int main(int argc, char* argv[]) { _asm { push 0x74 ; JMP >> JZ push offset Here call WriteMe add esp, 8 Here: JMP short Here } printf("Holy Sh^& OsIX, it worked! #JMP SHORT $2 was changed to JZ $2n"); return 0; }

ご覧のとおり、プログラムは無限ループを単純なJZ遷移に置き換えます。これにより、プログラムは次の指示に進むことができ、置換の事実を確認するメッセージが表示されます。すごいね私はあなたが今思うと思うに...うーん、面白いが、私はそのような何かをすることができますか？おそらくそうです！

ただし、このメソッド（WriteProcessMemoryを使用）には多くの脆弱性があります。まず、経験豊富なクラッカーがインポートテーブルを分析し、疑わしい機能を検出します。彼は、おそらく、この呼び出しにいくつかの休憩を入れ、近くのコードを分析し、必要なものを見つけます。 WriteProcessMemoryの使用が一般的なのは、メモリ内のコードを収集するコンパイラー、または実行可能ファイルのアンパッカーのみです。ただし、このトリックを使用すると、初心者のクラッカーを自由に切り詰めることができます。私は自分のプログラムでこのテクニックをよく使用しています。

もう1つのSax WriteProcessMemoryは、メモリに新しいページを作成できないことです。この機能のトリックは、既存のページでのみ機能します。したがって、この関数のアプリケーションを思い浮かべる方法はいくつかありますが、スタック上のコードの実行に注意を向けます。

5.スタックにコードを配置し、実行します！

スタックにコードを配置することは許容されるだけでなく、時には必要になることさえあります。特に、コンパイラーがその場でコードを生成できるようにすることで、コンパイラーの作業を楽にします。しかし、スタックとのそのような自由はシステムのセキュリティを危険にさらすでしょうか？もちろん、彼らはあなたのお尻にトラブルをもたらす可能性があります。さらに、これはプログラムに最適なテクノロジーではありません。スタック上でコードの実行を禁止するパッチをインストールすると、ほとんどの作成が麻痺するためです。一方、そのようなパッチはありますが、特にLinux、Solarisには非常に便利ですが、それをインストールするのは2人だけだと思います（著者自身、hee hee）。

上記のWriteProcessMemoryの脆弱性をまだ覚えていますか？スタックに実行可能コードを配置するトリックは、それらを削除するための2つの素晴らしいオプションを提供します。まず、コードを変更する命令はメモリの未知のセクションにあるため、クラッカーがそれらを追跡することはほとんど不可能です。保護されたコードを分析するには、彼は私たちのプログラムのツリーを彗星自体の下で切り取らなければならないので、おそらく彼の作品は大成功を収めることはありません！スタックでコードを実行することを支持するもう1つの議論は、プログラムはいつでも必要なだけメモリを割り当て、いつでも解放できるということです。デフォルトでは、オペレーティングシステムはスタックに1 MBのメモリを割り当てます。実行中のタスクがより多くのメモリを必要とする場合、プログラムは追加のクォータを要求する場合があります。

ただし、スタックにコードを配置する前に知っておく必要のあるニュアンスがいくつかあります。したがって、ここでそれらについて説明します。

6.ローミングコードが健康に悪い理由

Windows 9x、Windows NT、およびWindows 2kでは、スタックが異なる場所にスタックされることに注意してください。したがって、プログラムをクロスプラットフォームにするためには、相対アドレス指定を使用することが重要です。この要件を実現することはそれほど難しくありません。このためには、いくつかの簡単なルールに従うだけです。

80x86の世界では、すべての「ショートジャンプ」と「nir-kala」は相対的なものです。つまり、線形アドレスを使用する必要はありませんが、宛先アドレスと次のプログラム命令のアドレスの差を使用する必要があります。このような相対的なアドレス指定は私たちの生活を大幅に簡素化しますが、それにも限界があります。

たとえば、void OSIXDemo（）{printf（ "Hi from OSIXn"）;}関数がスタックにコピーされて呼び出された場合はどうなりますか？このような呼び出しは、printfアドレスが変更されているため、エラーになる可能性があります。

アセンブラでは、アドレス指定レジスタを使用して、この問題を簡単に修正できます。たとえば、LEA EAX、printfNCALL EAXなど、printf関数のローミング呼び出しを非常に簡単に実装できます。これで、相対ではなく絶対線形アドレスがEAXレジスタに配置されます。したがって、printf関数がどこから呼び出されたかは関係ありません。正しく機能します。

このようなトリックを再現するには、コンパイラがアセンブラー挿入をサポートしている必要があります。あなたが低レベルのプログラミングに興味がないなら、これはあなたにとって完全なサックスですが、高レベルの言語によって提供される兵器庫に自分自身を制限することでまったく同じことができるかもしれません。以下に簡単な例を示します。

リスト2.関数をスタックにコピーして実行する方法

 void Demo(int (*_printf) (const char *,...)) { _printf("Hello, OSIX!n"); return; } int main(int argc, char* argv[]) { char buff[1000]; int (*_printf) (const char *,...); int (*_main) (int, char **); void (*_Demo) (int (*) (const char *,...)); _printf=printf; int func_len = (unsigned int) _main  (unsigned int) _Demo; for (int a=0; a<func_len; a++) buff[a] = ((char *) _Demo)[a]; _Demo = (void (*) (int (*) (const char *,...))) &buff[0]; _Demo(_printf); return 0; }

したがって、高レベルの言語ではスタック上でコードを実行できないことを誰も耳につかないでください。

7.最適化を今すぐ開始します！

QMSを記述するか、スタックで実行されるコードを使用する場合、コンパイラーの選択に真剣に取り組み、その機能を研究する必要があります。最も可能性が高いのは、特にコンパイラが「最適化」モードに設定されている場合、プログラムからプログラムへの最初のアクセスでコードがエラーを折りたたむことです。

なぜこれが起こっているのですか？ CやPascalのような純粋に高レベルのプログラミング言語では、関数コードをスタックや他の場所にコピーするのは非常に難しいからです。プログラマには関数へのポインタを取得する機会がありますが、同時に、その使用を標準化するルールはありません。プログラマーの間では、これは「マジックナンバー」と呼ばれ、コンパイラーだけが知っています。

幸いなことに、ほとんどすべてのコンパイラはコードを生成するときに同じロジックを使用します。これらは、ある種の未記述のコードコンパイル規則です。したがって、プログラマーも使用できます。

リスト2をもう一度見てみましょう。Demo（）関数へのポインターはその開始と一致し、関数の本体はこの関数の開始直後にあると正しく仮定します。ほとんどのコンパイラは、この「常識的なコンパイル」に準拠していますが、すべてがこれに従うとは想定していません。まあ、少なくとも大物（VC ++、Borlandなど）はまだこのルールを順守しています。したがって、未知または新しいコンパイラーを使用していない場合、「常識的なコンパイル」の欠如を心配しないでください。 VC ++に関する1つの注意：デバッグモードで作業している場合、コンパイラはいくつかの「アダプター」を挿入し、関数を別の場所に配置します。くそーマイクロソフト。ただし、設定で「インクリメンタルにリンク」フラグが設定されていることを確認するだけで、コンパイラが適切なコードを生成するように強制します。コンパイラにそのようなオプションがない場合、QMSを使用できないか、別のコンパイラを使用できません！

別の問題は、関数の長さを決定することです。これには、シンプルで信頼できるトリックがあります。 C ++では、sizeofステートメントは、関数自体のサイズではなく、関数ポインターのサイズを返します。ただし、原則として、コンパイラはオブジェクトがソースコードに表示される順序に従って、オブジェクトにメモリを割り当てます。そのため、...関数のサイズは、関数へのポインターとそれに続く関数へのポインターの差です。とても簡単です！このトリックを覚えておいてください。最適化コンパイラはこれらの規則に従わないので、それはあなたにとって有用です。したがって、今説明した方法は機能しません。 QMSを書くと、コンパイラの最適化が健康に悪いのはなぜですか？！？！？

コンパイラを最適化するもう1つのことは、THINKが使用されない変数を削除することです。リスト2の例に戻ると、バッファーに何らかの値が書き込まれますが、そこからは何も読み取られません。ほとんどのコンパイラは、制御をバッファに転送するという事実を認識できないため、コードをバッファにコピーする命令を削除します。ろくでなし！これが、制御が初期化されていないバッファに転送されてから...ブームになる理由です。クラッシュ。このような問題が発生した場合は、「グローバル最適化」ボックスのチェックを外すとすべてが正常になります。

それでもプログラムが機能しない場合は、giveめないでください。考えられる理由は、各関数の最後にコンパイラーがスタックを制御するサブルーチン呼び出しを挿入することです。これがMicrosoft VC ++の機能です。デバッグされたプロジェクトに__chkesp関数呼び出しを追加します。この関数の説明をわざわざ探してはいけません。ドキュメントにはありません！この呼び出しは相対的であり、それを排除する方法はありません。ただし、最終プロジェクトでは、VC ++は関数を終了するときにスタックの状態をチェックするため、プログラムは時計のように機能します。

8.独自のプログラムでのQMS

ですから、ようやく、皆さんが待ち望んでいたことの時が来ました。記事で説明されているこの長い道のりをすべて訪れた場合、私はあなたを歓迎します。（雷の拍手）

さて、あなたは自分に「スタックでコード（関数）を実行することの利点は何ですか？」これに応じて、群衆は次のように言います：Ahhhhhhhhhhhhh。

暗号化されたコードは、逆アセンブルクラッカーのお尻に非常に大きな破片です。もちろん、デバッガーを使用して、彼は彼の人生を少し楽にしますが、それでも暗号化されたコードは彼/彼女の人生を信じられないほど難しくします。

たとえば、XOR操作をコードの各行に順次適用し、再利用時にソースコードを復元する最も単純な暗号化アルゴリズム！

次に、Demo（）関数の内容を読み取り、暗号化し、結果をファイルに書き込む例を示します。

リスト3. Demo関数を暗号化する方法

 void _bild() { FILE *f; char buff[1000]; void (*_Demo) (int (*) (const char *,...)); void (*_Bild) (); _Demo=Demo; _Bild=_bild; int func_len = (unsigned int) _Bild  (unsigned int) _Demo; f=fopen("Demo32.bin", "wb"); for (int a=0; a<func_len; a++) fputc(((int) buff[a]) ^ 0x77, f); fclose(f); }

暗号化の結果は文字列変数に配置されます。これで、関数Demo（）をソースコードから削除できます。後で必要になったら、復号化してローカルバッファにコピーし、実行のために呼び出すことができます。お尻を蹴りますか？

このアルゴリズムの実装例は次のとおりです。

リスト4.暗号化されたプログラム

 int main(int argc, char* argv[]) { char buff[1000]; int (*_printf) (const char *,...); void (*_Demo) (int (*) (const char *,...)); char code[]="x22xFCx9BxF4x9Bx67xB1x32x87 x3FxB1x32x86x12xB1x32x85x1BxB1 x32x84x1BxB1x32x83x18xB1x32x82 x5BxB1x32x81x57xB1x32x80x20xB1 x32x8Fx18xB1x32x8Ex05xB1x32x8D x1BxB1x32x8Cx13xB1x32x8Bx56xB1 x32x8Ax7DxB1x32x89x77xFAx32x87 x27x88x22x7FxF4xB3x73xFCx92x2A xB4"; _printf=printf; int code_size=strlen(&code[0]); strcpy(&buff[0], &code[0]); for (int a=0; a<code_size; a++) buff[a] = buff[a] ^ 0x77; _Demo = (void (*) (int (*) (const char *,...))) &buff[0]; _Demo(_printf); return 0; }

printf（）関数が挨拶を表示することに注意してください。一目見ただけで何も変わったことはありませんが、「Hello、OSIX！」という行が見えるはずです。彼女はコードセグメントに場所がありません（ボーランドは何らかの理由でそこに行を配置しますが）、データセグメントをチェックすることで、その場所にあることがわかります。

さて、たとえクラッカーが彼の前にソースコードを持っているとしても、彼のために私たちのプログラムはまだ地獄のパズルの1つのままです。この方法を使用して、「秘密の」情報（プログラムのシリアル番号とキーなど）を隠します。

この方法を使用してシリアル番号を確認する場合は、解読する場合でもクラッカーのパズルが保持されるように検証を整理する必要があります。次のリストでこれを行う方法を示します。

QMSを実装するときは、変更するバイトの正確な場所を知る必要があることに注意してください。したがって、高水準言語の代わりに、アセンブラーを使用する必要があります。さあ、私と一緒にいて、もう終わりだ！

上記のメソッドの実装でアセンブラを使用する場合、1つの問題があります。 MOV命令を使用してバイトを変更するには、パラメーターとしてABSOLUTE線形アドレス（おそらく、コンパイル前は不明だったと思われます）を渡す必要があります。しかし...プログラムの実行中にこの情報を取得できます。 CALL $ + 5 / POP REG / MOV [reg + relative_address]、xx-私に非常に人気のあるコード。次のように機能します。 CALL命令を実行した結果、アドレス（またはこの命令の絶対アドレス）はスタックに残ります。このアドレスは、スタック機能コードのアドレスのベースアドレスとして使用されます。

そして、これは私があなたに約束したシリアル番号の検証の例です...

リスト5.シリアル番号の生成とスタックの実行

 MyFunc: push esi ;   ESI   mov esi, [esp+8] ; ESI = &username[0] push ebx ;      push ecx push edx xor eax, eax ;    xor edx, edx RepeatString: ;     Lodsb ;     AL test al, al ;   ? jz short Exit ;  ,   1     ;   ,     ,   ; ()    ,   XOR mov ecx, 21h RepeatChar: xor edx, eax ;   XOR  ADC ror eax, 3 rol edx, 5 call $+5 ; EBX = EIP pop ebx ; / xor byte ptr [ebx0Dh], 26h; ;     ;  XOR  ADC. loop RepeatChar jmp short RepeatString Exit: xchg eax, edx ;   (.)  EAX pop edx ;   pop ecx pop ebx pop esi retn ;

このコードは、奇妙なように見えます。同じ引数を繰り返し渡すと、同じ結果またはまったく異なる結果が得られるためです。ユーザー名の長さに依存します。奇数の場合、関数を終了するときのXORはADCに置き換えられます。それ以外の場合は、何も起こりません！

さて、これですべてです。この記事が少なくともあなたにとって有益なものであったことを願っています。彼女の版画は私に2時間かかりました！フィードバックはいつでも歓迎します。

英語ソース： Giovanni Tropeano。 自己修正コード// CodeBreakers Journal。 巻 1、いいえ 2006年2月。

自己修正コード