Yum_Yum

Disk Forensic #30 (복구 된 키 이미지 파일의...)

해당 문제 파일을 다운 받아서 FTK Imager 도구를 통해 확인해보면 특이한 점은 존재하지 않는다.

FTK Imager : 포렌식의 가장 기본 도구로, 디스크 이미징 작업에 많이 활용

다운로드 사이트 : https://accessdata.com/product-download/ftk-imager-version-4-2-1

그래서 혹시나 삭제된 파티션이 존재하는지 확인을 위해 R-Studio 프로그램을 통해서 문제 이미지 파일을 열어 확인해 보자.

R-Studio : 하드디스크 파티션 파일 복구 프로그램

참조 사이트 : https://www.r-studio.com/

문제 파일을 열어 실행시킨 다음, 각 파티션 내용을 보면 Empty Space19에서 [마우스 우클릭] - [Scan] 기능을 사용하여 Recognized0과 Recognized1이 생성되는 것을 확인할 수 있다. (그림 1 참고)

FTK Imager로 확인했을 때는 다른 용량의 파티션이 있음을 알 수 있으므로 Recognized1이 50MB의 용량으로 의심스러운 점을 확인할 수 있다.

의도적으로 삭제된 파티션이 있을 거란 추측을 해볼 수 있으며, MBR을 분석해보자.

MBR영역은 부트 코드와 파티션 테이블, 시그니처(AA 55)로 나뉘게 된다.

문제에서 주어진 evidence.001 파일을 HxD로 열어보면 파티션 테이블 영역에 총 3개의 파티션 정보가 있음을 확인할 수 있다.

위 [그림 2]에서는 보이는 파티션 정보가 4개이지만 [그림 3]에서는 파티션 테이블에 파티션이 3개만 존재하는 것을 확인할 수 있다.

또한 한 개의 파티션 정보가 확장 파티션임을 확인할 수 있다. (타입 오프셋 : 0x05)

그리고 [그림 2]의 FTK Imager에서 마지막 파티션이 Recovered로 나오는 점으로 보아 파티션에 대한 오프셋 정보만 삭제 되어 자동으로 복구가 되어 보여주는 것 같다.

하지만 R-Studio를 통해 확인했던 50MB 파티션 정보는 아니므로 추가적 분석을 진행해야 한다.

50MB의 삭제된 파티션 정보를 찾기 위해서 NTFS VBR 시그니처 (EB 52 90 4E 54 46 53)로 검색하여 분석해보면 다음과 같이 파티션 테이블에 있는 3개의 파티션 외에 112896 섹터에 파티션이 있음을 확인할 수 있다.

이렇게 해서 파티션 테이블에서 112896 섹터에 해당하는 파티션 정보를 의도적으로 삭제했음을 알 수 있다.

해당 파티션 정보를 파티션 테이블에 입력한 다음, 복구를 통해 문제를 해결할 수 있을 것 같다.

복구하기 이전 MBR 파티션 테이블 오프셋 구조와 NTFS BR 오프셋 구조를 파악해야 한다.

※ 파티션 테이블 오프셋 구조

0-0 : Boot Flag로 0x00은 부팅 불가능, 0x80은 부팅 가능 의미

1-3 : CHS(Cylinder, Head, Sector) 주소 지정 방식 (시작 위치 정보)

4-4 : 해당 파티션 파일 시스템 타입 (0x07은 NTFS, 0x0B는 FAT32를 의미)

5-7 : CHS 주소 지정 방식 (끝 위치 정보)

8-11 : LBA 주소 지정 방식 (파티션 시작 위치)

12-15 : 해당 파티션 총 섹터 개수

현재의 하드디스크는 LBA 주소 지정 방식을 취하고 있으므로 CHS 주소 지정 방식 내용을 제외하고는 복구를 진행할 수 있다.

112896 섹터의 VBR 정보를 분석하여 파일 시스템 타입은 NTFS(0x07)임을 확인할 수 있으며, 8-11 오프셋에 해당하는 LBA 주소 지정 방식 파티션 시작 위치는 112896 섹터임을 알 수 잇다.

112896 섹터를 파티션 테이블에 입력할 때는 16진수로 변환한 다음, 리틀 엔디안 방식으로 입력해야 한다.

112896은 16진수로 0x1B900이다.

따라서 12-15 오프셋에 해당하는 파티션의 총 섹터 개수는 NTFS BR 오프셋 구조를 통해 확인할 수 있다.

오프셋 구조 중에서 Total Sector 영역이 파티션 상의 총 섹터 개수를 의미한다.

