(혼자 공부하며 참고하기 위해 본문 내용을 그대로 가져왔습니다. 문제시 삭제 조치 하겠습니다.)



운영 체제는 프로그램을 실행할 때 프로세스 단위로 관리합니다. 동작 중인 프로그램이 하나의 프로세스가 되는 것입니다. 운영 체제에서는 프로세스를 사용하여 실행 중인 다양한 응용 프로그램을 구분하고 스레드는 운영 체제에서 프로세서 시간을 할당하는 기본 단위가 됩니다.



※ 프로세스 구성 요소(메모리 구조)

 - Data 영역: 전역변수나 static 변수의 할당을 위해 존재하는 영역입니다.

 - Stack 영역: 지역변수 할당과 함수 호출 시 전달되는 인자 값들의 저장을 위해 존재합니다.

 - Heap 영역: 동적할당(malloc, calloc 함수에 의한 할당)을 위해 존재합니다. (프로그래머가 할당.)

 - Code 영역: 실행파일을 구성하는 명령어들이 올라가는 메모리 영역입니다.




스레드는 프로세스 내에서 실행되는 흐름의 단위를 말합니다. 일반적으로 하나의 프로세스는 하나의 스레드를 가지고 있지만 프로그램 환경에 따라 둘 이상의 스레드를 동시에 실행할 수 있습니다. 이러한 실행 방식을 멀티 스레드라고 합니다. 스레드가 여러개 실행될 경우 스케줄러는 각 스레드에게 시간을 할당하여 실행함으로써 사용자가 보기에 여러 스레드가 동시에 실행되는 것 처럼 보이게 됩니다.



※ 스레드 특징

 - 각 스레드는 독립적인 스택 영역을 가집니다.

 - 코드 영역을 공유합니다.

 - 데이터 영역 및 힙 영역을 공유합니다.(전역변수와 동적 할당된 메모리 공간도 공유가 가능합니다.)

 - 프로세스 핸들 테이블을 공유합니다. 프로세스 핸들 테이블에 대한 핸들 정보는 프로세스 내의 스레드들에게  

   공유되어 각 스레드가 그 핸들에 대해 접근이 가능합니다.

 - 결국 같은 프로세스 내의 스레드들은 스택 이외의 모든 것을 공유하게 됩니다.




출처 : http://securityfactory.tistory.com/59

'Analysis > Theory' 카테고리의 다른 글

Ollydbg_Back To User Mode  (0) 2019.01.06
Themida 단순 Unpack  (0) 2019.01.06
악성코드 'PlugX Dropper'의 설치 방식  (0) 2019.01.06
중복 실행 방지 코드_CreateMutex( )  (0) 2019.01.06

1. Overview



1.1 Origin of name


VirusTotal Software Engineer인 Victor M. Alvarez의 트윗에 따르면 YARA의 Full name은 다음과 같다.


"YARA is an ancronym for:

YARA: Another Recursive Ancronym, or Yet Another Ridiculous Acronym. Pick your choice."


Yet Another Recursive Acronym 또는 Yet Another Ridiculous Acronym 이다[1][2].



2. About YARA



2.1 Features of yara


yara의 특징은 다음과 같다[3].


º 텍스트 기반 또는 바이너리 패턴을 기반으로 Malware 변종(malware families)에 대한 탐지를 제공

º 16진수 문자열, 텍스트 문자열, 정규 표현식 (Regular Expression) 을 지원

º PE, ELF 분석을 처리하는 모듈과 함께 오픈 소스 Cuckoo 샌드박스를 지원



Rules을 작성하는 기준에 대한 가이드는 다음과 같다[4].


º Rules에 Hit 되는 기준은 악성코드의 동작에 필요한 부분이여아 함

º 작성한 Rules는 기준 악성코드와 변종 악성코드 패밀리를 구별할 수 있을정도로 충분해야함

º 작성한 Rules는 다른 악성코드들 사이에서 일반적으로 통해야 한다(common across).




2.2 Get rules from external sources


YaraRules Github에서는 다양한 Rule set을 제공한다. rules는 Anti-Debug 및 Anti-Visualization techniques, 악성 문서, 패커 등을 탐지하기위한 규칙이 있다[5].

