Practical Malware Analysis Lab 1-2

Lab 1-2

  Analyze the file Lab01-02.exe

Q1. Upload the Lab01-02.exe file to http://www.VirusTotal.com/. Does it match

      any existing antifirus definitions?

    A: Trojan 이라고 나오네...

Q2. 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.
 
    A: UPX v3.0 Packing 되어 있다.

 

   upx.exe로 잘~ 풀린다.

    > upx.exe -d Lab01-01.exe

Q3. Do any imports hint at this program's functionality?

      If so, which imports are they and what do they tell you?

  

      A: WinINet.dll의 InternetOpen / Url로 웹페이지에 접속한다.

         ADVAPI32.dll의 CreateServiceA로 서비스로 실행된다.

         SystemTimeToFileTime으로 파일 시간을 위장? 할 수 있고,

         CreateMutex/OpenMutex와 WaitForSingleObject로 내가 실행 중인지 알거나,

         무엇을 위해 대기 할 수 있다.

Q4. What host- or network-based indicators could be used to identify this malware

     on infected machines?

     A: 시스템에 멀웨어가 생성한 뮤텍스가 존재하는가?

        혹은 "MalServices" 서비스가 실행/존재 하는가?

        

      

Practical malware analysis LAB 1-1

지나가다 알게 된 너무나 설명이 좋은 책.

난이도는 초급 ~ 중급 사이라고 할 수 있는데,

어려운 주제도 쉽게 설명하는 저자가 이 시대에 필요한 사람!

각설하고, 총  22챕터, 800페이지로 구성되어 있으며

각 챕터마다 LAB으로 문제를 풀어야만 다음 장으로 넘어갈 수 있다. (나는..)

실습해 볼 수 있는 악성 모듈들을 저자 블로그에 가면 다운로드 할 수 있으니 얼마나 감사한 일인가. 

다운로드에 주의하길 바라며, 이제 LAB 1을 풀어본다.

LAB 1-1

Analyze the file Lab01-01.exe / dll

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

    A:




이 사이트에 Lab01-01.dll / Lab01-01.exe 파일을 업로드 하고 검사를 하면, 30여가지 이상의 안티 바이러스 제품이 결과를 알려주는데, 재미있는 것은 트로이 목마류의 악성코드라고 하지만, 사용자 리뷰 쪽에는 Practical Malware Analysis LAB 1이라고 코멘트가 남겨져 있다. 

Q2. When were these files complied?

   A:  2010년 12월 19일 16:16:38 UTC
       dll과 exe는 1분 차이로 컴파일 되었다.

 PEview로 Lab-01-01.dll 모듈을 보면 NT_HEADER -> FILE_HEADER에 TimeDateStamp 값을 UTC 시간으로 보여주고 있다.
 

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

     A: Packing이나 obfuscating 되지 않았다.

  

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

    A: Lab01-01.dll은 WS2_32.dll을 임포트 하며, Hint가 N/A인 걸로 봐서 Ordinal로 GetProcAddress를 하고 있다. Socket관련 함수를 사용한다는 점이 키 포인트임.

   Lab01-01.exe는 CreateFileA과 FileFirstFileA등을 사용하므로 파일을 찾는 것으로 보인다.
   CopyFileA도 사용하는 것 뭘까..

Q5. Are there any other files or host-based indicators that you could look for

     on infected systems?

   

   A: Kernel32.dll을 Kerne132.dll로 위장하고 있다!! (이 부분은 해답을 보고 알았다.. 보고도       노쳐 버렸네..)

 

 Q6. What network-based indicators could be used to find this malware

      on infected machines?

      A: Strings.exe Lab01-01.dll 치면 IP 주소를 볼 수 있다. 이 IP 서버와 통신할 것으로

         보인다... 127.26.152.13 은 Local 네트워크 주소이므로 악성 로직은 아닌 것으로..

      

      

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

    

    A:  음.. 이 파일의 목적은 아마도... 어떤 파일을 생성하거나 찾아서,

        127.26.152.13 서버로 전송하지 않을까..

[Windows Internals] Chapter 14 - Crash Dump Analysis

예전 Windows XP 때 까지만 해도, 블루 스크린이 발생하는 경우가 종종 있었다.
원인도 모르고, 해결 방법도 몰랐기에 포맷 후 OS를 다시 설치하는 일을 반복했던
기억이 있다. 이번 장에서는 Crash에 대해 알아보자.

Why Does Windows Crash?