NTFS는 파티션 정보의 마지막 섹터에 BR 백업본이 존재한다.

BR 백업본 섹터까지 포함하여 Total Sector + 1값을 파티션 테이블 12-15 오프셋에 입력한다.

위 [그림 6]에서 표시한 부분이 112896 섹터 NTFS BR의 Total Sector 영역이다.

Total Sector는 0x18FFF이며 +1을 해주게 되면 0x19000이다.

지금까지 파티션 테이블에 입력할 정보를 리틀 엔디안 방식으로 정리하면 다음과 같다.

문제 파일을 HxD로 열어 위 표의 내용을 4번째 파티션 테이블 정보에 입력해보자.

위 [그림 7]과 같이 수정한 다음 FTK Imager로 문제 파일을 다시 열어보면 Partition 4가 새로 생성된 것을 확인할 수 있다.

파티션 4에는 NTFS 볼륨이 있으며, 하위 root 폴더에는 문제와 관련 있어 보이는 JPG 파일이 존재한다.

이제 FTK Imager에서 [마우스 우클릭] - [Export Files...] 메뉴를 통해 해당 파일 을 추출하여 내용을 확인해보자.

내용을 확인해보면 문제에서 언급한 KEY 이미지를 확인할 수 있다.

이제 해당 파일의 MD5 Hash 값을 계산하여 플래그로 입력해주면 된다.

MD5 Hash 값 계산을 위해 HashCalc라는 도구를 이용하여 계산해보자.

HashCalc : 다양한 해시값 추출 프로그램으로, 파일 무결성 검사 도구

설치 사이트 : https://www.slavasoft.com/hashcalc/

HashCalc를 통해 해당 파일에 대한 MD5 Hash 값을 얻을 수 있으며, 플래그로 입력해주면 된다.

해당 문제는 다른 방법으로 $MFT 구조를 분석하여 $DATA 영역에서 실제 파일이 저장된 주소를 얻어 수동으로 파일을 카빙하여 답을 얻을 수도 있다.

이렇게 해서 위 과정을 통해 문제를 해결할 수 있다.

# Reference

http://www.yes24.com/Product/Goods/59156934

Multimedia Forensic #82 (SECCON WARS)

문제 파일로 텍스트 파일이 주어지고, 확인해보면 유튜브 동영상과 관련된 URL이 적혀 있다.

주어진 URL을 통해 접속해보면 SECCON WARS 2015 동영상을 볼 수 있다.

음악은 마치 스타워즈 BGM과 비슷한 음악이며, 영상을 보다보면 위와 같이 중앙에 QR코드 같은 것이 보인다.

이것으로 영상에 비춰지는 QR코드를 복구하는 게 이번 문제의 핵심 요소라는 것을 추측해볼 수 있다.

QR코드는 노란 글씨가 하단에서 상단으로 올라갈 때, 그 고유 영역은 계속해서 검은색으로 유지되기 때문에 여러 프레임을 겹쳐서 보면 정확한 QR코드를 확인할 수 있을 것이다.

먼저 QR코드 확인을 위해 유튜브 동영상을 저장해야 한다.

저장을 위한 도구로는 YouTube Downloader HD 프로그램이나 다른 도구들도 있지만, 필자는 1gram Player 도구를 사용해서 동영상을 저장하였다.

1gram Player : 유튜브에 있는 동영상을 저장하거나 mp3 파일로 추출하기 위해 사용하는 프로그램

참고 사이트 : https://1gram.net/ 

동영상을 저장하면 윈도우 / 리눅스 환경에서 ffmpeg 프로그램을 사용해서 한 프레임마다 그림 파일로 저장한다.

이때, 한 프레임 당 한 그림 파일이 생성되므로 새로운 폴더를 만든 후에 해당 폴더에서 작업하는 것이 매우 효율적이다.

ffmpeg : 디지털 음성 스트림과 영상 스트림에 대해서 다양한 종류의 형태를 기록하고 변환하는 컴퓨터 프로그램

참조 사이트 : https://www.ffmpeg.org/

다음 명령어와 옵션을 통해 동영상에 대한 프레임을 추출해낼 수 있다.

위와 같이 명령어를 입력한 다음, 결과를 확인해보면 무려 2000개가 넘는 그림 파일이 생성된다.

생성된 그림 파일을 확인해보면 700 프레임부터 QR 코드의 전체적인 윤곽이 잡힌다.

700 프레임부터 QR코드의 윤곽이 희미해지는 시점인 마지막 프레임까지 따로 구분을 지어 파일을 합친다.

