发表于 | 分类于

总结

  1. 基本都是使用DexClassLoader进行加载，构造函数的参数分别是：apk/dex/jar路径、缓存oat的路径（已无效）、lib路径、父类加载器。只是加载dex和lib，其它资源不会加载。dex中全部java类载入。
  2. 加载时注意权限，api23以后权限写在清单里是没有效果的（如sd卡读写权，只是能开启但不会自动开启），开启需要写代码询问或者手动去设置中开启清单申请的。没有权限会直接抛出一般错误
  3. 查看错误原因时要逐层向父类找，比如找不到加载类错误的父类可能抛出的是未加载dex

壳加载方案：
因为需要原apk的各种manifest声明、资源、lib、以及权限问题，所以一般在原apk中进行修改，在manifest中加入最早运行的类application的自定义声明，并将原application名保存，将原apk的资源、dex加密。放入自己的dex（一般包含原dex）、so到apk中。在自己的dex-application中加载so。so内解密资源、解密dex、加载dex。之后替换运行原本application即可。

阅读全文 »

发表于 | 分类于

前言

自制rom才是通杀
adb shell ps可看全部进程。adb shell 后ps却不行….
adb shell dumpsys activity top |more 可以直接显示最上层应用的详细信息，包名、id、pid都可以查看到。（less和more在前是打开文件用的，想用其功能显示输出要用管道）

阅读全文 »

发表于 | 分类于

逆向加固应用

  1. 四大组件如果想要使用，必须在androidmanifest.xml中声明。因此不论如何加固，四大组件名字都会摆出来（如何加固？要知道为何四大组件名字必须写在xml中），但application可以改，并动态加载application。
  2. libdvm加载dex用的dvmDexFileOpenPartial，360加固自己实现了这个函数，art如何加载的？art也能调用360实现的这个函数？art与dvm开放的接口相同。相同又是如何做到完整替换的？-针对的是java字节码。需要阅读双方源码。
  3. ida导入头是用读取文件，执行脚本用shift+F2
  4. 最好的过一般反调试的方法是改系统源码。
  5. webview的js可访问自定义的java对象，用来提供前端操控本机app的内部行为，相当于自定义了一个浏览器接口。同时带来了很多安全问题，注册js对象名时一般要加密-获取该名称即可调用内部接口，加密后是知道开放的对象是什么但不知道用什么名字调用。获取该字串：java层调试需要从头附加不容易过壳。（java如何附加到运行一半的app中调试？）修改smali前面的壳容易检测出来，前端js遍历全部对象挨个调用可以不获取字串调用，仿造java层加载so调用加密方法可以获取字串。反正要求是给定字串加密后为所需，固定的数据，不用分析加密过程取得结果就行。
  6. adb可以帮助输入内容等与屏幕交互，点击输入框后用adb shell input text “”即可。
  7. 书中例题就是考一个提供给js接口的安全性。
  8. 最好的dump dex也是修改android源码。
  9. 现在的app都是做成了浏览器开放接口给js调用，所以需要研究webview或是自定义view的详细用法与原理！！！

爱加密

  1. 反调试一般为了阻止你一步dump关键函数，可以通过在常见反调试点下断的方式绕过，比如fopen，gets等。当然最好的dump和过反调试方式还是改android内核源码。（做一个必须-简直无敌）
  2. ida可以用G直接搜索全局符号表找到指定函数
  3. ida的hex-view可以改内存空间，edit改完记得点apply change。
  4. ida也可以修改寄存器等
  5. 还原apk：把manifest中的application name还原，assets不需要的删除，apktool回编译，把dex换成dump出来的，签名。
  6. dvm加载so用的dvmloadnativecode函数

android漏洞

  1. 文件解压漏洞，解压的文件名可以含任意字符，所以可以用../进入data/data（此目录下各应用用户为各应用本身，所以有7权，此外data/app下各文件属于system用户，但其他用户有执行和阅读权，所以可打开并执行）覆盖/自定义文件
  2. 屏幕录取权限不易发现漏洞，可加windowmanager.layoutparams.FLAG_SECURE使自己应用安全防录制与截屏

Wannacry加密病毒

  1. 通过获取windowmanager获取权限建立浮窗为顶层造成勒索，同时用DeviceAdminReceiver修改锁屏密码使其重启也不知密码
  2. 可怕的是sd卡权限，sd卡权限默认直接就对应用开放了，因此该应用把sd卡内的数据全部加密。经测试我的模拟器在完全没有提醒的情况下虚拟sd卡被破坏。

对于所有平台，一般公共数据都是开放的，sd卡、硬盘等，所有软件都可以使用api访问这部分内容，因此任意软件都可以修改加密其内容形成勒索，执行软件时一定要注意。

发表于 | 分类于

DDMS提供了强大的应用监控能力
https://blog.csdn.net/songyi160/article/details/53107245

有关逆向方面可用的：

应用信息

只有开启了debugger模式的应用才可以显示，点击可开启8700端口调试。
调试端在pc，用来与被调试服务端（android）通过adb交互，8600+这个端口是调试服务端在本地开开用来给调试器jdb等使用的，8700是备用公共的。可以用adb或ddms将这个端口转发到pc端

控件

加载layout时id名标记，用R.id数字在资源中查找对应名称，用名称找到控件。读资源时应该直接分析成id。混淆可改名。
通过代码定位控件：可以通过id在public或R中对应名字，后用名字在layout中对应。
通过控件定位代码：layout找到名字public找到id，再在代码中找id

通过DDMS的Dump View可以直观查看当前页面layout布局，并可以查看控件信息，名字。

logcat

完整的logcat输出，完整的筛选功能。

文件

直观的文件任意查看，导出导入。

发表于 | 分类于

so中节加密

c语言处理文件格式写好写点：
注意点：

  1. 加密时遍历节找到名字（存的是相对于字串节的地址偏移）加密，并将节偏移存到头的节偏移处，节大小和页数存到头的入口点处，为了方便解密时查找，同时这俩项对so加载无用。破坏section，但可从p节读出结构。
  2. 解密函数在init中解密，用属性声明为特殊段，init执行时文件已经加载，可以修改。
  3. linker等native的加载源码需要熟
  4. 头、节等都是基于装载地址映射的，节等按头加载，代码和数据用重定位定位。因此修改节内数据、节数据、头数据只要文件偏移+装载地址即可。
  5. c语言对文件格式读取与细节处理比java来的方便。清晰
  6. 操作步骤：写好so与解密函数，编译后用加密程序处理。
阅读全文 »

发表于 | 分类于

本机测试成功

过程简介

3部分：

  1. 源程序apk
  2. 加壳程序，将apk直接附着于解壳程序apk的dex后
  3. 解壳程序，读出dex后的程序并解密加载运行。重点！主要是用反射调用系统java层。详细需要看aosp。

操作步骤：编写源apk，将源apk与解壳的dex用加密程序合并，将dex复制回解壳apk中。签名。

360加固中：将dex中藏有源dex，但资源并没加密，运行自己的脱壳程序在so中解密源加载运行。因为data区应该是dex最后的区了，所以用data_size+data_off判断是否藏有其它。
art运行模式对这种加载模式有什么影响？一样有可以加载dex？

阅读全文 »

发表于 | 分类于

非虫的加固总结：http://www.mottoin.com/89035.html

非root hook：
hook需要更改目标内存空间，应用进程本身当然可以，该进程是属于一个用户的。别的用户想动其它用户的进程就需要权限了，同一个用户动自己的其它进程当然也可以。因此原理上免root hook可实现。

