Исходя из моего вопроса TF101 Android: устройство блокировки изображений через adb, в котором я безуспешно пытался сохранить необработанное изображение блочного устройства путем перенаправления вывода, этот вопрос пытается определить, что пошло не так.
Ситуация:
Блочное устройство на устройстве Android было прочитано дважды.
- Один раз (безуспешно) с помощью: adb shell su -c "dd if =/dev/block/mmcblk0p7" | pv> faulty.raw
- Один раз (успешно) не с перенаправлением вывода, а с использованием netcat, что привело к success.raw
Файловая система - 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
Результирующий вывод показывает только различия в двух файлах в шестнадцатеричном формате. В первом столбце указано смещение файла, во втором столбце указано значение в неисправном изображении, а в третьем столбце - значение в удачном изображении.
Кто-нибудь может увидеть, что пошло не так с командой, использующей перенаправление вывода из этого двоичного сравнения? Также: можно ли (неисправное) изображение восстановить, применив некоторую коррекцию? Размеры файлов сопоставимы
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? Я думаю об этом по двум причинам:
- Соответствующие байты часто равны "00", что, я считаю, сохраняется в разных кодовых страницах.
- Кажется, есть удивительное количество прямых преобразований byte1 -> byte2. Слишком много, чтобы быть полностью случайно.
Примеры:
- 20 -> C0 (см. 0000049B и 000004C3)
- 62 -> 59 (см. 00000499 и 000004A9)
- 0D -> 3D (см. 00000490 и 000004A0, но отличаются в 0000050D и 0000050E)
- 1B -> 20 (см. 0000042F и 00000433)
- 2B -> 30 (см. 0000042D и 00000431)
- 2C -> BF (см. 0000049D и 000004C5)
- 2E -> 1E (см. 00000491 и 000004A1)
- 4B -> 8B (см. 00000498 и 000004A8)
- 4D -> 6B (см. 0000049C и 000004C4)
- AD -> 47 (см. 0000042E и 00000432, но отличается в 000004BD)
Как видите, замечательная последовательность. Различия могут быть связаны с изменениями на блочном устройстве между двумя считываниями файла изображения.
Кто-нибудь может определить кодовую страницу первого файла? (Если эта теория действительно верна.)