干货 | 聊聊移动端安全加固

作者简介

 

老松树,携程高级开发经理,专注于移动应用的信息安全。

随着移动互联网产业的高速发展,智能手机的全面普及,移动App已经无处不在。据统计,我国智能手机用户达到12亿,手机App总量达到400万款。手机APP在方便人们生活之余,也带来了巨大的安全隐患。

App主要面临的风险:

1)静态攻击风险

APP通常很容易被反编译逆向分析源码,出现被破解、篡改、广告植入、二次打包、仿冒/钓鱼应用等风险。

2)动态攻击风险

由于APP运行环境和用户操作行为不可控,导致APP在运行过程中面临各种动态攻击,如模拟器、多开器、加速器、注入攻击、动态调试、设备篡改、位置欺诈等攻击。

3)业务作弊风险

企业大量业务已经由线下及Web端转至手机APP端,目前地下黑灰产通常在APP注册、登录、营销活动场景进行批量化、机器化作业,威胁平台利益和用户账号安全。

移动安全已经成为互联网企业发展过程中面临的一个重要问题,需要更多的关注和投入。

一、手机APP安全加固介绍

解决移动安全问题,要从APP前端的加固,和业务后端的分析两方面进行。本文将介绍手机APP安全加固方面的知识。

下面从iOS平台着手,从以下几个方面,介绍移动端安全加固的方案。

一个标准的安全加固SDK,要包含以下几个要素:

  • 运行环境检测

  • 环境数据的收集

  • 符号,代码的混淆

  • 算法的混淆

  • 虚拟机技术

二、运行环境检测

确认APP的运行环境是否安全,是APP加固的最基础条件。所以我们的加固SDK中,要尽量靠前的进行APP的检测。

检测主要包括以下方面:

  • 越狱检测

  • Hook检测

  • Debug检测

  • 重签名检测

  • 模拟器检测

  • 代理检测

2.1 越狱检测

2.1.1 越狱概念

越狱是指利用iOS系统的某些漏洞,取得到iOS的root权限,然后改变一些程序使得设备的功能得到加强,突破封闭式环境。

越狱使得第三方管理工具可以完全访问iOS设备的所有目录,并可安装更改系统功能的插件和盗版的软件。

对于攻击者来说,越狱一般是iOS设备破解的第一步,只有越狱过才能实现后续的安装插件,砸壳获取二进制文件等一系列操作。

2.1.2 越狱检测

根据越狱手机和非越狱手机权限等方面的区别,我们可以检测当前环境是否是越狱设备。

例如,可以检测下面这些目录:

  • 检测系统根目录文件

  • 检测是否有一些越狱插件

/bin/bash
/bin/sh
/var/lib/cydia/
/Applications/Cydia.app
/Library/MobileSubstrate
...

如果这些目录存在,则表示当前是越狱设备。

2.2 Hook检测

2.2.1 Hook概念

Hook(钩子),实际上是一个处理消息的程序段,通过系统调用,把它挂入系统。每当特定的消息发出,在没有到达目的窗口前,钩子程序就先捕获该消息。在Hook程序执行完,再决定后续的操作。

攻击者在破解APP时,经常会通过Hook方式,对APP中的关键位置的函数进行Hook。

通过Hook手段,攻击者可以方便破解分析,可以模拟发送业务请求,可以调用加密方法进行数据处理等。

2.2.2 Hook检测

iOS中的Hook主要有以下几种:

  • 通过iOS的runtime消息转发的特性,实现对iOS函数的Hook。

  • 利用程序在调用外部函数时,通过符号表查询函数实际地址,实现的例如C系统函数的Hook。

  • 利用第三方插件库,实现汇编级别的Hook。

在Hook检测时,可以通过各类Hook的原理和特性,进行反向的检测。

对于汇编级别的Hook,通过比较函数内的汇编代码,来判断是否有汇编级别的Hook。

2.3 Debug检测

2.3.1 Debug

在破解App包时,需要通过GDB或LLDB来进行调试。所以对APP的调试检测,也是必须的。

2.3.2 Debug检测

可以通过ptrace等方法,查看是否处于调试状态。对于已经发布的包,如果检测出调试状态,应该及时终止进程,阻止攻击者的攻击。并且让崩溃点,尽量远离检测点,并清空进程信息,防止攻击者确认检测关键点位置。

2.4 重签名检测

2.4.1 重签名

App Store下载的应用,在砸壳之后,可以通过重签名的方式,实现App包的安装运行,实现逻辑的修改,APP的多开等功能。

2.4.2 重签名检测

对于包的重签名检测,可以从以下两方面进行:

  • 检测embedded.mobileprovision中的签名信息,是否正确。

  • App Store下载的包都是加密的,砸壳后的包是没有加密的,可以检测加密标志的状态。

2.5 模拟器检测

攻击者也有可能使用ARM模拟器运行,需要进行模拟器检测。

2.6代理检测

攻击者可以通过设置网络代理,抓取App的业务请求,实现修改重发等操作,要进行必要的代理检测。

三、环境数据的收集

通过收集App运行手机的环境信息,尽可能的识别和标识运行设备,跟踪危险用户动作行为,进行持续分析。

通过设备信息的聚合分析,判断用户的环境是否真实,是否是虚拟的伪造的设备。例如:对于攻击者通过设备,进行自动化的注册登录等行为,通过设备ID等信息的聚合,可以发现其中的一些规律。

手机的环境信息,列举部分:

IDFA      广告标示符
IDFV      Vendor(供应商)标识
Appleid   appleid的相关的一串id
Wifi      Wi-Fi信息
fingerprint  设备指纹信息
os_model  系统型号信息
CUP信息
手机型号
屏幕宽高
内存大小
手机容量
.....