动态符号表dynsym hook

hook掉关键函数（jni_Onload）从而阻止一般断点。基本思路：

  1. 获取动态库基址（文件头中无，在加载时系统生成的信息中）
  2. 计算加载头表program header table实际地址
  3. 取动态信息表dynameic地址
  4. 取dynsym地址（动态导出导入符号表，有so中定义的各种符号地址）
  5. 遍历符号表，找到地址对应后更改

ps：代码段一般都只会设置为可读可执行的，因此需要使用mprotect改变内存页为可读可写可执行。
GOT是将代码段所使用的其它模块的函数地址、全局变量地址提出，用别的模块中的函数填入，从而间接使用外部函数。
外部引用查的是什么?如果是提前加载好的全局表应该改节无用，应该是用时查找节。因为该指针函数可以被使用说明全局表已经加载过了。但这个全局表没有给jni用？linker、jni的具体查找函数并调用过程！
将指向后的地址加跳转也行。

相关结构体：

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
程序表头：
struct Elf32_Phdr {
  Elf32_Word p_type;   // Type of segment
  Elf32_Off  p_offset; // File offset where segment is located, in bytes
  Elf32_Addr p_vaddr;  // Virtual address of beginning of segment
  Elf32_Addr p_paddr;  // Physical address of beginning of segment (OS-specific)
  Elf32_Word p_filesz; // Num. of bytes in file image of segment (may be zero)
  Elf32_Word p_memsz;  // Num. of bytes in mem image of segment (may be zero)
  Elf32_Word p_flags;  // Segment flags
  Elf32_Word p_align;  // Segment alignment constraint
};
dynmiac每项：
typedef struct dynamic {
    Elf32_Sword d_tag;
    union {
    Elf32_Sword d_val;
    Elf32_Addr d_ptr;
    } d_un;
} Elf32_Dyn;
符号表每项：
typedef struct elf32_sym {
    Elf32_Word st_name;
    Elf32_Addr st_value;
    Elf32_Word st_size;
    unsigned char st_info;
    unsigned char st_other;
    Elf32_Half st_shndx;
} Elf32_Sym;

通过符号表hook got

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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
#include <jni.h>
#include <dlfcn.h>
#include <elf.h>
#include <android/log.h> 
#include <sys/mman.h>
#define LOGD(...) ((void)__android_log_print(ANDROID_LOG_DEBUG, "ror_got_hook", __VA_ARGS__))
#define MEM_PAGE_SIZE 4096
#define MEM_PAGE_MASK (MEM_PAGE_SIZE-1)
#define MEM_PAGE_START(x)  ((x) & ~MEM_PAGE_MASK)
#define MEM_PAGE_END(x)    MEM_PAGE_START((x) + (MEM_PAGE_SIZE-1))
#define ElfW(type) Elf32_ ## type
JNIEXPORT jint JNICALL ReturnGiveValue(int val)
{
    return val;
}
JNIEXPORT jint JNICALL ReturnFakeValue(int val)
{
    return val * 100;
}
int __attribute__((constructor))  gothook()
{
    //获取动态库基值
    void* testlib = dlopen("/data/data/com.test.test/libtest.so",RTLD_LAZY);
    int nBase = *(int*)(testlib+0x8C);
    LOGD("nBase : %x",nBase);
    //计算program header table实际地址
    ElfW(Ehdr) *header = (ElfW(Ehdr)*)(nBase);
    if (memcmp(header->e_ident, "\177ELF", 4) != 0) {
        return 0;
    }
    int phOffset = header->e_phoff;
    int phNumber = header->e_phnum;
    int phPhyAddr = phOffset + nBase;
    LOGD("phOffset  : %x",phOffset);
    LOGD("phNumber  : %x",phNumber);
    LOGD("phPhyAddr : %x",phPhyAddr);
    int i = 0;
    ElfW(Phdr)* phdr_table = (ElfW(Phdr)*)(nBase + phOffset);
    if (phdr_table == 0)
    {
        LOGD("phdr_table address : 0");
        return 0;
    }
/*
// Program header for ELF32.
struct Elf32_Phdr {
  Elf32_Word p_type;   // Type of segment
  Elf32_Off  p_offset; // File offset where segment is located, in bytes
  Elf32_Addr p_vaddr;  // Virtual address of beginning of segment
  Elf32_Addr p_paddr;  // Physical address of beginning of segment (OS-specific)
  Elf32_Word p_filesz; // Num. of bytes in file image of segment (may be zero)
  Elf32_Word p_memsz;  // Num. of bytes in mem image of segment (may be zero)
  Elf32_Word p_flags;  // Segment flags
  Elf32_Word p_align;  // Segment alignment constraint
};
*/
    //遍历program header table，ptype等于2即为dynameic，获取到p_offset
    unsigned long dynamicAddr = 0;
    unsigned int dynamicSize = 0;
    for (int i = 0; i < phNumber; i++)
    {
        if (phdr_table[i].p_type == PT_DYNAMIC)
        {
            dynamicAddr = phdr_table[i].p_vaddr + nBase;
            dynamicSize = phdr_table[i].p_memsz;
            break;
        }
    }
    LOGD("Dynamic Addr : %x",dynamicAddr);
    LOGD("Dynamic Size : %x",dynamicSize);
/*
typedef struct dynamic {
    Elf32_Sword d_tag;
    union {
    Elf32_Sword d_val;
    Elf32_Addr d_ptr;
    } d_un;
} Elf32_Dyn;
*/
    //开始遍历dynamic段结构，d_tag为6即为符号表地址
    int systemTableAddr = 0;
    ElfW(Dyn)* dynamic_table = (ElfW(Dyn)*)(dynamicAddr);
    for(i=0;i < dynamicSize / 8;i ++)
    {
        int val = dynamic_table[i].d_un.d_val;
        if (dynamic_table[i].d_tag == 6)
        {
            systemTableAddr = val + nBase;
            break;
        }
    }
    LOGD("System Table Addr : %x",systemTableAddr);
/*
typedef struct elf32_sym {
    Elf32_Word st_name;
    Elf32_Addr st_value;
    Elf32_Word st_size;
    unsigned char st_info;
    unsigned char st_other;
    Elf32_Half st_shndx;
} Elf32_Sym;
*/
    //遍历符号表，查找符号表中标记的ReturnGiveValue函数地址，替换为ReturnFakeValue的地址
    int giveValuePtr = 0;
    int fakeValuePtr = 0;
    int fakeFunc = (int)ReturnFakeValue - nBase;
    int giveFunc = (int)ReturnGiveValue - nBase;
    i = 0;
    LOGD("fakeFunc Addr : %x",fakeFunc);
    LOGD("giveFunc Addr : %x",giveFunc);
    void* pstart = (void*)MEM_PAGE_START(((ElfW(Addr))systemTableAddr));
    mprotect(pstart,MEM_PAGE_SIZE,PROT_READ | PROT_WRITE | PROT_EXEC);
    ElfW(Sym)* symTab = (ElfW(Sym)*)(systemTableAddr);
    while(1)
    {
        LOGD("func Addr : %x",symTab[i].st_value);
        if(symTab[i].st_value == giveFunc)
        {
            symTab[i].st_value = fakeFunc;
            LOGD("New Give func Addr : %x",symTab[i].st_value);
            break;
        }
        i ++;
    }
    mprotect(pstart,MEM_PAGE_SIZE,PROT_READ | PROT_EXEC);
    return 0;
}

