玩命的销售日志 2017.7.31

devilogic 日志

上周在睡眠14个小时后，发了一篇22号的日志，喷了一堆东西，想到好久没写文章了就顺手发到看雪,结果晚上看雪论坛首页就被保定XX上门（小妹）xxx给攻陷了。也不知道是不是我方。
既然要把自己培养成一名合格的销售，总要懂点销售技巧，从亚马逊买了几本书。也不知道灵不灵。

拜拜上面的几本书，保佑我读完销售功力大增。

每次在见客户之前，其实我都在心里默念态度第一，服务第一，千万不要怼客户，三年多前骂客户的事情绝对不能再发生。
其实发生那种事情并不是我想要的结果，具体原因是一个银行客户，在和我们对接之后，一个新的加固包出现兼容性问题，当时我们的兼容性在大概$90%$以上吧，这个客户需要$100%$，他们安全部门对兼容性确实很重视，例如：在一次上线前要我们买3部三星note2吧，貌似是这个手机因为他们领导在用这个，我忘记是因为他们有三个领导还是不确定领导用的是哪个运营商定制的手机。所以要求我们购买联通，移动，电信三个定制版本（要求假设空间全覆盖，他们不去搞机器学习真是可惜了）。但是这种对自己工作的态度我还是很欣赏的。所以其实我并不是十分的反感(当时合同也没签，说在走流程试用)。我们当时整夜给他们调试兼容性，一个重要原因是在Google Play上有差评，可能大概有$20$多个吧，我记不清楚了。我也很理解，所以我们也很用心，我们当时还没那么多自建手机，为了他们每天租手机，一次$200$多台吧。具体价钱忘记了，大概一天$10$元。后来客户提出要上testin的TOP600当时一次测试费用大概$5000$，我们也同意了。当时推了一个新版本后，还是有差评(因为崩溃引起的)。他们安全部门的人就着急了。质问我们是不是真的测试兼容性了，不相信我们的测试部门。随后大晚上派了北京的同事来监督我们测试，当时晚上幸亏我没在，我在估计当场就要打人了。不过也惹恼了平常好脾气的李哥直接把他们捻出去了。我骂人应该发生在这件事之前，当时我进群和他们协调工作，爆发点是因为不到10天的时间，我们的测试费用已经高达近10万了。要知道他们合同还没签署。我一开始还和人家好好的协商，协商一点就是他们在崩溃前首先测试一下他们的程序，因为我们发现的是这$20$来条崩溃评论，至少有十几条是因为原包崩溃引起的。在我们相互调试2,3个版本后，发现多数崩溃都是业务部门自身APP开发引起，但是这个安全部门相当的弱势，估计是惹不起业务部门。也估计是打业务部门打脸打多了。不敢在拿的报告打人家脸了。每次都让我们先测试，主要是提出使用TOP600测试，当时我就想让他们先自测试。这测试一次就$5000$块钱。大家相互理解嘛，都不容易。矛盾就在这里吧，他们不同意，我就有点火大了。当时在微信群里回了一句大概是：“你们程序写的个那个逼样”，随后又和他们探讨了一下什么是充分条件，什么是必要条件。总之，他们无话了。估计当时已经毛了。这里不得不提牛哥(娜迦so动态加载保护就是他写的)，不亏也是厂矿子弟出身，直接也不给客户面和我一起怼，所以对于那次我最多负$70\%$的责任。下午我就被李哥给教育了一顿，说客户很生气，后果很严重。我和牛哥在的群他们已经不使用了。重新建了一个群。这个事件后，虽然心里有火。但是我们还是尽力配合他们，事情就这样又过了一年半吧。他们要求再做一次TOP600，我们也做了。我们觉得我们中的机率很大，毕竟给他免费服务了$3$年,虽然骂了人家，但是我觉得还好，毕竟没有直接问候他老母。那段时间是各个厂家尽相低价竞标严重的日子。所以为了保中，我们报了$10000$块钱。随后奇迹又发生了，中标的不是我们，是我们的竞争对手(这里简称B...吧，念的时候可以拉长音)。客户的职员还有脸问我们的同事，“你们不会告我们吧？”。随后我问朱哥哥怎么处理这事情，朱哥哥说他早已放弃这个客户了。我说那就算了。
之后相安无事，直到后来又发生一件神奇的事情，今年315，工信部泰尔实验室把这家客户的壳给破解了，然后做了转账劫持攻击并发到了网上。我当时还感觉这家客户肯定会把B给替换掉，我们倒是没想法替换成我们，感想这下另外一家竞争对手可以趁需而入了(简称S吧，随便起的，如果有人联想这个首字母，那就联想吧。这个对手确实不值得我们尊重。B虽然没有洁操，但S更无耻)。但是奇迹又发生了，那么苛求的客户居然妥协了，居然没有替换，随后更新了一版本强度更高的。但是看看国内360市场，应用宝市场等大市场，骂成神码样子的了。我们当时仅Google Play的$20$个差评他们就受不了了。现在N个市场都是整屏整屏的差评，他们居然最后采用的方式是关评的方式处理，居然还是不处理供应商B。这是件很神奇的事情，否则按照他们的要求早应该替换了啊。随后B对外宣称只是破解了第一层免费的防护。真的我这次直接想骂脏话了，操尼码不要脸的东西，人家都尼码实现转账劫持性攻击了，你TMD的好意思说破解了第一层免费的防护。脸呢？当其他客户是傻X吗？不是号称全公司500多号人估值30个亿吗？这是500人估值30个亿做出来的事情，说出来的話吗？全JB应该去抛腹自尽。你倒是出来和用过你们产品的客户道歉啊。欺骗算怎么回事。不想说了说多了都是气話。只能说我太天真。

