ELF文件整体布局 下图是后来例子中main.o和main.elf的布局. 其中,只有elf header的位置是固定的,固定在文件开始,其它部分的位置都不确定. 比如下面的main.o布局中,.text .comment .shstrtab两个节在前面,而section header table在后面 正常流程应该是由elf header找到section header table,然后,基于该表,定位其它的节. main.o是Reloc文件,没有program header:main.elf

ELF文件格式是一个开发标准,各种UNIX系统的可执行文件都采用ELF格式,它有三种不同的类型: 可重定位的目标文件 可执行文件 共享库 现在分析一下上一篇文章中经过汇编之后生成的目标文件max.o和链接之后生成的可执行文件max的格式,从而理解汇编.链接和加载执行的过程. 一.目标文件 ELF文件格式提供了两种不同的视角,在汇编器和链接器看来,ELF文件是由Section Header Table描述的一系列Section的集合,而执行一个ELF文件时,在加载器看来它是由Program Hea

声明:以下的代码成果,是参考了网上的injso技术,在本文的最后会给出地址,同时非常感谢injso技术原作者的分享. 但是injso文章中的代码存在一些问题,所以后面出现的代码是经过作者修改和检测的.也正因为这些错误,加深了我的学习深度. 最近因为在学习一些调试的技术,但是很少有提到如何在函数运行时实现函数替换的. 为什么会想到这一点?因为在学习调试时,难免会看到一些内核方面的调试技术,内核中的调试有一个kprobe,很强大,可以实现运行时的函数替换.其原理就是hook,钩子,但是学习了这个kp

转载自http://bbs.pediy.com/showthread.php?t=191649 以前一直对.so文件加载时解密不懂,不了解其工作原理和实现思路.最近翻看各种资料,有了一些思路.看到论坛没有类似帖子,故来一帖,也作为学习笔记.限于水平,本菜没有找到安卓平台一些具体实现思路,这些方法都是借鉴其他平台的实现思路和本菜的YY,肯定会有不少疏漏和错误之处,还请各位大牛指正,感激不尽! 简单粗暴的so加解密实现一.  概述利用动态链接库实现安卓应用的核心部分,能一定程度的对抗逆向.由于ida

catalog . INTRODUCTION . THE PROCESS IMAGE . THE CORE IMAGE . EXECUTABLE RECONSTRUCTION . FAILURES IN RECONSTRUCTION . USES OF RECONSTRUCTION . Helper Tools . Code For New Linux Kernel 1. INTRODUCTION This article documents the results from experimen

目录 . 引言 . ELF文件格式 . ELF格式分析工具 0. 引言 0x1: ELF文件类型 ELF文件标准里把系统中采用ELF格式的文件归为以下几类 . 可重定位文件(Relocatable File) 这类文件包含了代码和数据,可以被用来链接成可执行文件或共享目标文件,静态链接库也可以归为这一类 ) .o文件 . 可执行文件(Executable File) 这类文件包含了可以直接执行的程序,它的代表就是ELF可执行文件,它们一般都没有扩展名 ) /bin/bash文件 . 共享目标文件

其实问题的本质是对elf格式的理解问题,因为是查看so库的符号表发现的问题. 事情起因是这样的,由于我的一个程序编译的时候出现了undefined reference to “XXX”的错误,需要链接特定的so库,发现用nm [file]找不到“XXX”函数符号,结果用readelf -s [file] 就找到了.其实问题是我对so理解的不深刻. 一般来说,对于一个so库有两个符号表,一个是“正常的”(在.symtab和.strtab节中).一个是动态的(.dynsym和.dynstr节中).如

程序减肥,strip,eu-strip 及其符号表 我们要给我们生成的可执行文件和DSO瘦身,因为这样可以节省更多的磁盘空间,所以我们移除了debug信息,移除了符号表信息,同时我们还希望万一出事了,比如coredump了,我们能获取更多的信息,这时候我们又希望有符号表.     我们等不能做到呢.Linux下是怎么解决这个矛盾的呢?先看第一个问题,程序减肥.      1 程序减肥     我写了个简单的代码,main调用了foo,foo调用了bar,其中bar故意访问了非法地址,为了引起co

