VNZ-ROAD
NEXTVNZ
Bài viết được chia sẻ và phân tích bởi một bạn có nick TigerPuma, tại trang tradhackingvn. đọc bài sẽ thấm câu đời chẳng cho không ai cái gì”
Copy về để anh em Vn-Zoom đọc và tham khảo
Mở đầu
Sau khi đọc bài của anh superkhung về phân tích lỗ hổng bảo mật của camera (xem bài viết tại đây), mình cảm thấy rất phấn khích và cũng muốn chia sẻ 1 chút kinh nghiệm cho các bạn đi sau về cách phân tích và tiếp cận với các thiết bị nhúng, hi vọng cộng đồng làm embedded security trong nước sẽ lớn mạnh dần lên trước cơn bão IoT đang vần vũ ngoài kia. Loạt bài này sẽ gồm 2 phần, phần 1 sẽ để cập đến cách tiếp cận 1 thiết bị nhúng lấy firmware, giải mã các phân vùng encoded/encrypted, map các segment trên IDA để phân tích, phần 2 sẽ nói về reverse và 1 số kết quả thu được sau khi reverse (có nhiều vấn đề mà trước đây rất nhiều người trong đó có cả mình đổ lỗi do nhà mạng nhưng thực tế lại thật bất ngờ).
Bài phân tích này mình thực hiện cũng lâu rồi, tại thời điểm đó xảy ra nhiều việc để mình rất thấm cái câu “đời chẳng cho không ai cái gì” lại thêm thằng bạn “thân” cho mượn con Iphone 6 “Tung của”, trí tò mò khiến mình quyết định phẫu thuật thử xem anh bạn “hàng xóm phương bắc” liệu có “cho không” anh bạn phía Nam được cái gì không mà sao lại bán rẻ đến vậy.
P/S: các cách tiếp cận mà mình đưa ra không phải là duy nhất, vì vậy rất welcome các bạn cùng vào bàn luận về các kỹ thuật advance khác. >
<
Phần cứng
Quan sát từ bên ngoài có vẻ không khác hàng thật mấy từ cái camera lồi, switch gạt im lặng, dải anten, khe sim … . Còn phần cứng bên bao gồm CPU: Mediatek SOC MT6250A, Flash 16Mb 25LQ128YIG, Radio: HS8269U …. Khi bật nguồn, màn hình có vẻ chất lượng không được tốt, các giao diện bên trong cũng y nguyên như iphone chính hãng (Message, Maps, ibooks, AppStore …), tất nhiên các app này đều fake và chẳng liên quan gì đến Apple cả. Vào thử 1 số app thấy khá giống app trên các điện thoại feature phone hồi xưa. Sau 1 hồi trải nghiệm, kết luận đầu tiên ngoài cái màn hình to có cảm ứng, còn lại cũng chỉ ngang con Nokia chèn bánh xe của mình, đúng là tiền nào của nấy, haizzz.
Đọc firmware
Sau khi phân tích phần cứng có 2 cách để đọc firmware:
- Board sử dụng IC flash ngoài ta có thể bóc flash ra và gắn vào mạch đọc bên ngoài.
- Tìm cổng debug (JTAG/SWD, ICSP, UART, USB, SPI …) để đọc ngược firmware ra.
Ở đây mình sử dụng cách 2 trước để không phải can thiệp phần cứng đến mạch, trong trường hợp giải pháp này không thành công sẽ suy nghĩ đến cách 1.
Dò một lượt trong mạch không thấy chân JTAG, UART chỉ thấy cổng USB. Check trong datasheet của chip MT6250A thấy chip có hộ trợ BSL (Bootstrap Loader) qua cổng USB (mình hay tìm datasheet trên baidu, google.ru). Google thêm 1 chút thì thấy ít nhất có 2 tool có thể đọc được firmware ra: Flashtool, GPGDragon. Các bạn có thể sử dụng bất kì tool nào trong 2 tool đều được.
Phân tích firmware
Sau khi đọc lên ta sẽ có 1 file binary 16M (bằng size với flash), sử dụng binwalk để xem trong binary này có những gì.
Do các các phân vùng bao gồm cả các file raw nên sau khi filter lại ta sẽ có các phân vùng như sau (sau segment VIVA là vùng FAT32, vùng này sẽ được mount lên sau khi thiết bị chạy):
Dựa vào các thông tin trên mình cắt nhỏ firmware và load thử lên IDA:
Nhìn như trên hình thì IDA nhận diện được rất ít hàm.Khả năng cao là firmware đã bị mã hóa hoặc encode rồi.
Theo cách tiếp cận thông thường, muốn đi ngược được thì bạn ít nhất phải nắm rất rõ làm thế nào để đi xuôi, đặc biệt là khi làm với các thiết bị nhúng nền tảng cực kì đa dạng và rất đặc thù. Do đó, hãy tìm cách đi xuôi trước, tìm hiểu rõ các bước làm sao để build được helloworld, làm sao để đẩy helloworld xuống (tất nhiên mình khuyến cáo các bạn không nên đẩy xuống ngày khi vẫn còn chưa hiểu rõ về con chip, rất có thể bạn sẽ làm brick nó và hết đồ chơi luôn). Ngoài ra file helloworld bạn build được sẽ rất có ích cho việc reverse sau này.
Cái đầu tiên mình nghĩ đến là tìm xem có tải được sourcecode và tutorial ở đâu đó hướng dẫn dev trên con này không, vẫn như thường lệ cái gì không ở đâu có thì hãy tìm trên baidu, không phải chém nhưng cộng đồng tàu khựa rất mạnh và thường cũng hay leak những cái rất hay ho. Dựa vào 1 vài pattern trong file binary vừa đọc được, mình tìm được 1 bộ source trên baidu, tải về và giải nén ra được 1 thư mục khoảng 7GB.
Tiến hành thiết lập môi trường và build thử, do logbuild khá dài nên mình log tạm ra 1 file để tiện đọc lại. thời gian build khá lâu mất khoảng hơn 1 tiếng. Trong quá trình chờ build lên google tìm hiểu thêm 1 chút về quá trình boot của con MTK này. Quá trình boot chia thành 4 tầng:
- ROM code kiểm tra signature và load Bootloader
- Bootloader kiểm tra signature và load External Bootloader
- External Bootloader kiểm tra signature và load ROM_GHF (Primary_MAUI) -> phần này có thể coi như kernel, bao gồm các driver và cả scheduler
- ROM_GHF sử dụng hardware giải nén VIVA và load VIVA -> phần này tương đương user space, bao gồm toàn bộ các ứng dụng chạy bên trên (UI, aplication, …), đây là phần chứa nhiều customize code nhất. Do phần này bị nén nên đây là lý do vì sao khi load lên IDA lại không nhận diện được các hàm.
Sau khi buid xong, trace Trong logbuild cũng xác định được phần VIVA được nén bởi script aliceProcess.pm
Script gọi đến ứng dụng ALICE.exe
Việc tiếp theo chúng ta cần phải giải nén phân vùng code này, có 2 cách để thực hiện tiếp:
- Dịch ngược file Alice.exe kia xem nó sử dụng giải thuật nén gì và làm ngược lại.
- Modify lại ROM_GHF code để sau khi nó giải nén xong ta sẽ dump toàn bộ và lưu vào thẻ nhớ.
Dịch ngược window file không phải là thế mạnh của mình nên mình lại chọn cách 2 (thực ra mình cũng thử sơ qua cả cách 1 bằng cách google 1 vài chuẩn nén thông dụng rồi dùng 7zip uncompress nhưng không thành công). Tuy nhiên vấn đề ở chỗ các tầng boot đều kiểm tra signature. Check lại trong logbuild phát hiện đoạn signature được ký bởi script gfh_process.pl.
Với key file.
Okie, với 1 sự may mắn không hề nhỏ là con iphone này lại sử dụng luôn chữ ký mặc định giống trong source leak, mọi chuyện lại trở nên đơn giản.
Sử dụng keypatch (http://www.keystone-engine.org/keypatch/) tiến hành sửa bỏ phần check signature của External Bootloader để không check signature của ROM_GHF code nữa. Sau đó sign lại External Bootloader, từ đây yên tâm thoải mái sửa ROM_GHF mà không sợ bị reject nữa.
Sau khi sửa bootloader, chúng ta sẽ tiếp tục sửa lại code phần ROM_GHF, do phần FAT32 trên flash chỉ còn lại dung lượng rất nhỏ (~13kb) không đủ chứa VIVA code sau khi giải nén, do đó mình lựa chọn đẩy thẳng ra thẻ nhớ, để đảm bảo thẻ nhớ khởi tạo xong, mình chọn 1 action sẽ được gọi đến sau khi hệ thống đã khởi động (hàm LCD_Physical_Interface_Lock), hàm này được gọi khi bạn bấm nút tắt màn hình.
Sử dụng chính tool đọc firmware load 2 binary vừa sửa xuống (với flash_tool thì sửa lại file scatter, comment các phân vùng còn lại, còn với GPGDragon thì sử dụng 010 editer replace 2 phân vùng vừa sửa vào file 16M sau đó ghi cả 16M xuống). sau đó khởi động lại điện thoại, bấm tắt màn hình và đợi một lúc (do chúng ta đã can thiệp vào driver nên sẽ phải chờ 1 lúc điện thoại mới tắt được màn hình), sau khi màn hình tắt, giữ nút nguồn để tắt hẳn điện thoại, tháo thẻ nhớ và tận hưởng thành quả:
IDA đã load được hầu hết các hàm ở vùng VIVA (trước khi giải nén có magic header là “ALICE”, sau khi giải nén xong sẽ có header là CAKE).
Okie như vậy toàn bộ firmware đã được giải nén, hẹn gặp lại các bạn ở part 2
P/S: Bonus cái ảnh file raw (tạm gọi là helloworld đi) sau khi mình build lại, các bạn có thể sử dụng file helloworld này để nắm được cấu trúc các segment cơ bản của chip, từ đó map lại vào IDA hoặc load các segment chạy giả lập.
Phần 2
Điện thoại trung quốc có thực sự rẻ ???? (Phần 2)
Như ở phần trước mình đã mô tả các bước tiếp cận để có thể lấy được firmware của 1 chiếc điện thoại Iphone Trung Quốc (ai chưa đọc có thể xem tại đây), phần 2 này mình sẽ hồi ký tiếp phần phân tích và những phát hiện khá shock về dòng điện thoại này (Phần này mình hầu như lót dép hóng nên phần mô tả kỹ thuật sẽ không chi tiết như trước, tuy nhiên sẽ vẫn có những kinh nghiệm nho nhỏ đặc thù riêng của reverse thiết bị nhúng).
Map address
Từ bảng địa chỉ lấy được từ binwalk chúng ta sẽ load lần được các phân vùng code lên IDA, tuy nhiên đây chỉ có các phân vùng code, ngoài ra còn có các vùng RAM ( và địa chỉ của các register của module ngoại vi: timer, gsm, gpio, lcd …). Để tìm ra địa chỉ các vùng RAM có thể tra datasheet, hay tham khảo “helloworld” hoặc tra google :v.
Sau khi có địa chỉ chúng ta sẽ tạo các segment trên IDA như sau (ở đây mình không map riêng vùng peripheral bởi vì số lượng các khối ngoại vi rất nhiều, khi dịch ngược sử dụng đến module nào mình sẽ tra trực tiếp datasheet và tạo biến mang tên thanh ghi của module chức năng đó).
Map symbol
Do firmware khi nạp xuống đã bị strip đi toàn bộ các phân vùng symbol, do đó khi load lên IDA sẽ chỉ toàn sub_xxxx mà thôi, điều này khiến cho việc dịch ngược cục firm khoảng gần 10Mb trở nên tương đối khó khăn, điều này cũng sẽ thường xuyên gặp với các thiết bị nhúng, đặc biết là các thiết bị không sử dụng MMU.
Có 2 tool có thể làm việc reverse trở nên đơn giản hơn: bindiff và rizzo, tuy nhiên bắt buộc bạn phải build được helloworld như bài trước và sử dụng càng nhiều hàm trong thư viện trên helloworld càng tốt.
Làm theo hướng dẫn của các tool compare giữa file mẫu helloworld và firmware ta sẽ có:
Đây cũng chính là cách mà mình tìm ra vị trị hàm trong ROM_GHF ở bài viết trước để insert code đọc vùng dữ liệu encode ra.
Tuy nhiên đừng vội mừng, trick này cũng không phải là tuyệt đối để bạn có thể vểnh râu ngồi đọc binary như đọc code C được đâu bởi vì:
- Tool rất hay nhận sai với các hàm nhỏ ít intruction (có thể compare 100% giống nhau nhưng thực tế lại chẳng liên quan gì đến nhau vì nó là hàm wraper cho 2 hàm khác nhau trong thư viện).
- Các hàm thực sự mà “đối thủ” phía bên kia code cũng không thể nhận ra vì đương nhiên nó chẳng nằm trong lib nào để mà compare cả.
Trên đây là toàn bộ những gì mình chia sẻ về kỹ thuật, còn khi dịch ngược, sẽ tùy mục đích bạn tìm bug để khai thác hay tìm kiếm backdoor sẽ có những chiến thuật khác nhau, ngoài ra còn phụ thuộc nhiều vào kinh nghiệm của chính bản thân bạn nữa. Nếu ai chỉ muốn tìm hiểu về kỹ thuật tiếp cận thiết bị nhúng thì có thể dừng tại đây.
Mục đích lần này của mình là trả lời cho câu hỏi: “Điện thoại Trung quốc liệu có thực sự rẻ ???” do đó mình chọn cách tiếp cận theo hướng tìm backdoor dấu trong firmware.
Và câu trả lời là không. Đương nhiên các bạn đã đoán được từ đầu, nhưng tại sao lại không?
Liệu có bao giờ chúng ta nghĩ rằng mua 1 chiêc iphone chỉ khoảng hơn triệu đồng nhưng thực tế đang phải trả lãi hàng tháng vài trục đến vài trăm nghìn, điều đó hoàn toàn có thể xảy ra bởi vì rất nhiều mẫu điễn thoại trên thị trường đã bị gắn sẵn backdoor.
Cụ thể backdoor như thế nào?
Với chiếc điện thoại iphone Trung quốc, backdoor bao gồm 04 luồng hoạt động chính:
1. Timer “services”: Định kỳ gọi điện theo cấu hình
- Định kỳ 120 giây (2 phút) thực hiện kiểm tra và gọi điện
- Nếu chưa lấy được IMSI: Thực hiện lấy IMSI
- Nếu đã lấy được IMSI và thỏa mãn điều kiện sau, thực hiện gọi:
o Máy đang idle
o Số gọi đi khác “NULL” và “0”
o Số ngày đã đợi >= tần suất
o Thời gian (giờ, phút) hiện tại >= Thời gian cấu hình (chỉ gọi điện sau a giờ b phút hàng ngày)
- Thời lượng cuộc gọi là ngẫu nhiên giữa cấu hình min và max
2. Timer “wap”: Định kỳ request lên C&C nhận cấu hình gọi điện
- Định kỳ 43200 giây (12 giờ) request đến C&C nhận lệnh:
o URL: m.w-chen.com/gjservices.php?imsi=%s&resource=%s
o imsi: IMSI của SIM
o resource: ID của máy (trong trường hợp iPhone là MTK11BW1224RT50NEW)
- Dữ liệu trả về có dạng:
<html><head><body><div style=”display:none”>###+265881064634–3–115–117###</div></body></head></html>
o +265881064634: Đầu số quốc tế
o 3: Tần suất gọi (ngày/cuộc)
o 115: Thời lượng gọi min (giây)
o 117: Thời lượng gọi max (giây)
3. Timer “imsi”: Lấy IMSI của SIM
- Chạy 1 lần khi khởi động máy, lấy IMSI của SIM1, nếu không được thì lấy SIM2
4. Timer “services_freq”: Kiểm tra số ngày đợi theo tần suất gọi
- Định kỳ 3600 giây (1 giờ) chạy 1 lần
- Vào giờ “18” hàng ngày, tang biến g_irday (biến cho biết số ngày đã đợi, nếu đủ tần suất sẽ thực hiện gọi điện).
Mục đích của backdoor là gì?
Với cuộc gọi quốc tế có giá cước lên đến hàng chục nghìn 1 phút, bạn có thể sẽ bị hút máu một cách cực kỳ khủng khiếp và ai sẽ được lợi ở đây ???
Chắc hẳn các bạn đều đã từng nghe qua các dịch vụ giá trị gia tăng như: Kể chuyện đêm khuya, nghe nhạc theo yêu cầu, tổng đài nhắn tin dự đoán tỷ số bóng đá, tổng đài xố số, chơi gamek, lô đề… Khi bạn nhắn tin hoặc gọi điện đến các tổng đài này thì bạn sẽ bị trừ tiền tùy theo phí dịch vụ mà tổng đài quy định, nhiều đầu số chỉ cần nhắn tin 1 lần đăng ký và bị trừ tiền hàng tháng. Các đầu số trên backdoor cũng hoạt động theo nguyên tắc giống như vậy.
Với việc quản lý không đủ chặt về các nhà cung cấp dịch vụ nội dung di động (Content Service Provider — SP) như hiện nay, số lượng SP mọc lên như nấm sau mưa với đủ các thể loại dịch vụ. Và đương nhiên khi quản lý không chặt cùng các chế tài xử phạt không đủ sức răn đe thì sẽ xuất hiện rất nhiều tiêu cực, điển hình như gần đây nhất vụ SAM media chỉ bị phạt 55 triệu trong khi thu lời về 230 tỷ ??!!!
Tìm hiểu thêm 1 chút thì mình phát hiện ra thực tế dịch vụ này khá phổ biến tại Trung Quốc, có trang web và banner công khai luôn như ảnh bên dưới đây:
(1) Service Provider đăng ký dịch vụ VAS, báo với Skylin (Công ty cung cấp thiết bị có backdoor)
(2) Skylin build app vào các handset Trung Quốc, xuất bán cho các nhà cung cấp handset
(3) Handset được bán cho người dùng
(4) Người dung lắp SIM, nạp tiền, handset tự động đăng ký dịch vụ
(5) Telco thu tiền người dùng trả cho Service Provider, Service Provider share lợi nhuận với Skylin
Sau phát hiện này, chợt nhớ ra bà cụ ở nhà cũng đang dùng 1 em cục gạch, lại cũng hay kêu vừa nạp tiền được mấy hôm không gọi đi đâu mấy mà đã hết, chột dạ lôi ra kiểm tra thì cũng bị y như em iphone bên trên. Chỉ có khác là không chỉ có 1 loại mã độc mà còn có nhiều loại mã độc trên cùng 1 thiết bị. Các mã độc này đều có C&C riêng và nhận lệnh điều khiển gọi điện hoặc gửi tin nhắn khi có yêu cầu một cách độc lập.
Kết Luận:
Còn chờ gì nữa, hãy kiểm tra lại chính chiếc điện thoại của bạn nếu có thể, giặc ngay bên cạnh bạn đó.
Nguồn P2 P1
Copy về để anh em Vn-Zoom đọc và tham khảo
Mở đầu
Sau khi đọc bài của anh superkhung về phân tích lỗ hổng bảo mật của camera (xem bài viết tại đây), mình cảm thấy rất phấn khích và cũng muốn chia sẻ 1 chút kinh nghiệm cho các bạn đi sau về cách phân tích và tiếp cận với các thiết bị nhúng, hi vọng cộng đồng làm embedded security trong nước sẽ lớn mạnh dần lên trước cơn bão IoT đang vần vũ ngoài kia. Loạt bài này sẽ gồm 2 phần, phần 1 sẽ để cập đến cách tiếp cận 1 thiết bị nhúng lấy firmware, giải mã các phân vùng encoded/encrypted, map các segment trên IDA để phân tích, phần 2 sẽ nói về reverse và 1 số kết quả thu được sau khi reverse (có nhiều vấn đề mà trước đây rất nhiều người trong đó có cả mình đổ lỗi do nhà mạng nhưng thực tế lại thật bất ngờ).
Bài phân tích này mình thực hiện cũng lâu rồi, tại thời điểm đó xảy ra nhiều việc để mình rất thấm cái câu “đời chẳng cho không ai cái gì” lại thêm thằng bạn “thân” cho mượn con Iphone 6 “Tung của”, trí tò mò khiến mình quyết định phẫu thuật thử xem anh bạn “hàng xóm phương bắc” liệu có “cho không” anh bạn phía Nam được cái gì không mà sao lại bán rẻ đến vậy.
P/S: các cách tiếp cận mà mình đưa ra không phải là duy nhất, vì vậy rất welcome các bạn cùng vào bàn luận về các kỹ thuật advance khác. >
<Phần cứng
Quan sát từ bên ngoài có vẻ không khác hàng thật mấy từ cái camera lồi, switch gạt im lặng, dải anten, khe sim … . Còn phần cứng bên bao gồm CPU: Mediatek SOC MT6250A, Flash 16Mb 25LQ128YIG, Radio: HS8269U …. Khi bật nguồn, màn hình có vẻ chất lượng không được tốt, các giao diện bên trong cũng y nguyên như iphone chính hãng (Message, Maps, ibooks, AppStore …), tất nhiên các app này đều fake và chẳng liên quan gì đến Apple cả. Vào thử 1 số app thấy khá giống app trên các điện thoại feature phone hồi xưa. Sau 1 hồi trải nghiệm, kết luận đầu tiên ngoài cái màn hình to có cảm ứng, còn lại cũng chỉ ngang con Nokia chèn bánh xe của mình, đúng là tiền nào của nấy, haizzz.
Đọc firmware
Sau khi phân tích phần cứng có 2 cách để đọc firmware:
- Board sử dụng IC flash ngoài ta có thể bóc flash ra và gắn vào mạch đọc bên ngoài.
- Tìm cổng debug (JTAG/SWD, ICSP, UART, USB, SPI …) để đọc ngược firmware ra.
Ở đây mình sử dụng cách 2 trước để không phải can thiệp phần cứng đến mạch, trong trường hợp giải pháp này không thành công sẽ suy nghĩ đến cách 1.
Dò một lượt trong mạch không thấy chân JTAG, UART chỉ thấy cổng USB. Check trong datasheet của chip MT6250A thấy chip có hộ trợ BSL (Bootstrap Loader) qua cổng USB (mình hay tìm datasheet trên baidu, google.ru). Google thêm 1 chút thì thấy ít nhất có 2 tool có thể đọc được firmware ra: Flashtool, GPGDragon. Các bạn có thể sử dụng bất kì tool nào trong 2 tool đều được.
Phân tích firmware
Sau khi đọc lên ta sẽ có 1 file binary 16M (bằng size với flash), sử dụng binwalk để xem trong binary này có những gì.
Do các các phân vùng bao gồm cả các file raw nên sau khi filter lại ta sẽ có các phân vùng như sau (sau segment VIVA là vùng FAT32, vùng này sẽ được mount lên sau khi thiết bị chạy):
Dựa vào các thông tin trên mình cắt nhỏ firmware và load thử lên IDA:
Nhìn như trên hình thì IDA nhận diện được rất ít hàm.Khả năng cao là firmware đã bị mã hóa hoặc encode rồi.
Theo cách tiếp cận thông thường, muốn đi ngược được thì bạn ít nhất phải nắm rất rõ làm thế nào để đi xuôi, đặc biệt là khi làm với các thiết bị nhúng nền tảng cực kì đa dạng và rất đặc thù. Do đó, hãy tìm cách đi xuôi trước, tìm hiểu rõ các bước làm sao để build được helloworld, làm sao để đẩy helloworld xuống (tất nhiên mình khuyến cáo các bạn không nên đẩy xuống ngày khi vẫn còn chưa hiểu rõ về con chip, rất có thể bạn sẽ làm brick nó và hết đồ chơi luôn). Ngoài ra file helloworld bạn build được sẽ rất có ích cho việc reverse sau này.
Cái đầu tiên mình nghĩ đến là tìm xem có tải được sourcecode và tutorial ở đâu đó hướng dẫn dev trên con này không, vẫn như thường lệ cái gì không ở đâu có thì hãy tìm trên baidu, không phải chém nhưng cộng đồng tàu khựa rất mạnh và thường cũng hay leak những cái rất hay ho. Dựa vào 1 vài pattern trong file binary vừa đọc được, mình tìm được 1 bộ source trên baidu, tải về và giải nén ra được 1 thư mục khoảng 7GB.
Tiến hành thiết lập môi trường và build thử, do logbuild khá dài nên mình log tạm ra 1 file để tiện đọc lại. thời gian build khá lâu mất khoảng hơn 1 tiếng. Trong quá trình chờ build lên google tìm hiểu thêm 1 chút về quá trình boot của con MTK này. Quá trình boot chia thành 4 tầng:
- ROM code kiểm tra signature và load Bootloader
- Bootloader kiểm tra signature và load External Bootloader
- External Bootloader kiểm tra signature và load ROM_GHF (Primary_MAUI) -> phần này có thể coi như kernel, bao gồm các driver và cả scheduler
- ROM_GHF sử dụng hardware giải nén VIVA và load VIVA -> phần này tương đương user space, bao gồm toàn bộ các ứng dụng chạy bên trên (UI, aplication, …), đây là phần chứa nhiều customize code nhất. Do phần này bị nén nên đây là lý do vì sao khi load lên IDA lại không nhận diện được các hàm.
Sau khi buid xong, trace Trong logbuild cũng xác định được phần VIVA được nén bởi script aliceProcess.pm
Script gọi đến ứng dụng ALICE.exe
Việc tiếp theo chúng ta cần phải giải nén phân vùng code này, có 2 cách để thực hiện tiếp:
- Dịch ngược file Alice.exe kia xem nó sử dụng giải thuật nén gì và làm ngược lại.
- Modify lại ROM_GHF code để sau khi nó giải nén xong ta sẽ dump toàn bộ và lưu vào thẻ nhớ.
Dịch ngược window file không phải là thế mạnh của mình nên mình lại chọn cách 2 (thực ra mình cũng thử sơ qua cả cách 1 bằng cách google 1 vài chuẩn nén thông dụng rồi dùng 7zip uncompress nhưng không thành công). Tuy nhiên vấn đề ở chỗ các tầng boot đều kiểm tra signature. Check lại trong logbuild phát hiện đoạn signature được ký bởi script gfh_process.pl.
Với key file.
Okie, với 1 sự may mắn không hề nhỏ là con iphone này lại sử dụng luôn chữ ký mặc định giống trong source leak, mọi chuyện lại trở nên đơn giản.
Sử dụng keypatch (http://www.keystone-engine.org/keypatch/) tiến hành sửa bỏ phần check signature của External Bootloader để không check signature của ROM_GHF code nữa. Sau đó sign lại External Bootloader, từ đây yên tâm thoải mái sửa ROM_GHF mà không sợ bị reject nữa.
Sau khi sửa bootloader, chúng ta sẽ tiếp tục sửa lại code phần ROM_GHF, do phần FAT32 trên flash chỉ còn lại dung lượng rất nhỏ (~13kb) không đủ chứa VIVA code sau khi giải nén, do đó mình lựa chọn đẩy thẳng ra thẻ nhớ, để đảm bảo thẻ nhớ khởi tạo xong, mình chọn 1 action sẽ được gọi đến sau khi hệ thống đã khởi động (hàm LCD_Physical_Interface_Lock), hàm này được gọi khi bạn bấm nút tắt màn hình.
Sử dụng chính tool đọc firmware load 2 binary vừa sửa xuống (với flash_tool thì sửa lại file scatter, comment các phân vùng còn lại, còn với GPGDragon thì sử dụng 010 editer replace 2 phân vùng vừa sửa vào file 16M sau đó ghi cả 16M xuống). sau đó khởi động lại điện thoại, bấm tắt màn hình và đợi một lúc (do chúng ta đã can thiệp vào driver nên sẽ phải chờ 1 lúc điện thoại mới tắt được màn hình), sau khi màn hình tắt, giữ nút nguồn để tắt hẳn điện thoại, tháo thẻ nhớ và tận hưởng thành quả:
IDA đã load được hầu hết các hàm ở vùng VIVA (trước khi giải nén có magic header là “ALICE”, sau khi giải nén xong sẽ có header là CAKE).
Okie như vậy toàn bộ firmware đã được giải nén, hẹn gặp lại các bạn ở part 2
P/S: Bonus cái ảnh file raw (tạm gọi là helloworld đi) sau khi mình build lại, các bạn có thể sử dụng file helloworld này để nắm được cấu trúc các segment cơ bản của chip, từ đó map lại vào IDA hoặc load các segment chạy giả lập.
Phần 2
Điện thoại trung quốc có thực sự rẻ ???? (Phần 2)
Như ở phần trước mình đã mô tả các bước tiếp cận để có thể lấy được firmware của 1 chiếc điện thoại Iphone Trung Quốc (ai chưa đọc có thể xem tại đây), phần 2 này mình sẽ hồi ký tiếp phần phân tích và những phát hiện khá shock về dòng điện thoại này (Phần này mình hầu như lót dép hóng nên phần mô tả kỹ thuật sẽ không chi tiết như trước, tuy nhiên sẽ vẫn có những kinh nghiệm nho nhỏ đặc thù riêng của reverse thiết bị nhúng).
Map address
Từ bảng địa chỉ lấy được từ binwalk chúng ta sẽ load lần được các phân vùng code lên IDA, tuy nhiên đây chỉ có các phân vùng code, ngoài ra còn có các vùng RAM ( và địa chỉ của các register của module ngoại vi: timer, gsm, gpio, lcd …). Để tìm ra địa chỉ các vùng RAM có thể tra datasheet, hay tham khảo “helloworld” hoặc tra google :v.
Sau khi có địa chỉ chúng ta sẽ tạo các segment trên IDA như sau (ở đây mình không map riêng vùng peripheral bởi vì số lượng các khối ngoại vi rất nhiều, khi dịch ngược sử dụng đến module nào mình sẽ tra trực tiếp datasheet và tạo biến mang tên thanh ghi của module chức năng đó).
Map symbol
Do firmware khi nạp xuống đã bị strip đi toàn bộ các phân vùng symbol, do đó khi load lên IDA sẽ chỉ toàn sub_xxxx mà thôi, điều này khiến cho việc dịch ngược cục firm khoảng gần 10Mb trở nên tương đối khó khăn, điều này cũng sẽ thường xuyên gặp với các thiết bị nhúng, đặc biết là các thiết bị không sử dụng MMU.
Có 2 tool có thể làm việc reverse trở nên đơn giản hơn: bindiff và rizzo, tuy nhiên bắt buộc bạn phải build được helloworld như bài trước và sử dụng càng nhiều hàm trong thư viện trên helloworld càng tốt.
Làm theo hướng dẫn của các tool compare giữa file mẫu helloworld và firmware ta sẽ có:
Đây cũng chính là cách mà mình tìm ra vị trị hàm trong ROM_GHF ở bài viết trước để insert code đọc vùng dữ liệu encode ra.
Tuy nhiên đừng vội mừng, trick này cũng không phải là tuyệt đối để bạn có thể vểnh râu ngồi đọc binary như đọc code C được đâu bởi vì:
- Tool rất hay nhận sai với các hàm nhỏ ít intruction (có thể compare 100% giống nhau nhưng thực tế lại chẳng liên quan gì đến nhau vì nó là hàm wraper cho 2 hàm khác nhau trong thư viện).
- Các hàm thực sự mà “đối thủ” phía bên kia code cũng không thể nhận ra vì đương nhiên nó chẳng nằm trong lib nào để mà compare cả.
Trên đây là toàn bộ những gì mình chia sẻ về kỹ thuật, còn khi dịch ngược, sẽ tùy mục đích bạn tìm bug để khai thác hay tìm kiếm backdoor sẽ có những chiến thuật khác nhau, ngoài ra còn phụ thuộc nhiều vào kinh nghiệm của chính bản thân bạn nữa. Nếu ai chỉ muốn tìm hiểu về kỹ thuật tiếp cận thiết bị nhúng thì có thể dừng tại đây.
Mục đích lần này của mình là trả lời cho câu hỏi: “Điện thoại Trung quốc liệu có thực sự rẻ ???” do đó mình chọn cách tiếp cận theo hướng tìm backdoor dấu trong firmware.
Và câu trả lời là không. Đương nhiên các bạn đã đoán được từ đầu, nhưng tại sao lại không?
Liệu có bao giờ chúng ta nghĩ rằng mua 1 chiêc iphone chỉ khoảng hơn triệu đồng nhưng thực tế đang phải trả lãi hàng tháng vài trục đến vài trăm nghìn, điều đó hoàn toàn có thể xảy ra bởi vì rất nhiều mẫu điễn thoại trên thị trường đã bị gắn sẵn backdoor.
Cụ thể backdoor như thế nào?
Với chiếc điện thoại iphone Trung quốc, backdoor bao gồm 04 luồng hoạt động chính:
1. Timer “services”: Định kỳ gọi điện theo cấu hình
- Định kỳ 120 giây (2 phút) thực hiện kiểm tra và gọi điện
- Nếu chưa lấy được IMSI: Thực hiện lấy IMSI
- Nếu đã lấy được IMSI và thỏa mãn điều kiện sau, thực hiện gọi:
o Máy đang idle
o Số gọi đi khác “NULL” và “0”
o Số ngày đã đợi >= tần suất
o Thời gian (giờ, phút) hiện tại >= Thời gian cấu hình (chỉ gọi điện sau a giờ b phút hàng ngày)
- Thời lượng cuộc gọi là ngẫu nhiên giữa cấu hình min và max
2. Timer “wap”: Định kỳ request lên C&C nhận cấu hình gọi điện
- Định kỳ 43200 giây (12 giờ) request đến C&C nhận lệnh:
o URL: m.w-chen.com/gjservices.php?imsi=%s&resource=%s
o imsi: IMSI của SIM
o resource: ID của máy (trong trường hợp iPhone là MTK11BW1224RT50NEW)
- Dữ liệu trả về có dạng:
<html><head><body><div style=”display:none”>###+265881064634–3–115–117###</div></body></head></html>
o +265881064634: Đầu số quốc tế
o 3: Tần suất gọi (ngày/cuộc)
o 115: Thời lượng gọi min (giây)
o 117: Thời lượng gọi max (giây)
3. Timer “imsi”: Lấy IMSI của SIM
- Chạy 1 lần khi khởi động máy, lấy IMSI của SIM1, nếu không được thì lấy SIM2
4. Timer “services_freq”: Kiểm tra số ngày đợi theo tần suất gọi
- Định kỳ 3600 giây (1 giờ) chạy 1 lần
- Vào giờ “18” hàng ngày, tang biến g_irday (biến cho biết số ngày đã đợi, nếu đủ tần suất sẽ thực hiện gọi điện).
Mục đích của backdoor là gì?
Với cuộc gọi quốc tế có giá cước lên đến hàng chục nghìn 1 phút, bạn có thể sẽ bị hút máu một cách cực kỳ khủng khiếp và ai sẽ được lợi ở đây ???
Chắc hẳn các bạn đều đã từng nghe qua các dịch vụ giá trị gia tăng như: Kể chuyện đêm khuya, nghe nhạc theo yêu cầu, tổng đài nhắn tin dự đoán tỷ số bóng đá, tổng đài xố số, chơi gamek, lô đề… Khi bạn nhắn tin hoặc gọi điện đến các tổng đài này thì bạn sẽ bị trừ tiền tùy theo phí dịch vụ mà tổng đài quy định, nhiều đầu số chỉ cần nhắn tin 1 lần đăng ký và bị trừ tiền hàng tháng. Các đầu số trên backdoor cũng hoạt động theo nguyên tắc giống như vậy.
Với việc quản lý không đủ chặt về các nhà cung cấp dịch vụ nội dung di động (Content Service Provider — SP) như hiện nay, số lượng SP mọc lên như nấm sau mưa với đủ các thể loại dịch vụ. Và đương nhiên khi quản lý không chặt cùng các chế tài xử phạt không đủ sức răn đe thì sẽ xuất hiện rất nhiều tiêu cực, điển hình như gần đây nhất vụ SAM media chỉ bị phạt 55 triệu trong khi thu lời về 230 tỷ ??!!!
Tìm hiểu thêm 1 chút thì mình phát hiện ra thực tế dịch vụ này khá phổ biến tại Trung Quốc, có trang web và banner công khai luôn như ảnh bên dưới đây:
(1) Service Provider đăng ký dịch vụ VAS, báo với Skylin (Công ty cung cấp thiết bị có backdoor)
(2) Skylin build app vào các handset Trung Quốc, xuất bán cho các nhà cung cấp handset
(3) Handset được bán cho người dùng
(4) Người dung lắp SIM, nạp tiền, handset tự động đăng ký dịch vụ
(5) Telco thu tiền người dùng trả cho Service Provider, Service Provider share lợi nhuận với Skylin
Sau phát hiện này, chợt nhớ ra bà cụ ở nhà cũng đang dùng 1 em cục gạch, lại cũng hay kêu vừa nạp tiền được mấy hôm không gọi đi đâu mấy mà đã hết, chột dạ lôi ra kiểm tra thì cũng bị y như em iphone bên trên. Chỉ có khác là không chỉ có 1 loại mã độc mà còn có nhiều loại mã độc trên cùng 1 thiết bị. Các mã độc này đều có C&C riêng và nhận lệnh điều khiển gọi điện hoặc gửi tin nhắn khi có yêu cầu một cách độc lập.
Kết Luận:
Còn chờ gì nữa, hãy kiểm tra lại chính chiếc điện thoại của bạn nếu có thể, giặc ngay bên cạnh bạn đó.
Nguồn P2 P1
