＃ 前言

在Root前提下，我们可以使用Hooker方式绑定so库，通过逆向方式篡改数值，从而达到所谓破解目的。然而，目前无论是软件加固方式，或是数据处理能力后台化，还是客户端数据真实性验证，都有了一定积累和发展，让此“懒技术”不再是破解修改的万金油。再者，阅读汇编指令，函数指针替换，压栈出栈等技术需要一定技术沉淀，不利于开发同学上手。

两年前，也是因为懒，很懒，非常懒，堆积了足够的动力，写了一个基于人工模拟方式，对一个特定规则的游戏进行暴力破解。我们都知道，人工模拟方式，绕过了大量防破解技术，只要还是人机交互模式，并且满足一定的游戏规则，基本是无法防御的。

以下是一段技术应用视频，以便大家对文章有个初步认识：

大家能够看到，这段一分钟的视频，在50秒的时候就刷爆了游戏分数上限，足见此技术能力并不亚于传统的Hooker篡改内存地址方式。

技术实现原理

因涉及到安全方面的考量，本文主要围绕技术实现原理和关键技术点进行阐述。

技术要求：

1. 支持多分辨率
2. 支持多点触摸
3. 支持输入速率动态变更
4. 处理能力峰值需要达到30fps

实现方式分三步：

1. 劫持屏幕
2. 分析数据
3. 模拟输出

1.劫持屏幕

先说说劫持屏幕，做过截屏功能的同学应该清楚，Root了之后能访问设备“dev/graphic”文件夹，里面有fb0, fb1, fb2三个screen buffer文件。这里用到的是fb0文件。

抛出一个问题，当前主流屏幕分辨率都在1920*1080区间，一张图片的缓存能去到2M左右，要达到30fps的性能指标，光是屏幕数据的读写耗时，就满足不了要求。怎么做呢？

一般在做图像处理的时候都会想到parallel programming。然而，这里的图片是时间相关的，不适宜采用多线程任务派发。

懒人一番思量后，发现一条捷径，共享内存读取，请看以下代码。

mapbase = mmap(0, **mapsize, PROT_READ, MAP_SHARED, fd, offset);

这行代码广泛存在于各个截屏代码片段中，精髓在于PROT_READ 和 MAP_SHARED上。先科普一下mmap参数中这两个参数吧。

prot ： 映射区域的保护方式。可以为以下几种方式的组合：

• PROT_EXEC 映射区域可被执行
• PROT_READ 映射区域可被读取
• PROT_WRITE 映射区域可被写入
• PROT_NONE 映射区域不能存取

flags ： 影响映射区域的各种特性。在调用mmap()时必须要指定MAP_SHARED 或MAP_PRIVATE。

• MAP_FIXED 如果参数start所指的地址无法成功建立映射时，则放弃映射，不对地址做修正。通常不鼓励用此旗标。
• MAP_SHARED 对映射区域的写入数据会复制回文件内，而且允许其他映射该文件的进程共享。
• MAP_PRIVATE 对映射区域的写入操作会产生一个映射文件的复制，即私人的“写入时复制”（copy on write）对此区域作的任何修改都不会写回原来的文件内容。
• MAP_ANONYMOUS建立匿名映射。此时会忽略参数fd，不涉及文件，而且映射区域无法和其他进程共享。
• MAP_DENYWRITE只允许对映射区域的写入操作，其他对文件直接写入的操作将会被拒绝。
• MAP_LOCKED 将映射区域锁定住，这表示该区域不会被置换（swap）。

因为我们不需要写屏，所以prot只需要采用PORT_READ；而我们期望避免屏幕数据的多次创建，flags就需要用到MAP_SHARED，这样文件句柄fd指向的内存块数据就会实时变更，无需多次创建，拷贝，释放数据。

2.分析数据

截取到屏幕数据就好办了，对每一帧进行数据处理，这里完全就是算法问题了。懒人都用搓算法，大概的思路就是：7*7宫格，对于所有相连的两个同色item做了横向映射表和纵向映射表，然后轮寻处理5连，4连和3连。里面还有一些涉及到实现细节的映射表重置与预判，因为不是本文重点，就带过了。

void Handle_X_Combination() {

    LOGE("Handle_X_Combination");

    gen_Horizontal_Matrix(6);

    get_Horizontal_X_Match();

    gen_Vertical_Matrix(0, 6);

    get_Vertical_X_Match();
}

下面是程序运行时的Log信息片段，以供大家参考。

3. 模拟输出

算法会输出当前屏幕的一个模拟手势操作队列，最精彩的当然放到最后，也是此工程的技术点，怎么模拟输出手势的问题。

Android所给予的截屏和模拟操作分别为 adb screenshot 和 adb shell sendevent (根据android版本，有些机型用的是input event，记得没错的话～)
所有需要adb处理的指令，都不能采用高并发方式调用，要不然要么机器重启，要么指令堵塞。所以adb这条路不通。
怎么办呢？

懒人又一番思量后，linux系统大都采用文件buffer，直接将指令写文件吧。其实adb也是写文件，不过adb做了一层转译，这里涉及到设备层指令代码，不同机型定义的指令代码不尽相同。

要完成此任务，首先要弄清楚几件事情：

