-
-
[原创]Android逆向-Android基础逆向（2）
-
发表于: 2018-1-27 09:43
-
0x00前言
不知道所以然的看Android逆向-Android基础逆向（1）
##1.本次学习内容
（1）APK文件伪加密
（2）资源文件防反编译
（3）apk打包流程
（4）apk反编译流程
（5）apk回编译流程
0x01 APK文件伪加密
之前说道，APK文件类似于ZIP文件，ZIP文件有一项技术是伪加密，就是让ZIP变成加密的状态，但是它自己其实并没有什么密码，所以叫做伪加密。原理就是把密码标志位改掉，接下来就是我们具体的原理了，我怕一篇不够写，要是不够写的话我就分成几篇研究了。
##1.内容说明
（1）zip不加密
（2）zip真加密
（3）双方对比
（4）伪加密
（5）APK实现
###zip文件结构
##2.ZIP不加密
突然想起我要不要把自己的实验环境共享出来。。。先留着吧，万一有用再共享吧。。。
首先我们新建一个文件，就.txt吧。然后把它压缩了。
然后通过FlexHEX打开。恩，反正我喜欢用FlexHEX。其他什么都可以，可以打开二进制文件就行。
这里就不得不研究一下zip加密字段放在什么位置了。
参考zip官方文档
###2.1local file header signature
首先来看第一个local file header signature，本地文件头签名。这里默认是0x04034b50，有没有人给我讲讲这里为什么是默认0x04034b50。
相对应的看我们的例子：
这个是我们demo。
顺便来看一下我们的APK吧。（这个APK是上节课所演示的）
这里APK也是一样的。
这里有一个小问题就是高位高低位的存储方式问题。高位在下，低位在上，学过汇编的应该都知道。
###2.2 version needed to extract
然后来看下一个字段部分。 version needed to extract ，解压缩版本。这里是最低的可解压缩的版本显示。
首先是看demo。
然后是我们的apk。
我们来看一下官方解释。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 | version needed to extract (2 bytes) The minimum supported ZIP specification version needed to extract the file, mapped as above. This value is based on the specific format features a ZIP program must support to be able to extract the file. If multiple features are applied to a file, the minimum version should be set to the feature having the highest value. New features or feature changes affecting the published format specification will be implemented using higher version numbers than the last published value to avoid conflict. Current minimum feature versions are as defined below: 1.0 - Default value 1.1 - File is a volume label 2.0 - File is a folder (directory) 2.0 - File is compressed using Deflate compression 2.0 - File is encrypted using traditional PKWARE encryption 2.1 - File is compressed using Deflate64(tm) 2.5 - File is compressed using PKWARE DCL Implode 2.7 - File is a patch data set 4.5 - File uses ZIP64 format extensions 4.6 - File is compressed using BZIP2 compression* 5.0 - File is encrypted using DES 5.0 - File is encrypted using 3DES 5.0 - File is encrypted using original RC2 encryption 5.0 - File is encrypted using RC4 encryption 5.1 - File is encrypted using AES encryption 5.1 - File is encrypted using corrected RC2 encryption** 5.2 - File is encrypted using corrected RC2-64 encryption** 6.1 - File is encrypted using non-OAEP key wrapping*** 6.2 - Central directory encryption * Early 7.x (pre-7.2) versions of PKZIP incorrectly set the version needed to extract for BZIP2 compression to be 50 when it should have been 46. ** Refer to the section on Strong Encryption Specification for additional information regarding RC2 corrections. *** Certificate encryption using non-OAEP key wrapping is the intended mode of operation for all versions beginning with 6.1. Support for OAEP key wrapping should only be used for backward compatibility when sending ZIP files to be opened by versions of PKZIP older than 6.1 (5.0 or 6.0). When using ZIP64 extensions, the corresponding value in the Zip64 end of central directory record should also be set. This field currently supports only the value 45 to indicate ZIP64 extensions are present. |
###2.3 general purpose bit flag
第三个字段，通用标志位。
还是先来看看demo吧。
demo的标志位为00 08
然后再来看一下我们的apk文件。
APK文件的标志位是00 00，这里我们发现这里并不一样。我们来仔细看一下官方文档的说明。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 | general purpose bit flag: (2 bytes) Bit 0: If set, indicates that the file is encrypted. (For Method 6 - Imploding) Bit 1: If the compression method used was type 6, Imploding, then this bit, if set, indicates an 8K sliding dictionary was used. If clear, then a 4K sliding dictionary was used. Bit 2: If the compression method used was type 6, Imploding, then this bit, if set, indicates 3 Shannon-Fano trees were used to encode the sliding dictionary output. If clear, then 2 Shannon-Fano trees were used. (For Methods 8 and 9 - Deflating) Bit 2 Bit 1 0 0 Normal (-en) compression option was used. 0 1 Maximum (-exx/-ex) compression option was used. 1 0 Fast (-ef) compression option was used. 1 1 Super Fast (-es) compression option was used. Note: Bits 1 and 2 are undefined if the compression method is any other. Bit 3: If this bit is set, the fields crc-32, compressed size and uncompressed size are set to zero in the local header. The correct values are put in the data descriptor immediately following the compressed data. (Note: PKZIP version 2.04g for DOS only recognizes this bit for method 8 compression, newer versions of PKZIP recognize this bit for any compression method.) Bit 4: Reserved for use with method 8, for enhanced deflating. Bit 5: If this bit is set, this indicates that the file is compressed patched data. (Note: Requires PKZIP version 2.70 or greater) Bit 6: Strong encryption. If this bit is set, you should set the version needed to extract value to at least 50 and you must also set bit 0. If AES encryption is used, the version needed to extract value must be at least 51. Bit 7: Currently unused. Bit 8: Currently unused. Bit 9: Currently unused. Bit 10: Currently unused. Bit 11: Currently unused. Bit 12: Reserved by PKWARE for enhanced compression. Bit 13: Used when encrypting the Central Directory to indicate selected data values in the Local Header are masked to hide their actual values. See the section describing the Strong Encryption Specification for details. Bit 14: Reserved by PKWARE. Bit 15: Reserved by PKWARE. compression method: (2 bytes) (see accompanying documentation for algorithm descriptions) 0 - The file is stored (no compression) 1 - The file is Shrunk 2 - The file is Reduced with compression factor 1 3 - The file is Reduced with compression factor 2 4 - The file is Reduced with compression factor 3 5 - The file is Reduced with compression factor 4 6 - The file is Imploded 7 - Reserved for Tokenizing compression algorithm 8 - The file is Deflated 9 - Enhanced Deflating using Deflate64(tm) 10 - PKWARE Data Compression Library Imploding 11 - Reserved by PKWARE 12 - File is compressed using BZIP2 algorithm |
我们来看bit 0：If set, indicates that the file is encrypted.如果这里被设置成了1，那么就代表加密。
我们demo的general purpose bit flag字段是0008，换算成二进制是，工具包里没有二进制转换工具，懒得上网页，我去找找其他工具包里有没有。找了半天，可能网络安全工具包对逆向开发人员不友好。不找了，自己写一个，好烦。顺便练习一下python的命令行工具制作。
终于写完了。在中间遇到一个问题就是如何让从十六进制的数转化为二进制，然后最好转化成8位的显示方法。问了同学，朋友最后还是解决了。恩，开心。代码不想贴。下次有机会吧。
通过运行程序我们发现第0个bit不是1，那么就不是加密。再看看apk的二进制码。
运行程序进行转换。
发现apk的第三个部分也不是0那么说明apk也是没有加密的事实如此。
我又加密了一个demo1，来进行观察。
然后使用脚本进行编码转换
然后这里的编码就是00001000 00000001，可以看到第0bit，位是1。
我自己做了测试，发现这里的1代表的就是有加密，而并不是加密的意思。所以我们要接着往下看。
###2.4compression method
这个字段是压缩版本，压缩方法。我们来看一下官方说明。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | (see accompanying documentation for algorithm descriptions) 0 - The file is stored (no compression) 1 - The file is Shrunk 2 - The file is Reduced with compression factor 1 3 - The file is Reduced with compression factor 2 4 - The file is Reduced with compression factor 3 5 - The file is Reduced with compression factor 4 6 - The file is Imploded 7 - Reserved for Tokenizing compression algorithm 8 - The file is Deflated 9 - Enhanced Deflating using Deflate64(tm) 10 - PKWARE Data Compression Library Imploding 11 - Reserved by PKWARE 12 - File is compressed using BZIP2 algorithm |
这个就是压缩方式，就不细细说明了。
###2.5 last mod file time
文件最后修改时间。
来看看demo的时间。
这个是apk的时间。
###2.6 last mod file date
文件最后修改日期。
demo的日期。
###2.7 crc-32
CRC即循环冗余校验码（Cyclic Redundancy Check[1] ）：是数据通信领域中最常用的一种查错校验码，其特征是信息字段和校验字段的长度可以任意选定。
来看看demo中的crc-32
apk中的crc-32
###2.8 compressed size
这个字段就是压缩后的大小。我们来观察一下demo的大小。
###2.9 uncompressed size
压缩前的大小，自己看吧，不想截图了。
###2.10 file name length
文件名长度
###2.11 extra field length
额外的字段长度，一般为空。
###2.12 File data
之上是一个大模块，然后就是这个模块。
###2.13directory structure— File header
和之前分析过的一样，我们知道在第四个字段的第0bit，0和1控制着是否加密。我们尝试把第0个bit改成1。
这个是没有更改的状态。
这里是我们更改后的样子。
我们发现我们的文件已经进行了加密。
##3.zip加密分析+对比
我们来看一下zip加密文件的字段。我们发现这里加密后的文件字段就是被设置成为了0108，二进制表示为：00001000 00000001。第0bit是1，所以这个加密的。
##4.apk伪加密尝试
###4.1首先加密AndroidManifest.xml
安装进行测试，发现可以正常安装。
进行反编译。
这里我们发现出错误了，也就是说，我们在防止反编译的道路上迈出了一步，至于是一大步还是一小步，我就不知道了。至少我们现在有了一种可以简单的保护apk的方法了。接下来可能还有进行其他的一些测试。
###4.2加密签名文件
进行反编译：
然后我们发现在反编译到签名文件的时候就发生了错误。然后在手机上进行安装尝试。
测试之后发现还是可以照常安装并且打开。这里就不上图了，上传麻烦。
###4.3加密dex文件
然后使用Androidkiller进行反编译，反编译失败。之前的我可能要懵掉的，但是现在，嘿嘿。
进行安装检查。安装成功，我是用我的自己手机测试了，你们随便玩，反正我是安装成功了。这里就不上传图片了，是不是篇幅有一点大了。恩。。。下一篇继续，这里的学习目的也就差不多了。
突然想写一个伪加密工具出来。可以考虑一下。
#0x02 结束语
学习内容没有完成，没关系，下次接着来。工具明天写我要睡觉了。
2018年1月26日00:42:02
如果有需要请参考：
Android逆向-Android基础逆向（1）
##以及java系列：
Android逆向-java代码基础（1）
Android逆向-java代码基础（2）
Android逆向-java代码基础（3）
Android逆向-java代码基础（4）
Android逆向-java代码基础（5）
Android逆向-java代码基础（6）
Android逆向-java代码基础（7）
Android逆向-java代码基础（8）
