移动互联网终端主要有哪些(手机超级终端卸载方法)-昊阳知识网

一次性进群，长期免费索取教程，没有付费教程。

ID：Computer-network

一、移动终端安全概述

随着移动通信技术以及互联网技术的快速发展和相互融合，移动互联网发展迅速，移动智能终端在硬件、软件及带宽3个方面都得到了显著增强。移动互联网的快速发展为新移动应用的发展开辟了广阔空间，同时也带来了新的安全隐患。

移动互联网的安全问题主要存在3个方面：移动智能终端安全、网络安全和应用安全。用户通过移动智能终端使用移动业务，并将大量用户个人信息存储在移动设备中。因此，既要保证移动业务的安全，实现移动网络与移动智能终端之间的通信安全，同时还要保证用户个人信息的安全。由此可见，移动智能终端的安全对整个移动互联网的安全至关重要。本文简要介绍移动终端面临的安全风险，对Android、iOS平台的系统架构、安全机制、系统安全分析及安全防护措施重点介绍。

二、终端安全风险

1、系统漏洞

2、恶意软件

（2）隐私窃取：在用户不知情或未授权的情况下，获取涉及用户隐私的信息。

（3）远程控制：在用户不知情或未授权的情况下，接受远程控制端指令并进行相关操作。

（4）恶意传播：通过自动复制、感染、投递、下载等方式将自身、自身的衍生物或其他恶意代码扩散。

（6）系统破坏：通过感染、劫持、篡改、删除、终止进程等手段导致移动终端或其他非恶意软件的部分或全部功能、用户文件等无法正常使用，干扰、破坏、阻断移动通信网络、网络服务或其他合法业务正常运行。

（7）诱骗欺诈：通过伪造、篡改、劫持短信、彩信、邮件、通信录、通话记录、收藏夹、桌面等方式诱骗用户。

（8）流氓行为：对系统没有直接损害，也不对用户隐私、资费造成侵害的恶意行为。

三、Android平台安全

1、Android系统架构

Android采用层次化系统架构，官方公布的标准架构如图1所示。Android由底层往上分为4个主要功能层，分别是Linux内核层（Linux Kernel）、系统运行库层（Libraries和Android Runtime）、应用程序框架层（Application Framework）和应用程序层（Applications）。

图1 Android系统架构

（1）Linux内核层

Android以Linux操作系统内核为基础，借助Linux内核服务实现硬件设备驱动、进程和内存管理、网络协议栈、电源管理、无线通信等核心系统功能。

Android内核对Linux内核进行了增强，增加了一些面向移动计算的特有功能。例如，低内存管理器LMK（Low Memory Killer）、匿名共享内存（Ashmen），以及轻量级的进程间通信Binder机制等。这些内核的增强使Android在继承Linux内核安全机制的同时，进一步提升了内存管理、进程间通信等方面的安全性。

（2）系统运行库层

位于Linux内核层之上的系统运行库层是应用程序框架层的支撑，为Android系统中的各个组件提供服务。系统运行库层由系统类库和Android运行时构成。系统库大部分由C/C 编写，所提供的功能通过Android应用程序框架为开发者所使用。Android运行时又包含核心库和Dalvik虚拟机两部分。核心库提供了Java5 se API的多数功能，并提供Android的核心API，如android.os、android.net、android.media等；Dalvik虚拟机是基于Apache的Java虚拟机，被改进以适应低内存、低处理器速度的移动设备环境，Dalvik虚拟机依赖于Linux内核，实现进程隔离与线程调度管理、安全和异常管理、垃圾回收等重要功能。

（3）应用程序框架层

应用程序框架层提供开发Android应用程序所需的一系列类库，使开发人员可以进行快速的应用程序开发。

（4）应用程序层

2、Android安全机制的组成

（1）进程沙箱

