HackTMCTF Write up
Forensic
Strange PCAP
파일을 열어보면 Protocol이 USB로 나와있습니다.
USB Protocol 이란?
로컬 컴퓨터와 USB 사이의 통신 내용을 패킷으로 잡을때 사용되는 Protocol 입니다.
Info에 다양한 통신 기록이 존재 합니다.
그중에서 데이터를 담을 만한 Info 는 usb.transfer_type이 0x01 인 "URB_INTERRUPT in" 입니다.
filter 에서 usb.transfer_type == 0x01 을 입력하면 Info 가 URB_INTERRUPT in 인 패킷만 출력이 되게 됩니다.
그리고 URB_INTERRUPT in 에 데이터를 담기 위해서는 Capture Data 에 들어있습니다.
위와 같이 Leftover Capture Data 에 값이 들어 있습니다.
해당 패킷파일에서 Leftover Capture Data가 들어 있는 패킷들의 공통점은 패킷의 Length가 35라는 것입니다.
위의 Leftover Capture Data를 추출해 보겠습니다.
00:00:24:00:00:00:00:00
00:00:00:00:00:00:00:00
00:00:19:00:00:00:00:00
00:00:00:00:00:00:00:00
00:00:0a:00:00:00:00:00
00:00:00:00:00:00:00:00
00:00:0d:00:00:00:00:00
00:00:00:00:00:00:00:00
00:00:21:00:00:00:00:00
00:00:00:00:00:00:00:00
02:00:00:00:00:00:00:00
02:00:16:00:00:00:00:00
02:00:00:00:00:00:00:00
02:00:16:00:00:00:00:00
02:00:00:00:00:00:00:00
00:00:00:00:00:00:00:00
20:00:00:00:00:00:00:00
20:00:0f:00:00:00:00:00
00:00:00:00:00:00:00:00
00:00:26:00:00:00:00:00
00:00:00:00:00:00:00:00
20:00:00:00:00:00:00:00
20:00:11:00:00:00:00:00
20:00:00:00:00:00:00:00
00:00:00:00:00:00:00:00
20:00:00:00:00:00:00:00
20:00:0b:00:00:00:00:00
20:00:00:00:00:00:00:00
00:00:00:00:00:00:00:00
20:00:00:00:00:00:00:00
20:00:19:00:00:00:00:00
20:00:00:00:00:00:00:00
00:00:00:00:00:00:00:00
00:00:18:00:00:00:00:00
00:00:00:00:00:00:00:00
02:00:00:00:00:00:00:00
02:00:0e:00:00:00:00:00
02:00:00:00:00:00:00:00
00:00:00:00:00:00:00:00
00:00:27:00:00:00:00:00
00:00:00:00:00:00:00:00
02:00:00:00:00:00:00:00
02:00:07:00:00:00:00:00
02:00:00:00:00:00:00:00
00:00:00:00:00:00:00:00
00:00:23:00:00:00:00:00
00:00:00:00:00:00:00:00
00:00:07:00:00:00:00:00
00:00:00:00:00:00:00:00
00:00:20:00:00:00:00:00
00:00:00:00:00:00:00:00
02:00:00:00:00:00:00:00
02:00:09:00:00:00:00:00
02:00:00:00:00:00:00:00
00:00:00:00:00:00:00:00
00:00:28:00:00:00:00:00
00:00:00:00:00:00:00:00
위와 같이 출력이 되는데 ~~:00:00:00:00:00:00:00는 의미 없는 값이므로 지워보면 아래와 같습니다.
00:00:24:00:00:00:00:00
00:00:19:00:00:00:00:00
00:00:0a:00:00:00:00:00
00:00:0d:00:00:00:00:00
00:00:21:00:00:00:00:00
02:00:16:00:00:00:00:00
02:00:16:00:00:00:00:00
20:00:0f:00:00:00:00:00
00:00:26:00:00:00:00:00
20:00:11:00:00:00:00:00
20:00:0b:00:00:00:00:00
20:00:19:00:00:00:00:00
00:00:18:00:00:00:00:00
02:00:0e:00:00:00:00:00
00:00:27:00:00:00:00:00
02:00:07:00:00:00:00:00
00:00:23:00:00:00:00:00
00:00:07:00:00:00:00:00
00:00:20:00:00:00:00:00
02:00:09:00:00:00:00:00
00:00:28:00:00:00:00:00
위의 데이터를 바탕으로 아래의 표를 비교해서 대조해 보겠습니다.
데이터는 16진수 newmap은 10진수 이므로 맞춰서 변환을 해보면 아래와 같이 출력이 됩니다.
7vgj4ssl9nhvuk0d6d3f
위의 데이터를 가지고 무엇을 할 수 있나 확인 해보던중 패킷파일의 1224번 패킷을 확인해 보면 zip 파일이 있다는 것을 알 수 있습니다.
상대적으로 패킷의 크기가 크고 Flag.txt 를 가지고 있는 zip 파일 이기 때문에 카빙을 해보겠습니다.
zip 파일을 열어보니 password가 필요했으나 저희가 얻은 문자열(7vgj4ssl9nhvuk0d6d3f)은 password 가 아니였습니다.
자세히 Capture data 를 확인해 보면 아래와 같은 부분이 변환을 할때 누락된 것을 확인 할 수 있습니다.
맨 앞의 데이터를 무시하고 3번째에 존재하는 hex 값으로만 데이터를 변환 했었습니다.
맨앞에 오는 데이터의 의미를 검색해 보면 아래와 같은 값을 가지고 있다는 것을 알 수 있습니다.
0x00 = 아무것도 누르지 않은 상태
0x02 = 왼쪽 shift 를 누른 상태
0x20 = 오른쪽 shift를 누른 상태
그렇기 때문에 0x02와 0x20 이 있는 문자는 대문자로 변환해줘야 합니다.
Password : 7vgj4SSL9NHVuK0D6d3F
Flag : HackTM{88f1005c6b308c2713993af1218d8ad2ffaf3eb927a3f73dad3654dc1d00d4ae}
Reference :
https://github.com/TeamRocketIst/ctf-usb-keyboard-parser
RR
문제파일을 보면 총 3개의 img파일이 있습니다.
하지만 2.img파일은 크기가 0byte입니다.
2.img파일을 복구 해야하는것 같습니다.
먼저 문제를 자세히 살펴 보면 드라이브가 고장나서 복구를 해야한다. 라고 하면서 문제 뒷부분을 보면 Reusing All of Internal Disks라고 되어있는데 이부분을 보고 RAID 를 유추 할 수 있습니다.
RAID와 연관 지어서 문제를 해결해야 할것 같습니다.
RAID 란?
복수 배열 독립 디스크(Redundant Array of Independent Disks 또는 Redundant Array of Inexpensive Disks)의 약자로 여러개의 하드디스크에 일부 중복된 데이터를 나눠서 저장하는 기술입니다.
그렇기 때문에 제공된 디스크이미지파일은 모두 하나의 하드디스크의 역할을 하고 있습니다.
또한 2.img 파일이 없어도 중복된 데이터를 나눠서 저장하기 때문에 1.img와 3.img 파일을 이용해서 마운트를 해도 파일을 확인 할 수 있습니다.
이를 RAID Array 라고 합니다.
일단 file 명령과 RAID 관련 명령어인 mdadm을 이용해서 1.img 와 3.img 를 확인해 보겠습니다.
해당 문제가 RAID 와 관련되어 있는 문제이고, 제공된 디스크이미지 파일도 RAID와 관련되서 RAID number이 있어야 하지만 file 명령어와 mdadm 명령어의 어딜 봐도 RAID와 관련된 문제가 없습니다.
파티션 테이블이 유효하지 않은 값으로 채워져 있다는 것을 알 수 있습니다.
그렇기 때문에 유효한 파티션테이블의 오프셋을 알아보기위해서 binwalk을 이용해 보겠습니다.
mdadm에서는 Partition[0]의 offset을 1046528 이라고 했지만 binwalk 에서 보았을땐 Filesystem의 offset은 1048576입니다.
dd 명령어를 이용해서 오프셋을 수정해보겠습니다.
다시 mdadm명령어로 확인해보겠습니다.
RAID 5라는것을 알 수 있습니다.
losetup 명령어를 이용해서 loop을 생성한뒤 mdadm 으로 드라이브를 마운트 해보겠습니다.
mdadm 명령어로 /dev/md0 에 1_.img와 3_.img 를 mount했습니다.
마운트가 된것을 확인할 수 있습니다.
Flag.jpg 에 FLAG 가 있습니다.
Flag : HackTM{1bf965b6e23e5d2cb4bdfa67b6d8b0940b5a23e98b8593bb96a4261fb8a1f66a}
Find My Pass
문제파일을 다운 받아 보면 아래와 같이 vmem 파일이 있는 것을 확인 할수 있습니다.
먼저 해당 vmem 파일이 어떠한 profile을 사용하는지 알아보기 위해서 imageinfo 플러그인을 이용해 보겠습니다.
Win7SP1x86 profile을 사용하고 있다는 것을 알 수 있었습니다.
이번에는 먼저 해당 메모리 덤프 파일의 프로세스에서 수상한 데이터가 있는지 찾아 보겠습니다.
0x86e1b810 KeePass.exe 라는 프로세스가 존재 합니다.
KeePass.exe 란?
키패스 패스워드 세이프(KeePass Password Safe) 프로그램으로 Microsoft Windows를 대상으로 자유 오픈소스 암호 관리자 프로그램입니다.
내보내기 하는 파일의 확장자는 .kdbx 입니다.
그렇기 때문에 KeePass.exe 로 내보내기한 데이터에 flag를 숨겼을 가능성이 있습니다.
또한 KeePass.exe 에서 내보내기를 하면 Database.kdbx 라는 파일을 내보내기 하기 때문에 filescan 플러그인으로 검색을 해보겠습니다.
해당 파일을 추출해보겠습니다.
해당 파일을 KeePass를 통해서 열어보겠습니다.
KeePass.exe 는 해당 메모리 덤프 파일에 로그는 있었으나 추출해서 실행해 보면 실행이 되지 않았습니다.
그렇기 때문에 아래의 사이트에서 KeePass.exe 를 설치 하시면 될 것 같습니다.
Download Link : https://keepass.info/download.html
열기 위해서는 KeePass를 설명할때 이야기 한거 처럼 암호 관리자 프로그램으로 암호가 필요한것 같습니다.
Password로 의심되는 문자열이 존재 합니다.
dmVZQmdzOlUrcEBlRj87dHQ3USVBIn 를 패스워드로 사용해 보겠습니다.
Database.kdbx가 열렸습니다.
데이터를 눌러보면 Attachments 에 nothinghere.7z 라는 첨부파일이 있는 것을 알 수 있습니다.
압축해제시 패스워드를 필요로 하는데 힌트에 자기는 1가지의 password를 사용한다고 했으니 dmVZQmdzOlUrcEBlRj87dHQ3USVBIn를 다시 사용해 보겠습니다.
Flag : HackTM{d14c02244b17f4f9dfc0f71ce7ab10e276a5880a05fca64d39a716bab92cda90}
Secrets Communicated
문제를 좀 해석해 보면 범죄자가 경찰과 만남에서 휴대전화를 떨어뜨렸고, 전화기의 펌웨어를 얻었고, 해당 펌웨어 에서 온라인 채팅 서비스를 통해서 집에 있는 연락 담당자 에게 무엇을 보냈는지 알아내는 것이 문제 인것 같습니다.
펌웨어를 마운트 해서 온라인 채팅 서비스와 관련된 디렉터리를 찾아서 접근하는하는것이 키워드 인것 같습니다.
문제 파일을 받아보면 아래와 같이 7.2GB 정도의 img 파일이 들어 있습니다.
해당 파일을 fdisk -l 명령어를 이용해서 this_is_it.img 파일을 확인해 보면 img1 ~ img44 까지 총 45개의 img 파일이 존재한다는 것을 알 수 있습니다.
용량이 가장큰 5GB 짜리 img 파일인 this_is_it.img44에 많은 데이터가 있을 것이므로 flag가 숨겨져 있을 가능성이 큽니다.
오프셋을 계산해서 mount를 해야하기 때문에 계산을 해보면 4751360 * 512 = 2432696329 offset 입니다.
losetup 명령어를 이용해서 this_is_it.img 파일을 /dev/loop1 에 올리고 mount라는 디렉터리에 /dev/loop1 을 mount 합니다.
그러면 ~/mount 라는 디렉터리에 마운트가 되어서 좀더 쉽게 접근이 가능합니다.
좀더 수월한 접근을 위해서 su 명령을 이용해서 root 로 사용자 계정을 전환했습니다.
mount 폴더를 살펴 보면 아래와 같은 디렉터리를 확인 할 수 있습니다.
app 관련 디렉터리부터 camera 디렉터리, lost+found 디렉터리 등등 안드로이드에 탑재된 디렉터리들이 존재 하는것으로 보아 해당 img 파일은 안드로이드 폰에 탑재되어 있는 디렉터리 인 것 같습니다.
Android의 앱 데이터를 분석해 보면 알 수 있을것 같아서 경로를 찾아보니 /data/ 디렉터리가 데이터를 가지고 있다는 것을 알게 되었습니다.
/data/com.facebook.orca/databases 하위에 facebook과 관련된 message db가 존재 하는 것도 알수 있습니다.
threads_db2 파일을 DB Viewer인 DB Browser for SQLite 를 이용해서 열어보면 여러 테이블중 message 테이블에서 아래와 같은 문자열을 확인 할 수 있습니다.
해당 대회에서는 앞의 문제들에서 보았듯이 이러한 숫자와 문자의 결합의 문자열은 password로 사용될 수 있기 때문에 일단 Keep 해두겠습니다.
혹시나 Flag인가 확인해 봤지만 아니였습니다.
이번에는 /media/0/ 경로에 가보면 아래와 같은 폴더들을 확인 할 수 있습니다.
자세한 세부내용을 확인하기 위해서 ls * -l 을 입력해 보겠습니다.
다른 디렉터리들은 파일이 있거나 파일이 없는 것으로 보이지만 Download 디렉터리는 파일이 있지만 이름이 눈에 보이지 않습니다.
그러면 Download 디렉터리 하위에 있는 파일이 이름은 안보이지만 어떤 파일인지 확인해 보겠습니다.
zip 파일인것을 알 수있습니다.
해당 파일을 cp 명령어로 복사 후에 압축 해제 해보겠습니다.
/mnt/hgfs/memory 경로는 메인 host 컴퓨터와의 공유 폴더를 만들어 뒀습니다.
윈도우로 봐도 파일 명이 보이지 않습니다.
.zip을 붙이고 압축을 해제해 보겠습니다.
으음... 압축된 파일명도 눈에 보이지 않습니다.
password가 필요하는데 앞에서 찾아둔 문자열을 사용해 보겠습니다.
Password : 8ab96434b285b34f77d805079b91a552
Windows 에서 압축을 해제를 했지만 압축 해제한 파일이 아예 없어져서 다시 linux에서 압축해제를 해보겠습니다.
파일명은 저 파일명 앞부분을 복사해서 Tab 하면 자동안
압축 해제가 완료 되었습니다.
압축 해제된 파일명은 좀 짧은 편인것 같습니다.
file 명령어로 확인해 보니 텍스트 파일인것 같습니다.
Flag 를 확인 할 수 있습니다.
Flag : HackTM{a1f6bb8b4f993e3fbea836b001339d5f2387043fe504ba290fbe9674de4a2a16}