背景
我们的生活、工作、学习都正在被数字化、移动化。智能手机的普及推动了手机APP的快速发展，小到沟通聊天、车票预定，大到银行理财、支付交易，各种APP层出不穷。人们对APP的功能性、多样性的积极态度远远超出了对信息安全的担忧，APP的安全方面并没有得到很好的保证，通过APP导致的信息安全事件，经常被爆出。正在兴起的车联网也未能幸免，据统计车联网信息安全约50%安全漏洞、风险，来自于车载APP。针对APP的设计与研发，需要对信息安全高度重视，做到杜渐防萌，确保用户敏感数据的安全。
车载APP攻击手段
- 静态分析
静态分析指的是对APP安装文件的安全漏洞检测。首先获得应用程序安装包文件，即APK文件，然后通过逆向工具（如APKIDE、Dex2Jar等）进行反编译，将APK文件逆向为Java源文件或JAR文件，对其进行源代码级的解析。
常见的Java层逆向工具：Android Killer和APKIDE
Android Killer是一款可以对APK文件进行反编译的可视化工具，它能够对反编译后的Smali文件进行修改，并将修改后的文件重新进行打包形成APK文件。一旦APK文件被逆向，那么很容易对其进行篡改和注入攻击。
APKIDE也是可视化的、用于修改安卓APK文件的工具。该工具集成了 ApkTool，Dex2jar，JD-GUI 等APK修改工具，集APK反编译、APK打包、APK签名为一体，是非常便利的 APK 修改工具。
常见的NATIVE层逆向工具：IDA pro
IDA pro以其强大的功能和众多的插件成为了很多逆向分析师的首选。IDA pro是商业产品。使用IDA反汇编二进制文件的目的，是利用工具得到反汇编之后的伪代码，另外，再结合file 、readelf等指令使用，可以说如虎傅翼，准确还原出源代码并非难事。
以上是Java层和Native层逆向的常用方法。静态分析的优点是无需运行代码，无需像动态分析那样改写Android系统源码，或要求用户对Android系统进行重定制和安装定制版的ROM，因此静态分析具有速度快、轻量级的优点。但是静态分析的缺点是因为无法真实模拟程序的动态运行，所以存在误报率高的问题。
- 动态分析
由于静态分析难以满足安全人员的分析要求，天生对软件加固、混淆免疫的动态分析技术应运而生。相对于轻量级的静态分析，动态分析则是重量级的程序运行时的分析。在一般情形，需对Android系统进行重新定制与改写，包括改写安全机制；在原生Android系统中加入监视器，实时监视数据的流向；在危险函数调用时，检测所需权限等。
常见的动态分析的工具：TaintDroid
TaintDroid是变量级和方法级的污点跟踪技术工具，可对敏感数据进行污点标记，污点数据在通过程序变量、方法、文件和进程间通信等途径扩散时，对其进行跟踪审查。如果污点数据在一个泄露点(如网络接口)离开系统， TaintDroid就在日志中记录数据标记、传输数据的应用程序和数据目的地，实现对多种敏感数据泄露源点的追踪。
动态分析的优点是，检测精度较高，缺点是需要修改Android系统源码，形成用户全新裁剪的操作系统，同时需要通过更新ROM安装这种定制系统。另外还有代码覆盖率低，执行效率低下等，但是瑕不掩瑜，个人认为熟悉各种动态分析技术的核心原理也应当是安全从业人员的必备要求。
- 其他攻击手段
恶意软件攻击：最著名的三大AndroidRootExploit恶意软件是Zimperlich、Exploid和RATC(RageAgainstTheCage)。恶意软件的核心原理是砸壳或解密，然后发起“rootexploit”攻击，通过非法手段获取根权限。
提权攻击：指没有任何权限的恶意程序能够通过第三方合法APP获得所需的权限，或者说一个拥有较低(较少)权限的应用程序访问拥有较高(较多)权限的组件而不受任何限制。
中间人攻击（MITM）：顾名思义，攻击者插入到原本直接通讯的双方，让双方以为还在直接跟对方通讯，但实际上双方的通讯对方已变成了中间人，信息已经是被中间人获取或篡改。
车载APP安全方案
- APP合法性
一般情况下，车厂对自己放在应用市场的APP都有严格的审查策略、验签名机制、开发者ID的管理，以此来确保APP的合法性。如下是一个简单的APP生产流程图：
- 车厂委托APP供应商开发APP应用；
- APP供应商登陆车厂的开发者中心申请开发用的证书；
- 车厂将APP供应商开发完成的APP，推送到应用市场后台；
- 汽车用户到车厂专属的应用商店，下载自己想要的APP。
- APP研发阶段安全策略
API接口
检查所有jar包，特别是引用第三方jar包时，一定要做接口是否安全分析，并做代码扫描，自行开发的jar包、War包需要加密处理，防止反编译、防止逆向工程。如果SO库文件的话，源代码需要进行混淆处理，增强反编译的难度。另外，对混淆策略做评估分析，防止APP性能有明显下降；同时，SO库文件还需要进行加壳处理，使SO文件无法正确反编译和反汇编。另外，API接口还需要授权绑定，防止API接口被非授权应用调用运行。
功能测试报告
APP开发过程中，单元测试报告，结合测试报告，代码review记录。
性能测试报告
关注的参数有：CPU，内存，耗电量，流量，FPS，APP的安装耗时和启动耗时。
自身安全
通过静态分析技术，识别APP自身存在的恶意行为、敏感权限、病毒木马等风险。
防代码逆向
覆盖Java、C、C++、C#、Lua、JavaScript代码，识别每项代码防逆向工程的自我保护能力。
防动态攻击
独创真机运行模式，模拟调试、内存dump、注入Hook等攻击，检测APP的自我动态防御能力。
- 本地数据
通过静态分析技术，检测APP是否存在明文密钥、证书、敏感数据、开发日志等信息。
如果条件允许的话，采用安全执行环境TEE/SE方案（SE成本更高些），密钥生成和密钥保存都放到TEE/SE可信环境下完成，来保证本地数据的安全。
如果无法采用安全执行环境方案的话，密钥的生产用key2code完成，保证密钥的安全，从而保证本地数据的安全。本地数据不管是用文件、SQLite保存都要加密保存，加密算法根据实际情况拟定，因为APP加密的数据需要到云端解密，所以需要云与端都支持的算法才行，目前传统车厂算法库是存在没有及时更新的风险的。
- 安全UI
安全UI在支付场景下，被规范严格要求的是安全键盘。通常要求实时加密通过安全键盘的信息，隐藏键盘回显，按键水印等信息，防止第三方键盘或者系统键盘安全级别无法掌控等风险。推荐采用TEE方案的TUI，键盘的描画与输入均在TEE侧完成，可做到安全显示、安全输入、安全指示，达到防止截屏/录屏，防止数据收集，防钓鱼的目的，确保数据更安全。
由于技术具有一定的复杂度，目前还没有车厂采用基于TEE的TUI方案。目前国内的安全UI实现大多仍然是采用基于白盒加密的实现。但是在手机上金融级别的安全应用，已经使用了基于TEE的TUI实现。
- 身份认证
应对登录的用户进行身份标识和鉴别，检验APP是否具备抵达认证风险的能力。
- 通信数据
对网络通信HTTP、HTTPS等协议进行安全检测，及时发现潜在的安全漏洞，目前云与端通信基本都是SSL/TLS1.2协议、双向认证，确保云端链路的安全。如果可以的话，应升级到TLS1.3。原因与技术细节之后我们将在专门章节进行交流。
- 内部数据
针对APP常用组件的配置进行检测，及时发现潜在的安全漏洞，避免数据泄漏问题。
- 恶意漏洞
定期更新应用漏洞，及时发现安全风险，预警开发人员。
- 恶意行为检测上传
车载APP安全策略除了数据加密、代码混淆、反调试等主动防护外，还需要采用动态检测 APP 异常信息，主动上报车机设备信息、调试器信息、是否越狱、修改器信息、hook 工具信息、加速器信息、外挂工具信息、攻击框架信息等恶意行为到云端服务器（车厂负责管理），作为业务风控参考指标。当APP遭受注入、调试、篡改、重签名等非法攻击行为时，云端服务器会警告用户、封号、冻结APP、甚至禁止车辆使用。
以上是车联网众多节点中的APP（端）的一些安全措施和方案，下一回我们将分析车联网后台（云）安全方案，敬请关注。