玩大家的2019新年红包


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


0x0000 索引

正在加载…

0x0100 laosb 的新年红包

放出时间:2019 年 1 月 1 日

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

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

0x0101 The Guess Game

Snipaste_2019-01-01_19-15-24.png

直接点击弹出了一个 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);

拿到了第一组数字

grp1.png

0x0102 The Christmas Egg

Snipaste_2019-01-01_19-26-48.png

根据源码中 <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 得到第二组数字。

grp2.png

0x0103 The Typo I've made

Snipaste_2019-01-01_19-37-51.png

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

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

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

grp3.png

0x0104 ?

Snipaste_2019-01-01_19-43-13.png

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

Snipaste_2019-01-01_15-21-21.png

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

grp4.png

utf-53……

行了,AK。

0x01ff

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

IMG_2899.png


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 或内容。就跟着去了跳转的页面。

Snipaste_2019-02-03_13-16-01.png

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

md5("step1")="2e957eb8c030fc2d10de5607715f4c55"

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

Snipaste_2019-02-03_13-21-08.png

Snipaste_2019-02-03_13-22-48.png

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

Snipaste_2019-02-03_13-23-40.png

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

这是一个 GIF。

Snipaste_2019-02-03_13-25-00.png

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

Snipaste_2019-02-03_13-26-39.png

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

Snipaste_2019-02-03_13-29-31.png

Snipaste_2019-02-03_13-33-27.png

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

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

Snipaste_2019-02-03_15-10-38.png

0x0203 Problem C. 神秘的祝福

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

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

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

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

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

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

Snipaste_2019-02-03_13-53-29.png

hmm……

Snipaste_2019-02-03_13-54-09.png

这才是签到题吧!

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,啥都没有。

Snipaste_2019-02-04_21-55-19.png

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

Snipaste_2019-02-04_21-58-19.png

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

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

0x0301 commit

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

Snipaste_2019-02-05_10-12-25.png

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

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

Snipaste_2019-02-05_10-14-33.png

完 全 一 致。

最后就是将 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,均失败。

Snipaste_2019-02-05_10-52-23.png

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

Snipaste_2019-02-05_10-52-54.png

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

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

0x0303 major

Snipaste_2019-02-05_19-50-36.png

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

Snipaste_2019-02-05_11-39-03.png

音频一般是直接丢进 Audition。

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

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

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

Snipaste_2019-02-05_12-21-22.png

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

Snipaste_2019-02-05_11-58-08.png

2.6 kHz

Snipaste_2019-02-05_11-58-41.png

3.5 kHz

Snipaste_2019-02-05_11-59-09.png

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

Snipaste_2019-02-05_10-25-00.png

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

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

Snipaste_2019-02-05_10-19-08.png

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

Snipaste_2019-02-05_10-24-17.png

可见最后一个划线部分是之前页面返回的那个字符串,而前面是“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。


红包领取截图

IMG_3010.png

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

最下面一个据 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。直接打开以后可以看到一个儿童画(逃)。

Snipaste_2019-02-05_12-58-28.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+?

Snipaste_2019-02-05_13-03-59.png

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

0x0403 打不出去的电话

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

Snipaste_2019-02-05_13-58-14.png

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

124254701302443011630246572234451223306211025275122212505542044352521455102256525702525206015250526212345162426615022051524224525242523054125253102254501241403452025030071

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

Snipaste_2019-02-05_14-01-50.png

0x0404 转换来转换去

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


协议: 本文根据 Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License 进行授权。

标签: 红包


  • 这篇文章一条评论也没有……

撰写新评论

account_circle
mail
insert_link
mode_comment