또한 VirusTotal, ThreatConnect 등과 같은 위협 정보 공유 플랫폼(Threat Intelligence sharing platforms)들이 YARA를 지원한다. 이를 통해 수집한 위협 정보를 기반으로 Rules를 작성할 수 있다[6][7].


VirusTotal의 경우 개인 API로 자신의 Rules를 입력하고 Hit 되는 샘플이 업로드 될 때 notice 해준다.

[그림 1]은 위협 정보 공유 플랫폼에서 지원하는 YARA 화면이다.


[그림 1] VirusTotal and ThreatConnect



2.3 Automatically generate rules

yara rules를 작성하는 일을 자동화 해주는 경우는 다음과 같다.


º Joe Sandbox[8]
- https://www.joesandbox.com/yaraspaged/
- Joe Sandbox에서는 동적 분석 결과를 바탕으로 Windows용 Signature를 제작할 수 있음
- 무료 온라인 샌드박스 (VirusTotal, Hybrid-Analysis, Malwr 등)과 호환

º Hyara[9]
- https://github.com/hy00un/Hyara
- 정적 분석 단계에서의 YARA 제작의 편의성을 극대화한 강력한 IDA Plug-in

(Hyara 관련 내용은 본 블로그의 Make yara rule with Hyara (IDA plug-in) 게시글 참고)






2.4 Make yara rules

자세한 문법은 YARA documentation 를 참조


2.4.1 Strings 문법

º wide : Unicode와 같은 2바이트 문자를 한 글자로 검색할 때 사용
º ascii : ascii 문자열 형식 검색 (wide와 함께 사용할 경우  순서 상관없음)
º nocase : 대/소문자 구분하지 않음
º fullword : 문자열을 하나의 문자열로 취급 (?)

<코드 분석 이후 yara 제작과 함께 상세한 내용 작성 예정>
<yara import 추가>
<yara 문법 추가>


N. Conclusions



암호화, 패킹, 다형성 등 우회가 비교적 쉬운 시그니처 기반 탐지에 대한 문제점들이 제시되고 있지만 여전히 YARA는 강력한 시그니처 기반 탐지 도구이다. 탐지 방안에 있어서 단독으로 사용하기는 무리가 있지만 다양한 탐지 도구들과 함께 병행하면 문제가 없다고 생각하며, 자동화 도구를 활용하여 높은 능률을 보장 받을 수 있다고 생각한다.

N. Related Reports



(1) https://github.com/VirusTotal/yara

(2) https://yara.readthedocs.io/en/v3.8.1/

(3) https://yararules.com/

(4) https://github.com/Yara-Rules/rules

(5) https://twitter.com/yararules



N. References



[1] https://twitter.com/plusvic/status/778983467627479040

[2] https://github.com/VirusTotal/yara/issues/58

[3] https://yara.readthedocs.io/en/v3.5.0/index.html

[4] https://securityintelligence.com/signature-based-detection-with-yara/

[5] https://github.com/Yara-Rules/rules

[6] https://www.virustotal.com/

[7] https://threatconnect.com/

[8] https://www.joesecurity.org/blog/8938263704094453988

[9] https://github.com/hy00un/Hyara

1. Overview



'''

박혜윤_이력서(181119)열심히하겠습니다.exe

이미지 무단사용관련 내용확인(박혜윤작가).exe

'''


파일명으로 유포된 GandCrab v5.0.4 랜섬웨어 악성코드이다.



2. File Info



SHA-256 : cf0ea1584d93d65c00012664eb39f2b003e41b60885759d6219b2d29a02ddcc3

<분석 완료 후 내용 추가 예정>


3. Detailed analysis


<분석 완료 후 내용 추가 예정>


N. Used Automated Malware Analysis Tools list



[1] VirusTotal, Available : https://www.virustotal.com/

[2] Hybrid-analysis, Available : https://www.hybrid-analysis.com/

[3] Intezer analyze, Available : https://analyze.intezer.com/


N. Related Report



[1] http://blog.alyac.co.kr/1989

[2] https://www.boannews.com/media/view.asp?idx=74745

'Analysis > Malware Analysis' 카테고리의 다른 글

[hwp] 한미우호협회 사칭 악성코드 분석  (0) 2020.12.20

블로그 이전으로 작성시간 변경됨 - 기존 [2019.01.03 00:47] 작성

1. Overview


