Rokarolla Android Banking Trojan: Inside a Packed Device-Takeover Platform

The Rokarolla Android banking trojan combines fake login screens, message collection, and remote device interaction. With the required permissions, it can steal credentials and manipulate legitimate app interfaces.

The analyzed sample hides its main payload inside a malformed APK. Its recovered code reveals 135 command labels covering screen capture, messaging, overlays, and device control.

Executive Summary

Rokarolla is not merely an overlay phisher. In this build, a concealed second-stage DEX establishes a sticky foreground heartbeat, accepts 135 literal command labels, fetches target and overlay content, captures UI and notification state, handles SMS and WAP push, interacts with calls, and supports screenshot-oriented pseudo-VNC behavior. The architecture places observation, deception, and interaction on the compromised handset, where they can operate across the legitimate application and its authentication channels.

The outer APK is only the first layer. Its application class, net.chef.talent.Drealmyself, reads a long-named asset, transforms it with an RC4-compatible routine keyed by the literal oNG, writes the result as page/moAajk.ttf, and injects the contained code. Replaying that routine recovers a valid ZIP and a 4,082,008-byte DEX 039 payload. Every DEX header check passes.

Inside the payload, a sticky foreground service repeatedly sends device state to /heartbeat.php and hands returned command and params values to a 135-label dispatcher. The labels cover overlays, screen and UI collection, input gestures, SMS and calls, notification access, device settings, and lifecycle control. The package also fetches monitored-application and HTML mapping data, allowing targets and phishing interfaces to change without rebuilding the APK.

The crypto is deliberately split by function. The loader uses a static stream transform for concealment. A separate Android Keystore flow retrieves an AES key for selected translated UI-anchor material. Its primary wrapped-key branches use RSA-OAEP with SHA-256/MGF1-SHA256; only the explicit wrapped_sha1 compatibility branch uses SHA-1/MGF1-SHA1. AES-GCM then uses a 32-byte key, 12-byte nonce, and 128-bit tag.

Key Findings

• Concealed payload: The main malicious code is decoded from an APK asset and loaded at runtime.
• Broad command support: The recovered dispatcher contains 135 literal labels covering overlays, input, collection, communications, and device settings.
• Combined access: Accessibility, notifications, SMS, and screen capture can bring several account-security functions under the same attacker-controlled workflow.
• Changeable targeting: The malware retrieves monitored-app lists and interface content from its server.
• Two embedded domains: This build contains morevoms.cfd and beralisvc.info. Two additional domains are associated through passive records, not extracted from the payload.
• Separate encryption functions: The loader’s concealment routine is distinct from the RSA-OAEP/AES-GCM workflow used for selected interface material.
• Two detection targets: The supplied YARA rules address the packed APK and the recovered DEX separately.

What Is the Rokarolla Android Banking Trojan?

Rokarolla is an Android banking trojan designed to control the same device on which a victim runs financial applications and receives authentication prompts. That matters because modern account security is distributed across the screen, notifications, SMS, biometric or PIN prompts, and trusted application context. Rokarolla attempts to collapse those layers into one remotely directed environment.

Its capabilities form a chain. Package discovery and a server-supplied monitored-app list tell the implant when a relevant application is present. HTML mapping and translation endpoints supply changeable interface content. Overlay activities place that content above or around the legitimate application. Accessibility code observes nodes, reads interface text, injects clicks and gestures, navigates system screens, and captures visual state. Notification and SMS components collect out-of-band messages. Call controls and device-state commands can interrupt or distract the victim. A heartbeat carries state to the server and receives the next action.

This is why the label “banker” can understate the engineering. Credential theft is one result, but the system is closer to a mobile remote-access and transaction-manipulation platform. The 135-label dispatcher includes commands for starting and stopping VNC-like capture, entering text, clicking by text or description, swiping, drawing gestures, requesting PIN or pattern interfaces, showing live or black overlays, opening settings, changing SMS roles, manipulating notifications, collecting contacts, and changing screen or sound behavior.

In this implementation, the monitored-application list is retrieved at runtime from /monitored_apps_full.php, and HTML mappings arrive through /get_html_mapping.php. The exact target list can therefore change server-side, while the locally countable command surface remains fixed at 135 dispatcher labels in the recovered DEX.

