1、古人云：没有规矩，不成方圆！任何组织要想正常运作，肯定需要有一系列的规章制度来约束参与其中的每个个体，否则每个个体都是各干各的，从全盘来看就是一群做着布朗运动的散沙！IT技术也一样，最典型的就是计算机网络了：为了确保整个网络能正常收发数据包，早在几十年前就制定了一整套计算机网络的通信协议，这就是大家耳熟能详的TCP/IP协议！无论是源端发送数据包的、中途转发数据包的，还是目的端接受数据包的，大家都按照统一的协议格式生成、转发和解析数据包（本质就是一串字符串），确保了目的端能正确收到和解析源端的数据，由此带来了计算机网络的飞速发展！
基于计算机网络协议扩展一下：其实windwos下的PE格式、linux/android下的ELF格式本质上讲也是一种介于操作系统和编译器之间的协议！开发人员写好了代码，为了能在操作系统上顺利运行，编译器必须把高级语言的代码转换成操作系统能识别的文件格式+cpu能识别的机器码，只有这样，操作系统才能正确加载可执行文件到内存，然后运行！加壳最关键的原理就在这了：为了防止被静态分析，很多时候要想尽各种办法隐藏真实的代码，等执行的时候才还原！而且为了防止IDA等逆向软件的分析，文件格式可能还被故意破坏，不是标准的PE或ELF格式，导致操作系统无法正确地识别和加载，只能加壳的程序自己加载和执行，相当于“自立门户”了！整个过程大致如下：
加壳工具、loader、被保护SO。
- SO: 即被保护的目标 SO。
- loader: 自身也是一个 SO，系统加载时首先加载 loader，loader 首先还原出经过加密、压缩、变换的 SO，再将 SO 加载到内存，并完成链接过程，使 SO 可以正常被其他模块使用（本质是把自定义格式的so修复成操作系统能执行的格式）。
- 加壳工具: 将被保护的 SO 加密、压缩、变换，并将结果作为数据与 loader 整合为 packed SO。
从上述的描述看，loader本身就是个脱壳工具（只不过是加壳厂家官方的工具），抓住了loader，不就等于找到了脱壳的方法了？为了更好的学习loader，这里有必要研究一下加载到内存、修复链接等核心工作的原理和关键点！
2、（1）加载到内存！不知道大家平时在写代码调用其他so中函数的时候有没有仔细想过：为啥要用dlopen、dlsym函数，而不直接简单粗暴地用open、fopen等函数打开so了？dlopen和普通的open函数有啥本质区别了？open函数都很熟悉，本质是通过系统调用找到文件在磁盘的位置，然后生成fd，后续通过fd操控文件！相比之下，dlopen要复杂多了：不但要加载到内存，还要解析文件格式，然后修复链接。先来看看第一步加载和解析文件格式都是怎么做的（这里以8.0.1版本为例，源码链接在文章末尾参考处有）！
- 在/bionic/linker/linker.cpp中有do_dlopen函数（这里多说几句，linux内核有很多do开头的函数，都是内核内部的执行函数）,核心代码如下：
ProtectedDataGuard guard; 2013 soinfo* si = find_library(ns, translated_name, flags, extinfo, caller);//查找so是否已经被加载 2014 loading_trace.End(); 2015 2016 if (si != nullptr) { 2017 void* handle = si->to_handle(); 2018 LD_LOG(kLogDlopen, 2019 "... dlopen calling constructors: realpath=\"%s\", soname=\"%s\", handle=%p", 2020 si->get_realpath(), si->get_soname(), handle); 2021 si->call_constructors();//初始化so 2022 failure_guard.Disable(); 2023 LD_LOG(kLogDlopen, 2024 "... dlopen successful: realpath=\"%s\", soname=\"%s\", handle=%p", 2025 si->get_realpath(), si->get_soname(), handle); 2026 return handle;
会先在soInfo链表中挨个遍历，看看目标so是否已经加载。如果没有，就继续调用CallConstructor继续初始化so！其中 find_library_internal 函数核心代码如下：
soinfo* candidate; 1438 1439 if (find_loaded_library_by_soname(ns, task->get_name(), search_linked_namespaces, &candidate)) { //根据so的名称查找是否已经加载 1440 task->set_soinfo(candidate); 1441 return true; 1442 } 1443 1444 // Library might still be loaded, the accurate detection 1445 // of this fact is done by load_library. 1446 TRACE("[ \"%s\" find_loaded_library_by_soname failed (*candidate=%s@%p). Trying harder...]", 1447 task->get_name(), candidate == nullptr ? "n/a" : candidate->get_realpath(), candidate); 1448 1449 if (load_library(ns, task, zip_archive_cache, load_tasks, rtld_flags, search_linked_namespaces)) { //正式加载so 1450 return true; 1451 }
先根据so的名称查找在soInfo的链表中查找是否已经存在。如果不存在，说明还没加载，继续调用load_library 加载so。代码非常多（在这里:http://aospxref.com/android-8.1.0_r81/xref/bionic/linker/linker.cpp#1178），而且分散在不同的函数，我这里选重点说明整个流程：
// Open the file. 先打开文件 1341 int fd = open_library(ns, zip_archive_cache, name, needed_by, &file_offset, &realpath); 1342 if (fd == -1) { 1343 DL_ERR("library \"%s\" not found", name); 1344 return false; 1345 } //生成soInfo结构体，后续用于记录so的属性 soinfo* si = soinfo_alloc(ns, realpath.c_str(), &file_stat, file_offset, rtld_flags); 1277 if (si == nullptr) { 1278 return false; 1279 } 1280 1281 task->set_soinfo(si); 1282 1283 // Read the ELF header and some of the segments.读取so的elf头，用于解析so 1284 if (!task->read(realpath.c_str(), file_stat.st_size)) { 1285 soinfo_free(si); 1286 task->set_soinfo(nullptr); 1287 return false; 1288 } 1289 1290 // find and set DT_RUNPATH and dt_soname 1291 // Note that these field values are temporary and are 1292 // going to be overwritten on soinfo::prelink_image 1293 // with values from PT_LOAD segments. 1294 const ElfReader& elf_reader = task->get_elf_reader(); 1295 for (const ElfW(Dyn)* d = elf_reader.dynamic(); d->d_tag != DT_NULL; ++d) { 1296 if (d->d_tag == DT_RUNPATH) { 1297 si->set_dt_runpath(elf_reader.get_string(d->d_un.d_val)); 1298 } 1299 if (d->d_tag == DT_SONAME) { 1300 si->set_soname(elf_reader.get_string(d->d_un.d_val)); 1301 } 1302 } 1303 1304 for_each_dt_needed(task->get_elf_reader(), [&](const char* name) { 1305 load_tasks->push_back(LoadTask::create(name, si, ns, task->get_readers_map())); 1306 }); 1307 //装载so，并给soInfo结构体赋值 641 ElfReader& elf_reader = get_elf_reader(); 642 if (!elf_reader.Load(extinfo_)) { 643 return false; 644 } 645 646 si_->base = elf_reader.load_start(); 647 si_->size = elf_reader.load_size(); 648 si_->set_mapped_by_caller(elf_reader.is_mapped_by_caller()); 649 si_->load_bias = elf_reader.load_bias(); 650 si_->phnum = elf_reader.phdr_count(); 651 si_->phdr = elf_reader.loaded_phdr(); 652 653 return true; 654 }
整个流程简单清晰：先打开文件，然后解析elf文件头，最后新生成so结构体记录加载的so文件属性！打开和加载的过程中，/bionic/linker/linker_phdr.cpp 中的这两个函数里面包括了整个加载过程的精髓：
bool ElfReader::Read(const char* name, int fd, off64_t file_offset, off64_t file_size) { 150 CHECK(!did_read_); 151 CHECK(!did_load_); 152 name_ = name; 153 fd_ = fd; 154 file_offset_ = file_offset; 155 file_size_ = file_size; 156 157 if (ReadElfHeader() && //读elf头 158 VerifyElfHeader() && //校验elf头 159 ReadProgramHeaders() && //读程序头 160 ReadSectionHeaders() && //读接头 161 ReadDynamicSection()) { //读动态节头 162 did_read_ = true; 163 } 164 165 return did_read_; 166 } 167 168 bool ElfReader::Load(const android_dlextinfo* extinfo) { 169 CHECK(did_read_); 170 CHECK(!did_load_); 171 if (ReserveAddressSpace(extinfo) && //为段开辟内存空间 172 LoadSegments() && //加载段，这里是很好的脱壳点 173 FindPhdr()) { //设置程序的加载地址 174 did_load_ = true; 175 } 176 177 return did_load_; 178 }
自己写壳的加载程序时，完全可以仿照这8个步骤一步一步做（事实上，很多加壳和脱壳loader程序也都是这么干的！）！至此，这个so的代码是不是就能执行了？很明显还不行，原因很简单：链接还没修复了！所谓的链接，本质就是调用其他函数时需要正确的地址！
（2）修复链接
整个过程最核心的函数就是prelink_image和link_image了，作用分别是：
- 解析linker文件中dynamic段的各项，例如重定位表，符号表
- 对全局变量，外部函数等地址进行重定位
核心代码如下：prelink_image 大都是这种switch case结构，根据不同的tag做不同的解析；
for (ElfW(Dyn)* d = dynamic; d->d_tag != DT_NULL; ++d) { 2857 DEBUG("d = %p, d[0](tag) = %p d[1](val) = %p", 2858 d, reinterpret_cast<void*>(d->d_tag), reinterpret_cast<void*>(d->d_un.d_val)); 2859 switch (d->d_tag) { 2860 case DT_SONAME: 2861 // this is parsed after we have strtab initialized (see below). 2862 break; 2863 2864 case DT_HASH: //导出函数定位 2865 nbucket_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[0]; 2866 nchain_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[1]; 2867 bucket_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr + 8); 2868 chain_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr + 8 + nbucket_ * 4); 2869 break; 2870 2871 case DT_GNU_HASH: //导出函数定位 2872 gnu_nbucket_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[0]; 2873 // skip symndx 2874 gnu_maskwords_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[2]; 2875 gnu_shift2_ = reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[3]; 2876 2877 gnu_bloom_filter_ = reinterpret_cast<ElfW(Addr)*>(load_bias + d->d_un.d_ptr + 16); 2878 gnu_bucket_ = reinterpret_cast<uint32_t*>(gnu_bloom_filter_ + gnu_maskwords_); 2879 // amend chain for symndx = header[1] 2880 gnu_chain_ = gnu_bucket_ + gnu_nbucket_ - 2881 reinterpret_cast<uint32_t*>(load_bias + d->d_un.d_ptr)[1]; 2882 2883 if (!powerof2(gnu_maskwords_)) { 2884 DL_ERR("invalid maskwords for gnu_hash = 0x%x, in \"%s\" expecting power to two", 2885 gnu_maskwords_, get_realpath()); 2886 return false; 2887 } 2888 --gnu_maskwords_; 2889 2890 flags_ |= FLAG_GNU_HASH; 2891 break; 2892 2893 case DT_STRTAB: 2894 strtab_ = reinterpret_cast<const char*>(load_bias + d->d_un.d_ptr); 2895 break; 2896 2897 case DT_STRSZ: 2898 strtab_size_ = d->d_un.d_val; 2899 break; 2900 2901 case DT_SYMTAB: 2902 symtab_ = reinterpret_cast<ElfW(Sym)*>(load_bias + d->d_un.d_ptr); 2903 break; 2904 2905 case DT_SYMENT: 2906 if (d->d_un.d_val != sizeof(ElfW(Sym))) { 2907 DL_ERR("invalid DT_SYMENT: %zd in \"%s\"", 2908 static_cast<size_t>(d->d_un.d_val), get_realpath()); 2909 return false; 2910 } 2911 break;
解析完后就是重定位了，根据不同的条件给relocate函数传入不同的参数！
if (android_relocs_ != nullptr) { 3300 // check signature 3301 if (android_relocs_size_ > 3 && 3302 android_relocs_[0] == 'A' && 3303 android_relocs_[1] == 'P' && 3304 android_relocs_[2] == 'S' && 3305 android_relocs_[3] == '2') { 3306 DEBUG("[ android relocating %s ]", get_realpath()); 3307 3308 bool relocated = false; 3309 const uint8_t* packed_relocs = android_relocs_ + 4; 3310 const size_t packed_relocs_size = android_relocs_size_ - 4; 3311 3312 relocated = relocate( 3313 version_tracker, 3314 packed_reloc_iterator<sleb128_decoder>( 3315 sleb128_decoder(packed_relocs, packed_relocs_size)), 3316 global_group, local_group); 3317 3318 if (!relocated) { 3319 return false; 3320 } 3321 } else { 3322 DL_ERR("bad android relocation header."); 3323 return false; 3324 } 3325 } 3326 3327 #if defined(USE_RELA) 3328 if (rela_ != nullptr) { 3329 DEBUG("[ relocating %s ]", get_realpath()); 3330 if (!relocate(version_tracker, 3331 plain_reloc_iterator(rela_, rela_count_), global_group, local_group)) { 3332 return false; 3333 } 3334 } 3335 if (plt_rela_ != nullptr) { 3336 DEBUG("[ relocating %s plt ]", get_realpath()); 3337 if (!relocate(version_tracker, 3338 plain_reloc_iterator(plt_rela_, plt_rela_count_), global_group, local_group)) { 3339 return false; 3340 } 3341 } 3342 #else 3343 if (rel_ != nullptr) { 3344 DEBUG("[ relocating %s ]", get_realpath()); 3345 if (!relocate(version_tracker, 3346 plain_reloc_iterator(rel_, rel_count_), global_group, local_group)) { 3347 return false; 3348 } 3349 } 3350 if (plt_rel_ != nullptr) { 3351 DEBUG("[ relocating %s plt ]", get_realpath()); 3352 if (!relocate(version_tracker, 3353 plain_reloc_iterator(plt_rel_, plt_rel_count_), global_group, local_group)) { 3354 return false; 3355 } 3356 } 3357 #endif
relocate函数内部同样也是switch case结构，根据不同的type修改reloc表、符号表等，还有修改系统函数、全局/静态变量的绝对地址！
switch (type) { 2579 case R_GENERIC_JUMP_SLOT: 2580 count_relocation(kRelocAbsolute); 2581 MARK(rel->r_offset); 2582 TRACE_TYPE(RELO, "RELO JMP_SLOT %16p <- %16p %s\n", 2583 reinterpret_cast<void*>(reloc), 2584 reinterpret_cast<void*>(sym_addr + addend), sym_name); 2585 2586 *reinterpret_cast<ElfW(Addr)*>(reloc) = (sym_addr + addend); 2587 break; 2588 case R_GENERIC_GLOB_DAT: 2589 count_relocation(kRelocAbsolute); 2590 MARK(rel->r_offset); 2591 TRACE_TYPE(RELO, "RELO GLOB_DAT %16p <- %16p %s\n", 2592 reinterpret_cast<void*>(reloc), 2593 reinterpret_cast<void*>(sym_addr + addend), sym_name); 2594 *reinterpret_cast<ElfW(Addr)*>(reloc) = (sym_addr + addend); 2595 break; 2596 case R_GENERIC_RELATIVE: 2597 count_relocation(kRelocRelative); 2598 MARK(rel->r_offset); 2599 TRACE_TYPE(RELO, "RELO RELATIVE %16p <- %16p\n", 2600 reinterpret_cast<void*>(reloc), 2601 reinterpret_cast<void*>(load_bias + addend)); 2602 *reinterpret_cast<ElfW(Addr)*>(reloc) = (load_bias + addend); 2603 break; 2604 case R_GENERIC_IRELATIVE: 2605 count_relocation(kRelocRelative); 2606 MARK(rel->r_offset); 2607 TRACE_TYPE(RELO, "RELO IRELATIVE %16p <- %16p\n", 2608 reinterpret_cast<void*>(reloc), 2609 reinterpret_cast<void*>(load_bias + addend)); 2610 { 2611 #if !defined(__LP64__) 2612 // When relocating dso with text_relocation .text segment is 2613 // not executable. We need to restore elf flags for this 2614 // particular call. 2615 if (has_text_relocations) { 2616 if (phdr_table_protect_segments(phdr, phnum, load_bias) < 0) { 2617 DL_ERR("can't protect segments for \"%s\": %s", 2618 get_realpath(), strerror(errno)); 2619 return false; 2620 } 2621 } 2622 #endif 2623 ElfW(Addr) ifunc_addr = call_ifunc_resolver(load_bias + addend);
（3）加入soInfo结构体
此时只有loader这个so是被操作系统linker加载的，所以也只有loader的so能和art交互（猜猜为什么？）！为了让自己关键代码的so也能和art交互，需要替换掉loader的so的属性，把其改成关键代码so的属性； PS：soInfo记录了内存中so结构体的核心属性，完全可以用来检索so，核心属性列举如下：
装载链接期间主要使用的成员: 装载信息 const ElfW(Phdr)* phdr; size_t phnum; ElfW(Addr) base; size_t size; 符号信息 const char* strtab; ElfW(Sym)* symtab;
下一个soInfo节点
重定位信息 ElfW(Rel)* plt_rel; size_t plt_rel_count; ElfW(Rel)* rel; size_t rel_count; init 函数和 finit 函数 Linker_function_t* init_array; size_t init_array_count; Linker_function_t* fini_array; size_t fini_array_count; Linker_function_t init_func; Linker_function_t fini_func; 运行期间主要使用的成员: 导出符号查找（dlsym）: const char* strtab; ElfW(Sym)* symtab; size_t nbucket; size_t nchain; unsigned* bucket; unsigned* chain; ElfW(Addr) load_bias; 异常处理: unsigned* ARM_exidx; size_t ARM_exidx_count; load_library 在为 SO 分配 soinfo 后，会将装载结果更新到 soinfo 中，后面的链接过程就可以直接使用soinfo的相关字段去访问 SO 中的信息。
操作系统为了便于管理，还会把soInfo组织成链表形式，所以在soinfo_alloc函数中就会把新生成的soInfo结构体加入链表，开发人员只要遍历链表就能查找到所有已经加载的so了！这里扩展一下：windows下做安全防护时，经常会把进程或线程的链表断开，让逆向破解人员找不到自己的进程或线程！ 修改soInfo结构体的时候建议通过如下基址+偏移的形式修改！每个偏移代表什么含义可通过AOSP源码查询得到！
3、最后总结一下一般加壳的原理流程：
- 关键文件可以不是elf格式，比如自定义的文件格式；还可以对关键代码加密
- 执行时先装载loader，由于loader本身是标准的so，所以直接用操作系统的linker加载即可（就是调用操作系统提供现成的dlopen等API）！
- loader被加载后，会调用callConstractor函数，该函数内部先后依次执行init、initArray、jni_onload等函数，所以加载自己关键文件、解密代码、还原成elf结构、修复链接/重定位、加入soInfo链表（“解壳”三部曲：加载、链接、替换soInfo结构体）等工作都可以在这三个方法中做。具体代码完全可以参考android源码，结合自己文件实际格式即可！
这里借（抄）鉴（袭）某位大佬整理的ELF格式的解析图凑数：
附上看雪r0ysue大佬的加壳demo 链接：https://pan.baidu.com/s/1MZSjotH8cs7wrOIAiZM5NQ 提取码：kjvm 思路就是自己定义的loader完成了操作系统linker的功能！
脱壳点：
1、mprotect函数：以前关注这个函数是在反调试阶段，比如把内存设置为不可执行，等自己代码快要执行到目标内存区域时再调用mprotect把内存设置为可执行。如果检测到被ida调试，就不改内存属性为可执行，让ida调试时跳转到这里时就会报signal异常！除了反调试，在加壳领域mprotect也能用上。比如在脱壳时，肯定需要一段内存存放代码（以任何形式申请的内存默认都没有执行权限），并且同样需要调用mprotect函数把内存设置为可执行！所以逆向时可以通过hook mprotect函数，看看第三个参数是不是设置内存为可执行。同时如果第二个参数len也不小，那么这个mprotect很有可能就是在脱壳用了！参考的hook代码如下：
2、soInfo结构体：因为每个加载的so都会生成soInfo结构体，然后加入链表中，所以soInfo链表保存了所有已加载so的soInfo，从这个链表就能找到自己想要so的信息，然后借此脱壳；poc代码如下： 从maps文件查找linker64的地址，然后继续找solist的地址，最后遍历soInfo！
void initlinker(){ char line[1024]; int *end; long* base; int n = 1; FILE *fp = fopen("/proc/self/maps", "r"); while (fgets(line, sizeof(line), fp)) { if (strstr(line, "linker64")) { if (n == 1) { start = reinterpret_cast<int *>(strtoul(strtok(line, "-"), NULL, 16)); end = reinterpret_cast<int *>(strtoul(strtok(NULL, " "), NULL, 16)); } else { strtok(line, "-"); end = reinterpret_cast<int *>(strtoul(strtok(NULL, " "), NULL, 16)); } n++; } } int soheaderoff = findsym("/system/bin/linker64", "__dl__ZL6solist"); soheader = reinterpret_cast<long *>((char *) start + soheaderoff); } void *findsobase(const char *soname) { long* base; long* soinfo; int n=0; for (_QWORD * result = reinterpret_cast<uint64 *>(*(_QWORD *) soheader); result; result = (_QWORD *)result[5] ){ if(*(_QWORD *) ((__int64) result + 408)!= 0&&strcmp(reinterpret_cast<const char *>(*(_QWORD *) ((__int64) result + 408)), soname)==0) { base= reinterpret_cast<long *>(*(_QWORD *) ((char *) result + 16)); long* size= reinterpret_cast<long *>(*(_QWORD *) ((char *) result + 24)); long* load_bias= reinterpret_cast<long *>(*(_QWORD *) ((char *) result + 256)); const char* name= reinterpret_cast<const char *>(*(_QWORD *) ((__int64) result + 408)); soinfo= reinterpret_cast<long *>(result); break; } } return soinfo; }
3、mmap：从磁盘读取大文件后为了节约内存，用mmap是最合适不过的了！大文件很有可能是加壳的so！
4、so加载加壳总结：
为了增加内存中so被识别和dump的难度，可以把elf header或section header删除，或者用异或的方式加密混淆，比如下面这样的：
标红部分是改过的，再用ida打开就不行了！总的来说，建议用异或而不是直接删除，能让逆向人员dump还原so的时候怀疑人生: 我是不是dump的位置选错了？代码上就类似这种：
bool LoadSegments() { for (size_t i = 0; i < phdr_num_; ++i) { const ElfW(Phdr) *phdr = &phdr_table_[i]; if (phdr->p_type != PT_LOAD) { continue; } // Segment addresses in memory. ElfW(Addr) seg_start = phdr->p_vaddr^0x5a + load_bias_; ElfW(Addr) seg_end = seg_start + phdr->p_memsz^0x5a; ElfW(Addr) seg_page_start = PAGE_START(seg_start); ElfW(Addr) seg_page_end = PAGE_END(seg_end); ElfW(Addr) seg_file_end = seg_start + phdr->p_filesz^0x5a; // File offsets. ElfW(Addr) file_start = phdr->p_offset^0a5x; ElfW(Addr) file_end = file_start^0x5a + phdr->p_filesz; ElfW(Addr) file_page_start = PAGE_START(file_start); ElfW(Addr) file_length = file_end^0x5a - file_page_start; long* pp= reinterpret_cast<long *>(seg_page_start);
选一些自认为比较重要的字段在完全加载后再异或0x5a（当然其他数字也行），达到迷惑逆向人员的目的！
参考：
1、https://cloud.tencent.com/developer/article/1071358 android linker与so加壳技术
2、https://www.cnblogs.com/r0ysue/p/15398936.html 基于linker实现so加壳 上篇
https://zhuanlan.zhihu.com/p/413630468 下篇
3、http://aospxref.com/android-8.1.0_r81/ AOSP源码查询
4、https://wwm0609.github.io/2020/06/12/android-linker/ android dynamic linking简介