LTESniffer: ओपन-सोर्स LTE डाउनलिंक/अपलिंक स्निफर

 (github.com/SysSec-KAIST)
1 पॉइंट द्वारा GN⁺ 2024-10-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • LTESniffer एक ओपन-सोर्स टूल है जो LTE बेस स्टेशन और स्मार्टफोन के बीच डाउनलिंक·अपलिंक वायरलेस मैसेज कैप्चर करता है; पहले PDCCH से DCI और RNTI हासिल करता है, फिर PDSCH·PUSCH को डिकोड करके डेटा ट्रैफिक का विश्लेषण करता है
  • यह एन्क्रिप्टेड मैसेज को डिक्रिप्ट नहीं कर सकता, और केवल MAC·physical layer header जैसे अनएन्क्रिप्टेड हिस्सों, बेस स्टेशन broadcast messages, या कनेक्शन की शुरुआती plaintext messages का विश्लेषण कर सकता है
  • सुरक्षा शोध के लिए API identity mapping, IMSI collecting, UE capability profiling — इन 3 चीजों को सपोर्ट करता है, और इसका implementation PDSCH·PUSCH protocol packet decoding के जरिए उन passive sniffer जरूरतों को पूरा करने की कोशिश करता है जिन्हें मौजूदा LTE security research मानकर चलती थी
  • फीचर दायरे में LTE Advanced·LTE Advanced Pro, अपलिंक·डाउनलिंक में अधिकतम 256QAM, FDD, अधिकतम 20MHz बेस स्टेशन, DCI formats 0/1A/1/1B/1C/2/2A/2B, और transmission modes 1~4 शामिल हैं
  • रियल-टाइम decoding के लिए multi physical core CPU और SDR configuration चाहिए; अपलिंक ट्रैफिक collecting में UE signal कमजोर होने के कारण sniffer को स्मार्टफोन के पास रखना पड़ता है या directional antenna·RF frontend·amplifier जैसे hardware reinforcement की जरूरत होती है

LTESniffer क्या करता है

  • LTESniffer एक ओपन-सोर्स sniffer है जो LTE डाउनलिंक और अपलिंक दोनों को कैप्चर करता है
  • इसका operation flow पहले PDCCH को डिकोड करके active users के DCI और RNTI प्राप्त करने का है, और फिर इनका उपयोग करके PDSCH और PUSCH को आगे डिकोड कर अपलिंक·डाउनलिंक डेटा ट्रैफिक लाया जाता है
  • सामान्य user perspective से, यह बेस स्टेशन और उससे connected स्मार्टफोन के बीच आने-जाने वाले LTE wireless messages को दोनों दिशाओं में कैप्चर करने वाला टूल है
  • एन्क्रिप्टेड मैसेज डिक्रिप्ट नहीं किए जा सकते
    • एन्क्रिप्टेड मैसेज में MAC·physical layer header जैसे अनएन्क्रिप्टेड हिस्सों का विश्लेषण किया जा सकता है
    • plaintext में भेजे जाने वाले बेस स्टेशन broadcast messages या शुरुआती connection messages का पूरा विश्लेषण संभव है

सुरक्षा शोध API और research उद्देश्य

  • LTESniffer security applications और research के लिए 3 API functions देता है
    • identity mapping
    • IMSI collecting
    • UE capability profiling
  • कई LTE security studies यह मानती हैं कि हवा में privacy-related packets कैप्चर कर सकने वाला passive sniffer मौजूद है, लेकिन बताया गया है कि मौजूदा open-source sniffers PDSCH और PUSCH के protocol packets को डिकोड नहीं कर पाते, इसलिए वे requirements पूरी नहीं करते
  • विस्तृत जानकारी paper में संकलित है
  • LTESniffer का मुख्य उद्देश्य cellular network security·analysis research को support करना है
    • चूंकि यह अपलिंक·डाउनलिंक user data collect करता है, इसलिए LTE traffic sniffing से जुड़े local regulations का पालन करना चाहिए
    • user privacy-related information को जानबूझकर collect करने जैसे illegal use के लिए developers जिम्मेदार नहीं हैं

