OSForensics 9 逆向工程闲谈
2022-4-29 03:0:0 Author: mp.weixin.qq.com(查看原文) 阅读量:14 收藏

创建: 2022-04-27 20:49
http://scz.617.cn:8/misc/202204272049.txt

目录:

    ☆ 背景介绍
    ☆ OSForensics 8.0.1000 受限破解
    ☆ BinDiff得到 OSForensics 9.1.1012 无效破解
    ☆ 遭遇"Code Virtualizer"
    ☆ "Time Travel Debugging" (TTD) vs "Code Virtualizer" (CV)
    ☆ 反"反调试"
        1) x64dbg
            1.1) 修改指定内存的字节流
            1.2) 修改指定内存的字符串
            1.3) 查看内存
            1.4) 反汇编窗口(CPU)光标移到指定地址
            1.5) 查看调用栈回溯
            1.6) 断点命中时修正CIP并继续执行
        2) windbg
    ☆ OSForensics 9.1.1012 凑合破解

☆ 背景介绍

看NTFS ADS时搜到这个

How to view files with NTFS streams
https://www.osforensics.com/faqs-and-tutorials/how-to-view-files-with-ntfs-streams.html

挺喜欢OSForensics的"File System Browser"功能。

https://www.osforensics.com/download.html
https://osforensics.com/downloads/osf.exe

这是款商业软件,有30天受限试用,截至本文写作时最新版是9.1.1012。

☆ OSForensics 8.0.1000 受限破解

https://pan.baidu.com/s/1140djZBPHheqj-75Yl9J-Q
(提取码:aqbk)

之前网上瞎找的,事后发现标题党,版本并不是9.0.1002,而是8.0.1000。二次分发者应该是个祖上缺了大德的,玩这种把戏。

该受限破解版包含原始安装包及用于替换的osf64.exe。官方不再提供8.0.1000版安装包。osf64.exe有108MB,单个PE这么大,相当丧心病狂,后来才明白,这是原厂商为了反逆向工程。

安装完桌面有个快捷方式到此程序

"C:\Program Files\OSForensics\OSForensics.exe"

它只是个loader,根据CPU位数调用osf32.exe或osf64.exe,后二者才是干活的。受限破解版实际替换

C:\Program Files\OSForensics\osf64.exe

未加小木马,就是几处静态Patch

$ fc /b osf64_old.exe osf64_new.exe

0182B98A: E8 90
0182B98B: B1 90
0182B98C: E1 90
0182B98D: FF 90
0182B98E: FF 90
0182BFF6: 84 85
0182C9DA: 0F E9
0182C9DB: 84 D7
0182C9DC: D6 00
0182C9DF: 00 90
018B6497: 75 EB

该受限破解只是表面上将30天试用版变成Pro版,不再弹框提示试用版快到期,但应用该破解后仍然无法使用Pro版才有的功能。我没有仔细测试,不确定是否有暗桩未拔。

☆ BinDiff得到 OSForensics 9.1.1012 无效破解

前面说了,8.0.1000受限破解二次分发者玩了个标题党,写成9.0.1002破解,心想这与9.1.1012离得不远,BinDiff可以快速找出新Patch点。

以前碰上有old版crack,想求new版crack,不一定动用BinDiff。IDA看看old中Patch点附近的特征字符串,若new与old版本接近,很容易定位new中Patch点。但搞osf64时,未能这样简单得手,于是动用BinDiff。也挺烦的,因为osf64非常大,上百兆。

参看

《BinDiff二进制比较简介》
http://scz.617.cn:8/misc/202109131335.txt

先打开9.1.1012的i64,再BinDiff打开8.0.1000的i64,整个过程肉眼可见的耗时,可以扔那儿去干点别的事。由于old与new版本相差较大,BinDiff受限。此外,后来才知道OSForensics动用了"Code Virtualizer",进一步限制了BinDiff。

最后能在new中找到3个Patch点,其中一个动态调试发现无需Patch,其余两个Patch点见下

WinMain

0000000141960B9E 33 C9                       xor     ecx, ecx
/*
 * nop掉
 */

0000000141960BA0 E8 DB E1 FF FF              call    sub_14195ED80
--------------------------------------------------------------------------
sub_1419F55A0

00000001419F55E0 66 305 B5 FC 56 04        cmp     ax, cs:word_145F6529C
/*
 * 将jnz换成无条件跳转jmp
 */

