Bach`s Blog

1. 서론

apk 파일은 Zip파일에서 확장된 형태로 Zip파일과 동일한 구조를 같습니다. apk의 구조를 알아보기 위해 Zip파일 구조를 알아보았습니다. 

2. 본론

Zip 파일은 여러 개의 파일이 압축(혹은 압축되지 않은)되어 묶여 있는 파일이며 각 파일에 대한 내용이 담긴 헤더(Local file header)가 있고 이 헤더를 위한 각각의 헤더(Central Directory header)가 있으며 이 헤더들을 위한 끝판왕 헤더(End of Central Directory header)로 살펴볼 수 있습니다. 말로 풀어 이해가 잘 안되지만 그림으로 살펴보면 아래와 같습니다.

zip file 개요

2.1 ) End of Central Directory

End of Central Directory는 파일의 맨 마지막에 위치하고 있으며, 위에서 언급했 듯 Central Directory의 정보(시작 offset, 전체 Central Directory사이즈 등)를 가지고 있습니다. 즉, Zip파일 구조를 뜯어보려면 제일 먼저 End of Central Directory를 찾으면서 시작해야합니다. 하지만 End of Central Directory의 크기는 file comment때문에 가변적이고, 시작점을 단번에 찾기는 쉽지 않습니다. 

file comment는 End of Central Directory의 맨 마지막에 위치하고, file comment를 제외한 상위 바이트들의 사이즈는 22바이트입니다. 따라서 file comment가 존재하지않는 경우 파일의 끝에서부터 22바이트 떨어진 지점 부터 End of Central Directory가 시작됩니다. End of Central Directory가 시작되는지 확인하기 위해서는 4바이트를 읽어 signature(0x06054B50)와 일치하는지 확인해여 확인 할수 있습니다. 

종합해보면 End of Central Directory를 찾는 과정은 다음 처럼 생각해 볼 수 있습니다.

1) 파일 맨 끝에서부터 22바이트 떨어진 지점으로 파일포인터를 이동한다.

2) 해당 지점에서 4바이트를 읽는다.

3) signature와 일치하는지 확인한다.

4) 일치하지 않는 경우 파일의 상위로 파일포인터를 감아가면서 2) ~ 3)의 과정을 반복한다.

      end of central dir signature    4 bytes  (0x06054b50)
      number of this disk             2 bytes
      number of the disk with the
      start of the central directory  2 bytes
      total number of entries in the
      central directory on this disk  2 bytes
      total number of entries in
      the central directory           2 bytes
      size of the central directory   4 bytes
      offset of start of central
      directory with respect to
      the starting disk number        4 bytes
      .ZIP file comment length        2 bytes
      .ZIP file comment       (variable size)

End of Central Directory 구조

End of Central Directory의 시작점을 찾았다면 위에 서술된 구조를 참조하여, 차례대로 읽어드리면됩니다.

참고 : http://stackoverflow.com/questions/8593904/how-to-find-the-position-of-central-directory-in-a-zip-file

End of Central Directory에서 Central Directory들의 첫 시작 offset을 읽어 파일포인터를 이동시킴으로써 Central Directory를 읽을 수 있습니다.

2.2) Central Directory

Central Directory는 zip파일에 포함된 파일들의 정보를 가지고 있는 Local header의 정보(Local header의 offset, 파일명, 압축사이즈 등)를 가지고있습니다. End of Central Directory에서 얻은 offset을 통해 Central Directory들의 첫 시작 주소를 찾았다면, 이 또한 역시 4바이트를 읽어 signature(0x02014B50)와 비교하여 검증을 해볼 수 있습니다.  일치 하지 않는다면, 위에서 offset을 잘못찾은 것입니다. 

Central Directory들은 연속되어 존재합니다. 

ex) 첫 번째 파일의 Central Directory -> 두 번째 파일의 Central Directory -> ....... -> N 번째 파일의 Central Directory

Central Directory의 구조는 아래와 같습니다.

 central file header signature          4 bytes  (0x02014b50)
        version made by                 2 bytes
        version needed to extract       2 bytes
        general purpose bit flag        2 bytes
        compression method              2 bytes
        last mod file time              2 bytes
        last mod file date              2 bytes
        crc-32                          4 bytes
        compressed size                 4 bytes
        uncompressed size               4 bytes
        file name length                2 bytes
        extra field length              2 bytes
        file comment length             2 bytes
        disk number start               2 bytes
        internal file attributes        2 bytes
        external file attributes        4 bytes
        relative offset of local header 4 bytes

        file name (variable size)
        extra field (variable size)
        file comment (variable size)

Central Directory 구조

Central Directory역시 파일명, extra field, file comment등의 가변 크기의 변수를 갖지만 사이즈를 가지고 있으므로, 읽는데 어려움은 없습니다. file comment의 끝에 바로 다음 Central Directory가 시작 되기 때문에 다음 Central Directory의 offset이 따로 존재 하지 않는 것으로 추측됩니다.

Central Directory에서 local header offset을 얻었으면 비로소 실제 파일에 접근 할 수 있는 local header에 도달할 수 있습니다.

2.3) Local file header

Local file header는 파일의 0번부터 시작하며, 순차적으로 N번째 파일까지 이어집니다.

Local file header에는 Zip파일 내부에 존재하는 각 파일에 대한 정보들(파일 명, 압축 메서드 정보, crc-32 등)을 가지고 있습니다.

Local file header뒤에는 압축에 암호화가 되어있는 경우와 암호화가 되어있지 않은 경우로 뒤에 위치하는 데이터가 다릅니다.

암호화가 되어있는 경우에는 encryption header가 뒤에 온 후 file data(압축 되어있거나 압축되지 않은)

암호화가 되어 있지 않은 경우에는 바로 file data가 오게 됩니다.

      local file header signature     4 bytes  (0x04034b50)
      version needed to extract       2 bytes
      general purpose bit flag        2 bytes
      compression method              2 bytes
      last mod file time              2 bytes
      last mod file date              2 bytes
      crc-32                          4 bytes
      compressed size                 4 bytes
      uncompressed size               4 bytes
      file name length                2 bytes
      extra field length              2 bytes

      file name (variable size)
      extra field (variable size)

Local file header 구조

3. 결론

Zip파일 구조를 파악하기 위해 가장 중요한 세 가지 헤더를 알아보았는데, 아직 부족한 점이 많습니다.

encryption 여부를 파악하여 실제 file data를 찾아내는 방법, file data뒤에 이어지는 file description파트, zip64에 따른 내용 등

Zip파일 전체 구조를 확실히 파악하기 위해서는 조금 더 연구를 해보아야 할 것 같습니다.

개인적으로는 한글 자료가 상세하게 되어있는 것이 없어서 짦은 영어끈으로 머리 싸매가며 연구해본 첫 경험이라 매우 뜻깊었습니다.

참고

1) 위에 분석 방법을 C로 개발한 프로젝트를 git hub에 올려두었습니다.

링크 : https://github.com/uisooshin/ZipAnalyzer

2) 위 내용은 아래의 링크에 상세 내용이 있습니다.

링크 : https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

2016년 6월 19일 세종대학교 광개토관 컨벤션홀에서 열린 Google I/O 2016 Extended Seoul에 다녀온 후 개인적으로 정리 / 후기를 남겨봅니다!

이 행사는 13:00 ~ 18:00 동안 50분 컨퍼런스 10분 휴식방식으로 5번 3개의 트랙이 진행되었습니다. 저는 안드로이드에 타겟을 맞추어 세션을 왔다 갔다하며 참여하였습니다! 꼼꼼히 적는다고 적었으나, 아는만큼 보인다고.. 알아들은 것 위주로 개인적으로 중요하다 생각했던 것 위주로 적어서 두서없이 정리가 되었네요ㅠ 정리한 내용은 아래와 같습니다.

1. 안드로이드 N을 준비하는 개발자를 위한 안내서 - 이승찬 (Track A)  

1-1) Android N 진행 현황

Android N은 6월 15일에 공개된 API 즉, API24가 최종으로 배포될 예정이고 큰 결함이 없는 이상 수정없이 배포될 예정이라고 합니다. 또한 이전 배포한 마쉬멜로 이하 버전들은 항상 버그가 발견되거나 수정사항이 생겨서 일정이 조금씩 밀려서 10월 정도에 릴리즈가 되곤했다고 하는데, 이번 N버전은 일정대로 순항 중이고 현재 큰 버그가 없다면 8월 중에는 N버전 사용가능 단말(Nexsus, xperia)에 한해 릴리즈 유저가 생길 전망이라고 합니다!

 1-2) Android N for Developer

Android N에 대처하는 개발자들에게 3가지 정도를 이야기했습니다.

1-2-1) Supproting Multiple Screens

기존에 많이 알려져있듯이 Android N 버전에서의 가장 큰 변화는 Supproting Multiple Screens 입니다. 단말의 화면을 분할하여 2개의 앱을 실행하는 기능인데요, 나뉜 화면 간 Drag and Drop까지 가능하다고 합니다. 

Multiple Screens는 기본적으로 한 화면에 두 개의 Activity가 실행되지만 기존의 Activity생명주기라던지, Orientation과 같은 View 메커니즘 상의 변화는 없다고 합니다. 다만 유의할 점이 몇 가지 생겼습니다. 

유의점 

- 앱에서 화면을 landscape 또는 portrait로 제한하고 있는 경우 멀티스크린에서 view가 제대로 동작하지 않을 수 있으니 유의해야합니다.

-  Screen Zoom이라는 기능은 안드로이드 접근성을 고려해 생긴 기능으로 말그대로 화면을 Zoom을 할 수 있는 기능입니다. 기존에 High performance device를 타겟으로 한 앱이라면 320dp의 리소스가 누락되어있을 수 있는데, 이런 경우에는 resource not found exception -> app crash 가능성이 있습니다.

- Chrome Book은 아직 국내에서 많은 인기를 얻고 있지는 못하지만 미국에서 진행된 Google I/O 2016에서는 상당한 관심을 보였던 분야라고 합니다. Chrome Book에서도 Multiple Screens를 고려한 개발이 이루어져야 한다고 합니다.

제가 유의점을 들으면서 종합적으로 이해한 내용은 기존의 버전에서 앱의 화면은 비교적 정적으로 지정되어있었다면 N버전부터는 내 앱이 어떤 화면에서 어떤 해상도로 어떻게 실행 될지 알수 없는 상황이 되고 많은 UI의 가능성을 고려하지 않으면 안된다는 내용이라고 이해했습니다.

물론 멀티스크린을 무조건 지원해야하는 것은 아닙니다. 멀티스크린을 지원하지 않게 지정하려면 엑티비티 설정 중 resizeableActivity를 false 값으로 셋팅하여 지원하지 않도록 설정 할 수 있습니다. 다만 이 resizeableActivity의 default값은 true이고, Activity_task의 root에 설정된 값을 나머지 task들이 모두 같은 값을 갖게 됩니다.

구체적인 방법은 아래와 같습니다.

if I can't support Multi-Window

1. targetSdk < 24, screenOrientation = portrait | landscape

2. targetSdk = 24

   a. resizeableActivity = false

      launchMode = singleInstance | singleTask

   b. resizeableActivity = fase

      documentLaunchMode = always

1-2-2) Battery Optimization

더 나은 앱을 위해서 모든 개발자들이 고민하는 요소 중의 하나인 베터리 최적화에 대한 내용을 이야기했습니다.

구글이 생각하는 Battery Optimization을 위해 Background Activity 3가지 원칙이 있었는데요,

 1. Reduce

    - 하지말자

 2. Defet

    - 해야되면 충전 할 때 하자

 3. Coalesce

    - 여러가지 작업을 한번에 몰아서 하자

이런 원칙을 지키기 위해서 Marshmallow버전부터 있었던 Doze mode라는 것을 N에 더 강화시켰다고합니다. 안드로이드 개발을 하고있다고 하면서도 처음듣는 내용이라서 매우 부끄러웠습니당ㅠㅠ

Marshmallow에서 Doze mode는 간단히 말해서 단말이 일정시간동안 움직이지 않고 스크린이 비활성화 되어있다면 네트워크 작업, 알람 작업 등의 백그라운드 작업이 멈추게됩니다. 이 기능이 Android N에서는 한층 더 강화되어서 이동 중일때에도 스크린이 비활성화 된 경우 Doze mode가 활성화 된다고하네요.

이런 Doze mode에 대한 앱 테스트를 진행 할 수 있는 방법은 아래의 adb 커맨드로 환경을 설정해서 테스트를 진행 할 수 있습니다.

adb shell dumpsys deviceidle step (light) 

또한 베터리 관련해서 Battery Historian이라는 것을 이용하면 app의 베터리 사용량을 자세히 모니터링 할 수 있다고 하니 참고하시기바랍니다.

1-2-3) Memory Optimization

4. Android Studio 2.2(Preview 3 기준) - 김태호 (Track A)

새롭게 나올 Android Studio 2.2에 대해서 현재까지 나온 Preview 3을 기준으로 잘 설명해주셨습니다. 개인적으로 이 세션을 듣고나서 Android Studio 2.2에 대한 기대감이 엄청나게 올라갔습니다!

4-1) Design

4-1-1) 기존에 있었던 Visual Editor가 더욱 심플하고 파워풀해졌습니다. 

몇 가지 눈에 띄는 것을 꼽아보자면 레이아웃 리소스 외 menu와 Preferences를 지원하고 에디터 내에서 스크롤 뷰의 스크롤 지원하며 속성 탭 개편을 통해 주요 속성화면과 전체 속성 화면간 전환이 이루어져서 굉장히 편리하게 개선되었습니다!

4-1-2) Constraint Layout

새롭게 추가된 Constraint Layout은 Visual Editor와 맞물려서 앱의 Layout과 View를 굉장히 간편하게 만들수 있게 되었습니다. XCode와 견주어도 더 좋으면 좋았지 떨어질 것 같지 않은 성능인 것 같았습니다. 세션 진행자 분께서 시연영상을 보여 주셨는데 기존에는 거의 xml로 작업했다면 제 기준으로 1~2시간은 족히 했을 작업을 10분도 안되서 뚝딱 하는 걸 보고 굉장히 놀랐습니다. 거의 프리젠테이션에서 도형그리기 수준(?)으로 보였습니다. 또한 기존의 레이아웃은 Relative Layout안에 Linear Layout이 배치되고, 또 안에 Layout이 배치되거나 View가 배치되는 구조가 일반적이였는데 Constraint Layout은 이러한 계층 구조를 가지지 않고 Constraint Layout안에 한번에 다 배치가 되는 구조라 계층구조가 굉장히 단순해지고 쉬워졌습니다! 

4-1-3) Layout inspector

현재 표시되고 있는 단말기 (혹은 에뮬레이터)의 뷰 구조를 확인할 때 사용하는 툴인데요, 기존에 DDMS 내에 포함되어 있던 기능과 거의 유사하며 뷰 디버깅에 용이하다고 합니다. Android Monitor Pane > Layout Inspector를 통해 사용할 수 있다고하는데, 사실 아직 개발하면서 UI 디버깅을 많이 해본 적이 없어서 그런지 Constraint Layout에 비해 크게 기대되는 기능은 아니였습니다. 역시 아는만큼 보이는 거겠지요.ㅠㅠ

4-2) Develop

코드 분석과 리소스 관리측면에 대해서 향상되었습니다. 

4-2-1) Find & Remove Unused Resources기능은 앱내에서 참조하지 않고 있는 리소스를 찾아서 제거해주는 기능이라고 합니다. Android N에서 제공하는 멀티스크린에서는 리소스의 량이 크게 증가할 거라는 생각이 들었는데, 이것과 맞물려서 유용할 것 같습니다.

4-2-2) 또한 추가된 Annotations 22.2에서 Threading Annotations를 통해서 @UIThread, @MainThread, @WokerThread, @BinderThread 등으로 지정하고 구현을 해서 런타임 에러를 많이 줄일 수 있게 될거 같습니다.

또한 기존에 타겟 sdk를 지정하고 그와 맞지 않는 api를 사용하여 개발을 하면 노란 밑줄이 가면서 잠재적인 에러를 내포하는 코드가 되곤했는데 @RequiresApi를 통해서 호출하는 단말의 api레벨에 따라 알아서 판단해서 분기해서 호출하게 됩니다.  

@Dimension, @Px 어노테이션은 px과 dp 값을 표시하게 되어 좀더 깔끔한 UI처리를 할 수 있게 도와줍니다. 

@Keep은 난독화 관련 어노테이션은 Proguard 돌릴 때 난독화를 돌리지말아라 하는 어노테이션으로 알아두면 굉장히 유용할 것 같습니다. 단, Keep 어노테이션은 Gradle plugin 2.2+를 사용 해야합니다.

4-2-3) firebase plugin이 추가되었는데 GCM등의 서비스를 제공하기 편하도록 해주는 플러그인이라고 합니다.

4-2-4) 현재 개발 중 모르는 api는 f2키를 눌러 제공되는 document를 보고 확인 할 수 있습니다. 앞으로는 sample code 또한 document와 같이 제공되어 더욱 쉽게 이해 할 수 있게 도와준다고합니다. 

1. Man In The Middle Attack?

  중간자 공격(man in the middle attack, MITM)은 네트워크 통신을 조작하여 통신 내용을 도청하거나 조작하는 공격 기법이다. 중간자 공격은 통신을 연결하는 두 사람 사이에 중간자가 침입하여, 두 사람은 상대방에게 연결했다고 생각하지만 실제로는 두 사람은 중간자에게 연결되어 있으며 중간자가 한쪽에서 전달된 정보를 도청 및 조작한 후 다른 쪽으로 전달한다.

  일반적으로 가정에서 흔히 구성되고 있는 네트워크 형태로는 하나의 인터넷 회선에 공유기를 사용하여 홈 네트워크를 구성하고 있다. 이 때, 공격자가 같은 홈 네트워크를 사용하고 있다고 가정하면, 위 그림과 같은 중간자 공격을 수행 할 수 있다. 피해자 입장에서는 공유기를 통해서 인터넷과 연결되고 생각 할 수 있지만, 실제로는 공격자를 통해 공유기를 거쳐 인터넷을 사용 하고 있는 것이고, 공격자는 피해자의 패킷들을 감청 및 조작이 가능하다.

  이 글에서는 ARP 스푸핑을 통해 MITM을 수행하는 모습을 보여줄 것이다.

실습 환경은 공격자 PC의 OS는 Kali linux 2.0, 피해자 OS는 Windows 7을 사용하였다. AP는 iptime 104N모델 펌웨어 9.58버전을 사용하였다.

2. ARP Spoofing

  ARP 스푸핑(ARP spoofing)은 근거리 통신망(LAN) 하에서 주소 결정 프로토콜(ARP) 메시지를 이용하여 상대방의 데이터 패킷을 중간에서 가로채는 중간자 공격 기법이다. 이 공격은 데이터 링크 상의 프로토콜인 ARP 프로토콜을 이용하기 때문에 근거리상의 통신에서만 사용할 수 있는 공격이다.

 이 기법을 사용한 공격의 경우 특별한 이상 증상이 쉽게 나타나지 않기 때문에 사용자는 특별한 도구를 사용하지 않는 이상 쉽게 자신이 공격당하고 있다는 사실을 확인하기 힘들다.

  ARP(Address Resolution Protocol, ARP)는 네트워크 상에서 IP 주소를 물리적 네트워크 주소로 대응(bind)시키기 위해 사용되는 프로토콜이다. 여기서 물리적 네트워크 주소는 이더넷 또는 토큰링의 48 비트 네트워크 카드 주소를 뜻한다.

3. arpspoof tool 사용 

victim의 ip는 192.168.0.3이고, 네트워크의 gateway의 ip는 192.168.0.1,

공격자의 ip는 192.168.0.2이다. 

arpspoof 사용법 : arpspoof -i [interface 설정] -t [victim ip] [위장 할 ip] 

arpspoof -i wlan0 -t 192.168.0.3 192.168.0.1

 먼저, 피해자 pc에 내가 게이트웨이인 것처럼 위장하도록 한다.

 그 다음, 같은 방식으로 arpspoof를 이용해 게이트웨이에게 내가 피해자의 pc인 것처럼 위장한다.

arpspoof -i wlan0 -t 192.168.0.3 192.168.0.1

  이렇게 설정하면 위의 그림과 같은 가짜 경로를 만들어 낼 수 있으며, 실제로 피해자의 컴퓨터에서 arp -a 명령어를 통해 arp테이블을 보면 게이트웨이 ip주소와 공격자 컴퓨터의 맥주소가 같은 것을 볼 수 있다.

 피해자와 게이트웨이로부터 받은 패킷을 서로에게 ip forwarding 해주기 위하여 echo 1 > /proc/sys/net/ipv4/ip_forward 로 설정을 해준 후 fragrouter툴을 사용하여 ip 포워딩을 해서 연결을 완성해준다.

fragrouter -B1

 이 후, WireShark를 이용하여 피해자의 인터넷 패킷을 감청 할 수 있으며,

필터에 ip.addr == 192.168.0.3(피해자의 ip주소) 입력하여 필터링을 해주어 쉽게 볼 수 있다.

  아래의 그림은 한국기술교육대학교 온라인교육 홈페이지에 로그인 할 때의 패킷이고, 해당 홈페이지는 아이디와 비밀번호를 Plain text로 전달하여 다 보이게 된다.

1 . 정적분석

1) VirusTotal

분석 전 실습파일(Lab03-03.exe)를 VirusTotal(www.virustotal.com)에서 검사를 해본 결과

탐지 비율이 37/54로써 악성 코드임을 짐작할 수 있었다.

2) PEview와 Depandency Walker

 PEview와 Depandency Walker로 Lab03-03.exe의 PE구조에서 kernel.dll밖에 임포트하지 않는 것으로 보여지지만,

GetProcAddress 함수를 사용하는 것으로 보아서는 다른 dll도 임포트하지 않을까 라는 추측을 했고

WriteFile함수를 보고 어떠한 파일에 영향을 미치는 일을 할 것 같다는 생각을 했다.

3) PEiD

혹시 패킹이 된것은 아닐까 싶어 PEiD를 사용하여 분석해보았지만 

Visual C++ 6.0으로 컴파일 된 것 외에 다른 정보는 얻을 수 없었다.

 4) strings

전에 하던 정적 분석에서는 strings를 사용해 유용한 문자열을 많이 뽑아 볼 수 있었지만,

이번 파일은 그다지 유용한 문자열이 없었다. 거의 텍스트가 깨지거나 의미없는 특수기호 대문자 AAAAAAAAAAAA의 

연속이였고 그나마 의미있어보이는 문자열을 캡쳐해보았다. 물론 저게 무엇을 의미하는지는 잘 모르겠다.

정적 분석 결과 

1. virus total을 이용한 조회 결과는 악성코드로 보는 것이 맞는 것 같다.

2. 어떠한 방식인지는 모르겠지만 파일에 영향을 주는 일을 할 것같다.

-----------------------------------------------------------------------이외엔 정적 분석으로 별 소득이 없었다. 

2. 동적분석

1) Process Monitor

Lab03-03.exe를 실행 하면, svchost.exe라는 자식 프로세스를 생성 한 후에 

Lab03-03.exe프로세스는 종료되어진다.

생성된 자식 프로세스 svchost.exe는 Lab03-03.exe프로세스 종료 이후 고아 프로세스가 된다.

(책에서 고아 프로세스라고 설명을 하던데 원래 있는 말인지는 모르겠지만 잘 이해할 수있게 표현 한것 같다.)

svchost.exe는 아래와 같이 services.exe아래에 자식 프로세스로 생성 되는 것이 일반적이기 때문에

고아프로세스로 실행 되고 있는 svchost.exe프로세스는 이상하다고 생각 된다.

고아가 된 svchost.exe프로세스의 속성을 확인하던 중 [ENTER]와 [TAB]과 같은 문자열을 발견했는데,

보통 키로거에서 많이 볼 수 있는 문자열이라고 한다.

또한 practicalmalwareanalysis.log이라는 로그파일(?)의 이름처럼 보이는 문자열도 찾았다.

(키로거는 사용자의 키 값을 서버에 전송하거나, 키의 값을 파일로 저장하여 그 파일을 전송하는 악성코드의 종류인데,

아마 숫자 영문키 외에 엔터, 쉬프트, 컨트롤 등과 같은 키값을 저장하기 위해 만들어놓은 문자열이 아닌가 추측한다.) 

2) ProcessMonitor

 Process Explorer를 통해 수상한 프로세스를 찾았고, 그 프로세스의 pid는 3412였고, 

ProcMon에 필터를 PID로 두고 분석을하였다.

 분석을 한 결과 

Process Profiling

CreateFile

QueryStandardInformationFile

WriteFile (*n번)

CloseFile

IRP_MJ_CLOSE

1. Process Profiling을 하면서 키이벤트가 발생하는 것을 감지하고

2. CreateFile, QueryStandardInformationFile, WriteFile의 과정으로 파일을 열고 키값을 저장

3. CloseFile, IRP_MJ_CLOSE를 통해 파일입출력을 닫는다.

이러한 과정을 통해 키로깅을 하고 있는 것 같다.

파일의 저장경로는 옆에 나와있듯이 Lab03_03.exe가 위치한 폴더 내이고,

파일 명은 Process Explorer에서 찾아낸  practicalmalwareanalysis.log였다.

파일을 메모장으로 열어보니, 어떤 윈도우창에서 어떤 키를 조작했는지 까지 상세하게 나와있었다.

끝:)

------------------------------------------------------------------------------------------------------------

전에 했던 분석에서는 HTTP GET방식을 이용해 통신기능을 수행해서 탐지 시그니처를 정할 수 있었는데, 

이러한 경우엔 파일의 고유 값 외에 어떤 것을 탐지 시그니처로 정해야할지 아직 잘 모르겠다. ㅠ 

그래도 이번 분석은 책의 도움을 많이 받지 않고 한 것에 만족한다. 

1 . 정적분석

1) VirusTotal

분석 전 실습파일(Lab03-02.dll)을 VirusTotla(www.virustotal.com)에서 검사를 해본결과 

탐지 비율이 41/54로써 거의 악성코드임을 짐작할 수 있었다.

2) PEview

 PEview로 Lab03-02.dll의 PE구조에서, ws2_32.dll과 winnet.dll을 임포트하며

사용하는 함수들을 보면 통신기능을 수행할 것으로 짐작돼는 internet과 http관련 함수들이 보여서

어떠한 데이터를 외부로 전송하거나, 외부로 부터 악성코드를 다운받을 것이라 짐작되어진다.

 5) strings

strings로 찍어보면 practicalmalwareanalysis.com 이라는 서버네임같이 보이는 문자열도 보이고,

GET, HTTP/1.1이라는 문자열을 보아 유추해보면 80포트를 이용하여 http를 get방식으로 사용할 것이라고 추측해 볼수 있었다. installA로 설치가 가능 할 것으로 예상된다.

정적 분석 결과 

1. 외부와 http의 get방식을 이용하여 통신하여, 데이터를 전송하거나 악성코드를 다운받을 것이다. 2. installA라는 문자열을 통해 이것으로 설치를 할 수 있을 것 같다.

3. virus total을 이용한 조회 결과는 악성코드로 보는 것이 맞는 것 같다.

2. 동적분석

1) rundll32.exe Lab03-02.dll,installA

dll자체는 실행 파일이 아니므로 단독으로 실행하여 분석을 진행 할 수 없으나,

rundll32.exe을 통해 해당 dll의 함수를 실행 시켜 분석을 계속 진행 해 볼 수 있었다.

(dll의 installA실행 전후 관찰을 위해 rundll32실행 전 Process Explorer와 Regshot을 미리 셋팅해두었고, 이 후 변화를 분석하였다.)

2) Regshot 

키가 추가된 위치를 보면 악성코드가 서비스 IPRIP를 이용해 설치 했다는 것을 볼 수 있다.

또한 악성코드가 dll이므로 자체 실행이 아닌 dll을 로드할 실행 파일이 필요한데 이것은 imagepath를 보면 알 수있다.

ImgePath는 헥사코드로 인코딩이 되어 있어서 디코딩을 하여 확인을 한 결과 

svchost.exe 프로세스 내에서 실행 되는 것을 확인 하였다.

(그 외 DisplayName이나 Description항목은 악의적인 서비스를 식별하는데 사용가능한 흔적을 생성한다. 라고 책에 설명되어 있는데, 아직은 잘 이해 하지 못하겠다.)

3) regedit

실행 -> regedit을 실행하여 실제 레지스트리에 저렇게 등록 되어 있는지 확인해 보았더니, regshot 보고서에서 보았던 

내용이 그대로 등록되어있음을 확인 할 수 있었다.

4) Process Explorer

Process Explorer를 통해 실제 Lab03-02.dll을 로드하여 실행되고있는 svchost를 구별하기 위해 검색해 보았고, 1104라는 pid를 가진 scvhost프로세스라는 것을 찾았다! 

(서비스에 Intranet Network Awaeness(INA+)[IPRIP]라는 항목도 보인다.)

5) 악성코드의 실행

ApateDNS를 통해서 모든 요청을 나 자신으로 돌아오게 만들고 넷켓을 이용하여 80포트로 들어오는 요청을 받는다.

특별히 80포트를 조회한 이유는 정적분석(strings)을 통하여 http의 GET방식을 사용 할 것이라 추측하였기때문이다.

그 결과 예상대로 http의 GET방식을 사용한 요청이 들어왔으며 host역시 정적분석 문자열을 통하여 확인했던

practicalmalwareanalysis.com 이였다.

여기서 악성코드의 시그니쳐를 뽑아 내자면,

첫째로 serve.html이 http요청을 하고있기 때문에 이것을 시그니쳐로 GET요청을 사용 할 수 있고,

두 번째로 User-Agent에서 사용자 컴퓨터명을 제외한 Windows XP 6.11이 일정하기때문에 시그니쳐로 사용 할 수 있다. 

:) 끝

____________________________________________________________________________________________________________

사실 아직까지는 책과 인터넷 검색을 통해서 따라하는 수준이고, 익숙치가 않다. 마지막 결과를 받는 부분에서 제대로 

악성코드를 설치하고 실행을 했음에도 결과값이 나오지않다가 어쩌다가 결과 값을 받게 되었다. 요청이 찍히지 않았는지, 왜 갑자기 요청이 들어오게 되었는지 잘모르겠지만, 하나하나 따라하다보면 결국엔 혼자서도 잘 할 수 있을 거라 믿고

열심히 진행해야겠다.

1 . 정적분석

1) VirusTotal

분석 전 실습파일(Lab03-01.exe)을 VirusTotla(www.virustotal.com)에서 검사를 해본결과 

탐지 비율이 50/54로써 거의 악성코드임을 알수 있었다.

2) PEview

PEview로 Lab03-01.exe의 PE구조를 살펴 보니, 임포트한 dll은 kernel32.dll밖에 보이지 않았으며 별다른 점은 보이지 않았다.

3)Depandancy Walker

Depandancy Walker에서 살펴보아도 임포트한 dll은 kernel32.dll, 사용한 함수는 ExitProcess밖에 보이지 않는다.

이 점을 미루어보아 무언가로 패킹되었다는 것을 짐작 할 수 있었다.

4)PEiD

PEiD로 확인해 보니 예상대로 패킹이 되어있었고, PEncrypt로 패킹이 되어있었다. 

5) strings

strings로 찍어보면 www.practicalmalwareranalysis.com이라 던가 어떤 레지스트리 경로처럼 보이는 것도 나오고, 

의심스러운 파일명하며, 단서가 될만한 것들이 찍혀보이는 것을 확인했다.

정적 분석 결과 

PEncrypt로 패킹이 되어 있으며, 도메인네임이 있는 것으로 보아 통신기능(어떠한 파일을 다운을 받거나, 데이터를 빼내는 기능 등)을 하는 것 같다는 것을 유추해 볼 수 있다. 또한 무슨일을 하는지는 모르지만 VirusTotal의 결과로 사용자에게 피해를 주는 악성코드라는 것을 알게 되었다.

2. 동적분석

1)Process Explorer

프로그램 실행 전 Process Explorer를 실행하고 실습파일을 실행하였고, 

어떤 dll을 로드하는지 확인해보니 ws2_32.dll과 wshtcpip.dll과 같은 dll을 로디해서 사용하는것을 확인, 고로

통신기능을 수행할 것으로 생각 할 수 있다.

2)Process Monitor

위의 정적분석 (strings의 결과)를 거쳤을때, 어떠한 파일경로로 의심되는 문자열이 있었고, 레지스트리경로로 보이는 문자열이 있었기 때문에, 필터설정을 위의 그림과 같이 Process Name은 Lab03-01.exe, Operate는 writeFile과 RegSetValue를 필터링 하여 살펴본 결과가 나왔다. 

먼저, WriteFile의 결과로 나온것을 더블클릭하여 자세히보니,  c:\WINDOWS\system32의 경로에 

크기가 7168byte짜리인 vmx32to64.exe라는 파일을 생성하고 있다는 것을 알 수 있었다.

이 파일을 다시 VirusTotal에 올려서 검사를 해보았더니

아래 처럼 사실 파일의 이름만 바뀌었을 뿐, Lab03-01.exe와 같은 파일임을 알수 있었다. 위의 SHA256키가 같고,

다른 분들이 분석한 것을 보면 파일의 md5해시값도 또한 같다고 한다.

이 점을 보면 Lab03-01.exe를 실행하면 c:\WINDOWS\system32의 경로에 vmx32to64.exe라는 이름으로 바꾸어 

복사 생성한다는 것을 알 수있다.

다시 ProcMon의 결과로 돌아와서 이번엔 RegSetValue의 결과를 상세히 확인하면, 복사생성한 vmx32to65.exe를 

레지스트리에 등록하여 윈도우 시작시 프로그램이 자동 시작되도록 값을 셋팅하는 것을 알 수 있다. 

시작프로그램에서 역으로 제거하는 방법은 

실행창에서 regedit을 실행 -> 레지스트리 관리창을 띄우고

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run에서 해당 정보를

(여기서는 VideoDriver라는 이름으로 되어있다. 실제 실행되는 파일은 vmx32to64.exe이다.) 삭제한다.

3)ApateDNS

역시 정적분석(Strings)결과 도메인네임으로 보이는 문자열이 보였기때문에, 또한 Process Explorer의 결과로 

통신기능을 지원하는 dll을 로드하므로 통신기능을 수행할 것 같다는 짐작을 할 수 있었으므로, ApateDNS로 확인해보았더니 문자열에서 보았던 주소로 어떠한 요청을 보내고 있다는 것을 확인할 수 있었다.

따라서 요청하는 IP를 나에게 다시 돌아오게 만들고, netcat을 이용, 80번 포트(http서비스)와 443번 포트(https서비스)를 리스닝을해놓고 기다려보니 80번 포트는 아무것도 오지않았고, 443포트에서 알수 없는 외계어가 들어왔다.

확실히 어떠한 것을 보내고 있는지는 모르지만 해당 서버로 어떠한 데이터를 주기적으로  데이터를 전송하고 있었다.

최종결론

실습파일(Lab03-01.exe)은 실행시 악성코드작성자가 코딩한 경로로 이름을 변경한(vmx32to64.exe) 자기자신을 복사 생성하며, 동시에 레지스트리에 그 복사 파일을 등록하여 윈도우시작시 자동 실행되어지게 만들었다.

또한 어떠한 내용인지 정확히 밝혀지지는 않았지만 www.practicalmalwareanalysis.com으로 주기적으로 https를 이용 어떠한 데이터를 전송하고 있는 것으로 분석 되었다.

Q. This program can detect debuggers. Find out the name of the debugger detecting function the program uses.

그림 1

최초 프로그램을 실행해보면, 정상이라는 글이 일정 시간간격으로 출력되는 것을 볼 수있다.

 그러나, 올리디버거로(또는 다른 디버깅 툴) 실행시,

그림 2

이러한 메인 루틴을 지나게 되면

그림 3

디버깅 당하고 있음을 출력하는 문자열을 볼 수 있다.

메인 루틴(그림 2)을 살펴 보면 문제에서 요구하는 답을 직관적으로 (IsDebuggerPresent) 알 수 있으며, 일정 시간을 두면서 문자열을 출력하는 이유 또한 알 수 있다.(Sleep함수)

보이는 바와 같이 IsDebuggerPresent함수는 Kernerl32.dll에 속해 있고, 디버깅을 당하고 있을시 non-zero, 디버깅을 당하고 있지 않다면 zero를 리턴한다. 

MSDN참조 : http://msdn.microsoft.com/en-us/library/windows/desktop/ms680345(v=vs.85).aspx

문제에 대한 답은 찾았으나, 디버깅을 하면서도 정상 이라는 문자열을 출력해보고 싶었다.

가장 쉽게 처음 생각한 방법은 IsDebuggerPresent함수를 지나 후에 있는 

TEST eax,eax 를 mov eax, 0으로 바꾸어보는 것이였다. 리턴 값을 조정해주면 내부가 어떻든간에

쉽게 해결될꺼라고 생각했는데, 정말 멍청한 생각이였음.

test 명령어는 두 값을 비교하여 플래그를 수정한다.

TEST 명령어는 피연산자들을 AND연산하여 즉, 두 피연산자중 하나라도 0이면 ZF = 1로 셋팅된다.

따라서 test eax, eax라는 것은 eax가 0인지 아닌지를 판별하는 명령어를 의미하게 된다.

CMP명렁어와 다른점은 두 피연산자들의 뺄셈연산을하여 같은지 다른지를 비교하는 것으로 차이점이 있다.

test명령어 아래에 나타나는 JE명령어는 이 ZF가 1이면 점프분기하는 조건분기 명령어중 하나이다.

따라서 단순 mov eax, 0으로 바꾸게 된다면 ZF값을 수정해 주지 못함으로써 아래의 JE조건분기를 수행할 수 없어서

프로그램이 뻗게되었다.

다음 방법으로 생각 한 것은 IsDebuggerPresent함수 내부에서 리턴 하기 전에 리턴 값을 0으로 수정해보기로 하였다.

함수 내부로 진입해 점프를 두 번 수행 하고 나니

그림 4

이 세개의 명령어 수행후 리턴을 하게 되었다. 이때 eax값은 7efde000, 따라서 7efde002 메모리번지에 있는 값으로 셋팅된 후 리턴 하게 된다는 것을 알게 되었고, 이 메모리 번지로 찾아갔다.

그림 5

BeingDebugged = TRUE로 되어있는 것을 보면 이 값을 리턴되었을때 디버깅이 되고있음을 의미한다는 것을 확실히 확신할 수 있었지만, 이 값을 변경 할 수 없었으며,

반대의 의미를 리턴하는 값을 아래에서 찾을 수 없었다.(찾게 된다면 74f33785의 movzx문을 수정해볼 생각이였다.)

왜 변경 할 수 없었는지에 대한 의문.... 잘 모르겠다.

kernerl32.dll에 있기 때문이거나, dll에 있는 부분이여서 동적으로 할당 되는 부분을 수정할 수 없기 때문이 아닌가 하고 생각만 해봄...ㅠㅠ

결국 IsDebuggerPresent함수 내부를 수정하는 것도 실패하고, 남은 방법은 

메인 루틴에서 test명령어 이후에 나타나는 je명령어를 jmp로 수정하는 방법밖에 떠오르지 않아서, 수정해보았더니

디버깅 중에도 정상으로 출력하는 것을 볼 수 있었다. 

결국 돌아돌아서 별 거 아닌 패치를 했지만, IsDebuggerPresent함수 내부를 한번 들여다 본 것과

단순 레지스터들의 값들뿐만아니라 여러 플래그들도 같이 둘러봐야 된다는 교훈을 얻게된 것같다.

CPU Register란?

: CPU내부에 존재하는 다목적 공간

  RAM은 물리적 제약에 의해 비교적 저속이나,

  Register는 CPU와 한 몸이기 때문에 고속이다.

  ( Register >> Cache >> RAM >> HDD ) //컴구조 시간에 배운 기억이;;

레지스터의 종류는 많지만, 우선은 기본적으로 알아야할 레지스터부터 알아본다.

*추후 control, memory, debug Register들의 공부도 필요하게 될 것같다.

Basic Program execution Register  - General Purpose Registers ( 32bit * 8개 ) //범용레지스터

                                                 - Segment Registers ( 16bit * 6개 )

                                                 - Program Status Control Registers ( 32bit * 1개 )

                                                 - Instruction Pointer ( 32bit * 1개 ) 

먼저 General Purpose Registers에 대해 알아보면,

각각의 크기는 32bit ( 4 byte )이며, 보통의 용도는 상수/주소 등을 저장하는데 쓴다.

특정 어셈블리 명령어에서 특정레지스터를 조작하기도하며, 특정레지스터는 특수용도로 사용된다.

그림과 같이 범용레지스터는

EAX ( Accumulator Operands and result data )

EBX ( Pointer to data in the DS Segment )

ECX ( Counter for String and Loop Operations )

EDX ( I/O Pointer )

EBP ( Pointer to data on the Stack )

ESI ( Source Pointer for String Operations )

EDI ( Destination Pointer for string Operations )

ESP ( Stack Pointer ) 로 구성이 되어있다.

그림에서 반이 나누어진 것을 볼수 있는데,

현재 사용되고있는 32bit기준으로 레지스터가 확장되었기 때문이다.

예전에는 16bit를 사용 하였기때문에 레지스터의 용량 또한 16bit였고, 여기서

확장된(Extend)의미를 붙여 각 레지스터에 E가 붙게 되었다.

새로 레지스터를 만들지 않고 확장시킨이유는 예전과 호환을 위해서라고 한다.

각 범용레지스터의 사용 용도는

EAX ~ EBX레지스터들은 주로 산술연산 (add, sub, xor, or 등) 명령어에서 상수/변수 값의 저장용도로

많이 사용되며 특별히 EAX와 ECX는 다른 특정 용도가 있다.

eax -> 함수 리턴값에 사용             ecx-> 반복loop 카운트수 저장

ESP는 스택 메모리 주소를 저장하고 있어서, 스택의 PUSH, POP에 따라 값이 변한다.

EBP는 함수 호출시 그 순간의 ESP를 저장하여 리턴 직전에 ESP값을 되돌려서 Stack이 깨지지않게 하는 역할을 한다.

나중에 나오지만 이것을 Stack Frame 기법이라고 한다.

ESI와 EDI는 특정 명령어들과 함께 주로 메모리 복사에 사용된다.

출처 : 리버싱 핵심원리 (이승원 저)

같은 네트워크망에 있다면 아이피 형식은 ex) 192.168.0.x 이런식으로 비슷하기 마련이다.

보통은 1은 게이트웨이로 쓰이며 이후 255까지 많은 접속 컴퓨터및 통신기기가 있을 수 있다.

먼저 기본으로 자신의 ip는 ifconfig 명령어를 통해 ip address 및 게이트웨이주소 맥주소 등을 확인해 볼수 있다.

그리고 ping 명령어를 통해 해당 아이피주소에 통신기기의 응답을 받을 수 있다.

예를 들어 ping 192.168.0.2 ~ 192.168.0.255 까지 각 아이피 주소에 대해 접속한 기기를 검색해 볼수 있는데,

하나하나 다 하다보면 시간이 너무 오래걸릴 것이므로....

간단한 프로그래밍을 통해 스스로 핑을 확인해 볼 수 있다.

#include <stdio.h>

int main()

{

      int i = 0;

      char order[100];

      for( i = 0; i <= 255; i++)

     {

            sprintf( order, "ping -c 192.168.0.%d |grep from", i );

            system( order );

     }

     printf("Search is finished\n");

     return 0;

}

위의 예제를 보면 0부터 255까지 i가 증가하면서  ping 명령어를 찍어보고 있고, 255까지 서치가 끝나면 서치가 끝났다는

printf문을 끝으로 프로그램이 종료된다.

ping명령어의 옵션으로 -c를 붙인 것은 해당 아이피의 응답을 한 번만 듣겠다는 옵션이고,

|grep from은 from이 포함된 결과만 보게 해주는 구문이다. 왜 그렇게 했냐면

응답이 있는 아이피 어드레스만이 from이 포함된 출력을 주고,(응답이 없을 경우 from이 포함되어있지않은 결과가나옴)

우리가 얻고 싶은 아이피 어드레스는 응답이 있는 것이므로 쓸데 없는 결과를 삭제한다고 볼 수 있다.

참조 : 해커스쿨 (http://www.hackerschool.org/)

처음으로 블로그에 올리는 글이고, 아직 학부생이라 허접한 내용이지만 하나씩 하나씩 글쓰는 재미를 얻어가야겠다;;;