supported features और implementation base

  • LTESniffer FALCON के ऊपर implement किया गया है और srsRAN libraries का उपयोग करता है
  • मुख्य support scope इस प्रकार है
    • PDCCH, PDSCH, PUSCH control·data channels की real-time uplink·downlink decoding
    • LTE Advanced और LTE Advanced Pro
    • अपलिंक·डाउनलिंक दोनों में अधिकतम 256QAM
    • DCI formats 0, 1A, 1, 1B, 1C, 2, 2A, 2B
    • transmission modes 1, 2, 3, 4

    • केवल FDD support

      • अधिकतम 20MHz बेस स्टेशन
      • हर स्मार्टफोन के लिए अधिकतम UL/DL modulation scheme की automatic detection
      • हर UE के लिए physical layer configuration की automatic detection
      • RNTI-TMSI mapping, IMSI collecting, UE Capability Profiling
      • v2.1.0 update में subframe IQ raw data file recording, recorded files के जरिए offline decoding, और downlink mode API activation जोड़े गए हैं
      • downlink mode API केवल identity collecting और mapping API पर लागू होता है
      • संबंधित जानकारी LTESniffer-record-subframe branch और README में है
      • v2.0.0 update ने uplink sniffing mode में दो USRP B-series के उपयोग को support किया और bugs fix किए
      • संबंधित जानकारी LTESniffer-multi-usrp branch और README में है

hardware·software requirements

  • Stable operation OS Ubuntu 18.04/20.04/22.04 है
  • real-time LTE traffic decoding के लिए, बेस स्टेशन पर active users ज्यादा होने वाले peak time में multiple physical cores वाला high-performance CPU चाहिए
    • Intel i7-9700K PC पर 150 active users वाले बेस स्टेशन traffic को real-time decode करने का उदाहरण है
    • recommended specs: 8 या उससे अधिक physical cores वाला Intel i7 CPU, 16GB या अधिक RAM, 256GB SSD
  • सिर्फ डाउनलिंक sniffing करते समय srsRAN द्वारा supported अधिकांश SDR इस्तेमाल किए जा सकते हैं
    • उदाहरण USRP या BladeRF हैं
    • SDR को USB 3.0 से PC से connect होना चाहिए
    • transmission modes 3·4 downlink messages decode करने के लिए 2 RX antennas चाहिए
    • अगर केवल 1 RX antenna है, तो सिर्फ transmission mode 1 downlink messages decode होते हैं
    • GPSDO downlink sniffing में synchronization सुधारने में मदद करता है, लेकिन अनिवार्य नहीं है
  • अपलिंक sniffing में अपलिंक और डाउनलिंक दो frequencies को साथ में सुनना होता है, इसलिए दो configurations supported हैं
    • single USRP X310: 2 RX channels को अलग-अलग uplink·downlink frequencies पर tune किया जा सकता है, और GPSDO optional है
    • 2 USRP B-Series units: B210/B200 को अपलिंक·डाउनलिंक के लिए अलग-अलग उपयोग किया जाता है, और दोनों USRP को synchronize करने के लिए GPSDO को clock source और time reference के रूप में इस्तेमाल किया जाता है
    • 2 USRP B-Series configuration में GPSDO अनिवार्य है

installation और execution flow

  • source build से पहले UHD 4.0 या उससे ऊपर install करना जरूरी है, और source build recommended है
  • srsRAN dependencies और LTESniffer dependencies install करने के बाद repository clone करें और cmake, make -j 4 से build करें
  • build के बाद executable file <build-dir>/src/LTESniffer में स्थित होती है
  • मुख्य execution modes 3 हैं
    • बेस स्टेशन से आने वाले LTE downlink traffic की sniffing
    • स्मार्टफोन से बेस स्टेशन की ओर जाने वाले LTE uplink traffic की sniffing
    • security API
  • commercial networks पर इस्तेमाल करने से पहले LTE traffic sniffing से जुड़े local regulations जांचने चाहिए
  • जिस बेस स्टेशन से test smartphone connected है और uplink·downlink bands जांचने के लिए Android के लिए Cellular-Z इस्तेमाल किया जा सकता है
    • LTESniffer को भी उसी cell और frequency से connect करना होगा

