[转]通过apk签名使应用程序有系统权限

[转]通过apk签名使应用程序有系统权限

(2013-01-08 13:40:50)

转载▼

标签：

it

分类： Android

出处：http://blog.csdn.net/doom66151/article/details/7085464

问题：
系统预装软件，需要访问一些配置文件，配置文件的owner都是设置为system。所以应用程序需要有授权才可以读写。
google搜索找到以下文章，解决了这个问题。
以下内容解释了：
android系统权限规则？
如何使应用程序获取系统权限？
apk签名的过程？
apk签名的原理？
#################################################################
以下内容转自：
http://hi.baidu.com/donghaozheng/blog/item/23ca75ec0028bbdc2e2e21c5.html
Android系统是运行在Linux内核上的，Android与Linux分别有自己的一套严格的安全及权限机制，
很多像我这样的新手,尤其是习惯了windows低安全限制的用户，很容易在这方面弄混淆，下面是我总结的Android系统权限相关的内容，
作为这段时间对android权限学习的总结，也希望能对大家有所帮助，不正确之处请指出。
首先分清两个概念：
要区分apk运行时的拥有的权限与在文件系统上被访问（读写执行）的权限两个概念。
apk程序是运行在虚拟机上的,对应的是Android独特的权限机制，只有体现到文件系统上时才使用linux的权限设置。
（一）linux文件系统上的权限
-rwxr-x--x system system 4156 2010-04-30 16:13 test.apk
代表的是相应的用户/用户组及其他人对此文件的访问权限，与此文件运行起来具有的权限完全不相关。
比如上面的例子只能说明system用户拥有对此文件的读写执行权限；system组的用户对此文件拥有读、执行权限；其他人对此文件只具有执行权限。
而test.apk运行起来后可以干哪些事情，跟这个就不相关了。
千万不要看apk文件系统上属于system/system用户及用户组，或者root/root用户及用户组，就认为apk具有system或root权限。
（二）Android的权限规则

（1)Android中的apk必须签名

