2025 ISCC练武区域赛、决赛RE+MOBILE 详解合集-先知社区

faze

和校赛是一样的，把断点下在最后if语句的判断，直接动调运行到这，然后找flag

ISCC{(-e_=4d6)Xrl}

SecretGrid

下载拿到附件运行发现缺个库，只能上网找了个对应的库才能正常运行

main函数

先是输入一个9*9大小的矩阵，然后进入

checklist1

函数。

根据伪代码中该函数的返回值需要大于8，再结合ai的辅助分析结果，这应该是一种类似数独的情况，然后尝试输入随机的数独，发现可以过。

接下来就是

checklist2

函数，这个函数的大体逻辑是对矩阵中每一位的上下左右、左上、左下、右上、右下八个方向查找指定的单词，函数返回值就是找到指定单词的次数，大于4即可过这个check，具体单词为

可以用z3约束爆破

ilterupaseuapslirtrsptialuepalitresutrsupealiueialsrtplteruispasiulapteraprsetuil

完了运行程序，过了两次check，输出了一个flag，是假的，也怪不得main函数里输出You almost get the flag!

但是缺提示了True decode is in true_decode。

有一段

S123

开头的，看起来是

Motorola S-record格式

。上网查了下，是一种表示机器码的ASCII格式（常见于嵌入式固件）。

将这段多个 S-record 格式的记录转换成二进制文件，然后ida分析。

爆红的是key，也就是前面输出的假flag，result是在decode函数里看到的那串三十位的数据

输出结果加上ISCC{}

