डिस्क्लेमर: अध्ययन 2013 में शुरू हुआ था, इसलिए यदि आपको लगता है कि कुछ तरीके बेवकूफ और खतरनाक हैं - तो आप सही हैं, यह बात थी। हालाँकि, मैंने इस प्रक्रिया में बहुत कुछ सीखा।

प्रविष्टि
यह सब मेरे पहले बच्चे के जन्म से कुछ महीने पहले शुरू हुआ। मैं और मेरी पत्नी हमेशा एक शांत लेईका कैमरा खरीदना चाहते थे और अचानक महसूस किया कि अगर हमने इसे अभी नहीं खरीदा है, तो हम इसे लंबे समय तक नहीं कर सकते। इसलिए, हमने M240 कैमरा और ... बूम का आदेश दिया, हमें छह महीने तक लाइन में लगाया गया। जल्द ही मैं प्रतीक्षा से थक गया, और मैंने उनकी साइट का अध्ययन करना शुरू कर दिया। मेरा ध्यान तुरंत फाइल सेक्शन पर गया। खैर, आप अनुमान लगा सकते हैं क्यों ... फर्मवेयर!

मैंने एक अनएन्क्रिप्टेड और असम्पीडित फ़ाइल ( m8-2_005.upd ) m8-2_005.upd जो PWAD मैजिक से शुरू होती है। क्या आप पहचानते हैं? हां, यह सही है, यह कयामत पैच WAD प्रारूप है। दोस्तों लगता है क्लासिक्स से प्यार हो गया। प्रारूप बहुत अच्छी तरह से प्रलेखित है , इसलिए इसे पार्स करना मुश्किल नहीं था।

Leica फर्मवेयर फ़ाइलें

फर्मवेयर लीका एम 8

यह वास्तव में बहुत मज़ेदार है, क्योंकि जब मैंने बाद में संपीड़ित लीका टी फर्मवेयर फ़ाइल का अध्ययन किया, तो मैंने पहली बार संपीड़न विधियों का परीक्षण करने का फैसला किया जो आईडी सॉफ़्टवेयर अतीत में उपयोग किया गया था।

विकिपीडिया का कहना है कि उन्होंने LHA प्रारूप का उपयोग किया, जो अनिवार्य रूप से LZW है। लेकिन आम LZW डिकम्प्रेसर्स फिट नहीं थे, इसलिए मैंने आईडी सॉफ्टवेयर के एक विशिष्ट कार्यान्वयन की तलाश शुरू कर दी - और वॉइला, मुझे स्रोत कोड में कैटाकॉम्ब आर्मगेडन मिला। मुझे स्वीकार करना चाहिए, भाग्यशाली।

किसी भी स्थिति में, M8 पर वापस जाएं। यहाँ फर्मवेयर संरचना है:

  नियम: 0x0000008C (3036: 0x00000BDC) - XML ​​विवरण
 LUTS: 0x00000C68 (183274: 0x0002CBEA)
  गामा: 0x0000007C (31760: 0x00007C10)
  GAIN: 0x00007C8C (50344: 0x0000C4A8)
  LEICA: 0x00014134 (7000: 0x00001B58)
  BLEMISH: 0x00015C8C (250: 0x000000FA)
  WREF: 0x00015D88 (82480: 0x00014230)
  OBJ: 0x00029FB8 (11268: 0x00002C04)
  संस्करण: 0x0002CBBC (46: 0x0000002E)
 पीएक्सए: 0x0002D854 (858384: 0x000D1910)
 बीएफ: 0x000FF164 (134522: 0x00020D7A) - एनालॉग डिवाइसेस ब्लैकफिन प्रोसेसर परिवार
 GUI: 0x0011FEE0 (3574180: 0x003689A4)
  ट्रांस: 0x0000005C (59988: 0x0000EA54) - स्थानीयकरण
  IMAGES: 0x0000EAB0 (267433: 0x000414A9)
   21_1PRT: 0x000000CC (18411: 0x000047EB) - JFIF की तस्वीर
   21_2GRP: 0x000048B8 (23172: 0x00005A84) - JFIF की छवि
   21_3PAN: 0x0000A33C (23034: 0x000059FA) - JFIF की तस्वीर
   24_1PRT: 0x0000FD38 (18489: 0x00004839) - JFIF की छवि
   24_2GRP: 0x00014574 (23230: 0x00005ABE) - JFIF की छवि
   24_3PAN: 0x0001A034 (22998: 0x000059D6) - JFIF की छवि
   28_1PRT: 0x0001FA0C (22605: 0x0000584D) - JFIF की तस्वीर
   28_2GRP: 0x0002525C (23081: 0x00005A29) - JFIF की छवि
   28_3PAN: 0x0002AC88 (23282: 0x00005AF2) - JFIF की छवि
   35_1PRT: 0x0003077C (22496: 0x000057E0) - JFIF की छवि
   35_2GRP: 0x00035F5C (23532: 0x00005BEC) - JFIF की तस्वीर
   35_3PAN: 0x0003BB48 (22881: 0x00005961) - JFIF की छवि
  FONT1: 0x0004FF5C (1522988: 0x00173D2C)
  FONT2: 0x001C3C88 (1723676: 0x001A4D1C)
  संस्करण: 0x003689A4 (0: 0x00000000)
 M16C: 0x00488884 (130406: 0x0001FD66) - रेनेसस M16C परिवार (मोटोरोला S- रिकॉर्ड)
 FPGA: 0x004A85EC (131604: 0x00020214) - Xilinx संयमी 3
 FSL: 0x004C8800 (814: 0x0000032E) - पहला चरण बूटलोडर 

बॉक्स से बाहर आईडीए ब्लैकफिन प्रोसेसर का समर्थन नहीं करता है, लेकिन एक तृतीय-पक्ष प्लगइन है ।

फर्मवेयर लीका एम 9

Leica M9 फर्मवेयर फ़ाइल ( m9-1_196.upd ) एन्क्रिप्टेड लगती है: हिस्टोग्राम लगभग 0.45% का वितरण दिखाता है।



कहानी का अंत? शायद नहीं। तथ्य यह है कि लेईका ने कैमरों में कमजोर प्रोसेसर का उपयोग किया था, और उस समय उपभोक्ता इलेक्ट्रॉनिक्स में XOR एन्क्रिप्शन का अक्सर उपयोग किया जाता था, इसलिए मैंने XOR ऑपरेशन के लिए फर्मवेयर की तुलना करने और कुछ आंकड़ों की गणना करने के लिए एक सरल उपकरण लिखने का फैसला किया।

प्रमुख लंबाई को सबसे लंबे दोहराए जाने वाले पैटर्न की खोज करके निर्धारित किया गया था। यह समझ में आता है, क्योंकि किसी भी फर्मवेयर में आमतौर पर दोहराए जाने वाले डेटा के बड़े ब्लॉक शामिल होते हैं, जैसे कि 0x00 / 0xFF पैड या ग्रूट पिक्सल के साथ ग्राफिक्स। कुंजी को कुंजी की लंबाई के भीतर बाइट्स की आवृत्ति द्वारा गणना की जाती है, जहां सबसे आम बाइट कुंजी बफर में जाती है। कार्यक्रम के परिणाम ने स्पष्ट रूप से XOR एन्क्रिप्शन का संकेत दिया। फिर मुझे संभावित कुंजी प्राप्त करने और कोड को डिक्रिप्ट करने के लिए टूल को थोड़ा संशोधित करना पड़ा। यह फिर से एक PWAD फ़ाइल बन गई।