1. 一个点击事件的构成是怎样的
2. 一个滑动事件的构成多了什么
3. 事件的指令代码分别代表什么

万能的adb给了我一些思路，adb shell getevent，会打印出当前event的指令。再科普一下，event有很多，包括compass_sensor，light_sensor，pressure_sensor，accelerometer_sensor等等。
我们这里监听的是，touchscreen_sensor。

有了上面的指导信息，要构建一个模拟操作函数就很容易了。操作屏幕打印出想要的模拟的手势，然后写下来就好了。一共会有这么几个模拟操作函数需要创建：

`
void simulate_long_press_start_event(int touch, int fromX, int fromY);
void simulate_long_press_hold_event(int touch, int fromX, int fromY);
void simulate_long_press_end_event(int touch);
void simulate_press_event(int touch, int fromX, int fromY);
void simulate_move_event(int touch, int fromX, int fromY, int toX, int toY);
`


下面给出一个我写好的范例出来，大家可以依葫芦画瓢，把剩下的写好。

void simulate_press_event(int touch, int fromX, int fromY) {

    pthread_mutex_lock(&global.writeEventLock);

    LOGE("simulate_press_event");

    INPUT_EVENT event;

    // 0. Multi-Touch
    // 此项目非必要，因为没有用到多点触摸，是另一个项目使用到了
    event.type = 0x3;
    event.code = 0x2f;
    event.value = touch;
    write(global.fd_event, &event, sizeof(event));

    // 1. ABS_MT_TRACKING_ID:
    // 理论上必要，因为Android事件输入是批量处理的，需要用到输入id，
    // 但是这里偷懒使用了同步锁，并且没有多点触摸需求，所以不会有Tracking_ID串扰问题，也就不需要记数了
    event.type = 0x3;
    event.code = 0x39;
    event.value = global.event_id > 60000 ? 10 : global.event_id++;
    write(global.fd_event, &event, sizeof(event));

    // 2. At screen coordinates:
    // 触摸点x，y坐标
    event.type = 0x3;
    event.code = 0x35;
    event.value = fromX;
    write(global.fd_event, &event, sizeof(event));
    event.type = 0x3;
    event.code = 0x36;
    event.value = fromY;
    write(global.fd_event, &event, sizeof(event));

    // 4. Sync
    // 数据同步到设备
    event.type = 0x0;
    event.code = 0x0;
    event.value = 0x0;
    write(global.fd_event, &event, sizeof(event));

    event.type = 0x3;
    event.code = 0x39;
    event.value = 0xffffffff;
    write(global.fd_event, &event, sizeof(event));

    // 4. Pure event separator:
    // 结束符
    event.type = 0x0;
    event.code = 0x0;
    event.value = 0x0;
    write(global.fd_event, &event, sizeof(event));

    pthread_mutex_unlock(&global.writeEventLock);
}

建议大家在动手写模拟输入模块之前，先仔细研读Android input事件机制，对于个人程序修为大有裨益。有时间我会单独写一个技术文档供大家参考，目前就此带过了。

调试

因为我是个懒人，能偷懒的地方都会花时间深研。以下，是个人针对本项目调试的一些懒技巧，以供各位参考。

下面是在Debug模式下生成的8张连续图片。能看到每个小宫格的右上方都打印出了当前识别的颜色。如果当前宫格需要被移动，则采用双色绘制表明移动的方向，上下双色表示需要上下移动，左右双色表示需要左右移动。

此外，调测程序的时候必不可少的就是单步回归了，以下是设计的Dummy模式，以验证Bug修复效果。

int loadImageData(const LPSTR device, GGLSurface *gr_framebuffer,
        Var_ScreenInfo *vi, Fix_ScreenInfo *fi, ssize_t* mapsize) {
#ifdef TEST_DUMMY
    return test_dummy("/mnt/sdcard/screenss.bmp", &gr_framebuffer, &vi, &fi);
#else
    return get_framebuffer(device, &gr_framebuffer, &vi, &fi, &mapsize);
#endif
}

至此，主要关键技术已经简述完毕，谢谢大家。

＃ 后记

大家如果仔细看了这篇文章，会发现视频中的游戏版本，和截屏图片的版本是不一致的。视频是我在13年的时候录的，截屏是因为KPI考核要求写文章，临时又生成一遍的，所以会有版本差异。做这个技术的初衷就是因为懒，才想到虐爆Android的。从开始到第一个demo出来，大概花了一周的时间，因为思路都比较清晰，后续的优化反而花了一个多月，包括防破解这块（总不能出个破解然后被人爆菊吧，太侮辱智商了）还是需要仔细走读一下底层实现。其中也请教了当时公司安全部的哥们，知道了更多关于软件实现机制，也深知安全的重要性，所以这段代码一直只存留在我的代码实验室，以前不会，现在不会，以后也不会开源发布，所以请各位海涵了。有兴趣的同学可以通过自己的努力实现一遍，对个人技术的提高会有很大帮助。

这篇技术文档的确只覆盖了一些关键技术节点，还有较多和当前程序不相关的技术并没有被涵盖，例如底层加固技术，动态底层Binary Dex加载技术（在Art下需要有一定的修改，懒，没有去深挖了），so库混淆，屏幕同步，模拟输入同步等，往后有时间再行一一简述吧。