Anatomy of a Fake Government App: Dissecting an Android Dropper Disguised as “mParivahan”

A file lands in your inbox or, more realistically, arrives as a WhatsApp forward, an SMS about an “unpaid traffic challan,” or a link promising to help you renew your RC online.

The attachment is called:

NextGen_mParivahan.apk

It looks official enough.

Millions of people in India are familiar with mParivahan and use government transport services for exactly this kind of thing. So the name itself doesn’t immediately raise an eyebrow.

That’s the trick.

I decided to take the APK apart not on a phone, and certainly not by installing it, but on an analysis workbench and see what was actually inside.

What emerged was a textbook example of an Android dropper: an application whose visible interface is largely a delivery mechanism for another, concealed payload.

The interesting part wasn’t simply discovering that the APK was malicious.

It was seeing how deliberately it was designed to make analysis harder.

Step 1: The file looks normal. That’s the point.

At first glance, NextGen_mParivahan.apk looks like a perfectly ordinary Android application.

It’s a valid ZIP-based Android package, approximately 11.8 MB in size, containing the familiar components you’d expect:

• classes.dex
• resources.arsc
• AndroidManifest.xml
• Android resources
• Application icons
• Layout files
• AndroidX/AppCompat/Material Components libraries

Nothing about the top-level structure immediately screams malware.

And that’s precisely the point.

A dropper doesn’t need to look malicious.

It needs to look boring enough to get installed.

The first line of defense isn’t always an antivirus engine. Very often, it’s a human being looking at an application name and deciding whether to tap Install.

The attacker only needs to win that decision once.

Step 2: The manifest that refused to open

The first serious anomaly appeared during extraction.

A standard ZIP utility reported something along the lines of:

“AndroidManifest.xml is encrypted, password required for extraction.”

That doesn’t make much sense.

A genuinely encrypted Android manifest would present a fundamental problem: Android needs to parse the manifest in order to understand the package.

So was the APK corrupted?

Or was something else happening?

Inspecting the raw ZIP structure provided the answer.

The encrypted bit had been manipulated in the ZIP metadata for the manifest and roughly a hundred other entries.

The underlying content, however, wasn’t actually encrypted.

When the misleading flag was ignored, the manifest decompressed normally using standard DEFLATE.

That distinction is crucial.

This wasn’t ordinary encryption.

It was metadata manipulation designed to confuse analysis tooling.

Think of it as putting a “locked” sign on a door that isn’t actually locked. Many automated tools will respect the sign and stop. A more forgiving parser may simply ignore it and continue.

The technique can interfere with tools such as:

• unzip
• apktool
• automated APK parsers
• malware scanners
• sandbox ingestion pipelines

And the manipulation wasn’t isolated.

103 of 238 parsed ZIP entries carried the suspicious flag, including AndroidManifest.xml.

That’s a substantial portion of the archive.

One particularly interesting entry went further: its ZIP metadata claimed an uncompressed size of approximately 1.5 GB, despite the compressed data being only a few megabytes.

That’s highly implausible and consistent with zip-bomb-style metadata poisoning, where malformed size information can cause naïve unpackers or automated analysis systems to allocate excessive resources, fail, or time out.

Before examining the application’s actual behavior, we already had evidence that someone had taken deliberate steps to make the package harder to inspect.

Step 3: A package name that gives the game away

Once the manifest could be parsed, the application’s declared package name appeared:

com.bum029.bsqj1m

That isn’t an official-looking government namespace.

It certainly doesn’t match the identity a user would reasonably expect from an application presenting itself as India’s mParivahan service.

The surrounding code tells a similar story.

Class names include strings such as:

LmHZpPjZwq8wPUibA9
gEqvW6VnlWERSwutPp
jPfXPQJdzLf8nBacZr

Obfuscation by itself isn’t evidence of malware. Legitimate Android applications routinely use R8, ProGuard and similar techniques.

But security analysis is about patterns, not isolated indicators.

Here, randomized identifiers appear alongside:

• A misleading government-app identity
• A generic signing certificate
• Suspicious assets
• Cryptographic payload-handling code
• Package installation APIs
• Anti-analysis ZIP manipulation

The package begins to look less like a normal application and more like a disposable malware build.

Even some resource filenames are randomized.

There is also a stray .DS_Store file inside the APK. An interesting artifact suggesting that the package was assembled or manipulated on a macOS workstation.