पीडब्लूएडी की सामग्री से निम्न संरचना का पता चला:

  नियम: 0x0000007C (2788: 0x00000AE4) - एक्सएमएल विवरण
 LUTS: 0x00000B60 (4060616: 0x003DF5C8)
  प्रक्रिया: 0x0000004C (3900572: 0x003B849C)
   क्रिएट: 0x0000004C (20: 0x00000014) - टाइमस्टैम्प
   LUTS: 0x00000060 (427744: 0x000686E0)
   GAINMAP: 0x00068740 (20008: 0x00004E28)
   लेंस: 0x0006D568 (3452724: 0x0034AF34)
  सीसीडी: 0x003B84E8 (148662: 0x000244B6)
   क्रिएट: 0x0000004C (20: 0x00000014) - टाइमस्टैम्प
   BLEMISH: 0x00000060 (1092: 0x00000444)
   WREF: 0x000004A4 (147452: 0x00023FFC)
   लिन: 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) - एनालॉग डिवाइसेस ब्लैकफिन प्रोसेसर परिवार
  bf0: 0x0000004C (117846: 0x0001CC56) - मुख्य प्रोसेसर
  bf1: 0x0001CCA4 (117826: 0x0001CC42) - सबप्रोसेसर की फर्मवेयर
  bf0.map: 0x000398E8 (27072: 0x000069C0) - वर्णों के लिए मुख्य प्रोसेसर फर्मवेयर कार्ड: D
  bf1.map: 0x000402A8 (26304: 0x000066C0) - पात्रों के साथ उप-प्रोसेसर फर्मवेयर कार्ड: डी
 शरीर: 0x00426A90 (143280: 0x00022FB0) - रेनेसा M16C परिवार (मोटोरोला S- रिकॉर्ड)
 GUI: 0x00449A40 (3647624: 0x0037A888)
  ट्रांस: 0x0000005C (131656: 0x00020248) - स्थानीयकरण
  IMAGES: 0x000202A4 (267433: 0x000414A9)
   21_1PRT: 0x000000CC (18411: 0x000047EB) - JFIF की तस्वीर
   21_2GRP: 0x000048B8 (23172: 0x00005A84) - JFIF की छवि
   21_3PAN: 0x0000A33C (23034: 0x000059FA) - JFIF की तस्वीर
   24_1PRT: 0x0000FD38 (18489: 0x00004839) - JFIF की छवि
   24_2GRP: 0x00014574 (23230: 0x00005ABE) - JFIF की छवि
   24_3PAN: 0x0001A034 (22998: 0x000059D6) - JFIF की छवि
   28_1PRT: 0x0001FA0C (22605: 0x0000584D) - JFIF की तस्वीर
   28_2GRP: 0x0002525C (23081: 0x00005A29) - JFIF की छवि
   28_3PAN: 0x0002AC88 (23282: 0x00005AF2) - JFIF की छवि
   35_1PRT: 0x0003077C (22496: 0x000057E0) - JFIF की छवि
   35_2GRP: 0x00035F5C (23532: 0x00005BEC) - JFIF की तस्वीर
   35_3PAN: 0x0003BB48 (22881: 0x00005961) - JFIF की छवि
  FONT1: 0x00061750 (1522988: 0x00173D2C)
  USBLOGO: 0x001D547C (1775: 0x000006EF) - JFIF की तस्वीर
  FONT2: 0x001D5B6C (1723676: 0x001A4D1C)
 FPGA: 0x007C42C8 (150176: 0x00024AA0) - Xilinx Spanan MA
 BF547: 0x007E8D68 (937576: 0x000E4E68) - एनालॉग डिवाइसेस ब्लैकफिन प्रोसेसर फैमिली (FSL?) 

फर्मवेयर लीका एम 240

मुझे हर सुबह लीका फर्मवेयर के साथ डाउनलोड पृष्ठ की जांच करने की आदत पड़ गई। जल्द ही एक नई फ़ाइल दिखाई दी: FW_M240_1_1_0_2.FW ।

यह एन्क्रिप्टेड नहीं दिखता था, लेकिन संकुचित था ...

दबाव

हिस्टोग्राम 0x9D पर एक विशाल फट दिखाता है।



शायद यह किसी प्रकार का संपीड़न जादू है। इंटरनेट पर एक खोज [9D + सम्पीडन] कुछ भी नहीं निकली, सिवाय इसके कि 0x1F9D को LZ1 संपीड़न के लिए हस्ताक्षर के रूप में उपयोग किया जाता है । यदि कुछ भी हो, तो मैं LZ संपीड़न प्रकारों को समझता हूं और 0x9D के बाद बाइट्स को देखने का फैसला किया है। और मैंने चार विकल्प देखे:

1. 9D 70 C4
   
2. 9D 00
   
3. 9D XX YY
   
4. 9D XX 8Y YY

आपने और क्या नोटिस किया:

• पहला विकल्प 0x30 पते पर केवल एक बार पॉप अप करता है: यह संभवतः संपीड़ित डेटा के संकेतक के रूप में उपयोग किया जाता है;
  
• XX कभी भी 0x7F से अधिक नहीं होता है;
  
• तीसरे और चौथे मामलों में YY का अंतिम बाइट कभी 0x7F से अधिक नहीं होता है

LZ के बारे में मुझे जो पता है, यह LZ77 या LZSS से बहुत मिलता-जुलता है, जहां YY इंडेंट स्टेप है और XX को कॉपी करने के लिए बाइट्स की संख्या है। और दूसरा विकल्प 0x9D जारी करने का एक विशेष मामला है। मैंने एक साधारण सी फ़ंक्शन लिखा है जो इस तर्क को लागू करता है। उसने पुष्टि की कि हम सही दिशा में आगे बढ़ रहे हैं, लेकिन चौथा विकल्प अभी भी योजना में फिट नहीं है।

मैंने इसकी व्याख्या करने के लिए हर तरह से कोशिश की, लेकिन इसका कुछ नहीं आया। इसलिए, मैंने सलाह के लिए अपने साथियों की ओर रुख किया। एक आदमी ने देखा कि मेरी अपनी टिप्पणियों के अनुसार, YY की चौथी बाइट केवल तभी दिखाई देती है जब उच्चतम बिट 0x8Y सेट होता है: यह इंडेंट स्टेप के लिए सिर्फ एक अतिरिक्त दूरी है। मुझे शर्म आ रही थी, सब कुछ इतना स्पष्ट निकला ...

अंत में, डिकम्प्रेसर ने एक वैध स्ट्रीम जारी करना शुरू कर दिया ... जब तक यह फ़ाइल के बीच में अटक नहीं गया। स्लाइडिंग विंडो की अज्ञात लंबाई के कारण ऐसा हुआ। अतिरिक्त डिबगिंग और परीक्षणों ने स्थिति को तय किया।

तो फर्मवेयर M240 को पार्स करने के लिए एक उपकरण था।

फर्मवेयर संरचना

एक अज्ञात प्रारूप के साथ काम करने के लिए, मैं कुछ ऑफसेट और कोड वर्गों के आकार को मापने से बेहतर कुछ भी नहीं आया - और फ़ाइल हेडर में निकटतम मूल्यों को खोजने की कोशिश कर रहा हूं। उदाहरण के लिए, यह ब्लॉक:

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

अंततः में बदल गया:

1E1CAF2E — "LEICA FILE"
01010002 - 1.1.0.2
005C1AB1 — (big endian)
01291A7E — (big endian)
AE3873659C3D75B4342F446E13178E6B — MD5
00000001 —
00000030 —

जैसा कि मैंने फर्मवेयर की संरचना को समझा, मैंने अपने टूल में सुधार किया, और अंत में, इसने इसका उत्पादन किया:

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!

M240 फर्मवेयर में नौ तत्वों वाला एक कंटेनर शामिल है:

IMG_LOKI-212.bin -
IMG_LOKI-213.bin -
CTRL_SYS-11.bin - -
IMG-FPGA-212.bin - ()
IMG-FPGA-213.bin - ()
IMG-DSP-212.bin - DSP
IMG-DSP-213.bin - DSP
IMG-LENSDATA-212.bin -
IMG-LENSDATA-213.bin -

जैसा कि आप देख सकते हैं, एक फर्मवेयर में फाइलों के दो सेट होते हैं। बाद में मुझे पता चला कि 212 इमेज प्रोसेसिंग माइक्रोक्रिसिट का एक संस्करण है, और Leica M240 के दो संस्करण उत्पादन में गए। यह अध्ययन 212 संस्करण पर आधारित है।

सिस्टम प्रबंधन: CTRL_SYS-11.bin

सिस्टम नियंत्रण चिप के लिए केवल सामान्य हिस्सा फर्मवेयर है। यह वास्तव में एक बड़ा द्विआधारी है, और कोड आसानी से अनुमान लगा सकता है कि इसका क्या उद्देश्य है।

$ 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

इस प्रकार, हमारे पास Renesas SH7216 प्रोसेसर (SH-2A) है, जो लोडिंग के प्रारंभिक चरण, I / O परीक्षण और फर्मवेयर अपडेट के लिए जिम्मेदार है। बॉक्स से बाहर आईडीए इस प्रकार के प्रोसेसर का समर्थन करता है। यह केवल सही आधार लोड पता खोजने के लिए बना रहा, फर्मवेयर अनुभागों के विवरण से जाना जाता है: यह 0x0 ।

Section Name: "[A]CTRL_SYS-11"
Section offset: 14680064 | 0x00E00000
Section size: 917277 | 0x000DFF1D
Section base: 0 | 0x00000000

