分类: android

首先这篇文章是具体参考【原创】**应用加固的脱壳分析和修复,上文作者在今年2月12号发了一篇文章详细分析了整个过程,由于腾讯加固的技术也不断演进,所以我在上文的基础,分析现在7月份腾讯加固采用的新方法。与上文重复的部分就不再过多说明,所以阅读本文之前,要首先看懂上文的大致思路。

1.查看加固的DEX

首先,用010 Editor来分析一下该加固后的DEX文件,在文件的尾部明显看到injected_data,injected_data的偏移地址为0x415C,大小为0x1310BF,选中这一部分数据,可以看到明显的qihoo文件头,黑色下划线的部分:0x71, 0x68, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00。在libprotectClass.so加固的版本中,最初的版本文件头的后四位均为0,后面的升级版本后四位可能为数据大小。
DEX文件

更多

首先这篇文章是具体参考【原创】**应用加固的脱壳分析和修复,上文作者在今年2月12号发了一篇文章详细分析了整个过程,由于腾讯加固的技术也不断演进,所以我在上文的基础,分析现在7月份腾讯加固采用的新方法。与上文重复的部分就不再过多说明,所以阅读本文之前,要首先看懂上文的大致思路。

1.反编译apk

首先,看一下原apk和加固后的文件变化情况,主要是修改了AndroidManifest.xml和classes.dex,以及新增了libmain.so和libshell.so两个文件。
然后下载最新的Apktool的源码进行编译,得到apktool-cli.jar这个文件。然后直接进行反编译,如无意外的出错了。因为腾讯加固就是利用一些Apktool的bug来阻止反编译,但是又不影响安卓程序的加载。

第一个错误,是腾讯加固时添加了两个同名的ID,attr/fasten,导致反编译时出错。由于这些ID是腾讯加固添加进去的,对于程序没有影响,所以我在Apktool的做法是直接忽略这种同名的ID。其实这个问题是Apktool的bug导致的,我这种忽略的方法是治标不治本,如果这些ID在程序中是有用的就不能这样做了。

Exception in thread "main" brut.androlib.AndrolibException: Multiple res specs: attr/fasten
	at brut.androlib.res.data.ResType.addResSpec(ResType.java:70)
	at brut.androlib.res.decoder.ARSCDecoder.readEntry(ARSCDecoder.java:221)
	at brut.androlib.res.decoder.ARSCDecoder.readConfig(ARSCDecoder.java:191)
	at brut.androlib.res.decoder.ARSCDecoder.readType(ARSCDecoder.java:159)
	at brut.androlib.res.decoder.ARSCDecoder.readPackage(ARSCDecoder.java:116)
	at brut.androlib.res.decoder.ARSCDecoder.readTable(ARSCDecoder.java:78)
	at brut.androlib.res.decoder.ARSCDecoder.decode(ARSCDecoder.java:47)
	at brut.androlib.res.AndrolibResources.getResPackagesFromApk(AndrolibResources.java:538)
	at brut.androlib.res.AndrolibResources.loadMainPkg(AndrolibResources.java:63)
	at brut.androlib.res.AndrolibResources.getResTable(AndrolibResources.java:55)
	at brut.androlib.Androlib.getResTable(Androlib.java:64)
	at brut.androlib.ApkDecoder.setTargetSdkVersion(ApkDecoder.java:209)
	at brut.androlib.ApkDecoder.decode(ApkDecoder.java:92)
	at brut.apktool.Main.cmdDecode(Main.java:165)
	at brut.apktool.Main.main(Main.java:81)
更多

转载,英文原文链接

网上很多人宣称可以给windows系统提供一个通用adb驱动,但他们通常只是重新打包一下Google提供给亲儿子Nexus设备的USB驱动包,通过修改android_winusb_inf文件,添加大量USB的Vendor ID和Product ID进去。为什么这样还做不到真正的通用呢?因为如果你设备的ID信息没有添加进去,这样的驱动并不能驱动你的设备。

然而微软的系统提供一种实现通用的驱动的方法。给一个设备寻找相应驱动的时候,windows系统可以通过硬件ID(例如:USB的Vendor ID和Product ID),也可以通过兼容ID(例如:InterfaceClassClassID,InterfaceSubClassID和InterfaceProtocolID)。幸运的是,所有安卓adb驱动的接口ID都是一样的。

更多

1.配置环境

一台已root手机
IDA pro6.6
Android SDK

准备工作:
1.1把Android SDK添加到环境变量中
1.2把已root手机的系统中关键so拖到本地,必要时可以静态读取,获取系统函数的偏移地址。
例如把手机系统的system/lib的文件拖到本地debugging文件夹中。

adb pull /system/lib .\debugging\lib

1.3在IDA pro6.6中找出android_server,并把android_server放到手机system/bin中。push的时候没有root权限,可以如下操作:

adb push android_server /data/local/tmp
adb shell
su
cp /data/local/tmp/android_server /system/lib
更多

本文主要参考博客:
Android4.0内存Dex数据动态加载技术
APK加壳【2】内存加载dex实现详解
CSDN的大牛写的博客太简洁了,内存动态加载主要参考taoyuanxiaoqi的博文,写得比较详细。我的上一篇文章提到使用DexClassLoader函数,把apk文件加载进来,不过这样的做法会导致apk文件躺在文件系统中,这样的做法并不安全,在4.0之后,可以通过封装Dalvik_dalvik_system_DexFile_openDexFile_bytearray函数,可以在解密出dex文件的byteArray数组后,不需要保存到文件系统的路径上,直接通过4.0的函数在内存中读取。
参考博客他们的做法是,通过修改DexShellTool,并不是把payload.apk拼接到unshell.dex的后面,只是把payload.apk的classes.dex拼接到unshell.dex的后面。然后通过读取出classes.dex数组,并不保存到文件系统中,实现在内存中动态加载。
但是我比较懒,不想修改DexShellTool,还是把payload.apk拼接到后面,然后把payload.apk解压放到文件系统中,然后把里面的classes.dex数组读出来,这样进行动态加载,主要是想验证Dalvik_dalvik_system_DexFile_openDexFile_bytearray函数,文件系统还是躺着一个apk。

1.配置环境

本文的编译环境如下:
Android Studio 1.2.1.1
JDK 1.7.0_79
SDK
NDK
跟我的上一篇文章的环境是一样的,由于taoyuanxiaoqi的博文写的比较详细,代码我就不一一copy了,主要说一下编译过程中可能由于编译版本不同而提示的错误。

更多

本文主要参考博客:
Android APK加壳技术方案【2】
APK加壳【1】初步方案实现详解
由于之前没有接触过安卓编程,所以即便有两篇这么详细的教程,但是还是走了不少弯路,都折腾了大概一个星期左右。而且两个博主都没有放出demo,所以就想回顾一下这个学习的过程,并给出一个Demo。

1.配置环境

本文的编译环境如下:
Android Studio 1.2.1.1
JDK 1.7.0_79
SDK
NDK
Android Studio都出了这么久了,应该都没有什么bug了;JDK网上的人都说不要选择java8,用java7就够了;然后SDK是必须的,NDK是用来编译底层c/c++的共享库的。
建议大家把上面两个博主的前后几篇文章都看一下,因为原理和实现都已经描述的很清楚了。

更多