Giải phóng Wi‑Fi trên ESP32 [Video]

 (media.ccc.de)
1 điểm bởi GN⁺ 2024-12-29 | 1 bình luận | Chia sẻ qua WhatsApp
  • ESP32 rất phổ biến, đến mức riêng tại CCH có lẽ đã dùng tới hàng nghìn chiếc, nhưng ngăn xếp Wi‑Fi cốt lõi lại là dạng đóng nên khó chỉnh sửa và kiểm tra
  • Phiên 38c3 bắt đầu từ reverse engineering thiết bị ngoại vi Wi‑Fi và trình bày quá trình tạo ra một ngăn xếp Wi‑Fi mã nguồn mở
  • Mục tiêu không chỉ là một bản thay thế đơn thuần, mà là giúp có thể tự xác minh và sửa chữa phần mềm xử lý dữ liệu nhạy cảm
  • Nếu ngăn xếp mới được thiết lập ổn định, ESP32 có thể vượt ra ngoài vai trò SoC IoT thông thường để trở thành nền tảng không dây giá rẻ cho nghiên cứu và thử nghiệm
  • Khi đủ tính năng được mở ra, có thể ứng dụng nó cho các công cụ pentest, bộ định tuyến mesh B.A.T.M.A.N., hay ứng dụng khách AirDrop

Vì sao cần mở ngăn xếp Wi‑Fi đóng

  • Ngăn xếp Wi‑Fi hiện có của ESP32 vẫn hoạt động, nhưng vì là triển khai đóng nên khó kiểm tra cách nó vận hành bên trong hoặc chỉnh sửa theo nhu cầu
  • Mục tiêu cốt lõi của ngăn xếp Wi‑Fi mã nguồn mở là cho phép chỉnh sửa và kiểm tra khu vực có thể xử lý dữ liệu nhạy cảm
  • Việc tại CCH có lẽ đang có hàng nghìn ESP32, tất cả đều chạy ngăn xếp Wi‑Fi đóng như vậy, càng làm rõ vấn đề này

Từ reverse engineering đến ngăn xếp mới

  • Dự án bắt đầu bằng việc reverse engineering ngăn xếp Wi‑Fi độc quyền của ESP32
  • Sau đó phát triển thành việc triển khai ngăn xếp Wi‑Fi mã nguồn mở trực tiếp điều khiển thiết bị ngoại vi Wi‑Fi của ESP32
  • Trong quá trình đó, nội dung cũng đề cập tới Wi‑Fi, ESP32, reverse engineering nói chung và cách tiếp cận với những dự án kiểu này

Ứng dụng khi ESP32 được mở ra

  • Khi các tính năng của ESP32 được mở hoàn toàn, nó có thể đảm nhiệm nhiều vai trò hơn như một công cụ nghiên cứu và một SoC IoT
  • Các ví dụ ứng dụng có thể gồm:
    • Công cụ pentest
    • Bộ định tuyến mesh B.A.T.M.A.N.
    • Ứng dụng khách AirDrop