मैंने इसे आईडीए में लोड किया और सभी कार्यों को मान्यता दी, लेकिन मैंने विशेष रूप से इसमें खुदाई नहीं की, क्योंकि मुख्य प्रोसेसर का फर्मवेयर अधिक दिलचस्प है।

यहां यह भी ध्यान दिया जा सकता है कि इस चिप का UART सर्विस पोर्ट पर खुलता है, जहां यह डाउनलोड लॉग प्रदर्शित करता है। हम बाद में इस पर वापस आएंगे।

मुख्य चिप: IMG_LOKI-212.bin

इस फर्मवेयर की रिवर्स इंजीनियरिंग शुरू करने के लिए, आपको पहले कुछ सवालों के जवाब देने होंगे:

1. किस प्रकार का प्रोसेसर
   
2. आधार लोड पता क्या है
   
3. क्या ओएस पर आधारित है, यदि कोई हो

हमारे उपकरण के लिए धन्यवाद, हम पहले से ही आधार लोड का पता जानते हैं: यह 0x100000 ।

Section Name: "[A]IMG_LOKI-212"
Section offset: 0 | 0x00000000
Section size: 7340032 | 0x00700000
Section base: 1048576 | 0x00100000

फर्मवेयर शेष उत्तरों को पठनीय रूप में संग्रहीत करता है। उदाहरण के लिए, यह पंक्ति:

$ 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
...

इस प्रकार, हम एक कस्टम प्रोसेसर Fujitsu FR (Leica इसे Maestro कहते हैं) और ऑपरेटिंग सिस्टम Softune REALOS के साथ काम कर रहे हैं। वास्तव में, यह ब्लैकफिन की तुलना में बहुत बेहतर है, क्योंकि बॉक्स से बाहर आईडीए एफआर का समर्थन करता है।

FR प्रोसेसर मॉड्यूल

वास्तविकता इतनी उज्ज्वल नहीं थी, क्योंकि फर्मवेयर फ़ाइल डाउनलोड करने के बाद, आईडीए कार्यक्रम ने कोई निर्देश, बाहरी लिंक आदि नहीं दिखाए।

मैंने इसे ठीक करने का फैसला किया, लेकिन अंत में मुझे फर्मवेयर के कुछ हिस्सों को पूरी तरह से फिर से लिखना पड़ा। यहाँ परिणाम है:





ana , ins और out में सुधार के अलावा, एक पूरी तरह से नया emu कोड हो सकता है:

• डेटा के लिए विभिन्न प्रकार के कोड और बाहरी लिंक को पहचानना;
  
• स्विच स्टेटमेंट को पहचानें
  
• स्टैक ट्रेसिंग करें;
  
• अलग-अलग ढेर तर्क और स्थानीय चर
  
• कार्यों को सही ढंग से पहचानें।

लेकिन सबसे बड़ा बदलाव, जैसा कि आपने देखा, निर्देशों के लिए बड़े अक्षर हैं :)

निर्देशों का पूरा सेट देखना चाहते हैं? यहाँ यह है:

  ADD OR BTSTH LSR MOV BN LDRES EXTSH   
 ADD2 ORH MUL LSR2 JMP BP स्ट्रिप्स EXTUH   
 ADDC ORB मुलू ASR कॉल 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   
 और BEORL DIV4S ST BNE DMOV ADDSP लीव   
 ANDH BEORH LSL STH BC DMOVH EXTSB XCHB    
 ANDB BTSTL LSL2 STB BNC DMOVB EXTUB 

तो, सरल और सुंदर।

वैसे, आपने देखा होगा कि कुछ निर्देश संरेखित नहीं हैं:

  बीआरए: डी loc_xxx
     LDI: 8 # 0x64, R5 

यह प्रोसेसर मॉड्यूल में गलती नहीं है, लेकिन वास्तव में फुजित्सु एफआर परिवार की एक विशेषता है। इसे देरी स्लॉट कहा जाता है और यह RISC प्रोसेसर के लिए काफी विशिष्ट है।

FR80 प्रोसेसर मैनुअल से (ध्यान दें: लिंक अब काम नहीं करता है):

निर्देश, जो शाखा निर्देश के तुरंत बाद स्थित है (इसका स्थान "विलंब स्लॉट" कहा जाता है) शाखा से पहले निष्पादित किया जाता है, और लक्ष्य पते पर निर्देश शाखा के बाद निष्पादित किया जाता है। चूंकि देरी स्लॉट में निर्देश शाखा ऑपरेशन से पहले निष्पादित किया गया है, स्पष्ट निष्पादन गति 1 चक्र है।

इस प्रकार, यह, संक्षेप में, पाइपलाइन का अनुकूलन है, और इसे याद रखना बेहतर है, क्योंकि यह लीका फर्मवेयर में हर जगह उपयोग किया जाता है।

साफ्ट्यून REALOS

विकी से :

सॉफ्ट्यून Fujitsu FR, FR-V और F2MC प्रोसेसर परिवारों के लिए Fujitsu का एकीकृत विकास वातावरण है। REALOS RONITRON वास्तविक समय कर्नेल द्वारा संचालित। उदाहरण के लिए, इसका उपयोग Nikon DSLR कैमरों में (Nikon EXPEED देखें) और K के साथ कुछ Pentax कैमरे हैं।

तो यह एक बहुत ही लोकप्रिय सभ्य आरटीओएस है जिसमें कार्यों, सेमाफोर और अन्य उपहार हैं। मैं सोच रहा था कि क्या लीका फर्मवेयर में कुछ मानक पुस्तकालय कार्यों को पहचानना संभव है।

मुझे अध्ययन के पहले भाग को समय की एक बड़ी बर्बादी कहना है, और यहाँ क्यों है।

सॉफ्ट्यून आईडीई को ढूंढना बहुत मुश्किल था, लेकिन अंत में मैं कुछ पाने में कामयाब रहा। जैसा कि अपेक्षित था, आईडीई में पुस्तकालय शामिल थे। चार बायनेरिज़ थे:

• lib911.lib
  
• lib911e.lib
  
• lib911if.lib
  
• lib911p.lib

मुझे नहीं पता कि हो सकता है, शायद जड़ता से, जैसा कि मैंने लीका से जुड़ी हर चीज को हैक कर लिया था, मैंने फिर से प्रारूप की रिवर्स इंजीनियरिंग शुरू कर दी। हां, एक बहुत अच्छी तरह से प्रलेखित ऑब्जेक्ट मॉड्यूल प्रारूप । और हां, निश्चित रूप से, मैंने इसके लिए एक विशेष उपकरण लिखा है :

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

इसका उपयोग करके, आप *.pat फ़ाइलें बना सकते हैं और हस्ताक्षर फ़ाइलों को बनाने के लिए IDA FLAIR में इनपुट के रूप में उनका उपयोग कर सकते हैं।

$ 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

इस हस्ताक्षर को लागू करने के बाद, मैंने अंततः IMG_LOKI-212.idb में पत्राचार को खुशी से देखा।

ख़ाका

फर्मवेयर में लाइनों की संख्या तुरंत ध्यान आकर्षित करती है। कई कार्यों को उनकी कार्यक्षमता के लिए नामित किया गया है। सामान्य पैटर्न को समझने के लिए रिवर्स इंजीनियरिंग प्रक्रिया में यह बहुत उपयोगी है।

यह भी ध्यान रखना महत्वपूर्ण है कि फर्मवेयर फ़ाइल के कुछ हिस्सों को रीसेट हैंडलर में एक अलग पते पर कॉपी किया जाता है। उदाहरण के लिए, रनटाइम पर अंतर्निहित लोडर रैम में अधिक चलता है।

मुझे अतिरिक्त अनुभागों को मैन्युअल रूप से बनाना था, परिणामस्वरूप, मुझे निम्नलिखित लेआउट मिला:

बीच में आता है

टीबीआर (टेबल बेस रजिस्टर) तक पहुंचकर रुकावट वाले वैक्टर की तालिका पाई जा सकती है:

LDI:32 #int_table, R0
MOV R0, TBR

आमतौर पर यह फर्मवेयर की शुरुआत में वेक्टर रीसेट हैंडलर में होता है।

तालिका में हैंडलर के पते को फॉर्मूला TBR + (0x3FC - 4 × inum) अनुसार रिवर्स ऑर्डर में संग्रहित किया जाता है, इसलिए तालिका के अंत में रीसेट वेक्टर ऑफसेट 0x3FC ।

