CN104506639A - 一种获取Root权限的方法及装置 - Google Patents
一种获取Root权限的方法及装置 Download PDFInfo
- Publication number
- CN104506639A CN104506639A CN201410838606.2A CN201410838606A CN104506639A CN 104506639 A CN104506639 A CN 104506639A CN 201410838606 A CN201410838606 A CN 201410838606A CN 104506639 A CN104506639 A CN 104506639A
- Authority
- CN
- China
- Prior art keywords
- mobile terminal
- file
- root authority
- executable file
- recovery
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Stored Programmes (AREA)
Abstract
本发明提供一种获取Root权限的方法及装置,具体步骤为:启动移动终端的相应刷机模式;向该启动刷机模式的移动终端写入用于获取系统最高权限的可执行文件;重启所述移动终端以用于获取系统Root权限。相应的,本发明还提供一种获取Root权限的装置。本发明不仅适用于多种品牌机型的提权,对较难Root的机型也能够获取Root权限。
Description
技术领域
本发明涉及移动终端的提权,具体而言,本发明涉及一种获取Root权限的方法及装置。
背景技术
众所周知,Root权限是指Unix类操作系统(包括Linux和Android)的系统管理员权限,类似于Windows系统中的Administrator(管理员)权限;Root权限可以访问和修改用户的移动设备中几乎所有的文件(Android系统文件及用户文件)。但是,由于目前移动终端系统对于Root权限的管理非常严格,通常情况下多数应用或程序都不具备Root权限,因此对于某些需要具备Root权限的操作就无法执行,例如安装或卸载应用等操作;同时,此类操作调用进程每次执行相应操作时都需要向系统申请Root权限,但如果此时其他应用进程正在使用Root权限进行相关操作,则此调用进程的Root权限申请便无法成功;更甚者,如果用户在系统中设置了禁用Root权限的操作,则相关调用进程便无法进行相关操作。
通常移动终端用户都想获取其终端系统更广泛的控制权,鉴于此,业内提供了各种提权方案用于获取Android系统的Root权限,实现用户权限提升,达到全面控制操作系统的目的。
提权方案通常是基于系统的漏洞注入相应的提权可执行文件,但是对于刚入市场还没有发现漏洞的机型,一般的提权方法难以获取移动终端的Root权限,本发明提供的获取Root权限的方法不仅可以实现市场上多种品牌的机型提权,对于上述难以Root的机型,也可以较方便地获取Root权限。
发明内容
本发明的目的旨在解决不同厂商的机型获取Root权限的问题,以及较难通过常用提权方法获取Root权限的机型提权的问题。
为了实现上述目的,本发明提供一种获取Root权限的方法,所述方法包括以下步骤:
启动移动终端的相应刷机模式;
向该启动刷机模式的移动终端写入用于获取系统最高权限的可执行文件;
重启所述移动终端以用于获取系统Root权限。
进一步的,该方法还包括PC端向云端服务器发送特征信息请求获取与移动终端匹配的recovery文件。
具体的,所述特征信息具体指所述移动终端的包括机型、CPU型号、系统版本号、内核版本号中的一种或任意多种。
优选的,所述用于获取系统最高权限的可执行文件通过recovery镜像文件或cache镜像文件写入系统的system分区。
优选的,所述用于获取系统最高权限的可执行文件为su可执行文件或su可执行文件的OTA差分包。
一种获取Root权限的装置,包括:
刷机模式启动模块:用于启动移动终端的相应刷机模式;
可执行文件写入模块:用于将获取系统最高权限的可执行文件写入移动终端;
重启模块:重启所述移动终端以用于获取系统Root权限。
进一步的,所述装置还包括执行模块,用于执行写入移动终端的可执行文件,获取Root权限。
进一步的,所述装置还包括PC端请求模块,用于PC端向云端服务器发送特征信息请求获取与移动终端匹配的用于获取系统最高权限的recovery文件。
进一步的,所述装置还包括云端服务器,用于向PC端推送与移动终端匹配的用于获取系统最高权限的recovery文件。
优选的,所述可执行文件写入模块的可执行文件为su可执行文件或su可执行文件的OTA差分包。
相比现有技术,本发明的方案具有以下优点:
1.本发明采用刷机方式实现移动终端的Root权限获取,通过启动刷机模式将用于获取系统最高权限的可执行文件写入系统,不仅可以实现多种品牌机型的Root权限,对一些采用常用提权方法难以Root的机制也可以获取Root权限。
2.本发明写入移动终端的可执行文件可以是OTA差分包形式,通过启动其特定刷机模式写入系统可执行文件差分包,可以实现三星移动终端的提取。
3.本发明仅仅将用于提权的可执行文件或可执行文件的OTA差分包写入系统的system分区,无需对系统的ROM进行重写,可以减小系统刷机带来风险的同时实现Root提权。
4.本发明进行提取的可执行文件或可执行文件差分包由PC端向云端服务器请求获取,云端服务器推送与PC端发送的特征信息匹配的可执行文件或可执行文件差量包,进一步提高Root权限提取的成功率。
本发明附加的方面和优点将在下面的描述中部分给出,这些将从下面的描述中变得明显,或通过本发明的实践了解到。
附图说明
本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解,其中:
图1为一种获取Root权限的方法流程图
图2为一种查杀病毒的方法流程图
图3为一种获取Root权限的装置原理框图
具体实施方式
下面详细描述本发明的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,仅用于解释本发明,而不能解释为对本发明的限制。
本技术领域技术人员可以理解,除非特意声明,这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是,本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件,但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解,当我们称元件被“连接”或“耦接”到另一元件时,它可以直接连接或耦接到其他元件,或者也可以存在中间元件。此外,这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
本技术领域技术人员可以理解,除非另外定义,这里使用的所有术语(包括技术术语和科学术语),具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是,诸如通用字典中定义的那些术语,应该被理解为具有与现有技术的上下文中的意义一致的意义,并且除非像这里一样被特定定义,否则不会用理想化或过于正式的含义来解释。
本技术领域技术人员可以理解,这里所使用的“终端”、“终端设备”既包括无线信号接收器的设备,其仅具备无发射能力的无线信号接收器的设备,又包括接收和发射硬件的设备,其具有能够在双向通信链路上,执行双向通信的接收和发射硬件的设备。这种设备可以包括:蜂窝或其他通信设备,其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备;PCS(Personal Communications Service,个人通信系统),其可以组合语音、数据处理、传真和/或数据通信能力;PDA(PersonalDigital Assistant,个人数字助理),其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或GPS(Global PositioningSystem,全球定位系统)接收器;常规膝上型和/或掌上型计算机或其他设备,其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“终端”、“终端设备”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的,或者适合于和/或配置为在本地运行,和/或以分布形式,运行在地球和/或空间的任何其他位置运行。这里所使用的“终端”、“终端设备”还可以是通信终端、上网终端、音乐/视频播放终端,例如可以是PDA、MID(Mobile Internet Device,移动互联网设备)和/或具有音乐/视频播放功能的移动电话,也可以是智能电视、机顶盒等设备。
本技术领域技术人员可以理解,这里所使用的远端网络设备,其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云。在此,云由基于云计算(Cloud Computing)的大量计算机或网络服务器构成,其中,云计算是分布式计算的一种,由一群松散耦合的计算机集组成的一个超级虚拟计算机。本发明的实施例中,远端网络设备、终端设备与WNS服务器之间可通过任何通信方式实现通信,包括但不限于,基于3GPP、LTE、WIMAX的移动通信、基于TCP/IP、UDP协议的计算机网络通信以及基于蓝牙、红外传输标准的近距无线传输方式。
随着移动互联网的发展,移动终端已经成为不可或缺的部分。由于Android系统的开源性,使得Android系统的移动终端用户越来越多,为了充分利用系统权限,提升用户体验,需要获取系统的Root权限。获取Root权限后至少可以做以下任一种操作:备份系统,修改系统内部程序,将应用程序安装到SD卡,获取文件目录,静默安装应用程序,卸载应用程序以及卸载系统预装应用程序等。
涉及Root提权操作的技术原理,也已在背景技术部分介绍,Root的过程其实就是把su文件放到/system/bin/中,把Superuser.apk放到system/app下面,前者用于监听用户的权限请求并与后者通信,后者主要是在与前者通信的基础上实现人机交互,从而允许用户做出相关指示。理论上,如果su可以实现为可以默认通过所有权限请求,则SuperUser.apk甚至可以舍弃。此外还需要设置/system/bin/su可以让任意用户可运行,使其具有有set uid和set gid的权限,具体可通过在android机器上运行命令:adb shell chmod 4755/system/bin/su便可实现。当然,也不排除本领域技术人员利用操作系统的变化例如其新版本或者经人为修改的出厂设定等,而使得破解机制有所变化。然而,不管这些破解机制如何变化,破解过程中所涉的数据,无非借助代码文件及运行这些文件之类的配置参数形成新的破解方案,本领域技术人员完全可以理解,这些破解方案可以被整合并概括为本发明的用于获取Root权限的方案文件。因此,对本发明方案文件的理解,应理解为涵盖所有能够用于获取具有权限管理功能的操作系统的最高权限的破解手段相关的代码文件及其配置参数,以及这些代码文件和配置参数的整合体,而不仅仅局限于上述以“su”、“SuperUser.apk”命名或实现的个别文件。任何最小化解释本发明的方案文件的企图均应被视为未超脱本发明的实质范围。
如前所述,本发明所采用的概念“配置信息”,可以仅指前述用于获取Root权限的方案文件,也可以是在Root方案文件的基础上,进一步结合相关运行参数配置而得,还可以是仅包含所述方案文件的指向信息如其URL或文件名的数据,不管配置信息的实现形式如何,只要该配置信息能够被使用它的用于实施Root提权操作的程序(进程)对应正确解析正常使用即可。应当知晓,当配置信息包含的是指向信息的文件名时,应当从本机中获取相应的方案文件,当是指向信息的链接时,应当利用相应的URL从远程下载方案文件适用之。也就是说,配置信息的格式,完全可以由本领域技术人员在进程软件实现时,依照一定的协议进行规定,只要在使用的过程中,遵守同一协议进行正向或反向的对应处理即可。利用好这些配置信息,便能更高效地实现系统提权。
Root提权方案,依提权后权限作用的生命周期来看,包括永久Root权限和临时Root权限,顾名思义,获取永久Root权限的应用程序一旦获取Root权限,以后无需再进行Root提权;而临时Root权限的生命周期只是操作系统的一次从开机到关机的过程,下次开机需要再次进行Root。本发明提供的方案是通过刷机方式实现手机终端的永久Root。
为了获取移动终端的永久Root权限,本发明提供一种获取Root权限的方法,请参见图1,以Android系统智能手机作为具体实施例一进行说明,其原理描述如下:
S11、启动移动终端的相应刷机模式
通常情况下,常用刷机模式主要有以下两种:
1、Recovery刷机模式
Recovery是一个刷机的工厂界面,在recovery模式下,用户可以安装系统、清空数据、备份系统、恢复系统等。刷入recovery相当于给设备安装了一个dos。Recovery是一个微型系统,可以对手机的各个分区进行擦除和写入。我们常说的recovery模式下的刷机就类比于电脑ghost装机。Recovery模式下的刷机是卡刷,将刷入的ROM包放到SD卡的根目录下,然后通过手机的组合键进入recovery模式就可以实现刷机。
2、Fastboot刷机模式
Fastboot模式是Google的官方模式,是Android系统的一个特殊工程模式,通过Fastboot界面连接PC段,可以在PC端通过特殊指令操作手机。Fastboot模式下的刷机是线刷,需要先在PC端安装Fastboot工具,通过数据线连接手机端,输入指令控制手机实现相应操作。Fastboot相比recovery实现的是更底层的操作,级别比recovery高,当内核损坏不能通过recovery刷机时,仍然可以用Fastboot实现刷机,通过Fastboot模式刷机更加灵活,功能也更强大。
本发明采用手机终端更底层的fastboot刷机模式,启动该刷机模式的具体实施方式为:安装ADB(Android Debug Bridge)工具到PC端,其中ADB工具是Android提供的一个通过调试工具,也就是Debug工具,借助这个工具可以管理设备或手机的模拟器状态。将手机通过USB数据线连接到PC端,ADB工具界面输入“adb reboot bootloader”命令启动手机到fastboot刷机模式。
当然也可以采用组合按键的方式,手机在锁屏模式下按下相应的组合按键进入fastboot模式,不同厂商生产的手机进入fastboot模式的组合按键不同,例如部分手机通过按下音量减小键和电源键进入fastboot模式。
手机终端成功启动到odin模式后,手机界面会显示相应的提示信息。
S12、向该启动刷机模式的移动终端写入用于获取系统最高权限的可执行文件
Android系统启动时,首先会进行硬件自检之类的操作,接着会检查当前手机按键的状态,如果此时按键状态处于某种刷机模式,如recovery模式,那么系统会调用ROM里的recovery程序,验证完刷机包的完整性和数字签名的合法性,由recovery程序将刷机包解压并将相应文件写入ROM中替换ROM的原有文件,下次启动手机时,就会从ROM中载入替换过的文件,并利用这些文件启动和运行系统。故刷机的本质就是通过一定方法对ROM中文件的覆盖和替换,更改或替换手机中原本存在的一些语言、图片、软件或操作系统。而本发明中的刷机是对手机系统刷入获取最高权限的可执行文件而不是ROM包,由此获得系统的永久Root权限。
每部手机都有自带的recovery,但只能刷入由厂商签名的官方刷机包,如果采用版本不兼容的recovery刷机会刷坏手机,所以我们需要下载不同品牌手机相应的官方recovery,对其进行修改,加入执行Root权限的su可执行文件,当然要保证可以通过官方recovery的数字签名,得到修改后的官方recovery。
此处所述修改后的官方recovery具体指根据不同品牌手机下载官方recovery镜像文件,即recovery.img文件。其中镜像文件类似于zip压缩包,它将特定的一系列文件按照一定格式制作成单一文件,以便下载和使用。镜像文件无法直接使用,需要利用一些虚拟光驱工具进行解压后使用。
Android系统主要有六个分区:
1、boot分区
boot分区负责手机开机,包括内核和内存。没有这个分区设备将无法启动。仅在特别需要的情况下,才可以通过recovery擦除这个分区。并且,一旦擦除该分区,在安装一个包含boot分区的新系统前,设备不能被启动,以下表1揭示了镜像文件boot.img的组成结构:
boot header | 文件头信息 |
kernel | 内核 |
ramdisk | 内存(包括初始化系统所需的全部核心文件) |
second stage loader | 第二阶段装载(可选) |
表1 boot.img组成结构
2、recovery分区
recovery分区称为恢复区,被视为一种替代启动分区,保存简单的OS或底层软件,可以启动设备到一个recovery控制台上执行阈值的恢复和维护操作。
3、system分区
system分区包含整个操作系统,烧入了经过编译的system.img镜像文件,包括Android的用户界面以及所有预先安装在设备中的系统应用。擦除这个分区,将把Android系统从设备中删除,但设备仍然可以启动,仍然可以把手机放入恢复或引导模式安装新的ROM。
4、misc分区
misc分区用于保存设备的配置信息,如CID(Customer IDentity)、BCD(Bootloader Control Block)、USB和其他硬件设备配置信息,其中BCD主要用于存放recovery引导信息。
5、data分区
data分区也称为用户数据区,包含用户的数据,存放用户的联系人、短信、设置和应用程序等信息。擦除这个分区相当于恢复出厂设置,恢复到第一次启动设备的状态,或者最后一次执行系统升级的状态。
6、cache分区
cache分区也称为缓存区,存储系统频繁访问的数据和应用程序的组件,CPU调用和执行命令时会优先调用这里的数据。擦除cache分区不影响用户资料,只是去掉了现有的数据,系统会再自动生成。
为了获取手机系统Root权限,我们将recovery镜像文件(recovery.img)刷入手机系统的recovery区。其中,此处的recovery镜像文件是经修改加入包含获取系统最高权限的可执行文件,即包含su的root文件,该recovery.img是与手机版本相匹配的官方文件。所述修改后的recovery文件在云端服务器生成,PC端向云端服务器发送手机终端的包括机型、CPU型号、系统版本号、内核版本号中的一种或任意多种的特征信息,服务器根据特征信息匹配手机机型相应的可执行文件,将该可执行文件放入与该手机机型匹配的官方recovery镜像文件,PC端下载该匹配的修改recovery文件。
其中,上述的云端服务器保存有数据库,例如,云端服务器需要配置2个数据库:方案信息库和机型支持信息库。方案表中包含精确方案表(精准匹配)和通用方案表(所有机型匹配),机型记录表是学习型数据库,服务器通过客户端反馈的信息,对机型记录表进行实时更新。
云端服务器接受到客户端发送的请求(包含机型名称,CPU型号,Andriod版本)后,开始查询是否有方案匹配到该请求,并且向机型支持机型表中查询那些方案曾经支持过这个机型,最后把所有获取匹配的方案保存下来,根据特定的规则来排序,然后把排序好的方案统一的返回给客户端。让客户端按照顺序去一一执行。
上述通过fastboot模式将所述recovery镜像文件刷入系统recovery区,具体实施方法为:PC端安装fastboot模式工具,对已进入fastboot模式的手机通过fastboot工具输入fastboot命令“fastboot flash recoveryc:\recovery.img”并回车,将recovery镜像文件刷入系统,其中recovery镜像文件存放在电脑中的某个路径下,最好是短路径,此处假设直接将recovery镜像文件放入C盘下。需要注意的是recovery镜像文件的文件名必须是recovery.img,如果不是要重新命名为recovery.img。也可以通过输入命令“fastboot boot c:\recovery.img”启动recovery镜像文件,直接启动recovery程序中的相关指令将包含su的root文件写入到系统的system分区。
其中su是二进制文件或.so文件,Android系统原版的su中的部分代码如下所示:
由上述代码可以看出系统只允许myuid为AID_ROOT和AID_SHELL的进程使用su登录,如果将上述部分的su代码的限制去掉,则系统中的任何进程都可以使用su进行登录了,所以Root的执行文件都在su程序中。通过写入修改后的使系统中任何进程都有登录权限的su程序就可以实现Root提权。
S13、重启所述移动终端以用于获取系统Root权限
由上述可知,获取Android系统Root权限的本质是,在系统中加入一个任何用户都可以用于登录的su命令,或者替换掉系统中的su程序。系统中默认的su程序需要验证实际用户的权限,只有Root和shell用户才有权限运行系统默认的su程序,而破解后的su程序将不检查实际用户权限,这样普通用户也可以运行su程序,提升自己的权限。
将修改后的包含su等用于root的可执行文件的官方recovery镜像文件刷入手机系统的recovery分区,覆盖原有的recovery文件。启动手机到recovery模式,recovery程序会自动将root文件放入系统的system分区,重启手机到正常模式,系统自动执行su,从而获得手机Root权限。也可以通过命令“fastboot boot c:\recovery.img”直接启动recovery,系统执行recovery程序将包含su的root文件放入系统system分区,重启手机到正常模式,系统启动并执行su,实现root权限的获取,其中如果系统有自动重启到正常模式的机制,则可以通过该机制由系统自启动到正常模式;如果没有所述机制,则由PC端通过ADB工具发送指令启动系统到正常模式。
以Android系统的三星智能手机为具体实施例二对本发明提供的方法作进一步说明,详细方案描述如下:
S11、启动移动终端的相应刷机模式
由于刷入三星手机的文件包为tar格式,不同于通常刷入的zip格式文件包,所以本发明将三星手机启动到odin模式进行刷机。
odin模式是三星手机特有的刷机模式,具体启动方法为:手机通过USB数据线连接至PC端,通过安装于PC端的ADB工具,输入命令”adbdevices”确定手机正确连接,再输入命令”adb reboot download”将手机启动到odin模式。
除此之外,也可以采用组合按键的方法启动到odin模式,三星智能手机可以采用同时按下音量减小键、HOME键和电源键启动至odin模式。
手机终端成功启动到odin模式后,手机界面会显示相应的提示信息。
S12、向该启动刷机模式的移动终端写入用于获取系统最高权限的可执行文件
针对三星手机的odin模式,制作基于OTA的su差分包和recovery镜像文件,Android平台提供Google diff arithmetic差分机制,支持OTA差分包。
其中,OTA(Over-the-Air),即空中下载技术,通过移动通信(GSM或CDMA)的空中接口对SIM卡数据及应用进行远程管理的技术。基于C/S方式,服务器端为运营商的后台系统(客户中心、计费系统、应用服务器),客户端则是一块SIM卡。运营商的后台系统负责将服务请求发送给一个OTA网关,然后由这个OTA网关把这些服务请求转换成短信后发给一个短信服务中心(SMSC),最后由这个短信服务中心把它们传给服务区内的一个或多个SIM卡。SIM卡与OTA网关之间的通信通过互发短信实现,这就是所谓的短信通道。
OTA就是一项基于短消息的机制,通过该技术手机用户只要进行简单操作,就可以依照个人喜好把网络所提供的各种业务利用OTA机制下载到手机。OTA技术能用于参数配置、漏洞修补、估计更新和软件安装升级,最常用的功能就是手机获取推送信息升级系统,这样手机系统更新不用数据线就可以通过无线下载方式进行,就像PC通过互联网下载软件更新一样方便。很多Android厂商经常会有小修补型的改进,通常都是使用OTA的方式给用户提供升级。在手机需要进行升级或者更新功能的时候,通过主动获取或者对数据进行远程自动推送的方式,可以让用户通过无线下载方式更新手机系统,并且OTA升级方式将在升级完成后不会知道手机上的用户数据。
su的OTA差分包在云端服务器生成成,具体过程为:手机连接PC客户端,PC客户端向服务器发送手机终端的包括机型、CPU型号、系统版本号、内核版本号中的一种或任意多种的特征信息,服务端将该手机终端对应版本系统包与加入su的对应版本系统包作为生成差分包的原始包,分别命名为org.tar和ota.tar,编写一个脚本命令,例如/build/tools/releasetools/ota_from_target_files_n_i org.tar ota.tar updata.tar生成差分包,其中update.tar为生成的su的OTA差分包。
服务器将上述su的OTA差分包放入cache镜像文件,客户端从服务端下载修改后的recovery文件和包含su差分包的cache镜像文件,将cache.img和修改后的recovery.img通过odin模式写入系统。三星odin模式检测出cache分区有更新,会直接将手机启动到recovery模式,recovery程序解析cache.img镜像文件中的命令并执行,将cache.img中的su写入系统的system分区。
S13、重启所述移动终端以用于获取系统Root权限
su写入系统后,手机终端以正常模式启动,加载系统文件并执行写入的su,实现手机终端的Root提权,其中如果手机有自动重启到正常模式的机制,就可以通过该机制由系统自启动到正常模式;如果没有所述机制,则由PC端通过ADB工具发送指令启动系统到正常模式。
参看图2所示,在本发明实施例中,还提出了一种将上述的方法用于查杀顽固程序的应用场景中。
以Android为例,移动终端与PC机连接的方式如下:
(1)移动终端需要打开USB调试模式,以允许PC机对移动终端进行通信和控制。Android系统默认是关闭USB调试模式的,因此需要用户手动打开。优选地,可以增加一个用户引导,提示用户开启USB调试模式的的方法。
其中,每种类型的移动终端对于开启USB调试模式的方式不同,因此可以总结市面上的Android移动终端打开USB调试模式的方法,根据用户的机型进行提示。
(2)打开USB调试之后,使用数据线把移动终端连接到PC机上。PC中的查毒工具(例如急救箱)会枚举USB设备,并判断是否是移动终端设备,如果是,就试图通过socket与手机内部的ADB(Android DebugBridge,调试桥)Server进程通信,并完成移动终端与PC机的通信工作的初始化。
(3)初始化成功之后,查毒工具向移动终端中发送一个ELF或APK文件,并运行该ELF或APK文件,PC端的查毒工具即可通过该文件与移动终端进行通信,以完成对于恶意程序的查杀操作。
在完成PC机与移动终端的连接后,即可开始对于恶意程序的查杀流程。
首先执行步骤S201,获取移动终端的机型信息。
需要说明的是,移动终端的存储空间中设置有BOOT分区,其操作系统文件保存在BOOT分区中,并且操作系统文件以压缩包的形式保存在BOOT分区中。
在本实施例中,以安卓操作系统为例,则系统文件压缩包为boot.img。
例如,不死木马就是被写入到boot.img中。一般在操作系统启动时,会首先将boot.img解压缩,并释放到内存中,继而进行操作系统的启动,因此,现有的杀毒方式是不能清除不死木马的,在操作系统重启后,不死木马会再次被释放到移动终端的内存中。
在boot.img中,包括有两部分:内核kernel及根目录(initramdisk);其中,所述根目录下包含有服务目录及引导配置文件inti.rc,所述服务目录下包含有服务文件。其中,所述服务目录可包括有sbin目录。
一般的安卓操作系统的启动过程如下:
首先,接收到开机或重启触发指令后,以只读的方式加载引导分区中的所述boot.img。然后,通过所述boot.img的kernel读取所述根目录下的inti.rc中的配置信息,用以在操作系统启动时,指示操作系统中的程序执行什么操作,例如指示屏幕显示开机动画等。
其中,对于不同的移动终端,由于生产厂家不同、使用的操作系统不同,其BOOT分区的存储位置不同、系统文件压缩包boot.img的压缩格式也不同,因此,进行重新刷机必须先获取其机型信息以获知BOOT分区的存储位置。
在获取BOOT分区的位置时,还可以根据移动终端中的分区表获取其BOOT分区的位置。
其中,一般情况下,分区表位于移动终端的磁盘(存储空间)起始处的一个或者几个扇区内,只要读取这几个扇区,然后按照特定格式解析,就能得到分区表。不同格式的磁盘需要适配工作,很多厂商对于其移动终端的磁盘格式采取自定义的方式,另外也有小部分厂商使用MBR(MainBoot Record,主引导记录)和GPT(GUIDPartition Table,GUID磁碟分割表)格式的磁盘。
以安卓操作系统的启动为例进行说明,在移动终端加电后,其会首先加载CPU中的程序代码Bootloader,通过该代码,引导找到BOOT分区,并将BOOT分区中的系统文件boot.img读取到内存中,并将其中的kernel和ramdisk进行解压缩,首先运行其中的kernel文件,加载linux内核(安卓操作系统采用linux内核),在操作系统的内核启动后,运行ramdisk中的程序,进而完成整个操作系统的启动。
需要说明的是,分区表的存储位置以及磁盘的存储格式都是可以自定义的,所以不同手机和操作系统的分区表的位置是不同的,需要通过适配来完成。
在一般的情况下,移动终端可能存在多个分区,则可逐个分区进行查找,确定BOOT分区的位置。
移动终端的机型信息,可以包括有移动终端的品牌、操作系统的型号、内核版本号等,例如可以是:
华为P6、操作系统Emotion UI、内核版本安卓4.2.2;
魅族MX4、操作系统Flyme 4.0、内核版本安卓4.4.1。
在获取移动终端的机型信息后,执行步骤S202,根据该移动终端的机型信息获取该移动终端的BOOT分区的存储位置,以及boot.img的压缩格式。
其中,移动终端的生产厂家对其BOOT分区的位置的定义不同,主要是为了保护其操作系统不会被恶意修改。在本发明实施例中,可以通过适配的方法获取不同的机型信息的移动终端的BOOT分区的位置、boot.img的压缩格式,并保存到数据库中。
当需要得知移动终端的BOOT分区的位置和boot.img的压缩格式时,只需要通过机型信息在数据库中查询即可。
对于寻找BOOT分区的位置,以Google的Android手机Nexus为例进行说明,Nexus系统的手机在系统启动时会枚举设备,找到BOOT分区对应的设备,并在proc内存文件系统的/dev/blocks目录创建一个名为“BOOT”的符号链接,只要枚举/dev/blocks目录就可以得到boot分区对应的设备。
而对于获取boot.img的格式,仍以Google的Android手机Nexus为例,它的boot.img文件的格式在Android源码中是可以找到的,只要按照这个格式解析就可以了,其他一些厂商会自定义格式,需要适配。
接着,执行步骤S203。在步骤S203中,通过在步骤S202中得到的BOOT分区的位置读取得到boot.img,并根据其压缩格式进行解压缩,得到系统文件。
得到系统文件,也即需要得到kernel与initramdisk。在步骤S202中确定boot.img的格式之后,就可以解压读取到initramdisk。
本步骤S203仍以Google的Android手机Nexus手机为例,它的initramdisk是先用以cpio格式打包,然后再使用gzip格式压缩的,只要在程序中先按照gzip格式解压缩,然后再按照cpio格式解包就可以得到里面所有的文件,然后就可以进入下面步骤的查杀操作。
其中,其他手机的可能会存在XZ、LZMA、LZO等压缩格式,需要先判断是哪种压缩格式,然后再使用按照相应的格式进行解压。
在得到系统文件后,即进行恶意程序扫描的步骤,即执行步骤S204,扫描系统文件中是否存在预设的恶意程序特征,如果是,则执行步骤S205,如果不是,则执行步骤S206。
在本实施例中,扫描系统文件中是否存在预设的恶意程序特征,可以根据系统文件中用于记录启动项的配置文件,查找可自启动的程序的文件路径,提前这些文件路径中的每一个文件的文件特征值,判断是否存在与预设恶意文件特征值匹配的文件。此时,可以通过查询云安全服务器等方式获取文件的特征值等,从而判断是否存在恶意程序,等等。
其中,由于本发明实施例提供的方法需要通过刷机的方式对恶意程序进行彻底清除,为了避免刷机可能对用户数据造成损失,可以提示用户先对移动终端中的数据进行备份等。
本发明实施例上述的方法,可以用于查杀顽固的恶意程序,当移动终端中的文件保护有预设的恶意程序特征时,通过在PC上执行重刷操作系统分区的操作,能够彻底清除ROM病毒等寄存于操作系统分区中的恶意程序,解决了ROM病毒类的恶意程序不能彻底查杀的问题,保护了用户的数据财产安全,防止用户受到恶意程序的骚扰,可以防止恶意程序扣费,偷跑流量,弹出各种垃圾广告,窃取用户隐私,以及保证用户手机支付的安全等,对移动终端杀毒引擎无法正常查杀的恶意程序可以进行彻底的清除。
相应的,参见图3所示的原理框图,提供一种获取Root权限的装置,包括刷机模式启动模块11、可执行文件写入模块12、重启模块13、执行模块14,此外还包括PC端请求模块15以及云端服务器模块16。其中,
刷机模式启动模块11,用于启动移动终端的相应刷机模式。具体指通过fastboot模式进行刷机,即将手机切换至fastboot模式。具体方法为:手机通过USB数据线连接至PC端,通过PC端的ADB工具输入命令”adbdevices”确定手机正确连接,输入命令“adb reboot bootloader”将手机启动至fastboot模式,或输入命令”adb reboot download”将三星手机启动到odin模式,启动成功后手机界面会显示相应的启动成功提示。
可执行文件写入模块12,用于将获取系统最高权限的可执行文件写入移动终端。具体方法为:第一,可以通过fastboot工具输入命令“fastbootflash recovery c:\recovery.img”将包含su的修改后recovery镜像文件写入手机系统system分区;第二,可以直接启动包含su的修改后的recovery镜像文件,recovery程序将su文件写入手机系统的system分区。针对三星手机,将获取系统最高权限的可执行文件的OTA差分包放入cache.img镜像文件,cache.img和recovery.img通过odin模式写入系统。三星odin模式检测出cache分区有更新,会直接重启到recovery模式,recovery程序解析cache.img镜像文件中的命令并执行,将cache.img中的可执行文件写入系统的system分区。
执行模块14,用于执行写入移动终端的可执行文件,获取Root权限。具体为:recovery镜像文件将可执行文件写入系统后,由重启模块13将移动终端重新启动到正常模式,系统自动加载系统文件,执行写入的用于获取最高权限的可执行文件,从而获得手机终端的Root权限。
PC端请求模块15向云端服务器发送移动终端的包括机型、CPU型号、系统版本号、内核版本号中的一种或任意多种的特征信息,获取并下载与移动终端匹配的包含可执行文件的修改recovery镜像文件或包含可执行文件的OTA差分包的cache镜像文件。
云端服务器模块16接收PC端的请求信息匹配移动终端相应的可执行文件或可执行文件的OTA差分包,与移动终端相匹配的官方recovery文件生成修改后的recovery镜像文件或者cache镜像文件,并推送到PC端。
以上所述仅是本发明的部分实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (10)
1.一种获取Root权限的方法,其特征在于,包括以下步骤:
启动移动终端的相应刷机模式;
向该启动刷机模式的移动终端写入用于获取系统最高权限的可执行文件;
重启所述移动终端以用于获取系统Root权限。
2.根据权利要求1所述的一种获取Root权限的方法,其特征在于,该方法还包括PC端向云端服务器发送特征信息请求获取与移动终端匹配的recovery文件。
3.根据权利要求2所述的一种获取Root权限的方法,其特征在于,所述特征信息具体指所述移动终端的包括机型、CPU型号、系统版本号、内核版本号中的一种或任意多种。
4.根据权利要求1所述的一种获取Root权限的方法,其特征在于,所述用于获取系统最高权限的可执行文件通过recovery镜像文件或cache镜像文件写入系统的system分区。
5.根据权利要求1所述的一种获取Root权限的方法,其特征在于,所述用于获取系统最高权限的可执行文件为su可执行文件或su可执行文件的OTA差分包。
6.一种获取Root权限的装置,其特征在于,包括:
刷机模式启动模块:用于启动移动终端的相应刷机模式;
可执行文件写入模块:用于将获取系统最高权限的可执行文件写入移动终端;
重启模块:重启所述移动终端以用于获取系统Root权限。
7.根据权利要求6所述的一种获取Root权限的装置,其特征在于,所述装置还包括执行模块,用于执行写入移动终端的可执行文件,获取Root权限。
8.根据权利要求6所述的一种获取Root权限的装置,其特征在于,所述装置还包括PC端请求模块,用于PC端向云端服务器发送特征信息请求获取与移动终端匹配的用于获取系统最高权限的recovery文件。
9.根据权利要求6所述的一种获取Root权限的装置,其特征在于,所述装置还包括云端服务器,用于向PC端推送与移动终端匹配的用于获取系统最高权限的recovery文件。
10.根据权利要求6所述的一种获取Root权限的装置,其特征在于,所述可执行文件写入模块的可执行文件为su可执行文件或su可执行文件的OTA差分包。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410838606.2A CN104506639A (zh) | 2014-12-29 | 2014-12-29 | 一种获取Root权限的方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410838606.2A CN104506639A (zh) | 2014-12-29 | 2014-12-29 | 一种获取Root权限的方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN104506639A true CN104506639A (zh) | 2015-04-08 |
Family
ID=52948354
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410838606.2A Pending CN104506639A (zh) | 2014-12-29 | 2014-12-29 | 一种获取Root权限的方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104506639A (zh) |
Cited By (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105072616A (zh) * | 2015-08-31 | 2015-11-18 | 宇龙计算机通信科技(深圳)有限公司 | 刷机rom的验证方法和刷机rom的验证装置 |
CN105224367A (zh) * | 2015-09-30 | 2016-01-06 | 浪潮电子信息产业股份有限公司 | 一种软件的安装方法及装置 |
CN105243339A (zh) * | 2015-10-19 | 2016-01-13 | 广东欧珀移动通信有限公司 | 一种刷机系统镜像的签名方法和装置 |
CN105512544A (zh) * | 2015-11-30 | 2016-04-20 | 深圳市创想天空科技股份有限公司 | 一种获取移动终端超级用户权限的方法及装置 |
CN105868644A (zh) * | 2015-12-11 | 2016-08-17 | 乐视移动智能信息技术(北京)有限公司 | 控制移动终端Root功能的方法、装置及移动终端 |
CN105956457A (zh) * | 2016-04-27 | 2016-09-21 | 四川秘无痕信息安全技术有限责任公司 | 一种频繁执行root权限操作并获得实时结果反馈的方法 |
CN105975815A (zh) * | 2016-04-29 | 2016-09-28 | 北京奇虎科技有限公司 | 应用程序的运行控制方法及装置 |
CN106162612A (zh) * | 2016-06-27 | 2016-11-23 | 北京小米移动软件有限公司 | 控制Root权限的方法及装置 |
CN106203101A (zh) * | 2015-04-30 | 2016-12-07 | 北京壹人壹本信息科技有限公司 | 一种安全管理方法及装置 |
CN106650408A (zh) * | 2016-12-09 | 2017-05-10 | 武汉斗鱼网络科技有限公司 | 一种用于判断安卓系统是否具有root权限的方法和系统 |
CN106791124A (zh) * | 2016-12-27 | 2017-05-31 | 北京奇虎科技有限公司 | 移动终端的刷机方法和刷机装置 |
CN108228215A (zh) * | 2018-01-02 | 2018-06-29 | 青岛海信移动通信技术股份有限公司 | 终端设备的ota升级包的推送方法及装置 |
CN109241703A (zh) * | 2017-07-04 | 2019-01-18 | 武汉安天信息技术有限责任公司 | 一种应用软件获取Android系统root权限的方法和系统 |
CN109635589A (zh) * | 2018-12-25 | 2019-04-16 | 成都卫士通信息产业股份有限公司 | So文件调用的方法及装置 |
CN110826069A (zh) * | 2019-11-05 | 2020-02-21 | 深信服科技股份有限公司 | 一种病毒处理方法、装置、设备及存储介质 |
CN111327683A (zh) * | 2020-01-21 | 2020-06-23 | 奇安信科技集团股份有限公司 | 加密信息提取方法、装置、计算机设备及可读存储介质 |
CN112434314A (zh) * | 2020-11-16 | 2021-03-02 | 深圳市优博讯科技股份有限公司 | 一种调试提权的方法及系统 |
CN113032014A (zh) * | 2019-12-09 | 2021-06-25 | 成都鼎桥通信技术有限公司 | 一种双系统终端的域间模式同步方法和装置 |
CN113905365A (zh) * | 2021-12-13 | 2022-01-07 | 龙旗电子(惠州)有限公司 | 安卓终端单双卡配置方法、装置及设备 |
CN114048402A (zh) * | 2022-01-12 | 2022-02-15 | 深圳软牛科技有限公司 | Android系统的FRP锁移除方法、装置、设备及存储介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102981835A (zh) * | 2012-11-02 | 2013-03-20 | 福州博远无线网络科技有限公司 | 安卓应用程序永久获取Root权限的方法 |
CN103019775A (zh) * | 2012-11-28 | 2013-04-03 | 北京小米科技有限责任公司 | 一种终端设备刷机的方法、装置和设备 |
CN103051778A (zh) * | 2012-12-04 | 2013-04-17 | 东莞宇龙通信科技有限公司 | 移动终端和移动终端设置时间的方法 |
CN103473502A (zh) * | 2013-09-16 | 2013-12-25 | 惠州Tcl移动通信有限公司 | 一种获取基于安卓的移动终端Root权限的方法和系统 |
CN103714287A (zh) * | 2013-12-25 | 2014-04-09 | 北京奇虎科技有限公司 | 一种获取临时Root权限的方法及装置 |
-
2014
- 2014-12-29 CN CN201410838606.2A patent/CN104506639A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102981835A (zh) * | 2012-11-02 | 2013-03-20 | 福州博远无线网络科技有限公司 | 安卓应用程序永久获取Root权限的方法 |
CN103019775A (zh) * | 2012-11-28 | 2013-04-03 | 北京小米科技有限责任公司 | 一种终端设备刷机的方法、装置和设备 |
CN103051778A (zh) * | 2012-12-04 | 2013-04-17 | 东莞宇龙通信科技有限公司 | 移动终端和移动终端设置时间的方法 |
CN103473502A (zh) * | 2013-09-16 | 2013-12-25 | 惠州Tcl移动通信有限公司 | 一种获取基于安卓的移动终端Root权限的方法和系统 |
CN103714287A (zh) * | 2013-12-25 | 2014-04-09 | 北京奇虎科技有限公司 | 一种获取临时Root权限的方法及装置 |
Non-Patent Citations (2)
Title |
---|
MYTIANKONG: "HTC One S运用SuperBoot应用获取完全Root权限的详细教程", 《HTTP://MYTIANKONG.COM/?P=6173》 * |
团支书: "通用Root教程(完整版!附自救方法)", 《MIUO米柚论坛》 * |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106203101A (zh) * | 2015-04-30 | 2016-12-07 | 北京壹人壹本信息科技有限公司 | 一种安全管理方法及装置 |
CN105072616B (zh) * | 2015-08-31 | 2019-10-11 | 宇龙计算机通信科技(深圳)有限公司 | 刷机rom的验证方法和刷机rom的验证装置 |
CN105072616A (zh) * | 2015-08-31 | 2015-11-18 | 宇龙计算机通信科技(深圳)有限公司 | 刷机rom的验证方法和刷机rom的验证装置 |
CN105224367A (zh) * | 2015-09-30 | 2016-01-06 | 浪潮电子信息产业股份有限公司 | 一种软件的安装方法及装置 |
CN105243339A (zh) * | 2015-10-19 | 2016-01-13 | 广东欧珀移动通信有限公司 | 一种刷机系统镜像的签名方法和装置 |
CN105512544A (zh) * | 2015-11-30 | 2016-04-20 | 深圳市创想天空科技股份有限公司 | 一种获取移动终端超级用户权限的方法及装置 |
CN105512544B (zh) * | 2015-11-30 | 2018-12-04 | 深圳市创想天空科技股份有限公司 | 一种获取移动终端超级用户权限的方法及装置 |
CN105868644A (zh) * | 2015-12-11 | 2016-08-17 | 乐视移动智能信息技术(北京)有限公司 | 控制移动终端Root功能的方法、装置及移动终端 |
CN105956457B (zh) * | 2016-04-27 | 2018-11-13 | 四川秘无痕信息安全技术有限责任公司 | 一种频繁执行root权限操作并获得实时结果反馈的方法 |
CN105956457A (zh) * | 2016-04-27 | 2016-09-21 | 四川秘无痕信息安全技术有限责任公司 | 一种频繁执行root权限操作并获得实时结果反馈的方法 |
CN105975815A (zh) * | 2016-04-29 | 2016-09-28 | 北京奇虎科技有限公司 | 应用程序的运行控制方法及装置 |
CN106162612A (zh) * | 2016-06-27 | 2016-11-23 | 北京小米移动软件有限公司 | 控制Root权限的方法及装置 |
CN106650408B (zh) * | 2016-12-09 | 2020-08-04 | 武汉斗鱼网络科技有限公司 | 一种用于判断安卓系统是否具有root权限的方法和系统 |
CN106650408A (zh) * | 2016-12-09 | 2017-05-10 | 武汉斗鱼网络科技有限公司 | 一种用于判断安卓系统是否具有root权限的方法和系统 |
CN106791124A (zh) * | 2016-12-27 | 2017-05-31 | 北京奇虎科技有限公司 | 移动终端的刷机方法和刷机装置 |
CN109241703A (zh) * | 2017-07-04 | 2019-01-18 | 武汉安天信息技术有限责任公司 | 一种应用软件获取Android系统root权限的方法和系统 |
CN108228215A (zh) * | 2018-01-02 | 2018-06-29 | 青岛海信移动通信技术股份有限公司 | 终端设备的ota升级包的推送方法及装置 |
CN109635589B (zh) * | 2018-12-25 | 2022-06-14 | 成都卫士通信息产业股份有限公司 | So文件调用的方法及装置 |
CN109635589A (zh) * | 2018-12-25 | 2019-04-16 | 成都卫士通信息产业股份有限公司 | So文件调用的方法及装置 |
CN110826069A (zh) * | 2019-11-05 | 2020-02-21 | 深信服科技股份有限公司 | 一种病毒处理方法、装置、设备及存储介质 |
CN110826069B (zh) * | 2019-11-05 | 2022-09-30 | 深信服科技股份有限公司 | 一种病毒处理方法、装置、设备及存储介质 |
CN113032014A (zh) * | 2019-12-09 | 2021-06-25 | 成都鼎桥通信技术有限公司 | 一种双系统终端的域间模式同步方法和装置 |
CN113032014B (zh) * | 2019-12-09 | 2022-08-09 | 成都鼎桥通信技术有限公司 | 一种双系统终端的域间模式同步方法和装置 |
CN111327683A (zh) * | 2020-01-21 | 2020-06-23 | 奇安信科技集团股份有限公司 | 加密信息提取方法、装置、计算机设备及可读存储介质 |
CN111327683B (zh) * | 2020-01-21 | 2022-12-16 | 奇安信科技集团股份有限公司 | 加密信息提取方法、装置、计算机设备及可读存储介质 |
CN112434314A (zh) * | 2020-11-16 | 2021-03-02 | 深圳市优博讯科技股份有限公司 | 一种调试提权的方法及系统 |
CN113905365A (zh) * | 2021-12-13 | 2022-01-07 | 龙旗电子(惠州)有限公司 | 安卓终端单双卡配置方法、装置及设备 |
CN113905365B (zh) * | 2021-12-13 | 2022-03-15 | 龙旗电子(惠州)有限公司 | 安卓终端单双卡配置方法、装置及设备 |
CN114048402B (zh) * | 2022-01-12 | 2022-04-22 | 深圳软牛科技有限公司 | Android系统的FRP锁移除方法、装置、设备及存储介质 |
CN114048402A (zh) * | 2022-01-12 | 2022-02-15 | 深圳软牛科技有限公司 | Android系统的FRP锁移除方法、装置、设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104506639A (zh) | 一种获取Root权限的方法及装置 | |
CN102804194B (zh) | 用于提供应用安全性的方法及装置 | |
CN102622241A (zh) | 一种软件升级方法及装置 | |
US8701104B2 (en) | System and method for user agent code patch management | |
US20140372799A1 (en) | System Differential Upgrade Method, Apparatus, and Mobile Terminal | |
US20090124251A1 (en) | Method of Assessing Compatibility Between Applications and Processor Devices | |
CN101751593B (zh) | 智能卡及其备份与恢复方法和系统 | |
CN107783776B (zh) | 固件升级包的处理方法及装置、电子设备 | |
KR20110082585A (ko) | 디바이스상의 컴포넌트들을 자동으로 처리하기 위한 시스템 | |
CN104375849A (zh) | 加载内核的方法及装置 | |
CN101826026A (zh) | 嵌入式设备、嵌入式设备中固件在线升级的系统及方法 | |
CN107992308A (zh) | 一种安卓终端应用程序的插件化管理方法 | |
CN103067392A (zh) | 一种基于Android终端的安全访问控制方法 | |
CN104318160A (zh) | 查杀恶意程序的方法和装置 | |
CN105204909A (zh) | 一种基于移动终端的强相关apk升级方法及系统 | |
CN101984406A (zh) | 一种通过无线局域网对终端进行升级的方法和系统 | |
CN105468395A (zh) | 更新方法、装置及系统 | |
CN107220074A (zh) | 对支撑层软件功能的访问、升级方法及装置 | |
CN103840968A (zh) | 一种版本更新方法、装置及终端设备 | |
CN101895883A (zh) | 一种支持鉴权算法更新的智能卡及方法 | |
CN102968321A (zh) | 应用程序安装装置和应用程序安装方法 | |
CN110413292B (zh) | 应用程序的轻应用安装方法、移动终端及存储介质 | |
CN113961226B (zh) | 一种软件开发工具包修复方法、终端、服务器及设备 | |
CN105335195A (zh) | 一种设备驱动升级方法、装置及电子设备 | |
CN104778058A (zh) | 应用程序更新方法和应用程序更新系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20150408 |
|
RJ01 | Rejection of invention patent application after publication |