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的资源对象中了。
到此分析整理如下：

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！