一、对保护机制的探索：

本文针对刷过的题目，介绍一些常见的保护机制以及破解方法，这里一个个介绍。

1、checksec

工欲善其事必先利其器，这个指令用于检查题目的保护机制以及判断是32位还是64位的程序，专业地讲是用来检查可执行文件属性，例如PIE, RELRO, PaX, Canaries, ASLR, Fortify Source等等属性。 举个栗子：

checksec + 文件名，可实现检查功能：

2、Arch表示位数，amd64-64-little表示该程序是64位的，32位的是i386-32-little：

1
2
3
4
5
6

[*] '/home/v1ct0r/Desktop/Review/pwn2'
    Arch:     i386-32-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x8048000)

3、FORTIFY（强化）

fority其实是非常轻微的检查，用于检查是否存在缓冲区溢出的错误。适用情形是程序采用大量的字符串或者内存操作函数，如memcpy，memset，stpcpy，strcpy，strncpy，strcat，strncat，sprintf，snprintf，vsprintf，vsnprintf，gets以及宽字符的变体。

_FORTIFY_SOURCE设为1，并且将编译器设置为优化1(gcc -O1)，以及出现上述情形，那么程序编译时就会进行检查但又不会改变程序功能

_FORTIFY_SOURCE设为2，有些检查功能会加入，但是这可能导致程序崩溃。

