Shellcode初探[3x]: 自制实用shellcode加载器，绕过杀软（静态）

上次写这个系列的文章已经过于很长时间了，整个系列也已经歪到研究免杀去了。
本文是对第三篇的补充。

我们之前介绍过：

在第三篇中，我们用了简单的思路：

隐藏了shellcode和IAT中的敏感函数，从而绕过部分杀软。
如果你对基础还不熟悉，可以看看之前的文章。

其实免杀还有一个思路：自制工具。自己做的自己用。

当然啦，+1-1搞个exe还是太弱了。毕竟现在已经是2025年了，那么这种思路真的有任何实用价值吗？
基于上一篇文章的思路，我做了另一个工具。已经做成一个处理脚本放在GitHub上了：

ShellcodeEncrypt2Dll_vs_VT

（现在已经是3/72了）找了一个Win10，Windows Defender静态还能绕过。

自制工具没事别放VT上。这个我自己打算分享出来，放Github上了。被人丢VT上面是迟早的事。

那有小伙伴要问了：“啊，不放VT，还能放哪个上面测试呢？”
免费的antiscan.me已经没了。

用Kleenscan。他们有比较新的杀毒软件引擎。大概40个，他们不会把样本提交。
使用方法类似VT。有免费额度。

我放一个（有他们网站生成的推广链接）
Kleenscan

谈谈ShellcodeEncrypt2DLL

和之前那篇文章思路类似，我们对shellcode和系统函数名的字符串进行了处理。只不过之前是+1-1，我们这次直接用AES进行加密。编译成DLL。~~(别看到DLL就没兴趣关网页了，下面我会解释为什么用DLL)~~

当然这个东西主要还是在针对静态查杀，虽然这样也已经有一点点抗分析能力。

这个项目中的脚本可以生成一个DLL. 其中的shellcode和需要用到的一些函数都被AES加密。可以选择DLL中是否包含KEY。如果选择不包含key的话，你需要在使用时想办法自己传入KEY。

这也意味着如果样本就算被捕获也很难分析出它原本shellcode是什么。

相信我的读者都应该对DLL有一个基本了解了吧？简单说一嘴。比如有一个函数，排序，很多程序都要用。但是每个exe里面都带一个排序代码是不是也太浪费空间了？我们为什么不把它打包进一个二进制文件，然后exe运行的时候直接调用不好吗？这个二进制文件就是DLL.

那么为什么我们要用DLL?

因为exe被针对太狠了。同样的恶意代码，你做成exe在VT上一般情况下都会比DLL被杀得更狠。
DLL具有很强的灵活性。它可以直接用rundll32运行，也可以用一个exe拉起来做sideload。同样，我们还可以用PowerShell，python加载。
我们还可以用hijack的方式劫持正常应用的DLL。
还有像是PrintNightmare这种漏洞利用也要上传恶意DLL

+1-1所做的仅仅只是隐藏。我们之前隐藏了shellcode和函数名称。很好。但是任何一个人如果去逆向了这个程序，很轻松的就会发现+1-1，于是shellcode被逆向。我们不能指望保密算法来保密shellcode。
用AES可以防止shellcode被逆向出来。当然，你就最好把KEY硬编码进去。

我们可以通过很多手段获取KEY。比如，我们在rundll32里面作为参数传进去，或者sidelaod的时候作为参数。
别的加密算法行吗？行。我只是懒。

其实我甚至考虑过比如把shellcode放在DLL里，把key和AES解密算法放进EXE里。运行的时候，exe直接加载DLL获取shellcode和其他被加密的函数名，然后在exe里执行。

后面我有试图去绕过剩下的杀毒软件（随着时间变成了3家）。不过我没有成功。
这三个：Cynet, Kaspersky, Rising。
我用的方法是：在PE的段里填充成0. 比如原来的.text，我直接整个section填充成0.

我试着填充.text和.data，这三家一样报毒，给出的理由都一样。
又试着单独填充了.rdata，这次Kaspersky没报毒了。
填充.idata，这次换rising没报毒。

后面填充过edata，没影响。
总之，kaspersky可能就是觉得.rdata里那些加密的数据可疑。而rising可能觉得导入表是特征。

cynet我就不清楚了。
于是我把idata，rdata都填充掉。
这次这三个都没报毒。但是DeepInstinct报毒了…

头大。可能更好的方案是把这些写进正常的DLL里面吧…

btw 因为我最近疯狂提交到VT测试，有个沙盒说我那个去掉idata, edata的那个版本：
动态规避，HTTP通信，躲沙箱，反调试反分析…

啊？…