B A S I C  S T A T I C  T E C H N I Q U E S

- Antivirus Scanning: A Useful First Step

- Hashing: A Fingerprint for Malware    

C:\>md5deep c:\WINDOWS\system32\sol.exe

373e7a863a1a345c60edb9e20ec3231 c:\WINDOWS\system32\sol.exe

- Finding Strings

ASCII strings use 1 byte per character, and Unicode uses 2 bytes per character.

But those bytes may not actually represent that string; they could be a memory address, CPU instructions, or data used by the program

- Packed and Obfuscated Malware

If upon searching a program with Strings, you find that it has only a few strings, it is probably either obfuscated or packed, suggesting that it may be malicious

Packed and obfuscated code will often include at least the functions LoadLibrary and GetProcAddress, which are used to load and gain access to additional functions

- Portable Executable File Format

the format of a file can reveal a lot about the program’s functionality.

- Linked Libraries and Functions

Knowing how the library code is linked is critical to our understanding of malware because the information we can find in the PE file header depends on how the library code has been linked.

Static, Runtime, and Dynamic Linking

Exploring Dynamically Linked Functions with Dependency Walker

Imported Functions

Exported Functions

EXEs are not designed to provide functionality for other EXEs, and exported functions are rare. If you discover exports in an executable, they often will provide useful information.

- Static Analysis in Practice

- The PE File Headers and Sections

Executable Description

.text Contains the executable code

.rdata Holds read-only data that is globally accessible within the program

.data Stores global data accessed throughout the program

.idata Sometimes present and stores the import function information; if this section is

not present, the import function information is stored in the .rdata section

.edata Sometimes present and stores the export function information; if this section is not

present, the export function information is stored in the .rdata section

.pdata Present only in 64-bit executables and stores exception-handling information

.rsrc Stores resources needed by the executable

.reloc Contains information for relocation of library files

The section sizes can be useful in detecting packed executables. For example, if the Virtual Size is much larger than the Size of Raw Data, you know that the section takes up more space in memory than it does on disk. This is often indicative of packed code, particularly if the .text section is larger in memory than on disk. This tells us that a packer will unpack the executable code to the allocated .text section.

Lab01-1.exe

Lab 1-1

This lab uses the files Lab01-01.exe and Lab01-01.dll. Use the tools and techniques described in the chapter to gain information about the files and answer the questions below.

Questions

1. Upload the files to http://www.VirusTotal.com/ and view the reports. Does either file match any existing antivirus signatures?

2. When were these files compiled?

3. Are there any indications that either of these files is packed or obfuscated? If so, what are these indicators?

4. Do any imports hint at what this malware does? If so, which imports are they?

CreateProcess를 통하여 새로운 프로세스를 만드는 것을 확인 할 수가 있으며 WS2_32.dll은 Networking을 하기 위하여 필요한 dll로써 다른 곳과 연결을 할려는 것을 알 수가 있다.

문자열을 확인해보면 특정한 주소가 있는 것을 확인할 수가 있고, 이 주소와 네트워킹을 하려한다는 것을 알 수가 있다.

FindFirstFile과 FindNextFile을 통하여 특정한 이름의 파일을 찾는 과정과 CreateFile과 CopyFile을 통하여 특정한 파일에 어떠한 작업을 하는 것을 예상 할 수가 있다.

아래와 같이 C:\windows\system32\kernel132.dll과 작업을 할려는 것을 확인 할 수가 있고, 아래와 같이 Lab01-01.dll과도 직접적으로 관련이 있는 것을 확인 할 수가 있다.

5. Are there any other files or host-based indicators that you could look for on infected systems?

.EXE의 CreateFile, CopyFile, FindFirstFile, FindNextFile과 같은 함수를 통하여 확인을 할 수가 있다. C:\Windows\System32\kerne132.dll 과 직접적으로 관련이 있다는 것 또한 우리는 문자열을 통하여 알 수 있다.

6. What network-based indicators could be used to find this malware on infected machines?

.dll의 WS2_32.dll의 모든 내용이 Network와 관련이 되어 있기에 이를 통해서 알 수가 있다. 또한 문자열을 확인하였을때 IP주소가 존재하는 것까지 확인을 할 수 있다.

7. What would you guess is the purpose of these files?

The .dll file is probably a backdoor. The .exe file is used to install or runthe DLL.

Detailed Analysis

To answer the first question, we upload the file to VirusTotal.com, which performs

a scan against antivirus signatures.

Next, we open the files in PEview. For each file, we navigate to the

IMAGE_NT_HEADERSIMAGE_FILE_HEADERTime Date Stamp field,

which tells us the compile time. Both files were compiled on December 19,

2010, within 1 minute of each other. This confirms our suspicions that these

files are part of the same package. In fact, a compile time that close strongly

suggests that these files were created at the same time by the same author.

We know that the files are related because of the compile times and where

they were found. It’s likely that the .exe will use or install the .dll, because

DLLs cannot run on their own.

Then we check to see if either file is packed. Both files have small but

reasonable numbers of imports and well-formed sections with appropriate

sizes. PEiD labels this as unpacked code compiled with Microsoft Visual C++,

which tells us that these files are not packed. The fact that the files have

few imports tells us that they are likely small programs. Notice that the DLL

file has no exports, which is abnormal, but not indicative of the file being

packed. (You will learn more about this export section when we return to

these files in Lab 7-3.)

Next, we look at the files’ imports and strings beginning with the .exe. All

of the imports from msvcrt.dll are functions that are included in nearly every

executable as part of the wrapper code added by the compiler.

When we look at the imports from kernel32.dll, we see functions for

opening and manipulating files, as well as the functions FindFirstFile and

FindNextFile. These functions tell us that the malware searches through the

filesystem, and that it can open and modify files. We can’t be sure what the

program is searching for, but the .exe string suggests that it is searching for

executables on the victim’s system.

We also see the strings C:\Windows\System32\Kernel32.dll and C:\windows\

system32\kerne132.dll. (Notice the change from the letter l to the number 1

in kernel32.dll.) The file kerne132.dll is clearly meant to disguise itself as the

Windows kernel32.dll file. The file kerne132.dll can serve as a host-based indicator

to locate infections, and it is one that we should analyze for malicious code.

Next, we look at the imports and strings for Lab01-01.dll, which imports

functions from WS2_32.dll. Because these functions are imported by ordinal,

we don’t know which functions are being imported. We also see two interesting

functions imported from kernel32.dll: CreateProcess and Sleep, which are

commonly used as backdoors. These functions are particularly interesting to

us in combination with the strings exec and sleep. The exec string is probably

sent over the network to command the backdoor to run a program with

CreateProcess. The sleep string is probably used to command the backdoor

program to sleep. (This malware is complex. We’ll return to it in Lab 7-3,

once we have covered the skills to analyze it fully.)

Lab01-2.exe

Lab 1-2

Analyze the file Lab01-02.exe.

Questions

1. Upload the Lab01-02.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?

2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.

PEView로 확인을 했을때 UPX 섹션이 존재하기도하며 이에 더해 첫번째 UPX 섹션의 경우 SizeOfRawData가 0으로써 언패킹 과정 중에 그곳에 Instruction이 쓰이는 것으로 예상된다.

3. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?

우선 패킹이 되어있을때는 프로그램이 실행되면서 실행압축된 것을 해제 할때 LoadLibrary를 사용하므로 인하여 저곳에 존재하고 있는 것을 확인 할 수가 있다. 그리고 언패킹 후에는 ADVAPI32.dll에서 CreateServiceA라고 되어있는데, 이 dll은 주로 Registry나 서비스를 제어할때 쓰는 dll 이므로 CreateService는SCM에 새로운 서비스를 등록한다는 것으로 예상이 된다. 여기서 내 예상으로는 아마 자동실행에 등록을 하지 않을까 싶다.( 물론 아닐 확률도 높음 )

그리고 WININT.dll 보면 InternetOpen과 InternetOpenUrl을 볼수가 있는데, 이는 특정 사이트를 여는 것이다. 구체적인 사이트는 두번째 사진에서와 같이 www.malwareanalysis.com으로 연결이 될 것이라 예상할 수가 있다.

4. What host- or network-based indicators could be used to identify this malware on infected machines?

만약 레지스트리에 등록하는 것이 맞다면 host-based에도 포함이 되고 그렇지 않다면 Network-based에만 포함이 된다. 

Detailed Analysis

When analyzing Lab 1-2, we upload the file to VirusTotal.com and see that it

matches at least three virus signatures. One antivirus engine identifies it as a

malicious downloader that downloads additional malware; the other two identify

it as packed malware. This demonstrates the usefulness of VirusTotal.com.

Had we used only one antivirus program to scan this file, we would probably

not get any information.

Upon opening the file with PEview, several indicators tell us that this

file is packed. The most obvious indicators are sections named UPX0, UPX1,

and UPX2—section names for UPX-packed malware. We could use PEiD to

confirm the file’s packed nature, but it is not foolproof. Even if PEiD fails

to identify the file as UPX-packed, notice the relatively small number of

imports and that the first section, UPX0, has a virtual size of 0x4000 but a raw

data size of 0. UPX0 is the largest section, and it’s marked executable, so it’s

probably where the original unpacked code belongs.

 Having identified the program as packed, we can unpack it by downloading

UPX from http://upx.sourceforge.net/ and running the following command:

upx -o newFilename -d originalFilename

The -d option says decompress the file, and the -o option specifies the

output filename.

After unpacking, we look at the imports sections and the strings. The

imports from kernel32.dll and msvcrt.dll are imported by nearly every program,

so they tell us little about this specific program. The imports from wininet.dll

tell us that this code connects to the Internet (InternetOpen and InternetOpenURL),

and the import from advapi32.dll (CreateService) tell us that the code creates a

service. When we look at the strings, we see www.malwareanalysisbook.com, which

is probably the URL opened by InternetOpenURL as well as by Malservice, which

could be the name of the service that is created.

We can’t be sure what this program is doing, but we’ve found some indicators

to help search for this malware across a network.

Lab01-3.exe

Lab 1-3

Analyze the file Lab01-03.exe.

Questions

1. Upload the Lab01-03.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?

2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.

3. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?

패킹이 FSG 1.0으로 되어있기에 언패킹 툴을 구하지 못하였다. 따라서 Manual Unpack을 하였는데 언패킹 후에 아래와 같이 dll이 확인이 되는 것을 볼 수가 있다.

4. What host- or network-based indicators could be used to identify this malware on infected machines?

프로그램을 실행할 경우 아래와 같이 해당 사이트로 연결이 되는 것을 확인 할 수가 있다. 이는 네트워크에 기반했음을 알수가 있다.

Manual Unpack

Detailed Analysis

For the file Lab01-03.exe, VirusTotal.com reports a variety of different signatures

with vague-sounding names. The most common signature is that of a

file packed with the FSG packer.

When we open the file in PEview, we see several indications that the file

is packed. The first is that the file sections have no names. Next, we see that

the first section has a virtual size of 0x3000, but a raw data size of 0. We run

PEiD to confirm, and it identifies the packer as FSG 1.0 -> dulek/xt.

To confirm that the file is packed, we search for the imports, but there

doesn’t seem to be an import table. An executable file without an import

table is extremely rare, and its absence tells us that we should try another

tool, because PEview is having trouble processing this file.

We open the file with Dependency Walker, and see that it does have an

import table, but it imports only two functions: LoadLibrary and GetProcAddress.

Packed files often import only these two functions, which further indicate

that this file is packed. We can try to unpack the file using UPX, but we

know that the file is packed with FSG, rather than UPX. We’ll return to this

file in Chapter 18, once we have covered the skills to unpack it.

Lab01-4.exe

Lab 1-4

Analyze the file Lab01-04.exe.

Questions

1. Upload the Lab01-04.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?

2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.

3. When was this program compiled?

4. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?

아래에서와 같이 ADVAPI32.DLL을 통하여 권한에 대하여 어떠한 작업을 하려고 한다. 또한 CreateFile, WriteFile, 등을 통하여 특정 파일을 생성을 하고 WinExec 함수를 통하여 그 파일을 실행 시키려고 하는 것 같다.

이뿐만 아니라 Resource와 관련된 함수또한 존재하는데 이는 Resource 부분에서 무엇인가를 가져온다는 것이다. 

5. What host- or network-based indicators could be used to identify this malware on infected machines?

우선 권한을 변경한 뒤에 System32\wupdmgrd.exe라는 파일을 생성하거나 실행할 것이라 예상할 수가 있다. 이를 통해 우리는 호스트 기반이라는 것을 확인 할 수가 있었다. 하지만 문자열을 보면 도메인주소가 존재하는 것을 확인할 수가 있다. 하지만 위에서 봤듯이 네트워킹과 관련된 함수는 존재하지 않았다.

여기서 우리는 위에서 리소스를 다루는 함수가 있었다는 것을 상기해야한다. 즉 리소스 섹션에 무엇인가가 숨겨져 있을수도 있다는 것이다.

6. This file has one resource in the resource section. Use Resource Hacker to examine that resource, and then use it to extract the resource. What can you learn from the resource?

Resource Hacker를 통하여 해당 File을 열어보면 PE 구조의 첫 시작부분부터 존재하는 것을 확인 할 수가 있다. 이것이 처음에는 파일을 잘못 인식한줄 알았지만 알고보니 저 부분 자체가 하나의 다른 파일이였던 것이다. 아래의 사진과 같이 Action > Save resource를 통하여 저장을 해보자.

이렇게 나온 파일을 우리는 PEView를 통하여 열어보면 네트워킹을 하는 함수를 발견할 수가 있다. 이러한 방식은 실제 멀웨어에서 이용되는 방식이므로 잊지 말자.

Detailed Analysis

For the Lab01-04.exe file, the results from VirusTotal.com suggest a program

related to a downloader. PEview gives no indication that the file is packed

or obfuscated.

The imports from advapi32.dll tell us that program does something

with permissions, and we can assume that it tries to access protected files

using special permissions. The imports from kernel32.dll tell us that the program

loads data from the resource section (LoadResource, FindResource, and

SizeOfResource), writes a file to disk (CreateFile and WriteFile), and executes

a file on the disk (WinExec). We can also guess that the program writes files

to the system directory because of the calls to GetWindowsDirectory.

Examining the strings, we see www.malwareanalysisbok.com/updater.exe,

which is probably the location that holds the malicious code for download.

We also see the string \system32\wupdmgr.exe, which, in combination with

the call to GetWindowsDirectory, suggests that a file in C:\Windows\System32\

wupdmgr.exe is created or edited by this malware.

We now know with some confidence that this malicious file downloads

new malware. We know where it downloads the malware from, and we can

guess where it stores the downloaded malware. The only thing that’s odd is

that the program doesn’t appear to access any network functions.

  The most interesting part of this malware is the resource section. When

we open this malware in Resource Hacker, we see one resource. Resource

Hacker identifies the type of the resource as binary, meaning arbitrary binary

data, and when we look at the data, most of it is meaningless. But notice the

string !This program cannot be run in DOS mode. This string is the error message

included in the DOS header at the beginning of all PE files. We can therefore

conclude that this resource is an additional executable file stored in the

resource section of Lab01-04.exe. This is a fairly common technique used in

malware.

To continue analyzing this file with Resource Hacker, we click Action

Save resource as binary file. After saving the resource, we open the file in

PEview to analyze the file embedded within it. Looking at the imports, we see

that the embedded file is the one that accesses the network functions. It calls

URLDownloadToFile, a function commonly used by malicious downloaders. It

also calls WinExec, which probably executes the downloaded file.

x86 Instruction Set Reference

Derived from the September 2014 version of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, volumes 2A and 2B.

More info at zneak/x86doc

This reference is not perfect. It's been mechanically separated into distinct files by a dumb script. It may be enough to replace the official documentation on your weekend reverse engineering project, but in doubt, go get the official and freely available documentation.

x86.zip

PE파일이 메모리에 로딩되었을 떄 각 섹션에서 메모리의 주소와 파일 옵셋을 매핑하여보자.

위의 사진은 리버스코어 블로그에서 퍼온 것으로 메모리에서는 VA로 위치를 표한하며 파일에서는 Offset으로 위치를 표현하는데

그림과 같이 파일에서와 메모리에서의 위치가 차이가 나는 것을 확인할수가 있다. 그렇기에 메모리에서의 값을 확인한 후에 수정을 하고자 할때에는 직접 그 위치의 Offset 값을 구하여 찾아 가야한다. ( 물론 PEView 를 통해 편하게 할수도 있다.)

