玩大家的2019新年红包

新年最快乐的是拿红包，解谜红包更好玩！又到了新的一年，大家都准备好了新年红包呢。这里收拾了一些我解一些大佬的红包的过程。

0x0000 索引

正在加载…

0x0100 laosb 的新年红包

放出时间：2019 年 1 月 1 日

地址：https://xn--xv9h.lao.sb/2019/newyear/

难度：感觉应该是非常容易，因为 10 分钟就能 AK。

0x0101 The Guess Game

直接点击弹出了一个 alert 说数字太大，查看源码发现了调用的函数 window.guessGame.answer(2019)。去控制台把参数改成了 2018，还是说太大，又把参数改成了 0，说是太小。因为源码是走的 wasm，所以可以通过反编译拿到答案，但我这里选择了 override alert 函数的方法：

function getAnswer(i){
    let isCorrect=false;
    window.alert=function(str){
        if(str.indexOf('small')<0 && str.indexOf('big')<0){
            isCorrect=true;
        }
    }
    window.guessGame.answer(i);
    if(isCorrect){
        console.log(i);
    }
}
for(let i=0;i<=2019;i++)getAnswer(i);

拿到了第一组数字

0x0102 The Christmas Egg

根据源码中 <a href="step1/the_number_you_held/" style="display: none;">Step #1 - The Christmas Egg</a>，得知第二组的 url 是 step1/32/ 进入第二组。

直接点击按钮并没有什么卵用。看源码发现请求了 ./the_package/3.11.5.json，手动请求发现其内容为 { "title": "Ho ho ho!" }。联想到圣诞节的时候，Ant Design 那个吓人的“彩蛋”，是在 3.11.6 中被移除的。于是改成 3.11.6 得到第二组数字。

0x0103 The Typo I've made

根据之前的 url 构造出 step2/22/。提示已经很明显说了这是一个 typo，我们也可以注意到这里有个 button 写着“regbeg”。所以如果脑洞够大的就可以直接在控制台里看到 regbeg 的值就是第三组。

但是我脑洞不够大，其实这个 typo 我还是在看 generateRedBag 的代码的时候才发现的。

// laosb diss 了 antd 并且安利了一波他的 Holakit。不过 Holakit 是真的香。

0x0104 ?

这个关卡似乎没有名字。但是出的很有迷惑性，以至于我看群里一大堆人以为自己在前一关没搞出正确答案。这看起来是个 404 页面，其实并不是。刚开始我也以为我没搞出正确答案，但是看见控制台的不寻常，我就懂了一切。

step3/65 的 status 并不是 404。（还好 status 不是 404 要不然真的找死都找不到了。）那么玄机一定在这个页面上。

utf-53……

行了，AK。

0x01ff

拼接后答案为 32226553。谢谢 laosb！

0x0200 cyy (Round 2)

放出时间：2019 年 2 月 3 日

因为 cyy 的 round 1 是和我讨论做出来的，所以我当时没解，今天他做了 round 2 当然要玩一玩呀。

地址：https://hs.cyyself.name:4343/2019-red-envelope-r2/

难度：稍微有点简单。还是比较绕的。

0x0201 Problem A. 签到

刚开始进入 /a/index.html 就跳转，我还以为是在 index.html 上做文章。但是并没有看到可疑的 header 或内容。就跟着去了跳转的页面。

页面提示“下一步在哪儿”，但是源码并没有什么的奇怪的东西。最后才注意到页面文件名可能是个 MD5。使用工具可得

md5("step1")="2e957eb8c030fc2d10de5607715f4c55"

因此如法炮制 md5("step2")="9b782e40768fc9007786b032ba7911aa" 并替换进 URL。得到一个登录框。随便输了一堆东西，都提示密码不正确。

