私の質問から続く TF101 Android：adb経由の画像ブロックデバイス 私が出力リダイレクトによってブロックデバイスの生のイメージを保存することに失敗したところで、この質問は何が悪かったのかを判断しようとします。
状況 ：
Androidデバイス上のブロックデバイスが2回読み出されました。
- 一度（失敗して）次のようにしてください。 pv＆gt; faulty.raw
- 一度（正常に）出力リダイレクトを使うのではなくnetcatを使うことで成功した。
ファイルシステムはext4です。生の画像ファイルを次のコマンドと比較しました。
cmp -l faulty.raw successful.raw | mawk 'function oct2dec(oct, dec) {for (i = 1; i <= length(oct); i++) {dec *= 8; dec += substr(oct, i, 1)}; return dec} {printf "%08X %02X %02X\n", $1, oct2dec($2), oct2dec($3)}' | head -n 100
結果の出力には、2つのファイルの違いだけが16進形式で表示されます。最初の列はファイルのオフセット、2番目の列は不良イメージの値、3番目の列は正常なイメージの値です。
このバイナリ比較の出力リダイレクトを使用して、コマンドの何が問題になっているのか誰かにわかりますか？ また、（誤った）画像は何らかの修正を加えることで修復できますか？ファイルサイズは同等です
0000040D AE 37
0000040E 5D 8A
0000040F 22 2A
00000411 1D BE
00000412 03 01
0000042D 2B 30
0000042E AD 47
0000042F 1B 20
00000431 2B 30
00000432 AD 47
00000433 1B 20
00000435 B7 B9
00000490 0D 3D
00000491 2E 1E
00000493 30 D8
00000494 7B ED
00000495 56 44
00000498 4B 8B
00000499 62 59
0000049B 20 C0
0000049C 4D 6B
0000049D 2C BF
000004A0 0D 3D
000004A1 2E 1E
000004A3 68 10
000004A4 B6 49
000004A5 61 59
000004A8 4B 8B
000004A9 62 59
000004BB E0 C0
000004BC 16 46
000004BD AD 82
000004C3 20 C0
000004C4 4D 6B
000004C5 2C BF
000004E9 58 00
000004EA 40 00
000004EB 17 00
0000050D 0D 0A
0000050E 0D F3
0000050F 0A 02
00000510 F3 00
00000511 02 03
00000513 03 00
0000051D 00 FA
0000051E 00 79
0000051F FA 00
00000520 79 00
00000521 00 05
00000522 00 06
00000523 05 00
00000524 06 00
00000525 00 FA
00000526 00 79
00000527 FA 00
00000528 79 00
00000529 00 06
0000052A 00 06
0000052B 06 00
0000052C 06 00
0000052D 00 05
0000052E 00 86
0000052F 05 00
00000530 86 00
0000055D 00 1C
00000561 1C 02
00000563 02 00
00000579 00 14
0000057A 00 D2
0000057B 50 63
0000057C 4F 12
0000057D 54 00
0000057E 12 00
00001001 00 03
00001002 00 04
00001003 03 00
00001004 04 00
00001005 00 04
00001006 00 04
00001007 04 00
00001008 04 00
00001009 00 05
0000100A 00 04
0000100B 05 00
0000100C 04 00
0000100F 00 F6
00001010 00 1F
00001011 F6 01
00001012 1F 00
00001013 01 04
00001015 04 00
00001021 00 03
00001022 00 84
00001023 03 00
00001024 84 00
00001025 00 04
00001026 00 84
00001027 04 00
00001028 84 00
00001029 00 05
作業理論
これはおそらく、Androidデバイスとadbを実行しているデバイスとの間のコードページの不一致が原因である可能性がありますか？私はこれを考えている理由は2つあります。
- 一致するバイトは多くの場合「00」で、これはさまざまなコードページで節約されていると思います。
- 驚くべき数の直接変換byte1 - ＆gt;があるようです。 byte2完全に偶然によるものであるには多すぎる。
例：
- 20 - > C0（0000049Bと000004C3を参照）
- 62 - > 59（00000499および000004A9を参照）
- 0D - > 3D（00000490と000004A0を参照。ただし、0000050Dと0000050Eでは異なります）
- 1B - > 20（0000042Fおよび00000433を参照）
- 2B - > 30（0000042Dおよび00000431を参照）
- 図2C - ＆GT。 BF（0000049Dと000004C5を参照してください）
- 2E - > 1E（00000491と000004A1を参照）
- 4B - > 8B（00000498および000004A8を参照）
- 4D - ＆gt; 6B（0000049Cと000004C4を参照）
- AD - ＆gt; 47（0000042E abd 00000432を参照してください。ただし、000004BDでは異なります）
ご覧のとおり、驚くべき一貫性があります。違いは、2つの画像ファイルの読み出しの間のブロックデバイスの変更に起因する可能性があります。
誰かが最初のファイルのコードページを識別できますか？ （もしこの理論が実際に成り立つなら）