Orien Daily
- 📸 @Phillia_0526
2026.07.25 Hot girls ver.🔥
2026.07.25 辣妹ver.🔥 #ITZY #있지 #YEJI #예지
原文 #黄礼志Media is too bigVIEW IN TELEGRAM - 📸 @Yellow_yj0526 ×2
260725 KMONSTAR TAIBEI
완벽한 이목구비를 가진 표범🐆
@ITZYofficial #ITZY #있지 #YEJI #예지 #イェジ
原文 #黄礼志 - 📸 @sc06256 ×3
昨日の小夏さんの配信であった小屋でのシーン、実は私好きなんです！！
涙を流し修の手紙を読む雛子さんの姿が忘れられらないです😢
修に頼らず頑張ろうと決心する雛子さんがとてもステキでした🥰🥰
＃加藤小夏 #SILENTHILLf
原文 #加藤小夏 - 📚 「〜にあたって」不是万能的“在……时”
很多人写技术文档时会把「在部署前」「在实验开始时」一律写成「〜するとき」或者「〜前に」。这不算错，但语气很平，少了一层“这是一个正式节点，要特别处理”的意思。真正适合这种场景的，常常是「〜にあたって」。
它最常见的使用场景，是进入一个重要动作、阶段、决策点之前，先说明前提、方针、注意事项。比如系统移行、論文投稿、実験開始、データ公開，这些都不是随手一做的小动作，而是“开始做这件事时，需要郑重交代一点东西”。这时候用「〜にあたって」很自然。
它和相近表达的区别，要卡得很清楚。「〜とき」只是单纯说“……的时候”，信息最中性；「〜際に」更书面，也常见于通知和公告；「〜にあたって」则更像“值此……之际，在正式着手这个关键事项前后”，带有准备、说明、配套处理的感觉。所以你可以说「本番環境へデプロイするにあたって、ロールバック手順を確認する」，但不太会说「昼ご飯を食べるにあたって」。后者太小，撑不起这个句型。还有一点别忽略：「〜にあたって」前面通常接意志性、重大性较强的动作，不适合接偶发小事，也不适合拿来描述纯客观同时发生的动作。
例句直接拿去用就行。
研究計画書を提出するにあたって、関連研究との違いを一段落で明示した。
在提交研究计划书时，先用一段明确写出了和相关研究的区别。
本番環境へ移行するにあたって、監視項目とロールバック条件を事前に合意しておく必要がある。
在迁移到生产环境之前，需要事先就监控项和回滚条件达成一致。
機密データを外部共有するにあたって、匿名化の手順が再現可能であることを確認した。
在对外共享敏感数据时，先确认了匿名化流程是可以复现的。
💡 記憶ポイント：要表达“进入一个重要动作/阶段之际，需要先交代原则、准备或注意事项”时，用「〜にあたって」。如果只是普通的“……时候”，用「〜とき」就够了；如果动作太小、太日常，别硬套这个句型。关键记忆点是：，不是万能的“在……时”。 - 🔐 Silver Ticket：为什么伪造一个服务票据，能直接绕过很多 Windows 横向移动防线
很多人先记住 Kerberos 里最危险的是 Golden Ticket，但现实攻防里，Silver Ticket 往往更安静，也更贴近“已经拿下一台机器后怎么继续扩大权限”这个场景。它的核心不是伪造整套登录身份，而是伪造“某个具体服务愿意接受的票据”。如果攻击者已经拿到了某个服务账户的密钥，比如机器账户、IIS 应用池账户，或者跑 SQL Server 的域账户，他就能自己离线构造一张 TGS（Ticket Granting Service ticket），然后直接去访问这个服务。关键点在于，这张票据不一定要再去找域控签发，所以很多只盯着 DC 日志的检测思路会漏掉它。
为什么会发生？因为 Kerberos 的服务票据本质上是“拿服务自己的密钥加密，证明这个客户端被允许访问你”。服务端收到票据后，只要能用自己的密钥解开，并且里面的字段看起来成立，就可能放行。也就是说，验证动作发生在服务端，而不是每次都回头问域控“这票是真的吗”。这就是 Silver Ticket 的土壤：一旦服务密钥泄露，攻击者就能伪造“发给这个服务看的证明”。它不像 Golden Ticket 那样掌控整个域，但对文件共享、远程管理、MSSQL、HTTP/SPN 绑定服务这些目标已经足够致命。
现实里它常被用在“低噪声横向移动”。比如攻击者先拿下一台服务器的本地管理员，再导出这台机器账户的哈希。接着他可以伪造访问cifs/host的票据去碰 SMB，共享、计划任务、远程服务控制都可能被串起来。如果拿到的是http/或mssqlsvc/这类 SPN 对应账户的密钥，攻击面就会变成 Web 管理后台、数据库服务甚至应用层数据。它可怕的地方不在“理论上能做”，而在于很多环境里服务账户权限本来就配得过大，结果一个服务密钥泄露，后面不只是这个服务出事，而是一串依赖它的资源一起沦陷。
防它不能靠空话。第一，别让服务账户长期复用静态高权限口令，优先用 gMSA 这类自动轮换的托管账户。第二，机器账户和服务账户权限要收紧，别让一个跑业务的账户顺手拥有本地管理员、远程登录或数据库超权。第三，检测上不要只看 TGS-REQ/TGT 申请链路，因为 Silver Ticket 可能根本不经过正常申请；你要盯的是“服务端看到一个 Kerberos 登录，但域控侧没有对应票据签发痕迹”的不一致，还有异常 SPN 访问、伪造票据常见的生命周期和 PAC 特征。第四，一旦怀疑泄露，处理不是“删个会话”就完了，而是必须轮换对应服务账户或机器账户密钥，不然伪造能力还在。
🧪 你在一台 IIS 服务器上发现攻击者导出了运行站点的域服务账户 NTLM/AES 密钥。第二天，域控上几乎没有新的异常票据申请日志，但这台 IIS 后面的 SQL Server 和文件共享却出现了来自该用户身份的 Kerberos 访问。更可能发生了什么？为什么只盯域控日志会漏报？
💡 核心记忆：Silver Ticket 的本质不是“偷到一次登录”，而是“拿到服务密钥后，自己伪造这个服务愿意相信的票据”。 - 🔑 编译器为什么喜欢 SSA 形式
很多人第一次见到 SSA，会觉得它只是编译器内部一种“奇怪写法”：每个变量只能被赋值一次，循环入口还要插一个 φ 函数，看起来比普通代码更绕。问题是，编译器不是为了优雅才这样折腾，它是在给优化开路。因为一旦“一个名字只对应一个定义”，数据从哪里来、流到哪里去，就突然变得非常清楚。你不用再反复猜x现在到底是哪次赋值后的x，而是直接看到x1、x2、x3分别来自哪里，这让常量传播、死代码删除、值范围分析这些优化变得直接得多。
真正关键的不是“单次赋值”这四个字，而是它把“值的身份”和“变量的名字”拆开了。普通代码里，同一个变量名会在不同时间代表不同值；SSA 里，每个名字只代表一个值。如果控制流分叉后又汇合，比如if的两个分支都给x赋了不同结果，那么汇合点就用 φ 函数表达“这里的值取决于你是从哪条边走过来的”。φ 不是运行时真的调用了一个函数，它更像是控制流图上的占位符，告诉编译器：在这个点上，值的来源有多个候选，但每条路径上其实仍然很明确。
这就是为什么 SSA 对优化器特别友好。比如你看到某个y3 = x2 + 1，而x2明明是常量 4，那就能立刻把y3改写成 5；如果后面没人再用y3，这条计算还能被删掉。要是没有 SSA，编译器得先证明中间没有别的赋值悄悄改过x，分析会复杂得多。说白了，SSA 不是让程序跑得更快的魔法，它是让“证明某段代码可以安全优化”这件事变简单了。编译器真正值钱的地方，不是会不会做优化，而是能不能在不改错行为的前提下放心地做优化。
🧪 课后一题：如果一个变量v在if和else两个分支里都被重新赋值，控制流汇合后还要继续使用它，那么在 SSA 里通常为什么需要引入 φ 函数？v
💡 易混淆点：φ 函数不是运行时真正执行的普通函数调用，它只是编译器在中间表示里用来描述“多来源合并”的记号。
