☰

解决这个十六进制谜语！ - 我的输出重定向出了什么问题？

tag-icon • tag-icon linux android redirection disk-image hexdump
解决这个十六进制谜语！ - 我的输出重定向出了什么问题？

接下来我的问题TF101 Android：通过 adb 实现图像块设备我尝试通过输出重定向保存块设备的原始图像，但没有成功，这个问题试图确定出了什么问题。

情况：

Android 设备上的块设备被读出两次。

  1. 一次（不成功）：adb shell su -c "dd if=/dev/block/mmcblk0p7" | pv >aulty.raw
  2. 一次（成功）不是使用输出重定向，而是使用 netcat 生成 successful.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 的设备之间的代码页不匹配造成的吗？我这样想有两个原因：

  1. 匹配的字节通常是“00”，我相信这在不同的代码页中是保留的。
  2. 字节 1 -> 字节 2 的直接转换次数似乎惊人。数量太多，不可能完全是偶然的。

例子：

  • 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

事实证明这个问题比我的工作理论简单得多。

adb 在 Windows 机器上运行。它将每个“\n”字符替换为“\r\r\n”。使用多行 perl 脚本恢复该文件这个答案。

相关内容