a_silly_coder的博客

首先检查保护将文件拖入64位ida查看代码逻辑，发现这个代码有些复杂，但是大多数都是无效信息，很多输入都是指引程序进行的，扰乱我们的视线。关键信息有：v3v4的数值地址都给出来了，然后查看sub_400D72函数这里首先输入一个name，这是干扰输入，只要不超过0xC的长度即可。然后sub_400A7D也是干扰输入，只需要跟着代码输入就可以了。接着查看sub_400BB9与sub_400CA6sub_400BB9这里很显然是有一个格式化字符串漏洞。接着看s...

首先检查文件保护将文件拖入32位ida阅读代码后，发现这是一个简单的格式化字符串漏洞，通过修改pwnme的数值为8，直接执行cat flag。pwnme在0x0804A068的位置。随后用gdb确认偏移，有两种方法，一种是直接数栈上的位置，另一种是输入AAAA.%x.%x.%x查看。我采用第一种。栈上是第11个位置，但是由于第一个位置参数是格式化字符串，所以输入的AAAA其实是格式化字符串的第10个参数。开始编写攻击脚本。from pwn import ...

下载文件后首先检查保护，发现不存在canary，可以进行栈溢出。将文件拖入ida32位进行查看，发现是一个简单的登录。首先在login()中输入账号和密码，发现passwd存在buf中，可输入长度有0x199，然后传入check_passwd()函数中。然后在check_passwd中将0x199长度的buf复制给dest，但是dest距离ebp只有0x14，我们也在文件中发现了cat flag的函数，所以思路就很清晰了，在输入密码时，输入一个长字符串，在check_passwd函数..

下载文件后首先查看保护，发现可以进行栈溢出攻击将文件拖入32位ida进入vulnerable_function后，发现了read处有栈溢出漏洞在查看代码后，发现没有提供system和bin/sh，但是由于给了libc，所以可以找到libc的偏移量，然后计算出system和bin/sh的加载地址。对于plt表，got表，实际加载地址，我是这么理解的：通过elf.plt['write']获取到的是write在plt表中的地址1，这个地址1上存放的实际内容是write在got表的地..

下载文件后，首先检查保护：将文件拖入64位ida，查看代码基本逻辑是：读取一个输入，存入unk_601068，接着比较dword_60106C是否等于一个预期的值，如果相等，执行对应函数，函数内直接执行cat flag.txt所以思路就是需要覆盖dword_60106C，让其等于预期值，此时我们需要在输入unk_601068时，对dword_60106C进行覆盖，接着我们查看这两个值的存放位置。发现这两个值之间相隔4个字节，所以需要4个字节的填充数据，接着输入预期值。..

下载文件后，首先检查保护：将文件拖入64位ida阅读main函数后，发现执行后就直接获取了控制权，根本不需要任何攻击。所以脚本如下，只需要连接即可。执行脚本：

下载文件后，首先检查保护：随后将文件拖入ida，查看源码，在hello函数中，发现了如下代码首先用安全的fgets输入了一个变量，接着用不安全的gets接收了一个变量，在此处可以确认是栈溢出，且溢出点就在此处。开始寻找利用方式，发现了system函数还缺一个"/bin/sh"字符串，找遍了代码，没有发现，但是由于此前可以有一个自己的输入，保存在name变量上，即可以自己手动输入"/bin/sh"，自此，设计栈结构为：开始编写脚本：from pwn imp...

下载文件后，首先检查保护开启了金丝雀，不能溢出到返回地址将文件拖入ida阅读代码逻辑是：首先输入name（赋值给v7），接着使用seed[0]作为种子生成10个随机数，每一轮都要猜对，10轮后进入sub_C3E()函数，我们进入这个函数后，发现是直接执行cat flag。回头看main函数，发现v7和seed[0]都在栈上，且给v7赋值时使用的gets()方法所以确定攻击思路：在输入name时，输入足够长的数据，覆盖seed[0]，然后自己模拟C语言的rand()方法生...

下载文件后，首先查看保护将文件拖入ida 32位，发现函数名明示了攻击点点进vulnerable_function函数后，发现buf距离ebp有0x88的距离，但是可以读入0x100的大小，确定这是一道栈溢出的题目，溢出点就在此处。确定溢出点后，开始寻找利用方式，发现代码中给出了system函数，在0x8048320的位置随后寻找sh或者bin_sh字符串：此时要素齐全，开始编写脚本。设计栈的结构为：脚本为：发送脚本，开始攻击：...

下载文件后首先查看文件的保护将文件拖入ida，反汇编后，发现有个函数名已经明示了进入vulnerable_function后，发现buf到rbp的距离为0x80，而read中给buf赋值的空间有0x200，确定这是一道栈溢出的题目，溢出点就在此处。随后发现文件提供了callsystem。开始着手编写脚本。payload解释：buf距离rbp有0x80的长度，再加上需要覆盖rbp的8位（64位下覆盖rbp需要8字节）所以填写的垃圾数据有0x80 + 0x8。rbp后是返回.