🌬️ 🥂 ⚽️ 「ではない」バグを修正するにはどうすればよいですか 🔒 🔧 🙎🏿

だから、私たちには仕事があります：バグを修正すること、それを拒否する製造元、顧客は気づかないが、私は生きたい。カメラがあり、それからUDPへのストリームは単純に破壊され、TCPへのストリームは機能しますが、接続は常に切断されます（そして、中断するたびに3〜5秒のビデオが消えます）。誰もが問題を犯していますが（カメラとソフトウェアの両方）、双方がすべてが傷ついていると主張しています。つまり、状況は正常です。バグが見えますか？いやしかし、彼はそうです。

ソフトウェアはカメラよりもはるかに頻繁に更新されるため、後で触れる必要のない場所を編集することは理にかなっています。そのため、カメラの側面から修正します。

ブリッジヘッド研究

まず最初に、最新のファームウェア（私の場合はfirmware_TS38ABFG031-ONVIF-P2P-V2.5.0.6_20140126120110.bin）を使用して、それが何であるかを調べます。

  $ file firmware_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin
 firmware_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin：データ

 $ du -b firmware_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin
 15222724 firmware_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin

 $ xxd firmware_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin | 頭
 0000000：4649 524d 5741 5245 6481 db15 c447 e800ファームウェア.... G ..
 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 0000 X ...............
 0000040：0000 0000 0000 0000 0000 0000 0000 0000 ................
 0000050：0000 0000 0000 0000 0000 0000 0000 0000 ................
 0000060：0000 0000 0000 0000 0000 0000 0000 0000 ................
 0000070：0000 0000 0000 0000 0000 0000 0000 0000 ................
 0000080：0000 0000 0000 0000 0000 0000 0000 0000 ................
 0000090：0000 0000 0000 0000 0000 0000 0000 0000 ................

 $ binwalk firmware_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin
 10進数の説明
 -------------------------------------------------- -------------------------------------------------- ---
 1556 0x614 uImageヘッダー、ヘッダーサイズ：64バイト、ヘッダーCRC：0xB21E2C9F、作成日：2013年9月22日11:07:02 2013、イメージサイズ：1831280バイト、データアドレス：0x80008000、エントリポイント：0x80008000、データCRC：0x1F4EFBAB、OS ：Linux、CPU：ARM、イメージタイプ：OSカーネルイメージ、圧縮タイプ：なし、イメージ名： "Linux-2.6.18_pro500-davinci_IPNC"
 14468 0x3884 gzip圧縮データ、Unixから、最終変更日：Sun Sep 22 11:07:02 2013、最大圧縮
 1832900 0x1BF7C4 CramFSファイルシステム、リトルエンディアンサイズ13389824バージョン＃2 sort_dirs CRC 0xc832a8c3、エディション0、7334ブロック、2607ファイル

そのため、その形式は不明であり、「FIRMWARE」という開始ラベルは、それが独自のものであるという考えを呼び起こします。uImage内のカーネルとcramfsの存在は、実際には単純なものであることを示唆しています。 TS38OEMABFG_LINUX行の存在は、これがアーカイブのあるバージョンを思い起こさせるものであることを示唆しています。

ここから、どこを探すかを見つける必要があります。そこからファイルシステムを引き出して、原因モジュールを探します。

  $ dd if = firmware_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin bs = 1832900 skip = 1 of = cramfs
 7 + 1レコードを受信しました
 7 + 1レコードが送信されました
  13389824バイト（13 MB）コピー、0.161755秒、82.8 MB /秒
 $ fakeroot cramfsck -x fs cramfs
 $ grep LIVE555 -R fs /
 fs / opt / topsee / rtsp_streamerバイナリマッチ
 $文字列fs / opt / topsee / rtsp_streamer |  grep TCP
 sendRTPOverTCP
 12RTCPInstance
 sendRTPOverTCPが失敗しました。sock：％d、chn：％d
  RTCPインスタンスではない
 RTCPInstance :: RTCPInstanceエラー：totSessionBWパラメーターはゼロであってはなりません！
 RTP / AVP / TCP
 ％sTransport：RTP / AVP / TCP;ユニキャスト;宛先=％s;ソース=％s;インターリーブ=％d-％d
 / TCP;ユニキャスト
 RTCPソケットの作成に失敗しました（ポート％d）
 MediaSession :: begin（）：RTPおよびRTCPソケットを作成できません
 RTCPインスタンスの作成に失敗しました
 「」でRTCP「BYE」を受信しました
 18RTCPMemberDatabase

ほほほ！「SendRTPOverTCPが失敗しました、sock：％d、chn：％d」は、コードがデバッグ出力で変換されることを示しています。つまり、作業量が桁違いに削減されます。

したがって、探しているエラーを含むモジュール、デバッグ行が内部にあるモジュールがあります。これは、サイズ変更のプロセスが大幅に簡素化されることを意味します。

ローカリゼーションと問題の修正

モジュールを逆アセンブラーにロードし、OverTCPを使用してデバッグ行を探し、そこからコードを探して出力します=> sendRTPOverTCP関数が見つかりました。