ISCC{T%uo4=WJfd0Due#qKmaIPfkiyp4UIX}

greet

rust题...

高亮的就是密文

以下就是flag的加密逻辑

就是一个循环左移，但是每次循环左移的位数在变，可以动调看v29的值的变化规律就好了，直接写脚本逆

ISCC{8IRM6hA0gb}

有趣的小游戏

拿到附件，先运行了一下程序，确实是个小游戏，经典maze考点，但是C的位置是随机的，并且迷宫很明显有走不通的地方。

ida开始分析

根据代码逻辑对一些函数和变量进行了重命名，同时还对一些关键函数进行了注释。

跟进

sub_41D620

函数分析根据输入程序具体做了什么操作

前半部分的逻辑都是很经典的，根据输入改变坐标，重点分析吃到金币之后的操作，跟进

sub_41D580

函数

sub_41D580

函数

静态分析的工作做完了，接下来进行动态调试验证前面的分析。一直调试到开始吃到金币，然后跟踪到读取txt文件的

sub_40165D

函数，

双击跟进

lpAddress_1

，然后按d，跳转地址，

跟进，看到有未分析成功的数据，按C，然后按P，申明为代码，F5反编译

很明显就是xxtea。那么到目前为止，就已经确定了密文，加密算法，以及key可以在内存中找到

但是由于不知道游戏什么时候结束，于是乎就只能爆破，已有的线索是flag格式ISCC{}

爆破脚本

ISCC{]aH_~=$a*j<.3hlcgeHE|+[Y}

邦布出击

先分析Java层

flag输进来会先check格式，是否是ISCC{}和长度是否大于7，然后才会继续运行下去。

可以看到先从a类的a方法获取一个值，跟踪

这个类就是实现了一个blowfish的加密过程，但是密钥是b类的c方法的返回值，继续跟踪

而这个方法缺返回了一个空。这也是导致程序运行闪退的原因，如果这里是正常的话，就可以一把梭了。那么我们接下来的任务就是查找blowfish的key是怎么来的。

MainActivity2类中就是让用户输入数据库的一些值，然后可以发现数据库是被加密了的，

看

这里对数据库进行解密操作，同时也检查用户在向数据库中写入数据时，是否有写入的数据，。继续看

这里看到了对数据库进行插入的操作，并且还有个info属性，看着像base64编码的结果，进行解码，并从第四个值的解码结果可以得知需要对前三个进行三次base64解码

然后进行三次解码

得到了一个类似密钥的值，但此时此刻我们去查看附件中的数据库，发现确实是被加密了，那估计这个key就是用来解密的了

用

sqlcipher

进行解密

这样就拿到了blowfish加密的key：

H4iJkLmNoPqRsTuV

接下来就只需要对encrypt方法进行hook，因为blowfish的加密结果是des加密的密文，同时还需要hook b类的c方法，把正确的key进行return

FRIDA 脚本

输入符合格式要求的测试数据触发一下，即可获取flag

ISCC{rR6ql9CGn0u/kBPZpMzCEKmQy0ZkdlNB}

Detective

先看Java层

可以看到启动页是

LoginActivity

，查看

就是检查输入的

四位password

是否正确，正确则显示调用

MainActivity

。而check逻辑在so层。

继续看MainActivity

逻辑也很清晰，就是将输入的flag，先检查格式，ISCC{}，以及长度，大括号内的内容先在a类中的a方法进行加密，再传到so层的

stringFromJNI

进行加密，然后和一串已知的密文进行check。

a类

有点抽象...

a类中的b方法就是将字符转十六进制，不足三位的补0。转成十六进制之后再传到b类的a方法

先对特定索引的值进行字符3的增加，同时以索引的奇偶，来将字符打乱顺序，分成两部分，拼接在一起。然后两位两位进行遍历，对于符合特定值的字符，在其后边append字符21，并且将原来的顺序颠倒，例如传进去是AB,那么处理之后就是BA21。

完了再回到a类的c方法，先在字符串前面填上00，实际的作用就是又转回字符形式，从十六进制形式。

Java层看完了，看so层。

Java_com_example_detective_LoginActivity_validatePassword

就是将四位的验证码传进去，计算sha256，进行比较，但其实这个可以不用管，直接hook一下就可以过了。

Java_com_example_detective_MainActivity_stringFromJNI

对flag就是一个异或，key也有了，那么接下来就可以写脚本解密了

ISCC{@@bM0r!y}

HolyGrail

⑩...

先看Java层，

MainActivity

就是app运行首页面的初始化代码，跟踪提交按钮所执行的逻辑，跟踪到

FlagValidationActivity

类，

关键逻辑

一样，先检查格式，然后检查大括号里的内容，先传入a类的validateFlag方法进行加密，

依次跟踪查看代码逻辑

先

vigenere

加密，然后传入so层的

processWithNative

进行加密，再到b类的a方法进行转换。但是到目前为止，我们没有找到密文在哪，这个app用到了

sharedPreferences

，安卓的一个数据持久化的类，我们运行app，在最开始要求按一定顺序勾选耶稣和其十二门徒的顺序，但这个顺序根据提示，是在

mobile2

里的

libSequence-Clues.so

里，无敌了...

找到顺序

找到顺序之后，还需要和app中按钮一一对应，直接全局随便搜一个名字，在布局文件里就可以看到

这里就只列举了一个，剩余十二个都可以找到。

但是，分析so层

libholygrail.so

的

Java_com_example_holygrail_a_processWithNative

，只看到了一个十六进制转十进制，十进制转十三进制的逻辑，所以索性就直接黑盒测试，Frida hook

validateFlag

方法的返回值，将所有的可见字符一一输入，就可以得到加密结果

hook脚本

拿到对应关系

而每个按钮对应的值也可以在so层里找到

看到

checkBox3

对应

。这也清楚了对应关系为什么存在!了。直接人工还原一下，也挺简单的。

得到

Wvqh~0f5zke3va~

，然后维吉尼亚在线解密一下

ISCC{Dome~0f5ecr3ts~}

练武题(决赛)

CrackMe

根据题目描述可知，有花指令，ida打开分析也确实如此

勾选出来的这三个就是具体的加密逻辑，都加了花，都是一样类型的花指令

红色部分未定义一下，黑色部分全nop

红色部分按C，然后上面两字节nop一下，就正常F5了

另外两个都一样

一个类似于凯撒加密的逻辑

标准的rc4。

但是发现前两个加密都是对偶数维进行加密，rc4是全部进行加密的，所以正确的密文应该是偶数位

解密：

把偶数位提出来，提不提都可以，然后进行解密

ISCC{2Q7gVLMK6HKaZg1}

uglyCpp

c++逆向，代码确实很丑...ida分析

初步静态分析的结果

太丑了，只能动调根据函数处理结果来倒推函数作用

根据动调结果可知

fun1

函数，是将输入的36位的flag构成一个完全二叉树

fun2

函数对上面构建好的完全二叉树进行中序遍历

fun4

用字符串

"key1key2key3key4"

生成了一个176字节的字节流

fun5是关键的加密函数，跟进

跟踪下来，就是一个异或

异或的值跟一下，就可以拿到了，解密脚本

得到：L2lM3ILC}NwXSg7p{QC9IJxSAM8ICGHoBkqD

然后再恢复一下顺序

ISCC{ABMw7Cx8Hq2INXgpQ9JSMIGokDLl3L}

GGAD

运行app，就开始播放视频，然后看了下AndroidManifest.xml，程序入口不对，改一下

用MT管理器改一下，然后重新打包下载就好了，也没有验证签名啥的

先看Java层

so层

validateKey

check

key

，然后先检查flag的格式，接着将大括号里的内容和

KeyManager.getKey()

生成的key传入a类的a方法进行check

b方法是十六进制转八位二进制

b类

对flag的奇偶位分别进行check

接下来就去so层找输入的密钥，就可以进行hook了

key的sha256值，上cmd5查一下，就有了

ExpectoPatronum

，完了hook

c.a()

c.a result=

55B5C16A2A394DE8

JNI2

对二进制数据中，如果是1就换成0，是0就换成1

JNI1

就是一个rc4

解密脚本

得到：

3aaa74cac38e09e59dc50c862ba29197

然后cybernetics厨子解一下rc4

ISCC{Cr3d3nceB@r3b0n3}

叽米是梦的开场白

分析Java层

这里先从so层动态加载了一个dex

先把这个dex找到先，在libmobile04.so

Java_com_example_mobile04_MainActivity_getEncryptedSegment

很明显了，这就是dex文件，dump下来，然后jadx打开

这里其实是一个3DES，Java层中有密文了，还差key，在libSunday.so中

解密

得到第一部分flag

接下来是第二部分flag

看到这里从assets文件中加载了一个文件

将文件和第二部分flag传到a类的a方法

又调用了libMonday.so

框出来的这部分就是对从assets目录中读取的文件进行的解密的处理逻辑

然后ida分析解密的文件

还是一个3DES，key和密文都有，直接解密

ISCC{WiMIit2Hx2hlAJ}