这种签名不是基于权威证书的，不会决定某个应用允不允许安装，而是一种自签名证书。
重要的是，android系统有的权限是基于签名的。比如：system等级的权限有专门对应的签名，签名不对，权限也就获取不到。
默认生成的APK文件是debug签名的。
获取system权限时用到的签名，见：如何使Android应用程序获取系统权限
（2）基于UserID的进程级别的安全机制
大家都知道，进程有独立的地址空间，进程与进程间默认是不能互相访问的，是一种很可靠的保护机制。
Android通过为每一个安装在设备上的包（apk）分配唯一的linux userID来实现，名称为"app_"加一个数字，比如app_43
不同的UserID，运行在不同的进程，所以apk之间默认便不能相互访问。
Android提供了如下的一种机制，可以使两个apk打破前面讲的这种壁垒。
在AndroidManifest.xml中利用sharedUserId属性给不同的package分配相同的userID，通过这样做，两个package可以被当做同一个程序，
系统会分配给两个程序相同的UserID。当然，基于安全考虑，两个package需要有相同的签名，否则没有验证也就没有意义了。
（这里补充一点:并不是说分配了同样的UserID，两程序就运行在同一进程, 下面为PS指令摘取的，
显然，system、app_2分别对应的两个进程的PID都不同，不知Android到底是怎样实现它的机制的）
User PID PPID
system 953 883 187340 55052 ffffffff afe0cbcc S system_server
app_2 1072 883 100264 19564 ffffffff afe0dcc4 S com.android.inputmethod.
system 1083 883 111808 23192 ffffffff afe0dcc4 S android.process.omsservi
app_2 1088 883 156464 45720 ffffffff afe0dcc4 S android.process.acore
（3）默认apk生成的数据对外是不可见的
实现方法是：Android会为程序存储的数据分配该程序的UserID。
借助于Linux严格的文件系统访问权限，便实现了apk之间不能相互访问似有数据的机制。
例：我的应用创建的一个文件，默认权限如下，可以看到只有UserID为app_21的程序才能读写该文件。
-rw------- app_21 app_21 87650 2000-01-01 09:48 test.txt
如何对外开放？
<1> 使用MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE 标记。
When creating a new file with getSharedPreferences(String, int), openFileOutput(String, int), or openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory), you can use the MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE flags to allow any other package to read/write the file. When setting these flags, the file is still owned by your application, but its global read and/or write permissions have been set appropriately so any other application can see it.
（4）AndroidManifest.xml中的显式权限声明
Android默认应用是没有任何权限去操作其他应用或系统相关特性的，应用在进行某些操作时都需要显式地去申请相应的权限。
一般以下动作时都需要申请相应的权限：
A particular permission may be enforced at a number of places during your program's operation:
At the time of a call into the system, to prevent an application from executing certain functions.
When starting an activity, to prevent applications from launching activities of other applications.
Both sending and receiving broadcasts, to control who can receive your broadcast or who can send a broadcast to you.
When accessing and operating on a content provider.
Binding or starting a service.
在应用安装的时候，package installer会检测该应用请求的权限，根据该应用的签名或者提示用户来分配相应的权限。
在程序运行期间是不检测权限的。如果安装时权限获取失败，那执行就会出错，不会提示用户权限不够。
大多数情况下，权限不足导致的失败会引发一个 SecurityException， 会在系统log（system log）中有相关记录。
（5）权限继承/UserID继承
当我们遇到apk权限不足时，我们有时会考虑写一个linux程序，然后由apk调用它去完成某个它没有权限完成的事情，很遗憾，这种方法是行不通的。
前面讲过，android权限是经营在进程层面的，也就是说一个apk应用启动的子进程的权限不可能超越其父进程的权限（即apk的权限），
即使单独运行某个应用有权限做某事，但如果它是由一个apk调用的，那权限就会被限制。
实际上，android是通过给子进程分配父进程的UserID实现这一机制的。
（三）常见权限不足问题分析
首先要知道，普通apk程序是运行在非root、非system层级的，也就是说看要访问的文件的权限时，看的是最后三位。
另外，通过system/app安装的apk的权限一般比直接安装或adb install安装的apk的权限要高一些。
言归正传，运行一个android应用程序过程中遇到权限不足，一般分为两种情况:
（1）Log中可明显看到权限不足的提示。
此种情况一般是AndroidManifest.xml中缺少相应的权限设置，好好查找一番权限列表，应该就可解决，是最易处理的情况。
有时权限都加上了，但还是报权限不足，是什么情况呢？
Android系统有一些API及权限是需要apk具有一定的等级才能运行的。
比如 SystemClock.setCurrentTimeMillis()修改系统时间，WRITE_SECURE_SETTINGS权限好像都是需要有system级的权限才行。
也就是说UserID是system.
（2）Log里没有报权限不足，而是一些其他Exception的提示,这也有可能是权限不足造成的。
比如：我们常会想读/写一个配置文件或其他一些不是自己创建的文件，常会报java.io.FileNotFoundException错误。
系统认为比较重要的文件一般权限设置的也会比较严格，特别是一些很重要的(配置)文件或目录。
如
-r--r----- bluetooth bluetooth 935 2010-07-09 20:21 dbus.conf
drwxrwx--x system system 2010-07-07 02:05 data
dbus.conf好像是蓝牙的配置文件，从权限上来看，根本就不可能改动，非bluetooth用户连读的权利都没有。
/data目录下存的是所有程序的私有数据，默认情况下android是不允许普通apk访问/data目录下内容的，通过data目录的权限设置可知，其他用户没有读的权限。
所以adb普通权限下在data目录下敲ls命令，会得到opendir failed, Permission denied的错误，通过代码file.listfiles()也无法获得data目录下的内容。
上面两种情况，一般都需要提升apk的权限，目前我所知的apk能提升到的权限就是system（具体方法见：如何使Android应用程序获取系统权限）,
至于是否有root级的，如何提升至root级不得而知，知道的朋友劳烦告知，感激不尽。
##############################################################################
以下整理自：《如何使Android应用程序获取系统权限》
http://hi.baidu.com/donghaozheng/blog/item/30a00d4f9fca873baec3ab69.html
1. 在应用程序的AndroidManifest.xml中的manifest节点中加入android:sharedUserId="android.uid.system"这个属性。
2. 使用eclipse编译出apk文件，但是这个apk文件是不能用的。
3. 使用目标系统的platform密钥来重新给apk文件签名。
最后解释一下原理，首先加入android:sharedUserId="android.uid.system"这个属性。通过Shared User id,拥有同一个User id的多个APK可以配置成运行在同一个进程中。那么把程序的UID配成android.uid.system，也就是要让程序运行在系统进程中，这样就有权限来修改系统时间了。
只是加入UID还不够，如果这时候安装APK的话发现无法安装，提示签名不符，原因是程序想要运行在系统进程中还要有目标系统的platform key，就是上面第二个方法提到的platform.pk8和platform.x509.pem两个文件。用这两个key签名后apk才真正可以放入系统进程中。第一个方法中加入LOCAL_CERTIFICATE := platform其实就是用这两个key来签名。
这也有一个问题，就是这样生成的程序只有在原始的Android系统或者是自己编译的系统中才可以用，因为这样的系统才可以拿到platform.pk8和platform.x509.pem两个文件。
要是别家公司做的Android上连安装都安装不了。试试原始的Android中的key来签名，程序在模拟器上运行OK，不过放到G3上安装直接提示"Package ... has no signatures that match those in shared user android.uid.system"，这样也是保护了系统的安全。
最最后还说下，这个android:sharedUserId属性不只可以把apk放到系统进程中，也可以配置多个APK运行在一个进程中，这样可以共享数据，应该会很有用的。
总结简单三步
>>>>>>>使用platform密钥对apk进行签名
1 创建一个目录
2 整理必须的文件：
密钥文件：进入build/target/product/security ,找到【platform.pk8】和【platform.x509.pem】系统默认使用的密钥。
signapk工具：进入build\tools\signapk找到SignApk.java，运行 javac或者直接mm编译。
signapk.jar的源码位置build/tools/signapk，编译以后生成的文件路径：out/host/linux-x86/framework/signapk.jar
3.执行命令: java -jar signapk.jar platform.x509.pem platform.pk8 your.apk your_signed.apk
这条命令的意义是：通过signapk.jar这个可执行jar包，以“platform.x509.pem”这个公钥文件和“platform.pk8”这个私钥文件对“your.apk”进行签名，签名后的文件保存为“your_signed.apk”。
对于此处所使用的私钥和公钥的生成方式，这里就不做进一步介绍了。可以参考 http://blog.csdn.net/absurd/article/details/5002763
#############################################################################
程序签名的具体过程和原理
此笔记主要参考了 下面的文章整理出来的。
http://www.blogjava.net/zh-weir/archive/2011/07/19/354663.html
这里还有一篇文章将apk破解的，也许对你的理解有帮助。
http://www.blogjava.net/zh-weir/archive/2011/06/11/352099.html
signapk.jar是Android源码包中的一个签名工具。由于Android是个开源项目，所以我们可以直接找到signapk.jar的源码，路径为/build/tools/signapk/SignApk.java。通过阅读signapk源码，我们可以理清签名APK包的整个过程。
签名好的APK包中多了一个叫做META-INF的文件夹。里面有三个文件，分别名为MANIFEST.MF、CERT.SF和CERT.RSA。signapk.jar就是生成了这几个文件.
1、 生成MANIFEST.MF文件：
程序遍历update.apk包中的所有文件(entry)，对非文件夹非签名文件的文件，逐个生成SHA1的数字签名信息，再用Base64进行编码。具体代码见这个方法：
private static Manifest addDigestsToManifest(JarFile jar)
关键代码如下：
1 for (JarEntry entry: byName.values()) {
2 String name = entry.getName();
3 if (!entry.isDirectory() && !name.equals(JarFile.MANIFEST_NAME) &&
4 !name.equals(CERT_SF_NAME) && !name.equals(CERT_RSA_NAME) &&
5 (stripPattern == null ||!stripPattern.matcher(name).matches())) {
6 InputStream data = jar.getInputStream(entry);
7 while ((num = data.read(buffer)) > 0) {
8 md.update(buffer, 0, num);
9 }
10 Attributes attr = null;
11 if (input != null) attr = input.getAttributes(name);
12 attr = attr != null ? new Attributes(attr) : new Attributes();
13 attr.putValue("SHA1-Digest", base64.encode(md.digest()));
14 output.getEntries().put(name, attr);
15 }
16 }
之后将生成的签名写入MANIFEST.MF文件。关键代码如下：
1 Manifest manifest = addDigestsToManifest(inputJar);
2 je = new JarEntry(JarFile.MANIFEST_NAME);
3 je.setTime(timestamp);
4 outputJar.putNextEntry(je);
5 manifest.write(outputJar);
这里简单介绍下SHA1数字签名。简单地说，它就是一种安全哈希算法，类似于MD5算法。它把任意长度的输入，通过散列算法变成固定长度的输出（这里我们称作“摘要信息”）。你不能仅通过这个摘要信息复原原来的信息。另外，它保证不同信息的摘要信息彼此不同。因此，如果你改变了apk包中的文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是程序就不能成功安装。
2、 生成CERT.SF文件：
对前一步生成的Manifest，使用SHA1-RSA算法，用私钥进行签名。关键代码如下：
1 Signature signature = Signature.getInstance("SHA1withRSA");
2 signature.initSign(privateKey);
3 je = new JarEntry(CERT_SF_NAME);
4 je.setTime(timestamp);
5 outputJar.putNextEntry(je);
6 writeSignatureFile(manifest,
7 new SignatureOutputStream(outputJar, signature));
RSA是一种非对称加密算法。用私钥通过RSA算法对摘要信息进行加密。在安装时只能使用公钥才能解密它。解密之后，将它与未加密的摘要信息进行对比，如果相符，则表明内容没有被异常修改。
3、 生成CERT.RSA文件：
生成MANIFEST.MF没有使用密钥信息，生成CERT.SF文件使用了私钥文件。那么我们可以很容易猜测到，CERT.RSA文件的生成肯定和公钥相关。
CERT.RSA文件中保存了公钥、所采用的加密算法等信息。核心代码如下：