우선, 700 프레임부터 마지막 프레임까지 옮겨질 임의의 폴더를 생성한다.

폴더를 생성했으면 700 프레임부터 마지막 프레임까지 생성한 폴더로 이동시킬 for문을 작성한다.

파일이 옮겨졌으면 폴더로 들어가서 imagemagick 프로그램의 convert 명령어로 파일을 합친다.

imagemagick : 그래픽 이미지를 새로 만들거나, 고치는 데 사용되는 자유-오픈 소스 소프트웨어

참조 사이트 : https://imagemagick.org/index.php 

결과를 확인해보면 출력된 그림 파일을 통해 뚜렷한 QR코드를 확인할 수 있다.

이제 QR코드 스캐너로 QR코드를 디코딩하면 된다.

QR코드를 디코딩하면 위와 같이 플래그 확인이 가능하다.

※ 주의사항 : 복구한 JPG 파일을 QR코드 스캐너 웹사이트에서는 스캔이 제대로 진행되지 않아,  스마트폰 QR코드 스캐너로 계속 시도하다가 겨우 완료하였다... 그러므로 꼭 스마트폰 QR코드 스캐너를 사용하길 바란다..

이렇게 해서 위와 같은 과정으로 해당 문제를 해결할 수 있다.

문제 해결~~

# Reference

http://www.yes24.com/Product/Goods/59156934

Disk Forensic #17 (이 편리한 안드로이드...)

이번 문제는 apk 확장자가 처음으로 나오는 문제이다.

해당 문제는 안드로이드 apk에 대한 문제로, apk 파일 분석을 위해 apktool로 분석해야 한다.

apktool : apk 파일을 디코딩해주는 도구

다운로드 참조 사이트 : https://ibotpeaches.github.io/Apktool/install/ 

먼저 apktool을 이용하여 주어진 husavik.apk 파일을 디컴파일 해보자.

참고로 디컴파일 옵션은 'd'이다.

명령을 수행하면 husavik 폴더가 생성되며, 디컴파일 내용을 확인 가능하다.

여러 파일들 중에서 AndroidManifest.xml이라는 파일을 통해 패키지 흔적을 확인할 수 있다.

AndroidManifest.xml은 어플리케이션 권한과 같은 필수 정보에 대한 설정 파일이다.

해당 xml 내용을 보면 tf.icec.husavik이라는 패키지 내용을 확인할 수 있다.

상세 분석을 위해 jadx-gui 도구로 패키지에 대한 자바 코드를 분석해보자.

jadx-gui : 안드로이드 apk 파일을 디컴파일하고, 자바 코드 뷰어 기능을 제공하는 도구

다운로드 사이트 : https://bintray.com/skylot/jadx/unstable/v1.1.0-b1266-a5ea560e#files

[그림 4]는 jadx-gui 도구로 해당 패키지 내용을 확인한 결과이다.

그리고 내용에는 Base64로 인코딩 된 문자열을 확인 가능하다.

플래그 확인을 위해 Base64 디코딩 사이트로 이동하여 디코딩을 해보면 다음과 같은 결과를 얻을 수 있다.

Base64 디코딩 사이트 : https://www.base64decode.org/

자바 코드에서 찾은 문자열을 Base64 디코딩을 진행하면 해당 문제에 대한 플래그를 확인할 수 있다.

디코딩을 통해 나온 문자열을 플래그로 입력해주면 문제를 해결할 수 있다.

# Reference

http://www.yes24.com/Product/Goods/59156934

Disk Forensic #13 (조개를 찾아 열고, 진주를 찾으십시오.)

해당 문제 파일로 out.img 이미지 파일이 주어진다.

이미지 파일 분석을 위해 FTK Imager를 통해 해당 파일을 분석해보자.

FTK Imager : 포렌식의 가장 기본 도구로, 디스크 이미징 작업에 많이 활용

다운로드 사이트 : https://accessdata.com/product-download/ftk-imager-version-4-2-1

FTK Imager로 해당 이미지 파일을 열어보면 USB에 대한 이미지 파일이라는 것을 확인 가능하다.

여러 파일과 디렉토리를 분석하던 도중 밑에 [unallocated space]에서 수상한 파일을 발견하였다.

해당 파일의 사이즈가 매우 큰 것부터 이상하고, 헤더 시그니처는 ZIP 파일의 시그니처인 것을 확인하였다.

해당 파일을 추출한 다음, 확장자를 zip으로 바꾼 후에 압축을 풀어 상세 분석을 진행하였다.

파일의 압축을 풀어주면 여러 상위 디렉토리들과 파일들이 존재한다.

