Burp प्रमाणपत्र स्थापित करें

Tip

AWS Hacking सीखें & अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking सीखें & अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking सीखें & अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE) assessment tracks (ARTA/GRTA/AzRTA) और Linux Hacking Expert (LHE) के लिए full HackTricks Training catalog ब्राउज़ करें।

HackTricks का समर्थन करें

ADB के माध्यम से सिस्टम-व्यापी proxy

एक सिस्टम-व्यापी HTTP proxy कॉन्फ़िगर करें ताकि सभी apps का ट्रैफ़िक आपके interceptor (Burp/mitmproxy) के माध्यम से जाए:

# Set proxy (device/emulator must reach your host IP)
adb shell settings put global http_proxy 192.168.1.2:8080

# Clear proxy
adb shell settings put global http_proxy :0

Tip: In Burp, अपने listener को 0.0.0.0 से बाइंड करें ताकि LAN पर डिवाइस कनेक्ट कर सकें (Proxy -> Options -> Proxy Listeners).

वर्चुअल मशीन पर

सबसे पहले आपको Burp से Der certificate डाउनलोड करना होगा। आप यह Proxy –> Options –> Import / Export CA certificate में कर सकते हैं।

Der format में सर्टिफिकेट एक्सपोर्ट करें और इसे ऐसे फॉर्म में परिवर्तित करें जिसे Android समझ सके। ध्यान दें कि AVD में Android मशीन पर burp certificate configure करने के लिए आपको इस मशीन को run करना होगा और इसे -writable-system विकल्प के साथ लॉन्च करना होगा।
उदाहरण के लिए आप इसे इस तरह चला सकते हैं:

C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system

फिर, burps सर्टिफिकेट को कॉन्फ़िगर करें:

openssl x509 -inform DER -in burp_cacert.der -out burp_cacert.pem
CERTHASHNAME="`openssl x509 -inform PEM -subject_hash_old -in burp_cacert.pem | head -1`.0"
mv burp_cacert.pem $CERTHASHNAME #Correct name
adb root && sleep 2 && adb remount #Allow to write on /syste
adb push $CERTHASHNAME /sdcard/ #Upload certificate
adb shell mv /sdcard/$CERTHASHNAME /system/etc/security/cacerts/ #Move to correct location
adb shell chmod 644 /system/etc/security/cacerts/$CERTHASHNAME #Assign privileges
adb reboot #Now, reboot the machine

एक बार मशीन का रीबूट पूरा हो जाने पर Burp certificate उस पर उपयोग में होगा!

Magisk का उपयोग

यदि आपने अपना डिवाइस Magisk से rooted किया है (शायद एक emulator), और आप पिछले steps का पालन करके Burp cert इंस्टॉल नहीं कर पा रहे हैं क्योंकि filesystem is read-only है और आप इसे remount कर writable नहीं कर सकते, तो एक और तरीका है।

इस this video में समझाया गया है कि आपको:

  1. Install a CA certificate: बस drag&drop करके DER Burp certificate को मोबाइल में डालें, extension को .crt में बदलें ताकि यह Downloads फ़ोल्डर में स्टोर हो जाए और फिर Install a certificate -> CA certificate पर जाएं
  • यह चेक करें कि certificate सही तरीके से स्टोर हुआ है: Trusted credentials -> USER पर जाकर
  1. Make it System trusted: Magisk module MagiskTrustUserCerts (.zip फ़ाइल) डाउनलोड करें, इसे फोन में drag&drop करें, फोन पर Magisk app खोलें और Modules सेक्शन में जाएं, Install from storage पर क्लिक करें, .zip module चुनें और इंस्टॉल होने के बाद फोन को reboot करें:
  • Reboot के बाद, Trusted credentials -> SYSTEM पर जाएं और चेक करें कि Postswigger cert वहाँ मौजूद है

वैकल्पिक: AlwaysTrustUserCerts (Android 7-16 Beta)

यदि आप Android 14+ पर हैं (या उन पुराने डिवाइसेज़ पर जो Conscrypt Mainline अपडेट्स प्राप्त कर चुके हैं और अब /apex/com.android.conscrypt/cacerts का उपयोग करते हैं), तो Magisk module AlwaysTrustUserCerts system trust के लिए आवश्यक bind-mounting को ऑटोमेट कर देता है। यह user CAs को system trust में mirror करता है और mounts को Zygote/app namespaces में inject करता है ताकि apps बिना मैन्युअल nsenter काम के certs देख सकें।

  1. पहले Burp CA को एक user cert के रूप में इंस्टॉल करें।
  2. module इंस्टॉल करें और reboot करें।
  3. अगर module विकल्प देता है, तो /system/etc/security/cacerts को /apex/com.android.conscrypt/cacerts में mount करते समय nested mounts (अन्य modules से) दिखाई देने के लिए --rbind चुनें।

