审计 TON FunC 合约时系统排查三类高危漏洞（布尔值误…

对 TON 区块链上用 FunC 编写的智能合约做安全审计，覆盖整数当布尔、假 Jetton 合约、转发 TON 未做 gas 检查三类平台特有漏洞。

适用场景

解决思路

1. 确认平台：检查是否存在 .fc / .func 文件，识别 TON Blueprint 或 toncli 项目结构，定位合约源码，找出与 Jetton 相关的合约。
2. 布尔逻辑审查：用 rg "int.*is_|int.*has_|int.*flag|int.*enabled" contracts/ 查找类布尔变量；用 rg "= 1;|return 1;" contracts/ | grep -E "is_|has_|flag|enabled|valid" 查找用正整数当布尔的情况；用 rg "~.*\(|~ " contracts/ 查找对类布尔值的取反操作。
3. 对每个布尔值逐项核对：是否用 -1 表示 true、0 表示 false；是否没有用 1 或其他正整数；逻辑运算是否正确。
4. Jetton 处理函数分析：用 rg "transfer_notification|op::transfer_notification" contracts/ 找出所有 transfer_notification 处理函数。
5. 对每个 Jetton 处理函数逐项核对：是否校验 sender 地址；是否将 sender 与存储的 Jetton wallet 地址比对；是否在未校验 sender 的情况下信任 forward_payload；是否有管理员函数可设置 Jetton wallet 地址。
6. Gas / 转发金额审查：用 rg "forward_ton_amount|forward_amount" contracts/ 和 rg "load_coins\(\)" contracts/ 查找转发金额用法；用 rg "send_raw_message" contracts/ 查找所有出站消息。
7. 对每条出站消息逐项核对：转发金额是否固定或有上界；若由用户提供，是否校验 msg_value >= tx_fee + forward_amount；合约余额是否无法被抽干；send_raw_message 的 flags 是否使用得当。
8. 人工复核：检查布尔逻辑中的 ~、&、| 运算符；消息解析与校验；gas 经济与手续费计算；存储操作与数据序列化。
9. 输出覆盖表：在发现项之上列出全部 3 个模式，每行给出 verdict（found / clear / n/a）与证据。found 需给出 file:line 并在下方完整撰写发现；clear 需点名你搜索的函数、存储地址或检查项，便于读者复现；n/a 需用一句话说明原因（如“该合约不处理任何 Jetton 转账通知”），没查过不算 n/a。三行都要填，Verdict 单元格为空即视为报告不完整。
10. 按模板撰写发现：包含标题（严重级别 + 漏洞名）、Location（file:line 及所在处理函数）、Description、Vulnerable Code、Attack Scenario、Proof of Concept、Recommendation（含修复代码）、References。
11. 按优先级排序：Critical 为假 Jetton 合约（未授权铸造/入账），需立即修复；High 为整数当布尔（逻辑错误、条件失效）与转发 TON 未做 gas 检查（余额被抽干），需在上线前修复。
12. 编写单元测试：用 @ton/sandbox 与 ton-core 验证 TRUE = -1、FALSE = 0 且不等于 1；验证假 Jetton 转账被拒绝（success: false）；验证 gas 不足的转发金额被拒绝。
13. 编写集成测试：部署真实 Jetton minter 与 wallet，调用 setJettonWallet 设置真实钱包地址，从真实 Jetton wallet 发起转账并验证成功。
14. 完成审计前过一遍清单：布尔逻辑（全部用 -1/0、无正整数当布尔、返回布尔值的函数返回 -1、~ & | 取值正确、测试覆盖）；Jetton 安全（transfer_notification 校验 sender、与存储的 Jetton wallet 地址比对、初始化时存储该地址、有管理员函数可设置/更新、未校验 sender 时不信任 forward_payload、用假 Jetton 合约测试拒绝）；Gas 与转发金额（金额固定或有界，或校验 msg_value >= tx_fee + forward_amount、余额受保护、send_raw_message flags 正确、测试验证无法用超额转发抽干合约）；测试（三类漏洞的单元测试、与真实 Jetton 合约的集成测试、所有操作的 gas 成本分析、主网前先上测试网、输出含全部 3 行且每行带 verdict 的覆盖表）。
15. 拒绝以下借口：“合约很小，多数模式显然不适用”——n/a 只需一句话且让判断可复核，沉默等于没查；“FunC 没有自动化工具所以覆盖无法系统化”——没有扫描器正是覆盖表存在的理由，人工审查就是方法，覆盖表让它可审计；“我只查了与该合约相关的模式”——判断哪些模式相关本身就是扫描的一部分，不是开始扫描的前提，先填完表再按严重级别排序；“没有发现就没什么可报告”——零发现的扫描同样要输出完整覆盖表，这张表才是交付物；“sender 显然就是 Jetton wallet”——那就指出它比对的是哪个存储地址，任何合约都能发 transfer notification，缺失比对就是假 Jetton 漏洞；“消息是 non-bounceable 所以 gas 无所谓”——指出预留了多少，转发时没留够剩余执行所需的 gas 会让合约中途卡死，与 bounce 行为无关。

适用边界 · 注意事项

• 非 TON 区块链或非 FunC 编写的合约（如 Solidity、Rust 合约）不适用。
• 不涉及 Jetton 转账通知、布尔逻辑或 TON 转发的纯工具类/库代码，多数模式不适用。
• 没有 TON 开发环境（TON Blueprint、toncli、ton-compiler）时无法运行测试与编译验证，只能做静态人工审查。