Rokarolla Timeline and Public Records

The public record starts in February 2026. Each date below is tied to what a registry, repository, public scan, certificate record, or DNS snapshot can establish. None is promoted to an infection date.

Public Sample Record

The Koodous record identifies the sample as package com.eje.clx, with a size of 13,595,861 bytes and a repository timestamp of 2 April 2026.

Its displayed application name imitates “TikTok.” The string combines Cyrillic and Greek characters with invisible word joiners, creating a familiar-looking label from a different underlying character sequence.

This label is a useful investigation clue. The repository timestamp establishes when the record was created, not when the APK was built or first distributed.

Related Domain Activity

Analyzing Rokarolla samples establishes morevoms.cfd and beralisvc.info as the two compiled HTTPS bases. Registry records extend that infrastructure chronology. ICANN’s RDAP-backed lookup records abiorime.cfd at 18:23:53 UTC and beralisvc.info at 18:24:35 UTC on 2026-02-05. Both use Global Domain Group LLC, placing their creation about 42 seconds apart.

The next convergence appears in public-scan history. On 2026-06-16, urlscan records abiorime.cfd at 17:11:13.280 UTC, beralisvc.info at 17:11:35.209 UTC, and morevoms.cfd at 17:11:57.603 UTC. Each submitted HTTPS URL resolves to 79.137.202.216, putting the three names on one address within 45 seconds. The corresponding records are abiorime, beralisvc, and morevoms.

Certificate Transparency places Let’s Encrypt issuance at 08:47:00 UTC for abiorime.cfd, 08:47:10 for beralisvc.info, and 08:47:22 for morevoms.cfd on 2026-06-23. All four names show tightly grouped certificate activity on 2026-07-16; abiorime.cfd and morevoms.cfd recur on 2026-09-13. The exact timing and repeated maintenance strengthen the cluster relationship.

The 2026-09-14 DNS snapshot resolves morevoms.cfd to 79.137.202.216, beralisvc.info to 178.173.248.132, and both adjacent names to 62.60.216.130. Historical urlscan results show that beralisvc.info moved from 79.137.202.216 to 178.173.248.132 by 2026-07-09, while morevoms.cfd remained on the former address.

The four-name infrastructure cluster is supported across separate passive systems: a 42-second registration pair, a 45-second public-scan convergence, repeated certificate maintenance, and later address reuse. The compiled configuration remains the boundary for direct malware indicators: morevoms.cfd and beralisvc.info are embedded in this payload, while abiorime.cfd and blestorians.cfd remain adjacent hunting pivots rather than confirmed C2 for this build.

Sample Metadata

The analyzed file is a signed Android APK with deliberately inconsistent ZIP metadata. Its outer package contains nine DEX files, while the recovered payload contains one additional DEX file.

Retain the original Sample Metadata table, with these edits:

• Change the header to Field | Value.
• Change “File type” to Android APK with malformed ZIP metadata.
• Change “APK signing” to v2 and v3 signatures verified in the reported analysis.
• Keep the hashes, size, package, SDK levels, version, and component counts unchanged.

The APK contains 761 ZIP members. Twelve have unusually long names. The manifest entry also contains conflicting compression fields and a CRC value that differs from the calculated value.

These inconsistencies can disrupt tools that expect conventional ZIP metadata. A parsing failure should therefore prompt further inspection rather than end the analysis.

Loader and Staging Chain

Android starts the application class before ordinary activities, making Drealmyself the ideal staging point. The loader obtains a private directory named page, works with an output named moAajk.ttf, reads the wrapped asset, and passes the resulting file to c.b.a.a.d(...) for class-loader injection. The .ttf extension is camouflage; the decoded object is a ZIP containing Dalvik bytecode.

The decoder uses the literal ASCII key oNG. It fills a 256-byte state array, permutes the array with the repeating key, and uses the evolving state to XOR each input byte. That is the recognizable structure of RC4’s key-scheduling and pseudo-random-generation algorithms. The routine offers concealment and portability, not strong secrecy: both the algorithm and key live in the outer DEX.

