最新消息:欢迎访问Android开发中文站!商务联系QQ:1304524325

Andriod 破解之道(一)

开发进阶 AndroidChina 1901浏览 0评论

# 前言

在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信息片段,以供大家参考。

435BEE50_B652_49A4_9A95_BBF67165BBD1

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。

4E3C742D_8BDD_485B_9903_7BAA36FB04AC

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

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张连续图片。能看到每个小宫格的右上方都打印出了当前识别的颜色。如果当前宫格需要被移动,则采用双色绘制表明移动的方向,上下双色表示需要上下移动,左右双色表示需要左右移动。

screen000_jpeg screen001_jpeg
screen002_jpeg screen003_jpeg
screen004_jpeg screen005_jpeg
screen006_jpeg screen007_jpeg

此外,调测程序的时候必不可少的就是单步回归了,以下是设计的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库混淆,屏幕同步,模拟输入同步等,往后有时间再行一一简述吧。

转载请注明:Android开发中文站 » Andriod 破解之道(一)

您必须 登录 才能发表评论!