自动重构Meterpreter绕过杀软
前言
此文章记录了我们对杀毒软件某些方面的研究，以及我们如何设法自动重构Meterpreter以绕过我们所遇到的每个AV / EDR。 虽然下面详细介绍了每种技术的思想和字符串混淆过程的实现，但我们决定在以后的文章中发布有关API导入隐藏/系统调用重写的详细信息，以使此内容尽可能简短。 源代码位于https://github.com/scrt/avcleaner
大多数公司通常采取防御措施来保护其信息系统免受攻击，在这些措施中，杀毒软件或EDR等安全软件通常是必不可少的工具集。尽管过去几年来绕过任何类型的恶意软件检测机制非常容易，但如今这样做无疑需要付出更多的努力。
另一方面，在POC本身被反病毒软件阻止的情况下，与漏洞相关的风险交流变得更具有挑战性。尽管理论上可以说有可能绕过检测并保留它，但实际上这样做可能会增加强度。
鉴于此，需要能够绕过杀毒软件。使事情稍微复杂化的是，在SCRT，我们尽可能地使用公开可用的开源代码工具，以展示我们的工作可以被任何熟练使用它们的人复制，并且不依赖于昂贵的私人工具。
问题现状
现在的社区通常喜欢将任何防病毒的检测机制归类为静态或动态。通常，如果在恶意软件执行之前触发了检测，则将其视为一种静态检测。但是，值得一提的是，杀软也可以在恶意软件执行期间调用静态检测机制（例如签名），以响应诸如进程创建，内存中文件下载等事件。无论如何，如果我们想对任何类型的安全软件使用旧的Meterpreter，我们都必须对其进行修改，使其满足以下要求：
在文件系统扫描或内存扫描时，绕过任何静态签名。绕过“行为检测”，这种行为通常与绕过用户界面API hooking有关。
但是，Meterpreter包含几个模块，整个代码库总计约700’000行代码。此外，它会不断更新，这意味着运行项目的私有分支肯定会导致扩展性很差。简而言之，我们需要一种自动转换代码库的方法。
解决方案
经过多年绕过防病毒软件的实际经验，我们发现恶意软件检测几乎都是基于字符串，API hooks或两者的结合。
即使对于实施机器学习分类的产品（例如Cylance），一个没有字符串，API导入和可挂钩API调用的恶意软件也可以像足球射门一样穿过Sergio Rico的防御网络。
Meterpreter具有成千上万个字符串，不会以任何方式隐藏API导入，并且可以使用用户界面API hook轻松拦截敏感的API，例如WriteProcessMemory。 因此，我们需要以自动化的方式对此进行补救，这将产生两个潜在的解决方案：
源到源代码重构LLVM在编译时混淆代码库。
显然，后者将是首选方法，这是许多流行的研究得出相同的结论。 主要原因是，转换遍历可以只编写一次，而可以独立于软件的编程语言或目标体系结构重复使用。
但是，这样做需要有用Visual Studio以外的编译器编译Meterpreter的能力。尽管我们已于2018年12月发布了一些更改工作，但在一年多之后，正式代码库的采用仍然是一个需要持续的过程。
同时，我们已决定不顾一切成本的实施第一种方法。在对源代码重构的最新技术进行了彻底的回顾之后，libTooling（Clang / LLVM工具链的一部分）似乎是解析C / C ++源代码并对其进行修改的唯一可行的选择。
注意：由于代码库高度依赖Visual Studio，因此Clang无法解析Metepreter的很大一部分。但是，仍然有可能以一半的概率绕过目标防病毒软件。在这里，我们可能遇到源到源转换相对于编译时转换的唯一优势：那就是编译时转换要求整个项目进行编译而没有任何错误。而源到源转换可以允许成千上万的编译错误。而你只会得到一个不完整的抽象语法树，这非常好。
字符串混淆
在C / C ++中，字符串可能位于许多不同的上下文中。 libTooling并不是一个足够好的工具，因此我们应用了帕雷托法则（也即二八定律），将研究范围限制在Meterpreter代码库中最可疑的字符串出现的代码上：
函数参数列表初始化
函数参数
例如，我们知道，在以下情况下，ESET Nod32将标记字符串ntdll为可疑：
ntdll = LoadLibrary(TEXT("ntdll"))
但是，用以下方式重写此代码段将成功绕过检测：
wchar_t ntdll_str[] = {'n','t','d','l','l',0};
ntdll = LoadLibrary(ntdll_str)
在看不见的幕后，第一个代码片段使字符串ntdll存储在生成的二进制文件的.rdata段内，并且防病毒程序很容易发现该字符串。 第二个片段是字符串在运行时存储在堆栈中，并且在通常情况下与代码在静态上无法区分。 IDA Pro或替代产品通常能够识别字符串，但它们也需要对二进制文件运行更高级且计算量更大的分析。
列表初始化
在Meterpreter的代码库中，可以在几个文件中找到这种构造，例如在c/meterpreter/source/extensions/extapi/extapi.c 中：
Command customCommands[] =
{
COMMAND_REQ("extapi_window_enum", request_window_enum),
COMMAND_REQ("extapi_service_enum", request_service_enum),
COMMAND_REQ("extapi_service_query", request_service_query),
COMMAND_REQ("extapi_service_control", request_service_control),
COMMAND_REQ("extapi_clipboard_get_data", request_clipboard_get_data),
COMMAND_REQ("extapi_clipboard_set_data", request_clipboard_set_data),
COMMAND_REQ("extapi_clipboard_monitor_start", request_clipboard_monitor_start),
COMMAND_REQ("extapi_clipboard_monitor_pause", request_clipboard_monitor_pause),
COMMAND_REQ("extapi_clipboard_monitor_resume", request_clipboard_monitor_resume),
COMMAND_REQ("extapi_clipboard_monitor_purge", request_clipboard_monitor_purge),
COMMAND_REQ("extapi_clipboard_monitor_stop", request_clipboard_monitor_stop),
COMMAND_REQ("extapi_clipboard_monitor_dump", request_clipboard_monitor_dump),
COMMAND_REQ("extapi_adsi_domain_query", request_adsi_domain_query),
COMMAND_REQ("extapi_ntds_parse", ntds_parse),
COMMAND_REQ("extapi_wmi_query", request_wmi_query),
COMMAND_REQ("extapi_pageant_send_query", request_pageant_send_query),
...
}
这些字符串以明文形式存储在ext_server_espia.x64.dll的.rdata节中，并由ESET Nod32进行选择。
更糟糕的是，这些字符串是位于列表初始化程序中的宏的参数。 这引入了很多棘手的案例，但这些案例并不需要关心。我们的目的是自动重写此代码段，如下所示：
char hid_extapi_UQOoNXigAPq4[] = {'e','x','t','a','p','i','_','w','i','n','d','o','w','_','e','n','u','m',0};
char hid_extapi_vhFHmZ8u2hfz[] = {'e','x','t','a','p','i','_','s','e','r','v','i','c','e','_','e','n','u','m',0};
char hid_extapi_pW25eeIGBeru[] = {'e','x','t','a','p','i','_','s','e','r','v','i','c','e','_','q','u','e','r','y'
0};
char hid_extapi_S4Ws57MYBjib[] = {'e','x','t','a','p','i','_','s','e','r','v','i','c','e','_','c','o','n','t','r'
'o','l',0};
char hid_extapi_HJ0lD9Dl56A4[] = {'e','x','t','a','p','i','_','c','l','i','p','b','o','a','r','d','_','g','e','t'
'_','d','a','t','a',0};
char hid_extapi_IiEzXils3UsR[] = {'e','x','t','a','p','i','_','c','l','i','p','b','o','a','r','d','_','s','e','t'
'_','d','a','t','a',0};
char hid_extapi_czLOBo0HcqCP[] = {'e','x','t','a','p','i','_','c','l','i','p','b','o','a','r','d','_','m','o','n'
'i','t','o','r','_','s','t','a','r','t',0};
char hid_extapi_WcWbTrsQujiT[] = {'e','x','t','a','p','i','_','c','l','i','p','b','o','a','r','d','_','m','o','n'
'i','t','o','r','_','p','a','u','s','e',0};
char hid_extapi_rPiFTZW4ShwA[] = {'e','x','t','a','p','i','_','c','l','i','p','b','o','a','r','d','_','m','o','n'
'i','t','o','r','_','r','e','s','u','m','e',0};
char hid_extapi_05fAoaZLqOoy[] = {'e','x','t','a','p','i','_','c','l','i','p','b','o','a','r','d','_','m','o','n'
'i','t','o','r','_','p','u','r','g','e',0};
char hid_extapi_cOOyHTPTvZGK[] = {'e','x','t','a','p','i','_','c','l','i','p','b','o','a','r','d','_','m','o','n','i','t','o','r','_','s','t','o','p',0};
char hid_extapi_smtmvW05cI9y[] = {'e','x','t','a','p','i','_','c','l','i','p','b','o','a','r','d','_','m','o','n','i','t','o','r','_','d','u','m','p',0};
char hid_extapi_01kuYCM8z49k[] = {'e','x','t','a','p','i','_','a','d','s','i','_','d','o','m','a','i','n','_','q','u','e','r','y',0};
char hid_extapi_SMK9uFj6nThk[] = {'e','x','t','a','p','i','_','n','t','d','s','_','p','a','r','s','e',0};
char hid_extapi_PHxnGM7M0609[] = {'e','x','t','a','p','i','_','w','m','i','_','q','u','e','r','y',0};
char hid_extapi_J7EGS6FRHwkV[] = {'e','x','t','a','p','i','_','p','a','g','e','a','n','t','_','s','e','n','d','_','q','u','e','r','y',0};
Command customCommands[] =
{
COMMAND_REQ(hid_extapi_UQOoNXigAPq4, request_window_enum),
COMMAND_REQ(hid_extapi_vhFHmZ8u2hfz, request_service_enum),
COMMAND_REQ(hid_extapi_pW25eeIGBeru, request_service_query),
COMMAND_REQ(hid_extapi_S4Ws57MYBjib, request_service_control),
COMMAND_REQ(hid_extapi_HJ0lD9Dl56A4, request_clipboard_get_data),
COMMAND_REQ(hid_extapi_IiEzXils3UsR, request_clipboard_set_data),
COMMAND_REQ(hid_extapi_czLOBo0HcqCP, request_clipboard_monitor_start),
COMMAND_REQ(hid_extapi_WcWbTrsQujiT, request_clipboard_monitor_pause),
COMMAND_REQ(hid_extapi_rPiFTZW4ShwA, request_clipboard_monitor_resume),
COMMAND_REQ(hid_extapi_05fAoaZLqOoy, request_clipboard_monitor_purge),
COMMAND_REQ(hid_extapi_cOOyHTPTvZGK, request_clipboard_monitor_stop),
COMMAND_REQ(hid_extapi_smtmvW05cI9y, request_clipboard_monitor_dump),
COMMAND_REQ(hid_extapi_01kuYCM8z49k, request_adsi_domain_query),
COMMAND_REQ(hid_extapi_SMK9uFj6nThk, ntds_parse),
COMMAND_REQ(hid_extapi_PHxnGM7M0609, request_wmi_query),
COMMAND_REQ(hid_extapi_J7EGS6FRHwkV, request_pageant_send_query),
COMMAND_TERMINATOR
};
隐藏API导入
调用由外部库导出的函数会使链接器向导入地址表(IAT)写入一个条目。 最终函数名称将在二进制文件中以明文形式显示，因此在无需执行恶意文件的情况下，可以静态恢复函数名。 当然，有些函数名称相比其他名称更可疑。 一个更明智的做法是隐藏所有可疑二进制文件，同时，保留大多数合法二进制文件中存在的文件。
例如，在Metepreter的kiwi扩展中，可以找到以下行：
enumStatus = SamEnumerateUsersInDomain(hDomain, &EnumerationContext, 0, &pEnumBuffer, 100, &CountRetourned);
该函数由samlib.dll导出，因此链接器会使字符串samlib.dll和SamEnumerateUsersInDomain出现在已编译的二进制文件中。
要解决此问题，可以在运行时使用LoadLibrary/GetProcAddresss导入API。当然，这两个函数都适用于字符串，因此也必须对其进行混淆。 因此，我们希望按如下所示自动重写上述代码段：
typedef NTSTATUS(__stdcall* _SamEnumerateUsersInDomain)(
SAMPR_HANDLE DomainHandle,
PDword EnumerationContext,
DWORD UserAccountControl,
PSAMPR_RID_ENUMERATION* Buffer,
DWORD PreferedMaximumLength,
PDWORD CountReturned
);
char hid_SAMLIB_01zmejmkLCHt[] = {'S','A','M','L','I','B','.','D','L','L',0};
char hid_SamEnu_BZxlW5ZBUAAe[] = {'S','a','m','E','n','u','m','e','r','a','t','e','U','s','e','r','s','I','n','D','o','m','a','i','n',0};
HANDLE hhid_SAMLIB_BZUriyLrlgrJ = LoadLibrary(hid_SAMLIB_01zmejmkLCHt);
_SamEnumerateUsersInDomain ffSamEnumerateUsersInDoma =(_SamEnumerateUsersInDomain)GetProcAddress(hhid_SAMLIB_BZUriyLrlgrJ, hid_SamEnu_BZxlW5ZBUAAe);
enumStatus = ffSamEnumerateUsersInDoma(hDomain, &EnumerationContext, 0, &pEnumBuffer, 100, &CountRetourned);
Rewriting syscalls
重写系统调用
默认情况下，在运行Cylance的计算机上使用Meterpreter的migration命令会触发杀软检测（请谨慎）。 Cylance会使用用户界面hook检测进程注入。 为了避开检测，可以去掉hook，这似乎是现在的主流趋势，或者可以完全避免使用hook。 我们发现，读取ntdll，恢复系统调用号并将其插入随时可以调用的Shellcode中更为简单，这可以有效地绕过任何杀软用户区的钩子。 迄今为止，我们尚未找到可以将从磁盘读取的NTDLL.DLL的行为识别为可疑的蓝队。
实现
上述所有想法都可以在基于libtools的源代码重构工具中实现。本节说明我们是如何做到这一点的，这是在时间和耐心之间的妥协。因为缺少libtools文档，所以此处还有改进的空间，如果你发现了什么，那可能是我们希望得到的反馈。
抽象语法树101
编译器通常包括几个组件，最常见的是解析器和词法分析器。 当将源代码提供给编译器时，它首先从原始源代码（程序员编写的代码）中生成一个解析树，然后将语义信息添加到节点（编译器真正需要的）。 此步骤的结果称为抽象语法树。 维基百科展示了以下示例：
while b ≠ 0
if a > b
a := a − b
else
b := b − a
return a
这个小程序的典型AST如下所示：
在编写需要理解其他程序属性的程序时，这个数据结构允许使用更精确的算法，因此执行大规模代码重构是一个不错的选择。
Clang的抽象语法树
由于我们需要正确修改源代码，因此我们需要熟悉Clang的AST。 好消息是Clang公开了一个命令行开关，以漂亮的颜色转储AST。 坏消息是，对于除”玩具项目”以外的所有项目，设置正确的编译器标志都非常棘手。
现在，让我们做一个现实而简单的翻译测试单元:
#include <windows.h>
typedef NTSTATUS (NTAPI *f_NtMapViewOfSection)(HANDLE, HANDLE, PVOID *, ULONG, ULONG,
PLARGE_INTEGER, PULONG, ULONG, ULONG, ULONG);
int main(void)
{
f_NtMapViewOfSection lNtMapViewOfSection;
HMODULE ntdll;
if (!(ntdll = LoadLibrary(TEXT("ntdll"))))
{
return -1;
}
lNtMapViewOfSection = (f_NtMapViewOfSection)GetProcAddress(ntdll, "NtMapViewOfSection");
lNtMapViewOfSection(0,0,0,0,0,0,0,0,0,0);
return 0;
}
然后，将以下脚本插入.sh文件中：
WIN_INCLUDE="/Users/vladimir/headers/winsdk"
CLANG_PATH="/usr/local/Cellar/llvm/9.0.1"#"/usr/lib/clang/8.0.1/"
clang -cc1 -ast-dump "$1" -D "_WIN64" -D "_UNICODE" -D "UNICODE" -D "_WINSOCK_DEPRECATED_NO_WARNINGS"
"-I" "$CLANG_PATH/include"
"-I" "$CLANG_PATH"
"-I" "$WIN_INCLUDE/Include/msvc-14.15.26726-include"
"-I" "$WIN_INCLUDE/Include/10.0.17134.0/ucrt"
"-I" "$WIN_INCLUDE/Include/10.0.17134.0/shared"
"-I" "$WIN_INCLUDE/Include/10.0.17134.0/um"
"-I" "$WIN_INCLUDE/Include/10.0.17134.0/winrt"
"-fdeprecated-macro"
"-w"
"-fdebug-compilation-dir"
"-fno-use-cxa-atexit" "-fms-extensions" "-fms-compatibility"
"-fms-compatibility-version=19.15.26726" "-std=c++14" "-fdelayed-template-parsing" "-fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions" "-fseh-exceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-x" "c++"
请注意，WIN_INCLUDE指向一个文件夹，其中包含与Win32 API进行交互的所有必需的标头。 这些是从标准Windows 10安装中直接获取的，为了避免让你头疼，我们建议你执行相同操作，千万不要选择MinGW。 然后，以需要测试的C文件作为参数来调用脚本。 虽然这会产生一个18MB的文件，但通过搜索我们定义的字符串之一（例如“ NtMapViewOfSection”），可以轻松导航到AST的有趣部分：
现在，我们有了一种可视化AST的方法，可以更轻易地了解如何更新节点才能获得结果，同时不在结果源代码中引入任何语法错误。 以下各节包含与使用libTooling进行AST操作有关实现的详细信息。
ClangTool样板
在进入有趣的内容之前，需要一些样板代码，因此需要将以下代码插入main.cpp中：
#include "clang/AST/ASTConsumer.h"
#include "clang/AST/ASTContext.h"
#include "clang/AST/Decl.h"
#include "clang/AST/Type.h"
#include "clang/ASTMatchers/ASTMatchFinder.h"
#include "clang/ASTMatchers/ASTMatchers.h"
#include "clang/Basic/SourceManager.h"
#include "clang/Frontend/CompilerInstance.h"
#include "clang/Frontend/FrontendAction.h"
#include "clang/Tooling/CommonOptionsParser.h"
#include "clang/Tooling/Tooling.h"
#include "clang/Rewrite/Core/Rewriter.h"
// LLVM includes
#include "llvm/ADT/ArrayRef.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/Support/CommandLine.h"
#include "llvm/Support/raw_ostream.h"
#include "Consumer.h"
#include "MatchHandler.h"
#include <IOStream>
#include <memory>
#include <string>
#include <vector>
#include <fstream>
#include <clang/Tooling/Inclusions/IncludeStyle.h>
#include <clang/Tooling/Inclusions/HeaderIncludes.h>
#include <sstream>
namespace ClSetup {
llvm::cl::OptionCategory ToolCategory("StringEncryptor");
}
namespace StringEncryptor {
clang::Rewriter ASTRewriter;
class Action : public clang::ASTFrontendAction {
public:
using ASTConsumerPointer = std::unique_ptr<clang::ASTConsumer>;
ASTConsumerPointer CreateASTConsumer(clang::CompilerInstance &Compiler,
llvm::StringRef Filename) override {
ASTRewriter.setSourceMgr(Compiler.getSourceManager(), Compiler.getLangOpts());
std::vector<ASTConsumer*> consumers;
consumers.push_back(&StringConsumer);
// several passes can be combined together by adding them to `consumers`
auto TheConsumer = llvm::make_unique<Consumer>();
TheConsumer->consumers = consumers;
return TheConsumer;
}
bool BeginSourceFileAction(clang::CompilerInstance &Compiler) override {
llvm::outs() << "Processing file " << 'n';
return true;
}
void EndSourceFileAction() override {
clang::SourceManager &SM = ASTRewriter.getSourceMgr();
std::string FileName = SM.getFileEntryForID(SM.getMainFileID())->getName();
llvm::errs() << "** EndSourceFileAction for: " << FileName << "n";
// Now emit the rewritten buffer.
llvm::errs() << "Here is the edited source file :nn";
std::string TypeS;
llvm::raw_string_ostream s(TypeS);
auto FileID = SM.getMainFileID();
auto ReWriteBuffer = ASTRewriter.getRewriteBufferFor(FileID);
if(ReWriteBuffer != nullptr)
ReWriteBuffer->write((s));
else{
llvm::errs() << "File was not modifiedn";
return;
}
std::string result = s.str();
std::ofstream fo(FileName);
if(fo.is_open())
fo << result;
else
llvm::errs() << "[!] Error saving result to " << FileName << "n";
}
};
}
auto main(int argc, const char *argv[]) -> int {
using namespace clang::tooling;
using namespace ClSetup;
CommonOptionsParser OptionsParser(argc, argv, ToolCategory);
ClangTool Tool(OptionsParser.getCompilations(),
OptionsParser.getSourcePathList());
auto Action = newFrontendActionFactory<StringEncryptor::Action>();
return Tool.run(Action.get());
}
由于该样板代码取自官方文档中的示例，因此不需要再进一步的描述。 唯一值得一提的修改是在CreateASTConsumer的内部。 我们的最终目标是在同一个翻译单元上进行多次转换。 可以通过将项目添加到集合中来完成（基本行是consumers.push_back(&...);）。
字符串混淆
本节描述有关字符串混淆过程的最重要的实现细节，包括三个步骤：
在源代码中找到字符串。用变量替换它们在适当的位置（包含函数或全局上下文中）插入变量定义/赋值。
在源代码中查找字符串文字
可以如下定义StringConsumer（在StringEncryptor命名空间的开头）：
class StringEncryptionConsumer : public clang::ASTConsumer {
public:
void HandleTranslationUnit(clang::ASTContext &Context) override {
using namespace clang::ast_matchers;
using namespace StringEncryptor;
llvm::outs() << "[StringEncryption] Registering ASTMatcher...n";
MatchFinder Finder;
MatchHandler Handler(&ASTRewriter);
const auto Matcher = stringLiteral().bind("decl");
Finder.addMatcher(Matcher, &Handler);
Finder.matchAST(Context);
}
};
StringEncryptionConsumer StringConsumer = StringEncryptionConsumer();
给定一个翻译单元，我们可以告诉Clang在AST中找到一个模式，同时注册一个“处理程序”以在找到匹配项时调用。 Clang的ASTMatcher公开的模式匹配功能非常强大，但在这里并未得到充分利用，因为我们仅是用它来定位字符串。
然后，我们可以通过实现MatchHandler来解决问题，它将为我们提供MatchResult实例。 MatchResult包含对标识的AST节点的引用以及上下文信息。
接下来我们可以实现一个类的定义，并从clang::ast_matchers::MatchFinder::MatchCallback:继承一些东西：
#ifndef AVCLEANER_MATCHHANDLER_H
#define AVCLEANER_MATCHHANDLER_H
#include <vector>
#include <string>
#include <memory>
#include "llvm/Support/raw_ostream.h"
#include "llvm/Support/CommandLine.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/ADT/ArrayRef.h"
#include "clang/Rewrite/Core/Rewriter.h"
#include "clang/Tooling/Tooling.h"
#include "clang/Tooling/CommonOptionsParser.h"
#include "clang/Frontend/FrontendAction.h"
#include "clang/Frontend/CompilerInstance.h"
#include "clang/Basic/SourceManager.h"
#include "clang/ASTMatchers/ASTMatchers.h"
#include "clang/ASTMatchers/ASTMatchFinder.h"
#include "clang/AST/Type.h"
#include "clang/AST/Decl.h"
#include "clang/AST/ASTContext.h"
#include "clang/AST/ASTConsumer.h"
#include "MatchHandler.h"
class MatchHandler : public clang::ast_matchers::MatchFinder::MatchCallback {
public:
using MatchResult = clang::ast_matchers::MatchFinder::MatchResult;
MatchHandler(clang::Rewriter *rewriter);
void run(const MatchResult &Result) override; // callback function that runs whenever a Match is found.
};
#endif //AVCLEANER_MATCHHANDLER_H
在MatchHandler.cpp中，我们必须实现MatchHandler的构造函数和run回调函数。 构造函数非常简单，仅仅只需要存储 clang::Rewrite的实例以供以后使用即可：
using namespace clang;
MatchHandler::MatchHandler(clang::Rewriter *rewriter) {
this->ASTRewriter = rewriter;
}
run的实现如下所示：
void MatchHandler::run(const MatchResult &Result) {
const auto *Decl = Result.Nodes.getNodeAs<clang::StringLiteral>("decl");
clang::SourceManager &SM = ASTRewriter->getSourceMgr();
// skip strings in included headers
if (!SM.isInMainFile(Decl->getBeginLoc()))
return;
// strings that comprise less than 5 characters are not worth the effort
if (!Decl->getBytes().str().size() > 4) {
return;
}
climbParentsIgnoreCast(*Decl, clang::ast_type_traits::DynTypedNode(), Result.Context, 0);
}
上面摘录的三段代码中有三个点值得一提：
我们提取与StringEncryptionConsumer中定义的模式匹配的AST节点。为此，可以调用函数getNodeAs，它需要一个字符串作为参数，该参数与模式绑定的标识符相关（请参见const auto Matcher = stringLiteral().bind("decl")行）我们会跳过分析中没有在翻译单元中定义的字符串。实际上，我们的过程会在Clang的预处理程序之后进行干预，它会将包含的系统头的内容复制粘贴到翻译单元中。然后，我们准备处理字符串。 由于我们需要在上下文中找到此字符串，因此需将提取的节点沿着Result.Context传递给用户定义的函数（在本例中为climbParentsIgnoreCast，因为缺少更好的名称），其中包含一个 参考随附的AST。 目标是向上访问树，直到找到有趣的节点。 在这种情况下，我们对CallExpr类型的节点感兴趣。
bool
MatchHandler::climbParentsIgnoreCast(const StringLiteral &NodeString, clang::ast_type_traits::DynTypedNode node,
clang::ASTContext *const pContext, uint64_t iterations) {
ASTContext::DynTypedNodeList parents = pContext->getParents(NodeString);
if (iterations > 0) {
parents = pContext->getParents(node);
}
for (const auto &parent : parents) {
StringRef ParentNodeKind = parent.getNodeKind().asStringRef();
if (ParentNodeKind.find("Cast") != std::string::npos) {
return climbParentsIgnoreCast(NodeString, parent, pContext, ++iterations);
}
handleStringInContext(&NodeString, pContext, parent);
}
return false;
}
简而言之，此函数以递归方式查找StringLiteral节点的父节点，直到找到一个有趣的节点（非“ cast”）。 handleStringInContext也很简单：
void MatchHandler::handleStringInContext(const clang::StringLiteral *pLiteral, clang::ASTContext *const pContext,
const clang::ast_type_traits::DynTypedNode node) {
StringRef ParentNodeKind = node.getNodeKind().asStringRef();
if (ParentNodeKind.compare("CallExpr") == 0) {
handleCallExpr(pLiteral, pContext, node);
} else if (ParentNodeKind.compare("InitListExpr") == 0) {
handleInitListExpr(pLiteral, pContext, node);
} else {
llvm::outs() << "Unhandled context " << ParentNodeKind << " for string " << pLiteral->getBytes() << "n";
}
}
从上面的代码片段可以明显看出，实际上只有两种类型的节点可以处理。 如果需要，添加更多内容也应该很容易。 事实上，这两种情况都已经用类似的方式处理。
void MatchHandler::handleCallExpr(const clang::StringLiteral *pLiteral, clang::ASTContext *const pContext,
const clang::ast_type_traits::DynTypedNode node) {
const auto *FunctionCall = node.get<clang::CallExpr>();
if (isBlacklistedFunction(FunctionCall)) {
return; // exclude printf-like functions when the replacement is not constant anymore (C89 standard...).
}
handleExpr(pLiteral, pContext, node);
}
void MatchHandler::handleInitListExpr(const clang::StringLiteral *pLiteral, clang::ASTContext *const pContext,
const clang::ast_type_traits::DynTypedNode node) {
handleExpr(pLiteral, pContext, node);
}
替换字符串
由于CallExpr和InitListExpr都可以用类似的方式处理，因此我们定义了一个公共的可用函数。
bool MatchHandler::handleExpr(const clang::StringLiteral *pLiteral, clang::ASTContext *const pContext,
const clang::ast_type_traits::DynTypedNode node) {
clang::SourceRange LiteralRange = clang::SourceRange(
ASTRewriter->getSourceMgr().getFileLoc(pLiteral->getBeginLoc()),
ASTRewriter->getSourceMgr().getFileLoc(pLiteral->getEndLoc())
);
if(shouldAbort(pLiteral, pContext, LiteralRange))
return false;
std::string Replacement = translateStringToIdentifier(pLiteral->getBytes().str());
if(!insertVariableDeclaration(pLiteral, pContext, LiteralRange, Replacement))
return false ;
Globs::PatchedSourceLocation.push_back(LiteralRange);
return replaceStringLiteral(pLiteral, pContext, LiteralRange, Replacement);
}
我们随机生成一个变量名。在最近的位置找到一些空白空间，然后插入变量声明。 这基本上是一个ASTRewriter->InsertText()的包装将字符串替换为在步骤1中生成的标识符将字符串所在位置添加到集合中。 这很有用，因为在访问InitListExpr时，相同的字符串将出现两次（不知道为什么）。
最后一步是真正难以实现的一步，因此让我们首先关注这一点：
bool MatchHandler::replaceStringLiteral(const clang::StringLiteral *pLiteral, clang::ASTContext *const pContext,
clang::SourceRange LiteralRange,
const std::string& Replacement) {
// handle "TEXT" macro argument, for instance LoadLibrary(TEXT("ntdll"));
bool isMacro = ASTRewriter->getSourceMgr().isMacroBodyExpansion(pLiteral->getBeginLoc());
if (isMacro) {
StringRef OrigText = clang::Lexer::getSourceText(CharSourceRange(pLiteral->getSourceRange(), true),
pContext->getSourceManager(), pContext->getLangOpts());
// weird bug with TEXT Macro / other macros...there must be a proper way to do this.
if (OrigText.find("TEXT") != std::string::npos) {
ASTRewriter->RemoveText(LiteralRange);
LiteralRange.setEnd(ASTRewriter->getSourceMgr().getFileLoc(pLiteral->getEndLoc().getLocWithOffset(-1)));
}
}
return ASTRewriter->ReplaceText(LiteralRange, Replacement);
}
通常情况下，应该使用ReplaceText API实现替换文本，但是实际上遇到了很多错误。 当涉及到宏时，由于Clang的API行为不一致，因此事情会变得非常复杂。 例如，如果取消选中isMacroBodyExpansion()，最终将替换“ TEXT”而不是其参数。
例如，在LoadLibrary(TEXT("ntdll"))中，实际结果会变成LoadLibrary(your_variable("ntdll"))，这明显是错误的。
原因是TEXT是一个宏，当由Clang的预处理器处理时，会将其替换为L"ntdll"。 我们的转换过程是在预处理器完成工作之后发生的，因此查询标记”ntdll”的开始和结束位置将产生几个字符的额外值，这对我们没有用处。 不幸的是，使用Clang的API来查询原始翻译单元中的实际位置是一种魔咒，只能通过不断试错来进行。
在最近的空白位置插入变量声明
现在我们可以用变量标识符替换字符串了，我们的目标是定义该变量并为它分配给原始字符串的值。 简单的说，我们希望打补丁后的源代码包含char your_variable[] = "ntdll"，同时不覆盖任何内容。
可能有两种情况：
字符串文字位于函数体内。字符串文字位于函数主体外部。
后者是最直接的方法，因为只需要查找使用字符串的表达式的开头即可。
对于前者，我们需要找到封闭函数。 Clang公开了一个API来查询函数体的起始位置。 这是插入变量声明的理想位置，因为该变量将在整个函数中可见，并且我们插入的标记不会覆盖内容。
在任何情况下，这两种情况都可以通过访问每一个父节点来解决，直到找到一个FunctionDecl或VarDecl类型的节点为止：
MatchHandler::findInjectionSpot(clang::ASTContext *const Context, clang::ast_type_traits::DynTypedNode Parent,
const clang::StringLiteral &Literal, bool IsGlobal, uint64_t Iterations) {
if (Iterations > CLIMB_PARENTS_MAX_ITER)
throw std::runtime_error("Reached max iterations when trying to find a function declaration");
ASTContext::DynTypedNodeList parents = Context->getParents(Literal);;
if (Iterations > 0) {
parents = Context->getParents(Parent);
}
for (const auto &parent : parents) {
StringRef ParentNodeKind = parent.getNodeKind().asStringRef();
if (ParentNodeKind.find("FunctionDecl") != std::string::npos) {
auto FunDecl = parent.get<clang::FunctionDecl>();
auto *Statement = FunDecl->getBody();
auto *FirstChild = *Statement->child_begin();
return {FirstChild->getBeginLoc(), FunDecl->getEndLoc()};
} else if (ParentNodeKind.find("VarDecl") != std::string::npos) {
if (IsGlobal) {
return parent.get<clang::VarDecl>()->getSourceRange();
}
}
return findInjectionSpot(Context, parent, Literal, IsGlobal, ++Iterations);
}
}
测试
git clone https://github.com/SCRT/avcleaner
mkdir avcleaner/CMakeBuild && cd avcleaner/CMakeBuild
cmake ..
make
cd ..
bash run_example.sh test/string_simplest.c
如您所见，这很好用。 现在，此示例非常简单，可以使用正则表达式解决，并减少代码行数。