The wrapped asset begins at local-header offset 0x5140EE, is 1,758,522 bytes after extraction, and has SHA-256 83151a593966689546f4749e51fc54aea16602360747343f3ecc02eedb31e2df. Replaying the code produces a same-sized ZIP with SHA-256 24dd3b5488782ca9a95456eef1560fc9258ae75e5552668b486053d700903c9d. Its recovered DEX has SHA-256 47e353081da5d5adfa6f6c10d5949a2ad13149707e0417da3b1230f94414b0d8.

The outer nine DEX files and recovered payload all declare version 039. For every file, the magic, header size, endian tag, declared size, Adler-32, and SHA-1 signature match independently computed values. That result proves the bytecode layers are internally coherent before any semantic interpretation begin

APK Signing and Integrity

The reported analysis verified the APK’s v2 and v3 signatures using the embedded 2,048-bit RSA key. The stored content digest also matched the recomputed digest.

A valid signature does not establish that an application is trustworthy. It confirms verification against the embedded signing identity. The signing certificate’s SHA-256 fingerprint remains useful for sample correlation.

The package’s malformed ZIP metadata and its reported signature verification should be treated as separate findings. Neither should be used to assume that every Android version or analysis tool will process the package identically.

Android Components and Requested Access

The manifest requests 33 permissions and declares components associated with messaging, calls, notifications, overlays, screen capture, and background operation.

These declarations identify requested access and intended functions. They do not prove that all access was granted. Investigators should examine the device’s actual permissions, enabled services, and default application roles.

The manifest requests 33 permissions. Communications access covers SMS, MMS, phone state, calls, and contacts. Cross-application control combines overlays, package queries, notification listening, and two accessibility services. Persistence-oriented declarations include foreground service, special-use/data-sync service categories, wake locks, screen wake, exact alarms, and battery-optimization exemption. Storage and settings access includes external-storage management, write settings, notification policy, and package installation requests.

The architecture is modular without being fragmented. Receivers bring in SMS, MMS, phone, and role-change events. Services retain privileged observation. Activities display overlays or move the user into system flows. The heartbeat connects those pieces to remote instructions. A defender who looks only for a suspicious launch activity can miss the real control plane distributed across services and receivers.

How Rokarolla Abuses Accessibility and Other Privileges

Reading Screens and Performing Actions

With accessibility access enabled, Rokarolla can process interface events and inspect application elements through AccessibilityNodeInfo trees.

The recovered code supports locating controls by text or description, entering text, tapping coordinates, swiping, and performing gestures. These functions can help a remote operator interact with legitimate application screens.

Overlay commands add another layer. They can display deceptive prompts, obscure parts of the screen, or change whether an overlay accepts touch input.

Those actions make overlays more powerful. A static phishing screen can collect a secret, but an accessibility-assisted overlay can react to the underlying application, block input, switch touchability, place modal or full-screen content, request a PIN or pattern, and then return control. Commands such as liveoverlay, liveoverlayblock, showpinlockoverlay, showpatternlockoverlay, inject_block, overlay_point, and loading_screenshot describe multiple interface strategies rather than one fixed template.

The notification listener adds a second sensor. It reads posted notifications, builds records for submission, and can selectively cancel items. Transaction alerts, authentication messages, and fraud warnings can therefore become both intelligence and something to suppress from the victim’s view.

Notifications, SMS, and Calls

SMS and call roles extend that control beyond one application. The package declares SMS read, receive, send, and write capabilities; registers for normal SMS and WAP push; monitors default-SMS changes; and exposes respond-via-message components. A call-screening service and phone-state receiver support blocking and re-enabling calls. The result is a device-level collection system that can observe common out-of-band authentication and reduce the victim’s chance to notice or respond.

Rokarolla can also ask its server to turn a screenshot into coordinates. In the generic OCR path, the accessibility service registers TEXT_FOUND and TEXT_FOUND_FAILED receivers, assigns an attempt ID and 20-second timeout, captures the screen, and writes screenshot_<timestamp>.png to Downloads. A multipart POST to /ocr.php carries the image plus target_text and match_index. A valid response supplies found, x, and y; those coordinates are broadcast back with screenshot dimensions and can feed accessibility clicks or gestures. The generic path deletes the temporary PNG on success, not-found, and error.

Screenshot-Based Text Recognition

A second OCR path is hard-wired to find “Cancel.” It writes cache/screenshots/ocr_<timestamp>.png, submits the same OCR request with match index 0, adjusts the returned Y coordinate by about 7.15% of screen height, and clicks it. We found no explicit deletion of this specialized cache file, so cleanup is confirmed for the generic path only.

