Earlier this month, we did a post about a family of premium rate SMS Trojans, which we detected as Trojan:Android/FakeNotify.A. Now we've found that the trojan has been updated, with changes to make analysis and detection more troublesome.
The new version comes from the same developer, as can be seen from the signing certificate. There's no change in the trojan's overall behavior, but the coding approach has changed significantly enough to foil static analysis tools and such.
For example, while analyzing, I compared the SMS sending routine from both the original and the current versions, and observed a change from the earlier simpler coding approach to a more dynamic one.
In the original version of FakeNotify, the routine was implemented in a straightforward manner that makes it is very easy to "read" what it does:
FakeNotify.A
The new version however takes advantage of the Reflection/Dynamic Invocation feature in the Java language to accomplish the same purpose, while making it harder for analysts to "read" the code.
The developer even goes one step further by obfuscating the string arguments with their own encoding/decoding algorithm (though this is just a simple substitution-like cipher). You can see the encoded form below:
The change in coding approach could easily defeat most static analysis tools.
Side note: during analysis, I suddenly realized the similarity between Windows LoadLibrary and GetProcAddress combo API functions and some features of Java Reflection. When it comes to dynamic retrieval of other API function addresses (Windows) and classes or method object handles (Java), both will allow the developer to call or invoke a recently acquired method or function.
Anyway, let's go back to Android world. To ease analysis of the new FakeNotify version, I created a simple Python script to replace instances of obfuscated strings with the plaintext ones of all the decompiled Java sources of the malicious application.
After the patching, it became clearer that the SMS sending routine obtains the handle to the class SmsManager and its getDefault method/function, which subsequently needs to be invoked/called or properly initialized in order to use the SmsManager class's sendTextMessage function:
Granted, this is hardly the first time I've seen the Java Reflection feature being used by Android malware, and the string obfuscation is not complex. It is however a pretty clear example of how Android malware developers are continuously adapting and upgrading their techniques to keep their "products" fresh and undetected.
