この話は、Samsung Galaxy Ace 2スマートフォン（別名GT-I8160、別名codina）のコアを使った実験が失敗した結果、デバイスの再起動につながったという事実から始まり、EFSセクションの読み取りが停止したことが判明しました。 実際、実験自体はこの問題とは何の関係もありません-おそらく私はどういうわけかそれらにたどり着きますが、これはこの記事の範囲外です。 EFSセクションはこのスマートフォンで最も重要なものの1つですが、このセクションを殺してもそれ自体が壊滅的な結果につながることはありません。たとえば、必要に応じてWIFI MACとBT MACを変更した後、たとえば別の電話から復元することができるからです このデバイスでは、IMEIはEFSパーティションには保存されませんが、CSPSA（クラッシュセーフパラメーターストレージエリア、文字通り「クラッシュ耐性パラメーターストレージエリア」と翻訳されます）。 さて、このセクションで何かがおかしくなったとしても、それほど面白くありません。実際、これについては後で説明します。 興味のある方は、猫の下でお願いします。



EFSパーティションに障害が発生した後、まずダンプを削除し、e2fsckを使用してそのダンプを上げようとしました。 失敗-EXT4スーパーブロックが破損しており、実際、すべてがセクションの内容がミンチ肉に変わったように見えました。 バックアップを探す時期でしたが、不注意（！）でした。ほとんどの不幸な瞬間に、それは私のコンピューターやフラッシュドライブにはありませんでした。 それ以上の苦痛は、バックアップをタイムリーに行った場合にのみ回避できました。 夕方遅く、インターネット上でこのセクションのダンプを検索し始め、外国のリソースでそれを見つけ始めたので、すぐにそれをフラッシュし始めました。 おそらく、 dd



ユーティリティを使用するときに発生する可能性がある最悪の事態の1つは、パーティションへのパスの入力中のタイプミスまたはエラーです。 今、私は自分自身の不注意（または曲率、あなたが望むものと呼ぶ）に疑問を抱く必要がありますが、それはまさに起こったことです... / dev / block / mmcblk0p6であるはずです。 実際、それ以降は特別な説明は必要ありません;録音中にddがセクションの終わりに達したというメッセージを表示したときにのみ起こったことの壊滅的な性質をすでに理解しました。 私はこのデバイスを何年も使用しており、この神忘れられたデバイスの下に残っている数少ない開発者の一人であるようです。 どちら側でこんなに愚かな状況に陥るのでしょうか？ 私に尋ねることなく、私自身が知りたいです...それで、軽い手で電話は「レンガ」でなくとも「障害者」になりました。

CSPSAセクションスタディ

そのため、ディスクへのアクティブな書き込み中にEFSパーティションがクラッシュしましたが、クラッシュに強いCSPSAパーティションは私の無謀さに抵抗できませんでした。 SCに行くと、おそらく彼らは肩をすくめていたでしょう。 別のデバイスのCSPSAファームウェアでも問題は修正されません。 IMEIは、明らかに、このセクション以外の場所に保存され、CSPSAにあるものと比較されます。 また、この記事はIMEIの変更に関するものではなく、その復元に関するものです。



どう見ても絶望的な状況だと思いました。 CSPSAセクションの内部を選んで、明らかにするつもりはなかったことに明らかに巻き込まれました。 ST-Ericsson Novathor U8500チップセットの2014年にリークしたソースの中には、このセクションで作業できるユーティリティのソースがあることが判明しました 。

 root@:/ # cd ramdisk root@:/ramdisk # ./cspsa-cmd [CSPSA]: open CSPSA0 [CSPSA]: <CSPSA_Open('CSPSA0').> [CSPSA]: <Result 'T_CSPSA_RESULT_OK'> [CSPSA]: ls Key Size 0 4 1 96 2 96 3 96 1000 38 66048 497 -8192 41 -4 4 -3 4 -2 4 -1 4 Number of keys in CSPSA : 11 Total size of all values: 884 [CSPSA]: read_to_file 3e8 /sdcard/1000.bin [CSPSA]: <Read (000003e8) to file '/sdcard/1000.bin'> [CSPSA]: CSPSA_GetSizeOfValue(000003e8): T_CSPSA_RESULT_OK [CSPSA]: <CSPSA_Read(000003e8).> [CSPSA]: <CSPSA_ReadValue(000003e8, 38): T_CSPSA_RESULT_OK> [CSPSA]: <38 bytes written to file '/sdcard/1000.bin'.> [CSPSA]: write_from_file 3e8 /sdcard/1000.bin [CSPSA]: <Write (000003e8) from file '/sdcard/1000.bin'> [CSPSA]: <38 bytes read from file '/sdcard/1000.bin'.> [CSPSA]: <CSPSA_WriteValue(000003e8, 38).> [CSPSA]: <CSPSA_WriteValue(000003e8, 38): T_CSPSA_RESULT_OK>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「open CSPSA0」コマンドはCSPSA0ソケットを開き、cspsa-serverプロセスに接続します。 ご覧のとおり、lsコマンドはCSPSAに保存されているパラメーターとそのサイズを表示します。



