2020安洵杯--MISC

签到题
打开链接给了一个道格的微信公众号二维码，关注微信公众号回复：fl4g
得到一个链接：https://share.weiyun.com/bKjXMcZJ 密码：d0g3
链接里是一个flag.docx文件，里面是：🐻🐧👞🐪👲👎👜👣👚🐧👤👖🐸👅👛👖🐿🐨👋👖👣👠🐾👟👫🐨👰👴
用这个网站http://www.atoolbox.net/Tool.php?Id=936
解码一下就可以得到flag：D0g3{Welc0m_ANd_H1T_liGht1y}

王牌特工
文件链接：链接：https://pan.baidu.com/s/1Ahlkgsm1SYJe3V_8RomZ2g 提取码：lhh1
将得到的文件拖进虚拟机里查看一下：

(base) pwn@ubuntu:~/Desktop/test$ file findme 
findme: Linux rev 1.0 ext3 filesystem data, UUID=f2b1e8fa-29a6-454b-b6df-6182044790bc (needs journal recovery) (large files)
(base) pwn@ubuntu:~/Desktop/test$ 

可以发现是一个ext3文件，我们先挂载看下文件内的内容：

(base) pwn@ubuntu:~$ su
Password: 
root@ubuntu:/home/pwn# ls
123     code       Downloads         miniconda3  Pictures   Videos
ae64    Desktop    examples.desktop  Music       Public
alpha3  Documents  git               peda        Templates
root@ubuntu:/home/pwn# cd Downloads/
root@ubuntu:/home/pwn/Downloads# file findme
findme: cannot open `findme' (No such file or directory)
root@ubuntu:/home/pwn/Downloads# file '/home/pwn/Desktop/findme' 
/home/pwn/Desktop/findme: Linux rev 1.0 ext3 filesystem data, UUID=f2b1e8fa-29a6-454b-b6df-6182044790bc (needs journal recovery) (large files)
root@ubuntu:/home/pwn/Downloads# mkdir /mnt/abc
root@ubuntu:/home/pwn/Downloads# mount '/home/pwn/Desktop/findme' /mnt/abc
(base) pwn@ubuntu:/mnt/abc$ ls -l
total 1042
-rw-r--r-- 1 root root 1048576 Nov 21 02:49 flagbox
-rw-r--r-- 1 root root      29 Nov 21 02:49 key.txt
drwx------ 2 root root   12288 Nov 21 03:09 lost+found

挂载文件夹⾥可⻅lost+found文件夹，flagbox和key.txt. 根据key提⽰，flagbox应⽤Veracrypt打开：

key:a_cool_key
use Veracrypt

⾥⾯flag.txt显⽰这⾥是假flag，让我应该看看之前的路。想到lost+found文件夹，于是尝试从ext3硬盘镜像中恢复被删除文件。

(base) pwn@ubuntu:~/Desktop$ ext3grep ./findme --ls --inode 2
Running ext3grep version 0.10.2
WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is.
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set. This either means that your partition is still mounted, and/or the file system is in an unclean state.
Number of groups: 2
Loading group metadata... done
Minimum / maximum journal block: 218 / 1247
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1605957136 = Sat Nov 21 03:12:16 2020
Number of descriptors in journal: 29; min / max sequence numbers: 3 / 10
Inode is Allocated
Finding all blocks that might be directories.
D: block containing directory start, d: block containing more directory entries.
Each plus represents a directory start that references the same inode as a directory start that we found previously.

Searching group 0: DD+++
Searching group 1: 
Writing analysis so far to 'findme.ext3grep.stage1'. Delete that file if you want to do this stage again.
Result of stage one:
  2 inodes are referenced by one or more directory blocks, 2 of those inodes are still allocated.
  1 inodes are referenced by more than one directory block, 1 of those inodes is still allocated.
  0 blocks contain an extended directory.
Result of stage two:
  2 of those inodes could be resolved because they are still allocated.
All directory inodes are accounted for!


Writing analysis so far to 'findme.ext3grep.stage2'. Delete that file if you want to do this stage again.
The first block of the directory is 204.
Inode 2 is directory "".
Directory block 204:
          .-- File type in dir_entry (r=regular file, d=directory, l=symlink)
          |          .-- D: Deleted ; R: Reallocated
Indx Next |  Inode   | Deletion time                        Mode        File name
==========+==========+----------------data-from-inode------+-----------+=========
   0    1 d       2                                         drwxr-xr-x  .
   1    2 d       2                                         drwxr-xr-x  ..
   2    3 d      11                                         drwx------  lost+found
   3    4 r      12                                         rrw-r--r--  flagbox
   4  end r      13                                         rrw-r--r--  key.txt
   5  end r      14  D 1605957180 Sat Nov 21 03:13:00 2020  rrw-------  .coolboy.swp
   6  end r      15  D 1605957136 Sat Nov 21 03:12:16 2020  rrw-------  .coolboy.swpx

用十六进制编辑器打开修复好的.coolboy.swp文件，拉到尾部发现：

55yf55qE5a+G56CBOnRoaXNfaXNfYV90cnVlX2tleQ==

(base) pwn@ubuntu:~$ echo 55yf55qE5a+G56CBOnRoaXNfaXNfYV90cnVlX2tleQ== | base64 -d
真的密码:this_is_a_true_key(base) pwn@ubuntu:~$ 

用这个真的密码再对上一次的flagbox解密：

flag{you_are_a_cool_boy}

套娃
文件链接：链接：https://pan.baidu.com/s/1V8wrrDeLeQfiYeCW91DFSg 提取码：vqvt
打开文件发现全是带锁的文件，用ZipCenOp伪加密走了一遭发现并没有结果，用WinRAR查看password文件夹发现里面的文件字节数都一样是2符合CRC32碰撞的思路，脚本走一下：

import binascii
import string

dic = string.printable
crc1 = 0xea4446b6
crc2 = 0xed7987de
crc3 = 0x46fe0943
crc4 = 0x4be30989
crc5 = 0xb31975c0
crc6 = 0xd6bb1bef

for i in dic:
    for j in dic:
        s = i + j
        if (crc1 == (binascii.crc32(s) & 0xffffffff)):
            text1 = s
        if (crc2 == (binascii.crc32(s) & 0xffffffff)):
            text2 = s
        if (crc3 == (binascii.crc32(s) & 0xffffffff)):
            text3 = s
        if (crc4 == (binascii.crc32(s) & 0xffffffff)):
            text4 = s
        if (crc5 == (binascii.crc32(s) & 0xffffffff)):
            text5 = s
        if (crc6 == (binascii.crc32(s) & 0xffffffff)):
            text6 = s
print text1 + text2 + text3 + text4 + text5 + text6

得到结果：!qQIdEa@#!z)
对easyzip解密，得到的文件先用WinRAR修复一下，发现其中的redeme.txt文件和它的副本文件CRC值一样，分别将它们两个单独压缩，用明文攻击：

得到密码：%3#c$v!@
用base64解码：

Wm1kcFkxOWZibTkwYkh0d2NuZGpYMTk5WVhvbVkyVmhaR2xB

继续base64解码：

ZmdpY19fbm90bHtwcndjX199YXomY2VhZGlA

继续base64解码：

fgic__notl{prwc__}az&ceadi@

很明显一个栅栏密码：

flag{zip&crc_we_can_do_it}

BeCare4
文件链接：链接：https://pan.baidu.com/s/1gbIb7dvcDNp5ENuUqmdagQ 提取码：ehuh
文件里一张带锁图片和一个文本，压缩包内的照片带锁用伪加密试了试没有结果，那密码应该是在文本内了，文本的话可能存在款字节隐写，网站解一下：
oh,you found the pass:RealV1siBle
拿到图片，根据题目的提示Eye，利用SilentEye解密一下，直接得到flag：D0g3{1nV1sible_flag_Can_You_find?!}