SoftBankのIMEI制限回避 SIMロック解除のおまけ付き ～Nexus 5X編～
SO-01Gと引き換えに入手した Nexus 5Xでもできたので報告します。
まずは、QPST_2.7.422を展開して、qpstをインストールしてください。
3個置き換えましたと出たら 成功です。
手順はどうも N5Xに限らず、Qualcomm機で行けるのは行けるっぽいです。
(私はXiaomi Mi4の手順をそのままやったら行けました。)
調べると結構出てくる方法なのでざっくり説明します。
あと注意点として.....
※IMEIの書き換えを行うにあたって
必ず自身で契約し 自身で所持している
SoftBank端末のIMEIを使用してください。
IMEIを書き換えた場合、
今回なら Nexus 5XのIMEIを出荷時に戻すまで、
もとのSoftBank端末は絶対に手放したり、Nexus 5Xも売ったり処分しては
いけません。
また、この記事における内容のすべてにおいて責任を放棄しています。
問題や訴訟、その他実行した人や周辺の方に不利益な事柄等生じても
私、Kiraは一切の責任を取りません。
すべて自己責任において実行してください。
また、この内容通りにやっても同じように行かない可能性もあります。
その場合も自己責任です。
このことに少しでも疑問を感じる場合は 実行しないでください。
端末の状態としては Y!mobile版のSIMロックかかったままのNexus 5Xです。
ですがこの手順を実行すると SIMロックが勝手に外れます。
(書き換え前はネットワークキーを求められた)
Y!mobile版を安く仕入れて適当なIMEIにすれば
単純にSIMロック解除の方法しても使えます。
解除済みは高いしね！
では、紹介します！
---------------------------------
A.前準備
adb/fastbootを使用するので platform-toolsをダウンロード/Pathを通します。
このあたりを参考にするといいと思います。
終わったら一応再起動しておきましょう。
その後、書き換えの主役をダウンロードしてください。
最後になんでもいいですが、バイナリエディターも落としておいてください。
(私はStirlingを使いました。)
---------------------
B.環境整備
主役をダウンロードしたら、展開してください。
展開したら 以下のファイルが転がっていると思います。
(QPST.2.7.422.msiとsetup.exeがありますが、setup.exeでokです)
QualcommDrvとQualcommSetupは気にしないでokです。
終わったらNexusの操作です。
------------------------------
0.最新版に上げる
とりあえず 最新版にアップデートしておいてください。
(OPM7.181205.001のはず)
-----------------------------
1.ブートローダーをアンロックする。
パス通ってる前提です。
設定→システム→端末情報→ビルド番号連打→開発者オプション
→OEMロック解除をON
USBデバッグonしたら、
adb reboot bootloader
fastbootが起動するので(ドロイド君にSTARTの画面です)
fastboot flashing unlock
音量大→決定
そのままもう一度電源を押し、初期設定画面が出るまで待つ。
起動したら設定は全部スキップし、ホームにたどり着く。
また開発者オプションでUSBデバッグをonにしておきます。
2.twrpとmagiskをインストール
Root化が必要なので TWRPとMagiskをインストールします。
(SuperSUでも良いけど私がMagisk信者なのでw)
TWRPはここ
Magiskはここ
そしたらまた
adb reboot bootloader
fastbootが起動したら
fastboot flash recovery のあと ダウンロードしたtwrp******.imgを
コマンドプロンプトにドラッグアンドドロップすると そのままイメージが
指定されるので そのままenter。
FINISHEDとコマンドプロンプトに出たら、
Nexus側の音量下を何回か押し Recoveryになったら電源押して
TWRP起動。
TWRPが起動したらなんか出るので そのままスワイプする
Nexus 5xとPCを接続して Magis-V**.*.zipをコピーし
インストールする
このサイトの 5項がわかりやすいかも？
再起動後 しばらく待って 一回 Magisk Managerを起動する
3.書き換え！
いよいよ書き換えです。
まずは diagモードに入るために
adb shell
su
setprop sys.usb.config diag,adb
これでしばらく待ちます。
デバイスマネージャーに Qualcomm HS-USB Diagnostics 903Dがアレば
okかと思います。
(末尾4桁は違うかも？)
できたら、スタートからQPST Configlationを起動します。
起動後、 Portsタブに移動して
State項目がEnabled、PhoneがMSM8994というものがあるはずです。
こうなっていたら、
上のメニューバーの Start Clientsから Software Downloadをクリックします。
そうすると QPST Software Downloadというものが起動するので
Backupタブをクリックします。
次に、わかりやすくするため
QCN Fileの横の Browseをクリックして、わかりやすい場所に保存してください。
画像の例では デスクトップの sbmフォルダに n5x.qcnという名前で保存します。
そしたら Startをクリックして しばらく待ちます。
Memory Backup Completedと出たら
n5x.qcnをバイナリエディターで開きます。
同時に IMEI Converterも起動してください。
(.NETのインストールが求められたらしてください)
まず、Nexus 5XのIMEIを確認して
IMEI ConverterのENTER IMEI欄に 5xのimeiを入れて
CONVERT IMEI してください。
例えばIMEIが 「356123456789123」だとしたらこうです。
CONVERTED IMEIの中身(HEX)をコピーして
バイナリ内から検索して見てください。
3つ一致するはずです
そうしたら今度は IMEI Converterを一度閉じて 開き直して
SoftBank端末のIMEIを入力してCONVERT IMEIして、
HEXをコピーしてください。
SoftBank端末のIMEIが「356123412341234」だとして話を勧めます。
Stirlingの場合、メニューバーの検索・移動から 置換で
検索データにNexus 5XのIMEIのHEXを、
置換データに SoftBank端末のIMEIのHEXを貼り付けて
データ種別を16進データ。
置換範囲を データ全体にして 一括置換をクリックしてください。
今回の場合、qcnファイルの中身を置換した後
n5x.qcnとn5x.qcn.bakがありますが 置換済みはn5x.qcnです。
n5x.qcn.bakは n5xshipment.qcnなどにして保管しておくと
imeiをもとに戻すのに楽できます。
いよいよ書き換え本番です。
NVをリストアするには modemst1/2とfsgを消し飛ばす必要があるので
まずは fsgを消し飛ばします。
adb reboot bootloader
fastboot起動後
fastboot erase fsg
FINISHEDとコマンドプロンプトに出たら、
Nexus側の音量下を何回か押し Recoveryになったら電源押して
TWRP起動。
BackupからEFSだけバックアップ。
終わったら
PCにつないで QPSTのとかが入ってたフォルダーにある
EraseModemフォルダを
TWRP/BACKUPS/シリアル(英数字の羅列)のフォルダ内にコピーしてください
こうなるはずです。
そしたらTWRP側で Restoreを開きます。
EraseModemというのがあるはずなので タップしてリストアします。
終わったら再起動します。
このとき設定からIMEIを見ると 0 になっていると思います。
なっていたら正解です。
0になったのを確認したら
再び diagモードに入るために
adb shell
su
setprop sys.usb.config diag,adb
diagモードに入ったら
QPST Software Downloadを再び開き
Restoreタブを開き QCN Fileがn5x.qcnになっているのを確認した上で
Allow phone/file ESM mismatchにチェックを入れ Startをクリックします。
Memory Restore Completedと出たら完了！
書き換え完了です！！
ただ時間がかかるので のんびり待ちましょう。
---------------
最後にAPN設定についてですが、
fourgsmartphoneが正しいはずなのですが
Y!MobileのAPN、 plus.acs.jpで自動接続され データ定額内に収まってるので
特にsbmapmgetter使わなくても Nexus 5Xでは良さそうです。
ついでにVoLTE使えました！(HDアイコン)
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="480" height="251"><rect fill-opacity="0"/></svg>)
この記事へのコメント
いくつか教えて頂きたいのです
nexus4の4.2.2のバージョンです
デバイスマネージャーに Qualcomm HS-USB Diagnostics 903Dが現れず
ほかのデバイス
CDC Serial と Nexus 4 が３個(みんな不明なデバイス）です
QualcommDrv を編集する必要があるのでしょうか
それと、TWRPのバックアップの項目に EFSがありません
他の端末のベースバンドは書き換えた事はあるのですが
突然の質問で恐縮ですが、宜しくお願い致します。
コメントありがとうございます。
確かNexus 4はLGのドライバーを入れないとダメな気がするので、LG United Mobile Driverをインストールしてください。
また Qualcomm HS-USB...のポートはNexus 4では多分出ないので
LGE AndroidNet for Diagnostics Portのポートを使用してください。
TWRPのEFSのあれはNexus 5Xでは使えたので なるべく操作ミスを起きづらくするためにああしてあります。
なので EFSを吹っ飛ばす際はバックアップをとった上で
TWRPのターミナルから dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/efs で飛ばせるかもしれません。
が、私自身はNexus 4を所持していないので検証できません。すみません。
of=以降のパスは予想なので /dev/block/platform以降のパスは確認をしてください。
進んでいけばどこかに by-nameのあるフォルダーに出るはずです。
なにか他にありましたら遠慮なくコメントどうぞ！
早々のご回答、恐れ入ります
私はコマンドとかは、猿以下のド素人です
Kiraさんと同じ端末にすれば問題はないのでしょうが
かさばらない Nexus 4 を選んでしまいました
取りあえず LG United Mobile Driver 等ツールは
ひととおり揃えてはいるのですが、猿以下のスキルでは
情報をくださる皆さんが、頼りです
QPSTでQCN Fileを作ってQCN Fileを任意のIMEIに編集し
TWRPを起動させた状態で、EFSを吹っ飛ばすコマンドを打ち
TWRPにEFS項目がないので、編集済みのQCN Fileを戻すコマンドを打つと言うことでしょうか
QPSTのレストアは使えないのでしょうか
トンチンカンな質問で恥ずかしいのですが
お暇な時にでも、宜しくお願い致します。
度々、申し訳ありません
QPSTでレストアですね 重要なのはEFSを吹っ飛ばす事なのですね
それと かくいちさんのブログの
efs.imgの件ですがパソコンにコピーできないのですが
なにか方法があるのでしょうか。
いえいえ！猿以下なんて...スマホいじり始めた頃は私もそんな漢字でした。何台壊したかわかりませんｗ
さて、本題に入ります。
大まかにはあっていますね。
Nexus 4で使えそうな手順をわかりやすく言うと
1.Nexus 4側でdiagモードにする(記事本文3番)
2.QPSTでqcnファイルをバックアップする
3.QCNに入ってるIMEIをPC側で書き換え
4.fastbootモードに移動し fastboot erase fsg
5.TWRPに入ってefsを飛ばすコマンドを打つ(バックアップとかそういうのはここではナシ)
6.再起動し、再度diagモードに
7.QPSTで書き換えたqcnで復元という流れになります。
書き換えには結果的にqpstの復元を使います。
また、ここまで書いておいてアレですが
Androidをバージョンアップしてはどうでしょうか？
Android 4.2だと何かと不便が多いでしょうし、こだわりがなければAndroid 5.1まで上げたほうがいいと思います。
ご回答感謝いたします バージョンアップの件ですが
Xperia LT26Wのベースバンドを書き換えたときに
カスタムロムの6.0.1では無理で、4.1.2に戻したら成功したので
今回も出来るだけ初期版に近い状態におとしました
カスタムロムで問題ないようならAndroid 6.0 Marshmallow くらい迄は
上げたいと思います
お言葉に甘えて、図々しく質問させてください
Nexus4はこのように表示されました
C:\Users\HP>adb shell
shell@android:/ $ su
root@android:/ # cd /dev/block/platform
root@android:/dev/block/platform # ls
msm_sdcc.1
root@android:/dev/block/platform # msm_sdcc.1
sh: msm_sdcc.1: not found
127|root@android:/dev/block/platform # cd msm_sdcc.1
root@android:/dev/block/platform/msm_sdcc.1 # cd by-name
root@android:/dev/block/platform/msm_sdcc.1/by-name # ls -l
lrwxrwxrwx root root 2019-12-24 18:47 DDR -> /dev/block/mmcblk0p24
lrwxrwxrwx root root 2019-12-24 18:47 aboot -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2019-12-24 18:47 abootb -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 2019-12-24 18:47 boot -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2019-12-24 18:47 cache -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 2019-12-24 18:47 grow -> /dev/block/mmcblk0p25
lrwxrwxrwx root root 2019-12-24 18:47 m9kefs1 -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2019-12-24 18:47 m9kefs2 -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2019-12-24 18:47 m9kefs3 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2019-12-24 18:47 metadata -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 2019-12-24 18:47 misc -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 2019-12-24 18:47 modem -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2019-12-24 18:47 persist -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 2019-12-24 18:47 recovery -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2019-12-24 18:47 rpm -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2019-12-24 18:47 rpmb -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 2019-12-24 18:47 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2019-12-24 18:47 sbl2 -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2019-12-24 18:47 sbl2b -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2019-12-24 18:47 sbl3 -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2019-12-24 18:47 sbl3b -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2019-12-24 18:47 system -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 2019-12-24 18:47 tz -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2019-12-24 18:47 tzb -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 2019-12-24 18:47 userdata -> /dev/block/mmcblk0p23
root@android:/dev/block/platform/msm_sdcc.1/by-name #
流れ的には QPST Configrationでバックアップ＞qcn編集＞efs,fsgの０埋め
＞QPST Configrationで編集済みqcnファイル指定してリカバリ
このように理解しています
私の環境ではどの領域を０埋めすればいいのでしょうか
もちろん各領域のバックアップを取って実行するつもりです
ご指導、宜しくお願い致します。
Nexus 4について色々調べたのですが、
結論として QPSTでは書き換えはできない可能性が高いと判断しました。
というのも知人からNexus 4を借りることができたので 検証したのですが、私の方でも何故か diagモードに入れずqpstでそもそも扱えませんでした。
また、fsg/efsに該当するパーティションもどれかわからないため、完全に手詰まりです。。。申し訳ないっ！
Octoplus LGという有料ツール(多分BOXかドングル購入も必要)を使えば可能なようです。
お役に立てず申し訳ありませんでした。
わざわざ検証までして頂いて、ありがとうござます
qpstでバックアップを取り編集まではできたのですが
やっぱりfsgを消すコマンドでエラーです
efsは多分、m9kefsじゃないかと思うんですが
何分、そもそもfsg,efsがなんなのかも解らない状況です
もう少しネット検索したりして学びたいと思います
年末のお忙しいところ、お手をとり申し訳ありません
ご指導感謝いたします
どうぞ、良いお年をお迎えください。
度々、恐れ入ります
fastboot erase fsgなしのまま
TWRPターミナルから
dd if=/dev/zero of=/dev/block/mmcblk0p8
dd if=/dev/zero of=/dev/block/mmcblk0p9
dd if=/dev/zero of=/dev/block/mmcblk0p10
実行後 QPST Restoreから
端末情報のIMEIが変更されました
ありがとうございました。
なんと...fsgとかその辺りを飛ばさなくても良かったとは......。
あとはm9efs1/2/3まとめて飛ばして細かいことをせずQPST Restoreで行けたんですね！
勉強になりました。
IMEI書き換えできてよかったです。
もし生獣さんがよろしければ、記事にしたいと思うのですがよろしいですか？
こんばんは
記事の件、全然問題ありません
あれからMarshmallowを入れてみました
IMEIは書き換えた状態で一安心です。
よかったです...
ぜひとも書き換えできたNexus 4と共によいお年をお迎えください！
C:\Program Files (x86)\Qualcomm\QPST には見つかりませんでした。
Nexus5x側の /sdcard/twrpにも見つかりませんでした。
何卒よろしくお願いいたします。
>tさん
>
>EraseModemのファイルがどこにあるか教えていただけないでしょうか？
記事中でダウンロードしたn5x_imeirepairkitの中の一番最初の場所（QPSTなんたら.zipとかあるところ）にありますよ
ありがとうございました
かくいちさんのブログでRedmi note 9S の件でコメントさせて頂いてます、yoooossyaです。
いろいろと教えて頂きたくコメントさせて頂きます。
modemst1/2とfsgをもう一度吹き飛ばし起動できましたが、root化して、qcnで書き戻しすると再度起動しなくなりました。
再起動を繰り返す状態です。
本ブログでは『Memory Restore Completedとでるまで時間がかかります』とありますが、どの位かかるんでしょうか？
書き戻しした時は１分もかからずにMemory Restore Completedとなりました。
何か復活させる方法はあるますでしょうか・・・。
かくいちさんのブログでも返信してくれていたのに気が付きませんでした...すみません！
Memory Restore Completedまでにはだいたい5～6分程度です。
Redmi Note 5は3分程度だったので新しい端末だと短いのかも知れません。
吹き飛ばしたら起動しましたか...
ただそれを書き換え前のものであってもqcnを書き戻すと再度文鎮となるとちょっと厳しい気もしますね...
別の書き込みがイメージが確認できた時点で起動しないようにしてある感じがしますね
しかしなかなか厳しいですね..
心が痛みますが、twrpで全パーティションをごにょっとして本格的に文鎮にして
保証適応なんて手があったり...(以前に一度やりましたが心が本当に痛むのでそれっきりやっていません。)
ありがとうございます。起動できたので元に戻せると思ったのですが甘かったです･･･。
事前にmodemst1/2とfsgのバックアップを取っていれば、復活も可能なのでしょうか？
バックアップの方法も分かりませんが･･･。
最悪もうひとつ端末をゲットして、その端末のmodemst1/2とfsgファイルを移植して、同じIMEI端末を二個作ろうかと･･･。
理論上はその通りです。
正常に動くRN 9sからEFSをバックアップして、それから戻せば同じIMEIの端末が出来るはずです。
TWRPのBackupに EFSというものはありませんか？
ない場合は、私がコマンドを教えますので （端末毎に変わります）その結果をコピペとかしていただければバックアップは取れると思います。
...ただ、私が若干危惧しているのは EFS領域までハッシュチェックなどしているとしたら その手を使っても文鎮化する恐れがあります。
今まである程度私がいじった端末の中では IMEI書き換えはしないまでも あまりその領域まで整合性チェックしてる端末は見たことがないので （日本メーカーは除くけど）、おおよそいけるとは思うのですが...
確定的に大丈夫といえる根拠もないので結構リスクは高いかなぁと思います。
TWRPのBackupに EFSの項目はあるのですが、バックアップすると最後にエラーと出てバックアップが取れません…。
移植も厳しいかもしれませんね…。
もう1端末同じの買うのなら、確実にIMEI変更できそうなUMIDEGI買おうかなぁ…(^-^;
EFSのバックアップは手元のRN 9sだともう壊滅的にダメになってるので多分失敗すると思います。
あくまで正常動作してることが前提なので…
UMIDIGIは書き換えかなり楽ですねw
S5 Proなんかは値もUMIDIGIにしてはかなり高いですが、Redmi Note 9sと張れるとかそんな話を聞きました。
防水が必須でないのであればUMIDIGIもいいと思いますよ！
諦めきれずに試行錯誤してます。
Maui toolでできないかと…。
yutubeで書換えしてるのを見てると『Qcfire』ってアプリを使っている様で…。
Qcfireって何なんでしょう？
インストールして起動しようとすると「ドングルを挿せ」的なエラーが出て起動しないし…。
ググってもCrack版の様な情報しか出てこないですし…。
ドングルで起動できるなら買っちゃおうかな…とも思うのですが、販売サイトとかにもたどり着けないですし…。
Maui meta toolのことですかね... それはMediaTek SoC端末専用のツールなのでRN 9sには残念ながら使えないのです...
Qcfireは見た感じ Qualcomm SoC端末のファーム書き換えなどに強いツールっぽいですね。
詳しくはあっているかわかりませんが
画面内の項目を見ている限り
特定のファイル(saharaというパーティション構成なども含んだ完全なファームウェアイメージと私は理解しているもの)を
用意できると多分完全文鎮からも復帰できそうに見えます。
ただそのファイルがほぼ手に入らないのでどうにもならないんですが..w (EFSはおおよそこれでは戻りません。それぞれ違います)
Qcfireは見ている限りはEFS周りも復元やリセット？できるそうですしその一環でもしかするとIMEIを新規書き込みできるかもしれません。
これも確証がないのでなんとも言えませんが...
Added Xiaomi IMEI RSA..と書いているサイトもありますが
2019年のもので RN 9sに使えるかは結構疑問ですｗ
最新版について調べようと思うと crack系ばかりで役に立たず...
ドングルに関してはこちらで調べたところ UMT dongleかNCK Pro boxが必要なようです。
こちらで調べられたあくまで一例ですがリンクを乗っけておきます。
・Qcfilの情報集めに使ったサイト
https://forum.hovatek.com/thread-26907.html
・NCK Pro box
https://amzn.to/3fIIyMc (高っかいです。めちゃ高い。)
http://www.nckshop.com/index.php?route=product/product&product_id=181
これが直販なんでしょうか？ 100ドルほどです。
https://gsmserver.com/nck-pro-box-with-cables-nck-box-plus-umt/
90ドル弱です。
UMT dongleについては AliExpressあたりで調べたら結構出てきました。
5000円程度でしょうか...
https://ja.aliexpress.com/w/wholesale-umt%20dongle.html
これらのドングル or ボックスを用意して あとはサイト通りにやれば立ち上がるんだと思います。
個人的にはワンチャンス狙える気もします。
他にも気になることやわからないことがありましたら
コメント遠慮なくどうぞ。
持ってる知識を総動員してがんばりますｗ
いろいろ調べて頂いてありがとうございます。
ドングルも販売してるんですね…、付属品でケーブルが沢山付いてて敷居が高そうです…。
また何かあれば質問させて下さい。
たびたびすみません。
今後するかもしれない、redmi note 9sのファイル移植のために実験をしたく教えて下さい。
①０で上書きしたmodemst1、modemst2、fsgをPCに保存する。
②QPSTでIMEIファイルを書き戻して、再起動を繰り返す端末にする。
③TWRPを起動してコマンドでPCに保存したmodemst1,2,fsgファイルを端末に転送する。
これで端末が起動できるなら、移植の可能性も高いですよね？
端末のファイルをPCに保存する方法、また端末に戻す方法を教えて下さい。
ググって自分なりにしてみましたが上手くいきませんでした･･･。
コマンドで分かった端末情報は
/dev/block/platform/soc/1d84000.ufshc/by-name
fsg -> /dev/block/sdf4
modemst1 -> /dev/block/sdf2
modemst2 -> /dev/block/sdf3
となってました。
よろしくお願いいたします。
そうですね。
その手法で起動ができるなら、移植可能な確率は高くなると思います。
端末のファイル(=イメージ)をPCに保存する方法は、一度端末の内部ストレージ(PCに接続したときに見える場所)に一旦保存し PCにコピーする手法をとります。
twrp起動状態 or rootなadb shellに入った状態で
dd if=/dev/block/platform/soc/1d84000.ufshc/by-name/fsg of=/data/media/0/fsg.img
↑fsgを内部ストレージにバックアップ
dd if=/dev/block/platform/soc/1d84000.ufshc/by-name/modemst1 of=/data/media/0/modemst1.img
dd if=/dev/block/platform/soc/1d84000.ufshc/by-name/modemst2 of=/data/media/0/modemst2.img
↑modemst1/2を内部ストレージバックアップ
その後、PCに接続して内部ストレージにある さっきの fsg.img、modemst1と2.imgをドラッグ&ドロップでOKです。
全部コマンドで済ませたければ
adb pull /data/media/0/fsg.img
adb pull /data/media/0/modemst1.img
adb pull /data/media/0/modemst2.img
でいいと思います。(どちらも結果は同じなので好みの方法でどうぞ！)
逆に、端末に戻すには
さっきのimg群を 内部ストレージのルート(DCIMとかあるところ)にコピーして
dd if=/data/media/0/fsg.img of=/dev/block/platform/soc/1d84000.ufshc/by-name/fsg
dd if=/data/media/0/modemst1.img of=/dev/block/platform/soc/1d84000.ufshc/by-name/modemst1
dd if=/data/media/0/modemst2.img of=/dev/block/platform/soc/1d84000.ufshc/by-name/modemst2
で書き戻し完了です。
(if=とof=以下のパスが逆になってます)
ここからは私が気になるだけなんですが、
場合によっては他のパーティションも怪しかったりするので もし時間があれば
全パーティションの情報をコメントに書いていただけないでしょうか？
shellに入った状態で
cd /dev/block/platform/soc/1d84000.ufshc/by-name/
のあと
ls -l
でズラぁぁっと出るはずなので それを全部コピペしてください(コメント欄なので文字数大丈夫かわかりません。できなかったらすみません)
お返事ありがとうございます。
早速実験してみます。
端末のリストを記載します。
curtana:/dev/block/platform/soc/1d84000.ufshc/by-name # ls -l
total 0
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 ALIGN_TO_128K_1 -> /dev/block/sdd1
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 ALIGN_TO_128K_2 -> /dev/block/sdf1
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 abl -> /dev/block/sde8
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 ablbak -> /dev/block/sde24
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 aop -> /dev/block/sde1
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 aopbak -> /dev/block/sde17
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 apdp -> /dev/block/sde35
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 bluetooth -> /dev/block/sde5
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 bluetoothbak -> /dev/block/sde21
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 boot -> /dev/block/sde51
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 bootbak -> /dev/block/sde55
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 cache -> /dev/block/sda13
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 catecontentfv -> /dev/block/sde49
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 catefv -> /dev/block/sde48
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 cateloader -> /dev/block/sde41
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 cdt -> /dev/block/sdd2
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 cmnlib -> /dev/block/sde11
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 cmnlib64 -> /dev/block/sde12
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 cmnlib64bak -> /dev/block/sde28
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 cmnlibbak -> /dev/block/sde27
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 cust -> /dev/block/sda7
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 ddr -> /dev/block/sdd3
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 devcfg -> /dev/block/sde13
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 devcfgbak -> /dev/block/sde29
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 devinfo -> /dev/block/sde33
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 dip -> /dev/block/sde34
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 dsp -> /dev/block/sde9
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 dspbak -> /dev/block/sde25
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 dtbo -> /dev/block/sde52
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 dtbobak -> /dev/block/sde54
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 exaid -> /dev/block/sda14
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 ffu -> /dev/block/sda16
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 frp -> /dev/block/sda5
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 fsc -> /dev/block/sdf5
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 fsg -> /dev/block/sdf4
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 gsort -> /dev/block/sda15
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 hyp -> /dev/block/sde3
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 hypbak -> /dev/block/sde19
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 imagefv -> /dev/block/sde15
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 imagefvbak -> /dev/block/sde31
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 keymaster -> /dev/block/sde10
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 keymasterbak -> /dev/block/sde26
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 keystore -> /dev/block/sda4
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 limits -> /dev/block/sde38
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 logdump -> /dev/block/sde42
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 logfs -> /dev/block/sde40
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 mdtp -> /dev/block/sde7
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 mdtpbak -> /dev/block/sde23
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 mdtpsecapp -> /dev/block/sde6
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 mdtpsecappbak -> /dev/block/sde22
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 metadata -> /dev/block/sda12
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 minidump -> /dev/block/sda6
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 misc -> /dev/block/sda3
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 modem -> /dev/block/sde4
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 modembak -> /dev/block/sde20
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 modemst1 -> /dev/block/sdf2
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 modemst2 -> /dev/block/sdf3
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 multiimgoem -> /dev/block/sde44
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 multiimgqti -> /dev/block/sde45
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 persist -> /dev/block/sda2
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 qupfw -> /dev/block/sde14
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 qupfwbak -> /dev/block/sde30
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 recovery -> /dev/block/sda8
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 recoverybak -> /dev/block/sda9
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 secdata -> /dev/block/sde47
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 splash -> /dev/block/sde37
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 spunvm -> /dev/block/sde36
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 ssd -> /dev/block/sda1
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 storsec -> /dev/block/sde43
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 super -> /dev/block/sda17
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 toolsfv -> /dev/block/sde39
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 tz -> /dev/block/sde2
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 tzbak -> /dev/block/sde18
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 uefisecapp -> /dev/block/sde16
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 uefisecappbak -> /dev/block/sde32
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 uefivarstore -> /dev/block/sde46
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 userdata -> /dev/block/sda18
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 vbmeta -> /dev/block/sde50
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 vbmeta_system -> /dev/block/sda10
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 vbmeta_systembak -> /dev/block/sda11
lrwxrwxrwx 1 root root 16 1970-03-25 14:01 vbmetabak -> /dev/block/sde53
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 xbl -> /dev/block/sdb1
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 xbl_config -> /dev/block/sdb2
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 xbl_configbak -> /dev/block/sdc2
lrwxrwxrwx 1 root root 15 1970-03-25 14:01 xblbak -> /dev/block/sdc1
ありがとうございました。実験成功しました。
起動不能にした後、TWRPからファイルを戻したことろ無事に起動できました。
移植が可能っぽいので、少し希望がでてきました！
おおおぉぉぉぉぉ！それは本当によかったです！
こちらも先程コメントで教えていただいたパーティション一覧をじーっと見てましたが あまりそれらしきパーティションも見当たらず..
そして今回の起動可能だった報告をみて 多分 fsgとmodemst1/2で大丈夫そうかなと思います。
よかった...希望が見えた....w
試行錯誤とは並行して、Xiaomiのサポートともやりとりしてました。
———————-サポートより——————-
ご購入から一年以内（付属品は半年以内）かつメーカー責による修理費用：無償
※万が一お客様責任による故障と診断された場合
（外部からの衝撃による損傷、パネル破損、水没判定、基板腐食など）や、新品端末のご購入日、または端末製造日から一年以上の場合は有償修理となり、修理費用またはキャンセル料と、弊社までの片道送料が発生致します。
※修理をキャンセルしようとする場合は、弊社までの片道送料と診断料5500円をお支払いください。
———————————————————-
との事でした。
起動しない状態にして送ったら、無償修理にならないですかね？
『修理キャンセルで5,500円…』
が気になってます…。
ゴニョゴニョして完全文鎮にしないとダメですかね…。
起動しない状態とは qcnを書き戻してた時のような状態ということでいいですか？
だとすると、もしかしたら改造がバレちゃうかもしれません。
一応電源が入っちゃうので 診断とかそのあたりができてしまう可能性が....
前にHuaweiでの話ですが P8liteが買って半年後に突然死してしまったので
IMEI書き換え状態のまま出すしかなかったので 修理に出しましたが
その時は無償で交換になったので大体どの会社も保証期間内ならこんな感じだと思います。
なのでゴニョゴニョして完全文鎮にしたほうがいいと思います。
Xiaomiには申し訳ないですが...これが多分確実です
もしゴニョゴニョするつもりでしたら
この間教えていただいた パーティション情報をもとにすると
こんな感じでいいと思います。
shellに入って
dd if=/dev/zero of=/dev/block/sda
3分待って CTRL+C 同時押しで中断
dd if=/dev/zero of=/dev/block/sdb
3分待って CTRL+C 同時押しで中断
dd if=/dev/zero of=/dev/block/sdc
3分待って CTRL+C 同時押しで中断
dd if=/dev/zero of=/dev/block/sdd
3分待って CTRL+C 同時押しで中断
dd if=/dev/zero of=/dev/block/sde
3分待って CTRL+C 同時押しで中断
dd if=/dev/zero of=/dev/block/sdf
3分待って CTRL+C 同時押しで中断
多分これでパーティションが0で上書きできます。
パーティション構成もすべて0で埋まってグチャグチャになるので
sdfまでやって 再起動すると
うんともすんとも言わない状態になると思います
ありがとうございます。
ゴニョゴニョしてから発送したいと思います。
度々すみません。
ゴニョゴニョする前に、再度確認させて下さい。
今現在、Lineage OSを入れており起動できてます。
以前お伝えしたファイルリストもLineage OSのものです。
ゴニョゴニョするときは、Lineage OSのまま行えばいいのでしょうか？
Mi Flashで初期ROMに戻すとファイル構造が変わっちゃいますよね？
カスタムROMを入れてる痕跡を消さなきゃ…、と初期ROMに焼き直す事ばかり考えてました…。
ふと気になって…。
Lineage OSのままでOKです。
MiFlashで戻してもいいですが、それっきりカスタムROMに戻れずゴニョゴニョできなくなっても困っちゃうので…
起動しなくなると改造判定は下せないので大丈夫かと思います！
コマンド打ってます。
上から順番に
dd if=/dev/zero of=/dev/block/sda
3分待って CTRL+C 同時押しで中断し
次の/sdb
/sdc
/sdd
/sde
/sdf
は write error:No space left on device
となりました…。
大丈夫でしょうか…、端末はまだ再起動してません…。
ありがとうございました。
できることを再度やろうと
dd if=/dev/zero of=/dev/block/sda
を打って放置してたら、端末が真っ黒になり電源ボタンを押しても何も反応しなくなりました。
おめでとうございます（なのか！？）
無事にゴニョゴニョ成功です！
あとは修理に出すだけですね。
無事に交換出来ることを祈ってます（たぶん行けると思います）
本当にありがとうございました。
結果はご報告させて頂きます。
コメントありがとうございます。
タブレットのAPNは Androidタブレット用のSIMでしたら、確かスマホ向けのものと同じはずなので fourgsmartphoneでいけます。
つまり記事内のAPN設定でそのまま可能です。
APNのIDとPASSはSBMAPNGetterで吸い出してください。
＞802LGにご興味あったりしますか。
そうですね... ないわけではないですね。
なんと言ってもまだ数少ない大手キャリア向け MediaTek端末ですし機会があれば触ってみたいです。
EngModeなどどうなっているのか気になりますね。
ご無沙汰しております。
本日、やっとredmi note 9Sが戻ってきました。
お陰様で、修理費は取られる事なく部品交換された様で、IMEIなど別の番号に変わったものとなってしましました。
『新品が送られてくるかな？』
と期待していたので少し残念な感じはありますが、無事に直ったので良かったです。
kira様には色々教えて頂き、満足のいく結果が得られました。
本当にありがとうございました。
新品じゃないのはちょっと残念でしたけど無償修理でよかったですね！
うまく行ったようで安心しました
（TWRPでバックアップしていたEFS,fsgのリストアですぐに復活できました。）
使ったROMはストックROMの最新版（11.0.11.0）で、ブートループと言ってもOSは一度完全に立ち上がり、モバイル通信のアンテナが立つ瞬間に落ちてしまうといった感じです。
書き換えたqcnが不完全なんでしょうかね～。
（qcn内でIMEIに該当する箇所が1つだけでした。）
何とかできそうでできないのがもどかしい…もし何か他にできそうなことがあれば是非ご助言をお願いいたします。
コメントありがとうございます。
挙動的には惜しいなぁとは思いますがつながらないんですね...
もしかしたらですが(あくまで予想です) IMEIのあるEFS領域を検証するデータがどこかにあって、
それと照らし合わせてデフォルトのIMEIと合わない場合再起動するという挙動なのかな？？
と思いますね...
qcnが不完全な可能性もありますがなんとも言えないですね...
modemst1,2あたりになんだか他にも役割がありそうな気もします。
OnePlus端末なのですがmodemstとfsgのところでつまずいてしまいあと少しのところで止まってしまいます
コマンドが間違っているのかもしれませんがご指導の方よろしくお願いいしたいです
一応それらしきディレクトリは見つけたので貼っておきますできればコマンドを教えていただけると助かります
/dev/block/platform/soc/1d84000.ufshc/by-name
におそらくあると思います
コメントありがとうございます。
「NVをリストアするには modemst1/2とfsgを消し飛ばす必要があるので」のところでよろしいでしょうか？
端末によって全くパーティション構成やパーティション名が異なるので、一概には言えません。
おそらくですが、
/dev/block/platform/soc/1d84000.ufshc/by-name/fsg
/dev/block/platform/soc/1d84000.ufshc/by-name/modemst1
/dev/block/platform/soc/1d84000.ufshc/by-name/modemst2
が存在するかと思われます。
なので形としては
dd if=/dev/zero of= パーティションのパス
で飛ばせると思います。
...というのも私の記事で 記事のような分かりづらいやり方をしているのはddコマンドでは書き込めなかったからです。
ちなみにOnePlusの何でしょうか？
おっしゃっている場所であっています
TWRPの導入まではいけたのですがその後のコマンドで消し飛ばす段階でコマンドがうまく行かずに止まってしまいます
そのままコピーしてくると
PS C:\Users\potato> adb shell
OnePlus7Pro:/ $ su
OnePlus7Pro:/ # /dev/block/platform/soc/1d84000.ufshc/by-name
/system/bin/sh: /dev/block/platform/soc/1d84000.ufshc/by-name: can't execute: Is a directory
となるのですが
やはり自分の理解不足なのでしょうか？
お時間を取らせてしまい申し訳ありませんどうかよろしくお願いいたします
いえいえ、全然大丈夫ですよ！
そうですね、おそらくですがパスがちょっと間違えてるんだと思います。
以下のカギカッコ内のコマンドをコピペで試してみてください。
「dd if=/dev/zero of=/dev/block/platform/soc/1d84000.ufshc/by-name/fsg」
「dd if=/dev/zero of=/dev/block/platform/soc/1d84000.ufshc/by-name/modemst1」
「dd if=/dev/zero of=/dev/block/platform/soc/1d84000.ufshc/by-name/modemst2」
何も出ずにシェルに戻る(＝OnePlus7Pro:/ #)になったら少なくともパーティションを消し飛ばせています。
もし Resource Busyかno space left on deviceと出たらddコマンドではできないので
TWRPから0埋めしたmodemst1/2を、fsgをfastbootから飛ばす必要があります。
ただしこのあたりは機種によってだいぶ挙動が異なりますので、
TWRPからやるのか、fastbootからやるのかが全く変わってきます。
場合によっては消し飛ばせないこともありますし、
最悪の場合、消し飛ばせたはいいけど復旧やIMEI書き込みができないという結果になることもあります。
(以前Redmi Note 9Sでそのようなことになっていました。)
もしもNo such file or directoryとでたら単純にパーティション名が私の予想と違っていた。ということになるので
「ls /dev/block/platform/soc/1d84000.ufshc/by-name」でパーティション名を出せるので、それをコメントにコピペしていただければ
私があたりを付けることは可能です。
(おそらく文字数的に一気に貼り付けられないので、２～３個に分けて貼り付けることになると思います。)
ちなみに、消し飛ばしたあと復旧ができなくなってしまうと、
確実にモバイル通信はできなくなりますし
最終的にはどれだけROM焼きし直しても 起動しないという状況に陥ることもあります。
コマンドの実行は慎重に、かつ覚悟を持ってお願いします。
可能ならばTWRPやfastbootからの方法も教えていただけますでしょうか？
やはりそうですか...
一応TWRPからであれば、BackupからEFSを選んでバックアップを行って、
中のイメージファイル(多分端末による)をバイナリーエディタなどでゼロ埋めしたもので復元する...という形です。
(専門用語的なのをベラベラまくし立ててる感じになってすみません。)
しかし、問題はTWRPのバックアップできるパーティションが端末
によって異なるので、
場合によっては自分でTWRPを調整するぐらいでないと厳しい場合もあります。(ソースコード周りなども理解したりする必要がある)
一度TWRPのBackupからEFSがあるか確認して見てください。
一応バックアップは取りました６MBくらいの大きさでした
よろしくお願いいたします
すみません。返信が来ているのをすっかり忘れていました...
内蔵ストレージにあるTWRPフォルダーの中にbackupフォルダーがあるはずです。
そこからそのバックアップの中身のファイル名を全部書いていただけますか？
こちらこそ手間を取らせてしまい申し訳ありません
TWRPの中身は
efs1.emmc.win
efs2.emmc.win
efsc.emmc.win
efsg.emmc.win
efs1.emmc.win.sha2
efs2.emmc.win.sha2
efsc.emmc.win.sha2
efsg.emmc.win.sha2
raecovery.log
となっています
よろしくおねがいします
efs1.emmc.win
efs2.emmc.win
efsc.emmc.win
efsg.emmc.win
の4つのファイルをStirlingなどのバイナリエディターで
すべて「0」で置き換えてください。
その後バックアップフォルダーの中身を0で置き換えた4つのファイルに置き換えて、TWRPからEFSをRestoreしてください。
分かりづらい説明ですみません...
今試したのですがIMEIが消えないということはできていないということですよね？
何度か試したのですがなかなか消えないです...
なんと...
0埋めしたものでもIMEIが消えないとなると、何かしらスナップショット的なものが取られていて再起動時に復元されているか、
あるいはそもそも書き込みができていない(=プロテクトが掛かってる？)可能性がだいぶ高い気がします。
というのも、私自身が流石に全部の端末の挙動を確認できているわけではないので もしかしたら何かしらライトプロテクト的なものを解除する方法があるかもしれませんが、
そこまでやってだめとなると、経験上のことではありますが
何らかのプロテクトがかかっていると仮定します。
それを外して0埋めできたとしても、
そこからIMEIを書き換えたファイルを書き込んでも、起動できなくなったり、IMEIが不明なままで終わってしまう可能性がかなり高い気がします。
見た限り、物理的なボックスやUMT Dongleを使って書き換えできた例は見つかるので、そういったツールを使わないと厳しいのかもしれません。
他に私から提案できる方法としては、別のバージョンや製作者のTWRPを焼いて、同様の手順を試してみるということがあります。
もしかするとパーティションが２つあるということが原因かもしれないですね...
調べて調べてやっとたどり着いかのがこの記事でサポートしていただけてすごく感謝していますなんとか成功させたかったけど厳しい感じでしょうか？
どの記事を参考にするといいのかもわからなくて...
できる限りお金はかけたくないですからねー...
いわゆるA/Bパーティション端末というやつですか？
その可能性は考えてませんでした。
基本的には(というかPixelではになりますが)A/Bが用意されているのは、システムアップデートで触るパーティションだけな機種が多いのでその可能性を捨てちゃってましたね...
もしかしたらブートスロットをAならB、逆も然りという感じで変えてからもう一度やってみると、なにか変化があるかもしれません。
正直私自身も ああいったドングル系などは怪しすぎて手を出したこともなく、出そうと思ったこともないのでわかりますｗ
なんだか高いですからね...