さらに、read_to_fileコマンドを使用すると、パラメーター（ここではHEX-3e8で指定された数値1000）をファイルに書き込み、write_from_fileコマンドを使用してファイルからセクションにパラメーターを書き込むことができます。



このようなユーティリティを見つけることができたのは確かに素晴らしいことですが、IMEIが正常に再度読み取られるように、これらのパラメーターに何が含まれているべきかについてのヒントは提供しませんでした。 実際、ユーティリティは、真実の一部を「隠す」ことができ、すべてのパラメーターを公開せず、IMEIが保存されているパラメーターを非表示にすることができます。 これらのパラメーターに何が含まれるかを理解するには、CSPSAのいくつかの異なるセクションが必要でしたが、実際には、そのような個人情報とセクションをマージするように頼むことはできません。 インターネット上のCSPSAには2つの異なるセクションがありましたが、cspsa-cmdを介して読み取られたパラメーターを比較すると、互いに比較すると、合計で約512〜768バイトの大きな差が生じました。 すべての情報源でさえ、私が理解するまでに長い時間がかかる可能性があります（まったく理解できた場合）。 「額」にCSPSAを復元するという考えは、電話の復元に役立つ可能性のあるマージされたソースの他の部分を見て、放棄されなければなりませんでした。



私は有望に見える別のユーティリティに出会いました。



リンクには、このユーティリティでサポートされているコマンドのリストが含まれています。

 (...) static const struct { const char *str; cops_return_code_t (*func)(cops_context_id_t *ctx, int *argc, char **argv[]); } api_funcs[] = { {"read_imei", cmd_read_imei}, {"bind_properties", cmd_bind_properties}, {"read_data", cmd_read_data}, {"get_nbr_of_otp_rows", cmd_get_nbr_of_otp_rows}, {"read_otp", cmd_read_otp}, {"write_otp", cmd_write_otp}, {"authenticate", cmd_authenticate}, {"deauthenticate", cmd_deauthenticate}, {"get_challenge", cmd_get_challenge}, {"modem_sipc_mx", cmd_modem_sipc_mx}, {"unlock", cmd_simlock_unlock}, {"lock", cmd_simlock_lock}, {"ota_ul", cmd_ota_simlock_unlock}, {"get_status", cmd_simlock_get_status}, {"key_ver", cmd_verify_simlock_control_keys}, {"get_device_state", cmd_get_device_state}, {"verify_imsi", cmd_verify_imsi}, {"bind_data", cmd_bind_data}, {"verify_data_binding", cmd_verify_data_binding}, {"verify_signed_header", cmd_verify_signed_header}, {"calcdigest", cmd_calcdigest}, {"lock_bootpartition", cmd_lock_bootpartition}, {"init_arb_table", cmd_init_arb_table}, {"write_secprofile", cmd_write_secprofile}, {"change_simkey", cmd_change_simkey}, {"write_rpmb_key", cmd_write_rpmb_key}, {"get_product_debug_settings", cmd_get_product_debug_settings} }; (...)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前のcspsa-cmdの場合と同様に、cops_cmdはプロセスサーバーcopsdaemonに接続します（COPSはCOre Platform Securityの略です）。



デバイス上のこのcopsdaemonバイナリは、ソース内のものとは異なることが判明しました（またはAndroid.mkを正しく構成できませんでした）。とにかく、ソースからコンパイルされたものは動作を拒否しました。 ただし、cops_cmdユーティリティは他の専用ソフトウェアと互換性があり、正常に起動したようです。



私が最初にやろうとしたのは、 cops_cmd read_imei