1 je = new JarEntry(CERT_RSA_NAME);

2 je.setTime(timestamp);
3 outputJar.putNextEntry(je);
4 writeSignatureBlock(signature, publicKey, outputJar);
其中writeSignatureBlock的代码如下：
1 private static void writeSignatureBlock(
2 Signature signature, X509Certificate publicKey, OutputStream out)
3 throws IOException, GeneralSecurityException {
4 SignerInfo signerInfo = new SignerInfo(
5 new X500Name(publicKey.getIssuerX500Principal().getName()),
6 publicKey.getSerialNumber(),
7 AlgorithmId.get("SHA1"),
8 AlgorithmId.get("RSA"),
9 signature.sign());
10
11 PKCS7 pkcs7 = new PKCS7(
12 new AlgorithmId[] { AlgorithmId.get("SHA1") },
13 new ContentInfo(ContentInfo.DATA_OID, null),
14 new X509Certificate[] { publicKey },
15 new SignerInfo[] { signerInfo });
16
17 pkcs7.encodeSignedData(out);
18 }
好了，分析完APK包的签名流程，我们可以清楚地意识到：
1、 Android签名机制其实是对APK包完整性和发布机构唯一性的一种校验机制。
2、 Android签名机制不能阻止APK包被修改，但修改后的再签名无法与原先的签名保持一致。（拥有私钥的情况除外）。
3、 APK包加密的公钥就打包在APK包内，且不同的私钥对应不同的公钥。换句话言之，不同的私钥签名的APK公钥也必不相同。所以我们可以根据公钥的对比，来判断私钥是否一致。