526互联

某虚拟相机app分析

发布时间 2023-12-23 04:26:52作者: 怎么可以吃突突

so脱壳

dynamic段混淆

对so文件libSecShell.so脱壳，so加壳肯定要在init/init_array中还原原始so文件，readelf查看so的.dynamic节区发现只有NEEDED和SONAME类型，符号表和字符串表等其他重定位信息都没有这显然是有问题的。

ida加载文件是可以正常解析符号表和字符串表等信息的，难道是readelf和ida解析dynamic段的方式有区别？

readelf继续查看so文件的program header table发现一个问题，dynamic是在第二个PT_LOAD段中，但是其文件段内偏移和内存段内偏移不一样，正常情况下dynamic文件段内偏移和内存段内偏移是相等的。内存地址肯定不会错的，因为linker是通过内存地址解析的dynamic节区，那也就是文件偏移被修改了，正常情况下文件偏移应该为0xa10b8 + 0x794 = 0xa184c

查看0xa184c偏移对应的数据果然是一个标准的dynamic段，将对应的文件偏移修正。

修正了dynamic段的文件偏移后，再次用readelf查看对应的dynamic信息发现已经可以正确解析。事实证明ida是通过内存偏移去解析的dynamic段和linker程序一样，而readelf是通过文件偏移去解析dynamic段。

readelf继续看一下section header tabel发现其描述的的dynamic段的文件偏移也是指向错误的0xab320，android 7.0之后linker程序需要解析section header table，linker解析program header table去读取dynamic的时候是通过内存偏移所以不会有问题，但是section header table只有dynamic的文件偏移，所以linker通过文件偏移读取到阉割版的dynamic段不会出现问题吗？

查看linker加载so的源码，ElfReader::ReadDynamicSection会进行如下操作，所以加壳程序将program header table中的dynamic对应的文件偏移改为和section header table一样都指向被阉割的dynamic节区可能目的并不是为了混淆readelf的解析，而是为了兼容linker的检查，只不过恰好起到了混淆readelf的效果。

  1. 判断program header table中的dynamic文件偏移是否等于section header table中dynamic的文件偏移
  2. 判断program header table中的dynamic文件大小是否等于section header table中dynamic的文件大小
  3. 利用section header table中的dynamic文件偏移将dynamic节区map到内存中
  4. 利用section header table中的strtab文件偏移将strtab节区map到内存中