通过重定位表hook got

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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
#include <jni.h>
#include <dlfcn.h>
#include <elf.h>
#include <android/log.h> 
#include <sys/mman.h>
#define LOGD(...) ((void)__android_log_print(ANDROID_LOG_DEBUG, "ror_got_hook", __VA_ARGS__))
#define MEM_PAGE_SIZE 4096
#define MEM_PAGE_MASK (MEM_PAGE_SIZE-1)
#define MEM_PAGE_START(x)  ((x) & ~MEM_PAGE_MASK)
#define MEM_PAGE_END(x)    MEM_PAGE_START((x) + (MEM_PAGE_SIZE-1))
#define ElfW(type) Elf32_ ## type
char str[] = "return give value";
JNIEXPORT void JNICALL ReturnGiveValue()
{
    char logStr[255] = {0};
    strncpy(logStr,str,strlen(str));
    LOGD("%x",(unsigned int)strncpy);
    LOGD("show : %s",logStr);
}
int my_strncpy(char* s1, char* s2, int n)
{
    memcpy(s1,"return fake value\0",18);
    LOGD("%x",(unsigned int)strncpy);
    return 1;
}
int __attribute__((constructor)) gothook()
{
    //获取动态库基值
    void* testlib = dlopen("/data/local/tmp/libtest.so",RTLD_LAZY);
    int nBase = *(int*)(testlib+0x8C);
    LOGD("nBase : %x",nBase);
    //计算program header table实际地址
    ElfW(Ehdr) *header = (ElfW(Ehdr)*)(nBase);
    if (memcmp(header->e_ident, "\177ELF", 4) != 0) {
        return 0;
    }
    ElfW(Phdr)* phdr_table = (ElfW(Phdr)*)(nBase + header->e_phoff);
    if (phdr_table == 0)
    {
        LOGD("phdr_table address : 0");
        return 0;
    }
    size_t phdr_count = header->e_phnum;
    LOGD("phdr_count : %d", phdr_count);
    //遍历program header table，ptype等于PT_DYNAMIC即为dynameic，获取到p_offset
    unsigned long dynamicAddr = 0;
    unsigned int dynamicSize = 0;
    for (int i = 0; i < phdr_count; i++)
    {
        if (phdr_table[i].p_type == PT_DYNAMIC)
        {
            dynamicAddr = phdr_table[i].p_vaddr + nBase;
            dynamicSize = phdr_table[i].p_memsz;
            break;
        }
    }
    LOGD("Dynamic Addr : %x",dynamicAddr);
    LOGD("Dynamic Size : %x",dynamicSize);
/*
typedef struct dynamic {
    Elf32_Sword d_tag;
    union {
    Elf32_Sword d_val;
    Elf32_Addr d_ptr;
    } d_un;
} Elf32_Dyn;
*/
    ElfW(Dyn)* dynamic_table = (ElfW(Dyn)*)(dynamicAddr);
    unsigned long jmpRelOff = 0;
    unsigned long strTabOff = 0;
    unsigned long pltRelSz = 0;
    unsigned long symTabOff = 0;
    int i;
    for(i=0;i < dynamicSize / 8;i ++)
    {
        int val = dynamic_table[i].d_un.d_val;
        if (dynamic_table[i].d_tag == DT_JMPREL)
        {
            jmpRelOff = val;
        }
        if (dynamic_table[i].d_tag == DT_STRTAB)
        {
            strTabOff = val;
        }
        if (dynamic_table[i].d_tag == DT_PLTRELSZ)
        {
            pltRelSz = val;
        }
        if (dynamic_table[i].d_tag == DT_SYMTAB)
        {
            symTabOff = val;
        }
    }
	//重定位表
    ElfW(Rel)* rel_table = (ElfW(Rel)*)(jmpRelOff+nBase);
    LOGD("jmpRelOff : %x",jmpRelOff);
    LOGD("strTabOff : %x",strTabOff);
    LOGD("symTabOff : %x",symTabOff);
    //遍历查找要hook的导入函数，这里以strncpy做示例
    for(i=0;i < pltRelSz / 8;i++)
    {
		//取重定位表每一项的符号表下标24 8 位分开功能
        int number = (rel_table[i].r_info >> 8) & 0xffffff;
		//符号表下标找到对应项
        ElfW(Sym)* symTableIndex = (ElfW(Sym)*)(number*16 + symTabOff + nBase);
		//找到对应名字
        char* funcName = (char*)(symTableIndex->st_name + strTabOff + nBase);
    //  LOGD("Func Name : %s",funcName);
        if(memcmp(funcName,"strncpy",7) == 0)
        {
            void* pstart = (void*)MEM_PAGE_START(((ElfW(Addr))rel_table[i].r_offset + nBase));
            mprotect(pstart,MEM_PAGE_SIZE,PROT_READ | PROT_WRITE | PROT_EXEC);
            LOGD("r_off : %x",rel_table[i].r_offset + nBase);
            LOGD("my_strncpy : %x",my_strncpy);
			//要重定位的位置位于got处，修改其地址。
            *(unsigned int*)(rel_table[i].r_offset + nBase) = my_strncpy;
        }
    }
    return 0;
}

资源混淆

resources.arsc这个文件是存放在APK包中的，他是由AAPT工具在打包过程中生成的，他本身是一个资源的索引表，里面维护者资源ID、Name、Path或者Value的对应关系。https://www.jianshu.com/p/3cc131db2002
通过resources.arsc这个桥梁，使R.类+名（这个组合名可以锁定资源，给人看的，二进制中只是id）的int值还原到type+名，从而可以用android框架寻找加载资源。
例如value/string.xml添加名-值生成的R.string.名使用该值，编译为id。使用时resources.arsc中通过id找到对应的分类与名，value下的几个分类都被打包在resources.arsc里了，所以string资源可以直接在resources.arsc中通过种类加名找到。还有些xml被加密放在原处（layout），还有些没加密放原处（mipmap）：这些按类就是文件夹，名就是文件名路径就能查找到。在Android系统中，Resources类可以根据ID来查找资源，而AssetManager类根据文件名来查找资源
混淆只是将还原时的type+名改变，同时将res中文件名改变。没有做到资源加密。
针对图片加密：当图片资源放在drawable中的时候，能有相应的Id去解析： BitmapFactory.decodeResource(res, id)
如果放置在assets下，就需要根据文件的名字去解析（Android提供AssetManager）。
若使用id解析，其实是框架中的Resources类先根据ID来找到资源文件名称，然后再将该文件名称交给AssetManager类来打开对应的文件的。但是这个过程由框架实现无法更改，所以若自己写应用时加密方式可采用手动从assets中提取自定义加密文件。
若针对任意apk如何加密资源？（所有资源-layout、string、图片特别关注）其实这些都可以手动加载，但是如何在不大量改代码情况下实现自动化。

发表于 | 分类于

非虫的文章：http://www.mottoin.com/89035.html

Android Java混淆(ProGuard)

该开源项目用来混淆java字节码，现已集成在sdk中：SDK\tools\proguard。
使用：build.gradle中配置：