Android扩展了Linux内核安全模型的用户与权限机制，将多用户操作系统的用户隔离机制巧妙地移植为应用程序隔离。在Linux中，一个用户标识（UID）识别一个给定用户；在Android上，一个UID则识别一个应用程序。在安装应用程序时向其分配UID。应用程序在设备上存续期间内，其UID保持不变。权限用于允许或限制应用程序对设备资源的访问。不同的应用程序分别属于不同的用户，因此，应用程序运行于自己独立的进程空间，与UID不同的应用程序自然形成资源隔离，如此便形成了一个操作系统级别的应用程序“沙箱”，如图2所示。

图2 Android应用程序沙箱机制

（2）权限模型

Android要求用户在使用API时进行申明，称为permission。这样对一些敏感API的使用在安装时就可以给用户风险提示，由用户确定是否安装。申明在Android Manifest.xml文件里面进行设置。一些最常用的权限许可如下：

READ_CONTACTS：读用户通信录数据；

RECEIVE_SMS：测试是否收到短信；

ACCESS_COARSE_LOCATION：通过基站或Wi-Fi获取到位置信息；

ACCESS_FINE_LOCATION：通过GPS来获取到更精准的位置信息。

Permission通过protection Level分4个等级：normal、dangerous、signature、signatureorsystem。不同的保护级别代表程序要使用此权限时的认证方式，normal 的权限只要申请就可以使用；dangerous的权限在安装时需要用户确认才可以使用；signature权限可以让应用程序不弹出确认提示；signatureorsystem的权限需要开发者的应用和系统使用同一个数字证书。

（3）系统分区及加载

Android设备的分区包括系统分区、数据分区及SD卡分区等。

①系统分区

系统分区通常加载为只读分区，包含操作系统内核、系统函数库、实时运行框架、应用框架与系统应用程序等，由OEM厂商在出厂时植入，外界无法更改。/system/app 目录存放系统自带应用程序 APK；/system/lib 目录存放系统库文件；/system/framework 目录存放Android系统应用框架的.jar文件。

②数据分区

数据分区用于存储各类用户数据与应用程序。一般需要对数据分区设定容量限额，并且防止黑客向数据分区非法写入数据，或者防止创建非法文件对数据分区进行恶意破坏。/data/data目录存放的是所有APK程序数据，每个APK对应自己的Data目录，即在/data/data目录下有一个与Package名字一样的目录，APK只能在此目录下操作，不能访问其他APK的目录；/data/app 目录存放用户安装的 APK；/data/system目录存有 packages.xml、packages.list和appwidgets.xml等文件，记录安装的软件及Widget信息等；/data/misc 目录保存Wi-Fi账号与VPN设置等。

③SD分区

SD卡是外置设备，可以从其他计算机系统上进行操作，完全不受Android系统控制。

（4）应用程序签名

Android 操作系统的代码签名采用自签名机制，是一种适度安全策略的体现，在某程度上保证了软件的溯源目标及完整性保护。但程序签名只是为了声明该程序是由哪个公司或个人发布的。不需权威机构签名和审核，完全由用户自行判断是否信任该程序。API按照功能划分为多个不同的能力集，应用程序要明确声明使用的能力。应用程序在安装时提示用户所使用到的能力，用户确认后安装。

APK安装时的验证过程如下：计算CERT.sf文件的散列值；用公钥（证书）验证CERT.rsa文件，得到结果和上面的CERT.sf的散列值进行比较，如果相同，则表明CERT.sf文件是未被篡改的；由于 CERT.sf 文件包含了 APK 包中 MANIFEST.MF 文件中的散列值，而MANIFEST.MF包含了APK中其他文件的散列值，因此从CERT.sf文件可以得到其他文件的正确散列值；最后，验证MANIFEST.MF中列出的APK包中的其他文件和其对应的散列值是不是同一值，从而判断APK包的完整性。

3、系统安全分析

（1）Linux内核安全分析

Linux内核决定着Android系统的性能，为Android系统提供核心系统服务，如安全性、内存管理、进程管理、网络协议等。与其他操作系统相比，Android系统存在的安全性缺陷并不显著，且Android在标准Linux内核的基础上，还进行了很多有益的扩展，如Ashmen机制、Low Memory Killer机制等。Ashmem 解决了 POSIX Shmem 释放共享内存的问题， Low Memory Killer则实现强制释放内存。这些内核增强都在不同程度上极大地提升了Android系统的安全性。

