android毕设（3）

Android 通讯录demo

Android打开一个activity的方法

1、设置Intent

Intent intent =new Intent(当前Activity.this, 要打开的Activity.class);

2、通过startActivity打开activity

startActivity(intent);//打开新的activit

————————————————————————————————————————————————————————————

Android 联结魅族与必须豌豆荚公共使用

Win7的设置方法:

 

1.安装adb驱动，最简单的方法是用豌豆荚或91助手之类的，只要连上一次，就安装成功了.

2.打开“设备管理器”，找到里面的mx4设备(Android Composite ADB Interface)，右键属性，选“详细信息”标签，“属性”选“硬件ID”，下面会有两行值，

我的其中一行是 “USB\VID_2A45&PID_0C02&MI_01”

看到其中VID_XXXX了吧，把XXXX值记下来。

3.找到C:\Users\XXX\.android\adb_usb.ini文件（XXX是你的当前操作系统用户名），在里面另起一行追加“0xXXXX”（不含引号）。

前面的0x表示是16进制数，把后面的XXXX替换成上面你记下来的值。

重启电脑 或者 退出eclipse，再在任务管理器里把“adb”进程杀掉再重进eclipse。即可。

——————————————————————————————————————————————————————————————————————

第三章  静态污点分析原理

扫描其中所有的 Android系统发送数据的 API调用，这里就将搜索到第 124 行有系统发送短信的API 调用，且其发送的数据存储在寄存器v2 中。

然后向上追踪寄存器 v2，在 123 行中遇到算术指令且其结果赋值给 v2，所以需要切换追踪寄存器为v0、v1。继续向上追踪 v0、v1。 对于 v1，追踪到其来源于 122 行的常量赋值。 对于v0，追踪到 121 行的数据移动指令，表明该信息流来源于 120 行的 invoke指令。由于 invoke 指令将信息流变为非顺序型信息流，所以就需要查看之前控制流分析所得到的结果，得到其信息流的来源位于222 行的 v3。接着跳转到 222 行，并将追踪寄存器切换为 v3。向上追踪v3，在 221 行的数据移动指令发现 v3 来源于 220 行的 invoke 指令，而 invoke 指令所调用的函数为系统获取机器ID 的 API，所以此时就可以判断 v3 包含了敏感数据，也就是 124 行中调用系统发送短信的API 所发送的数据中有敏感数据（机器 ID）。 以上即为我们的第二版本的数据流分析算法，

它以寄存器为粒度进行追踪，而寄存器也是smali 代码中的最小粒度，所以相对于以函数为粒度的数据流分析算法来说，相当大的提高了精确度。但是，在对算法进行测试的时候发现，在某些情况下，该算法也无法追踪到寄存器数据的所有来源。例如：…

 

 

最下端开始向上追踪 v1寄存器，追踪到 115 行时表明 v1 来源于 114 行的 invoke 指令，

而该 invoke 指令为系统 API，不是我们查的获取敏感数据的 API，这就需要继续追踪该调用 API所使用的参数，也就是 v0, 所以此时就将追踪的寄存器转换为 v0。继续向上追踪 v0 时，由于 110行到 113 行的代码的目的寄存器都不是 v0，所以继续向上追踪 v0，直到 100 行，因为第 100行的目的寄存器正好是现在所追踪的寄存器 v0，所以得到 v0 的源头是 Ljava/lang/String Builder。 但是，我们观察源码时，可以发现 v0 中还包含 110 行中声明的字符串“Hello”，而此次追踪中并没有追踪到。 在对算法进行分析后，我们得出该方法未追踪到数据的原因如图  3-2 所示。

变量 v0 有三条分支对其进行操作，且这三条分支除了在起点交叉外其余点不交叉，那么在根据一条分支进行反方向数据流分析时，只会对这一条分支中产生的操作进行分析，而其他两条操作都不会追踪到。但因为其无法考虑到所有的分支，所以无法追踪到所有的数据。

根据对代码的分析，可以得出，第二个版本中的数据流追踪算法的多个处理分支都是由invoke 指令产生的，所以这里我们以invoke 指令为分割点，将 由简单追踪算法所产生的数据流分割为无数的小片段数据流。

寻找代码中的 Android 系统发送数据的 API 调用，找出它所发送的数据的寄存器，然后查找上一步所产生的无数小片段数据流，找出所有与此行代码相连的代码（不需要匹配寄存器），然后再接着寻找与刚才寻找出来的代码相连着的代码，如此循环下去，最后将所有连接的源头数据找出即是我们要追踪的数据的源头。

在以上代码中，我们得到的所有的分段数据流如表  3-3 所示。

 

 得到了表  中的数据后，我们查找代码中系统发送数据 API 的调用，可以查到在第 116 行有系统发送短信的API 调用，且发送的数据存储在寄存器v1 中,由此可得出需要追逐的数据为<116,  v1>。然后，查找分段数据流中所有包含<116, v1>的数据流，可以得出<116, v1, 114, v0>，从中取出<114, v0>，再在分段数据流中查找<114>，由此可以得到<114, v0, 100, v0>（注：<116, v1, 114, v0>之前已经分析，所以此处将不再分析）。此时，<100,  v0>即为数据流的一个源头Ljava/lang/String Builder;，但是此时还没有结束，还需接着查询包含<100>的数据流，得到<113, v0, 100, v0>和<111, v0, 100, v0>，继续查找包含<113>和<111>的数据流，得到<113, v1, 112, v1>和<111, v1, 110, v0>，此时，<112, v1>为数据流的一个源头“World”，而<110, v0>为数据流的另一个源头“Hello ”，此时，所有的片段数据流都已经查询完毕，且系统发送短信API 所发送的数据的源头也都已找到：Ljava/lang/String Builder;、“World”、  “Hello ”。