output और analysis

  • LTESniffer output के रूप में pcap files देता है, और Wireshark में आगे analysis और packet tracing किया जा सकता है
  • generated filenames mode के अनुसार अलग होते हैं
    • downlink: sniffer_dl_mode.pcap
    • uplink: sniffer_ul_mode.pcap
    • API: api_collector.pcap
  • pcap files उसी directory में generate होती हैं जहां LTESniffer run किया गया है
  • Wireshark decoded packets का सही analysis कर सके, इसके लिए pcap_file_example/README.md की configuration guide देखें
  • uplink pcap file में uplink और downlink messages दोनों शामिल होते हैं
    • केवल uplink देखने के लिए mac-lte.direction == 0 filter इस्तेमाल करें
    • केवल downlink देखने के लिए mac-lte.direction == 1 filter इस्तेमाल करें

uplink sniffing की distance constraints

  • LTESniffer की uplink effective range SDR जैसे RF frontend की performance की वजह से limited है
  • UE battery use optimize करने वाला mobile device है, इसलिए uplink signal power बेस स्टेशन downlink signal से काफी कमजोर होती है
  • uplink traffic सफलतापूर्वक capture करने के लिए receiving signal power इन तरीकों से बढ़ाई जा सकती है
    • UE के physically करीब position करना
    • directional antenna, dedicated RF frontend, signal amplifier जैसे special hardware का उपयोग

FAQ में बताई गई limitations और alternatives

  • GPSDO ज्यादा stable synchronization के लिए उपयोगी है, लेकिन downlink sniffing में GPSDO के बिना भी LTE signal से synchronize करके packets decode किए जा सकते हैं
  • uplink sniffing में GPSDO केवल 2 USRP B-series का उपयोग करते समय जरूरी है
    • single USRP X310 configuration में GPSDO की जरूरत नहीं है
  • downlink traffic srsRAN library द्वारा supported BladeRF जैसे SDR पर भी technically run किया जा सकता है
    • हालांकि LTESniffer downlink function testing केवल USRP B210 और X310 पर की गई है
  • LTESniffer उपयोग की legality के लिए unencrypted LTE traffic sniffing से जुड़े local regulations check करने चाहिए
    • एक अन्य test method के रूप में Faraday cage के अंदर srsRAN आधारित private LTE network setup करने का तरीका बताया गया है
  • दो users के बीच message content में केवल unencrypted parts देखे जा सकते हैं
    • बेस स्टेशन और user के बीच wireless traffic अधिकतर encrypted होता है
  • LTE network में TMSI, GUTI, IMSI, RNTI जैसे plaintext में exposed कई identifiers literature में दिखते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-23
