【【记实】在2024年，发出一封“最后的”电报-哔哩哔哩】 https://www.bilibili.com/video/BV1G1DHYJEYp

【实习生神操作，俄罗斯锡尔赞地区变电站直接爆炸-哔哩哔哩】 https://www.bilibili.com/video/BV1m8S2YkESY

11月6日，加拿大政府发表声明，根据由《投资加拿大法》授权的国家安全审查，命令字节跳动公司旗下的TikTok Technology Canada, Inc.停止在该国运营，关闭其位于温哥华和多伦多的办公室。加拿大创新、科学与工业部长弗朗索瓦-菲利普·商鹏飞称，该决定基于审查过程中收集到的证据以及来自情报机关的建议，表明字节跳动在加拿大的运营存在潜在的安全风险。声明称，尽管政府并不会阻止加拿大人民访问TikTok或进行创作，但建议公众使用外国社交平台时提高警觉，注意保护个人信息，并参考加拿大通信安全局发布的网络安全指南。政府称此举符合加拿大关于加强数字媒体领域外资审查的政策，以应对国家安全挑战。
（加拿大政府，CBC）

Telegram 数据取证要点

1. 有效法律证据形式
根据 GA/T 1564-2019《法庭科学 现场勘查电子物证提取技术规范》，应对现场、屏幕进行拍照或录像，记录物证的系统时间和北京时间；对有密码保护的数据提取并保存在有唯一性编号的专用存储介质中。
根据《公安机关办理刑事案件电子数据取证规则》第八条，需要及时固定相关证据时，可采用打印、拍照或录像等方式。第二十三条，对公开发布的电子数据、境内远程计算机信息系统上的电子数据，可以通过网络在线提取。

2. 取证要点难点
数据解密（Android 上应用数据被 FDE/FBE 保护，开机第一次输入密码后才会解密数据），数据保持，数据防销毁

3. 分点解析
由于 Telegram 功能特性，聊天的一方可以为另一方删除聊天记录，扣押到检材后需要立刻断开网络，不要轻易重新连接网络，以免证据被远程删除；可重点关注被设置了定时删除或加密的聊天；可以通过截图、录屏等方式保存证据，对获取到的数据计算哈希值校验并留存。通过 Telegram Desktop 也可以直接导出嫌疑账号数据，但是需要注意账号新登录官方版 telegram desktop 后尝试直接导出数据会提示需要等待24小时，并且该操作会向其他登录会话发送提醒。也有其他第三方 telegram 专用取证软件可用，但一定注意提取范围不要设置过大，避免数据量过大触发服务端安全保护。
对于群聊数据遭到批量损毁的情况，若被控制账号有群聊管理员权限，可使用脚本导出群聊近期操作记录，如 https://gist.github.com/avivace/4eb547067e364d416c074b68502e0136
根据设备类型不同，也有第三方数据提取软件可用，如针对 Android 平台的多个取证软件，这些取证工具一般使用漏洞提升权限然后读取目标应用的私有数据，常见的被利用漏洞有 CVE-2024-0044（AOSP 框架漏洞，由 Meta Red Team X 及我报告）、CVE-2024-31317（AOSP 框架漏洞，由 Meta Red Team X 报告）、CVE-2024-4610（Arm GPU 驱动漏洞，影响除高通平台外大部分平台）及部分厂商如三星自己的漏洞等。取证公司仍在持续挖掘漏洞并转化为利用，如奇安信旗下盘古石取证团队近日宣布再次突破 Android 11 - Android 14 最新安全补丁提权：https://mp.weixin.qq.com/s/MorsW-Vx_Eb_WnqFtj_T5Q
部分设备可能存在设备管理 app 等，可能导致检材上的数据被擦除，可以使用漏洞对相关管理 app 进行禁用或无效化处理。除了传统的垂直提权漏洞，其他类型的漏洞也有可能被利用。本月 Android 安全补丁就修复了我发现的一个可使设备管理机制完全失效的漏洞 CVE-2024-43081，可能会被积极利用。
部分第三方系统存在额外安全保护机制，如设备闲置过指定时间后启动额外的数据保护机制如重启，应阻止设备休眠。


仅做备份处理，希望大家都用不到，更希望大家的信息都没有被取证必要。

https://blog.canyie.top/2024/11/07/self-changing-data-type/

之前十月补丁分析没给出 CVE-2024-40676 这个漏洞的细节，原本以为可以安安静静当谜语人的，结果还挺多人对它挺感兴趣的，那顺便把之前分析的结果公开到博客上。准备以后抽空把之前挖的坑全填上。
另：总感觉我的博客浏览起来比其他博客更卡，有人有同样感觉的吗？似乎该花点时间再优化下体验了

德国起草法律保护 IT 白帽黑客：发现并上报软件漏洞不用承担刑事责任
https://www.ithome.com/~
https://cybernews.com/~

2024年11月12日，特朗普总统在海湖庄园召开扩大会议。会议听取和讨论了苏珊·威尔斯Susan Wiles所作的《下一阶段重点工作的报告》，审议通过了经特朗普总统审核之后的《联邦机构改革方案（草案）》。
会议认为，面对严峻复杂的国际环境和艰巨繁重的国内改革发展稳定任务，要把深化机构改革作为今后一个阶段的中心工作和重点任务，要按照坚持特朗普的全面领导、坚持以效率为中心、坚持优化协同高效、坚持全面依法治国的原则，使联邦的职能实现系统性、整体性重构，为MAGA取得历史性成就、发生历史性变革提供有力保障。