RAW = RVA - VirtualAddress + PointerToRawData

RAW = 파일에서의 주소

RVA = 메모리에서의 주소

VirtualAddress = 메모리에서의 섹션 시작 위치

PointerToRawData = 파일에서의 섹션 시작 위치

우선 RVA - VirtualAddress를 통하여 메모리에서의 해당 주소가 섹션 시작 위치로 부터 몇번쨰 순서에 있는지를 알기 위함이다. 이를 통하여 메모리에서의 몇번쨰 순서인지를 알게된후에 파일에서의 섹션 시작위치 값을 더해준다면 파일에서의 섹션시작위치 + 순서값 = 을 통하여 파일에서의 주소를  알수가 있다. 이를 통해 다른 블로그의 RVA to RAW를 본다면 훨씬 이해가 쉬울것이라 혼자 생각한다.

EAX : 산술 연산을 수행하기 위해 사용되거나 함수의 리턴 값을 전달하기 위해 사용된다.

EDX : 데이터 레지스터로 기본적으로 EAX 레지스터의 확장 개념으로 사용된다. 즉 곱하기나 나누기 같이 복잡한 연산을 위해 추가적으로 데이터를 저장할 때 사용된다. 또한 범용 목적의 저장소로도 사용이 된다.

ECX : 카운터 레지스터라 불리며, 반복적으로 수행되는 연산에 주로 사용된다. 반복 연산에서는 문자열을 저장하거나 카운트를 세는 작업이 수행 된다. 중요한점은 ECX는 값을 감소시키면서 카운트를 센다는 점이다.

           예: count = 0

           While count < 10:

           Print “Loop num : %d” % count

           Count+=1

에서 위 코드를 어셈으로 변환해보면 카운트 값을 나타내는 ECX의 값이 첫번째 반복 연산을 수수행할 때 10이고, 두번째에는 9로 감소한다는 것을 알수 있다.

ESI : EDI와 같이 데이터를 처리하는 반복문에서 효과적으로 데이터를 처리하기 위해 사용된다. ESI는 데이터 연산을 위한 Source Index를 나타내거나 입력 데이터 스트림의 위치를 나타낸다.

EDI : 데이터 연산의 Destination index(목적지)를 나타내거나 데이터 연산의 결과가 저장 되는 위치를 나타내는데 사용된다. ESI는 읽기위해 사용되고 EDI는 쓰기 위해 사용된다고 생각하면 된다.

ESP : Stack pointer로 EBP와 함께 함수 호출과 스택연산에 쓰인다. 힘수기 호출 될 때 먼저 함수에 전달되는 파라미터가 스택에 PUSH되고 그 다음에는 리턴 주소가 스택에 PUSH된다. ESP 레지스터는 스택의 가장 높은 주소를 가리킨다. 따라서 함수 호출시 ESP 레지스터는 리턴 주소를 가리킨다.

EBP : Base pointer, EBP 레지스터는 호출 스택의 가장 낮은 위치를 가리키는데 사용된다.

EBX : 특정한 목적이 없는 레지스터로 추가적인 저장소로 이 레지스터를 사용한다.

EIP : 현재 실행 중인 명령의 주소를 가리킨다. CPU가 바이너리 코드를 실행시킴에 따라 EIP 레지스터는 CPU가 현재 어느 코드를 실행중인지 나타내기 위해 계속적으로 코드의 주소를 갱신한다.

데이터 타입

BYTE : 8비트 부호 없는 정수

SBYTE : 8비트 부호 있는 정수

WORD : 16비트 부호 없는 정수

SWORD : 16비트 부호 있는 정수

DWORD : 32비트 부호 없는 정수

SDWORD : 32비트 부호 있는 정수

FWORD : 48비트 정수

QWORD : 64비트 정수

TBYTE : 80비트 정수

연산자(operand) 타입

r8 : 8비트 범용 레지스터

r16 : 16비트 범용 레지스터

r32 : 32비트 범용 레지스터

Reg : 임의의 범용 레지스터

Sreg : 16비트 세그먼트 레지스터

Imm : 8, 16, 32비트 상수

imm8 : 8비트 상수

imm16 : 16비트 상수

imm32 : 32비트 상수

r/m8 : 8비트 범용 레지스터 또는 8비트 메모리

r/m16 : 16비트 범용 레지스터 또는 16비트 메모리

r/m32 : 32비트 범용 레지스터 또는 32비트 메모리

mem : 8, 16, 32 비트 메모리

명령어 (Command Destination,Source ) 

- ADD(add) : destination과 source를 더해 destination에 저장한다.

- SUB(Subtract) : destination에서 source값을 뺀 뒤 destination에 저장한다.

- SBB(Subtract with Borrow) : 하위 자리의 수계산 중에 빌림수를 가져갔다면 그것을

                                           감안해 뺄셈을 한다.

dst = dst - src - CF 식으로 생각하면 된다.

- MUL(Unsigned Integer Multiply) : 부호 없는 al, ax, eax의 값을 피연산자와 곱한다.

피연산자가 8비트 이면 al과 곱해서 ax에 저장되고 16비트이면 ax와 곱해서 dx:ax에 저장된다.

피연산자가 32비트 이면 EAX와 곱해서 EDX:EAX에 저장된다.

- IMUL(Integer Multiplication) : 부호 있는 al, ax, eax의 값을 피연산자와 곱한다.

결과에 따라 CF, OF가 달라질 수 있다.

피연산자가 8비트 이면 al과 곱해서 ax에 저장되고 16비트이면 ax와 곱해서 dx:ax에 저장된다.

피연산자가 32비트 이면 EAX와 곱해서 EDX:EAX에 저장된다.