Server-Controlled Web Content

The WebView layer is equally concrete. open_url launches a JavaScript-enabled WebViewActivity using operator-supplied URL/package parameters. A separate overlay WebView exposes HtmlUpdater.updateHtml() to JavaScript; the bridge stores supplied HTML in a local cached_html SQLite table keyed by package. That bridge updates local overlay content. Credential submission remains a separate /save_credentials.php channel.

Heartbeat and Command-and-Control Communication

Xfbhds is a foreground service that returns START_STICKY. It creates a quiet notification on HeartbeatChannel with ID 123, schedules an early task around one second after startup, and supports an approximately 60-second default polling cadence. Five-second connection and read timeouts keep dead infrastructure from pinning the loop indefinitely.

Each heartbeat contains a compact operational snapshot:

The server response is parsed for command and params, then handed to g5.i1.c1. The heartbeat is ordinary JSON transported by HTTPS; Rokarolla’s RSA/AES channel has a narrower job described later.

Domain Selection and Fallback Behavior

The payload starts with two embedded HTTPS bases. Its failure-handling logic can switch between them or construct a .xyz hostname from a time-derived token and a configurable prefix.

This fallback mechanism means investigations should not rely only on the two embedded domains. New domain activity becomes more meaningful when correlated with the package, services, and other indicators.

Endpoint Functions

The endpoint table lists 27 PHP paths. They divide enrollment, commands, targeting, collection, and telemetry into separate functions.

Remote Commands and Device-Control Capabilities

The recovered dispatcher contains 135 literal command labels. The following sections group the functions described in the analysis.

Three commands require particular care when describing their behavior:

These three handlers are real code paths rather than inferred capabilities. overlay_point_close completes a point-overlay lifecycle; emergency_reset clears controller state rather than resetting Android; and draw_gesture passes an arbitrary gesture into the accessibility layer.

Overlays and Fake Prompts

Overlay/UI deception accounts for 30 mapped labels, while accessibility input/navigation accounts for 33. The overlay group includes live and blocking overlays, loading screens, PIN and pattern prompts, black-screen behavior, touchability changes, and point-oriented interfaces. Server endpoints for monitored apps, HTML mapping, translation, and credentials give those commands external content and context.

A typical control chain can detect or launch an application, fetch matching UI material, display an overlay, capture input, and dismiss or change the overlay when the underlying state moves. The division between show, hide, start, stop, touchable, not_touchable, and close labels shows attention to interface lifecycle rather than a one-shot web page.

Screen, Interface, and Data Collection

Collection commands include interface logging, contacts, clipboard content, SMS retrieval, screenshots, and VNC-like screen interaction.

“VNC-like” describes the effect, not proof that the malware uses the conventional VNC protocol. Screen images provide visual feedback, while accessibility commands supply actions such as tapping, typing, and navigation.

Messaging, Calls, and Device Settings

Other handlers support SMS-related actions, call controls, brightness and volume changes, screen-state changes, and settings navigation.

Combined with overlays and screen interaction, these functions could influence what the user sees and hears during an attack. Each action remains subject to the access available on the device.

Cryptographic Architecture

Rokarolla uses two unrelated cryptographic layers. The first is packaging: a static RC4-compatible transform hides the second-stage ZIP. The key ships in the loader, so this is an analysis barrier rather than durable secrecy.

The second layer is a server-assisted key workflow in g5.o5. The code creates a 2048-bit RSA key in the Android Keystore under alias anchor_decrypt_key. It registers device key material through /register_device.php and obtains a type-tagged wrapped value through /get_encryption_key.php.

The wrapper type selects both OAEP digests:

• wrapped_key -> SHA-256/MGF1-SHA256
• wrapped_sha256 -> SHA-256/MGF1-SHA256
• wrapped_sha1 -> SHA-1/MGF1-SHA1 compatibility fallback

w() builds RSA/ECB/OAEPWith<digest>AndMGF1Padding and constructs an OAEPParameterSpec whose MGF1 parameter follows that branch: MGF1ParameterSpec.SHA256 on the primary paths and MGF1ParameterSpec.SHA1 on the fallback. The result must be exactly 32 bytes.