Kaspersky lab의 GReAT 팀은 Rich Header 분석을 통해 공격 그룹을 밝혀낸 사례가 있다. 해당 내용을 담은 보고서가 공개되어 있으며 관련 내용의 일부를 해석한 내용은 다음과 같다[1].


'''2018 평창 올림픽 기간 동안 유포된 Olympic Destroyer에서는 Bluenoroff 패밀리의 파일과 동일한 Rich 헤더를 공유하였고 이는 동일한 환경을 사용하여 빌드되었다는 것을 뜻한다.'''


Rich Header는 변조가 쉽고 변조 유무에 대한 검증을 제공하지 않기 때문에 신뢰성이 높지 않지만 Attack Group간의 유사성을 표현하는데 간접 지표가 될 수 있다고 생각한다.


2. Background


Rich Header는 Visual Studio 6 (1998) 이후 MS Toolchain에 포함되며 훨씬 이전 버전에서 등장했을 수 있다. 2004년에 처음 논의되었고 2008년에 Daniel Pistelli에 의해 reverse engineered되었다[2]. Microsoft Toolchain을 반복할 때마다 리치 헤더가 생성되는 방식을 조정하고 제품 매핑 업데이트 하며 바이너리가 만들어진 정보를 포함한다.


PE 구조에서 DOS 헤더와 COFF 사이의 헤더에는 2가지 Stub가 존재한다[2].


1. DOS program

- "This program cannot be run in DOS mode" 를 출력

- Microsoft로부터 Documented 되었다.

- MSVC /SUB 컴파일러 플래그를 사용하는 모든 유효한 MS-DOS 응용 프로그램으로 릴리즈 가능


2. Rich Header

- 알 수 없는 바이트가 포함된 RICH 헤더로 문자열 "Rich"와 매직 넘버로 끝남

- Microsoft 공식 언급 없음

- 일관된 설명 없음


[그림 1] PE 파일 포맷 (일부)



3. Structure


3.1 PE Structure


PE 구조는 다음과 같다.


[그림 2] PE 구조


3.2 Rich Header Structure

Rich Header의 구조는 다음과 같다. Rich Header의 내용은 4바이트의 Checksum을 통해 XOR 연산 되어 있다. 이를 통해 XOR 이전의 값을 얻을 수 있다.


[그림 3] Rich Header 구조


Checksum 4바이트 값을 통한 XOR 연산을 진행한 결과는 [그림 4]와 같다. 이와 같이 헤더의 시그니처는 "DanS"라는 문자열로 이루어져 있다. 이를 통해 XOR 키를 얻는 방법 또한 존재한다[3].
[그림 4] XOR 연산이 완료된 Rich Header



각각의 값에 대한 자세한 설명은 [그림 5]와 같다.

Header (4 + 12 bytes)
- "Dans"
- Zero padding (or not)

@Comp.id Blocks (n x 8 bytes)
- n@Comp.id Block

Footer (8 + x bytes)
- "Rich" identifier
- Checksum
- Zeropadding (16 배수로 예상)
[그림 5] 헤더 구조

3.3 @Comp.id Structure

"@Comp.id" 는 "compiler build number" and "id" 의 줄임말이다[4].


ID 값은 각 목록 항목의 유형을 나타낸다. 예를 들어 특정 ID는 특정 버전의 C 컴파일러를 사용하여 생성된 OBJ 파일을 나타낸다. ID 값은 Visual Studio 릴리즈 간에 변경되는 값이다. 이러한 ID는 각 컴파일러 또는 어셈블러에서 생성되며 "@Comp.id" 심볼 형식으로 연결된 각 OBJ 파일 내에 저장된다.



● mCV
    - 결과물을 만들기 위한 컴파일러의 마이너 버전

● ProdID
    - 특정 식별 또는 객체 유형을 지정하는 고유 식별자

● Count
    - 특정 ProdID 및 mCV가 링커에서 사용된 빈도 지정



[그림 6] @Comp.id Structure

4. Conclusion



[그림 7]은 Rich Header가 존재하는 컴파일러와 존재하지 않는 컴파일러를 나눈 것이다[2].

[그림 7] Rich Header 생성 / 비생성 컴파일러



Microsoft에서 공식 문서로 제공하지 않고 비교적 생소한 내용이지만 실제 Threat intelligence에서 연관성을 표출한 사례가 있고 Attack Group를 추적하고 증명하는데 간접 지표로 충분히 활용 될 수 있을 것이라 생각한다.



