Reverse Engineering Bluetooth Protocols
1.0.0
เอกสารนี้สรุปกระบวนการที่ฉันผ่านไปยัง Reverse-Engineer โปรโตคอลบลูทู ธ ของเครื่องตรวจจับเรดาร์ Cobra Irad 900 ของฉัน เป้าหมายเริ่มต้นของฉันคือการมีอินเทอร์เฟซ Raspberry Pi 3 ของฉันพร้อมอุปกรณ์ผ่าน Bluetooth เพื่อจัดการการแจ้งเตือน โดยไม่ ต้องใช้แอปพลิเคชัน iOS/Android ในที่สุดก็ทำหน้าที่เป็นอินเทอร์เฟซที่ดีกับ "Caruter" Raspberry Pi ของฉัน
เป็นสิ่งสำคัญที่จะต้องทราบว่าฉันไม่มีประสบการณ์เบื้องต้นกับโปรโตคอลบลูทู ธ แต่มันเป็นประสบการณ์การเรียนรู้ที่สนุกโดยรวม
เมื่อฉันเริ่มโครงการนี้ครั้งแรกฉันไม่รู้ว่าจะเริ่มต้นตรงไหน แต่กับ Google ฉันรู้วิธีดมกลิ่นการจราจรบนเว็บปกติ แต่บลูทู ธ เป็นกล่องดำสำหรับฉัน ด้วยการค้นหาอย่างรวดเร็วฉันพบไลบรารี Pybluez รวมถึงตัวอย่างเกี่ยวกับการสื่อสารผ่าน RFCOMM ฉันยังพบแหล่งข้อมูลที่ดีหลายอย่างรวมถึงโพสต์บล็อกที่น่าสนใจโดย Travis Goodspeed
อย่างไรก็ตามคำแนะนำเล็กน้อยเกี่ยวกับเรื่องนี้ฉันยังใช้เวลากับทรัพยากรเช่นนี้เป็นจำนวนมากโดยคิดว่า Bluetooth LE เป็นสิ่งที่ฉันกำลังมองหา
เล่นกับ iPhone 5 Jailbroken เก่าของฉันฉันสามารถใช้ BTSERVER เพื่อบันทึกการจราจรบลูทู ธ ที่ส่งและรับจาก iPhone ของฉัน เมื่อถูกล้อมรอบด้วยอุปกรณ์บลูทู ธ หลายไฟล์ไฟล์บันทึกก็เพิ่มขึ้นอย่างรวดเร็วแม้ว่ามันจะไม่ได้เป็นปัญหามากนัก โชคดีที่บันทึกถูกส่งออกเป็นไฟล์. pklg ทำให้ง่ายต่อการกรองแพ็กเก็ตที่เกี่ยวข้องใน Wireshark
การใช้ตัวกรองแพ็คเก็ต bluetooth.src == B8:92:1D:00:3F:61 ฉันสามารถเห็นแพ็คเก็ตดิบที่แอพ iOS ส่งไปยังเครื่องตรวจจับเรดาร์ ฉันใช้ตัวอย่างการบันทึกการสื่อสารระหว่างโทรศัพท์ของฉันและเครื่องตรวจจับเรดาร์บางรายการที่มีการแจ้งเตือนที่ถูกสร้างขึ้นและบางส่วนไม่มี
ข้อมูลบลูทู ธ ถูกถ่ายโอนผ่านโปรโตคอล RFCOMM เมื่ออุปกรณ์เชื่อมต่อครั้งแรกพวกเขาจะส่งข้อมูลไปมาอาจจะซิงค์การตั้งค่า (เพิ่มเติมในภายหลัง) หลังจากนั้นอุปกรณ์ทั้งสองจะทำตามรูปแบบที่คาดการณ์ได้ระหว่างกัน เครื่องตรวจจับเรดาร์จะส่งแพ็กเก็ต RFCOMM ผ่านบลูทู ธ ในช่วงเวลา 1/2 วินาทีปกติ ด้วยเวลาและความอดทนฉันสามารถถอดรหัสโครงสร้างน้ำหนักบรรทุกที่ส่งจากเครื่องตรวจจับเรดาร์ไปยัง iPhone ได้
โครงสร้างน้ำหนักบรรทุก: เครื่องตรวจจับเรดาร์→ iPhone
| รายการ | ค่า (hex) | ขนาด |
|---|---|---|
| คำนำ | 55 | 1 ไบต์ |
| ขนาดน้ำหนักบรรทุก | xx xx | 2 ไบต์ |
| การกระทำ | XX | 1 ไบต์ |
| ที่สงวนไว้ | 00 | 1 ไบต์ |
| คนทำ | XX | 1 ไบต์ |
| ที่สงวนไว้ | xx xx xx xx xx xx | 6 ไบต์ |
| เตือน | XX | 1 ไบต์ |
| ประเภทการแจ้งเตือน | XX | 1 ไบต์ |
| - | - | - |
เมื่อเครื่องตรวจจับเรดาร์กำลังทำงานอยู่มันจะส่งแพ็คเก็ตในรูปแบบข้างต้น แม้ว่าเครือข่ายคอมพิวเตอร์ไม่ใช่ความเชี่ยวชาญของฉัน แต่ฉันจะพยายามอธิบายให้ดีที่สุดเท่าที่จะทำได้
ไบต์คำนำที่ส่งจะถูกส่งด้วยค่า 0x55 เสมอ สิ่งนี้ระบุว่าเป็นจุดเริ่มต้นของข้อความ Payload ใหม่จากอุปกรณ์แทนที่จะดำเนินการต่อจากแพ็คเก็ตก่อนหน้า หลังจากนั้นคือค่า 2 ไบต์ที่มีขนาดของส่วนที่เหลือของข้อความ (ทุกอย่างหลังจาก 3 ไบต์แรก) ค่าการกระทำระบุประเภทของข้อมูลที่แพ็คเก็ตกำลังส่ง
หมายเลข SEQ คือสิ่งที่เริ่มน่าสนใจ หากคุณเข้าเรียนในเครือข่ายหรือรู้เล็กน้อยเกี่ยวกับ TCP คุณอาจรู้แล้วว่ามันมีไว้เพื่ออะไร เครื่องตรวจจับเรดาร์จะส่งค่า 1 ไบต์ไปยัง iPhone และแอปพลิเคชัน iOS จะต้อง ตอบกลับด้วยหมายเลข ACK ที่มีค่าเดียวกัน มิฉะนั้นเครื่องตรวจจับเรดาร์จะรู้ว่ามีบางอย่างที่ผิดปกติและตัดการเชื่อมต่อตัวเอง
ไบต์ Alert ระบุว่ามีการกระตุ้นการแจ้งเตือนหรือไม่ ถ้าเป็นเช่นนั้นมันคือชุดของค่า 0x41 และไบต์ต่อไปนี้จะใช้เพื่อระบุประเภทของการแจ้งเตือนกำลังถูกส่ง ฉันไม่สามารถหาค่านิยมได้มากเกินไปเนื่องจากฉันไม่ได้เป็นเจ้าของปืนเรดาร์จริง แม้ว่าผู้ชายที่ใช้คำสั่งทำเครื่องจำลองปืน LiDAR โดยใช้ Arduino นั่นช่วยได้มากในการวิเคราะห์แพ็คเก็ต
เพื่อให้แอป iOS รักษาการเชื่อมต่อกับอุปกรณ์จำเป็นต้องส่งการตอบกลับในรูปแบบที่ถูกต้อง โชคดีที่การตอบสนองต่อเครื่องตรวจจับเรดาร์นั้นง่ายกว่ามากและมีเพียง 9 ไบต์
การตอบสนอง: iPhone →เครื่องตรวจจับเรดาร์
| รายการ | ค่า (hex) | ขนาด |
|---|---|---|
| คำนำ | 55 | 1 ไบต์ |
| ขนาดน้ำหนักบรรทุก | xx xx | 2 ไบต์ |
| การกระทำ | 02 | 1 ไบต์ |
| ที่สงวนไว้ | 00 | 1 ไบต์ |
| กก | XX | 1 ไบต์ |
| ที่สงวนไว้ | 00 42 | 2 ไบต์ |
| เคาน์เตอร์ | XX | 1 ไบต์ |
ดังที่ได้กล่าวไว้ก่อนหน้านี้ค่า ACK จะต้องเป็นค่าเดียวกับค่า SEQ ที่ได้รับก่อนหน้านี้มิฉะนั้นการเชื่อมต่อจะถูกตัดการเชื่อมต่อ นั่นง่ายพอ โปรโตคอลอื่น ๆ อาจมีวิธีการตรวจสอบลูกค้าที่ชัดเจนน้อยกว่า มาก โชคดีที่นี่ไม่ใช่กรณี ที่น่าสนใจมีตัวแปร counter อื่นที่ใช้ ฉันไม่เคยรู้เลยว่าไบต์มีไว้เพื่ออะไร แต่มันลดลง 1 สำหรับการตอบสนองแต่ละครั้งต่ออุปกรณ์ ค่าทั้งสองนี้ง่ายพอที่จะเขียนโค้ดลงในสคริปต์ Python และไม่ได้ทำงานมากเกินไปเลย
ดังที่ฉันได้กล่าวไว้ก่อนหน้านี้เมื่อแอป iOS เชื่อมต่อกับเครื่องตรวจจับเรดาร์เป็นครั้งแรกการตั้งค่าและข้อมูลบางอย่างจะถูกซิงโครไนซ์ไปมา มันไม่ได้เป็นสิ่งสำคัญสำหรับฉันที่จะคิดออกและทำลายแพ็คเก็ตเหล่านั้นและฉันไม่ต้องการใช้เวลามากเกินไปในเรื่องนี้ ฉันส่งออกบันทึกแพ็คเก็ตทั้งหมดใน wireshark เป็นไฟล์ XML (data.xml) จากนั้นใช้สคริปต์ Python (parsedata.py) เพื่อประมวลผลและจัดเก็บข้อมูลสำหรับการใช้งานในภายหลัง
เมื่อโหลดแล้ว Radar.py จะเปิดข้อมูลที่ประมวลผลล่วงหน้าภายในไฟล์ packetData.dat จากนั้นสแกนสำหรับเครื่องตรวจจับเรดาร์ผ่านบลูทู ธ และพยายามเชื่อมต่อกับมัน เมื่อเชื่อมต่อเครื่องตรวจจับเรดาร์จะส่งข้อมูลไปสองสามแพ็คเก็ตไปยังอุปกรณ์ที่เชื่อมต่อ โชคดีที่พวกเขาเป็นแพ็กเก็ตที่แน่นอนเดียวกันในลำดับที่แน่นอนเดียวกันในแต่ละครั้ง สคริปต์ Python จะตรวจสอบข้อมูลจากไฟล์ packetData.dat สำหรับแพ็คเก็ตที่ได้รับ เมื่อสคริปต์ Python หลักพบแพ็คเก็ตเครื่องจักรแล้วมันจะส่งการตอบสนองที่บันทึกไว้ก่อนหน้านี้ไปยังเครื่องตรวจจับเรดาร์
น่าแปลกที่มันได้ผลดี แม้ว่าฉันจะจินตนาการว่าฉันจะต้องอัปเดตไฟล์ข้อมูลหากฉันเปลี่ยนการตั้งค่าใด ๆ ภายในแอพ iOS มันไม่ได้เป็นปัญหามากนักเนื่องจากฉันต้องกำหนดค่าอุปกรณ์หนึ่งครั้งและอาจไม่เคยใช้แอพอีกเลย
จากข้อมูลทั้งหมดที่ฉันค้นพบฉันสามารถเขียนสคริปต์ Python ที่จำลองการเชื่อมต่อของ iPhone หากไม่พบแพ็กเก็ตภายในฐานข้อมูลของการตอบสนองที่บันทึกไว้จะสร้างแพ็คเก็ตตอบกลับด้วยโครงสร้างที่ฉันมีรายละเอียดก่อนหน้านี้
เมื่อมองย้อนกลับไปมันเป็นโครงการที่สนุกจริงๆที่ทำสิ่งที่ฉันไม่เคยมีประสบการณ์มาก่อน ในฐานะที่เป็นวิชาเอกวิทยาการคอมพิวเตอร์มันน่าสนใจที่จะทำอะไรบางอย่างกับฮาร์ดแวร์หนึ่งครั้งที่ไม่มากก็น้อย
Brandon Asuncion // [email protected]
ความคิดเห็น/ข้อเสนอแนะใด ๆ ได้รับการชื่นชม!
