sanchar saathi android app - comprehensive security & privacy analysis
the sanchar saathi app is a government utility mandated by the department of telecommunications for device verification and fraud reporting. this comprehensive analysis examines the decompiled source code to understand its data collection practices, security posture, and potential privacy implications.
app information
- version: 1.5.0
- package: com.dot.app.sancharsaathi
- developer: c-dot (centre for development of telematics)
- department: department of telecommunications, government of india
executive summary
this analysis examines the decompiled source code to understand data collection practices, security posture, and potential privacy implications of the sanchar saathi application.
key findings
π΄ critical: full sms body and call log access
the app has complete access to sms message content and call logs including contact names, going beyond basic verification needs.
π high: persistent device identifier via mediadrm
uses mediadrm uuid for permanent device tracking that survives factory resets on some devices.
π’ positive: sqlcipher encryption for local storage
implements aes-256 encryption for local database, protecting data from device theft.
π medium: no certificate pinning
vulnerable to man-in-the-middle attacks if malicious ca certificate is installed.
π‘ low: comprehensive root/tamper detection
implements multiple checks for rooted devices and system tampering.
verdict
safe for intended use - the app is a legitimate government utility with no evidence of malicious behavior. however, it requires extensive permissions that grant access to highly sensitive user data. users should understand the scope of data collection before installation.
background & context
why this analysis?
the government is mandating companies to install sanchar saathi, raising concerns about:
- privacy: what data does it collect?
- surveillance: can it be used for mass surveillance?
- security: is the data protected?
- transparency: what happens to collected data?
app purpose
according to official documentation:
- verify mobile device genuineness (imei validation)
- report lost/stolen phones
- fraud reporting via "chakshu" feature
- know your mobile (kym) registration
decompilation source
source code access
the apk was decompiled using decompiler.com and the complete source code is available on github for transparency and verification.
- github repository: devzoy/sanchar-saathi-decompiled
- apk hash: 0414ad43793f457cba391a4c029b8a19
- official app: google play store
permission analysis
declared permissions
the AndroidManifest.xml declares the following permissions with
varying levels of risk:
read_sms (π΄ dangerous)
stated purpose: verify sms delivery
actual usage: reads full sms body
necessity: β οΈ excessive
read_call_log (π΄ dangerous)
stated purpose: fraud reporting
actual usage: reads call history with names
necessity: β οΈ feature-specific
read_phone_state (π΄ dangerous)
stated purpose: imei verification
actual usage: accesses imei/imsi
necessity: β necessary
camera (π dangerous)
stated purpose: scan barcodes
actual usage: qr/barcode scanning
necessity: β necessary
access_fine_location (π dangerous)
stated purpose: location tagging
actual usage: fraud report location
necessity: β feature-specific
permission request flow
%%{init: {'theme':'dark', 'themeVariables': { 'actorBkg':'#1e40af','actorBorder':'#3b82f6','actorTextColor':'#fff','actorLineColor':'#60a5fa','signalColor':'#60a5fa','signalTextColor':'#fff','labelBoxBkgColor':'#374151','labelBoxBorderColor':'#60a5fa','labelTextColor':'#fff','loopTextColor':'#fff','noteBorderColor':'#10b981','noteBkgColor':'#065f46','noteTextColor':'#fff','activationBorderColor':'#10b981','activationBkgColor':'#065f46','sequenceNumberColor':'#fff','fontSize':'15px'}}}%%
sequenceDiagram
participant U as π€ User
participant F as π± Flutter UI
participant S as βοΈ SathiMainActivity
participant A as π Android System
U->>F: Initiate feature
(e.g., Fraud Report)
activate F
F->>S: Request permission
via MethodChannel
activate S
S->>A: requestPermissions()
activate A
A->>U: Show permission dialog
deactivate A
U->>A: Grant/Deny
activate A
A->>S: onRequestPermissionsResult()
deactivate A
S->>F: Return permission status
deactivate S
F->>U: Enable/Disable feature
deactivate F
code reference: SathiMainActivity.java:240-297
data collection & privacy
1. sms data extraction
code location: sources/Q3/c.java
β οΈ critical finding
the app reads the complete message body, not just metadata. this goes beyond "verification" and constitutes full sms surveillance capability.
// Q3/c.java - Lines 28-47
Cursor query = context.getContentResolver().query(
Telephony.Sms.Inbox.CONTENT_URI,
new String[]{"address", "body", "date"},
"sub_id = ? AND date >= ?",
strArr,
"date DESC LIMIT " + Integer.toString(i5)
);
// Extracts:
hashMap.put("ADDRESS", string); // Sender phone number
hashMap.put("BODY", string2); // FULL MESSAGE BODY
hashMap.put("DATE24HR", format); // Timestamp
hashMap.put("DATE12HR", format2); // Formatted timestamp
what it collects:
- address: sender phone number (π΄ reveals contacts)
- body: full message content (π΄ complete surveillance)
- date: timestamp (π activity timeline)
- filter: last 29 days (~1 month of data)
2. call log extraction
code location: sources/Q3/b.java
// Q3/b.java - Lines 31-72
Cursor query = context.getContentResolver().query(
CallLog.Calls.CONTENT_URI,
new String[]{"number", "date", "duration", "name", "type"},
bundle,
null
);
// Extracts:
hashMap.put("NUMBER", string); // Phone number
hashMap.put("DURATION", str2); // Call duration
hashMap.put("CACHED_NAME", string3); // Contact name from phonebook
hashMap.put("CALL_TYPE", callType); // MISSED/REJECTED/INCOMING
hashMap.put("DATE24HR", format); // Timestamp
what it collects:
- number: phone number (π΄ reveals contacts)
- cached_name: contact name from phonebook (π΄ identity exposure)
- duration: call duration (π communication patterns)
- call_type: missed/rejected/incoming (π behavioral data)
- filter: last 29 days, incoming only
3. persistent device tracking
code location: SathiMainActivity.java:318-324
// SathiMainActivity.java - Lines 318-324
try {
return Base64.encodeToString(
new MediaDrm(new UUID(-1301668207276963122L, -6645017420763422227L))
.getPropertyByteArray("deviceUniqueId"),
2
);
} catch (Exception unused) {
return "";
}
}
β οΈ critical finding
this creates a permanent device identifier that, when combined with phone number, sim info, sms, and call logs, enables comprehensive user profiling.
tracking details:
- method: mediadrm uuid (π΄ persistent across factory resets)
- uuid: widevine drm id
- persistence: survives factory reset on some devices (π΄ permanent tracking)
- uniqueness: device-specific (π΄ cannot be changed)
- purpose: device fingerprinting (π΄ cross-app tracking possible)
4. sim card information
code location: SathiMainActivity.java:330-347
// SathiMainActivity.java - Lines 330-347
public final String n0(Context context) {
HashMap hashMap = new HashMap();
SubscriptionManager subscriptionManager =
(SubscriptionManager) context.getSystemService(SubscriptionManager.class);
List<SubscriptionInfo> activeSubscriptionInfoList =
subscriptionManager.getActiveSubscriptionInfoList();
for (SubscriptionInfo next : activeSubscriptionInfoList) {
int simSlotIndex = next.getSimSlotIndex(); // SIM slot (0/1)
String charSequence = next.getCarrierName().toString(); // Carrier name
next.getSubscriptionId(); // Subscription ID
hashMap.put(String.valueOf(simSlotIndex), charSequence);
}
return hashMap.toString();
}
what it collects:
- sim slot index: 0, 1 (π‘ dual sim detection)
- carrier name: "airtel", "jio" (π service provider tracking)
- subscription id: unique sim identifier (π sim tracking)
data flow diagram
%%{init: {'theme':'dark', 'themeVariables': { 'primaryColor':'#3b82f6','primaryTextColor':'#fff','primaryBorderColor':'#2563eb','lineColor':'#60a5fa','secondaryColor':'#10b981','tertiaryColor':'#ef4444','noteBkgColor':'#1f2937','noteTextColor':'#fff','fontSize':'16px'}}}%%
flowchart LR
A["π€ User Device"] -->|"1. SMS Content"| B["π§ Q3/c.java"]
A -->|"2. Call Logs"| C["π Q3/b.java"]
A -->|"3. Device UID"| D["π MediaDrm"]
A -->|"4. SIM Info"| E["π± SubscriptionManager"]
A -->|"5. IMEI/IMSI"| F["π‘ TelephonyManager"]
B --> G["ποΈ SQLCipher DB"]
C --> G
D --> G
E --> G
F --> G
G -->|"When Online"| H["π NetworkWorker"]
H -->|"HTTPS"| I["π api.sancharsaathi.gov.in"]
style A fill:#1e40af,stroke:#3b82f6,stroke-width:3px,color:#fff
style B fill:#374151,stroke:#60a5fa,stroke-width:2px,color:#fff
style C fill:#374151,stroke:#60a5fa,stroke-width:2px,color:#fff
style D fill:#374151,stroke:#60a5fa,stroke-width:2px,color:#fff
style E fill:#374151,stroke:#60a5fa,stroke-width:2px,color:#fff
style F fill:#374151,stroke:#60a5fa,stroke-width:2px,color:#fff
style G fill:#065f46,stroke:#10b981,stroke-width:3px,color:#fff
style H fill:#374151,stroke:#60a5fa,stroke-width:2px,color:#fff
style I fill:#991b1b,stroke:#ef4444,stroke-width:3px,color:#fff
security assessment
1. local data protection
β sqlcipher encryption
the app uses sqlcipher for database encryption, which is a positive security practice.
- encryption: β implemented (aes-256)
- key management: β οΈ unknown (likely in flutter layer)
- protection: π’ good (protects against device theft)
2. network security
β no certificate pinning
file: network_security_config.xml
- cleartext traffic: β disabled (good - forces https)
- certificate pinning: β not implemented (π΄ vulnerable to mitm)
- trust store: system cas (β οΈ trusts all system cas)
β οΈ risk
without certificate pinning, the app is vulnerable to man-in-the-middle attacks if a malicious ca certificate is installed on the device.
3. root detection
β comprehensive checks
code location: SathiMainActivity.java:181-328
the app implements multiple detection methods:
- build.tags contains "test-keys" (detects custom roms)
- system properties (ro.debuggable, ro.secure)
- world-writable directories (tampered system partition)
- su binary paths (/system/bin/su, /system/xbin/su, /sbin/su)
- root management packages (magisk, supersu, etc.)
- superuser apks
risk assessment
privacy risks
sms surveillance (π΄ critical)
severity: critical | likelihood: high
impact: full message content accessible
mitigation: runtime permissions, user awareness
call log profiling (π΄ critical)
severity: critical | likelihood: high
impact: communication patterns revealed
mitigation: feature-specific permission request
persistent tracking (π high)
severity: high | likelihood: high
impact: cross-session user profiling
mitigation: none (inherent to mediadrm)
data breach (π high)
severity: high | likelihood: medium
impact: sensitive data exposure if backend compromised
mitigation: sqlcipher encryption, https
mitm attack (π medium)
severity: medium | likelihood: low
impact: data interception if malicious ca installed
mitigation: implement certificate pinning
overall risk score
π medium-high risk
the app is not malicious but has extensive surveillance capabilities that could be misused if:
- backend is compromised
- data retention policies are unclear
- access controls are weak
recommendations
for users
β grant permissions only when needed
priority: π΄ high
minimize data exposure by granting permissions only when actively using features.
β review permissions regularly
priority: π medium
revoke unused permissions through android settings.
β use for intended purpose only
priority: π medium
avoid unnecessary features to minimize data collection.
β οΈ understand data collection scope
priority: π΄ high
sms/call logs are fully accessible when permissions are granted.
conclusion
summary
the sanchar saathi app is a legitimate government utility with no evidence of malicious behavior. the app functions as intended for device verification and fraud reporting. however, it possesses extensive data collection capabilities that raise significant privacy concerns.
β οΈ the surveillance anlogy
to understand the privacy implications in simple terms, consider this scenario:
imagine the government, concerned about rising domestic violence cases, mandates that every household in india must install a security camera inside their home. they assure you: "don't worry, the footage will only be accessed when you request it for your safety."
while the stated purpose is legitimate, the infrastructure for surveillance is now in place. the camera is always there, always recording, always capable of being accessed. you're asked to trust that it will only be used as promised.
this is the sanchar saathi situation. the app works for its intended purpose today, but it has built-in capabilities to:
- read every sms you receive
- access your complete call history with contact names
- track your device permanently, even after factory reset
- monitor your sim cards and network providers
the core issue isn't the current functionalityβit's the future potential. if the government pushes an update tomorrow, they have the infrastructure to enable mass surveillance. the fact that companies are being forced to pre-install this app means users don't even have a choice to opt out.
the trust question
if you trust that the government will never misuse these capabilities, never expand the scope beyond the stated purpose, and never succumb to the temptation of having such powerful surveillance tools at their disposal, then the app poses minimal risk.
however, history has shown that surveillance infrastructure, once built, tends to expand in scope. the question isn't whether the app is malicious todayβit's whether you're comfortable with the power it grants for tomorrow.
β positive aspects
- sqlcipher encryption for local data
- cleartext traffic disabled (https enforced)
- root detection for security
- no unprotected exported components
β οΈ concerns
- full sms body access (not just metadata)
- call log with contact names
- persistent device tracking via mediadrm
- no certificate pinning
- unclear data retention policy
final verdict
safe for intended use, but users should:
- understand the scope of data collection
- grant permissions only when using specific features
- trust the government's data handling practices
transparency note
this analysis is based on static code analysis of the decompiled apk. dynamic analysis (runtime behavior monitoring) would provide additional insights into actual network traffic, backend api endpoints, data encryption in transit, and server-side data storage.
disclaimer
this analysis is for educational and security research purposes only. the findings are based on static code analysis and may not reflect runtime behavior. users should make informed decisions based on their own risk assessment.
π¨ spread awareness
this is a matter of digital privacy for every indian. share this analysis to help others understand what's being installed on their phones.
π copy link to share:
π‘ tag journalists and privacy advocates when sharing on social media to amplify the message