gcc -D_FORTIFY_SOURCE=1 仅仅只会在编译时进行检查 (特别像某些头文件 #include <string.h>)

gcc -D_FORTIFY_SOURCE=2 程序执行时也会有检查 (如果检查到缓冲区溢出，就终止程序)

所以编辑时，可以有如下代码：

1
2
3

gcc -o test test.c							// 默认情况下，不会开这个检查
gcc -D_FORTIFY_SOURCE=1 -o test test.c		// 较弱的检查
gcc -D_FORTIFY_SOURCE=2 -o test test.c		// 较强的检查

4、NX（DEP）

NX即No-eXecute（不可执行）的意思，NX（DEP）的基本原理是将数据所在内存页标识为不可执行，当程序溢出成功转入shellcode时，程序会尝试在数据页面上执行指令，此时CPU就会抛出异常，而不是去执行恶意指令。

通俗地讲，就是堆栈不可执行保护，即我们的shellcode(一段可以直接调用system(“/bin/sh”)函数getshell的代码)

无法在堆栈中执行，没有x权限。编译时有如下命令：

1
2
3

gcc -o test test.c					// 默认情况下，开启NX保护
gcc -z execstack -o test test.c		// 禁用NX保护
gcc -z noexecstack -o test test.c	// 开启NX保护

5、RELRO

在Linux系统安全领域数据可以写的存储区就会是攻击的目标，尤其是存储函数指针的区域。 所以在安全防护的角度来说尽量减少可写的存储区域对安全会有极大的好处.

GCC, GNU linker以及Glibc-dynamic linker一起配合实现了一种叫做relro的技术: read only relocation。大概实现就是由linker指定binary的一块经过dynamic linker处理过 relocation之后的区域为只读.

设置符号重定向表格为只读或在程序启动时就解析并绑定所有动态符号，从而减少对GOT（Global Offset Table）攻击。RELRO为” Partial RELRO”，说明我们对GOT表具有写权限。

说白了，默认情况下，got表可改，开了保护，got表不可改。

1
2
3
4

gcc -o test test.c						// 默认情况下，是Partial RELRO
gcc -z norelro -o test test.c			// 关闭，即No RELRO
gcc -z lazy -o test test.c				// 部分开启，即Partial RELRO
gcc -z now -o test test.c				// 全部开启，即

6、canary（金丝雀的故事，感兴趣自己谷歌~）

就是栈溢出保护，栈溢出保护是一种缓冲区溢出攻击缓解手段，当函数存在缓冲区溢出攻击漏洞时，攻击者可以覆盖栈上的返回地址来让shellcode能够得到执行。当启用栈保护后，函数开始执行的时候会先往栈里插入cookie信息，当函数真正返回的时候会验证cookie信息是否合法，如果不合法就停止程序运行。攻击者在覆盖返回地址的时候往往也会将cookie信息给覆盖掉，导致栈保护检查失败而阻止shellcode的执行。在Linux中我们将cookie信息称为canary。

通俗地讲，canary被覆盖成aaaaaaaa的话，就会直接报错，exit，一般情况下，canary位置如下：

接着我们填充垃圾字符会覆盖canary，就会触发stack_check_fail函数，执行exit退出程序，编辑如下：

1
2
3
4

gcc -o test test.c						// 默认情况下，不开启Canary保护
gcc -fno-stack-protector -o test test.c  //禁用栈保护
gcc -fstack-protector -o test test.c   //启用堆栈保护，不过只为局部变量中含有 char 数组的函数插入保护代码
gcc -fstack-protector-all -o test test.c //启用堆栈保护，为所有函数插入保护代码

7、PIE（ASLR，又叫内存地址随机化）

一般情况下NX（Windows平台上称其为DEP）和地址空间分布随机化（ASLR）会同时工作。

PIE最早由RedHat的人实现，他在连接起上增加了-pie选项，这样使用-fPIE编译的对象就能通过连接器得到位置无关可执行程序。fPIE和fPIC有些不同。可以参考Gcc和Open64中的-fPIC选项.

gcc中的-fpic选项，使用于在目标机支持时，编译共享库时使用。编译出的代码将通过全局偏移表(Global Offset
Table)中的常数地址访存，动态装载器将在程序开始执行时解析GOT表项(注意，动态装载器操作系统的一部分，连接器是GCC的一部分)。而gcc中的-fPIC选项则是针对某些特殊机型做了特殊处理，比如适合动态链接并能避免超出GOT大小限制之类的错误。而Open64仅仅支持不会导致GOT表溢出的PIC编译。

gcc中的-fpie和-fPIE选项和fpic及fPIC很相似，但不同的是，除了生成为位置无关代码外，还能假定代码是属于本程序。通常这些选项会和GCC链接时的-pie选项一起使用。fPIE选项仅能在编译可执行码时用，不能用于编译库。所以，如果想要PIE的程序，需要你除了在gcc增加-fPIE选项外，还需要在ld时增加-pie选项才能产生这种代码。即gcc -fpie -pie来编译程序。单独使用哪一个都无法达到效果。

内存地址随机化机制（address space layout randomization)，有以下三种情况：

1
2
3
4
5
6
7
8

0 - 表示关闭进程地址空间随机化。
1 - 表示将mmap的基址，stack和vdso页面随机化。
2 - 表示在1的基础上增加堆（heap）的随机化。
gcc -o test test.c				// 默认情况下，不开启PIE
gcc -fpie -pie -o test test.c		// 开启PIE，此时强度为1
gcc -fPIE -pie -o test test.c		// 开启PIE，此时为最高强度2
gcc -fpic -o test test.c		// 开启PIC，此时强度为1，不会开启PIE
gcc -fPIC -o test test.c		// 开启PIC，此时为最高强度2，不会开启PIE

开了和没开内存地址随机化是2回事，难度也是一个天一个地~

二、总结

综上，在出题时一般可以参考：

1
2
3
4

NX：-z execstack / -z noexecstack (关闭 / 开启)
Canary：-fno-stack-protector /-fstack-protector / -fstack-protector-all (关闭 / 开启 / 全开启)
PIE：-no-pie / -pie (关闭 / 开启)
RELRO：-z norelro / -z lazy / -z now (关闭 / 部分开启 / 完全开启)

以上就是常见的保护机制，那么知道了保护机制，怎么破解又可以用几篇文章来讲了，预知后事，请看下集：

栈溢出从入门到放弃3~