weixin_51055545的博客

主函数开始时，调用函数，将flag文件打开，注意是在根目录下的flag,然后将flag读到全局变量s处，这个0x60很有帮助，构成了一个堆头；程序申请的0x10的堆块起到了存放指针的作用，很正常的堆布局，直接doublefree，去改指针；64位程序，关闭了pie保护，直接放到ida分析；这里注意要劫持的堆地址为s-0x10,此时；连续申请两次，再show,即可读出flag.将堆块释放后，未将指针置空，存在uaf;先申请2个查看堆布局；漏洞点在删除功能处，...

想找一道高分题来做一做，想着会很难，但分析了IDA,才发现如此简单.检查保护：基本上全开了，IDA分析：主函数中，满足这个条件就会直接get shell，直接覆盖即可,exp:from pwn import *elf = ELF('./task_gettingStart_ktQeERc')io = remote('node4.buuoj.cn',27594)#io = process('./task_gettingStart_ktQeERc')libc = elf.libccont

文章目录通过canary报错信息来解题(ssp攻击)前言：背景知识：检查保护：IDA分析：exp分析：通过canary报错信息来解题(ssp攻击)前言：​ 我们知道栈溢出的基本原理是通过发送大量数据，溢出导致覆盖返回地址，劫持程序执行流，针对开启canary保护的题目，程序中存在gets()或类似这样的危险溢出函数，却又没其他洞的情况下，我们可以利用ssp攻击达到get flag,或get shell的目的.背景知识：​ 我们输入过多数据，导致栈溢出时，程序puts出来的报错信息同样是调用了__

文章目录PicoCTF_2018_echo_back例行检查：IDA分析：exp：PicoCTF_2018_echo_back例行检查：开了部分relro,没开pie，IDA分析：函数主逻辑在vul()函数中：先打印出一句话，然后让我们输入，大小控制在0x7f，然后很明显一个格式化字符串，然后下边直接puts完后，程序结束.程序中存在system，并且没开pie，这里我们考虑直接改got表，我选择的是改printf()_got为system_plt,下边程序直接结束了，这里我们没办法去输入

例行检查是开 了部分relro，可以改写got表，然后栈不可执行不，IDA分析很简单的一个程序，会先初始化一些后续要用到的栈空间，然后让我们输入，字节数大小会有限制，然后再对我们的输入做一个长度判断，长度符合的话就会调用printf()函数，存在格式化字符串漏洞，程序里没有system，binsh字符串，我们这里就要先leak出地址，然后返回system即可，观察程序不难发现，我们无法溢出去控制返回地址，然而我们可以去改 某一函数的got表地址为system，从而去get shell，通过分析，s

例行检查：分析64位程序，一道静态编译的题目，ida中分析：主要要绕过的函数为do_stuff(),双击进去查看：我们这要猜对数字，就会返回v5=1,然后就会在主函数执行win()函数，win()函数中存在栈溢出：大小为0x168,思路就很清晰了，接下来就开始exp的编写，exp分析:猜数字直接调试就可以看到是0x54，也就是84刚开始我就直接用：root@ubuntu:/home/giantbranch/Desktop/pico# ROPgadget --binary vuln

最近学习了一些srop的一些知识，这里通过一道题目来加深一下对srop的运用。文章目录1.srop的简单介绍2.rootersctf_2019_srop题目例行检查漏洞分析1.srop的简单介绍这里推荐大家一篇文章sropSROP全称为Sigreturn Oriented Programming，其攻击核心为通过伪造一个‘Signal Frame’（以下简称sigFrame）在栈上，同时触发sigreturn系统调用，让内核为我们恢复一个sigFrame所描述的进程，如一个shell、一个wrtie

shellcode 类题目文章目录shellcode 类题目1.没开沙箱（此时我们可以系统调用get shell）picoctf_2018_shellcodemrctf2020_shellcode2.开启沙箱（orw读flag）gwctf_2019_shellcode1.没开沙箱（此时我们可以系统调用get shell）(一)32位程序系统调用32位程序有别于64位程序，32位通过栈传参，我们常用的寄存器有4个数据寄存器(eax,ebx,ecx,edx),2个变址寄存器(esi,edi)，2个指针寄

这里借鉴参考lonyliu师傅的博客，记录学习一下.NX：-z execstack / -z noexecstack (关闭 / 开启) 不让执行栈上的数据，于是JMP ESP就不能用了Canary：-fno-stack-protector /-fstack-protector / -fstack-protector-all (关闭 / 开启 / 全开启) 栈里插入cookie信息PIE：-no-pie / -pie (关闭 / 开启) 地址随机化，另外打开后会有get_pc_thunk

BUUCTF 【rctf2018_babyheap】今天下午干了一下午，估计是我太菜了呜呜呜拿到附件，先检查程序例行检查：保护机制全开，这很‘堆题’程序和漏洞分析程序又add,show,del三个功能，漏洞点在add()中;存在off by null漏洞，可以溢出一个’\x00’字节，show(),del()函数功能正常，而程序add堆块时，调用的是calloc，即限制了我们申请tcachebin，我们不能申请tcachebin，也就不可以来打free_hook来get shell

