สิ่งที่ทำให้ฉันมีความคิดที่จะสร้างเครื่องมือพกพาสำหรับวิเคราะห์เครือข่าย WiFi คือ .
ขอบคุณพวกเขาสำหรับความคิด ฉันแค่ไม่มีอะไรทำ
งานทั้งหมดทำขึ้นโดยเป็นส่วนหนึ่งของงานอดิเรกเพื่อความสนุกสนานและเพิ่มพูนความรู้ด้านเทคโนโลยีเครือข่าย ช้าๆ สัปดาห์ละ 1..4 ชั่วโมง ตั้งแต่ต้นปีนี้
ฉันไม่ได้วางแผนการใช้งานจริงใดๆ เหล่านั้น. นี่ไม่ใช่เครื่องมือของแฮ็กเกอร์
ในขณะนี้ ฟังก์ชันการทำงานที่วางแผนไว้ทั้งหมดทำงานได้ แหล่งทั้งหมดพร้อมประกอบอย่างสมบูรณ์ . นอกจากนี้ยังมีคำแนะนำในการประกอบ ฯลฯ ในหมายเหตุนี้ ฉันจะไม่ทำซ้ำข้อมูลที่โพสต์บน GitHub ฉันจะบอกคุณเฉพาะสิ่งที่ฉันเห็นว่าจำเป็นเพื่ออธิบายแยกกัน
ความคิดเห็นของฉันเกี่ยวกับ “เครื่องมือสากล” และเหตุผลในการเลือก ESP32
ฉันไม่อ้างว่าเป็นความจริง ทุกคนมีของตัวเอง ฉันจะพยายามปรับการเลือกฮาร์ดแวร์ของฉัน
กรณีการใช้งานของการรวมกันของ Linux (เริ่มแรกคือ Raspberry Pi) + "อุปกรณ์ต่อพ่วง" ในรูปแบบของคอนโทรลเลอร์ (STM32) + CC1110 (8051 คอร์) และแผนการที่จะอัดทุกอย่างที่เป็นไปได้ในนั้น (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) ดูเหมือนจะไม่เหมาะกับฉัน อย่างไรก็ตาม, ดูเหมือนว่าจะยังคงเป็นส่วนตัวและปิดอยู่ (flipper-zero github “องค์กรนี้ไม่มีที่เก็บข้อมูลสาธารณะ”) และมุ่งสู่ฮาร์ดแวร์ที่ไม่ธรรมดามากนัก
บางทีฉันอาจคิดผิด และในอนาคตผู้เขียนจะเปิดเผยแหล่งที่มาของซอฟต์แวร์ต่อสาธารณะ แต่ถ้าไม่เป็นเช่นนั้น ฉันจะไม่ซื้อฮาร์ดแวร์ชิ้นนั้นโดยไม่มีซอร์สโค้ด
ข้อกำหนดของฉันสำหรับ "เครื่องมือ"
กล่องควรมีขนาดเล็ก (ยิ่งเล็กยิ่งดี)
ดังนั้น:
- ไม่จำเป็นต้องใช้แบตเตอรี่ในตัว ด้วยกระแสไฟ > 100 mA เมื่อทำงานกับ Wifi แบตเตอรี่ในตัวจะมีขนาดใหญ่หรือใช้งานได้ไม่นาน ดังนั้นให้ “กล่อง” ใช้พลังงานจากพาวเวอร์แบงค์มาตรฐาน อย่างไรก็ตาม ฉันมักจะมีพาวเวอร์แบงค์ติดตัวไว้ในกระเป๋า/ในรถยนต์เสมอ
- เก็บ “กล่อง” Linux พร้อมเครื่องมือไว้ข้างใน เขียนมาหลายปีในทุกภาษา ด้วยหน้าจอขนาดเล็กและปุ่มควบคุมจำนวนน้อย จึงไม่สมเหตุสมผล สามารถดู/ประมวลผลผลลัพธ์ได้บนแล็ปท็อปปกติที่มีแป้นพิมพ์และหน้าจอเต็มรูปแบบ
- ส่วนประกอบต่างๆ ควรเข้าถึงได้ง่ายและเป็นที่รู้จักอย่างกว้างขวาง (SDK ที่มีอยู่ ตัวอย่างและเอกสารประกอบมากมาย)
เป็นผลให้สำหรับฉันตัวเลือกนั้นชัดเจน - ESP32
สำหรับงานทั้งหมดที่ระบุไว้ในบทความที่แจ้งให้ฉันดำเนินการ ความสามารถของ ESP32 ก็เพียงพอแล้ว แม้ว่าสิ่งที่ฉันยังอยากทำมากที่สุดคือ:
- เล่นกับบลูทูธ
- ลองใช้ช่วง 433mHz ด้วยฮาร์ดแวร์ที่ง่ายที่สุด (เฉพาะการมอดูเลตแอมพลิจูด ซึ่งเพียงพอสำหรับความต้องการในทางปฏิบัติ)
บินในครีมใน ESP32
- ESP32 SDK (IDF) ค่อนข้างงุ่มง่าม
- ฟังก์ชันการทำงานบางอย่าง (เช่น สแต็ค WiFi) มาโดยไม่มีซอร์สโค้ดในรูปแบบของไลบรารีสแตติกที่ประกอบขึ้น
- ไม่รองรับย่านความถี่ 5GHz และมีข้อจำกัดและความซุ่มซ่ามในการทำงานกับ WiFi
แต่ราคา/ขนาดสามารถชดเชยข้อบกพร่องเหล่านี้ได้อย่างสมบูรณ์
ฟังก์ชั่นซอฟต์แวร์หลัก
ฉันจะอธิบายฟังก์ชันการทำงานและความคิดเห็นของฉันโดยย่อเกี่ยวกับ...
การจัดการการตั้งค่าและการอัพโหลดไฟล์จาก SD
การควบคุมภายนอกทั้งหมดทำได้ผ่านเว็บเพจธรรมดา ซึ่งเปิดใช้งานในรายการเมนูแยกต่างหาก ESP32 เริ่มต้นในโหมด WiFi AP และแสดงเพจตามที่อยู่ IP คงที่
แม้ว่าคอร์ ESP32 จะค่อนข้างเร็ว แต่ดังการทดลองแสดงให้เห็นว่าการทำงานพร้อมกันของบริการเว็บในตัวและตัวอย่างเช่นโหมดเราเตอร์เข้ากันไม่ได้มากนัก ดังนั้นจึงไม่มีการควบคุมแบบไดนามิกและเพจไม่พร้อมใช้งานในโหมดอื่นๆ ทั้งหมด
นอกจากนี้ การควบคุมแบบไดนามิกไม่จำเป็นสำหรับวัตถุประสงค์ในการวิจัย
โหมดการทำงานกับแพ็คเกจ Beacon
โหมดมีความซ้ำซากและไม่น่าสนใจมาก สร้างขึ้นมา “เพราะมันเป็นไปได้” สำหรับเช็ค.
มีตัวอย่างอยู่ในตัวอย่าง Espressif อย่างเป็นทางการ
โหมดการสแกนรายการ AP
จริงๆ แล้วสมาร์ทโฟนทุกเครื่องก็สามารถทำได้
ในโหมดนี้รายการ AP จะถูกบันทึก
บีคอนสแปมเมอร์
ESP32 เริ่มต้นเป็น AP โดยมี SSID ที่ซ่อนอยู่และ MAC แบบสุ่ม และเริ่มส่ง [เฟรมบีคอน] ตามรายการ SSID ที่สร้างไว้ล่วงหน้า (สร้างขึ้นด้วยตนเองหรือได้รับก่อนหน้านี้โดยการสแกนรายการ AP)
โหมดการดมแพ็กเก็ต WiFi
นักพัฒนา Espressif ได้เพิ่มความสามารถให้แอพพลิเคชั่นซอฟต์แวร์รับแพ็กเก็ต WiFi ทั้งหมด "ลอยอยู่ในอากาศ" ผ่านฟังก์ชันโทรกลับ จริงๆ แล้วไม่ใช่ทั้งหมด เนื่องจากคุณสามารถตั้งค่าโหมดสำหรับช่องสัญญาณคงที่เพียงช่องเดียวเท่านั้น
มีการจำกัดเวลาที่เข้มงวดมากในการประมวลผลฟังก์ชันการโทรกลับ หากสิ่งนี้ไม่ก่อให้เกิดปัญหาสำหรับโหมดการรวบรวมสถิติอย่างง่ายฉันต้องปรับแต่งสำหรับโหมดบันทึกไฟล์ PCAP บนการ์ด SD โดยจัดระเบียบการบันทึกผ่านคิวในหน่วยความจำและเซมาฟอร์ โดยคำนึงถึงลักษณะเฉพาะที่กระบวนการเรียกการโทรกลับทำงานบนคอร์หนึ่งและกระบวนการที่เขียนไปยัง SD ในอีกคอร์หนึ่ง
ในช่วง "อากาศที่มีเสียงดัง" แพ็กเก็ตบางส่วนจะหายไป (ไม่มีที่ว่างในคิวและถูกทิ้งไป) แต่จะมี "อากาศ" ทั่วไปของอพาร์ทเมนต์ในตอนเย็น (5..7 AP ภายในการมองเห็น) บันทึกใน PCAP เสร็จสมบูรณ์โดยไม่สูญเสียแพ็กเก็ต
นอกจากนี้ สำหรับการตรวจสอบและบันทึก PCAP จะมีโหมดการกรองตามรายการ MAC ในส่วนหัวของแพ็กเก็ต
ตัวอย่างเช่น คุณสามารถติดตามการปรากฏตัวของบุคคลในคลับ/ร้านกาแฟก่อนที่เขาจะเข้าไปหรือปรากฏตัวต่อหน้าผู้อื่น มีคนเพียงไม่กี่คนที่ปิดการใช้งาน WiFi และการเชื่อมต่ออัตโนมัติกับ AP ที่รู้จัก (ตอนนี้ผมปิดเครื่องแล้ว..)
การดูข้อมูลจราจรที่บันทึกไว้ใน Wireshark ถือเป็นการศึกษาและน่าสนใจสำหรับการทำความเข้าใจแผนที่ ทั้งหมดนี้ได้ผล
โหมดสำหรับการทำงานกับแพ็คเกจ deauth
ตามค่าเริ่มต้น ห้ามส่งแพ็คเกจเหล่านี้ในไลบรารี libnet80211.a ซึ่งมาโดยไม่มีแหล่งที่มา แต่มันง่ายที่จะแก้ไขโดยปรับแต่งเล็กน้อย ตอนแรกฉันสงสัยว่ามันคุ้มค่าที่จะโพสต์แพตช์หรือไม่ แต่หลังจากเดินไปตามสถานที่ต่าง ๆ โดยเปิดโหมดสแกนเฟรม deauthentication ฉันก็คิดว่า: "นี่มันอะไรกัน" ยิ่งไปกว่านั้น ใน esp8266 การส่งมอบแพ็คเกจเหล่านี้ไม่ได้ปิดและมีแอสเซมบลีบน github สำหรับ esp8266
ในหลาย ๆ ที่ (ฉันจะไม่บอกว่าที่ไหน) มีการใช้การปราบปราม AP ที่ไม่ต้องการด้วยวิธีนี้ และนี่ไม่ใช่ "คนพาล"...
และฉันก็แปลกใจด้วยที่การกระจายอินเทอร์เน็ตจากโทรศัพท์ของฉันใช้งานไม่ได้ในบางที่...
โหมดการติดตามหมายเลขและ RSSI ของแพ็กเก็ตดังกล่าวมีประโยชน์มากในการทำความเข้าใจว่า "จุดที่ AP ด้านซ้ายไม่ชอบ"
โหมดเราเตอร์
คุณลักษณะนี้น่าจะเป็นสิ่งที่น่าสนใจที่สุดในการสำรวจ
ESP32 รองรับการทำงานพร้อมกันในโหมด STA + SoftAP ดังนั้นคุณสามารถใช้เราเตอร์ NAT แบบคลาสสิกกับมันได้
เพื่อรองรับสแต็กเครือข่าย Espressif ใช้ทางแยก (แทบไม่มีการเปลี่ยนแปลง) ของไลบรารี lwip
แต่ตามค่าเริ่มต้นในบิลด์มาตรฐาน ไลบรารี esp-lwip ไม่ได้จัดเตรียมการส่งต่อระหว่างอินเทอร์เฟซ netif 'ap' (SoftAP) และ 'st' (STA)
แน่นอนคุณสามารถทำได้โดยไม่ต้องใช้ NAT แต่มีปัญหาในการเชื่อมต่อ STA สองตัวขึ้นไปเข้ากับอินเทอร์เฟซ 'ap' และซิงโครไนซ์ที่อยู่ IP จากอินเทอร์เฟซเครือข่าย 'st' ไปยัง 'ap' ดังนั้นความยากลำบากจึงไม่คุ้มค่าและผ่าน NAT ได้ง่ายขึ้น
นอกจากนี้ยังมีทางแยก esp-lwip จาก martin-ger ซึ่งเพิ่มการใช้งาน NAT สำหรับ IP4 อย่างง่าย
แม้ว่ามือของฉันรู้สึกอยากจะสร้างมันขึ้นมาใหม่หมดจด (ในความคิดของฉันมันง่ายกว่าหากไม่มีการแยกโปรเจ็กต์ แต่ผ่าน LWIPตะขอ ฟังก์ชั่นที่กำหนดไว้ในระหว่างการประกอบ) แต่ความเกียจคร้านมีชัยและใช้ตัวเลือกจาก martin-ger ตามที่เป็นอยู่
ในโหมดเราเตอร์ การรับส่งข้อมูล IP4 ขาเข้าและขาออกจะถูกดู
โดยเฉพาะอย่างยิ่งสิ่งต่อไปนี้จะถูกแยกออกมาเพื่อแสดงบนหน้าจอและรวบรวมสถิติเป็นไฟล์:
- ชื่ออุปกรณ์ที่เชื่อมต่อกับ SoftAP ESP32 (แพ็กเก็ต DHCP)
- URL จากคำขอ DNS (พอร์ต UDP 53) จากอุปกรณ์ที่เชื่อมต่อกับ SoftAP ESP32
นอกจากนี้ คุณยังสามารถเปิดใช้งานการบันทึกการรับส่งข้อมูลไปยังไฟล์ PCAP ได้อีกด้วย
โหมดนี้มีประโยชน์มาก เช่น เพื่อทำความเข้าใจว่าโทรศัพท์ของคุณส่งอะไรไปยังเครือข่าย และไปที่ใด
คุณสามารถนึกถึงวิธีอื่นๆ ในการใช้โหมดนี้ โดยคำนึงถึงความสามารถในการควบคุมการรับส่งข้อมูลขาเข้าและขาออก softAP ESP32 อย่างสมบูรณ์ในระดับอินเทอร์เฟซเครือข่าย: ส่วนหัว Ehernet (destMAC[6]+srcMAC[6]+type[2]) + เพย์โหลด (ประเภท IP4, IP6, DCHP ฯลฯ)
โดยหลักการแล้ว ESP32 สามารถรับมือกับฟังก์ชั่นเราเตอร์ WiFi->WiFi ได้ค่อนข้างดี โดยส่งผ่านการรับส่งข้อมูลปกติโดยไม่มีความล่าช้าเป็นพิเศษ โดยพื้นฐานแล้ว ความล่าช้าในโทรศัพท์ที่เชื่อมต่อผ่านเราเตอร์บน ESP32 จะไม่สังเกตเห็นได้ชัดเจน
ขออภัย Espressif API ไม่สามารถตั้งค่าตัวกรองสำหรับ MAC ที่เชื่อมต่อกับ SoftAP EPS32 แต่จะเสนอให้พูดว่า "ลาก่อน" (esp_wifi_deauth_sta) กับ STA ที่เชื่อมต่ออยู่แล้วซึ่ง "ไม่ต้องการ"
การกรองโดย MAC สำหรับ STA ที่เชื่อมต่อจะต้องดำเนินการผ่านการเรียก esp_wifi_deauth_sta()
ในข้อสรุป
แม้ว่าฉันจะไม่ได้คิดอะไรใหม่ ๆ ภายในกรอบการทำงานกับ ESP32 แต่บางทีผลลัพธ์ (ซอร์สโค้ด) อาจจะน่าสนใจสำหรับใครบางคน
ฉันต้องการทราบว่าโค้ดนี้เขียนขึ้นเพื่อการศึกษาเท่านั้น สำหรับ “การแฮ็ก” ฯลฯ นั้นจงใจทำให้ไม่สะดวกนัก
ฉันไม่ได้ทำแผงวงจรพิมพ์เพราะใช้เวลา 1.5-2 ชั่วโมงในการบัดกรีผ้าพันคอที่เสร็จแล้วด้วยลวด
และถ้าคุณทำ คุณจะต้องประกอบมันไม่ใช่จากบอร์ดสำเร็จรูป แต่ต้องประกอบจากส่วนประกอบแต่ละชิ้น แล้วมิติก็จะเล็กลงอีก
ที่มา: will.com