5. References


[1] The devil’s in the Rich header, Kaspersky lab GReAT, 2018.03, Available: https://securelist.com/the-devils-in-the-rich-header/84348/

[2] RSA Conference 2017, AIR-T10, From Mole Hills to Mountains: Revealing Rich Header and Malware Triage, Available: https://published-prd.lanyonevents.com/published/rsaus17/sessionsFiles/5013/AIR-T10-From-Mole-Hills-To-Mountains-Revealing-Rich-Header-And-Malware-Triage.pdf

[3] http://dukup11ch1.tistory.com/46?category=780155

[4] https://bytepointer.com/articles/the_microsoft_rich_header.htm

[5] https://hy00un.github.io/2018/09/16/rich_header.html

[6] http://trendystephen.blogspot.com/2008/01/rich-header.html

[7] https://www.ntcore.com/files/richsign.htm

[8] https://bytepointer.com/articles/the_microsoft_rich_header.htm

'Reversing > Theory' 카테고리의 다른 글

Windows XP Folders and Locations & Windows 7 and Vista  (0) 2019.01.06
Process Hollowing  (0) 2019.01.06
Code Injection overview  (0) 2019.01.06
프로세스 핸들과 PID의 차이  (0) 2019.01.06
CreateFile의 CreateFileW CreateFileA 차이  (0) 2019.01.06

블로그 이전으로 작성시간 변경됨 - 기존 [2018.08.01 01:09] 작성


악성코드 분석에 있어서 코드인젝션 기법은 반드시 알고 있어야 하는 개념이다. 본 포스팅에서는 코드인젝션에 대한 개념을 정리한다.


1. 코드인젝션이란?


- 코드인젝션은 (정상적인) 프로세스에 악성코드를 주입하는 기술

- 악성코드가 별도의 프로세스를 생성하지 않고 (정상적인) 프로세스의 메모리 영역에 숨어서 동작

- 프로세스 목록만을 조사해서는 탐지할 수 없음

- 프로세스 이름을 기반으로 한 필터링(방화벽 등) 우회 가능

- 주입된 코드는 Target Process의 메모리 영역에 마음대로 접근할 수 있음




1.1 코드 인젝션의 종류


1. Remote Code Injection

2. Process Hollowing

3. Dll Injection

4. Reflective DLL Injection 등






2. Remote Code Injection



1) AdjustTokenPrivilege() -> SeDebugPrivilege 권한 획득
2) Process walking : Target Process(Host Process) 탐색
3) Target Process의 핸들 획득
4) VirtualAllocEx() -> Target Process의 가상 주소 공간에 새로운 메모리 영역 할당
5) VirtualProtectEx() -> Target Process 내에 새롭게 할당받은 메모리 프로텍트 속성에 read/write/execute 권한 추가
6) 주입할 코드 로드 : 주입 경로(네트워크(Memory only malware), 파일, 레지스트리 등)
7) WriteProcessMemory() -> 읽어들인 코드를 Target Process 내에 새롭게 할당받은 메모리 영역에 주입
8) CreateRemoteThread() -> 쓰레드 생성 후 EPROCESS 구조체에 있는 쓰레드리스트에 새로운 쓰레드를 등록하여 주입된 코드를 실행하도록 함






2.1 Remote Code Injection에 쓰이는 주요 API


1) AdjustTokenPrivilege()
    타겟 프로세스의 메모리에 코드를 주입하기 위해 SeDebugPrivilege 권한 활성화
2) OpenProcess()
    타겟 프로세스의 핸들 획득
3) VirtualAllocEx()
    SeDebugPrivilege 권한이 있으면 다른 프로세스의 빈 영역에 코드 주입 가능
    타겟 프로세스의 가상 주소 공간에 새로운 메모리 영역 할당
4) VirtualProtectEx()
    타겟 프로세스 내에 새롭게 할당받은 메모리의 프로텍트 속성에 read/write/execute 추가
    메모리 프로텍트 속성은 VAD 영역에 저장됨






3. Process Hollowing



1) AdjustTokenPrivilege() -> Target Process에 메모리를 주입하기 위해 SeDebugPrivilege 권한 활성화
2) CreateProcess(..CREATE_SUSPENDED..) -> Target Process를 suspended 모드로 만듬
    cf) suspended 모드 : EPROCESS 구조체 등 정상 생성되나 동작은 하지 않음
