Ye command aapke connected Android device ya emulator par DIVA APK install kar dega.
Diva Android App
Is article mein, main DIVA Android app ke baare mein baat karunga jo Github user payatu ne develop ki hai. Is app ka purpose developers aur security enthusiasts ko Android vulnerabilities ke baare mein seekhne mein madad karna hai — wo bhi ek jaan bujh kar vulnerable banayi gayi Android application ko evaluate karke. Installation section mein application ke Github repository ka link diya gaya hai, jahan pe aapko un vulnerabilities ki list milegi jo currently is app mein maujood hain.
Disclaimer
Mujhe ye article likhne ki motivation isliye mili kyunki main Android mobile application security ko aur achhe se samajhna chahta tha. Ye article obviously aapko DIVA Android application mein jo vulnerabilities hain, unhe solve karne mein madad karega.
Main readers ko yeh encourage karta hoon ki jitni zyada vulnerabilities khud se exploit kar sakein, utni karein — aur agar kahin atak jaayein ya kisi vulnerability ko exploit karne ka ek alag approach dekhna ho, to phir baad mein waapas aake is article ko padhein.
Chalo, bina time waste kiye installation se shuru karte hain 😁
Installation
Is section mein main un sabhi applications ka zikr karunga jo main vulnerability testing ke liye use karne wala hoon.
1. Android Studio
Agar aapke system mein Android Studio installed nahi hai, to yahan click karo usse download karne ke liye.
2. SDK Platform Tools
SDK Platform Tools download karne ke liye yahan click karo.
Download hone ke baad, platform tools ko extract karo aur us folder ko Environment Variables ke path mein add kar do.
3. DIVA APK
DIVA ka APK file download karne ke liye yahan click karo, ye GitHub se milega.
4. JADX-GUI
JADX GUI ek decompiler hai jo APK ko read karne mein madad karta hai. Use download karne ke liye yahan click karo.
5. APKTool
Yahan humein do files download karni hongi:
Pehla file
apktool.jarhai – usse download karne ke liye yahan click karo.Dusra file ek
.zipformat mein hoga – uske liye yahan click karo.
Ab:
apktool.jarko locate karo aur usse Windows directory mein copy kar do.Phir
apktool.batko locate karo jo milegaApktool\scripts\windowsfolder mein – usse bhi Windows directory mein copy kar do.Ab Windows path ko bhi Environment Variables ke path mein add kar lo.
6. Java Runtime Environment (Optional)
Agar aapke system mein Java JDK Development Kit installed nahi hai to apktool kaam nahi karega.
Is problem ko solve karne ke liye yahan click karo aur Java install karo.
Install hone ke baad, Java ki installation directory ko bhi Environment Variables ke path mein add kar do.
How to install DIVA APK on the Android device
PowerShell open karo aur neeche diya gaya command run karo.
Mainne Android Debug Bridge (adb) ka use kiya apne emulator ko verify karne ke liye aur DIVA APK file install karne ke liye.
Note: Android Debug Bridge (adb) ek powerful command-line tool hai jo aapko device ke saath communicate karne deta hai. adb command ka use karke aap kai tarah ke actions perform kar sakte ho jaise apps install karna, debug karna, ya phir device ke Unix shell ko access karke commands run karna.
adb devices
Ye command batayega ki kya aapka Android device (ya emulator) system pe properly run ho raha hai ya nahi.
PowerShell ka use karke DIVA APK locate karo
PowerShell open karo aur us location par jao jahan DIVA APK file save hai.
Neeche diya gaya command run karo:
adb install diva-beta.apk
Successfully install hone ke baad, aapko DIVA app apne Android device mein dikhai deni chahiye.
Tap (Click) on the Diva app icon to launch the application.
1. INSECURE LOGGING
Sabse pehle, maine Jadx-gui ka use kiya source code read karne ke liye, taaki main wo vulnerable code identify kar sakun jo insecure logging ka reason ban raha hai.
Upar wali image se humein yeh clearly dikh raha hai ki insecure logging public void section mein ho rahi hai. Jab user apne credentials enter karta hai, to wo diva-log mein store ho jaate hain aur unhe string mein convert kar diya jaata hai — jisse wo easily kisi bhi insaan ke liye visible hote hain jo diva-log file tak access paa le.
Phir aap adb shell ps command run karte ho taaki running processes ki list mil sake aur aap process ID (PID) identify kar sako.
Shell permission ka use karke aap ye command run karte ho:
logcat | grep 6530
Yani aap us process se related logs capture karna chahte ho jo tab active hota hai jab user input form mein apne credentials daalta hai.
Note: Yahan 6530 ek example ke liye Process ID (PID) hai.
Logcat ek command-line tool hai jo system ke sare messages ka log dikhata hai — ismein wo messages bhi hote hain jo aapne khud apni app se Log class ka use karke likhe hote hain.
Conclusion :
Yeh dikhata hai ki credentials ya sensitive information ka logging secure nahi hai, jiski wajah se koi bhi insaan jo device ke logs dekh raha ho, unhe access kar sakta hai.
2. HARCODING ISSUES — PART 1
Sabse pehle, aap Jadx-gui ka use karte ho taaki application ke source code mein vulnerable code ki location find ki ja sake.
Upar wali image se yeh samajh aata hai ki jab user vendor key enter karta hai, to uske result ke basis par user ko ek response milta hai. Agar vendor key vendorsecretkey ke barabar hoti hai, to message aata hai: “Access granted! See you on the other side”, warna message hota hai: “Access Denied! See you in hell!”
Is explanation se yeh clear hai ki developer ne application ke source code mein hi correct vendor key chhod di hai, jisse koi bhi source code access karne wala easily sahi key nikaal sakta hai.
Yeh wahi feedback hai jo user ko milta hai jab wo correct vendor key ke saath successfully login karta hai.
Yeh woh feedback hai jo user ko tab milta hai jab wo galat vendor key ke saath login karne ki koshish karta hai:
“Access Denied! See you in hell!”
3. INSECURE DATA STORAGE — PART 1
Jadx-gui ka use karke jab hum application ka source code read karte hain, to humein wo directory dikhai deti hai jahan user ke credentials store hote hain. Aur apne terminal ka use karke hum root access le kar Android device mein us directory ki exact location find kar sakte hain.
Neeche wali image mein dikhaya gaya hai ki user ne kya details provide ki hain aur Save button click karne ke baad kya response mila hai.
adb shell run karo taaki Android device par root access mil sake aur ls run karo taaki directory ke saare files list ho sakein.
Next, cd data/data/ run karo taaki us directory mein enter kar sako aur ls run karo taaki directory ke saare files list ho sakein.
cd jakhar.aseem.diva run karo taaki us directory mein enter kar sako aur ls run karo taaki us directory ke saare files list ho sakein.
Upar wali image se humein shared preferences directory mil gayi.
Us directory ko access karne ke liye, cd shared_prefs run karo aur ls run karke directory ke andar ke items dekh sakte ho.
Ab cat jakhar.aseem.diva_preferences.xml run karo taaki aap XML file ko read kar sakein.
Conclusion: Plain text mein credentials store karna ek insecure tareeka hai data ko store karne ka.
4. INSECURE DATA STORAGE — PART 2
Sabse pehle, hum Jadx-gui ka use karenge source code ko analyze karne ke liye taaki application ki vulnerability ko identify kiya ja sake.
Upar wali image se humein stored credentials ka location dikh raha hai aur kaise unhe store kiya gaya hai, jo ki SQL database format mein hai. Ab hum root access gain karenge Android device par aur wo database locate karenge jahan ids2 stored hai, taaki dekh sakein ki wo ek directory hai ya ek readable file.
Root access gain karne se pehle, hum user credentials insert karenge taaki kuch data database mein save ho sake, phir us data ko locate karenge.
Sabse pehle, adb shell ka use karke device par root access gain karo. Phir, cd data/data/jakhar.aseem.diva/databases/ command run karo taaki directory mein jaa sako aur ls run karke us directory ke items list kar sako.
ls -la command run karo taaki directory mein maujood saare files aur items ko list kiya ja sake.
ids2 mein SQL format ko read karne ke liye, Android device se root access exit kar do aur file ko apne system par pull karo.
Run karo: adb pull /data/data/jakhar.aseem.diva/databases/ids2
Ab SQLite Viewer ka use karke ids2 file ko read karte hain. Website par jaane ke liye yahan click karo.
ids2 file ko drag aur drop karo, aur android_metadata ko myuser mein change karo taaki aap credentials dekh sakein.
5. INSECURE DATA STORAGE — PART 3
Jadx-gui ka use karke source code ko read karo taaki aap application ki vulnerability find kar sakein.
Humne yeh pata kiya ki application ne ek temp file create ki hai jiska naam uinfo hai.
Stored credential ko access karne ke liye, maine adb shell ka use karke Android device ka root access gain kiya.
Phir, cd data/data/jakhar.aseem.diva/ run karke application directory mein gaya aur ls -la run karke specified directory ke andar saare files aur directories ko list kiya.
Uske baad, cat uinfo44475423tmp run karke file ka content standard output par print kiya.
Conclusion: Upar wali image se humein dikh raha hai ki user credentials us location par present hain jo humein Jadx-gui ka use karke mili thi.
6. INSECURE DATA STORAGE — PART 4
Jadx-gui ka use karke application ka source code read karte hue, maine yeh pata kiya ki user credentials kis location par store ho rahe hain aur file ka naam kya hai, jo ki Android phone ke external storage device par hai.
Agar aap koi bhi credential input karne ki koshish karte ho, to aapko ek error milega kyunki application ko SD card par kisi bhi cheez ka password nahi diya gaya hai.
Application ke storage permission ko change karne ke liye, aapko Android device par settings mein jaakar app permissions ko modify karna padega. Yeh steps follow karo:
Settings mein jao.
Apps ya Applications section ko open karo.
Apne application ko search karo (jaise DIVA app).
Permissions section par click karo.
Yahan se Storage permission ko enable karo.
Isse application ko storage access mil jayega aur wo data ko read/write kar paayega.
Shuru karne ke liye, adb shell run karo taaki device ka root access gain kar sako aur phir ls command run karo taaki directory ke andar ke saare items list ho sakein.
cd mnt run karo taaki aap Android device ke external storage ko access kar sako, aur phir ls run karo taaki directory ke andar ke saare items list ho sakein.
Agla step hai, cd sdcard run karke directory mein enter karna aur phir ls -la run karke saare items ko list karna.
Uske baad, cat uinfo.txt run karo taaki file ka content standard output par print ho sake.
Conclusion: Aap dekh sakte hain ki agar aap ls command use karke directory ke items list karte ho, to uinfo.txt file nahi dikhayi degi. Isliye, agar aapko lagta hai ki file us directory mein ho sakti hai, to dono commands ko try karna recommended hai.
7. INPUT VALIDATION ISSUES — PART 1
Jadx-gui ka use karke jab aap application ka source code padhte ho, to aap notice karoge ki ye input validation SQL injection ke liye vulnerable hai. Saath hi, aap tino user credentials bhi easily database mein dekh sakte ho bina zyada deeply jaaye, jo ki credentials store karne ka secure tareeka nahi hai.
Chalo ek random user credential try karte hain aur dekhte hain ki humein kya response milta hai.
Ab chalo SQL injection ka use karke search validation ko bypass karte hain aur database mein maujood tino credentials ko nikalte hain.
8. INPUT VALIDATION ISSUES — PART 2
Ye challenge sensitive information ko access karne ke baare mein hai, jahan humein us file ka path use karna hai jisme sensitive data store hai. Chalo, pehle wale challenge (vuln 6) ka file path use karke try karte hain.
9. ACCESS CONTROL ISSUES — PART 1
Jadx-gui ka use karke jab maine application ka source code padha, toh mujhe vulnerable code mila jo ye batata hai ki API credentials ko access karne ke liye kya action perform ho raha hai.
Chalo PowerShell ka use karke API credentials access karne wali activity start karte hain.
Sabse pehle, adb shell run karo taaki Android device ka root access mil jaye.
Uske baad, yeh command run karo:
am start -a jakhar.aseem.diva.action.VIEW_CREDS
Iss command se directly activity start ho jaayegi jo normally “VIEW API CREDENTIALS” button se open hoti hai, aur hum usse bypass kar paayenge.
Kya aapko is step ke baad ka demonstration bhi chahiye?
Yeh hai result jo aapko pichle step ke baad milega.
Iska matlab hai ki aapne successfully “VIEW API CREDENTIALS” activity ko bypass kar liya hai aur credentials dekh pa rahe ho bina app ke normal UI flow follow kiye.
10. ACCESS CONTROL ISSUES — PART 2
Jadx-gui ka use karke jab hum application ka source code padhte hain, toh humein woh activity dikhai deti hai jo Tveeter API credentials ko view karne ke liye responsible hai. Lekin, humein us activity ko bypass karna padega jo Tveeter se milne wale pin ko maangti hai.
Maine Jadx-gui ka use karke “pin received from Tveeter” wali activity ko find kiya.
Ab hum PowerShell ka use karke bina application ke activity ko start karenge.
Pehle, adb shell run karo taaki Android device ka root access mil sake.
Uske baad ye command run karo:
am start -n jakhar.aseem.diva/.APICreds2Activity -a jakhar.aseem.diva.action/.VIEW_CREDS2 –ez check_pin false
Ye command us activity ko start karegi jo Tveeter ke API credentials ko dikhati hai.
Agar successful ho jata hai, toh aapko ye result milega.
11. ACCESS CONTROL ISSUES — PART 3
Jadx-gui ka use karke application ka source code padte hue, maine wo location find ki jahan pin store hota hai.
Run adb shell to get root access to the Android device.
Next, run cd data/data/jakhar.aseem.diva/shared_prefs/ to shared preferences folder ko access karne ke liye, phir ls run karo directory mein items list karne ke liye.
Run cat jakhar.aseem.diva_preferences.xml to xml file ko read karne ke liye.
Jadx-gui ka use karke, aap vulnerable code find kar sakte ho jisme private notes ko access kiya ja sakta hai bina user dwara banaye gaye pin ke.
Using content query, chalo vulnerable code run karte hain jo private notes ko access karega.
Run karo:
content query –uri content://jakhar.aseem.diva.provider
12. HARDCODING ISSUES — PART 2
Jadx-gui ko use karke application ke source code ko read karo.
Upar diye gaye image mein hum dekh sakte hain ki ek instance banaya gaya hai jiska naam “private DivaJni” hai. Agar hum private DivaJni ke source code ko dekhein, to humein pata chalta hai ki yeh ek soName ka use karta hai, jo system library mein located hai.
Jadx-gui mein “divajni” soName file ko locate karne ke liye, aapko resources > lib > x86 > libdivajni.so folder mein jaana hoga.
Device se file access karne ke liye, humein neeche diye gaye steps follow karne honge:
adb shell run karke device par root access lein.
Phir cd /data/data/jakhar.aseem.diva run karke directory mein enter karein, aur ls run karke directory ke items ko list karein.
Ab, cd lib run karke directory mein enter karein, phir ls run karke directory ke items ko list karein.
strings command ka use karke, hum file ke andar ka information padh sakte hain.
Run kijiye: strings libdivajni.so
Ab humein is file mein kai possible vendor keys mil gaye hain, aur unhe ek-ek karke try karna time-consuming ho sakta hai. Toh maine Diva Android repository par research kiya taaki pata chale ki vendor key application ke andar embedded hai ya nahi.
Google par “Diva” search karo aur “Payatu/diva-android” repository ko open karo, phir app/src/main/jni/divajini.c file par jao.
Agar tum source code ko dhyan se padho, toh tumhe vendor key embedded mil jayega. Ab hum woh key try karenge aur dekhenge ki humein kya response milta hai.
Agar tum woh vendor key use karoge jo application ke source code mein embedded thi, toh tumhe ye result milega.
13. Input Validation Issues — Part 3
Is application par denial of service attack karne ke liye, humein random numbers ko baar-baar run karna hoga, jitni baar chahein. Agar hum yeh ek ya do baar try karenge, toh application crash nahi hoga.
Lekin jab hum is process ko baar-baar repeat karenge, toh application overload ho sakta hai aur crash ho sakta hai.
Ab, hum random numbers ki sankhya badhate hain. Jab hum zyada random numbers ko baar-baar run karenge, toh yeh application ko zyada load dega, aur agar application is load ko handle nahi kar pata, toh woh crash ho sakta hai.
Is technique se denial of service attack ko effectively perform kiya ja sakta hai.
Result
1. Insecure Logging
Vulnerability: Log Injection
Description: Jab application sensitive information (jaise password ya personal data) ko log files mein bina proper protection ke store karti hai, toh attacker uss log file mein malicious data inject kar sakta hai. Isse log files corrupt ho sakti hain, sensitive data leak ho sakta hai, ya attacker ka code bhi execute ho sakta hai.
Example: Agar ek web application user inputs ko bina sanitize kiye log kar rahi ho, toh attacker easily malicious input inject kar sakta hai, jo baad mein administrator ke liye harmful ho sakta hai.
2. Hardcoding Issues
Vulnerability: Hardcoded Credentials (Password ya API Keys)
Description: Jab sensitive data jaise API keys ya passwords source code mein directly hardcode kiye jaate hain, toh koi bhi jo code ko access karega, wo easily sensitive information dekh sakta hai. Isse unauthorized access ka risk badh jaata hai.
Example: Agar ek mobile app ke source code mein API keys hardcoded hain, toh attacker un keys ko misuse kar sakta hai aur third-party services ka galat istemal kar sakta hai.
3. Insecure Data Storage
Vulnerability: Insecure Direct Object References (IDOR) ya Insecure Data Storage
Description: Jab sensitive data ko insecurely store kiya jaata hai, jaise plain text mein ya bina encryption ke, toh attacker easily uss data ko access kar sakta hai. Yeh risk badh jaata hai jab sensitive data ko proper encryption ke bina store kiya jaata hai.
Example: Agar user passwords ko plain text mein store kiya jaata ho ya weak hashing algorithms jaise MD5 ka use ho raha ho, toh attacker easily wo passwords retrieve kar sakta hai.
4. Input Validation Issues
Vulnerability: SQL Injection
Description: Input validation issues tab hoti hain jab user input ko sahi tarike se validate ya sanitize nahi kiya jaata. Isse attacker malicious code inject kar sakta hai (jaise SQL commands ya script code), jo data breach, unauthorized access, ya harmful commands ko execute kar sakta hai.
Example: Agar ek form field mein attacker
'; DROP TABLE users; --input kare, toh woh insecure SQL query ko manipulate kar ke database ko corrupt kar sakta hai.
5. Access Control Issues
Vulnerability: Broken Access Control
Description: Jab access controls properly implement nahi hote, tab users unauthorized resources access kar sakte hain. Iska matlab hai ki attacker apne privileges ko elevate kar sakta hai ya restricted data access kar sakta hai.
Example: Agar ek user jisko sirf apna account info dekhna chahiye, woh admin-level payment details dekh sakta hai, toh yeh access control issue hai.
| OWASP Category | DIVA Labs |
|---|---|
| M1: Weak Server Side Controls | – (DIVA me server-side control ka direct example kam hai, but intent hijacking aur poor backend validation indirectly touch karta hai) |
| M2: Insecure Data Storage | – InsecureDataStorage1 – InsecureDataStorage2 – InsecureDataStorage3 |
| M3: Insufficient Transport Layer Protection | – InsecureDataStorage3 (partly, if HTTP communication sniffing involved) |
| M4: Unintended Data Leakage | – InputValidationIssues – Logging Issues (agar koi specific task aaya) |
| M5: Poor Authorization and Authentication | – HardcodedAccessControl – InsecureActivityLaunch |
| M6: Broken Cryptography | – InsecureDataStorage2 (agar weak encryption use hui hai) |
| M7: Client Side Injection | – InputValidationIssues (jaise intent injection, parameter tampering) |
| M8: Security Decisions Via Untrusted Inputs | – HardcodedSecrets – InsecureActivityLaunch |
| M9: Improper Session Handling | – (Session management DIVA me explicitly nahi diya gaya, but storage of login data insecurely touch karta hai) |
| M10: Lack of Binary Protections | – HardcodedSecrets (reverse engineering se secrets nikalna) – General APK tampering |
Short samajh ke points:
Insecure Storage = Sab kuch jaise passwords, tokens bina encryption ke device pe store karna.
Insufficient Transport Protection = Agar app HTTP use kar rahi hai HTTPS ke bina.
Poor Auth/Authz = Jaise activities ko bina authentication ke access kar sakte ho.
Broken Cryptography = Weak encryption lagana ya insecure cryptographic practices.
Client-Side Injection = Jaise data directly trust kar lena input me aur execute karna.
Security Decisions via Input = App trust kar leti hai user ke input ya activity calls pe bina verify kare.
Lack of Binary Protections = App ka easily reverse engineer ho jaana (Hardcoded credentials etc.).
Quick Example:
Hardcoded Secrets → M8 + M10
Insecure Data Storage1/2/3 → M2 (Direct hit)
Input Validation Issues → M4 + M7
Insecure Activity Launch → M5 + M8
Hardcoded Access Control → M5
**DIVA APK OWASP Mobile Top 10 Mapping**
– M1: Weak Server Side Controls → (Input Validation Issues indirect)
– M2: Insecure Data Storage → Insecure Data Storage1, 2, 3
– M3: Insufficient Transport Layer Protection → Insecure Data Storage3
– M4: Unintended Data Leakage → Input Validation Issues
– M5: Poor Authorization and Authentication → Hardcoded Access Control, Insecure Activity Launch
– M6: Broken Cryptography → InsecureDataStorage2
– M7: Client Side Injection → Input Validation Issues
– M8: Security Decisions Via Untrusted Inputs → Hardcoded Secrets, Insecure Activity Launch
– M9: Improper Session Handling → (Partial storage issues)
– M10: Lack of Binary Protections → Hardcoded Secrets, APK tampering
