M4ndU의 만두만두한 블로그

Forensics

Sounds Familiar

dtmf

이건 너무 부정확해서 다른 도구를 사용했다.

http://www.polar-electric.com/DTMF/Index.html

0과 1이 많아서 키패드 알파벳 변환은 아니다.

띄어서 입력되는 부분을 고려하면

100 88 82 106 100 71 90 55 78 87 86 106 99 109 86 48 88 50 89 120 81 68 108 102 90 71 57 102 98 109 57 48 88 122 86 111 81 72 74 108 102 81 61 61

이 되고, 이를 ascii로 변환한 뒤에 base64로 디코딩해주면 플래그가 나온다.

dtmf decode -> ascii -> base 64

Forensics

IRC

memdump.lime.z 파일이 주어진다.

zlib compreesed data이므로 압축을 풀어주자.

압축을 풀고 strings와 grep을 사용해서 프로필 정보를 알아냈다.

debian 10.2.1-6 에 linux version 5.10.0-11-amd64이다.

volatility2 사용을 위한 profile을 create해야한다. 

환경 구성의 편의를 위해서 커널버전 5.10.0-11에 가장 근접하는 데비안 버전을 사용했다.

debian 11.0.0 amd64 iso 파일을 다운받아서 가상환경을 구축해준다.

https://ftp.cae.tntech.edu/debian-cd/dvd/

apt install linux-headers-5.10.0-11-amd64

apt install linux-headers-5.10.0-11-common

apt install linux-image-5.10.0-11-amd64

apt install linux-image-5.10.0-11-amd64-dbg

디스크 용량은 15GB 이상 확보하자.

기존에 설치되어 있는 커널 버전은 remove 해준다.

https://github.com/volatilityfoundation/volatility/wiki/Linux 을 참고하여 프로필을 생성하면 된다.

/boot/System.map-<uname -r> 파일을 보면 

The real System.map is in the linux-image-<version>-dbg package

이렇게 되어 있다. apt install linux-image-5.10.0-11-amd64-dbg 를 한 이유가 real System.map 파일을 얻기 위해서다.

real System.map 파일은 usr/lib/debug/boot/ 경로에 있다.

생성된 프로필 zip 파일을 볼라티리티 overlays linux 폴더에 옮겨 넣는다.

hexchat이라는 irc 프로그램을 설치한 기록을 확인할 수 있다.

pslist에서 hexchat이 확인된다.

이제 irc password를 찾기 위해서 log 파일을 확인하면 password를 찾을 수 있을 것이라고 생각했다.

그런데 log파일들이 있는 경로는 알지만 정확한 로그 파일을 봐야하고 그 파일의 이름이 뭔지를 알 수 없었으므로

(linux는 filescan이 안된다. 정확한 파일의 절대 경로를 알고 있어야 한다.)

여기서부터는 게싱을 했다.

HxD로 메모리 덤프 파일을 열어서 hexchat과 utctf를 검색했고, P=blabla 문자열을 확인할 수 있었다.

utctf.live는 irc 주소, P 값은 irc password로 추측되었다.

해당 P값을 flag로 제출했다.

WEB

Websockets

어드민 로그인 페이지가 있는데 username은 admin이고 pw는 숫자 3자리라고 한다.

웹소켓으로 id와 pw를 전달한다.

파이썬으로 쓰윽

WEB

pdf로 변환을 해준다.

<h1 id='test2'>a</h1><script>x = new XMLHttpRequest();
x.open('GET','file:///etc/passwd',false);
x.send();
document.getElementById('test2').innerHTML= x.responseText+location.href;
</script>

이렇게 파일을 읽어올 수 있고

+location.href로 현재 경로를 알아냈다.

<h1 id='test2'>a</h1><script>x = new XMLHttpRequest();
x.open('GET','file:///usr/src/app/app.py',false);
x.send();
document.getElementById('test2').innerHTML= x.responseText;
</script>

약간의 게싱으로 app.py의 소스를 가져온다.

flag가 환경변수에 있는데, /proc/environ을 못읽도록 하고 있다. 그런데 필터링 우회해서 해당 파일에 접근해도 결과가 안나왔다. (언인텐이라서 이쪽으로는 못풀게 아에 막은 듯 싶다.)

/admin 페이지 로그인으로 플래그를 얻어야 하는데 unix계정 로그인을 하면 된다.

아까 passwd파일을 확인했을 때 WeakPasswordAdmin 이라는 계정이 있었다. 해당 계정의 패스워드를 구해서 로그인하면 될 것으로 보인다.

/etc/shadow 파일도 가져온다.

클리어.

Misc

https://ropsten.etherscan.io/tx/0xca78d2d51101fda93f3f8c62f4349dd23a7e5692cef667ab834c3611601f068f

그냥 이더스캔으로 컨트랙트 생성 트랜젝션의 인풋값 보면 된다.

올해에는 대학부로 참여했다. 분야별 난이도 차이가 좀 큰 편이었다.

처음에 크립토 잡고 풀다가 하루 다 보내버리고 뒤늦게 웹에 합류하여 문제를 풀었다. 좀 더 빨리 웹을 잡고 풀었으면 좀 더 점수를 낼 수 있었을 텐데 아쉬웠다. 그리고 예선전은 인원 제한이 없는걸 몰랐어서 처음엔 4명 모아서 할려고 했다가 대회 시작 직전에 뒤늦게 사람 2명밖에 못 데려온 것도 좀 아쉬었다. 내년에는 소학회원들 많이 데리고 하면 좋을 거 같다.

코게에도 포렌식이나 네트워크 문제 나왔으면 좋겠다. 예전엔 그래도 한 두개씩 나왔던거 같은데..

WEB - superbee

golang으로 작성되어 있고

beego 라는 프레임워크를 사용하고 있다.

플래그는 app.conf에 정의되어 있고 (물론 주어진 파일에서는 REDEACTED)

http://[IP]/main/index 경로로 접속하면 flag를 확인할 수 있도록 되어 있지만

쿠키값을 비교하여 admin이 아니면 플래그를 확인할 수 없고, login 페이지로 redirect된다.

먼저 어드민 패스워드를 획득하여 어드민계정으로 로그인 하는 방법은

패스워드를 알아낼 방법이 없으므로 불가능하고

SSTI일까 생각해봤지만,

사용자가 입력한 값으로 render하는 곳이 없고, 애초에 beego에서는 값을 직접 때려주기 때문에 불가능하다.

어떻게 풀어야 될까 생각을 해보다가

/admin/authkey 페이지로 접근해서 encrypted_auth_key를 얻고

aes 복호화를 해서 평문 auth_key를 얻어서 sess 쿠키 값을 설정해서 main/index로 접근하여 flag를 얻는 루트같았다.

그러지 않고서야 aesencrypt함수를 넣어두고 admin페이지를 만들어둘 이유가 없다고 생각했다.