मैंने FR मैनुअल से अधिकांश रुकावटें पाईं और सुझाव दिया कि Leica Maestro का लेआउट समान है। फिर उन्होंने प्रत्येक हैंडलर लिया और एक स्ट्रिंग या किसी अन्य संकेत को खोजने की कोशिश की जो रुकावट के उद्देश्य को प्रकट करता है।

परिणामस्वरूप, मैंने यह सूची बनाई:



कई व्यवधान काफी अपेक्षित हैं, जैसे कि ऑडियो / एसडीआईओ / वीडियो / जेपीईजी / रॉ, लेकिन उनमें से सबसे रहस्यमय की पहचान करने की कोशिश करें? मैं int_uart_in बाधित करने के बारे में बात कर रहा int_uart_in । ऐसा लगता है कि कैमरा कुछ प्रकार के कंसोल मोड UART CLI का समर्थन करता है।

सिस्टम कॉल

लगभग किसी भी OS की तरह, सॉफ्टलाइन REALOS सिस्टम कॉल का उपयोग करता है। कोडांतरक में, वे इस तरह दिखते हैं:



सिस्टम कॉल हैंडलर के वास्तविक पते की गणना निम्नानुसार की जाती है। आइए INT #0x40 इंटरप्ट हैंडलर की तलाश शुरू करें। जैसा कि ऊपर वर्णित है, यह

(0x3FC - 4 × inum) = (0x3FC - 4 × 0x40) = 0x2FC = int_realos_syscall

हैंडलर में, 16-बिट शब्दों के साथ सिस्टम कॉल टेबल के नीचे एक लिंक ढूंढना आसान है। इस तालिका में विशिष्ट रिकॉर्ड सूत्र syscall_table_bottom + (num * 2) द्वारा गणना की गई है:

[syscall_table_bottom + (-23 * 2)] = [syscall_table_bottom - 0x2E] = [0x1012EA] = 0xE68

यह एक पते की तरह नहीं दिखता है, क्योंकि सिस्टम कॉल हैंडलर के वास्तविक पते की गणना syscall_table_bottom + offset रूप में की जाती है। पूरी प्रक्रिया को आरेख में दिखाया गया है।



सभी सिस्टम कॉल और उनकी कार्यक्षमता को सॉफ्टलाइन आरईएलओएस / एफआर कर्नेल मैनुअल में इंगित किया गया है , इसलिए मैं तालिका में सभी कार्यान्वित हैंडलर को पुनर्स्थापित करने और आईडीबी को थोड़ा और सुधारने में सक्षम था।



बेशक, आप आईडीए में सिस्टम कॉल के प्रकारों को परिभाषित करके कोड को और अधिक सुंदर बना सकते हैं।



मैंने इन सिस्टम कॉल और अधिक के लिए स्वचालित रूप से खोज करने के लिए एक पायथन स्क्रिप्ट लिखी थी।

कार्य

sta_tsk सिस्टम कॉल में sta_tsk मैंने देखा कि मुख्य फ़ंक्शन को पैरामीटर के रूप में पारित नहीं किया गया है, लेकिन पीआईडी। इसका मतलब यह है कि यह कार्य विवरणकों के एक बड़े सरणी को देखने का समय है। और यह sta_tsk साथ शुरू करने के लिए समझ में आता है।

  ROM: 102180 sys_sta_tsk:
 ROM: 102180 ST RP, @ -R15
 ROM: 102182 LDUB @ (R14, 0x4F), R3
 ROM: 102184 LDI: 32 # word_100B80, R14 

बहुत शुरुआत में हम कुछ लिंक देखते हैं। मुझे डेटा प्रकारों के साथ थोड़ा छेड़छाड़ करना था, लेकिन अंत में टुकड़े एक साथ आए:

  ROM: 100B80 word_100B80: .word 0xF;  कार्यों की संख्या
 ROM: 100B82 .word 0x1C;  कार्य विवरणक आकार

 ROM: 100B84 .long 0x82A09F5C;  कार्य 1 विवरणक
 ROM: 100B88 .long 0x1000D
 ROM: 100B8C। 0 को
 रॉम: 100B90। 0x40000000 लंबा
 ROM: 100B94। लंबा उप_1A7DB2;  मुख्य कार्य
 ROM: 100B98 .long 0x8286EEC0
 ROM: 100B9C। लंबे 0

 ROM: 100BA0। लंबे 0x82A09F88;  कार्य 2 विवरणक
 ROM: 100BA4 .long 0x20010
 रोम: 100BA8। 0 0
 ROM: 100BAC .long 0x40000000
 ROM: 100BB0। लंबे उप_1A6BD2;  मुख्य कार्य
 ROM: 100BB4 .long 0x8287EEC0
 रॉम: 100BB8। लंबा 0
 ... 

और इसी तरह। केवल 15 कार्य। प्रत्येक मुख्य कार्य को देखना, कार्य का नाम और उद्देश्य निर्धारित करना (अंतिम को छोड़कर) समय की बात थी। यहाँ पूरी सूची है:

1. SubCPU
   यह कार्य जाहिरा तौर पर कैप्चर ऑपरेशंस जैसे एक्सपोज़र, ऑन-स्क्रीन दृष्टि, आदि के लिए जिम्मेदार है।
   
2. KeyManager
   सबसे अधिक संभावना है, यह कार्य हार्डवेयर बटन के साथ जुड़ा हुआ है।
   
3. GuiManager
   काफी बड़ा काम, जिसमें यूआई स्टेट मशीन और इंटरफ़ेस रेंडरिंग को लागू किया गया है।
   
4. DebugManager
   हां, डिबग करने के लिए कुछ है। यम यम।
   
5. FileManager
   यह कार्य फ़ाइल संचालन के बारे में है।
   
6. FamManager
   मैं कहूंगा कि यह कार्य फाइलों और मेमोरी के लिए जिम्मेदार है, क्योंकि यह फाइल मैनेजर और मेमोरी मैनेजर के कार्यों पर निर्भर करता है।
   
7. MemoryManager
   कोई आश्चर्य नहीं: स्मृति संचालन, पूल प्रबंधन, आदि।
   
8. ImageManager
   यह कार्य एन्कोडिंग / डिकोडिंग प्रक्रियाओं और अन्य छवि प्रसंस्करण प्रक्रियाओं का प्रबंधन करता है।
   
9. UsbManager
   वर्तमान चुनौती USB संचार प्रसंस्करण है, जिसमें MassStorage, PTP और Leica का अपना प्रोटोकॉल शामिल है।
   
10. IOManager
    यह कार्य एसडी और सीएफ कार्ड (क्या? अन्य सीएफ? शायद यह मॉडल 213 से है) जैसे भंडारण उपकरणों का प्रबंधन करता है।
    
11. Systemmanager
    सामान्य कार्य संचालन, बिजली प्रबंधन आदि जैसे विभिन्न कार्य।
    
12. सेटिंग प्रबंधक
    कैमरा स्थिति और सेटिंग्स को संभालता है।
    
13. MonitorManager
    कैमरा स्थिति को बदलता है और अन्य कार्यों को सूचित करता है।
    
14. PeripheralManager
    यह कार्य जीपीएस, चमक और कुछ अन्य सेंसर को नियंत्रित करता है।
    
15. अज्ञात
    दुर्भाग्य से, मुझे उसके लिए कुछ भी महत्वपूर्ण नहीं लगा।

यह ध्यान रखना दिलचस्प है कि मुख्य सरणी के बाद एक और बकाया विवरणक है।

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

और कार्य का कार्य केवल स्वयं शाखा है।

ROM:101494 sub_101494:
ROM:101494 BRA sub_101494 ; CODE XREF: sub_101494

इस डिस्क्रिप्टर को start फ़ंक्शन के अंत में संदर्भित किया जाता है, जो अन्य कार्यों को बनाने और फर्मवेयर स्थापित करने के लिए जिम्मेदार है। तो यह प्रणाली निष्क्रियता का कार्य है।

मॉड्यूल और संदेश

कार्यों के अलावा, आप कुछ तार्किक वस्तुओं को परिभाषित कर सकते हैं, जैसे कि IO और परिधीय मॉड्यूल। कार्य के एक हिस्से के रूप में मॉड्यूल संदेश संचालकों के समूह के रूप में प्रस्तुत किए जाते हैं।

IO समूह में शामिल लगता है:

• आईओ मैनेजर
• उप-प्रोसेसर
• USB प्रबंधक
• USB PTP
• यूएसबी लीका प्रोटोकॉल
• USB मास स्टोरेज
• बटन प्रबंधक
• डिबग प्रबंधक
• लेंस प्रबंधक

और परिधीय समूह में:

• परिधीय प्रबंधक
• प्रकाश संवेदक
• एल ई डी
• वक्ता
• झुकाव सेंसर
• टोपी बंद पहचान
• जीपीएस मॉड्यूल
• 3DAxis मॉड्यूल

मैसेजिंग सिस्टम स्वयं मानक SOFTUNE संरचनाओं का उपयोग करता है:

 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 } 

जैसी कि उम्मीद थी, आईपीसी में कई संदेश समूह भी हैं। चूंकि कई संदेश कार्यों और मॉड्यूल में संसाधित होते हैं, इसलिए मैं इनमें से कुछ समूहों को ही पुनर्प्राप्त करने में सक्षम था:

  0x1101xxxx - वैश्विक सिस्टम संदेश:
              0x11010002 = SYS_UPDATE_BOOTLOADER या
              0x11010005 = SYS_ERASE_SETTINGS
 0x1102xxxx - छवि कैप्चर से संबंधित संदेश:
              0x11020001 = CMD_CAP_CAPTURE या
              0x11020008 = IMAGE_STATUS_CHANGED  
 0x1104xxxx - प्लेबैक से संबंधित घटनाओं के बारे में संदेश:  
             0x11040002 = PLY_DISABLE_PLAY_MODE 
             0x11040004 = PLY_IMAGE_READY  
0x1108xxxx -     PTP  .:
             0x11080002 = DBG_CHANGE_LEVEL 
             0x11080012 = DBG_WRITE_ROM_DUMP_SD  
0x2201xxxx -  USB PTP
             0x22010108 =    
             0x22010118 =  DebugObject  
0x2202xxxx -     SUBCPU:
             0x22020002 = E_SUBCPU_REQUEST_M_EXPOSURE_REQUEST  
             0x22020015 = E_IO_SUBCPU_COMMAND_CLEANING_SENSOR  
0x2203xxxx -    :
             0x22030001 =   
0x2204xxxx -   IO:
             0x2204000C = / Mass Storage 
             0x22040012 =    
0x330000xx -     UI:
             0x33000001 =  
             0x33000007 =  
0x440000xx -   ,     
             0x44000013 = E_IMG_CMD_CHANGE_PINFO  
0x55xxxxxx —   FAM:  
             0x558800xx = - FAM 
             0x558888xx =     FAM
0x6602xxxx —     LED, :
             0x66020001 -  LED  X 
             0x66020002 =   LED  
0x6604xxxx -  :
             0x66040001 =  
             0x66040007 =    
0x6611xxxx -  ,   
0x6622xxxx -   ,   
0x6660xxxx - मेमोरी से संबंधित कुछ अन्य संदेश:
             0x66600006 = HISTOGRAM  
             0x66600011 = RAWCOMP  
0x771100xx और 0x77AA00xx - स्विचिंग कैमरा मोड से संबंधित संदेश 

दुर्भाग्य से, कई अन्य पोस्ट अज्ञात बने हुए हैं।

जीयूआई

फर्मवेयर फ़ाइल में, हम निम्नलिखित वर्गों को भी देखेंगे: CTRL_SYS-11 , IMG-LOKI-212 , IMG-DSP-212 , IMG-FPGA-212 और IMG-LENSDATA-212 ।

मुझे आश्चर्य हुआ कि GUI संसाधनों का पूर्ण अभाव था। लेकिन वे कहीं और होना चाहिए, सबसे अधिक संभावना है, IMG-LOKI-212 में निर्मित हैं ।

फ़र्मवेयर विकास के लिए मेरे सामान्य दृष्टिकोणों में से एक है सभी संभावित क्रॉस-रेफरेंस को पुनर्स्थापित करना। न केवल कोड में, बल्कि डेटा अनुभाग में भी। फिर मैं उनके माध्यम से देखता हूं, कोड के कुछ हिस्सों के कुछ पैटर्न या लिंक खोजने की कोशिश कर रहा हूं।

Leica फर्मवेयर कोई अपवाद नहीं था। अन्य डेटा अनुक्रमों के पते के साथ कई समान डेटा अनुक्रम हैं जो आगे बढ़ते हैं, आदि। जैसा कि मैंने लिंक के पदानुक्रम पर चढ़ा, मैंने आखिरकार एक परिचित फ़ंक्शन देखा।

उदाहरण के लिए, मुझे बिना किसी लिंक के डेटा संरचना मिली:

 g_data = { ... } 

एक अन्य संरचना ने इसे संबोधित किया:

 g_data_struct1 = { ... , &g_data } 

बदले में किसे दूसरी संरचना द्वारा संदर्भित किया जाता है:

 g_data_struct2 = { &g_data, ... } 

इस डेटा संरचना में कोड से एक लिंक है, और इसे दूसरे फ़ंक्शन के पैरामीटर के रूप में पास किया जाता है:

 func1() ╰ func2(..., &g_data_struct2, ...) 

हालाँकि, func1()इसे सीधे किसी अन्य फ़ंक्शन से नहीं कहा जाता है, लेकिन कुछ सरणी में संग्रहीत किया जाता है:

 g_func_list1[] = { ..., func1(), ... } 

ऊपर देखते हुए, मुझे कोड में एक कॉल मिली g_func_list1:

 func3() { g_func_list1[x] } 

और फिर, यह फ़ंक्शन एक सरणी में संग्रहीत है:

 g_func_list2[] = { ..., func3(), ... } 

कुछ अन्य कोड स्वयं ऐरे को एक्सेस करते हैं:

 func4() { g_func_list2[x] } 

सौभाग्य से, इस समय फ़ंक्शन को दूसरे फ़ंक्शन से बुलाया जाता है, और इसी तरह gui_MADE_ApplicationRun।

 gui_Statemachine_DoStateChange() ╰ gui_MADE_ApplicationRun() ╰ func5() ╰ func4() 

कुछ पंक्तियों से संकेत मिलता है कि GUI सबसिस्टम को "MADE" कहा जाता है, और MADE_GetSysTriजो कुछ भी मतलब है , उसका उपयोग करके पृष्ठ संक्रमण को नियंत्रित किया जाता है। GUI राज्य मशीन मूल रूप से एक फ़ंक्शन में कार्यान्वित की जाती है gui_Statemachine_DoStateChange। जीयूआई के बारे में जानकारी एकत्र करने के बाद, सामान्य तस्वीर उभरी:



जैसा कि आप देख सकते हैं, जीयूआई संसाधनों के लिए मुख्य कार्य है gui_CopyImageDesc(हालांकि यह एक वास्तविक नाम नहीं है)। उसके पास निम्न तर्क हैं:

 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 ) 

संसाधन विवरण चार प्रकार के होते हैं:

 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; } 

पहले प्रकार में अभिलेखों के एक सरणी के संदर्भ में एक हेडर होता है। प्रत्येक रिकॉर्ड में निर्देशांक और पिक्सेल डेटा के लिए एक पता होता है। वर्तमान प्रकार राज्य-निर्भर तत्वों का वर्णन करने के लिए लगता है, जैसे कि आइकन, जो UI से ग्रे हो सकते हैं या गायब हो सकते हैं।

दूसरा प्रकार भी एक हेडिंग के साथ शुरू होता है और इसका उपयोग स्थानीयकरण, लाइनों या पाठ के ब्लॉक का वर्णन करने के लिए किया जाता है।

तीसरा प्रकार विभिन्न भाषाओं के लिए चरित्र मानचित्रों का वर्णन करता है।

बाद का प्रकार अन्य सभी स्थिर संसाधनों के लिए जिम्मेदार है, जैसे कि चित्र, पृष्ठभूमि, आदि।

अब आइए छवियों के लिए डेटा पर एक नज़र डालें। पहले छह बाइट्स एक छोटे हेडर की तरह दिखते हैं, इसके बाद किसी प्रकार का दोहराव पैटर्न होता है, जहां हर दूसरा बाइट या तो होता है , या । ऐसा नहीं है कि ग्रहण करने के लिए तार्किक है और

+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

0xFF0x040x00080x0014- प्रत्यक्ष बाइट ऑर्डर (बड़ा एंडियन) के साथ एक दृश्य में चौड़ाई और ऊंचाई। इस डंप के अंत में, हम एक और अनुक्रम की शुरुआत देखते हैं 00 06 00 14 00 01। सबसे अधिक संभावना है, यह अगला संसाधन है (जैसा कि इसके लिंक द्वारा पुष्टि की गई है)। इस प्रकार, वास्तविक छवि डेटा का आकार 146 बाइट्स है। लेकिन छवि का आकार 0x8 * 0x14 = 0xA0 = 160 होना चाहिए। यह स्पष्ट है कि डेटा शुद्ध पिक्सेल नहीं है और 8-बिट LUT भी नहीं है, क्योंकि यह 14 बाइट्स छोटा है। फिर क्या?सम्भवतः किसी प्रकार का संपीडन।

