CBC字节翻转攻击原理与实战：从密文篡改到任意明文构造-北京尧图网络

1. 从一个加密Cookie说起CBC模式的结构性弱点做Web安全或CTF的朋友大概率都见过这类“加密即信任”的Token设计——服务端把一个包含用户身份和权限的明文对象序列化后用AES-CBC加密生成一段看起来完全不可读的密文下发到客户端作为会话凭证。表面上看没问题密钥只有服务端知道密文不可读那用户就不能篡改了吧等真正分析这套体系时你会发现AES-CBC这个模式本身藏着一个很尴尬的结构性缺陷密文分组之间按位耦合且解密过程对密文的完整性完全不设防。攻击者不需要知道密钥只需要能拿到一段合法密文、能观察密文被解密后的行为比如服务端是否返回解密失败、是否出现特定错误码就能通过翻转密文中的特定比特使解密后的明文变成自己想要的任意值。这就是CBC字节翻转攻击CBC Byte-Flipping Attack的核心。这项技术的诱人之处在于它攻击的不是算法强度而是模式设计。AES本身是安全的密钥也牢牢握在服务端手里但CBC模式将一个“不可破解的算法”降级成了一个“可以被精准编辑的明文模板”。安全圈常说的“密码学不是拼算法强度而是拼模式选择”CBC字节翻转就是最典型的例证。这篇文章我想从完整的技术链条出发拆解CBC字节翻转攻击的底层机制并手把手演示一次完整的攻击构造过程。适合三类人阅读打CTF的选手这个是常客考点、做Web安全的工程师用来审视自研加密协议以及纯粹对密码学感兴趣的开发者帮你彻底搞懂XOR和分组密码的工作关系。整个过程不需要高深的数学基础高中数学的异或运算即可。2. 前置知识CBC模式为什么是“链式”的在讲攻击之前得先把CBC模式的解密逻辑讲透因为整个攻击就是建立在解密公式的基础上的。如果你已经熟悉AES-CBC的加解密流程可以快速过一遍。2.1 加密与解密的公式拆解CBC的全称是Cipher Block Chaining即“密码分组链接”。加密时明文按照分组大小AES为16字节切成若干个明文块每一块在加密之前先与前一个密文块做异或运算然后再送入AES加密器。这里有个特殊处理第一个明文块没有“前一个密文块”所以用初始向量IV来代替。于是加密过程可以写成C_i E(P_i XOR C_{i-1}) C_0 IV对应的解密过程P_i D(C_i) XOR C_{i-1} C_0 IV从解密公式能直观看到要得到当前块的明文需要两个输入——当前块的密文C_i以及前一个密文块C_{i-1}第一个块则是IV。这两个输入中key的参与被封装在D()函数里我们无法控制但C_i和C_{i-1}都是密文而密文对攻击者是可见甚至可修改的。这就是攻击能够成立的天然条件。2.2 “翻转”一词的含义与XOR的性质“翻转”指的是把比特从0改为1或从1改为0。攻击的数学根基来自异或运算的几个简单性质交换律和结合律A XOR B B XOR A(A XOR B) XOR C A XOR (B XOR C)自身逆运算A XOR A 0归零还原A XOR B XOR A B这三个性质叠加产生了一个关键推论如果已知原始明文P和原始密文C想要让解密后的明文变成想要的P 只需要把密文改为 C C XOR P XOR P因为解密时D(C) XOR IV D(C XOR P XOR P) XOR IV结合CBC的块链接结构效果会精准地只作用于当前块的对应字节。这就是“字节翻转”可以定点修改明文的数学基础。实际上你在做翻转时不需要理解AES内部的S盒、列混淆等细节因为D()是密钥黑盒。你要处理的只是D()的输入输出之间的XOR关系这正是CBC被翻转子攻击“欺负”的原因。3. 攻击的本质把密文当作可编辑的模板很多人第一次接触字节翻转会被“翻转”这个词吓住以为需要搞什么差分分析。其实整个攻击的思考方式非常直接——把它当成一个模板编辑问题。3.1 修改C_{i-1}会影响到谁根据解密公式P_i D(C_i) XOR C_{i-1}我们可以做两组简单推理推理1修改某个密文块C_j中的任意字节会直接改变P_j的全部字节因为D(C_j)整体变化了无法预测同时P_{j1}中对应位置的字节会按照我们构造的XOR值发生变化。也就是说修改C_j的代价是“牺牲”P_j换取P_{j1}的精准修改。推理2修改IV中的某个字节会直接且只改变P_1对应位置的字节并且这种改变完全可控因为IV不经过AES解密直接参与XOR。这就是第一个分组不需要“牺牲”其他块的原因——前提是你手里有IV并且服务端确实用同一个IV去解密。理解这两条推理后攻击的全貌就出来了我们要修改第N个分组的某个明文值就去修改第N-1个分组的对应密文字节。唯一要承受的副作用是第N-1个分组解密后会变成不可预测的乱码。在实际攻击中能不能接受这个副作用决定了攻击构造的复杂程度。3.2 在既有密文上做定点字节修改假设我们有这样一个数据包格式16字节 | 16字节 | 16字节 header | uid | role作用是将role字段位于第3个分组从0改为1。根据上面的推理要改P_3的某个字节就改C_2的对应字节。攻击者构造新密文C_2 C_2 XOR P_2 XOR P_2其中P_2是原始明文第2块P_2是想要P_2变成的任何值某些场景下我们甚至可以不去关心P_2变成什么。解密端在用C_2解密时P_3会精准变成P_2和P_3之间的XOR结果。只要P_2 P_3 XOR 预期新值P_3就是预期新值。这里要注意一个容易犯迷糊的点攻击者为什么要知道原始明文P_2因为翻转公式里需要原始明文来计算翻转掩码。但在真实攻击中原始明文不一定是已知的。怎么解决要么从其他渠道比如某种数据格式泄漏、协议文档、常识推断恢复明文要么配合Padding Oracle爆破出解密中间值再把中间值当作已知量进行翻转。稍后会详细展开。3.3 受害者视角解密端完全不设防CBC模式下解密端拿到密文后只会机械地执行“解密 XOR前块”的操作它不会验证密文是否被篡改。只要密文长度合法、解密后填充合法应用层就会继续处理这个“被污染但语法合法”的明文。很多开发者以为“密文不可读不可篡改”但可读性和完整性是两码事。这一行认知偏差不知道养活了多少安全测试项目。4. 从零构造一次完整攻击实操演示现在抛开抽象推导用一个具体例子走通全流程。我以一次内部演练中遇到的模拟场景为例。4.1 假设的攻击场景与数据包格式某系统使用AES-128-CBC加密了一个会话凭证密钥32字节AES-256分组16字节。凭证明文结构如下字段1: magic(4字节) 字段2: user_id(4字节) 字段3: role(4字节) 字段4: expire_time(4字节)全部拼接后恰好16字节。明文magic0x61626364 (abcd) user_id0x00000005 role0x00000000 (0为普通用户, 1为管理员) expire_time0x5F1E8B20这段明文用密钥K加密后得到密文C。于是CBC的分组情况是IVAC_1B。由于明文只有一组攻击者想要修改P_1里的role字节只能用IV来翻转因为C_0 IV。4.2 情况一已知原始明文直接翻转IV在已知原始明文P的情况下攻击变得非常简单。假设目标是把role字段从0改成1定位role字段在明文中的偏移量8第9个字节计算翻转掩码5F1E8B20里的第8字节role的低位字节从0x00变为0x01掩码 0x00 XOR 0x01 0x01将IV的第8字节异或0x01得到新IVIV IV IV[8] IV[8] XOR 0x01解密端P_1[8] D(C_1)[8] XOR IV[8] D(C_1)[8] XOR IV[8] XOR 0x01 P_1[8] XOR 0x01 0x00 XOR 0x01 0x01role字段成功变为1其余字节完全不变。整个攻击只改了一个字节且不需要触碰任何密文分组。这就是第一个分组的攻击优势IV通常随密文一起传输攻击者可以自由改动。4.3 情况二明文不可知用Padding Oracle爆破中间值现实中最常见的情况是攻击者不知道原始明文只拿到了密文。比如token是加密的一段JSON字段名和值都是动态的。此时就需要先通过Padding Oracle拿到解密中间值I D(C_i)然后将I作为已知量来构造翻转。Padding Oracle攻击的核心逻辑利用了CBC解密后填充校验的差异性。AES-CBC解密后最后一个分组的最后一个字节会被当作填充长度如果填充不合法解密程序通常会抛出“padding error”。攻击者利用这个错误作为“预言机”逐字节猜测解密中间值。推导过程假设我们要猜测I的最后一个字节。将前一个密文块的最后一个字节设为X自定义值解密最后一个分组得到 P_last I XOR X 服务端检查P_last的最后一个字节是否是合法的padding。它是合法padding (0x01) 当且仅当 I[15] XOR X 0x01 I[15] X XOR 0x01 如果服务端没有报错说明猜测成功如果报错就换一个X继续试直到找到正确的X。找到最后一个字节后继续构造“末尾最后两字节 0x02, 0x02”的条件依次向前猜测每个字节。每个字节最多256次尝试16字节分组最坏情况下尝试4096次也就是几秒钟到几分钟的请求量。这个技术在CTF和实战中都是成熟的标准操作网上有大量半成品脚本可以直接套用。4.4 从中间值到翻转构造新密文块拿到I D(C_1)之后翻转就变得和情况一同样简单。比如目标是把P_1第8字节从某个未知值改成0x01C_1[8] I[8] XOR 0x01当解密端执行P_1[8] D(C_1)[8] XOR IV[8] I[8] XOR (I[8] XOR 0x01) XOR IV[8] 0x01 XOR IV[8] ??? 等一下 —— 这里不对有个细节点必须澄清。上面的推导有问题D(C_1)[8] 并不等于翻转后的D(C_1)[8]。因为修改密文块C_1本身会让整个D(C_1)的结果完全改变无法预测。前文说过这条规律修改C_i会破坏P_i带来不可控的乱码。因此CBC字节翻转里“修改当前块”和“修改前一块”是两个完全不同的操作修改C_i能精准控制P_{i1}但P_i会变成乱码修改C_{i-1}能精准控制P_i代价是P_{i-1}变成乱码C_{i-1}是前一块密文修改它会让P_{i-1}整体乱掉所以正确的操作是想修改P_1不能改C_1而要改IV想修改P_2要改C_1依此类推。上面的中间值爆破思路适用于“想在某个特定密文块上做翻转需要知道该块解密后的中间值”——但反过来用的时候要注意我们是把目标块的前一块而非目标块本身的密文作为翻转载体。让我把完整的翻转公式重新理顺假设目标是让P_2变成P_2原始P_2未知通过Padding Oracle爆破出 I_2 D(C_2)构造 C_1 C_1 XOR I_2 XOR P_2解密时P_2 D(C_2) XOR C_1 I_2 XOR (C_1 XOR I_2 XOR P_2) C_1 XOR P_2这里我又写混了。实际的正确流程是解密时 P_2 D(C_2) XOR C_1攻击者想让 P_2 变成 P_2需要 C_1 D(C_2) XOR P_2但 D(C_2)是未知的所以先爆破出它这就是中间值上面描述的Padding Oracle步骤正是在爆破它然后在原始C_1上做XORC_1 C_1 XOR P_2 XOR P_2但前提是知道P_2更普适的做法是直接构造C_1 I_2 XOR P_2此时不需要修改原C_1而是完全替换掉C_1所以最完整的流程是拿到原始密文C_1和C_2爆破出I_2 D(C_2)将C_1替换为 C_1 I_2 XOR P_2其中P_2是想要的明文解密P_2 I_2 XOR C_1 I_2 XOR (I_2 XOR P_2) P_2这样完全不需要知道原始P_2。原理上一旦拿到中间值就等于把“解密后的结果”提前握在手里剩下的翻转只是XOR运算想改成什么就改成什么。4.5 多分组数据包的完整构造示例真实系统几乎不会只加密一个分组。假设明文结构有三个分组Block 1: {user:alice Block 2: ,role:0,exp Block 3: ire:12345678}攻击者想把role从0改成1。这里有两种做法做法A翻转第2块到第1块目标是P_2中的role字节偏移量第2块内第10个字节修改C_1的对应字节公式C_1[10] C_1[10] XOR P_1[10] XOR P_2_target[10]前提需要知道P_1[10]的原始值即“alice”中偏移10对应的字符这个通常是可以从协议格式推断出来的做法B替换整个C_1先爆破出D(C_1)中间值I_1直接把C_1替换为 I_1 XOR 想要的新P_1此时P_1被完全控制比如改成{user:bob,ro凑齐16字节P_2的role字段保持原样但P_1已经被改成了我们想要的内容做法B更强大因为它不光能做翻转还能在中间值已知的条件下构造任意明文。代价是需要对每个分组都爆破一次中间值。5. 实战中绕不开的坑边界条件与利用限制理论说通了真正打起来你会发现现实比推导里多出一堆麻烦。下面这些坑都是我在实际测试和CTF赛题中踩过的按严重程度排序说。5.1 第一个分组的特殊地位IV的利用与局限第一个分组是最容易利用的因为IV通常和密文一起明文传输攻击者可以随意修改而且修改IV不影响任何其他分组。代价是你需要知道原始明文才能计算出精确的翻转掩码。如果明文结构不透明就需要先解决“如何知道明文内容”的问题。这里有个实用技巧很多场景下明文里包含JSON标签、固定字段名、Magic Number这些可预测片段用这些已知片段作为锚点可以推导出相邻未知区域的翻转值。5.2 Padding错误可能摧毁整个会话小心“牺牲品”分组前面说过修改C_j会让P_j变成不可预测的乱码。这个乱码分组在解密时如果恰好落在最后一个分组很有可能因为padding校验失败而整个解密流程直接中止更谈不上进入应用层逻辑。这意味着攻击者在选择“要牺牲的分组”时必须避免拿最后一个分组当牺牲品。实操上如果目标字段在最后一个分组而解密程序又严格要求合法padding攻击难度会显著上升——你得先修改前面某个分组作为padding的“替死鬼”同时目标分组恰好不受影响。这本质上是一个规划问题很多时候比技术本身还要费脑。5.3 密文长度与数据完整性校验的叠加限制很多真实系统会额外在明文里加上MAC或签名比如先加密后MAC的“Encrypt-then-MAC”模式。在这种情况下仅翻转密文是不够的因为MAC校验会在应用层再次失败。但这不代表字节翻转就彻底没戏了——它只是从“直接利用”变成了“信息泄露通道”。比如某些框架在MAC校验失败时会返回不同的错误码攻击者可以利用这个差异做更精细的Padding Oracle甚至结合其他漏洞把攻击链路继续推进。5.4 压缩、序列化与编码的复合问题如果数据在加密前经过了压缩或特殊序列化翻转后的明文即使通过了padding校验也未必能通过应用层的格式解析。比如JSON解密后变成非法JSON服务端直接500。这种场景下你需要精心构造P_2让它在XOR运算后仍然是一个语法合法的JSON片段。这样做难度呈指数级上升但在部分真实系统里是可以做到的。6. 自动化思路写一个通用字节翻转工具手工逐字节计算容易出错。我习惯把常用的字节翻转逻辑写成一个通用脚本遇到类似场景直接替换参数。以下是一个面向CTF场景的Python模板它包含了Padding Oracle爆破和翻转两个核心模块。6.1 爆破中间值的核心循环import requests from Crypto.Cipher import AES def pad_oracle(ciphertext, iv, oracle_url): 针对每个密文分组爆破出解密中间值。 oracle_url是服务端的解密错误判断接口返回True表示padding正确False表示错误。 block_size 16 intermediate bytearray() # 逐个字节爆破从最后一个字节往前 for byte_pos in range(1, block_size1): # 根据已知的中间值字节构造已填充部分的值 known_pad bytes([x ^ byte_pos for x in intermediate]) found False for guess in range(256): if guess known_pad[-1] if known_pad else False: continue # 构造测试密文块将目标字节替换为guess test_block bytearray(b\x00 * block_size) # 从后往前设置先保持后面字节为合法填充值 for k in range(1, byte_pos): test_block[-k] known_pad[-k] test_block[-byte_pos] guess test_cipher bytes(test_block) ciphertext if pad_oracle(test_cipher): real_val guess ^ byte_pos intermediate.insert(0, real_val) found True break if not found: raise Exception(爆破失败请检查oracle逻辑) return bytes(intermediate)这个脚本的核心逻辑是从最后一个字节往前逐字节爆破每次都利用已知的后缀字节构造合法的padding值通过oracle反馈判断当前字节是否猜中。注意爆破每个字节时都要跳过“会与已知填充冲突”的guess值避免误判。6.2 拿到中间值之后的翻转函数def flip_cbc(ciphertext, iv, block_index, target_plaintext): block_index: 要修改的目标明文所在的分组索引0起始 target_plaintext: 期望该分组解密后的完整内容必须是block_size字节 block_size 16 blocks [iv] [ciphertext[i:iblock_size] for i in range(0, len(ciphertext), block_size)] # 爆破目标分组的解密中间值 target_block blocks[block_index 1] # blocks[0]是IV inter pad_oracle(bytes(target_block), blocks[block_index], lambda ct: requests.post(ORACLE_URL, data{ct: ct.hex()}).status_code 200) # 构造新的前一块密文 new_prev bytes([inter[i] ^ target_plaintext[i] for i in range(block_size)]) blocks[block_index] new_prev # 重组密文 new_cipher b.join(blocks[1:]) new_iv blocks[0] return new_iv, new_cipher注意这里有个细节如果目标分组是第一个分组new_prev要作为IV返回而不是作为密文的一部分。很多教程在这个地方含糊其辞导致初学者把IV和密文块拼接顺序搞反费了半天劲解密出来全乱。6.3 脚本的局限性与适用边界上面的脚本假设服务端的oracle是可稳定访问的HTTP接口且错误响应不会限流。实战中如果oracle不稳定爆破时间会大幅拉长。另一个隐性限制是当你替换整个C_1时C_1原本对应的那个组的副本会丢失——如果你的目标字段跨越多个分组需要为每个分组分别爆破和翻转。整个脚本做的是一个非常机械的事真正的难点在“判断哪些分组可以被牺牲”“目标plaintext应该组装成什么样子”这些需要人工判断的环节。7. 防御视角为什么说“别自己造加密协议”聊完了攻击细节再从防守方视角聊聊怎么彻底堵住这类漏洞。这不是套话因为我见过太多系统在“加固”了加密算法之后依然被字节翻转击穿问题往往不是出在加密强度上而是出在模式选择上。7.1 首选方案切换到认证加密模式目前业界公认的答案是使用带认证的加密模式比如AES-GCM、AES-CCM、ChaCha20-Poly1305。这些模式在加密的同时生成一个完整性标签tag解密时先验证标签再解密。哪怕攻击者翻转了密文tag校验必然失败解密流程在第一时间就会被拦截。从字节翻转的角度看GCM的计数器模式CTR本身没有块链接密文任意字节的翻转只会导致明文对应位置的翻转但tag校验把这条路完全封死了。比CBC最大的优势是无论你怎么改密文认证阶段直接把你挡在门外连Padding Oracle这种侧信道都不给留。7.2 如果历史原因只能用CBC怎么降低风险假设系统老、流量大、一时半会儿换不掉CBC至少要有以下几层防线固定IV 防重放服务端为每个用户维护独立的、随机生成的IV攻击者无法替换IV那第一个分组的翻转通道就被堵死了。同时配合时间戳或随机数防重放能进一步限制攻击窗口。应用层二次校验在密文中额外附带一个基于密钥的HMAC且将密文和IV都纳入HMAC计算范围。这就是Encrypt-then-MAC的标准做法——先加密再对密文算HMAC。解密端先校验HMAC再解密。即使模式是CBC翻转攻击也会被HMAC拦截。注意一定要用“先加密后MAC”的顺序而不是“先MAC后加密”否则MAC本身可能被当作攻击面。白名单校验明文结构应用层解析明文前先验证是否有预期字段、字段值是否在合法范围内。比如role字段不是0就是1如果出现3就拒绝。这种做法能拦截盲目的翻转尝试但不拦已知明文的结构性攻击因为翻转后的语义可能完全合法。所以它只能作为纵深防御的一层不能单靠它。7.3 对自研协议的三条忠告第一条永远不要在自研方案里做一个“只加密不认证”的设计。密码学里所有声称“因为用户看不到密钥所以安全”的方案都是等待被攻击的靶子。第二条密码学库已经提供了足够成熟的封装如libsodium、Tink等不要自己拼装原语。自拼装的复杂性十有八九会引入和字节翻转同类的结构性漏洞。第三条如果一定要用CBC务必阅读所有关于padding oracle攻击的资料假设攻击者已经拿到了解密中间值然后反问自己即便对手能完全控制明文内容系统还能扛住吗如果答案是“扛不住”就别用CBC。8. 延伸思考字节翻转背后的通用密码分析思路在我个人做安全这些年见过不少人把字节翻转当成一个孤立的“魔术技巧”来记却忽略了它背后更通用的思维模式——寻找加密系统中的“线性可控点”。CBC因为XOR链的存在天然提供了这种可控点但类似的现象在其他密码结构中也存在。8.1 从字节翻转到分组替换攻击如果攻击者手里有“明文-密文对”集合比如两个不同用户各自的加密凭证除了单字节翻转还可以做分组替换——把某个用户密文中的指定密文块原样替换成另一个用户密文中的对应块。这种攻击利用的同样是CBC“块之间独立解密”的特性不需要知道密钥也不需要爆破中间值只需要能拿到两段合法密文。举一个经典场景两份密文分别解密出{role:user,uid:5}和{role:admin,uid:1}直接把前者的第二个密文块替换成后者的第二个密文块解密后角色字段就变成admin了。这给我们的启发是CBC模式下密文的“可拼接性”和“可编辑性”同样危险完整性校验不是可选项。8.2 与Padding Oracle攻击的孪生关系字节翻转和Padding Oracle像一对孪生兄弟字节翻转解决的是“改了密文之后如何让明文符合预期”Padding Oracle解决的是“不知道明文时如何获取解密中间值”。两者经常组合使用——用Padding Oracle获取中间值再配合字节翻转构造任意明文。理解这种组合关系比单纯背一个攻击模板要有用得多。实际CTF题目里这两种技巧往往会和Web框架的序列化标签、数据库回显错误等场景结合形式多种多样底层原理万变不离其宗。8.3 顺着“可控点”思维做安全评审我现在看一个系统是否值得深入测试时会先画一条数据流标出所有“加密后的数据落回到客户端”或“客户端可以回传加密数据”的位置。凡是有这种位置且没有做完整性校验字节翻转和分组替换的利用面就存在。顺着这条线去思考攻击面比去翻CVEs列表效率高得多。9. 个人实操心得几个值得记录的细节写到最后分享几个我在实际项目中踩过且花了不少时间才弄明白的细节希望能帮后来的朋友们少走弯路。9.1 关于翻转字节的偏移计算翻转时最常犯的错误是偏移量算错。明文分组是16字节一组目标字节在全明文中的偏移量要先换算成“分组内偏移”再换算成“目标块的前一块的字节位置”。举例明文长度40字节目标在第30字节。那么它在第2分组内偏移是1430 - 16 1414对应0索引要修改的是C_1[14]而不是C_2[14]。这个换算关系每次都要仔细核对。我的习惯是先写小函数做偏移换算不要手工心算。9.2 爆破时oracle的噪声处理Padding Oracle爆破最怕oracle不稳定。如果网络抖动或者服务端偶发超时爆破结果会出现误判。我的做法是每个字节连续验证两次以上两次结果一致才记录。这样爆破时间是原来的两倍但换来的是几乎零误判值得。另一个小技巧是设置合理的超时和重试机制不要用默认的requests超时否则大批量请求时会出现大量假阴性。9.3 密文块合并时的字节序问题Python里字节串做XOR运算需要逐字节循环不能直接对整个bytes对象做位运算。这个坑看似基础但在写工具时很容易被数组索引搞乱。另外字节序要保持一致——AES的分组是按网络序大端处理的如果你的加密库用的是小端存储翻转结果会完全错位。遇到翻转子后解密出来是乱码优先检查字节序和偏移量而不是怀疑原理写错了。

CBC字节翻转攻击原理与实战：从密文篡改到任意明文构造

相关推荐

Qt 5.12与QGIS 3.10实战：状态栏实时坐标显示与坐标系转换

FPGA SDRAM控制器设计：状态机、刷新与数据通路详解

wow.js滚动触发动画原理与实战：IntersectionObserver轻量封装

更多资讯

C++工厂模式详解：从简单工厂到抽象工厂的工程实践指南

Linux进程深度解析：从task_struct到僵尸进程排障

现代C++工厂模式实战：从简单工厂到依赖注入

Windows下Redis C客户端hiredis静态库编译链接与避坑实践

Spring Boot 2.0整合Quartz：从入门到生产级任务调度实践

C# WebApi实战：原生WebSocket构建即时聊天与连接管理

今日更新

防关联浏览器哪个好？三款产品实测差异解析

2026钢铁行业AI转型系统选型对比：多基地排产、大宗原燃料采购与质量追溯，六家厂商能力差异在哪里

影刀RPA深度实战：大模型Fine-tuning定制RPA专用Prompt与指令生成

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？