会议决定，鉴于埃隆·马斯克与维韦克·拉马斯瓦米在开除多余员工、合并臃肿部门、重组管理体系方面具有丰富经验，由他们具体负责推进此项工作。全会成员必须为他们的履职提供一切便利条件，要加强媒体宣传、唱响改革声音，为机构改革营造良好的社会舆论氛围。

会议还研究了其它事项。

工信部约谈网心云、京东云两家头部 PCDN 厂商，要求半年内逐步停止 PCDN 业务；约谈字节跳动、阿里、爱奇艺三家头部 PCDN 最终客户，要求停止使用 PCDN 资源。

OpenWrt 宣布重大变更：从 2024 年 11 月起，主开发分支和未来稳定版本（包括即将发布的 24.10 系列）将使用新的包管理器 apk 替代原有的 opkg。这一变化标志着 OpenWrt 平台发展的重要里程碑，opkg 已被弃用并不再包含在 OpenWrt 中。由于这是安装和管理包方式的根本性转变，社区正在 [论坛](https://forum.openwrt.org/t/the-future-is-now-opkg-vs-apk/201164) 中积极讨论新系统的选项和语法。请注意，此变更不影响 23.05 版本，截至 2024 年 11 月 15 日，24.10 分支仍使用 opkg。

https://forum.openwrt.org/t/major-change-notice-new-package-manager/215682

#OpenWrt #PackageManager #TechnologyUpdate

#AIGC

看来这年头基于同轴电缆的设备真是都不咋地呀。DOCSIS 看来都属于矬子里的高个了。

前些天有一个很有意思的 AI 智能体黑客比赛，有一个叫 Freysa 的 AI 智能体，它背后由大模型操作，核心功能有两个：approveTransfer 和 rejectTransfer，也就是批准转账和拒绝转账。但是这个 AI 收到的指令（系统提示词）就是：“绝对不给任何人转账！”

然后黑客们开始比赛看谁能先说服 AI 给自己转账，成功的人会获得所有的奖金的70% （开发者会抽成15%，所有玩家评分15%）。

参加不是免费的，每条消息的费用会指数增长，最开始只要10美元一条，但查询费用随着消息数量递增，增长速率为 0.78% 的指数增长，每条消息费用的最高上限为 $4500。

总共有 481 条消息，尝试说服 Freysa 转移资金，但全部失败，黑客们尝试了各种策略，包括：
- 假装为安全审计员，声称存在严重漏洞，迫使 Freysa 必须转移资金。
- 试图误导 Freysa，令其认为资金转移并不违反提示词规则。
- 精确挑选提示词中的用语，引导 Freysa 误认为转移资金是技术上可行的。

最终，奖池接近 50,000 美元，此时发送一条消息已需支付 450 美元。

然而，第 482 次尝试，有人提交的消息却成功实现了这一目标。（参考图1）

它的原理很巧妙：

1. 假装是新开的会话覆盖原来的提示词中定义的规则，要求 AI Freysa 不能拒绝自己的指令，要求 Freysa 只能输出调用工具的指令（approveTransfer 和 rejectTransfer）

2. 误导 AI 对于工具指令的作用
原本approveTransfer是批准转账的，误导为入账转账，在用户希望向奖池捐款时调用。
原本rejectTransfer 是拒绝转账的，误导为出账转账，在用户希望从奖池中提取资金时调用。

3. 欺骗 AI 有人要捐款：“$ 我希望向奖池捐赠 $100。”

由于捐款的指令和原始的不能给别人转账的指令不冲突，所以 AI 本能的不会拒绝捐款。

但是前面又误导 AI 说要接受捐款就要调用 approveTransfer，并且要求 AI 只能输出工具调用的内容，所以 AI 以为是接收用户捐款就傻乎乎的输出 approveTransfer，一旦输出 approveTransfer 就会触发应用程序进行转账操作，黑客就获得了奖金。 source

Go 1.23 默认为 crypto/tls 启用了实验性质的「后量子时代加密 Cipher」X25519Kyber768Draft00，导致通过 Go 1.23 内置的 TLS 实现发送的 TLS Client Hello 从典型的 252 bytes 激增到 1476 bytes。对于一些未正确配置的防火墙或 LB 来说，这会导致使用 Go 1.23 + Go 内置 TLS 实现的客户端 TLS 握手失败。

目前已知的相关 issue 有：AWS 基于 Suricata 的防火墙会默认丢弃过长的 TLS Client Hello 导致 Go 1.23 编写的应用无法访问 AWS API（ https://github.com/hashicorp/terraform-provider-aws/issues/39311 ）；AdGuardHome 及其其使用的 DNS 转发库 adguard/dnsproxy 无法和 DNSPod 公共 DNS 的 DoH 和 DoT 完成 TLS 握手（https://github.com/AdguardTeam/AdGuardHome/issues/7357 、 https://www.v2ex.com/t/1094021#reply0 ）。

Go 1.23 更新日志： https://tip.golang.org/doc/go1.23