Grandstream電話用のカスタムファームウェアの作成

私たちの会社は最終的にIPテレフォニーに切り替えることを決定し、GXP2130とGXP2160など、さまざまなモデルのGrandstream IP電話を購入しました。 すべては問題ありませんが、これらの電話機のBLFキーは、無料回線の場合、非常に明るい緑色に光り、非常に迷惑です。 以下に、この問題の解決方法を説明します。

脆弱性検索

始めるために、私はbinwalkを通じて電話のファームウェアを実行し、16進エディターを調べました。 結果は動揺し、ファームウェアは暗号化されたため、別の方法で電話自体へのルートアクセスを取得する必要があります。 ほぼ2週間、私はWebインターフェイスのフィールドをフィルタリングする脆弱性を探していました。 いくつかの場所で、syslogdおよびudhcpdコマンドにパラメーターを渡す機会を見つけました。 syslogの場合、これは興味を引くものではありませんでしたが、udhcpdの場合、-sパラメーターを指定して、インターフェースを構成するために実行されたスクリプトを参照することができました。 ここでは任意のコマンドを実行できますが、そのパラメーターを指定することは不可能であり、常にdefconfigパラメーターを使用して実行されました。 この脆弱性を使用して、価値のあることを行うことはできませんでした。 したがって、脆弱性の検索は継続されました。 そして、私は彼女を見つけました！ 正確な場所を教えません メーカーはすぐにそれをカバーすることができ、将来的にはそれがまだ便利になる可能性があります、まあ、それなしでルートアクセスを取得できます。
さらに、メーカーはおそらく、たとえばデバッグのためにルートを取得する可能性を残すべきであり、それを探すことは有用だと示唆しました。 Web経由で実行されたすべてのスクリプトを分析しましたが、同様のスクリプトは見つかりませんでした。 その後、シェルの分析を開始しました。これは、sshを介して入手できます。

シェル分析

sshを介して電話に接続すると、gs_configシェルが表示されます。このシェルから、シェル自体によって処理されたコマンドの小さなリストを入手できます。 ヘルプに記載されていないサービスコマンドがあるかもしれないと提案しました。 このために、私は立ち上げました

strings gs_config 

バイナリ内の行を見て、奇妙な奇妙なものを見ました：

 console fw_setenv console yes gssu /bin/sh 

これらのコマンドをシェルですばやく入力すると、次のことがわかりました。

 Grandstream GXP2130 Command Shell Copyright 2014 GXP2130> gssu Challenge: fb72f22fc5e233ae Response: 

チームはチャレンジに基づいて生成されたパスワードを必要とします
ためらうことなく、IDAにgs_configをロードし、そこでgssu行を探します。

さらに、関数sub_94BCでXFERを渡します

gssuコマンドを入力した後、sub_B254関数が呼び出され、その結果に応じて/ bin / shコマンドが実行されるかどうかがわかります。

この関数に移動してF5を押し、アセンブラーからC ++擬似コードに切り替えます
コードを見ると、チャレンジが最初に生成され、結果のチャレンジが変数sに配置されていることが明らかです。

 printf("Challenge: %s\n", s); 

次に、ユーザー応答からの入力が受信され、応答自体の生成が開始されます

この行は、nvramから管理者パスワードを引き出します。これにより、web faceおよびsshにログインします
次に、変数v13に格納されます。
次に、sub_B254関数のパラメーターである変数v1の内容が分析されます。 その値は、どのコマンドに対してResponseをテストしているのか、そのようなコマンドが3つあるはずであることを示していますが、gssuとconsoleの2つしか見つかりませんでした
gssuの場合、変数v14 の文字列％s：sfTXrhCA2010：％sを取得します
次に、 sprintfを介して、Callenge：sfTXrhCA2010：Passwordという形式の最終行を取得し、変数v27に入れます。
次に、この行のmd5を検討します。

次に、do ... whileループが8回繰り返され、md5の合計の半分を通過して、16進数に変換されます。 次に、入力された応答と比較します。
アルゴリズムは非常に単純です。Pythonでのkeygenの実装は次のとおりです。

 import hashlib import sys challenge=sys.argv[2] pwd=sys.argv[1] secret=':sfTXrhCA2010:' # /sin/sh #secret=':dspg_cordless_config:' #secret=':a50ba3e905c0627eb0a204d82880fb46:' # console str=challenge+secret+pwd md5=hashlib.md5(str).hexdigest() result=md5[:16] print result 

