有提取项目代码到同一个文本文件中再给 LLM 问答使用的场景,但碰到了项目有不同编码的文件导致提取内容部分乱码问题,为解决此问题二开了 SmartCharsetConverter,原项目具体信息可前往主页查看。
LLM 对算法还是相当擅长的,哪怕是没有相关名称符号的情况下,也能精准识别,这给逆向工程带来了相当大的改变。
KCTF 2025 第二道逆向题,直接向三个 LLM(Gemini 2.5 Pro、Deepseek-V3、GPT-5) 提问反编译的功能函数,基本都能分析出实现的是一个三维迷宫,但不太能每次都准确判断出迷宫大小。后尝试,在单次提问中除提供关键反编译代码和数据外,再指出三维迷宫大小,Gemini 2.5 Pro 就直接给出了正确求解 flag 的 python 代码。几个 LLM 共迭代提问 10+ 次,历时 1h 左右即解决此题。
使用 LLM 进行问题解决时,添加一些已进行的确定性分析内容,会有更好的回答效果。
前段时间在一个群里有群友说自己写的 Windows 内核驱动老是莫名蓝屏,不盯着就很突然来一下,看崩溃调用栈,显示错误在使用 PsSetCreateProcessNotifyRoutineEx
注册的进程通知回调函数 CreateNotifyRoutine
中,指向 ExFreePoolWithTag(Msg, msg_tag)
一句,但他使用内核校验器和调试了很久都没排查到哪里有问题。
后面我断续看了两次,比照着自己写的驱动代码,发现判断这应该是个竟态条件(Race Condition)问题,如此也比较符合描述的不稳定蓝屏现象,改了下就正常了。这算是我第一次排查到竟态条件问题,之前只在看相关的漏洞分析利用碰到的多,感觉还是比较有意思的,记录一下。
之前碰到一款安卓旧系统版本的设备,对其有提权调试需求,试了几款 Root 工具感觉不太好用,加上发现设备系统有检测措施会进行相应的保护,于是思路转向了通过 CVE 漏洞对设备进行临时提权。经过一番摸索分析,找到了还没有挂掉的系统 OTA 升级包的下载链接,恢复出来了内核符号表及地址,从而打开突破口,定位到 CVE 提权漏洞需要的符号信息,最后适配编译了 CVE-2015-1805(Pipe Read)、CVE-2015-5195(Ping Pong)和 CVE-2017-8890(Phoenix Talon)三个漏洞利用提权程序,可以成功提权,这里记录一下。
之前分析一款 .net 软件,使用 dnspy 打开一些可执行文件后,发现方法都无法被正常反编译,经对壳代码一些字样进行分析和搜索后,判断是加了德国一款保护软件的 .NET JIT 壳,把函数的方法体指令即 ILCode 都给抽取走了,会在运行时进行解密提供使用。
接着我开始琢磨怎么还原,搜索到 wwh1004 前辈的分析文章《.NET JIT脱壳指南与工具源码》 和相应的开源项目 JitUnpacker-Framework,但经过简单尝试后发现并不能解决我碰到的保护壳类型。
主要因为该保护程序有着较为复杂的保护模块和运行逻辑,无法简单地通过项目工具对单个 .net 可执行文件进行加载解析所有方法,再通过 MethodDesc::DoPrestub
主动调用获取还原需要的信息,因为保护程序模块还没启动起来,其次哪怕能模拟启动起来了,还有一堆检查反调试在等着呢。比如经测试,如果直接调试或者 frida 注入会被检测到,保护程序的授权会立马被注销掉,软件也无法正常运行启动了。
其次的话 JitUnpacker-Framework 项目工具是六年前发布的,支持范围是 .NET 2.0~4.72,.NET 4.8+ 的版本是没有进行适配的。而现在新版 Windows 系统几乎默认安装高版本 4.8+ 的 Framework,并跟随 Windows 系统进行更新升级,可以兼容执行 .NET 4.0+ 的程序,无疑给工具带来不少局限性。
之前使用 angr 的断点功能在执行一个地址时打印出某个寄存器的值,因为默认开启了 vex ir 优化,把寄存器赋值操作给优化没了,所以开始我怎么也获取不到正确的寄存器值,被坑了一把,这里记录一下。
前段时间分析一个使用 Equinox OSGi 框架开发的 Java 桌面 win 应用软件,文件数据结构很是庞杂,有着层层的目录,光 plugins files 目录下的 osgi bundle jar 包都有近 500 个。分析时候发现几个核心 jar 包被加密了,可以看到 class 文件魔数由 CAFEBABE 变为了 CAFEBEBA。本想按常规的 Java 应用逆向思路去找 Java agent、native agent 或者是自定义 ClassLoader 动态解密 class 文件,可以说毫无踪迹、一点影子都没有。
查看 Java jvm 启动配置文件和进程的启动信息,都没有出现 -javaagent:xxx.jar
或者 -agentlib:xxx
的字样。又找了很久没有头绪,甚至怀疑是不是软件魔改了 jvm 动态解密了指定的 class 文件,经简单的调试和文件版本、签名信息确认后也排除了。
更新:2024-11-18
前段时间看到复现分析 GL-iNet 路由器 CVE-2024-39226 漏洞的两篇文章(1 ,2),看完也跟着了分析下,固件仿真过程踩了一些坑,开始我直接用 Ubuntu24 的 qemu-system-arm 跟着操作都会出现错误“Cortex-A9MPCore peripheral can only use Cortex-A9 CPU”,摸索了挺久发现文章用的都是 debian_wheezy_armhf 来仿真,但太老了以至于直接跑 GL-iNet 固件会出现 Illegal instruction 的错误,就使用 Ubuntu18 安装的低版本 qemu-system-arm,能绕过来指定仿真开发板非支持的 cpu,qemu 在高版本中修复了这个问题,就出现了新些版本 Ubuntu 安装的 qemu-system-arm 启动报错问题。
搜 .Net Assembly Diff 工具时候,在 StackOverflow 一个回答中了解到 NDepend 工具,可以试用 14 天,试了下 diff 效果还不错,别的功能也很丰富,下载到的版本是 2024.1.1.9735。
.NET Assembly Diff / Compare Tool - What's available? [closed]
https://stackoverflow.com/questions/1280252/net-assembly-diff-compare-tool-whats-available
将程序断网后点击 Start Evaluation 会进入 NDepend manual server access 流程,自动生成了 Date Request text,到网站可以获取到 Data Response text,输入后即可激活。
程序联网的话,应该是后台直接发起请求验证结果完成激活,对程序断网可以方便分析,并且程序会随时联网发送消息,比如 patch 造成或修改授权造成的运行异常报告,还是给断了好。