Android Malware Series, Issue #1: Unmasking Android’s Hidden Threats, A Short Technical Report

Note: This report belongs to Inside the DEX, a new series of analyses covering Android malware samples.

This is my first write-up focused on mobile malware, specifically Android. Android malware remains a major threat to the general population; according to StatCounter.com, 75.2 % of the world’s users on Android (at the time of this writing), the attack surface is enormous.

In this short technical review, I discuss several static analysis findings to demonstrate how much intelligence can be gathered without dynamic execution or emulation. Not everyone has the resources or capability to run full mobile sandboxes or emulators, but even pure static analysis can reveal valuable insights into malware behavior.

Static analysis of the provided APK revealed a camera preview pipeline that delivers raw preview frames into an internal message pump, alongside evidence of HTTP POST sinks writing byte arrays behavior consistent with the capability to stream or exfiltrate camera preview data whenever network connectivity is available.

Key findings

A summary of the key findings are compiled in the following bullet points;

• Camera preview is started and owned by an obfuscated manager d3/c; preview frames are delivered to a callback d3/f.
• d3/f.onPreviewFrame([B, Camera) posts the NV21 frame bytes to a Handler (d3/b) instead of sending immediately, the handler is the critical fork to the sink.
• Repo-wide search shows HttpURLConnection / getOutputStream() / write([B) hits (excluding Umeng library code) in smali\a2\* and smali\b2\*, confirms byte-array POST sinks.
• Network logic includes an observer pattern (UMSenderStaticNotify) which waits for connectivity and triggers queued processing, meaning exfil may be delayed until network is available and retried.
• The code checks for com.tencent.mobileqq presence and contains Chinese SDK logging (Umeng), indicating either targeting/compatibility logic or reuse of SDK components; domains touched may include Tencent-related subdomains (requires runtime confirm).

The manifest has shown some intresting permissions.in the manifest.

Permissions

• android.permission.INTERNET
• android.permission.CAMERA
• android.permission.RECORD_AUDIO / android.permission.MICROPHONE
• android.permission.WRITE_EXTERNAL_STORAGE / android.permission.READ_EXTERNAL_STORAGE / android.permission.MANAGE_EXTERNAL_STORAGE
• android.permission.REQUEST_INSTALL_PACKAGES
• android.permission.READ_PHONE_STATE
• android.permission.ACCESS_FINE_LOCATION / ACCESS_COARSE_LOCATION
• android.permission.ACCESS_WIFI_STATE / android.permission.CHANGE_NETWORK_STATE / android.permission.ACCESS_NETWORK_STATE
• android.permission.WAKE_LOCK
• android.permission.MODIFY_AUDIO_SETTINGS
• android.permission.READ_SETTINGS

Evidence & artifacts

• Smali anchors / methods observed: ewho Activity binds SurfaceHolder → d3/c.b(SurfaceHolder) uses Camera.open(), setPreviewDisplay(...), startPreview().
• Frame path: Camera → d3/f.onPreviewFrame(byte[]) → d3/b.handleMessage(Message).
• Network sinks: HttpURLConnection + OutputStream.write(byte[]) occurrences in a2/* and b2/* smali directories.
• Network queue/observer: UMSenderStaticNotify.onConnectionAvailable() and MSG_PROCESS_NEXT retry semantics.
• Checks for network connection: ConnectivityManager var1 = (ConnectivityManager)var0.getSystemService(“connectivity”);
• Logging with UMRTLog and ULog: UMRTLog.i("MobclickRT", "...") logs network status changes, with some Chinese strings embedded (e.g., “创建CMI…”, “MSG_PROCESS_NEXT”), which translate roughly to:
  • 创建CMI = “Create CMI”
  • 连接成功 = “Connection successful”
  • 网络断开 = “Network disconnected”

I also re-wrote this function. Just for simplicity and ease of viewing. Essentially it does the following:

This function watches for network connectivity and, when the device is online, notifies registered observers. Those observers’ onConnectionAvailable() callbacks likely start queued actions, i.e., uploading data, sending heartbeats, or polling a C2 server. The Chinese log strings suggest the code came from a Chinese source or developer; behavior is typical of malware that delays exfiltration until a network is available.

I used findstr to parse through any key words and from I think based on the screenshot, It shows the camera preview callback feeding frames into a handler (onPreviewFrame to Handler.obtainMessage() to sendToTarget()), and elsewhere raw byte arrays are written to network streams (HttpURLConnection.getOutputStream() / OutputStream.write([BII) and setRequestMethod). By filtering out some known analytics, so this looks like custom code that captures live camera frames and uploads them to a remote server (probable exfiltration).

I also did some keyword searches and was able to find some directories of intrest

Led to:

The snippet below is checking if a flag called "SET_SENDREQUEST_AND_UPLOAD" is present in a map, and if it equals "false", it logs and stops further execution (likely skipping a data upload).
If the flag allows uploading, the code proceeds to inspect app metadata, specifically checking if the package name matches "com.tencent.mobileqq" (the QQ app) and then fetches its version info from the package manager. It also builds or logs a report string (sdkreport, HttpUtils.doReport) which strongly suggests SDK telemetry, analytics, or possible data exfil/reporting behavior. In short: it’s a conditional upload/report function that checks configuration, verifies QQ’s presence, and then prepares a network report or telemetry payload.

The same function is represented in two forms:

• Left side: Decompiled Java
• Right side: Smali code, aka low-level Dalvik bytecode.

the Smali though is what the Android actually executes, and the Java is a human-readable reconstruction of it. Just little easier to read is all.

This snippet of the function seems to build a report/payload from an internal map and, if allowed by a config flag, prepares and sends that report (via HttpUtils.doReport), including adding metadata like whether com.tencent.mobileqq (QQ) is installed and its version. If the SET_SENDREQUEST_AND_UPLOAD flag is present and set to "false", it aborts and does not upload. It also returns early with status codes when there’s nothing to send.

Breakdown:

1. Grab a Map of data to be reported; if it’s empty it returns (no upload).
2. Check a runtime/config map for the key "SET_SENDREQUEST_AND_UPLOAD" — if its value equals "false", log and stop.
3. Otherwise iterate the data entries, build a report string/payload (calls getCommandForUpdatePVC / builds sdkreport). The getCommandForUpdatePVC looks like a method that prepares a network request payload to get remote instructions from a server, likely as part of some command-and-control (C2) logic.
4. Query PackageManager for com.tencent.mobileqq and get its versionName (adds device/app metadata).
5. Call HttpUtils.doReport(...) (the network/upload routine) to send the payload.

Impact assessment

• User privacy impact: High > real-time preview frames could be exfiltrated without UI indication, exposing sensitive on-screen / environment visuals.
• Operational risk: Moderate > exfil may be opportunistic (waits for connectivity) and retried, making detection harder.
• Attribution/actor: Unknown; presence of Umeng/Tencent strings may be legitimate SDK reuse or indicate an author/hosting choice > Requires network capture for confirmation.

Recommended immediate actions

1. Quarantine sample and any devices that ran it. (Containment)
2. Block identified sink domains / IPs found during dynamic testing (network IOCs to follow).
3. Disable camera permission or uninstall app from any host until further analysis.
4. Collect dynamic evidence: run the APK in an instrumented emulator (fake camera feed) and capture full network traffic (mitmproxy/tcpdump) to confirm payload contents and destination.

Short remediation checklist for defenders

• Revoke or review camera permission grants for the app; remove app if not trusted.
• Monitor outbound HTTP POST traffic sizes/timing from devices (many small or periodic large POSTs correlated to app foreground/background changes).
• Add IDS/NGFW rule to log/block connections to observed domains once dynamic analysis reveals them.
• Add local app-control policy: deny camera access to apps without clear UX for capture.

IOCs

• Notable classes/methods: d3/c (camera manager), d3/f.onPreviewFrame([B,Camera]), d3/b.handleMessage(Message), ewho Activity.
• Network sink pattern: HttpURLConnection → getOutputStream() → write([B) found in smali\a2\* and smali\b2\*.
• Observability hooks: UMSenderStaticNotify.onConnectionAvailable() / MSG_PROCESS_NEXT — code queues payloads until connectivity.

Conclusion

This analysis reveals a deliberate, multi-stage design: the app captures raw camera preview frames via a Camera.PreviewCallback, queues them to a handler, and transmits the byte payloads over custom HttpURLConnection logic when network connectivity is present. The manifest and smali show powerful permissions (CAMERA, RECORD_AUDIO, STORAGE, INTERNET), obfuscation and native libraries, and explicit network-retry logic, all hallmarks of spyware built for stealthy, opportunistic exfiltration. Blocking any single control (e.g., network or runtime permission enforcement) would be insufficient; the sample uses combined techniques to remain functional across varying device states.