💪🏼 👓 🔆 हमें एक बग को ठीक करना चाहिए जो "नहीं" है 👌🏾 🔳 👩‍🔬

इसलिए, हमारे पास एक कार्य है: एक बग को ठीक करने के लिए, जिस निर्माता से यह अस्वीकार करता है, ग्राहक नोटिस नहीं करते हैं, लेकिन मैं जीना चाहता हूं। एक कैमरा है, इसे यूडीपी से स्ट्रीम बस नारकीय रूप से तोड़ता है, टीसीपी को स्ट्रीम काम करता है, लेकिन कनेक्शन लगातार फटे हुए हैं (और प्रत्येक ब्रेक के साथ, 3-5 सेकंड का वीडियो गायब हो जाता है)। हर कोई समस्या का दोषी है (कैमरा और सॉफ्टवेयर दोनों), लेकिन दोनों पक्ष दावा करते हैं कि वे सभी आहत हैं, यानी स्थिति सामान्य है: क्या आप बग को देखते हैं? कोई। लेकिन वह है ।

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

ब्रिजहेड अध्ययन

सबसे पहले, हम नवीनतम फर्मवेयर लेते हैं (मेरे मामले में - फर्मवेयर_TS38ABFG031-ONVIF-P2P-V2.5.0.6_20140126120110.bin), और पता करें कि यह क्या है:

  $ फ़ाइल फर्मवेयर_TS38ABFG006-ONVIF-P2P-V2.5.0.6_201401261210.bin
 फर्मवेयर_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin: डेटा

 $ du -b फर्मवेयर_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin
 15222724 फर्मवेयर_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin

 $ xxd फर्मवेयर_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin |  सिर
 0000000: 4649 524d 5741 5245 6481 db15 c447 e800 FIRMWAREd .... ।।
 0000010: 0300 0000 1406 0000 b0f1 1b00 4c21 815d ............ L।]
 0000020: 5453 3338 4f45 4d41 4246 475f 4c49 4e55 TS38OEMABFG_LINU
 0000030: 5800 0000 0000 0000 0000 0000 0000 X ..............।
 0000040: 0000 0000 0000 0000 0000 0000 0000 ................
 0000050: 0000 0000 0000 0000 0000 0000 0000 ................
 0000060: 0000 0000 0000 0000 0000 0000 0000 ................
 0000070: 0000 0000 0000 0000 0000 0000 0000 ................
 0000080: 0000 0000 0000 0000 0000 0000 0000 ................
 0000090: 0000 0000 0000 0000 0000 0000 0000 ................

 $ Binwalk फर्मवेयर_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin
 डेमल हेक्स डेस्क
 -------------------------------------------------- -------------------------------------------------- ---
 1556 0x614 uImage हेडर, हेडर का आकार: 64 बाइट्स, हेडर CRC: 0xB21E2C9F, बनाया गया: Sun Sep 22 11:07:02 2013, छवि का आकार: 1831280 बाइट्स, डेटा पता: 0x80008000, एंट्री पॉइंट: 0x80008000, डेटा CRC: 0x1F4EFBAB.03। : लिनक्स, सीपीयू: एआरएम, छवि प्रकार: ओएस कर्नेल छवि, संपीड़न प्रकार: कोई नहीं, छवि का नाम: "लिनक्स-2.6.18_pro500-davinci_IPNC"
 14468 0x3884 gzip संकुचित डेटा, यूनिक्स से, अंतिम बार संशोधित: Sun Sep 22 11:07:02 2013, अधिकतम संपीड़न
 1832900 0x1BF7C4 CramFS फाइल सिस्टम, थोड़ा एंडियन आकार 13389824 संस्करण # 2 सॉर्ट किए गए_डिस्क CRC 0xc832a8c3, संस्करण 0, 7334 ब्लॉक, 2607 फाइलें

तो, इसका प्रारूप अज्ञात है, स्टार्ट लेबल "FIRMWARE" विचारों को उद्घाटित करता है कि यह अपने आप में कुछ है, uImage के अंदर एक कर्नेल और cramfs की उपस्थिति से पता चलता है कि वास्तव में यह कुछ सरल है। लाइन TS38OEMABFG_LINUX की मौजूदगी बताती है कि यह संग्रह के कुछ संस्करण की याद दिलाने वाला भी है।