Magisk module कैसे बनाना सीखें

देखें https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437

Android 14 के बाद

हाल के Android 14 रिलीज़ में system-trusted Certificate Authority (CA) certificates के हैंडलिंग में एक महत्वपूर्ण बदलाव देखा गया है।

Note: कुछ Android 12/13 डिवाइसेज़ जिनको Conscrypt Mainline अपडेट्स मिले हैं वह पहले से ही /apex/com.android.conscrypt/cacerts का उपयोग कर रहे हैं। यदि वह directory आपके डिवाइस पर मौजूद है, तो आपको नीचे वर्णित वही APEX injection तकनीक उपयोग करनी होगी।

पहले, ये certificates /system/etc/security/cacerts/ में रखे जाते थे, जिन्हें root privileges वाले लोग एक्सेस और मॉडिफाई कर सकते थे, जिससे ये सिस्टम भर में तुरंत लागू हो जाते थे। हालांकि, Android 14 के साथ, स्टोरेज लोकेशन को /apex/com.android.conscrypt/cacerts में स्थानांतरित कर दिया गया है, जो /apex पाथ के भीतर आता है और स्वभाव से immutable है।

APEX cacerts path को writable के रूप में remount करने के प्रयास विफल होते हैं, क्योंकि सिस्टम ऐसे ऑपरेशन्स की अनुमति नहीं देता। यहाँ तक कि directory को unmount करने या उसे एक अस्थायी फाइल सिस्टम (tmpfs) से overlay करने के प्रयास भी इस immutability को पार नहीं कर पाते; applications फ़ाइल सिस्टम स्तर पर किए गए परिवर्तनों की परवाह किए बिना मूल certificate डेटा तक पहुँचती रहती हैं। यह मजबूती इसलिए है क्योंकि /apex माउंट को PRIVATE propagation के साथ कॉन्फ़िगर किया गया है, जिससे /apex डायरेक्टरी के भीतर किए गए किसी भी परिवर्तन का प्रभाव अन्य प्रक्रियाओं पर नहीं पड़ता।

Android की initialization init process के साथ होती है, जो ऑपरेटिंग सिस्टम शुरू होने पर Zygote process भी शुरू करता है। यह प्रक्रिया application processes लॉन्च करने के लिए एक नया mount namespace बनाती है जिसमें एक private /apex माउंट शामिल होता है, इस तरह इस डायरेक्टरी में किए गए बदलाव अन्य प्रक्रियाओं से अलग-थलग रहते हैं।

फिर भी, उन लोगों के लिए एक workaround मौजूद है जिन्हें /apex डायरेक्टरी के अंदर system-trusted CA certificates को मॉडिफाई करने की आवश्यकता है। इसमें /apex की PRIVATE propagation को हटाने के लिए मैन्युअल रूप से उसे remount करना शामिल है, जिससे वह writable बन सके। प्रक्रिया में /apex/com.android.conscrypt की सामग्री को किसी अन्य स्थान पर कॉपी करना, फिर /apex/com.android.conscrypt डायरेक्टरी को unmount करके read-only प्रतिबंध हटाना, और फिर मूल स्थान पर सामग्री को restore करना शामिल है। इस तरीके में सिस्टम क्रैश से बचने के लिए तेज़ी की आवश्यकता होती है। यह सुनिश्चित करने के लिए कि ये परिवर्तन सिस्टम-व्यापी रूप से लागू हों, system_server को restart करने की सिफारिश की जाती है, जो प्रभावी रूप से सभी applications को पुनः प्रारंभ करता है और सिस्टम को एक सुसंगत स्थिति में लाता है।

# Create a separate temp directory, to hold the current certificates
# Otherwise, when we add the mount we can't read the current certs anymore.
mkdir -p -m 700 /data/local/tmp/tmp-ca-copy

