레지스터

레가 : http://forensic.korea.ac.kr/tools.html

이벤트로그

로그 뜻 설명 사이트 : https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/

MMA(Microsoft Message Analyzer): 개발 중지...

점프파일(LNK)

LECMD :

점프리스트

JUMPLIST explorer :

프리패치

WinPrefetchView :

뮤캐쉬

MUICacheView v1.01: http://www.nirsoft.net/utils/muicache_view.html

앰캐쉬(amcache.hve)

amcacheparser:

쉼캐쉬

shimdector: himCacheParser: https://github.com/mandiant/ShimCacheParser

썸네일 캐쉬

thumbnaildatabaseviewer: http://www.itsamples.com/thumbnail-database-viewer.html

아이콘 캐쉬

thumbnaildatabaseviewer: http://www.itsamples.com/thumbnail-database-viewer.html

윈도우 타임라인

WxTcmd: https://ericzimmerman.github.io/#!index.md Timeline Explorer: https://ericzimmerman.github.io/#!index.md

VSS 개념 및 실습

shadowexplorer: https://www.shadowexplorer.com/downloads.html

window search

휴지통 파일

RBCmd: https://ericzimmerman.github.io/#!index.md

SRUM

SrumECmd: https://ericzimmerman.github.io/#!index.md

BAM

포렌식 툴 존재 x

FeatureUsage

포렌식 툴 존재 x

Windows Notification Center

포렌식 툴 존재 x

기타 포렌식 툴 모음 사이트

ericzimmerman: https://ericzimmerman.github.io/#!index.md 포렌식 proof: http://forensic-proof.com/tools

문제 다운로드 : https://dreamhack.io/wargame/challenges/729 win search는 파일을 검색할 때 사용되는데, 빠르게 찾기위해서 윈도우에서 미리 인덱싱을 해 놓는다. 그리고 데이타베이스에 저장한다. 이 데이타베이스를 분석하면 다양한 정보를 얻을 수 있으며, txt파일 같은 경우 내용도 저장되는 경우가 존재한다.

-사용자가 자주 사용하거나 최근에 사용한 문서 또는 프로그램을 관리하는 링크 파일 (미디어 파일은 제외) -윈도우7 이상 존재하는 아티팩트 -응용 프로그램별로 그룹화

예시 위 사진과 같이 최근에 닫은 탭, 자주방문한 페이지등의 정보가 존재한다.

포렌식 관점

• 문서, 프로그램 실행 유무 판단
• 자주 사용하는 문서, 프로그램 정보 확인
• 최근에 사용한 문서, 프로그램 정보 확인

경로

• C:\Users%USERNAME%\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestination

• C:\Users%USERNAME%\AppData\Roaming\Microsoft\Windows\Recent\CustomDestination

AutomaticDestinations

• 단어 뜻 그대로 운영체제가 자동으로 남기는 항목

• 최근 사용한 목록(Resent)나 사용자가 직접 고정시킨 항목(Pinned)가 위치하고 있다.

• 확장자는 automaticdestinations-ms

CustomDestinations

• 자주 사용되는 목록(Frequent)나 작업 목록(Tasks)가 존재하고 있다.
• 확장자는 customdestinations-ms

저장되는 파일 이름은 APP id로 아래 링크에서 app id와 app의 이름을 확인가능하다. :https://github.com/EricZimmerman/JumpList/blob/master/JumpList/Resources/AppIDs.txt

실습

ftk-imager을 통해서 파일들을 복사하였다. 그 후 jumplistexplorer을 통해서 파일들을 확인하였다. 아래 링크에서 파일 다운로드 가능하다. https://ericzimmerman.github.io/#!index.md 위는 chrome 점프리스트이다. 보면 lnk의 형태가 여러개 존재하고 그중 하나의 정보를 보면, 절대 위치 파일을 연시간, 파일의 정보를 알 수 있다.

LNK은 바로가기이다. 이러한 바로가기 파일은 윈도우에서 자동으로 만들게 되어있다.(비활성화 가능하다). LNK는 다양한 루트에 만들어진다. 이를 분석하여 파일의 실행으 확인 할 수 있다.

바탕화면 폴더

• Windows XP : C:\Documents and Settings<user name>\Desktop
• Windows 7 / 8 / 10 / 11 : C:\Users<user name>\Desktop

최근문서(Recent) 폴더

• Windows XP : C:\Documents and Settings<user name>\Recent
• Windows 7 / 8 / 10 / 11 : C:\Users\AppData\Roaming\Microsoft\Windows\Recent

시작프로그램(Start) 폴더

• Windows XP : C:\Documents and Settings<user name>\Start Menu\Programs
• Windows 7 / 8 / 10 / 11 : C:\Users<user name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs

바탕화면(Desktop) 폴더

• Windows XP : C:\Documents and Settings<user name>\Desktop
• Windows 7 / 8 / 10 / 11 : C:\Users<user name>\Desktop

빠른실행(QuickLaunch) 폴더

• Windows XP : C:\Documents and Settings<user name>\Application Data\Microsoft\Internet Explorer\Quick Launch
• Windows 7 / 8 / 10 / 11 : C:\Users<user name>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch

참고로 빠른실행 및 시작프로그램이 무엇인지 모르면? 아래링크를 읽어보세용

https://blog.naver.com/PostView.nhn?blogId=taeil34&logNo=221345931016

실습

LEcmd을 통해서 recent의 hmtl 분석파일을 만들었다.

아래 사진은 lnk의 html이다.

추가적인 분석

usb을 통해서 불법적인 avi 파일을 유통하는 것을 잡을 때 사용될 수 있다. 아래 링크 참고

http://forensic-proof.com/archives/607

실습

ntfs tracker 통해서 분석한 것이다.

악성코드를 분석할 때, suspcious behavior을 통해서 시간을 확인하고 시간 관계를 통해서 파일을 흐름을 분석했다.

추가적인 분석을 위해서 db을 추출한뒤, sqlite을 통해서 분석하였다.

NTFS의 구조는 MBR(gpt)-VBR-MFT-file 순으로 되어있다, 여기서 MFT는 MFT ENTRY로 이루어져 있다. MFT ENTRY중 하나가 $MFT이다. $MFT는 MFT의 정보를 가지고 있다. 즉 파일들의 정보를 가지고 있다. 참고로 파일 하나당 MFT ENRTY가 하나이상 만들어진다.

추가적으로 MFT ENTRY는 HEAEDER - fixuparrary- 속성 헤더(헤더가 두개로 나뉨) - 속성 정보 - endmarker - 사용하지 않는 공간으로 되어있다.

실습

$MFT는 ftk imager로 열면 root아래에 존재한다. 이를 MFTExplorer로 분석해보았다.

알수 있는 정보: 속성 헤더 관련된 정보, 파일 구조, 파일 종류, 파일 시간 등

다운로드 경로: https://ericzimmerman.github.io/#!index.md

레지스터는 운영체제와 응용프로그램 운영에 필요한 정보를 저장한 계층형 데이터베이스이다.

• 시스템 정보(systeminfo)
• 오토런(autorun)
• 로그인 시간정보
• 환경변수 설정정보
• 응용프로그램
• 저장, 열기 기능을 사용한 프로그램
• 저장 열기된 프로그램
• usb 흔적
• 마운트 된 기기들
• shellbags(사용자가 접근한 폴더 정보)

위와 같은 다양한 정보를 얻을 수 있다. 이에 대해서 추가적인 정보는 다음 아래의 사이트에서 확인할 수 있다.

http://www.forensic-artifact.com/registry-forensics/main

실습1(rega)

레가 다운로드: http://forensic.korea.ac.kr/tools.html

위에 링크를 읽어보면 알수 있다. 루트 키는 하이브 파일, 혹은 메모리에 휘발성으로 저장된다. 이중 하이브파일을 분석하여 위에서 언급한 다양한 정보를 파악할 수 있다.

아래는 레가를 통해서 수집한 하이브이다.

아래와 같은 정보를 확인할 수 있다.

REGA의 장점

1. 보기 좋은 UI

REGA의 문제점

1. log 파일들을 완벽히 구해내지 못한다. 하이브는 로그파일을 만든다. 거기에 존재하는 정보를 놓칠 수 있다.
2. 또한 지원하지 않는 기능이 존재한다.

실습2

rla 다운로드 : https://ericzimmerman.github.io/#!index.md

ftk imager 통해서 필요한 파일들을 추출했다 sam, security, system과 같은 파일들은 windows/system32/config에 존재하였고 ntuser의 경우 user/사용자/ 에 존재하였다.

보면 알다싶이 하이브이외의 로그파일에도 산발적으로 분포한 기록을 rla을 통해서 통합해준다

이후 regripper을 통해서 하이브를 분석합니다.

kisa에서 발표한 침해사고대응을 기준으로 보면 절차는 간략하게 다음과 같다.

기초 정보 수집 -> 프로세스 정보 분석 -> 네트워크 정보 분석 -> 레지스트리 분석 -> 로그 기록확인 -> rootkit 분석 -> 원인 분석을 위해 악성코드 동작 분석을 통해 원래 상태 복구 필요한 도구 설명

kisa의 경우 os에서 자체적으로 주는 기능 혹은 sysinternal을 사용하였다. 하지만 덤프를 통한 백업 혹은 로그들이 삭제되어 있을 경우 이를 복구하는 방식은 가르쳐주지 않았다.

그럼에도 좋은 내용이니 확인 해보실 바람 . : https://www.kisa.or.kr/2060204/form?postSeq=11&page=1

디스크 메모리(백업 및 분석의 목적)

초기분석의 목적은 사고 인지 시점에서 피해시스템의 상태를 변경시키지 않고 원인 규명에 필요한 모든 침입 흔적을 찾아보는 것이다.

우선 침해사고가 발생한 시스템의 디스크 이미지를 복사할 수 있는 프로 그램을 활용하여 디스크 이미지를 생성한다.

