用户
搜索
  • TA的每日心情
    慵懒
    3 天前
  • 签到天数: 106 天

    连续签到: 1 天

    [LV.6]常住居民II

    i春秋作家

    推荐小组成员

    Rank: 7Rank: 7Rank: 7

    102

    主题

    234

    帖子

    347

    魔法币
    收听
    0
    粉丝
    15
    注册时间
    2017-7-24

    幽默灌水王突出贡献春秋文阁i春秋签约作者i春秋推荐小组积极活跃奖春秋游侠秦

    HAI_ i春秋作家 推荐小组成员 幽默灌水王 突出贡献 春秋文阁 i春秋签约作者 i春秋推荐小组 积极活跃奖 春秋游侠 秦 楼主
    发表于 2018-1-26 00:47:25 12230

    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。
    这里写图片描述
    我们来看一下官方解释。

    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,这里我们发现这里并不一样。我们来仔细看一下官方文档的说明。

    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

    这个字段是压缩版本,压缩方法。我们来看一下官方说明。

     (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)

    本帖被以下淘专辑推荐:

    破解的目的是为了更好的开发
    没看懂,讲的很乱
    使用道具 举报 回复
    发新帖
    您需要登录后才可以回帖 登录 | 立即注册