这些 Windows 可执行元数据特征是否意味着我认为它们的作用? [英] Do these Windows executable meta data traits mean what I think they do?

问题描述

我正在学习汇编作为恶意软件分析项目的一部分，并尝试使用一些 Node.js 库从 GitHub 抓取可执行文件并反汇编它们.

I'm learning Assembly as part of a malware analysis project and trying to use a few Node.js libraries to scrape executables from GitHub and disassemble them.

特别是我专注于 x86-64 PE.

Specifically I'm focusing on x86-64 PE.

但是一个反汇编器，比如我选择的那个 不一定要找到特定可执行格式的指令，例如在 PE 中.

But a disassembler, such as the one I chose isn't necessarily supposed to find the instructions in a particular executable format such as in a PE.

除了首先需要知道我的指令应该从哪里开始，当我开始使用反汇编程序时，我意识到我还需要为程序设置一个特定的 RIP 值来启动.我不完全理解为什么有些程序以不同的内存偏移量开始，但据说这是为了允许其他协作进程将内存放在同一块中.或者类似的东西.

In addition to first needing to know where my instructions should start, when I started using the disassembler, I realized I also needed to set a particular RIP value for the program to start at. I don't fully understand why some programs start at different memory offsets, but supposedly it's to allow other cooperating processes to put memory in the same block. Or something like that.

所以我的目标是知道:

• RIP 的正确起始值
• 用于查找首条指令的正确字节，超出标头.

所以我使用了一个库来查找元数据，像这样:

So I used a library to find meta data, like so:

let metaData = await executableMetadata.getMetadataObjectFromExecutableFilePath_Async(execPath);

当传递一个带有这样标题的 exe 时:

Which when passed an exe with a header like this:

0:      4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00
16:     b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00
32:     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
48:     00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00
64:     0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68
80:     69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f
96:     74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20
112:    6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00
128:    50 45 00 00 4c 01 03 00 91 3f 9a ef 00 00 00 00
144:    00 00 00 00 e0 00 22 00 0b 01 30 00 00 12 00 00

告诉我们:

{
  format: 'PE',
  pe_header_offset_16le: 128,
  machine_type: 332,
  machine_type_object: {
    constant: 'IMAGE_FILE_MACHINE_I386',
    description: 'Intel 386 or later processors and compatible processors'
  },
  number_of_sections: 3,
  timestamp: -275103855,
  coff_symbol_table_offset: 0,
  coff_number_of_symbol_table_entries: 0,
  size_of_optional_header: 224,
  characteristics_bitflag: 34,
  characteristics_bitflags: [
    {
      constant: 'IMAGE_FILE_EXECUTABLE_IMAGE',
      description: 'Image only. This indicates that the image file is valid and can be run. If this flag is not set, it indicates a linker error.',
      flag_code: 2
    },
    {
      constant: 'IMAGE_FILE_LARGE_ADDRESS_AWARE',
      description: 'Application can handle > 2-GB addresses.',
      flag_code: 32
    }
  ],
  object_type_code: 267,
  object_type: 'PE32',
  linker: { major_version: 48, minor_version: 0 },
  size_of_code: 4608,
  size_of_initialized_data: 2048,
  size_of_uninitialized_data: 0,
  address_of_entry_point: 12586,
  base_of_code: 8192,
  windows_specific: {
    image_base: 4194304,
    section_alignment: 8192,
    file_alignment: 512,
    major_os_version: 4,
    minor_os_version: 0,
    major_image_version: 0,
    minor_image_version: 0,
    major_subsystem_version: 6,
    minor_subsystem_version: 0,
    win32_version: 0,
    size_of_image: 32768,
    size_of_headers: 512,
    checksum: 0,
    subsystem: {
      constant: 'IMAGE_SUBSYSTEM_WINDOWS_CUI',
      description: 'The Windows character subsystem',
      subsystem_code: 3
    },
    dll_characteristics: 34144,
    dll_characteristic_flags: [ [Object], [Object], [Object], [Object], [Object] ]
  },
  base_of_data: 16384
}

由此，我想也许我找到了我需要的两条信息:

And from this, I think maybe I found the two pieces of info I needed:

• 第一个指令字节:windows_specific.size_of_headers (512)
• RIP 起始值:address_of_entry_point (12586)

• First instruction byte: windows_specific.size_of_headers (512)
• RIP starting value: address_of_entry_point (12586)

但我基本上是猜测.任何更熟悉此元数据的人都可以解释要查看的正确属性以获取我需要的信息吗?

But I'm basically guessing. Could anyone more familiar with this meta data explain the correct properties to look at to get the info I need?

推荐答案

Windows 可执行文件以 16 位 DOS 存根开始.文件偏移量 60 处的双字包含 DWORD PE 签名的偏移量，在您的示例中它是 60: 80 00 00 00，即十进制的 128.PE 签名后紧跟 COFF 文件头(文件偏移 132).你可能想用汇编语言的头结构来处理你的十六进制转储.COFF_FILE_HEADER.Machine 是 132: 4C 01，即 0x14C 表示 32 位可执行文件.在 64 位可执行文件中，它将是 0x8664.

Windows executable file begins with 16bit DOS stub. Double word at the file offset 60 contains offset of DWORD PE signature, in your example it is 60: 80 00 00 00, i.e. 128 in decimal. PE signature is immediately followed with COFF file header (file offset 132). You may want to confront your hexadecimal dump with structure of headers in assembly language. COFF_FILE_HEADER.Machine is 132: 4C 01, i.e. 0x14C which signalizes 32bit executable. In 64bit executable it would be 0x8664.

文件头后跟COFF 部分头.您对那些在 中设置位 SCN_MEM_EXECUTE=0x2000_0000 的部分感兴趣COFF_SECTION_HEADER.特性.

File header is followed by COFF section headers. You are interrested in those sections, which have set bit SCN_MEM_EXECUTE=0x2000_0000 in COFF_SECTION_HEADER.Characteristics.

COFF_SECTION_HEADER.PointerToRawData 指定代码开头的文件偏移量.剖析出从该文件偏移量开始的 .SizeOfRawData 字节，并将该部分代码提交给您的反汇编程序.请注意，在运行时，代码实际上会映射到 .VirtualAddress，与 .PointerToRawData 不同.

COFF_SECTION_HEADER.PointerToRawData specifies file offset of the start of code. Dissect out .SizeOfRawData bytes which start at this file offset and submit that portion of code it to your disassembler. Beware that on run-time the code will be in fact mapped to .VirtualAddress, different from .PointerToRawData.

这篇关于这些 Windows 可执行元数据特征是否意味着我认为它们的作用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！