इस हेक्साडेसिमल डंप को देखते हुए, यह विश्वास करना मुश्किल है कि किसी प्रकार की जटिल योजना का उपयोग किया जाता है। लेईको की GUI बहुत रंगीन नहीं है, इसलिए मेरे अनुभव में यहाँ LUT तालिका का उपयोग करना सबसे अच्छा है। इस स्थिति में, UI संसाधन LUT सूचकांकों को पूरी तरह से दोहराएंगे 03 03 03या जैसे 1 1 1। आमतौर पर, कंप्रेसर डेटा दोहराव से छुटकारा पाने की कोशिश करता है, उन्हें एक लिंक के साथ बदल देता है। ये सूचकांक सरणियाँ RLE जैसी सरल विधि के साथ भी संपीड़न के लिए आदर्श हैं [data][number]। लिखने का एक साधारण आदेश data(मान) numberबार।

इस सब को ध्यान में रखते हुए, मैंने सुझाव दिया कि हम दो एलयूटी रंगों ( 0xFFऔर 0x04) के साथ एक साधारण छवि को देख रहे हैं , और रंग के सामने बाइट खींचने के लिए पिक्सेल की संख्या है।

"और फिर आपने एक और उपकरण लिखा," आपको लगता है। लेकिन नहीं, मैंने एक कलम और कागज लिया और कोशिकाओं में भरना शुरू कर दिया। यह हास्यास्पद है कि मेरे पास अभी भी वह तस्वीर है।



कहीं न कहीं, मैंने महसूस किया कि 160 पिक्सेल इस छवि के लिए पर्याप्त नहीं हैं, इसलिए 0x8 और 0x14 को दो से गुणा करने की आवश्यकता है। तीसरा शब्द 0x0001 इंगित करता है कि क्या छवि एक ASCII वर्ण है, इसलिए अंतिम ImageAsset संरचना निम्नानुसार है:

 struct ImageAsset { uint16_t width; // /2 (big endian) uint16_t height; // /2 (big endian) uint16_t ascii; // 1,   ASCII struct image_data { uint8_t number; //     uint8_t color; //     LUT } data[]; } 

लेकिन एक हिस्सा अभी भी गायब है: LUT।

यह खोजना इतना मुश्किल नहीं था, क्योंकि कई लिंक और संरचनाएं पहले से ही मैन्युअल रूप से बहाल की गई थीं, इसलिए मैंने धीरे-धीरे डेटा अनुभागों के माध्यम से स्क्रॉल किया, 16-बिट या 32-बिट मानों में से 256 तत्वों की एक सरणी की तलाश में, जब तक मैं इस पार नहीं आया: फिर से, धन्यवाद के साथ अपने काम में Blackmagic Design, मैं तुरंत YUV पिक्सल (उदाहरण के लिए, 8080 संख्या के साथ सभी मूल्यों) को मान्यता दी। मैं फिर से कागज पर मैन्युअल रूप से पूरे उपयोगकर्ता इंटरफ़ेस को आकर्षित करने के लिए मूर्ख नहीं हूं, इसलिए हां, मैंने एक और उपकरण - M240UITool लिखा है । फर्मवेयर फ़ाइल से बीएमपी / पीएनजी तक सभी छवि संसाधनों को रीसेट करने के अलावा, यह उपकरण सभी यूआई संसाधनों को निर्धारित करने के लिए आईडीए में आईडीसी स्क्रिप्ट बना सकता है।

.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





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



हम पहले से ही जानते हैं कि एक यूआई पेज बनाने वाले फ़ंक्शन से, इसे कई बार कहा जाता है gui_CopyImageDesc। मुझे लगा कि UI संसाधन ब्राउज़र बनाने और सभी पेज रेंडरिंग विशेषताओं को परिभाषित करने के लिए बहुत अच्छा होगा। इसके लिए विकल्प -cका इरादा है - यह संसाधनों को देखने के लिए एक विशेष कंटेनर बनाता है।

और किसने कहा कि यूआई संसाधन ब्राउज़र असामान्य नहीं लग सकता है?



इंटरैक्टिव (स्क्रीनशॉट पर पारभासी बटन) होने के नाते, यह उपकरण आपको ईवीएफ / एलसीडी मेनू के पृष्ठों के माध्यम से न केवल स्क्रॉल करने की अनुमति देता है, बल्कि एक पृष्ठ के भीतर रेंडरिंग चरणों को भी देखता है।

दुर्भाग्य से, इस कृति के लिए स्रोत कोड कहीं खो गया था, लेकिन हेडर फाइलें अभी भी M240UITool कोड में हैं, इसलिए तकनीकी रूप से आप इसे स्क्रैच से फिर से बना सकते हैं।

डिबग मेनू

रिवर्स इंजीनियरिंग के दौरान हम मुख्य रूप से किस लाइन की तलाश कर रहे हैं? मेरी राय में, यह शब्द debugऔर इसका व्युत्पत्ति।

फर्मवेयर में बहुत सारी दिलचस्प लाइनें थीं, लेकिन ये विशेष हैं: ऐसा लगता है कि आप चाबियों के कुछ संयोजन का उपयोग करके डिबग मोड में प्रवेश कर सकते हैं। इन सभी लाइनों को एक विशाल फ़ंक्शन से बुलाया जाता है , जो एक बटन स्कैन स्टेट मशीन को लागू करता है। यहाँ यह आईडीए में कैसा दिखता है:

$ 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

ScanningForDebugWithKeyAndJoyStick



मैं झूठ नहीं बोलूंगा, यह समझने में कुछ समय लगा कि हार्डवेयर बटन फर्मवेयर में कैसे संसाधित होते हैं, और फिर बटन और जॉयस्टिक के लिए एन्यूमरेटेड प्रकारों को पुनर्स्थापित करें। लेकिन जब मुझे कॉम्बिनेशन मिला, तो मुझे चिराग के साथ पता चला कि वह कुछ नहीं कर रही है। यह शायद केवल एक विशिष्ट GUI पृष्ठ से काम करता है। जीयूआई राज्य मशीन के मैनुअल ट्रेसिंग के कुछ और शाम - और समस्या हल हो गई है, और हम रिज्यूमे मेनू पेज को खोजने में भी कामयाब रहे।

अंत में, डिबग मोड में आपका स्वागत है।



मैंने बहुत सोचा कि क्या इस संयोजन की घोषणा की जाए, लेकिन इसे बंद करने का फैसला किया गया। मैं अपने अद्वितीय उपकरणों को जारी करने के लिए लीका द्वारा की गई कड़ी मेहनत का सम्मान करता हूं, और मैं इस तथ्य के लिए जिम्मेदार नहीं होना चाहता हूं कि उनके सेवा केंद्र कुछ विचारहीन जिज्ञासा के परिणामस्वरूप कैमरों के टूटे हुए शवों को भर देंगे।

लेकिन फिर भी, मैं इस तरह से जाने के लिए तैयार लोगों के लिए रिवर्स इंजीनियरिंग को सरल बनाने के लिए कुछ प्रगणित प्रकार प्रदान करूँगा।

 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 }; 

PTP

USB कार्य के बारे में सोचकर, मैंने तीन मोड परिभाषित किए (जो डीबग मेनू में भी पुष्टि की गई है):

• PTP
  
• एमएससी (मास स्टोरेज क्लास)
  
• लइका प्रथा

PTP सबसे दिलचस्प है क्योंकि यह अच्छी तरह से प्रलेखित है और आपको कैमरे को नियंत्रित करने की अनुमति देता है।

फर्मवेयर में PTP हैंडलर ढूंढना काफी आसान है, क्योंकि इस कोड से बहुत सारे कॉल आते हैं। सभी पीटीपी कॉल को तीन समूहों में विभाजित किया गया है: लिगेसी , लेइका एक्सटेंडेड (एलई) और प्रोडक्शन ।

डिबगिंग संदेशों ने लगभग सभी कोड के लिए नाम स्थापित करने में मदद की।

 विरासत: लीका एक्सटेंडेड: उत्पादन:                           
0x1001 - GetDeviceInfo 0x9001 - कैमरा सेटिंग सेट करें 0x9100 - उत्पादन सत्र खोलें      
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 

PTP इंटरफ़ेस का कार्यान्वयन स्वयं मानक लगता है, लेकिन कुछ आदेशों की सीमाएँ हैं जो मैं जानबूझकर यहाँ छोड़ देता हूं।