（2）系统库安全分析

Android系统库是应用程序框架的支撑，是连接应用程序框架层与Linux内核层的重要纽带，主要包括Surface Manager、多媒体库、SQLite、Open Gl|ES、Web Kit等。

Android提供了一些可供原生进程使用的原生库，从安全性的角度来看，原生库用C/C 编写，不属于类型安全，比Java代码更容易出错。原生库代码缺乏安全保障，其资源主要来自一些已过时的、易受攻击的移植库版本，比如 SQLite、Web Kit 等。使用原生代码具有风险，因为它们已脱离了虚拟机提供的防御层。

（3）虚拟机安全分析

Android的Dalvik虚拟机是Android中Java程序的运行基础。每一个Android应用程序在底层都会对应一个独立的Dalvik虚拟机实例，其代码在虚拟机的解释下得以执行。

Dalvik的安全对系统安全起关键性作用，直接影响到所有的应用程序。Dalvik中的.dex文件是一个潜在的攻击点，因为它很有可能被恶意篡改。在安装应用程序以及加载.dex文件到内存时都会对.dex文件进行错误检查，当错误检查失败时，还可使用一些可以显示的“断言”语句用于记录信息。然而，“断言”语句仅为开发和测试所用，无法阻止恶意改动文件的行为。由于Dalvik的字节码没有执行Java的类型安全，这样也会为攻击者提供编译不安全代码的机会，替代原有代码，转换为.dex字节码，从而执行危险的字节码，导致应用程序崩溃或执行任意代码。

4、Android应用安全分析

（1）应用权限分析

用户往往无法鉴别哪些是潜在危险的软件，很可能会下载不安全的软件。目前，有的恶意软件通过访问Internet就能很容易读到存储在设备上的重要信息，比如短信、通信录、位置信息等，并且在用户毫无察觉的情况下访问或盗取私有信息。

应用权限机制虽然为系统和应用程序提供了一定的安全保障，比如在manifest文件中为应用程序设定权限、应用程序签名等，尽可能地为应用程序提供安全保障。但是，仍然不可避免地存在滥用权限机制的问题。

比如，共享用户ID的特性就存在着安全隐患，一旦应用程序声明了一个共享用户ID，在其运行时，每一个共享这个用户ID的应用程序都会被授予一组相同的权限，它们之间可以互相访问资源。这样一来，攻击者就有可能利用共享用户ID进行恶意攻击。假如一个应用程序具备访问Internet功能，另一个应用程序实现访问联系人名单的功能，如果这2个应用程序共享用户ID，运行在同一个进程，它们都同时具备了读取联系人信息和通过Internet传输数据的2种功能，那么攻击者可能会利用这2个应用程序，轻松地通过Internet获取联系人信息。

（2）应用程序安装

Android应用程序以.apk文件形式在设备上进行部署。.apk文件是一个包括.dex文件的归档文件，不含有源代码。软件包管理器为安装进程提供服务，检查.apk的正确性。检查方式包括但不局限于验证数字签名、共享用户ID的合法性、权限要求及验证.dex文件。但是由于Android采用对应用程序签名的形式，有开发者自签名，没有经过权威认证机构的鉴定，所以，无法对开发者身份进行验证，也无法验证.apk的完整性。

Android系统上安装设备的方式也直接影响到应用程序的安全性。.apk文件有3种安装方式，它们的区别在于是否与软件包管理器或安装程序包直接交互。第一种方式是通过Android的adb调试桥安装，安装过程直接由软件包管理器执行，没有与任何用户交互，自动授予应用程序正常级别和危险级别的权限，由于缺乏用户的交互，这种安装方式具有较高安全风险。其余的2种方式分别是从应用商店安装、从SD卡上的.apk文件进行安装，直接与软件包管理器交互。

（3）数据库安全分析

目前，主流的数据库都采用了各种安全措施，主要包括用户认证、访问控制、数据加密存储和审计等措施。Android采用了开源的SQLite。