Crash되는 이유는 다양한데, 일반적으로 아래 몇 가지가 되겠다.

 - 메모리에 접근시 ACCESS VIOLATION

 - Read only 메모리에 Write 하거나 매핑되지 않은 주소를 Read하는 행위

 - 핸들링 되지 않은 Exception과 trap

 - 또한 커널과 드라이버에서 예상치 못한 동작으로 인해 발생.

The Blue Screen

직접적으로 블루 스크린을 발생하는 것은 KeBugCheckEx API이다. 

KeBugCheckEx가 화면을 파랑색으로 칠하고, 안내 메시지를 뿌린다.

WDK에 문서화되어 있으므로 자세한건 참고하기 바란다.

최종적으로, KeBugCheckEx는 KeRegisterBugCheckCallack으로 사전 등록된 함수를 호출한다. 이 함수 안에서는 드라이버가 crash dump에 data를 추가하여 기록하는 등의 작업을 할 수 있도록 해준다.

300 개 이상의 BugCheckCode가 존재하며, 이 값이 코드를 Stop 시킨 원인이라 할 수 있다.
나머지 4개의 인자는 BugCheckCode 값에 따라 다른 값이 들어간다. crash난 주소나 data 주소가 들어갈 수 있다.

VOID  KeBugCheckEx(
  _In_ ULONG     BugCheckCode,
  _In_ ULONG_PTR BugCheckParameter1,
  _In_ ULONG_PTR BugCheckParameter2,
  _In_ ULONG_PTR BugCheckParameter3,
  _In_ ULONG_PTR BugCheckParameter4
);

Windows Vista SP1을 기반으로 수집된 통계를 보면, 30개의 Stop code가 96%의 crash를 발생시켰고, 몇 가지로 그룹화 할 수 있다.

• Page fault  

[Windbg] e 명령어 활용

오늘은 e 명령어에 대해 알아보자.
e 명령은 메모리에 들어있는 값을 바꾸는 enter 명령어다.
프로세스가 실행 중인 레지스터 값도 바꿀 수 있고, 메모리 변수 값도 바꿀 수 있다.

그럼 바로 실습 들어가시겠다.
 (1) Windbg를 실행한다.
 (2) Ctrl+E 누르고 C:/windows/system32/notepad.exe를 실행

자 여기까지 했으면 메모장이 실행됨과 동시에 Windbg가 제어권을 가지고 있을 것이다.
이제 메모장이 출력하는 MessageBoxW의 title 스트링을 바꿔보자.
아래 메시지 박스의 타이틀을 "메모장"에서 "사람인"으로 바꿀 것이다.

우선 메모장이 MessageBoxW를 호출할 때 break point가 잡혀야 하므로,
windbg에서 bp user32!MessageBoxW 한다.

         bp user32!MessageBoxW

이제 메시지 박스가 호출되도록, 메모장 - 편집 - 바꾸기를 클릭하고,
찾을 내용에 "fewf" 아무거나 입력한 후 [다음 찾기]를 클릭하면
MessageBoxW가 호출 되기 직전에 windbg로 제어권이 넘어갈 것이다.

자 이제 "메모장" 이란 타이틀은 MessageBoxW(hwnd, pwcsTitle, pwcsMsg, ..)
2번째 인자로 넘어간 다는 것을 알 수 있다.

그럼 확인해 보자.

0:000> ddu ebp+0n8
0009f360  002b09ea "ﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮ"
0009f364  03de6dd8 ""ff"을(를) 찾을 수 없습니다."
0009f368  0031f218 "메모장"
0009f36c  00000040

ebp+8이   첫번째 인자 : hwnd 이고,

ebp+12가 두번째 인자 : pwcsTitle

ebp+16이 세번째 인자 : pwcsMsg 이다.

그럼 ebp+12가 가리키고 있는 값을 바꾸면 되겠다.

ebp+12의 값은 0031f218 이다!

0:001> dd ebp+0n12
041dfe94  0031f218 77b99f72 00000000 73731998
041dfea4  00000000 00000000 00000000 00000000

0031f218가 "메모장" 문자열의 [0] 번째 주소다.

0:000> du 0031f218 
0031f218  "메모장"

자 이제 0031f218 주소에 들어있는 값을 바꾸면 되겠다.

ezu : e 변수 값 변경 / zu 유니코드 널 스트링으로!
0:000> ezu 0031f218 "사람인"