谈谈当前移动加固产品的强度

从$13$年开始，加固市场慢慢兴起。到现在市场逐步接受这个概念，已经有$4$年时间了。$Android$方面主要有两种文件需要保护。一种是dex，一种是so文件。dex保护方面主要经历了三个阶段。

1. 类加载
2. 类抽取
3. 虚拟机保护

让我们聊聊这三种方式吧，第一种方式最为恶心。就是利用了Java提供的一个类似LoadLibrary的接口将目标dex动态加载起来，在文件形态中做加密。如果不是有这种接口，我相信不会有大量的公司来搞软件保护这种小众行业。说句不好听的话。$Android$的一个开源政策以及Java提供的加载接口使得让非逆向人员有了做这个行业的机会。让我们回到正题，这种保护非常简单。只要在程序运行起来后，附加进程dump内存即可还原。

再让我们看看第二种方式，在第一种持续一段时间后，发现这种方式过于容易被还原。就产生出了第二种方式，这种方式将要保护的类代码抽取掉，在类代码运行时，由优先启动的桩函数调用回填代码将加密后的代码写回去。这个桩函数可以是hook libdvm.so，libart.so，并攻击其中解析类代码的函数，也可以利用Java语言的一些优先特性来优先启动一些回填来替代hook操作。所以有些检测单位以及会用dexhunter的团队大言不惭的说可以破掉所有保护，真想说句：“快JB拉倒吧”。

为了避免上一种方法的弊端就产生了第三种方式。这种虚拟机保护的方式与PC上虚拟机保护原理大致相同。就是使用c语言在写一个自己字节码的虚拟机，将要保护的dex代码进行转换。在原先dex代码上填写进入虚拟机的引导代码。这种方式破解起来很麻烦，没有了类抽取的一些缺点。但是麻烦的是，如果使用这种方式保护的代码过多，会明显的降低效率。并且兼容性并不是那么好做。上面我BB半天就是因为B的兼容性做的太差了，导致客户的崩溃率过高的。

所以重点来了，很多客户都认为S和B这两家企业会在中标后给客户上他们所谓的虚拟机保护，这里我可以负责任的告诉你们，你们太天真了。他们只会给他们少量客户上这种产品，因为他们怕调试，为了节省售后成本。目前在这方面量产化的只有娜迦与360，说的不好听的一点SB两家企业很多商用版本都没有360免费的强，更不要和我们相比了。当然我不否认他们也有虚拟机保护，问题是其兼容性如何，是否能做好相应的售后服务就是两说了。
以上大概就是三种保护。

所以，如果你们遇到SB两家公司的产品，可以尝试使用dexhunter来尝试一下，应该可以得到很好的效果。除了极少数的一部分客户以外。

谈谈加密算法

加密算法，其实谁去关心呢？但是如果让我们对这个较真一下，就会发现每个加固厂商的算法都low到极点。这点我们其实做的还算好。为了效率以及实现方便的原因。没家厂商都会实现一些自己流加密算法。当然有时候密钥相当的简单。例如在S厂家在对dex做完类抽取处理之后，会xor 0xff作为加密。以下有段简单的python代码。暴力对比明文与密文来寻找出密钥。

#!/usr/bin/python
# coding:utf-8
import pdb
import numpy as np
import struct
#from collections import Counter
def xor(src, key):
    f = open('./a.bin', 'wb')
    for i in range(0, len(src)):
        if src[i] != 0:
            m = src[i] ^ key
        else:
            m = src[i]
        f.write(struct.pack('B', m))
    f.close()
def cracker(src, dest):
    """
    src 是对比明文
    dest 是要破解的密文
    """
    def __loop_try__(t, d):
        r = 0
        for k in range(0, 256):
            m = d ^ k
            if m == t:
                r = k
                break
        return r
    data1 = np.fromfile(src, dtype=np.uint8)
    data2 = np.fromfile(dest, dtype=np.uint8)
    key = 0
    keys = {}
    for i in range(0, 1000):
        key = __loop_try__(data1[i], data2[i])
        item = []
        if hex(data1[i]) in keys:
            item = keys[hex(data1[i])]
        if hex(key) not in item:
            item.append(hex(key))
        keys[hex(data1[i])] = item
    return keys
if __name__ == "__main__":
    keys = cracker('./classes4.dex', './classes.dex')
    #data1 = np.fromfile('./classes.dex', dtype=np.uint8)
    #xor(data1, 255)
    #pdb.set_trace()
    print keys
else:
    pass

cracker的第一个参数是明文文件，后边是密文文件。
如果有兴趣的人可以对比一下S的加固包。其中加密后的dex在assets的ijiami.data中，这个文件其实是个zip格式的文件也就是做过压缩的文件，将后缀名换成zip即可打开从中取出加密后的dex。这家企业的程序员恐怕不知道信息熵是何物，他们居然在xor 0xff时，跳过了$0$字节，估计是想$0$占了一个程序大部分的区域，对他不加密可以提高压缩效果吧。其实多虑了。反正你就异或一字节不会提高你程序的熵值，压缩率可以保证。可怕的是号称在安全圈，可是这些程序员的基本信息安全知识的素质都没有。

总结

加固市场的安全现在完全依赖一个开源产品，叫做llvm不是可以通过这个可以对加固程序本身做混淆的話。那些虚拟机保护代码，类抽取代码都会瞬间被逆向。完全没有强度可言。
加密算法强度低，其实可以理解。毕竟客户需要更好的产品体验，加快启动的速度。但是用单字节密钥还是过份了一些。