00000001419F55E7 75 1E                       jnz     short loc_1419F5607

应用上述各Patch后直接进OSF主界面,显示Pro版。其实是假Pro版,且有暗桩未拔,使用"File System Browser"时会闪退,x64dbg调试发现有未处理异常抛出。

可能这种破解方案适用于8.0.1000,但绝对不适用于9.1.1012。

需要指出的是,利用BinDiff从旧版破解获取新版破解,是一种通用手段,尽管具体到本例失败了。

☆ 遭遇"Code Virtualizer"

碰上OSForensics之前,我从未遭遇过"Code Virtualizer",没有早早意识到CV的存在,只是觉得OSF挺结实,做了不少反静态分析对抗。事后简单复盘,避免反复踩坑。

OSForensics 9.1.1012可能用CV进行保护,用IDA反汇编osf64.exe验证之。

IDA中Shift-F7,如果看到有".vlizer",很可能用"Code Virtualizer"保护过。IDA中在指定地址处Ctrl-S,若该地址属于".vlizer",表示指定地址位于CV虚拟机中,如既无长期经验积累又无强烈刚需,不建议调试CV虚拟机,弃坑走人为上。或许识别CV有成熟方案,这里只是个人不成熟的经验。

CV处理过OSF后,IDA的Strings窗口很可能找不到某些字符串,"(Pro only)"就是一例。若Strings窗口找不到,最好字节流搜一下,比如

$ python3 -c "import sys,hexdump;print(hexdump.dump(bytes(sys.argv[1],encoding='utf-16')[2:]))" "(Pro only)"
28 00 50 00 72 00 6F 00 20 00 6F 00 6E 00 6C 00 79 00 29 00

在"Hex View"窗口中Alt-B搜索。

下面是网上公开流传过的"Code Virtualizer"逆向工程资料汇集

Inside Code Virtualizer v1.0.1.0 - scherzo <[email protected]gmail.com> [2007-02-16]
https://forum.tuts4you.com/files/file/1933-inside-code-virtualizer-v1010/
https://github.com/lmy375/awesome-vmp/blob/master/note/2007_scherzo_Inside_Code_Virtualizer.pdf
(Inside Code Virtualizer v1.0.1.0.rar)
(SB百度文库还收费)

Code Virtualizer的一点分析和还原 - Ryosuke [2008-04-03]
https://bbs.pediy.com/thread-62447.htm

Code Virtualizer 1.3.8.0小窥 - 朱季峰(neineit) [2010-11-20]
https://bbs.pediy.com/thread-125140.htm

关于Code Virtualizer pcode解密的一种方法 - vasthao [2011-7-16]
https://bbs.pediy.com/thread-137265.htm

DeCV a decompiler for Code Virtualizer by Oreans - pakt [2012-10-03]
https://gdtr.wordpress.com/2012/10/03/decv-a-decompiler-for-code-virtualizer-by-oreans/
https://github.com/pakt/decv
(Decompiler for Code Virtualizer 1.3.8)

Code Virtualizer虚拟机保护初探 - 董阳(robinh00d) [2014-06-09]
https://www.nsfocus.com.cn/upload/contents/2015/03/o_19fepsr5ut2s59f18bt1ejt4psb.pdf

两个OllyDbg插件
VMSweeper
Oreans UnVirtualizer

董阳那篇最有感触,好不容易在网上找到带图版,居然是NSFOCUS技术内刊版。和他聊起后才发现8年前在四楼小会议室里他讲过一遍,于是我又重新看了一遍。

我只是大致看了这批CV资料,并未在OSF逆向工程中实践之,耗不起。

☆ "Time Travel Debugging" (TTD) vs "Code Virtualizer" (CV)

OSF没有考虑到TTD技术的出现,其反调试措施没有针对TTD记录。

参看

《MSDN系列(46)--WinDbg Preview TTD入门》
http://scz.617.cn:8/windows/202201251528.txt
http://scz.617.cn:8/windows/MSDN_46.docx

TTD.exe -out osf64.run -launch osf64.exe
TTD.exe -out osf64.run -attach <pid>
TTD.exe -stop <pid>
TTD.exe -stop all

DbgX.Shell.exe osf64.run
windbgx osf64.run

提醒一句,不需要在OSF所在环境安装"WinDbg Preview",系统很可能自带tttracer,得到.run文件后弄到其他更方便的环境中慢慢鞭尸。