ファームウェアを使用する

さて、電話で永久にrootになる方法を学びました。今度はファームウェアを解凍する方法を学びます。
電話機の実行可能スクリプトをざっと見てみると、スクリプト/ sbin / provisionが見つかります。これは実際に電話機をフラッシュする役割を果たします。
prov_pipe_unpackコマンドを使用してファームウェアが個別のファイルに解凍され、 prov_pipedecコマンドを使用してファームウェアの個別のセクションが復号化されていることがわかります。 実際、これは同じバイナリです。 そのすべての機能を見つけるために、私はそれをIDAに投げ込みました。私たちが興味を持っているチームを見つけました。これらは次のとおりです。

prov_unpack
prov_dec
prov_enc
prov_pack

これがIDAでどのように検索されたかについては触れません。リバースエンジニアリングを容易にするために、gdbserverを電話にダウンロードし、デバッガーでこれらのコマンドを実行しました。
次に、これらのコマンドについて詳しく説明します。
prov_unpack-ファームウェアを個別のファイルに解凍し、次のように開始します。

 prov_unpack gxp1400fw.bin 

解凍結果は現在のディレクトリにあります。
prov_dec-個々のファームウェアファイルを復号化します

 prov_dec nokey gxp1400prog.bin gxp1400prog.bin 

最初のパラメータはファームウェアキーです。工場出荷時のファームウェアの場合はnokeyですが、独自のキーを持つOEM電話がある場合があります。
2番目のパラメーターは、復号化するファイルです
3番目のパラメーター-メーカーの意図によると、これは携帯電話のフラッシュ内の画像に対応するセクションです。プログラムはファイルのバージョンと既にフラッシュされたバージョンを比較し、等しい場合は何もしません。 暗号化されたファームウェアファイルを2番目のパラメーターとして再度指定すると、すべてがスムーズに進みます。 出力は復号化されたファイルgxp1400prog.binです
prov_enc-画像を暗号化して戻しますが、特別な形式の画像が必要です。
画像フォーマットについてさらに詳しく：
イメージは、ヘッダーとsquashfsファイルシステムなどの有用なデータ自体で構成されます。
以下は画像ヘッダーgxp2130prog.binの例です

ヘッダーは最初の0x5Cバイトを受け取ります。形式は次のとおりです。

 struct header { DWORD signature; DWORD version; DWORD size_max; DWORD size; WORD image_id; WORD checksum; WORD ts_year; WORD ts_month_day; WORD ts_time; WORD oem_id; DWORD FW_V_Mask; WORD supported_bits1; WORD supported_bits2; WORD supported_bits3; WORD supported_bits4; WORD HW_id; } 

すべてのフィールドの目的は明確ではありませんが、重要ではありません。主なものを考慮してください。
versionはバージョンです。ファームウェアを電話機にフラッシュする場合、そのバージョンは現在よりも高くなければなりません
size-ファームウェア内の有用なデータのサイズ。このパラメーターはprov_encと暗号化を使用します
チェックサム -ファームウェアのチェックサム。ファームウェアを復号化するときに使用され、一致しない場合、ファームウェアは更新されず、後で生成されます。 日付を修正できることを除いて、残りのヘッダーフィールドは元のヘッダーフィールドのままにしてください。
次に、ヘッダーはサイズ0x5Cまでゼロです
ペイロードはオフセット0x200から取得され、ヘッダーとペイロードの間のスペースがユニットで詰まっています...
これは、復号化されたファームウェアの外観です。この形式では、ヘッダーとともにフラッシュに書き込まれます。
prov_encユーティリティは異なる形式で動作します。 入力には、有用なデータが最初に移動するファイルと、その直後（ファイルの最後）にサイズ0x5Cのヘッダーが必要です。 prov_encは、ヘッダーからペイロードのサイズを読み取り、それらを暗号化してから、ヘッダー自体を暗号化します。 ヘッダーでは常に最初の32バイトのみが暗号化され、残りのバイトは暗号化されません。 暗号化されたファイルを組み立ててprov_packユーティリティファームウェアに戻すには、最初の形式に変換する必要があります。 既に暗号化されたヘッダーをファイルの先頭に移動し、ファームウェアの暗号化された本体をオフセット0x200に配置します。
このようにprov_encを開始します：

 prov_enc nokey gxp1400prog.bin gxp1400prog.bin 

