上边的资料对ELF文件格式的分析非常详细，这边主要记录一下自己感觉比较重要和掌握的不是很清楚的部分，增加一些自己的理解，也方便后续查阅。
该方法的主要原理是利用dl_runtime_resolve函数来对动态链接的函数进行重定位。
Linker是Android系统动态库so的加载器/链接器，要想轻松地理解Android linker的运行机制，我们需要先熟悉ELF的文件结构，再了解ELF文件的装入/启动，最后学习Linker的加载和启动原理。 鉴于ELF文件结构网上有很多资料，这里就不做累述了。
本文介绍了ELF的基本结构和内存加载的原理，并用具体案例来分析如何通过ELF特性实现HIDS bypass、加固/脱壳以及辅助进行binary fuzzing。
这两天在编写一个插件系统Demo的时候，发现了个很奇怪的问题：插件加载器中已经链接了ld库，但是应用程序在链接插件加载器的时候，却还需要显式的来链接ld库。否则就会报：DSO missing from command line。这个报错翻译过来就是没有在命令行中指定该动态库。 这个报错就很搞事了，你说你明明知道需要哪个库，为什么不直接帮我链接呢，非得我显示的在命令行中指定呢？
在IDA动态调试-没啥卵用的静态加固中，我构造了一个畸形的ELF文件，虽然能够糊弄一下IDA的静态分析，但是动态分析无效。
通过Hook系统在本进程中的open和close、read、write这些系统函数，来了解打开的文件以及其是否被释放。由于只是Hook本App的系统调用，所以不需要Root权限也可以完成。
这边文章不是一个如何引导，尽管它确实展示了如何编译和调试共享库和可执行文件。为了解动态加载的内部工作方式进行了优化。写这篇文章是为了消除我在该主题上的知识欠缺，以便成为一名更好的程序员。我希望它也能帮助您变得更好。
参数 loader 为Android的应用类加载器，它是 PathClassLoader 类型的对象，继承自 BaseDexClassLoader 对象，下面看 BaseDexClassLoader 的 findLibrary() 方法。
ld - GNU的Linker，通常是编译程序的最后一步 记录一下手册，以备不时之需 -> ldpentium -v GNU ld (Wind River VxWorks G++ 4.3-386) 2.19.51.20090709 -> ldpentium --help Usage: ldpentium [options] file... Options: -a KEYWORD Shared library control for HP/UX compatibili
原文：http://xcd.blog.techweb.com.cn/archives/222.html
前两天网上投递了简历，面试了一家C++公司，然后对面负责人给我发了一份笔试题，题目是：
ld命令是二进制工具集GNU Binutils的一员，是GNU链接器，用于将目标文件与库链接为可执行程序或库文件。
作者简介： 伟林，中年码农，从事过电信、手机、安全、芯片等行业，目前依旧从事Linux方向开发工作，个人爱好Linux相关知识分享。 原理概述 为什么要研究链接和加载？写一个小的main函数用户态程序，或者是一个小的内核态驱动ko，都非常简单。但是这一切都是在gcc和linux内核的封装之上，你只是实现了别人提供的一个接口，至于程序怎样启动、怎样运行、怎样实现这些机制你都一无所知。接着你会对程序出现的一些异常情况束手无策，对内核代码中的一些用法不能理解，对makefile中的一些实现不知所云。所以这就是我们
一是做个总结，二是做个备份。上篇文章感谢@大米指出的错误，格式化字符串漏洞还未销声匿迹！！！
1. 前言 Android 系统安全愈发重要，像传统pc安全的可执行文件加固一样，应用加固是Android系统安全中非常重要的一环。目前Android 应用加固可以分为dex加固和Native加固，Native 加固的保护对象为 Native 层的 SO 文件，使用加壳、反调试、混淆、VM 等手段增加SO文件的反编译难度。目前最主流的 SO 文件保护方案还是加壳技术， 在SO文件加壳和脱壳的攻防技术领域，最重要的基础的便是对于 Linker 即装载链接机制的理解。对于非安全方向开发者，深刻理解系统的装载与链
可执行与可链接格式 （Executable and Linkable Format，ELF），常被称为 ELF格式，是一种用于可执行文件、目标代码、共享库和核心转储（core dump）的标准文件格式，一般用于类Unix系统，比如Linux，Macox等。ELF 格式灵活性高、可扩展，并且跨平台。比如它支持不同的字节序和地址范围，所以它不会不兼容某一特别的 CPU 或指令架构。这也使得 ELF 格式能够被运行于众多不同平台的各种操作系统所广泛采纳。 ELF文件一般由三种类型的文件：
这期的内容主要是讲完读取输入的部分，有一些之前遗漏的信息，以及之前未讲完的初始化ehframe以及shared object读取的部分。有许多地方默认读者读过上期内容，建议先阅读上期内容后再来查看本期。
之前我们介绍了ret2text和ret2shellcode，这篇给大家介绍一下ret2libc。
在上周的一篇转载文章中，介绍了一种如何把一个动态库中的调用函数进行“掉包”的技术，从而达到一些特殊的目的。
对于大型的工程项目，依赖许多人的配合，包含大量不同的代码库与服务，有的我们能够访问程序的源代码，有的可以访问程序的可重定位文件，有的可以访问到可执行文件及其环境，假如我们想在在不同的层面改变或者添加一些逻辑，操作系统、编译器以及程序语言、代码库等都提供了 一些机制使得 开发者可以 方便的 增加或替换代码逻辑，对于逻辑调试、测试、性能分析、版本兼容等都有比较好的效果。
上一篇文章中，我们介绍了如何让汇编语言与 C 语言相互调用： 如何实现汇编语言与 C 语言之间的相互调用
我们知道动态链接器本身也是一个共享对象，但是事实上它有一些特殊性。对于普通共享对象文件来说，它的重定位工作由动态链接器来完成。他也可以依赖其他共享对象，其中的被依赖共享对象由动态链接器负责链接和装载。可是对于动态链接器来说，它的重定位工作由谁来完成？它是否可以依赖于其他共享对象？
在分析了Pornhub使用的平台之后，我们在其网站上检测到了unserialize函数的使用，其中的很多功能点（例如上传图片的地方等等）都受到了影响，例如下面两个URL：
ret2dlresolve是linux下一种利用linux系统延时绑定(Lazy Binding)机制的一种漏洞利用方法，其主要思想是利用dlruntimeresolve()函数写GOT表的操作，改写写入GOT的内容，使其成为getshell的函数值。
我们日常开发中编写的C/C++代码经过NDK进行编译和链接之后，生成的动态链接库或可执行文件都是ELF格式的，它也是Linux的主要可执行文件格式。我们今天就要借助一个示例来理解一下android平台下native层hook的操作和原理，不过在这之前，我们还是要先了解一下ELF相关的内容。
在了解了共享对象的绝对地址的引用问题后，我们基本上对动态链接的原理有了初步的了解，接下来的问题是整个动态链接具体的实现过程了。动态链接在不同的系统上有不同的实现方式。ELF的动态链接的实现方式会比PE的简单一点，在这里我们先介绍ELF的动态链接过程在LINUX下的实现，最后我们会专门的章节中介绍PE在Windows下的动态链接过程和它们的区别
在android系统中，进程之间是相互隔离的，两个进程之间是没办法直接跨进程访问其他进程的空间信息的。那么在android平台中要对某个app进程进行内存操作，并获取目标进程的地址空间内信息或者修改目标进程的地址空间内的私有信息，就需要涉及到注入技术。
The C library. Stuff like fopen(3) and kill(2).
在使用动态库开发部署时，遇到最多的问题可能就是 undefined symbol 了，导致这个出现这个问题的原因有多种多样，快速找到原因，采用对应的方法解决是本文写作的目的。
上一篇文章中，我们结合此前已经介绍过的一系列知识，成功的将内核载入内存并进入到了保护模式中。 实战操作系统 loader 编写（上） — 进入保护模式
之前几篇介绍exploit的文章, 有提到return-to-plt的技术. 当时只简单介绍了 GOT和PLT表的基本作用和他们之间的关系, 所以今天就来详细分析下其具体的工作过程.
readelf命令用来显示一个或者多个elf格式的目标文件的信息，可以通过它的选项来控制显示哪些信息。这里的elf-file(s)就表示那些被检查的文件。可以支持32位，64位的elf格式文件，也支持包含elf文件的文档（这里一般指的是使用ar命令将一些elf文件打包之后生成的例如lib*.a之类的“静态库”文件）。
在Linux应用的开发过程中，直接利用现成的第三方库(俗称：轮子)来完成自己的业务功能，是很常见的事情。
可执行文件的装载 进程和装载的基本概念的介绍 程序（可执行文件）和进程的区别 程序是静态的概念，它就是躺在磁盘里的一个文件。 进程是动态的概念，是动态运行起来的程序。 现代操作系统如何装载可执行文件 给进程分配独立的虚拟地址空间 将可执行文件映射到进程的虚拟地址空间（mmap） 将CPU指令寄存器设置到程序的入口地址，开始执行 可执行文件在装载的过程中实际上如我们所说的那样是映射的虚拟地址空间，所以可执行文件通常被叫做映像文件(或者Image文件)。 可执行ELF文件的两种视角 可执行ELF格式具有不寻常的
大家好，我是架构君，一个会写代码吟诗的架构师。今天说一说readelf命令使用说明[通俗易懂],希望能够帮助大家进步!!!
可执行文件的符号表(symbol table)记录了某个可执行文件中的函数名、全局变量、宏定义等符号信息，这些信息对于我们调试十分重要。
从今天开始我们正式开始Android的逆向之旅，关于逆向的相关知识，想必大家都不陌生了，逆向领域是一个充满挑战和神秘的领域。作为一名android开发者，每个人都想去探索这个领域，因为一旦你破解了别人的内容，成就感肯定爆棚，不过相反的是，我们不仅要研究破解之道，也要研究加密之道，因为加密和破解是相生相克的。但是我们在破解的过程中可能最头疼的是native层，也就是so文件的破解。所以我们先来详细了解一下so文件的内容下面就来看看我们今天所要介绍的内容。今天我们先来介绍一下elf文件的格式，因为我们知道Android中的so文件就是elf文件，所以需要了解so文件，必须先来了解一下elf文件的格式，对于如何详细了解一个elf文件，就是手动的写一个工具类来解析一个elf文件。
so 文件是啥？so 文件是 elf 文件，elf 文件后缀名是.so，所以也被称之为so 文件, elf 文件是 linux 底下二进制文件，可以理解为 windows 下的PE文件，在 Android 中可以比作dll，方便函数的移植，在常用于保护 Android 软件，增加逆向难度。
相信有不少 Linux 用户都碰到过运行第三方（非系统自带软件源）发布的程序时的 glibc 兼容性问题，这一般是由于当前 Linux 系统上的 GNU C 库（glibc）版本比较老导致的，例如我在 CentOS 6 64 位系统上运行某第三方闭源软件时会报：
链接是将各种代码和数据片段收集并组合为一个单一文件的过程，这个文件可以被加载到内存中执行。
前面章节我们了解了ELF文件的头部结构，这次我们深入了解另一个非常重要的数据结构，那就是程序表头。操作系统严重依赖该结构来加载ELF文件或是实现动态链接。程序表头反映的是当ELF加载到内存后所形成的“视图”或结构，也就是说ELF文件存在硬盘上或者被加载到内存，它展现出来的形态不一致。
上一期主要讲了链接前的一些准备流程以及在mold中链接过程的简单介绍。这期开始我们从链接过程中的功能开始介绍。在开始之前，提前说明一下里面各种缩写有很多，我会在第一次出现时提及缩写具体含义是什么，如果后期更的期数比较多会考虑专门写一页缩写的参考，方便查阅。
背景：第三方so依赖glibc2.14版本，如何在不升级redhat 6.2自带的gblic2.12情况下，运行so？
通过sqlplus的spool功能我们将数据库日常运维的结果输出到日志文件，而有时候则需要定时输出，为避免日志文件名的重复，我们可以将输出的日志文件名采用动态命名方式来实现。本文则是针对这个问题给出一个示例，供大家参考。
要想实现ELF文件的入口劫持，不深入掌握其运行原理与组成结构那是不可能的。ELF的内部结构复杂，加载逻辑难以理解，因此我们需要通过切香肠的方式，将这个困难的技术点一点一滴的去攻克。
在这篇文章中，让我们看看如何使用 GOT 覆盖和解引用技巧。来绕过共享库地址随机化。我们在第一部分中提到过，即使可执行文件没有所需的 PLT 桩代码，攻击者也可以使用 GOT 覆盖和解引用技巧来绕过 ASLR。
概念:每一个外部定义的符号在全局偏移表（Global offset Table）中有相应的条目，GOT位于ELF的数据段中，叫做GOT段。
ELF的英文全称是The Executable and Linking Format，最初是由UNIX系统实验室开发、发布的ABI(Application Binary Interface)接口的一部分，也是Linux的主要可执行文件格式。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