然后尝试看看存不存在注入漏洞的时候敲了个引号(')就拿到了红包。

0x0202 Problem B. 来自中老年的表情包

这是一个 GIF。

首先我们先来看看图片序列。并没有奇怪的东西。

binwalk 发现了一个 zip。解压……啥玩意儿，要密码？尝试直接去除加密标记位，解压失败，所以也不是伪加密。

因为坚信 cyy 留了点什么线索，结果在这里卡了半个多小时。最后选择了暴力的方式，得到密码为 2019。得到 happy.wav。

显然是个 DTMF 信号，翻译得到口令。

0x0203 Problem C. 神秘的祝福

下载得到的是一个可执行文件……直接上 IDA 吧。

main 函数里有个 MOV [RBP+flag], 21616767，然后用这个作为参数调用了 cal 函数，这个函数里有个字符串 {flag_ZhiHuBao_69871339}。然而！这两个八位数字都不是口令！

看来关键应该是在 cal 函数里面了。

cal 函数的逻辑是将那个 flag 字符串的字符值依次相加得到 sum。最后 21616767 ^ sum * sum 的值就是红包口令。

0x0204 Problem D. 这辈子也不可能拿到的

这个页面好嚣张。我今天还偏要拿到你。说着看了眼 header。

hmm……

这才是签到题吧！

0x02ff

最后共计得到 0.45+1.09+14.57+0.12 共 16.23 元。感谢 cyy！

0x0300 laosb 的春节红包

放出时间：2019 年 2 月 4 日约 20 时

地址：https://xn--xv9h.lao.sb/2019/spring_festival/major/

难度：我感觉是较难，比较需要脑洞。

首先打开首页，阅读了说明、看了 header，啥都没有。

最后看了眼源码。发现了三个奇怪的地方：注释、meta 标签的 tracker 属性、一个隐藏的超链接。

注释说的是获得 token 的方式，就是请求 getPart/{partName}/{sha1(token)}。

隐藏的超链接指向 major 目录，看起看来是其中的一个 token。tracker 属性里的 base64 解出来是 commit new major guess。联想一下 major，可知其他三个都是子目录，那就一个个来吧。

0x0301 commit

这里得到的是一个 patch 文件。

利用 GitHub 的高级搜索功能可以定位到 meteor/meteor 这个仓库和 laosb 的 #8452，然后就可以找到合并这个 pr 进上游的 commit。然后打开它的 patch。

https://github.com/meteor/meteor/commit/1c9eacaeb882f9f7b70a4a1e8b7e8d4cf7bd9161.patch

完全一致。

最后就是将 commit hash 给 sha 掉就好了。（这里 laosb 表示，提示词“commit”本身就是线索，所以 token 是 commit hash）

https://xn--xv9h.lao.sb/2019/spring_festival/getPart/commit/3467bd53fad00ca7cd88cffa30f4e030bfd0de70

0x0302 new

这一关的确出的别出心裁。因为页面上的提示语 new/Yeah!/ 和 getPart 的 URL 规则很相似，所以我尝试了 Yeah! Year 2019 等等字符串的 sha1，均失败。

一帧帧看了 GIF、又看了遍 GIF 的 hex 之后还是不知道在哪儿。盯着这个提示语，突然灵机一动，在 GIF 的 base64 中搜索 new/ 结果真的找到了一个符合 new/{token}/ 的字串。

把中间的 mpAAFcRW2XcaASCa 拉出来 sha 掉，就是正解。

https://xn--xv9h.lao.sb/2019/spring_festival/getPart/new/6c40c78b2b93c208dc3dd7e5310819860f0f13a8

0x0303 major

音频文件，不过 laosb 在页面上“挂着羊头卖狗肉”。链接写着 Rec_002.wav，却是指向 Rec_001.wav 的。修正链接下载到 Rec_002.wav。

音频一般是直接丢进 Audition。

刚开始因为群里先开始玩的 Jack 说了 DTMF 很鬼畜，laosb 说“全损音质不是给人听的”，然后我就以为 laosb 是用 DTMF 做的，然后让我们通过频谱来读。也就先入为主的在频谱图上找了半天 DTMF。浪费了几十分钟一无所获之后我冷静下来，重新阅读了页面上的提示。

要牢牢地抓住一个中心和两个基本点。两个基本点可能没那么容易掌握，但是很重要。

然后我又听了一遍音频，果然有三段比较明显的特定频率的声音。

又想到了页面说要“除以 100 再把三个连接起来”，就想到了这三段声音的频率才可能是重点。

2.6 kHz

3.5 kHz

800 Hz

所以最后的 token 是 263508，sha 掉它，一切解决。

https://xn--xv9h.lao.sb/2019/spring_festival/getPart/major/1026edeb20aafb543d6d53c9fc6e8c8d82efb36a

0x0304 guess

这是元旦的 Guess Game 的升级版本。查看源码。

<a href="#" onclick="window.guessGame.answer('89iuerguiytn8y23ct8erignyvqeycn9q83ynx9qngadjghadhfkljg')">Step #undefined - The Guess Game</a>

看起来这次是猜字符串了。并且点击相应元素还会返回一个 9t84f48g5f2o6h892h75g825hf675cnvnc9xs8kaorejyqty834yt99。

既然当时 laosb 说了遍历并不是预期解，这次的页面上也说“一百以内的数字太简单”。所以上反汇编还是有必要的。

首先下载 wasm，利用工具转换成 wat。

直接读 wat 还是太硬核了，但是我的直觉告诉我这应该是一个字符串比较，因此去找 data 区可以发现这些东西。

可见最后一个划线部分是之前页面返回的那个字符串，而前面是“Great that's right”“Nearly the answer.”这些提示语。那前面划线那一长串不明含义的字符串就可能是答案。但是太长了，于是根据前面返回的字符串长度刚好可以切成两个。

7h84f4875f2o6h892h75f825hfjdjcnvnc9xskkaorejyqty834yt98 // Great that's right
7h84f4875f2o6h892h75f825hf775cnvnc9xskkaorejyqty834yt98 // Nearly the answer.

sha 掉第一个字符串，得到正解。

https://xn--xv9h.lao.sb/2019/spring_festival/getPart/guess/7cb42c05bd136b03ef44efc864f515447e0129dd

0x03ff

现在我们手里有了这样的 token。

commit  4 1
        6 5

new     0,2 7

major   5,7 3

guess   1 4
        3 2

完了，不知道怎么样组装成一个 8 位的支付宝红包口令。

我仔细观察了 13 分钟，最后终于找到了规律。（要不是我抄写到 notepad 上的时候，在逗号中间加了空格（~~我干扰我自己~~），估计花不了这么长时间。）

每一组是两位数，空格前代表位置，空格后是位置上的数字，于是组合后是 74721353。

感谢 laosb。

红包领取截图

似乎没有第二个人领走呢。

最下面一个据 laosb 说是直接给妹子红包码然后妹子领走的（

~~所以正确解法是找 laosb 妹子要出口令。~~

0x0400 Jack

放出时间：2019 年 2 月 4 日 13 时

地址：http://bucket.renjikai.com/2019_RedBag.zip 这个是所有中间过程的 zip 包，Jack 最初发出来的是压缩包内的 10.Release/Redbag.zip。

难度：比较容易，只要比较熟悉套路就好。而且 Jack 也说了借鉴了 cyy 红包的一部分。

0x0401 带拉链的涂鸦

解压了以后可以得到一个 flag.png。直接打开以后可以看到一个儿童画（逃）。

使用工具并没发现 PNG 的校验码什么的有误，随后 binwalk。

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 1605 x 789, 8-bit/color RGB, non-interlaced
91            0x5B            Zlib compressed data, compressed
43089         0xA851          Zip archive data, encrypted at least v2.0 to extract, compressed size: 1632974, uncompressed size: 2662688, name: flag_linux_amd64
1676109       0x19934D        Zip archive data, encrypted at least v2.0 to extract, compressed size: 1670871, uncompressed size: 2777036, name: flag_windows_amd64.exe
3347032       0x331258        Zip archive data, encrypted at least v2.0 to extract, compressed size: 12, name: Password is 8 number digits
3347412       0x3313D4        End of Zip archive, footer length: 22

可以发现在 PNG 尾部有追加的 zip 压缩包。解压发现有密码，但是有个文件提示密码是 8 位数字。于是提取出压缩包用工具爆破，很快就能得到 20199102 为压缩包的密码。

0x0402 代价很大的新年祝福

解压后可以得到两个可执行文件，这两个可执行文件的功能应该都是一样的。运行后只输出了一个新年祝福。本来我以为是和 cyy 一样隐藏了一个算法在其中，结果丢进 IDA 发现还真的只是一个 printf。我就纳闷儿了。这到底是为什么呢？

随后我注意到了这两个可执行文件不寻常的大小，一个 printf 显然只需要一点点，但是为啥需要 2M+？

然后我就发现了有个 wav 被藏在了 data section 里面，把它抠出来。

0x0403 打不出去的电话

打开 wav，可以看出来这是组很清晰的 DTMF 信号。

使用工具可以读出这样一组序列。

124254701302443011630246572234451223306211025275122212505542044352521455102256525702525206015250526212345162426615022051524224525242523054125253102254501241403452025030071

这是啥，显然不是电话号码。我仔细观察了数字的规律，发现它只包含了 0-7 八个数字，猜测是八进制。于是我将其转换为十六进制，发现是一组疑似 Base64 的编码。

0x0404 转换来转换去

使用 Base64 解码可得 MZWGCZ33IFWGS4DBPFPVAYLTONPTOMBXGI2TMMZQPU======。但是单凭这个并不能确定它是什么形式的编码。前面都挺顺利的，在这儿卡了不少时间，经过 Jack 的提示，选择了 Base32 进行解码，最后得到了 flag{Alipay_Pass_70725630}。