किसी भी मामले में, उपरोक्त सभी काफी रोमांचक है। आप सोच सकते हैं, "चलो बस USB के माध्यम से कैमरे में प्लग करें और libptp के साथ जांच शुरू करें।" यह सही है।

धिक्कार है ...

Leica M240 में USB पोर्ट नहीं है।

बंदरगाह को संभालें

Leica इस कैमरे के लिए कुछ सामान प्रदान करता है, लेकिन एक विशेष रूप से दिलचस्प है। हम मल्टी-फंक्शन हैंडल Leica M (14495) के बारे में बात कर रहे हैं । यह मामले के निचले धातु भाग को बदल देता है, बिल्ट-इन जीपीएस और कई कनेक्टर जैसे यूएसबी, एक एससीए फ्लैश टर्मिनल, डीआईएन / आईएसओ-एक्स और एक पावर सॉकेट प्रदान करता है।



और आप फिर से कहते हैं: "महान, अब इसे खरीदें, इसे कैमरे से संलग्न करें, कैमरे को यूएसबी के माध्यम से कनेक्ट करें और परिवाद के लिए जांच शुरू करें।" यह सही है।

केवल यह लानत है ...

इसकी लागत लगभग 900 डॉलर है।

अपने स्वयं के एडेप्टर बनाने के लिए यह लगभग नौ सौ कारण हैं। हालाँकि, केवल मामले में, मैंने इस एक्सेसरी के लिए ईबे नोटिफिकेशन की स्थापना की।

योजक

कैमरे पर कनेक्टर निम्नानुसार है:



मैंने इसे इंटरनेट पर खोजने की कोशिश की, लेकिन गंभीरता से, आप Google पर इसका वर्णन कैसे करेंगे?

थोड़ा हताश होकर, मैंने कुछ पागल चीजों के बारे में सोचना शुरू कर दिया, जैसे कि पन्नी या सुइयों को रबड़ के रबड़ से चिपकाना। लेकिन एक बार काम पर Blackmagic Design, कैमरा सर्किट बोर्ड को देख, मैंने देखा कि कनेक्टर्स में से एक का एक बहुत ही परिचित आकार था। अगले दिन मैं काम करने के लिए अपनी लीका M240 लाया - और हाँ, यह समान दिखता था, बस बहुत सारे पैड के साथ।

यह हमारे घटक प्रबंधक की भाग संख्या पूछने के लिए बनी हुई है, और फिर इसे सैमटेक सूची में पाया गया है: ERM8-013-05.0-L-DV-TR ।



हमने सैमटेक से यह भी पूछा कि क्या सैंपल लेना संभव था, और वे सहम गए।



टांका लगाने वाले लोहे, कार्डबोर्ड और बिजली के टेप के साथ थोड़ा काम - और मेरा अपना प्लग तैयार है (2013 का नमूना)।



पांच साल बाद, 2018 में, मैंने सैमटेक को एक और नमूना भेजने के लिए व्यक्तिगत रूप से पूछने का फैसला किया। मैं कुछ बेहतर करना चाहता था।

ERCD-013-05.00-TTR-TTR-1-D


फिर से, एक टांका लगाने वाले लोहे के साथ बहुत सारे काम, कसम खाना , तार काटना, कसम खाना, फिर से टांका लगाने वाले लोहे के साथ काम करके एक नया, अधिक आकर्षक विकल्प बनाना ...

pinout

कनेक्टर में 26 संपर्क हैं: प्रत्येक तरफ 13। अपने हिस्से को सोल्डर करने से पहले ही, मैंने मल्टीमीटर और लॉजिक एनालाइजर के साथ कैमरा कनेक्टर की जांच की। वैसे, आपको नीचे कवर सेंसर पर एक चुंबक लगाने की जरूरत है ताकि कैमरा समझता है कि कवर जगह में है।

पृथ्वी (कैमरा बंद, कोई बैटरी नहीं)

मैं हमेशा जमीन से शुरू करता हूं क्योंकि यह सुरक्षित और खोजने में बहुत आसान है।



इस प्रकार, हमारे पास आठ जमीनी रेखाएं (गहरे भूरे) हैं।

संभावित (कैमरा पर)

जब कैमरा चालू होता है, तो आप प्रत्येक पिन पर क्षमता को माप सकते हैं और तर्क और शक्ति के स्तर का अंदाजा लगा सकते हैं।

alexhude.imtqy.com/assets/2019/2019-01-24-hacking-leica-m240/probe2_potential.png

पिन 8-8 और 11–13 पर प्रदर्शन लॉजिक पिन के लिए बहुत अधिक है, इसलिए मैंने उन्हें शक्ति (लाल) के रूप में परिभाषित किया।

प्रतिरोध (कैमरा बंद, कोई बैटरी नहीं)

यह प्रतिरोध को मापने के लिए उपयोगी है। कुछ मामलों में, यह इनपुट की पहचान करने और कुछ लाइनों को समूह बनाने में मदद करता है।



कनेक्टेड आउटपुट (कैमरा बंद हो गया, कोई बैटरी नहीं)

फिर मैंने कैमरा बॉडी के सभी बाहरी पैड्स को चेक करने का निर्णय लिया कि वे सर्विस पोर्ट से जुड़े हैं या नहीं।



फ़्लैश सिंक संपर्क सीधे लाइन 10 से जुड़ा था।

लॉजिक एनालाइज़र (कैमरा चालू)

प्रत्येक लाइन के लिए डेटा निम्न क्रम में दर्ज किया गया था: चालू करें, कैमरा एलवी मोड में होना चाहिए, एक तस्वीर लेनी चाहिए, वीडियो रिकॉर्डिंग शुरू करनी चाहिए।



दो लाइनें कुछ डेटा के प्रसारण को दिखाती हैं: 01 और 21.

01 - 115200, 8 बिट्स का ट्रांसमिशन, 1 स्टॉप बिट, पैरिटी बिट, एलएसबी पहले।



प्रत्येक 500 एमएस, यह एक काउंटर भेजता है 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 बिट्स का संचरण, 1 स्टॉप बिट, कोई समता चेक बिट, एलएसबी पहले।



यह बूटलोडर लॉग को SH7216 ("लेइका कैमरा एजी" ऊपर के स्क्रीनशॉट में) भेजता है।

चलो उन्हें गहरे नीले रंग का निशान दें। यह बहुत दुख की बात है कि डेब्यू मेनू में अधिकतम डिबगिंग सेटिंग्स के साथ भी मेस्ट्रो लॉग बाहर नहीं जाता है।



इन संपर्कों पर, प्रतिरोध 310kOhm है।

मुझे पता नहीं क्यों, लेकिन मैंने सुझाव दिया कि अन्य डेटा लाइनों में समान प्रतिरोध हो सकता है या बंद हो जाएगा। इसलिए, मैंने लाइनों को परिभाषित किया ~ ~ 300kOhm, ~ 200kOhm, और ~ 100kOhm को डेटा लाइनों (चित्र में नीले रंग के शेड) के रूप में।

सामान्य तौर पर, निम्नलिखित चित्र खींचा गया था।



डेटा लाइन पर 12 उम्मीदवार। लेकिन उन्हें कैसे जांचना है? एकीकृत सर्किट की विद्युत सुरक्षा के बारे में लोहे के विशेषज्ञों के साथ एक छोटी सी बातचीत के बाद, मैंने 4kOhm रोकनेवाला के माध्यम से संपर्कों को रोकना शुरू कर दिया, जो वर्तमान को एक स्तर तक कम कर देता है कि इनपुट को जला नहीं जाना चाहिए।

UART

मैंने एक और धारणा बनाई कि आरएक्स लाइन TX के पास होनी चाहिए। लाइन्स 02, 03 और 20 अच्छे उम्मीदवारों की तरह दिखते हैं क्योंकि दोनों में TX की तरह 3.3 V का वोल्टेज है।

प्रारंभ में, मैंने बस पाइरेट का उपयोग करके इन पंक्तियों का पता लगाने की कोशिश की। दुर्भाग्य से, परिणाम बल्कि गंदा था। तब मैंने MacL पर SiLabs- आधारित केबलों को अधिक विश्वसनीय और गैर-परस्पर विरोधी के रूप में लिया।

सबसे पहले, मैंने TX केबल को 20 पिन करने के लिए कनेक्ट किया और helpबूटलोडर के बाद टाइप करना शुरू कर दिया । जैसा कि अपेक्षित था, थोड़े विलंब के बाद, कैमरे ने पात्रों को दोहराया।



