RTO-challan APK Malware Analysis : Static analysis Writeup #1

So I got this APK from my friend, and at that time I was starting my android malware analysis journey, so I thought why not analyze it. Never thought that I’ll face such a complex and encrypted APK. So please , read the analyst note in the end

Date: February 23, 2026

Sample: rto-challan.apk

SHA256: 5ff43ebecd36e2c89ff0163828e995b4438e3fa2ea24f9c88b4bc2618c9352a9

Executive Summary

This writeup covers static of rto-challan.apk, an Android malware sample disguised as a government traffic challan payment app targeting Indian vehicle owners.

The sample is not a simple piece of malware. It combines four techniques in one package: ZIP Slip path traversal, zip bomb resource exhaustion, Unicode-based filename obfuscation, and a nested encrypted payload. Standard analysis tooling fails against it by design. The inner ZIP/JAR container was partially confirmed through AES-CBC decryption

Threat level: High. Any system that extracted or scanned this APK should be treated as potentially compromised.

1. Initial Triage

Basic integrity check:

unzip -t rto-challan.apk

Every entry returned OK ,meaning the ZIP structure is intact and readable , but this tells us nothing about whether the contents are safe. The real concern became apparent when looking at the actual file listing hundreds of maliciously crafted paths sitting alongside a handful of genuine entries.

Legitimate entries:

• assets/dexopt/baseline.prof / baseline.profm
• DebugProbesKt.bin
• Standard AndroidX and Kotlin version metadata
• kotlin-tooling-metadata.json

Immediately suspicious:

• assets/aappppjijwijiwwerajdnjw — randomised name, 8.8 MB
• assets/kkywuwriowensonos — randomised name, 16 bytes

Two asset files with gibberish names, one large and one small — consistent with a payload and accompanying data, though not confirmed at this stage.

Virustotal Report

VirusTotal flagged the sample at 9/64 — confirming this is a detected malicious sample before any structural analysis begins.

2. ZIP Structure — The Attack Surface

2.1 ZIP Slip (Path Traversal)

The archive contains hundreds of entries with crafted paths designed to escape the extraction directory on vulnerable parsers:

/AndroidManifest.xml/@@@.xml         ← absolute path, targets filesystem root
/resources.arsc/!!!!!.xml            ← absolute path
AndroidManifest.xml/%%.xml           ← relative traversal attempt
classes.dex/><><><><.png             ← DEX file used as directory name
classes3.dex/​.9.png                ← zero-width space embedded in filename

ZIP parsers that do not sanitise entry paths will extract /AndroidManifest.xml/@@@.xml directly to the filesystem root rather than inside the intended output directory. On a vulnerable system this enables arbitrary file write anywhere - which can be chained into remote code execution by overwriting executables or startup scripts.

2.2 Nested File-as-Directory Confusion

Critical Android files are used as directory names, with malicious files placed inside them:

classes.dex/><><><><.png
META-INF/CERT.RSA/classes.dex.9.png
META-INF/androidx.appcompat_appcompat.version/classes.dex.xml

A validator might identify classes.dex as a safe file during the scan phase, while the extractor then processes classes.dex/ as a directory — writing nested files to wherever that path resolves. This exploits the inconsistency between validation and extraction logic in many security tools.

3. Obfuscation

3.1 Zero-Width Unicode Characters

Filenames embed invisible Unicode characters to break string matching in security filters:

Real examples from the archive:

res/values/arrays.xml/​.xml          ← ZW space in filename
‌A‌n‌d‌r‌o‌i‌d‌M‌a‌n‌i‌f‌e‌s‌t‌.‌x‌m‌l‌   ← every character separated by ZWNJ

The second example renders visually as AndroidManifest.xml but is a completely different byte sequence — effective against any AV performing byte-level signature matching.

3.2 Multi-Script Filenames

The archive cycles through Unicode scripts to generate thousands of distinct filenames that defeat pattern-based detection like these :

• Arabic: ا.xml
• Hebrew: א.xml
• Devanagari: क़ख़ग़ज़, ड़ढ़फ़य़, ऩऱऴळ
• CJK (Chinese): 零壹贰叁, 一, 㐀
• Japanese Hiragana/Katakana: あ, ぁ, ア, ァ
• Mathematical symbols: ∀∁∂∃∄, ⊕⊖⊗⊘⊙
• Box drawing: ░▒▓█▀, ▄▌▐■□
• Enclosed alphanumerics: ①②③④⑤, ⅠⅡⅢⅣⅤ, ⓐⓑⓒⓓⓔ
• Emoji: 🔒, 🔓, 🗝️, 🔐, ⚠️, ⛔, 🚫, ❌, ㊙️, 🈲

3.3 Special Character Filenames

Every directory contains entries with pure symbol names:

lib/####.png                    assets/---.png
lib/armeabi-v7a/||||.xml        res/menu/@#$%.xml
res/mipmap-hdpi/!@#$%^.9.png