None of these observations proves malicious intent by itself.

Together, they add weight to the same hypothesis.

Step 4: The permissions are strangely minimal

The recovered manifest requests several permissions that deserve attention.

QUERY_ALL_PACKAGES

This allows the application to obtain visibility into installed applications.

For legitimate apps, there are specific use cases for this capability. In malware, it can be valuable for device reconnaissance — identifying whether banking apps, UPI applications, wallets or security software are present.

REQUEST_INSTALL_PACKAGES

This one is even more significant in context.

It allows the application to request installation of other packages.

On its own, that isn’t malicious.

But remember that we already have a large opaque payload sitting inside the APK.

DUMP

This is unusual for an ordinary consumer-facing government service and warrants additional scrutiny.

Then there’s what the manifest doesn’t contain.

There are no obvious SMS permissions.

No obvious overlay permission.

No obvious accessibility-service declaration.

At first glance, that might sound reassuring.

It isn’t.

In fact, it fits the dropper architecture surprisingly well.

If the outer APK is merely the delivery mechanism, there’s no reason for the first stage to expose every capability of the eventual payload.

The dangerous permissions can arrive later.

Step 5: The 9.8 MB question

The biggest clue was sitting quietly inside the assets/ directory.

Two files immediately stood out.

The first was a roughly 9.8 MB binary blob:

assets/4yhSF0XrpYFNbefj

It had no meaningful filename and no useful file extension.

The second was:

assets/e6wOVmgSLN7CNGUD

and was exactly 16 bytes.

Sixteen bytes is an interesting size in cryptographic analysis.

It is compatible with an AES block size and can also represent an AES key or initialization vector, depending on how the implementation uses it.

But the file size alone proves nothing.

The code provided the missing context.

The DEX references:

javax.crypto.Cipher
javax.crypto.spec.SecretKeySpec
javax.crypto.spec.IvParameterSpec
javax.crypto.CipherInputStream

It also contains the literal transformation:

AES/CBC/PKCS5Padding

and the error message:

“Decryption failed”

Now the pieces start fitting together.

We have:

A large opaque binary

A 16-byte companion artifact

AES decryption code

A runtime decryption error

That is a very strong indication that the large asset is not ordinary application data.

It is likely a protected payload.

Step 6: The installation mechanism closes the loop

The next discovery was the one that transformed a suspicious encrypted asset into a coherent dropper architecture.

The DEX references:

android.content.pm.PackageInstaller
android.content.pm.PackageInstaller$Session
android.content.pm.PackageInstaller$SessionParams

The manifest also requests:

android.permission.REQUEST_INSTALL_PACKAGES

Individually, these APIs are legitimate Android functionality.

Together with the encrypted payload, however, they become highly significant.

The likely execution chain looks like this:

Victim receives fake mParivahan APK
                │
                ▼
        Victim installs APK
                │
                ▼
       Decoy application runs
                │
                ▼
       Reads embedded payload
                │
                ▼
       Decrypts payload with AES
                │
                ▼
      Creates PackageInstaller session
                │
                ▼
      Attempts second-stage install
                │
                ▼
       Second-stage malware

That’s the defining architecture of a dropper.

The outer application isn’t necessarily where the final malicious functionality lives.

Its primary job is delivery.

The visible APK can therefore remain relatively lightweight and unremarkable while the more dangerous functionality stays hidden inside an encrypted second stage.

Step 7: The “missing” malware is actually the clue

This explains something that initially looks contradictory.

The outer DEX doesn’t prominently contain obvious functionality for:

• SMS theft
• OTP interception
• Accessibility abuse
• Overlay attacks
• Credential harvesting

That’s not necessarily evidence of safety.

It’s exactly what we’d expect if the malware is staged.

Searching only the first-stage DEX for SmsManager or SYSTEM_ALERT_WINDOW is like searching a delivery truck for the contents of the package it hasn't opened yet.

The correct question isn’t:

“Where is the banking trojan?”

It’s:

“What is this application trying to install?”

That distinction is fundamental when analyzing droppers.

Step 8: Even the signing certificate tells a story

Every Android application must be signed.

This APK is signed with a certificate identifying itself as:

CN=Release
O=Android
C=US

That’s a generic, self-signed identity rather than an obvious organizational or government publisher identity.

