-
-
[原创]Stylizer v7.18.904.712 分析
-
发表于:
2019-8-20 18:27
4276
-
[原创]Stylizer v7.18.904.712 分析
Stylizer 是一个比较好用的CSS设计工具,从官网拿到它的最新版本后,发现现存的破解都不可用,所以跟进分析了下它的内容。
在分析之前,看了一下现存的逻辑,都是通过使用破解过的Stylizer.Application.dll替换安装文件后,就可以正常使用了,但是最新的版本,软件安装完后很干净,就两个文件:Stylizer7.exe,uninstall.exe ,这样很明显新版本已经做了更多的保护,越是这样就有分析的欲望了。
先IDA里字符串查找, 并没有找到特别多的信息,复杂的先不深入。
使用x64dbg动态调试下,进行开发信息识别:
好像是用C++开发,所以打算通过CE来定位注册逻辑进行分析,字符查找的时候,确认使用的是UTF-16的。定位到输入的无效Key地址有四个:
使用内存读取断点以后,进行“Authorize",进行调试,断下来,但是发现响应的代码并不在.text段:
000007FE990A0000 0000000000069000 PRV ERW------
这个就有点奇怪了,但是查壳并没有壳信息,所以从这个点回溯去了解启动阶段,从x64dbg进行调试
发现会在函数13FD32E37 Call 13D31230() 触发异常,从IDA中定位去看这个函数:
从函数中的提示信息,可以看到基本的操作过程,简化如上给出的信息。这个有点奇怪,对这个API不熟悉,所以查找了下相关的内容.
比较有用的信息是这个参考:https://www.experts-exchange.com/questions/28909682/C-Loading-Managed-Assembly-From-Memory-in-Unmanaged-Process.html
简单来说,上面的这些API是进行.net的运行时初始化和加载的操作,通过这个方式,可以实现C++ 运行时加载C#开发的APP。
这个就比较有意思了,运行程序没有壳,但是运行的代码在内存其它段中,有可能这个也是使用C++开发的加载器,实现的C#程序是动态加载的,那么这样的话,C#程序在哪儿呢?
查找sub_140001230后,判断应该是在下面的这个阶段能得到C#完整文件信息:
在x64dbg中设计断点,执行到这儿后,获取到v4的值和V22信息:
在内存中转到地址 0x2300040,看到到PE文件特征:
在x64dbg中使用命令 savedata :memdump:, 0x2300040, 0x62A400 进行内存区域DUMP。
在目录...release\x64\memdumps\memdump_37c8_0000000002300040_62a400.bin获取到导出文件,根据分析它应该是一个C#文件,使用dnspy加载。
从结果看,前面的分析都是正确的,而且DUMP出来的文件的资源中,引用了:Stylizer.Application.dll文件。(终于找到它了),在dnspy进行工程导出,在目录中得到了 Stylizer.Application.dll。
从之前的信息,关键的信息应该是在这个文件中,同样使用dnspy进行加载:
从这个结果看,这个文件是做了混淆保护的,这个时候,我好奇之前的补丁是怎么破解的,所以把之前的破解的这次的文件通过dnspy导出成工程后,进行文件对比, 不比不知道,发现这个软件混淆文件名都是确定的:
这样找到破解点应该就比较清楚了。 这样整体分析过程就分析清楚了。
并没有去分析Stylizer.Application.dll,从文件比较,可以确定patch点应该是此处:
1, 需要patch新的DLL文件;
2, 怎么修改Sytlizer7.exe文件;
对于问题1,因为使用了混淆,用dnspy是不行的,需要使用.Net Reflector作字节码编辑。
对于问题2,需要去回溯看看C#文件是的源是哪儿;
在IDA中回溯内存DUMP时的地址,发现是函数(unsigned int)sub_1400028B0(&v18, &Src, v9)处理的;进一步分析:
从上面的信息基本可以看出,应该是把C#文件打包成CAB包后,放置在一个BMP的资源对象中了。
到此分析整理如下:
[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课
最后于 2019-8-29 09:22
被nevinhappy编辑
,原因: