Application Programming Interfaces

Một application programming interface (API) là một tập hợp functions mà hệ điều hành tạo sẵn cho các chương trình ứng dụng. Nếu bạn muốn reverse dưới windows, điều bắt buộc là bạn phải bồi dưỡng cho mình kiến thức vững vàng về Windows API và các phương thức phổ biến để làm một vài thứ sử dụng APIs.

The Win32 API

Tôi đảm bảo một điều rằng bạn đã được nghe về Win32 API. Win32 là một tập hợp rất lớn các hàm mà tạo nên giao diện chính thức cấp thấp  cho Windows applications. Ban đầu khi Windows được giới thiệu, một số lượng lớn chương trình thực sự được phát triển sử dụng Win32 API, dần dần Microsoft giới thiệu các giao diện đơn giản, cấp cao hơn mà có thể thực hiện hầu hết các đặc tính được cung cấp bởi Win32 API. Một trong những interfaces phổ biến đó là MFC (Microsoft Foundation Classes), đó là một hệ thống cấp bậc của C objects mà có thể được sử dụng cho việc giao tiếp với Windows. Ban đầu, MFC sử dụng Win32 API cho việc gọi vào trong OS. Ngày nay, Microsoft thúc đẩy việc chuyển qua sử dụng .NET Framework cho việc phát triển các ứng dụng Windows. 

.NET framework sử dụng System class cho việc truy nhập các dịch vụ của hệ điều hành, những gì một lần nữa là một interface vào trong Win32 API.

Nguyên nhân cho sự tồn tại của các lớp cao hơn đó là Win32 không thực sự thân thiện với programmer. Nhiều operations yêu cầu việc gọi một chuỗi các hàm, thường yêu cầu khởi tạo các cấu trúc dữ liệu lớn và các cờ. Nhiều programmer đã nhanh chóng trở nên thất vọng khi sử dụng Win32 API. Các lớp cao hơn làm thuận tiện cho việc sử dụng, nhưng chúng cũng gây ảnh hưởng đến hiệu suất, bởi vì mọi lời gọi đến OS phải đi qua các lớp cao. Thỉnh thoảng các lớp cao thường thực hiện rất ít và tại một lúc khác chúng chứa một số lượng code đóng vai trò bắc cầu.

Nếu bạn đang dự định reversing các ứng dụng Windows, một điều quan trọng là bạn phải hiểu Win32 API. Đó là bởi vì bất kể giao diện cấp cao nào mà ứng dụng employ , cuối cùng nó cũng sử dụng Win32 API cho việc giao tiếp với OS. Một vài ứng dụng sẽ sử dụng native API, nhưng điều đó khá hiếm.

Core Win32 API chứa gần 200 APIs (nó phụ thuộc vào phiên bản của windows và có hay không undocumented Win32 APIs). Các APIs được chia thành 3 loại: Kernel, USER, và GDI.
Figure 3.3 shows mối quan hệ giữa Win32 interface DLLs, NTDLL.DLL, và kernel components.

Những thứ được liệt kê dưới đây là các thành phần quan trọng của Win32 API:

• Kernel APIs (còn được gọi BASE APIs) được implemented trong KERNEL.DLL module và bao gồm tất cả các dịch dụ không liên quan đến GUI, ví dụ như là file I/O, memory management, process and thread management, ... KERNEL32.DLL thường gọi native APIs thấp hơn từ NTDLL.DLL để implement các dịch vụ khác nhau. Kernel APIs được sử dụng để tạo và làm việc với kernel-level objects ví dụ như files, synchronization objects, ... tất cả được implemted trong system's object manager. 
• GDI APIs được implemented trong GDI32.DLL và bao gồm các dịch vụ đồ họa cấp thấp ví dụ như vẽ một đường thẳng, hiển thị một bitmap, ... GDI nói chung không được biết về sự tồn tại của windows và controls. GDI APIs được implemented chủ yếu trong kernel, bên trong WIN32K.SYS module. GDI APIs tạo ra system calls tới WIN32K.SYS để implement hầu hết APIs. GDI xoay quanh GDI objects được sử dụng cho drawing objects, ví dụ như device contexts, brushes, pens, ... Những đối tượng này không bị quản lý bởi kernel's object manager. 
• USER APIs được implemented trong USER32.DLL module và bao gồm tất cả các dịch vụ cấp cao liên quan đến GUI ví dụ như window-management, menus, dialog boxes, user-interface controls,... Tất cả GUI objects được vẽ bởi USER sử dụng GDI calls để thực hiện các hành động vẽ thực sự; USER phụ thuộc chặt chẽ vào GDI để thực hiện công việc của nó. USER APIs xoay quanh các đối tượng liên quan đến user-interface như là windows, menus, những thứ giống như vậy. Các đối tượng này không bị quản lý bởi kernel's object manager. 

The Native API 

Native API là interface thực sự với Windows NT system. Trong Windows NT Win32 API chỉ là một lớp nằm phía trên native API. Bởi vì NT kernel không có gì phải làm với GUI, native API không bao gồm bất cứ dịch vụ liên quan đến đồ họa nào. Native API là direct interface tới Windows kernel, cung cấp interfaces cho việc giao tiếp trực tiếp với memory manager, I/O system, object manager, processes và threads, ...

Các chương trình ứng dụng không bao giờ phải gọi trực tiếp tới native API - có thể phá vỡ tính tương thích của ứng dụng đó trong Window9x. Đó là một trong những lý do tại sao Microsoft không bao giờ document nó; các chương trình ứng dụng được mong đợi chỉ sử dụng Win32 APIs cho việc giao tiếp với hệ thống. Ngoài ra, bởi việc không làm lộ ra native API giữ lại sự tự do để thay đổi và revise nó mà không ảnh hưởng đến Win32 applications. 

Thỉnh thoảng việc gọi hoặc đơn thuần là hiểu một native API là quan trọng, trong những trường hợp có thể reverse implementation của nó để hiểu mục đích thực sự của nó. 

Về mặt kĩ thuật, native API là một tập hợp các hàm được exported từ cả NTDLL.DLL (cho user-mode callers) và từ NTOSKRNL.EXE (cho kernel-mode callers). APIs trong native API luôn luôn bắt đầu một trong 2 prefixes: hoặc là Nt hoặc là Zw , vì vậy các hàm có tên giống như NtCreateFile hoặc ZwCreateFile.

 

Processes and Threads

Processes và threads cả hai là đều là các đơn vị cấu trúc cơ bản trong Windows, chúng ta phải hiểu được chính xác chúng biểu diễn những gì. Bài viết này mô tả các khái niệm cơ bản về processes và threads và thảo luận về các chi tiết như việc chúng được implemented trong Windows như thế nào.

Processes

Một process là một khối xây dựng cơ bản (a fundamental building block) trong Windows. Một process là rất nhiều thứ, nhưng chủ yếu nó là một không gian địa chỉ bộ nhớ được biệt lập. Không gian địa chỉ này có thể sử dụng để running một chương trình, và các không gian địa chỉ được tạo ra cho mọi chương trình để chắc chắn rằng mỗi chương trình runs trong không gian địa chỉ của riêng nó. Bên trong không gian địa chỉ của một process hệ thống có thể nạp code modules, nhưng để thực sự run một chương trình, một process phải có ít nhất một thread running.

Threads

Một thread là một đơn vị thực thi code nguyên thủy (a primitive code excution unit). Tại bất kì một thời điểm cho trước, mỗi processor trong hệ thống đang running một thread, những gì có nghĩa là nó chỉ đang running một đoạn code; nó có thể code của chương trình hoặc OS code, không có vấn đề gì cả. Ý tưởng về threads đó là thay vì tiếp tục run một đoạn code cho khi nó kết thúc, Windows có thể quyết định ngắt một running thread tại bất cứ thời điểm nào và chuyển qua thread khác. Quá trình đó là trái tim trong khả năng của Windows nhằm đạt tới sự đồng thời.

Có thể dễ để hiểu threads là gì nếu bạn suy nghĩ về cách chúng được implemented bởi hệ thống. Về cốt lõi, một thread chỉ là một cấu trúc dữ liệu mà có CONTEXT data structure nói cho hệ thống về trạng thái của processor khi thread chạy lần cuối cùng. Khi bạn nghĩ về nó, một thread giống như là một little virtual processor mà có context riêng của nó và có stack riêng. Physical processor switches giữa nhiều virutal processors và thường xuyên bắt đầu thực thi từ thread's current context information và sử dụng stack của thread.

Lý do của việc một thread có thể có 2 stacks đó là trong Windows threads được luân phiên giữa running user-mode code và kernel-mode code. Cho ví dụ, một thread ứng dụng thông thường runs trong user mode, nhưng nó có thể gọi các system APIs được implemented trong kernel code. Trong các trường hợp như vậy system API code runs trong kernel mode từ bên trong calling thread. Bởi vì thread có thể run trong cả user mode và kernel mode nó phải có 2 stacks: một dành cho khi running trong user mode và một để khi nó running trong kernel mode. Việc tách biệt stack là một yêu cầu bảo mật và mạnh mẽ cơ bản. Nếu user-mode code có quyền truy nhập đến kernel stacks hệ thống có thể bị lỗ hổng đến các cuộc tấn công và nó có thể bị compromised bởi application bugs mà có thể ghi đề lên các phần của kernel stack.

Các thành phần quản lý threads trong Windows là scheduler và dispatcher, 2 thành phần này cùng vơi nhau chịu trách nhiệm cho việc quyết định những thread nào được chạy cho bao lâu, và cho việc thực hiện context switching khi gặp thời điểm nó muốn thay đổi running thread hiện hành.

Một khía cạnh đáng chú ý của kiến trúc Windows đó là kernel là preemtive và interruptible , nghĩa là một thread có thể thường xuyên bị ngắt khi running trong kernel mode như là nó có thể bị ngắt trong khi running trong user mode. Cho ví dụ, hầu như mọi Win32 API là có thể bị ngắt, như là hầu hết các internal kernel components. Cũng không phải ngạc nhiên, có một vài components hoặc code areas là không thể bị ngắt (bạn nghĩ điều gì sẽ xảy ra nếu chính scheduler bị ngắt...), nhưng chúng thường chỉ là các đoạn code  rất ngắn.

Context Switching

Chúng ta thường rất khó để hình dung được quá trình mà multithreaded kernel đạt được sự đồng thời với multiple threads, nhưng nó thực sự khá đơn giản. Bước thứ nhất cho kernel là để một thread run. Nó có ý nghĩa là để nạp context của nó (điều đó có nghĩa là entering một không gian địa chỉ bộ nhớ hợp lệ và khởi tạo các giá trị của tất cả các thanh ghi CPU) và để nó bắt đầu running. Thread sau đó runs bình thường trên processor (kernel sẽ không làm bất cứ thứ gì đặc biệt tại điểm này), cho đến thời điểm để chuyển qua một thread mới. Trước khi chúng ta thảo luận về quy trình thực sự của switching contexts, hãy nói về làm thế nào và tại sao một thread bị ngắt.

Sự thực rằng threads hay "từ bỏ" CPU theo ý muốn của nó, và kernel thậm chí không phải thực sự ngắt chúng. Điều đó xảy ra bất cứ khi nào một chương trình đang chờ cho một thứ gì đó. Trong Windows một trong những ví dụ phổ biến nhất đó là khi một chương trình gọi GetMessage Win32 API. GetMessage được gọi tại mọi thời điểm - nó là cách các ứng dụng yêu cầu hệ thống nếu user sinh ra bất cứ new input events (ví dụ như nhấp chuột hoặc gõ bàn phím) . Trong hầu hết các trường hợp, GetMessage truy nhập một message queue và chỉ extracts sự kiện tiếp theo, nhưng trong một vài trường hợp không có bất cứ messages trong queue. Trong những trường hợp như vậy, GetMessage chỉ enter vào waiting mode và không return cho đến khi new user input trở nên available.  

Objects and Handles

Windows kernel quản lý objects sử dụng một thành phần quản lý đối tượng trung tâm (a centralized object manager component). Object manager chịu trách nhiệm cho tất cả kernel objects ví dụ như sections, file, và device objects, synchronization objects, processes, và threads. Điều quan trọng để hiểu đó là thành phần này (object manager) chỉ quản lý các đối tượng liên quan đến kernel. Các đối tượng liên quan đến GUI ví dụ như windows, menus, và device contexts được quản lý bởi các object managers riêng biệt mà được implemented bên trong WIN32K.SYS

Viewing objects từ user mode, như hầu hết các ứng dụng vẫn làm, làm cho ta thấy chúng có cái gì đó hơi huyền bí. Điều quan trọng là phải hiểu rằng bản chất nằm phía ẩn sau tất cả các objects chỉ đơn thuần là các cấu trúc dữ liệu -- chúng thường được lưu trong nonpaged pool kernel memory. Tất cả objects sử dụng một standard object header, header này được sử dụng để mô tả các đặc tính cơ bản của đối tượng đó ví dụ như kiểu của đối tượng, reference count, name,... Object manager không biết gì về bất cứ các cấu trúc dữ liệu riêng biệt nào, nó chỉ biết header chung.

