Решите эту шестнадцатеричную загадку! - Что пошло не так с моим перенаправлением вывода?

559
Mel

Исходя из моего вопроса TF101 Android: устройство блокировки изображений через adb, в котором я безуспешно пытался сохранить необработанное изображение блочного устройства путем перенаправления вывода, этот вопрос пытается определить, что пошло не так.

Ситуация :

Блочное устройство на устройстве Android было прочитано дважды.

  1. Один раз (безуспешно) с: adb shell su -c "dd if = / dev / block / mmcblk0p7" | pv> faulty.raw
  2. Один раз (успешно) не с перенаправлением вывода, а с использованием netcat, что привело к success.raw

Файловая система - ext4. Необработанные файлы изображений сравнивались с помощью следующей команды:

cmp -l faulty.raw successful.raw | mawk 'function oct2dec(oct, dec) ; return dec} ' | 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? Я думаю об этом по двум причинам:

  1. Соответствующие байты часто равны «00», что, я считаю, сохраняется в разных кодовых страницах.
  2. Кажется, есть удивительное количество прямых преобразований 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)

Как видите, замечательная последовательность. Различия могут быть связаны с изменениями на блочном устройстве между двумя считываниями файла изображения.

Кто-нибудь может определить кодовую страницу первого файла? (Если эта теория действительно верна.)

1

1 ответ на вопрос

0
Mel

Оказывается, проблема была намного проще, чем моя рабочая теория.

ADB работал на машине Windows. Он заменял каждый символ '\ n' на '\ r \ r \ n'. Файл был восстановлен с использованием многострочного сценария perl этого ответа .