文件头处理
用文本处理工具打开，直接乱码。
用二进制处理工具打开，发现文件头为FF FE，即UNICODE编码中的小端UTF-16。
玩过cmd的都知道，批处理是ANSI的，这个明显是混淆文本查看器的骚操作，所以直接将其改为20（空格），然后就可以用文本处理工具打开了。
获得“单引号”变量值
看着篇幅不小的混淆后的文件，发现第一行后均是变量截取组成的语句，除了第二行，均使用变量“单引号”进行截取，
那么我们获得单引号变量的值，再根据批处理的变量截取原则还原原来的文本，不就大功告成了么？
在第二行前面加上Echo，一运行，直接关机……开机后发现原bat已经变成了CrLf。
估计是作者防止Echo查看语句设计的陷阱，咱可以：
赌5毛，作者调用shutdown而不是wmic执行关机操作。
赌5毛，作者的shutdown后面没有跟拓展名EXE。
赌5毛，作者的shutdown前面没有加%windir%\system32\。
赌5毛，作者使用Echo.>"%~0"来“清空”被修改的bat。
赌5毛，作者在尝试清空被修改的bat没有检测其属性。
众所周知，批处理对外部可执行文件的调用顺序类似普通程序对动态链接库的调用顺序，若不指定绝对路径，则若当前目录下有同名可执行文件，就会直接被调用。
于是，巧猥妙琐的念头诞生了：在批处理同目录下放置一个名为shutdown.bat的空文件。
执行批处理时先给自身加上只读属性。
复制一个新的批出来，加上Echo，跑一下程序，果然尝试写入自身时报“拒绝访问”错，关机小功能也被削了。
在第二行的每个&的后面也加上Echo，成功获得了单引号变量的值，写出vbs尝试还原，仍然得到了一堆乱码。
看着乱码，lz陷入疑惑之中，进而陷入对自己vbs的怀疑之中，是我写的程序出bug了么？
进过多次排查，确信lz的vbs代码没有毛病，重新观察“乱码”后，发现第三行出现了几个批处理语句。
lz突然醒悟，单引号变量是一个变量啊，作者难道不能在下文中将其改掉么？
看着非人可读的结果，lz不禁陷入深深的蛋疼之中，感受到了这个加密批的本质：体力活。
正在考虑要不要按顺序强行分析之时，突然灵机一动，既然这个代码可以执行，cmd必然会帮忙修改、展开单引号变量，那么我们为什么不可以直接获取这个变量呢？
于是去掉所有Echo，在各行之间加上语句“Set '&Pause”，跑起批，果然单引号变量的值变化了若干次，但是lz注意到，在开始执行真实批处理语句后，单引号变量的值不再改变了。
于是lz就成功拿到了最后的单引号变量的值，可以用这个值配合脚本快速还原出源代码。（用法自悟）- var = InputBox("")
- Const ForReading = 1
- Dim fso
- Set fso = CreateObject("Scripting.FileSystemObject")
- text = fso.OpenTextFile(WScript.Arguments(0),ForReading).ReadAll
-
- For i = 1 To Len(var)
-
- text=Replace(text,"%':~"&i-1&",1%",Mid(var,i,1))
-
- text=Replace(text,"%':~-"&Len(var)-i+1&",1%",Mid(var,i,1))
- Next
- WScript.Echo text
其它
通过模拟CMD执行和变量展开进行无手工操作直接解密将会在以后详细分析。实现可以看PCL斑竹的硬核代码。
直接调试CMD来获取单引号变量来解密的方法也会在以后详细分析。 | 
发表于 2019-3-17 22:17
|