如果系统执行文件的零填充部分会发生什么? [英] What would happen if a system executes a part of the file that is zero-padded?
问题描述
我在一些帖子/视频/文件中看到它们被零填充以看起来比它们大，或者符合某些文件系统实用程序用于移动文件的相同文件大小"标准，大多数情况下它们要么是恶作剧程序或恶意软件.
I've seen in some posts/videos/files that they are zero-padded to look bigger than they are, or match "same file size" criteria some file system utilities have for moving files, mostly they are either prank programs, or malware.
但是我经常想知道，如果文件损坏，会在文件末尾的大零填充空间中加载"下一组指令"，会发生什么?
But I often wondered, what would happen if the file corrupted, and would "load" the next set of "instructions" that are in the big zero-padded space at the end of the file?
会发生什么事吗? 0x0设置了什么指令?
Would anything happen? What's the instruction set for 0x0?
推荐答案
0字节的解码完全取决于CPU体系结构.在许多体系结构中，指令是固定长度的(例如32位)，因此相关的内容是00 00 00 00(使用十六进制表示法).
The decoding of 0 bytes completely depends on the CPU architecture. On many architectures, instruction are fixed length (for example 32-bit), so the relevant thing would be 00 00 00 00 (using hexdump notation).
在大多数Linux发行版中，clang/llvm内置了对多个目标体系结构(clang -target和llvm-objdump)的支持，这与gcc/gas/binutils不同，因此我能够使用它来检查某些体系结构我没有安装cross-gcc/binutils.使用llvm-objdump --version查看受支持的列表. (但是我没有弄清楚如何将其分解成像binutils objdump -b binary这样的原始二进制文件，而且我的clang不会自行创建SPARC二进制文件.)
On most Linux distros, clang/llvm comes with support for multiple target architectures built-in (clang -target and llvm-objdump), unlike gcc / gas / binutils, so I was able to use that to check for some architectures I didn't have cross-gcc / binutils installed for. Use llvm-objdump --version to see the supported list. (But I didn't figure out how to get it to disassemble a raw binary like binutils objdump -b binary, and my clang won't create SPARC binaries on its own.)
在x86上，00 00(2字节)解码( http://ref.x86asm.net/coder32.html )作为带有存储目标的8位add .第一个字节是操作码，第二个字节是指定操作数的ModR/M.
On x86, 00 00 (2 bytes) decodes (http://ref.x86asm.net/coder32.html) as an 8-bit add with a memory destination. The first byte is the opcode, the 2nd byte is the ModR/M that specifies the operands.
这通常会立即出现段错误(如果eax/rax不是有效的指针)，或者一旦执行从零填充部分的末尾掉落到未映射的页面中，就会出现段错误. (之所以会在现实生活中发生是因为
This usually segfaults right away (if eax/rax isn't a valid pointer), or segfaults once execution falls off the end of the zero-padded part into an unmapped page. (This happens in real life because of bugs like falling off the end of _start without making an exit system call), although in those cases the following bytes aren't always all zero. e.g. data, or ELF metadata.)
x86 64位模式:ndisasm -b64 /dev/zero | head:
address machine code disassembly
00000000 0000 add [rax],al
x86 32位模式(-b32):
x86 32-bit mode (-b32):
00000000 0000 add [eax],al
x86 16位模式:(-b16):
x86 16-bit mode: (-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会跳过全零的大块并显示...)
AArch32 ARM mode: cd /tmp && dd if=/dev/zero of=zero bs=16 count=1 && arm-none-eabi-objdump -z -D -b binary -marm zero. (Without -z, objdump skips over large blocks of all-zero and shows ...)
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
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.
PowerPC 32 and 64-bit: -target powerpc and -target powerpc64. IDK if any extensions to PowerPC use the 00 00 00 00 instruction encoding for anything, or if it's still an illegal instruction on modern IBM POWER chips.
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>
这篇关于如果系统执行文件的零填充部分会发生什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
