＃ 前言
在Root前提下，我们可以使用Hooker方式绑定so库，通过逆向方式篡改数值，从而达到所谓破解目的。然而，目前无论是软件加固方式，或是数据处理能力后台化，还是客户端数据真实性验证，都有了一定积累和发展，让此“懒技术”不再是破解修改的万金油。再者，阅读汇编指令，函数指针替换，压栈出栈等技术需要一定技术沉淀，不利于开发同学上手。
两年前，也是因为懒，很懒，非常懒，堆积了足够的动力，写了一个基于人工模拟方式，对一个特定规则的游戏进行暴力破解。我们都知道，人工模拟方式，绕过了大量防破解技术，只要还是人机交互模式，并且满足一定的游戏规则，基本是无法防御的。
以下是一段技术应用视频，以便大家对文章有个初步认识：
大家能够看到，这段一分钟的视频，在50秒的时候就刷爆了游戏分数上限，足见此技术能力并不亚于传统的Hooker篡改内存地址方式。
技术实现原理
因涉及到安全方面的考量，本文主要围绕技术实现原理和关键技术点进行阐述。
技术要求：
- 支持多分辨率
- 支持多点触摸
- 支持输入速率动态变更
- 处理能力峰值需要达到30fps
实现方式分三步：
- 劫持屏幕
- 分析数据
- 模拟输出
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做了一层转译，这里涉及到设备层指令代码，不同机型定义的指令代码不尽相同。
要完成此任务，首先要弄清楚几件事情：
- 一个点击事件的构成是怎样的
- 一个滑动事件的构成多了什么
- 事件的指令代码分别代表什么
万能的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库混淆，屏幕同步，模拟输入同步等，往后有时间再行一一简述吧。