Kernel code thường truy nhập objects qua việc sử dụng direct pointers trỏ đến object data structures, nhưng các chương trình ứng dụng rõ ràng không làm như vậy. Thay vào đó, applications sử dụng handles để truy nhập từng đối tượng. Một handle là một process numeric identifier, cơ bản nó là một chỉ số (index) bên trong process's private handle table. Mỗi entry trong handle table chứa một con trỏ trỏ đến đối tượng phía dưới, đó là cách hệ thống liên kết handles với objects. Cùng với object pointer, mỗi handle entry còn chứa access mask dùng để xác định kiểu operations nào có thể thực hiện được trên đối tượng sử dụng handle đó.

Access mask của đối tượng là một số nguyên 32-bit được chia thành 2 16-bit access flag words. Upper word chứa generic access flags như là GENERIC_READ và  GENERIC_WRITE . Lower word chứa object specific flags như là PROCESS_TERMINATE , những gì cho phép bạn kết thúc một process sử dụng handle của nó, hoặc KEY_ENUMERATE _SUB_KEYS , những gì cho phép bạn liệt kê các subkeys của một open registry key. Tất cả access rights constants được định nghĩa trong WinNT.h trong Microsoft Platform SDK.

Đối với mọi object, kernel duy trì 2 reference counts: a kernel reference count và a handle count. Objects chỉ được xóa đi mỗi khi chúng có zero kernel references và zero handles.

Named objects

Một vài kernel objects có thể được đặt tên, những gì hỗ trợ một cách để nhận dạng chúng một cách duy nhất trong toàn hệ thống. Giả sử rằng, ví dụ, 2 processes đồng bộ một số operation giữa chúng. Một cách tiếp cận tiêu biểu đó là sử dụng một mutex object, nhưng làm thế nào chúng biết được chúng đang xử lý chung mutex? Kernel supports object names với ý nghĩa là nhận dạng từng objects. Trong ví dụ của chúng ta cả 2 processes có thể thử tạo một mutex có tên là MyMutex. Bất cứ ai mà thực sự tạo đối tượng MyMutex đầu tiên, chương trình thứ 2 sẽ chỉ mở một new handle đến object. Điều quan trọng là sử dụng một common name đảm bảo rằng cả 2 processes đang xử lý cùng một đối tượng. Khi một API tạo một đối tượng ví dụ như CreateMutex được gọi cho một đối tượng đã tồn tại, kernel tự động xác định đối tượng đó trong global table và return một handle đến nó.

Named objects được sắp xếp trong hierarchical directories, nhưng Win32 API giới hạn các ứng dụng user-mode truy nhập đến các thư mục này. Dưới đây là những thư mục quan trọng:

BaseNamedObjects  thư mục này là nơi tất cả conventional Win32 named objects, ví dụ như mutexes, được lưu. Tất cả named-object Win32 APIs tự động sử dụng thư mục này -- các chương trình ứng dụng không có quyền điều khiển trong thư mục này.

Devices Thư mục này chức device objects cho tất cả các active system devices hiện hành. Nói chung mỗi device driver đều có ít nhất một entry trong thư mục này, thậm chí những driver này không được kết nối đến bất cứ thiết bị vật lý nào. Nó bao gồm logical devices như là Tcp , và physical devices như Harddisk0 . Win32 APIs có thể không bao giờ access trực tiếp trong thư mục này - họ sử dụng symbolic links. 

GLOBAL ?? Thư mục này là một symbolic link. Symbolic links là old-style names cho kernel objects. Old-style naming là cơ chế đặt tên theo DOS. Nghĩ về việc gán cho mỗi drive một letter, ví dụ C:, và về việc truy nhập physical devices sử dụng một 8-letter name kết thúc với một colon, ví dụ COM1: Những thứ mới kể đó là DOS names, và trong modern versions của Windows chúng được linked đến các thiết bị thực trong Devices directive sử dụng symbolic links. Win32 applications chỉ có thể access devices sử dụng symbolic link names của họ.

Một vài kernel objects không được đặt tên và chỉ được nhận dạng bởi các handles của chúng hoặc kernel object pointers. Một ví dụ điển hình cho đối tượng loại này là thread object , những gì được tạo mà không cần đến tên và chỉ được biểu diễn bởi handles (từ usermode) hoặc bởi direct pointer trong object (từ kernel mode).

Stack Frames

Trong bài viết này tôi sẽ trình bày cách thức subroutines có thể khai báo parameters mà đã được định vị trí trong runtime stack.

Stack frame là một vùng của stack được thiết lập dành cho arguments được đưa vào, subroutine return address, local variables, và saved registers. Stack frame được tạo ra là kết quả của thứ tự các bước sau:

• Passed arguments, nếu có, được pushed vào stack.
• Subroutine được gọi, địa chỉ trả về của subroutine được pushed vào stack.
• Khi subroutin bắt đầu thực thi, EBP được pushed vào stack.
• EBP được set bằng với ESP. Từ đây, EBP giống như một tham chiếu cơ bản (base reference ) cho tất cả subroutine parameters. 
• Nếu có local variables, ESP được giảm đi để dự trữ không gian cho các biến trên stack. 
• Nếu bất cứ thanh ghi nào cần được saved, chúng được pushed vào stack. 

Cấu trúc của một một stack frame bị tác động trực tiếp bởi mô hình bộ nhớ của một chương trình và phụ thuộc vào quy ước passing argument. 

Có một lý do chính đáng để học về passing arguments lên stack; gần như hầu hết các ngôn ngữ lập trình bậc cao sử dụng chúng. Ví dụ, nếu bạn muốn gọi functions trong MS-Windows Application Programmer Interface (API), bạn phải pass arguments vào stack. 

Stack Parameters

Chúng ta đã biết một cách để pass arguments đến procedures thông qua việc sử dụng registers. Chúng ta có thể nói rằng các procedures sử dụng register parameters.  Register parameters được tối ưu hóa cho tốc độ thực thi của chương trình và dễ dàng sử dụng. Không may mắn rằng, register parameters thường tạo code "rác" trong các chương trình gọi. Các contents tồn tại trên thanh ghi phải được lưu lại trước khi chúng có thể nạp các giá trị argument vào. Một trường hợp là khi gọi DumpMem từ thư viện Irvine32:

pushad

mov esi,OFFSET array                       ; starting OFFSET

mov ecx,LENGTHOF array                ; size, in units

mov ebx,TYPE array                          ; doubleword format

call DumpMem                                   ; display memory

popad

Stack parameters cho phép ta một cách tiếp cận linh hoạt hơn. Chỉ là trước subroutine call, arguments được pushed vào stack. Cho ví dụ, nếu DumpMem sử dụng stack parameters, chúng ta gọi nó sử dụng code sau:

push TYPE array

push LENGTHOF array

push OFFSET array

call DumpMem

Hai kiểu arguments được pushed vào stack trong suốt subroutine calls:

• Value arguments (các giá trị của các biến và constants)
• Reference arguments (các địa chỉ của các biến)

Passing by Value khi một argument được passed bằng value , một bản sao của giá trị này được pushed vào stack. Giả sử chúng ta gọi một subroutine có tên là AddTwo, passing nó 2 số nguyên 32-bit:

.data

val1    DWORD  5

val2    DWORD  6

.code

push   val2

push   val1

call AddTwo

Dưới đây là hình ảnh của stack trước CALL instruction 

Một function call tương đương viết trong C++ là :

  int sum = AddTwo( val1, val2);

Quan sát ta thấy rằng arguments được pushed vào stack theo thứ tự ngược lại với thứ tự khi ta khai báo, đây là một chuẩn của C và C++. 

Passing by Reference

Một argument passed thông qua reference gồm địa chỉ (offset) của một đối tượng. Các statements sau gọi Swap , passing 2 arguments bởi reference:

push   OFFSET  val2

push   OFFSET  val1

call     Swap

Phía dưới là hình ảnh của stack trước khi gọi Swap:

Hàm Swap trong C/C++ có thể được viết như sau:

  Swap(&val1, &val2);

Passing Arrays 

Các ngôn ngữ lập trình bậc cao luôn luôn pass arrays tới subroutines qua địa chỉ. Là như sau, chúng push địa chỉ của một mảng vào stack. Subroutine sau đó lấy địa chỉ từ stack và sử dụng nó để truy nhập đến mảng. Dễ dàng để nhận ra tại sao ta không muốn pass một mảng bởi value, bởi vì nếu làm như vậy yêu cầu phải push từng phần tử của mảng vào stack một cách riêng lẻ. Những hành động như vậy thường rất chậm và có thể chiếm dụng nhiều không gian trong stack. Statements phía dưới đây thực hiện đúng cách thông qua việc passing offset của một mảng đến một subroutine có tên là ArrayFill:

.data

array DWORD 50 DUP(?)

.code

push OFFSET array

call ArrayFill

Accessing Stack Parameters

Các ngôn ngữ lập trình bậc cao có nhiều cách để khởi tạo và truy nhập đến parameters chung suốt function calls. Chúng tôi sẽ sử dụng C và C++ để làm ví dụ. Chúng bắt đầu với một prologue bao gồm các statements làm nhiệm vụ save EBP register và trỏ EBP đến đỉnh của stack. Tùy theo lựa chọn, bạn có thể push một lượng registers lên stack, các giá trị trong các thanh ghi này sẽ được restored khi function returns. Cuối của function bao gồm một epilogue nơi mà EBP register được restored và RET instruction returns đến hàm gọi. 

AddTwo Example hàm AddTwo dưới đây, được viết trong C, nhận 2 số nguyên được passed bởi giá trị và return tổng của chúng:

int AddTwo(int x, int y)

{

       return x + y;

}

Nào, hãy cài đặt hàm này trong assembly. Trong prologue của nó, AddTwo pushes EBP vào stack để bảo quản giá trị tồn tại của nó:

AddTwo PROC

              push ebp

Tiếp theo, EBP được set đến cùng giá trị với ESP, vì vậy EBP có thể là base pointer cho AddTwo's stack frame:

AddTwo PROC

              push ebp

              mov ebp, esp

Sau khi 2 instructions thực thi, figure phía dưới đây shows contents của một stack frame. Một function call ví dụ như AddTwo(5, 6) có thể tạo ra parameter thứ hai được pushed trên stack, theo sau là parameter thứ nhất:

AddTwo có thể push các thanh ghi bổ sung mà không cảnh báo offsets của stack parameters từ EBP. ESP có thể thay đổi giá trị, nhưng EBP thì không. 

Base-Offset Addressing  Chúng tôi sử dụng base-offset addressing để access stack parameters. EBP là base register và offset là một constant. 32-bit values được trả về trong EAX. Implementation phía dưới đây của AddTwo cộng parameters và trả về tổng của chúng trong EAX:

AddTwo  PROC

            push ebp

            mov ebp, esp

            mov eax, [ebp + 12]

            add eax, [ebp + 8]

            pop ebp

            ret

AddTwo ENDP

Explicit Stack Parameters

Khi stack parameters được tham chiếu với expressions như là [ebp + 8], chúng ta gọi chúng là explicit stack parameters. Lí do ta gọi như vậy là vì assembly code states rõ ràng offset của parameter như là constant value. Một vài programmers định nghĩa symbolic constants để biểu diễn explicit stack parameters, để làm cho code của họ dễ đọc hơn:

y_param  EQU [ebp + 12]
x_param  EQU [ebp + 8]

AddTwo  PROC
        push ebp
        mov ebp, esp
        mov eax, y_param
        add eax, x_param
        pop ebp
        ret
AddTwo ENDP

Cleaning Up the Stack

Phải có một cách nào đó để remove parameters khỏi stack khi một subroutine returns. Nếu không, một memory leak có thể xảy ra, và stack có thể bị corrupted. Cho ví dụ, giả sử statements sau trong main gọi AddTwo:

push   6
push   5
call     AddTwo

Giả thiết rằng AddTwo leaves 2 parameters trên stack, minh họa dưới đây shows stack sau khi returning từ call:

Bên trong main, chúng ta có thể cố lờ đi vấn đề này và hi vọng rằng chương trình của chúng ta kết thúc một cách bình thường. Nhưng nếu chúng ta call AddTwo từ một loop, stack có thể overflow. Mỗi call sử 12 bytes không gian stack - 4 bytes dành cho mỗi parameter, cộng thêm 4 bytes cho địa chỉ trả về của lệnh CALL. Vấn đề trở nên nghiêm trọng nếu chúng ta gọi Example1 từ main, những gì sau đó quay ra gọi AddTwo:

main PROC
call Example1
exit
main ENDP
Example1 PROC
push 6
push 5
call AddTwo
ret                           ; stack is corrupted!
Example1 ENDP

Khi lệnh RET trong Example1 thực thi, lúc này ESP trỏ đến số 5 chứ không phải trỏ về return address để chuyển luồng thực thi trở về main.

Như bạn đã biết, lệnh RET sẽ nạp giá trị 5 vào con trỏ lệnh và cố gắng chuyển điều khiển đến memory address 5. Nếu giá trị 5 nằm bên ngoài không gian địa chỉ của chương trình, processor có thể sinh ra một runtime exception để báo cho OS kết thúc chương trình.

The C Calling Convention  Một cách đơn giản để remove parameters ra ngoài runtime stack là cộng ESP với một giá trị nào đó bằng với kích thước của parameters. Sau đó, ESP sẽ trỏ tới stack location chứa địa chỉ trả về của subroutine. Như trong ví dụ sau:

Example1  PROC
          push   6
          push   5
          call     AddTwo
          add    esp, 8
          ret
Example1 END

Các chương trình được viết bằng C/C++ thường xuyên remove arguments ra khỏi stack trong hàm gọi sau khi một subroutine được trả về.

STDCALL Calling Convention  Một cách phổ biến khác để remove parameters khỏi stack là sử dụng một quy ước có tên là STDCALL . Trong thủ tục AddTwo, chúng ta cung cấp một tham số nguyên đến lệnh RET, những gì sau đó cộng 8 vào EBP sau khi returning về thủ tục gọi. Số nguyên phải bằng với số lượng bytes stack space được sử dụng bởi subroutin parameters:

AddTwo PROC
        push ebp
        mov ebp, esp
        mov eax, [ebp + 12]
        add  eax, [ebp + 8]
        pop  ebp
        ret 8

Ta có thể nhận ra một số điềm giống và khác giữa STDCALL và C, giống nhau ở chổ STDCALL pushes arguments vào trong stack theo thứ tự ngược lại giống như C. Bởi việc có một parameter trong lệnh RET, STDCALL giảm được số lượng code được sinh ra cho subroutine calls (giảm đi một lệnh) và đảm bảo rằng calling programs sẽ không bao giờ quên dọn dẹp stack. C calling convention, mặt khác, cho phép subroutines khai báo một số lượng parameters tùy biến. Caller có thể quyết định bao nhiêu arguments nó sẽ pass. Một ví dụ là hàm printf , hàm này có số lượng arguments phụ thuộc vào số lượng format specifiers trong initial string argument:

int  x = 5;
float y = 3.2;
char z = 'Z';
printf("Printing values:  %d, %d, %c", x, y, z);

Một C compiler pushes arguments lên stack theo thứ tự ngược lại, theo sau bởi một count argument ám chỉ số lượng arguments thực sự . Hàm lấy argument count và accesses từng arguments một. Function implementation không có một cách tiện lợi nào để encoding một constant trong RET instruction để clean up stack, vì vậy trách nhiệm này để lại cho caller.

Passing 8-Bit and 16-Bit Arguments on the Stack

Khi passing stack arguments đến procedures trong protected mode, tốt nhất là push 32-bit operands. Mặc dù bạn có thể push 16-bit operands trên stack, nhưng làm như vậy sẽ ngăn ESP aligned một doubleword boundary. Một page fault có thể xảy ra và runtime performance có thể bị degraded. Bạn nên mở rộng chúng lên 32 bits trước khi pushing chúng vào stack.

Thủ tục Uppercase sau nhận một character argument và return uppercase của nó vào trong AL:

Uppercase  PROC
          push  ebp
          mov  esp, ebp
          mov  al, [esp+8]
          cmp  al, 'a'
          jb     L1
          cmp  al, 'z'
          ja     L1
          sub  al, 32
L1:     pop   ebp
          ret    4
Uppercase  ENDP


Nếu chúng ta pass một character literal đến Uppercase, PUSH instruction sẽ tự động mở rộng character này lên 32 bits:

push   'x'
call     Uppercase

Registry

Nếu bạn đã từng làm việc với các hệ điều hành Windows, chắc hẳn ít nhiều bạn đã từng nghe qua hoặc là nhìn thấy registry. Bạn không thể nói được quá nhiều về Windows internals mà không thể không biết về registry bởi vì nó là cơ sở dữ liệu hệ thống chứa những thông tin cần cho hệ thống để boot được và các thông tin về cấu hình hệ thống, các thiết lập phần mềm trên toàn hệ thống để điều khiển hoạt động của Windows, cơ sở dữ liệu an ninh (the security database), các thiết lập cấu hình cho mỗi người dùng (ví dụ như screen saver nào được sử dụng).

Ngoài ra, registry là một cửa sổ vào trong dữ liệu không ổn định trong bộ nhớ, ví dụ như trạng thái phần cứng hiện hành của hệ thống (device drivers nào được nạp, resources chúng đang sử dụng,..) cũng như là Windows performance counters. Performance counters không thực sự trong registry, được truy nhập thông qua registry functions. Tôi sẽ nói về cách performance counter được truy nhập từ registry trong các phần tiếp theo.

Mặc dù nhiều Windows users và administrator sẽ chẳng cần thiết phải nhìn trực tiếp vào registry (bởi vì bạn có thể view hoặc thay đổi hầu hết các thiết lập cấu hình với các tiện ích dành cho người quản trị), nhưng nó vẫn là nguồn thông tin hữu dụng bởi vì nó chứa nhiều thiết lập gây ảnh hưởng đến hiệu suất của hệ thống cũng như là cư xử của hệ thống. (Nếu bạn quyết định thay đổi trực tiếp các thiết lập registry, bạn phải thực hành một cách cực kỳ thật trọng; bất cứ một sự thay đổi nào cũng có thể gây ảnh hưởng xấu đến hiệu suất của hệ thống hoặc có thể làm cho hệ thống không boot được). Hầu hết registry keys được nhắc tới trong bài viết đều nằm dưới HKEY_LOCAL_MACHINE, ngắn gọn là HKLM.

Registry đóng vai trò "chìa khóa" trong hệ thống cấu hình và điều khiển Windows. Nó là một kho lưu trữ cho các thiết lập toàn hệ thống và cho mỗi user. Mặc dù hầu hết con người ta nghĩ về registry như là static data được lưu trên hard disk, như bạn thấy trong bài viết, registry còn là một window bên trong các cấu trúc khác nhau trong bộ nhớ được duy trì bởi Windows executive và kernel. Bài viết này không mang ý nghĩa cung cấp tất cả những gì có liên quan đến các nội dung của Windows registry. Đó là một kiểu thông tin chuyên sâu được có trong tài liệu “Technical Reference to the Windows2000 Registry” help file nằm trong Windows 2000 resource kits (Regentry.chm), và đối với Windows XP và Windows Server 2003, các thông tin này có thể được tìm thấy trên mạng như là một phần của Windows Server 2003 Deployment Kit tại http://www.microsoft.com/windowsserver2003/techinfo/reskit/
deploykit.mspx.

Bước đầu, tôi sẽ cung cấp cho bạn một cái nhìn toàn cảnh về registry structure, một thảo luận về các kiểu dữ liệu nó hỗ trợ, và một cuộc dạo chơi để tìm hiểu về các thông tin quan trọng Windows duy trì trong registry. Sau đó chúng ta sẽ khai thác internals configuration manager, thành phần thực thi chịu trách nhiệm cho việc implementing registry database. Tôi sẽ cover cấu trúc trên đĩa của registry, làm cách nào Windows lấy được thông tin cấu hình khi một ứng dụng yêu cầu nó, và những tiêu chuẩn nào được thực hiện để bảo vệ cơ sở dữ liệu hệ thống quan trọng.

Viewing and Changing the Registry

Nói chung, bạn không nên edit registry một cách trực tiếp: các thiết lập ứng dụng và hệ thống được lưu trong registry có thể được thay đổi một cách thủ công nên có một user interface tương ứng để điều khiển việc chỉnh sửa. Tuy nhiên, như bạn đã thấy, một vài thiết lập nâng cao và debug không có editing user interface. Do đó, có một số lượng công cụ được tích hợp vào trong Windows để giúp bạn view và modify registry.

Windows 2000 có 2 tools để editing registry - Regedit.exe và Regedt32.exe - trái lại Windows XP và Windows Server 2003 chỉ có Regedit.exe. Nguyên nhân ? Đó là do phiên bản Regedit của Windows 2000 có khả năng tìm kiếm, importing, và exporting linh hoạt, được ported từ Windows 98 và do đó không hỗ trợ cho editing hoặc viewing registry security hoặc registry không được định nghĩa trên Windows 98. Windows 2000 includes Regedt32 bởi vì mặc dù nó không có những đặc tính mạnh mẽ về tìm kiếm hay là importing, exporting, nó được viết ra chỉ để chạy trên Windows 2000 và do đó nó hỗ trợ security và các kiểu dữ liệu chỉ có riêng trên Windows 2000. Regedit được included trong Windows XP và Windows Server 2003 includes security editing và nó hiểu tất cả các kiểu dữ liệu registry, và do đó không cần đến Regedt32.

Cũng có một số lượng registry tools sử dụng command-line. Ví dụ, Reg.exe, những gì được included trong Windows XP và Windows Server 2003 và available trong Windows 2000 Support tools, có khả năng import, export, back up, và restore keys, cung như là so sánh, modify, và delete keys và values.

Registry Usage

Có 3 thời điểm chủ yếu mà dữ liệu cấu hình được đọc:

• Trong suốt quá trình boot, hệ thống đọc các thiết lập để xác định xem các device drivers để load và cách các subsystems khác nhau - ví dụ như memory manager và process manager - cấu hình chính chúng và điều chỉnh cư sử hệ thống. 
• Trong suốt quá trình login, Explorer và các thành phần Windows khác đọc các ưu tiên trên mỗi user từ registry, bao gồm network drive-letter mappings, hình nền desktop, screen saver, menu behavior, và vị trí đặt icon. 
• Trong suốt quá trình startup, các ứng dụng đọc các thiết lập toàn hệ thống, ví dụ như danh sách các thành phần cài đặt tùy chọn và licensing data, cũng như là các thiết lập trên mỗi user có thể include vị trí của menu và toolbar và danh sách các document được truy nhập gần đay nhất. 

Tuy nhiên registry có thể được đọc tại bất cứ thời điểm nào cũng được, ví dụ như trong một hồi đáp đến sự kiện thay đổi registry key hoặc value. Một vài ứng dụng monitor các thiết lập cấu hình trong registry và đọc các thiết lập được cập nhật khi chúng nhìn thấy sự thay đổi. Nói chung, tuy nhiên, trên một idle system có thể không có registry activity.

Registry thường bị modified trong các trường hợp phổ biến sau:

• Mặc dù không phải là sự thay đổi, cấu trúc bên trong registry và nhiều thiết lập mặc định được định nghĩa bởi một prototype version của registry được ships trên Windows setup media được copied trên một cài đặt mới. 
• Các cài đặt ứng dụng tạo các thiết lập mặc định ứng dụng và các thiết lập mà phản ánh các lựa chọn cấu hình cài đặt. 
• Trong suốt quá trình cài đặt một device driver, hệ thống Plug and Play tạo các thiết lập trong registry để nói cho I/O manager cách để start driver và tạo các thiết lập khác mà cấu hình hoạt động của driver. 
• Khi bạn thay đổi ứng dụng hoặc các thiết lập hệ thống thông qua user interfaces, những sự thay đổi này thường được lưu trong registry. 

Note: Buồn thay, một vài ứng dụng thăm dò ý kiến của registry bởi việc tìm kiếm những thay đổi khi chúng sử dụng hàm RegNotifyChangeKey, những gì đặt một thread vào trạng thái sleep cho đến khi một thay đổi xảy ra đến một vùng của registry nơi chúng chú ý.

Registry Data Types 

Registry là một cơ sở dữ liệu sở hữu một cấu trúc tương tự như là của disk volume. Registry chứa keys, những gì tương tự như là các thư mục trên đĩa, và values , những gì được so sánh với files trên một đĩa. Một key là một container có thể chứa keys khác (subkeys) hoặc values. Values, mặt khác, lưu dữ liệu. Keys ở mức cao nhất được gọi là root keys. Tôi sẽ sử dụng thuật ngữ subkey và key thay phiên nhau. (Chỉ root keys không phải là subkeys.)

Cả keys và values đều sử dụng quy tắc đặt tên của file system. Do đó, bạn có thể nhận dạng một value với name mark, những gì được lưu trong một key được gọi là trade, với name trade\mark. Một ngoại lệ đối với naming scheme này đó là mỗi key's unamed value. Hai Registry Editor, Regedit và Regedt32, display những giá trị: Regedit displays unamed value như (Default); Regedit32 sử dụng <No Name>.

Values lưu các kiểu dữ liệu khác nhau và có thể là một trong 15 kiểu được liệt kê trong Table 4-1. Các giá trị chính của registry là REG_DWORD, REG_BINARY, hoặc REG_SZ. Values của kiểu REG_DWORD có thể lưu các số hoặc Booleans; REG_BINARY values có thể lưu các số lớn hơn 32 bits hoặc raw data như là encrypted passwords; REG_SZ lưu strings (UNICODE, dĩ nhiên) mà có thể biểu diễn các nhân tố như names, filenames, paths, và types.

Kiểu REG_LINK khá hấp dẫn bởi vì nó để một key trỏ đến một key hoặc một giá trị khác. Khi bạn đi qua registry thông qua một link, path searching tiếp tục tại đích của một link. Cho ví dụ, nếu \Root1\Link có một REG_LINL value \Root2\RegKey, và RegKey chứa giá trị RegValue, 2 paths nhận dạng RegValue: \Root1\Link\RegValue và \Root2\RegKey\RegValue. Như được giải thích trong phần tiếp theo, Windows sử dụng registry links: 3 trong 6 registry root keys là các liên kết đến subkeys bên trong 3 root keys không phải link. Links không được lưu lại; chúng phải được tạo một cách động sau mỗi lần reboot. 

Registry Logical Structure 

Bạn có thể chart một tổ chức của registry thông qua dữ liêu được lưu bên trong nó. Có 6 root keys (và bạn không thể thêm mới hay xóa đi những root keys đã tồn tại) lưu thông tin, nhưng trong Table 4-2

Table 4-2 The Six Root Keys

HKEY_CURRENT_USER: lưu dữ liệu liên quan đến user đang logged-on

HKEY_USERS: lưu thông tin về tất cả accounts trên một máy

HKEY_CLASSES_ROOT: lưu file liên quan và Component Object Model (COM) object registration information. 

HKEY_LOCAL_MACHINE: lưu thông tin liên quan đến hệ thống

HKEY_PERFORMANCE_DATA: lưu thông tin về performance

HKEY_CURRENT_CONFIG : lưu một vài thông tin về current hardware profile

Tại sao root-key names bắt đầu với H? Bởi vì root-key names biểu diến Windows handle (H) đến keys. Table 4-3 lists tất cả root keys và viết tắt của chúng

HKEY_CURRENT_USER

HKCU root key chứa dữ liệu liên quan đến preferences (các ưu tiên) và cấu hình phần mềm của user logged-on. N

Tổng quan về Bots và Botnet

Sử dụng hàng ngàn máy tính ma (zombie machines) để khởi động cuộc tấn công từ chối dịch vụ (distributed denial of service attack) hay còn gọi là DDOS nhằm vào enterprise và goverment internet resources bởi attackers đang trở thành một xu hướng nguy hiểm và đáng báo động. Gần đây, xu hướng này ngày càng tăng, attackers sử dụng Internet Relay Chat (IRC ) networks cho việc điều khiển và quản lý các infected internet hosts. Paper này cung cấp một toàn cảnh về malicious bot được điều khiển từ xa bởi attacker thông qua private IRC channels. Paper này cung cấp...

Tóm tắt
Sử dụng hàng ngàn máy tính ma để khởi động cuộc tấn công từ chối dịch vụ nhắm vào enterprise và gorverment internet resources thực hiện bởi attackers đang trở thành một xu hướng nguy hiểm trong giới tội phạm mạng. Để tạo ra một "lực lượng" zombie internet hosts, attackers thường infect machines của home users có kết nối băng thông rộng đến internet, networks được duy trì bởi các trường đại học và doanh nghiệp nhỏ, với trojans được điều khiển từ xa. Những người chủ sở hữu của các máy tính này được hình dung như là users có nhận thức về bảo mật trên internet tương đối thấp và bị giới hạn resources để bảo vệ hạ tầng của họ. Gần đây, có một xu hướng gia tăng trong giới attacker, sử dụng Internet Relay Chat (IRC) networks để điều khiển và quản lý infected internet hosts. Paper này cung cấp một overview về malicious bot, một trojan được điều khiển từ xa lây nhiễm trên infected internet hosts và được điều khiển từ xa bởi attacker thông qua private IRC channels.

Paper cung cấp kiến thức nền tảng nằm phía dưới IP protocol, IRC (RFC 2810) và covers các thuật ngữ được sử dụng để giải thích các hoạt động của bots, các thành phần được cần đến trong malicious bots infection, hiểu biết về những ứng dụng có thể có của bot infected machines sử dụng bởi attacker. Làm thế nào và tại sao một attacker chọn một hệ thống mục tiêu để infect, mô tả quá trình của malicious bot infecting một hệ thống và attacker điều khiển từ xa infected system thông qua IRC channels, liệt kê và mô tả các đặc điểm của một vài "known" bots, có một cái nhìn vào cách bots có thể được sử dụng như là một phần của chiến lược chiến tranh thông tin, cung cấp những khuyến nghị cho home user và system admin để ngăn chặn, phát hiện và respond đến các hành vi của malicious bot.

Giới thiệu

Internet do đặc tính hiện hữu của nó, bao gồm một lượng hữu hạn tài nguyên và attackers exploit nó thông qua việc làm cạn kiệt (exhauting) các dịch vụ máy tính và mạng với các truy vấn không hợp pháp (illegitimate requests), do đó từ chối truy nhập hợp lệ đến các dịch vụ này. Mô hình của DOS attack cần từ một attacker duy nhất tấn công vào một máy mục tiêu đến nhiều máy attacker flooding requests đến một targer duy nhất. Mô hình DDOS sau này được tinh luyện lại qua việc sử dụng nhiều handlers dành cho việc chuyển hướng và quản lý một số lượng lớn hosts tấn công vào một single target.

Các tools và kĩ thuật phục vụ cho DOS attack đã có sẵn và dễ dàng sử dụng . Trong paper “Trends in Denial of Service Attack Technology” George M.
Weaver & Kevin J. Houle from CERT® Coordination Center đã thảo luận về mô hình, nơi attackers nhiễm một lượng lớn internet hosts với trojans được điều khiển từ xa và direct chúng tấn công DDOS targets thông qua handlers, như là một cách thức tấn công phổ biến nhất. Hấp dẫn thay, việc sử dụng handler để quản lý và điều khiển một số lượng lớn zombie hosts (infected system chịu dưới sự điều khiển của attacker) trong những năm gần đây, được thay thế bằng Internet Relay Chat (IRC) networks, hoạt động như attacker's virtual command and control centers.

Sự phổ biến rộng rãi của IRC network và services giúp attacker ngụy tạo các hành vi và qua mặt các kĩ thuật phát hiện trong vai trò của IRC traffic hợp lệ. Infected hosts kết nối attacker hosted IRC channel được gọi là bots và mạng của những bots này kết nối đến một IRC channel được gọi là "botnet".

'Bots' là tương tự như 'agent' trong mô hình  DDOS truyền thống infect host machine và duy trì access cho attackers để điều khiển chúng thông qua 'handlers' tương tự như là 'botnets', trong khi chúng ta đang nói đến IRC networks. Thông thường, một bot được installed trên một victim machine thiết lập outbound connections đến standard IRC network service port và joins attacker private channel. Public IRC networks như là Efnet, Undernet hoặc DALnet, cung cấp cho attackers một hạ tầng ổn định và có khả năng mở rộng để duy trì, mở rộng, quản lý và điều khiển đội quân bots của họ.

IRC networks cung cấp cho attackers khả năng dễ dàng và mềm dẻo để điều khiển hàng trăm hoặc hàng ngàn bots (malicious program trên từng máy tính bị lây nhiễm). Nó còn giúp họ ngụy trang được những dấu hiệu của mình, việc tạo ra công việc theo dõi nguồn của cuộc tấn công bởi sys-admins và các tổ chức pháp luật trở nên khó khăn hơn rất nhiều.

Tiêu chí attackers sử dụng để lựa chọn victims cho mục đích lây nhiễm bots là những băng thông tốc độ cao và tính có sẵn cao. Các targets tiềm năng không bị giới hạn bởi university servers mà còn mở rộng đến user sử dụng internet băng thông cao tại nhà và ISPs. Thêm vào đó, có sự gia tăng của trojans dựa trên IRC và backdoors dành cho file sharing thông qua IRC channels.

Có cả hàng trăm hoặc hàng ngàn bot packages có thể cấu hình, có thể tinh chỉnh đầy rẫy trên internet và hầu hết là miễn phí. Chúng trải dài từ những code được viết một cách chuyên nghiệp phục vụ cho công việc đến of-the-shelf excutables sử dụng bởi script kiddies. Một sự bảo vệ chống lại bot infection bởi anti-virys packages bị giới hạn đến "known" bot.

Background

IRC là một giao thức internet được phát triển năm 1988 bởi Jarkko Oikarinen, với tính năng cơ bản cho phép con người kết nối ở bất cứ đâu trên Internet để tham gia vào real-time text based discussions. Mỗi discussion ở trên một "channel", và nhiều người có thể join vào cùng một lượt. Theo như RFC 2810, IRC protocol được thiết kế nhiều năm phục vụ cho text based conferencing. IRC Protocol dựa trên mô hình client-server, và  nó phù hợp để chạy trên nhiều máy trong một mô hình hình phân bổ. Một setup thông thường yêu cầu một single process (the server) đóng vai trò trung tâm cho clients (hay servers khác) kết nối đến, thực hiện vận chuyển tin nhắn và các chức năng khác.

Một setup tiêu biểu bao gồm một user running một "IRC client " program những gì kết nối đến một server trong một IRC network. Tất cả servers được liên kết nối và gửi messages từ một user này đến user khác thông qua IRC network. Một server có thể được kết nối đến một vài server khác và lên tới hàng trăm clients. Mặc định TCP service port của IRC là 6667 và IRC servers lắng nghe trên một dải port từ 6000-7000, mặc dù nó có thể được cấu hình để run trên bất cứ port nào.

Trong một trong những chế độ giao tiếp available trên IRC networks nhiều IRC clients kết nối đến IRC servers để form một nhóm luận lý như là một channel. Giao tiếp gửi bởi mỗi client đến IRC server được đưa đến tất cả IRC clients khác được kết nối đến channel đó.

Thuật ngữ 'bot' được lấy ra từ "ro-bot". Bot là một thuật ngữ chung được sử dụng để một tả một script hoặc là một tập hợp scripts được thiết kế để thực hiện các hàm đã được định nghĩa trước một cách tự động. Bots được sử dụng bởi search engines để spider online website content và bởi online games để cung cấp các đối thủ ảo. ví dụ, games thỉnh thoảng chúng ta đấu với máy tính trong khi online, bot hoạt động như là các đối thủ. Chức năng của bot trong channels cung cấp cơ chế quản lý access lists, di chuyển files, chia sẻ users, chia sẻ thông tin channel, bất cứ thứ gì khác nếu scripts được added.

Tổng kết lại, IRC bots được tự động và điều khiển bởi events những gì có thể là command được gửi trong channel bởi IRC hoặc client với đặc quyền cho phép.

Elements of Typical IRC Bot Attack

Bots trong các trường hợp biến thể được sử dụng bởi attackers để infect victim machines sau khi chúng bị compromised hoặc victim machine bị lừa cài đặt phần mềm độc hại. Bots joins vào IRC channel đã được cấu hình và chờ cho attackers command.  Figure phía dưới đây shows typical IRC bot attack và các yếu tố được yêu cầu.

• Bot thông thường là executable file, có khả năng thực hiện một tập hợp functions, mỗi trong số chúng được kích hoạt bằng một specific command. Một bot khi được cài đặt trên victim machine copies chính nó vào trong một thư mục cài đặt có thể cấu hình và thay đổi thông tin hệ thống để có thể start mỗi lần hệ thống boots. Trên nền tảng Windows bots có thể được add instance của nó đến HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\, kích thước tiêu biểu của một compressed bot là nhỏ hơn 15kb. Một off-the-shelf bot nói chung được sử dụng bởi attacker ít "nguy hiểm" có thể được download từ các diễn đàn trên Internet và được edited để include, remote IRC server mong muốn được kết nối, remote TCP port để sử dụng cho kết nối này, channel để join trên server đó và authentication password được refer như 'key' để có được access đến attackers private channel. attacker nguy hiểm hơn có thể thao tác đến các đặc tính như là files được tạo sau khi cài đặt và thư mục cài đặt nơi bot files được đặt bên trong sau khi cài đặt. Một điểm quan trọng đáng chú ý ở đây là bots không phải exploits trên OS hoặc ứng dụng, chúng là payload vận chuyển bởi worms hoặc được sử dụng để cài backdoor mỗi khi một máy được thêm vào. 