그 중에서 ppt 상위 디렉토리에 있는 media라는 하위 디렉토리로 들어가 보면 [그림 3]과 같이 수많은 그림 파일들이 존재한다.

맨 처음에 있는 image0.gif라는 파일이다.

뭔가 QRcode와 비슷하게 생겨서 해당 파일에 대한 정보를 구글링을 통해 검색해본 결과, MaxiCode라는 형태의 파일이라는 것을 확인하였다.

MaxiCode : 기계 판독 기호 시스템으로 육각형의 점이 배열된 형태

해당 파일이 디코딩할 수 있는 파일이라는 것을 확인하였으므로, MaxiCode를 디코딩할 수 있는 사이트로 이동하여 해당 파일을 디코딩해보자.

MaxiCode 디코딩 사이트 : https://zxing.org/w/decode.jspx

위 사이트에 접속해서 image0.gif 파일을 업로드한 다음, 결과를 확인해보면 [그림 4]와 같이 MaxiCode에 대한 여러 정보들을 확인할 수 있다.

마지막 Parsed Result를 플래그로 입력해주면 문제를 해결할 수 있다.

# Reference

http://www.yes24.com/Product/Goods/59156934

Disk Forensic #12 (우리는 이 바이너리가...)

해당 파일을 다운로드하면 파일에 대한 확장자 정보가 나오지 않는다.

따라서 리눅스 환경으로 옮긴 다음, file 명령어를 통해 해당 파일의 확장자를 확인하였다.

다운로드한 binned라는 파일은 리눅스 실행 파일이라는 것을 확인할 수 있다.

해당 파일에 대한 동작 원리와 시스템 콜을 파악하여 분석하기 위해 strace 명령어를 입력하여 확인해보자.

strace 명령어는 시스템 콜을 추적하여 동작 과정을 출력해주는 명령어이다.

명령을 수행하면 파일의 동작 순서에 따라 시스템 콜을 확인 가능하다.

[그림 3]은 중간에 있는 내용이고, [그림 4]는 끝 부분에 있는 시스템 콜 내용이다.

위의 두 문자열 증거를 통해 두 문자열 사이의 31번 시스템 콜이 문제 해결과 연관되어 있다는 것을 추측 해볼 수 있다.

31번의 시스템 콜 내용은 다음과 같다.

아스키코드 변환 방식은 스테가노그래피 유형에서 자주 사용되는 방식이다.

따라서 31번 시스템 콜을 순서대로 시스템 콜 테이블 사이트에서 확인한 뒤, 번호를 정리하여 아스키코드로 변환하였다.

시스템 콜 테이블 사이트 : https://elixir.bootlin.com/linux/v3.14/source/arch/x86/syscalls/syscall_64.tbl

위 사이트에 접속한 다음, 시스템 콜 문자열을 시스템 콜 번호대로 아스키코드로 변환하면 플래그를 얻을 수 있다.

예시로 몇 가지만 설명해보자.

시스템 콜 맨 위에 보이는 문자열인 fork()는 시스템 콜 번호 57번이다.

이제 아스키코드로 변환 시켜보자.

57을 아스키코드 문자로 변환해보면 숫자 9를 의미한다.

한 가지 더 해보자면 그 다음 문자열인 getpeername() 시스템 콜 문자열의 시스템 콜 번호는 52번이다.

52는 아스키코드 문자로 숫자 4를 의미한다.

이렇게 하나씩 시스템 콜 문자열을 번호에 맞게 아스키코드로 변환 시켜보면 9447{Ch3ck_~} 플래그가 나오게 된다.

이번 문제는 처음 접해본 문제로 '이런 문제도 있구나' 라고 깨닫게 되었으며 많은 도움이 된 문제였다.

해당 문제를 접하는 사람은 꼭 풀어봤으면 좋겠다는 마음에 시스템 콜 문자열과 번호에 대한 아스키코드는 따로 정리하지 않겠다.

이로써 위 과정을 통하여 해당 문제를 해결할 수 있다. 

# Reference

http://www.yes24.com/Product/Goods/59156934

Network Forensic #50 (특정 위치에 무선 트래픽이 포함된...)

주어진 파일을 다운로드하면 cap 확장자를 가진 패킷 캡처 파일이다.

해당 파일 분석을 위해 Wireshark 도구로 분석해보자.

Wireshark : 오픈 소스 패킷 분석 프로그램으로 pcap을 이용하여 패킷을 잡아내는 것이 주요 기능

다운로드 사이트 : https://www.wireshark.org/download.html