The certificate’s validity period runs from:

May 24, 2026 → October 9, 2053

The start date also aligns closely with the APK’s internal build timestamps.

Again, a long-lived developer certificate isn’t automatically malicious.

But for an application masquerading as a government service, the signing identity matters enormously.

A filename can be changed.

An icon can be copied.

The application’s name can be copied.

The signing identity is a much harder thing to fake convincingly without actually possessing the legitimate publisher’s signing key.

This is why defenders should treat APK signing certificates as identity indicators, not merely technical metadata.

Step 9: The decoy doesn’t need to be sophisticated

Another interesting detail is the visible application itself.

The DEX is dominated by familiar AndroidX, AppCompat and Material Components libraries.

There are also ordinary-looking layouts such as:

activity_main.xml
second_activity.xml

This suggests a relatively simple interface.

Get Jay Pomal’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

And that’s enough.

A successful phishing application doesn’t need to reproduce every feature of the real government application.

It needs to create enough visual and contextual credibility to keep the victim from asking questions.

The attacker doesn’t need you to use the app for ten minutes.

They may only need you to:

Install → Open → Approve → Wait

Once the second stage has been delivered, the decoy has done its job.

Step 10: The social-engineering layer matters

The technical architecture only explains how the malware works.

The mParivahan branding explains why people install it.

A message about:

• an unpaid challan
• an expiring RC
• a traffic violation
• a pending vehicle document
• an urgent RTO notification

creates exactly the emotional conditions attackers want:

familiarity + urgency + authority

The victim isn’t thinking:

“Should I execute an untrusted Android binary?”

They’re thinking:

“I don’t want a traffic fine.”

That’s the social-engineering layer.

And it is arguably more important than the malware’s technical sophistication.

A highly sophisticated payload is useless if nobody installs it.

A relatively simple dropper can be extremely profitable if thousands of people believe the story surrounding it.

What We Can Confirm — And What We Shouldn’t Overclaim

This distinction matters.

A security report should separate observed behavior from reasonable inference.

Strongly supported by static analysis

The APK:

• Is not a trustworthy representation of the official mParivahan application.
• Uses the suspicious package name com.bum029.bsqj1m.
• Uses a generic self-signed certificate.
• Contains manipulated ZIP metadata designed to interfere with analysis.
• Contains a large opaque embedded binary.
• Contains cryptographic APIs and AES/CBC/PKCS5Padding.
• Contains a 16-byte companion artifact.
• Requests REQUEST_INSTALL_PACKAGES.
• References Android’s PackageInstaller APIs.
• Requests QUERY_ALL_PACKAGES.
• Has an architecture strongly consistent with a first-stage dropper.

Strongly indicated

The outer application is designed to decrypt and deliver another Android payload.

Not proven by the outer APK alone

The exact final capabilities of that second-stage payload.

The architecture is consistent with Android banking-trojan campaigns that use RTO, challan and mParivahan themes to distribute malware capable of stealing sensitive information or facilitating financial fraud.

But without extracting and analyzing the second stage, it would be irresponsible to claim that this particular sample definitely steals OTPs, UPI PINs or banking credentials.

That’s where good malware analysis stops guessing and starts proving.

The Bigger Picture

What makes this APK interesting isn’t a zero-day exploit.

There isn’t one.

The attacker doesn’t need one.

Instead, the sample relies on something much more practical:

misdirection.

The malicious capability is largely absent from the application a victim thinks they’re installing.

Instead, the outer APK contains the machinery required to retrieve and install something else.

The attack therefore has several layers:

Social engineering
        ↓
Trusted government branding
        ↓
Fake Android application
        ↓
Anti-analysis tricks
        ↓
Encrypted payload
        ↓
Runtime decryption
        ↓
Package installation
        ↓
Second-stage malware

Each layer has a different purpose.

The WhatsApp message gets your attention.

The mParivahan branding gets your trust.

The APK gets onto the device.

The ZIP manipulation slows down analysis.

The encrypted blob hides the payload.

The installer delivers it.

And the second stage gets the capabilities the attacker actually wants.

That’s a remarkably efficient attack chain.

Why This Matters Beyond One APK

There is a broader lesson here for anyone investigating Android malware.

“The app doesn’t ask for scary permissions” is no longer a sufficient safety check.

A first-stage dropper may intentionally avoid requesting the permissions associated with its ultimate objective.

