Trong quá trình nghiên cứu bảo mật các thiết bị IoT, chắc hẳn ai cũng sẽ gặp trường hợp thiết bị không có Log, không có shell, Khiến việc phân tích firmware trở nên khó khăn. Vậy vấn đề đặt ra liệu ta có thể sửa dữ liệu, thêm các option tùy ý để thuận tiện quá trình phân tích thiết bị hay không????
Bài viết này tôi sẽ không đề cập tới việc decrypt/encrypt firmware hay các vấn đề liên quan mà sẽ tập trung vào quá trình verify của Uboot và Kernel.
U-boot
Sau khi có được firmware đã decypt, extract firmware để lấy filesystem, thử thêm một lệnh bất kỳ vào /etc/init.d và nạp lại vào thiết bị. Lúc này chương trình báo lỗi trong quá trình Boot (ERROR: Kernel Secure Check Falied, Can't StartUp)
Vậy có thể kết luận nhanh là Uboot đã check kernel, ta sẽ phải phân tích Uboot đầu tiên.
Sau thời gian reverse ta sẽ tìm được nơi mà bước check này được xử lý.
Có 3 nguyên nhân dẫn tới Kernel Secure Check Falied, Can't StartUp
- Image null
- No Signature
- Verify Data Fail
Khi biết rõ nguyên nhân, ta có 2 giải pháp:
- Patch 3 hàm xử lý check
- Patch hàm chính gọi tới 3 hàm check này (đây là cách tốt nhất)
Dù Verify_data failed nhưng chương trình vẫn tiếp tục và gọi kernel. Coi như vấn đề này đã xong, khi chương trình khởi động lên thì nó bị reset liên tục, theo phán đoán thì lúc này kernel đã tiếp tục check Filesystem.
Kernel
Kernel nằm trong file có tên uImage, sau khi decrypt ta có những phân đoạn sau.
Nó được nén gzip, ta cắt ra và giải nén thì có được các module xử lý của kernel, tiến hành reverse nào.
Danh sách các filesystem được kernel kiểm tra sẽ nằm trong /etc/SigFilePartition, chương trình sẽ đọc và lưu danh sách filesystemvào bộ đệm rootlistbuff và lưu lại vào file /etc/SigFileList
Nội dung các file nằm trong /etc/SigFileList này sẽ được đọc và hash thành 1 giá trị 32-bytes.
Trong firmware tồn tại 1 file /etc/Data_signature, file này chứa giá trị hash filesystem gốc của firmware khi được sản xuất.
Hai kết quả hash của quá trình này sẽ được so sánh với nhau, nếu kết quả khác thì chương trình đã bị thay đổi và sẽ nhảy vào reliableenv_rebooot(). Và đó là lý do sau khi ta thêm thử 1 lệnh thì chương trình bị reset liên tục. Lý do đã rõ, thì ta có thể patch đoạn check và tùy ý thêm sửa nội dung trong filesystem.
Thử nghiệm
Mặc định Telnet của thiết bị không thể truy cập.
Tôi sẽ thêm 1 Binary mới vào thư mục bin và chạy dịch vụ Telnet để lấy shell trên port 5555.
Và đây là kết quả, ta đã có shell trên thiết bị, tha hồ debug và tìm lỗi.
