LTESniffer: công cụ nghe lén downlink/uplink LTE mã nguồn mở
(github.com/SysSec-KAIST)- LTESniffer là công cụ mã nguồn mở có thể thu các thông điệp vô tuyến downlink/uplink giữa trạm gốc LTE và smartphone, trước tiên lấy DCI và RNTI từ PDCCH rồi giải mã PDSCH·PUSCH để phân tích lưu lượng dữ liệu
- Không thể giải mã các thông điệp đã mã hóa; chỉ có thể phân tích các phần không được mã hóa như header tầng MAC và tầng vật lý, các thông điệp broadcast của trạm gốc hoặc các thông điệp plain text ở giai đoạn đầu kết nối
- API phục vụ nghiên cứu bảo mật hỗ trợ 3 chức năng: identity mapping, IMSI collecting, UE capability profiling; đây là triển khai nhằm bổ sung giả định về passive sniffer trong các nghiên cứu bảo mật LTE trước đây bằng khả năng giải mã gói giao thức PDSCH·PUSCH
- Phạm vi tính năng gồm LTE Advanced·LTE Advanced Pro, uplink·downlink tối đa 256QAM, FDD, trạm gốc tối đa 20MHz, DCI formats 0/1A/1/1B/1C/2/2A/2B, transmission modes 1~4
- Để giải mã thời gian thực cần CPU đa lõi vật lý và cấu hình SDR; việc thu lưu lượng uplink khó hơn do tín hiệu UE yếu nên sniffer phải ở gần smartphone hoặc cần tăng cường phần cứng như anten định hướng, RF front-end, bộ khuếch đại
LTESniffer làm gì
- LTESniffer là công cụ nghe lén mã nguồn mở có thể thu cả downlink và uplink LTE
- Luồng hoạt động là trước tiên giải mã PDCCH để lấy DCI và RNTI của các người dùng đang hoạt động, sau đó dùng chúng để tiếp tục giải mã PDSCH và PUSCH nhằm lấy lưu lượng dữ liệu uplink·downlink
- Từ góc nhìn người dùng phổ thông, đây là công cụ thu hai chiều các thông điệp vô tuyến LTE qua lại giữa trạm gốc và smartphone đang kết nối
- Không thể giải mã các thông điệp đã mã hóa
- Với thông điệp đã mã hóa, có thể phân tích các phần không được mã hóa như header tầng MAC và tầng vật lý
- Các thông điệp broadcast của trạm gốc được truyền ở dạng plain text hoặc các thông điệp đầu phiên kết nối có thể được phân tích đầy đủ
API nghiên cứu bảo mật và mục đích nghiên cứu
- LTESniffer cung cấp 3 chức năng API cho ứng dụng và nghiên cứu bảo mật
- identity mapping
- IMSI collecting
- UE capability profiling
- Nhiều nghiên cứu bảo mật LTE giả định có một passive sniffer có thể thu các gói liên quan đến quyền riêng tư trên không trung, nhưng tác giả cho biết các sniffer mã nguồn mở trước đây không đáp ứng được yêu cầu vì không giải mã được các gói giao thức của PDSCH và PUSCH
- Chi tiết được tổng hợp trong bài báo
- Mục tiêu chính của LTESniffer là hỗ trợ nghiên cứu bảo mật và phân tích mạng di động
- Vì thu thập dữ liệu người dùng uplink·downlink, cần tuân thủ quy định địa phương về sniffing lưu lượng LTE
- Nhà phát triển không chịu trách nhiệm cho việc sử dụng vào mục đích bất hợp pháp như cố ý thu thập thông tin liên quan đến quyền riêng tư của người dùng
Tính năng hỗ trợ và nền tảng triển khai
- LTESniffer được xây dựng trên FALCON và sử dụng thư viện srsRAN
- Phạm vi hỗ trợ chính như sau
- Giải mã thời gian thực uplink·downlink cho các kênh điều khiển và dữ liệu PDCCH, PDSCH, PUSCH
- LTE Advanced và LTE Advanced Pro
- Cả uplink và downlink đều hỗ trợ tối đa 256QAM
- DCI formats 0, 1A, 1, 1B, 1C, 2, 2A, 2B
- transmission modes 1, 2, 3, 4
-
Chỉ hỗ trợ FDD
- Trạm gốc tối đa 20MHz
- Tự động phát hiện sơ đồ điều chế UL/DL tối đa theo từng smartphone
- Tự động phát hiện cấu hình tầng vật lý theo từng UE
- RNTI-TMSI mapping, IMSI collecting, UE Capability Profiling
- Bản cập nhật v2.1.0 bổ sung ghi file IQ raw data theo subframe, giải mã offline bằng file đã ghi và kích hoạt API ở chế độ downlink
- API chế độ downlink chỉ áp dụng cho identity collecting và mapping API
- Nội dung liên quan có trong nhánh
LTESniffer-record-subframevà README - Bản cập nhật v2.0.0 hỗ trợ dùng hai USRP B-series trong chế độ sniffing uplink và sửa lỗi
- Nội dung liên quan có trong nhánh
LTESniffer-multi-usrpvà README
Yêu cầu phần cứng và phần mềm
- Hệ điều hành được xác nhận hoạt động ổn định là Ubuntu 18.04/20.04/22.04
- Việc giải mã lưu lượng LTE thời gian thực đòi hỏi CPU hiệu năng cao với nhiều lõi vật lý trong giờ cao điểm khi trạm gốc có nhiều người dùng hoạt động
- Có trường hợp giải mã thời gian thực lưu lượng của trạm gốc với 150 người dùng hoạt động trên PC Intel i7-9700K
- Cấu hình khuyến nghị là CPU Intel i7 với từ 8 lõi vật lý trở lên, RAM từ 16GB, SSD 256GB trở lên
- Khi chỉ sniff downlink, có thể dùng hầu hết SDR được srsRAN hỗ trợ
- Ví dụ là USRP hoặc BladeRF
- SDR phải được kết nối với PC qua USB 3.0
- Để giải mã thông điệp downlink ở transmission modes 3·4 cần 2 anten RX
- Nếu chỉ có 1 anten RX thì chỉ giải mã được thông điệp downlink ở transmission mode 1
- GPSDO giúp cải thiện đồng bộ trong sniffing downlink nhưng không bắt buộc
- Sniffing uplink cần nghe đồng thời hai tần số uplink và downlink, nên hỗ trợ hai cấu hình
- Một USRP X310 đơn lẻ: 2 kênh RX có thể chỉnh tới các tần số uplink·downlink khác nhau, GPSDO là tùy chọn
- 2 thiết bị USRP B-Series: dùng B210/B200 riêng cho uplink và downlink, đồng bộ hai USRP bằng GPSDO làm clock source và time reference
- Với cấu hình 2 USRP B-Series, GPSDO là bắt buộc
Cài đặt và quy trình chạy
- Trước khi build từ source cần cài UHD 4.0 trở lên, và khuyến nghị build từ source
- Sau khi cài dependency của srsRAN và LTESniffer, clone repository rồi build bằng
cmake,make -j 4 - Sau khi build, file thực thi nằm tại
<build-dir>/src/LTESniffer - Có 3 chế độ chạy chính
- Sniff lưu lượng downlink LTE từ trạm gốc
- Sniff lưu lượng uplink LTE từ smartphone tới trạm gốc
- API bảo mật
- Trước khi dùng trên mạng thương mại, cần kiểm tra quy định địa phương về sniffing lưu lượng LTE
- Để kiểm tra trạm gốc mà smartphone thử nghiệm đang kết nối cùng băng tần uplink·downlink, có thể dùng Cellular-Z cho Android
- LTESniffer cũng phải kết nối vào cùng cell và tần số đó
Đầu ra và phân tích
- LTESniffer xuất ra file pcap, có thể phân tích thêm và truy vết gói bằng Wireshark
- Tên file được tạo khác nhau theo từng chế độ
- Downlink:
sniffer_dl_mode.pcap - Uplink:
sniffer_ul_mode.pcap - API:
api_collector.pcap
- Downlink:
- File pcap được tạo trong cùng thư mục nơi LTESniffer đang chạy
- Để Wireshark phân tích đúng các gói đã giải mã, cần tham khảo hướng dẫn cấu hình trong
pcap_file_example/README.md - File pcap uplink chứa cả thông điệp uplink lẫn downlink
- Nếu chỉ muốn xem uplink, dùng bộ lọc
mac-lte.direction == 0 - Nếu chỉ muốn xem downlink, dùng bộ lọc
mac-lte.direction == 1
- Nếu chỉ muốn xem uplink, dùng bộ lọc
Giới hạn khoảng cách của sniffing uplink
- Phạm vi hiệu quả của uplink trong LTESniffer bị giới hạn bởi hiệu năng của RF front-end như SDR
- UE là thiết bị di động tối ưu pin nên công suất tín hiệu uplink yếu hơn rất nhiều so với tín hiệu downlink từ trạm gốc
- Để thu thành công lưu lượng uplink, có thể tăng công suất tín hiệu thu theo các cách sau
- Đặt thiết bị ở gần UE về mặt vật lý
- Dùng phần cứng chuyên dụng như anten định hướng, RF front-end chuyên dụng hoặc bộ khuếch đại tín hiệu
Hạn chế và phương án thay thế nêu trong FAQ
- GPSDO hữu ích để đồng bộ ổn định hơn, nhưng với sniffing downlink thì vẫn có thể đồng bộ với tín hiệu LTE và giải mã gói ngay cả khi không có GPSDO
- Trong sniffing uplink, GPSDO chỉ cần khi dùng 2 USRP B-series
- Cấu hình một USRP X310 đơn lẻ không cần GPSDO
- Lưu lượng downlink về mặt kỹ thuật cũng có thể chạy với SDR như BladeRF được thư viện srsRAN hỗ trợ
- Tuy vậy, chức năng downlink của LTESniffer mới chỉ được kiểm thử trên USRP B210 và X310
- Tính hợp pháp của việc dùng LTESniffer phụ thuộc vào quy định địa phương về sniffing lưu lượng LTE không mã hóa
- Một phương án thử nghiệm khác là dựng mạng LTE riêng dựa trên srsRAN bên trong lồng Faraday
- Nội dung thông điệp giữa hai người dùng chỉ xem được ở phần không mã hóa
- Phần lớn lưu lượng vô tuyến giữa trạm gốc và người dùng đều được mã hóa
- Trong mạng LTE có nhiều định danh bị lộ ở dạng plain text trong tài liệu nghiên cứu như TMSI, GUTI, IMSI, RNTI
- Tài liệu ví dụ được nêu là Watching the Watchers: Practical Video Identification Attack in LTE Networks
1 bình luận
Các ý kiến trên Hacker News
Chuẩn mạng di động rất tuyệt vì đầy rẫy chữ viết tắt
Nếu bạn chưa biết thì chữ Q trong PHICH nghĩa là "request"
Trong đó "ARQ" có lẽ có thể viết đầy đủ như https://en.wikipedia.org/wiki/Automatic_repeat_request
Một số người có thể nói chữ "Q" trong "ARQ" thực ra là "query", và những ai diễn giải là "request" thì đang đánh giá thấp vốn từ vựng trung bình
Cá nhân tôi, nghĩ kỹ thì thấy nhiều khả năng Q không phải là "request" hay "query", mà là một dấu vết khác của Q code theo quy ước nhưng khó hiểu trong https://en.wikipedia.org/wiki/Q_code
Đây là chữ Q trong PHICH: https://github.com/srsran/srsRAN_4G/blob/master/lib/src/phy/...
Như bình luận anh em đã nói, q là chữ Q trong reQuest
Trông có vẻ hay
Có một số hạn chế vì chỉ hỗ trợ FDD, không có TDD, và bị giới hạn ở 20MHz
Điều thú vị là dường như nó cũng có thể giải mã thời gian thực ở mức nào đó. Ở trạm gốc, phần lớn xử lý được đảm nhiệm bởi các bộ xử lý khá đa dụng, nhưng dù vậy vẫn được tích hợp chặt chẽ với phần cứng hơn phần mềm này rất nhiều
Tiếc là phần cứng để chạy cái này quá đắt :'(
Vì vậy chắc cũng chạy được trên limesdr
Nếu muốn rẻ hơn, có thể thử antsdr hoặc adalm-pluto: https://github.com/srsran/zynq_timestamping
Cũng có nhiều ghi chú hữu ích: https://www.quantulum.co.uk/blog/private-lte-with-analog-ada...
Một số tính năng cũng chạy được với dongle rtl-sdr giá rẻ. Đây là fork của dự án cũ https://github.com/Evrytania/LTE-Cell-Scanner
Hơi lạc đề, nhưng tôi tò mò liệu đã có ai thử nghe lén DSL chưa
DSL hiện đại, đặc biệt là VDSL2, về bản chất là tín hiệu tần số cao chạy trên cặp dây xoắn không được che chắn, nên nếu có cả nhánh rẽ trên đường dây thì chắc sẽ dễ rò rỉ và phát xạ ra ngoài
Thực tế có vẻ đúng đến mức các nhà vô tuyến nghiệp dư ở Anh đã phàn nàn rất nhiều về chuyện này[1]. Tôi tự hỏi liệu tín hiệu đó vẫn có thể giải điều chế được không, hay chỉ là một nhiễu nền khó chịu trong phổ tần
[1]: https://rsgb.services/public/publications/vdsl/measuring_and...
Cũng có âm thanh handshake của Adsl2: https://www.youtube.com/watch?v=foPGdfsrskA
Tôi nhớ đã thấy một cái tương tự với modem cáp DOCSIS nhưng không tìm được :(
Một sự thật thú vị ít được biết đến là các thế hệ điện thoại di động số ban đầu nằm ở điểm lưng chừng về độ khó giải mã
Hoàn toàn không dễ, nhưng cũng đủ dễ để bẻ khóa. Mã hóa thực sự đã bị phá
Rainbow table nặng 2TB và mất vài tháng để tạo: https://github.com/0xh4di/GSMDecryption?tab=readme-ov-file
Giờ tôi tự hỏi liệu các thế hệ sau đó có còn một vài lỗ hổng giải mã vì lý do này nọ hoặc do tác nhân cấp quốc gia nào đó không
Công việc thú vị, và thật vui khi thấy loại mã nguồn mở này vẫn còn được dùng
Khoảng 10 năm trước, tôi từng thử nghe lén downlink trong phòng nghiên cứu an ninh mạng của trường đại học
Một trong các dự án là đo xem hoạt động của cell giảm bao nhiêu trong kỳ nghỉ xuân, và một dự án khác là xem liệu có thể thực hiện tấn công timing vào một số điện thoại đã biết ở một vị trí đã biết để rút ra ID tạm thời, rồi gọi lặp lại để xem nó còn ở khu vực đó không
Theo tôi, ID tạm thời đó không đủ tạm thời. Làm tôi muốn quay lại vọc tiếp
Cũng có một số dongle 4G có chế độ debug bị hỏng đã biết, có thể dùng để trích xuất thông tin
LTESniffer được nói là mã nguồn mở, nhưng có vẻ không có tệp LICENSE ở cấp cao nhất và cũng không có thiết lập giấy phép trên kho GitHub
Để bao quát cả các tệp build và các tệp hỗ trợ khác, nên thêm một tệp LICENSE ở cấp cao nhất