#About
주어진 바로 가기 파일이 가리키는 대상 중 복사되지 않은 대상의 크기를 찾시오.
(단위는 Byte이며 정답 입력시 단위를 제외한 십진수 아라비아 숫자만 입력)
#Solution
[그림 1] - 문제 파일 확인
해당 문제에서 제공받은 폴더를 열어본 결과 5개의 바로 가기 파일을 확인할 수 있었으며, 문제에서 요구하는 핵심인
복사되지 않은 파일을 찾기위해서는 먼저 MAC Time에 대해 알아야 하며 MAC이 의미하는 바는 아래와 같다
Modified Time
수정 시간
Access Time
접근 시간
Creation Time
생성 시간
문제를 해결하기 위해서는 MAC Time의 시간 정보를 확인하고, 해당 정보가 가지는 의미를 파악하는 능력이 필요하다
[그림 2] - MAC Time 상태 변화
위 [그림 2]는 MAC Time이 상황에 따라 보존 or 변경되는 경우를 표로 나타낸 것이며 포렌식 위키에서 확인할 수 있었다
http://forensicswiki.org/wiki/MAC_times
이 중에서 문제에서 요구하는 것은 "복사되지 않은 대상"이므로 [그림 1]에서 확인했던 바로 가기 파일 5개 중 4개는 복사가 되었음을 추측할 수 있다
파일이 복사가 된 경우, [그림 2]에서 확인할 수 있듯 Access와 Creation 시간이 복사된 시점으로 바뀌고 Modified 시간은 보존 된다.
위 자료를 토대로 파일을 분석한 결과 아래의 (1,2,3,5).lnk 파일이 Modified Time이 2015년으로 보존 된 채로 Creation,Access Time이 2016년으로 변경되었다
[그림 3] - 1.lnk
[그림 4] - 2.lnk
[그림 5] - 3.lnk
[그림 6] - 5.lnk
위 파일들은 전부 복사가 됨으로 인해서 Creation Time과 Access Time이, Modified 시간보다 최근을 가리키며
오로지 4.lnk 파일만이 복사 되지않은 시간을 가리킨다 ( Creation Time < Modified Time < Access Time )
[그림 7] - 4.lnk
따라서 복사 되지 않은 파일은 4.lnk이며 해당 파일의 바이트 크기는 [그림 7]에서 확인할 수 있듯 248435이다
Answer = 248435
[ + ] 문제를 풀며
[그림 1]의 수정한 날짜의 시간과 010 Editor에서 파싱된 시간의 Modified 시간이 서로 일치 하지 않던 것이 궁금했고
궁금증을 해결하기 위해 010 Editor가 아닌 LNK Parser에서 링크 파일 파싱의 결과를 살펴보던 중 궁금증을 해결할 수 있었다
[그림 8] - 시간 비교 ( 010 Editor의 UTC+9 값과 동일 )
[그림 1]의 수정 시간은 링크 파일 자체의 수정 시간을 의미하며, 010 Editor에서의 수정 시간은 링크 파일이 가리키는 원본 파일의 수정 시간을 의미한다
[ + ] TIPS
Windows XP이후 Access Time의 경우 기본적으로, 읽기 작업을 진행할 때마다 Access Time을 업데이트하는 것은 성능면에서 비효율적이기 때문에
Access Time의 업데이트 기능이 비활성화 되어 있으며 활성화를 시키기 위해서는 아래의 경로에서 레지스트리 값을 수정해주어야 한다
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\FileSystem\NtfsDisableLastAccessUpdate
0 = 활성화
1 = 비 활성화
'Wargame' 카테고리의 다른 글
[Cresendo] Memory Problem 01 (0) | 2017.11.09 |
---|---|
[Cresendo] Shim Cache Problem 01 (0) | 2017.11.09 |
[Cresendo] LNK Problem 04 (0) | 2017.11.08 |
[Cresendo] LNK Problem 03 (0) | 2017.11.08 |
[Cresendo] LNK Problem 02 (0) | 2017.11.08 |