그런데 admin/authkey에 접근할려면 domain이 localhost가 되어야 한다.

아니 ssrf때릴 곳도 없는거 같은데 어떻게 domain명을 localhost로 만들지 고민을 하다가

Ctx.Input.Domain()이 사실 처음 보는 함수였기 때문에 정확히 어떻게 동작하는 지 알 필요가 있었다.

코드를 살펴보니 request의 host가 공백이면 localhost를 return해주고 있었다. (.....이게 맞나?)

그래서 burp suite로 리퀘 잡아서 Host 부분을 공백으로 바꿔주었더니

00fb3dcf5ecaad607aeb0c91e9b194d9f9f9e263cebd55cdf1ec2a327d033be657c2582de2ef1ba6d77fd22784011607

encrypted_auth_key값을 얻을 수 있었다.

해당 값을 복호화하기 위해서는 key값에 사용되는 auth_crypt_key값을 알아야하는데

키값이 공백일 수는 없는데.. 라고 생각을 하다가 

Padding 함수를 보면

Padding(key, 16)ciphertext가 [] 이더라도

16 - 0 % 16 = 16

16을 16번 반복 => [16] * 16 이 된다

즉 auth_crypt_key값이 공백이어도 된다.

aes cbc이고, iv와 key값이 동일하다

​복호화하여 auth_key를 구할 수 있다.

Md5("sess") = f5b338d6bca36d47ee04d93d08c57861

Md5(admin_id + auth_key) = Md5("admin" + "Th15_sup3r_s3cr3t_K3y_N3v3r_B3_L34k3d") = e52f118374179d24fa20ebcceb95c2af

Cookie: f5b338d6bca36d47ee04d93d08c57861=e52f118374179d24fa20ebcceb95c2af

이렇게 쿠키를 설정해주고, /main/index로 접근하면 flag를 확인할 수 있다.

WEB - babyfirst

로그인하고, 메모 작성하고, 메모를 읽는 간단한 서비스이다.

flag는 /flag에 있다.

memoServiet.class를 디컴파일해서 살펴봐야한다.

메모를 읽어오는 getMemo 함수를 보면 db에서 가져온 memo데이터를 가지고 lookupImg 함수를 돌리는데

lookupImg함수는 memo 내용에서 [URL] 패턴을 찾아서 해당 url 데이터가져와서 base64로 인코딩해서 <img>에 담아준다.