결과에서 사용되는 비트 이외에 남은 비트를 부호비트로 채운다.

- DIV(Unsigned Integer Divide) : 8, 16, 32비트 부호 없는 값의 나눗셈을 한다.

ax/8bit 값 -> al:ah (몫:나머지)

dx:ax/16bit 값 -> ax:dx

edx:eax/32bit 값 -> eax:edx

결과에 따라 CF, OF, ZF가 세트될 수 있다.

- IDIV(Integer Divide) : 8, 16, 32비트 부호 있는 값의 나눗셈을 한다.

ax/8bit 값 -> al:ah (몫:나머지)

dx:ax/16bit 값 -> ax:dx

edx:eax/32bit 값 -> eax:edx

나눌 대상은 나눌 값보다 커야 한다. 부호 없는 경우는 xor연산을 해 0으로 초기화시키면서

확장을 시키고 부호 있는 경우 movsx 동작을 하는 CBW, CWD, CDQ로 부호비트로 채우면서

초기화 시켜서 나눗셈 연산을 수행한다.

- INC(Increase) : 피 연산자에 1을 더한다.

연산 결과에 따라 ZF나 OF가 세트 될 수 있다.

- DEC(decrease) : 피 연산자에 1을 뺀다.

연산 결과에 따라 ZF나 OF가 세트 될 수 있다.

- LEA(Load Effective Address) : source 의 주소값을 destination에 복사한다.

다시말해 간단히 source 주소값을 알아내서 destination에 복사하는 명령어라고 보면된다.

- MOV(Move data) : source 데이터를 destination으로 복사한다.

- MOVS(Move String) : source에서 destination으로 복사한다.

                                 문자열을 다루기 때문에 ESI와 EDI를 다룬다.

                                 따라서 ESI 안의 주소가 가리키는 문자열을 EDI 안의 주소가

                                 가리키는 곳으로 복사한다.

MOVS destination, Source

(MOVSB, MOVSW, MOVSD, MOVSQ : BYTE, WORD, DWORD, QWORD)

복사하는 단위마다 명령어가 다르다.

MOVSQ : 64비트에서 사용 가능한 명령어.

- MOVZX(Move with zero-Extend) : BYTE나 WORD크기의 피 연산자를 WORD나 DWORD

                                                   크기로 확장하고 남은 비트는 0으로 채운다.

- MOVSX(Move with Sign eXtend) : BYTE나 WORD 크기의 피연산자를 WORD나 DWORD

                                                    크기로 확장하고 부호는 그대로 유지한다.

                                                    다시 말해 나머지 공간을 부호비트로 채운다.

* movzx와 movsx의 차이점은 확장시 부호비트에 따라 값이 달라지기 때문에

확장시 확장된 공간을 부호비트로 채우거나 0으로 채우기 위해 두가지로 나뉘어 진다.

movxz - unsign , movsz - sing

- rep(repeat string) : ECX가 0이 될 때 까지 문자열 관련 명령을 반복시킨다.

                             문자열 관련 명령어는 MOVS, SCAS, STOS 등이 있다.

- repne(repeat until Not Equal) : 보통 SCAS명령어와 함께 쓰인다.

지정된 데이터 타입별로 문자열을 구분하고 한번 구분할 때마다 ECX를 -1 시킨다.

ZF가 1이거나 ECX가 0이 되기 전까지 반복한다.

시작 하는 순간 ECX를 -1 하고 시작한다.

- SCAS(Scan String) : 보통 REPNE REPE와 같이 사용된다.

                               Register와 Memory의 데이터 비교한다.

AL 또는 AX, EAX와 ES:(E)DI가 지시한 메모리 내용 비교 후 같은 값이면 ZF가 1로 세트된다.

scasb, scasw, scasd로 사용 한다.

자동으로 DF에 따라 EDI값이 달라진다.

- STOS(Store String) : AL, AX, EAX 안의 값을 EDI가 가리키는 곳으로 문자열을 저장시킨다.

Stosb, stosw, stosd로 사용되며 rep명령어와 함께 사용될 수도 있다.

DF에 따라 EDI 값이 + 또는 - 된다.

- LOOP : ECX가 0이 될 때 까지 정해진 라벨로 goto 한다.

디스 어셈블리 되면 라벨은 주소가 된다. 다시말해 라벨은 주소다.

또 loop label 을 디스 어셈블리 하면 loopd short 주소 이런 형식으로 나오는데

Loop를 사용하면 CX를 사용한다는 이야기이고 loopd는 ECX값을 사용한다는 이야기이다.

Short은 가까운 라벨을 찾겠다는 의미인데 별 뜻은 없다라고 난 생각한다.

- AND : 논리연산자 중 하나로 마스크 비트를 씌우는 동작을 한다.

예를 들면 네트워크에서 서브넷 마스크를 설정하면 네트워크 이름이 나오게 되는게

하나의 예이다.

- SAR(Shift Arithmetic Right) : SHR 명령을 사용하면 부호 비트가 변화하기 때문에 값이

                                            일정하게 바뀌지 않는다.

이때 사용 하는 것이 SAR인데 SHR은 무조건 오른쪽으로 비트를 밀어버리는 반면에

SAR은 오른쪽으로 비트를 밀고 기존의 부호 비트를 다시 MSB에 적용시킨다.

예를 들어 10110110 (-74)라는 비트를 SHR하면 01011011(91)이 되는데

만약 SAR하면 11011011(-37)이 된다.

neg : 음수값을 양수로 양수값을 음수로 바꿀때 사용

- TEST : 두 오퍼랜드값을 AND연산을 수행한다.

