The Challan That Wasn't: Taking Apart a Fake RTO App Without Ever Running It
A static-analysis case study of an Android application that hides a second app, a server address and a remote-control channel.
Imagine receiving a message in a family or work WhatsApp group.
It claims that a traffic challan has been issued against your vehicle
and that you must pay the fine immediately. There is no official
website to visit. Instead, the message contains a small file named
RTO Challan.apk.
The instructions seem simple: download the file, install the app and check your challan details.
This is how fake traffic-challan applications can trick people into installing Android malware. In one reported case from Pune, a 70-year-old transporter reportedly lost approximately ₹24.35 lakh after installing a fraudulent application distributed through WhatsApp. Government agencies and cybersecurity researchers have repeatedly warned about similar campaigns.
We analysed one such sample to answer two important questions: what can the application do, and what evidence could help investigators identify the infrastructure behind it?
Table of Contents
- The Short Version
- A Scam with a Long History
- How We Approached the Analysis
- Layer One: The App That Asks for Almost Nothing
- Ten Pictures That Are Not Pictures
- A VPN That Filters the Web
- Layer Two: The App Inside the App
- Unlocking the Code Without Running It
- What the Hidden Code Can Do
- The Server and Remote-Command Channel
- The Infrastructure Behind the App
- What We Could Not Prove
- Dead Ends and Analytical Mistakes
- How Users Can Protect Themselves
- What Defenders Should Look For
- Indicators of Compromise
- How the Investigation Was Handled
- Sources and Further Reading
1. The Short Version
The application initially presented itself as an ordinary RTO challan utility. Its first layer requested relatively few permissions, but the investigation uncovered a much more complicated structure.
Key Findings
- The outer application contained ten files disguised as PNG images. Together, they held an encrypted package.
- The hidden second application was recovered with an exact size of 4,758,559 bytes.
- The hidden application declared permissions involving SMS, contacts, phone information and calls.
- Its main code was concealed behind a loader and could be recovered through static analysis.
- The recovered code contained routines for reading SMS, collecting contacts, sending messages, placing calls and executing USSD commands.
- Google Firebase Cloud Messaging was used as a remote-command channel in the application's code.
- Twenty server routes and fifteen remote-command names were identified.
-
Some server routes were named
card_payments,net_bankingandform_submissions.
The server domain was reported as registered on 20 July 2026 through Namecheap, with Cloudflare name servers.
2. A Scam with a Long History
Fake RTO and traffic-challan applications are part of a wider pattern of Android malware distribution in India. The approach often relies on urgency and familiarity rather than sophisticated social engineering.
A person receives a message about a pending traffic fine, an outstanding challan or a payment deadline. The message encourages the recipient to install an APK delivered through WhatsApp or SMS. Once installed, the application may attempt to access information that has nothing to do with checking a traffic fine.
Cyble documented RTO-themed phishing activity targeting Android users in India in 2024. Subsequent research described additional samples using multiple layers of payload delivery, manipulated package structures and techniques intended to make analysis more difficult.
In July 2026, reporting on a warning from the Press Information Bureau's fact-check unit highlighted the risks associated with fake e-challan links, APKs and PDFs. Public warnings have also stressed that traffic authorities do not distribute APK files as a method of challan payment.
Similar techniques appear in banking malware. Researchers have documented applications that collect SMS messages, misuse call forwarding and use Firebase Cloud Messaging to receive commands. These similarities provide useful context, but they do not prove that every sample belongs to the same malware family.
3. How We Approached the Analysis
Static analysis means examining an application's files and code without starting the application. It allows investigators to identify potentially dangerous functionality while reducing the risk of triggering actions against a real device or external infrastructure.
The investigation followed four principles.
3.1 Preserve the Original Evidence
The original APK should be fingerprinted using a cryptographic hash. A working copy can then be used for analysis while the original evidence remains unchanged.
3.2 Use Passive Analysis
The analysis did not involve visiting, pinging or scanning the domain and services discovered inside the application. Domain registration information can provide useful context without directly contacting the suspected infrastructure.
3.3 Do Not Use Embedded Credentials
The sample contained a Google API key. It was not used. Credentials discovered during malware analysis must not be treated as permission to access the associated service.
3.4 Separate Evidence from Assumptions
Findings were classified according to their level of certainty. Recovered code can confirm that a capability exists, but it cannot automatically prove that the capability was used against a victim.
4. Layer One: The App That Asks for Almost Nothing
The application initially installed by the victim was labelled RTO Challan.
| Property | Finding |
|---|---|
| Application label | RTO Challan |
| Outer package name | com.dxsvuji.fqyhjb.xplv |
| General permissions | Internet, network state, foreground service and notifications |
| Notable permission | Permission to install other applications |
The outer application did not request direct access to SMS, contacts or calls in the way the hidden application did. Its relatively modest permission list could therefore make it appear less suspicious to someone who only checked the first application's manifest.
The outer application also contained components associated with retrieving and preparing a second application.
This distinction is important when investigating Android malware: the first application installed on a device may not contain all the functionality that ultimately executes.
5. Ten Pictures That Are Not Pictures
Inside the outer APK, investigators found ten files named
dgtd_0.png through dgtd_9.png.
Despite their file extensions, the files did not begin with
the expected signatures of ordinary PNG images.
Each file contained approximately 382 KB of data with a random-looking appearance. Together, the ten files totalled exactly 3,823,856 bytes.
Two configuration files described a payload divided into ten parts, with a combined encrypted size of 3,823,856 bytes and an original size of 4,758,559 bytes.
| Observation | Result |
|---|---|
| Number of disguised files | 10 |
| File naming pattern | dgtd_0.png to dgtd_9.png |
| Combined encrypted data size | 3,823,856 bytes |
| Configured original payload size | 4,758,559 bytes |
The configuration files disagreed on build identifiers and keys. The reason for this discrepancy could not be established. One configuration may have been a decoy or may have belonged to another build.
Ordinary extraction tools also encountered a damaged package entry. Other tools were able to read the package, but the reason for the discrepancy was not proven.
6. A VPN That Filters the Web
The outer application also contained a VPN service. Android VPN functionality can allow an application to process network traffic passing through the device's VPN connection.
The recovered code read DNS lookups, compared requested domain
names against a list, and either forwarded DNS requests to
Cloudflare's public resolver at 1.1.1.1 or returned
a fabricated response indicating that the requested site did
not exist.
Such functionality could prevent access to selected websites. However, the investigation did not establish the contents of the filtering list or why particular domains might be included.
Therefore, the presence of DNS filtering is a finding. The intended purpose of the filtering remains unresolved.
7. Layer Two: The App Inside the App
The second application recovered during the investigation also used the label RTO Challan, but it had a different package name.
| Property | Finding |
|---|---|
| Hidden application label | RTO Challan |
| Hidden package name | yrk.rqillri.mvdli |
| Declared permissions | 17 permissions |
| Notable capabilities | SMS access, contacts, phone information, calls and background execution |
| Messaging integration | Google push messaging |
The hidden application's manifest declared permissions for reading, receiving and sending SMS messages; accessing contacts; reading phone state and numbers; placing calls; starting after device boot; running background services; and receiving Google push messages.
These permissions are unrelated to the basic task of displaying a traffic challan. Their presence becomes more concerning when considered alongside the recovered code and remote-command functionality.
The Signing Certificate
The hidden application was signed with the public Android test key. This key is shared by numerous unrelated applications and therefore does not provide a reliable identity for the author.
A signing certificate should not be treated as proof of common ownership unless there is additional evidence supporting that conclusion.
8. Unlocking the Code Without Running It
The hidden application's visible code was unusually small, measuring only 7,452 bytes. However, its manifest referred to services and receivers that could not be found in the visible code.
A much larger asset contained approximately 2.4 MB of data. Its measured randomness score was 7.99978 out of 8, suggesting that the contents were encrypted or compressed.
The loader contained several techniques that complicated straightforward analysis:
- Android class names were divided into smaller pieces, making ordinary text searches less effective.
- The loader attempted to access hidden system functionality.
- An early-start component helped prepare the hidden code.
- Five decoy classes contained empty methods.
- A helper included a 40-second delay, although the visible stub did not call it.
Recovering the Payload
The loader contained a 32-byte value used in the process of recovering the concealed code. Its routine read the large asset, applied an XOR operation using the key, decompressed the result and loaded the recovered content as executable Android code.
Investigators reproduced the relevant transformation on a separate computer without installing or executing the application. The resulting file was valid Android code with a consistent cryptographic fingerprint.
9. What the Hidden Code Can Do
The recovered code contained multiple routines that could expose personal information or enable unauthorised activity on a device.
9.1 Read SMS Messages
One routine queried the SMS inbox for information such as the sender, message text, date and read status. Another routine listened for newly received messages.
This capability is particularly concerning because SMS messages can contain one-time passwords, banking alerts and account recovery information.
9.2 Collect Contacts and SIM Information
The recovered code could access contact names and phone numbers. It also contained functionality for reading the SIM operator code.
9.3 Send SMS Messages and Place Calls
The application contained routines for sending SMS messages to selected numbers and placing calls.
9.4 Execute USSD Commands
USSD commands are codes entered through the phone dialler, often beginning with an asterisk or hash. Some USSD codes can manage call-forwarding settings.
The recovered application contained functionality for executing USSD commands, including call-forwarding-related operations, and reporting their results.
9.5 Start Automatically and Continue Running
The application included functionality associated with starting after the phone boots and keeping a background service active. These features could allow the application to remain available beyond an ordinary app session.
10. The Server and Remote-Command Channel
The recovered code contained a web client configured to communicate with a single server domain. Investigators identified twenty server routes and fifteen remote-command names.
Server Routes
The route names indicated functionality associated with device registration, status reporting, messaging identifiers, SMS uploads, contact uploads, USSD results and call-forwarding operations.
Three route names were especially notable:
api/card_paymentsapi/net_bankingapi/form_submissions
These names indicate that the server-side interface was designed to handle card-payment, net-banking and form-submission data. The investigation did not establish the precise fields behind these routes or prove that information was successfully transmitted to them.
Remote Commands Through Firebase
Google Firebase Cloud Messaging was used as a command-delivery channel in the recovered code. The application contained fifteen command names, including operations associated with:
- Reporting device status and refreshing its messaging address.
- Reading existing SMS messages and transmitting them.
- Collecting contacts and sending them to the server.
- Sending an SMS from a selected SIM to a specified number.
- Placing calls and executing USSD commands.
- Attempting call forwarding and reporting the result.
- Storing phone numbers for later use.
A command was ignored unless it identified the relevant device using its own device ID. This structure could allow an operator to direct commands to an individual device.
The "Background Sync Running" Notification
The code also contained a notification message reading
Background sync running. Other notification titles
included phrases such as "Syncing contacts" and "Reading messages".
The notification was configured to appear for ten seconds when
a command arrived.
These messages could make background activity appear routine. However, their presence in the code does not establish how a victim would have experienced the notification during actual execution.
11. The Infrastructure Behind the App
The server domain was reported as registered on 20 July 2026 through Namecheap. The domain used Cloudflare name servers, which means its registration information and DNS configuration alone do not reveal the origin server's actual address.
The outer application's configuration contained a date of 28 August 2026. That date could have been modified or fabricated and should not be treated as proof of when the application was created or deployed.
Firebase Project Identifiers
The application also contained identifiers associated with a Google Firebase project, including a project ID, project number and app ID.
These identifiers can help investigators identify the project associated with the application. They do not independently identify the person who created or controlled it.
Why Provider Records Matter
Relevant account, registration and access records may be held by Google, Namecheap and Cloudflare. Such records may help investigators establish links between accounts, infrastructure and individuals, subject to provider retention policies and applicable legal procedures.
12. What We Could Not Prove
A responsible technical investigation must explain not only what it discovered but also what remains unknown.
- The application was not executed, so its live screens and runtime behaviour were not observed.
- We cannot establish that any victim's SMS messages, contacts or financial information reached the server.
- We cannot identify the owner of the domain, Firebase project or server from the available evidence alone.
- The distribution path used to deliver this particular sample to victims was not established.
- The DNS filtering list was not fully examined.
- The data structures behind the card-payment and net-banking routes were not fully examined.
- The native library that appeared to handle key-related operations and environment checks was not fully analysed.
- Approximately seventy methods in the recovered code could not be converted into readable text, leaving some logic unresolved.
13. Dead Ends and Analytical Mistakes
Malware analysis can produce misleading results when data is interpreted without understanding where it came from. Several findings initially appeared more significant than they actually were.
13.1 Thousands of Apparent Domains
An early search produced names such as blogspot.com
and ngrok.io. These came from a public-suffix list
bundled with a common web library rather than necessarily
representing infrastructure controlled by the suspected operator.
13.2 A Misleading Certificate
The signing certificate initially looked like a possible method of connecting related samples. However, it was the public Android test key, which is shared by many unrelated applications.
13.3 A Phantom Database
A database was initially assumed to exist. Further examination showed that the database files located during that search belonged to analysis tools rather than the suspected application.
13.4 The Missing Server Address
Searching the visible code did not reveal the server address. The address became visible only after the concealed code was recovered.
14. How Users Can Protect Themselves
The most important lesson is straightforward: never install an Android application received through an unexpected message claiming to contain a traffic challan.
Before Installing an App
- Do not install APK files sent through WhatsApp, SMS or unfamiliar websites to view a traffic fine.
- Check challan information through the official government portal by entering its address yourself.
- Do not grant unnecessary SMS, contacts, accessibility, calling or device-management permissions.
- Keep Google Play Protect enabled and your Android device updated.
- Never disable security features merely because a message or an unfamiliar app instructs you to do so.
If You Have Already Installed a Suspicious APK
- Stop interacting with the application. If financial fraud is suspected, use a different trusted device to contact your bank.
- Check your phone for unfamiliar applications and review their permissions. Remove the suspicious application if it is safe to do so.
- Check call-forwarding settings and contact your mobile operator if you find unexpected changes.
- Change banking, email and other important passwords from a separate trusted device, especially if account access may have been exposed.
- Contact your bank immediately if you notice unauthorised transactions. Ask the bank to secure the affected account and payment instruments.
- Preserve relevant messages, transaction records, application details and other evidence. Avoid resetting the device before obtaining appropriate advice if a formal investigation is likely.
- Report suspected cyber financial fraud immediately through India's cybercrime helpline 1930 or the official National Cyber Crime Reporting Portal.
Always verify that you are using the genuine government website before entering personal information or making a payment.
15. What Defenders Should Look For
Security researchers and incident responders can use several characteristics from this sample as potential detection leads. No single characteristic should be treated as conclusive proof of malware.
| Potential Indicator | Why It Matters |
|---|---|
| A large package with a very small visible code file | May indicate that substantial functionality is hidden in assets or secondary payloads. |
| Manifest components with no corresponding visible implementation | May indicate dynamically loaded or concealed code. |
| Numbered files with image extensions that are not valid images | May indicate disguised payload storage. |
| Large assets with near-random byte distributions | May indicate encrypted or compressed data. |
| Unusual early-start loader components | May indicate that concealed code is prepared during application startup. |
| Routes named for payment cards, banking or form submissions | May indicate financial-data handling capabilities that warrant further examination. |
| SMS, contact and call-forwarding functionality combined with remote commands | May indicate a risk of surveillance, account compromise or remote misuse. |
These indicators are most useful when correlated with package metadata, cryptographic hashes, code references and other independently verified evidence.
Potential Prevention Opportunities
Two areas deserve particular attention:
- Detecting dangerous permissions in applications installed by another application, rather than examining only the first application.
- Providing clearer alerts when call forwarding is enabled or modified unexpectedly.
These are recommendations based on the observed capabilities and potential abuse paths. They are not findings that a specific platform or telecom operator failed in this case.
16. Indicators of Compromise (IOCs)
The following identifiers were recorded for defenders investigating this sample. Sensitive infrastructure identifiers and embedded keys are intentionally omitted from this public article while the investigation remains open.
| Indicator Type | Value |
|---|---|
| Application label | RTO Challan |
| Outer application package | com.dxsvuji.fqyhjb.xplv |
| Hidden application package | yrk.rqillri.mvdli |
| Loader package | moo.ocetrg.ytkn |
| Outer APK SHA-256 | 711a24d01a2b62e180e553195324909a6a33b34fcce085ee771fa33cb82c72d4 |
| Hidden application SHA-256 | e60cc02f66625f923b0229627be26a9cb8c82e3d5a214c2232086c644f1847dc |
| Recovered code SHA-256 | 352ddc5f4c643e687f7c3372e7392f2b7e3d5cf3ec19014551fc362783e344cc |
| Notable route names |
api/card_paymentsapi/net_bankingapi/form_submissionsapi/devices/{id}/contacts/batch
|
| Example command names |
read_old_sms,
read_contacts,
send_sms,
make_call,
call_forward,
payment
|
| Notification text | Background sync running |
IOCs are useful for searching and correlation, but they should be validated against the original sample before being used for blocking, attribution or formal evidentiary conclusions.
17. How the Investigation Was Handled
The analysis was passive from beginning to end. No server, storage bucket or messaging project named in the application was contacted. No credential discovered in the sample was used, and no victim data was accessed or retained as part of this analysis.
Evidence files and a technical report were prepared for law-enforcement authorities and CERT-In, India's national incident-response team.
The recommended next steps include preserving relevant provider records through authorised legal procedures and coordinating further investigation with the appropriate authorities.
This case demonstrates how static analysis can reveal significant functionality hidden inside an Android application without executing the application or contacting its external infrastructure.
Conclusion: Never Trust an APK Just Because It Says Challan
The fake RTO Challan sample demonstrates why Android malware analysis cannot stop at an application's name, icon or initial permission list.
Beneath the outer application, investigators found disguised payload files, a concealed second application, SMS and contact collection routines, call-related capabilities, remote commands and server routes associated with financial data.
The most important result was not an attribution to a particular criminal group. It was a reproducible set of technical findings that can guide further investigation while respecting the limits of the available evidence.
For everyday users, the practical advice is simple: never install an APK received through an unexpected traffic-challan message. Check your challan through the official government portal, keep your device protected and report suspected financial cybercrime immediately.
Stay Alert. Verify Before You Install.
A message that looks official is not proof that it is genuine. Verify the source, avoid unfamiliar APK files and report suspicious activity through official channels.
18. Sources and Further Reading
The following references were listed in the original case study. They provide background on RTO-themed malware, Android banking malware and public warnings about fraudulent e-challan messages.
-
Cyble:
Regional Transport Office themed phishing campaign targets
Android users in India.
Read the research -
Cyble:
GhostBat RAT: Inside the Resurgence of RTO-Themed Android Malware.
Read the research -
CYFIRMA:
RTO Challan Fraud: A Technical Report on APK-Based Financial
and Identity Theft, December 2025.
Read the technical report -
CYFIRMA:
Android Malware Posing as Indian Bank Apps.
Read the research -
Infosecurity Magazine:
Mobile Malware Targeting Indian Banks Exposes 50,000 Users.
Read the report -
McAfee Labs:
Android Malware Targets Indian Banking Users to Steal
Financial Info and Mine Crypto.
Read the research -
Business Standard:
Fake traffic challan scam: PIB warns against malicious
WhatsApp and SMS links, July 2026.
Read the report -
Greater Kashmir:
Crime Branch warns public against fake RTO challan APK scam
circulating via SMS and WhatsApp.
Read the report -
ETV Bharat:
Elderly From Pune Robbed Of Rs 24 Lakhs In Name Of Fake RTO
e-Challan Recovery Scam, 14 October 2026.
Read the report -
Google:
Launching enhanced fraud protection pilot in India, October 2024.
Read the announcement -
Business Standard:
Google Play Protect's new tools enhance app security on Android.
Read the report
Research note: This article describes findings from static analysis of one Android application sample. It does not establish that every application using similar techniques belongs to the same malware family. All attribution and runtime-behaviour claims should be supported by additional evidence.
.png)