• Victim machine: là compromised internet host nơi mà malicious bot được cài đặt sau khi attacker đã exploit một lỗ hổng ứng dụng hoặc OS hoặc user bị lừa cài đặt malicious program. Mỗi khi infected target host được biết đến như Zombies. 
• Attacker: là một người cấu hình bot , nó bao gồm một máy để cài đặt malicious bot, điều khiển và directs bots mối khi nó joins vào IRC channel. 
• Control channel: Là một private IRC channel tạo bởi một attacker như là điểm tập kết của tất cả bots đê join mỗi khi chúng được cài đặt trên infected machine và đang online, nó bao gồm một channel name và một password 'key' để authenticate.
• IRC Server: là một server cung cấp IRC services, nó có thể là một nơi cung cấp dịch vụ hợp pháp như DALNET hoặc một máy khác bị attacker chiếm lấy. 
• Botnet: Tất cả bots mỗi khi được kết nối đến control channel tạo ra một botnet ví dụ như mạng của bots, đang chờ attacker command

Malicious user Bots & Botnet

Các hành vi nguy hiểm dưới đây được thực hiện bởi attacker sử dụng bots và botnets.

• Distributed denial of service attacks: đây là nguyên nhân trước hết cho việc sử dụng IRC bots của attackers. Attacker có thể command các máy zombies của nó thông qua botnets, để gửi một luồng UDP packets lớn hoặc luồng kích thước lơn ICMP requests hoặc flood TCP sync requests đến target servers. Với hàng trăm thậm chí hàng ngàn bots sẵn sàng nghe lệnh attacker có thể gây tắc băng thông của target server dẫn đến từ chối các requests hợp lệ. 
• Secondary local infection: với việc cài đặt bots attacker chiếm hoàn toàn quyền điều khiển trên victim machine, attacker có thể download và cài đặt key logger hoặc trojan để thu thập các thông tin có giá trị từ infected host, như là banking password, credit card numbers hoặc bất cứ thông tin cá nhân nào được lưu trên compromised machine. 
• Trade bandwith: Một ứng dụng khá hấp dẫn khác trên infected machine là kinh doanh bandwith của high speed bots (infected machine sẽ thường xuyên on, kết nối băng thông cao đến internet) giữa cộng đồng hacker. 
• Backdoor: bots được cài đặt trên compromised machines như là backdoors để duy trì access sau khi exploit, nhất là đã có IRC traffic hợp lệ trong mạng. Attacker có thể cấu hình bots để sử dụng cùng remote TCP port như là được sử dụng bởi legitimate IRC traffic, do đó giảm đi cơ hội phát hiện bởi sys-admins. 
• Host illegal data:Trong một xu huống attackers đang sử dụng malicious bots để làm cho victim machine là một phần của file sharing network và sử dụng không gian lưu trữ của họ để lưu trữ illegal files, software, pirated movies, nhất là trong trường hợp infected host là server với không gian lưu trữ lớn được kết nối thông qua một đường truyền internet tốc độ cao. IRC bots (như là Iroffer) được thiết kế cho file-sharing qua IRC.

Ngoài ra, việc theo dõi attacker thực sự cài đặt malicious bot lên victim machine và sử dụng nó cho illegal activity là khá khó khăn và hiếm khi được theo đuổi bởi ISPs hoặc sys-admins. Có thể rõ ràng từ đây, mục đích sử dụng phá hoại của bots và botnet bị giới hạn chỉ bởi trí tưởng tượng của attacker và có thể yêu cầu infected machine bên trong host of illegale activities.

Prime Targets/Victims

Điều mong muốn của attacker là host kết nối đến internet, do đó hầu hết các lỗ hổng cho phép lây nhiễm bots ít bị moniterd, high bandwidth, home computers hoặc university servers.

• High bandwidth: Một trong những việc mà hầu hết attacker thực hiện sau khi lây nhiễm bots là việc tích lũy được lượng bandwidth để tấn công servers mục tiêu thông qua DDOS.
• Availability: attacker thích machines thường xuyên trong trạng thái on, vì thế tính sẵn sàng là rất cao để thực hiện các mệnh lệnh.
• Low user awareness & monitoring capability:  Users mà có những hiểu biết hạn chế về security và có số lượng tài nguyên bị giới hạn để đầu tư cho các thiết bị điều khiển là mục tiêu của bots infection. Thiếu đi sự cập nhật cho hệ điều hành và ứng dụng thêm vào đó là sự không tồn tại của các thiết bị điều khiển truy nhập như firewall đem cho attackers cơ hội để bẻ gãy hệ thống và duy trì bots trong một thời gian dài mà không bị nhận dạng hoặc bị truy tìm nguồn gốc. 
• Location: các máy mục tiêu của attacker, là những máy có vị trí địa lý rất xa so với attacker làm cho việc tìm ra nơi đầu sỏ là rất khó. 

Profile tiêu biểu mà fits tất cả các tiêu chí của một kết nối băng thông rộng trong một khu dân cư rộng hoặc university servers đó là được kết nối đến internet băng thông rộng và hầu như mọi lúc đều available. 

Attackers thường target các kết nối băng thông rộng cung cấp bởi ISP subnets hoặc university subnets mà có ít hoặc không có các thiết bị điều khiển truy nhập, thường thì có rất ít việc monitor kết nối mạng tại đây. 

Bots Infection & Control Process

Phần này mô tả quá trình attackers sử dụng bots, tinh chỉnh nó để phù hợp với nhu cầu của họ, exploiting victim host, infecting nó với malicious bot và điều khiển bots để attack targets khác hoặc sử dụng như là zombies. 

Coding/Editing: Quá trình bắt đầu phụ thuộc vào các kĩ năng của attacker, bởi lẽ họ có thể editing known bots có sẵn trên các diễn đàn phần mềm hoặc viết code của mình với các thành phần có thể cấu hình theo ý của họ, IRC server nơi bot sẽ kết nối mỗi khi được cài đặt trên victim machine, remote IRC TCP service port để kết nối, private channel name để join, password hoặc key để authenticate bots access đến private channel. Thêm vào đó, phụ thuộc vào mục đích cụ thể bot được sử dụng, bot có thể thay đổi location và name của file được đặt infected machine. Thậm chí hơn nữa attacker có thể lựa chọn việc sử dụng dynamic hoặc multiple channels mà một bot joins vì thế có thể duy trì được access đến botnet của họ trong trường hợp chúng bị banned bởi một IRC server cụ thể. Để làm được điều đó, attackers sử dụng các service providers như dyndns.com hoặc no-ip.com để liên kết dynamic ip mapping đến IRC server cho bots để join.

Figure phía trên show một single instance của bot infection, quá trình được lặp lại cho đến khi có một số lượng lớn hosts để tạo một đội quân bots hoặc zombie machines. 

Attacker, cố gắng infect victim machines hoặc thông qua exploiting một vài lỗ hổng hệ điều hành hoặc ứng dụng hoặc lừa user thực thi một malicious program để cài đặt bots. (1) Cách thông thường để attacker infecting một lượng lớn nhóm internet hosts là sử dụng exploit của các lỗ hổng chưa được biết đến,[NDNN] sử dụng nó để có được truy nhập đến victim machine và cài đặt bots như là backdoor để duy trì truy nhập. Quá trình được mô tả có thể được tự động bằng việc sử dụng một worm được định hướng, worm này sẽ scan qua một target subnet để tìm một lỗ hổng, exploit một lượng lớn systems chưa được vá và infect chúng với malicious bot. [ZDNET] theo một cách khác exploit unpatched web applications và lừa user thực thi một vài chương trình nguy hiểm hoặc virus để lây nhiễm bots. User có thể install một IRC client với trojan bên trong, trong khi đang thực hiện các công việc hợp lệ của IRC client nó đồng thời cài đặt một bot trên user machine. 

Sau khi bot installs trên victim machine nó sao chếp chính mình vào thư mục cài đặt và cập nhật registry keys trong trường hợp nền tảng Windows. Trong giai đoạn thứ 2, bot cố gắng kết nối đến IRC server với một nick name được sinh ra một cách ngẫu nhiên ví dụ một tên duy nhất hoặc handle biểu diễn bot nằm trong private channel của attacker. Bot sử dụng 'key', một mật khẩu xác thực để join private IRC channel của attacker. 

Hơn nữa có nhiều lần attackers sử dụng public IRC servers để phục vụ cho các hành vi của chúng và có thể bị banned bởi IRC administrators, do vậy đánh mất đội quan botnet của họ. Để tránh điều đó, attacker thỉnh thoảng sử dụng service providers như dyndns.com hoặc no-ip.com để (3) dynamic map bots của họ đến nhiều IRC servers. 

Mối khi (4) bot được cài đặt trên victim machine, nó joins attackers channel với unique nick name, như là một phần của attacker's botnet army đang chờ instructions. (5)

Thông thường khi nhiều bots join IRC channel attacker sẽ cho chúng đăng nhập vào (6) với một mật khẩu truy nhập phức tạp và bị mã hóa, đảm bảo rằng bots không thể bị điều khiển bởi người khác và làm cho nó khó bị hijack hơn. Sau khi yêu cầu truy nhập được chấp nhận attacker có thể direct và điều khiển từ xa hoạt động của một lượng lớn infected zombies thông qua botnet đso để tấn công các mục tiêu khác (7) hoặc sử dụng nó cho các hành vi gây hại khác.

Botnet Role in Information Warfare

Botnet hay là một đội quân bots với tốc độ cao có thể được sử dụng một cách hiệu quả để duy trì khả năng của DDOS attack và phát động các cuộc tấn công phối kết hợp tại bất cứ thời điểm mong muốn nào theo sự hướng dẫn của control master thông qua attacker. "Cable bots" cụm từ được sử dụng trong cộng đồng hacker để mô tả bots cài đặt trên compromised hosts kết nối đến internet thông qua các đường liên kết băng thông cao hoạt động giống như zombies chực chờ sự kích hoạt từ controller của nó, cung cấp cho attacker một lượng băng thông tích lũy để exploit hoặc deny access đến các dịch vụ trong máy tính mục tiêu. Trong bối cảnh là một tổ chức hoặc các hoạt động gián điệp chính phủ, một attacker có thể thu thập thông tin riêng tư trong một thời gian dài mà không bị cảnh báo.

Defending Against Bots & Botnet

Việc chống lại bots infection và attack có thể được phân ra thành 3 chặng : ngăn chặn, phát hiện và phản hồi như trong paper “ Botnet: Detection and Mitigation “ viết bởi Jim Jones và các giải thích phía dưới đây là dưới vai trò của home user và sys-admin, chi tiết của mỗi chặng như sau:

• Giai đoạn ngăn chặn: Khuyến nghị các thước đo, tiêu chuẩn user hoặc admin có thể thực hiện để ngăn cho hệ thống hoặc mạng của họ tránh khỏi bots infection. Chặng này phác thảo các thước đo ngăn chặn mà home user và sys-admin có thể implement để chống lại bots infection. 
• Giai đoạn phát hiện: Mesuares user và sys-admin có thể triển khai để nhận dạng một hành vi gây hại của bots trên máy hoặc là trong mạng. Nó phác thảo guidelines chung mà có thể được sử dụng để quan sát hoặc verify các hành động đáng ngờ. 
• Giai đoạn phản hồi: recommends hành động mà home-user, sys-admin có thể thực hiện để response đến bots infecting machine hoặc network.

Home User : prevention

•  Cần có những hiểu biết chung về security và privacy đối với tất cả online users. Có được sự hiểu biết là cách tốt nhất để ngăn malicious bots lây nhiễm vào computers. 
• Như đã nói từ trước cách phổ biến nhất của việc lây nhiễm là malicious bots đang compromising host thông qua việc exploiting các lỗ hổng trong OS hoặc các ứng dụng được cài đặt. Following vendor guidelines về sử dụng an toàn, patch và updates hệ điều hành và các ứng dụng 

Basic Dynamic Analysis: Sandbox

Dynamic analysis là bất cứ quá trình phân tích nào được thực hiện sau khi thực thi malware. Dynamic analysis techniques là bước thứ hai trong quá trình phân tích malware. Dynamic analysis thường được thực hiện sau basic static analysis đã được thực hiện xong, có hay không obfuscation, packing hoặc là việc phân tích đã tận dụng hết các kĩ thuật phân tích tĩnh chưa. Nó có thể yêu cầu monitering malware khi nó runs hoặc là kiểm tra hệ thống sau khi malware đã được thực thi.

Không giống như static analysis, dynamic analysis giúp bạn quan sát được các chức năng thực sự của malware, bởi vì, cho ví dụ, sự tồn tại của một action string trong một binary không có nghĩa là action sẽ thực sự được thực thi. Dynamic analysis còn là một cách hiệu quả để nhận dạng những chức năng mà malware thực hiện. Cho ví dụ, nếu malware của bạn là một keylogger, dynamic analysis có thể cho phép bạn tìm được vị trí của keylogger's log file trên hệ thống, phát hiện ra những kiểu records nó giữ, giải mã được nơi nó gửi thông tin của nó, và còn nhiều thứ khác. Những kiểu thông tin như vầy có thể rất khó có được khi ta chỉ sử dụng basic static techniques.

Mặc dù dynamic analysis techniques là cực kì mạnh mẽ, chúng chỉ nên được thực hiện sau khi basic static analysis đã được hoàn thành, bởi vì dynamic analysis có thể đặt mạng và hệ thống của bạn vào mối nguy hiểm. Dynamic techniques cũng có những giới hạn của chúng, bởi vì không phải tất cả code paths có thể thực thi khi một mảnh malware được run. Cho ví dụ, trong trường hợp command-line malware mà yêu cầu arguments, mỗi argument có thể thực thi các chức năng khác nhau của chương trình, và nếu không biết về options bạn không thể nào phân tích động tất cả các chức năng của chương trình. Bạn có thể cần sử dụng advanced dynamic hoặc static techniques để tìm ra cách làm cho malware thực thi tất cả các chức năng của nó. Bài viết này mô tả basic dynamic analysis techniques.

Sandboxes: The Quick-and-Dirty Approach

Một vài sản phầm phần mềm "tất cả trong một" có thể được sử dụng để thực hiện basic dynamic analysis, và phổ biến nhất là sử dụng sandbox. sandbox là một cơ chế bảo vệ (security mechanism) dành cho việc running các chương trình không đáng tin mà không phải lo sợ nó ảnh hưởng đến các hệ thống thực. Sandboxes bao gồm các môi trường được ảo hóa mà thường mô phỏng các dịch vụ mạng theo một vài kiểu mẫu nào đó để đảm bảo rằng phần mềm  hoặc là malware được tested sẽ hoạt động bình thường.

Using a Malware Sandbox

Nhiều malware sandboxes - như là Norman SandBox, GFI Sandbox, Anubis, Joe Sandbox, ThreatExpert, BitBlaze, và Comodo Instant Malware Analysis - sẽ phân tích malware miễn phí. Hiện tại, Norman Sandbox và GFI Sandbox (ban đầu có tên là CWSandbox) là 2 sandboxes phổ biến nhất.

Các sandboxes  cung cấp output dễ hiểu và là thích hợp cho bước phân loại ban đầu, miễn là bạn submit malware của mình lên sandbox websites. Mặc dù sandboxes được tự động, bạn có thể chọn để không phải submit malware chứa thông tin về công ty lên public website.

Hầu hết sandboxes làm việc tương tự như nhau, vì vậy tôi sẽ thảo luận về một sandbox, GFI sandbox. Figure 4-1 hiển thị bảng nội dung của một PDF report được sinh ra bởi việc running một file thông qua GFI Sandbox's automated analysis. Malware report bao gồm nhiều chi tiết khác nhau về malware, như là hành vi mạng nó thực hiện, file nó tạo ra, kết quả sinh ra thông qua việc scan với VirusTotal,...

 Reports được sinh bởi GFI sandbox khác nhau trong số lượng sections chúng chứa, dựa trên những gì analysis tìm được. GFI sandbox report 6 sections trong Figure 4-1, như sau:

• Analysis Summary liệt kê static analysis information và một toàn cảnh ở mức cao của các kết quả phân tích động. 
• File Activity section liệt kê các files được mở, được tạo, hoặc bị xóa cho mỗi process bị tác động bởi malware. 
• Created Mutexes section liệt kê mutexes tạo bởi malware. 
• Registry Activity section liệt kê các thay đổi đến registry.
• Network Activity section bao gồm network activity được sinh ra bởi malware, bao gồm cả việc thiết lập một listening port hoặc thực hiện một DNS request. 
• VirusTotal Results section liệt kê các kết quả của VirusTotal scan đối với malware.

Sandbox Drawbacks

Malware sandboxes thường có một vài nhược điểm chính. Cho ví dụ, sandbox đơn giản chỉ run executable, mà không có command-line options. Nếu malware executable yêu cầu command-line options, nó sẽ không thực thi bất cứ code nào và nó chỉ run khi cung cấp một option. Ngoài ra, nếu subject malware của bạn đang chờ cho command-and-control packet được trả về trước khi launching một backdoor, backdoor sẽ không được lanched trong sandbox. 

Sandbox có thể không record được tất cả events, bởi vì cả bạn lẫn sandbox không thể chờ đợi trong một thời gian đủ dài. Cho ví dụ, nếu malware được thiết lập để sleep trong vòng một ngày trước khi thực hiện các hành vi nguy hiểm, bạn có thể lỡ mất sự kiện đó. (Hầu hết sandboxes hook Sleep function và thiết lập nó ngủ chỉ trong một thời gian ngắn, nhưng để ngủ thì đâu phải chỉ có một cách này, và sandboxes không thể theo kịp tất cả những cách thức trên.)

Các khuyết điểm tiềm ẩn khác bao gồm:

• Malware thường phát hiện khi nó đang đực running trong một máy ảo, và nếu một máy ảo bị phát hiện, malware có thể dùng việc running hoặc trở mặt cư xử khác đi. Không phải tất cả sandboxes đều giải quyết được vấn đề này. 
• Một vài malware yêu cầu sự hiện diện của registry keys nhất định hoặc files trên hệ thống mà những thứ này có thể không được tìm thấy trong sandbox. Nhiều cái còn yêu cầu chứa dữ liệu hợp lệ, ví dụ như commands hoặc encrytion keys. 
• Nếu malware là một DLL, một lượng nhất định exported functions sẽ không được invoked một cách thích hợp, bởi vì một DLL sẽ không run dễ dàng như là một excutable. 
• Sandbox environment OS có thể không đúng với malware. Cho ví dụ, malware có thể crash Windows XP nhưng sẽ run mà không hề gì trong Windows 7.
• Một sandbox không thể nói cho bạn những gì malware làm. Nó có thể report các chức năng cơ bản, nhưng không thể nói cho bạn nếu malware là một custom Security Account Manager (SAM) hash dump utility hoặc một encryted keylogging backdoor. 

Designing Programs Using Abstract Data Types

Abstract data types là một vấn đề lớn. Chúng dẫn tới một cách suy nghĩ khác về tổ chức các chương trình lớn. Khi chúng ta nghĩ về thế giới, chúng ta dựa trên abstractions. Trong thế giới tài chính con người nói về cổ phiếu, về trái phiếu. Trong thế giới khoa học họ lại nói về proteins và residues. Khi cố gắng để hiểu những khái niệm này, chúng ta thu thập một vài dữ liệu liên quan và các đặc tính của các kiểu đối tượng vào trong một package. Cho ví dụ, chúng ta nghĩ về các cổ phiếu như là có một tỉ lệ và có một hạn định như là data attributes. Chúng ta còn có thể nghĩ về cổ phiếu như là có các hành động ví dụ như "set price" và "calculate yield to maturity". Abstract data types cho phép chúng ta kết hợp kiểu tổ chức như vậy trong thiết kế các chương trình.

Data abstraction khuyến khích program designers tập trung vào data objects hơn là functions. Nghĩ về một chương trình như là một tập hợp các kiểu hơn là tập hợp các hàm đem lại cho ta một cái nhìn sâu sắc về việc tổ chức chương trình. Giữa nhiều thứ khác, nó khuyến khích một người nghĩ về chương trình như là một quá trình của việc kết hợp các chunks lớn lại với nhau, bởi vì data abstractions bao hàm nhiều tính năng hơn chỉ là từng hàm. Nó còn dẫn chúng ta đến việc nghĩ về bản chất của lập trình không phải là việc viết từng dòng code mà là soạn ra từng modules.

Sự có sẵn của reusable abstractions không chỉ rút ngắn thời gian phát triển, mà còn thường xuyên dẫn đến những chương trình đáng tin cậy, bởi vì mature software thường xuyên đáng tin cậy hơn new software

Xây dựng lab phục vụ cho phân tích động malware

Malware labs có thể cực kì đơn giản hoặc rất phức tạp. Tất cả phụ thuộc vào resources hiện có của bạn (ví dụ như hardware, networking equipment, Windows licences, và những thứ khác), phụ thuộc vào bao nhiêu công việc phân tích bạn muốn tự động hóa, bao nhiêu options bạn muốn có. Bài viết này chỉ cho bạn cách set up một lab nhỏ bao gồm các mục tiêu ảo (virtual targets) và các mục tiêu vật lý (physical targets) sử dụng Internet thực hoặc mô phỏng. Hình phía dưới shows một ví dụ của môi trường lab.

Mô hình lab trên gồm các thành phần sau:

• Physical targets: Đây là các máy tính xài hệ điều hành Windows, chúng sẽ đảm nhiệm việc thực thi malware. Đừng lo lắng về việc lây nhiễm malware lên các máy vật lý. Bạn có thể ngăn chặn không cho chúng lây malware lây nhiễm với Deep Freeze , hoặc bạn cũng có thể re-image chúng một cách nhanh chóng qua các giải pháp như Truman và FOG. Khi FOG  d được thảo luận trong Recipe 7-8, những physical targets được coi như là FOG clients. Dĩ nhiên, các máy tính thật không phải là một yêu cầu, nhưng thật là tốt khi ta có chúng trong trường hợp ta cần phân tích VM-aware malware. 
• Virtual targets: Đây là các máy ảo chạy Windows bạn cũng sẽ thực thi malware trên các máy này. Mỗi khi bạn xong việc, bạn có thể phục hồi chúng về trạng thái trước khi bị lây nhiễm. Chúng tôi khuyến nghị bạn nên có ít nhất một hoặc hai VMs running các phiên bản khác nhau của Windows. Trong bài viết này, khi nhắc đến virtual targets tôi còn sử dụng hai thuật ngữ là virtual machine guests và VMs. 
• Controller: Đây là một máy tính vật lý chạy Linux. Nó runs imaging software để điều khiển physical targets, các phần mềm máy ảo (như là VMware hoặc VirtualBox) để điều khiển virtual targets, và các chương trình để điều khiển, log, hoặc mô phỏng truy cập mạng. Xuyên suốt bài viết này, tôi nhắc tới controller như là FOG server và virtual machine host, phụ thuộc vào vai trò của nó trong vấn đề ta thảo luận. 

Thông thường chúng ta chỉ xài một laptop, nhưng với những yêu cầu phía trên đòi hỏi ta phải có 2 máy thật (Physical targets và Controller). Bạn có thể tạo một lab dựa trên một máy tính duy nhất. Tôi khuyến cáo bạn nên sử dụng Linux như là hệ điều hành của controller, nhưng nó không phải là yêu cầu, chỉ là lựa chọn của bạn mà thôi. Bạn cũng có thể tạo một portable, personal lab trên các máy tính chạy Windows hoặc Mac OS X. Tuy nhiên, bởi vì chúng ta không thể cung cấp instructions trên mọi cấu hình có thể, tôi sẽ sử dụng setup trong Figure 7-1 như là một mô hình chung trong bài viết này và tôi sẽ chỉ ra những chỗ bạn cần điều chỉnh nếu lab của bạn khác với cách thức chung.

Mạng trong mô hình này được chứa trong một LAN duy nhất bởi vì đó là những gì người ta sử dụng nhiều nhất. Mặc dù không được chỉ ra trong Figure 7-1, tôi đang giả định rằng firewall có một địa chỉ IP bên ngoài để giao tiếp với Internet. Nêu bạn có quyền truy nhập đến một mạng lớn hơn hoặc bạn có nhiều địa chỉ external IP lấy từ ISP của bạn, khi đó bạn có thể gắn cho mỗi target những IP để nó có thể được route.

Trước khi bắt đầu với việc setting up một lab , luôn nhớ trong đầu rằng việc setting up một môi trường an toàn là rất quan trọng, nếu bạn không muốn compromise hệ thống host và controller của bạn. Virtual machines chia sẻ rất nhiều resources với host computer và một cách nhanh chóng có thể trở thành một nguy cơ an ninh nếu bạn cấp phép cho chúng. Dưới đây là một vài điểm giúp bạn ngăn chặn malware "chạy thoát" khỏi môi trường bị cô lập đến nơi mà chúng bị hạn chế:

• Đảm bảo rằng phần mềm máy ảo bạn đang sử dụng đã được cập nhật. Các lỗ hổng trong máy ảo có thể dẫn đến việc lây nhiểm malware lên host của bạn.
• Cấu hình firewall trên host của bạn để drop incoming packets đến từ targets. 
• Nếu bạn không muốn cho malicious code mà bạn run trong target có thể đi vào Internet, chắc chắn rằng bạn đã disable virtual network card, sử dụng host-only networking configuration, hoặc chứa traffic với simulation scripts (sẽ thấy trong Recipe 7-3)
• Disable shared folders giữa host và target hoặc làm cho chúng read-only.
• Ngăn chặn target truy nhập tới bất cứ shared devices hoặc removable media nào, ví dụ USB drives được cắm vào host của bạn. 
• Đừng tùy chỉnh (customize) target system của bạn với bất cứ thông tin nào, nếu bị leaked bởi một trojan, các thông tin này có thể được sử dụng để nhận dạng bạn. 