That 32-byte value becomes an AES-256 key. AES/GCM/NoPadding uses a 12-byte nonce and 128-bit tag. Recovered callers connect the protected channel to selected translated UI-anchor material, including /translate2.php?lang=. The heartbeat itself remains JSON inside HTTPS, so the application-layer crypto should not be described as blanket protection for every command or exfiltration path.

Rokarolla Infrastructure

The exact payload initializes https://morevoms.cfd and https://beralisvc.info. Registration, Certificate Transparency, urlscan, and DNS records connect abiorime.cfd and blestorians.cfd as adjacent infrastructure. The scope remains explicit: the first pair is compiled in this APK; the second pair is passive context, not binary-extracted configuration or confirmed C2 for this build.

The address movement is infrastructure history, not a claim that every address served every role continuously. Bare-IP blocking should be time-bounded. The more durable relationship is the two compiled C2 names, two adjacent passive pivots, synchronized registration and certificate maintenance, the exact path vocabulary, and the package’s foreground heartbeat.

The fallback logic is more durable than any current record. g5.m5.p() builds a host from a time-derived token and configurable prefix, defaulting the sanitized prefix to anyprefix, under .xyz. Detection should correlate emergent .xyz resolution with the package, certificate, service roles, and heartbeat paths.

Why Rokarolla Matters for Mobile Banking Security

Rokarolla targets several functions that users rely on to secure a banking session: the application interface, messages, notifications, and device interaction.

If an attacker gains access to several of these functions on the same phone, an authentication message may no longer provide an independent warning or approval channel. This is a device-compromise risk, not proof that every form of multifactor authentication can be bypassed.

The packaging also matters. The most relevant code sits behind a concealed payload and malformed ZIP metadata. Analysis that stops at the outer package may miss the main implementation.

For defenders, the lesson is to examine both the payload and the access it can obtain on a device.

Rokarolla Detection and Indicators of Compromise

File and Package Indicators

Behavioral Indicators

Look for combinations of suspicious access and behavior, especially:

• Accessibility access associated with an unexpected application.
• Notification-listener access alongside SMS or call-screening roles.
• Overlay access combined with screen capture and remote interaction.
• Persistent foreground activity with related network connections.
• Package, certificate, loader, or file evidence matching the indicators in this report.

Investigate the combination rather than treating any one permission as proof of malware.

Preserve the original APK, installer details, enabled services, default roles, permission grants, relevant files, and available network records before remediation. Collect only the artifacts accessible through the approved forensic workflow.

Network Indicators

High-value exact paths include /heartbeat.php, /get_encryption_key.php, /monitored_apps_full.php, /get_html_mapping.php, /translate_start.php?lang=, /translate2.php?lang=, /analitic.php, /ocr.php, /save_credentials.php, /receive_ui_tree.php, /push.php, /sms.php, /screen.php, and /upload_frame.php.

Treat the three snapshot addresses as dated leads. Correlate host, path, package, certificate, and Android privilege state wherever possible. Newly observed .xyz lookups from a handset with the same behavior deserve priority even if neither compiled domain appears.

Response Priorities

1. Isolate the device through an approved mobile incident-response workflow and preserve volatile role/service state.
2. Reset financial credentials, sessions, payment tokens, recovery factors, and messaging-account sessions from a known-clean device.
3. Search APK repositories and forensic collections for both the packed package and recovered-payload rule.
4. Review SMS, notification, call, and accessibility activity around financial events; do not assume MFA remained independent of the infected handset.
5. Block compiled domains, search historical DNS/proxy logs, and retain path-level telemetry.
6. After evidence collection, use an enterprise-approved reset or replacement and re-enrollment process for high-value accounts.

YARA Rules

rule Android_Banker_Rokarolla_Packed_APK
{
    meta:
        description = "Rokarolla Packed APK Yara Rule"
        author      = "Dark Atlas; @ELJoOker"
        date        = "2026-09-14"

    strings:
        $s0         = "net/chef/talent/Drealmyself" ascii
        $s1         = "moAajk.ttf" ascii
        $s2         = "com.eje.clx" wide
        $s3         = "OnwgPWy" wide
        $s4         = "ZrVAOk" wide
        $s5         = "mlMgEpJh" wide
        $s6         = "hLcsddRF" wide
        $s7         = "PBjIoK" wide
        $s8         = "Xfbhds" wide
        $s9         = "BmjjSWj" wide

    condition:
        uint32(0) == 0x04034b50 and
        filesize > 10MB and filesize < 20MB and
        (
            ($s0 and $s1 and $s2) and
            5 of ($s3, $s4, $s5, $s6, $s7, $s8, $s9)
        )
}