문제 파일을 확인해보면 일반 패킷 파일이 아닌 802.11 프로토콜을 가진 무선 패킷 파일이라는 것을 확인 가능하다.

무선 패킷 경우 암호화가 되어 있는 경우가 많기 때문에 평소 확인할 수 있는 패킷 캡처 파일과는 다르게 패킷 내용이 표시가 되지 않는다.

따라서 해당 패킷에 대한 암호화를 풀어야 해당 패킷 내용들을 확인할 수 있다.

암호를 풀기 위해 aircrack-ng 도구를 사용하여 분석하였다.

aircrack-ng : 무선랜 패킷 파일에 대한 종합 분석 도구이며, Monitoring / Attacking / Testing / Cracking 등 다양한 기능을 사용할 수 있다. (airdecap는 같은 폴더에 존재하며, 복호화 도구이다.)

다운로드 사이트 : https://www.aircrack-ng.org/

aircrack-ng를 사용하여 분석한 결과, WPA 방식 암호를 사용하는 것을 확인할 수 있으며, ESSID의 이름도 확인 가능하다.

ESSID : 접속하고자 하는 네트워크 이름

해당 패킷이 위처럼 WPA 방식이 아닌 WEP 방식이라면 암호화가 되어 있을 경우에 aircrack-ng를 사용해서 바로 암호를 찾아 복호화를 진행할 수 있다.

그러나 해당 패킷은 WPA 방식을 사용하였기 때문에 ESSID와 해당 패스워드를 알아야 복호화가 가능하다.

ESSID 패스워드는 해당 도구로 확인이 어렵기 때문에 암호화가 되지 않은 패킷을 사용한 IP 주소를 필터링하여 패스워드 실마리를 찾을 수 있는지 분석하였다.

ip.addr == 192.168.43.61 (암호화 되지 않은 패킷의 IP 주소)로 필터링하여 확인해보면 [그림 3]과 같이 GET 메소드를 사용하는 HTTP 패킷을 확인 가능하다.

해당 패킷의 상세 분석을 위해 [Follow TCP Stream]을 통해 확인해보자.

'Hdbgarea'라는 문자열을 확인할 수 있으며 데이터를 보내는 것을 확인 가능하다.

해당 문자열을 구글링을 통해 검색해보면 RouterPassView라는 도구를 확인할 수 있다.

해당 도구는 라우터의 백업 파일을 이용하여 잃어버린 패스워드를 찾아주는 도구이다.

해당 도구를 사용하여 원하는 패스워드를 확인해보자.

RouterPassView : 라우터 백업 파일을 이용해 잃어버린 비밀번호를 찾아주는 도구

다운로드 사이트 : https://www.nirsoft.net/utils/router_password_recovery.html

위 도구를 사용하기 위해 'Hdbgana' 문자열이 있는 데이터 부분을 추출해서 파일로 만든 다음, 데이터 파일을 분석해야 한다.

ASCII에서 RAW로 바꾼 다음, Save as...를 눌러 저장한다.

저장한 데이터 파일은 패킷의 헤더 부분까지 저장되므로 데이터 부분만 추출하고 싶을 때는 HxD를 실행하여 헤더 부분을 제거한다.

이제 RouterPassView를 실행하여 추출한 데이터를 열어보자.

[File] - [Open Router Config File] 메뉴를 통해 추출한 데이터를 확인해보면 위 그림과 같이 패스워드 확인이 가능하다.

이제 해당 패킷의 ESSID와 패스워드를 알았으니 해당 문제 패킷을 airdecap-ng 도구를 사용하여 복호화를 진행해보자.

위 명령어대로 입력해주면 복호화가 성공적으로 진행되며, 복호화 된 패킷 파일이 생성된다.

이제 복호화 된 패킷 파일을 열어 내용을 확인해보자.

복호화 된 파일 내용은 아예 다른 내용인 것을 확인할 수 있다.

이제 해당 문제에 대한 플래그를 찾아야 한다.

패킷에서 문제의 플래그 포맷을 검색해보면 다음과 같이 패킷 데이터에 문제 플래그 포맷이 확인 된다.

String으로 전환한 다음, 문제의 플래그를 검색해보면 위 화면과 같이 관련된 여러 패킷들이 확인된다.

해당 패킷들의 상세 분석을 위해 [Follow TCP Stream] 기능을 통해 확인해보면 문제의 플래그 확인이 가능하다.

이렇게 해서 위 과정을 통하여 해당 문제를 해결할 수 있다.

# Reference

http://www.yes24.com/Product/Goods/59156934