---
# System prepended metadata

title: 10003-sakana

---

# 10003-sakana


## Intro

本題是個類似 shell 的碗糕，提供一些妙妙指令，但大多無關警要。

## WARNING
執行環境必須要有 `ld-2.31`，其他版本都不行！！！  
請使用 gdb -> vmmap 查看

執行時需使用 `process('./sakana', env={"LD_PRELOAD":"./libc-2.31.so"})` 掛 libc 版本

## Deposit

<!-- 

首先看到命令是 512 bytes

![](https://i.imgur.com/KM2LjhW.png)

 -->


After decompiled with IDA, we discovered a hidden function `printf` in `parse_cmd`, which just echo what you've input. What worths to mention is it uses dangerous function `get_line` to get input.

![](https://i.imgur.com/mQwPpzD.png)

<!-- 
where v9 has len 264

![](https://i.imgur.com/JiFJ5I3.png)

we can use it to do a BOF.

 -->

However, by running `checksum` in `gdb` (+`gef`), we discovered that all `PIE`, `Stack Canary`, `ALSR` are all opened, that means we cannot use ordinary BOF, and we have to deal with the annoying canary.

### Leak Canary

Since that `printf` doesn't validate our input, we can put in many `%x`s to dump stack info.

Let's find where the canary is:

![](https://i.imgur.com/muL0vbg.png)
![](https://i.imgur.com/uw2Kgny.png)

Cool! Canary is at the 39th position.

### Expose PIE/Libc addr
<!-- 

expose pie...
![](https://i.imgur.com/zIEGw0l.png)

 -->

calc offsets using `vmmap`  
**The offset calculated from the pic below is WRONG! It used different libc/ld version (2.23 != 2.31)**
<!-- ![](https://i.imgur.com/EzKYcDs.png) -->
![](https://i.imgur.com/hPOA639.png)

apply offsets (this is CORRECT offset)

<!-- ![](https://i.imgur.com/2XbDrAc.png) -->

![](https://i.imgur.com/Z9Vlzm9.png)


# ROP
Create ROP chain
![](https://i.imgur.com/5lTJaDv.png)

However, we will still get SEGMENTATION FAULT :(  
According to [this link](https://hack543.com/16-bytes-stack-alignment-movaps-issue/), we discovered that when using `system()` in libc, the `rsp` stack must end with `0` (align to 16-byte address)  

So our ROP chain will be like:

![](https://i.imgur.com/1NFpD3l.png)


---

###### flag
`ADL{5aK4Na~~~cH1n4N4g0~~~https://youtu.be/Rwzy6Qt8gq8}`