3) ZwUnmapViewOfSection() or NtUnmapViewOfSection() -> Target Process의 메모리 영역을 비움(Hollowing out)
4) VirtualAllocEx() -> Target Process의 가상 주소에 새로운 메모리 영역 할당

5) 주입할 코드 로드 : 네트워크, 파일, 레지스트리 등
6) WriteProcessMemory() -> 읽어들인 코드를 Target Process 내에 새롭게 할당받은 메모리 영역에 주입
7) GetThreadContext() && SetThreadContext() -> 다음에 실행할 명령어의 주소가 주입한 코드의 시작점이 되도록 Thread context 변경
8) ResumeThread() -> suspended 상태의 Target Thread 실행





4. Dll Injection



- Target Process에 악성 DLL을 강제로 삽입하는 기법
- 로딩된 DLL 파일은 Target Process의 메모리 공간에 접근할 수 있음
- 프로그램 기능개선, 버그 패치, 악성 목적 으로 이용 가능
- 종류 : 레지스트리 조작, SetWindowsHookEx() 이용, CreateRemoteThread() 이용 등


- 키로거 제작에 많이 이용되는API(SetWindowsHookEx())를 이용
- 이벤트(키보드 입력) 발생 시 OS와 어플리케이션이 주고받는 함수인 SetWindowsHookEx()를 이용하는 경우도 있음




5. Remote Dll Injection



1) AdjustTokenPrivilege() -> Target Process의 메모리를 할당하고 데이터를 쓰기 위해 SeDebugPrivilege 권한 활성화
2) Process walking (타겟 프로세스를 찾는 과정)
3) OpenProcess() -> Target Process의 핸들 획득
4) VirtualAllocEx() -> Target Process의 가상 주소 공간에 새로운 메모리 영역 할당
5) WriteProcessMemory() -> Target Process의 새롭게 생성된 가상 주소 공간에 로딩할 DLL 파일의 경로 기록
6) CreateRemoteThread() -> Target Process에 쓰레드 생성 쓰레드가 실행할 코드의 주소는 LoadLibrary()의 주소, LoadLibrary()에 전달할 파라미터는 VirtualAllocEx()로 할당한 주소값으로 설정