하지만 결과는 저장하지 않고 플래그 레지스터에만 영향을 준다.

대체적으로 TEST 명령 후 jmp 구문이 온다.

TEST는 CMP와 비교할 수 있는데 둘 다 비교 후 결과는 저장하지 않고

플레그 레지스터만 바꾼다.

예를 들어 if문을 사용할 때 비교 대상이 있을경우(if(a<10) 와 비교 대상이 없을경우(if(a))

가 있는데 비교 대상이 있을 경우는 cmp를 쓰고 비교 대상이 없을 경우는

현재 상태를 모르기 때문에 값이 뭔지 알아내기 위해서 TEST 명령어를 이용해 AND연산을

이용해 자신이 어떤 값인지 알아낸다.

보통 참인지 거짓인지를 알아내기 위해 사용한다.

OF와 CF는 항상 0으로 세트되고 TEST 연산 결과값이 0이면 ZF가 1로 세트되고

아니면 0으로 해제된다.

- CALL : 함수 호출 시 사용된다.

Jmp와 같이 프로그램의 실행 흐름을 변경 시키지만 jmp명령어와 다른 점은

돌아올 리턴 어드레스를 스택에 저장한다는 것이다.

-CMP : 두 오퍼랜드를 비교한다.

Destination 에서 source 를 묵시적으로 값을 빼서 비교한다.

두 피연산자의 값이 같다면 결과는 0이 되고 ZF가 1로 세트된다.

- OFFSET : 세그먼트 시작부터 변수가 위치한 거리까지 상대적인 거리를 리턴한다.

예를 들어 lea edi, offset value 하면 세그먼트로부터 value의 위치를 edi에 저장한다.

- NOP(No Operation) : 아무일도 하지 않는다.

필요에 따라 유용하게 사용하는데 예를 들면 추가적인 코드를 삽입시키고자 할 때

중간에 바로 삽입이 안되기 때문에 공간을 만들어야 한다.

이럴 때 필요없는 코드를 nop하면 그만큼의 공간을 확보할 수 있다.

조건 점프 명령

 JMP는 플래그 래지스터 값들을 이용해 조건이 만족하면 점프를 수행하게 되는 명령어이다.

JA(Jump if (unsigned) above) : CF = 0 and ZF = 0

JAE(Jump if (unsigned) above or equal) : CF = 0

JB(Jump if (unsigned) below) : CF = 1

JBE(Jump if (unsigned) below or equal) : CF = 1 or ZF = 1

JC(Jump if carry flag set) : CF = 1

JCXZ(Jump if CX is 0) : CX = 0

JE(Jump if equal) : ZF = 1

JECXZ(Jump if ECX is 0) : ECX = 0

JG(Jump if (signed) greater) : ZF = 0 and SF = 0

JGE(Jump if (singed) greater of equal) : SF = OF

JL(Jump if (signed) less) : SF != OF

JLE(Jump if (signed) less or equal) : ZF = 1 and OF != OF

JNA(Jump if (unsigned) not above) : CF = 1 or ZF = 1

JNAE(Jump if (unsigned) not above or equal) : CF = 1

JNB(Jump if (unsigned) not below) : CF = 0

JNBE(Jump if (unsigned) not below or equal) : CF = 0 and ZF = 0

JNC(Jump if carry flag not set) : CF = 0

JNE(Jump if not equal) : ZF = 0

JNG(Jump if (signed) not greater : ZF = 1 or SF != OF

JNGE(Jump if (signed) not greater or equal) : SF != OF

JNL(Jump if (signed) not less) : SF = OF

JNLE(Jump if (signed) not less or equal) : ZF = 0 and SF = OF

JNO(Jump if overflow flag not set) : OF = 0

JNP(Jump if parity flag not set) : PF = 0

JNS(Jump if sign flag not set) : SF = 0

JNZ(Jump if not zero) : ZF = 0

JO(Jump if overflow flag set) : OF = 1

JP(Jump if parity flag set) : PF = 1

JPE(Jump if parity is equal) : PF = 1

JPO(Jump if parity is odd) : PF = 0

JS(Jump if sign flag is set) : SF = 1

JZ(Jump is zero) : ZF = 1

부호 확장 명령어

부호 있는 나눗셈 연산을 할 시 나눌 대상이 되는 값은 나눌 값보다 커야 하기 때문에 확장을

시켜줘야 하는데 부호 있는 확장을 할 시 사용하는 명령어가 부호 확장 명령어 이다.

- CBW(Convert Byte to Word) : byte크기를 word 크기로 확장시킴

- CWD(Convert Word to Dword) : word크기를 dword 크기로 확장시킴

- CDQ(Convert Dword to Qword) : dword 크기를 qword 크기로 확장시킴

*동작은 movsx와 같고 개념은 초기화 개념으로 본다.

IAT (Import Address Table)

IAT란 쉽게 말하여 프로그램이 어떤 라이브러리에서 어떤함수를 사용하고 있는지를 기술한 테이블입니다.

• DLL (Dynamic Linked Library)

동적 연결 라이브러리로 프로그램내에 라이브러리를 포함시키지 말고 별도의 파일(DLL)로 구성하여 필요할때마다 불러서 사용을 한다.

일단 한번 로딩된 DLL의 코드, 리소스는 Memory Mapping 기술로 여러 Process에서 공유를 한다.

라이브러리가 업데이트 되었을때 해당 DLL파일만 교체하면 되니 편리하다.

• DLL 로딩방식

프로그램내에서 사용되는 순간에 로딩하고 사용이 끝나면 메모리에서 해제시키는 방법(Explicit Linking)과 프로그램 시작할때 같이 로딩되어 프로그램 종료할때 메모리에서 해제되는 방법(Implicit Linking)이 있다.

//IAT는 바로 Implicit Linkiing에 대하 메커니즘을 제공하는 역할을 한다.

아래는 notepad.exe의 kernel32.dll 의 CreateFileW를 호출하는 코드이다.

CreateFileW 를 호출 할때 직접호출하지 않고 128A0E4 주소에 있는 값을 가져와서 호출 한다. 따라서 76F4732C를 값으로 가져오는 것이다.(모든 API 호출은 이런방식이다.) 즉 덤프에 kernel32.dll의 CreateFileW 함수의 주소값을 씌워 놓은 것이다.

76F4732C 주소가 바로 notepad.exe 프로세스 메모리에 로딩된 kernel32.dll의 CreateFileW 함수 주소이다.

모든 환경에서 CreateFileW 함수호출을 보장하기 위해서 컴파일러는128A0E4의 실제 주소(76F4732C)가 저장될 위치를 준비하고 CALL DWORD PTR DS:[128A0E4] 형식의 명령어를 적어두기만 하면 그 후 파일이 실행되는 순간 PE loader가 128A0E4의 위치에 CreateFileW의 주소를 입력해준다.

(DLL은 PE Header에 명시된 ImageBase에 로딩된디고 보장할수 없다. 반면에 process 생성 주체가 되는 EXE 파일은 자신의 ImageBase에 정확히 로딩이 된다.)

IMAGE_IMPORT_DESCRIPTOR                    //PE Body에 위치

PE파일은 자신이 어떤 라이브러리를 Import하고 있는지 IMAGE_IMPORT_DESCRIPTOR 구조체에 명시하고 있다.

• Import : library으로부터 서비스(함수)를 제공받는 일

• Export : library 입장에서 다른 PE 파일에게 서비스(함수)를 제공하는 일

일반적인 프로그램에서는 여러개의 Library를 Import하기 떄문에 Library의 수 많큼 위 구조체의 배열 형식으로 존재하게 되며, 구조체 배열의 마지막은 NULL 구조체로 끝난다.

• OriginalFirstThunk : INT (Import Name Table)의 주소 (RVA)                //여기서 Table은 배열을 의미한다.

• Name : Library 이름 문자열의 주소(RVA)

• FirstThunk : IAT(Import Address Table)의 주소(RVA)

//INT와 IAT는 long type(4Byte) 배열이며 NULL로 끝난다.

EAT (Export Address Table)

windows 운영체제에서 라이브러리란 다른 프로그램에서 불러 쓸수 있도록 관련 함수들을 모아놓은 파일(DLL/SYS) 입니다.

EAT는 라이브러리 파일에서 제공하는 함수를 다른 프로그램에서 가져다 사용할수 있도록 해주는 메커니즘이며 IAT와 마찬가지로 PE 파일내 특정 구조체(IMAGE_EXPORT_EIRECTORY)에 정보를 저장하고 있으며 이 구조체는 PE파일에 하나만 존재한다.

*참고로 IAT를 설명하는 IID구조체는 여러개의 멤버를 가진 배열형탤 존재한다. 왜냐하면 PE파일은 여러개의 라이브러리를 동시에 Import할수 있기때문이다.

kernel32.dll은 export하는 모든함수에 이름이 존재하며, AddressOfNameOrdinals 배열의 값이 index = ordinal 형태로 되었습니다

하지만 모든 DLL파일이 이와 같지는 않습니다.export하는 함수중에 이름이 존재하지 않을수도 있으며AddressOfNameOrdinals 배열의 값이 index != ordinal 인 경우도 있습니다.

따라사 위 순서를 따라야만 정확한 함수 주소를 얻을수 있습니다.

**본 게시물은 http://www.reversecore.com 을 참고하여 복습용으로 옮겨 적거나 한 것이지 결코 제 머리에서 나온게 아님을 알려드립니다.  자세한건 Reversecore로 가시는게 더 좋습니다.

IDA_Pro_Shortcuts.pdf

IDA PRO 단축키

​

Names ___________________________________ Shift+F4
Functions ________________________________ Shift+F3
Strings __________________________________ Shift+F12
Segments _________________________________ Shift+F7
Segment registers ___________________________ Shift+F8
Signatures ________________________________ Shift+F5
Type libraries _____________________________ Shift+F11
Structures _________________________________ Shift+F9
Enumerations ____________________________ Shift+F10

Data Format Options
ASCII strings style ____________________________ Alt+A
Setup data types ______________________________ Alt+D

File Operations
Parse C header file ___________________________ Ctrl+F9
Create ASM file ____________________________ Alt+F10
Save database _______________________________ Ctrl+W

Navigation
Jump to operand ______________________________ Enter
Jump in new window _______________________ Alt+Enter
Jump to previous position ________________________ Esc
Jump to next position ______________________ Ctrl+Enter
Jump to address _________________________________ G
Jump by name _______________________________ Ctrl+L
Jump to function _____________________________ Ctrl+P
Jump to segment _____________________________ Ctrl+S
Jump to segment register ______________________ Ctrl+G
Jump to problem ____________________________ Ctrl+Q
Jump to cross reference _______________________ Ctrl+X
Jump to xref to operand ___________________________ X
Jump to entry point __________________________ Ctrl+E
Mark Position _______________________________ Alt+M
Jump to marked position ______________________ Ctrl+M

Debugger
Star process ____________________________________ F9
Terminate process ___________________________ Ctrl+F2
Step into ______________________________________ F7
Step over ______________________________________ F8
Run until return _____________________________ Ctrl+F7
Run to cursor ___________________________________ F4

Breakpoints
Breakpoint list ___________________________ Ctrl+Alt+B

Watches
Delete watch __________________________________ Del

Tracing
Stack trace ______________________________ Ctrl+Alt+S

Search
Next code __________________________________ Alt+C
Next data __________________________________ Ctrl+D
Next explored _______________________________Ctrl+A
Next unexplored ____________________________ Ctrl+U
Immediate value ______________________________ Alt+I
Next immediate value _________________________ Ctrl+I
Text ______________________________________ Alt+T
Next text __________________________________ Ctrl+T
Sequence of bytes ____________________________ Alt+B
Next sequence of bytes _______________________ Ctrl+B
Not function ________________________________ Alt+U
Next void __________________________________ Ctrl+V
Error operand ______________________________ Ctrl+F

Graphing
Flow chart ____________________________________ F12
Function calls _____________________________ Ctrl+F12

Miscellaneous
Calculator _____________________________ Shift+/
Cycle through open views ________________ Ctrl+Tab
Select tab _________________________ Alt + [1…N]
Close current view ______________________ Ctrl+F4
Exit ___________________________________ Alt+X
IDC Command ________________________ Shift+F2

Edit (Data Types – etc)

Copy ____________________________________ Ctrl+Ins
Begin selection _______________________________ Alt+L
Manual instruction __________________________ Alt+F2
Code __________________________________________ C
Data __________________________________________ D
Struct variable _______________________________ Alt+Q
ASCII string ____________________________________ A
Array ______________________________________ Num *
Undefine ______________________________________ U
Rename _______________________________________ N

Operand Type
Offset (data segment) _____________________________ O
Offset (current segment) ______________________ Ctrl+O
Offset by (any segment) ________________________ Alt+R
Offset (user-defined) __________________________ Ctrl+R
Offset (struct) ___________________________________ T
Number (default) ____________________________ Shift+3
Hexadecimal ____________________________________ Q
Decimal _______________________________________ H
Binary _________________________________________ B
Character ______________________________________ R
Segment _______________________________________ S
Enum member __________________________________ M
Stack variable ___________________________________ K
Change sign ________________________________ Shift+-
Bitwise negate ______________________________ Shift+`
Manual ____________________________________ Alt+F1

Comments
Enter comment ______________________________ Shift+;
Enter repeatable comment __________________________ ;
Enter anterior lines ______________________________ Ins
Enter posterior lines ________________________ Shift+Ins
Insert predefined comment ___________________ Shift+F1

Segments
Edit segment ________________________________ Alt+S
Change segment register value __________________ Alt+G

Structs
Struct var __________________________________ Alt+Q
Force zero offset field ________________________ Ctrl+Z
Select union member __________________________ Alt+Y

Functions
Create function __________________________________ P
Edit function ________________________________ Alt+P
Set function end _________________________________ E
Stack variables ______________________________ Ctrl+K
Change stack pointer __________________________ Alt+K
Rename register _________________________________ V
Set function type _________________________________ Y​ 

Section Header                //각 Section의 속성을 정의한 것

앞에서 PE 파일은 code,data,resource 등이 각각의 section으로  저장이 된다했었습니다.

• code : 실행, 읽기 권한

• data : 비실행, 읽기, 쓰기

• resource : 비실행, 읽기

IMAGE_SECTION_HEADER

typedef struct _IMAGE_SECTION_HEADER {

...

UNION {

...

DWORD VirualSize;

}Misc;

DWORD VitualAddress;

DWORD SizeOfRawData;

DWORD PointerToRawData;

...

DWORD Characteristice;

} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;

• VirtualSize : 메모리에서 섹션이 차지하는 크기

• VirtualAddress : 메모리에서 섹션의 시작 주소 (RVA)

• SizeOfRawData : 파일에서 섹션이 차지하는 크기

• PointerToRawData: 파일에서 섹션의 시작위치

• Characteristices: 섹션의 특징( bit OR)

                                     //VirtualAddress & PointerToRawData  //IMAGE_OPTIONAL_HEADER32에 정의된                                             SectionAlignment & FileAlignment에 맞게 결정이 된다.

Notepad.exe 의  Section Header를 보면 3개의 Section이 존재하는 것을 확인 할 수가 있습니다.

RVA to RAW                              //  각 섹션에서 메모리의 주소(RVA), 파일 옵셋(RAW)

PE파일이 메모리에 로딩되었을떄 각 섹션에서 메모리의 주소(RVA)와 파일옵셋(RAW)을 잘 매핑 할수 있어야한다.

이러한 매핑을 일반적으로 "RVA ro RAW"라 합니다.

How to?

1)RVA가 속해 있는 Section 찾기

2)비례식을 사용해서 파일 옵셋(RAW)을 계산한다,

   비례식

RAW -PointerToRawData = RVA - VirtualAddress

>>    RAW= RVA - VirtualAddress + PointerToRawData

//RVA to Raw 는 PE header를 공부할때 가장 기본이 되는 개념이므로 잘숙지해야한다.

• RVA는 PE 파일이 메모리에 로딩되었을때의 메모리 주소를 의미하고, RAW는 PE 파일이 로딩되기 전의 File Offset을 의미

• 즉, RVA to RAW는 PE File의 각 Section이 Memory에 로딩되기 전의 File Offset과 메모리에 로딩된 후의 위치주소를 매칭하는 것이다.

**본 게시물은 http://www.reversecore.com 을 참고하여 복습용으로 옮겨 적거나 한 것이지 결코 제 머리에서 나온게 아님을 알려드립니다.  자세한건 Reversecore로 가시는게 더 좋습니다.