• 사용하는 툴 dd, ftk imager
• dd의 경우 비트바이 비트로 하드디스크를 복사할 수 있기 때문에 숨겨진 파일등 다양한 파일들을 복사할 수 있다. 또한 삭제할 수 없는 파일또한 삭제할 수 있다.
• 참고로 DD 사용전 포렌식에서 주용한 무결성 보호를 위해서 레지스터를 편집하여 보호한다.

휘발성 메모리

fmem, lieme 등의 프로그램을 사용하여 덤프한다. 휘발성 메모리에는 다양한 정보들이 들어있기에 추후 침해대응에 많은 도움을 준다.

시스템 기본 정보 수집

• psinfo 시스템 기본정보를 보여준는 프로글매이다. (-h: 설치된 핫픽스 정보, -s 설치된 S/W 목록정보, -d 디스크 볼륨정보)

• 핫픽스(hotfix 또는 quick-fix engineering update) 또는 QFE 업데이트(QFE update)는 제품 사용 중에 발생하는 버그의 수정이나 취약점 보완, 또는 성능 향상을 위해 긴급히 배포되는 패치 프로그램을 말한다

• date 분석 당시 시스템 날짜오 시간을 기록한다.(윈도우 내부 명령)

• uptime 프로그램의 부팅시간정보 확인 (/s 시스템 로그를 분석하여 재부팅 횟수, 블루스크린 횟수등의 통계정보를 보여줌)

네트워크 정보 수집

• ipconfig(윈도우 내부 명령어) : 시스템에 구성된 전체 IP주소, 서브넷 마스크, 기본게이트웨이를 확인하고 추가적으로 IP Routing 옵션이 enable로 되어 있는지, 새로운 IP주소가 추가되어 있는지, 초기 설정에 변경된 사항이 있는지 점검한다. (/all:시스템에 설치된 모든 네트워크 인터페이스정보 출력해준다)
• net sess(윈도우 내부 명령어) :로컬 컴퓨터의 공유자원에 접속한 클라이언트의 세 션 정보를 수집한다. 현재 공유자원에 접속한 컴퓨터이름, 사용자이름, 클라이언트 유형, 접속 수, 접속 유지 시간 등을 알 수 있다.
• nbtstat -c(윈도우 내부 명령어): TCP/IP의 NetBIOS 이름 테이블 정보를 수집 한다.
• arp -a(윈도우 내부 명령어): IP주소와 매칭되는 네트워크 인터페이스 하드웨어 주소 정보를 수집한다.
• route(윈도우 내부 명령어) : 로컬 컴퓨터에 설정된 라우팅 테이블 정보를 보여 준다
• net share(윈도우 내부 명령어) : 로컬 컴퓨터의 모든 네트워크 공유자원에 대한 정보를 보여준다
• netstat -na(윈도우 내부 명령어) : 로컬 컴퓨터의 TCP/IP 연결 상태와 프로토콜 통계 정보를 보여준다. 로컬 컴퓨터에 현재 활성화된 네트워크 연결정보 및 연결을 막 끝낸정보, 사용되는 포트 정보를 수집한다.
• tcpview : 로컬 컴퓨터의 TCP/IP 연결 상태와 해당 프로세 스명을 실시간으로 보여준다

  포트별 서비스 정보 수집

• fport 어떠한 응용 프로그램이 어떤 포트를 사용하는지에 대한 정보를 보여준다. /p :포트별 정렬 /a :응용프로그램 이름순 정렬 /I :프로세스 ID 정렬 /ap :응용 프로그램 디렉토리 순 정렬

아래는 포트확인 사이트이다. http://www.iana.org/assignments/port-numbers http://www.portsdb.org http://www.insecure.org/nmap/ http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/ resources/proddesc/superscan.htm

스니퍼 실행 확인

• promiscdetect:네트워크 인터페이스 카드의 promiscuous 모드 동작 유무를 알려준다.

사용자/그룹 정보 수집

• net user(윈도우 내부 명령어) 로컬 컴퓨터의 사용자 정보를 보여준다.
• net localgroup(윈도우 내부 명령어) 로컬 컴퓨터의 그룹 정보를 보여준다.

로그인 정보 수집

• psloggedon 로컬 컴퓨터 및 원격 컴퓨터의 로그인 정보 점검 도구이다.
• net 동작중인 서비싀 목록을 보여준다.

레지스터리 분석

• 대부분의 악성 프로그램은 시스템이 재부팅 되더라도 다시 실행될 수 있 도록 설정된다.
• 윈도우 시작 프로그램에 등록된 프로그램을 점검한다.
• 윈도우 설정파일 win.ini, system.ini 파일에 등록되어 있는 프로그램 을 점검한다.
• 레지스트리에 등록되어 있는 프로그램을 점검한다

  로그 기록 분석

• 로그 기록을 분석한다
• 만약 로그 기록이 없을 경우 해커가 삭제한 것이다.

1 .볼라틸리티 워크벤치 다운로드

아래의 링크를 가면 다운로드 할 수 있다.

링크: https://www.osforensics.com/tools/volatility-workbench.html 다운로드 링크 : https://www.osforensics.com/downloads/VolatilityWorkbench.zip

2 . Cridex 분석

