2023安洵杯第六届网络安全挑战赛 Re 部分WriteUp
本文最后更新于 2024年1月4日 上午
题目地址:i-SOON_CTF_2023/re at main · D0g3-Lab/i-SOON_CTF_2023
(github.com)
WriteUp + 复现
感觉有点简单
0x0 初探
64位的驱动
0x1 静态分析
驱动文件的入口点是DriverEntry
主要逻辑看起来还是比较清晰的
1 |
|
flag是从 flag.txt
文件中读取,经过加密后在sub_140001560
函数中进行对比,其中sub_1400011F0
是RC4被魔改了的,sub_140001360
是魔改的base64 魔改的RC4
1 |
|
魔改的base64
1 |
|
这个base64与标准不一样的是,他是相当于三个字节为一组,按小端排序,从低位到高位取,标准的base64就相当于把数据直接转化为二进制,然后逐一取6bits
0x2 求解
先还原base64,然后解RC4异或回去
1 |
|
牢大想你了
0x0 初探
1 |
|
Unity编写的
运行后的画面有点抽象,就不放了
0x1 分析
通过检索资料,从Assembly-CSharp.dll
入手
用dnSpy32打开,找到关键函数
1 |
|
查看 AAABAAABABABAAABBABBABAAAABBAABBAABABBBBBABAAAB
函数
1 |
|
进行了赋值,而这个this.BBABABBBABBABABAAABBBAABBAAAAAAABBBBBAABBAAAAAA
被引用的地方全是tea算法
1 |
|
直接进行解密
1 |
|
得到flag
你好PE
0x0 初探
1 |
|
依然是
PE32 并且打开IDA无法搜索到相关的字符串
0x1 分析 & 解题
在IDA中发现了加载资源的代码
1 |
|
对flag的检验是运行时加载运行的,导致我们无法搜索到相关字符串
通过调试,加载的地方是
1 |
|
大小为 0x000EBE00 下面的代码可以通过反编译,似乎是跳转表
1 |
|
把这一部分dump出来,用IDA打开,可以看到字符串
1 |
|
根据这里面PLZ Input Flag
的偏移地址,结合起始地址,计算出此时字符串的地址
1 |
|
在此处下一个硬件断点,F9,程序运行到了这里
1 |
|
这里对资源赋值到了 0x01010000
处,在这里重新找到字符串的地址,下访问断点
1 |
|
通过断点的命中,发现下面这段代码其实在对资源进行处理
1 |
|
在 sub_D3ED5C
函数中的
1 |
|
代码块call了资源中的内容,调试这部分,可以调到关键函数
1 |
|
虽然调到了,但是还是一步一步调过来的…
根据调试情况,写出正向脚本和逆向脚本
1 |
|
得到flag
你见过蓝色的小鲸鱼
0x0 初探
32位PE
在readme中,给了User:UzBtZTBuZV9EMGcz
0x1 分析
使用IDA打开,一时还找不到关键函数在哪,由于该程序使用了Win32API,可以尝试从这里下手,打MessageBoxA的断点
成功断下来,回溯堆栈
1 |
|
这个函数里面我们看到了正确或错误的相关字符串
1 |
|
该函数只有一个交叉引用,引用的函数即为主要处理函数
1 |
|
在加密函数中发现了算法关键字
1 |
|
故去Github搜索BlowFish,发现和加密过程中用到的数组数据一致,猜测是未进行魔改算法,通过对比算法,猜测是以Nmae为密钥,对Password进行加密,
0x2 求解
使用python进行求解
1 |
|
得到密码为
1 |
|
检验一下
mobilego
0x0 初探
这是一个Android逆向,通过jeb查看,主要逻辑主要是go编写的so文件中
1 |
|
0x1 动态调试
使用jadx直接进行调试 在check_flag
调用处打断点
1 |
|
断下来之后,单步调试,在变量窗口可以看到我们的输入经过加密后的结果
1 |
|
还有要对比的字符串
1 |
|
可以看到,其实就是打乱了次序的,我们再构建一次输入,检验一下打乱的次序是不是固定的
1 |
|
局部换成大写之后,依然是一致的,现在我们构建一个没有重复的输入
1 |
|
经过加密后
1 |
|
写出解密脚本
1 |
|
0x2 静态分析
使用IDA分析so文件,打开后发现没有去除符号,直接搜索check
,找到mobile_go_Checkflag
1 |
|
其中这个种子是在mobile_go_init_0
中进行定义的
1 |
|
大概意思就是通过生成伪随机数来达到打乱顺序的作用,而这个伪随机数的种子就是
2023 写一个go程序打印出这个过程
1 |
|
得到
1 |
|
然后再JEB中找到对比的字符串
1 |
|
进行还原
1 |
|