1
2
3
4
5
buildTypes {
        release {
            minifyEnabled true //开启混淆
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'//指定混淆配置文件为 proguard-rules.pro
}

该混淆配置文件位于build同目录下。

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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
#下面是常见的proguard.cfg配置项
#指定代码的压缩级别
-optimizationpasses 5
#包名不混合大小写
-dontusemixedcaseclassnames
#不去忽略非公共的库类
-dontskipnonpubliclibraryclasses
# 指定不去忽略非公共的库的类的成员
-dontskipnonpubliclibraryclassmembers
#优化  不优化输入的类文件
-dontoptimize
#预校验
-dontpreverify
#混淆时是否记录日志
-verbose
# 混淆时所采用的算法
-optimizations !code/simplification/arithmetic,!field/*,!class/merging/*
#保护注解
-keepattributes *Annotation*
#忽略警告
-ignorewarning
##记录生成的日志数据,gradle build时在本项目根目录输出##
#apk 包内所有 class 的内部结构
-dump class_files.txt
#未混淆的类和成员-printseeds seeds.txt
#列出从 apk 中删除的代码
-printusage unused.txt
#混淆前后的映射-printmapping mapping.txt
########记录生成的日志数据，gradle build时 在本项目根目录输出-end#####
#需要保留的东西
# 保持哪些类不被混淆
-keep public class * extends android.app.Fragment
-keep public class * extends android.app.Activity
-keep public class * extends android.app.Application
-keep public class * extends android.app.Service
-keep public class * extends android.content.BroadcastReceiver
-keep public class * extends android.content.ContentProvider
-keep public class * extends android.app.backup.BackupAgentHelper
-keep public class * extends android.preference.Preference
-keep public class * extends android.support.v4.**
-keep public class com.android.vending.licensing.ILicensingService
#如果有引用v4包可以添加下面这行
-keep public class * extends android.support.v4.app.Fragment
##########JS接口类不混淆，否则执行不了
-dontwarn com.android.JsInterface.**
-keep class com.android.JsInterface.** {*; }
#极光推送和百度lbs android sdk一起使用proguard 混淆的问题#http的类被混淆后，导致apk定位失败，保持apache 的http类不被混淆就好了
-dontwarn org.apache.**
-keep class org.apache.**{ *; }
-keep public class * extends android.view.View {        
  public <init>(android.content.Context);        
  public <init>(android.content.Context, android.util.AttributeSet);        
  public <init>(android.content.Context, android.util.AttributeSet, int);
  public void set*(...);    
 }
#保持 native 方法不被混淆
-keepclasseswithmembernames class * {        
  native <methods>;    
}
#保持自定义控件类不被混淆
-keepclasseswithmembers class * {        
  public <init>(android.content.Context, android.util.AttributeSet);    
}
#保持自定义控件类不被混淆
-keepclassmembers class * extends android.app.Activity {       
  public void *(android.view.View);    
}
#保持 Parcelable 不被混淆
-keep class * implements android.os.Parcelable {      
  public static final android.os.Parcelable$Creator *;    
}
#保持 Serializable 不被混淆
-keepnames class * implements java.io.Serializable
#保持 Serializable 不被混淆并且enum 类也不被混淆
-keepclassmembers class * implements java.io.Serializable {        
    static final long serialVersionUID;        
    private static final java.io.ObjectStreamField[] serialPersistentFields;
    !static !transient <fields>;        
    !private <fields>;        
    !private <methods>;        
    private void writeObject(java.io.ObjectOutputStream);        
    private void readObject(java.io.ObjectInputStream);        
    java.lang.Object writeReplace();        
    java.lang.Object readResolve();    
}
#保持枚举 enum 类不被混淆 如果混淆报错，建议直接使用上面的 -keepclassmembers class * implements java.io.Serializable即可
-keepclassmembers enum * {        
      public static **[] values();        
      public static ** valueOf(java.lang.String);    
}
-keepclassmembers class * {        
      public void *ButtonClicked(android.view.View);    
}
#不混淆资源类
-keepclassmembers class **.R$* {        
      public static <fields>;    
}
#避免混淆泛型 如果混淆报错建议关掉    
#–keepattributes Signature
######混淆保护自己项目的部分代码以及引用的第三方jar包library########
#如果引用了v4或者v7包
-dontwarn android.support.**
#如果用到Gson解析包的，直接添加下面这几行就能成功混淆，不然会报错    
#gson    
#-libraryjars libs/gson-2.2.2.jar    
-keepattributes Signature    
# Gson specific classes    
-keep class sun.misc.Unsafe { *; }    
# Application classes that will be serialized/deserialized over Gson    
-keep class com.google.gson.examples.android.model.** { *; }  
#客户端代码中的JavaBean(实体类)的类名与其字段名称全部变成了a、b、c、d等等字符串，这与服务端返回的json字符串中的不一致，导致解析失败。所以，解决的办法是：在进行混淆编译进行打包apk的时候，过滤掉存放所有JavaBean（实体类)的包不进行混淆编译      
-keep class com.android.model.** {*;}
####混淆保护自己项目的部分代码以及引用的第三方jar包library-end####

签名验证

在java&native代码中加入验证签名方式。检测是否是自己的签名。

动态加载dex

如何动态加载dex？
native层的代码拥有更高权限，可以看根目录等。

Android 系统提供了 DexClassLoader 来支持在程序运行过程中动态加载包含 classes.dex的.jar 或者.apk 文件。DexClassLoader 实例可以继续加载dex中的类，后可通过反射调用，调用的代码中需要的类会自动加载执行？

检测frida

https://bbs.pediy.com/thread-217482.htm?source=1
frida开源！必看相关hook模块。

反调试

  1. IDA调试端口检测:读取/proc/net/tcp，查找IDA远程调试所用的23946端口，若发现说明进程正在被IDA调试。
  2. 调试器进程名检测,遍历进程，查找固定的进程名，找到说明调试器在运行。
  3. 父进程名检测 有的时候不使用apk附加调试的方法进行逆向，而是写一个.out可执行文件直接加载so进行 调试，这样程序的父进程名和正常启动apk的父进程名是不一样的。
    测试发现：
    （1）正常启动的apk程序：父进程是zygote
    （2）调试启动的apk程序：在AS中用LLDB调试发现父进程还是zygote
    （3）附加调试的apk程序：父进程是zygote
    （4）vs远程调试 用可执行文件加载so:父进程名为gdbserver
    结论：父进程名非zygote的，判定为调试状态
  4. 自身进程名检测 :也是解决上面问题的。
  5. apk线程检测 ：同样.out加载so来脱壳的场景正常apk进程一般会有十几个线程在运行(比如会有jdwp线程)，自己写可执行文件加载so一般只有一个线程，可以根据这个差异来进行调试环境检测。
  6. apk进程fd文件检测：根据/proc/pid/fd/路径下文件的个数差异，判断进程状态。 （apk启动的进程和非apk启动的进程fd数量不一样） （apk的debug启动和正常启动，进程fd数量也不一样）
  7. 安卓系统自带调试检测函数：
    java层：android.os.Debug.isDebuggerConnected();
    so层： libdvm.so中的dvmDbgIsDebuggerConnected()函数，调用他就能得知程序是否被调试。dlopen(/system/lib/libdvm.so) dlsym(_Z25dvmDbgIsDebuggerConnectedv)这个函数可能不让用了。
    art：art模式下，结果存放在libart.so中的全局变量gDebuggerActive中， 符号名为_ZN3art3Dbg15gDebuggerActiveE
  8. ptrace检测：每个进程同时刻只能被1个调试进程ptrace，再次p自己会失败。1 主动ptrace自己,根据返回值判断自己是否被调试了。2 或者多进程ptrace。
  9. 函数hash值检测：so文件中函数的指令是固定，但是如果被下了软件断点，指令就会发生改变(断点地址被改 写为bkpt断点指令)，可以计算内存中一段指令的hash值进行校验，检测函数是否被修改或 被下断点。
  10. 断点指令检测：上面说了，如果函数被下软件断点，则断点地址会被改写为bkpt指令，可以在函数体中搜索bkpt指令来检测软件断点。
  11. 系统源码修改检测：安卓native下流行的反调试方案是读取进程的status或stat来检测tracepid，原理是调试状态下的进程tracepid不为0。对于这种调试检测手段，彻底的绕过方式是修改系统源码后重新编译，让tracepid永远为 0。对抗这种bypass手段，我们可以创建一个子进程，让子进程主动ptrace自身设为调试状态， 此时正常情况下，子进程的tracepid应该不为0。此时我们检测子进程的tracepid是否为0， 如果为0说明源码被修改了。
  12. 单步调试陷阱：
    原理：调试器从下断点到执行断点的过程分析：
    1 保存：保存目标处指令
    2 替换：目标处指令替换为断点指令
    3 命中断点：命中断点指令(引发中断 或者说发出信号)
    4 收到信号：调试器收到信号后，执行调试器注册的信号处理函数。
    5 恢复：调试器处理函数恢复保存的指令
    6 回退：回退PC寄存器
    7 控制权回归程序.
    主动设置断点指令/注册信号处理函数的反调试方案:
    1 在函数中写入断点指令
    2 在代码中注册断点信号处理函数
    3 程序执行到断点指令，发出信号 分两种情况：
    (1)非调试状态 进入自己注册的函数，NOP指令替换断点指令，回退PC后正常指令。 (执行断点发出信号—进入处理信号函数—NOP替换断点—退回PC)
    (2)调试状态 进入调试器的断点处理流程，他会恢复目标处指令失败，然后回退PC，进入死循环。
  13. 利用IDA先截获信号特性的检测
    原理： IDA会首先截获信号，导致进程无法接收到信号，导致不会执行信号处理函数。将关键流程 放在信号处理函数中，如果没有执行，就是被调试状态。
  14. 利用IDA解析缺陷反调试
    原理： IDA采用递归下降算法来反汇编指令，而该算法大的缺点在于它无法处理间接代码路径， 无法识别动态算出来的跳转。而arm架构下由于存在arm和thumb指令集，就涉及到指令集 切换，IDA在某些情况下无法智能识别arm和thumb指令，进一步导致无法进行伪代码还原。
    在IDA动态调试时，仍然存在该问题，若在指令识别错误的地点写入断点，有可能使得调试 器崩溃。（ 可能写断点 ,不知道写ARM还是THUMB ,造成的崩溃）
  15. 五种代码执行时间检测
    原理： 一段代码，在a处获取一下时间，运行一段后，再在b处获取下时间， 然后通过(b时间­a时间)求时间差,正常情况下这个时间差会非常小， 如果这个时间差比较大，说明正在被单步调试。
    做法： 五个能获取时间的api：
    time()函数 time_t结构体
    clock()函数 clock_t结构体
    gettimeofday()函数 timeval结构 timezone结构
    clock_gettime()函数 timespec结构
    getrusage()函数 rusage结构
  16. 三种进程信息结构检测
    原理： 一些进程文件中存储了进程信息，可以读取这些信息得知是否为调试状态。
    做法：
    第一种： /proc/pid/status /proc/pid/task/pid/status TracerPid非0 statue字段中写入t（tracing stop）
    第二种： /proc/pid/stat /proc/pid/task/pid/stat 第二个字段是t（T）
    第三种： /proc/pid/wchan /proc/pid/task/pid/wchan ptrace_stop
  17. Inotify事件监控dump
    原理： 通常壳会在程序运行前完成对text的解密，所以脱壳可以通过dd与gdb_gcore来dump /proc/pid/mem或/proc/pid/pagemap，获取到解密后的代码内容。
    可以通过Inotify系列api来监控mem或pagemap的打开或访问事件， 一旦发生时间就结束进程来阻止dump。

elf

  1. ELF常见HOOK方案及应用
    a) Inline hook
    b) GOT hook
    c) PRELOAD hook
    d) Linker重定位hook

  2. ELF若干种保护方案
    a) UPX壳及分析
    b) Shellcode保护方案
    c) 链接器及加载器
    d) VMP

  3. ELF混淆方案
    a) 花指令
    b) 指令乱序，使用B衔接
    c) 指令替换，替换为B指令
    d) 指令索引并且乱序，使用索引表来跳转
    e) LLVM方式混淆

  4. ELF反调试
    a) 捕捉信号
    b) 检测tracerPID
    c) 检测调试进程
    d) 处理ELF格式，阻止IDA加载
    e) 多进程守护
    f) CRC校验
    g) 调试中断指令检测（类似x86 0xCC）

  5. ELF函数加密
    a) ELF入口加解密
    b) 函数动态加解密，指令级加解密
    c) 基于加载器的函数加解密

https://bbs.pediy.com/thread-183116.htm中的：

Dex 中方法的隐藏

一种：
class段中将 DexMethod 的 methodIdx 值设为 0x0，相当于将原先的方法指向了前一个方法，因为这个是依据上一个方法架构体中Idx的偏移。
访问标志符 accessFlags 一般不需要修改，在Dex文件格式里，directMethods和 virtualMethods 是分开的。
将codeOffset 设置为前一个方法的代码偏移地址。
更新需隐藏方法的下一个方法的methodIdx，可以使用公式next_method_idx=original_next_method_idx+original_method_idx
重新计算 Dex 的 SHA1哈希值和Adler校验值，并用以更新 DexHeader，可以使用DexFixer修复 classes.dex文件
重新打包生成 APK 文件：

二种：
class段中，将相应的 directMethodsSize 或virtualMethodsSize 减 1，同时将表示该需要隐藏方法的 DexMethod 结构体中的数据全部修改为 0，这样就可以将该方法隐藏起来

读取隐藏方法：
取数据流，用反射调用 android.content.res.AssetManager.openNonAsset 方法打开当前应用程序的classes.dex文件;或者Context.getPackageCodePath()来获得当前应用程序对应的apk文件的路径，利用此路径构造ZipFile对 象 ，进而获取classes.dex的ZipEntry ，利用ZipFile的getInputStream(ZipEntry)方法获取classes.dex 的数据流。
修复 Dex 文件，将之前隐藏方法的 DexMethod 结构体恢复
将修复后的 Dex 数据使用类加载器重新加载；
搜索调用。

Dex 完整性校验

首先在代码中完成校验值比对的逻辑，此部分代码后续不能再改变，否则 CRC 值
会发生变化；
从生成的 APK 文件中提取出 classes.dex 文件，计算其 CRC 值，其他 hash 值类似；
将计算出的值放入 strings.xml 文件中。

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
1. String apkPath = this.getPackageCodePath();
 
2. Long dexCrc = Long.parseLong(this.getString(R.string.dex_crc));
 
3. try {
 
4. ZipFile zipfile = new ZipFile(apkPath);
 
5. ZipEntry dexentry = zipfile.getEntry("classes.dex");
 
6. if(dexentry.getCrc() != dexCrc){
 
7. System.out.println("Dex has been *modified!");
 
8. }else{
 
9. System.out.println("Dex hasn't been modified!");
 
10. }
 
11. } catch (IOException e) {
 
12. // TODO Auto-generated catch block
 
13. e.printStackTrace();
 
14. }

APK 完整性校验类似，不过数据放在服务器，app只是请求和处理判断。

Java 反射

Java 反射机制允许运行中的 Java 程序对自身进行检查，并能直接操作程序的内部属性或方法，可动态生成类实例、变更属性内容以及调用方法。
增加静态分析难度

字串混淆

dex中的，string中的。

代码乱序

通过goto切割代码。

APK 伪加密

根据操作系统安装apk时与普通zip文件的不同来修改apk文件。比如General purpose bit flags 第 0 位置 1

Manifest Cheating

这个方法挺好的。360中也遇见了
生成的 R.java文件中包含了相应的资源类型、名称以及对应的 id 值。资源 id 是 32bit 的整型值，格式为:0xPPTTNNNN。其中 PP 表示使用该资源的包，TT 代表该资源的类型，而 NNNN 是该类型中资源的名称。对于应用程序资源，PP 值固定为 7f，而对于被引用的系统资源包，其 PP值为 01。

Manifest Cheating 的基本原理是，在 AndroidManifest 的节点中插入一个未知id(如 0x0)，名称为 name 的属性，其值可以是一个从未定义实现的 Java 类文件名。而对AndroidManifest 的修改需要在二进制格式下进行，这样才能不会破坏之前 aapt 对资源文件的处理。由于是未知的资源 id，在应用程序运行过程中，Android 会忽略此属性。但是在使用apktool 进行重打包时，首先会将 AndroidManifest.xml 转换为明文，进而会包含名称为 name的属性，而相应的 id 信息会丢失，apktool 重打包会重新进行资源打包处理，由于该 name属性值是一个未实现的 Java 类，重打包后的应用程序在运行过程中，由于 application 节点中定义的类是先于所有其他组件运行的，若系统找不到对应的类，会出现运行时错误，Dalvik虚拟机会直接关闭。

黄皮书中的第8章

有具体的代码

  1. 代码混淆
  2. 资源混淆
  3. 签名保护
  4. 手动注册native
  5. 反调试检测

发表于 | 分类于

本次基于google官方文档下载编译：
https://source.android.com/setup/build/requirements
还有一篇详细的博客：
https://blog.csdn.net/dd864140130/article/details/51718187

相关准备

master 分支历来都是在 Ubuntu Long Term Support (LTS) 版本中进行开发和测试，采用ubuntu-14.04-desktop-amd64。试了其它14.04.4之类的，都有冲突。
master 分支事最少，带有预编译版本的 OpenJDK；因此无需另行安装。较低的版本则需要单独进行安装。

vpn

因为要下载的是谷歌官方的，所以必不可少。采用购买ssr。
先用shadowsocks启动：https://blog.csdn.net/u011774239/article/details/53905702
在应用中使用：https://github.com/Shadowsocks-Wiki/shadowsocks/blob/master/6-linux-settings.md

此后需要外网的指令加前缀

putty+telnet

远程操控：
telnet在linux的设置：https://blog.csdn.net/linux_ever/article/details/50519028

编译环境

python 2.7
make3.81
git
java环境1.8对于ubuntu14.04特殊，参考官方安装：
https://source.android.com/setup/build/initializing#installing-the-jdk
安装所需的软件包 (Ubuntu 14.04)

1
sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev libgl1-mesa-dev libxml2-utils xsltproc unzip

下载源码

https://source.android.com/setup/build/downloading
用Repo管理git指定要下载的分支。
android-8.1.0_r1支持机型较多而且较新。目前下了这个，61G

可以用shell脚本错误时自动sync

1
2
3
4
5
6
7
8
9
10
11
#!/bin/bash
#FileName source_asyn.sh
PATH=~/bin:$PATH
# 注意修改成你要编译的版本，比如这里我在mac上编译的是Android-7.1.1——r6
repo init -u https://aosp.tuna.tsinghua.edu.cn/platform/manifest -b android-7.1.1_r6
repo sync
while [$? = 1]: do
echo "=========download failed,again============"
sleep 5
repo sync
done

学习linux脚本！

编译

https://source.android.com/setup/build/building
先找到对应版本设备的二进制文件：https://developers.google.com/android/drivers
俩个都下载按说明添加到源代码树的 vendor/ 层次结构中。
之后步骤按照官方。
遇到的错误：
jack未启动错误：jack-admin start-server再接着make
Out of memory error：
输入

1
2
3
export JACK_SERVER_VM_ARGUMENTS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4096m"
out/host/linux-x86/bin/jack-admin kill-server
out/host/linux-x86/bin/jack-admin start-server

虚拟机运行

source build/envsetup.sh这句就是在配置环境变量，可以使用jack、emulator等
编译完成后直接emulator等较长时间即可在虚拟机中运行android了

fastboot刷机

编译后配置好的fastboot直接刷到实体机（因此购买谷歌官方机十分方便测试cm的mi3编译时失败…..买个google垃圾机吧…）
购买后：
google机开启设备锁编译完成后使用fastboot flashall -w直接刷机成功。

刷机后android无法访问网络：
显示已连接，但无法正常访问网络是正常的，但所有网络请求失败原因是系统时间不正确，导致服务器无法通过时间验证，在设置处设置时间即可。

打包rom

几个补充知识

Android基于Permission的安全机制：https://blog.csdn.net/luoshengyang/article/details/17131835
简记：系统文件与目录被用uid、gid划分，进程持有uid/gid，从而决定进程能否使用api或者访问文件等操作，android root后所有的root操作一定要用su提权，所以在su时检测是否给权。
system/build.prop:系统信息
default.prop：系统配置.debugger选项所在
当你获得了android的应用shell时，可以用run-as变成开了debugger权限进程的uid shell。从而越权。

android开源项目的管理：https://blog.csdn.net/luoshengyang/article/details/18195205
未看完

android编译系统：https://blog.csdn.net/luoshengyang/article/details/18466779
android的make由一个mk文件，include其它mk文件组成。只执行一个。

android系统的各镜像分析：https://blog.csdn.net/luoshengyang/article/details/20501657
一个是正常的系统，它由boot.img、system.img、ramdisk.img和userdata.img等组成，另外一个就是recovery系统，由recovery.img组成。
boot.img启动其它几个，另一个系统是由recovery启动全部。
通过对比Android正常使用时的系统和进行升级时使用的Recovery系统，我们就可以对运行Linux系统的移动设备（或者说嵌入式设备）世界窥一斑而知全豹，实际上我们只需要有一个BootLoader、一个Linux Kernel，以及一个Ramdisk，就可以将它们运行起来。Ramdisk属于用户空间的范畴，它里面主要包含了Linux Kernel启动完成时所要加载的根文件系统。这个根文件系统的作用就是为整个系统提供一个init程序，以便Linux Kernel可以将控制权从内核空间转移到用户空间。系统提供什么样的功能给用户使用主要取决于在用户空间层运行了哪些服务和守护进程。这些服务守护进程都是直接或者间接地由init进程启动的。例如，对于recovery系统来说，它最主要提供的功能就是让用户升级系统，也就是它的主要用户空间服务就是负责执行长级任务的recovery程序。又如，我们正常使用的Android系统，它的主要用户空间服务和守护进程都是由system.img镜像提供的，此外，我们还可以通过userdata.img镜像来安装第三方应用来丰富手机的功能。因此，我们也可以说，init进程启动的服务决定了系统的功能。当然 ，这些功能是建立是硬件的基础之上的。

CM ROM

androidROM刷机：https://blog.csdn.net/luoshengyang/article/details/29688041
下载编译需要前几篇的知识：repo和编译系统
用户正常使用Android设备时的系统，主要是包含有两个分区：System分区和Boot分区。System分区包含有Android运行时框架、系统APP以及预装的第三方APP等，而Boot分区包含有Kernel和Rootfs
fastboot为bootloader的一种交互启动方式，可以刷recover和普通模式，recovery则是可以刷普通模式。
recover与普通模式则是俩个系统。
关于cm：
2016年12月23日，Cyanogen公司宣布他们关闭CyanogenMod的服务器
CyanogenMod随即宣布会进行转移，并更名为LineageOS

于是编译小米3的lineageos

Cancro是mi3/4 ：小米3的电信版和小米4移动版，刷机包前缀都是cancro
https://www.cnblogs.com/jiaoxiake/p/6875864.html 好的下载编译教程
https://github.com/LineageOS 其git仓库
https://www.lineageos.org/ 其官网
https://download.lineageos.org/cancro lineageos对小米的支持
https://wiki.lineageos.org/devices/cancro lineageos对mi3的信息
https://wiki.lineageos.org/devices/cancro/build 官方构建方法
https://wiki.lineageos.org/devices/cancro/install 官方刷机方法

一：找到目标测试：
在官网的支持https://download.lineageos.org/cancro上找到其编译好的镜像测试-同时按博客中的去git中查找是否存在源码与设备是否开源
刷机-adb可以在Android和恢复模式下工作
因为这个机子只能支持到14.1也就是android7.0.想测试更高版本的源代码请买google官方机
测试刷机成功

二：下载源代码
参考：https://www.cnblogs.com/jiaoxiake/p/6875864.html
https://wiki.lineageos.org/devices/cancro/build
远程连接telent
下载构建包，注意和官方的环境有所不同，不要重用
sudo apt-get install bc bison build-essential ccache curl flex g++-multilib gcc-multilib git gnupg gperf imagemagick lib32ncurses5-dev lib32readline-dev lib32z1-dev liblz4-tool libncurses5-dev libsdl1.2-dev libssl-dev libwxgtk2.8-dev libxml2 libxml2-utils lzop pngcrush rsync schedtool squashfs-tools xsltproc zip zlib1g-dev
由于需要vpn所以一直用root权操作，注意PATH配置，环变与变量是和shell绑定的，不是用户。
其它步骤一样。直到repo sync

三：编译
获取设备文件除了breakfast。还有单独的项目提供各设备的文件
https://github.com/TheMuppets
在.repo/loccal_mainifest/roomsevice.xml 文件中新增一行：

1
<project name="TheMuppets/proprietary_vendor_xiaomi" path="vendor/xiaomi" remote="github" revision="cm-14.1"/>

然后执行repo sync 同步

编译失败，java-doc:错误找不到okhttp.connectionpool的类文件。
未找到解决方法。

发表于 | 分类于

出题人博客：https://blog.csdn.net/u011247544

  1. cygwin可运行linux程序如readlef来查看elf文件。
  2. 还配置了开源项目LIEF用py解析elf

出题人写的got表hook：https://blog.csdn.net/u011247544/article/details/78564564
有续

1
int __attribute__((constructor))  gothook()

经解析在init_array中被指向。
且type为E

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
SHT_NULL     = 0: 该值表示该节是一个无效(非活动)的节头,它没有对应的节;该节头中的其它成员也都是无意义的;
SHT_PROGBITS = 1: 该值表示该节所包含的信息是由程序定义的,该节内容的格式和含义都是由程序来决定的;
SHT_SYMTAB   = 2: Symbol table;SHT_SYMTAB和SHT_DYNSYM这两类节中都含有符号表;目前,目标文件中最多只能各包含一个这两种节,但以后会取消这种限制;一般来说,SHT_SYMTAB提供的符号用于在创建目标文件的时候编辑链接,在运行期间也有可能会用于动态链接;SHT_SYMTAB包含完整的符号表,它往往会包含很多在运行期间(动态链接)用不到的符号;所以,一个目标文件可以再有一个SHT_DYNSYM节,它含有一个较小的符号表,专门用于动态链接;
SHT_STRTAB   = 3: String table;该值表示该节是一个字符串表;目标文件中可以包含多个字符串表节;
SHT_RELA     = 4: Relocation entries with addends;该值表示该节是一个重定位节,包含有带明确加数(Addend)的重定位项,对于32位类型的目标文件来说,这个加数就是Elf32_Rela;一个目标文件可能含有多个重定位节;
SHT_HASH     = 5: Symbol hash table;该值表示该节包含一张哈希表;所有参与动态链接的目标文件都必须包含一个符号哈希表;目前,一个目标文件中最多只能有一个哈希表,但这一限制以后可能取消;
SHT_DYNAMIC  = 6: Dynamic linking information;该值表示该节包含的是动态链接信息;目前,一个目标文件中最多只能有一个SHT_DYNAMIC节,但这一限制以后可能取消;
SHT_NOTE     = 7: Notes;该值表示该节中包含的信息用于以某种方式来标记文本文件;
SHT_NOBITS   = 8: Program space with no data (bss);该值表示该节的内容是空的,节并不占用实际空间;这时字段sh_offset只代表一个逻辑上的位置概念,并不代表实际的内容;
SHT_REL      = 9: Relocation entries,no addends;该值表示该节是一个重定位节,包含有带明确加数的重定位项,对于32位类型的目标文件来说,这个加数就是Elf32_Rel;一个目标文件中可能包含有多个重定位节;
SHT_SHLIB    = 10: Reserved;
SHT_DYNSYM   = 11: Dynamic linker symbol table;
SHT_INIT_ARRAY = 14: Array of constructors;
SHT_FINI_ARRAY = 15: Array of destructors;
SHT_PREINIT_ARRAY = 16: Array of pre-constructors;
SHT_GROUP         = 17: Section group;
SHT_SYMTAB_SHNDX  = 18: Extended section indeces;
SHT_NUM           = 19: Number of defined types;
SHT_LOOS          = 0x60000000: Start OS-specific;
SHT_GNU_ATTRIBUTES= 0x6ffffff5: Object attributes;
SHT_GNU_HASH      = 0x6ffffff6: GNU-style hash table;
SHT_GNU_LIBLIST   = 0x6ffffff7: Prelink library list;
SHT_CHECKSUM      = 0x6ffffff8: Checksum for DSO content;
SHT_LOSUNW        = 0x6ffffffa: Sun-specific low bound;
SHT_SUNW_move     = 0x6ffffffa
SHT_SUNW_COMDAT   = 0x6ffffffb
SHT_SUNW_syminfo  = 0x6ffffffc
SHT_GNU_verdef    = 0x6ffffffd: Version definition section;
SHT_GNU_verneed   = 0x6ffffffe: Version needs section;
SHT_GNU_versym    = 0x6fffffff: Version symbol table;
SHT_HISUNW        = 0x6fffffff: Sun-specific high bound;
SHT_HIOS          = 0x6fffffff: End OS-specific type;
SHT_LOPROC        = 0x70000000: Start of processor-specific;
SHT_HIPROC        = 0x7fffffff: End of processor-specific;
SHT_LOUSER        = 0x80000000: Start of application-specific;
SHT_HIUSER        = 0x8fffffff: End of application-specific;

但是这里的elf被破坏了.
但是加载elf用的是progrem header，section无用，因此查看elf信息可以直接查看progrem header中的dynamic段，内部为一个一个项，以type区分用途，其中就包含init、got等
但是用cygwin+readelf查看ph：

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
Dynamic section at offset 0x34be0 contains 28 entries:
  标记        类型                         名称/值
 0x00000003 (PLTGOT)                     0x35f00
 0x00000002 (PLTRELSZ)                   488 (bytes)
 0x00000017 (JMPREL)                     0x5d00
 0x00000014 (PLTREL)                     REL
 0x00000011 (REL)                        0x3a18
 0x00000012 (RELSZ)                      8936 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffa (RELCOUNT)                   1109
 0x00000006 (SYMTAB)                     0x168
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000005 (STRTAB)                     0x13c8
 0x0000000a (STRSZ)                      7571 (bytes)
 0x00000004 (HASH)                       0x315c
 0x00000001 (NEEDED)                     共享库：[liblog.so]
 0x00000001 (NEEDED)                     共享库：[libstdc++.so]
 0x00000001 (NEEDED)                     共享库：[libm.so]
 0x00000001 (NEEDED)                     共享库：[libc.so]
 0x00000001 (NEEDED)                     共享库：[libdl.so]
 0x0000000e (SONAME)                     Library soname: [libexecute_table.so]
 0x0000000c (INIT)                       0x8c59
 0x0000001a (FINI_ARRAY)                 0x34cc8
 0x0000001c (FINI_ARRAYSZ)               8 (bytes)
 0x00000019 (INIT_ARRAY)                 0x34cd0
 0x0000001b (INIT_ARRAYSZ)               60 (bytes)
 0x00000010 (SYMBOLIC)                   0x0
 0x0000001e (FLAGS)                      SYMBOLIC BIND_NOW
 0x6ffffffb (FLAGS_1)                    标志： NOW
 0x00000000 (NULL)                       0x0

找到0x34cd0处ida打开：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
LOAD:00034CD0 ; ELF Initialization Function Table
LOAD:00034CD0                 DCD sub_625C+1
LOAD:00034CD4                 DCD sub_635C+1
LOAD:00034CD8                 DCD sub_654C+1
LOAD:00034CDC                 DCD sub_67BC+1
LOAD:00034CE0                 DCD sub_6CDC+1
LOAD:00034CE4                 DCD sub_7048+1
LOAD:00034CE8                 DCD sub_738C+1
LOAD:00034CEC                 DCD sub_76C4+1
LOAD:00034CF0                 DCD sub_7868+1
LOAD:00034CF4                 DCD sub_7884+1
LOAD:00034CF8                 DCD sub_78C4+1
LOAD:00034CFC                 DCD sub_78D4+1
LOAD:00034D00                 DCD sub_79B0+1
LOAD:00034D04                 DCD sub_7A8C+1
LOAD:00034D08                 ALIGN 0x10
LOAD:00034D08 ; LOAD          ends

此时含有大量垃圾指令，需要动态调试。断在init的方法：
http://www.blogfshare.com/linker-load-so.html
pull出system/bin/linker 在ida中分析出”[ Calling %s (size %zd) @ %p for ‘%s’ ]”处：

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
int __fastcall _dl__ZL10call_arrayIPFviPPcS1_EEvPKcPT_jbS5_(int result, int a2, int a3, int a4)
{
  int v4; // r7
  int v5; // r5
  int v6; // r6
  int v7; // r8
  int i; // r4
  v4 = a2;
  v5 = a4;
  v6 = a3;
  v7 = result;
  if ( a2 )
  {
    result = _dl_g_ld_debug_verbosity;
    if ( _dl_g_ld_debug_verbosity < 2 )
    {
      i = 0;
      goto LABEL_6;
    }
    ((void (*)(signed int, const char *, const char *, ...))_dl_async_safe_format_log)(
      4,
      "linker",
      "[ Calling %s (size %zd) @ %p for '%s' ]",
      v7,
      a3,
      a2,
      a4);
    for ( i = 0; ; ++i )
    {
      result = _dl_g_ld_debug_verbosity;
LABEL_6:
      if ( i == v6 )
        break;
      if ( result >= 2 )
        ((void (*)(signed int, const char *, const char *, ...))_dl_async_safe_format_log)(
          4,
          "linker",
          "[ %s[%d] == %p ]",
          v7,
          i,
          *(_DWORD *)(v4 + 4 * i));
      _dl__ZL13call_functionPKcPFviPPcS2_ES0_((int)"function", *(char **)(v4 + 4 * i), v5);
    }
    if ( result > 1 )
      result = ((int (*)(signed int, const char *, const char *, ...))_dl_async_safe_format_log)(
                 4,
                 "linker",
                 "[ Done calling %s for '%s' ]",
                 v7,
                 v5);
  }
  return result;
}

_dl_ZL13call_functionPKcPFviPPcS2ES0((int)”function”, (char **)(v4 + 4 i), v5)：

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
int __fastcall _dl__ZL13call_functionPKcPFviPPcS2_ES0_(int a1, char *a2, int a3)
{
  char *v3; // r6
  int v4; // r4
  int result; // r0
  int v6; // r5
  v3 = a2;
  v4 = a1;
  result = (int)(a2 + 1);
  v6 = a3;
  if ( (unsigned int)(a2 + 1) >= 2 )
  {
    if ( _dl_g_ld_debug_verbosity >= 2 )
      ((void (*)(signed int, const char *, const char *, ...))_dl_async_safe_format_log)(
        4,
        "linker",
        "[ Calling c-tor %s @ %p for '%s' ]",
        v4,
        a2,
        a3);
    ((void (__fastcall *)(int, int, int))v3)(_dl_g_argc, _dl_g_argv, _dl_g_envp);
    result = _dl_g_ld_debug_verbosity;
    if ( _dl_g_ld_debug_verbosity >= 2 )
      result = ((int (*)(signed int, const char *, const char *, ...))_dl_async_safe_format_log)(
                 4,
                 "linker",
                 "[ Done calling c-tor %s @ %p for '%s' ]",
                 v4,
                 v3,
                 v6);
  }
  return result;
}

((void (__fastcall *)(int, int, int))v3)(_dl_g_argc, _dl_g_argv, _dl_g_envp);就是调用init_array init_proc
的地方。

其中的函数开启线程检测/proc/self/status反调试。hook jni_load函数。
mprotect调用了两次，第一次修改JNI_OnLoad的偏移，由0x8205修改为0xA260 ，jni_onload中FindClass与RegisterNatives注册native函数0xAC98。
第二次mprotect调用就是解密0xAC98处的验证函数。分析验证即可。

不要随意在jni_load直接下断点，可能会检测是否更改这俩处。而且hook 符号表了后不会走jni_onload符号处的函数？不是一次性读取完符号表的么？还是init之后读？。

2018.6.28：
由于无法断在jni_load处，(没找到libdvm.so，经询问得知5.0后全是art执行….)无法得知真正的jni_onload内容。
5.0后在libart.so中调用，这里变动较大，需要分析8.0源码。

只能动调init那几个函数分析关键调用了，因为hook与解密，反调试等操作肯定会用到几个系统调用：pthread_create，mprotect与_NR_openat。在这里作者存了几个关键函数（各种非正常调用系统调用的方式？）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
//proc_4
  v8 = (struc_table *)operator new(0x20u);
  sub_C8A0(v8);
 
//sub_C8A0
struc_table *__fastcall sub_C8A0(struc_table *result)
{
  result->dlopen = (int)off_35D08;
  result->sscanf = (int)off_35D0C;
  result->__NR_read = (int)off_35D10[0];
  result->__NR_close = (int)off_35D14[0];
  result->__NR_mprotect = (int)off_35D18;
  result->__NR_openat = (int)sub_C874;
  result->sleep = (int)off_35D1C;
  result->pthread_create = (int)off_35D20;
  return result;
}

发现自己所欠缺：密码学，ida脚本dump，android系统源码知识(源码中8.0下apk执行流程)、linux系统知识。反调试与混淆法不熟悉