为了满足嵌入式系统对数据库本身的轻便型，以及对数据库存储效率、访问速度、内存占用率等性能的要求，SQLite采用不同于大型数据库的实现机制，但这同时带来了潜在的安全隐患。数据库没有用户管理、访问控制和授权机制，凡是操作系统的合法用户，只要该用户对文件具有读写权限，就可以直接访问数据库文件。开源SQLite数据库不提供加密机制，因此，不提供数据级的保密性。Android系统在使用过程中很有可能遭受到SQL注入攻击。对于数据库查询，如果开发者采用字符串连接方式构造SQL语句，就会产生SQL注入。

（4）软件更新安全分析

Android 系统软件更新是一种普遍采用的安全机制，能对系统的缺陷进行及时更改，一般采用Internet在线更新的方式完成。可以经用户确认后采用阶段性地通过HTTP向服务器发送查询语句的方式进行在线更新，或者通过SD上的更新包进行升级。

在Android系统的在线升级软件更新方式中，更新文件分两步进行验证：第一步，在下载阶段使用设备的公钥进行验证；第二步，使用通过代码映射在可执行文件中的辅助公钥作为修复工具来验证。Android系统不会安装未经密钥验证的更新软件包，因此，Android软件更新机制的设计是完善而且安全的。

四、iOS平台安全

1、i OS平台系统架构

iOS操作系统的层次架构分为4层，从上到下依次为：Cocoa Touch Layer（触摸UI层）、Media Layer（媒体层）、Core Services Layer（核心服务层）、Core OS Layer（核心OS层）。

低层次框架提供i OS的基本服务和技术，高层次框架建立在低层次框架之上，用来提供更加复杂的服务和技术，较高级的框架向较低级的结构提供面向对象的抽象。

Foundation和 UIKit框架是应用编程用到的2个主要的框架，能够满足大多数应用程序的开发需求。

UIKit框架提供的类，用于创建基于触摸的用户界面。所有iOS应用程序都是基于 UIKit，没有这个框架，就无法交付应用程序。UIKit提供应用程序的基础架构，用于在屏幕上绘图、处理事件，以及创建通用用户界面及其中元素。UIKit还通过管理屏幕上显示的内容来组织应用程序。

Foundation框架为所有应用程序提供基本的系统服务。应用程序以及UIKit和其他框架，都是建立在Foundation框架的基础结构之上。Foundation框架提供许多基本的对象类和数据类型，使其成为应用程序开发的基础。它还制定了一些约定（如用于取消分配等任务），使代码更加一致，可复用性更好。

整个框架架构如图3所示。

图3 i OS系统架构

（1）Cocoa Touch Layer

Cocoa Touch Layer包含创建iOS应用的关键框架。该层包含的框架定义应用的外观，也提供基本的应用基础和关键的技术支持，如多任务、触摸输入、推送通知和许多其他的高级系统服务。在开发应用时，应当首先研究该层的技术，并看技术是否能够满足需要。

（2）Media Layer

媒体层包含在应用中实现多媒体体验的图形、声音、视频技术和框架。使用这层的技术可以更容易建立好看和好听的应用。

（3）Core Services Layer

Core Services Layer包含应用需要的基础系统服务。这些服务中的核心是Core Foundation和Foundation框架，定义了所有应用使用的基本类型。该层也包含独立的技术来支持一些其他功能，如位置、i Cloud、社交媒体和网络。

（4）Core OS Layer

Core OS Layer是用Free BSD和Mach改写的Darwin，是开源的、符合POSIX标准的一个Unix核心。这一层包含或者说提供整个iOS的一些基础功能，比如硬件驱动、内存管理、程序管理、线程管理（POSIX）、文件系统、网络（BSD Socket）,以及标准输入输出等，所有这些功能都会通过C语言的API来提供。另外，值得一提的是，这一层最具有Unix色彩，如果需要把Unix上所开发的程序移植到iOS上，多半都会使用到Core OS的API。

核心OS层的驱动也提供了硬件和系统框架之间的接口。然而，出于安全考虑，只有有限的系统框架类能访问内核和驱动。

