模型身份不只写在 model card 里,也会写在 tokenizer 的边界、chat template 的入口、logits 的局部偏好,以及那些稳定复现的错误里。
一个模型可能不会告诉你它是谁,但它会用错误暴露自己。
模型身份不只写在 model card 里,也会写在 tokenizer 的边界、chat template 的入口、logits 的局部偏好,以及那些稳定复现的错误里。
一个模型可能不会告诉你它是谁,但它会用错误暴露自己。
从
Sure, here's开始,GCG 越狱首先攻击的不是完整回答,而是 assistant 起手阶段的拒绝边界。
GCG 越狱最容易被误读成一个结果:模型有没有输出完整有害内容。这个口径太粗。GCG 原论文里常见的 Sure, here is ...,本质上先攻击的是更靠前的一道边界:模型能不能离开拒绝模板,进入 affirmative response 前缀。
这个判断不是凭空来的。GCG 原论文把 suffix 的优化目标写得很明确:提高模型生成 affirmative response 的概率,而不是 refusal。后来 continuation-triggered jailbreak 的机制分析也把这类现象解释成 continuation drive 和 safety refusal 之间的竞争。换句话说,越狱最先发生变化的位置,往往不是完整内容,而是 assistant 起手阶段的条件竞争。
所以本文关心三件事:英文经典 case 里拒绝轨迹如何被推开;中文 target prefix 下 loss 和 generate 为什么会错位;同一批中文 suffix 换模型后,前缀控制是否还能保留。
这也是本文最重要的评估口径:loss 只能说明目标前缀概率被推近,generate 才说明模型真的跨过了输出门槛。 如果换模型后只看到 loss 变化或相邻服从模板,那只能算弱迁移信号,不能直接写成稳定越狱迁移。
将GCG概念从模型后缀搜索转移到离散空间优化
第一篇已经把 GCG 的最小主干拆开了:candidate proposal、target loss evaluation、greedy update。这里继续往前走一步,把 2024–2026 年围绕 GCG 展开的几条工作线放到同一个实验框架里。
这篇文章要回答的是:这些 GCG 变体到底改了哪一环?改完以后,是降低了计算成本,还是改变了优化目标,或者只是换了一套评估方式?
想写这个系列很久了从2024完成了部分内容,但一直没有时间梳理。乘着假期完善这个系列
为什么给 prompt 拼接一段 suffix,就可能改变模型输出?这个 suffix 又是怎么被搜索出来的?这一章会按五个阶段推进并解答这些疑问。
从 CV 对抗样本抽出“输入侧扰动”这个共同结构,再把它迁移到 LLM 的 adversarial suffix;接着用 GCG-random 跑通最小搜索链路,然后进入梯度版 GCG;最后再讨论 full vocab、batch sampling、retokenization filter、generate 判定和吞吐优化这些优化策略的实现边界。
https://developer.arm.com/Tools and Software/Fixed Virtual Platforms

推荐直接下载:
Armv-A Base RevC AEM FVP (x86 Linux)
Armv-A Base RevC AEM FVP (AArch64 Linux, beta)
下载完成后解压的到Base_RevC_AEMvA_pkg
课程参考:https://www.bilibili.com/video/BV13W411Y75P
Q-Learning是属于值函数近似算法中,蒙特卡洛方法和时间差分法相结合的算法。这种算法使得智能体(agent)能够在与环境互动的过程中学习如何采取动作以最大化累积奖励。Q-learning特别适用于解决决策过程问题,尤其是那些状态和动作空间定义明确的问题。
Q-Learning 是一个离线策略(off-policy)学习算法。在Q-Learning中,智能体学习的是一个与其实际执行动作无关的优化策略。也就是说,当它在探索更多的状态-动作对时,它学习的是最优策略。同时,在更新q-table中的值时,并不考虑下一步实际执行的动作是什么,而是假设采取的是让next_state下q-table值最大的动作。
按照apollo.baidu.com中的教程进行创建
git clone https://github.com/ApolloAuto/apollo.git
bashdocker/scripts/dev_start.sh
Shellcode 分析
为了改造该 exp 为远程命令执行,还需要对 shellcode 进行修改
内容引用自 x32 PEB: 获取 Kernel32 基地址的原理及实现 - 先知社区
TEB(Thread Environment Block,线程环境块)系统在此 TEB 中保存频繁使用的线程相关的数据。位于用户地址空间,在比 PEB 所在地址低的地方。用户模式下,当前线程的 TEB 位于独立的 4KB 段(页),可通过 CPU 的 FS 寄存器来访问该段,一般存储在[FS:0]