संपर्क 02 और 03 UART के लिए अगले उम्मीदवार थे। दुर्भाग्य से, कोई संकेत नहीं थे कि ये लाइनें टैप की जा रही थीं।

आरेख में, प्रसिद्ध UARTs हरे रंग की एक गहरा छाया द्वारा इंगित किए जाते हैं।

यूएसबी

यह सब बीच में एक हेडर के साथ आधे में एक यूएसबी केबल काटने और संवेदन के लिए 4kOhm प्रतिरोधों के साथ शुरू हुआ। एक अंतर जोड़ी की संकेत अखंडता? नहीं, तो मुझे वास्तव में परवाह नहीं थी। :)



तब मैंने घर पर कई यूएसबी होम डिवाइसों की जांच की, ताकि यह अंदाजा लगाया जा सके कि इस पोर्ट पर संचार कैसा दिखता है।

कैनन


कैमरा Blackmagic पॉकेट


कैमकॉर्डर कैनन कैमकॉर्डर कैनन


कैमकॉर्ड


किचेन


किडज़ूम कैमरा


वे सभी थोड़े अलग हैं, लेकिन प्रारंभिक डी-डी + राज्य कम है। ठीक है, हम जानेंगे, और अब हम जाँचेंगे कि हमारे पास क्या है:

• 22 - संभावना नहीं है, क्योंकि डी-डी + एक अंतर जोड़ी है और काफी करीब होना चाहिए;
  
• 04/05 - इसकी संभावना नहीं है क्योंकि उनके पास अलग प्रतिरोध है;
  
• 14/15 — , ;
  
• 15/16 — , .

इसलिए मैंने USB D-D + को 15/16 पिन से कनेक्ट किया और इसे iMac ...



USB PTP स्क्रीन पर कनेक्ट किया , लेकिन कैमरा होस्ट पर दिखाई नहीं दिया। मैंने इलेक्ट्रॉनिक सर्किट के लेआउट पर विभिन्न विकल्पों को कॉन्फ़िगर करने की कोशिश की, लेकिन कुछ भी काम नहीं किया। बीगल ने बहुत सारे क्षतिग्रस्त पैकेज और अन्य त्रुटियों को दिखाया। अंत में, मैंने हार मान ली और फ़र्मवेयर उल्टा इंजीनियरिंग करने लगा।

यह अंतिम पिनआउट है, यूएसबी गहरे हरे रंग में चिह्नित है।



किसने सोचा होगा कि कुछ साल बाद वही ईबे नोटिफिकेशन मेरे पास आएगा और मैं बहुत सस्ते में वांछित एक्सेसरी खरीदूंगा।

अंत में, मैं पीटीपी के बारे में अपनी धारणाओं का परीक्षण कर सकता हूं। लेकिन पहले यह बहुत उत्सुक था कि गैजेट के अंदर यूएसबी पीएचवाई कैसे दिखता है।



अंदर एसएमएससी 2512 बी हब थासही जैक से मिनी यूएसबी कनेक्टर के लिए सड़क पर। चिप डिफ़ॉल्ट मोड में काम करती है क्योंकि कोई EEPROM या SCL / SDA पिन नहीं है। पहले डाउनस्ट्रीम पोर्ट को कैमरा बॉडी पर सॉकेट में रूट किया जाता है, लेकिन दूसरा कुछ भी कनेक्ट नहीं होता है।

मैं शायद कुछ याद किया, लेकिन मेरे लिए इस तरह के समाधान का कोई मतलब नहीं है। तकनीकी पासपोर्ट का कहना है कि चिप में "पूरी तरह से एकीकृत यूएसबी-पिन, साथ ही वोल्टेज को बढ़ाने और कम करने के लिए प्रतिरोधक हैं।" शायद लीका इंजीनियरों ने अपने स्वयं के यूएसबी पीएचवाई को लागू नहीं करने का फैसला किया, लेकिन हब में एक का उपयोग किया, जो अच्छी तरह से परीक्षण किया गया और बॉक्स से बाहर काम करता है। वास्तव में, मैं उन्हें दोष नहीं दे सकता, क्योंकि इससे पहले कि मैंने ऐसा करने की कोशिश की, और यह एक मुश्किल काम हो गया। शायद यह नकली के खिलाफ सुरक्षा के लिए एक विशेषता है, जो जानता है।

किसी भी स्थिति में, यदि आप USB PHY को समझते हैं और मदद करने के लिए तैयार हैं, तो मुझे लिखने में संकोच न करें: इस ब्रांडेड एक्सेसरी के बिना USB पोर्ट के माध्यम से काम करना संभव होना चाहिए :)

PTP फिर से

जैसा कि मैंने कहा, यह Leica PTP विस्तार के साथ खेलने का समय है।

सौभाग्य से, मुझे libptp के बजाय एक बहुत अच्छा C ++ पुस्तकालय मिला - यह libEasyPTP है । इस लाइब्रेरी पर आधारित टूल को लिखने में भी अधिक समय नहीं लगा: मुझे पहले से ही Leica PTP इंटरफ़ेस में कुछ सीमाएँ पता थीं।

और यद्यपि M240PTPTool काफी छोटी है, यह अवधारणा के सबूत ( प्रोग्राम कोड ) की भूमिका के लिए काफी उपयुक्त है ।

केवल दो अनुरोध PTP के माध्यम से जाते हैं: GetDebugBuffer (0x900C) और DebugCommandString (0x900D) । वैसे, डिबग लॉग को भरने के लिए मॉड्यूल के लिए, आपको मेनू में "डीबग" या "डीबग रॉ" के रूप में डीबग स्तर सेट करने की आवश्यकता है।

M240PTPTool इंटरफ़ेस में कई विकल्प हैं:

• बाहर निकलें - उपकरण बंद करें;
  
• फ्लश - कैमरे से डिबग बफर को मर्ज करें:

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
...

किसी अन्य पाठ को डिबगिंग कमांड के रूप में कैमरे में भेजा जाता है। उदाहरण के लिए, यह helpतर्कों के साथ सभी संभावित आदेशों को प्रदर्शित करता है: पूरी सूची काफी बड़ी है, लेकिन देखो, आप किसी भी कार्य के लिए सॉफ्टइन को सीधे संदेश भेज सकते हैं! वहाँ भेजने के लिए क्या दिलचस्प होगा ... एक और लोकप्रिय लाइन जो फ़र्मवेयर में अक्सर खोजी जाती है । चलो देखते हैं कि क्या हमारे पास एक है। जाहिरा तौर पर, आप फर्मवेयर को एसडी कार्ड पर डंप कर सकते हैं। "डंपिंग फाइल टू कार्ड" लाइन के लिंक का उपयोग करना, इसके लिए जिम्मेदार कोड को खोजना आसान है। यह विशाल सिस्टम टास्क ब्लॉक में स्थित है (पीआईडी ​​11, जैसा कि हम पहले से ही जानते हैं) और बिना तर्क के संदेश द्वारा बुलाया जाता है । डायल में M240PTPTool , प्रेस दर्ज करें और स्क्रीन पर नज़र।

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

...



dump

$ 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

0x11080006

send Message;11;0x11080006



फिर एसडी कार्ड निकालें और जांचें कि उस पर क्या है।



यहां यह फर्मवेयर सहित एक पूर्ण डंप है।

इससे अनंत संभावनाएं खुलती हैं। उदाहरण के लिए, आप एक MCU के साथ एक छोटा उपकरण बना सकते हैं, USB होस्ट के लिए समर्थन और संदेशों के जटिल अनुक्रम लॉन्च करने के लिए बटन ...

और फिर हमारे पास एक दूसरा बच्चा था। :)

उपसंहार

यदि आप उपकरण को तोड़ना नहीं चाहते हैं, तो आमतौर पर सर्किट बोर्ड में केस या सोल्डरिंग तारों को खोले बिना इसे जांचने का एक तरीका है। नीचे मेरी युक्तियां हैं यदि आप रुचि रखते हैं:

• डिवाइस के बारे में सभी सार्वजनिक जानकारी प्राप्त करें: तकनीकी विनिर्देश, घटकों पर डेटा, इनसाइड की तस्वीरें, कारखाने से वीडियो ;)
  
• यदि आपके पास फ़र्मवेयर है, तो इसमें डील-डौल करें और बाहरी आउटपुट पर युक्तियों की तलाश करें;
  
• , ;
  
• GND// , ;
  
• ;
  
• , ;
  
• , (, );
  
• , Google (USB/UART/SPI/I2C/1Wire);
  
• , ;
  
• , ;
  
• , .

github.com/alexhude

!