bool ElfReader::ReadDynamicSection() {
  // 1. Find .dynamic section (in section headers)
  const ElfW(Shdr)* dynamic_shdr = nullptr;
  for (size_t i = 0; i < shdr_num_; ++i) {
    if (shdr_table_[i].sh_type == SHT_DYNAMIC) {
      dynamic_shdr = &shdr_table_ [i];
      break;
    }
  }
  if (dynamic_shdr == nullptr) {
    DL_ERR_AND_LOG("\"%s\" .dynamic section header was not found", name_.c_str());
    return false;
  }
  // Make sure dynamic_shdr offset and size matches PT_DYNAMIC phdr
  size_t pt_dynamic_offset = 0;
  size_t pt_dynamic_filesz = 0;
  for (size_t i = 0; i < phdr_num_; ++i) {
    const ElfW(Phdr)* phdr = &phdr_table_[i];
    if (phdr->p_type == PT_DYNAMIC) {
      pt_dynamic_offset = phdr->p_offset;
      pt_dynamic_filesz = phdr->p_filesz;
    }
  }
  // 判断program header table中的dynamic文件偏移是否等于section header table中dynamic的文件偏移
  if (pt_dynamic_offset != dynamic_shdr->sh_offset) {
    // 如果Android版本大于7就直接报错
    if (get_application_target_sdk_version() >= 26) {
      DL_ERR_AND_LOG("\"%s\" .dynamic section has invalid offset: 0x%zx, "
                     "expected to match PT_DYNAMIC offset: 0x%zx",
                     name_.c_str(),
                     static_cast<size_t>(dynamic_shdr->sh_offset),
                     pt_dynamic_offset);
      return false;
    }
    // Android版本小于7给出警告
    DL_WARN_documented_change(26,
                              "invalid-elf-header_section-headers-enforced-for-api-level-26",
                              "\"%s\" .dynamic section has invalid offset: 0x%zx "
                              "(expected to match PT_DYNAMIC offset 0x%zx)",
                              name_.c_str(),
                              static_cast<size_t>(dynamic_shdr->sh_offset),
                              pt_dynamic_offset);
    add_dlwarning(name_.c_str(), "invalid .dynamic section");
  }
  // 判断program header table中的dynamic文件大小是否等于section header table中dynamic的文件大小
  if (pt_dynamic_filesz != dynamic_shdr->sh_size) {
    if (get_application_target_sdk_version() >= 26) {
      DL_ERR_AND_LOG("\"%s\" .dynamic section has invalid size: 0x%zx, "
                     "expected to match PT_DYNAMIC filesz: 0x%zx",
                     name_.c_str(),
                     static_cast<size_t>(dynamic_shdr->sh_size),
                     pt_dynamic_filesz);
      return false;
    }
    DL_WARN_documented_change(26,
                              "invalid-elf-header_section-headers-enforced-for-api-level-26",
                              "\"%s\" .dynamic section has invalid size: 0x%zx "
                              "(expected to match PT_DYNAMIC filesz 0x%zx)",
                              name_.c_str(),
                              static_cast<size_t>(dynamic_shdr->sh_size),
                              pt_dynamic_filesz);
    add_dlwarning(name_.c_str(), "invalid .dynamic section");
  }
  if (dynamic_shdr->sh_link >= shdr_num_) {
    DL_ERR_AND_LOG("\"%s\" .dynamic section has invalid sh_link: %d",
                   name_.c_str(),
                   dynamic_shdr->sh_link);
    return false;
  }
  const ElfW(Shdr)* strtab_shdr = &shdr_table_[dynamic_shdr->sh_link];
  if (strtab_shdr->sh_type != SHT_STRTAB) {
    DL_ERR_AND_LOG("\"%s\" .dynamic section has invalid link(%d) sh_type: %d (expected SHT_STRTAB)",
                   name_.c_str(), dynamic_shdr->sh_link, strtab_shdr->sh_type);
    return false;
  }
  if (!CheckFileRange(dynamic_shdr->sh_offset, dynamic_shdr->sh_size, alignof(const ElfW(Dyn)))) {
    DL_ERR_AND_LOG("\"%s\" has invalid offset/size of .dynamic section", name_.c_str());
    return false;
  }
  // 利用section header table中的dynamic文件偏移将dynamic节区map到内存中
  if (!dynamic_fragment_.Map(fd_, file_offset_, dynamic_shdr->sh_offset, dynamic_shdr->sh_size)) {
    DL_ERR("\"%s\" dynamic section mmap failed: %s", name_.c_str(), strerror(errno));
    return false;
  }
  dynamic_ = static_cast<const ElfW(Dyn)*>(dynamic_fragment_.data());
  if (!CheckFileRange(strtab_shdr->sh_offset, strtab_shdr->sh_size, alignof(const char))) {
    DL_ERR_AND_LOG("\"%s\" has invalid offset/size of the .strtab section linked from .dynamic section",
                   name_.c_str());
    return false;
  }
  // 利用section header table中的strtab文件偏移将strtab节区map到内存中
  if (!strtab_fragment_.Map(fd_, file_offset_, strtab_shdr->sh_offset, strtab_shdr->sh_size)) {
    DL_ERR("\"%s\" strtab section mmap failed: %s", name_.c_str(), strerror(errno));
    return false;
  }
  strtab_ = static_cast<const char*>(strtab_fragment_.data());
  strtab_size_ = strtab_fragment_.size();
  return true;
}

利用section header table中的dynamic文件偏移将阉割版的dynamic节区map到内存中，后续linker解析会出现问题吗，继续分析linker哪里会对map到内存的dynamic_进行访问。查看源码发现后续只会对map到内存的dynamic_中的DT_NEEDED, DT_SONAME, DT_RUNPATH, DT_FLAGS_1这四种类型的信息进行解析，所以只要阉割版的dynamic段中包含原始dynamic中的DT_NEEDED, DT_SONAME, DT_RUNPATH, DT_FLAGS_1这四种类型的信息linker就可以正常加载so，所以一开始用readelf查看到的阉割版的dynamic只有DT_NEEDED, DT_SONAME这两种类型。

INIT段解密代码和重定位

前面查看dynamic段可以得知init函数地址为0xc0648,这里通过向init函数头部写入死循环指令，然后使用ida附加上去动态调试。

首先将0x1031C ~ 0x74BB1加密压缩的代码读取到map中

接着解密代码，解密后代码的地址范围是0x1031c ~ 0xA0EFB，ida将解密后的代码dump并patch回原so中。

然后进行重定位修复，其会将AB3A4开始的数据copy到AB110地址数组中的每一个地址中。

AB3A4地址是符号相关重定位信息默认的got表，linker程序会将重定位的数据写入到此地址处，而上述重定位将默认got表中的重定位数据copy到AB110地址数组中的每一个地址中完成程序的重定位修复，这说明符号相关重定位信息的got表地址实际保存在AB110地址数组中，现在符号相关重定位信息中的got表地址是错误的（壳修改的）。