pstree를 보고 아래와 같은 이상 파일이 있음을 확인했다. 이전에 쓴 글을 참고하여 분석해보았다.

3. 워크 벤치 단점

일단 txt파일로 로그를 저장하는데 내용만 저장할 수 없다. 또한 GUI상태로 보기는 불편하다. GUI이기 때문에 속도가 느리다는 단점이 있다.

메모리 분석시 사용한 도구는 volatility 이다

기본적인 명령 구조는 vol~ -f 파일명 명령이다.

1. volatility 사용법

운영체제 식별

• imageinfo : 메모리덤프의 운영체제 식별
• * volatility -f <이미지 파일> _imageinfo**

프로세스 검색

• pslist : 프로세스 리스트를 시간 순서대로 보여줌

• psscan : 프로세스 구조체 스캔 후 출력, 숨겨진 프로세스 출력 가능

• pstree : pid, ppid 기준으로 구조화하여 보여줌,

최초로 생성되는 프로세스를 제외하고, 모든 프로세스는 부모 프로세스를 복제해 생성되고 계 층관계 트리가 생긴다. 각각의 프로세스는 자식 프로세스와 부모 프로세스에 대한 정보를 가진다. PID(Process ID)는 운영체제에서 프로세스를 구분하기 위해 부여한 번호이다. PPID(Parent Process ID)는 해당 프로세스를 만든 부모 프로세스의 PID를 의미한다.

• psxview : pslist, psscan을 포함한 도구들의 결과를 한 눈에 볼 수 있음,

pslist는 true인데 psscan 은 false인 경우 숨겨진 프로세스라고 의심 가능하다.

Volatility -f <이미지파일> --profile

=Suggested Profile pslist / psscan / pstree / psxview > pslist / psscan / pstree / psxview.log

네트워크 분석

• connections : 현재 연결된 tcp 통신에 대한 정보

• connscan : 풀 태그 스캐닝 방식을 사용해 연결을 파악하고 종료된 연결까지 파악 가능

• netscan : 메모리의 네트워크 정보, 프로세스 정보 출력

• sockets : tcp, udp를 포함한 모든 프로토콜 출력, 현재 listening 상태에 있는 소켓 출력

_ volatility -f <이미지 파일> --profile=<프로파일 명> connections > connections.log_

volatility -f <이미지 파일> --profile=<프로파일 명> connscan

cmd분석

• cmdscan, consoles : 콘솔에 입력한 값들을 볼 수 있음. cmdscan은 cmd.exe가 실행한 명령을 나열하고 consoles는 명령이 성공했는지 안 했는지 알 수 있음

• cmdline : 프로세스가 실행될 때의 인자 값을 확인할 수 있음

volatility -f <이미지 파일> --profile=<프로파일 명> cmdscan > cmdscan.log

volatility -f <이미지 파일> --profile=<프로파일 명> consoles > consoles.log

_ volatility -f <이미지 파일> --profile=<프로파일 명> cmdline > cmdlines.log_

파일 분석 및 덤프

• filescan : 메모리 내에 존재하는 모든 파일들의 리스트 출력

• dumpfiles : 파일을 덤프, 옵션으로 메모리 주소, 프로세스 줄 수 있음

• virtustotal 사이트는 바이러스 검사를 할 수 있는 사이트이다.

__ volatility -f <이미지 파일> --profile=<프로파일 명> filescan > filescan.log __

volatility -f <이미지 파일> --profile=<프로파일 명> dumpfiles -Q <메모리주소> -D <저장 할 디렉토리>

프로세스 세부 분석

• procdump : 프로세스의 실행 파일을 추출

volatility -f <이미지 파일> --profile=<프로파일 명> memdump -p pid -D <저장할 디렉토리> __ __volatility -f <이미지 파일> --profile=<프로파일 명> procdump -p pid -D <저장할 디렉토리>

2. 분석 시작

1. 이미지 정보 분석

2. 필요한 파일을 정보 추출

3. 악성코드 판별

explorer.exe가 바이러스입니까? 전혀 그렇지 않다. 진정한 explorer.exe 파일은 "Windows 탐색기"라고하는 안전한 Microsoft Windows 시스템 프로세스입니다. 그러나 바이러스, 웜 및 트로이 목마와 같은 맬웨어 프로그램 작성자는 프로세스에서 탐지를 피하기 위해 동일한 파일 이름을 사용합니다

Reader_sl.exe는 PDF로 작성, 보기, 수정 및 인쇄하기 위해 Adobe에서 만든 소프트웨어 및 웹 서비스 인 Adobe Acrobat에 속한 실행 파일입니다. 위 사진을 보면 알 수 있다 싶이 숨겨진 파일은 없다 cmdline을 살펴보면 경로도 살펴보았다. 두 파일 모두 원래 있어야 하는 경로에 있다. 무슨뜻이냐면, explorer.exe는 이는 windows 경로 밑에 있어야 한다.

하지만 위 두파일이 가장 의심되는 파일이기 때문에 procdump 및 dumpfile을 통해서 파일을 추출하고 바이러스토탈에 돌려보았다. 결과는 아래와 같다.