Bạn cần có kiến thức về TCP/IP, Linux system administration, và Windows system administration. Bạn cần biết sử dụng máy ảo như VMware hoặc Virtual Box. Bạn cần phải quen thuộc với forensic tools, cũng như là khả năng tùy chỉnh Perl và Python scripts để phù hợp với nhu cầu của bạn. 

Networking

Cấu hình mạng hợp lý trong môi trường lab của bạn là một bước quan trọng cho việc capturing và phân tích traffic mà malware sinh ra. Việc giải quyết thách thức này yêu cầu sự hiểu biết về các network settings khác nhau mà hầu hết các sản phẩm máy ảo cung cấp. 

Tham khảo Table 7-1, đây là một bảng tổng kết về các chế độ mạng: host-only, NAT/shared, và bridged. 

Ba modes được định nghĩa như sau:

• Host-only mode: Mode này tạo ra một private LAN được chia sẻ giữa host và VMs của nó. VMs không thể giao tiếp với các hệ thống bên ngoài- những hệ thống mà có thể tốt hoặc xấu, dựa trên mục đích của bạn. Đó là rất tệ nếu bạn muốn cho phép malware liên hệ (contact) với các sites thực tế trên Internet, bởi vì nó sẽ không hoạt động, nhưng một điều tốt đó là nếu bạn muốn chứa traffic trong môi trường sandbox của cá nhân bạn . 
• NAT/Shared mode: VMs contact với máy khác trong LAN hoặc Internet, nhưng các kết nối thường có địa chỉ IP nguồn là địa chỉ IP của host. Các máy khác khổng thể khởi tạo các kết nối đến ngược trở lại VMs nếu không có cấu hình port-forwarding trên máy host. 
• Bridge mode: VMs chia sẻ physcal Ethernet adaptor của host, nhưng chúng các địa chỉ IPv MAC của riêng chúng. VMs xuất hiện trong cùng local subnet với host. Đó là cấu hình duy nhất cho phép các máy khác tạo ra các kết nối gửi đến VMs. Nó còn là mode duy nhất cho phép các máy bên ngoài, như là router hoặc firewall, để phân biệt giữa traffic sinh ra bởi host và traffic sinh ra bởi một VM trên host. 

Chúng tôi khuyến nghị sử dụng bridged mode cho các VMs của bạn và gán cho chúng các địa chỉ IP vì vậy bạn mới có thể xác định được VM nào chịu trách nhiệm cho traffic mà bạn capture. Dĩ nhiên, nếu bạn chỉ có một VM và không có nhu cầu cho incoming connections đến VM của bạn, khi đó NAT/Shared mode sẽ thích hợp. 

RECIPE 7-1: ROUTING TCP/IP CONNECTIONS IN YOUR LAB

Trên máy của bạn, đối với controller trong sơ đồ ở đầu bài, sử dụng ifconfig để xác định địa chỉ IP của nó. Sau đó sử dụng ipconfig trên Windows targets của bạn để làm điều tương tự. Kiểm tra tất cả các máy nằm chung một subnet và đảm bảo rằng bạn có thể ping controller từ Windows targets. Để thuận tiện cho việc tham khảo, Table 7-2 cung cấp các giá trị có liên quan lấy từ lab của tôi, những thứ này sẽ còn liên quan trong các phần sau. 

Note: Nếu bạn bị hạn chế về mặt hardware, bạn có thể sử dụng máy ảo Linux như là controller. Trong trường hợp đó, bạn sẽ cần tối thiểu 2 VMs - một để running Windows (the target) và cái kia để running Linux (the controller).

Thế nào, bây giờ bạn đã kiểm tra được tính liên thông của mạng giữa controller và targets của bạn, bạn sẽ cần tạo ra một vài thay đổi để tất cả traffic sinh ra bởi programs trên target "đổ" vào controller. Chúng ta sẽ thảo luận một vài cách thức để thực hiện điều đó, vì vậy bạn có thể đánh giá được những điểm mạnh và điểm yếu, nhưng tôi thực sự khuyên bạn nên sử dụng chỉ một cách thức đó là kĩ thuật IP routing. 

Redirecting DNS

Nếu bạn đã biết DNS hostname của server(s) được liện hệ với malware, bạn có thể modify hosts file để điều hướng các kết nối đến controller's IP. Hosts file được đặt trong thư mục %SYSTEMROOT%\config\drivers\etc và nó được định dạng như sau:

# redirect DNS to the controller’s IP
172.16.176.130 commandserver.com

Entry phía trước forces processes trên target machine để kết nối với địa chỉ IP của controller sau khi resolving commandserver.com với DNS. Nếu bạn có một process trên controller của bạn lằng nghe incoming connections, bạn có thể log traffic và nhìn xem malware có thể làm gì khi kết nối thành công đến server thực sự commandserver.com.

Có một vài điểm yếu với phương thức này. Thứ nhất, bạn sẽ không thường xuyên "chắc ăn" biết được hostname mà một sample contact đến, và giả sử nếu bạn biết được đi nữa, thêm các entries đến host files mỗi lần phải thực hiện một cách thủ công và tẻ nhạt. Thứ hai, nếu malware resolves domains sử dụng DNS_QUERY_NO_HOSTS_FILE flag trong DnsQuery, khi đó nó sẽ bypass your hosts file entries.