TTD技术用于破解软件确实是个超级利器,属于降维打击,时间维度上的任意操控。但是,OSF有CV技术加持,相当程度抵消了TTD。尽管TTD可以操控时间,但CV让整个时间线呈现出混沌,除非对CV有持续经验积累,否则即使动用TTD,也大大受限。

看过《十三度凶间》的可以类比一下,TTD是最外层的监控者,CV将信息藏到最内层虚拟世界,除非进入最内层世界,否则最外层监控者无法直接获取被藏起来的信息。

OSF经CV加持后,wt这类命令完全陷入混沌,事实上不可用。但TTD可以操控时间,换个角度看,也部分抵消了CV。若对CV有过经验积累,再动用TTD,效果必定杠杠的。

某些调试、测试或静态Patch导致OSF调"USER32!MessageBoxA"弹框,既往经验是看调用栈回溯,向call的低址方向寻找条件跳转指令,对之Patch。但TTD调试OSF时,kpn得不到MessageBoxA的主调位置。用x64dbg动态调试,一样。一度怀疑OSF用到"ntdll!NtContinue"反调试技巧,后来发现,只是利用ret转移过来。此间有个重要经验分享,停在MessageBoxA入口时,用"Step Over Back"会跑飞,回到当前线程的初始阶段,用"Step Out Back"也会跑飞,应该用"Step Into Back"。换句话说,用"p-"、"g-u"跑飞时,换用"t-"试试,或者"!tt"指定值减1。此坑与ret转移强相关,也与CV虚拟机强相关,若目标是普通正经程序,无此坑。

找到了MessageBoxA的主调位置,发现位于CV虚拟机中,无前期积累的情况下未能找到关键分叉点,这就是我说的CV部分抵消了TTD。

☆ 反"反调试"

一般用IDA静态看,并不用IDA动态调,这是个人习惯问题。TTD调试只能鞭尸,验证Patch方案还是得实时动态调试。

cdb.exe -noinh -snul -hd -o osf64.exe

从ibp g之后进程结束,看不到OSF主界面,后来确认OSF有一些反调试机制。

跟bluerust抱怨windbg没有趁手的反"反调试"插件,他推荐了ScyllaHide

https://github.com/x64dbg/ScyllaHide

1) x64dbg

ScyllaHide有现成的x64dbg插件,用"x64dbg+ScyllaHide"反"反调试"成功

https://github.com/x64dbg/x64dbg

下载ScyllaHide后复制相应文件到x64dbg相应目录,启动x64dbg时自动加载相应插件

ScyllaHide\x64dbg\x32\plugins\
x64dbg\x32\plugins\

    HookLibraryx86.dll
    ScyllaHideX64DBGPlugin.dp32
    scylla_hide.ini

ScyllaHide\x64dbg\x64\plugins\
x64dbg\x64\plugins\

    HookLibraryx64.dll
    ScyllaHideX64DBGPlugin.dp64
    scylla_hide.ini

Plugins->ScyllaHide->Options

此处有非常全面的反"反调试"措施,默认用"VMProtect x86/x64"

这是平生第一次用x64dbg,因为不玩破解,正经调试用windbg,x64dbg类似OllyDbg的GUI。按自己调试需求整理《x64dbg速查手册》,最后发现把"x64dbg.chm"遍历一下即可。

分享其中几个小操作

1.1) 修改指定内存的字节流

set r9, #A0#
set r9, #A0 13#
set r9, #A0 13 E4 6A FA FF FF FF#
set r9, #A013E46A#

将r9指向的内存写成指定字节流,可以无空格。该法普适,可修改.text、.data。

1.2) 修改指定内存的字符串

其实上一小节的内容就可以满足需求,但有其他方法。

strset $tmp"foo bar blah blah"
strcpy rdx, $tmp
vardel $tmp

将rdx指向的内存写成指定字符串,该字符串没有结尾的\0,只支持ASCII,不支持UNICODE。strset/strcpy是未公开命令。

上面这种办法太受限了,为了写UNICODE字符串,还是动用set吧。

写UNICODE字符串

$ python3 -c "import sys,hexdump;print(hexdump.dump(bytes(sys.argv[1],encoding='utf-16')[2:],sep=''))" "foo bar blah blah"
66006F006F002000620061007200200062006C0061006800200062006C0061006800