これを見ると、send（）関数への2つの呼び出しがすぐにわかります。1つは4バイト、もう1つは入力に渡されるバッファーです。これは、最も古いバージョンではないが、すでにバッファーを統合したが、sendDataOverTCP関数をまだ作成していない場合（実装の違いの詳細については、最後の<postを参照してください）

ここで問題が発生します。実際には余白がない（ファイル内に空きスペースがない）ときに、バイナリ形式でバグを修正する方法を教えてください。

sendDataOverTCP-sendPacketを呼び出す上記の関数に移動します。コードはバージョンごとに変更されず、本質的に同じです-foreach（ストリーム）{sendDataOverTCP（パケット、ストリーム）}。

幸いなことに、コードはデバッグfprintsでgeneしみなく詰め込まれていました。以下に、このループがバイナリ形式でどのように見えるかを示します。

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フォームを使用してもなお悪いと詳細に説明しているようです...そして違いがなければ、単にmakeSocketBlocking（）.. makeSocketNonBlocking（）で呼び出しをラップしないのですか？

実際、システムバッファに場所がある場合、send（）は即座に実行されます。スペースがない場合、sendDataOverTCPの実装はそのまま残ります（なぜゼロに固定されてすぐに抜け落ちないのか-前の記事を参照）。

いいね！ fcntl関数からすばやく巻き戻すと、 makeSocketBlockingとmakeSocketNonBlockingが見つかります。その後、どのコードになるかを描画します。

 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

パッチを適用するには、アームのドキュメントを開いて心の中で翻訳するか、別のファイルにコードを記述して翻訳します（すべての遷移（BL / BGE / ITD）が正しく再カウントされるように、ORGで正確なアドレスを設定することを忘れないでください）コードで適切な指示を見つけたので、それに基づいて必要なオペコードを計算しました（ARMを初めて編集しています、申し訳ありません）。

その結果、破損からTCPストリームを保護するパッチが重ねられたrtsp_streamerを取得します。

はんだ付け、地味な組み立て

そのため、新しいrtsp_streamerがあり、ファームウェア... binが組み込まれています。まあ、それはすべてが簡単だと思われます：cramfsを解凍し、ファイルを置き換え、それを元に戻し、bin内で置き換える必要があります：

  $ fakeroot -s .fakeroot cramfsck -x repack cramfs
 $ cp rtsp_streamer repack / opt / topsee /
 $ fakeroot -i .fakeroot mkcramfs repack newcramfs
 $ dd if = firmware_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin of = firmware_new.bin bs = 1832900 count = 1
 $ cat newcramfs >> firmware_new.bin

取得したfirmware_new.binをカメラ... 0エフェクトに注ぎます。カメラはファームウェアを食べますが、何も起こりません。不快です。そのため、この.binの形式を理解する必要があります。

16進エディタで開き、kumekuを起動します。

（0） 「ファームウェア」-100％ヘッダー、8バイト。

（8） 64 81 DB 15-4バイト、目的は明確ではありません。におい-チェックサム

（12） 0x00E847C4 = 15222724-はい、4バイト、ファームウェアのサイズ。 _new.binを確認します-いいえ、サイズは変更されていません。つまり、サイズとは関係ありません。

（16） 0x00000003-4バイトxs何。ヘッダーバージョンはできますか？

（20） 0x00000614 = 1556-したがって、これは内部のコアへの変位です

（24） 0x001BF1B0 = 1831344-これはコアのサイズです（1831344 + 1556 = 1832900）

（28） 4C 21 81 5D-うーん。再びチェックサムに似たもの。

（32） 「TS38OEMABFG_LINUX」とその後のゼロの束-100hバイト、明らかにセクション名の場所

（288） 0x001BF7C4 = 1832900-はい、次のセクションへのオフセット

（292） 0x00CC5000 = 13389824-はい、セクションサイズ

（296） 「TS38OEMABFG_V2.5.0.6」およびゼロの束は不透明です。セクション名の下の100hバイト。

しかし、その前にチェックサムはありませんO_O

（552-1556） -外観が不明なもの。

だから、おおよそのポイントは明らかです。 cramfsのサイズは変更されていません。つまり、これらはサイズではないため、チェックサムです。

カーネルを抽出し、その長さ4バイトのチェックサムを考慮します。

  $ dd if = firmware_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin of = kernel bs = 1 skip = 1556 count = 1831344
 $ crc32カーネル 
 5d81214c

まあ、まあ...オフセット28でちょうど0x5D81214C。ラッキーは標準のCRC32です。幸運なのは、標準ツールはそれを数える方法しか知らないからです。そうでなければ、私はPythonを実行し、すでに「より難しい」と考えなければなりません:)

したがって、私たちが持っているチェックサムはcrc32です。そして、元のcramfsのチェックサムは何ですか？.. 37499eef。まあまあ。オフセット552では、0x37499eefが書き込まれます。そのため、何らかの理由で、ファイルシステムのパーティション名の後のチェックサムが書き込まれます。さて、何が必要なのか、誇りに思っていません。プレートの更新：