需要将符号相关重定位信息中的got表地址修复为AB110地址数组中实际的got地址，使用idc脚本patch恢复。

#include <idc.idc>
static main(void)
{
    //start address
    auto start_address1 = 0xFDF4;
    auto end_address1 = 0x10314;
    auto i = start_address1;
    auto start_address2 = 0xAB110;
    auto offset = 0;
    for(i = start_address1; i <= end_address1; i = i + 8){
        auto dword = Dword(start_address2 + offset);
        PatchDword(i , dword);
        offset = offset + 4;
    }
}

壳运行时在修复了重定位数据后还会将符号相关重定位信息默认的got表中的重定位数据销毁，通过破坏符号相关重定位信息。

在完成了解密代码patch和重定位表的修复后，将section信息清空，这样ida就可以正常解析so了。可以看到so中字符串相关信息时运行时解密的，并且还有大量的间接跳转，switch跳转和动态跳转指令计算跳转，这也导致了JNI_Onload不能F5反编译。

anti frida check

JNI_Onload函数中会通过/proc/self/task/%s/status枚举线程名称，并调用自己实现的strstr函数sub_59530进行比较是否有frida线程gum-js-loop和gmain。

还会通过/proc/self/fd进行fd反查，看是否存在linjector管道。

绕过方法就是通过frida hook sub_59530自己实现的strstr函数，对 gum-js-loop,gmain和linjector进行过滤。

var my_strstr_add = SecShell_module.add(0x59530 + 1)
Interceptor.replace(my_strstr_add, new NativeCallback(function(arg1, arg2){
    const arg2String = Memory.readUtf8String(arg2)
    if (-1 != arg2String.indexOf("gum-js-loop") ||
        -1 != arg2String.indexOf("gmain") ||
        -1 != arg2String.indexOf("linjector")){
            return new NativePointer(0x0)
    }
    var my_strstr = new NativeFunction(my_strstr_add, 'pointer', ['pointer', 'pointer']);
    return my_strstr(arg1, arg2)
}, 'pointer', ['pointer', 'pointer']))

此检测点是动态跟踪出来的，其实更快的方法应该是对open系统调用hook，看什么地方会打开/proc/self/task/%s/status和/proc/self/fd/。

dex文件脱壳

实际此dex加的是一代壳，直接dump dex就可以了，但是为了分析一下其壳运行流程所以通过动态调试和静态分析跟踪了一下JNI_Onload的运行。

JNI_Onload会调用RegisterNative注册0x12个com.SecShell.SecShell.H类的native函数

hook libc.so的一些基本函数，如read，write等

hook libdexfile.so的art::ArtDexFileLoader::Open(std::string const&, unsigned int, art::MemMap &&, bool, bool, std::string*)函数

创建/data/data/com.xianyu.gaotong/.cache/oat/arm/classes.odex文件并写入4个字节

反射调用com.SecShell.SecShell.H.f，第一个参数为com.SecShell.SecShell.H类的classloader，第二个参数为/data/user/0/com.xianyu.gaotong/.cache/classes.jar，classes.jar文件就是classes0.jar

com.SecShell.SecShell.H.f函数最后会调用 com.SecShell.SecShell.H.e加载/data/user/0/com.xianyu.gaotong/.cache/classes.jar并返回得到的Elements[]将其copy到当前classloader的dexElements头部完成dex的加载。

com.SecShell.SecShell.H.e是一个native函数对应的地址为libSecShell.so!0x21ED8会open classes.jar，调用read读取文件，因为之前hook了read函数，所以在filter_read中对读取的classes.jar内容进行解密

最后调用inflate对解密后的数据进行解压缩得到原始dex文件。

文件指纹校验

重新签名后运行不会崩溃，说明没有签名校验，但是修改apk的文件在重打包后运行会崩溃，说明有文件校验。文件校验的话肯定会open base.apk文件，hook libc未发现说明使用的是svc调用。利用ebpf hook __arm64_compat_sys_open函数（32位）并进行栈回溯。

查看栈回溯的结果发现有线程会打开base.apk文件，对应的偏移为0x6aa0c


0x6aa0c地址处就是通过svc调用的open打开base.apk文件

然后svc调用mmap2将base.apk加载到内存中

后面会检查assets/meta-data/manifest.mf保存的原始文件文件指纹是否与当前文件一致

绕过文件指纹校验方法，找到线程函数为0x7BF08，hook pthread_create并阻止此线程的创建。

app功能分析