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号