通过种类繁多的设备信息的收集,上传到后端后,由后端通过AI,大数据等手段进行设备打分,设备聚合等一系列操作,给设备定义出一个安全范围。为安全人员的后续分析,提供有力的数据支撑。

四、符号,代码的混淆

4.1符号的混淆

对代码中,关键部分的代码,类名,函数名等部分,要进行混淆。让攻击者无法轻易通过名称,理解当前代码的功能含义,增加破解难度。

可以通过宏定义的方式,混淆函数名称,例如:

#define  MyClass       FX123ADHZA
#define  propertyName  XZAF891AFJ
#define  method_arg1   KAJ18XA91F
#define  method_arg2   JAC12DDASS
#define  method_arg3   WIAK198FJS


@interface MyClass : NSObject
@property (nonatomic,copy) NSString * propertyName;
- (void)method_arg1:(NSString *)arg1 method_arg2:(NSString *)arg2 method_arg3:(NSString *)arg3;
@end

编译出来的代码如下图所示,混乱的方法名,让攻击者理解方法含义的成本增加:

4ba9c4efe5039a6a3f4924969e4c2139.png

4.2 字符串混淆

攻击者在进行逆向分析时,通常会根据一些特定的字符串,查找定位到代码的关键位置。所以在安全加固的过程中,不让关键的字符串以明文的形式存在,要对字符串进行混淆,在运行使用时,再解析出来:

例如字符串,对这段字符串可以使用异或等方式进行混淆,混淆后的结果为:

0123456789ABCDEF

混淆后的效果为:

ea84bb6e0c5dd2ba5c881077e493b858.png

4.3 数据混淆

常用的加密算法,算法通常都有一些运算的模数。对这些模数,也要进行混淆处理,在使用时再解析出来使用。

五、算法的混淆

攻击者逆向过程中,通过砸壳获取到APP的二进制文件。将二进制文件放入IDA软件,可以进行静态分析,还可以通过插件,反编译出伪代码。

所以,在安全加固的过程中,要对安全SDK中的关键算法,进行算法的编译混淆。

通过Clang,在编译过程中,将算法逻辑打乱重排,嵌套一些while循环,或者switch分支,并且插入一些混淆代码,防止攻击者的反编译。

例如,正常的算法的汇编代码:

9f424d1172bcc0136028a24b675ef2c0.png

这样的汇编代码,可以在IDA中,通过IDA等分析工具,可以反编译出伪代码,攻击者可以很方便的进行分析,通过调试还原出代码的原始逻辑:

aec87ebdd56df0c24f1e1a328dc345a1.png

而我们在编译过程中,将汇编代码进行打乱重排,插入虚假判断逻辑等,可以有效的进行防范。如下图所示,便是一种混淆模式,将算法混淆之后的效果:

a822b7be98cbfb5583202dde93c36112.png

混淆后的代码,代码段被切割重排,中间还插入了无用代码,使攻击者无法阅读,更增加了攻击者调试的成本。

六、虚拟机技术

在安全加固方面,安全性最高的一种加固手段,就是虚拟机加固技术。它是将原始代码的算法代码,编译为动态的VM虚拟机指令,在虚拟机中解释执行,最终计算出计算结果。

加密后的代码,具有不可逆性,无法被反编译回源代码。算法代码动态执行,单步执行,难以调试分析。

而且,虚拟机处理的算法代码,可以动态下发,极大的提高了算法的安全性。

064c95e808bc5be32cc41a765240d392.png

七、携程安全加固SDK的产品功能

7.1 种类齐全的设备信息

携程安全加固产品,经用户授权后,收集种类相对齐全的设备信息,通过设备信息,后端分析算法,可以高效辨别设备的真实性。

通过大数据技术,对设备信息进行多维度分析,给设备进行打分,建立用户安全等级。

7.2 多样/隐蔽/安全的设备环境监测

我们对设备的环境监测,越狱,调试,重签名等检测项,都提供了两种以上的检测方案,做到多方案互备。

每种检测方法,都使用了非常隐蔽的调用方法,减少被Hook,被定位的可能性。让加固产品的环境监测更加安全可信。

7.3 自主实现的代码混淆技术

使用了自主实现的代码混淆技术(bnof),对比市面上开源的混淆算法,更加安全和高效。

携程的代码混淆技术,可以抗优化,可以灵活调节代码切割粒度,执行效率更加高效。混淆后的汇编代码,无法进行反编译,修复成本极高,能对关键加密代码提供很好的保护。

7.4 自主实现的虚拟机技术

携程的安全加固产品,使用了自主实现的虚拟机技术(VM),安全,稳定,可靠。虚拟机技术为核心的加密代码,提供了极强的保护。

八、总结

在严峻的安全形势下,携程加固产品上线以来,取得了良好的效果,为安全部门和业务部门的风控和反爬虫工作,提供了强力的支持。

团队招聘信息

我们是携程火车票研发团队,负责火车票业务的开发以及创新。火车票研发在多种交通线路联程联运算法、多种交通工具一站式预定、高并发方向不断地深入探索和创新,持续优化用户体验,提高效率,致力于为全球人民买全球火车票。

在火车票研发团队,你可以和众多技术大牛一起,真实地让亿万用户享受你的产品和代码,提升全球旅行者出行体验和幸福指数。

如果你也热爱技术,并渴望不断成长,火车票研发团队期待与你一起高速前行。目前我们前端、后台、算法、大数据、测试等技术岗位均有职位。

简历投递:tech@trip.com  邮件标题:【姓名】-【携程火车票】-【投递职位】

【推荐阅读】

0d0a262749d2932b45c658f96c7422f7.png

 “携程技术”公众号

  分享,交流,成长

### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值