[file:///flag]가 되면 좋겠지만 file로 시작하는 건 필터링해버린다.

종료 30분 남은 시점에셔 여기서 막혀서 못 풀었다.

[url:file:///flag] 로 하면 된다.

https://github.com/openjdk/jdk11/blob/master/src/java.base/share/classes/java/net/URL.java#L575

ㅠㅠ 아쉽

CRYPTO - dark-arts

챌린지 1,2,3,4를 모두 통과해야 플래그를 얻을 수 있다.

CHAL1은 GUESS_MODE()를 64번 통과해야 한다.

GENERATOR1에서 랜덤으로 func_gen 과 func_random 둘 중 하나로 고정되서 리턴한다.

gess_mode에서 x에 값을 직접 넣어서 그 결과를 알 수 있고, 그 값들을 가지고  mode가 0일지 1일지 (func_gen을 통과한 결과인지 func_random을 통괗나 결과인지)를 맞춰야 한다.

func_gen과 func_random 둘다 결과는 무조건 0 또는 1이 나온다.

func_gen은 랜덤 seed와 x의 각 bit를 내적한 값으로 66행의 식을 계산한 값이 결과가 된다.

x가 0 [0]이라면 prod가 0이 되고 66행의 계산 결과는 0이 된다.

x가 1 [1]이라면 prod는 1 또는 0이 되고, 1이라면 66행의 결과는 (1 % 2 + 1 % 3 ) %2 = 0

x가 2 [0,1]이라면 prod는 1 또는 0이 되고, 결과는 0

x가 3 [1,1]이라면 prod는 2 또는 1 또는 0이 되고 2라면 (2 % 2 + 2 % 3 ) % 2 = 0

x가 4, 5, 6, 8, 9, 10, 11 일 때에도 (bit 중 1인 bit의 개수가 3개 미만인 수들) 모두 결과는 0이 된다.

x가 7 [1,1,1] 이라면 prod가 3이 될 수도 있는데 (3 % 2 + 3 % 3) % 2 = 1이다.

따라서 x에  0,1,2,3,4,5,6,8,9,10,11 넣어서 결과가 1 나오면 무조건 mode=1

모두 0이 나오면 mode = 0 으로 판단하도록 코드를 작성하여 돌렸다.

chal2도 guess_mode()를 64회 통과해야하는데

이제는 리턴 값이 0,1,2,3,4 총 5개 이며

func_gen에서 x를 sha256을 돌려서 사용한다.

일단 x에는 int만 들어가고 x를 0부터 1씩 증가시켜 넣어서 결과를 확인했을 때 규칙을 찾을 수 없었고

sha256(x) 의 결과들 중에서 bit중 1의 개수가 작아봐야 80-90개 사이였기 때문에

chal1처럼 풀 수 없었다.

다르게 풀어야 되는 거 같은데..

https://dfir.pubpub.org/pub/h78di10n/release/2

저자: Alexandros Vasilaras 1 , Evangelos Dragonas 2 , Dimitrios Katsoulis 3

vasilaras@digitalforensics.gr , dragonas@digitalforensics.gr , katsulis@digitalforensics.gr

라이선스:  Creative Commons Attribution 4.0 국제 라이선스(CC-BY 4.0)

- 개요

질문 : Windows 이벤트 로그에서 이전에 연결된 장치의 VSN을 몇 개나 복구할 수 있는가

OS 버전 : Windows 10 Pro 2004 build 19041

도구 : JLECmd 1.4.0.0, LECmd 1.4.0.0, AXIOM 4.7, Partition-4DiagnosticParser

- 배경

윈도우 10에 파티션/진단 이벤트 로그가 처음 도입됨.

C:\Windows\System32\winevt\Logs\ Microsoft-Windows-Partition%4Diagnostic.evtx

이 로그에서 여러 볼륨이 있는 장치의 최대 3개의 VSN을 찾을 수 있음.

해당 로그를 분석해서 VSN을 추출하는 도구를 개발함.

해당 이벤트 로그에는 이동식 디스크 (USB 스틱, SD카드, 외장 하드 등)과 컴퓨터 내부 디스크에 대한 정보가 저장됨.

- 이벤트 로그 필드 일부 설명

[시스템 섹션]

• EventID: 항상 1006
• TimeCreated [SystemTime]: 타임스탬프
• EventRecordId: 로그 파일 내의 각 기록에 할당된 고유 번호
• Computer: 컴퓨터 이름
• Security [UserID]: 유저의 SID값. 항상 S-1-5-18임 (User SYSTEM).

[이벤트 데이터 섹션]

• DiskNumber: In our analysis, we found this number varying in a range between 0-3, with 0 being assigned to the disk running the operating system (OS).
• IsSystemCritical: This value is usually false, apart from when DiskNumber was 0.
• BytesPerSector: Bytes per sector (usually 512-defined by the manufacturer) of the device.
• Capacity: The total capacity of the device (in bytes).
• Manufacter: The manufacturer of the device. Not always accurate.
• Model: Model of the device. Not always accurate.
• SerialNumber: Serial number of the device.
• ParentId: Information about the device, including Vendor ID, Product ID, Serial Number (potential correlation with registry files).
• PartitionStyle: The partition scheme of the device. MBR is 0. GPT (GUID Partition Table) is 1.
• PartitionCount: Number of partitions of the device. Not to be trusted.
• Mbr: Raw dump of the first 512 bytes of the Master Boot Record of the device. Contains device’s Disk Signature and Master Partition Table.
• Vbr0: Raw dump of the Volume Boot Record of the device’s 1st partition. Contains the VSN of this partition.
• Vbr1: Raw dump of the Volume Boot Record of the device’s 2nd partition. Contains the VSN of this partition.
• Vbr2: Raw dump of the Volume Boot Record of the device’s 3rd partition. Contains the VSN of this partition.
• Vbr3: In our analysis, we found that this field is not populated with the raw dump of the Volume Boot Record of the device’s 4th partition. If someone wants to determine the existence of a 4th partition, he should examine the Master Partition Table.

위에서 볼 수 있듯 한 장치의 두 번째 및 세 번째 파티션의 VSN도 저장한다. 사용자가 자신의 장치를 포맷하더라도(할당된 VSN 손실) 이벤트 로그에서 이전 VSN을 검색할 수 있다.

- 조건 및 한계점

이 연구는 Microsoft-Windows-Partition%4Diagnostic.evtx 이벤트 로그에 대한 포렌식 분석에만 중점을 둠. 레지스트리 등의 다른 아티팩트를 조사하지 않는다.

이 연구는 할당되지않음 또는 MBR 파티션이 있는 장치로 제한됨. GPT 파티션 장치는 이 이벤트 로글르 다른 방식으로 기록함. 또한 4번째 파티션이 존재할 경우 4번째 파티션에 대한 정보는 저장되지 않음.

이 연구는 FAT32, NTFS, exFAT, EXT3 파일 시스템을 사용하는 장치만을 대상으로함. 다른 파일시스템을 사용하는 장치는 이 이벤트 로그를 다른 방식으로 기록함.

해당 이벤트 로그의 수명은 짧음. 주요한 윈도우 10 업데이트될 때 이벤트 로그가 지워짐. 다만, 19041에서 19042로의 업데이트와 같이 사소한 업데이트로는 지워지지 않음.

장치유형(SSD), 연결유형 (USB <- SATA 디스크)는 이벤트 로그를 다른 방식으로 기록함.

- 방법론

VSN은 파티션의 고유하게 하는 한 가지 기능임.

VSN은 VBR 내부에 있으며, 오프셋과 길이는 파일시스템에 따라 다름.

VSN은 LNK파일 및 점프 모곩에서 대상 파일이 있는 볼륨을 가리키는데 사용됨.

MBR 파티션 테이블이 있는 장치를 식별하는 다른 기능은 디스크 서명임.

디스크 서명은 MBR의 offset 0x1b8(4byte, little endian)에 있으며 파티션이 만들어질 때 할당 됨.

--- 직접 시연을 하기 위해서 사용된 환경 및 장비가 다릅니다. ---

OS : Windows 10 home 21H2 19044.1415
usb device : A(unknown) 64GB(MBR, 4 NTFS partition), B(unknown) 8GB (MBR, 1 FAT32 partition & 1 EXT3 partiton)
software : JLECmd 1.4.0.0, LECmd 1.4.0.0, AXIOM 4.7

• 1단계 : 이 단계에서 A 64GB USB 장치는 테스트 컴퓨터에 여러 번 연결/해제되었습니다. 장치가 연결되어 있는 동안 LNK 파일과 점프 목록을 생성하기 위해 여러 파일(4개 파티션 모두에 위치)에 액세스했습니다. 일정량의 데이터가 생성된 후 이벤트 로그, LNK 파일 및 점프 목록에 대한 포렌식 검사를 진행했습니다.
• 2단계 : 이 단계에서 A 64GB USB 장치의 모든 파티션을 삭제하고 3개의 새로운 NTFS 파티션을 생성했습니다. 1단계(연결/연결 해제, 모든 파티션의 파일 액세스)와 동일한 과정을 반복했습니다. 일정량의 데이터가 생성된 후 이벤트 로그, LNK 파일 및 점프 목록에 대한 포렌식 검사를 진행했습니다.
• 3단계 : 이 단계에서 B 8GB USB 장치는 테스트 컴퓨터에 여러 번 연결/해제되었습니다. 잠시 후 우리는 이벤트 로그에 대한 포렌식 조사를 진행했습니다.
• 4단계 : 이 단계에서 B 8GB USB 장치의 FAT32 파티션을 삭제하고 새로운 exFAT 파티션을 생성했습니다. 3단계(연결/연결 해제)와 동일한 과정을 반복했습니다. 잠시 후 우리는 이벤트 로그에 대한 포렌식 조사를 진행했습니다.

A usb의 환경 구성에 실패. 처음에 NTFS 파티션 4개로 나누고 각 파티션에 테스트용 파일까지 넣고 usb 재인식하니까 위 사진처럼 파티션 구성이 바뀌어서 인식됨. usb 자체 문제인지 특성인지 파악 못함.

B USB의 경우 FAT32와 EXT3 파티션 구성이 유지되었음.

그러나 FAT32 파티션을 exFAT 파티션으로 포맷하고 재인식하니 exFAT 파티션이 RAW로 인식되버림.

첫번째 파티션을 exFAT 대신 NTFS로 다시 포맷하여 진행함.

따라서 3~4단계만 진행.

1단계

그냥 위 사진 상태의 usb를 연결하고 파일에 접근한 뒤 로그를 확인해 보았다.

NTFS로 정상적으로 인식되는 첫 번째 파티션은 vbr이 제대로 기록되었고, 나머지는 vbr이 0000으로 기록되었지만 이를 통해 최소 4개의 파티션이 존재했음을 알 수 있다.

2단계

3단계

USB를 연결하고 FAT32 파티션 내에 있는 테스트 파일을 열어본 이후 Microsoft-Windows-Partition%4Diagnostic.evtx 해당 이벤트 로그를 확인한 내용이다.

FAT32 파티션의 vbr은 기록되었지만 EXT3 파티션은 인식할 수 없는 포맷이므로 vbr이 기록되지 않았다.

그래도 2개의 파티션이 있는 것을 확인할 수 있다.

4단계

역시 2개의 파티션이 존재함을 알 수 있고, 두 번째 EXT3 파티션은 여전히 0000으로 기록되어있으며

첫번째 파티션이 새로 포맷되었기 때문에 vbr값이 변경된 것을 알 수 있다.

mbr값은 동일하다.

- 결론

이 게시물에서 우리는 특히 장치 속성이 필요한 경우 "Microsoft-Windows-Partition%4Diagnostic.evtx" 검사의 중요성에 대해 설명했습니다. 이 유물이 몇 년 전에 발견되었지만 우리는 아직 그 풍부한 정보를 완전히 탐색하지 못했습니다. 그럼에도 불구하고 우리는 저장되어 있는 사용 가능한 모든 VSN을 수동으로 추출하는 방법과 이 프로세스를 자동화하는 도구를 개발하는 방법을 보여주었습니다. 이 이벤트 로그에 대한 추가 연구의 여지가 있지만 독자가 이 이벤트 로그에서 찾을 수 있는 주요 아티팩트 중 일부에서 가치를 찾을 수 있기를 바랍니다.

https://github.com/theAtropos4n6/Partition-4DiagnosticParser

- 앞으로

해당 이벤트 로그가 GPT 파티션을 사용하는 장치를 처리하는 방법과 다양한 파일 시스템을 처리하는 방법을 분석할 예정.

- DFIR 리뷰

 USB 드라이브에는 여러 볼륨이 포함될 수 있으며, 동일한 물리적인 USB 드라이브에서 여러 볼륨을 나올 수 있다는 사실을 간과할 수 있따는 점을 중요하게 지적함.

ASCTF에 출제한 리눅스 메모리 포렌식 문제 제작에  12시간 이상 소요된 것 같다. 사전 계획 빼고 문제 제작 자체만.

순조롭게 진행되었다면 절반도 안걸렸을테지만.. 처음 만들다보니 헤메는 것이 많았다.

그리고 만들고 보니 왜 CTF들에 리눅스 메모리 문제는 거의 없는지도 느낄 수 있었다.

리눅스 메모리 포렌식 문제 제작은 처음이지만, 최근에 한 번 풀어 본 적이 있다.

리눅스 메모리 포렌식의 특징은 분석 자체는 볼라티리티로 하면 되므로

윈도우랑 별 차이가 없기 때문에 쉽다.

그런데 이 볼라티리티를 사용하기 위한 환경 구성에 시간이 많이 소요된다.

프로필을 생성하는 방법은 쉽게 찾을 수 있다.

이 과정에 비교적 많은 시간이 소요된다. 리눅스를 가상머신에 깔고 커널버전을 맞춰줘야 하니까..

리눅스 종류랑 리눅스 커널 버전이 매우 다양해서, 볼라티리티에서 모든 종류의 프로필을 배포할 수 없고

많은 프로필들을 한 번에 볼라티리티에 적용할 경우 볼라티리티의 성능이 매우 나빠진다.

따라서 필요한 프로필만 그때 그때 만들어서 적용을 해서 사용을 해야한다.

이 부분을 노리고 문제 제작을 계획했다.

리눅스에서 메모리를 덤프할 때 사용할 수 있는 소프트웨어들에는 여러가지가 있다.

그 중에서 나는 들어본 적 있는 lime을 사용하기로 했고 관련 포스트를 찾아보았다,

위 포스트를 찾아서, 문제 시나리오대로 구성을 한 뒤에 덤프를 위해 사용방법을 따라했다.

근데 사용 예시에 format이 raw로 설정되어있다. 밑에 옵션은 처다보지도 않고, 당연히 메모리 덤프는 raw지! 하고 raw로 덤프를 떴다.

그리고 볼라티리티를 돌렸는데 여기서 문제가 발생했다.

이런 식으로 no base address space가 떴다. (사용했던 볼라티리티 버전은 2.6.1 최신이었다.)

문제 제작한 환경이 ubuntu 18.04.1 x64 linux version 5.4.0-42-generic 이었고, 동일한 환경에서 제작된 문제를 이전에 풀어본 적이 있었기 때문에 전혀 이해가 가지 않은 상황이었다.

그래서 좀 찾아보니까 

리눅스 커널 4.8 부터는 KASLR이 적용되어 있어서 저런 현상이 발생되고 분석을 진행할 수 없다는 내용이었다.

추가로 kaslr이 적용된 4.8에서 사용할 수 있는 볼라티리티 버전이 있다는 내용도 있었다.

이 시점에서 의문이 들었다.

내가 풀었었던 동일한 환경의 문제는 어떻게 제작이 되었던 것일까?

1. 나랑 다른 방식으로 메모리를 덤프하였다.

2. kaslr을 해제하고 문제를 제작하였다.

2번 같은 경우 kaslr을 해제할 수 있다는 내용을 보고 선택지를 추가하게 되었다.

난 여기서 1번에 의심을 가졌으면 금방 해결되었을 문제였지만 나는 4.8 kaslr 버전용 볼라티리티가 따로 있어? 에 흥미를 느끼고 4.8 환경에서 문제를 제작해서 해당 볼라티리티 버전만을 사용하게 해서 문제를 풀게 하면 재밌겠다는 생각이 들었다. 그리고 이게 안되면 kaslr을 해제해서 만들자로 plan b를 세웠다.

(아무 의미가 없는 행동이었다. bneuburg가 제작한 4.8 kaslr 지원 버전에는 2개가 있는데, 모두 2017년에 올라온 것이고 지금은 이미 최신버전 볼라티리티에 기본 탑재되어 있는 기능이다. 근데 난 몰랐다. (아니 나 2017년도 내용임을 확인안하고 뭐했냐..))

기존에 사용하던 18.04.1에서는 커널 버전을 4.8로 내릴 수 없어서 4.8로 탑재되어 있는 16.10을 다운받아 환경을 구성하였다.

그리고 똑같은 짓을 하고

똑같이 raw로 덤프를 떠서

볼라티리티를 돌렸고

똑같은 결과가 나왔다. No base address.

왜 안되지 하고 깃헙 페이지를 자세히 봤다. 이전엔 자세히 안보고 걍 지원되는 버전 정도만 확인 했었다.

이걸 딱 읽고 아 라임 포멧이어야 하는구나를 알게 되었다.

그리고 이전에 읽었던 lime 사용방법 블로그로 돌아와서

방법2-1에는 포멧을 lime으로 써두셨더라..

그래서 처음부터 다 잘못됐음을 깨닳고 처음 환경에서 lime으로 뽑아내서 최신버전 볼라티리티를 돌렸고

분석에 성공했다.

이렇게 메모리 덤프를 볼라티리티에 인식하게 하는 것에 성공했다.

다음 두번째 문제가 있었다.

처음 계획했던 시나리오는 크롬이나 파이어폭스 검색 기록을 확인해서 특정 시간에 검색한 키워드를 찾아내는 것이었다.

근데 문제는 일단 chromehistory firefoxhistory 플러그인이 리눅스에서는 지원되지 않았다.

그러면 히스토리 파일을 뽑아내야하는데, 파일을 추출 할때 윈도우처럼 filescan 같은 플러그인이 없고 find_file 플러그인 하나로 파일의 메모리 주소 뽑아내고 파일 추출을 다 해야한다.

find_file로 파일의 메모리 주소를 뽑아내려면 파일의 full 절대 경로를 알아야 한다. 크롬은 기본 설치 경로를 생각하고 히스토리 파일을 뽑아낼 수 있겠지만 파이어폭스는 랜덤 문자열의 profile 이름으로 생성된 폴더에 있기 때문에 해당 폴더명을 알아내야하는 과정이 필요한데, lime 포멧은 R-Studio 같은거에서도 분석이 안되서 파일 구조를 확인할 수 없고

bash에서 해당 파일명을 주고자 bash로 직접 해당 폴더까지 접근하는 것을 시나리오 넣기엔 너무 부자연스러웠다. 문제 제작을 위해 고의로 넣은 내용 느낌. 개인적으로 이런거 안 좋아한다.

뭐 어떻게 해서 풀 절대경로를 줘서 파일을 추출하더라도 내용이 제대로 들어있지 않았다.

그래서 히스토리 파일을 뽑아내는 것은 의미가 없었다.

그래서 크롬/파이어폭스 프로세스를 덤프를 떠서 찾아내야 하는데,

yarascan으로 http 뽑아내서 링크들을 뽑아내는 것은 가능한데, 시간 값을 뽑아내려면 뭐 어떻게 잘 해서 뽑아내야할건데 난 모른다.

그래서 문제 지문에 구글 검색으로 첫 번째로 검색한 내용은? 같은걸 할까 했지만 이 경우 구글 검색 링크 "https://www.google.com/search?q=" 로 yarascan 돌리면 바로 나와버리기 때문에 난이도가 매우 낮았다. 이건 볼라티리티 안쓰고 그냥 grep으로도 뽑아낼 수 있으므로 

브라우저 검색 기록을 찾아내는 것은 포기하고

어디서 많이 본 프로세스 뽑아내서 실행하기가 되었다.

근데 또 문제가 있었다. bash에 입력한 명령어는 볼라티리티 플러그인으로 확인할 수 있지만, 출력된 내용은 플러그인으로 확인할 수 없는 것으로 알고 있다.

하지만 그냥 raw로 출력 내용이 남아 있기 때문에 strings랑 grep으로 다 뽑아낼 수 있다.

grep에 키워드가 최대한 걸리지 않도록 플래그를 base64 이중으로 인코딩하는 등의 노력을 했지만

"ASCTF"가 키워드에 걸렸다. "ASCTF{"만 생각하고 이건 생각 못했다. 이건 롸업에도 써놨다.

이걸 롸업 작성하면서 알아서 해당 프로세스의 pid값을 플래그에 추가하는 걸로 문제를 수정하였다.

pid값은 볼라티리티로만 뽑아낼 수 있으니까..

혀튼 리눅스 메모리 포렌식 문제를 제작해보고 다시 풀어보면서 

리눅스 메모리 분석은 윈도우 메모리 분석이랑 비슷하거나 할 수 있는게 더 적었고

실제 분석보다 환경 구성의 비중이 크고 오래걸리고 어렵고 귀찮고 짜증나기 때문에

CTF에서 리눅스 메모리 문제를 보기 어려웠던 이유를 알 수 있었다.

분석 자체만 가지고 어렵게 만들 수만 있다면 프로필 파일은 같이 제공해줘도 되긴 하는데

음

응애

나 뉴비

Q1 objectaid class diagram install error.

-> download objectaid-1.2.2.zip or ojectaid-1.2.4.zip from here.

Q2 objectaid class diagram "finish" button is not working.

-> use old version of eclipse.

오늘까지 객프 과제 마감인데, 오늘 과제하다가 3 2번 화났다.

첫번째는 저번주랑 이번주 할 일이 너무 많았다.

첫번째는 UML만들어야되는데 objectaid 사이트가 터진지 오래라 플러그인을 바로 다운받지 못했고

두번째는 다이어그램생성하는데 finish버튼을 눌러도 아무 반응이 없었던 것이었던거시다.

이클립스에서 UML 간편하게 만들려면 objectaid 플러그인을 사용해야한다.

직접 플러그인을 다운을 받던 이클립스 통해서 설치를 하던 objectaid사이트에서 데이터를 받아오게 되어있다.

그런데 사이트가 몇 달 전에 터진거 같다.  정확히는 도메인 만료되서 연장 안한거 같은데... 6월까지는 살아있던거 같던데..

혀튼 그래서 플러그인 설치하려면 파일을 직접 구하는 수 밖에 없었다. 그래서 여러 사이트랑 블로그 찾아서 파일 2개를 구했다.

https://drive.google.com/file/d/1JNdkcMxQ-hGPKcoS-JaoiwtMgCYiJ7qP/view?usp=sharing 

https://drive.google.com/file/d/1E1YFbVNe-swgLsLvKXb46VQjAxa4Gxd_/view?usp=sharing 

Archive 버튼 눌러서 다운받은 zip 파일 그대로 걸어주면 된다.

이렇게 해결되나 싶더니 문제가 또 발생했다.

finish 버튼을 아무리 눌러도 반응이 없었다. 뭐 오류메세지를 주는 것도 아니고 뭘 하려는 시늉이라도 해야지.. 아무 반응이 없었다.

그래서 또 다른 블로그들 보니까  옛날 버전에서는 된다는 건 확실했고

4.2.1 주노 다운받아서 플러그인 다시 설치해서 성공했다.

힘들었다.

2021-11-24 01:16 작성 2021-11-28 19:42 공개

아주대 사이버보안학과의 날을 맞아 11월 27일 토요일 12:00 부터 23:59까지 12시간동안 후이즈 & 해머 CTF가 개최되었다.

난 포렌식 5문제와 미스크 한 문제를 출제 및 대회 운영 및 관리를 담당하였다.

문제를 제작할 때 항상 참신하고 재밌는 문제를 만들려고는 하는데 쉽지가 않다. 요즘 학교 과제하느라 CTF도 열심히 안하고 포렌식 공부도 거의 안해서 머리 속에 새로운 지식이 없다. 정체된 상황에 올해 대회 문제출제를 두 번 하면서 아이디어가 거의 바닥나 버렸다. 여기서 문제를 더 뽑아내려고 하다보니 문제 퀄리티가 개인적으로 아쉽다.

앞으로도 문제 출제하려면 공부해야겠다..

Official Write up

원래 출제자 롸업 안썼는데 이번 대회에서는 문제풀이 세미나가 없어서 작성하게 됐다.

문제만들면서 플래그 값 설정하는 것도 하나의 재미라고 느끼는데, 이번에는 그냥 문제명이랑 소금 섞어서 md5 해시값을 플래그 값으로 설정했다. 밀린 과제하면서 문제 만들려다보니 시간을 조금이라도 줄이려..

문제 난이도는 사보 학생들만 참여하고 대회 시간이 12시간으로 짧은 것을 고려하여 전체적으로 쉽지만 다양하게 (스테가노, 멀티미디어, 네트워크, 메모리, 디스크) 출제했다.

Forensic

사보의 기묘한 모험 - 436 points, 7 solvers

Whois&HaMer.png 이미지 파일 하나가 주어진다.

해당 파일을 헥스 에디터로 열어서 보면, PNG 푸터 시그니쳐 뒤에 데이터가 존재함을 알 수 있다.

binwalk 명령어를 사용하면 PNG + ZIP + PNG 구조로 이루어진 것을 확인할 수 있다.

가운데 ZIP 파일 영역을 따로 추출(헥스에디터로 직접 뽑아내기, Winhex 기능 사용하기,foremost 사용하기, 다양하다)해서 압축을 풀면 flag.7z 파일이 있으며

flag.7z 파일의 압축을 풀면 flag.txt를 얻을 수 있다.

flag.txt의 내용을 base64 디코딩하면 플래그를 획득할 수 있다.

ASCTF{5B75794CE6A122D57EDAABFE80CD09F1}

그날 본 사진의 크기를 우리는 아직 모른다. - 484 points, 4 solvers

i_found.png 이미지 파일 하나가 주어진다. 이미지 뷰어로 열어보면 아무것도 보이지 않는다.

왜냐하면 사진 크기가 1 * 1로 설정되어 있기 때문이다.

그런데 사진 크기가 1 * 1 가 정상일리 없다.

tweakpng.exe로 열어보면 IHDR 청크의 CRC값이 올바르지 않다고 한다.

따라서 사진의 크기 값이 강제로 수정되었으며, 올바른 크기값을 찾아야한다는 것을 알 수 있다.

IHDR 청크의 구조는 아래와 같다.

데이터 무결성을 검증하기 위한 CRC 값이 포함되어 있는데, 주어진 파일의 CRC 값이 정상이라고 가정할 경우 이 CRC 값을 사용해서 brute force로 원본 크기 값을 찾아낼 수 있다.

주어진 파일의 IHDR CRC 값은 0x770f8fb2 이다.

width 값과 height 값을 0부터 2999까지 브포하는 파이썬 코드 쓱 짜서 돌려주면

금방 나온다.

나온 값으로 수정해주면

플래그를 획득할 수 있다.

ASCTF{9B7ECCDFD7DE68131D92660B786B9725}

포렌식 문제에 페이크 플래그밖에 없는 뉴비포렌서로 환생해버렸다 - 472 points, 5 solvers

ASCTF.pcap 파일 하나가 주어진다.

Wireshark로 열어보면 802.11 패킷들을 확인할 수 있다.

패킷을 살펴보면 누군가에 의한 대량의 Deauthentication 패킷이 발생하였고 이후 HonHaiPr_05:b6:c7의 EAPOL 패킷이 캡쳐된 것을 확인할 수 있다. EAPOL 패킷이 캡쳐되었으므로 이후 데이터 패킷들을 복호화할 수 있다.

aircrack-ng와 rockyou.txt로 사전 공격을 해주면 패스워드 12356789를 얻을 수 있다.

다시 wireshark로 돌아와서 Edit > Preferences > Protocols > IEEE 802.11

이렇게 키를 추가해주면 된다.

복호화된 패킷들에서 http 필털르 걸어주면

flag.zip파일을 다운받은 것을 확인할 수 있는데, flag.zip 파일에서 플래그를 찾을 수 있다.

ASCTF{6746EAC315DADFED3A6CF3F4F8BBE5E2}

메모리 덤프입니디만, 문제라도? - 500 points, 1 solvers

리눅스 메모리 덤프 문제 처음 만들어보는데 만들 때 삽질 많이 했던 문제다. 어떤 삽질들을 했는지는 스터디에 오시면 들으실 수 있..

리눅스 메모리 포렌식 특성상 문제 풀이보다 환경 구성이 더 오래걸리는 문제다.

먼저 mem.lime이 주어진다.

보통 메모리 덤프파일이 주어지면, 프로필을 확인하기 위해 volatility의 imageinfo 플러그인을 사용하려고 하겠지만

절대 나오지 않는다.

프로필을 알아내려면 strings와 grep 명령어를 사용해서 알아내야 한다.

우분투 18.04에 커널은 linux version 5.4.0-42-generic임을 알 수 있다.

리눅스는 리눅스 종류에 커널 종류까지 너무 많아서 볼라티리티에서 프로필을 기본적으로 제공하지 않는다. (https://github.com/volatilityfoundation/profiles 극히 일부만 제공한다.)

따라서 직접 동일 버전의 VM을 구축하여 프로필을 생성해야 한다.

http://old-releases.ubuntu.com/releases/18.04.1/

우분투 18.04.1로 가상환경을 구축하고

커널 버전을 맞춰준 뒤에

https://github.com/volatilityfoundation/volatility/wiki/Linux 을 참고하여 프로필을 생성하면 된다.

$ apt-get install dwarfdump

$ apt-get install build-essential

$ cd volatility/tools/linux

$ make

$ head module.dwarf (module.dwarf 파일이 생성되었는지 확인)

 

$ sudo zip volatility/volatility/plugins/overlays/linux/Ubuntu1204.zip volatility/tools/linux/module.dwarf /boot/System.map-5.4.0-24-generic

vol.py --info에서 프로필에서 확인 가능하면 성공

분석할 준비가 끝났다.

linux_bash 플러그인을 사용해보면 터미널에 입력한 내용을 확인할 수 있는데,

asctf라는 파일을 실행한 것을 확인할 수 있으며

pslist로도 pid 2743에서 확인할 수 있다.

asctf 파일을 추출하는 방법은 여기서는 두가지가 있는데, linux_dump_map을 사용하는 것과 linux_find_file을 사용하는 것이다.

linux_dump_map을 사용하기 위해서 먼저 linux_proc_maps를 통해 start 주소값을 얻어서

linux_dump_map으로 추출할 수 있다.

linux_find_file 을 사용하기 위해서는 정확한 파일 경로를 알아야 한다. 윈도우의 filescan이 있었으면 좋겠지만..

다시 linux_bash화면으로 돌아가보면, 앞에 cd .. cd home cd mandu를 통해 현재 디렉토리 위치가 /home/mandu/ 임을 확인할 수 있다.

따라서 asctf라는 파일은 /home/mandu/asctf 에 위치함을 알 수 있다.

Inode 값을 획득할 수 있고 이 값을 사용해서 다시 linux_find_file을 사용하면 파일을 추출할 수 있다,

이렇게 추출한 asctf파일을 실행해주면 base64 문자열을 획득할 수 있으며 실행결과에 나와있듯이 base64 디코딩 2번 시도해주면 플래그를 얻을 수 있다.

ASCTF{5818F673E8A6EA7BE5524722407090D5_2743}

헥스에디터로 열어서 ASCTF 검색하면 바로 찾을 수 있다.

('ASCTF{' 랑 flag 검색하는거는 막았지만 ASCTF는 못 막았다..)

문제 다시 만들기엔 시간이 없어서 pid값을 플래그에 추가해서 인증하는 것으로 수정했다.

(플래그를 출력하는 프로세스의 pid를 찾으라는 내용이 문제 풀이 방향에 힌트를 주는 것 같지만.. 언인텐으로 간단히 풀리는 것 보단 낫다.)

[대회 종료 후]
예상대로 출력하는 플래그는 많이들  찾으셨지만 pid값은 제대로 찾지 못하셨다.

그런데 문제가 대회 종료 30분 전까지 안풀렸고, 볼라티리티로 잘 안된다는 문의까지 들어와서 
파일 잘 못 올라갔나 하고 식은땀 줄줄 흘리며 체크섬 확인했다. (문제 만들때 삽질을 많이해서 다른 버전의 파일이 올라갔을 가능성이 1%정도 있었다.) 다행히 파일은 풀리는걸로 제대로 올라갔었다. 

아주사보는 후이즈 선배의 꿈을 꾸지 않는다. - 484 points, 4 solvers

ad1 파일이 주어지고, 중요 문서 파일이 암호화되었으니 복호화하라는 문제다.

ad1파일은 autopsy같은 프로그램으로 분석해도 되겠지만 나에게 익숙한 ftk imager로 풀이를 작성한다.

바탕화면을 보면 바로 암호화 '당한 것'으로 보이는 .enc 파일을 찾을 수 있다.

다운로드 폴더에서는 dream.zip파일을 찾을 수 있으며 그 안에는 아주 수상해보이는 ps1파일, bat 파일을 찾을 수 있다.

(롸업 쓰면서 든 생각인데, zip 파일에 암호 걸어서 패스워드를 웹상의 파일 다운로드 경로에 같이 둬서 크롬 방문 기록을 반드시 확인하게 할 걸 그랬다.)

readme에서는 dream_installer.bat를 실행하라고 한다.

dream_installer.bat 은 파워쉘로 dream.ps1을 실행한다.

dream.ps1은 http://35.212.225.5/asctf/hello.pyc 를 임시폴더에 다운받아와 실행한다.

임시폴더에서 hello.pyc를 찾을 수 있다.

hello.pyc는 uncompyle6로 디컴파일 할 수 있다.

간단하다. 단순 xor이다.

important.enc = important.hwp xor key 이므로 바탕화면에서 찾았던 important.enc를 important.hwp로 이름을 바꾼뒤에 hello.pyc를 실행하면 복호화된 important.enc를 얻을 수 있으며 다시 이름을 .hwp로 바꿔서 열어주면 플래그를 획득할 수 있다.

ASCTF{E95312D231A4784B78E631FD91468DBB}

Misc & Crypto

사보 스파이 - 493 points, 3 solvers

에니그마랑 난수방송 합친 문제

책상 1 폴더에서 에니그마 모델명을 확인할 수 있으며 '글자가 적혀있는 종이.pdf'에서 암호문을 얻을 수 있다.

나머지 3개 파일은 의미 없는 파일이다. 패스.

EVZVKSVSLRNARMMAWNUKQTBZQLJRVVSJXEGGVAKEDDBVIWNIIALLZVWGKHDZJCJFJ
VNSZOOSZGZWGFMOQLJSPWARZREXFCJUIOMNZUQWOSEVZQQWSGZOYOZCXMFCOPL
XVJQWCEGRGIMDCCEJNIPPMADJIMDYSYZVNRYRRZHHGYVZHMHAPEHGGMNAQMYUQN
QCTJYJHESOYNJPUONUURFCCWYITLWGCXMPACWHZZWLKWAIYLDMJBHPSGRNTZXUI
WMYXVRIMPRXMQOGRWYWHHENBXQYWUNQTENFLUDLFEMEKVKCNHFWXXPHNYHJV
VBZBOABVPWPGCKOHPGMULSWZOFXFMVPGSPQAAMJBDNESNWLXZEDRVPFMFGYZAM
QJTHZXGUPSWCXCXJTSAIYFLQPQFXBWHIXOLCFFSHHFAXQKOFWAJYBLDAWIDXXSWF
YIXFPEZJTYGWGZRONJYBXDOZILNJBPSIXZIKMLIJJPCRUZYVNGFOSJGDPNVXBMTBMTPN
OCHOURVHNATIFIBCCFITHPWNOAFAPRCCHZWUBBAQRCVZXQLAOLMDTFMUIQZQLVX
FMMYWAJHMZTFXMPFEDJPJJFHODUZJVLARKQJNKAACXUGQKJBLLIGPHDHKDPTSFJXHG
MOLKNWGSQXTPQEJCROINZZLHYPTQATODLRCEXAMCTRQPOGAMRYEZAASWWTXBAT
VVLTGOAUEBQTOQGFDWTPIYGEVZMXUUYTBTGSAZEIWPXYVOOZWMHLJOCBPFAFOPZ
KGTFSDJTZBNSEIEJBCFHNWMHFOLTIPIWJBDWSFFNPCJQPYQHEMNNDAJAFXDVABJNAZ
TRUABHXKCAKVPDWYDTKSMVSBQQPBIDSJXEZVPPXRTCGJHBWVGWYZYCDSZBYPARV
UKLNYXAKXJDWVRAYBFPHOGHMJUABKPUONDKITAZEGHTHXMZPALYIWLHONLUOMQ
QIBWVKYJBKXHGGCLRUYTJGQAMXEIJJPVVKOARQZHXCRJQYYAAXMSOMQEZKXVOJUSH
UFMTWCHAFZUDZJQGUKLRWHGWOEDYGQFHCAIKSSEZZAJDHIUBXEOZKVOCHLZVRCZ
CDHPIFNNBIMVITTMCQOYUCUPBEMVOLFIBUHAAULTILYLRSGHBLLQTBICBOPXHKYFY
AGRXCRFAEICVLVQWVRGYEJNRKVUUQEQUBBAUSFFIXGQBIAEBWOILJXKKKMYDHKDKH
LLANHSUWFPYHSFZRRDWPSUBOIQVXPFLREWRTBVJZQEBOEJZMAMFVSWNKFEOTGTH
MLWZBUWDIYSCMKAIQDXGVJYUUPZDIXVECZJXGOQCHGKFQWOXSOHWWZBDHIVAIFPG
BJIYKPMBDSQOJJIKXLYWBURLFLRLBFPGBXZMDSFALOEVMIRSWAPJKODZDMUJGNVNWV
VTWAGLDNWIXPMBOXGQGIMBVHERICXTWTXWJYZZMQGAPZQLLHXPPIKVNAGPHXAUT
CPSGQNWPVKVJTHZCXOUOBOSDPNEYTOOTWWQKJGUPFPMMGLHHNZWJIEDNUICSYYA
KVHDLCVKZLEUCBMKAFRKJTEJARZQXNGTDJZBSXWKQXHDASUUEZDJZELOFWOTAJTJV
GXCMSONEBZQFHZLJUDDUKBAKRPWXMUUOUDFOYHMMWWWRFQFLKCAEXMDFGORB
TZIBUEJAVQJWXRFXCIMYIMKMNCNUTFSQZDFPYNMGUAJNJMTRXBSNPNHQUSYFMOYB
BWRKXZKSSIXCRZSXLCGCKGQAAIWGWYALFIKTKHRPBIZWEMMAUFIWIVIGMPDUKALG
YWIXY

책상2 폴더에는 5개의 이미지 파일이 있는데 빨간색으로 모자이크된 부분들이 존재한다.

학과 사이트 또는 구글 검색 관련 이미지에서 원본 내용 또는 이미지를 찾아서 가려진 부분을 순서대로 가져오면

2 1 5 => II, I, V

B

CSM

EBS

A-B, C-D 이다.

해당 정보들을 가지고 에니그마 복호화를 하면 된다.

참고로 복호화된 내용은 http://security.ajou.ac.kr/security/intro/intro01.jsp 의 파파고 영어 번역본이다.

라디오 방송 폴더에는 mp3 파일이 존재하는데, 들어보면 여러 정수값들을 불러준다.

해당 값 번째에 해당되는 평문의 알파벳들을 뽑아내면 된다. text[불러주는값]

그러면 RETURNTOTHEDEPARTMENTOFSOFTWARE 가 된다.

따라서 플래그는 ASCTF{RETURNTOTHEDEPARTMENTOFSOFTWARE} 이다.

Obligatory Shark

Every Breath You Take

Height and width are empty.

But we have a CRC.

1200 x 675

hmm

found something

she is queen mary

why it is not working?

HASH Cracking

Hash 1

hashcat.exe -a 0 -m 0 hash.txt rockyou.txt

phantomlover

Hash 2

-m 100

fishchips

Hash 3

-m 1700

mommadobbins

Hash 4

sha2-256 -> nothing

ghost -> -m 6900

happyfamily

Hash 5

-m 3200

cowabunga

Hash 6

-m 500

scottiebanks

Hash 7

-m 1800

igetmoney

Steganography

A cornucopia of numbers

bin to ascii

base64 decode

DO{C0nVeR510n_m4Dn355}

The Detective

Queen's gambit

base64 decode

Not exactly Nestene's Autons

Phreak File

cellphone keypad sound

use dtmf

decoded value가 부정확하게 나와서 직접 debug해서 값을 선별했다.

numbers to alphabet

OSINT: Tour de Japan

1 - Dare enter the mirror world

google image search

Tokyu_Plaza

2 - The land of culture

AKIBA

Akihabara

bic_camera_akiba

3 - A childhood favourite

sunshine_city

4 - One of the classics

"Inside Tokyo’s dedicated Nintendo, Pokémon, and Capcom Stores | Solid State Now"

SHIBUYA_PARCO

5.a - The Central Hub

tokyo_station

5.b - This way, Emperor Naruhito

Gyoko-Dori

6

구글 이미지 검색에서 비슷한 위치가 나온다.

(왜 문제 풀 당시에는 못찾았었지.. 구글 이미지검색을 안했었던가..)

오나기 강에서 같은 나무 난간을 찾을 수 있다.

7

거대한 환풍구처럼 보인다. 하지만 저것만 가지고 위치를 판단하기 어렵다.

오른쪽 뒷쪽을 보면 돌 벽이 있다.

이전 문제들이 도쿄에 있었으므로 이번 문제도 도쿄에 있을 것이라고 예상하고 dokyo stone wallls를 검색해본다.

tokyo castle

근처 로드뷰를 확인해보면,

문제의 사진에 나온 가로드의 형태와 비슷한 것을 확인할 수 있다.

이 것으로 이 주변이 맞음을 확인할 수 있다.

주변 영국 대사관 앞에서 같은 구조물을 찾을 수 있다.

8 - A staple drink of Japan

melon_soda

9

울창한 나무들, 연못, 기와지붕, 노란 건물, 하얀 건물이 보인다.

역시나 tokyo로 키워드를 두고 이미지 검색을 하면 tokyo garden이라는 키워드를 뽑아낼 수 있다.

tokyo garden들로 검색을 해보면 그 중에 happo-en에서 사진들 중에 한얀 건물과 연못 사진을 확인할 수 있다.

10

(아니 이건 히라가나 가타카나 한자 읽을 줄 알아야 풀 수 있는 문제 아닐까..)

참고한 롸업에 따르면, 선거 포스터처럼 보이는 곳에 荒川西日三글자를 통해서 아라카와구 니시닛포리 3초메 인 것을 알 수 있다고 한다.

(문제 풀 때 구글 이미지 번역으로 사람이름 알아내서 지역구가 도쿄도 인 것 까지밖에 못알아 냈다.)

이어서 오른쪽 상단 간판에 '테루'가 써져 있는데 호텔의 호'테루'다.

荒川 西日暮里 3丁目 おんぼろホテル을 검색해서  谷中 富士見ホテル임을 알아내고 (못찾겠는데요)

문제 사진 오른쪽 간판 밑에 <-30m 가 써있으므로 호텔 반경 30m 내 사진과 같은 장소를 로드뷰로 찾아낸다.찾은 장소는 谷中 大島酒店인데, 이 곳이 夕焼けだんだん라고 하는 유명한 장소라고 한다.

谷中 Yanaka답은 Yanaka

근데 사진 장소는 아라카와구인데 정답은 다이토구 야나카야? 뭐지

11 - An island of mascots

amami

일본어 대충 읽을 줄 알아서 품 ㅋㅋ

12

13 - The river of Sakura

meguro river

Log Analysis

Part 1 - Ingress

search "cmd"