Hacker News की राय

  • मोबाइल नेटवर्क स्टैंडर्ड abbreviations से भरे होते हैं, यही अच्छी बात है
    अगर आपको नहीं पता था, तो PHICH में Q का मतलब "request" है

    • ऊपर क्या कहा जा रहा है, यह समझना चाहने वालों के लिए: PHICH referenced project में नहीं आता, लेकिन अजीब मोबाइल नेटवर्क abbreviations का एक उदाहरण है; यह "Physical channel HybridARQ Indicator Channel" का acronym है
      इसमें मौजूद "ARQ" शायद https://en.wikipedia.org/wiki/Automatic_repeat_request के रूप में expand किया जा सकता है
      कुछ लोग कह सकते हैं कि "ARQ" में "Q" असल में "query" है, और जो लोग इसे "request" के रूप में expand करते हैं वे औसत vocabulary level को कम आंक रहे हैं
      निजी तौर पर, सोचने पर मुझे लगता है कि Q के "request" या "query" होने के बजाय, https://en.wikipedia.org/wiki/Q_code में दिखने वाली पारंपरिक opaque Q code का एक और निशान होने की संभावना अधिक है
    • मुझे लगा आप मजाक कर रहे हैं
      यहां PHICH के अंदर Q है: https://github.com/srsran/srsRAN_4G/blob/master/lib/src/phy/...
      sibling comment की तरह, q reQuest का Q है

  • अच्छा लग रहा है
    यह सिर्फ FDD support करता है, TDD नहीं, और 20MHz तक सीमित है, इसलिए कुछ constraints हैं
    लगता है कि यह कुछ हद तक real-time decoding भी कर सकता है, जो दिलचस्प है। base station में processing का बड़ा हिस्सा काफी general-purpose processors करते हैं, लेकिन फिर भी वह इस software की तुलना में hardware के साथ कहीं ज्यादा tightly integrated होता है

  • अफसोस है कि इसे चलाने के लिए hardware बहुत महंगा है :'(

    • यह srsRAN इस्तेमाल करता है, और srsRAN vendor-independent SoapySDR support करता है
      इसलिए यह limesdr पर भी चलेगा
      सस्ते विकल्प के तौर पर antsdr या adalm-pluto आजमा सकते हैं: https://github.com/srsran/zynq_timestamping
      अच्छे notes भी काफी हैं: https://www.quantulum.co.uk/blog/private-lte-with-analog-ada...
    • अगर आप ज्यादा accessible LTE metadata decoder में रुचि रखते हैं, तो https://github.com/JiaoXianjun/LTE-Cell-Scanner देखें
      कुछ features सस्ते rtl-sdr dongle पर भी चलते हैं। यह पुराने https://github.com/Evrytania/LTE-Cell-Scanner का fork है
    • अगर आपके पास पहले से PC है, तो bladeRF 2.0 micro xA5 को $670 में खरीदकर यह संभव लगता है, लेकिन इस case में आप सिर्फ downlink sniff कर सकते हैं
    • Adalm Pluto जैसा पर्याप्त bandwidth और dynamic range वाला सस्ता hardware भी है, लेकिन देखने में support नहीं लगता
    • सच में ऐसा है? मुझे उत्सुकता है कि phone modems इतने सस्ते कैसे होते हैं

  • थोड़ा अलग विषय है, लेकिन सोच रहा हूं कि क्या किसी ने DSL eavesdropping की कोशिश की है
    modern DSL, खासकर VDSL2, मूल रूप से unshielded twisted pair के ऊपर चलने वाला high-frequency signal है, इसलिए line branches जैसी चीजें हों तो यह आसानी से leak होकर radiate करेगा
    वास्तव में UK के amateur radio operators इस बारे में काफी शिकायत करते हैं[1], लगता है ऐसा ही है। सोच रहा हूं कि क्या उस signal को अब भी demodulate किया जा सकता है, या वह spectrum में सिर्फ परेशान करने वाला baseline noise है
    [1]: https://rsgb.services/public/publications/vdsl/measuring_and...

  • एक कम-जानी लेकिन दिलचस्प बात यह है कि शुरुआती digital mobile phone generations decode करने की कठिनाई के बीच वाले अस्पष्ट zone में हैं
    बिल्कुल आसान नहीं, लेकिन इतना आसान कि तोड़ा जा सके। encryption सच में टूट चुका है
    rainbow table 2TB की है और इसे बनाने में कई महीने लगे: https://github.com/0xh4di/GSMDecryption?tab=readme-ov-file
    अब सोच रहा हूं कि क्या बाद की generations में भी अलग-अलग कारणों या कुछ state actors की वजह से decryption holes थोड़े-बहुत हैं

  • मजेदार काम है, और ऐसा open source अभी भी इस्तेमाल होते देखना अच्छा लगा
    करीब 10 साल पहले university network security lab में downlink eavesdropping किया था
    projects में से एक यह measure करना था कि spring break के दौरान cell activity कितनी कम होती है, और दूसरा यह देखना था कि known location पर known phone number के लिए timing attack करके temporary ID निकाली जा सकती है या नहीं, और repeated calls से यह देखा जा सकता है या नहीं कि वह अभी भी उस area में है
    मेरे हिसाब से वह temporary ID पर्याप्त temporary नहीं थी। फिर से इसे हाथ लगाने का मन हो रहा है

  • कुछ 4G dongles भी हैं जिनमें जानकारी निकालने के लिए इस्तेमाल होने वाला, जाना-माना broken debug mode है

  • LTESniffer खुद को open source कहता है, लेकिन न तो top-level LICENSE file है और न ही GitHub repository license settings दिखती हैं

    • ज्यादातर source files में copyright headers हैं कि code AGPLv3 है, और यह top-level LICENSE file वाले existing projects https://github.com/falkenber9/falcon और https://github.com/srsran/srsRAN_Project से fork किया गया है
      build files और बाकी supporting files को भी cover करने के लिए top-level LICENSE file जोड़ना सही रहेगा