# Copy out the existing certificates
cp /apex/com.android.conscrypt/cacerts/* /data/local/tmp/tmp-ca-copy/

# Create the in-memory mount on top of the system certs folder
mount -t tmpfs tmpfs /system/etc/security/cacerts

# Copy the existing certs back into the tmpfs, so we keep trusting them
mv /data/local/tmp/tmp-ca-copy/* /system/etc/security/cacerts/

# Copy our new cert in, so we trust that too
mv $CERTIFICATE_PATH /system/etc/security/cacerts/

# Update the perms & selinux context labels
chown root:root /system/etc/security/cacerts/*
chmod 644 /system/etc/security/cacerts/*
chcon u:object_r:system_file:s0 /system/etc/security/cacerts/*

# Deal with the APEX overrides, which need injecting into each namespace:

# First we get the Zygote process(es), which launch each app
ZYGOTE_PID=$(pidof zygote || true)
ZYGOTE64_PID=$(pidof zygote64 || true)
# N.b. some devices appear to have both!

# Apps inherit the Zygote's mounts at startup, so we inject here to ensure
# all newly started apps will see these certs straight away:
for Z_PID in "$ZYGOTE_PID" "$ZYGOTE64_PID"; do
if [ -n "$Z_PID" ]; then
nsenter --mount=/proc/$Z_PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
fi
done

# Then we inject the mount into all already running apps, so they
# too see these CA certs immediately:

# Get the PID of every process whose parent is one of the Zygotes:
APP_PIDS=$(
echo "$ZYGOTE_PID $ZYGOTE64_PID" | \
xargs -n1 ps -o 'PID' -P | \
grep -v PID
)

# Inject into the mount namespace of each of those apps:
for PID in $APP_PIDS; do
nsenter --mount=/proc/$PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts &
done
wait # Launched in parallel - wait for completion here

echo "System certificate injected"

Bind-mounting through NSEnter

  1. लिखने योग्य डायरेक्टरी सेट करना: प्रारंभ में, मौजूदा non-APEX सिस्टम प्रमाणपत्र निर्देशिका के ऊपर tmpfs माउंट करके एक लिखने योग्य डायरेक्टरी स्थापित की जाती है। यह निम्नलिखित कमांड से किया जाता है:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. Preparing CA Certificates: लिखने योग्य डायरेक्टरी के सेटअप के बाद, जिन CA प्रमाणपत्रों का उपयोग करना हो उन्हें इस डायरेक्टरी में कॉपी करना चाहिए। इसमें डिफ़ॉल्ट प्रमाणपत्रों को /apex/com.android.conscrypt/cacerts/ से कॉपी करना शामिल हो सकता है। इन प्रमाणपत्रों की अनुमतियाँ और SELinux लेबल्स को उपयुक्त रूप से समायोजित करना आवश्यक है।
  2. Bind Mounting for Zygote: nsenter का उपयोग करके Zygote के mount namespace में प्रवेश किया जाता है। Zygote, जो Android applications लॉन्च करने की प्रक्रिया के लिए जिम्मेदार है, इस चरण की आवश्यकता इसलिए है ताकि इसके बाद शुरू होने वाले सभी एप्लिकेशन नई कॉन्फ़िगर की गई CA प्रमाणपत्रों का उपयोग करें। उपयोग किया गया command है:

Tip: यदि /system/etc/security/cacerts में nested mounts हैं (Magisk modules के साथ सामान्य), तो उन mounts को app namespaces में propagate करने के लिए --rbind का उपयोग --bind के बजाय करें।

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
# If /system/etc/security/cacerts includes nested mounts, prefer --rbind
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --rbind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

यह सुनिश्चित करता है कि शुरू की जाने वाली हर नई ऐप अद्यतन CA प्रमाणपत्र सेटअप का पालन करेगी।

  1. चल रही ऐप्स पर परिवर्तन लागू करना: पहले से चल रही एप्लिकेशनों पर परिवर्तन लागू करने के लिए, nsenter का उपयोग फिर से प्रत्येक ऐप के namespace में व्यक्तिगत रूप से प्रवेश करने और समान bind mount करने के लिए किया जाता है। आवश्यक कमांड है:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. Alternative Approach - Soft Reboot: एक वैकल्पिक तरीका init प्रक्रिया (PID 1) पर bind mount करने और उसके बाद ऑपरेटिंग सिस्टम को stop && start कमांड्स के साथ soft reboot करने का है। यह तरीका सभी namespaces में परिवर्तन फैलाएगा, जिससे प्रत्येक चल रहे ऐप को अलग-अलग संबोधित करने की आवश्यकता नहीं होगी। हालांकि, रीबूट करने की असुविधा के कारण यह विधि सामान्यतः कम पसंद की जाती है।

संदर्भ

Tip

AWS Hacking सीखें & अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking सीखें & अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking सीखें & अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE) assessment tracks (ARTA/GRTA/AzRTA) और Linux Hacking Expert (LHE) के लिए full HackTricks Training catalog ब्राउज़ करें।

HackTricks का समर्थन करें