hgame week2 WP

hgame week2 WP
Britneyweek2的题更加难绷啊,感觉大脑被论剑了(呜呜呜
RE
Signin
主要是过掉反调试
1.xxtea加密的key由一段程序的硬编码计算而来
而软件断点的原理是用一条软件断点指令替代断点地址所在位置的操作码字节,也就是说通过软件断点得到的key是错误的
2.硬件断点的检测
这里的qword_1400BB880即为delta,Dr寄存器是调试寄存器,储存我们的硬件断点,也就是说delta为0时才是正常状态
过掉反调试,标准xxtea,直接解密即可
1 |
|
Mysterious signals
Java层很简单没什么东西
b是类似签名(最后发现是把密文16进制转为字符串)的东西 c函数是字符串解密函数
c函数就不分析了,用不到
通过动态注册找到b函数,发现是几层加密叠叠乐
key0的生成,这里注意反调试
进入主加密函数,这里的v14其实就是aes加密的sbox,作为key1
紧接着又生成了一个key2
第一步加密用key1(sbox)进行换表
第二步加密用key2进行变异tea加密
第三步把16进制转换为字符串
exp写的是依托,见谅
1 |
|
1 | import struct |
Fast and frustrating
aot逆向,相当逆天,死去的线性代数又开始攻击我了
主逻辑所在位置
这里是第一次验证,验证了当前语言所属国家名称(这个api好像在win11 aot下有问题 无法返回正常值,不使用aot编译就能得到不清楚什么问题,而且好像没有缩写是vt的国家吧???)
这里取出了一个字符串进行base64解码,gunzip和反序列化操作得到一个Constrs对象
字符串来自Resouces类下的get函数
但是这个字符串并未初始化,进字符串搜索
成功找到
给了一个27*27的矩阵还有一个向量
这里的一大坨我是没看懂,不过我猜可能是输入变成向量和矩阵相乘等于给出的向量
z3解出结果,key为CompressedEmbeddedResources,按理来说,输入key应该就会得到flag,但是报错了?!!
在这里其实存在两种语言,只有vt这个语言才能正常进行解密
虽然我们绕过了最开始的语言检测,但是系统识别到的语言没有改变,也就不会加载FastAndFrustrating.Resources.vt.resources对应的正确数据,所以我们应该找到一种方法绕过这种机制
翻看net的源码发现
通过修改ResFileExtension即可走正常的执行流
这里注意修改0xd那里,这是字符串长度
Nop'd
这个更是烧脑
main函数fork了一个子进程,让子进程执行游戏,父进程ptrace子进程,这样就没办法对子线程进行调试了
构造函数指定了main函数终止后的函数,
这个函数进行了一系列复杂的操作,很难看懂,不过他使用ptrace读取和修改了数据,那我们就可以使用LD_PRELOAD这一特性对其读写内容进行监听
1 |
|
这里直接使用pwntools把地址随机化关闭
运行即可得到日志
分析日志我们发现,launcher从syscall旁边读取数据,经过运算得到opcode,然后取出game中保存的数据进行操作
观察几个加密函数
发现一处简单的运算,还原后发现是chacha20加密的特征
既然这样,那我们就可以直接取出最后一次生成的矩阵直接用来加密
不过在launcher中我们并未找到最后一步的加密,难道在game中吗??
果然,这里的rax指向我们的输入,下面跟生成的矩阵和一个值异或
这里的值其实就是
可以将rax打印出来验证
取出值解密即可
1 | key = [0x4a,0x69,0x5b,0x2a,0xf3,0x87,0x56,0x46,0xf3,0x7,0x74,0xc6,0x65,0x73,0xd6,0x16,0x45,0xfe,0xd9,0x98,0x3,0x76,0xb3,0x6d,0x50,0xe0,0x96,0xf7,0x4c,0xbc,0xb0,0xa4,0xea,0xf2,0xdc,0x93,0xd8,0x38,0x8,0xa7,0x23,0xde,0x6b,0x3b,0x87,0x84,0x6e,0xd1,0x4,0x4d,0xc3,0x2a,0x56,0x3f,0xee,0x8,0xa3,0xd8,0x76,0xe6,0x6b,0xbc,0x48,0xca] |