2、iOS安全架构

如图4所示i OS的安全架构包含3个部分：硬件层安全、操作系统层安全、应用层安全。

图4 i OS安全架构

（1）硬件层安全

硬件加密：硬件芯片内嵌加密引擎，实现全磁盘加密、指纹加密、文件加密；

安全存储：实现对与硬件关联的UID、GID等信息的安全存储，无法直接被软件和固件读取。

（2）操作系统层安全

系统完整性保护：验证启动过程每一步中的签名组件，实现安全启动链；

Secure Enclave：提供Data Protection密钥管理所需的加密算法，并维护Data Protection的完整性；

Secure Element：服从电子支付的金融业需求，服务于Apple Pay；

Touch ID：指纹感测系统，使对设备的安全访问更便捷。

（3）应用层安全

代码签名：验证代码完整性和追溯开发者；

运行时进程安全：应用间通过沙箱实现垂直隔离，应用与OS间实现横向隔离，保护运行时进程安全；

应用扩展：通过提供扩展来向其他应用程序提供功能；

应用程序组：实现同一个开发者账户拥有的应用程序和扩展共享内容；

应用中的数据保护：为开发者提供Data Protection的API，提高应用的安全性；

配件：只有授权的配件（如蓝牙、外接键盘等）才能访问设备。

3、i OS安全机制的组成

（1）代码签名

Apple需要所有开发人员对自己的i OS应用程序使用数字签名技术。这个签名用来标识应用程序的开发者以及保证应用程序在签名之后不被更改和损害。要获得i OS开发的签名证书，可以使用Keychain Access工具中的证书代理（Certificate Assistant）来创建一个证书签名请求（CSR）。当请求被核实后，就可以下载证书并安装使用。整个流程和Symbian完全一样，只不过提供开发证书方不是第三方而是苹果公司。

苹果开发者计划分为标准开发计划、企业开发计划。如果开发者希望在APP Store发布应用程序，则可以加入i OS开发者标准计划。如果开发者希望创建部署于公司内部的应用，并且其公司雇员不少于500人，则可以加入i OS开发者企业计划。

苹果给用户提供两类证书：Developer Certificate，主要用户本机测试；Distribution Certificate，主要用于2种场景，Ad-hoc和APP Store，其中，Ad-hoc用于广泛的测试和共享，限定100台设备以内；APP Store用于发布应用程序。

（2）运行时安全

通过沙箱机制，将应用与其他应用、操作系统进行隔离，从而实现运行时进程安全。每个应用在安装时都被分配一个独立的文件夹，应用间或应用与系统间都无法直接互相访问彼此的资源。由于沙箱的限制，第三方杀毒、加密软件无法访问其他应用和操作系统资源，而只能保护软件自己的运行环境，因此，i OS上没有可用的第三方安全产品。沙箱机制与应用扩展技术配合，对外提供有限的接口，实现应用间资源的安全共享。

运行时进程安全分为纵向隔离和横向隔离。

纵向隔离：应用间无法访问彼此的文件，只能使用i OS提供的服务访问自己文件夹以外的信息，以防止恶意应用搜集或篡改存储在其他应用中的信息。

横向隔离：系统文件和资源对用户级的应用是屏蔽的，整个OS分区是只读的，从而无法安装kernel模式的恶意软件。

（3）设备口令

通过设备口令进行保护，防止手机丢失后信息被泄露。

（4）设备和程序控制

可以由用户配置哪些信息可以被应用程序访问。用户可以配置是否可以使用Safari浏览器、安全应用软件、使用摄像头以及位置等信息，如果禁用这些信息，使用时就会弹出错误信息。

（5）安全存储

iOS的安全存储主要包括三部分，首先是可以使用iOS4 CDSA结构中提到的Apple File DL Module提供对文件的加密；其次是对设备数据如邮件等的加密；最后是通过启用设备口令产生和保护密钥。

iOS可以对通过iTune备份到PC上的数据进行加密。

（6）远程销毁

远程数据销毁，可以远程清除终端上的数据，用于手机丢失后进行远程数据销毁。