如果系统执行零填充文件的一部分,会发生什么？

Question

我在一些帖子/视频/文件中看到它们是零填充的,看起来比它们更大,或者匹配一些文件系统实用程序用于移动文件的"相同文件大小"标准,大多数它们是恶作剧程序或恶意软件.

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

会发生什么事吗？什么是指令集0x0？

Answer 1

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 Thumb/Thumb2: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.IDK,如果对PowerPC的任何扩展使用00 00 00 00指令编码,或者它仍然是现代IBM POWER芯片上的非法指令.

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>