1

我在一些帖子/视频/文件中看到，它们被零填充以看起来比实际更大，或者符合某些文件系统实用程序用于移动文件的“相同文件大小”标准，主要是恶作剧程序或恶意软件.

但是我经常想，如果文件损坏会发生什么，并且会“加载”文件末尾大零填充空间中的下一组“指令”？

会不会有事？指令集是干什么用的0x0？

4

1 回答 1

7

字节的解码0完全取决于 CPU 架构。在许多架构上，指令是固定长度的（例如 32 位），因此相关的东西是00 00 00 00（使用 hexdump 表示法）。

在大多数 Linux 发行版上，clang/llvm 支持内置的多个目标架构（clang -target和llvm-objdump），这与 gcc / gas / binutils 不同，因此我能够使用它来检查一些我没有跨 gcc / 的架构binutils 安装。用于llvm-objdump --version查看支持的列表。（但我不知道如何让它反汇编像 binutils 这样的原始二进制文件objdump -b binary，而且我的 clang 不会自己创建 SPARC 二进制文件。）

在 x86 上，00 00（2 字节）将 ( http://ref.x86asm.net/coder32.html ) 解码为具有内存目标的8 位add。第一个字节是操作码，第二个字节是指定操作数的 ModR/M。

这通常会立即出现段错误（如果eax/rax不是有效的指针），或者一旦执行从零填充部分的末尾落入未映射的页面中，就会出现段错误。（这在现实生活中会发生，因为在没有_start进行退出系统调用的情况下就掉线了），尽管在这些情况下，以下字节并不总是全为零。例如数据或 ELF 元数据。）

x86 64 位模式: ndisasm -b64 /dev/zero | head:

address   machine code      disassembly
00000000  0000              add [rax],al

x86 32 位模式 ( -b32):

00000000  0000              add [eax],al

x86 16 位模式：（-b16）：

00000000  0000              add [bx+si],al

AArch32 ARM 模式：cd /tmp&& dd if=/dev/zero of=zero bs=16 count=1&& arm-none-eabi-objdump -z -D -b binary -marm zero。（如果没有-z，objdump 会跳过大块的全零并显示...）

addr   machine code   disassembly
0:   00000000        andeq   r0, r0, r0

ARM 拇指/拇指 2：arm-none-eabi-objdump -z -D -b binary -marm --disassembler-options=force-thumb zero

0:   0000            movs    r0, r0
2:   0000            movs    r0, r0

AArch64：aarch64-linux-gnu-objdump -z -D -b binary -maarch64 zero

 0:   00000000        .inst   0x00000000 ; undefined

MIPS32 : echo .long 0 > zero.S&& clang -c -target mips zero.S&&llvm-objdump -d zero.o

zero.o: file format ELF32-mips
Disassembly of section .text:
   0:       00 00 00 00     nop

PowerPC 32 和 64 位:-target powerpc和-target powerpc64. 如果 PowerPC 的任何扩展使用任何00 00 00 00指令编码，或者它仍然是现代 IBM POWER 芯片上的非法指令，则 IDK。

zero.o: file format ELF32-ppc   (or ELF64-ppc64)
Disassembly of section .text:
   0:       00 00 00 00  <unknown>

IBM S390：clang -c -target systemz zero.S

zero.o: file format ELF64-s390
Disassembly of section .text:
   0:       00 00  <unknown>
   2:       00 00  <unknown>
于 2018-05-03T09:11:24.193 回答