Web + 值班邮件台 解题思路： 题目首页是一个“值班邮件台”系统，访问后可以在响应中发现两个与身份相关的 Cookie，分别是 `mail_user=guest` 和 `mail_role=user`。同时页面内容还提示前端继续沿用浏览器侧的旧标记做身份切换联调，这说明后台很可能直接信任客户端传入的身份字段，没有做真正的服务端鉴权绑定。因此首先尝试伪造 Cookie，将其修改为 `mail_user=admin; mail_role=admin`，然后访问 `/admin.php`，成功进入后台预览面板。 进入后台后，页面给出了一个联调说明文件下载地址...

Mobile + 密码验证 解题思路： 题目给了一个 APK，Java 层会先检查 flag 的基础格式，然后调用 NativeBridge.verifyFlag(AssetManager, String) 进入 JNI 做真正校验。先从 Java 层入手，确认输入必须满足三个条件：总长度为 36，以 ISCC{ 开头，以 } 结尾。这样可以把中间 payload 固定为 30 字节，并继续拆成三段：A = flag[5:13]，长度 8；B = flag[13:25]，长度 12；C = flag[25:35]，长度 10。后续 native 逻辑就是围绕这三段分别做约束。 继续逆向 so，可以提取出 assets 中参与校验的四...

Reverse + 拆弹专家 解题思路： 这道题是一个 Windows 逆向题，整体形式类似“三关拆弹”，需要依次通过三个验证阶段，全部通过后程序会拼接输出最终 flag。程序逻辑比较清晰，核心在于分别逆向每一关的校验方式，然后将三段正确输入组合起来。 第一关是一个 8 字符输入验证。程序要求输入为可打印 ASCII 字符，随后会经过一个类似 2x2x2 魔方变换的自定义加密流程，包含位置置换、字节加法、PKCS#7 填充和 Base64 编码，最后对结果做 FNV1a 哈希并与目标值比较。不过在分析对应函数时，可以直接从代码注释中看到第一关明文已经被写出，即 `HYXHJTME`，因此这一关不需要额外爆破，直接可得答案。 第二关...

========================= Adriod + 按步取匙 解题思路（必须包含文字说明+截图） APK 包名 com.mobilezkp，核心逻辑在 native 层 libzkpcore.so（ARM64）。整个认证流程分四步： Login — 验证用户名/密码 Challenge 1 — 输入 8 位 hex 验证码 Challenge 2 — 输入 32 位 hex 令牌 Challenge 3 — 输入 16 位 hex 密钥，依赖 intermediate_token 通过全部挑战后，nativeGenerateFlag() 输出最终 flag。 静态分析环境 libzkpcore.so：ARM64 动...

Web + 数字古墓 解题思路： 这道题分为两个阶段，两个页面都会直接显示 PHP 源码，因此整体思路就是审计代码并构造对应利用。第一阶段入口是 `/rune_trial.php`，第二阶段入口是 `/mechanism_chamber.php`，最终需要先在第一阶段拿到第二阶段要读取的文件名，再在第二阶段通过反序列化利用链读出 flag。 第一阶段的核心在于服务端会先将对象序列化，再对序列化结果执行字符串替换，最后再反序列化。函数中会把 `amgoinvc` 替换成更短的 `iscc`，这就导致序列化串中的长度信息与真实内容不一致，从而形成典型的 PHP 反序列化字符串逃逸。构造时将多个 `amgoinvc` 放入参数 `d` 中...

Reverse + 毛毛虫的逆袭 解题思路： 题目给出的是一个 64 位 Windows 可执行文件，初步分析可以看到其节表中存在 `UPX0`、`UPX1`、`UPX2` 等特征，导入函数也非常少，只有 `LoadLibraryA`、`ExitProcess`、`GetProcAddress`、`VirtualProtect` 等典型壳程序接口，因此可以判断该程序使用了 UPX 进行加壳。首先使用 `upx -d` 对样本进行脱壳，脱壳后文件体积明显增大，导入表恢复正常，便于后续静态分析。 在脱壳后的程序中，可以从字符串区直接看到输入提示和校验失败提示，确定 flag 格式为 `ISCC{}`，其中花括号内部长度为 20 个字符...

========================= Mobile-深海金库 解题思路 初步分析 解压 APK 后可以定位到两层核心逻辑：Java 层负责输入格式校验与字节预处理，Native 层负责最终验签。关键文件如下： `classes.dex` / `classes2.dex` — Java 层逻辑 `lib/x86_64/libsecure_verify.so` — Native 校验 字符串搜索可见 `com/example/mobile02/MainActivity`、`nativeVerify`、`libsecure_verify.so`，可以确认真正的核心校验位于 Native 层。 Java 层流程 交互坑点：长按...

mobile+ 深潮协定 解题思路： 题目给出一个 Android APK，包名为 `cn.iscc.deepseal`，核心校验流程分为 Java 层和 Native 层两部分。首先在 Java 层分析 `FlagValidator.check()`，可以看到程序先检查输入是否满足 `ISCC{}` 的格式，然后取出花括号内部内容，交给 `CryptoEngine.transform()` 处理，最后再调用 `NativeBridge.verify()` 进行最终校验。因此解题关键就是把这两层变换完整逆向出来。 继续分析 `CryptoEngine.transform()`，发现其参数不是写死在代码里的，而是从...

Web + 灵感笔记 解题思路： 题目是一个 Flask 云笔记应用，所有数据都存储在 Session 中，没有使用数据库。首先在前端 `main.js` 中发现了两个关键接口，一个是 `POST /api/v1/project/detail`，可通过 `project_id` 获取项目详情；另一个是 `GET /api/admin/hint`，只有管理员可以访问。继续分析后确认 Session 中保存了用户信息、笔记内容、日志、注册用户等数据，说明整个系统高度依赖服务端 Session 逻辑。 接着尝试登录后台，发现管理员存在弱口令 `admin/admin`，成功登录后访问 `/api/admin/hint`，得到隐藏接口...

Misc-盲相阵列 解题思路（必须包含文字说明+截图） 1. 附件分析 压缩包内包含 array_iq.csv 和 rx_note.txt。提示给出采样率 48000 Hz、符号率 1200 baud、残余频偏约 +1700 Hz，并明确数据链路为 PN mask -> 16-lane column DMA -> H(7,4) nibbles -> BP1 frame。 2. 信号解调 由 48000 / 1200 = 40 可知每个符号有 40 个采样点。对复数 I/Q 样本做 -1700 Hz 频偏校正，枚举 0..39 的符号边界后，最佳符号偏移为 17。 对每 40 个采样求平均得到符号，再用前 80 个符号估计公共相位，完...