악성코드로 의심할 수 있는 수준이다.

4. 악성코드 작동 방식

connections의 결과이다. pid 1484 즉 explorer.exe는 41.168.5.140을 통해서 통신을 하고 있다. 더 세부적인 분석을 하기 위해서 memdump을 통해서 string 분석을 할 것이다.

4-1 explorer.exe memdump 결과

위와 같은 41.168.5.140:8080/zb/v_01_a/in/ 과 같은 웹사이트 주소를 발견했다. 아마도 웹 사이트를 통해서 explorer.exe는 통신하는 것이 아닐까 싶다. 이후 다양한 은행 관련 주소를 찾았다. 아마도 은행 관련 피싱 악성코드로 의심된다. 어도비 관련된 api을 찾았다. 이는 브라우저에 추가 기능 해주는 것이다. 메일 관련된 다양한 함수를 찾았다. 아마도 감염된 컴퓨터를 통해서 추가적인 악성코드를 퍼트릴려고 하는 것 갔다.

4-2 reader_sl

41.168.5.140과 통신하는지 확인하고 연결되어 있다면 프로그램이 작동하는 것 갔다. 메일을 보내는 함수를 찾은 것 갔다.

3. 결론

악성코드가 어떤것인지 의심되는 부분을 추출을 성공했지만, 구체적으로 어떤방식으로 악성코드가 작동되는지 파악하는 것에는 한계점이 있다. 그렇기에 악성코드를 추출하고 정적 동적 분석을 실해야한다.

추가적으로 악성코드가 이메일을 통해서 침투되었다고 의심은 할 수 있지만 실질적으로 어떻게 침투되었는지는 메모리 포렌식만을 통해서 알아내기는 힘들 것 같다.

이러한 침해사고대응을 잘 대응하기 위해서는 포렌식 기술 뿐만아니라 다양한 정보보안 지식이 있어야 할 것 같다.

아래 이름이 영역이 특히하게 변경되었다. 하지만 데이터 부분은 그대로 존재하는 것을 확인할 수 있다.

위 사진은 VBR에서 중점적인 부트섹터 구조이다

MFT ENTRY 0번부터 16번

MFT ENTRY 헤더

MFT ENTRY 속성 공통 헤더

resident 헤더

Non-resident 헤더

stand-info 구조

Name

Data

이러한 NTFS는 아래와 같은 특징이 있다.

NTFS 특징

1) USN 저널 (Update Sequence Number Journal 또는 Change Journal)

2) ADS (Alternate Data Stream)

3) Sparse 특징

4) 파일 압축

5) VSS (Volume Shadow Copy Service)

6) EFS (Encrypting File System)

EFS는 NTFS 상에서 파일 및 디렉터리를 암호화 하는 기능으로 CryptoAPI와 EFS File System Run-Time Library(ESRTL)를 사용한 대칭키 방식으로 암호화 한다. 앞선 그림에서와 같이 각 파일 및 디렉터리의 고급 항목을 통해 암호화를 사용할 수 있다.

7) Quotas

Windows 서버형 제품군은 다중사용자를 위한 시스템이다. 다중 사용자를 지원할 경우 각 사용자의 디스크 사용량을 제한하기 위해 쿼터(Quotas) 기능을 사용한다. 만약, 쿼터 기능이 설정된 시스템에서 자신에게 할당된 공간 이상으로 사용하고자 할 경우 경고메시지를 받게 된다.

8) 유니코드 지원

NTFS는 파일, 디렉터리, 볼륨 등의 이름을 지정할 때 모두 유니코드를 사용해 처리한다.

9) 동적 배드 클러스터 재할당

배드 섹터가 발생한 클러스터는 사용할 수 없다. 배드 섹터가 발생한 클러스터는 $BadClus 파일에 추가되어 더이상 사용되지 않도록 관리된다.

이러한 특징은 추후 MFT의 속성에 나타난다.

NTFS 구조

• mft는 mft entry로 이루어짐
• mft는 고정적인게 아님
• mft는 물리적으로 연결 x
• vbr뒤에 mft가 바로 나오지 않음

MFT 영역의 마지막이 점선으로 표시된 점은 MFT 영역의 크기는 미리 예측할 수 없기 때문에 항상 고정적으로 VBR 다음에 오는 것이 아니라 볼륨에 파일 및 디렉터리가 많아 질수록 데이터 영역에 조각나 저장될 수 있다. 따라서 초기 포맷 시에는 일정 영역만 MFT를 위한 영역으로 할당된다. 추가적으로 VBR 뒤에 물리적으로 MFT가 붙어나오는 것은 아니다.

VBR

VBR(Volume Boot Record)는 NTFS 구조에서 가장 앞부분에 위치하는 영역이다. VBR의 크기는 고정된 크기를 가지지 않고 다음과 같이 클러스터 크기에 의존한다.

부트섹터

VBR의 첫 번째 섹터는 부트 코드를 포함한 부트 섹터가 위치한다. 나머지 섹터들은 추가적인 부트 코드를 저장하기 위한 용도로 사용되거나 NTLDR(NT Loader)을 빠르게 로드하기 위해 NTLDR의 위치를 저장하기 위한 용도로 사용된다.