buuctf【cscctf_2019_qual_babyheap】今天找了一道100分题目，题目本身并没有那么难例行检查64位的程序，保护机制全开，放到IDA中分析漏洞分析函数功能很简单，功能基本齐全，漏洞点在creat()中，当我们申请堆块，写入内容时，会在最后多写入一个’\x00’字节，存在off by null 溢出，但程序只允许我们申请15个堆块，因此要合理利用堆块。利用思路1.通过for循环申请足够多的堆块，在将其释放，构造出unsorted bin2.堆风水，利用off

BUUCTF【ez_pz_hackover_2016】例行检查开了relro，其他保护机制都没开，扔到IDA中分析漏洞分析chall()函数中，有fgets()，但长度不够覆盖到返回地址，没法溢出，接着会获取s的长度，然后字符串检索，在这里我给出memchr()的定义：*C 库函数 void *memchr(const void str, int c, size_t n) 在参数 str 所指向的字符串的前 n 个字节中搜索第一次出现字符 c（一个无符号字符）的位置。然后程序会有一个if检查，

BUUCTF【hitcontraining_magicheap】刷题例行检查：程序为64位，除了pie，其他保护机制都开了。放到IDA中分析漏洞分析：首先看到一个菜单，发现程序是没有输出功能的，这里我们想到了去打stdout结构体来leak出地址，这里是有一个后门的，我设置了满足的条件发现没出flag，应该比赛的环境下flag路径是对的，但buuctf路径是不对的，所以我们就去get shell拿flag。漏洞点在edit()函数中，creat_heap()函数获取我们的大小后，在ed

BUUCTF【roarctf_2019_easy_pwn】检查程序：保护机制全开分析：add(),show(),free()函数都正常，漏洞点在edit()中a2-a1=10时，我们可以多写入一个字节，存在by one溢出思路：1.堆风水泄露libc地址2.堆块重叠劫持malloc_hook为one_gadget3.申请触发one_gadgetexp:leak地址：add(0x90)add(0x18)add(0x90)add(0x90)free(0)edit(1,0

一道题学习 House of force首先说明一下House of force的利用条件：1.能够通过堆溢出等方法控制到topchunk的size2.分配的大小没有限制，即可以申请任意大小的堆块3.能够泄露出堆地址(topchunk)House of force 产生的原因: 在于 glibc 对 top chunk 的处理，进行堆分配时，如果所有空闲的块都无法满足需求，那么就会从 top chunk 中分割出相应的大小作为堆块的空间。若 top chunk 的 size 值是由用户控制的任意的

Buuctf ：【ciscn_2019_es_4】检查程序：64位程序，没有开pie保护漏洞分析：edit()中存在of by null利用思路：1.堆风水构造overlap，指针残留，泄露出libc地址2.再次堆布局，劫持free_hook,覆写为system3.free掉’/bin/sh’的堆块，get shell分析：1.由于add()中限制了我们申请堆的大小，没法通过直接申请0x420的堆块泄露地址，所以要填满tcache bin,释放后进入unsorted bin中，有32

一天一道buu今天做了这道堆题没有想象的难，毕竟是道1分的题例行检查64位程序，保护机制全开的，放到IDA漏洞分析漏洞在edit()函数中，我们add()之后，在edit()时，能再次控制size的大小，存在堆溢出。分析好漏洞后，就开始利用利用思路和分析1.我们先利用堆溢出泄露出libc地址2.劫持fd指针到malloc_hook，覆盖malloc_hook为one_gadget，当再次申请堆块时调用one_gadget，从而get shell分析首先堆布局，申请0x100的堆，释放

例行检查一下程序：64位的一道堆题，放到IDA中看下：首先看到一个菜单：

例行检查程序：还是32位程序，没有canary，很可能是溢出类的。放到IDA中：主函数没什么特别，进入vuln()函数看一下：果然存在溢出漏洞，两次溢出，直接去get shell第一次溢出去泄露libc地址，第二次溢出get shell这里我选怎printf()函数作为泄露的函数，同样也可以选择puts()函数，构造payload ：io.recvuntil(':')payload = 'A'*0x6cpayload += p32(0)payload += p32(

先放进虚拟机中检查：任何保护机制都没开，放到32位IDA中：主函数很简单，进入vuln()函数看一下:很明显有溢出，进入栈中看偏移：这里偏移为0x28，我们思路是第一次溢出，去泄露libc地址，再次进行溢出get shell。第一次溢出：io.recvuntil(':')payload = 'A'*0X28payload += p32(0)payload += p32(printf)payload += p32(main)payload += p32(elf.got.

在buu里挑了一道heap的题，是一道off by null 的题，比较容易，经典一些例行检查：

Buuctf：【axb_2019_heap】(格式化字符串，of by null，unlink)例行检查64位，保护机制全开，IDA中分析漏洞分析此处edit()函数中会多写入\x00字节，导致溢出一个\x00字节，存在of by null 漏洞，add()中限制了我们申请堆块的大小，只能申请大于0x80的堆块利用思路1.利用格式化字符串漏洞泄露出程序基地址和libc基地址2.利用unlink，通过unlink修改chunk0的内存地址为free_hook地址，再次edit0号堆块，覆写为s