Một lựa chọn khác là bạn có thể tạo một DNS server cho chính mình và cấu hình nó để trả về IP của controller cho một vài hoặc tất cả hostnames mà target cố gắng để resolve. Sử dụng kĩ thuật này, bạn không phải edit thủ công hosts file, nhưng malware vẫn có thể bypass setup của bạn thông qua việc không thực hiện DNS lookups và contacting với một hệ thống bằng IP của nó. Malware có thể lờ đi DNS settings trên target machine của bạn và resolve hostnames sử dụng một public DNS server thay thế (cho ví dụ, Google's open DNS).

Redirecting IP with Routing

Nếu bạn thay đổi thiết lập mạng trên target của mình, trỏ gateway của nó vào controller của bạn, sau đó tất cả traffic sẽ hit controller của bạn mặc kệ malware contacts với một hệ thống bởi DNS name hoặc IP. Nếu bạn có một quyết định quan trọng cần phải quyết - Bạn có muốn log hay là forward packets đến real servers trên Internet hay là bạn muốn redirect packets đến một hệ thống giả hoặc các dịch vụ mô phỏng ?

Nếu bạn forward packets đến real servers, bạn có thể biết được chính xác hơn những cư sử của malware trong tự nhiên, nhưng có một mối lo ngại đó là bạn có thể làm lộ IP của bạn với bad guys. Nếu bạn sử dụng một bộ phần mềm mô phỏng, bạn có thể tạo hoàn toàn một sandnet chứa chính nó, nhưng bạn sẽ không thực sự quan sát được malware trong môi trường tự nhiên.

Để route tất cả target machine's traffic thông qua controller, làm theo các bước sau:

1. Trên controller chạy Linux, enable IP forwarding trong kernel bằng việc thực hiện command sau như root:

          $ sudo su

          # echo 1 > /proc/sys/net/ipv4/ip_forward

    2.    Trên controller, đảm bảo rằng iptables default firewall policy cho phép forwarding packets,           như sau

          $sudo iptables - P FORWARD ACCEPT

    3. Quay lại target, cấu hình mạng cho nó sao cho default gateway trỏ đến controller. Bạn có thể 

          thực hiện điều này thông qua 2 cách. Cách thứ nhất yêu cầu gõ command sau trong cmd.exe

          C:\> route change 0.0.0.0 mask 0.0.0.0 172.16.176.130

         Bạn cũng thể sử dụng GUI, như trong Figure 7-2. 

 Với thiết lập như trên, bạn có thể tự tin để capture, redirect, hoặc interact với bất cứ traffic được sinh bởi Windows target machine. Sở dĩ tôi nói từ "tự tin" một cách công bằng bởi vì mặc dù chúng ta không bao giờ có thể nhìn thấy nó trong tự nhiên, malware có thể reconfigure default gateway trên target machine và gửi traffic xung quan controller. Khả năng để làm điều đó phụ thuộc vào nơi đặt controller của bạn. Malware còn cần phải biết IP của next-hop router mà nhận hoặc và forwards traffic; tuy nhiên, có rất nhiều thứ bạn có thể học được từ một trace route đơn giản. 

Recipe 7-2: CAPTURING AND ANALYZING NETWORK TRAFFIC

Tất cả traffic gửi từ / đến targets của bạn đổ xuống controller, bạn đã có thể khởi động tiện ích capture trên controller và nhìn packets trong thời gian thực. 

NOTE: 

Bên cạnh phương thức capturing packets, bạn có thể sử dụng một vài kĩ thuật khác:

• Kết nối machines trên mạng của bạn đến một old hub nếu bạn có một cái, và sử dụng dụng một mode sniffer.
• Plug sniffer của bạn vào trong một switch hoặc router để cho phép port mirroring.
• Kết nối target machines đến controller của bạn thông qua crossover cable. 

Using WireShark's GUI 

WireShark là một công cụ phân tích giao thức mạng trên Windows, Linux, MAC OS X, trên các OS khác. Bên cạnh việc capturing packets, WireShark có thể thực hiện việc kiểm tra "sâu" hàng trăm giao thức, và xuất ra kết quả là pcap file, CSV, hoặc XML. Nó còn có khả năng filter mạnh mẽ. Nếu WireShark chưa được cài đặt trên controller của bạn, bạn có thể tải nó bằng cách running command sau:

  $ sudo apt-get install wireshark

Figure 7-3 shows WireShark's GUI. Bạn sẽ chú ý đến source address của DNS queries là 172.16.176.138 - target VM. DNS server hồi đáp lại queries là 172.16.176.2, trên mỗi cấu hình trong bước phía trước. Bạn có thể nhìn thấy được target resolved hostnames trong wikipedia.org và google.com domains để giao tiếp với những servers này thông qua HTTP.

Using tshark

Nếu bạn thích các công cụ sử dụng command-line hơn (được khuyến khích cho việc phân tích tự động), bạn có thể sử dụng tshark , là một non-GUI version của Wireshark. Bạn có thể cài đặt nó như sau:

 $ sudo apt-get install tshark

Command sau đây shows cách để capture packets trên eth0 interface, tự động thoát ra sau 60 giây, và lưu packets vào output.pcap

 $ sudo tshark -i eth0 -a duration:60 -w output.pcap

Để đọc packets sử dụng cùng cách thức phân tích như GUI version của Wireshark, bạn có thể làm như sau:

 $ tshark -r output.pcap -V

Using tcpdump

tcpdump không bao gồm các phân tích giao thức mở rộng như Wireshark và tshark, nhưng nó cung cấp khả năng capture đáng tin và mạnh mẽ và các khả năng đọc trở lại. Nếu bạn cần cài đặt nó, sử dụng command sau:

 $ sudo apt-get install tcpdump

Command sau shows cách để capture packets trên eth0 interface đã được đánh đánh địa chỉ đến hoặc từ 172.16.172.138, và lưu tất cả bytes trong packet (thông qua việc thiết lập snaplen đến 0) trong output.pcap:

 $ tcpdump -i eth0 -s 0 -w output.pcap host 172.16.172.138

Từ khóa host là một trong nhiều BPF-style filters mà giúp cho bạn điều khiển chính xác những packets nào được lưu trong file của mình. Để có nhiều thông tin về BPF-style filters, gõ man tcpdump

Nếu bạn pass -r flag đến tcpdump, nó sẽ phân tích file packet capture được lưu.

 $ tcpdump -r output.pcap

Chúng tôi khuyến cáo bạn có thể pass -n flag để ngăn cho tcpdump khỏi thực hiện DNS lookups, những gì có thể tốn thời gian. Dĩ nhiên, nếu bạn muốn nhìn thấy DNS names thay cho IP addresses, đừng sử dụng -n flag.

Using snort IDS

Bạn có thể cài đặt Snort IDS lên controller của mình để cảnh báo bất cứ traffic đáng nghi nào gửi đến hoặc là gửi từ target machines trong khi malware đang running. Snort sẽ cho bạn một gợi ý tốt về các kiểu cảnh báo bạn sẽ nhìn thấy nếu một malware hay malware tương tự tồn tại trên mạng công ty. Commands sau tạo một simple Snort setup với Emerging Threats signatures trên controller của bạn:

 $ sudo apt-get install snort
 $ sudo wget -P /etc/snort/rules http://www.emergingthreats.net/rules/emerging-all.rules
 $ sudo echo 'include $RULE_PATH/emerging-all.rules' >> /etc/snort/snort.conf
 $ sudo /etc/init.d/snort start

Nếu bạn muốn kiểm tra xem mọi thứ thực hiện có thành công không hoặc nhìn xem command-line parameters startup script gửi đến Snort, khi đó bạn có thể view nó như sau:

 $ cat /proc/'pidof snort'/cmdline
/usr/sbin/snort –m 027 –D –d –l /var/log/snort –u snort –g snort –c \
/etc/snort/snort.conf –S HOME_NET=[172.16.176.0/24] –i eth0

Data Encoding [1]

Khi phân tích malware, chúng ta thường gặp thuật ngữ data encoding, data encoding liên quan đến tất cả các hình thức thay đổi nội dung nhằm ẩn đi ý đồ ban đầu. Malware sử dụng các kĩ thuật encoding tạo ra một lớp mặt lạ cho các hành động nguy hiểm của nó, và chúng ta trong vai trò của malware analyst, chúng ta cần hiểu các kĩ thuật encoding này để hiểu hơn về malware.

Khi sử dụng data encoding, attackers sẽ chọn phương thức mà họ cảm thấy thích hợp với mục tiêu của họ nhất. Thình thoảng, họ chọn ciphers (thuật toán mã hóa) đơn giản mà dễ dàng để code và cung cấp đầu đủ tính bảo vệ ; những lúc khác, họ sử dụng ciphers phức tạp khiến cho việc nhận dạng và reverse-engineering trở nên khó khăn hơn.

Mục tiêu của việc phân tích Encoding Algorithms

Malware sử dụng encoding cho nhiều mục đích khác nhau. Ứng dụng phổ biến nhất dành cho việc mã hóa (encryption) các giao tiếp mạng. Malware còn sử dụng encoding để nguy trang cho việc hoạt động bên trong của nó. Ví dụ, một malware author có thể sử dụng encoding cho các mục đích sau:

• Để ẩn các thông tin về cấu hình (configuration information), ví dụ như command-and-control domain
• Để lưu thông tin đến một file tạm trước khi lấy cắp nó. 
• Để lưu strings được sử dụng bởi malware và decode chúng trước khi cần xài
• Để ngụy tạo malware như là một công cụ hợp lệ, ẩn đi strings được sử dụng bởi các hành động nguy hại. 

Mục đích của chúng ta khi phân tích encoding algorithms luôn luôn có hai thứ cần phải đạt được sau đây: Nhận dạng encoding functions và sau đó vận dụng kiến thức để decode nhưng bí mật của attacker.

Simple Ciphers

Các kĩ thuật encoding đơn giản đã tồn tại hàng nghìn năm. Trong khi bạn có thể cho rằng với khả năng tính toán tốc độ cao của các máy tính hiện đại đã khiến simple ciphers tuyệt chủng, nhưng không phải vậy. Các kĩ thuật encoding đơn giản thường được vận dụng để ngụy trang nội dung làm cho nó xuất hiện trước mắt người dùng dưới dạng không thể đọc được hay là chuyển dữ liệu vào trong một tập hợp kí tự khác. 

Simple ciphers thường bị xem thường vì tính không phức tạp của nó, dẫu vậy chúng mang lại nhiều lợi thế cho malware, bao gồm những điều sau:

• Chúng đủ nhỏ khi được sử dụng trong các môi trường hạn chế ví dụ như exploit shellcode. 
• Chúng kém rõ ràng hơn nhiều complex ciphers.
• Chúng có chi phí thấp và do đó ảnh hưởng rất ít đến performace. 

Malware authors sử dụng một simple cipher không mong đợi được cipher họ dùng miễn dịch được trước sự phát hiện ; họ chỉ đơn giản là đang tìm kiếm một cách dễ dàng để ngăn basic analysis nhận dạng các hành vi của mình. 

Caesar Cipher

Một trong ciphers đầu tiên được sủ dụng đó là Caesar cipher. Ceasar cipher đã được sử dụng liên tục khi Roman Empire ẩn messages được chuyển đi qua chiến trường bởi những người giao liên. Nó là một hình thức cipher đơn giản, dễ dàng thực hiện bằng cách dịch chuyển (shifting), trong đó mỗi ký tự trong văn bản bằng một ký tự cách nó một đoạn trong bảng chữ cái để tạo thành bảng mã. 

Chi tiết về cách mã hóa cũng như giải mã xem thêm tại: http://vi.wikipedia.org/wiki/M%E1%BA%ADt_m%C3%A3_Caesar

XOR

XOR cipher là một simple cipher tương tự như Ceasar cipher. XOR có nghĩa là exclusive OR và là một phép logic có thể được sủ dụng để modify bits. 

Một XOR cipher sử dụng một static byte value và modify mỗi byte của plaintext thông qua việc thực hiện phép tính logic XOR với giá trị đó. Cho ví dụ, Figure 14-1 shows cách message ATTACK AT NOON có thể được encoded sử dụng XOR với byte 0x3C. Mỗi kí tự được biểu diễn bởi một cell, với ASCII character (hay là control code), và hex value của kí tự nằm ở phía dưới cùng. 

Như bạn có thể thấy trong ví dụ này, XOR cipher thường trả kết quả theo bytes mà không bị giới hạn bởi các kí tự có thể in ra được (những ô được tô xậm trong hình vẽ). C trong ATTACK được chuyển sang dạng hex là 0x7F, mã hex này ám chỉ delete character. Cũng tương tự như vậy, space character được dịch thành 0x1C là mã cho file separator. 

XOR cipher dễ sử dụng bởi vì nó đơn giản - chỉ yêu cầu một lệnh máy và reversible.

Một reversible cipher sử dụng cùng một function để encode và decode. Để decode những thứ encoded với XOR cipher, bạn có thể lặp lại XOR function với key giống như trong quá trình encoding. 

Quá trình implementation XOR encoding như chúng ta đang thảo luận - nơi mà key là giống nhau trong mọi encoded byte - còn được gọi với cái tên single-byte XOR encoding.

Brute-Forcing XOR Encoding

Nào hãy tưởng tượng chúng ta đang điều tra một sự cố liên quan đến malware. Chúng ta biết được rằng vài giây trước khi malware starts, 2 files được tạo trong thư mục cache của browser. Một trong các file đó là SWF file, đó là file chúng ta nghi vấn nó được sử dụng exploit browser's Flash plug-in. Một file khác có tên là a.gif , nhưng nó không có GIF header, những gì bắt đầu với các kí tự GIF87a hoặc GIF89a. Thay vào đó, file a.gif bắt đầu với các bytes như trong Example 14-1

Ok. Chúng ta nghi ngờ file này là một XOR-encoded executable, nhưng làm thế nào chúng ta có thể tìm ra ? Một chiến lược khi làm việc với single-byte encoding đó là brute force. 

Bởi vì chỉ có 256 giá trị có thể cho mỗi kí tự trong file, thật dễ dàng và nhanh gọn để cho máy tính thử tất cả 255 single-byte keys có thể được XORED với file header, và so sanh output bạn mong đợi cho excutable file. XOR encoding sử dụng từng key trong 255 keys có thể được thực hiện bởi một script, và Table 14-1 shows output của những script như vậy 

Brute-Forcing Many Files

Brute-forcing có thể được sử dụng một cách chủ động. Ví dụ, nếu bạn muốn search nhiều files để kiểm tra cho XOR-encoded PE files, bạn có thể tạo 255 signatures cho tất cả các sự kết hợp XOR, tập trung vào các phần tử của file mà bạn nghĩ có thể biểu diễn được. 

Cho ví dụ, chúng ta muốn search cho single-byte XOR encodings của string This program. Nó là phổ biến đối với PE file header để chứa một string như là This program must be run under Win32, hay là This program cannot be run in DOS. Qua việc sinh ra tất cả các hoán vị của string ban đầu với mỗi giá trị XOR có thể, chúng ta có thể đưa ra một tập các signatures để search, như bạn có thể thấy trong Table 14-2

NULL-Preserving Single-Byte XOR Encoding

Nào hãy nhìn lại encoded file trong Example 14-1. Chú ý vào sự xuất hiện một cách "náo loạn" của XOR key 0x12, chỉ nhìn qua chúng ta cũng có thể nhận ra điều này. Hầu hết các bytes trong phần mở đầu của header là 0x12! Nó demo một điểm yếu của single-byte encoding: Nó thiếu đi một cách hiệu quả để ẩn đi khởi user nếu user thực hiện scanning thủ công encoded content với hex editor. Nếu encoded content có một số lượng lớn NULL bytes, single-byte "key" trở nên càng rõ ràng. 

Malware authors đã phát triển một cách thông minh hơn để giảm thiểu vấn đề này bằng việc sử dụng NULL-preserving single-byte XOR scheme. Không giống như XOR encoding scheme thông thường, NULL-preversing single-byte XOR scheme có 2 ngoại lệ:

• Nếu plaintext character là NULL hoặc là key chính nó, khi đó byte được bỏ qua.
• Nếu plaintext character không là NULL cũng chẳng phải key, khi đó nó được encoded qua XOR với key. 

Như Table 14-3, code cho modified XOR không phức tạp hơn là mấy so với XOR ban đầu 

Trong Table 14-3, C code dành cho XOR function ban đầu nằm phía bên trái, và NULL-preserving XOR function nằm phía bên tay phải. Vì vậy nếu key là 0x12, khi đó bất cứ 0x00 hoặc 0x12 sẽ không được chuyển đổi, nhưng bất cứ byte nào khác 2 byte này sẽ được chuyển đổi thông qua việc XOR với 0x12. Khi một PE file được encoded theo kiểu này, key với những gì nó encoded sẽ không dễ để ta thể có một cái nhìn trực quan về nó. 

Nào hãy cùng nhau so sánh Example 14-1 (với 0x12 key) với Example 14-3. Example 14-3 biểu diễn cùng encoded PE file,  cũng là encoded với 0x12, nhưng lúc này NULL-preversing encoding, việc làm này gây ra khó khăn trong việc nhận diện XOR encoding và không có bằng chứng nào về sự hiện diện của key ở đây cả. 

 

Kĩ thuật  NULL-preversing XOR còn đặc biệt phổ biến trong shellcode, nơi điều quan trọng là có thể thực hiện encoding với một lượng rất nhỏ code. 

Nhận dạng XOR Loops trong IDA Pro

Nào bây giờ hãy tưởng tượng bạn tìm thấy shellcode bên trong SWF file. Bạn đang disassembling shellcode trong IDA Pro, và bạn muốn tìm XOR loop mà nghi ngờ rằng nó tồn tại để decode file a.gif liên kết với nó. 

Trong disassembly, XOR loops có thể bị nhận dạng bởi một số lượng nhỏ loops với một lệnh XOR nằm giữa của một loop. Cách dễ dàng nhất để tìm ra một XOR loop trong IDA Pro là search tất cả instances của XOR instruction, làm như sau:

1. Đảm bảo rằng bạn đang nhìn vào code (window title nên chứa "IDA View").

2. Chọn Search -> Text

3. Trong Text Search dialog, enter xor, chọn Find all occurences checkbox, và sau đó click OK. Bạn nhìn thấy một cửa sổ giống như trong Figure 14-2

                                                Figure 14-2

Việc search một XOR instruction không có nghĩa là XOR instruction được sử dụng cho encoding. XOR instruction có thể được sử dụng với nhiều mục đích khác nhau. Một trong số đó là sử dụng XOR để clear các nội dung của một thanh ghi. XOR instructions có thể được tìm thấy dưới 3 hình thức :

• XOR một thanh ghi với chính thanh ghi đó.
• XOR của một thanh ghi (hoặc memory reference) với một constant
• XOR giữa một thanh ghi (hoặc memory reference) với một thanh ghi khác (hoặc memory reference)

Nó xuất hiện phổ biến trong dạng đầu tiên, bởi vì XOR của một thanh ghi với chính nó là một cách hiệu quả để làm cho giá trị thanh ghi trở về 0. May mắn thay, việc clearing một thanh ghi không có liên quan gì đến data encoding, vì vậy chúng ta có thể lờ nó đi. Như bạn có thể nhìn thấy trong Figure 14-2, hầu hết các instructions được liệt kê là lệnh XOR của một thanh ghi với chính nó (ví dụ như xor edx, edx).

Một XOR encoding loop có thể được sử dụng hoặc trong hai forms sau: một XOR của một thanh ghi  với một constant hoặc là một XOR của một thanh ghi với một thanh ghi khác. Nếu bạn gặp may, XOR sẽ xuất hiện cùng với một thanh ghi và một constant, bởi vì điều đó công nhận rằng bạn có thể đang chứng kiến encoding, và bạn sẽ biết được key. Lệnh xor edx, 12h trong Figure 14-2 là một ví dụ của dạng thứ hai của XOR. 

Một trong các dấu hiệu của encoding là một small loop chứa XOR function. Hãy nhìn vào lệnh chúng ta nhận diện được trong Figure 14-2. Như ta thấy trong IDA Pro flowchart trong Figure 14-3 chỉ ra, lện XOR với 0x12 xuất hiện như là một phần của một small loop. Bạn có thể nhìn thấy một block tại loc_4012F4 tăng một biến đếm, và block tại loc_401301 kiểm tra xem biến đếm này có vượt quá một độ dài cho trước không.