Thông tin phiên và điều kiện công bố

  • Diễn giả là Frostie314159 và Jasper Devreker
  • Đây là phiên dài 38 phút diễn ra tại Saal 1, thuộc track Hardware & Making của 38c3, vào ngày 2024-12-27
  • Video và âm thanh được cung cấp ở các định dạng MP4, WebM, MP3 và Opus
  • Tài liệu được công bố theo điều kiện http://creativecommons.org/licenses/by/4.0

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-12-29
Ý kiến trên Hacker News

  • Bài liên quan: https://zeus.ugent.be/blog/23-24/open-source-esp32-wifi-mac/

    • Nếu phiên bản mã nguồn mở tương thích với API đóng thì có lẽ sẽ có lợi thế lớn
      Khi tương thích, có thể tận dụng nguyên các hướng dẫn và ví dụ đã tích lũy trên Internet, đồng thời giảm chi phí gia nhập. Ngay cả người chỉ muốn chỉnh sửa rất ít ở tầng MAC cũng có thể đi theo cách làm hiện có mà không phải gánh việc học API mới, rồi chỉ sửa phần mình muốn
    • Tôi là tác giả bài viết. Toàn bộ loạt bài cũng có tại https://esp32-open-mac.be/

  • Đến giờ vẫn khá lạ là chỉ Espressif mới thành công trong việc đưa modem WiFi vào một vi điều khiển khá ổn
    ST vẫn còn tụt khá xa ở mảng này

    • Các ví dụ khác gồm dòng BK72xx (BK7231T, BK7231N), dòng RTL87xx (RTL8710BN, RTL8710BX) và RP2040
      Tuy nhiên WiFi trên bo mạch RP2040 W trông như một module bên ngoài. Nguồn là https://esphome.io
    • Espressif đã kết hợp tốt các yếu tố: giá rẻ, dễ tiếp cận, phần cứng dễ dùng, phần mềm dễ dùng và không có hạn chế giấy phép kỳ quặc
      Có thể mua lẻ từng chiếc ở khắp nơi; được bán dưới nhiều dạng breakout board có nguồn USB, cổng lập trình và chân được ghi nhãn; tài liệu, ví dụ, Arduino IDE và NodeMCU cũng đầy đủ. Arduino ban đầu cũng tương tự, nhưng mắc kẹt quá lâu với chip AVR hiệu năng thấp, bo mạch không phải hàng Trung Quốc thì đắt, và cũng không có WiFi. Raspberry Pi Pico có tính năng tốt nhưng giai đoạn đầu khó mua, còn những thứ khác thì gần giống “chip đơn” mua từ nơi như DigiKey, phí vận chuyển đắt, tài liệu hơn 600 trang, chỉ để gửi một gói ping đầu tiên cũng cần hơn 300 trang, phải hàn vào bo mạch, và để lập trình thường cũng cần thiết bị đắt tiền
    • Nordic Semiconductor cũng có vi điều khiển có Bluetooth và WiFi. Tuy nhiên chúng ít phổ biến hơn nhiều so với giải pháp của Espressif
    • Phần lớn module dựa trên TuYa trên AliExpress là Beken
    • TI đã có vi điều khiển WiFi+Bluetooth từ gần 10 năm trước và cũng cung cấp Cortex-M4

  • Tôi chưa xem video nên xin lỗi nếu đã được đề cập, nhưng tôi thắc mắc liệu chứng nhận vô tuyến của ESP32 có bị gắn với firmware hộp đen chính thức hay không
    Ngay cả với cùng phần cứng, nếu dùng firmware mở thì có phải gửi lại cho FCC và các cơ quan chứng nhận khác để kiểm tra tính phù hợp không?

    • Nếu phân phối theo cách đó thì đúng, còn nếu người dùng cuối tự sửa thì không
      Tôi không nhớ ngay điều khoản CFR, nhưng FCC cho phép rõ ràng việc bất kỳ ai sử dụng một lượng nhỏ thiết bị chưa chứng nhận. Nếu thiết bị đó vi phạm quy định khác thì vẫn là vi phạm, nhưng bản thân việc đã sửa phần cứng hay phần mềm không bị cấm
    • Tôi cho là vùng xám. Nếu không sai quá nhiều, trong chứng nhận họ chỉ thử nghiệm và ghi lại hiệu năng vô tuyến ở điều kiện xấu nhất, còn phần tài liệu kỹ thuật còn lại giống một brochure khá chi tiết với sơ đồ khối cấp cao và lý thuyết hoạt động hơn là tài liệu thiết kế hiện đại kiểu file chế tạo PCB hay script build firmware
      Sự tồn tại của firmware gần như không được thừa nhận. Cũng có một lý do. Thiết bị vô tuyến không cần giấy phép nhưng được chứng nhận như WiFi được kỳ vọng phải chống can thiệp vì lợi ích công cộng. Vì vậy khi FCC thảo luận yêu cầu chứng nhận router WiFi, họ đã cân nhắc mở rộng sang cả phần mềm bằng cách bắt buộc Secure Boot cho toàn bộ đống router WiFi rác đầy lỗ hổng; đó là một ý tưởng kinh khủng nên đã bị bỏ. Hiện tại, chừng nào firmware tạo ra không rõ ràng gây phát xạ ngoài chuẩn, tôi xem nó gần như nửa hợp pháp hoặc nửa bất hợp pháp. Tôi không phải luật sư
    • Đúng vậy

  • https://github.com/esp32-open-mac

  • Trước đây từng có ý tưởng provisioning mật khẩu WiFi. Có thể truyền SSID và mật khẩu bằng cách điều chế độ dài gói tin
    Thiết bị IoT mới tất nhiên không thể giải mã gói tin, nhưng có thể quan sát độ dài. Tôi cũng đã viết một bản triển khai mẫu cho Linux, nhưng không tìm được chip IoT nào cung cấp quyền truy cập PHY cấp thấp đủ để làm việc này

    • SmartConfig của TI hoạt động như vậy bằng cách dùng trường độ dài. Vì thế chỉ cần dùng chip IoT đã triển khai nó; TI cung cấp khá nhiều chip như thế
    • https://www.keacher.com/xmas24/ dùng OOK cho truyền dữ liệu, và có ưu điểm là thu hoạch năng lượng từ tín hiệu WiFi nên không cần pin
    • Không thể dùng phương án cuối là reverse engineering sao, hay là bất khả thi?
    • Nếu là bây giờ thì tôi sẽ chỉ dùng WPA3

  • Hỏi ngoài lề, một trong các diễn giả đã công khai số DECT. Điều đó có nghĩa là vẫn có người mang theo điện thoại cũ để dùng ở hội nghị công nghệ sao?

    • Họ vận hành nhiều mạng để liên lạc thoại trong sự kiện. Tìm hiểu thì thấy thường dùng kết hợp DECT, SIP, GSM
      Cũng có dashboard trạng thái hiển thị các chỉ số trong sự kiện
      [1] https://events.ccc.de/2024/12/22/38c3-poc-isdn-version/
      [2] https://dashboard.eventphone.de/d/de7sgxz63vzeoe/38c3?orgId=...
    • Đúng vậy. Ở các hacker camp thì nó khá tiện, và tôi vẫn còn một chiếc
      Đặc biệt ở khu cắm trại, vùng phủ WiFi có thể lúc được lúc không, nên dù đi tới nhà vệ sinh hay bãi đỗ xe vẫn có thể nhận cuộc gọi. Vì dùng tần số riêng, nó cũng không làm các băng tần mà WiFi, Bluetooth, Zigbee sử dụng thêm đông đúc. Có thể dùng một app nào đó, nhưng DECT rất ổn định và tầm phủ cũng tốt hơn WiFi rất nhiều. Tôi có một máy Siemens khá ổn, cỡ Nokia 8210, nên không cần mang theo thứ to như cục gạch. Giờ pin chắc gần chết rồi, nhưng đúng kiểu pin thời đó nên có thể thay được

  • Trong nhà riêng ở Đức, DECT vẫn còn rất phổ biến
    Bền bỉ hơn VoIP qua WiFi rất nhiều

    • Tôi xem đó là truyền thống của CCC
    • Đúng vậy. Tuy nhiên cũng có thể dùng GSM hoặc SIP, và trên thực tế dù dùng mạng hiện đại, không gian số vẫn giống nhau nên thường được gọi là số DECT
      Vì DECT xuất hiện trước, nó đã trở thành như một danh từ chung cho mạng điện thoại nội bộ

  • Tôi tò mò mức độ hack sâu đến đâu. Việc truyền frame trông chỉ như thiết lập vài thanh ghi rồi chờ ngắt, nên tôi tự hỏi liệu có phải nó đang giao tiếp với một tầng firmware khác thực hiện công việc thật sự hay không
    Làm tôi nhớ đến bo mạch Raspberry Pi Pico. Có SoC RP2040 chính, nhưng WiFi là một module WiFi/BT riêng (CYW43xx) có lõi Arm riêng. Giao diện thanh ghi bên ngoài của module WiFi cũng không được tài liệu hóa công khai, nhưng có driver mã nguồn mở (https://github.com/georgerobotics/cyw43-driver/tree/cf924bb0...) nên có thể suy luận ra đặc tả. Tuy nhiên driver này rốt cuộc cũng giao tiếp với phần mềm chạy trên lõi Arm bên trong module, và mã đó được nhà sản xuất cung cấp dưới dạng một blob nhị phân firmware khổng lồ. Blob đó thực ra nằm trong các file header ở thư mục firmware của kho lưu trữ được liên kết. Tôi tò mò vụ hack ESP32 lần này tương ứng với cấu trúc đó như thế nào

  • Ấn tượng là các diễn giả trông thật sự rất trẻ. Thật thú vị khi thấy họ tích lũy được mức kiến thức kỹ thuật như vậy ở độ tuổi còn trẻ đến thế

    • Ngày nay mọi thứ đều được công khai. Trẻ em có thể học những gì chúng muốn ở độ tuổi ngày càng nhỏ hơn
      Cờ vua là một ví dụ hoàn hảo. Trước đây nhiều kiến thức nằm trong sách, và thường là sách tiếng nước ngoài. Giờ thì mọi thứ đều công khai, và khi đạt đến một trình độ nhất định, bạn có thể dễ dàng chơi với đối thủ trong top 100, nên tốc độ tiến bộ nhanh hơn

  • Tiến thêm một bước tới thư viện MicroPython hỗ trợ chế độ promiscuous

    • Tại sao? Cái đó ESP SDK đã hỗ trợ rồi

  • Xem không cần tải xuống: https://media.ccc.de/v/38c3-liberating-wi-fi-on-the-esp32/pl...