之前碰到一款安卓旧系统版本的设备,对其有提权调试需求,试了几款 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+ 的程序,无疑给工具带来不少局限性。
一老哥使用 LiteSQL2014 在 Windows 11 系统启动数据库服务失败,辗转找到我这里来解决。可以看到点击启动后,运行日志的异常输出为“启动服务 [发生错误]
”和“sqlserver [异常终止]
”,并且伴随一个错误弹窗 “System Error. Code:232. 管道正在被关闭
”。
之前使用 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 造成或修改授权造成的运行异常报告,还是给断了好。
四哥推荐了 Andrea Corbellini 的椭圆曲线加密算法科普系列文章后,在<椭圆曲线加密算法科普系列的作业>和<椭圆曲线加密算法之Sony惨案模拟题>文章中各出了一些作业题目,我花了些时间进行了解答并回复,这里记录一下。
以及,四哥博客文章<椭圆曲线加密算法之Sony惨案模拟题的答案>亦有对我答题的整理。
更新:2025-03-31
在上篇文章《对一个apk协议的继续分析—libsgmain反混淆与逆向》中的调试 trace 一节,我提到了微软的 TTD,即 Time Travel Debugging ,还放了沈沉舟和krash两位前辈的文章。
什么是 TTD 呢,按官网的介绍来说,TTD 是一款用户级进程的 trace 录制工具,录制完成后可以在调试器中向前向后重放,不需要再重新运行程序就能让你的调试器状态回退,并且还能分享你的 trace 文件给别人,从方方面面帮助你更快更轻松找到 bug。
当时我只是通过各种文章了解到 TTD 的相关介绍,但一直没有什么契机和需求,就还没有实操过,甚至 Windbg 也没怎么摸过。直到沈沉舟前辈前段时间在微博上发了一个关于 Windows UWP Calculator 的 puzzle:
Win10 Calculator是UWP程序,找出UI界面上乘法运算对应的汇编指令所在。要求计算器必须是UWP,且版本不低于11.2210.0.0。非UWP计算器不考虑,更低版本UWP不考虑,可以是Win11上的UWP计算器,只要版本不低于11.2210.0.0。
事情是这样的,两三年前在看雪论坛看到一篇帖子《对一个apk的协议分析》,作者 yezheyu 要分析的签名算法是apk调用阿里安全组件 libsgmainso-5.4.56.so 中安全签名类 SecuritySignature 的 sign 方法,虽然最后没有还原算法,但 yezheyu 把十分详尽的分析过程写在了帖子中,提供了十分多的参考价值。
当时也试着动手分析了下,不过功力水平不够, JNI_OnLoad 函数的混淆都没办法能给还原下,分析了一段时间就给搁置了。几年过去了,现在各方面水平尤其是汇编分析能力相比以前熟练精进了不少,又重新试着分析下,总的来说还算比较顺利地分析出来了,没有卡着或者在哪个环节花了很多的时间。