rule Android_Banker_Rokarolla_Recovered_Payload
{
    meta:
        description = "Rokarolla Recovered DEX Payload Yara Rule"
        author      = "Dark Atlas; @ELJoOker"
        date        = "2026-09-14"

    strings:
        $s0         = "morevoms.cfd" ascii
        $s1         = "beralisvc.info" ascii
        $s2         = "/heartbeat.php" ascii
        $s3         = "/get_encryption_key.php" ascii
        $s4         = "anchor_decrypt_key" ascii
        $s5         = "/save_credentials.php" ascii
        $s6         = "Lcom/eje/clx/Xfbhds;" ascii
        $s7         = "AES/GCM/NoPadding" ascii
        $s8         = "overlay_point_close" ascii
        $s9         = "emergency_reset" ascii
        $s10        = "draw_gesture" ascii

    condition:
        uint32(0) == 0x0a786564 and
        uint32(4) == 0x00393330 and
        filesize > 3MB and filesize < 5MB and
        (
            ($s0 and $s1 and $s2 and $s3 and $s4 and $s5) and
            ($s6 and $s7 and $s8 and $s9 and $s10)
        )
}

FAQ

Why does Rokarolla need accessibility?
Accessibility exposes interface events, node text, actions, gestures, and screen context. Rokarolla uses those primitives to observe and manipulate applications and Android settings.

Is the payload actually a font?
No. moAajk.ttf is a disguised output name. The decoded object is a ZIP containing DEX 039 bytecode.

How many commands are in this build?
There are 135 literal dispatcher labels extracted directly from the recovered payload.

How many PHP paths are compiled?
There are 27 unique paths. The count is confirmed by both the 3,429-file decompiled-source pass and the recovered DEX string pool.

Does emergency_reset erase the phone?
No. Its handler clears internal controller state. It is not a factory-reset command.

Where is the target-application list?
It is not embedded as a fixed list. This implementation requests monitored applications from /monitored_apps_full.php, allowing the server-side target set to change without rebuilding the APK.

What exactly is the OAEP configuration?
The primary wrapped_key and wrapped_sha256 paths use SHA-256/MGF1-SHA256. The explicit wrapped_sha1 fallback uses SHA-1/MGF1-SHA1.

Does AES-GCM protect every message?
No. It protects selected translated UI-anchor material. The heartbeat is JSON transported by HTTPS.

Why are there two YARA rules?
Analysts may encounter either the packed APK or the extracted payload DEX. Each format therefore has its own strong string conjunction and validation target.

What is the fastest high-value device check?
Review enabled accessibility services, notification listeners, default SMS/call roles, overlays, foreground services, and the presence of com.eje.clx or page/moAajk.ttf, then preserve the APK and network history.

Conclusion

Rokarolla’s defining feature is convergence. The loader, Android privilege model, heartbeat, command dispatcher, server-supplied content, and dedicated collection paths all serve one device-takeover workflow. An overlay can ask for a credential while accessibility reads and controls the real application, notifications and SMS expose authentication context, and screen feedback guides the next action.

The packaging is noisy but effective: a malformed APK surrounds nine valid outer DEX files, while a small loader unwraps the 4 MB payload that matters. The protocol is similarly layered: HTTPS carries the heartbeat, a resilient base selector rotates or generates hosts, and a separate RSA-OAEP/AES-GCM channel protects selected UI-anchor configuration. The primary OAEP paths are SHA-256/MGF1-SHA256; SHA-1/MGF1-SHA1 exists only as the named fallback.

For defenders, the best coverage crosses layers. Detect the signed packed APK, the recovered DEX, the loader contract, privileged Android roles, heartbeat and endpoint vocabulary, and emergent infrastructure behavior. Then treat an affected handset as an account-security incident, because Rokarolla is built to reach the screen, messages, notifications, calls, and interaction that financial authentication depends on.