du : 유니코드 스트링으로 보여줘
0:000> du 0031f218 
0031f218  "사람인"

자 이제 MessageBoxW로 들어온 값을 아래와 같이 바꿨으니 g 실행하면!!
메시지박스가 출력되면서  MessageBoxW(hwnd, "사람인", ..., ...) 으로 출력된다!

메모리가 변경됐으니, 다시 MessageBoxW가 호출되도 "메모장" 대신 "사람인"으로 

출력되겠다. 이상!

Advanced Windows Debugging [1] - 디버깅 툴 소개

팀에서 막내와 함께 윈도우 디버깅 스터디를 해보자고 시작한 책이 바로 이 책이다.

"모르는 것은 죄가 아니다 하지만 알려고 하지 않는 것은 대죄다."

 

1. 각종 디버깅 툴 소개
이 장에서는 이 책에서 사용하는 디버깅 툴 뿐만 아니라, 유용한 디버깅 관련 툴을 간단히 소개하고 넘어간다. 그 내용을 정리하면, 크게 세가지로 분류할 수 있다.

• 메모리 누수 관련 툴
• Leak Diagnosis Tool : LD Graph와 함께 사용한다.
  
• 디버깅 툴
• Windbg : GUI 기반 유저/커널모드 디버깅 툴.
               x64버전 Windbg는 x86 프로세스도 디버깅 된다.
• CDB      : Console 기반 유저모드 디버깅 툴.
               부팅시 그래픽 서브시스템이 초기화 되기 전 꼭 필요한
               OS 서브 시스템 프로세스에 어테치가 가능하다.
• NTSD   :
• KD       : Console 기반 커널 모드 디버깅 툴.
  
• 프로세스/네트워크 룩업 툴
• Process Explorer
• Wireshark

PRINTING ARCHITECTURE

지금 내가 맡고 있는 제품은 프린트 보안...

수 많은 보안 영역 중에 프린트 보안은 인기도 없고 관심도 없다.

그렇다고 기술적으로 배울게 없는 것은 아니다.

프린트 보안 S/W의 요구사항은 대체적으로 아래와 같을 것이다.

      

      1. 인쇄물에 회사 로고를 넣어줘 

            => 워터마크

      2. 누가 언제 무엇을 인쇄 했는지 관리자가 알 수 있게 해줘

            => 인쇄 로깅

요구사항은 단순 하지만 기능을 구현하려면 알아야 할 것들이

한 두 가지가 아니다. 그 중 첫 번째로 알아야 할 것은 인쇄 프로세스가 되겠다.

오늘은 인쇄 프로세스에 대해 공부해 보자.

이 주제에 대해 구글링을 조금 해보신 분들이라면 알겠지만 제대로된 자료가 많이 없다.

그래서 책을 찾아 봤는데... 인쇄에 대해 깊이 있게 설명하고 있는 책은 많지 않다... 

하지만! GDI로 가장 유명한 책인 Windows Graphics Programming Win32 GDI and DirectDraw을 선택하고, 2.4 Printing Architecture 챕터를 공부해 보기로 한다. 

책을 처음 보기 때문에... 아래 글 수준은 책을 번역하는 정도가 될 것 같다. 

하루 하루가 장애와의 전쟁

내가 일하는 곳 그 자리는 하루 하루 장애와
전쟁을 치르는 곳이다. 내가 소프트웨어 개발자인지
유지 보수 담당자인지 구분이 안될정도다.

수 많은 버그들이 담긴 견고하지 않은 제품이
고객에게 전달되면 그 버그를 해결하기 위해 필요한
노력은 개발과 QA시에 발견되는 것보다 더 힘이든다.

버그 원인과 위치를 찾기 위한 시간.
고객의 불만은 그 제품에 대한 신뢰를 무너뜨린다.

난 스마트폰 초기부터 아이폰만 쓰고 있는데
그 이유 중 하나는 스카이 시절에 삼성 폰 sw에
버그가 많아 아직도 이 고정관념 때문에 삼성
개발자를 믿지 않기 때문이다.

믿음이 깨지면 회복하기 어렵다는것...

제품에 대한 신뢰는 당장 눈 앞에 보이는
수주 수익보다 더 큰 가치를 창출한다고 믿는다.
요즘 이런 생각들을 하면서...

회사을 바꿀 수 없다면
내 위치에서 할 수 있는 것들을 찾으려 한다.
개발자로 보람차고 행복하게 일하는 그 날 까지!!