SUBGROUPX Repo: https://github.com/n-WN/SubgroupX 日期: 2026-02-05 / 环境: http://223.6.249.127:28433 / 技术栈: Node.js v20.19.6 alpine x64, Next.js 16.0.6 dev, React 19.2.0 / 题目类型: Web, 500 pts / 结论 通过 React Flight 反序列化触发 server reference，加上 Hello() 的模板字符串 toString sink，实现了不依赖 constructor/__proto__/prototype 的 RCE，最终读取 flag:

SUBGROUPX Repo: https://github.com/n-WN/SubgroupX Griffin 这题的关键是 Phase1 恢复的 $x$ 存在仿射不确定性，导致 Phase2 求根得到的是 $x = a m + b$ 而不是 $m$，需要对 $(a,b)$ 做 affine 枚举。 / 结论 flag: alictf{**} 关键坑点: Phase1 恢复的 $x$ 存在仿射不确定性，导致 Phase2 求根得到的是 $x = a m + b$ 而非 $m$，必须做 affine 枚举，最终命中 $(a,b)=(-1,256)$ Full solve code (gist) 复现参数 以下数值来自一次成功复现的检查点和附件内容:

SUBGROUPX Repo: https://github.com/n-WN/SubgroupX 这题最终落地利用点是 MapDB 的 linked record：把 payload 分散种在多段 icon 记录里，再通过极少量元数据 patch 把 “icon” 指向链表头，最后 GET /files/icon 触发 Serializer.JAVA 反序列化完成 RCE。 / 题目信息 题目：staircase 分值：500 目标：拿到 flag{...}（flag 文件位于容器根目录 /flag-<random>.txt） 远程：题面端口会变更，需要以最新为准（本文最终打通的是 tcp *.*.*.*:*，HTTP 服务） hint： 远程环境不出网 MapDB 支持“链表式”记录（linked record）存储/读取，用于巨型记录 最终结论 本地已打通 本题最终落地利用链不再依赖“用受限写原语合成任意字节串”，而是：

SUBGROUPX Repo: https://github.com/n-WN/SubgroupX 解了几道分数较高的题目，部署后继续修复公式渲染（theme/模板问题）。 / AstralCat 服务端每轮随机 99 字节 message，用 Luo Shu 做 CBC。关键点是同一个对象连续调用两次 Encrypt()，第二次加密的输入其实是第一次的密文。

SUBGROUPX Repo: https://github.com/n-WN/SubgroupX 整理版汇总：按仓库内文档与脚本串主线，每题只保留关键思路和 exp 核心片段（截图已脱敏）。 / 整理说明 本文按仓库内文档与脚本整理，每题只保留解题主线与 exp 核心片段。 文中用 HOST:PORT 代替真实地址，flag 统一写为 LilacCTF{...}，不包含外链 URL 与真实 IP。

SUBGROUPX Repo: https://github.com/n-WN/SubgroupX XCTF Lilac 的 Solana/Anchor misc。核心是 ClaimRequest 与 Faucet 绑定关系校验缺失，并结合 no_pda=true 的绕过手法，最终一次性把 vault 清空。 / 题目附件：/_p/67efe178c3919b1ea379da0869983aa081d7769aaac76d1a073926a489beca49.tar.gz / 题目信息 类型：Solana / Anchor（misc） 远程：1.95.144.176:9990 交互：PoW → 上传 solve.so → 提交 Vec<Instruction>（服务端只用 user 一把私钥签名交易） 目标：让 ATA(global_pda, fee_mint)（同时也是 faucet vault）余额变成 0，服务端打印 flag 这题本质是一个 “ClaimRequest 与 Faucet 绑定关系校验缺失” 的逻辑漏洞：程序只验证 ClaimRequest 的 PDA 是正确的，但没有验证 ClaimRequest 属于当前正在处理的 faucet，导致可以用“别的 faucet 的 ClaimRequest”去领“当前 faucet 的钱”。

自从接触到工作，记忆节点似乎就由工作为 key，其余为 value，所以本篇 blog 的时间线基本都是由工作发散的

from Kotori 学长の小测验 / from secret import flag from Crypto.Util.number import * # seed = bytes_to_long(flag) bits = seed.bit_length() while True: p = getPrime(bits + 1) if p > seed: break print(p) a = getRandomRange(1, p) b = getRandomRange(1, p) for _ in range(3): seed = (a * seed + b) % p print(seed) # 31893593182018727625473530765941216190921866039118147474754069955393226712079257707838327486268599271803 # 25820280412859586557218124484272275594433027771091486422152141535682739897353623931875432576083022273940 # 24295465524789348024814588142969609603624462580932512051939198335014954252359986260009296537423802567677 # 14963686422550871447791815183480974143372785034397446416396172429864269108509521776424254168481536292904 RSA的计算过程是： / 任选两个大质数p和q，p!=q，计算N=pq 计算N的欧拉函数r(n)=(p-1)(q-1) 任选一个e满足 1<e<r(n) ,且e与r(n)互质 找到d，使e*d/r(n)=x……1（x是多少不重要，重要的是余数为1）后丢弃p， 至此（n，e）为公钥，（n，d）为私钥 加密：C=Me(mod n)；解密：M=Cd（mod n） 下述推导来自 (RSA 介绍 - CTF Wiki)

一道AirDrop主题密码题wp / 题面 小A鼓起勇气向女神索要电话号码，但女神一定要考考他。女神说她最近刚看了一篇发表于安全顶会USENIX Security 2021的论文，论文发现苹果AirDrop隔空投送功能的漏洞，该漏洞可以向陌生人泄露AirDrop发起者或接收者的电话号码和电子邮箱。小A经过一番努力，获得了女神手机在AirDrop时传输的手机号哈希值，但再往下就不会了，你能继续帮助他吗？小A只记得女神手机号是170号段首批放号的联通号码。Hash：c22a563acc2a587afbfaaaa6d67bc6e628872b00bd7e998873881f7c6fdc62fc / flag格式：flag{13位电话号码（纯数字，含国家代码）}