実行することでした。今は思い出せませんが、「エラー13、デバイスが改ざんされています」などのcops_cmd read_imei



れました。 ああ、もちろん、CSPSAセクションがめちゃくちゃになっているので、他に何が期待できますか。 ソースの短い読みはbind_propertiesコマンドにつながりました：

 static cops_return_code_t cmd_bind_properties(cops_context_id_t *ctx, int *argc, char **argv[]) { cops_return_code_t ret_code; cops_imei_t imei; (...) usage: (...) fprintf(stderr, "Usage: bind_properties imei <imei> (15 digits)\n" "Usage: bind_properties keys <k1 k2 k3 k4 k5> (keys are space delimited)\n" "Usage: bind_properties auth_data <auth_number> <auth data file name>\n" "Usage: bind_properties data <data file name> <optional don't merge flag 0, otherwise merge will occur>\n"); return COPS_RC_ARGUMENT_ERROR; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ソースからわかるように、この関数はIMEIをデバイスに書き込むように設計されています。 しかし、これは不運です。記録する直前にのみ、秘密鍵を使用して認証する必要があります。秘密鍵は明らかに持っていません。 認証の必要性を回避しようとするために、引き続きcopsdaemonを選択し続けるだけでした。幸いなことに、すべてはそれなしで行われました。

アイデアを求めて

検索と熟考に数日かかりました。 xda-developersと知り合いの1人と話した後、NFCチップを搭載したGT-I8160品種GT-I8160Pには、デフォルトの「ハーフエンプティ」CSPSAセクションを持つファームウェアがあり、このデバイスのこのROMのファームウェアがリードすることがわかりましたIMEIが「無効」であるという事実、つまり、IMEIの15桁すべてがゼロになります（CSPSAパーティションの場合に発生するのか、まったく機能しないのか正確には覚えていません）。 私が最初にしたことは、このファームウェアをダウンロードし、CSPSAセクションをフラッシュすることでした。 同僚がこのROMの部分的なファームウェア（つまり、ブートローダーなどの「危険な」パーティションを含まない個々のパーティションのファームウェア）を提供しました。 非常に無駄なエクササイズであり、最終的にデバイスを「ブリック」する可能性があります。 最後に、数日後、上記のソースコードで忙しかったときに、XDAの同僚が本当に信じられないほど貴重な発見をしました。

 #TA Loader to write default IMEI service ta_load /system/bin/ta_loader recovery user root group radio oneshot
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、Android 4.1.2ストックファームウェアからのラムディスクのinit.samsungcodina.rcファイルの内容のクリッピングであり、コメントで、これがデフォルトでIMEIを復元するサービスであることを明示しています。

二度と考えずに、私はターミナルから走りました：

 /system/bin/ta_loader recovery
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デバイスは再起動して復旧モードになり、その後システムを手動で再起動して、出来上がりました！ IMEIはすでに「null」として表示されていませんが、ゼロに設定されており、ネットワーク登録は利用可能ですが、進行中です。 「無効化された」IMEIの秘密が明らかにされました。



しかし、もちろん、このようなデフォルトのIMEIを使用するのはまったく素晴らしいことではありません。 HEXエディターでta_loaderバイナリーを調べて（このツールのソースはまだありませんでした）、ゼロのIMEIを独自のコマンドで置き換えるには、かなり短い検索で十分でした：

 sed -i "s,<15_zeroes>,<IMEI>," /ramdisk/ta_loader sed -i "s,<IMEI>0,<16_zeroes>," /ramdisk/ta_loader
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

sedコマンドが2回呼び出されるのはなぜですか？ IMEIに関連しないバイナリには15を超えるゼロのシーケンスがあります。したがって、不要な変更を返すには、コマンドをもう一度呼び出す必要があります。 この方法で「左側」のIMEIを記述しようとしても役に立たないことを保証するために急いでいます。ユーティリティは、ボックス（またはデフォルト）からのみIMEIを記述できるように機能します。 もう1回再起動して回復し、次にシステムを再起動すると、見よ、IMEIが配置されます。 XDA Developersフォーラムで回復プロセスについて詳しく説明しました。 そのようなこと、幸いなことに、メーカーが元のIMEIを復元するための抜け穴を残しました。 上記の不運がなかったら、私はおそらくこれすべてをいじくり回すことを決して考えなかっただろう、しかしその一方で、この全体の物語は起こらなかっただろう。