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号