每个进程所所分配的内存由很多部分组成，通常我们称之为段，一般会有如下段:
注: 为什么要区分初始化数据段，和未初始化数据段呢？,未初始化数据段简称为BSS段，有何含义BSS全称为Block Started by Symbol，其主要原因在于程序在磁盘上存储时，没有必要为未经初始化的变量分配存储空间，相反，可执行文件只需要记录未初始化数据段的位置和所需大小即可。直到运行时才分配内存空间。通过size命令可以显示可执行文件的文本段，初始化数据段，未初始化数据段的段大小信息。
大多数UNIX实现中C语言编程环境提供了三个全局符号:etext，edata，end，可在程序内使用这些符号获取文本段，初始化数据段，未初始化数据段结尾处下一字节的地址。代码如下:
通过读取proc/PID/cmdline可以得到任一进程的命令行参数信息，如果想获取程序本身的命令行参数，可以使用proc/self/cmdline来读取，对于如何获取进程的程序名有如下两种方法:
/proc/self/exe的符号链接内容，这个文件会通过符号链接到真正的可执行文件路径，是绝对路径，通过readlink可以读取其中链接的绝对路径名称
将变量声明为volatile是告诉优化器不要对其进行优化，从而避免了代码重组。例如下面这段程序:
对上面的代码使用gcc -O -S进行优化编译，查看其汇编代码。关键代码如下:
2)中间没有对a进行修改，因此根据代码的上下文分析后进行优化，直接拿%eax进行比较。但是编译器的优化仅仅只能根据当前的代码上下文来优化，如果在多线程场景下另外一个函数中对a进行了修改，但是这里却使用的是a的旧值，这就会导致代码逻辑上出现了问题，很难debug。我们来看看加了volatile关键字后情况变成什么样了。下面是加了volatile后的汇编代码:
volatile关键字远远在比我这里描述的更加复杂，这里有篇文章建议大家阅读一下，深刻了解下这个关键字的作用。。
brk和sbrk是linux提供给我们的两个用于分配内存的系统调用，内存的分配其实就是将堆区的内存空间进行隐射和物理内存页进行关联。我们的程序会大量的调用这两个系统调用，这导致一个问题就是大量的系统
调用开销的产生，为此malloc和free封装了这两个函数，通过brk和sbrk预先分配一段比较大的内存空间，然后一点点的分配出去，通过维护内部的一个记录分配出去的内存块信息，方便后面的回收和合并
这样就避免了大量系统调用的调用开销。下面是这两个函数的函数原型:
可以看出mtrace起到了内存分配的跟踪功能，会把所有的内存分配和释放操作就记录下来。
上面只是简单的演示了其基本用法，更详细的用法参见man 文档。
mcheck的功能和mprobe的功能，但是MALLOC_CHECK_这种方式无需进行修改和重新编译，通过设置不同的值来控制对内存分配错误的响应方式下面是一个使用MALLOC_CHECK_环境变量的实现方式mcheck的功能的例子:
上面的三种方式都是通过函数库的形式给程序添加了内存分配的检测，和追踪功能，我们也可以使用一些第三方的工具来完成这些功能，比较流行的有Valgrind，Insure++等。
linux提供了mallopt用来修改各选参数，以控制malloc所采用的，例如:何时进行sbrk进行堆收缩。规定从堆中分配内存块的上限，超出上限的内存块则使用mmap系统调用，此外还提供了mallinfo函数，这个函数会返回一个结构包含了malloc分配内存的各种统计数据。下面是mallinfo的接口声明和基本使用。
下面是一段代码显示了当前进程的malloc分配内存信息
下面是运行以后的结果：
关于mallopt的使用这里就略过了，因为这东西较复杂，笔者自己也没认真看过。如果你希望了解，我给你推荐的第一手资料绝对是man 3 mallopt。
关于为什么要内存对齐，我推荐给大家一篇文章，通常我们在讨论内存的时候常常会使用byte来作为内存的最小分配单位，于是乎大家就认为内存是一个字节一个字节的进行读取的……，但其实这是一个误区，byte做内存的基本单位这是从程序员的角度来看待内存的，如果是CPU的话，它不会也这样看待，毕竟一次只读一个字节似乎有点太慢，的确，对于CPU来说，内存是一个个内存块来读取，内存块的大小通常是2的整数次幂。不同的硬件不同，一般是4或8个字节，如果字节不对齐会有什么后果呢？最直接的后果就是会导致你的程序变慢。具体分析如下:
对于单字节对齐的系统来说(这也正是程序员看到的内存状态)从地址0开始读取4个字节和从地址1开始读取4个字节没有任何区别，所以也不存在字节对齐的概念，对不对齐其实都一样。对于4字节对齐的系统来说,CPU一次要读取4个字节的内容，从地址0开始读取4个字节0~3，只需要读取一次就ok了。如果从1开始读取的话，需要读二次，第一次读0~3，第二次读4~7，然后截取这两个内存块的1~4这个区域，就是读取到的四个字节的内容了。因为CPU只会一个个内存块的边界开始读取一个内存块，地址1并不是内存块的边界，因此CPU会从0开始读取。就是这样的一个简单操作导致了CPU多进行了一次读操作，可想而知内存对齐该有多重要。关于内存对齐的更多分析请看我给大家推荐的文章。linux提供了posix_memalign和memalign两个函数用于分配字节对齐的内存地址，其函数原型如下:
我们知道malloc是在堆上进行内存分配的，但是你有听过在栈上也可以分配内存的嘛，的确是可以的alloca就可以在栈上进行内存的分配，因为当前函数的栈帧是位于堆栈的顶部。帧的上方是存在可扩展空间，只需要改堆栈指针值即可，其函数原型如下:
通过alloca分配的内存不需要进行释放，因为函数运行结束后自动释放对应的栈帧，修改器堆栈指针为前一个栈帧的末尾地址。alloca是不是很神奇，笔者很想知道其实现原理。尽管上文中已经说到了，其实就是利用栈上的扩展空间，扩展了栈的空间，使用栈上的扩展空间来进行内存的分配。下面是其实现代码的汇编表示.
两者相差0x20。也就是说虽然分配的是4个字节，但是栈顶却减少了0x20个字节，那么现在的栈顶就是0x7ffd366b7fb0，之前的栈顶是0x7ffd366b7fd0，这中间的区域就是分配的空间，至于为什么是0x20这一应该是和malloc的初衷相同，考虑到字节对齐吧。
每个进程所所分配的内存由很多部分组成，通常我们称之为段，一般会有如下段:
注: 为什么要区分初始化数据段，和未初始化数据段呢？,未初始化数据段简称为BSS段，有何含义BSS全称为Block Started by Symbol，其主要原因在于程序在磁盘上存储时，没有必要为未经初始化的变量分配存储空间，相反，可执行文件只需要记录未初始化数据段的位置和所需大小即可。直到运行时才分配内存空间。通过size命令可以显示可执行文件的文本段，初始化数据段，未初始化数据段的段大小信息。
大多数UNIX实现中C语言编程环境提供了三个全局符号:etext，edata，end，可在程序内使用这些符号获取文本段，初始化数据段，未初始化数据段结尾处下一字节的地址。代码如下:
通过读取proc/PID/cmdline可以得到任一进程的命令行参数信息，如果想获取程序本身的命令行参数，可以使用proc/self/cmdline来读取，对于如何获取进程的程序名有如下两种方法:
/proc/self/exe的符号链接内容，这个文件会通过符号链接到真正的可执行文件路径，是绝对路径，通过readlink可以读取其中链接的绝对路径名称
将变量声明为volatile是告诉优化器不要对其进行优化，从而避免了代码重组。例如下面这段程序:
对上面的代码使用gcc -O -S进行优化编译，查看其汇编代码。关键代码如下:
2)中间没有对a进行修改，因此根据代码的上下文分析后进行优化，直接拿%eax进行比较。但是编译器的优化仅仅只能根据当前的代码上下文来优化，如果在多线程场景下另外一个函数中对a进行了修改，但是这里却使用的是a的旧值，这就会导致代码逻辑上出现了问题，很难debug。我们来看看加了volatile关键字后情况变成什么样了。下面是加了volatile后的汇编代码:
volatile关键字远远在比我这里描述的更加复杂，这里有篇文章建议大家阅读一下，深刻了解下这个关键字的作用。。
brk和sbrk是linux提供给我们的两个用于分配内存的系统调用，内存的分配其实就是将堆区的内存空间进行隐射和物理内存页进行关联。我们的程序会大量的调用这两个系统调用，这导致一个问题就是大量的系统
调用开销的产生，为此malloc和free封装了这两个函数，通过brk和sbrk预先分配一段比较大的内存空间，然后一点点的分配出去，通过维护内部的一个记录分配出去的内存块信息，方便后面的回收和合并
这样就避免了大量系统调用的调用开销。下面是这两个函数的函数原型:
可以看出mtrace起到了内存分配的跟踪功能，会把所有的内存分配和释放操作就记录下来。
上面只是简单的演示了其基本用法，更详细的用法参见man 文档。
mcheck的功能和mprobe的功能，但是MALLOC_CHECK_这种方式无需进行修改和重新编译，通过设置不同的值来控制对内存分配错误的响应方式下面是一个使用MALLOC_CHECK_环境变量的实现方式mcheck的功能的例子:
上面的三种方式都是通过函数库的形式给程序添加了内存分配的检测，和追踪功能，我们也可以使用一些第三方的工具来完成这些功能，比较流行的有Valgrind，Insure++等。
linux提供了mallopt用来修改各选参数，以控制malloc所采用的，例如:何时进行sbrk进行堆收缩。规定从堆中分配内存块的上限，超出上限的内存块则使用mmap系统调用，此外还提供了mallinfo函数，这个函数会返回一个结构包含了malloc分配内存的各种统计数据。下面是mallinfo的接口声明和基本使用。
下面是一段代码显示了当前进程的malloc分配内存信息
下面是运行以后的结果：
关于mallopt的使用这里就略过了，因为这东西较复杂，笔者自己也没认真看过。如果你希望了解，我给你推荐的第一手资料绝对是man 3 mallopt。
关于为什么要内存对齐，我推荐给大家一篇文章，通常我们在讨论内存的时候常常会使用byte来作为内存的最小分配单位，于是乎大家就认为内存是一个字节一个字节的进行读取的……，但其实这是一个误区，byte做内存的基本单位这是从程序员的角度来看待内存的，如果是CPU的话，它不会也这样看待，毕竟一次只读一个字节似乎有点太慢，的确，对于CPU来说，内存是一个个内存块来读取，内存块的大小通常是2的整数次幂。不同的硬件不同，一般是4或8个字节，如果字节不对齐会有什么后果呢？最直接的后果就是会导致你的程序变慢。具体分析如下:
对于单字节对齐的系统来说(这也正是程序员看到的内存状态)从地址0开始读取4个字节和从地址1开始读取4个字节没有任何区别，所以也不存在字节对齐的概念，对不对齐其实都一样。对于4字节对齐的系统来说,CPU一次要读取4个字节的内容，从地址0开始读取4个字节0~3，只需要读取一次就ok了。如果从1开始读取的话，需要读二次，第一次读0~3，第二次读4~7，然后截取这两个内存块的1~4这个区域，就是读取到的四个字节的内容了。因为CPU只会一个个内存块的边界开始读取一个内存块，地址1并不是内存块的边界，因此CPU会从0开始读取。就是这样的一个简单操作导致了CPU多进行了一次读操作，可想而知内存对齐该有多重要。关于内存对齐的更多分析请看我给大家推荐的文章。linux提供了posix_memalign和memalign两个函数用于分配字节对齐的内存地址，其函数原型如下:
我们知道malloc是在堆上进行内存分配的，但是你有听过在栈上也可以分配内存的嘛，的确是可以的alloca就可以在栈上进行内存的分配，因为当前函数的栈帧是位于堆栈的顶部。帧的上方是存在可扩展空间，只需要改堆栈指针值即可，其函数原型如下:
通过alloca分配的内存不需要进行释放，因为函数运行结束后自动释放对应的栈帧，修改器堆栈指针为前一个栈帧的末尾地址。alloca是不是很神奇，笔者很想知道其实现原理。尽管上文中已经说到了，其实就是利用栈上的扩展空间，扩展了栈的空间，使用栈上的扩展空间来进行内存的分配。下面是其实现代码的汇编表示.
两者相差0x20。也就是说虽然分配的是4个字节，但是栈顶却减少了0x20个字节，那么现在的栈顶就是0x7ffd366b7fb0，之前的栈顶是0x7ffd366b7fd0，这中间的区域就是分配的空间，至于为什么是0x20这一应该是和malloc的初衷相同，考虑到字节对齐吧。
今天我们继续来看apk的相关知识，在前一篇：破解apk我们今天主要来看如何使用IDA来调试中的native源码，因为现在一些app，为了安全或者效率问题，会把一些重要的功能放到native层，那么这样一来，我们前篇说到的Eclipse调试smali源码就显得很无力了，因为核心的都在native层，Android中一般native层使用的是so库文件，所以我们这篇就来介绍如何调试so文件的内容，从而让我们破解成功率达到更高的一层。
我们在介绍如何调试so文件的时候，先来看一下准备知识：
早在之前的一篇文章：中使用IDA工具静态分析so文件，通过分析arm指令，来获取破解信息，比如打印的log信息，来破解apk的，在那时候我们就已经介绍了如何使用IDA工具：
这里有多个窗口，也有多个视图，用到最多的就是：
2、IDA View对应的so中代码指令视图：这里我们可以查看具体函数对应的arm指令代码
3、Hex View对应的so的十六进制数据视图：我们可以查看arm指令对应的数据等
当然在IDA中我们还需要知道一些常用的快捷键：
1、强大的F5快捷键可以将arm指令转化成可读的C语言，帮助分析
首先选中需要翻译成C语言的函数，然后按下F5：