[DFC] Digital Forensics Challenge 2025 - 문제풀이 및 논문 리뷰이번 글에서는 2025년 참가했던 "Digital Forensics Challenge"의 문제를 풀어보겠습니다. 먼저 "Digital Forensics Challenge"는 한국정보보호학회에서 주관하는 디지털포렌식 대회입니다. 2025년 기준으로 8월 1일부터 9월 30일까지 진행되었으며, 문제풀이 부문과 Tech Contest 영역으로 구분됩니다. 문제풀이 부문은 대회 시작일에 20문제를 일괄 공개하며, 주어진 기간 내 보고서를 작성하여 제출하는 방식으로 이루어집니다. 본 보고서에 다루볼 문제는 논문과 함께 읽어보면서 풀이가 필요한 205번 대해 풀이를 진행해보겠습니다. --- ## **205 – Hide and Seek** 개요 : 데이터 서버의 디스크 이미지를 압수하였다. 해당 디스크 이미지에는 여러 파일과 데이터가 은닉된 것으로 확인된다. 파일시스템 메타데이터(Superblock, Inode, Timestamp 등)을 활용하여 은닉된 데이터를 찾아내고 복구하여라. 먼저 문제에서 "disk.img" 파일 한개가 주어졌으며, 해당 파일시스템은 xfs였습니다. 풀이를 진행하기 앞서 문제 풀이의 방향성을 찾기위해 자료 조사를 하던 중 "Data hiding in the XFS file system" 논문을 발견하였습니다. 해당 논문에서는 XFS 파일시스템에서 은닉 가능한 방법 5개에 대해 설명합니다. 1. Superblock Slack Space 2. Inode Slack Space 3. Free List Area 4. Free Inodes 5. Nanosecond Timestamps 위 기법 중 일부를 사용하여 문제를 풀이할 수 있어 간략히 정리하면 아래와 같습니다. ### 1. Superbloack Slack Space 논문에서 XFS의 슈퍼블록 구조는 각 할당 그룹의 첫 번째 섹터를 차지하며, 실제 슈퍼블록은 512바이트 중 272 바이트만 사용한다고 명시되어 있다. 따라서 나머지 240 바이트는 데이터 은닉에 사용할 수 있지만, 쉽게 탐지할 수 있다고 설명한다. 다만, XFS는 슈퍼블록에 CRC-32C checksum을 저장하므로 데이터를 은닉한 뒤 이 또한 변경해야 한다. SuperBlock의 크기는 파일 시스템의 할당 그룹의 수에 따라 변경된다. 만약 기본적으로 XFS는 대부분에의 시스템에서 4개의 AG를 사용하므로 약 960바이트로 제한적인 저장 공간을 제공하지만 AG 구성에 따라 확대될 수 있다. ### 2. Inode Slack Space XFS의 Inode는 inode core, data forks, attribute forks로 구성되어 있다. inode core는 176 바이트를 차지하며,attribute fork가 없는 경우 inode에서 사용 가능한 슬랙 영역은 아래와 같다. > 512-(176+(16 \* X)) 위 식에서 사용된 X는 inode에 존재하는 data forks의 갯수이다. 연속된 파일(single extent) 기준으로 inode 하나당 약 320바이트의 슬랙 공간이 존재한다. ### 3. Free List Area XFS의 모든 Allocation Group(AG)에는 free list 영역이 존재한다. 이는 inode B+Tree의 확장을 대비하기 위해 예약된 공간이다. inode B+Tree는 처음에 할당 그룹에서 하나의 블록을 차지하며, 이후 확장을 위해 할당 그룹에 네 개의 블록이 추가로 예약된다. 예약된 공간에 데이터를 삽입함으로 정보를 은닉할 수 있다. XFS의 기본 블록 크기가 4096바이트이고 4TiB 미만의 모든 파일 시스템에는 4개의 할당 그룹이 존재하는데, 위 방법을 통해 65,536바이트의 은닉 공간이 존재한다. ### 4. Free Inodes XFS는 inode를 64개의 단위(chunk)로 할당한다. 이때 실제로는 사용되지 않았지만 이미 할당된 inode가 존재할 수 있다. inode가 생성되면 기본적인 메데이터(xfs 버전, checksum, UUID 등)만 설정되고, 나머지 공간은 비어있는 상태로 유지된다. 비어있는 공간에 데이터를 은닉하고, 비트맵 구조도 업데이트 하여 사용중인 inode로 변경함으로써 재할당을 방지한다. 만약 inode chunk가 모두 사용되었을 경우 일반 파일을 추가하여 새로운 chunk를 생성하면 추가적인 free inode를 생성할 수 있지만, 사용자가 숨겨진 데이터를 발견할 가능성이 높다. ### 5. Nanosecond timestamps XFS는 최신 파일시스템과 동일하게 나노초 단위의 타임스탬프를 사용합니다. 논문에서는 일반적인 사용자는 나노초 단위의 값을 확인하지 않는다는 점을 이용해 데이터를 은닉할 수 있다고 명시했습니다. xfs inode에는 MACB(Modify, Access, Change, Birth) 형태의 타임스탬프가 존재하며, 4바이트의 Unix time value와 4바이트의 nanosecond component로 구성된다. 이중 nanosecond component의 값을 덮어씌워 은닉을 수행할 수 있으며, 은닉 후 nanosecond component가 9자리에서 10자리로 변경될 수 있기 때문에 하위 3바이트만 데이터 은닉에 사용할 것을 제시다. --- ### 6. 문제풀이 **1."첫번째 은닉된 데이터를 복구한 파일의 SHA-256 해시 값은 무엇인가? (40 points)"** 해당 문제의 풀이 방법은 super bloack slack 영역에 은닉된 데이터가 존재합니다. 272바이트 이후 데이터부터 은닉된 데이터가 존재하지만 헤더 시그니처가 `00 00 00 38 29 61`이며, 푸터 시그니처는 `00 3B` 입니다. GIF 파일의 헤더 시그니처는 `47 49 46 38 39 61`이며, 푸터 시그니처는 `00 3B`로 헤더 시그니처가 일부 손상되어 있는 GIF 파일로 추정할 수 있습니다. 따라서 해당 데이터를 추출하고 손상된 시그니처 `47 49 46`을 삽입하면 작은 크기의 이미지가 나타나는 것을 확인할 수 있습니다. ``` SHA-256 : “764308a95688be904762c4732c39863d3de02db4bb3537b4801c577d7cfdb0ef” ``` **2."두번째 은닉된 데이터를 복구한 파일의 SHA-256 해시 값은 무엇인가? (40 points)"** 두번째 은닉된 데이터는 논문에 명시된 inode slack space 영역에 삽입되어 있습니다. inode 249번을 확인해보았을 때 첫번째와 동일한 `00 00 00 38 39 61`를 확인할 수 있었으며, 250, 251 inode의 slack 영역에도 데이터가 은닉된 것을 확인했습니다. 251번 inode에 은닉된 데이터 마지막에는 첫번째와 동일한 `00 3B`를 확인할 수 있었으며, 249번 inode slack에서 획득한 데이터부터 251번까지의 데이터를 하나로 이여붙여 추출했습니다. 추출된 파일의 손상된 시그니처를 삽입하여 저장한 결과 1번과 동일하게 작은 크기의 이미지가 나타난 것을 확인할 수 있습니다. ``` SHA-256 : “eb7b360ee39a2005c8192118736169ab555317ddff0a76c21ca330749959d762” ``` **3."세번째 은닉된 데이터의 SHA-256 해시 값은 무엇인가? (50 points)"** 문제를 확인하면 파일시스템 메타데이터 (Superblock, inode, Timestamp 등)을 활용하여 은닉된 데이터라고 명시되어 있다. 첫번째, 두번째 은닉된 데이터가 Superblock, inode의 슬랙 공간이었기 때문에 세번째 은닉된 데이터는 Timestamp와 관련이 있을 것이라고 유추할 수 있다. 또한, 논문에서도 나노 초 타임스탬프를 통해서 은닉하는 기법을 소개하고 있어 해당 방법을 통해 접근하였다. 먼저 해당 디스크 이미지를 wsl에 마운트하였다. 마운트 한 뒤 아래 명령어와 같이 inode 순서대로 MACB(Modify/Access/Change/Birth) 타임스탬프를 수집하여 텍스트 파일로 저장하였다. ``` cut -d'|' -f2 ~/xfswork/files_with_inodes.txt | tr '\n' '\0' | xargs -0 stat -c '%n|%y|%x|%z|%w' > /mnt/e/2025dfc/testd/times_by_inode.txt ``` 해당 명령어의 결과로 저장된 txt 파일을 분석 시 `"./ai/1000_F_564265464_mp9OwlBNexenRBJcwg5qhCwOxr4TC3gk.jpg"` 파일만 다른 파일과 달리 Modify 타임스탬프가 2024-02-10 19:09:30.000016160으로 나노초 타임스탬프가 다른 파일과 다른 것을 확인하였다. 해당 파일은 inode 222번 파일이며, 나노초 타임스탬프 영역에 "DFC 2025" 문자열과 inode 슬랙 영역에 "Here it is!" 문자열이 은닉되어 있었다. 해당 문자열을 합치고 hash를 계산한 결과 아래와 같다. ``` SHA-256 : “146a481b7b2b5f879612637a0683a3a4d693df3d19763e61aef1866e648ce301” ``` **4."은닉된 데이터를 모두 제거하고 은닉 이전의 디스크 이미지를 만드는 방법을 서술하시오. (검증용 은닉 이전의 디스크 이미지 MD5 해시 값 : b79ff8b1a233eb2406aa4508d765c961) (70 points)"** 은닉된 데이터가 있는 위치는 Super block, inode 222, 249, 250, 251 이다. XFS는 무결성을 보장하기 위해 CRC-32c 체크섬 값을 사용한다. 문제에서 은닉 이전의 디스크 이미지로 요구하기 때문에, 은닉된 데이터를 00으로 변경하여 주고, 은닉 이전에 Super block과 inode의 CRC-32c 체크섬 값으로 변경하여야 한다. 하지만 inode 222는 해당 파일의 타임스탬프 나노 초에 데이터를 은닉하였기 때문에, 은닉 이전에 타임스탬프 나노 초로 변경한 이후, 해당 슬랙 공간에 있는 은닉 데이터를 `00`으로 변경하여야 한다. 해당 inode 근처의 217\~224의 타임스탬프를 분석한 결과 Modify 가 `2024-02-10 19:09:30.000000000`으로 동일한 것을 확인할 수 있다. 또한 패턴을 확인할 수 있었는데 217번 inode의 chage time은 218번의 access time이 되는 특징을 가지고 있다. 따라서 규칙에 따르면 inode 222의 타임스탬프는 아래와 같다. > inode Number : 222 > > Name : 1000_F_564265464_mp9OwlBNexenRBJcwg5qhCwOxr4TC3gk.jpg > > Modify : 2024-02-10 19:09:30.000000000 > > Access : 2025-07-26 19:54:20.748569413\ > Change : 2025-07-26 19:54:20.749545926 > > Birth : 2025-07-26 19:54:20.748569413 추가로 super block 데이터를 삭제하기 위해 xfs_repair를 사용하였으며, inode 222, 249, 250, 251은 직접 수정했다. inode 249/250/251도 동일하게 CRC32c 값이 변경되었고, 슬랙 공간에 있던 은닉 데이터가 삭제된 것을 확인할 수 있다. \ (inode 249 CRC32c – 75 1A DA B4, inode 250 CRC32c – 85 DE 83 36, inode 251 CRC32c – 24 E8 A0 E9) 이후, disk_repair.img에서 super block(섹터 0), inode 222(섹터 222), inode 249(섹터 249), inode 250(섹터 250), inode 251(섹터 251)을 hex값을 disk_origin.img의 동일한 위치에 값으로 변경해준다. 해당 과정을 완료하면 문제에서 주어진 “b79ff8b1a233eb2406aa4508d765c961”와 동일한 이미지 파일이 생성된 것을 확인할 수 있었다. ### 7. 참고문헌 \[1\] Data Hiding in the XFS File System, Toolan, F., & Humphries, G. (2025). *Data hiding in the XFS file system*. *Forensic Science International: Digital Investigation, 52*, 301884.