Win32病毒编写指南1.0：安全与技术解析

PDF文件

下载需积分: 10 | 330KB | 更新于2024-07-30 | 185 浏览量 | 举报收藏

立即下载

"Virus Writing Guide 1[1].0 for Win32.pdf 是一份关于创建Windows 32位病毒的指南，旨在教授读者病毒编写技术。文档可能包含详细步骤、技术细节以及如何防御病毒的信息。" 在计算机安全领域，病毒编写通常被视为非法和不道德的行为，然而，这份指南可能会探讨以下知识点： 1. **病毒基础知识**：介绍什么是计算机病毒，其工作原理，如何通过自我复制和感染其他程序来传播。 2. **Win32 API**：Windows操作系统中的32位应用程序接口是病毒编写者常用的技术，因为它们可以访问系统核心功能。指南可能会详细解释如何利用这些API创建恶意代码。 3. **病毒编写技术**：包括如何设计病毒结构，编写注入代码，以及如何隐藏病毒活动，使其不易被反病毒软件检测到。 4. **感染机制**：讲解病毒如何寻找和感染目标文件，如通过文件关联、网络共享、电子邮件附件等方式。 5. **触发条件**：讨论病毒何时执行其破坏性行为，可能是时间触发、用户行为触发或其他特定事件。 6. **免杀技术**：介绍如何避免被反病毒软件检测到，包括代码混淆、行为伪装等方法。 7. **防御策略**：虽然此文档主要关注编写病毒，但可能也会提及一些防御措施，如如何保护个人电脑免受病毒感染，或者如何分析和清除病毒。 8. **法律与道德问题**：可能会简要提到病毒编写可能涉及的法律问题，强调进行此类活动的风险和责任。 9. **安全研究与逆向工程**：部分教程可能包括逆向工程概念，即如何分析已知病毒的工作原理，这对于理解病毒行为和开发反病毒解决方案至关重要。 10. **编程语言**：可能涉及使用汇编语言或高级编程语言（如C++）编写病毒的技巧。重要的是要明确，了解这些技术的目的是为了提高网络安全意识和防御能力，而不是为了创建恶意软件。在合法和道德的范围内，学习这些知识可以帮助安全专家更好地对抗病毒和恶意软件威胁。

later) appear to serve a similar purpose. This field defaults to 1.0 in all

Win32 EXEs to date.

■ Major Image Version and Minor Image Version:

A user-definable field. This allows you to have different versions of an EXE

or DLL. You set these fields via the linker /VERSION switch. For example,

"LINK /VERSION:2.0 myobj.obj".

■ Major Subsystem Version and Minor Subsystem Version:

Contains the minimum subsystem version required to run the executable. A

typical value for this field is 3.10 (meaning Windows NT 3.1).

■ Reserved1:

Seems to always be 0 (perfect for an infection mark).

■ Size Of Image:

This appears to be the total size of the portions of the image that the

loader has to worry about. It is the size of the region starting at the

image base up to the end of the last section. The end of the last section is

rounded up to the nearest multiple of the section alignment.

■ Size Of Headers:

The size of the PE header and the section (object) table. The raw data for

the sections starts immediately after all the header components.

■ Checksum:

Supposedly a CRC checksum of the file. As in other Microsoft executable

formats, this field is ignored and set to 0. The one exception to this rule

is for trusted services and these EXEs must have a valid checksum.

■ SubSystem:

The type of subsystem that this executable uses for its user interface.

WINNT.H defines the following values:

NATIVE 1 Doesn't require a subsystem (such as a device driver)

WINDOWS_GUI 2 Runs in the Windows GUI subsystem

WINDOWS_CUI 3 Runs in the Windows character subsystem (console app)

1. Invoke a breakpoint instruction before starting the process

2. Invoke a debugger on the process after it's been loaded

■ Number Of Rva And Sizes:

The number of entries in the DataDirectory array (below). This value is

always set to 16 by the current tools.

IMAGE_SECTION_HEADER

───────────────────┘

┌─────────────────────────────────── ┐

─── Begin Of Section Header

│ Section Name │ Size : 8 BYTES

├─────────────────────────────────── ┤

─── +00000008h

│ Virtual Size │ Size : 1 DWORD

├─────────────────────────────────── ┤

─── +0000000Ch

│ Virtual Address │ Size : 1 DWORD

├─────────────────────────────────── ┤

─── +00000010h

│ Size Of Raw Data │ Size : 1 DWORD

├─────────────────────────────────── ┤

─── +00000014h

│ Pointer To Raw Data │ Size : 1 DWORD

├─────────────────────────────────── ┤

─── +00000018h

│ Pointer To Relocations │ Size : 1 DWORD

├─────────────────────────────────── ┤

─── +0000001Ch

│ Pointer To Line Numbers │ Size : 1 DWORD

├─────────────────────────────────── ┤

─── +00000020h

│ Number Of Relocations │ Size : 1 WORD

├─────────────────────────────────── ┤

─── +00000022h

│ Number Of Line Numbers │ Size : 1 WORD

├─────────────────────────────────── ┤

─── +00000024h

│ Characteristics │ Size : 1 DWORD

└─────────────────────────────────── ┘ ─────────

Total Size : 28h BYTES

■ Section Name:

This is an 8-byte ANSI name (not UNICODE) that names the section. Most

section names start with a . (such as ".text"), but this is not a

requirement, as some PE documentation would have you believe. You can name

your own sections with either the segment directive in assembly language, or

with "#pragma data_seg" and "#pragma code_seg" in the Microsoft C/C++

compiler. It's important to note that if the section name takes up the full

8 bytes, there's no NULL terminator byte. If you're a printf devotee, you

can use %.8s to avoid copying the name string to another buffer where you

can NULL-terminate it.

■ Virtual Size:

This field has different meanings, in EXEs or OBJs. In an EXE, it holds the

actual size of the code or data. This is the size before rounding up to the

nearest file alignment multiple. The SizeOfRawData field (seems a bit of a

misnomer) later on in the structure holds the rounded up value. The Borland

linker reverses the meaning of these two fields and appears to be correct.

For OBJ files, this field indicates the physical address of the section. The

first section starts at address 0. To find the physical address in an OBJ

file of the next section, add the SizeOfRawData value to the physical

address of the current section.

■ Virtual Address:

In EXEs this field holds the RVA to where the loader should map the section.

To calculate the real starting address of a given section in memory, add the

base address of the image to the section's VirtualAddress stored in this

field. With Microsoft tools, the first section defaults to an RVA of 0x1000.

In OBJs, this field is meaningless and is set to 0.

■ Size Of Raw Data:

In EXEs, this field contains the size of the section after it's been rounded

up to the file alignment size. For example, assume a file alignment size of

0x200. If the VirtualSize field from above says that the section is 0x35A

bytes in length, this field will say that the section is 0x400 bytes long.

In OBJs, this field contains the exact size of the section emitted by the

compiler or assembler. In other words, for OBJs, it's equivalent to the

VirtualSize field in EXEs.

■ Pointer To Raw Data:

This is the file-based offset of where the raw data emitted by the compiler

or assembler can be found. If your program memory maps a PE or COFF file

itself (rather than letting the operating system load it), this field is

more important than the VirtualAddress field. You'll have a completely

linear file mapping in this situation, so you' ll find the data for the

sections at this offset, rather than at the RVA specified in the Virtual

Address field.

■ Pointer To Relocations:

In OBJs this is the file-based offset to the relocation information for this

section. The relocation information for each OBJ section immediately follows

the raw data for that section. In EXEs this field (and the subsequent field) are

meaningless, and set to 0. When the

linker creates the EXE, it resolves most of the fixups, leaving only base

address relocations and imported functions to be resolved at load time. The

information about base relocations and imported functions is kept in their

own sections, so there's no need for an EXE to have per-section relocation

data following the raw section data.

■ Pointer To Line Numbers:

This is the file-based offset of the line number table. A line number table

correlates source file line numbers to the addresses of the code generated

for a given line. In modern debug formats like the CodeView format, line

number information is stored as part of the debug information. In the COFF

debug format, however, the line number information is stored separately from

the symbolic name/type information. Usually, only code sections (such as

.text) have line numbers. In EXE files, the line numbers are collected

towards the end of the file, after the raw data for the sections. In OBJ

files, the line number table for a section comes after the raw section data

and the relocation table for that section.

■ Number Of Relocations:

The number of relocations in the relocation table for this section (the

PointerToRelocations field from above). This field seems relevant only for

OBJ files.

■ Number Of Line Numbers:

The number of line numbers in the line number table for this section (the

PointerToLinenumbers field from above).

■ Characteristics:

What most programmers call flags, the COFF/PE format calls characteristics.

This field is a set of flags that indicate the section's attributes (such as

code/data, readable, or writeable,). For a complete list of all possible

section attributes, see the IMAGE_SCN_XXX_XXX #defines in WINNT.H. Some of

the more important flags are shown below:

0x00000020 This section contains code. Usually set in conjunction with the

剩余166页未读，继续阅读

zpp520

粉丝: 3

Win32病毒编写指南1.0：安全与技术解析

Virus Writing Guide 1.0 for Win32

Virus Writing Guide for Win32

Virus.Win32.Ramnit.X专杀工具

Virus Writing Guide 1.0 for Win32.7z

Virus_Writing_Guide_1.0_for_Win32

Phunky Virus Writing Guide

virus.win32.pubwin.b 病毒

delphi Virus.Win32.HLLW.Delf.k.

病毒程序汇编分析 Virus Writing Guide

virustotal-for-investigators.pdf

最新资源