चूँकि अब हमें केवल यह देखना है कि कहाँ देखना है - बस फ़ाइल सिस्टम को वहाँ से बाहर निकालें, और अपराधी मॉड्यूल की तलाश करें:

  $ dd if = फर्मवेयर_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin bs = 1832900 Skip = 1 of = cramfs
 7 + 1 रिकॉर्ड प्राप्त किया
 7 + 1 रिकॉर्ड भेजा गया
  13389824 बाइट्स (13 एमबी) कॉपी किए गए, 0.161755 एस, 82.8 एमबी / एस
 $ fakeroot cramfsck -x fs cramfs
 $ grep LIVE555 -R fs /
 Fs / opt / topsee / rtsp_streamer बाइनरी मैच
 $ तार fs / ऑप्ट / टॉपसी / rtsp_streamer |  grep टीसीपी
 sendRTPOverTCP
 12RTCPInstance
 sendRTPOverTCP विफल, जुर्राब:% d, chn:% d
  आरटीसीपी उदाहरण नहीं है
 RTCPInstance :: RTCPInstance error: totSessionBW पैरामीटर शून्य नहीं होना चाहिए!
 आरटीपी / एवीपी / टीसीपी
 % sTransport: RTP / AVP / TCP; यूनिकैस्ट; डेस्टिनेशन =% s; सोर्स =% डी; इंटरलेयर्ड =% d-% d
 / टीसीपी; यूनिकस्ट
 RTCP सॉकेट बनाने में विफल (पोर्ट% d)
 MediaSession :: आरंभ (): RTP और RTCP सॉकेट बनाने में असमर्थ
 RTCP उदाहरण बनाने में विफल
 प्राप्त RTCP "BYE" पर "
 18RTCPMemberDatabase

Hohoho! "SendRTPOverTCP विफल हुआ, जुर्राब:% d, chn:% d" हमें बताता है कि कोड का डिबगिंग प्रिंट के साथ अनुवाद किया गया है, जिसका अर्थ है कि परिमाण के आदेशों से कार्य की मात्रा कम हो जाती है!

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

स्थानीयकरण और समस्याओं को ठीक करें

हम मॉड्यूल को एक डिस्सेम्बलर में लोड करते हैं, डीबग लाइन के लिए ओवरटेक का उपयोग करते हुए देखते हैं, इसके लिए कोड के लिए प्रिंट आउट => हमें सेंड आरटीओओओटीटीसीपी फ़ंक्शन मिला।

इसके माध्यम से देखते हुए, हम जल्दी से भेजने के लिए दो कॉल देखते हैं () फ़ंक्शन - 4 बाइट्स के साथ एक, इनपुट के पास एक बफर के साथ। इसका मतलब है कि हमें वह संस्करण मिला है जो सबसे पुराना नहीं है, लेकिन जब हम पहले से ही बफर को एकीकृत कर चुके थे, लेकिन हमने अभी तक SendDataOverTCP फ़ंक्शंस नहीं किया था (कार्यान्वयन में अंतर के बारे में अधिक जानकारी के लिए, अंतिम <पोस्ट देखें) ।

अब सवाल उठता है कि मैं बग को बाइनरी फॉर्म में कैसे ठीक कर सकता हूं, जब व्यावहारिक रूप से कोई मार्जिन नहीं होता है (फ़ाइल के अंदर कोई खाली जगह नहीं है)।

हम उस फ़ंक्शन के ऊपर जाते हैं जो sendDataOverTCP - sendPacket कहता है। इसका कोड संस्करण से संस्करण में नहीं बदला, यह अनिवार्य रूप से समान है - foreach (स्ट्रीम) {sendDataOverTCP (पैकेट, स्ट्रीम)}।

सौभाग्य से, कोड उदारता से डीबगिंग फ़्रीप्रिंट्स के साथ crammed था, और जो हमें बचाता है! यहां बताया गया है कि यह लूप बाइनरी फॉर्म में कैसा दिखता है:

loop_next_5FAE4: LDR R4, [R4,#4] CMP R4, #0 BEQ loc_5FB68 loop_body_5FAF0: MOV R3, R4 MOV R1, R5 MOV R2, R7 MOV R0, R6 BL sendRTPOverTCP CMP R0, #0 BGE loop_next_5FAE4 MOV R1, #0 LDR R2, =aS_10 ; "%s(): " LDR R3, =aSendpacket ; "sendPacket" MOV R0, #STDERR_FILENO BL fprintf_0 LDRB R12, [R4,#0xC] LDR R3, [R4,#8] MOV R1, #7 LDR R2, =aSendrtpovert_0 ; "sendRTPOverTCP failed, sock: %d, chn: %"... MOV R0, #STDERR_FILENO STR R12, [SP,#0x350+var_350] BL fprintf_0 ......

यह वास्तव में एक मोक्ष है! डिबग पीस को काटने से हमें 12 निर्देशों की मात्रा में जगह मिलती है (ARM में सभी निर्देश बिल्कुल 4 बाइट्स हैं, जो बहुत अच्छा है)।

इसलिए, स्थिति को सुधारने के लिए कुछ करने के लिए हमारे पास 12 निर्देशों में एक जगह है। लेकिन क्या? यह पूरी तरह से नवीनतम संस्करण से sendDataOverTCP कोड को यहां धकेलना बहुत मुश्किल होगा ...

हालांकि रुक जाते हैं। और क्यों? मुझे लगता है कि विस्तार से वर्णन किया गया है कि सही sendDataOverTCP फॉर्म का उपयोग करना अभी भी बुरा है ... और यदि आपको अंतर दिखाई नहीं दे रहा है, तो सिर्फ कॉल को मेक सॉकेट में क्यों न लपेटें () .. makeSocketNonBoning ()?

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

बहुत बढ़िया! Fcntl फ़ंक्शन से रिवाइंड करने से, हम मेक सॉकेटब्लॉकिंग और मेक सॉकेटनॉनब्लॉकिंग प्राप्त करते हैं, जिसके बाद हम ड्रॉ करते हैं कि किस कोड को बाहर करना चाहिए:

 loop_next_5FAE4: LDR R4, [R4,#4] CMP R4, #0 BEQ loc_5FB68 loop_body_5FAF0: ;     LDR R0, [R4,#8] BL makeSocketBlocking ;      MOV R3, R4 MOV R1, R5 MOV R2, R7 MOV R0, R6 BL sendRTPOverTCP ;     STMFD SP!, {R0} ;     LDR R0, [R4,#8] BL makeSocketNonBlocking ;      LDMFD SP!, {R0} ;      CMP R0, #0 BGE loc_5FAE4 ;       NOP NOP NOP NOP NOP NOP

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

नतीजतन, हमें rtsp_streamer एक पैच के साथ मिलता है, जो उस पर आरोपित है जो टीसीपी स्ट्रीम को भ्रष्टाचार से बचाता है।

ब्लास्ट सोल्डरिंग, सोबर असेंबली

तो, हमारे पास एक नया rtsp_streamer है, और फर्मवेयर है ... बिन जिसमें इसे बनाने की आवश्यकता है। ठीक है, ऐसा लगता है, सब कुछ सरल है: आपको cramfs को अनपैक करने की आवश्यकता है, फ़ाइल को बदलें, इसे वापस पैक करें, इसे बिन के अंदर बदलें:

  $ fakeroot -s .fakeroot cramfsck -x repack cramfs
 $ cp rtsp_streamer रिपैक / ऑप्ट / टॉपसी /
 $ fakeroot -i .fakeroot mkcramfs को newcramfs रिपैक करते हैं
 $ dd if = फर्मवेयर_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin = = फर्मवेयर_न्यू.बीन bs = 1832900 गिनती = 1
 $ बिल्ली newcramfs >> फर्मवेयर_न्यू.बिन

प्राप्त फर्मवेयर_न्यू.बिन को कैमरे में डालें ... 0 प्रभाव। कैमरा फर्मवेयर खाता है, लेकिन कुछ भी नहीं होता है। अप्रिय। तो, आपको इस .bin के प्रारूप को समझने की आवश्यकता है।

इसे हेक्स संपादक में खोलें, और कुमेकू शुरू करें:

(0) "FIRMWARE" - 100% हेडर, 8 बाइट्स।

(() ६४ DB१ डीबी १५ - ४ बाइट्स, उद्देश्य स्पष्ट नहीं है। गंध द्वारा - चेकसम

(12) 0x00E847C4 = 15222724 - हाँ, 4 बाइट्स, फ़र्मवेयर का आकार। हम _new.bin की जांच करते हैं - नहीं, आकार नहीं बदला है, जिसका अर्थ है कि इसका इससे कोई लेना-देना नहीं है।

(16) 0x00000003 - 4 बाइट्स xs क्या। हेडर संस्करण कर सकते हैं?

(२०) ०x००००६१४ = १५५६ - तो, और यह अंदर के मूल का विस्थापन है

(24) 0x001BF1B0 = 1831344 - और यह कोर का आकार (1831344 + 1556 = 1832900) है

(२ () ४ सी २१ 5१ ५ डी - हम्म। फिर से एक चेकसम के समान कुछ।

(32) "TS38OEMABFG_LINUX" और शून्य का एक गुच्छा - बाद में 100h बाइट्स, जाहिर तौर पर अनुभाग नाम के लिए एक जगह

(288) 0x001BF7C4 = 1832900 - हाँ, अगले भाग में ऑफसेट करें

(292) 0x00CC5000 = 13389824 - हाँ, अनुभाग आकार

(२ ९ ६) "TS38OEMABFG_V2.5.0.6" और शून्य का एक समूह अपारदर्शी हैं। 100h बाइट्स, स्पष्ट रूप से अनुभाग नाम के तहत।

लेकिन इसके सामने कोई चेकसम नहीं है O_O

(552-1556) - अज्ञात उपस्थिति का कुछ।

तो, मोटे तौर पर बिंदु स्पष्ट है। हमारे cramfs का आकार नहीं बदला है, जिसका अर्थ है कि ये आकार नहीं हैं, और इसलिए, चेकसम।

हम कर्नेल को निकालते हैं, और इसकी लंबाई में 4 बाइट्स के चेकसम पर विचार करते हैं:

  $ dd if = फर्मवेयर_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin = कर्नेल बीएस = 1 स्किप = 1556 काउंट = 1831344
 $ crc32 कर्नेल 
 5d81214c

ठीक है, ठीक है ... ऑफसेट पर सिर्फ 0x5D81214C। भाग्यशाली मानक CRC32 है। भाग्यशाली है क्योंकि मानक उपकरण केवल यह जानता है कि इसे कैसे गिनना है। अन्यथा, मुझे अजगर को चलाना होगा और पहले से ही "अधिक कठिन" पर विचार करना होगा :)

इसलिए, हमारे पास जो चेकसम हैं वे crc32 हैं। और मूल cramfs का चेकसम क्या है? .. 37499eef। तो-तो-तो। ऑफसेट 552 पर, 0x37499eef अभी लिखा गया है। तो, किसी कारण से, फ़ाइल सिस्टम के लिए चेकसम विभाजन विभाजन नाम लिखा है। अच्छा ठीक है, हमें क्या चाहिए, हमें गर्व नहीं है। प्लेट को अपडेट करना:

(28) 0x5D81214C - crc32 कर्नेल विभाजन

(552) 0x37499eef - crc32 पार्टीशन FS

(556-1556) - अज्ञात उपस्थिति का कुछ

हम crc32 newcramfs का पुनरावर्तन करते हैं, संपादक के साथ हेक्स, इसे बिनार में ऑफसेट 552 पर दर्ज करें, इसे कैमरे में भरें।

और ... कुछ नहीं O_O। तो, स्वभाव निराश नहीं था - ऑफसेट 8 पर यह वास्तव में crc32 है, लेकिन क्या से?

यहाँ हम सरलता से कार्य करते हैं - हम पाशविक बल शुरू करते हैं।

  $ अजगर
 >>> zlib आयात crc32 से
 >>> d = खुला ("फर्मवेयर_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin", "r")। () पढ़ें
 >>> हेक्स (crc32 (d [12:]))
 '-0x781aca29' # नं
 >>> हेक्स (crc32 (d [12: 1556]))
 '-0x6f8f1744' # नं
 >>> हेक्स (crc32 (d [0: 8] + d [12: 1556])
 '0x6d29f056' # नं
 >>> हेक्स (crc32 (d [0: 8] + d [12:]))
 '-0x652ac4fd' # सं
 >>> हेक्स (crc32 (d [0: 8] + "\" \ 0 \ 0 \ 0 \ 0 "+ d [12: 1556]))
 '0x15db8164' # उफ़!  यह है!

जल्दी से अच्छा किया। तो, हम प्लेट को अपडेट करते हैं:

(8) 0x15DB8164 - CRC32 हेडर (पहले 1556 बाइट्स), इस क्षेत्र को पहली बार

तो, वहीं, अजगर में हम हेडर फर्मवेयर_न्यू.बिन से crc32 को जल्दी से रिकवर करते हैं और इसे शुरुआत में हेक्स एडिटर में लिखते हैं।

कैमरे में डालो ... वह रिबूट में चला जाता है। और जवाब नहीं देता ... जवाब नहीं देता ... एक और ईंट ... ओह! पिंग चलते हैं! Fuuuh।

हम cam-resync.py लेते हैं, और फिर से हम अपने कैमरे को एक छड़ी के साथ चिपका देते हैं। और ... और धारा नहीं टूटती! वहीं, पहली कोशिश पर! Wiiii :)

यह रोटी पर लिप्त है, और यह पहले से ही खाने के लिए संभव है, लेकिन कुछ सही नहीं है

इस बीच, पहले से उल्लेख किया गया आंद्रेई सिमोकोकिन, अपने फर्मवेयर को rtsp_streamer I के साथ ठीक करता है और इसे समस्या कैमरों में से एक पर अपलोड करता है, जिसमें से कई ब्रेक थे। नतीजतन, परीक्षण से पता चला कि धारा नहीं टूटती है, हालांकि, वीडियो कलाकृतियां शुरू हुईं, यूडीपी पर पैकेट खोने के दौरान। चूंकि मैंने ऐसा कुछ भी नहीं किया था, इसलिए मैं उत्सुक था कि यह क्या है - मुझे फिर से कोड को देखना पड़ा। शुरू करने के लिए, तार देखें, हमारे पास डिबगिंग लाइनों का एक गुच्छा है। "% D सेकंड के लिए CheckBufferTimeout !!!", "% d ms से अधिक बफ़र किया गया डेटा, सभी बफ़र्ड डेटा ड्रॉप करें"।

अहा! यह पता चला है कि निर्माताओं ने अतिप्रवाह संरक्षण किया है! और अगर किसी कारण से सिंक्रोनस सेंड () अभी भी आवश्यकता से अधिक लटका हुआ है (डिफ़ॉल्ट रूप से - 1 सेकंड), तो यह अतिरिक्त को गिरा देता है। यह OOM और वीडियो लैग से बचाता है अगर यह एक पतले चैनल में फिट नहीं होता है। लेकिन गैर-ब्लॉकिंग सॉकेट और भेजने () के उपयोग के कारण कोड ने स्पष्ट रूप से पहले काम नहीं किया था।

ब्लॉकिंग में रैप करने के बाद ... नॉनब्लॉकिंग - कोड ने काम करना शुरू कर दिया :)

हालांकि, एक छोटी सी समस्या है: 1 सेकंड पर्याप्त नहीं है। यदि चैनल विफल होने लगता है, लेकिन पर्याप्त मोटा है, तो एक बूंद की संभावना मजबूत हो जाती है। इस तरह की किसी भी गिरावट के बाद, वीडियो को कीफ्रेम के बाद ही बहाल किया जाता है। आमतौर पर एक कीफ़्रेम काफी दुर्लभ होता है (प्रत्येक 5-10 सेकंड में एक बार) ... और यह एक अप्रिय स्थिति का पता लगाता है - यदि कोई विफलता थी, तो आपको अगले कीफ़्रेम से पहले 5-10 सेकंड प्रतीक्षा करने की आवश्यकता है ताकि वीडियो की मरम्मत हो। यदि आप कीफ्रेम की आवृत्ति को कम करते हैं, तो यह स्वचालित रूप से प्रेषित डेटा की मात्रा को बढ़ाता है, क्योंकि कीफ्रेम काफी मोटे हैं, जिसका अर्थ है कि यह चैनल मरने की आवृत्ति को बढ़ाता है। दुष्चक्र।

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

वैसे, "चालाक" उपचार एल्गोरिथ्म

अपने आखिरी लेख में मैंने यह बताने का वादा किया कि स्थिति को ठीक करना कितना आसान है। समाधान सिर्फ महसूस किए गए जूते की तरह है - चूंकि हम आरटीपी पैकेट भेजते हैं, इसलिए हम प्रत्येक के पास टाइमस्टैम्प है। पैकेट जीवनकाल भेजने से पहले sendRTPorRTCPPacketOverTCP में जांच करना पर्याप्त है, और यदि यह कॉन्फ़िगर किए गए से कम है (मुझे अभी भी लगता है कि 1 सेकंड टीसीपी पर पर्याप्त नहीं है, तो इसे 6-10 सेकंड होना चाहिए) इसे भेजें, अन्यथा यह चुपचाप भेजने के लिए नहीं है।

स्वचालित असेंबली-डिसैसफ़ॉर्म

केवल एक चीज बची हुई है, फर्मवेयर के असेंबली-डिसएस्पेशन को स्वचालित करने के लिए।

unpack.sh

छिपा हुआ पाठ

 fw=${1?Please give firmware bin as argument} if [ -e $fw.unpack ]; then echo "Already exists: $fw.unpack" exit 1 fi # Check format if [ "$(dd if=$1 bs=8 count=1 2>/dev/null)" != "FIRMWARE" ]; then echo "Wrong file" exit 1 fi mkdir -p $fw.unpack echo "Extract header..." dd if=$1 of=$fw.unpack/00header bs=1556 count=1 2>/dev/null echo "Extract kernel..." ksize=$(dd if=$1 bs=1 count=4 skip=24 2>/dev/null | perl -e 'print unpack("l", <>);') dd if=$1 of=$fw.unpack/01kernel bs=1 skip=1556 count=$ksize 2>/dev/null echo "Extract filesystem..." foff=$(dd if=$1 bs=1 count=4 skip=288 2>/dev/null | perl -e 'print unpack("l", <>);') dd if=$1 of=$fw.unpack/02cramfs bs=$foff skip=1 2>/dev/null echo "Unpack filesystem..." cd $fw.unpack fakeroot -s .fakeroot cramfsck -x root 02cramfs chmod +r -R root/ echo "Done"

चूँकि हम शीर्षक के टुकड़े का अर्थ नहीं जानते हैं, इसलिए हम मनमानी नहीं कर सकते हैं ताकि कैमरे को न मारें, इसलिए हम सभी टुकड़ों को सहेजते हैं जैसे वे हैं।

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

हालांकि, इसके साथ एक माइक्रो-समस्या है - अंत में, फ़ाइल को वर्तमान उपयोगकर्ता को पढ़ने के लिए उपलब्ध होना चाहिए। यदि आप एक "वास्तविक" रूट हैं, तो आप आसानी से फ़ाइल पढ़ सकते हैं, भले ही वह "chmod -r" हो। लेकिन ऐसी फाइल पर फ़ेकरूट टूट जाता है। इसलिए, अनपैक करने के तुरंत बाद, मैं सभी फ़ाइलों के लिए रीड की अनुमति को बदल देता हूं। लेकिन, सही पहुंच अधिकार fakeroot राज्य डंप में सहेजे जाते हैं, इसलिए रिवर्स असेंबली एक धमाके के साथ बंद हो जाती है।

बाकी अनपैकिंग में कोई दिलचस्प बिंदु नहीं है।

pack.sh

छिपा हुआ पाठ

 dir=${1?Please give path to a directory with unpacked firmware} nfw=${2?Please give name for a newly packed firmware} if [ ! -e $dir ]; then echo "Directory not exists: $dir" exit 1 fi if [ -e $nfw ]; then echo "Firmware already exists: $nfw" exit 1 fi # repack cramfs if [ ! -e $dir/02cramfs.bak ]; then mv $dir/02cramfs $dir/02cramfs.bak 2>/dev/null fi fakeroot -i $dir/.fakeroot mkcramfs $dir/root/ $dir/02cramfs # construct new firmware dd if=$dir/00header bs=1556 of=$nfw conv=notrunc 2>/dev/null # remove old header crc32 dd if=/dev/zero bs=1 seek=8 count=4 of=$nfw conv=notrunc 2>/dev/null # save kernel size if [ $(stat -c %s $dir/01kernel) -ge 2097152 ]; then echo "WARN: size of kernel is more than 0x200000. FW probably will not flash" fi perl -e 'print pack("l", -s "'$dir/01kernel'")' | dd bs=1 seek=24 count=4 of=$nfw conv=notrunc 2>/dev/null # save kernel crc32 crc32 $dir/01kernel | perl -e 'print pack("l", oct("0x".<>));' | dd bs=1 seek=28 count=4 of=$nfw conv=notrunc 2>/dev/null # save fs offset perl -e 'print pack("l", 1556+(-s "'$dir/01kernel'"))' | dd bs=1 seek=288 count=4 of=$nfw conv=notrunc 2>/dev/null # save fs size if [ $(stat -c %s $dir/02cramfs) -lt 8388608 ]; then echo "WARN: size of filesystem is less than 0x800000. FW probably will not flash" fi if [ $(stat -c %s $dir/02cramfs) -ge 15728640 ]; then echo "WARN: size of filesystem is more than 0xF00000. FW probably will not flash" fi perl -e 'print pack("l", -s "'$dir/02cramfs'")' | dd bs=1 seek=292 count=4 of=$nfw conv=notrunc 2>/dev/null # save fs crc32 crc32 $dir/02cramfs | perl -e 'print pack("l", oct("0x".<>));' | dd bs=1 seek=552 count=4 of=$nfw conv=notrunc 2>/dev/null # save full FW size perl -e 'print pack("l", 1556+(-s "'$dir/02cramfs'")+(-s "'$dir/01kernel'"))' | dd bs=1 seek=12 count=4 of=$nfw conv=notrunc 2>/dev/null # Update header crc32 crc32 $nfw | perl -e 'print pack("l", oct("0x".<>));' | dd bs=1 seek=8 count=4 of=$nfw conv=notrunc 2>/dev/null # concat rest cat $dir/01kernel >> $nfw cat $dir/02cramfs >> $nfw echo "Done"

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

सामान्य तौर पर, कैमरा स्वयं सीमा मूल्यों की जांच करता है, हालांकि, सुविधा के लिए, मैंने फ़ाइल सिस्टम और कर्नेल आकारों की सीमाओं पर एक चेक जोड़ा, ताकि यदि असेंबली के दौरान इसके आकार कम हो जाएं, तो एक चेतावनी प्राप्त करें और फ़र्मवेयर से अतिरिक्त पूंछ हटा दें।

श्रम का परिणाम

इसलिए, मैंने नवीनतम संस्करण 2.5.0.6 के निम्नलिखित पैच फ़र्मवेयर एकत्र किए:

firmware_TS38ABFG006-ONVIF-पी 2 पी-V2.5.0.6_20140126120110- TCPFIX.bin
firmware_TS38CD-ONVIF-पी 2 पी-V2.5.0.6_20140126121011- TCPFIX.bin
firmware_TS38HI-ONVIF-पी 2 पी-V2.5.0.6_20140126121444- TCPFIX.bin
firmware_TS38LM-ONVIF-पी 2 पी-V2.5.0.6_20140126121913- TCPFIX.bin
firmware_HI3518C-V4-ONVIF-V2.5.0.6_20140126124339- TCPFIX.bin

यदि आपको अचानक उसी निर्माता के किसी अन्य मॉड्यूल पर फिक्स की आवश्यकता है - टिप्पणियों में लिखें, मैं देखूंगा कि क्या संभव है।

ps: हर कोई, जिसे इन फर्मवेयर से कुछ और की जरूरत है, स्क्रिप्ट्स को अधिक सुविधाजनक जगह पर पोस्ट किया है - जीथब पर ।

हमें एक बग को ठीक करना चाहिए जो "नहीं" है