MBR에서 부팅 가능한 파티션(볼륨)을 찾으면 해당 볼륨의 첫 섹터(부트섹터)를 메모리에 로드한 후 실행한다. 위 부트섹터 그림에서 첫 3바이트는 “EB 52 90″으로 되어 있는데 이 내용을 해석하면 다음과 같다.

• EB 52 90 : JMP 52h + NOP (즉, 54h로 점프하여 BPB 이후의 부트 코드가 실행)

이후 BPB 항목을 참조하여 해당 볼륨의 운영체제를 로드하는 부트 코드가 실행된다.

부팅과정

위 과정을 더욱이 잘 알기위해서 기본적인 부팅과정을 알아 보겠다.

• cpu에 전원이 들어옴 -> ROM BIOS 부트프로그램 POST 수행 -> 부트 프로그램은 운영체제를 로드하기 위해 MBR이동 -> 부팅가능한 파티션 찾음 -> VBR로 이동 -> NTLDR이 추가적인 정보 로드 -> 윈도우 실행

자세한 내용 참고 : http://forensic-proof.com/archives/178

MFT 상세

$MFT 파일이 존재한다. 이는 MFT가 MFT ENTRY로 이루어져있고, MFT 엔트리는 디렉토리 및 파일 당 하나 이상 만들어진다. 이렇게 만들어진 MFT ENTRY는 파일의 메타정보를 가진다. 이러한 영역을 파일로 만든 것이 $MFT이다.

참고적으로 MFT 영역의 16개 엔트리는 파일시스템 자체의 메타 역할 및 추가적인 특성을 지원하기 위해 파일시스템 포맷시 미리 할당된다.

MFT 엔트리 구조

여기서 속성(Attr)은 상당히 중요하다. 일반적인 파일의 경우에는 위의 많은 속성 중 아래 그림과 같이 $STANDARD_INFORMATION, $FILE_NAME, $DATA 속성만 온다.

속성들은 크게 Resident 속성과 Non-resident 속성으로 나뉜다.

Resident 속성은 속성의 내용이 속성 헤더 바로 뒤에 위치하는 속성이다. 이에 반해, Non-resident 속성은 속성 내용이 너무 커서 MFT 엔트리 (1,024 바이트) 내부에 넣지 못할 경우, 별도의 클러스터를 할당 받아 저장하는 방식이다. 이때, 속성 내용 위치에는 할당 받은 클러스터의 위치 정보가 저장되어 있다

$DATA 속성은 700 byte 이상일 경우 Non-resident가 된다.

클러스트 런

클러스터 런은 Non-resident의 속성 내용의 위치를 표시해준다.

상세한 내용은 http://forensic-proof.com/archives/590 확인하길 바란다.

속성 헤더

속성의 헤더는 공통된 헤더 뒤에, Resident 혹은 Non-Resident에 따라 헤더가 달라진다.

속성 내용

속성은 16가지가 존재하며, 속성에 따라 분석하는 방식이 다르다. 기본적으로 $name, $stand_info, $DATA 가 기초적임으로 이 3가지를 중점적으로 알아보길 바란다.

esp 트릭을 통해서, oep를 구한 뒤, 복구시킨다. 아래사진은 언패킹된 파일이다.

2. 문제 풀이

아래 와 같은 부분이 바로 인증 루틴의 분기점이다. 이를 찾는방법은 스택을 통해서이다.

1. registration 부분을 들어간 뒤, 멈춘다.

2. 이후 사용자코드까지 실행을 시킨다.

3. 코드의 시작부분(push ebp, mov ebp, esp)을 찾는다.

4. 시작부분에 브레이크 포인트를 걸고 거슬러 올라가면서 분기점들을 모두 확인하면 도달할 수 있다.

5. 만약 지속적으로 반복하는 루틴안에 있다면 이를 빠져나와야 한다.

6. 데비안 특성을 이용한 다른 방식

2.풀이

실패한 정보를 기반으로 string 서치로 분기문을 찾았다. 그 위에 call함수가 있고 test al, al이 있는 것으로 보아서 call 함수는 아이디와 비밀번호를 확인하는 함수이다.

위 사진 처럼 들어가보니 mov eax, ebx가 있는 것을 확인할 수 있고, 이를 아래 사진처럼 변경하면 된다. 하지만, 아르마딜로로 패킹되어 있기 때문에 그대로 패치하면 파일이 작동하지 않는다. 물론 oep를 찾고 iat를 만드로 pe를 재빌딩해도 되지만, 실시간 패치 방법을 사용했다. 아래 사진은 rpp이다

3. 결과 값

0. 아르마딜로 패킹 안티리버싱

일단 아르마딜로는 여러가지 패킹하는 방식이 있지만 OutputStringA라는 함수의 오버플로우를 이용하여 올리디버거가 멈추게하는 방식이였다. 웃프게도 내가 사용한 디버거는 x64dbg이고, OutputStringA의 취약점은 없었기에 그냥 실행되었다... 하지만 프로그램 자체 오류상 디버깅을 하지못하였다..

