Security & Privacy

sanchar saathi android app - comprehensive security & privacy analysis

dec 02, 2025 β€’ 25 min read
Sanchar Saathi Android App Security 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.


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

external references