3.4 System File Mimicry

Entries masquerade as artifacts that analysts commonly skip and scanners often whitelist:

res/layout-large/__MACOSX.xml
res/layout-sw600dp/.DS_Store.9.png
res/menu/Thumbs.db.xml
res/mipmap-mdpi/.git.xml
res/raw/.gradle.xml

3.5 Legitimate SDK Camouflage

The outer APK bundles genuine Google and Android libraries — Firebase Analytics, Firebase Messaging, Google Play Services, and the full AndroidX suite — to appear legitimate to automated scanners and casual reviewers.

4. Tool Failures

Standard tooling failed across the board, which is itself a strong signal of how deliberately hardened this sample is:

Tool and their results

7z extracted the DEX files other tools could not reach — but they appeared as directories rather than regular files, with malicious entries nested inside. The ZIP Slip attack was working exactly as designed.

5. Suspicious Asset Files

Two files in the assets/ directory stand out and are worth documenting, though their exact role could not be confirmed through static analysis alone.

5.1 kkywuwriowensonos

Size: 16 bytes
Hex:  79 68 b8 6f 41 d0 fc c5 e7 05 2d a0 17 c0 2d 2b

16 bytes matches the size of an AES-128 key, an MD5 hash, a UUID, or a random nonce. The size alone is not enough to confirm function. What would actually support the key hypothesis is finding references to this file in decompiled classes.dex — specifically a code path that reads it and passes its contents to a cipher initialisation call. This was confirmed indirectly when AES-CBC decryption using this file as the key successfully produced a valid ZIP/JAR structure — see Section 6.

5.2 aappppjijwijiwwerajdnjw

Size:        8,825,296 bytes (8.8 MB)
First bytes: 9c 96 74 13 43 ce 9b fa 09 b5 4f 72 aa be d9 6c

The 9c96... header matches no known file format magic. High entropy and an unrecognised header are consistent with encryption — but also with compression, a custom binary format, or deliberate garbage. An entropy measurement sitting near 8.0 bits/byte would strengthen the encryption hypothesis.

Get Kurious Kakashi’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Metadata IOCs identified regardless of content:

• APKEditor signatures present — the APK was repacked using a tool commonly used to inject malicious payloads into legitimate app shells
• Adobe XMP metadata timestamp: December 2025 — approximate build/repack date

DIE (Detect It Easy) analysis confirmed:

• Compiler: dexlib2 — consistent with APKEditor repacking, not standard Android Studio compilation
• No DEX packer detected — encryption is at asset level, not DEX level
• Target SDK: Android 4.0.1–4.0.2 — unusually old minimum target, maximises malware distribution surface

URLs extracted from asset strings (urls.txt):

• http://ns.adobe.com/photoshop/1.0/
• http://ns.adobe.com/xap/1.0/
• http://ns.adobe.com/xap/1.0/mm/
• http://ns.adobe.com/xap/1.0/sType/ResourceEvent
• http://purl.org/dc/elements/1.1/
• https://github.com/REAndroid/APKEditor
• https://github.com/REAndroid/APKEditor/P
• https://github.com/REAndroid/APKEditorq
• http://www.w3.org/1999/02/22-rdf-syntax-ns

Domains extracted (domains.txt):

• github.com
• ns.adobe.com
• purl.org
• www.w3.org

IP extraction result: No IPs found in static strings — consistent with C2 addresses being resolved at runtime rather than hardcoded.

IOC extraction via grep confirms the APKEditor and Adobe XMP strings directly — visible evidence of the repacking signatures referenced above.

5.3 Certificate Field Anomalies

Inspection of X.509 certificate fields embedded in the APK signing chain revealed generic placeholder values consistent with automated repackaging:

• Subject CN values: microsoft1, david0, android1, china1, tyoko1
• Validity timestamps: 251220054129Z / 20530507054129Z0c1

These are not legitimate issuer identities. The CN strings are throwaway labels commonly inserted by APKEditor and similar repacking tools when resigning an APK with a generated certificate rather than a real developer key. The validity window stretching to 2053 is also characteristic of auto-generated certs designed to never expire during the malware’s operational lifetime. This corroborates the APKEditor repacking finding from Section 5.2 and provides an additional attribution indicator.

6. Decryption Attempts

Multiple approaches were attempted against the large asset file using the 16-byte file as a candidate key:

# AES-ECB
cipher = AES.new(key, AES.MODE_ECB)

# AES-CBC with embedded IV
iv = encrypted_data[:16]
cipher = AES.new(key, AES.MODE_CBC, iv)
# AES-CBC with zero IV
iv = b'\x00' * 16
cipher = AES.new(key, AES.MODE_CBC, iv)
# Single-byte XOR brute force
decrypted = bytes([b ^ key for b in encrypted])
# Multi-byte XOR with key file as repeating key
decrypted = bytes([b ^ xor_key[i % len(xor_key)] for i, b in enumerate(encrypted)])

