avcleaner - C/C++ source obfuscator for antivirus bypass

[blackhunt]

Blog posts​

The implementation is rather complex and this domain in software development is rarely documented in layman's terms. This is why there are blog posts which detail every design choice and go over the quirks of working with the LLVM API.

• https://blog.scrt.ch/2020/06/19/engineering-antivirus-evasion/
• https://blog.scrt.ch/2020/07/15/engineering-antivirus-evasion-part-ii/

Build​

docker build . -t avcleaner
docker run -v ~/dev/scrt/avcleaner:/home/toto -it avcleaner bash #adapt ~/dev/scrt/avcleaner to the path where you cloned avcleaner
sudo pacman -Syu
mkdir CMakeBuild && cd CMakeBuild
cmake ..
make -j 2
./avcleaner.bin --help

Usage​

For simple programs, this is as easy as:


avcleaner.bin test/strings_simplest.c --strings=true --


However, you should know that you're using a compiler frontend, which can only work well if you give it the path to ALL the includes required to build your project. As an example, test/string_simplest.c includes headers from the WinSDK, and the script run_example.sh shows how to handle such scenarios.

Common errors​

CommandLine Error: Option 'non-global-value-max-name-size' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options


In case you encounter this error, please use CMakeLists_archlinux.txt instead of CMakeLists.txt and it should go away.


Source Github : https://github.com/scrt/avcleaner

 

[d4x0n3l]

Hey, could you explain in more detail how exactly this "avcleaner" would actually help to bypass any AV please?

Lemme clarify:
- Inserting GetProcAddress / LoadLibrary calls everywhere around (this is what they do) may work against some dumb antiviruses, however this is not what legit program would do so this is a BIG red flag.
- About the part where they talk about string "obfuscation". When it comes to globals this just won't work at all. They also should understand that any modern compiler is smart enough to figure out this is still a string (in fact compilers are probably much smarter than most "researchers"), so yes it may be placed into .text section if it was aggregate initialized inside a function body, however this approach doesn't guarantee that so they likely will end up in the .rodata section* anyway (these folks say otherwise**).

Note I understand you are likely not an author so no offense, but from what I can see this is some kind of nonsense which should be easily detectable by any AV? Maybe I'm missing something, feel free to correct me in this case.


Also offtop and just my stereotypes, from my experience when I see usage of window's TCHAR, usage of "C/C++" combination and so on, it usually means that the one who uses them is not really an experienced C++ developer. You won't use TCHAR's in code which is meant to be cross platform and therefore you won't use it at all if you are used to write cross platform code, there's also no reason to use TCHAR's at all since utf8 windows api is broken and under windows you usually use wchar_t.
When it comes to "C/C++" word combination it usually means the one who uses it is either a C dev or writes in C++ the same way as in C but with classes (still the C dev actually =D). While still being semi-compatible with C modern C++ is very different from it, in fact it's even more different than lets say C# (yes C# is more C-like language than C++ is).


*: In this example string still ended up in the .rodata section as sequence of bytes without null terminator. However it still can be found by AV's. Note that I took it from their code.
**:

For instance, we know for a fact that ESET Nod32 will flag the string “ntdll” as being suspicious in the following context:

ntdll = LoadLibrary(TEXT("ntdll"))

However, rewriting this code snippet in the following manner successfully bypasses the detection:

wchar_t ntdll_str[] = {'n','t','d','l','l',0};
ntdll = LoadLibrary(ntdll_str)

Behind the scenes, the first snippet will cause the string “ntdll” to be stored inside the .rdata section of the resulting binary, and can be easily spotted by the antivirus. The second snippet will cause the string to be stored on the stack at runtime, and is statically indistinguishable from code, at least in the general case. IDA Pro or alternatives are often able to recognise the string, but they also run more advanced and computationally intensive analyses on the binary.