🍵[EASY]茶杯头大冒险
考点
加解密:
- 位运算和异或操作
- 迭代加密
说的是简单的Tea加密。。这个名字我还以为是。。。
Tea
“TEA” 的全称为**”Tiny Encryption Algorithm”** 是1994年由英国剑桥大学的David j.wheeler发明的.。就是微型加密算法。
TAG:分组加密;64位明文分组和128位密钥;存在缺陷,设计者提出XTEA,组织密钥表攻击,速度更慢;
加密函数:
1 | void Encrypt(long* EntryData, long* Key) |
解密思路:
1 | x +=xxx |
- 其中用了异或的一个重要特性:c=a^b,那么我们一直c求a一样的 a=c^b。反正逆向直接抄
算法如下
1 | void Decrypt(long* EntryData, long* Key) |
分析
- F5
1 | int __fastcall main(int argc, const char **argv, const char **envp) |
strlen((const char *)Str) == 24
说明flag是24位
关键应该是encrpt函数
1 | __int64 __fastcall encrypt(unsigned int *a1, unsigned int *a2) //encrypt(&Str[i], v6); |
查了一下(看出题人解释,发现就是Tea加密。
先处理main()
函数逆向
1 | def main(): { |
再处理decrypt()
函数逆向
1 | def decrypt(res, key): |
放弃python了。分组加密还是用数据类型强的语言吧,而且我也不熟练。就用cpp
1 |
|
- 终于python调试出来,python函数也需要
return
,其次& 0XFFFFFFFF
注意使用规范
1 | def decrypt(res, key): |
复盘
- 自我感觉用python坑的地方在十六进制数据转换为字符串部分,还有分组运算的溢出问题
- 用cpp写,转不转换成无符号整数都不影响,用不用十六进制表示数字也不影响,比较方便吧
✈️[EASY] 打飞机高手
考点
- (动态调试)
- patch
- 机器码和汇编转换
分析
- F5
1 | int __fastcall main(int argc, const char **argv, const char **envp) |
- 发现里面的函数都非常复杂,而且看不懂。
- 试着打开exe发现就是打飞机游戏,应该代码很多,不是简单的解密
- 其中show函数中有getflag,看起来是patch了
关键逻辑在show()
:
1 | result = score; |
把里面的114514那段改成1的数字就是了。
- 先打断点debug然后找到汇编地方
- edit里面选择patch
- 可以改机器码和汇编都可以,但我这汇编报错,不知道为什么。感觉是位数问题?
- 用机器码改,使用准换网站:https://shell-storm.org/online/Online-Assembler-and-Disassembler/?opcodes=48+3D+01+00+00+00&arch=x86-64&endianness=little&baddr=0x00000000&dis_with_addr=True&dis_with_raw=True&dis_with_ins=True#disassembly
最后一步:apply patches to input file
然后debuger重新启动,getflag!
复盘
- 学会使用IDA进行patch
- 注意patch的时候格式,最好还是就使用字节码替换吧
- 记得``apply patches to input file`
💥[EASY]爆了爆了,和java爆了
考点
- 安卓 apk 逆向
- base64 加密
分析
- 解压之后是apk,搜了一下Android逆向,可以使用apktool解压apk文件,获取源码
1 | D:\app\\apktool>java -jar apktool.jar d ezAndroid.apk -o ./demo |
解释:
- original 目录:保存了原始的 AndroidManifest.xml 和签名信息
- res 目录:应用程序的资源文件目录,包含了应用程序的布局文件、字符串资源、图片资源等。
- smali 目录:应用程序的 Smali 代码目录,包含了应用程序的所有 Smali 代码文件(Smali 就是字节码)
- assets 目录:应用程序的 assets 目录,包含了应用程序需要使用的各种资源文件,例如音频、视频、图片、配置文件等。
- lib 目录:应用程序的库目录,包含了应用程序需要使用的库文件,例如 so 文件等。
- AndroidManifest.xml:应用程序的清单文件,包含应用程序的名称、包名、版本号、权限等信息。
- apktool.yml:是 APKTool 工具使用的配置文件,用于指定反编译和打包 APK 文件时的各种参数和选项。
- 又用jadx反编译了一下
先查看AndroidManifest.xml
里面信息,发现可疑信息
1 | <activity android:exported="false" android:name="com.cnss.myapplication.o0o0o000o"/> |
于是找到这三个文件。其中o0o0o000o
中包含很多可疑函数,这应该就是这道题的关键了
1 | public class o0o0o000o extends AppCompatActivity { |
用雷电模拟器打开apk看看怎么个事儿
打开就让find the botton
呃呃,右下角一个小绿块。真无语了
想到 **
class** o0o0o0o0oo
里的代码:1
2
3
4
5
6
7
8public void onClick(View view) {
if (o0o0o0o0oo.this.packetInput.getText().toString().equals("com.cnss.myapplication")) {
Toast.makeText(o0o0o0o0oo.this, "Go to the final page", 0).show();
o0o0o0o0oo.this.startActivity(new Intent(o0o0o0o0oo.this, o0o0o000o.class));
return;
}
Toast.makeText(o0o0o0o0oo.this, "Plz find the packet name", 0).show();
}所以是:
com.cnss.myapplication
最后一步了,肯定就是o0o0o000o里面那串一眼base64加密
onclick逻辑:
1 | String s = o0o0o000o.this.decode(String.valueOf(flagInput.getText())); |
- decode 是 base64 的解码,decode_detail 逻辑就是四个字符,分别解密然后转成三个明文字符。但是每解密一次就执行 qwq()
- qwq() 进行了 base64 字符表的右移,相当于每次解密字符表都不同。
- 然后总逻辑是:对输入的值进行decode(base64变种),然后放进qvq 作为 key 进行aes 解密。
- 提示 key is a meaningful str
- 因此,思路就是把上面那些串都拿去解密。因为那些串:去掉末尾两个=,再将中间的=替换为0,就是标准的可以解密的 base64 密文。因此不管怎么样都要先把那100个解密了
- 直接抄他的逻辑用 java 跑
- 解密出来发现一个 meaningful str
- 直接传进 app 中
1 | import java.security.InvalidKeyException; |