手Q这个应用从成果来说异常的复杂，假如行使相同MFFA的框架去发掘文件理会类裂痕，服从低，并且文件进口在哪儿、怎样操作剧本举办自动化都长短常大的题目。本文在一次手Q的文件理会类裂痕发掘的进程中，提出了一种也许的办理题目的方案，妄称指南不惜见教。

?

目次：

1、题目说明

2、流程图

3、so筛选

4、测试措施编写

5、test case天生

6、测试得出crash

7、将来的事变

?

?

0x01 ?题目说明

今朝面对的题目是，不知道手Q的文件进口在哪儿（指代码层面），并且依据手Q的用户说明，手Q很有也许基础不提供代码进口，没有代码进口就没有自动化，靠着UI触发举办测试那是脑筋秀逗了。以是主要办理的题目得本身提供文件进口了，今朝看来得本身抠出so，本身写测试措施，本身载入测试用例，本身网络crash了，挖裂痕真是一条孤傲的路。

0x02 ?流程图

起主要先说明手Q的lib文件，找出待测的so，然后编写可以或许挪用该so的测试措施，将测试用例放进去举办自动化测试，最后网络native crash，人工说明之后拿到裂痕。流程很是简朴，将大题目拆分成以下几个题目，别离降服之后就能大成总方针了：

l??拿什么so？这个so用来做什么的？什么时辰会被挪用？

l??测试措施怎么在没有源码的环境下挪用so？

l??测试用例用什么天生？?

0x03 ?so筛选

筛选的方案着实大抵有两类：揣摩某个so是做什么的，然后动态调试验证；先动态调试挪用某个成果之后看手Q挪用了哪个so。两个方案行使的技能都差不多，首要都是操作动态调试最后确定so。

起主要先拿到so，把apk看成zip解压就行，内里有个lib库，拿到就好。然后我凭证要害字去筛选这些so，好比我有个预先的方针，想测的文件名目有如下：GIF、WAV、JPG、PNG等等，以是我找到了这个文件libGIFEngine.so，看起来就像一个理会GIF的so，插手备选。

验证方案：怎样验证呢？动态调试手Q，断点下在挪用so的相干函数，假如在发送GIF时，可以或许间断，就声名该so选对了。至于怎样成立一套动态调试手Q情形，则不是本篇包围的内容了。

在调试的进程中，我发明白有个函数叫NativeOpenFile的函数，绝不踌躇下断点，公然在发送GIF之后，措施间断在这里。本阶段事变完成。选出so：libGIFEngine.so?

0x04??测试措施的编写

起首轻微提一下JNI挪用类型，so都要切合JNI挪用类型才气被挪用，至于该类型细节是什么不消领略，只用领略一点：怎样挪用so的函数？

全部可以或许直接被Java层代码挪用的so函数，函数名都有牢靠名目，以下是libEngine.so的七个能被挪用的函数：

同时，在Java层代码中也要这么声明这些Native函数才气够被挪用。可是这里有个题目，测试措施要满意这个定名路径，即下图所示。以是必要把本身的测试措施的包名写成com.tencent.image，把测试的类名写成nativegifimage即可。

Java_com_tencent_image_nativegifimage.函数名

?之前要声明挪用的so，用System.loadLibrary可能System.load挪用某个so就可以了。挪用进程不再赘述，然后就可以开始编写测试函数了。

鉴于我走过的坑，这里我要插几句话：Android Studio1.5之后有了个新成果，可以在build.gradle中指定jniLibs路径，记得把测试类和主Activity分隔。

开始测试之前，必要沉着一下思索这里要做什么：要测试这七个函数，挪用GIF文件发生Native Crash，那么代表测试的历程会挂掉，怎样可以或许让测试措施自动的继承举办下去？这是写测试措施必要思量的题目。

基于此，我给出了测试措施的模子，仅供参考。

因为测试Task较量切合Service的特征，以是最后选了Service注册一个新历程举办测试。然后在主Activity历程中新建一个线程监控Service的运行状态，一旦检测到没有运行，自动重启Service，且记录下crash的文件名，好举办记录、复现、存储等等。以是我对Test Case举办编号，然后Service每测试通过一个就发送广播包，而间断之后重启Service时，发送个Intent同步一下测试进度即可。

然后凭证上述逻辑编写措施就行。这里尚有个题目，就是手Q界说了本身的非常，以是我们的测试措施中也必要响应的非常界说，因为非常处理赏罚的来源就是发送一个Error Code，以是只要能找得手Q中Error Code的界说即可。留意将手Q中各类常量转成响应的Error Code如下图所示。

原本的Error Code界说。

修改之后的Error Code界说。

然后措施或许就能跑起来了，虽然这中间还要颠末对各个Native函数的挪用参数、挪用逻辑的理会等等，就逐步看代码吧，假若有自动化代码说明器材的话，这里的进程也可以自动化。?

?

0x05? Test Case天生

着实File Fuzz中，天生测试用例是焦点的一环。我在事变中选取了Peach3作为天生Test Case的器材。Peach3作为Smart Fuzz的器材，可以依据文件模版天生测试用例，可是必要人工编写PIT文件驱动Peach运行，而编写PIT文件又是一个很是贫困的事变，以是我不在本文中论述这些了，我在近期会更新响应的Peach3的PIT文件编写教程，敬请等候。

关于Peach的变异计策，我回收了有序+随机计策，这样可以担保每次天生Test Case中测试序号同等的文件变异内容保持同等。有利于重放、网络Test Case，也有利于后期在漫衍式体系上大局限的测试。

0x06 ?测试得出crash

我在测试的进程中或许测试了40w阁下的Test Case，发明白一些crash，可是因为敌手Q挪用Native层函数的逻辑不足清楚，以是部门crash不能在手Q上直打仗发。可是也有一些crash可以直打仗发，而是否有操作空间留待后续的人工说明。

?0x07??将来的事变

方针：自动化、局限化

作为一个措施猿，把事变和糊口尽也许的自动化作为空想是很天然的工作，裂痕发掘进程中有以下几处没有自动化的：

l??筛选so

l??理脱手Q挪用逻辑

l??编写测试措施

个中筛选so必要依赖履历和人工说明才气获得，编写测试措施则可以通过代码重用进步服从，而手Q关于方针Native函数的挪用逻辑则可以通过器材举办说明得出，这方面可以再优化一下。未来可以或许自动化说明Native函数的挪用逻辑，乃至按照挪用逻辑得出一条手Q的执行路径，帮助编写测试措施就长短常舒畅的工作了。

其它File Fuzz也是Fuzz的一种，必要大量的运行时刻才行，以是漫衍式举办测试团结腾讯云举办负载平衡的测试和存储是一条很是有效的路。

趁便先容下腾讯的SO加固掩护方案：是指通过加壳、夹杂、VM等技能，掩护Native层代码，防备被逆向、改动、二次打包等举动。腾讯御安详平台有相干先容和试用体验。

?

（腾讯御安详团队）

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!