set rdx, #66006F006F002000620061007200200062006C0061006800200062006C0061006800#

写ASCII字符串

$ python3 -c "import sys,hexdump;print(hexdump.dump(bytes(sys.argv[1],encoding='utf-8'),sep=''))" "foo bar blah blah"
666F6F2062617220626C616820626C6168

set rdx, #666F6F2062617220626C616820626C6168#

1.3) 查看内存

不说GUI,命令行法

dump <addr>

1.4) 反汇编窗口(CPU)光标移到指定地址

不说GUI,命令行法

d [addr]

    不指定[addr]时,相当于"d rip",相当于按星号,回到rip

d USER32.DialogBoxParamW
d USER32:DialogBoxParamW

    用点号或冒号分隔模块名与函数名,不用惊叹号分隔,与windbg不同

1.5) 查看调用栈回溯

View->Call Stack (Alt-K)

呼出"Call Stack"窗口,当前线程的"Thread"列高亮显示

缺省是"Active Call Stack Frame",就是常规调用栈回溯算法,若目标PE做过反静态分析处理,这种调用栈回溯很容易中断,看不到主调位置。

"Call Stack"窗口右键菜单->Show Suspected Call Stack Frame

启用"Suspected Call Stack Frame"后会进行启发式调用栈回溯,对付做过反静态分析处理的PE时,颇有奇效。

1.6) 断点命中时修正CIP并继续执行

假设要实现这种效果,断在<addr>时自动跳到<newaddr>继续执行,可能有很多办法达到此目的,其中一种办法是

bp <addr>;bpgoto <addr><newaddr>

bpgoto是针对bp的补充设置,bpgoto不能直接设断,<addr>处断点命中后跳到<newaddr>继续执行,并不会停在<newaddr>。

2) windbg

ScyllaHide没有现成的windbg插件,但ScyllaHide有独立运行版本,理论上可与任意调试器配合使用,实现反"反调试"。

cdb.exe -noinh -snul -hd -o osf64.exe

假设停在ibp,"? @$tpid"获取目标PID,在另一个cmd中执行

"X:\path\ScyllaHide\InjectorCLIx64.exepid:2372 "X:\path\ScyllaHide\HookLibraryx64.dllnowait

成功时会输出

Loaded VA for NtUserBlockInput = 0x00007FFD2FAC7870
Loaded VA for NtUserQueryWindow = 0x00007FFD2FAC1290
Loaded VA for NtUserGetForegroundWindow = 0x00007FFD2FAC1810
Loaded VA for NtUserBuildHwndList = 0x00007FFD2FAC1410
Loaded VA for NtUserFindWindowEx = 0x00007FFD2FAC1E30
Loaded VA for NtUserGetClassName = 0x00007FFD2FAC1FD0
Loaded VA for NtUserInternalGetWindowText = 0x00007FFD2FAC1CD0
Loaded VA for NtUserGetThreadState = 0x00007FFD2FAC1090

PID     : 2372 0x944
DLL Path: X:\path\ScyllaHide\HookLibraryx64.dll

Hook injection successful, image base 0000000000170000

回到cdb的ibp处继续执行,这次OSF没有退出,可以看到GUI。

"X:\path\ScyllaHide\scylla_hide.ini"默认用"VMProtect x86/x64",可以对付绝大多数情况。

更多讨论参看

《让windbg反"反调试"
http://scz.617.cn:8/windows/202204281326.txt

☆ OSForensics 9.1.1012 凑合破解

不打算跟OSF中的CV耗,凑合着搞了个部分破解。

$ fc /b osf64_old.exe osf64_new.exe

0195E776: 7F EB
064BE1ED: 84 85

改2个字节,第一个字节由朱季峰提供,第二字节由scz提供,一人剁一个字节。可以无限试用,我最想用的"File System Browser"部分解锁Pro版功能,未能完全解锁。没有key.dat,OSF绿色化失败,这是厂商故意的。

没有动力与CV磕,投入产出不成比例,就这样吧。


文章来源: http://mp.weixin.qq.com/s?__biz=MzUzMjQyMDE3Ng==&mid=2247485830&idx=1&sn=7386a6ffc903164bb0ffefe38a7d8b7d&chksm=fab2cab9cdc543afdb6c895da00bdba6e6a9f9a3e7fc1e1c6e0e9e70321adf6f4f84a71f8ec1#rd
如有侵权请联系:admin#unsafe.sh