ここのすべてはprov_decに似ています。
prov_pack-暗号化されたすべてのファームウェアファイルを単一のファームウェアに収集し、電話機のファームウェアに対応

 prov_pack nokey gxp1400fw.bin gxp1400boot.bin gxp1400recovey.bin gxp1400core.bin gxp1400base.bin gxp1400prog.bin 

出力では、ファームウェアの準備ができたgxp1400fw.binファイルがあります。
電話自体よりもqemu仮想マシンでこれらのユーティリティを使用する方が便利です。

パッチ緑LED

次に、すべてが開始されたという事実に移り、BLFキーの緑色のLEDをオフにします。
gs_guiプロセスは、電話のGUIを担当します。/app/gui/にあり、/ app / gui / libのライブラリの山を使用します。
/ app / guiフォルダー内のLEDという単語でgrepを作成し、ライブラリlibFramework.so.1.0.0を見つけます。
そこにあるすべての機能には人間の名前があるため、コンピューターにマージしてIDAにロードします。
興味深い名前のturnOnMKPLEDを持つ関数が見つかりました。別のwriteToFile関数が呼び出されます（LEDCOLOR、int、bool）
以下は彼女の作品です。

ご覧のとおり、ファイル/ proc / sys / dev / led / *はLEDを操作するために使用されます
エコー経由でこれらのファイルにデータを書き込もうとすると、prog_greenファイルとprog_redファイルがBLF（MKP）キーを担当していることがわかりました。
したがって、緑色のLEDの点灯を禁止するには、prog_greenファイルへの書き込みを禁止するだけです。 16進エディタで、緑の表の1文字を変更しました。

ここで、パッチを適用したlibFramework.so.1.0.0を電話機に戻す必要があります。 このためのカスタムファームウェアを作成しましょう。
/ appディレクトリはgxp2130prog.binイメージに含まれています。 ファームウェアを解凍し、このイメージを復号化します。 次に、16進エディターで、すべてを0x200のオフセットにトリミングして、squashfsイメージを取得します。
squashfsを使用するには、squashfs-toolsユーティリティのセットが必要です。
Centosディストリビューションのバージョン4.0は解凍できなかったため、ソースからバージョン4.2をビルドする必要がありました
チームを開梱する

 ./unsquashfs gxp2130prog.bin 

コンテンツはsquashfs-rootディレクトリにあります
次に、ファイルlibFramework.so.1.0.0を私たちのものに変更して、パックし直します

 ./mksquashfs squashfs-root new.bin -comp xz -all-root -noappend -always-use-fragments 

次に、見出しを準備する必要があります。 開始するには、元のgxp2130prog.binからヘッダーを取得し、squashfsイメージの最後にコピーします。 次に、バージョンとサイズを修正する必要があります。 サイズは、キャプションなしのsquashfsイメージ自体のサイズです。 次に、チェックサムを計算する必要があります。 生成用のCコードを次に示します（Pythonの場合、何らかの理由で同様のコードが200倍遅く動作しましたが、アームエミュレーションを使用してqemuで開始しました）

 #include <stdio.h> void main(int argc, char *argv[]) { FILE *f; int summ=0; int word; char buff[32]; int i; f = fopen(argv[1],"rb"); if(f) { while(fread(buff,32,1,f) != 0) { for(i=0;i<32;i+=2) { word = buff[i]; word |= buff[i+1]<<8; summ += word; summ &= 0xFFFF; } } printf("%d\n",0x10000-summ); } else printf("Error\n"); } 

次に、前のセクションで説明したように、ファイルを暗号化し、ヘッダーを再配置してファームウェアを収集します。 まあ、それを点滅させます。
元のファームウェアを返す場合は、電話でルートからコマンドを入力する必要があります

 nvram set force_upgrade=1 

そして、電話機はすべてのファームウェアをフラッシュします。 バージョンに関係なく。

興味があれば、Grandstream電話のプロビジョニング（どこにも書かれていないニュアンスがあります）および閉じたweb-apiに関する詳細な記事を書くこともできます。

upd：GXV3140で応答を生成するための秘密がありました。

 :gshz: