Android（一）yunos_acb调试工具简析

1.yunos 调试工具正常只能自家手机助手使用，直接调用会提示`parameter verify false`参
数验证错误:

2.分析 acb.exe，找到对应`parameter verify false`字符串代码部分，发现入口有字符串验证 函数，而 `adb_commandline` 即正常 adb 工具入口:

3.verify_input 入口有一段字符串验证，通过之后才会对比指令:

4.验证的字符串就不算了，process explorer 可以直接从命令行里找到:`acb 覺ガ F x fork-server server`

5.附加对应字符串即可使用 acb 的调试功能:

6.不过 acb 工具只允许通过少部分指令，其他都被阉割了，如下直接使用 shell 就无法通过 验证，只能使用类似 shell am 的指令:

7.总结能使用的 adb 指令如下，相当有限，可直接复制使用，也可后面附加其他参数: 
acb覺ガF x fork-server
acb覺ガF x start-server
acb覺ガF x kill-server
acb覺ガF x devices 
acb覺ガF x get-state 
acb覺ガF x forward 
acb覺ガF x pull 
acb覺ガF x shell am 
acb覺ガF x shell pm 
acb覺ガF x shell logcat 
acb覺ガF x shell getprop 
acb覺ガF x shell ps
acb覺ガF x shell netstat

8.上述指令没有安装 apk，也没有 push 可以推送进手机后 pm 安装，具体实现安装细节还未 分析清楚

IoT（二）NFC

整理补充点RFID射频入门知识，方便以后使用：

NFC技术基于RFID，其工作频率为13.56MHz。

可以参考ISF这篇ppt：RFID-ISF2014-杨旭-中文.pdf

另外补充一本NFC方面经典书籍：Near Field Communication 

RF卡也称非接触IC卡、射频卡，基于电磁感应原理

当RF卡靠近电磁场时，线圈从电磁场中吸收能量，能力聚集足够时卡中微电路开始工作

微电路工作并不发射数据，而是利用消耗电磁能量使电磁信号发生变化，该电磁场变化即对应卡中的数据

IC卡存储区分配表：

RFID将整个存储区划分为多个扇区（一般16个），每个扇区4个块，每块16字节，其中每个扇区03块用来存放密钥。

（表来自学校一卡通）

扇区00的块00是特殊块，一般存储制造商代码：

• 第0～4字节为IC卡的序列号
• 第5字节为序列号的CRC校验码
• 第6字节为IC卡的容量“SIZE”字节
• 第7、8字节为IC卡的类型编码字节

其他字节由厂商自行定义。

存储区数据访问条件：

各扇区03块为控制位，前后各6B存储KeyA和B，Key不可读

中间AccessBits为访问控制设置，用于设置该分区四个存储块的访问条件和数据块类型

每个块有三个控制位，如块0：C10,C20,C30，访问条件如下：

块0、1、2有读、写、加值Increment、减值Decrement、传送transfer、恢复Restore，共六种操作

块03只有读写两种操作

IC卡内数据金额算法：

对比上图，60h即上图第01扇区第01块

我们只看选中的这两行就行，也就是

 10 27 00 00 EF D8 FF FF 10 27 00 00 01 FE 01 FE

我们暂且把这行数据分成四段来看

第四段是地址位，所以我们可以忽略不看，但是写卡的时候也不要动它，就让它保持原来的样子就行。第1和第3段是一样的。中间的FFFF也不要管了。
我们接下来开始计算其中的数据，先看第1段是1027，因为它是十六进制的，所以1027先倒序之后就是2710，然后再转换成二进制就是10011100010000，在计算的时候大家要记好一个十六进制数对应的是4个二进制数，所以前面转换的二进制其实应该是0010 0111 0001 0000，如果位数不够的话就在前边补零，然后再转换成十进制就是10000，因为保留两位小数，所以10000在刷卡时候就是100.00也就是100块。
再来看第二段EFD8，EFD8倒序一次是D8EF，然后转换成二进制就是1101 1000 1110 1111，然后再取这个二进制的反码，就是0010 0111 0001 0000，取反之后再转换成10进制就是10000，还是100块，只是这两个存储的方式不一样罢了，第3段和第1段是一样的，所以在计算方面，只计算第1段和第2段就行了。现在我们计算的是倒着来的，也就是从卡内的数据转换成具体金额的方法。也就是逆向计算的。
下面我们把这个具体的思路再整理一下：
1段数据算法(非逆向)：十进制金额→转二进制→转十六进制→倒序。
2段数据算法(非逆向)：十进制金额→转二进制→取反码→转十六进制→倒序。
下面是逆向计算数据的算法，其实就是把上面的反过来罢了，逆向计算的通常是为了验        证一下计算的数据有没有出错，算法如下：
1段数据算法(逆向)：十六进制倒序→转二进制→转十进制。
2段数据算法(逆向)：十六进制倒序→转二进制→取反码→转十进制。

有兴趣可以对这篇blog里的数据算一下：

http://blog.avlyun.com/2014/11/1668/nfc-phone-fee-consumption/

其他：

通常一个密码系统只要密钥未泄露，它也应该是安全的。

RF卡虽然数据存储在本地，但一般RF卡支付系统都会有后台审计的，只是时间未知。

也有一些RF卡只做身份识别，数据则在云端。

所以本地修改RF卡可以玩玩，不过不要太投入，毕竟有过前车之鉴（360员工被捕）。

武汉交通卡：

一般交通卡都可以使用NFC来识别，比如使用通用工具”NFCard“就可以读取余额和记录。

北京卡可以直接读取余额和记录：

武汉卡由于对余额做过处理，通用工具只能识别记录：

但若使用”武汉通行“官方充值工具则可以读取：

 

银行卡：

通用工具”NFCard“可以读取卡号、有效时间、ATM终端交易记录，余额信息本地应该没有：

Android/Malware（二）Xposed恶意插件可自动安装激活

（2014年11月18日发在AVLTeam blog Xposed恶意插件可自动安装激活）

0x0 概述

AVL移动安全团队在之前的《Xposed恶意插件》一文中分析了一个Xposed恶意插件，但是由于Xposed模块需要手动勾选重启后才能生效，导致应用场景有限。之后网友MindMac提供了一个可自动安装激活的Xposed恶意插件demo（需Root权限），以下是对此恶意插件的详细代码分析。

0x1 详细分析

安装开启该demo后在后台会自行安装Xposed，并勾选自身AutomaticXposed，之后自动重启系统使模块激活生效：

启动样本即进入Xposed的安装和激活：

检查是否安装了Xposed

首先检查是否安装过Xposed，若未安装则安装样本内嵌的Xposed。

静默安装Xposed插件

释放Xposed安装apk到sdcard：

获取su权限，通过pm来静默安装Xposed：

自动激活Xposed插件功能

启动Xposed的InstallService服务，通过Intent参数设置“Enable module”激活样本：

此服务原本实际上并不含有Xposed插件，属于作者重打包添加，所以此处demo的激活方式只适用于未安装Xposed的手机，若已安装则无法生效。

修改内嵌子包，添加InstallService激活插件并重启动系统

样本内嵌子包属于Xposed框架的安装包，但作者修改过，添加了一个InstallService用来激活插件以及重启动系统。

包结构主要差异对比，左为原版Xposed框架安装包，右为样本内嵌Xposed：

作者修改过的XposedInstall添加了InstallService，并使其导出以至于可以被外部调用：

服务运行之后首先检查手机系统版本和Xposed版本的兼容性，之后则设置勾选插件、重启系统激活插件：

复现原版Xposed的正常启动流程，因是样本直接激活没有通过正常的Xposed启动，故需如此：

调用原版ModuleUtil类的setModuleEnabled方法。修改Xposed配置文件，设置插件可用：

配置文件位于：/data/data/de.robv.android.xposed.installer/shared_prefs/enabled_modules.xml，将样本包名com.mindmac.xposed置值为1：

原版ModuleUtil类的updateModulesList方法 给/data/data/de.robv.android.xposed.installer/conf/modules.list文件写入样本完整路径：

配置完成之后，重启系统以便使设置生效：

0x2 总结

该样本虽然只是一个demo，但实现了自动安装Xposed及其插件，并自动勾选重启激活插件的功能。但若被恶意代码利用，可能会导致更严重的损害，请谨慎使用。

不过该样本目前只适用于未安装Xposed的手机，已经安装Xposed后则无法激活，而且内嵌的Xposed属于重打包需要另外添加模块。如果已经安装了Xposed，在Root权限下通过修改Xposed的配置文件来进行激活会更合适。

最后感谢MindMac 对AVL Team的关心和帮助，用户可以使用AVL Pro对此类工具进行检测。

附：网友MindMac提供的demo来源：https://github.com/MindMac/XposedAutomation

​

iOS/Malware（一）wirelurker-iOS样本分析

（发布于安天官网 “破界”木马（WIRELURKER）综合分析报告，主要分析了其中iOS部分样本）

4.4         “破界”运行于iOS平台核心文件(sfbase.dylib)分析

1.         start启动apps应用程序后，该应用程序会将其文件中的sfbase.dylib以Cydia插件的形式运行。

2.         窃取隐私：sfbase.dylib通过MSHookMessageEx来hook sendEvent函数，用于获取UIWindow相关的数据，电话、短信、浏览器、移动储存挂载、搜索、系统偏好等。

3.         通过getPhoneUser将通信录数据库拷贝到tmp临时空间，再通过查询语句获取内容。

4.         通过getSMSUser将短信数据库拷贝到tmp临时空间，再通过查询语句获取内容，其中包括了iMessage信息。

5.         最后使用getLoaclInfo将获取到的本地信息调用uploadFromFile函数通过POST上传信息，地址为：www.comeinbaby.com/app/saveinfo.php。

6.         检查更新：sfbase.dylib通过CheckUpdate调用CheckUpdate2检查是否有新版本，下载到临时空间并释放CheckUpdate2函数会检测样本是否有版本更新，地址为：http://www.comeinbaby.com/app/getversion.php?v=%@&adid=%@，其中参数v值为getCurrentVersion数据，即版本号；参数adid值为sharedManager+advertisingIdentifier+UUIDString数据；目前该域名已经不可访问。

Android/Malware（一）2014Android恶意代码编年史

（2014年10月28日发在AVLTeam blog Android恶意代码编年史，原始文档实际包含了每一个样本的详细情况，Android恶意代码数量太多，后续已经没再更新，不过倒是维护了一份iOS的版本，整理完后再发）

0x1 概述

目前Android 已然成为市场占有量最大的移动智能设备平台，同时也成为了移动恶意应用最大的温床，移动互联网的安全无疑已是当今主流安全威胁之一。相比传统PC恶意代码，移动恶意代码的发展更具有爆发性，各种开发技术、攻击技术和防御手段也在更加快速的迭代演变和发展。

统计2011年至今的移动恶意代码病毒库，可以看到 Android 平台下的恶意软件数量增长可谓极其迅速，年份间的数量差距几近鸿沟。从整个移动恶意代码病毒库中，可以发现不少具有典型恶意行为的手机应用软件，从它们身上可以观察到恶意软件发展的历程，以至于推测今后发展的趋势。

表1 Android恶意代码增长情况

0x2 Android恶意代码编年史

以下按照时间顺序总结近年来移动安全大事件和典型移动恶意代码。

从上述典型Android恶意代码可以看出，移动恶意代码的发展具有较强的爆发性。从时间线上来看，2010-2011年是其发展的开端，恶意代码数量还比较少，技术手段比较青涩；2012年则是过渡时期，恶意代码开始了对抗和漏洞利用；2013年至今则处在高速发展的爆发期，不论是在恶意代码的数量还是技术手段上，无一不在刷新着历史记录。

总结历史，我们可以观察到移动恶意代码发展的一些规律，希望能在技术手段、商业趋势等方面也做出一些基础判断，以帮助安全厂商能够建立更为强大的恶意代码对抗体系。

​