ECB and XOR attempts produced no recognisable output — confirmed by absence of valid magic bytes (DEX dex\n or ZIP PK\x03\x04) in the decrypted output. AES-CBC succeeded — producing a valid ZIP/JAR structure from the encrypted asset, confirmed by magic byte match. This confirms that kkywuwriowensonos functions as an AES-CBC key and that aappppjijwijiwwerajdnjw is the encrypted inner container.

Running strings on the raw asset prior to decryption produced 610KB of output consisting almost entirely of garbage, with no readable URLs, C2 addresses, package names, or credentials visible — consistent with strong encryption holding until the correct algorithm was applied.

Custom python script

7. Dropper Architecture (Confirmed)

AES-CBC decryption of the large asset file produced a ZIP/JAR format container — confirmed by magic byte match. The extracted structure exhibited identical ZIP Slip and obfuscation characteristics to the outer APK, suggesting a nested dropper architecture. Whether this container is a fully valid APK and whether it is independently executed at runtime was not confirmed through static analysis alone.

rto-challan.apk  (Outer Dropper — 11 MB)
│
├── assets/kkywuwriowensonos         ← AES-CBC key (confirmed)
├── assets/aappppjijwijiwwerajdnjw   ← AES-CBC encrypted container (confirmed by decryption)
│              │
│              └── inner ZIP/JAR container — ( confirmed by magic byte match )
│                         │
│                         ├── identical ZIP Slip structure
│                         └── DEX files (runtime execution unconfirmed statically)
│
└── classes.dex  ← likely contains runtime decryption logic
                   (decompilation was attempted but not completed)

The outer classes.dex likely contains the runtime decryption routine that unpacks and executes the inner container — however JADX decompilation of classes.dex was attempted but did not complete successfully, so this remains an inference rather than a directly confirmed finding. Dynamic sandbox analysis confirmed C2 communication from the executed sample — see Section 10.

8. Zip Bomb Characteristics

Beyond path traversal, the volume of archive entries creates resource exhaustion risk:

• Hundreds of entries force sequential processing, consuming CPU
• Deeply nested Unicode paths require recursive parsing
• AV engines that auto-decompress APKs for scanning may be crashed or rendered non-functional
• On a vulnerable system, full extraction could consume available disk space and corrupt other applications

Note: These impacts describe the structural risk based on confirmed archive characteristics. Resource exhaustion was not triggered during this analysis.

9. Attack Surface Summary

10. Behavior Report Findings (VirusTotal)

Dynamic analysis via VirusTotal’s behavior report confirmed active C2 communication at runtime. These findings are sourced from third party sandbox engines integrated into VirusTotal rather than direct execution by VirusTotal itself.

MITRE ATT&CK techniques observed:

The C2 IPs observed in sandbox traffic should be treated as active indicators of compromise. Any outbound connections to these addresses from a production environment indicate a compromised device.

Network IOCs (C2 IPs observed in sandbox traffic):

• 64.233.181.106:443
• 173.194.194.94:443
• 172.67.151.52:443
• 173.194.193.138:443
• 104.21.64.137:443
• 173.194.206.106:443
• 142.251.189.95:443

11. Delivery Context

The filename is socially engineered. RTO traffic challans are a common concern for Indian vehicle owners, and SMS/WhatsApp phishing campaigns impersonating government services are widespread. The likely delivery message:

“Your vehicle has an unpaid traffic challan. Download and pay via this official app to avoid legal action.”

This provides a believable reason to sideload an APK from an untrusted source, bypassing Google Play entirely.

The delivery mechanism described above is an assessment based on the filename and known phishing patterns targeting Indian users.

Tools Used

unzip, 7z, xxd, strings, Python 3, pycryptodome, jadx (attempted), apktool (attempted) , VirusTotal (static triage + behavior report)

Analysis conducted February 23, 2026. Static analysis findings are documented in Sections 1–9. Behavior Report Findings (VirusTotal) are documented in Section 10.

Analyst Note

This is my first malware analysis writeup and my first attempt at analyzing a sample of this complexity. Several areas of this analysis remain incomplete — classes.dex was not successfully decompiled, the manifest could not be extracted due to ZIP-level encryption on protected entries, and the full execution chain of the inner container was not traced statically.

Further analysis of this sample requires solving the ZIP-level encryption barrier before deeper static analysis is possible. Next steps will focus on building foundational analysis skills on simpler unencrypted samples before returning to this one.

Despite these gaps, the core findings — ZIP Slip structure, AES-CBC encrypted nested container, APKEditor repacking signatures, certificate anomalies, and confirmed C2 communication — are all evidence-backed and documented with supporting screenshots.

If you made it this far, might as well check out my GitHub for my projects 👉 github.com/gigachad80