Windows Shellcode与Win32汇编组件解析

需积分: 10 164 浏览量更新于2024-07-22 收藏 257KB PDF 举报

"Windows汇编相关的技术文档，主要讲解了在Windows环境下使用汇编语言实现的一些关键功能，如获取Windows API、进程复制、命令执行、文件传输和网络通信。文档中还介绍了WASMPackage（Windows Assembler Modular Program Package）的结构和组件，包括模块化架构、组件骨架和位置独立性解码等概念。" 本文档详细阐述了Windows汇编语言在实际应用中的几个重要方面，特别关注于shellcode的编写，这对于理解系统底层工作原理和安全领域至关重要。首先，文档介绍了如何在Windows环境下通过汇编语言来获取和调用Windows API。这是编写任何Windows系统级别的程序或shellcode的基础，因为API提供了操作系统的核心服务。接着，文档讲解了进程复制（Process Forking），这是创建新进程并使其与原始进程共享资源的一种技术。在恶意软件开发中，这一技巧常用于隐藏和持久化。然后，它涵盖了命令执行，这是通过汇编代码启动系统命令或程序的关键步骤，对于理解和控制系统的执行流程非常有用。进一步，文档提到了文件传输功能的实现，这在很多场景下都十分关键，比如数据窃取或更新程序。最后，讨论了网络通信，这包括如何使用汇编语言建立网络连接、发送和接收数据，这对于编写网络蠕虫或其他网络攻击工具来说是必不可少的知识。文档还介绍了一个名为WASMPackage的框架，它包含了一系列汇编代码模块，具有模块化设计，包括CORE（核心）和PLUGIN（插件）部分。组件骨架（Component Skeleton）定义了组件的基本结构，而位置独立性和解码机制则确保代码能在不同环境中正确运行，提高了代码的适应性和隐蔽性。这份文档深入浅出地介绍了Windows环境下的汇编语言编程，特别是针对shellcode和系统级功能的实现，对于想深入了解Windows系统底层运作和安全领域的学习者极具价值。

Chapter 2

Functionality of Win32 Assembly Components

During recent years, several types of vulnerabilities have been discovered, like heap and stack buﬀer

overﬂows, format strings and signed/unsigned bugs. The assembly components are used in those

vulnerabilities, which successful exploitation results in a possibility of unauthorized execution of

some code on a target machine. The asmcodes can theoretically perform any operation in the target

operating system with privileges determined by permissions of vulnerable service or application.

In the case of Microsoft Windows operating systems, such unauthorized execution of code is usually

aimed at downloading and executing a ﬁle on a target system or at starting interactive copy

of windows console. The main problem with the ﬁrst method is the need for additional reverse

communication channel that has to be established in order to download the ﬁle. The success in

this operation depends on many factors. The main problems are that such reverse channel may be

blocked (by appropriate conﬁguration of ﬁrewall or antivirus solution) or detected by network-based

IDS.

In the case of the second metho d, an attacker can interactively execute any commands in the

remote system. However, in MS Windows operating systems, working with command line console

has certain limitations, at least comparing with UNIX systems. In many situations, it may not

be suﬃcient and the attack may require downloading (using various strange methods) additional

software for performing desired operations.

It can be easily noticed that these two solutions can b e hardly considered as unfailing, ﬂexible

and eﬀective in practice. This was the main reason why we developed our own set of assembly

components with slightly extended functionality for the needs of penetration tests. In this chapter

we describe how we achieved independence of asmcodes from version of the operating system

(2.1), use of child processes to separate the asmcode from exploited application (2.2), working with

interactive shell (2.3). Then we describe additional features of the asmcodes like simultaneous ﬁle

transfer capability (2.4) and three options for remote communication with a target system (2.5).

2.1 Retrieving Windows API

Due to the speciﬁcity of exploitation techniques, the asmcodes executed during an attack have to

fulﬁll several sp ecial requirements. First of all they have to b e relo catable (i.e. can be executed

in arbitrary memory place, for example in data segment, heap or stack), should be as short as

possible and often must avoid some speciﬁc characters (commonly zeros). For all those reasons,

the asmcodes are always written in assembly languages, speciﬁc for a given processor platform (in

case of MS Windows, these are obviously processors of the most popular Intel x86 family).

In order to perform a given operation in the operating system, assembly components use the basis

functionality oﬀered by the operating system. In case of most UNIX systems, the asmcodes use

direct invocation of system calls through appropriate use of interrupts, gates or traps. The MS

Windows systems also export a set of system calls (may be invoked through 0x2e interrupt).

However, they have diﬀerent architecture of OS kernel that us based on the concept of subsystems,

and in result there is no simple mapping of some operations (necessary for the asmcodes) to system

calls.

This is the main reason why the assembly components for MS Windows operating systems are

designed and implemented to use higher level functions located in dynamic libraries. This solution

has some additional advantage, as it enables easy access to extended functionality of Windows API

implemented in shared libraries.

In order to invoke any Windows API function, its actual address in memory space of a given

process must be known. Although MS Windows operating systems use mechanism of prelocated

libraries

, the base address (and therefore addresses of all of the exported functions) may diﬀer in

case of various operating systems versions, installed service packs and last but not least versions

of the library itse lf. The development of methods for dynamic localization of function addresses in

any process is therefore one of the most critical issues, as it has direct impact on independence,

ﬂexibility and eﬀectiveness of the assembly component.

The most intuitive solution for ﬁnding addresses of required Windows API functions is connected

with the use of LoadLibrary() and GetProcAddress() routines from kernel32.dll library. The

ﬁrst function enables loading any dynamic library to process memory s pace and returns a handler,

which in fact is the base address where the library was mapped. In order to retrieve an actual

address of any exported API function from the library, the GetProcAddress() function is used

with the base address provided as an argument. However there is still a problem, as to use these

two nice functions, the information about their actual addresses is also required.

There are several techniques for solving this problem. Hackers which tend to use the simplest and

often not elegant solutions, commonly hardcode these addresse s, what obviously limits the usage

to the systems of similar conﬁgurations or forces to tune the code during the attack. The most

commonly hardcoded address is the base of kernel32.dll library, from which the addresses of

LoadLibrary() and GetProcAddress() routines are later calculated at runtime. Sometimes, the

base address of spe ciﬁc application containing a vulnerability is hardcoded. In such a case, the im-

port table of the application is used during a runtime to obtain address of getmodulehandle() func-

tion, which is used further to retrieve the base address of kernel32.dll library. Next, the export ta-

ble of the kernel32.dll is used to obtain the addresses for LoadLibrary() and GetProcAddress()

routines.

There are obviously other techniques that retrieve the base address of kernel32.dll on the ﬂy

and therefore achieve greater independence from the operating system and application versions.

These techniques are mainly used by virus coders and are based on scanning selected parts of

memory and looking for signatures of dynamic libraries headers ("PE\x00\x00" for PE format of

MS Windows executables and "MZ" in the case of MS-DOS) [1], [7]. The interesting way of using

this technique has been already introduced in one of earlier assembly c omponents for MS Windows

[4]. In that case, this technique was combined with automatic estimation of the base address of

loaded kernel32.dll library, by walking through SEH (Structured Exception Handling) chain and

looking for the address of library exception handling procedure.

However, it seems that the shortest and most eﬀective technique for automatic localization of

addresses of the libraries mapped into process memory space is based on scanning through a list

of loaded modules, which is available in PEB (Process Environment Block) [10]. The application

of this technique enables retrieving the address of kernel32.dll library loaded into the address

For example, it is possible to download a ﬁle through HTTP protocol from any server with a call at a single

function.

The base address where library should be loaded is speciﬁed during link time and saved in the library.

剩余35页未读，继续阅读

凡心一点2016

粉丝: 2
资源: 4

Windows Shellcode与Win32汇编组件解析

修复版微信小程序反汇编工具上线，支持Window与Mac

使用汇编语言解决远程控件子类问题

Linux汇编程序构建指南与支持文件介绍

masm for window汇编语言开发环境

罗云彬的WINDOW32汇编程序设计指南

Window 32位汇编语言程序设计

window程序设计和汇编程序设计

Window环境下32位汇编语言程序设计软件压缩包

HYPERION安装配置(Window2003)[汇编].pdf

Window7当做无线路由器[汇编].pdf

最新资源