（28） 0x5D81214C-crc32カーネルパーティション

（552） 0x37499eef-crc32パーティションFS

（556-1556） -外観が不明なもの

crc32 newcramfsを数え直し、16進数のエディターで、バイナリーのオフセット552に入力し、カメラに入力します。

そして...何もO_O。だから、才能は失望しませんでした-オフセット8では本当にcrc32ですが、何からですか？

ここで私たちは単純に行動します-総当たり攻撃を開始します。

  $ python
 >>> zlib import crc32から
 >>> d =オープン（ "firmware_TS38ABFG006-ONVIF-P2P-V2.5.0.6_20140126120110.bin"、 "r"）。read（）
 >>> hex（crc32（d [12：]））
 '-0x781aca29'＃いいえ
 >>> hex（crc32（d [12：1556]））
 '-0x6f8f1744'＃いいえ
 >>> hex（crc32（d [0：8] + d [12：1556]）
 '0x6d29f056'＃いいえ
 >>> hex（crc32（d [0：8] + d [12：]））
 '-0x652ac4fd'＃いいえ
 >>> hex（crc32（d [0：8] + "\ 0 \ 0 \ 0 \ 0" + d [12：1556]））
 '0x15db8164'＃エラー それ！

よくやった。したがって、プレートを更新します。

（8） 0x15DB8164-CRC32ヘッダー（最初の1556バイト）、最初にこのフィールドをヌルにする

そのため、Pythonですぐに、ヘッダーfirmware_new.binからcrc32をすばやくカウントし、最初に16進エディターに書き込みます。

カメラに注ぐ...彼女は再起動に入ります。そして答えない...答えない...別のレンガ...ああ！ ping go！ふう

cam-resync.pyを取得し、再びカメラをスティックで固定します。そして...そしてストリームは壊れません！すぐに、最初の試行で！ Wiiii :)

パンに塗られており、すでに食べることができますが、何かが正しくありません

一方、前述のAndrei Syomochkinは、修正したrtsp_streamerでファームウェアを収集し、問題のあるカメラの1つにアップロードしました。その結果、UDPでパケットを失ったときと同じように、テストはストリームが壊れないことを示しましたが、ビデオアーティファクトが始まりました。私はこのようなものを何も埋め込まなかったので、私はそれが何であるか興味がありました-私は再びコードを調べなければなりませんでした。まず、文字列を見てください。たくさんのデバッグ行があります。「％d秒のCheckBufferTimeout !!!」、「％dmsを超えるバッファデータ、すべてのバッファデータを削除!!!」。

うん！メーカーがオーバーフロー保護を行っていることがわかりました！また、何らかの理由で同期送信（）が必要以上にハングアップしている場合（デフォルトでは1秒）、超過分はドロップされます。これは、薄いチャネルに収まらない場合にOOMとビデオの遅延から保護します。しかし、ノンブロッキングソケットとsend（）を使用しているため、コードは明らかに以前は機能していませんでした。

Blocking ... NonBlockingでラップした後、コードは機能し始めました:)

ただし、小さな問題があります。1秒では不十分です。チャネルが故障し始めたが、十分に厚い場合、ドロップの確率はより強くなります。このようなドロップの後、ビデオはキーフレームの後にのみ復元されます。通常、キーフレームは非常にまれです（5〜10秒ごとに1回）...そして不快な状況が判明します-障害が発生した場合、次のキーフレームまで5〜10秒待ってからビデオを修復する必要があります。キーフレームの周波数を下げると、キーフレームが非常に厚いため、送信されるデータの量が自動的に増加します。つまり、チャネルが死ぬ頻度が高くなります。悪循環。

一般に、バッファリングタイムアウトを10秒に追加しました。これはOOMをキャッチするには十分ではありませんが、非安定チャネルでの再送信と遅延を静かに通過するには十分なはずです。

ところで、「 "な」治療アルゴリズム

前回の記事で、状況を修正するのがどれほど簡単かを伝えると約束しました。解決策はフェルトブーツのようなものです。RTPパケットを送信するため、それぞれにタイムスタンプがあります。パケットの有効期間を送信する前にsendRTPorRTCPPacketOverTCPをチェックインするだけで十分です。設定された有効期間よりも短い場合（TCPでは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が助けとなり、外部ファイルに状態を保存できます。したがって、fakerootを使用して解凍します。

ただし、それには微妙な問題があります-最後に、ファイルは現在のユーザーが読み取ることができるはずです。「実際の」ルートであれば、「chmod -r」であってもファイルを簡単に読み取ることができます。しかし、fakerootはそのようなファイルを壊します。したがって、解凍後すぐに、すべてのファイルの読み取り権限を変更します。ただし、正しいアクセス権は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の次のパッチが適用されたファームウェアを収集しました。

同じメーカーの他のモジュールの修正が突然必要になった場合は、コメントに書いてください。可能であれば表示します。

ps：これらのファームウェアから何か他のものを必要とする人は誰でも、より便利な場所-githubにスクリプトを投稿しています。

「ではない」バグを修正するにはどうすればよいですか