printf大法内核调试
我也是实在没辙了，MPAM通过patch修好后24h2还是起不来，于是决定用printf大法调，记录一下
没辙了
之前启动Windows的时候有EL3炸（EL3 exception循环），后来发现主线启动Linux也炸el3，于是成功修了MPAM，结果还是启动不了
我没调试工具什么jtag trace32啥的统统没有，华为不可能给我一点点文档，我这种折腾也不太可能被一心搞哈摸你的华为认可
我想到了printf大法：做一个哨兵stub，这个stub就直接往串口吐数据。吐什么不重要，有就行，然后把它插到ntoskrnl的各处，依次推断控制流
printf大法自然是万能的：啥玩意都能调，但问题在于我对ARM和逆向的了解和能力就仅仅是hello world的水平，实现这个思路对我来说要有几年的全力投入学习才能做到，对用工作党来说不现实
但好就好在：
AI
DS v4 pro终于发了，我用着最顺手的模型终于可用了，于是火速搭了个harness。经过周末两天实践，发现了一套最合适的操作模式：
- 说出需求让LLM整理出文档
- 让LLM根据文档整理出技术方案
- 根据技术方案拆解任务并执行
基于这个思路设计了我的工作区：
- 先告诉agent已知信息（具体啥毛病）已知尝试 整理成文档
- 输入printf思路，评估思路合理性和细节让ai整理大概的思路-尝试树
- 开始二分找问题
进度
中间绕了一些弯子：
- 一开始ai总试图使用windbg连接到winload的bootdebug调查，但问题出在ntoskrnl，这样做并没卵用。浪费了几个小时和几十M token
- 思路让我讨论到直接在winload插stub，ai试图patch bootmgfw的签名校验，然而并没能成功。最后发现关掉完整性校验flag，然后直接用原版bootmgfw就行
- 找打印stub：一开始我想用PL011串口MMIO直接打印，结果发现并不输出，怀疑是做了内存映射。AI建议的msr/mrs和brk也都不行，全被uefi处理了，没有爆到串口。最终在我要求下AI分析出了一个OEM SMC调用：它会打串口并且包含传入的参数，很完美
现在就开始作为AI的无情的tool来真机上重启跑patched kernel
边肝游戏边做事情，缺点是我的所有二游体力都爆了（理论上我是间隙去对话和执行ai操作，但实际上时间占用很满，导致经常一个本打了半小时）
标点
本文章标点比较自由，因为我平时打字不太喜欢用标点，其他文章里标点基本都是copilot写的，写这篇时copilot不可用（Github炸了）