ELF(Executable and Linking Format)文件格式是一个开放标准,各种UNIX系统的可执行文件都采用ELF格式,ELF是一种对象文件的格式,用于定义不同类型的对象文件(Object files)的内容是什么.以及都以怎样的格式去存放这些内容.它有三种不同的类型: 1.  可重定位的目标文件(Relocatable) 这是由汇编器汇编生成的 .o 文件.后面的链接器把一个或多个可重定位的目标文件作为输入,经链接处理后,生成一个可执行的对象文件 (Executable fi

Linux工具参考篇 原文出处:[Linux Tools Quick Tutorial] 1. gdb 调试利器 2. ldd 查看程序依赖库 3. lsof 一切皆文件 4. ps 进程查看器 5. pstack 跟踪进程栈 6. strace 跟踪进程中的系统调用 7. ipcs 查询进程间通信状态 8. top linux下的任务管理器 9. free 查询可用内存 10. vmstat 监视内存使用情况 11. iostat 监视I/O子系统 12. sar 找出系统瓶颈的利器 13.

之前几篇介绍exploit的文章, 有提到return-to-plt的技术. 当时只简单介绍了 GOT和PLT表的基本作用和他们之间的关系, 所以今天就来详细分析下其具体的工作过程. 本文所用的依然是Linux x86 64位环境, 不过分析的ELF文件是32位的(-m32). 大局观 首先, 我们要知道, GOT和PLT只是一种重定向的实现方式. 所以为了理解他们的作用, 就要先知道什么是重定向, 以及我们为什么需要重定向. 重定向(relocations), 简单来说就是二进制文件中留下的"

前文链接: ELF格式探析之一:Segment和Section ELF格式探析之二:文件头ELF Header详解 今天我们讲对目标文件(可重定位文件)和可执行文件都很重要的section. 我们在讲ELF Header的时候,讲到了section header table.它是一个section header的集合,每个section header是一个描述section的结构体.在同一个ELF文件中,每个section header大小是相同的.(其实看了源码就知道,32位ELF文件中的se

0x00  前言 这篇文章其实是我之前学习elf文件关于符号表的学习笔记,网上也有很多关于符号表的文章,怎么说呢,感觉像是在翻译elf文件格式的文档一样,千篇一律,因此把自己的学习笔记分享出来.dlsym()的源码是分析的android4.4的源码,android自己实现的bonic C库. 0x01  基本流程 android中关于elf文件,关于so文件信息的结构体: struct soinfo { public: char name[SOINFO_NAME_LEN]; const Elf3

0x00  前言   最近一段时间在弄android方面的东西,今天有人发了张截图,问:在要dump多大的内存? 一时之间我竟然想不起来ELF文件的哪个字段表示的是文件大小,虽然最后给出了解决方法,IDA CTRL+S,直接看Segements信息,可以得出整个文件的大小.但说明了自己对于ELF文件格式远不如PE文件那么熟悉,毕竟看PE文件格式是抱着<加密与解密>来来回回看了好几遍,而对于ELF文件只是在网上随便找了几遍博客,现在还记得大致的结构,对于一些具体的细节却并已经遗忘的差不多.于是想

在网上关于ctf pwn的入门资料和writeup还是不少的,但是一些过渡的相关知识就比较少了,大部分赛棍都是在不断刷题中总结和进阶的.所以我觉得可以把学习过程中的遇到的一些问题和技巧总结成文,供大家参考和一起交流.当然,也不想搞那些烂大街的东西,所以,打算从一道道pwn题开始,见微知著,在题目中延伸. 一:工欲善其事必先利其器 ubuntu14.01 64位(该版本对pwntools的支持最好). pwntools:用于快速编写pwn的exp的python库,功能非常强大. IDA:二进制必备

6.1 GNU C 的扩展关键字:attribute GNU C 增加一个 __atttribute__ 关键字用来声明一个函数.变量或类型的特殊属性.声明这个特殊属性有什么用呢?主要用途就是指导编译器在编译程序时进行特定方面的优化或代码检查.比如,我们可以通过使用属性声明指定某个变量的数据边界对齐方式. __atttribute__ 的使用非常简单,当我们定义一个函数.变量或类型时,直接在它们名字旁边添加下面的属性声明即可: __atttribute__((ATTRIBUTE)) 这里需要注意

转自:http://www.cnblogs.com/leo0000/p/5632642.html 声明:以下的代码成果,是参考了网上的injso技术,在本文的最后会给出地址,同时非常感谢injso技术原作者的分享. 但是injso文章中的代码存在一些问题,所以后面出现的代码是经过作者修改和检测的.也正因为这些错误,加深了我的学习深度. 最近因为在学习一些调试的技术,但是很少有提到如何在函数运行时实现函数替换的. 为什么会想到这一点?因为在学习调试时,难免会看到一些内核方面的调试技术,内核中的调试

转自:http://blog.chinaunix.net/uid-27717694-id-3966290.html 一.概述模块是作为ELF对象文件存放在文件系统中的,并通过执行insmod程序链接到内核中.对于每个模块,系统都要分配一个包含以下数据结构的内存区.一个module对象,表示模块名的一个以null结束的字符串,实现模块功能的代码.在2.6内核以前,insmod模块过程主要是通过modutils中的insmod加载,大量工作都是在用户空间完成.但在2.6内核以后,系统使用busybo

这两天看了一本书叫<linux二进制分析>,这里面提到的一个小工具kdress,这里分析一下 源码在:https://github.com/elfmaster/kdress kdress介绍 /boot目录下有一个vmlinux的文件,这是一个经过压缩的linux内核,不过缺少内核符号表,kdress就是用来从/proc/kallsyms或是System.map文件获取相关的符号信息,将获取到的符号信息重建到内核可执行文件中去. 源码分析 首先从一个python脚本启动,然后调用c语言的实现

Q1:线上问题的process 都为release版本!不带调试信息怎么查?(目前有时需要查线上问题, 不得不解决这个问题) 之前查问题都是编译环境编译一个带有debug信息的版本进行替换来调试,但是这是对必现问题,使用gdb调试没问题,如果是非必现问题呢?替换进程重新运行现象就会消失! 解决方法:使用objcoy将信息表分离, 在打包环境编译进程时, makefile 中加入 -ggdb -O0 编译完成后使用objcopy 分离出调试信息, 然后strip 掉debug信息. objcopy