Likewise:

“The APK looks corrupted” doesn’t necessarily mean the sample is harmless.

The corruption may be intentional.

And:

“I don’t see malware strings in classes.dex” doesn't mean there is no malware.

The malware may be somewhere else.

When an APK contains unusual archive structures, encrypted assets, cryptographic routines and package-installation capabilities, those pieces need to be analyzed as a system.

The individual clues matter.

The relationships between them matter more.

Practical Indicators for Defenders

For researchers investigating this particular sample, the following indicators are useful:

Filename

NextGen_mParivahan.apk

SHA-256

90dd5ba11e3f8ae26bc12719d799c0fd1c1a9d4de6b378a255e4ad338eca95ef

MD5

7eb78622a9fe328692684e22a4ea7e73

Package

com.bum029.bsqj1m

Embedded payload

assets/4yhSF0XrpYFNbefj

Companion artifact

assets/e6wOVmgSLN7CNGUD

Certificate identity

CN=Release, O=Android, C=US

These should be treated as sample-specific indicators, not universal signatures for every fake mParivahan campaign.

What Defenders Should Look For

When investigating suspicious Android packages, don’t stop at the obvious.

1. Verify the publisher identity

Don’t trust:

• Filename
• Icon
• Application name
• WhatsApp sender
• Website branding

Check:

• Package name
• Signing certificate
• Certificate fingerprint
• Distribution source

2. Inspect the APK as a ZIP archive

Look for:

• Inconsistent compression flags
• Impossible file sizes
• Duplicate entries
• Suspicious timestamps
• Randomly named assets
• Nested archives
• Unexpected binary blobs

Archive-level anomalies can reveal anti-analysis techniques before the application code is even examined.

3. Search for staging mechanisms

Pay particular attention to combinations involving:

• Cipher
• SecretKeySpec
• IvParameterSpec
• DexClassLoader
• PathClassLoader
• PackageInstaller
• REQUEST_INSTALL_PACKAGES
• dynamically loaded DEX files

None of these APIs is malicious by itself.

The combination and execution path are what matter.

4. Extract before you execute

If an encrypted payload can be recovered statically, analyze it separately.

Don’t immediately detonate suspicious samples on a personal phone.

Use an isolated analysis environment with:

• A disposable Android emulator
• Network monitoring
• DNS logging
• HTTP/S interception where appropriate
• Snapshot/revert capability
• No personal accounts
• No real banking applications
• No production credentials

The goal is to observe the malware without giving it anything valuable.

If You Already Installed It

If this APK has already been installed on a real device, treat it as a potential compromise, particularly if you granted permissions or the application installed a second package.

At minimum:

1. Disconnect the device from the internet.
2. Do not enter banking credentials or UPI PINs on it.
3. From a clean device, review bank and UPI activity.
4. Contact your bank immediately if you see unauthorised transactions.
5. Preserve the APK and its hash for investigation.
6. Check for unfamiliar applications and recently granted permissions.
7. If compromise is confirmed, consider professional forensic examination or a factory reset rather than assuming that uninstalling the visible application removed everything.

If money has been lost to a suspected cyber-fraud incident in India, report it immediately through 1930 and the National Cyber Crime Reporting Portal.

Final Thoughts

The most revealing thing about this APK isn’t the AES encryption.

It isn’t the randomized class names.

It isn’t even the fake mParivahan branding.

It’s the architecture.

The attacker has separated the operation into stages:

social engineering → decoy → anti-analysis → encrypted payload → decryption → package installation → second-stage execution

That separation makes the malware harder to inspect and easier to disguise.

It also exposes a weakness in the way we often think about malicious applications.

We tend to ask:

“What does this app do?”

With a dropper, that’s the wrong question.

The better question is:

“What is this app designed to deliver?”

Because sometimes the application sitting in front of you isn’t the weapon.

It’s the delivery mechanism.

And when a supposedly official government APK arrives through WhatsApp, contains manipulated archive metadata, hides a multi-megabyte encrypted payload, and has the ability to install another package, the safest assumption isn’t that you’ve discovered an unusually complicated government app.

You’ve discovered something that really doesn’t want to be inspected.

And that’s usually a very good reason to keep it off your phone.

Note: This is merely a static analysis, stay tuned for second part where we detonate the suspicious apk file. see y’all in second part.