(LoadLibrary 주소는 GetModuleHandle의 인자로 "Kernel32.dll"를 주어 핸들을 구하고 GetProcAddress의 인자로 "LoadLibrary"를 줘서 주소를 구할 수 있다.

hMod = GetModuleHandle("kernel32.dll");
pThreadProc = (LPTHREAD_START_ROUTINE)GetProcAddress(hMod, "LoadLibraryA"); 


Remote Dll Injection은 VAD 영역을 조사한다고 해서 탐지할 수 없다. 정상적으로 LoadLibrary() API를 이용하기 때문에 정상적으로 파일이 매핑되어 있어서 VAD 영역에서 탐지해낼 수 없다.




6. Reflective DLL Injection



- Remote DLL Injection이 로드할 dll 파일 이름을 기재하고 LoadLibrary()을 호출하여 이루어지는 데 반하여
- Reflective Dll Injection은 WriteProcessMemory()을 이용하여 DLL 파일 자체를 주입함

- VAD 영역에서 프로텍트 속성이 READEXECUTE 권한이 있고 매핑된 파일이 없는 경우 인젝션(Remote Code 인젝션, Process Hollowing, Reflective DLL 인젝션)을 의심해야함





7. References


1. LoadLibrary() 주소 구하는 방법 - http://reversecore.com/40

2. GetModuleHandle과 LoadLibrary - http://egloos.zum.com/itbaby/v/4659384




'Reversing > Theory' 카테고리의 다른 글

Windows XP Folders and Locations & Windows 7 and Vista  (0) 2019.01.06
Process Hollowing  (0) 2019.01.06
About Rich Header  (0) 2019.01.06
프로세스 핸들과 PID의 차이  (0) 2019.01.06
CreateFile의 CreateFileW CreateFileA 차이  (0) 2019.01.06

1. Overview


블로그 이전으로 작성시간 변경됨 - 기존 [2016.09.18 19:08] 작성

(혼자 공부하며 참고하기 위해 본문 내용을 그대로 가져왔습니다. 문제시 삭제 조치 하겠습니다.)



핸들(Handle)은 프로세스 정보 중 하나로 커널이 관리하는 오브젝트들에 할당되는 유일한 '값'

프로세스 생성시 필요한 자원에 대한 사용 요청을 할 때 사용 하는 값. 파일, 디렉터리, 포트, 스레드, 세마포어 등이 포함

하나의 프로세스에 여러 개의 핸들을 가지고 있는 것이 일반적


PID(Process ID)는 프로세스를 구분하기 위해 커널에서 제공하는 유니크한 ID


커널 객체는 핸들보다 유니크하게 구분하는 ID가 더 중요

다른 객체들은 ID가 없고, 유저 객체를 컨트롤 하기 위해서는 핸들이 있어야 함


윈도우 핸들은 다른 프로세스로 넘길 수 있음, 핸들을 사용한다는 것은 전역적이라는 것

예를 들어 A,B 프로세스가 있고, A프로세스의 커널객체의 핸들값이 200일 때 ID를 B에게 알려주면 언제든 핸들을 찾을 수 있음

(B프로세스가 사용할 핸들을 만들어 줌, A,B프로세스가 핸들 값이 각각 달리 할당되지만, ID는 같아서 사용 가능)



핸들 - 프로세스 내에서 해당 객체를 액세스할 때 사용하는 한정적인 값이며 이 핸들을 사용하여 객체를 마음대로 조작할 수 있다. (C++의 지역변수)
ID -  시스템 전역적인 값이며 다른 프로세스 ID와 절대 중복되지 않는다. 그래서 프로세스끼리 ID를 전달함으로써 목적이 되는 프로세스 핸들을 다시 오픈할 수 있다. 실행 중인 프로세스의 ID는 작업 관리자에서 쉽게 확인할 수 있다.
(C++에서 Get 함수)

정리 - 프로세스 ID는 프로세스간의 구분을 위한 중복되지 않는 식별값일 뿐이며 ID로부터 직접 프로세스를 제어할 수는 없다. ID로부터 핸들을 발급받아야만 비로소 이 객체를 제어할 수 있다.


hInstance : 프로그램의 인스턴스 핸들


2. Reference


[1] http://sapzapee.tistory.com/469
[2] http://yonghello.tistory.com/entry/%EC%8A%A4%EB%A0%88%EB%93%9C

'Reversing > Theory' 카테고리의 다른 글

Windows XP Folders and Locations & Windows 7 and Vista  (0) 2019.01.06
Process Hollowing  (0) 2019.01.06
About Rich Header  (0) 2019.01.06
Code Injection overview  (0) 2019.01.06
CreateFile의 CreateFileW CreateFileA 차이  (0) 2019.01.06

1. Overview


블로그 이전으로 작성시간 변경됨 - 기존 [2015.07.10 11:38] 작성

(혼자 공부하며 참고하기 위해 본문 내용을 그대로 가져왔습니다. 문제시 삭제 조치 하겠습니다.)

A 버전과 W 버전의 내부적 차이는, 인자가 Unicode 인지 아닌지가 대부분입니다.

 

실제로 코드를 보시면 A 에서는 Unicode 로 변환한 후 W 함수를 호출하는 경우가 많습니다.

 

이는 NT 계열은 내부적으로 Unicode 를 사용하도록 되어 있기 때문입니다. (ntdll.dll 의함수들 및 커널 함수들이...)

 

그러므로, 유니코드로 파일을 쓰시는 것은 Buffer 의 데이터에 대한 내용이지, A 함수를 사용하느냐의 차이가 아닙니다.

 

그리고 A, W 는 Macro 로 설정된 것으로, 현재 프로젝트의 설정이 어떻게 되어있느냐에 따라서결정됩니다.

 

물론 A 를 호출하셔도 내부적으로 W 를 호출하는 경우도 많이 있습니다.





2. Reference


[1] http://www.devpia.com/MAEUL/Contents/Detail.aspxBoardID=50&MAEULNo=20&no=654769&ref=654769


'Reversing > Theory' 카테고리의 다른 글

Windows XP Folders and Locations & Windows 7 and Vista  (0) 2019.01.06
Process Hollowing  (0) 2019.01.06
About Rich Header  (0) 2019.01.06
Code Injection overview  (0) 2019.01.06
프로세스 핸들과 PID의 차이  (0) 2019.01.06

+ Recent posts