Misc
第二周
拜师之旅②
binwalk发现有两个zlib，补全文件头得到另外一张png
得到flag
SHCTF{1t_is_@_lucky_idat}练假成真
图片分离后扫描二维码得到码表
ABCDjp0yIJKLSVOPQNMzURWX9cabZdefgFiEklmnohqrstuvwxhTG21345678Y+/分析二维码
二维码尺寸为29x29，由公式 (V-1)*4 + 21=29 可以推出二维码的Version为3，通过这张图可以得到 format information 为 101101101001011
通过查询可以知道此二维码使用的纠错等级为 M 以及使用的掩码为 3
其掩码对应的计算公式为：
( i + j ) mod 3 = 0
可以直接在QRazyBox上进行掩码填充，并用灰色块覆盖未知区域（灰色块在后续 Extract QR Information 中会被解码为 ? ，最后得到的如下图：
通过 Extract QR Information 功能对掩码填充前的图案进行信息收集（此处的信息收集自动进行掩码填充，前面手动掩码填充只是为了能够看到原始图象，方便读取数据），二维码数据读取有固定的顺序，大致如下：
通过解码得到的数据如下
[
"01000001","111101??","????????","????????",
"????????","????????","????????","????????",
"??100110","10100100","01100110","????????",
"????????","????????","????????","????????",
"????????","????????","????????","????????",
"????????","????????","????????","????????",
"????????","????????","????????","????????",
"????????","????????","???????1","10010111",
"11010000","1?1?????","?????001","11101100",
"00010?0?","???????0","00010001","11101100",
"00010001","111?1???","??010001","11101100",
"11111010","11011000","01111111","11001110",
"11110010","00100110","10110001","10000010",
"00011010","01110100","00010101","01001100",
"10010110","00001000","00010111","11001001",
"00001011","10101001","01100101","10010100",
"10110111","01011101","10000000","00001110",
"01111???","????????"
]先看前两个 01000001 , 111101??
0100 表示编码方式，此处为字节模式
编码方式后面是数据长度，根据版本和编码方式可以确定数据位数的长度
所以 0100 后面8位 00011111指示了长度信息，转换成十进制就是31，也就是说数据总长度为31个字节。数据会按每组8个bit分组，如果所有的编码加起来不是8个倍数我们还要在后面加上足够的0，在最初解码的时候我们能够看到第31个字节为 } ，通过查询发现他在第32组低四位和第33组高四位，第33组低四位为0000结束符
"1001 0111","1101 0000"接着就是补齐符。如果添加上结束符之后还没有达到我们最大的bits数的限制，我们还要加一些补齐码，补齐码就是重复这两个bytes：11101100 00010001 。至于要补多少个补齐符，需要查看文档中相应的字符数和数据容量对应表。从表中，我们可以知道，version 3-M 的数据容量为61个数据码字（每个数据码字为8位），而我们上面已经有了31个数据码字，所以要补充30个8bit，也就是15组补齐码。
可以通过自带的 Padding Bits Recovery 功能对其进行补齐，补齐后的数据如下：
["01000001","111101??","????????","????????",
"????????","????????","????????","????????",
"??100110","10100100","01100110","????????",
"????????","????????","????????","????????",
"????????","????????","????????","????????",
"????????","????????","????????","????????",
"????????","????????","????????","????????",
"????????","????????","???????1","10010111",
"11010000","11101100","00010001","11101100",
"00010001","11101100","00010001","11101100",
"00010001","11101100","00010001","11101100",
"11111010","11011000","01111111","11001110",
"11110010","00100110","10110001","10000010",
"00011010","01110100","00010101","01001100",
"10010110","00001000","00010111","11001001",
"00001011","10101001","01100101","10010100",
"10110111","01011101","10000000","00001110",
"01111???","????????"]通过观察我们还可以发现，如果最后一位为 } ，那么前面几位极有可能为 SHCTF{ ，将其解码后数据符合第二组数据低四位的前两位
0101 00110100 10000100 00110101 01000100 01100111 1011得到进一步修复后的数据，并且缺失的字节数Number of missing bytes (erasures) : 24 bytes (34.29%)
["01000001","11110101","00110100","10000100",
"00110101","01000100","01100111","1011????",
"??100110","10100100","01100110","????????",
"????????","????????","????????","????????",
"????????","????????","????????","????????",
"????????","????????","????????","????????",
"????????","????????","????????","????????",
"????????","????????","???????1","10010111",
"11010000","11101100","00010001","11101100",
"00010001","11101100","00010001","11101100",
"00010001","11101100","00010001","11101100",
"11111010","11011000","01111111","11001110",
"11110010","00100110","10110001","10000010",
"00011010","01110100","00010101","01001100",
"10010110","00001000","00010111","11001001",
"00001011","10101001","01100101","10010100",
"10110111","01011101","10000000","00001110",
"01111???","????????"]之前我们提到了纠错级别，二维码中有四种纠错级别：从低到高为L、M、Q、H。二维码残缺量不超过所对应的纠错等级允许的范围时，使用扫描工具依旧能扫描出内容，这就是为什么有人在二维码的中心位置加入图标，也依旧能够扫描的原因。
查看纠错等级表，可以发现 Version3—M 纠错等级最多只能恢复 15% 的数据，查看 GB/T 18284-2000 ，可以得到纠错码字数为26，符合要求
即只要二维码的损坏面积没有超过这个范围，理论上是可以恢复损坏的数据的。至于纠错码是如何计算的，这涉及到里德-所罗门纠错算法（Reed-Solomon error correction）
里德-所罗门码是定长码。这意味着一个固定长度输入的数据将被处理成一个固定长度的输出数据。在最常用的（255,223）里所码中，223个里德-所罗门输入符号（每个符号有8个位元）被编码成255个输出符号。大多数里所错误校正编码流程是成体系的。这意味着输出的码字中有一部分包含着输入数据的原始形式。符号大小为8位元的里所码迫使码长（编码长度）最长为255个符号。标准的（255,223）里所码可以在每个码字中校正最多16个里所符号的错误。由于每个符号事实上是8个位元，这意味着这个码可以校正最多16个短爆发性错误。
里德-所罗门码，如同卷积码一样，是一种透明码。这代表如果信道符号在队列的某些地方被反转，解码器一样可以工作。解码结果将是原始数据的补充。但是，里所码在缩短后会失去透明性。在缩短了的码中，“丢失”的比特需要被0或者1替代，这由数据是否需要补足而决定。（如果符号这时候反转，替代的0需要变成1）。于是乎，需要在里所解码前对数据进行强制性的侦测决定（“是”或者“补足”）。
利用 Reed-Solomon Decoder 模块进行解码
将括号内的进行base64换表解码
得到flag
SHCTF{THis_F14GTHis_F14G}遮遮掩掩?CCRC!
观察可以发现压缩包内文件均为3Betys，CRC32的3Bytes爆破得到密文
呋食性意怎嗄咯非捕呱達嗚呦噤更取訴覺覺山捕吖萌嘶嘍噤寶你類嘶噤啽很有住出捕既哮噗圖咬喜樣註性与熊论道解码得到flag
SHCTF{F0ll0w_TaFFy_m1@0_ThanK5_M1@0}
