Blind try of MobSF over a suspicious Android sample

MobSF is an open source framework for mobile application analysis. I’ve already used it from time to time, but never in-depth, as the combination DroidLysis+JEB(+potentially Frida, or a Frida derivative like Dexcalibur) works out fine for me. However, hey, we always need to learn new techniques, so I decided it was time to try MobSF for real. In this article, I intentionally use only MobSF, and over a suspicious Android sample I have never analyzed before. Please note I am not an author of this tool, and the way I use it may be non-optimized. I’ll walk you through my analysis, and we’ll sort out what this sample is doing (I don’t know yet!). It’s SHA256 hash is 8810ca80d21173528be71109cd9e5a73afce98a080892643ffdcbe53ac9b6893 .

Static analysis with MobSF

For an impatient user, a 3-minute analysis seems a bit long, however it completes without any issue :)

Using online translation, it seems this sample poses as the “Plant vs Zombies” game. “Fun” fact: the application’s certificate is issued for common name “Obfuscapk”. We can expect the sample to be obfuscated 😉. I skip MobSF permission list, I’ll go back to it if needed. The Android API table immediately catches my eye:

Looks like an asset is decrypted and perhaps dynamically loaded afterwards

With MobSF, we can directly click on the links of the table, therefore I jump to DecryptAsset and validate it does what it says: decrypt an asset with AES/ECB, using a hard-coded key.

Which asset is decrypted and is it loaded dynamically?

public static final String b = "mosco";
public p69691c7b(Context context) { this.Z = false; try { InputStream decryptAsset = DecryptAsset.decryptAsset(context.getAssets(), b);...

The same happens in p0cc175b9.p0cc175b9.p0cc175b9.p2510c390 with an asset named “ueiso”. The code also shows that all native librairies are encrypted, and will be decrypted before loading.

Conclusion: the malware decrypts 2 assets (“mosco” and “ueiso”) with a hard-coded AES key, using AES-ECB.

As for dynamic class loading, apparently class p4d236d9a.p856d3eb2.p2852dea9.p9efab239.paed8d309 loads all JARs in a given path, but I am unable to find who uses this class — thus which JAR this might refer to. It is possible the assets “mosco” and “ueiso” decrypt into JARs. We could decrypt the assets statically at this point to check, but I’ll leave this step for later with dynamic analysis.

Executing OS commands?

The code issues 2 commands: (1) logcat -d -v RAW -s AndroidRuntime:E -p package , which retrieves error messages of the malware, and (2) clears the log. Fortunately, neither command are real issues because they only concern the malware itself and its capacity to debug itself.

MobSF says malware author(s) do not write secure code 😆


Some are obviously benign (e.g, but I’ll definitely check,, and (not shown on the image, below).

Where are those URLs used? I was going to search the code, but the URL table in MobSF shows it for me 😄

The URL table shows where URLs are used. Very handy.

I can immediately check what the malware is sending to hxxp:// (minor bug/feature request: the corresponding code was not highlighted).

The code shows the malware posts various device information to Nothing too sensitive apart the IMEI (returned by p() in did, q() returns the android ID). In some other classes, the code sets cookies for this URL.

The URL is the programmer’s website. Not interesting.

public static final String str_help_msg_en = “Plants VS Zombs 2.4\nProgrammer:lzn1007\\nBlog:\n\nGame Mode:\nDAY:Ordinary mode of existence.\nNIGHT: [..]

Finally, there is a dirty post to, where the code sends the smartphone’s IMEI and IMSI. This is a security issue, however I have seen it so many times I am not sure this is enough to classify a sample as “malware”.

The code sends the IMEI, SIM serial number, IMSI and Build model.

Conclusion: the code is dirty and leaks sensitive information (IMEI, IMSI), but this cannot qualify as a CnC.

Dynamic analysis

Actually, the error message is not precise enough. I try in a shell and get the following error:

$ adb install ksapp.apk
Performing Streamed Install
adb: failed to install ksapp.apk: Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES: Failed to collect certificates from /data/app/vmdl1088091278.tmp/base.apk: META-INF/OBFUSCAT.SF indicates /data/app/vmdl1088091278.tmp/base.apk is signed using APK Signature Scheme v2, but no such signature was found. Signature stripped?]

At this stage, I spent time trying to solve the issue… I installed Lucky Patcher to disable signature verification for my APK, but unfortunately it did not work 😠. I also tried option -t and -d of adb install, but that does not bypass signature verification. Finally, I solved the problem by re-signing the APK myself (but I don’t like this solution — never like to “touch” a sample):

  1. Generate a test keystore with keytool
  2. Sign the “faulty” apk with apksigner (ships with the Android SDK). In my case: ~/Android/Sdk/build-tools/30.0.3/apksigner sign — ks my.jks — min-sdk-version 25 — in ksapp.apk — out signed-ksapp.apk

We need to have MobSF re-analyze signed-ksapp.apk (for dynamic analysis of ksapp.apk, MobSF will only try to install ksapp.apk and does not give the user control to install the app him/herself), and launch dynamic analysis. This time, I ran in a communication problem with my emulator: MobSF complained it could not connect to the emulator. After Lucky Patch install + failed patches, it’s not that surprising, I decided to re-launch my emulator with wiped data. Aaaah, it worked! I like the fact MobSF handles everything itself: finding the emulator, installing the sample, launching a Frida server.

The dynamic analysis UI is nice, but IMHO not ergonomic at all! The colums for Frida Logs or Frida Code Editor are too small (unless your screen is very large!)

I leave all the default options checked, and on the right pane, search for the Frida script aes_key (might be useful to the assets) and load it. By the way, it’s possible to add other scripts to the list by adding them to ./mobsf/DynamicAnalyzer/tools/frida_scripts/others/.

Unfortunately, I do not get any useful information for this sample:

  • Frida logs show nothing interesting [in the case of this sample]
  • The AES script does not launch: probably the sample does not reach the point where AES decryption is triggered?
The sample is stuck on this splash screen and crashes when I click 😢 to try and get more code executed.

Have I missed anything?

The sample is detected by some AV vendors as “Ksapp”, where this refers to a botnet which can execute remote commands. IMHO, this is a False Positive, because this particular sample does not do that. Some other vendors say that Ksapp is a trojan that steals the IMEI, IMSI and SIM serial number. This is more in line with my analysis.

I think I haven’t missed anything, please feel free to let me know if I did.

Recap / Conclusion

MobSF worked well.

  • Pros. I particularly like the “Android API” and “URL” tables. I also like to quickly jump to relevant part of the code. The dynamic analysis works well — compared to House and Dexcalibur, I appreciated it installs the APK + Frida server automatically.
  • Cons (personal!). For malware analysts, the static analysis displays lots of useless information e.g we don’t care how the developer could have secured his/her code better 😉 + Research with the code is limited: MobSF clearly does not have the features of a real decompiler. I miss cross references! Finally, I didn’t like the UI of dynamic analysis : too small, not intuitive, presence of useless features (e.g taking screenshots of the emulator, or viewing the emulator in the web page : we can do that easily from the emulator) while some other feature would need more explanation (what do the options do, indicate if Frida script is loaded or not, respawn an APK etc). On this account, Dexcalibur’s web interface is much better : we understand what buttons do quite intuitively. The good news is that all of this is perfectly fixable 😃

— Cryptax

Mobile and IoT malware researcher. The postings on this account are solely my own opinion and do not represent my employer.