1. 패킹된 비주얼베이직 OEP 찾는법.

TEXT 구간에 VB5!를 작성한다. 즉 심볼을 작성한다. 심볼을 작성한 주소를 찾는다. 심볼을 작성하기 위해서 작성할 주소를 스택에 올려야한다. 그렇기에 401000(베이스포인트:40000, text RVA : 1000)로 이동한다. 그 다음, text영역에서 push 'VB5! 주소'를 검색하여 찾는다. 그 부분이 OEP이다.

이는 패킹된 파일이 비주얼 베이직이기 때문에 찾을 수 있다. 그렇다면 어떻게 비주얼 베이직 언어로 만들어는지 알수 있냐가 관건이다. 이는 dll를 보면 알 수 있다.

2. 실시간 패치

Crack me를 대신 실습 파일로 설정하였다. jne 때문에 파일이 실행이 안되어 아래 사진처럼 파일을 jmp로 변경하였다. 아래는 R!SC.P.P.exe에 사용하는 파일이다. T는 타임이다. 5초 뒤에 파일이 실행되고 패치된다는 것이다. F의 경우 실행되는 파일이다. o의 경우 생성되는 파일이다. P는 패치이다. P의 구조는 패치주소/원래 형태/ 패치 형태이다.

reversMe_crack.exe의 파일 실행원리는 다음과 같다. 1.CreatProcessA -> 프로세스 실행 2.ReadProcessMemory, writeProcessMemory -> 프로세스 패치 3. 끝

3. 실시간 패치 사용되는 곳

패킹되어 있는곳에 바로 패치를 실행하면 파일이 실행되지 않는다. 또한, OEP를 찾고, IAT를 찾는게 힘들 경우 실시간 패치를 진행하면 된다.

게임핵을 만들때 많이 사용된다고 한다...

패킹이 되었는데 어떠한 정보인지 모른다면 pestdio peid 바이러스토탈

등 다양한 프로그램에 올려보는 것이 중요하다.

풀이

언패킹을 해야되서 보면, push ad가 있을 것을 알수 있음으로 upx와 같이 스택에 브레이크 포인트를 걸어서 oep를 찾는다 아래 코드는 진행되는 코드다 nop과 jmp문을 합쳐서 코드가 어떻게 진행되는지 어렵게 만든다. 이를 빈 공간에 패치를 통해서 해결하면된다.

아래는 패치한 코드이다.

iat 찾는법

오토 서치 기능이 scylla 있긴하지만, 완벽하지는 않다 그렇기에 수동으로 입력해야된다. 일단 iat를 찾아야 한다. 현재 구역에서 바이너리 찾기를 통해서(shift + ctrl + b)를 통해서 FF 25를 친다. FF 25는 포인터 점프이다. 이를 검색하면 아래와 같이 난온다. 이후에 위에 빨간색 줄쳐진 부분을 통해서 iat 위치의 시작점을 찾는다. 그후에 iat의 끝은 dll 이름이 나오는 곳이다.

궁금한점

1. FF 25의 검색을 통해서 찾은 구역은 무슨 구역인지
2. iat의 끝은 왜 dll 이름이 나오는 구역인지
3. dll 이름이 왜 하나만 있는지

파일을 언패킹한 뒤에 보면, iat를 인식하지 못하고 있다. 물론 iat를 구할때, va나 size를 잘못 줘서 발생할 수 도 있는 문제이다. 참고로 rav는 iat 주소 값이고, ptr은 438040 안에 있는 값이다. 위 사진 처럼 invalid 된 iat를 열어보면, 안에 kernel32.dll에 있는 findclose함수를 불로오는 걸 알 수 있다. 또한 findclose함수 이외에 어떠한 작동도 하지 않는 함수인것을 알 수 있다. 즉 redirection 함수임을 알 수 있다.

파일을 실행하면 뒤에처럼, 75D23840이라는 함수가 잘들어오는 것을 알수 있다. 분석해보면 다음과 같다. getprocAddress 함수라는 값은 함수의 주소값을 eax를 통해서 반환해준다. 그 후에 iat에 값을 넣는다. 그 후에 빨간 부분에서 함수에 값을 넣는것을 알 수 있다. 위사진은 iat의 구성이다. dll의 함수끼리 묶여있고 dll이 끝나면 8바이트의 00 00 00 00 나와서 구분해준다.

https://idlecomputer.tistory.com/180

DLL이란

Dynamic Link Library, 동적링크로 실행파일에서 해당 라이브러리 기능을 사용시에만 참조해 기능을 호출할 수 있는 방법이다. 여러 프로세스에서 공유하며 쓰는 라이브러리로 멀티태스킹 환경에서 각 프로세스마다 라이브러리를 갖고 그 용량을 차지하는 것보다 메모리에 한 번 로딩시켜 프로세스마다 공유시키면 메모리를 더 효율적을 사용할 수 있다.

실제 DLL 로딩 방식은 2가지 입니다.

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

라이브러리와 DLL의 차이점

라이브러리는 링크시 필요함 DLL는 프로그램 실행 혹은 함수 실행시 필요함

