The use of Flutter in malware to obfuscate analysis

September 4, 2024

As we discussed before, malware creators have a primary objective when developing a new piece of software: to avoid detection—or at least delay it for as long as possible.

To achieve this, they try to remain unnoticed, but in a large-scale infection attempt targeting hundreds of thousands of devices, this is practically impossible. Eventually, the malware sample will end up on a malware analyst's desk, where all its secrets will be laid bare.

Given that the released specimen will have a short lifespan, efforts are made to equip it with mechanisms that complicate the task of extracting its functionalities and communications. In other words, to make the analysts sweat before emerging victorious with the necessary data to create blocking and detection rules.

____

In previous entries we saw that they used new programming languages to make this task harder. The reason, which we reiterate here, is simple: there is not much information and few tools for these binaries, and until these gaps are filled, they exploit this window of opportunity.

Specifically, we know of Go and Rust (among others). These languages also enable faster development times due to their abstraction mechanisms and conveniences, which are absent in other native languages (such as C and C++).

Today, we're bringing a "dark horse" to the forefront. We’ve chosen this term because calling it "unknown" would be unfair. We’re referring to Dart, an object-oriented programming language designed by Google for the web.

However, Dart isn't as popular as Flutter, the platform where Dart plays a starring role. Flutter is widely used as a cross-platform application development framework, particularly in the mobile world, where developers can use Flutter to deploy the same version on both Android and iOS, drastically reducing development times.

Flutter is widely used as a cross-platform application development framework, particularly in the mobile world.

In any case, malware creators do not primarily use Dart because of Flutter’s portability (although they might, such as in the case of the MoneyMonger malware) but rather due to a feature of its compiler, which we’ll explore further below.

Fluhorse: an example of malware written in Flutter to hinder analysis

In May 2023, a new Android malware family named Fluhorse emerged. Although malware using Flutter had already been detected and studied, the novelty of Fluhorse was that its malicious routines were written specifically for this framework.

While Flutter's use was previously considered mainly for its cross-platform portability, this time it was leveraged for its anti-analysis capabilities, using concepts we will discuss shortly.

It’s worth reading the static analysis report from Fortinet, which details the "struggle" to reverse-engineer the Flutter binary and how a slip-up by the malware creators, by including the x86-64 binary, facilitated its analysis.

The post delves into the intricate layers of protection surrounding the malware, from the packaging of the resulting APK, which makes the package content structure challenging to interpret "humanly":

Source: Fortinet.

Additionally, the payload part (the set of actions in the code meant to be hidden from analysts) is encrypted (by the same packer) within the classic "classes.dex." Once decrypted, it unfolds another "classes.dex" containing malicious functionality.

This final object is the Flutter "snapshot," and here they erect another (almost) insurmountable barrier. This is where we’ll explore why Flutter is used as an anti-analysis mechanism.

Flutter as an anti-analytical measure

Firstly, Flutter's creators did not hinder analysis, but rather produced a final product optimized for size and performance. This is especially important for mobile development frameworks, where every byte and cycle taxes battery life.

That said, like other frameworks that allow reverse-engineering obfuscation to protect intellectual property, Flutter has optionsto obfuscate the code. This essentially means changing the names of variables, methods, and classes to random strings (see the image above). However, this is not the feature malware creators are most interested in.

Dart, the language used to program Flutter, allows the application to be compiled into different formats, providing flexibility and adaptability to meet developers' requirements for the context in which the application will be deployed.

Among the various compilation output formats, there are two main groups: Dart for the web and Native Dart. The latter has two modes: JIT and AOT:

JIT (Just In Time execution) mode compiles the code on-the-fly during program execution.
In the AOT (Ahead Of Time compilation) mode the code is precompiled by the application creator and injected into the Dart virtual machine.

Source: Dart.

In summary, AOT saves the hassle of compiling for the platform but, in exchange, requires pre-compiling the application for the different architectures on which it will run.

Remember, mobile devices have several types of architectures, which means a Dart AOT binary carries extra weight because it must contain all the code for each architecture. Recall what happened to the Fortinet lab: "they stumbled upon the x86-64 version code..."

AOT Snapshots

Here lies the crux of this discussion. This format is a serialization of the Dart virtual machine state and, as such, has its own highly optimized structure, which changes relatively quickly from one version to another. Reverse engineering documentation is still scarce.

Additionally, when an application is compiled, it statically loads all the necessary libraries (there is no dynamic linking), so the space to study within this snapshot is vast.

Moreover, remember that this is not code to be executed directly; instead, the Dart virtual machine will handle execution (recall, it is cross-platform). Therefore, even when disassembled, the code lacks immediate meaning.

Lastly, reverse engineering relies on applying existing knowledge about the object to analyze (breaking down the whole into parts). This process inevitably depends on a range of well-tested and optimized tools developed by the community or specialized companies. But, what happens if these tools do not exist or are still in a very early stage?

This is precisely the current state of reverse Dart AOT snapshots: optimized and ever-changing formats, poor documentation, and a lack of tools—a perfect storm for an analysis lab and an opportunity window for malware, as we have seen.

What can we do to combat malware using Flutter (Dart)?

There are some options, of course. In this field, curiosity is never in short supply, and fortunately, some share their findings. For example, the "reFlutter" project is a patched version of the original framework to help trace the application, which we can use to work with it in Frida or examine its traffic with an HTTP intercepting proxy.

Additionally, there are more publications addressing Dart AOT snapshot handling for reverse engineering. An excellent example is the recently published article "Reversing Dart AOT Snapshot" in the renowned ezine Phrack.

Conclusion

Clearly, this is yet another new challenge for malware analysts. It's an area previously unknown, now exploited by malware creators.

However, the community is quick to respond, and the continuous flow of published findings keeps a steady stream of new tools and knowledge to shrink the space available to attackers.