CreateProcessA参数型Shellcode的编码问题研究
宣布时间 2021-12-22简朴来讲 ，该控制系统的误差由两个程序组成：焦点程序CoreProcess和辅助程序HelpProcess ，焦点程序CoreProcess通过系统函数CreateProcessA来启动HelpProcess（同时转达了相关参数）。其中 ，CoreProcess的简化代码如下：
显然 ，HelpProcess的WinMain函数保存一个经典的栈溢出误差。当lpCmdLine的数据长度凌驾400字节时 ，对buff的strcpy操作就会爆发溢出；当长度凌驾404字节时 ，就会笼罩到eipCallerNext ，从而挟制HelpProcess的程序控制流。
回溯代码可知 ，lpCmdLine的数据泉源是CoreProcess的CreateProcessA挪用 ，且是用户可控的。因此 ，该误差的使用看起来是简朴的 ，只需要盘算好eipCallerNext的偏移量并使用shellcode填充buff即可。该误差的使用链和客栈结构如下所示：
在使用历程中 ，接纳测试填充字符举行溢出时 ，eipCallerNext的笼罩总是准确的；但接纳metasploit的shellcode来溢出时 ，eipCallerNext的笼罩就变得不准确。对数据举行较量后发明 ，shellcode在CoreProcess和HelpProcess是纷歧样的 ，即shellcode转达到HelpProcess后爆发了改变。别的 ，通过实验metasploit的差别shellcode ，发明这种改变没有显着的纪律可循。
针对这个问题 ，ADLab的清静研究员举行了深入的剖析 ，弄清了CreateProcessA参数转达的shellcode的编码问题 ，并开发了自动化处置惩罚要领 ，从而兼容恣意shellcode。
CreateProcessA的参数处置惩罚
Windows操作系统的内核是支持全球种种语言的 ，其提供统一的Unicode编码型内核态API；针对详细的国家或地区 ，Windows通过区域编码来实现外地语言支持 ，即Ansi字符串型的用户态API。这些用户态API在内部先把Ansi字符串转换为Unicode字符串 ，然后再挪用内核态API；这个转换历程是透明的 ，用户编写的程序对此无感知。
在Window操作系统上 ，1个Unicode字符由2个字节组成 ，1个Ansi字符由1个字节或2个字节组成。当首字节的值是0到127时 ，它是1个ASCII字符 ，对应Unicode字符的2字节的内容就是该ASCII字符加1个填充字符0；例如 ，Ansi字符”A” ，其对应的Unicode字符是”A\x00”。当首字节的值大于127时 ，则目今字节和下个字节组合起来是一个区域语言的字符 ，区域语言字符保存对应的Unicode字符映射表；例如 ，”\xce\xd2”的“\xce”不是1个正当的ASCII字符 ，它只能和“\xd2”联相助为1其中文字符“我” ，对应的Unicode字符是”\x11\x62”。
如下所示 ，CreateProcessA就是一个Ansi编码型的用户态API ，字符串”AAAA”会被自动转换为Unicode字符串并转达给HelpProcess ，然后在挪用WinMain之前又被自动还原为Ansi字符串。因此 ，关于Ansi字符串”AAAA” ，CoreProcess和HelpProcess在程序开发上都无需做任何特另外处置惩罚。
通常情形下 ，CreateProcessA参数lpCmdline的泉源是可靠的 ，好比编译时预界说的字符串和API的返回值 ，此时lpCmdline都是准确的Ansi字符串。因此 ，CreateProcess险些总能在Unicode和Ansi之间自由地准确转换。
现实上 ，关于任何一门区域语言 ，其Ansi字符和Unicode字符的映射都不是逐一映射关系；即在2字节的所有取值空间中 ，Ansi字符表的有用项数总是小于Unicode字符表的有用项数。这意味着 ，针对无法确认是区域语言的2个字节 ，若是强制视作Ansi字符则转换成Unicode字符后纷歧定能还原为初始的Ansi字符。例如：”\xeb\x2a”是一条通例的jmp offset指令 ，它不是1个正当的中文字符；若是视作Ansi字符强制转换为Unicode字符则是”\x3f\x00” ，再次转换为Ansi字符即是”?” ，丧失了jmp offset指令的语义。
因此 ，通过CreateProcessA的cmdline参数举行shellcode转达 ，必需要思量区域语言的Ansi字符和Unicode字符相互转换的问题。
在本文的误差使用案例中 ，外地区域的语言是中文简体 ，对应Ansi编码表是GBK。因此 ，必需要对metasploit的shellcode举行GBK编码 ，确保其是准确的Ansi字符串。
GBK表的编码在2字节取值空间的规模是8140－FEFE ，即第1字节的取值规模是0x81到0xFE ，第2字节的取值是0x40到0xFE ，如下所示：
别的 ，第2字节的现实有用取值尚有更多约束。好比 ，第2字节不可为0X7F。针对某些取值的字节 ，第2字节的取值比[0x40, 0xFE]的空间更小。如下图所示 ，有的只能取该空间的后半部分 ，有的则只能取前半部分。
关于shellcode来讲 ，其每个字节的取值在0到255之间都是完全正当的。因此 ，本文的误差使用要实现shellcode的随意替换 ，必需要有一种要领来对shellcode中违反GBK编码的字节举行处置惩罚 ，从而阻止Ansi字符和Unicode字符间转换导致的shellcode字符被改变的问题。一个基本的要领是凭证如下的流程对shellcode举行处置惩罚 ，其要害是对GBK表举行查表并修正汇编指令。
以如下的shellcode为例 ，在扫描到字节0xEB时 ，发明是非ASCII字符且查表GBK效果是不保存 ，需要举行转换；盘问GBK表后发明 ，在0xEB之前插入0x90可以使得90 EB是一个正当的GBK字符 ，同时90EB 38又不改变原来的汇编语义 ，转换乐成。同理 ，继续扫描到下一个字节0XEB时 ，再做同样的转换就可以。可是 ，第2次的转换插入了新的字节0x90 ，导致了原始lab1对应的偏移量爆发了改变；原始lab的指令现实位于转后的lab+1位置 ，使得第一个0XEB的语义不法了。因此 ，转换历程还要求跟踪指令区块的长度转变。
除了指令区块的长度改变外 ，尚有其它兼容性问题。好比 ，shellcode中特殊取值（典范有0）的字节处置惩罚问题 ，对shellcode的内嵌参数修改问题等。因此 ，只管查表转换是最基础的步伐 ，但全表盘问的空间大 ，限制了shellcode的无邪性。为相识决该问题 ，ADLab的清静研究员提出了一种基于盘算的shellcode编码要领。
Shellcode盘算转换
首先 ，我们把shellcode分为两部分：头部的牢靠decoder和尾部的多变payload。然后 ，接纳查表方法举行手工编写切合GBK编码的汇编代码。其中 ，decoder的长度很有限 ，决议了这个编写的价钱不大；同时 ，多变payload是没有特殊限制的 ，通过编写对应的encoder来编码payload使其不违反GBK编码 ，又可以被decoder还原。通过这种方法 ，对原始shellcode的选择和改变就完全不必体贴GBK编码问题 ，使得该误差的使用越发富厚。
为了镌汰decoder的体积 ，我们设计了一种盘算要领来编码息争码 ，这样就不需要存储GBK字符表或者重大的规则。原始shellcode编码时的盘算规则如下：
遇到字节是ASCII、0x80和0xff ，直接保存。
遇到字节是\x00 ，转换成加法运算符\x90和2个盘算数符\x80和\x80。
遇到字节是\x90 ，转换成加法运算符\x90和2个盘算数符\x48和\x48。
遇到2个字节可以转换为unicode字符 ，直接保存这2个字节。
遇到前面都不可处置惩罚的字节 ，直接转换成加法运算符\x90和2个盘算数符 ，第1个是\x80 ，第2个是差值。
接纳上述的编码要领后 ，任何shellcode都可以被转换为正当GBK字符串 ，并且decoder对payload的解码盘算也十分简朴 ，只需要如下的1条规则：
遇到字符是\x90 ，直接对后2个字符举行加法盘算 ，并用效果替换字符\x90。
至此 ，CreateProcessA参数转达的shellcode的编码问题就所有被约束在了只有一条规则的decoder代码中 ，很显然这是一个界线十明确确的局部问题 ，因此很容易就解决了。接纳这种要领 ，本文的误差使用可以随意挪用metasploit中的shellcode ，无需再担心它们的指令内部细节。
在多语言情形下 ，shellcode若是不是直接的内存转达 ，则可能会被系统API函数所转换 ，从而导致其因在获得执行权之前爆发内容改变而无效。因此 ，在误差使用历程中 ，需要注重shellcode是否受到多语言版本的API影响。
京公网安备11010802024551号