IAT가 존재하는 이유

호환성 때문이다.

가상메모리와 가상 공간 dll 방식

:https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=yheekeun&logNo=220709173937

INT를 IAT에 입력하는 이유

IID 에 INT에 있는 주소를 IAT에 옮기는 이유가 뭘까라는 의문이 든다 그냥 INT 주소를 옮기면 안되나 라는 생각이 든다. 하지만, DLL이 프로세스에 올라갈때, imagebase는 항상 고정이 아니다. INT 주소는 DLL 내부에 위치이다. IAT는 프로세스의 위치이다.

DLL import 작동 원리

1. 프로그램 내에 임포트 테이블 존재한다.
2. 임포트 테이블이란 DLL 헤더를 가지고 있으며, 각각에 필요한 함수가 있다.
3. 로더가 필요한 DLL을 로딩한다.
4. DLL에 IID라는 것이 존재한다. IID 내부에 INT와 IAT가 존재한다. INT에는 IMAGE_IMPORT_BY_NAME가 존재한다. IMAGE_IMPORT_BY_NAME에는 name과 hint가 존재한다. 이를 통해서 함수의 주소를 얻는다.
   • 추가적으로 IID-> OriginalFirstThunk를 사용안하고 함수의 주소를 찾기도 한다.
5. IAT 배열 값에 위에서 구한 함수 주소를 입력합니다. 주소가 들어가기 전에 배열에는 함수의 이름이 존재한다.
6. 이는 INT가 NULL만나기 전까지 반복한다.

문제풀이 FSG 2.0 UnPackMe

문제가 열리지 않는다... https://www.virustotal.com/gui/file/d5c694a33baf56816ff3907ac6e1ee56f5fb78f1c06ada04f3b6cb22c3893f21/details

바이러스 토탈을 돌리면 어떤 패커를 사용한지 알수 있다. 구글링을 통해서 FSG는 JMP 구문을 통해서 원본 코드로 갈수 있다 이를 이용하면 OEP를 찾을 수 있다.

문제풀이 UPX

UPX도 마찬가지로 바이러스 토탈에 올리면 어떠한 패커를 사용한지 알수 있고, 이를 기반으로 구글링을 통해서 언패킹 정보를 얻어서 언패킹하면된다. PUSHAD -> popAD -> OEP 진입한다는 루틴을 이용하면 된다고 한다.

UPX의 특징을 잘 이용하여 OEP로 진입한다. IAT가 문제가 생겨서 트리를 삭제시켰다. 그 후에 삭제된 IAT를 제외하고 나머에 맞게 VA와 SIZE 변경시키고 덤프를 뜬뒤, fix Dump를 하였다.

프로그램이 정상적으로 작동하였다. 하지만 왜 IAT한개 삭제되면 정상적으로 작동이 되지 않을 것 같은데 정상적으로 작동했는지는 의문이다.

문제풀이 UnPackMe_WinUpack0.39

winUpack의 특징도 UPX랑 같이 초반에 스택이 변경된 후 다시 그 위치로 스택이 다시 돌아올때가 OEP이다. 그 특징을 이용하면 언패킹이 가능하다.

EP : entry point OEP : origin entry point PEP : packed entryl point

언패킹은 OEP를 찾는 것이다.

scylla 사용 방법

1. 언패킹 후 덤프를 뜨는 것이 목적이라면 먼저 OEP 까지 진입하자.

2. 현재 EIP가 OEP에 위치한다면 플러그인 탭에서 Scylla를 선택한다.

3. 중간 왼쪽 부분을 보면 현재 EIP 주소에 맞게 OEP가 자동으로 설정되어 있을테니 굳이 추가할 필요는 없고 바로 오른쪽을 보면 "IAT Autosearch"라는 버튼이 있다. 이것을 클릭한다. 클릭 후 두 개 정도의 확인 버튼이 팝업된다.

4. 다음으로는 바로 아래의 버튼인 "Get Imports" 버튼을 클릭한다.

5. 이후 오른쪽의 "Dump" 버튼을 클릭하면 덤프된 exe를 저장시킬 위치를 선택할 수 있다. 기본적으로 원본 exe 이름 뒤에 "_dump"라는 이름이 붙어서 저장되는 것을 볼 수 있을 것이다. 저장된 결과물은 간단하게 덤프한 것으로서 IAT가 복구되지 않아서 실행되지 않을 것이다.

6. 이제 바로 아래의 "Fix Dump" 버튼을 클릭한다. 그리고 방금 전 저장했던 덤프한 exe 파일을 불러온다. 그러면 또 다른 실행 파일이 생성되며 (이름 뒤에 "_SCY"가 붙는다) 최종 결과물로서 실행까지 되는 것을 확인할 수 있다.

OEP를 찾는법

1. 패커에 따라 언패킹하는 방식은 모두 다르다.

2. 하지만, 기본적으로 프로그램이 실행되기 위해서 상대 메모리 주소가 패킹 이전과 같아야 한다.

3. 코드 영역으로 들어가면 그 것이 OEP라고 의심할 수 있다.