Detecting Custom String Decryption Routines
The instrumentation engine of Joe Sandbox Mobile is very versatile. Using special keywords, it is possible to instrument not only Android SDK API calls, but also any locally defined function of the current target. This is useful to instrument e.g. functions that might reveal interesting data for further analysis. A typical example of such a function is often a static string decryption method that follows a function signature, such as "public static String decryptRoutine(String encryptedString)". Using the following configuration option it is possible to instrument functions that match this type of function signature (enabled by default):
LOGAPI_SPECIAL0=__STATIC____ANYLOCALCLASS__;->__ANYFUNC__(Ljava/lang/String;)Ljava/lang/String;
As "Opfake.C" uses encrypted strings heavily this feature comes in quite handy, as outlines in the following screenshot:
The red marked rows are executed API calls that were instrumented. As we can see, the string "_+J+:s.j:xjjFXQvo3ss.]j-3s" is decrypted to "java.net.HttpURLConnection" calling the function "mkfkejkpu" in the "mkfkejkpu" class in package "mkfkejkpu". An information that would have been hidden, if the Joe Sandbox Mobile engine would not offer such rich configuration options, such as the template-style instrumentation of local functions. Of course, if we discover an interesting function call during analysis that is not instrumented, it is possible to update the configuration and rerun the sample for more live data extraction.
Resolving Reflective Invokes
Another nice feature is that we associate objects returned by "getMethod" or "getDeclaredMethod" with reflective method "invoke" calls to resolve the real method call and parameter data. Often, obfuscating techniques involve heavy reflective invoke usage. The following two screenshots outline this quite nicely:
As can be seen in the first screenshot, the reflection invoke at line 94 is resolved properly to "java.net.URL.openConnection" and the param0 reveals the URL address "http://gogos1.net/index.php". These "invoke" translations are injected into the API call stream and passed to signatures, just as-if they were called directly by the APK. That way the full signature set will be applied to the APK, independent of whether or not reflection is being used. The second screenshot outlines the same mechanism plus the parameter name resolving. The "getIntExtra" call is resolved properly and the parameters "name" and "defaultValue" are extracted by our Android SDK parameter name resolving engine making the obfuscation efforts mute.
Signature Source Linked to Disassembly
Another new feature is that the signature source is linked to the disassembly code and is clickable. That way it is very easy to find an entrypoint into the disassembly using the matched signatures at the top of the report. Checkout the following screenshot:
Here we see that the reflective invoke "openConnection" caused the "Opens an internet connection" signature to trigger. Clicking the "show sources" link allows us to view all disassembly locations that caused the signature to match. Clicking the "source"-link in turn allows us to easily navigate into the proper disassembly code location for further analysis. A very powerful intertwining of dynamic and static data, a technology that we call "Hybrid Code Analysis" (HCA).
Basic Data-Flow Analysis
Something we have been working on is adding data-flow analysis algorithms to the static code analysis engine of Joe Sandbox Mobile 1.0. In the first version a basic version of it will be included that follows string data propagation within a function scope. That way signatures depending on string parameter values will match even if an API call was never executed, as string data associated with the register list is passed to the signature interface (e.g. URI.parse being called with a "content://telephony" string). The following screenshot is a simple example:
Installation / Miscellaneous Section
Sometimes samples register receivers or start services during runtime that are not listed in the manifest xml. Joe Sandbox Mobile 1.0 keeps track of these events and lists the specific data as part of the "Installation" section at the top of the behavior data. Again, it is possible to navigate to the relevant disassembly code by clicking the link. The following screenshot outlines the new behavior section:
Also, we added a new command that simulates "GPS" satellite location change and call the associated listeneres registered by "requestLocationUpdate" to trigger even more payload. In this case, the latitude and longitude values can be set through the cookbook script used in the analysis.
Posts
