Làm thế nào để hack một chiếc máy ảnh đắt tiền và không bị vợ giết chết. Cách hack Leica M8, M9 và M240
Tuyên bố miễn trừ trách nhiệm : Admin khuyến cáo tham khảo bài viết tuy nhiên không nên thực hiện theo dưới bất cứ hình thức nào.
Phần mềm Leica M8
Đó là tệp không được mã hóa, không nén (m8-2_005.upd) bắt đầu bằng phép thuật PWAD[1]. Có ai nhận ra nó không? Vâng, bạn đã hiểu đúng - định dạng Doom Patch WAD. Những người này có vẻ yêu thích những tác phẩm kinh điển. Định dạng được ghi chép rất kỹ lưỡng và viết công cụ tách là một nhiệm vụ khá đơn giản để thực hiện [2].
Nó thực sự rất buồn cười, bởi vì sau đó khi tôi đang xem xét phần mềm Leica T được nén, điều đầu tiên tôi làm là kiểm tra các phương pháp nén được sử dụng bởi id Software trong quá khứ. Wikipedia nói rằng họ đã sử dụng LHA[3] về cơ bản là LZW. Nhưng khi tôi thử một số máy giải nén LZW chung chung, nó không hoạt động, vì vậy tôi bắt đầu tìm kiếm một triển khai cụ thể của Phần mềm id và thì đấy, cái từ nguồn Catacomb Armageddon [4] đã đúng. Tôi phải thừa nhận đó là một sự trùng hợp may mắn.
Dù sao, quay lại với M8, đây là cấu trúc phần mềm
RULES: 0x0000008C ( 3036:0x00000BDC) - XML description
LUTS: 0x00000C68 ( 183274:0x0002CBEA)
GAMMA: 0x0000007C ( 31760:0x00007C10)
GAIN: 0x00007C8C ( 50344:0x0000C4A8)
LEICA: 0x00014134 ( 7000:0x00001B58)
BLEMISH: 0x00015C8C ( 250:0x000000FA)
WREF: 0x00015D88 ( 82480:0x00014230)
OBJ: 0x00029FB8 ( 11268:0x00002C04)
VERSION: 0x0002CBBC ( 46:0x0000002E)
PXA: 0x0002D854 ( 858384:0x000D1910)
BF: 0x000FF164 ( 134522:0x00020D7A) - Analog Devices Blackfin Processor family
GUI: 0x0011FEE0 ( 3574180:0x003689A4)
TRANS: 0x0000005C ( 59988:0x0000EA54) - localization
IMAGES: 0x0000EAB0 ( 267433:0x000414A9)
21_1PRT: 0x000000CC ( 18411:0x000047EB) - JFIF image
21_2GRP: 0x000048B8 ( 23172:0x00005A84) - JFIF image
21_3PAN: 0x0000A33C ( 23034:0x000059FA) - JFIF image
24_1PRT: 0x0000FD38 ( 18489:0x00004839) - JFIF image
24_2GRP: 0x00014574 ( 23230:0x00005ABE) - JFIF image
24_3PAN: 0x0001A034 ( 22998:0x000059D6) - JFIF image
28_1PRT: 0x0001FA0C ( 22605:0x0000584D) - JFIF image
28_2GRP: 0x0002525C ( 23081:0x00005A29) - JFIF image
28_3PAN: 0x0002AC88 ( 23282:0x00005AF2) - JFIF image
35_1PRT: 0x0003077C ( 22496:0x000057E0) - JFIF image
35_2GRP: 0x00035F5C ( 23532:0x00005BEC) - JFIF image
35_3PAN: 0x0003BB48 ( 22881:0x00005961) - JFIF image
FONT1: 0x0004FF5C ( 1522988:0x00173D2C)
FONT2: 0x001C3C88 ( 1723676:0x001A4D1C)
VERSION: 0x003689A4 ( 0:0x00000000)
M16C: 0x00488884 ( 130406:0x0001FD66) - Renesas M16C Family (Motorola S-record)
FPGA: 0x004A85EC ( 131604:0x00020214) - Xilinx Spartan 3
FSL: 0x004C8800 ( 814:0x0000032E) - First Stage Loader
IDA không hỗ trợ bộ xử lý Blackfin ra khỏi hộp, nhưng một plugin của bên thứ ba có[5].
Phần mềm Leica M9
Cái này (m9-1_196.upd) trông có vẻ được mã hóa (histogram cho thấy phân phối khoảng 0,45%).
Kết thúc câu chuyện? Có lẽ không, bởi vì Leica đã từng đặt CPU khá yếu trong máy ảnh của họ và mã hóa XOR rất phổ biến vào thời điểm đó trong các thiết bị điện tử tiêu dùng, vì vậy tôi quyết định viết một công cụ thao tác XOR đơn giản để so sánh phần sụn với chính nó và tính toán một số thống kê trên đường đi.
Độ dài khóa được xác định bằng cách tìm kiếm mẫu lặp lại dài nhất. Điều này có ý nghĩa vì bất kỳ phần mềm nào cũng thường bao gồm các khối dữ liệu lặp lại lớn như đệm 0x00/0xFF hoặc đồ họa với các điểm ảnh LUT. Bản thân khóa được tính toán dựa trên số liệu thống kê trên mỗi byte trong độ dài khóa trong đó byte xảy ra thường xuyên nhất đi đến bộ đệm khóa. Đầu ra rõ ràng chỉ ra mã hóa XOR. Sau đó, vấn đề là sửa đổi công cụ của tôi một chút để có được một khóa tiềm năng và giải mã [6]. Một lần nữa, đó là tệp PWAD sau khi giải mã.
Nội dung PWAD tiết lộ cấu trúc sau:
RULES: 0x0000007C ( 2788:0x00000AE4) - XML description
LUTS: 0x00000B60 ( 4060616:0x003DF5C8)
PROCESS: 0x0000004C ( 3900572:0x003B849C)
CREATE: 0x0000004C ( 20:0x00000014) - timestamp
LUTS: 0x00000060 ( 427744:0x000686E0)
GAINMAP: 0x00068740 ( 20008:0x00004E28)
LENS: 0x0006D568 ( 3452724:0x0034AF34)
CCD: 0x003B84E8 ( 148662:0x000244B6)
CREATE: 0x0000004C ( 20:0x00000014) - timestamp
BLEMISH: 0x00000060 ( 1092:0x00000444)
WREF: 0x000004A4 ( 147452:0x00023FFC)
LIN: 0x000244A0 ( 22:0x00000016)
ICCPROF: 0x003DC9A0 ( 4304:0x000010D0)
ECI-RGB: 0x0000003C ( 540:0x0000021C)
sRGB: 0x00000258 ( 3144:0x00000C48)
A-RGB: 0x00000EA0 ( 560:0x00000230)
WBPARAM: 0x003DDA70 ( 7000:0x00001B58)
BF561: 0x003E0128 ( 289128:0x00046968) - Analog Devices Blackfin Processor family
bf0: 0x0000004C ( 117846:0x0001CC56) - main processor firmware
bf1: 0x0001CCA4 ( 117826:0x0001CC42) - sub-processor firmware
bf0.map: 0x000398E8 ( 27072:0x000069C0) - main processor firmware map with symbols :D
bf1.map: 0x000402A8 ( 26304:0x000066C0) - sub-processor firmware map with symbols :D
BODY: 0x00426A90 ( 143280:0x00022FB0) - Renesas M16C Family (Motorola S-record)
GUI: 0x00449A40 ( 3647624:0x0037A888)
TRANS: 0x0000005C ( 131656:0x00020248) - localization
IMAGES: 0x000202A4 ( 267433:0x000414A9)
21_1PRT: 0x000000CC ( 18411:0x000047EB) - JFIF image
21_2GRP: 0x000048B8 ( 23172:0x00005A84) - JFIF image
21_3PAN: 0x0000A33C ( 23034:0x000059FA) - JFIF image
24_1PRT: 0x0000FD38 ( 18489:0x00004839) - JFIF image
24_2GRP: 0x00014574 ( 23230:0x00005ABE) - JFIF image
24_3PAN: 0x0001A034 ( 22998:0x000059D6) - JFIF image
28_1PRT: 0x0001FA0C ( 22605:0x0000584D) - JFIF image
28_2GRP: 0x0002525C ( 23081:0x00005A29) - JFIF image
28_3PAN: 0x0002AC88 ( 23282:0x00005AF2) - JFIF image
35_1PRT: 0x0003077C ( 22496:0x000057E0) - JFIF image
35_2GRP: 0x00035F5C ( 23532:0x00005BEC) - JFIF image
35_3PAN: 0x0003BB48 ( 22881:0x00005961) - JFIF image
FONT1: 0x00061750 ( 1522988:0x00173D2C)
USBLOGO: 0x001D547C ( 1775:0x000006EF) - JFIF image
FONT2: 0x001D5B6C ( 1723676:0x001A4D1C)
FPGA: 0x007C42C8 ( 150176:0x00024AA0) - Xilinx Spartan 3A
BF547: 0x007E8D68 ( 937576:0x000E4E68) - Analog Devices Blackfin Processor family (FSL?)
Phần mềm Leica M240
Việc kiểm tra trang tải xuống chương trình cơ sở Leica mỗi sáng đã trở thành thói quen. Cuối cùng một tệp mới đã có sẵn -FW_M240_1_1_0_2. FW.
Nó trông không được mã hóa, nhưng nó trông có vẻ được nén...
Nén
Biểu đồ có một mức tăng đột biến lớn trên 0x9D.
Có lẽ đây là một loại phép thuật nén nào đó. Tìm kiếm trên Google cho "9D" và "nén" không giúp ích gì ngoài thực tế là 0x1F9D được sử dụng làm chữ ký nén LZW[7]. Để đề phòng, tôi đã quen thuộc với các loại nén LZ và quyết định tìm kiếm tất cả các byte sau 0x9D. Tôi đã tìm thấy bốn mẫu khác nhau:
9D 70 C49D 009D XX YY9D XX 8Y YY
Những quan sát của tôi về các loại mẫu này là:
- (1) xuất hiện một lần tại địa chỉ 0x30, có thể được sử dụng làm chỉ báo dữ liệu nén
- XX không bao giờ lớn hơn 0x7F
- byte cuối cùng YY trong (3) và (4) không bao giờ lớn hơn 0x7F
Từ những gì tôi biết về LZ, nó trông rất giống LZ77 hoặc LZSS nếu YY là khoảng cách lùi bước và XX là số byte để sao chép. Và (2) là một trường hợp đặc biệt để xuất ra 0x9D. Viết một hàm C đơn giản thực hiện logic này đã xác nhận rằng nó đang đi đúng hướng, nhưng vẫn chưa hoàn toàn ở đó vì (4).
Tôi đã dành một thời gian để thử các cách khác nhau để diễn giải nó, nhưng không có gì hiệu quả. Vì vậy, tôi chỉ hỏi một số người khác họ nghĩ gì và một người nhận thấy rằng theo quan sát của riêng tôi, byte thứ tư YY chỉ xuất hiện khi bit cao nhất của 0x8Y được đặt thêm độ dài thêm vào khoảng cách lùi lại. Thật xấu hổ cho tôi, điều đó quá rõ ràng. Cuối cùng, bộ giải nén bắt đầu xuất ra một luồng hợp lệ... cho đến khi nó bị kẹt ở đâu đó ở giữa tệp chương trình cơ sở. Điều này là do chiều dài không xác định của một cửa sổ trượt. Gỡ lỗi bổ sung và thử nghiệm đã sửa nó.
Sau đó, đã đến lúc một công cụ mới hoạt động với các tệp chương trình cơ sở M240[8].
Cấu trúc phần mềm
Để xử lý một định dạng tệp không xác định, tôi không thể nghĩ ra bất cứ điều gì tốt hơn là đo một số độ lệch và kích thước trong tệp và cố gắng tìm các giá trị gần nhất trong tiêu đề tệp. Ví dụ như khối này:
0x00: 1E 1C AF 2E 01 01 00 02 07 E1 EA 5E 00 5C 1A B1
0x10: 01 29 1A 7E AE 38 73 65 9C 3D 75 B4 34 2F 44 6E
0x20: 13 17 8E 6B 00 00 00 01 00 00 00 30 E1 E3 50 D1
cuối cùng biến thành:
1E1CAF2E - looks like "LEICA FILE"
01010002 - 1.1.0.2
005C1AB1 - compressed file size (big endian)
01291A7E - uncompressed file size (big endian)
AE3873659C3D75B4342F446E13178E6B - MD5 hash
00000001 - number of payloads
00000030 - first payload offset
Công cụ này đã phát triển cùng với sự hiểu biết tốt hơn về cấu trúc phần mềm và cuối cùng đầu ra trông như thế này:
Running with options:
+ firmware folder: M240_FIRMWARE
+ verbose enabled
Open firmware file: FW_M240_1_1_0_2.FW
File size: 6036193 | 0x005C1AE1
Parse container header:
version: 1.1.0.2
packed size: 6036145 | 0x005C1AB1
unpacked size: 19470974 | 0x01291A7E
body blocks: 1 | 0x00000001
body offset: 48 | 0x00000030
MD5: AE387365 9C3D75B4 342F446E 13178E6B
MD5 check: PASSED
Uncompress container body: ◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼◼
6036145 -> 19470974
Uncompression: DONE
Split container:
Number of sections: 9 | 0x00000009
Section table size: 612 | 0x00000264
Section table offset: 36 | 0x00000024
Section 1
Section Name: "[A]IMG_LOKI-212"
Section offset: 0 | 0x00000000
Section size: 7340032 | 0x00700000
Section base: 1048576 | 0x00100000
MD5: A8D55AA2 B0ACDB14 0673AD79 707674F3
MD5 check: PASSED
Create file: M240_FIRMWARE/IMG_LOKI-212.bin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Section 9
Section Name: "[A]IMG-LENSDATA-213"
Section offset: 19214844 | 0x012531FC
Section size: 255478 | 0x0003E5F6
Section base: 16252928 | 0x00F80000
MD5: 39C2BEC0 27ED23F6 2C1C8513 EEE697B9
MD5 check: PASSED
Create file: M240_FIRMWARE/IMG-LENSDATA-213.bin
Splitting container: DONE
Extraction COMPLETE!
Phần mềm M240 bao gồm một thùng chứa với 9 mục:
IMG_LOKI-212.bin - Application Processor Firmware
IMG_LOKI-213.bin - Application Processor Firmware
CTRL_SYS-11.bin - IO Processor Firmware
IMG-FPGA-212.bin - Image Processing (Sensor) Firmware
IMG-FPGA-213.bin - Image Processing (Sensor) Firmware
IMG-DSP-212.bin - DSP Firmware
IMG-DSP-213.bin - DSP Firmware
IMG-LENSDATA-212.bin - Lens Data
IMG-LENSDATA-213.bin - Lens Data
Như bạn đã nhận thấy có hai bộ tệp trong một chương trình cơ sở. Sau đó tôi phát hiện ra rằng 212 là phiên bản Image Board có nghĩa là có hai loại Leica M240 khác nhau trong tự nhiên. Nghiên cứu hiện tại dựa trên 212 nghiên cứu.
Kiểm soát hệ thống - CTRL_SYS-11.bin
Phần phổ biến duy nhất là phần mềm cho một số chip điều khiển hệ thống. Nhị phân này thực sự có rất nhiều chuỗi và nhìn qua chúng, không khó để có được ý tưởng về phần này dùng để làm gì.
$ strings CTRL_SYS-11.bin | rg SH
-> Test SH7216 data flash driver
-> Test SH7216 SCI driver
-> Test SH7216 I2C driver
-> Test SH7216 MTU2 driver
-> Test SH7216 ADC functions
-> Test SH7216 CMT driver
Vì vậy, đây là Renesas SH7216 (SH-2A) và nó chịu trách nhiệm cho giai đoạn khởi động sớm, kiểm tra IO và cập nhật chương trình cơ sở. IDA hỗ trợ loại bộ xử lý này ngay lập tức, vì vậy vấn đề là tìm cơ sở hình ảnh chính xác đã được biết từ phần mô tả phần mềm - 0x0:
Section Name: "[A]CTRL_SYS-11"
Section offset: 14680064 | 0x00E00000
Section size: 917277 | 0x000DFF1D
Section base: 0 | 0x00000000
Rõ ràng tôi đã đưa nó vào IDA và nhận ra tất cả các chức năng, nhưng không thực sự đào sâu vào nó nhiều vì tôi tò mò hơn rất nhiều về phần sụn bộ xử lý chính.
Một điều khác cần lưu ý ở đây là UART từ chip này được hiển thị trên cổng dịch vụ nơi nó in nhật ký khởi động. Chúng ta sẽ quay lại với điều đó sau.
Chip chính - IMG_LOKI-212.bin
Để bắt đầu thiết kế ngược phần mềm này, trước tiên cần phải trả lời một số câu hỏi:
- loại bộ xử lý là gì
- cơ sở hình ảnh là gì
- nó dựa trên hệ điều hành nào nếu có
Chúng tôi đã biết cơ sở hình ảnh từ M240FwTool, nó là0x100000
Section Name: "[A]IMG_LOKI-212"
Section offset: 0 | 0x00000000
Section size: 7340032 | 0x00700000
Section base: 1048576 | 0x00100000
Câu trả lời cho các câu hỏi còn lại được lưu trữ bên trong phần mềm ở dạng có thể đọc được của con người. Ví dụ chuỗi này:
$ strings ./IMG_LOKI-212.bin | rg Softune
6Softune REALOS/FR is Realtime OS for FR Family, based on micro-ITRON COPYRIGHT(C) FUJITSU LIMITED 1994-1999
...
Vì vậy, chúng tôi đang xử lý Fujitsu FR tùy chỉnh (Leica gọi nó là Maestro) và Softune REALOS. Trên thực tế, nó hứa hẹn hơn rất nhiều so với Blackfin vì IDA cung cấp hỗ trợ FR sẵn có.
Mô-đun xử lý IDA FR
Tuy nhiên, thực tế không sáng sủa như vậy, bởi vì khi tôi đặt tệp chương trình cơ sở vào IDA và chọn bộ xử lý FR, tôi phát hiện ra rằng mô-đun này hầu như không thể sử dụng được do thiếu hướng dẫn, không có xrefs, v.v.
Tôi đã quyết định sửa nó nhưng cuối cùng đã viết lại một số phần hoàn toàn[9]. Đây là kết quả:
Apart from fixes in ana, ins and out stages, brand new emu code was able to
- nhận ra các loại mã và xrefs dữ liệu khác nhau
- nhận biết các câu lệnh chuyển đổi
- thực hiện theo dõi ngăn xếp
- phân chia các đối số ngăn xếp và các biến cục bộ (nhờ làm sạch FR ABI)
- nhận biết các chức năng đúng cách
Nhưng sự thay đổi lớn nhất mà bạn nhận thấy là chữ in hoa cho các hướng dẫn :)
Bạn có muốn xem bộ hướng dẫn đầy đủ không?
Đây rồi:
ADD OR BTSTH LSR MOV BN LDRES EXTSH
ADD2 ORH MUL LSR2 JMP BP STRES EXTUH
ADDC ORB MULU ASR CALL BV COPOP SRCH0
ADDN EOR MULH ASR2 RET BNV COPLD SRCH1
ADDN2 EORH MULUH LDI INT BLT COPST SRCHC
SUB EORB DIV0S LDI INTE BGE COPSV LDM0
SUBC BANDL DIV0U LDI RETI BLE NOP LDM1
SUBN BANDH DIV1 LD BRA BGT ANDCCR STM0
CMP BORL DIV2 LDUH BNO BLS ORCCR STM1
CMP2 BORH DIV3 LDUB BEQ BHI STILM ENTER
AND BEORL DIV4S ST BNE DMOV ADDSP LEAVE
ANDH BEORH LSL STH BC DMOVH EXTSB XCHB
ANDB BTSTL LSL2 STB BNC DMOVB EXTUB
Đó là nó, đẹp và đơn giản.
Nhân tiện, bạn có thể nhận thấy rằng một số hướng dẫn không được căn chỉnh:
BRA:D loc_xxx
LDI:8 #0x64, R5
Nó không phải là một lỗi trong mô-đun bộ xử lý, mà thực sự là một tính năng của dòng Fujitsu FR. Nó được gọi là "Delay Slot"[10] và khá điển hình cho các bộ xử lý RISC.
Từ hướng dẫn sử dụng phần cứng FR80[11]:
The instruction that is located immediately following a branch instruction (the location is called a
"delay slot") is executed before branching, and an instruction at the branch destination is executed
after that. Because the instruction in the delay slot is executed before the branch operation, the
apparent execution speed is 1 cycle.
Vì vậy, về cơ bản đây là một tối ưu hóa đường ống và tốt hơn là nên ghi nhớ điều đó vì nó được sử dụng ở mọi nơi trong phần mềm Leica.
Phần mềm REALOS
Từ wiki[12]:
Softune is an Integrated development environment from Fujitsu for the Fujitsu FR, FR-V and F²MC
processor families. It provides an REALOS µITRON realtime kernel.
It is for example used for Nikon DSLRs (see Nikon EXPEED) and some Pentax K mount cameras.
Vì vậy, nó là một RTOS khá phổ biến với các tác vụ, semaphores và các tính năng khác và tôi đã tự hỏi liệu có thể nhận ra một số chức năng thư viện tiêu chuẩn trong phần mềm Leica hay không.
TÁN TỈNH
Lẽ ra tôi nên gọi phần này là "một bài thơ ca ngợi lãng phí thời gian" và đây là lý do tại sao.
Thật khó để tìm thấy Softune IDE trong tự nhiên nhưng cuối cùng tôi đã tìm được thứ gì đó để chơi. Như mong đợi, IDE bao gồm các thư viện. Có bốn nhị phân:
- lib911.lib
- lib911e.lib
- lib911nếu.lib
- lib911p.lib
Tôi không biết tại sao, nhưng có lẽ do quán tính, vì tôi đã rất thích hack mọi thứ liên quan đến Leica nhưng tôi đã thực sự bắt đầu đảo ngược định dạng đối tượng. Vâng, Định dạng Mô-đun Đối tượng được ghi chép rất tốt[13]. Và vâng tất nhiên tôi đã viết một công cụ để đối phó với nó[14]:
Fujitsu RISC Library Tool v1.0
Usage: FRLibTool [-s start] [-i imagebase] [-o output] [-f index] [-dv] FIRMWARE.BIN LIBRARY.LIB
This tool will help you to find Softune REALOS library functions in FR (Fujitsu RISC) firmware.
Use following arguments:
-f Specify firmware image file
-s Specify firmware image scan offset
-b Specify firmware imagebase
-o Specify output type (exclusively)
list - list of functions
idc - IDC script
py - IDA python script
pat - FLAIR pattern file
-i xxx Specify index of particular function
-d Dump library
-v Be verbose
Using this tool it was possible to create *.pat files and use them as input for the IDA FLAIR tool to generate signature files[15].
$ FRLibTool -o pat lib911.lib
$ FRLibTool -o pat lib911e.lib
$ FRLibTool -o pat lib911if.lib
$ FRLibTool -o pat lib911p.lib
...
$ sigmake -n "SOFTUNE C/C++ Library" lib911.pat lib911e.pat lib911if.pat lib911p.pat softune.sig
Cuối cùng, sau khi áp dụng chữ ký này, tôi rất vui khi thấy các trận đấu trong IMG_LOKI-212.idb .
Bố cục
Điều đầu tiên tôi nhận thấy là số lượng chuỗi trong phần mềm. Nhiều chức năng có tên của chúng trong cơ thể hoặc ít nhất là một số dấu hiệu cho thấy hành vi của chúng. Điều này cực kỳ hữu ích trong quá trình kỹ thuật đảo ngược để hiểu bố cục.
Điều quan trọng cần lưu ý ở đây là một số phần của tệp vi chương trình được sao chép đến các địa chỉ khác nhau trong trình xử lý đặt lại. Ví dụ: có một bộ nạp khởi động được nhúng trong mã được di chuyển đến RAM cao hơn trong thời gian chạy.
Tôi đã phải tạo các phần bổ sung theo cách thủ công và cuối cùng đã đến bố cục sau.
Làm gián đoạn
Một bảng vectơ ngắt có thể được tìm thấy bằng cách truy cập TBR (Table Base Register):
LDI:32 #int_table, R0
MOV R0, TBR
Điều này thường xảy ra trong trình xử lý vector đặt lại ngay ở đầu phần sụn.
Handler addresses in the table are stored in reverse order according to formula TBR + (0x3FC - 4 × inum), so that reset vector is located at the end of the table at offset 0x3FC.
Tôi đã tìm thấy hầu hết các ngắt này được xác định trong Hướng dẫn sử dụng phần cứng FR[11] và chỉ cho rằng bộ xử lý Maestro của Leica có bố cục tương tự.
Sau đó nhìn vào mọi trình xử lý và tôi đã cố gắng tìm một chuỗi hoặc bất kỳ gợi ý nào khác tiết lộ mục đích ngắt.
Đây là những gì tôi đã kết thúc với:
Nhiều trong số này như AUDIO/SDIO/VIDEO/JPEG/RAW đã được mong đợi, nhưng bạn có thể phát hiện ra cái hấp dẫn nhất không?
Tôi đang nói về int_uart_in, có nghĩa là máy ảnh có thể có một số loại UART CLI.
Hệ thống
Giống như hầu hết các hệ điều hành khác, SOFTUNE REALOS được thiết kế để sử dụng các cuộc gọi hệ thống cho IPC và các hoạt động khác.
Trong cuộc gọi hệ thống lắp ráp trông như thế này:
Địa chỉ thực tế của người xử lý cuộc gọi hệ thống được tính theo cách sau.
Hãy bắt đầu với việc tìm trình xử lý ngắt INT #0x40. Theo phần trước đây thì đây là
(0x3FC - 4 × inum) = (0x3FC - 4 × 0x40) = 0x2FC = int_realos_syscall
Nhìn qua trình xử lý, thật dễ dàng để tìm thấy tham chiếu đến cuối bảng syscall. Nó chứa các từ 16 bit.
Mục nhập cụ thể trong bảng này được tính bằng cách sử dụng công thức sau syscall_table_bottom + (num * 2):
[syscall_table_bottom + (-23 * 2)] = [syscall_table_bottom - 0x2E] = [0x1012EA] = 0xE68
As you can see this doesn’t looks like address, because the actual system call handler address is calculated as syscall_table_bottom + offset.
Sơ đồ sau đây cho thấy toàn bộ quá trình.
Tất cả các cuộc gọi hệ thống và phép thuật của chúng đều được liệt kê trong SOFTUNE REALOS/FR KERNEL MANUAL[16], do đó có thể khôi phục tất cả các trình xử lý được triển khai trong bảng và cải thiện IDB hơn nữa.
Và tất nhiên, có thể làm cho mã thậm chí còn đẹp hơn khi xác định các loại syscall trong IDA.
Tôi thực sự đã viết một tập lệnh PIDA python để tự động tìm ra điều đó và một số thứ khác[17]
Nhiệm vụ
Looking at sta_tsk syscall I noticed that there is no main task function passed as parameter, instead code is passing pid. This means it was a time to look for big array of task descriptors. And it makes sense to start from sta_tsk itself.
ROM:102180 sys_sta_tsk:
ROM:102180 ST RP, @-R15
ROM:102182 LDUB @(R14, 0x4F), R3
ROM:102184 LDI:32 #word_100B80, R14
Ngay từ đầu, chúng tôi thấy một số tài liệu tham khảo. Tôi đã phải chơi một chút với các loại dữ liệu, nhưng cuối cùng các mảnh ghép lại với nhau thành cái này:
ROM:100B80 word_100B80: .word 0xF ; number of tasks
ROM:100B82 .word 0x1C ; task descriptor size
ROM:100B84 .long 0x82A09F5C ; task 1 descriptor
ROM:100B88 .long 0x1000D
ROM:100B8C .long 0
ROM:100B90 .long 0x40000000
ROM:100B94 .long sub_1A7DB2 ; task main
ROM:100B98 .long 0x8286EEC0
ROM:100B9C .long 0
ROM:100BA0 .long 0x82A09F88 ; task 2 descriptor
ROM:100BA4 .long 0x20010
ROM:100BA8 .long 0
ROM:100BAC .long 0x40000000
ROM:100BB0 .long sub_1A6BD2 ; task main
ROM:100BB4 .long 0x8287EEC0
ROM:100BB8 .long 0
...
và v.v. Tổng cộng 15 nhiệm vụ. Chỉ là vấn đề thời gian để xem xét từng chức năng chính và tìm ra tên và mục đích của nhiệm vụ (ngoài chức năng cuối cùng). Đây là danh sách đầy đủ:
- CPU phụ
Nhiệm vụ này dường như chịu trách nhiệm cho các hoạt động chụp ảnh như phơi sáng, điều khiển chế độ xem trực tiếp, v.v. - Quản lý khóa
Rất có thể tác vụ này đang xử lý các nút phần cứng. - Quản lý Gui
Nhiệm vụ khá lớn khi triển khai máy trạng thái giao diện người dùng và bản vẽ giao diện. - Trình quản lý gỡ lỗi
Vâng, có một cái gì đó để gỡ lỗi. Ngon ngon. - Trình quản lý tập tin
Nhiệm vụ này là tất cả về các thao tác tệp. - Quản lý gia đình
Tôi sẽ nói rằng cái này chịu trách nhiệm về bộ nhớ tệp vì nó phụ thuộc vào các tác vụ của Trình quản lý tệp và Trình quản lý bộ nhớ - Trình quản lý bộ nhớ
Không có gì ngạc nhiên ở đây, hoạt động bộ nhớ, điều khiển nhóm, v.v. - Trình quản lý hình ảnh
Nhiệm vụ này là kiểm soát mã hóa/giải mã và các quy trình làm việc hình ảnh khác - Quản lý USB
Nhiệm vụ hiện tại là xử lý giao tiếp qua USB bao gồm MassStorage, PTP và một số giao thức Leica Custom. - Người quản lý IO
Có vẻ như nhiệm vụ này là quản lý các thiết bị lưu trữ như thẻ SD và CF (cái gì? CF à? có lẽ đó là tất cả những gì bảng 213 nói về). - Quản lý hệ thống
Nhiều thứ khác nhau như hoạt động chung của hệ thống, điều khiển năng lượng, v.v. - Trình quản lý cài đặt
Nhiệm vụ này là xử lý các thay đổi về trạng thái và cài đặt của máy ảnh. - Giám sát quản lý
Mục đích của nhiệm vụ này là để theo dõi những thay đổi trong trạng thái máy ảnh và thông báo cho các tác vụ khác. - Quản lý ngoại vi
GPS, độ sáng và một số cảm biến khác được điều khiển bởi tác vụ này. - Không rõ
Thật không may, tôi không tìm thấy bất cứ điều gì liên quan về cái này
Thật thú vị khi lưu ý ở đây rằng có một mô tả tác vụ nổi bật hơn sau mảng chính.
ROM:100D28 dword_100D28: .long 0x82A0A1F0
ROM:100D2C .long 0x21
ROM:100D30 .long 0
ROM:100D34 .long 0x80000000
ROM:100D38 .long tid16_task
ROM:100D3C .long 0x8285EEC0
ROM:100D40 .long 0
Và chức năng nhiệm vụ chỉ là một nhánh của chính nó.
ROM:101494 sub_101494:
ROM:101494 BRA sub_101494 ; CODE XREF: sub_101494
This descriptor is referenced at the end of start function which is responsible for spawning other tasks and firmware setup. So it is most likely an idle task.
Mô-đun và Tin nhắn
Ngoài các tác vụ, cũng có thể xác định một số đối tượng logic như IO và các mô-đun ngoại vi. Các mô-đun được thể hiện dưới dạng nhóm trình xử lý tin nhắn trong một trong các tác vụ.
Nhóm IO dường như bao gồm:
- Quản lý IO
- CPU phụ
- Trình quản lý USB
- Cổng USB PTP
- USB Leica tùy chỉnh
- Bộ lưu trữ dung lượng lớn USB
- Quản lý chính
- Trình quản lý gỡ lỗi
- Trình quản lý ống kính
trong khi nhóm ngoại vi có:
- Quản lý ngoại vi
- Cảm biến độ sáng
- Đèn LED
- Tiếng bíp
- Cảm biến độ nghiêng
- Phát hiện bìa
- Mô-đun GPS
- Mô-đun 3DAxis
Bản thân hệ thống nhắn tin dường như sử dụng các cấu trúc SOFTUNE tiêu chuẩn:
struct RealOS_MsgPayload
{
uint32_t msgID; // +0x0
uint32_t data[]; // +0x4
}
struct RealOS_Message
{
uint32_t os_reserved1; // +0x0
uint32_t os_reserved2; // +0x4
uint32_t to; // +0x8
uint32_t from; // +0xC
RealOS_MsgPayload* payload; // +0x10
}
Như mong đợi, IPC cũng được thiết kế để có một số nhóm tin nhắn. Xem xét rằng có rất nhiều tin nhắn được xử lý trong các tác vụ và mô-đun, tôi chỉ có thể khôi phục một số nhóm này khi duyệt qua phần mềm:
0x1101xxxx - global system messages like
0x11010002 = SYS_UPDATE_BOOTLOADER or
0x11010005 = SYS_ERASE_SETTINGS
0x1102xxxx - messages related to image capture for example
0x11020001 = CMD_CAP_CAPTURE or
0x11020008 = IMAGE_STATUS_CHANGED
0x1104xxxx - playback related messages cover events like
0x11040002 = PLY_DISABLE_PLAY_MODE or
0x11040004 = PLY_IMAGE_READY
0x1108xxxx - various messages for PTP debugging e.g.
0x11080002 = DBG_CHANGE_LEVEL or
0x11080012 = DBG_WRITE_ROM_DUMP_SD
0x2201xxxx - USB PTP messages like
0x22010108 = Camera Settings Change or
0x22010118 = Request DebugObject
0x2202xxxx - pretty big group of SUBCPU messages including for example
0x22020002 = E_SUBCPU_REQUEST_M_EXPOSURE_REQUEST
0x22020015 = E_IO_SUBCPU_COMMAND_CLEANING_SENSOR
0x2203xxxx - some other debugging message
0x22030001 = Debug String Command
0x2204xxxx - various IO messages like
0x2204000C = Enable/Disable Mass Storage or
0x22040012 = Reset device
0x330000xx - another big group related to UI, for instance
0x33000001 = Key pressed
0x33000007 = Lens connected
0x440000xx - not many info about this one, but looks like image processing group
0x44000013 = E_IMG_CMD_CHANGE_PINFO
0x55xxxxxx - group of FAM message groups:
0x558800xx = FAM file manager group or
0x558888xx = FAM menu settings 1 group
0x6602xxxx - seems to be some LED control messages e.g.
0x66020001 - Toggle LED with X Hz
0x66020002 = Enable Continuous LED
0x6604xxxx - beeper control messages including
0x66040001 = Beeper set or
0x66040007 = Card full noise
0x6611xxxx - memory related debug messages
0x6622xxxx - memory related image processing messages
0x6660xxxx - some other memory related messages like
0x66600006 = memory HISTOGRAM
0x66600011 = memory RAWCOMP
0x771100xx and 0x77AA00xx - camera mode switch related messages
Thật không may, nhiều người khác vẫn chưa được biết đến.
Giao diện người dùng
Chúng ta hãy xem lại các phần của tệp chương trình cơ sở: CTRL_SYS-11, IMG-LOKI-212, IMG-DSP-212, IMG-FPGA-212 và IMG-LENSDATA-212.
Điều làm tôi ngạc nhiên một chút là không có bất kỳ tài sản GUI nào. Nhưng nó phải ở đâu đó và rất có thể nó được nhúng vào IMG-LOKI-212.
Một trong những cách tiếp cận thông thường của tôi đối với kỹ thuật đảo ngược phần mềm là khôi phục tất cả các tham chiếu chéo có thể. Không chỉ từ mã, mà còn trong phần dữ liệu. Sau đó, tôi duyệt qua chúng để cố gắng tìm một số mẫu hoặc liên kết đến các phần đã biết của mã.
Phần mềm Leica không phải là một ngoại lệ. Có rất nhiều chuỗi dữ liệu trông giống nhau với địa chỉ đến chuỗi dữ liệu với địa chỉ đến chuỗi dữ liệu, v.v. Leo lên qua hệ thống phân cấp tham chiếu này, cuối cùng tôi đã xuất hiện tại một chức năng mà tôi nhận ra.
Ví dụ, tôi đã tìm thấy cấu trúc dữ liệu mà không có bất kỳ tài liệu tham khảo nào
g_data = { ... }
Nó được tham chiếu từ cấu trúc khác
g_data_struct1 = { ... , &g_data }
Mà lần lượt được tham chiếu từ một cấu trúc khác
g_data_struct2 = { &g_data, ... }
Cấu trúc dữ liệu này được tham chiếu từ mã và được truyền dưới dạng tham số cho một hàm khác
func1()
╰ func2(..., &g_data_struct2, ...)
However, func1() was not called directly from another function, instead if was stored in some array
g_func_list1[] = { ..., func1(), ... }
Looking above I found a reference to g_func_list1 from code
func3() {
g_func_list1[x]
}
Và một lần nữa, chức năng này được lưu trữ trong mảng
g_func_list2[] = { ..., func3(), ... }
Bản thân mảng được tham chiếu từ một số mã khác
func4() {
g_func_list2[x]
}
May mắn thay, chức năng lần này được gọi từ một chức năng khác và cứ thế cho đến khigui_MADE_ApplicationRun
gui_Statemachine_DoStateChange()
╰ gui_MADE_ApplicationRun()
╰ func5()
╰ func4()
According to some strings, GUI subsystem is called “MADE” and page transitions are handled using MADE_GetSysTri whatever it means. GUI state machine is mostly implemented in gui_Statemachine_DoStateChange function. Later getting more and more information about GUI overall picture started to look like that
As you can see the core function dealing with GUI assets is gui_CopyImageDesc (it is not a real name though). It has following arguments:
gui_CopyImageDesc(
uint32_t dstAddress; // R4 - destination address
UIDescType type; // R5 - description type
UITarget target; // R6 - rendering target
uint32_t descAddress; // R7 - description address
uint8_t always0; // (SP + 0x0) - always 0
uint8_t index1; // (SP + 0x4) - index 1
uint8_t index2; // (SP + 0x8) - index 2
uint16_t x_offset; // (SP + 0xC) - x offset
uint16_t y_offset; // (SP + 0x10) - y offset
uint16_t unknown2; // (SP + 0x14) -
uint32_t language1; // (SP + 0x18) - language id 1
uint32_t language2; // (SP + 0x1C) - language id 2
uint32_t funcAddress; // (SP + 0x20) - function address
)
Có bốn loại mô tả tài sản:
struct UIDescType0Header struct UIDescType1Header struct UIDescType2 struct UIDescType3
{ { { {
uint32_t address; uint32_t address; uint32_t reg; uint16_t x_offset;
uint16_t entries; uint16_t entries; uint32_t address; uint16_t y_offset;
uint16_t unknown; uint16_t unknown; uint16_t unknown1; uint32_t address;
} } uint16_t unknown2; }
uint16_t unknown3;
struct UIDescType0Entry struct UIDescType1Entry uint16_t tableoff;
{ { }
uint16_t x_offset; uint16_t x_offset;
uint16_t y_offset; uint16_t y_offset;
uint32_t address; uint32_t address;
} uint16_t objects;
uint16_t total_w;
uint16_t total_h;
uint16_t unknown;
}
Loại đầu tiên có tiêu đề với tham chiếu đến mảng các mục nhập. Mỗi mục nhập đều có tọa độ và địa chỉ dữ liệu pixel. Loại hiện tại dường như đang mô tả các yếu tố phụ thuộc vào trạng thái, chẳng hạn như các biểu tượng có thể chuyển sang màu xám hoặc biến mất khỏi giao diện người dùng.
Loại thứ hai cũng bắt đầu bằng tiêu đề và được sử dụng để bản địa hóa, mô tả các chuỗi hoặc khối văn bản.
Loại thứ ba mô tả bản đồ ký tự cho các ngôn ngữ khác nhau.
Loại cuối cùng chịu trách nhiệm cho tất cả các tài sản tĩnh khác, như hình ảnh, hình nền, v.v.
Bây giờ chúng ta hãy xem xét chính dữ liệu hình ảnh.
+0x00: 00 08 00 14 00 01 A2 FF 0A 04 05 FF 0C 04 03 FF
+0x10: 0D 04 03 FF 0E 04 02 FF 0E 04 02 FF 04 04 06 FF
+0x20: 04 04 02 FF 04 04 06 FF 04 04 02 FF 04 04 06 FF
+0x30: 04 04 02 FF 04 04 06 FF 04 04 02 FF 04 04 06 FF
+0x40: 04 04 02 FF 04 04 06 FF 04 04 02 FF 04 04 06 FF
+0x50: 04 04 02 FF 04 04 06 FF 04 04 02 FF 0E 04 02 FF
+0x60: 0E 04 02 FF 0D 04 03 FF 0D 04 03 FF 0C 04 04 FF
+0x70: 04 04 0C FF 04 04 0C FF 04 04 0C FF 04 04 0C FF
+0x80: 04 04 0C FF 04 04 0C FF 04 04 0C FF 04 04 0C FF
+0x90: 04 04 0D FF 02 04 2D FF 00 06 00 14 00 01 79 FF
First 6 bytes look like a little header followed by some repeating pattern where every second byte is either 0xFF or 0x04. Obvious guess for the 0x0008 and 0x0014 would be width and height in big endian. At the end of this dump we see a beginning of another sequence 00 06 00 14 00 01 which is most likely next image asset (this was also confirmed by reference to it). So the size of actual image data is 146 bytes. But the size of an image should be 0x8 * 0x14 = 0xA0 = 160. Clearly image data is not pure pixels and not even 8-bit LUT because it is 14 bytes smaller. Then what? There must be some kind of compression involved.
Looking at this hex dump it is hard to believe that they used something sophisticated. Also, Leica GUI is not very colourful or full of gradients and from my experience LUT is the best approach here. In this case UI assets will be full of repeating LUT indices like 03 03 03 or A1 A1 A1. Usually compressor it trying to get rid of repeating information replacing it with reference. These arrays of indices are perfect data to compress even with simple method like RLE [data][number]. In other words, write datato the output number of times.
Keeping all that in mind I assumed that this is most likely a simple image with two LUT colours (0xFF and 0x04) and the byte before colour is number of pixels to draw.
"Và sau đó bạn đã viết một công cụ khác" bạn có thể nghĩ. Không, tôi lấy bút và giấy và bắt đầu điền vào các ô vuông. Thật buồn cười là tôi vẫn giữ bản vẽ gốc này.
Ở đâu đó trên đường đi, tôi nhận ra rằng 160 pixel không đủ để phù hợp với hình ảnh này, thay vào đó 0x8 và 0x14 nên được nhân với hai. Từ thứ ba 0x0001 cho biết nếu hình ảnh là ký tự ASCII để cấu trúc ImageAsset cuối cùng trông như thế này:
struct ImageAsset
{
uint16_t width; // width/2 (big endian)
uint16_t height; // height/2 (big endian)
uint16_t ascii; // 1 if ASCII character
struct image_data {
uint8_t number; // number of pixels to render
uint8_t color; // index of pixel color in LUT
} data[];
}
Tuy nhiên, vẫn còn thiếu một phần - LUT.
Không khó để tìm một cái vì rất nhiều tài liệu tham khảo và cấu trúc đã được khôi phục theo cách thủ công, vì vậy tôi đã từ từ cuộn qua các phần dữ liệu để tìm kiếm mảng 256 mục có giá trị 16 bit hoặc 32 bit cho đến khi tôi gặp phải điều này:
.long 0x7008080, 0x72D8080, 0x73C8080, 0x75A8080, 0x79B8080, 0x71DFF6B, 0x7BE8080, 0x7FF8080
.long 0x77BBD27, 0x75B60E7, 0x7835F4A, 0x7D3089F, 0x7018080, 0x7028080, 0x7038080, 0x7048080
.long 0x7058080, 0x7068080, 0x7078080, 0x7088080, 0x7098080, 0x70A8080, 0x70B8080, 0x70C8080
.long 0x70D8080, 0x70E8080, 0x70F8080, 0x7108080, 0x7118080, 0x7128080, 0x7952B15, 0x7138080
.long 0x7148080, 0x7158080, 0x7168080, 0x7178080, 0x7188080, 0x7198080, 0x71A8080, 0x71C8080
.long 0x71D8080, 0x71E8080, 0x71F8080, 0x7338080, 0x7208080, 0x7218080, 0x7228080, 0x7238080
.long 0x7248080, 0x7248080, 0x7268080, 0x7278080, 0x7288080, 0x7298080, 0x72A8080, 0x72B8080
.long 0x72C8080, 0x75E8080, 0x7608080, 0x7628080, 0x7648080, 0x7678080, 0x7688080, 0x7698080
.long 0x76B8080, 0x76E8080, 0x7708080, 0x7728080, 0x7758080, 0x7778080, 0x7798080, 0x77C8080
.long 0x77E8080, 0x7818080, 0x7838080, 0x7868080, 0x7888080, 0x78B8080, 0x78D8080, 0x7908080
.long 0x7928080, 0x7958080, 0x7978080, 0x7998080, 0x79C8080, 0x79D8080, 0x7668080, 0x79E8080
.long 0x7A18080, 0x7A28080, 0x7A38080, 0x7A68080, 0x7A78080, 0x7A88080, 0x7AB8080, 0x7AC8080
.long 0x7AD8080, 0x7B08080, 0x7B28080, 0x7B58080, 0x7B88080, 0x7B98080, 0x7BC8080, 0x7CC8080
.long 0x7AB3BBB, 0x7E10094, 0x7E4556E, 0x4008080, 0x2922D17, 0x7B2AB00, 0x7C2A262, 0x71DFF6B
.long 0x768D4A2, 0x769D4EA, 0x7BD88AE, 0x705997B, 0x70BB377, 0x711CC73, 0x717E66F, 0x7238866
.long 0x729A262, 0x72FBB5E, 0x735D55A, 0x7417751, 0x747914D, 0x74DAA48, 0x753C444, 0x75F663B
.long 0x76B9933, 0x7998080, 0x771B32F, 0x77D5526, 0x7836F22, 0x789881E, 0x78FA21A, 0x7159095
.long 0x71AAA91, 0x720C38D, 0x726DD88, 0x7506F6A, 0x7568866, 0x75CA262, 0x762BB5E, 0x76E5E55
.long 0x7747751, 0x77A914D, 0x780AA48, 0x78C4D3F, 0x792663B, 0x7988037, 0x79E9933, 0x7AA3C2A
.long 0x7B05526, 0x7B66F22, 0x7BC881E, 0x72488AE, 0x72AA1AA, 0x72FBBA6, 0x735D4A2, 0x7427799
.long 0x7489095, 0x74DAA91, 0x753C38D, 0x77E556E, 0x7836F6A, 0x7898866, 0x78FA262, 0x79C4459
.long 0x7A15E55, 0x7A77751, 0x7AD914D, 0x7BF4D3F, 0x7CC8080, 0x7C5663B, 0x7CB8037, 0x7337FC8
.long 0x73999C4, 0x73FB2C0, 0x745CCBB, 0x7757799, 0x74C54FF, 0x77B9095, 0x780AA91, 0x7AB3C72
.long 0x7B1556E, 0x7B66F6A, 0x7BC8866, 0x74277E1, 0x74890DD, 0x74EAAD9, 0x754C3D5, 0x76066CC
.long 0x7667FC8, 0x76C99C4, 0x772B2C0, 0x77E55B7, 0x7846EB3, 0x78A88AE, 0x790A1AA, 0x7526EFB
.long 0x75787F7, 0x75DA1F3, 0x763BAEE, 0x76F5DE6, 0x77577E1, 0x77B90DD, 0x781AAD9, 0x78D4CD0
.long 0x79366CC, 0x79F99C4, 0x7E10094, 0x7CF44A1, 0x7DB7799, 0x7E71A90, 0x7ED338C, 0x7FF8080
.long 0x7328080, 0x7DC8080, 0x7C88080, 0x7508080, 0x775CD2C, 0x76944EA, 0x7808080, 0x71A61FF
.long 0x7244D40, 0x7242C15, 0xFFF8080, 0xF338080, 0xF668080, 0xF998080, 0xFCC8080, 0xF008080
.long 0xF4C54FF, 0xFAB3BBB, 0xFE10094, 0xFE4556E, 0xF952B15, 0xFDA7751, 0xFB2AB00, 0xFC2A262
.long 0xF1DFF6B, 0xF68D4A2, 0xF69D4EA, 0xFBD88AE, 0xA922D17, 0xC6E4130, 0xE286963, 0x74C55FF
.long 0x768D536, 0x7FF8080, 0x7FF8080, 0x7FF8080, 0x2922D17, 0x46E4130, 0x6286963, 0x8080
Một lần nữa, nhờ công việc của tôi cho Blackmagic Design, tôi đã có thể phát hiện ra các điểm ảnh YUV ngay lập tức (ví dụ như tất cả các giá trị 8080 này).
Rõ ràng là thật điên rồ khi đổ toàn bộ giao diện người dùng bằng tay bằng bút một lần nữa, vì vậy vâng, tôi đã tạo ra một công cụ khác - M240UITool[18]
Leica M (typ 240) UI Tool v1.0
Usage: ./M240UITool [-a address] [-i imagebase] [-s script] [-d dump] [-f folder] [-l LUT] [-rbv] FIRMWARE.BIN
This tool will help you to find UI resources in firmware.
Use following arguments:
-a Specify address of the gui_CopyImageDesc function (ex. 0x2F95E0)
-i Specify firmware imagebase
-s Specify IDC file name
-c Specify container file name
-d Specify dump image format
png - PNG format
bmp - BMP (ARGB) format
-f Specify folder for dumped images
-l Specify LUT for images (filename of address)
-b Specify number of bytes to display in verbose mode
-r Try to recover string characters
-v Be verbose
Ngoài việc kết xuất tất cả các tài sản hình ảnh từ tệp phần mềm sang BMP/PNG, công cụ này cũng có thể tạo tập lệnh IDC cho IDA để xác định tất cả các tài nguyên UI.
So far we already know that gui_CopyImageDesc is called multiple times from the function creating one UI page. I thought it would be awesome to have a UI resource browser and define all page-rendering functions. This is what the -c option is for - it produces a special container to be used in the viewer.
Và ai nói rằng một trình duyệt tài nguyên giao diện người dùng không thể trông lạ mắt?
Là tương tác (các nút bán trong suốt trên ảnh chụp màn hình ở trên), công cụ này cho phép bạn không chỉ cuộn qua các trang menu EVF/LCD mà còn thực hiện các giai đoạn kết xuất trong một trang.
Thật không may, nguồn gốc của kiệt tác này đã bị mất ở đâu đó nhưng các tệp tiêu đề vẫn ở đó như một phần của M240UITool, vì vậy về mặt kỹ thuật có thể tạo lại nó từ đầu.
Trình đơn gỡ lỗi
Chuỗi đầu tiên mà kỹ sư đảo ngược thường tìm kiếm trong mục tiêu là gì? Tôi đặt cược vào "gỡ lỗi" và các công cụ phái sinh.
Có rất nhiều chuỗi thú vị trong phần mềm, nhưng những chuỗi này rất đặc biệt:
$ strings ./IMG_LOKI-212_1.1.0.2.bin | grep "Debug Mode"
GUI: State: %d! Scanning for Debug Mode successful
GUI: Scanning for Debug Mode: State: %d, Ignore long DEL
GUI: Scanning for Debug Mode: State: %d
GUI: Scanning for Debug Mode: State: %d, Ignore long DEL
GUI: Scanning for Debug Mode: State: %d
GUI: Scanning for Debug Mode: State: %d, Ignore long DEL
GUI: Scanning for Debug Mode: State: %d
GUI: Scanning for Debug Mode: State: %d, Ignore long DEL
GUI: Scanning for Debug Mode: State: %d
GUI: Scanning for Debug Mode: State: %d, Ignore long DEL
GUI: Scanning for Debug Mode: State: %d
...
GUI: ScanningForDebugWithKeyAndJoyStick(): g_GUI_CheckForDebugWithKeyAndJoyStick = %d
Looks like it is possible to enter camera debug mode using some key combo. All these strings are referenced from one giant function ScanningForDebugWithKeyAndJoyStick which implements key scanning state machine. This is what it looks like in IDA
Tôi sẽ không nói dối, phải mất một thời gian để hiểu cách các nút phần cứng được xử lý trong phần mềm và sau đó khôi phục các enum cho các phím và cần điều khiển. Nhưng ngay cả sau khi tôi nhận được combo, thật đáng thất vọng khi phát hiện ra rằng nó không làm gì cả. Có lẽ nó chỉ hoạt động từ một số trang GUI cụ thể. Một vài buổi tối nữa theo dõi máy trạng thái GUI thủ công và vấn đề này đã được giải quyết cũng như trỏ đến trang menu Đặt lại.
Cuối cùng - Chào mừng bạn đến với Chế độ gỡ lỗi
Tôi đã suy nghĩ rất nhiều về việc liệu tôi có nên công khai combo này hay không nhưng quyết định không làm điều đó. Tôi tôn trọng công việc khó khăn mà Leica đang làm để đưa máy ảnh độc đáo của họ ra thị trường và không muốn chịu trách nhiệm nếu Trung tâm Dịch vụ của họ tràn ngập những cơ thể bị hỏng do sự tò mò thiếu suy nghĩ.
Phải nói rằng, tôi muốn cung cấp một số enums để giúp kỹ thuật đảo ngược dễ dàng hơn rất nhiều cho những người sẵn sàng đi theo cùng một con đường.
enum ControlActionType {
kControlAction_Idle, // 0
kControlAction_Push, // 1
kControlAction_Release, // 2
kControlAction_LongPush // 3
};
enum ControlBtnType {
kControlBtn_LV, // 0
kControlBtn_PLAY, // 1
kControlBtn_DEL, // 2
kControlBtn_ISO, // 3
kControlBtn_MENU, // 4
kControlBtn_SET // 5
};
enum ControlJoystickType {
kControlJoy_INFO, // 0
kControlJoy_Up, // 1
kControlJoy_Down, // 2
kControlJoy_Left, // 3
kControlJoy_Right // 4
};
Công ty PTP
Nhìn xung quanh mã tác vụ USB, tôi đã có thể xác định được ba chế độ USB khác nhau (nó cũng được xác nhận bởi menu gỡ lỗi):
- Công ty PTP
- MSC (Lớp lưu trữ hàng loạt)
- Tùy chỉnh Leica
PTP là phần thú vị nhất vì nó được ghi chép rõ ràng và cho phép bạn điều khiển máy ảnh.
Khá dễ dàng để xác định vị trí trình xử lý PTP trong phần mềm vì có rất nhiều chuỗi được tham chiếu từ mã đó.
Tất cả các yêu cầu PTP được chia thành ba nhóm: Legacy, Leica Extended (LE) và Production.
Các tin nhắn gỡ lỗi đã giúp đặt tên cho hầu hết mọi mã.
Legacy: Leica Extented: Production:
0x1001 - GetDeviceInfo 0x9001 - Set Camera Settings 0x9100 - Open Production Session
0x1002 - OpenSession 0x9002 - Get Camera Settings 0x9101 - Close Production Session
0x1003 - CloseSession 0x9003 - Get Lens Parameter 0x9102 - UpdateFirmware
0x1004 - Get Storage ID 0x9004 - Release Stage 0x9103 - Open OSD Session
0x1005 - Get Storage Info 0x9005 - Open LE Session 0x9104 - Close OSD Session
0x1006 - GetNumObjects 0x9006 - Close LE Session 0x9105 - Get OSD Data
0x1007 - GetObjectHandles 0x9007 - RequestObjectTransferReady 0x9106 - GetFirmwareStruct
0x1008 - GetObjectInfo 0x9008 - GetGeoTackingData 0x910B - GetDebugMenu
0x1009 - GetObject 0x900A - Open Debug Session 0x910C - SetDebugMenu
0x100A - Get Thumb 0x900B - Close Debug Session 0x910D - ODIN Message
0x100B - Delete Object 0x900C - Get Debug Buffer 0x910E - GetDebugObjectHandles
0x100E - Initiate Capture 0x900D - Debug Command String 0x910F - GetDebugObject
0x1014 - GetDevicePropDesc 0x900E - Get Debug Route 0x9110 - DeleteDebugObject
0x1015 - GetDevicePropV 0x900F - SetIPTCData 0x9111 - GetDebugObjectInfo
0x101C - Initiate Open Capture 0x9010 - GetIPTCData 0x9112 - WriteDebugObject
0x9020 - Get3DAxisData 0x9113 - CreateDebugObject
0x9030 - OpenLiveViewSession 0x9114 - Calibrate 3Daxis
0x9031 - CloseLiveViewSession 0x9115 - Magnetic calibration
0x9033 - Unknown 0x9116 - Get Viewfinder Data
Bản thân việc triển khai giao diện PTP có vẻ tiêu chuẩn, tuy nhiên một số lệnh có những hạn chế mà tôi cố tình bỏ qua ở đây.
Dù sao, tất cả những điều trên đều khá thú vị, vì vậy bạn có thể nghĩ "Hãy kết nối máy ảnh qua USB và bắt đầu thăm dò bằng libptp".
Ôi, chết tiệt...
Leica M240 KHÔNG có cổng USB theo thiết kế.
Cổng tay cầm
Leica không cung cấp nhiều phụ kiện cho chiếc máy ảnh này, tuy nhiên có một phụ kiện đặc biệt thú vị. Tôi đang nói về Tay cầm đa chức năng Leica M (14495). Nó thay thế vị trí kim loại phía dưới và cung cấp GPS tích hợp và một số đầu ra như USB, thiết bị đầu cuối flash SCA, DIN/ISO-X và ổ cắm điện.
Và bạn có thể nghĩ lại "Tốt vời, hãy mua cái đó, gắn nó vào máy ảnh, kết nối máy ảnh qua USB và bắt đầu thăm dò bằng libptp".
Ôi, chết tiệt...
Nó có giá gần 900 đô la Mỹ.
Nó giống như chín trăm lý do để tạo ra bộ chuyển đổi của riêng tôi thay vào đó. Tuy nhiên, chỉ trong trường hợp tôi thiết lập thông báo eBay cho tay cầm đã qua sử dụng.
Ổ cắm
Ổ cắm trên máy ảnh trông như thế này:
Tôi đã thử tìm kiếm nó trên internet, nhưng nghiêm túc mà nói, bạn sẽ mô tả nó như thế nào trên google?
Hơi tuyệt vọng, tôi đã bắt đầu nghĩ về một số điều điên rồ như dán giấy bạc hoặc kim vào cục tẩy cho đến một ngày tại nơi làm việc trong Blackmagic Design nhìn vào PCB máy ảnh, tôi nhận thấy rằng một ổ cắm có hình dạng rất quen thuộc. Ngày hôm sau tôi mang Leica M240 của mình đến nơi làm việc và vâng, nó trông tương tự, chỉ dài hơn rất nhiều với nhiều miếng đệm tiếp xúc hơn.
Vì vậy, vấn đề là yêu cầu người quản lý thành phần của chúng tôi cung cấp số bộ phận và sau đó duyệt Samtec để tìm số tôi cần - ERM8-013-05.0-L-DV-TR [19]
Chúng tôi cũng đã hỏi Samtec liệu có thể lấy mẫu không và có, họ vui lòng đồng ý gửi cho chúng tôi một số.
Một chút hàn, bìa cứng và băng keo để có được v2013 đột phá của riêng tôi.
Sau đó vào năm 2018, tôi quyết định đích thân yêu cầu Samtec cho một mẫu khác. Tuy nhiên, lần này tôi muốn thứ gì đó tốt hơn.
ERCD-013-05.00-TTR-TTR-1-D [20]
Sau đó, rất nhiều hàn, chửi thề, cắt dây, chửi thề và hàn lại chỉ để có được sự đột phá v2018:
Pinout
Ổ cắm có 26 tiếp điểm - 13 ở mỗi bên. Ngay cả trước khi tôi quản lý để xây dựng đột phá của mình, tôi đã thực hiện một số nghiên cứu thăm dò ổ cắm máy ảnh bằng đồng hồ vạn năng và máy phân tích logic. Nhân tiện, cần phải đặt một nam châm trên cảm biến nắp dưới cùng để máy ảnh nghĩ rằng một nắp được gắn vào.
Nối đất (máy ảnh đã tắt, không có pin)
Tôi luôn bắt đầu từ mặt đất vì nó an toàn và rất dễ tìm.
Vì vậy, có tổng cộng 8 đường đất (màu xám đậm).
Tiềm năng (máy ảnh đang bật)
Khi máy ảnh BẬT, có thể đo tiềm năng trên mỗi miếng đệm để có ý tưởng về logic và mức năng lượng.
Các cấp độ trên 8-9 và 11-13 quá cao để có thể logic, do đó tôi đã định nghĩa các miếng đệm này là nguồn (màu đỏ).
Điện trở (máy ảnh đã tắt, không có pin)
Một điều hữu ích khác để đo lường là sức đề kháng. Trong một số trường hợp, nó giúp xác định đầu vào và nhóm một số dòng.
Đầu ra được liên kết (máy ảnh đã tắt, không có pin)
Sau đó, tôi đã quyết định thăm dò tất cả các miếng đệm tiếp xúc bên ngoài trên thân máy ảnh để kiểm tra xem chúng có được liên kết với cổng dịch vụ hay không.
Flash Sync pad trên hotshoe được kết nối trực tiếp với dòng 10.
Logic Analyzer (camera đang bật)
Dữ liệu cho mỗi dòng được ghi lại bằng cách sử dụng trình tự sau:
BẬT, máy ảnh nên ở chế độ LV, chụp ảnh, bắt đầu quay video
Có hai dòng hiển thị một số loại truyền dữ liệu: 01 và 21.
01 - 115200, 8 bit mỗi lần truyền, 1 bit dừng, bit chẵn lẻ, LSB đầu tiên
Mỗi 500ms nó gửi một số bộ đếm C3 3C 02 81 00 01 00 82, C3 3C 02 81 01 01 00 83, C3 3C 02 81 02 01 00 80
21 - 115200, 8 Bit mỗi lần truyền, 1 Bit Dừng, Không có Bit Chẵn lẻ, LSB trước
Nó gửi nhật ký bộ nạp khởi động SH7216 ("Leica Camera AG" trên ảnh chụp màn hình ở trên)
Hãy đánh dấu chúng bằng màu xanh đậm. Thật đáng buồn khi không có nhật ký Maestro được hiển thị ở đâu đó ngay cả khi mức độ gỡ lỗi tối đa được bật trong menu Gỡ lỗi.
Những cái có tín hiệu có điện trở khoảng 310kOhm.
Không biết tại sao, nhưng tôi cho rằng các dòng dữ liệu khác có thể có sức đề kháng tương tự hoặc đóng. Do đó, tôi cũng đã xác định các đường ~300kOhm, ~200kOhm và ~100kOhm làm dữ liệu (các sắc thái của màu xanh lam trên ảnh).
Kết hợp lại, tôi có bức ảnh sau.
12 ứng cử viên cho các dòng dữ liệu. Nhưng làm thế nào để kiểm tra điều đó? Sau một cuộc trò chuyện ngắn với những người làm phần cứng về an toàn điện khi làm việc với IC, cuối cùng tôi đã chọc qua điện trở 4kOhm được cho là sẽ giảm dòng điện xuống mức mà tôi không có khả năng đốt cháy đầu vào.
UART
Một giả định khác mà tôi đã đưa ra là dòng RX nên nằm cạnh dòng TX. Các dòng 02, 03 và 20 trông giống như những ứng cử viên tốt vì cả hai đều là 3,3V như TX.
Ban đầu, tôi đã sử dụng Bus Pirate để nói chuyện với những dòng này, nhưng thật không may, nó không thể theo kịp cho kết quả khá lộn xộn. Sau đó, tôi đã chuyển sang cáp dựa trên SiLabs vì chúng đáng tin cậy hơn rất nhiều và không xung đột với bất kỳ thứ gì trên macOS.
At first, I attached cable TX to pin 20 and started to type help after bootloader banner. As expected the camera echoed characters back after a short delay.
Các chân tìm kiếm UART tiếp theo là 02 và 03. Thật không may, không có dấu hiệu nào cho thấy ai đó đang nghe những thứ đó.
Trên sơ đồ, các UART được biết đến được xác định bằng màu xanh lá cây đậm hơn.
USB
Tất cả bắt đầu với một cáp USB cắt đôi với tiêu đề ở giữa và điện trở 4kOhm để thăm dò. Tính toàn vẹn tín hiệu cho cặp vi sai? Không, hồi đó nó không làm phiền tôi nhiều :)
Sau đó, tôi đã đánh hơi một số thiết bị tiêu dùng có USB ở nhà để có ý tưởng về giao tiếp USB trông như thế nào.
Máy ảnh Canon
Máy quay phim bỏ túi Blackmagic
Máy quay phim Canon
Máy quay phim JVC
Móc khóa
Máy ảnh KidiZoom
Tất cả chúng đều khác nhau một chút, nhưng trạng thái D- D+ ban đầu là thấp. Chà, thật tốt khi biết, hãy kiểm tra những gì còn lại trên cổng kẹp tương tự như vậy:
22 - không chắc vì D- D+ là cặp vi phân và nên khá gần nhau
04/05 - không chắc vì họ có sức đề kháng khác nhau
14/15 - không chắc vì họ có sức đề kháng khác nhau
15/16 - có thể vì chúng gần nhau và có sức đề kháng tương tự
Do đó, tôi đã gắn USB D- D+ vào 15/16 và cắm nó vào iMac...
Có USB PTP trên màn hình, nhưng máy ảnh vẫn không xuất hiện trên máy chủ. Tôi đã thử thiết lập các sơ đồ chấm dứt USB khác nhau trên bảng mạch bánh mì nhưng không có gì hiệu quả. Beagle cho thấy nhiều gói bị hỏng và các lỗi khác. Cuối cùng tôi đã bỏ cuộc và quay lại phần mềm kỹ thuật đảo ngược.
Đây là sơ đồ chân cuối cùng với USB được sơn màu xanh lá cây đậm.
Ai có thể nghĩ rằng, vài năm sau tôi nhận được thông báo eBay mong muốn và quản lý để có được tay cầm này khá rẻ.
Cuối cùng, tôi có thể kiểm tra kết quả PTP của mình. Nhưng trước tiên tôi rõ ràng tò mò USB PHY trông như thế nào bên trong tay cầm.
Bên trong tôi tìm thấy trung tâm SMSC 2512b[21] ngay trên đường đi từ ổ cắm kẹp đến đầu nối Mini USB. Chip đang hoạt động ở chế độ mặc định vì không có EEPROM và các chân SCL/SDA bị kéo xuống. Cổng hạ lưu đầu tiên được định tuyến đến ổ cắm thân máy ảnh, nhưng cổng thứ hai không được kết nối với bất cứ thứ gì.
Tôi có thể đã bỏ lỡ điều gì đó nhưng đối với tôi giải pháp này không có nhiều ý nghĩa. Nhìn qua bảng dữ liệu, tôi phát hiện ra rằng chip có "Các điện trở kết thúc USB và kéo lên/kéo xuống tích hợp đầy đủ". Có thể các kỹ sư của Leica đã quyết định không triển khai USB PHY của riêng họ và sử dụng một cái trong một trung tâm được kiểm tra rất tốt và hoạt động ngay lập tức. Trên thực tế, tôi không thể đổ lỗi cho họ vì tôi đã cố gắng tự mình làm điều tương tự trước đó và nó có vẻ là một nhiệm vụ khó khăn. Nó cũng có thể là một tính năng bảo vệ tay cầm khỏi hàng giả, ai biết được.
Dù sao, nếu bạn giỏi USB PHY và sẵn sàng giúp đỡ, vui lòng ping tôi, có thể làm cho cổng USB hoạt động mà không cần kẹp :)
PTP một lần nữa
Như tôi đã nói, đã đến lúc chơi với các tiện ích mở rộng Leica PTP.
May mắn thay, tôi đã tìm thấy thư viện C++ khá thú vị để sử dụng thay vì libptp - libEasyPTP[22]. Cũng không mất nhiều thời gian để viết công cụ dựa trên thư viện này vì tôi đã biết một số hạn chế trong giao diện Leica PTP.
Ngay cả khi M240PTPTool khá lỗi, nó vẫn đủ tốt như PoC[23].
Chỉ có hai yêu cầu PTP được sử dụng: GetDebugBuffer (0x900C) và DebugCommandString (0x900D).
Nhân tiện, để tạo các mô-đun để điền vào nhật ký gỡ lỗi, cần phải đặt Cấp độ gỡ lỗi thành "Gỡ lỗi" hoặc "Gỡ lỗi RAW" trong Menu Gỡ lỗi.
Công cụ CLI cung cấp một số tùy chọn:
thoát thoát khỏi công cụ;
lệnh flush kết xuất bộ đệm gỡ lỗi từ máy ảnh:
M240> flush
I:[00:11:468]|01| DATE/TIME CORRECTED by 5921 sec
D:[00:12:079]|00| Send message from TID 0 to TID 1 over MBX 3 - length: 4 - MesgID: 0x22020103
D:[00:12:179]|00| Send message from TID 0 to TID 1 over MBX 3 - length: 4 - MesgID: 0x22020103
D:[00:12:282]|11| Message received from TID 0 for TID 1 over MBX 3
D:[00:12:283]|11| Message received from TID 0 for TID 1 over MBX 3
D:[00:12:301]|00| Send message from TID 0 to TID 1 over MBX 3 - length: 4 - MesgID: 0x22020103
D:[00:12:402]|00| Send message from TID 0 to TID 1 over MBX 3 - length: 4 - MesgID: 0x22020103
D:[00:12:502]|00| Send message from TID 0 to TID 1 over MBX 3 - length: 4 - MesgID: 0x22020103
...
any other text will be sent as Debug Command String to the camera. help for example outputs all possible commands with arguments:
M240> help
********* debug command description ********
exposure request
Description: requests a release from Sub CPU
Parameter 1: Exposure Time TV
still request
Description: simulates the -still request- command flow of Sub CPU
Parameter: no
...
send Message;[Parameter1];[Parameter2];[Parameter2];...;...
Description: Sending Message to Task
Parameter 1: Receiver Task ID
Parameter 2: Command ID
Parameter 3: Command Data[0] (32 Bit)
Parameter 4: Command Data[1] (32 Bit)
Parameter 5: .
Parameter 6: .
use maximum 10 Parameter
...
Danh sách đầy đủ khá lớn, nhưng wow, chúng tôi có thể gửi tin nhắn Softune thô cho bất kỳ nhiệm vụ nào! Điều gì rất thú vị mà chúng ta có thể gửi đến đó...
Chuỗi phổ biến khác để tìm kiếm trong phần mềm - "dump". Hãy xem những gì chúng ta có trong trường hợp của chúng ta.
$ strings IMG_LOKI-212_1.1.0.2.bin | rg -i dump
GUI: HEX DUMP: Address: %x, Length: %d
HSK: DBG_WRITE_ROM_DUMP_SD: File was properly opened, but it seems to be empty.
ROM_DUMP
HSK: DBG_WRITE_ROM_DUMP_SD: Flushing Dump to ROM. Size %d
SD:\ROM_DUMP.bin
HSK: DBG_WRITE_ROM_DUMP_SD Command received!
ROM_DUMP.bin
HSK: DUMP failed, no cards inserted!
HSK: DUMP FlashROM to SD card.
HSK: DUMP FlashROM to CF card.
Dumping files to card
Apparently, it is possible to dump firmware to SD card. It is easy to find code responsible for that by reference to string “Dumping files to card”. It is located in giant message hander of System Task (pid 11 as we already know) and can be triggered by message 0x11080006 without arguments.
Type send Message;11;0x11080006 in M240PTPTool, hit enter and observe the screen.
Sau đó tháo thẻ SD và kiểm tra những gì trên đó.
Đây rồi, kết xuất đầy đủ bao gồm cả phần mềm.
Nhưng điều quan trọng hơn, bây giờ có thể sửa đổi chương trình cơ sở này theo bất kỳ cách nào và flash nó trở lại máy ảnh bằng cách sử dụng một lệnh gỡ lỗi khác: send Message;11;0x11080012.
Như bạn có thể thấy điều này mở ra vô số cơ hội. Ví dụ: có thể xây dựng thiết bị nhỏ với MCU hỗ trợ máy chủ USB và một số nút để thực hiện các chuỗi tin nhắn phức tạp thông qua PTP. Và nếu nó không đủ - chỉ cần flash máy ảnh với phần mềm tùy chỉnh của riêng bạn...
Và sau đó chúng tôi có đứa con thứ hai :)
Phần kết
Thường có một cách để nghiên cứu các thiết bị mà bạn không muốn phá vỡ mà không cần mở thân hoặc hàn dây vào PCB của nó. Dưới đây là những lời khuyên của tôi nếu bạn không phiền:
- nhận tất cả thông tin công khai bạn có thể về thiết bị: bảng dữ liệu, tháo dỡ, ảnh nội bộ, video từ nhà máy [24] ;)
- đào sâu vào phần mềm nếu bạn có nó để tìm gợi ý về đầu ra bên ngoài
- luôn tìm kiếm các phép thuật khác nhau và các chuỗi byte lẻ mà bạn tìm thấy trong các tệp phần mềm
- đo GND/Tiềm năng/Skháng đối với tất cả các miếng đệm bên ngoài tiếp xúc không xác định
- thăm dò các miếng đệm này bằng máy phân tích logic
- luôn nhớ về các biện pháp an toàn khi xử lý thiết bị điện tử
- cố gắng loại trừ các miếng đệm không thuộc phạm vi quan tâm của bạn (mặt đất, nguồn)
- nếu bạn không thể nhận ra tín hiệu bằng chế độ xem tương tự của nó, hãy thử tìm kiếm những cái phổ biến nhất (USB/UART/SPI/I2C/1Wire)
- nếu bạn có một số ý tưởng về bản chất tín hiệu, hãy thử xác minh bản thân bằng các thiết bị điện tử tiêu dùng tương tự
- suy nghĩ
banăm lần trước khi cố gắng GỬI dữ liệu đến thiết bị, chẳng hạn như đường lái xe thấp/cao - và tất nhiên, đừng ngần ngại hỏi người khác
Tài liệu tham khảo
[1] https://github.com/alexhude/LeicaHacks/tree/master/Tools/pwadsplit
[2] http://doom.wikia.com/wiki/WAD
[3] https://en.wikipedia.org/wiki/LHA_(file_format)
[4] https://github.com/CatacombGames/CatacombArmageddon/blob/master/LZW.C
[5] https://github.com/krater/Blackfin-IDA-Pro-Plugin
[6] https://github.com/alexhude/LeicaHacks/tree/master/Tools/xortool
[7] https://en.wikipedia.org/wiki/List_of_file_signatures
[8] https://github.com/alexhude/LeicaHacks/tree/master/Tools/M240FwTool
[9] https://github.com/alexhude/LeicaHacks/tree/master/Tools/fr (requires IDA 6.4 SDK)
[10] https://en.wikipedia.org/wiki/Delay_slot
[11] https://edevice.fujitsu.com/fj/MANUAL/MANUALp/en-pdf/CM71-10158-1E.pdf (link is dead)
[12] https://en.wikipedia.org/wiki/Softune
[13] https://en.wikipedia.org/wiki/Relocatable_Object_Module_Format
[14] https://github.com/alexhude/LeicaHacks/tree/master/Tools/FRLibTool
[15] https://github.com/alexhude/LeicaHacks/tree/master/IDA/signatures/
[16] https://www.fujitsu.com/downloads/MICRO/fma/pdfmcu/resofrke-cm71-00321-3e.pdf
[17] https://github.com/alexhude/LeicaHacks/tree/master/IDA/scripts/softune.py
[18] https://github.com/alexhude/LeicaHacks/tree/master/Tools/M240UITool
[19] https://www.samtec.com/products/erm8-013-05.0-l-dv-tr
[20] https://www.samtec.com/products/ercd-013-05.00-ttr-ttr-1-d
[21] https://www.microchip.com/wwwproducts/en/USB2512B
[22] https://github.com/TrueJournals/libEasyPTP
[23] https://github.com/alexhude/LeicaHacks/tree/master/Tools/M240PTPTool
[24] https://youtu.be/p4t-OVIvuy8?t=196
Nguồn : https://alexhude.github.io/2019/01/24/hacking-leica-m240.html
Nhận xét
Đăng nhận xét