幽灵般的无栈Crash修复记

　　作者：rayhunterli，腾讯IEG游戏客户端开发工程师
　　导语本文主要对一例无栈Crash，在内网不能重现，外网没有内存dump和墓碑文件情况下；怎么通过残留寄存器值，深入结合C汇编层面函数调用原理，根据蛛丝马迹，定位解决问题。本文应同事邀请，经审批公开，但部分图片与内容为了信息安全，会进行打码和信息脱敏，只保留技术讨论，可能有些生硬，望谅解！一：问题信息与初步分析1。1后台上报与简要分析
　　新版本上线后，进行Crash总结时，发现CrashSight后台有不少无栈上报。JAVA层栈可以忽略，Native层栈只有一行，前面文章也提过崩溃的信息栈很少，通常来说越难查。
　　简要分析：只有一行栈，且PC值是一个奇怪的值，不属于某个模块。text代码段范围；但应该是程序执行时，执行到错误的地址了；该问题栈是无法回溯，连那个模块引发的都无法确认，这个才让难度几何级增大。
　　补充：Crash基本知识可以参考我以前写的一篇总结文章：《C中Crash定位原理与常见案例反汇编分析》
　　针对无栈问题，前不久我已经解决过一例安全模块引发的，相对简单很多，但属内网链接就不再公开。
　　少量同学对C函数再汇编层面调用过程理解有疑问，可参考《人人都能学的会C协程原理剖析与自我实现》，里面有函数调用过程讨论1。2常规行动与分析1。观察栈信息：只有一条栈，大量查看上报的PC寄存器值，发现基本没有什么规律性，有的很大，有的看真起来还接近。text段合理值，我随意截些图，如下图所示。总之来说，乱七八糟，各种各样，没有得出什么规律。
　　可能有人看到上报错误信号不同，但BUSADRALN与SEGVMAPERR都是访问到非法内存，只是内存没有对齐，可能就报BUSADRALN，否则SEGVMAPERR；由于出错值目前看有点随机，当然对不齐比能对齐的多，所以本例BUSADRALN多。2。观察日志：CrashSight后台上报通常都带有crash发生时部分logcat日志，往常复杂的案例，通过阅读大量案例的日志，总能找到蛛丝马迹。这次我也不知道读了多少条，并没有得到特别有效的结论，除了发现大都在战斗中时出问题，别的并没有收获。3。观察其它线程栈：
　　以前的经验，有时看看其它线程调用栈，可能也发现蛛丝马迹，但这个问题，也是失败告终。4。观察硬件及状态维度信息：比如出问题机器型号，众多，和型号无关；32位还64位也没用；游戏出问题时间，有几分钟的，有几十分钟的，也有一两小时无果，说明不是启动；观察状态：比如前后台，是加载阶段，退出阶段等，有时这个信息也挺有用，结合状态日志，确定了是战斗内，只有开始标识，没有结束标识。
　　总结：经过上面的行动处理，发现都失败，接下来有几个行动可选：1。读源码：
　　首先无栈问题，不能确定是那个模块引发的。在我们项目主要是xxxxxxA。so，xxxxxxB。so，xxxxxxC。so三大模块（名称隐藏），再加上很多其他小模块及第三方模块。这次是大版本更新，改动非常多，去看代码基本不太可能。最核心的是就算看了，你也不一定能发现，这种基本排除。2。大量测试：
　　本问题如果复现了，有墓碑文件，跳过第一层栈，手动解析，基本可以秒杀。不过本案例量也不算少，也不是严重的不行，内部与少量同学沟通，进行测试，没有复现问题；这个问题没有那么容易复现，同时感觉还不到全力投入人力进行大批量测试。3。底层深入分析：
　　本问题比较乱，出现问题点比较多，只要案例多，肯定能把规律性提取出来。我相信再搞一搞，结合汇编函数调用规律，全面分析，就可能成功，实在不行，再说。4。启用CrashSight实验功能：CrashSight也提功类似内存dump功能，但我们版本只有1Mb内存上传，100条线程左右估计要3Mb。基本会截断，需要他们手动解析二进制片段，还不一定有这个栈内存，非常麻烦。再加上这个功能只有一个项目用，可能有其它影响，和CrashSight同学讨论，这个做我方案3不成功的备选。
　　我先选择3，假如失败后，计划进行2，4。二：在寄存器与汇编指令中寻找蛛丝马迹
　　在一所有失败后，仅有最有效的信息，就剩32个寄存器，我们要从这仅有的信息中，尝试揪出本问题，还是比较难。
　　2。1探寻FP，LR，PC三个关键寄存器
　　对于我们这种情况，最核心关联的三个寄存器就是FP，LR，PC，我们项目主要模块，进行C编译时，没有通过fomitframepointer参数强制禁用FP；（禁用时回溯栈麻烦，需要用dwarf结合EFL的。ehframe段存放CFI信息）；通过大量阅读这些寄存器，稍微并整理了一下，大致分为下面5类类型1：lr，pc相同，看起来不正常，但FP看起来也不正常r290x051f0076a392d140r300x058e045c05220520pc0x058e045c05220520具体CrashSight链接：xxxxxxxx（公开版隐藏）类型2：lr，pc相同，看起来不正常，但FP看起来接近合理值r290x0000007ad6ef07e0r3007x048304504722a88pc0x0483047504722a88具体CrashSight链接：xxxxxxxx（公开版隐藏）类型3：lr，pc相同，看起来接近合理值，但FP看起来不正常r290x0485048404838210r300x0000006c04880487pc0x0000006c04880487具体CrashSight链接：xxxxxxxx（公开版隐藏）类型4：lr，pc相同，看起来接近合理值，但FP看起来也接近合理值r290x00000078f61faaa0r300x0000007804da04d2pc0x0000007804da04d2具体CrashSight链接：xxxxxxxx（公开版隐藏）类型5：lr，pc不相同，且三个都不正常r290x045d007823bf5170r300x045b0459045c051fpc0x005b0459045c051f具体CrashSight链接：xxxxxxxx（公开版隐藏）
　　结论：各种情况都有，没有发现特别意义，真的吗？？？也不是完全没有意义，且看下一小节2。2深入ARM分析跳转指令得出重要推论1
　　由常识可明确本例发生在指跳转指令。
　　别看这么多跳转指令，由2。1的信息，我们很快就能锁定。1。条件跳转指令排除：
　　不看条件，他们实质是offset跳转，跳转的实际为固定值，BranchToPCoffset，他们不可能跳转到变态大的PC值，且LR值通常不会变（先强写一下LR除外），基本排除了。2。B指令排除：
　　由于我们现在用4字节指令，留给B指令，只有26bit的偏移，不可能跳转到变态大的PC值；且这里出错时，PC相对地址不变，排除；加上LR不变，更加排除。3。BL指令排除：
　　同上，光变态大PC的数据排除，LR实际为跳转时PC4；这点也能排除4。BLR指令排除：
　　这个可以满足PC变态大，但必然有有通用寄存器Xn保存PC值，通过大量观察上报寄存器，找不到Xn，排除5。BR指令排除：
　　这个有时也用在函数结束，由LR提前从栈弹出，可以满足PC变态大，但必然有有通用寄存器Xn保存PC值，通过大量观察上报寄存器，找不到Xn，排除6。就你了：ret指令：
　　一般用在函数结束时，从栈内存中先弹出高位寄存器（X19X30，根据函数需要，编译实际保存不同），如果栈内存被改写，那么LR，FP都可能是错误的值，这样就能造成符合我们要求的无栈crash。
　　ARM平台的ret指令和x86x64平台，还是有点区别的，这点需要注意下。
　　总结：到现在，我们已经明确是在函数结束时，由于栈越界改写破坏了LR，或FP，或两者，ret指令跳转失败；这有用吗？？？有用，但只有一点点。因为到现在我们连那个所属那个模块都不知道，好像又陷入僵局。2。3再看FP与SP寄存器离真相更近一步
　　有了2。2小结的结论，函数返回，ret指令失败，有2。1小节我们问题是多种多样的，我们还可以观察FP与SP。
　　假设A函数调用B函数，B函数结束，ret指令失败，这时B函数的栈已经平衡了，这时我们可以推出一个重要结论：
　　SP：寄存器实际为A函数的栈顶，且不会被破坏
　　FP：寄存器如果没有被越界改写的情况下，就是A的函数的栈底
　　两者相减，就是函数A的栈大小，而一个函数的栈大小是固定的
　　于是我就挑了一些FP看似处于正常值的案例和SP相减，就得到下面的结果：r290x0000006f29ca5d40r300x0483047504727a88sp0x0000006f29ca5b00240H576r290x051f0076a392d140r300x058e045c05220520sp0x00000076a392d110pc0x058e045c05220520pstate0x000000008000000030H48不少r290x0485048404831170r300x0000007d04880487sp0x0000007e11601140pc0x0000007d04880487pstate0x000000002000000030H48侵入r290x051f007838a0dab0r300x058e045d045c04bcsp0x0000007838a0da80pc0x058e045d045c04bcpstate0x000000008000000030H48侵入r290x0000007ad6ef07e0r300x0483047504722a88sp0x0000007ad6ef05a0pc0x0483047504722a88pstate0x0000000060000000240H576r290x0000007e9816de60r300x048304750472ca88sp0x0000007e9816dc20pc0x048304750472ca88pstate0x0000000060000000240H576r290x000000756acd27d0r300x048304750472ca88sp0x000000756acd2590pc0x048304750472ca88pstate0x0000000060001000240H576
　　函数A栈大小，基本上固定为240H和30H两种（其中部分30H，感觉最高16位，好像被写入奇怪的值，后面48位，看起来是合理的栈内存地址；我这里抛出最高16位相减），说明可能至少两个函数出现这种情况。用IDA搜一个主要的模块，其实栈内存为240H并不太多，30H就一大堆。
　　总结：出问题的调用者函数栈内存大小为240H，也就是576个字节，或者48字节两种；这时结合其他寄存器观察，已经感觉到越界可能2字节一组（这点还不能完全实锤）；但好像还是没用，我们还是不知道那个模块，怎么破？？？2。4不要放弃，再深入观察寄存器结果呼之欲出
　　为什么不要放弃呢？因为我们这次无栈出现的寄存器杂乱，各式各样，各种组合，像幽灵一样，特征似乎不那么明显，反过来这也是好处，说明可以遍历多种出问题的情况。如果是越界，很大可能可能是一个跳跃性越界，而不是连续越界。就是这样，加上特征不明显，只要我看的多，就可能找到漏网之鱼。
　　我重点观察高位寄存器，对于异常值不断观察，再结合汇编知识，我们可以得到下面结论或推论。1。越界起始不是必然值：
　　如果从栈变量写越界栈寄存器，连续写的话，对于一个函数来说，当写到栈内存保留的寄存器时，必然是特定的，但本例不是。2。越界值似乎有点意思：
　　大量观察，发现特征也是2字节一组，且范围基本就是0x04xx，0x05xx较多。3。寄存存越界分析：
　　C编译器对FP开启模式，通常将FP，LR保存栈顶，如果有其它高位寄存器要保存，必然存在下面可能。a：越界先写坏其它高位寄存器，还没写坏后面的FP，LR。这种情况，能栈回溯，但访问高位寄存器可能引发crash，那么版本必然存在常规crash！！！b：越界写坏LR寄存器。这种情况发生时，就是我们要查的无栈Crashc：越界写坏不是本层函数栈，更高层次的函数栈，那么可能导致更高层函数崩溃。4。我们最想要的漏网之鱼：
　　由了上述3条结论后，我们可以寻找漏网之鱼，就是只有最高16位写坏的那种。反正本次够幽灵，规律性难概括，只要坚持看，肯定能找到，果不其然。很快找到，像这样越界从FP寄存器最高16bit，后面48bit是有效的r290x051f0076a392d140r300x058e045c05220520
　　我们只要继续再找，如果越界是LR最高16bit开始，那么我们就将秒杀这个bug
　　很快找到，像这样越界从LR寄存器最高16bit，后面48bit是有效的r290x00000073313ca1d0r300x0457007302d9a190sp0x00000073313ca1a010pc0x0057007302d9a190pstate0x0000000080001000查看模块地址：72fe7ad00073058aa000rxp00000000103：131902513libxxxxxxxA。so可以推出结论：从45ED190地址出问题，分析相应汇编，即将秒杀！！！7302d9a19072fe7ad00045ED190
　　再找到类似的r280x000000742d7fc698r290x00000074505bd810r300x045700742ab04bb8sp0x00000074505bd5d0pc0x005700742ab04bb8pstate0x0000000080000000也还是libxxxxxxxA。so模块，可以推出结论：从45EEBB8地址出问题，分析相应汇编，即将秒杀！！0x0742ab04bb80x742651600045EEBB8
　　总结：到现在我们充分利用对汇编的理解，结合大量的寄存器的观测，不停的寻找，才得到本文最重要的推论3，4，也找到两处函数调用地址；到这基本上这个问题就秒杀了，我们只需从CrashSight后台找相关常规崩溃去验证，我们的推论成立与否就可以了。搜索蛛丝马迹到此就结束了，下面转到常规分析。三：一步一步验证推论
　　虽然知道2。4小节的结论，可能秒杀这个问题。这有点利用假设站上帝视角，还存在假设，也为了在讲述角度更好示范解常规crash，先不直接用推论，进行更加常规点分析（我自己已先看那两个推论地址与反查出的函数名，CrashSight后台果然是有对应上报的，且相同业务上报位居高位）。先看本版本新增最多相同函数名的业务有栈崩溃，这个崩溃函数段就覆盖其中45EEBB8地址，虽地址有一偏差，但感觉是同一个问题。虽然用推论可能更快，但还是先解决已明确的问题把。不过最开始统计时相关同学告诉我已经修复了，最初我没有去管。3。1业务模块有栈新常规问题分析
　　示意图已经被我严重打码了，就是普通业务代码，一层一层的调用关系，虽看不到函数名，但这不影响技术本身。
　　首先看了一下相关同学的修改，好像C代码并没有特别大的可能崩溃风险，那么可能修改没用，于是我打开IDA进行0x00000000045eec7c附近反汇编。
　　0x00000000045eec7c此处汇编比较简单（已打码屏掉相关业务名称），x8应该是定值，不可能出错，只有X26寄存器可能出错，打开寄存器
　　从图上可以看出X8刚好是0x21150，符合条件；X26为0x0537053605350534，一看就是诡异不对的值；且从x24到x28都是0x05xx，这不是前面我们2。4小节的一个推论，这是巧合吗？
　　我再向上看看IDA：本函数X26在崩溃点前面有访问，且本函数汇编直接改动X26可能点比较少，我都排除了，说明前面是正常访问的；略加观察又发现三条推论符合2。4小节中：手动剔除某些案例LR寄存器最高16bit，得到0x0742ab04bb80x742651600045EEBB8，这个45EEBB8地址就是在本函数中，这两个基本就是一个问题2。2小节中：我们得出一个重要结论，无栈崩溃就是函数返回ret指令修改，结合本例有栈崩溃前面能正常访问X26，且自己不会直接修改，后面不能访问，也只能是函数调用返回发生，巧合吧，这点在下面会细说2。3小节中：函数栈内存为240H或30H，本函数栈内存大小就是240H，巧合吧
　　总之多么巧合啊，嘿嘿！
　　话又说回来，这个有栈的问题，只看C业务代码，很难修的。我们继续分析那里改坏寄存器的。3。2缩小汇编范围，加速分析分析汇编范围
　　如上文所述，动用我们2。4推论得到il2cpp的地址，可以直接定位出问题函数（lr地址需要4），再验证跳转函数真正内容就可以了，这样有点变态。我们看怎么常规修复这个x26问题，展开更多汇编。
　　如上图所示，在红框标注的X26之间出了问题，这里面有很多行汇编指令。
　　先说一下：本函数C源码有250行，转成C源码有976行，由C生成的汇编有1738行指令，看起来会很痛苦，我们要多结合C源码与BL这种跳转指令及调用关系链，不要全部反汇编，浪费时间，也没必要。
　　就算这样，我们卡了两个X26之间汇编，确定它们是顺序调用的，但里面涉及函数还是太多，且存在函数嵌套调用其他函数，用人工一个一个排除太费劲，另外还有形如虚函数，BLRXn调用，这种我们是不知道函数名称的，对应C源码是这样的，是无法读出来的，都需要我们结合C及C代码一点点推断。
　　缩小汇编范围
　　由前面信息，我敢肯定，肯定有更早一点的崩溃，毕竟我们的是幽灵模式，各种情况都有，只要我们广泛搜CrashSight后台就可以了。
　　在CrashSight后台，通过对栈关键字搜索（函数名称），以及对最最近上报的观察，处理一下，我得到下面的信息XXXXXXXXXXXXXXXXXXXXXXXXXXXXXA实际为本函数函数名称，为了信息安全，我这里代替示意pc00000000045eec7cXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA具体CrashSight链接：xxxxxxxx（公开版隐藏）pc00000000045eecdcXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA具体CrashSight链接：xxxxxxxx（公开版隐藏）pc00000000045eec84XXXXXXXXXXXXXXXXXXXXXXXXXXXXXA具体CrashSight链接：xxxxxxxx（公开版隐藏）pc00000000045eebb8XXXXXXXXXXXXXXXXXXXXXXXXXXXXXA具体CrashSight链接：xxxxxxxx（公开版隐藏）pc00000000045eecf4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXA具体CrashSight链接：xxxxxxxx（公开版隐藏）lr00000000045eecfcXXXXXXXXXXXXXXXXXXXXXXXXXXXXXA具体CrashSight链接：xxxxxxxx（公开版隐藏）
　　针对每个崩溃点，我都去IDA看一眼，就是不同对应越界不同的寄存器，越界值刚好是一个不可访问的，不再截图示意。找PC最小的，直接将范围缩小到了00000000045eebb8，这是非常重要的结论，直接命中我们2。4小节漏网之鱼推论：0x0742ab04bb80x742651600045EEBB8，即将秒杀，哈哈。
　　对于最后一个lr00000000045eecfc，多说一句，如果blrXn，这个寄存器Xn刚好是0，CrashSight的回溯是这样，只显示下一条的LR值。
　　打开IDA，跳转过去，
　　再看看寄存器值，X9是0x1F90，X8是0，符合猜测
　　在看的过程中，我还发现其他规律：XXXXXXXXXXXXXXXXXXXXXXXXXXXXXB实际为另一个函数函数名称，为了信息安全，我这里也是代替示意XXXXXXXXXXXXXXXXXXXXXXXXXXXXXC，XXXXXXXXXXXXXXXXXXXXXXXXXXXXXD，XXXXXXXXXXXXXXXXXXXXXXXXXXXXXE等都是不同的函数名称pc00000000045ed190XXXXXXXXXXXXXXXXXXXXXXXXXXXXXB具体CrashSight链接：xxxxxxxx（公开版隐藏）pc000000000085b41cXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE实际为上面的变种，比XXXXXXXXXXXXXXXXXXXXXXXXXXXXXB多了一层栈，其具体栈如下1pc000000000085b41cXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE〔arm64v8a〕2pc00000000045ed1a8XXXXXXXXXXXXXXXXXXXXXXXXXXXXXB〔arm64v8a〕3libil2cpp。sopc000000000463c1a0XXXXXXXXXXXXXXXXXXXXXXXXXXXXXC具体CrashSight链接：xxxxxxxx（公开版隐藏）pc000000000463c1b4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXC比XXXXXXXXXXXXXXXXXXXXXXXXXXXXXB少一层栈具体CrashSight链接：xxxxxxxx（公开版隐藏）pc000000000463c1a4XXXXXXXXXXXXXXXXXXXXXXXXXXXXXC比XXXXXXXXXXXXXXXXXXXXXXXXXXXXXB少一层栈具体CrashSight链接：xxxxxxxx（公开版隐藏）pc0000000004ed9a20XXXXXXXXXXXXXXXXXXXXXXXXXXXXXD比XXXXXXXXXXXXXXXXXXXXXXXXXXXXXB少二层栈具体CrashSight链接：xxxxxxxx（公开版隐藏）
　　用IDA看一下XXXXXXXXXXXXXXXXXXXXXXXXXXXXXB这个函数，崩溃点也和XXXXXXXXXXXXXXXXXXXXXXXXXXXXXA没有实质区别，都是高位寄存器坏了，只是这个函数短很多，访问高位寄存器地方少，所以排名不是那么高而已。我们又有下面推论：2。4小节中：手动剔除最高16bit，得到7302d9a19072fe7ad00045ED190，这个45ED190地址就是在XXXXXXXXXXXXXXXXXXXXXXXXXXXXXB中，这不巧了！！！同上面XXXXXXXXXXXXXXXXXXXXXXXXXXXXXA函数，这些都是对应高寄存器非法，又是函数返回ret指令修改，无栈崩溃也是，这不巧了2。3小节中：函数栈内存为240H或30H，本函数栈内存大小就是30H，两个都得到验证，哈哈2。4小节中：越界写坏不是本层函数，更高层次的函数栈，那么可能导致更高层函数崩溃，这不巧了，刚好符合，还引申一个下层栈也可能因收到错误信息而崩溃
　　总结：本小节基本上把我们的汇编级推论验证完了，如果我们用汇编级去秒杀，可以更快。到这里本案例基本上80的内容被搞定了，也说明验证了至少发现了两个A，B函数。接下来从汇编角度来进一步分析，他们都是虚函数，我们只需分析出这个虚函数到底是谁即可。3。3揪出真凶，分析幽灵一样的原因
　　从45EEBB8看，实际这是LR值，需退一条汇编指令，就是红框，虚函数调用。
　　结合汇编上下文，C源码上下文，C源码，很容易推出X9就是XXXXXXXXXXXXXXXXM函数地址，在IDA我已经标注；再汇编跳转过去
　　看到汇编开头我就笑了，基本就是他了，居然把高位寄存器保存了一遍，还有0x70字节大小栈对象，为可以越界埋下伏笔，这里汇编不用看了（当然我自己为了实锤，还是会看），只需要看高级语言就行了。
　　我们直接看C代码，由于业务比较长，也存在多处可能越界点情况，我略去很多没用的代码，作一段伪码：protectedoverridevoidXXXXXXXXXXXXXXXXM（boolbIn）｛AAAAAInfonewAAAA（）；AInfo。Count0；for（inti0；iTestCi）｛unsafe｛AInfo。Data〔AInfo。Count〕OriginData〔i〕；｝｝｝
　　C代码虽然是new，但结构体AAAA对象AInfo是栈对象，并非在堆区，这里在C生成的C代码及汇编都可以确认，我就不在贴更低层次的代码。它是unsafe的，看了一下改动，由于逻辑改动，确实导致可能数组不足，存在越界。但这里看起来像是连续的写入，越界为什么那么幽灵呢？？？
　　回答这个问题之前，还要看AAAA结构〔StructLayout（LayoutKind。Explicit，Pack8，Size82）〕unsafepublicstructAAAA｛〔FieldOffset（0）〕publicfixedushortData〔40〕；〔FieldOffset（80）〕publicbyteC｝
　　OH，OH，OH！！！明白了
　　原来AInfo。Count是在数组AInfo。Data后面哇，栈越界先覆写AInfo。Count自己；然后for循环再次推动越界时，由于是AInfo。Count是byte型，是否再次越界取决于写入的值。数组大小为40，如果写入的AInfo。Count为30，就不越界，反而覆盖了原来的值；如果为42，就越界，开始破坏x28，以此类推；如果为100，就可能破坏更加上层的函数栈。加上逻辑层本身for循环次数TestCount由业务决定，也是不定的，AInfo。Count写入值更是不定，多层不定折腾下，是否越界就变得很玄学。越界了从哪里开始越也很玄，越多少字节也很玄。只有明确越界覆写是ushort，也就是16位。
　　到此所有问题得解，一切结束。四：总结与反思
　　我们现在站在事后诸葛亮角度去分析：C这种函数栈越界很好处理，编译器开启函数栈保护，只需牺牲一点性能，就可以搞定，是否平时尝试开启一下？项目是否能接入更高级的内存诊断工具，GoogleASan，anitation，fuzzing！能否开启CrashSight的简易内存dump墓碑文件能够推进Crash修复需要近乎完全确认才能声明修复了，否则可能误导
　　本文较长，可能技术点有错误或者不全面，欢迎指出与讨论。如果大家有更好方法，一起交流讨论。相比Google平台，感谢CrashSight平台提供寄存器，模块地址，日志等信息供追查。