01. ReFS 개요 및 주요 특징

1) ReFS(Resilient File System) 개요

마이크로소프트(Microsoft)에서 데이터 가용성을 극대화하고 다양한 워크로드의 대규모 데이터 집합을 확장하면서 손상에 대한 복원력과 데이터 무결성을 바탕으로 설계된 ReFS는 시스템 레질리언스를 확보하기 위한 목적에 맞게 복원 파일 시스템(ReFS, Resilient File System)이라고 할 수 있다. 2012년 Windows Server 2012 운영체제부터 도입이 되었으며 확장되는 스토리지 시나리오를 해결함으로써 복원력과 성능, 확장성의 장점을 기반으로 현재도 업데이트를 통해 다양한 기능을 지원하고 있다.

ReFS는 대용량 데이터를 안정적으로 다루기 위한 목적으로 설계되었기 때문에 주로 기업이나 서버 환경에 활용되고 있다. 현재 ReFS을 지원하는 대상은 Windows Server 환경 운영체제인 2012, 2016, 2019, 2022 모두 지원되며, Windows 8 이상의 운영체제인 클라이언트 대상에서도 지원되고 있다. 현재 많은 시스템에서 범용적으로 사용되고 있는 NTFS(New Technology File System)를 대체하기 위해서 설계된 ReFS는 기존의 NTFS와도 파일 시스템 구조상에서 상당히 유사성을 띠고 있다. Windows 11 업데이트 소식에서는 NTFS가 ReFS로 대체된다는 소식도 들려오고 있어 차세대 파일 시스템으로서 ReFS가 주목받고 있다.

일각에서는 ReFS의 안정성에 대해서 일부 이견이 나오고 있으나 파일시스템의 복구 메커니즘의 안전성을 강화하기 위해서 지속적인 업데이트와 개발을 진행하고 있으며, 2023년 기준으로 최신 버전인 3.9 버전이 공개되어 있으며 3.10 버전이 개발을 진행하고 있다. ReFS가 NTFS와 유사하기는 하나 복원력과 확장성 등의 강화를 위한 목적으로 별도 트랜잭션 로그 파일을 사용하여 메타데이터 정보를 기록하는 구조적 차이가 존재하며, 운영 중인 모든 환경을 ReFS기반으로 운영하거나 침해사고 시에 아티팩트 등을 분석하기 위해서는 더욱 많은 연구가 필요한 실정이다.

그럼에도 불구하고 차세대 파일 시스템으로써의 가능성과 방향성을 고려해 보면 ReFS에 대한 고찰이 필요한 시점이라고 볼 수 있다. [표 1]과 같이 Windows 환경 이외의 애플이나 리눅스 기반의 파일 시스템과 비교해 보더라도 ReFS 파일 시스템만의 무결성과 저널링(Journaling)을 통한 트랜잭션 기록이나 스토리지 공간 관리 등의 장점이 있기 때문에 이번 호에서는 차세대 파일시스템으로 부각되고 있는 ReFS에 대해서 살펴보고자 한다.

2) ReFS의 주요 특징

ReFS는 NTFS의 뒤를 이을 차세대 파일 시스템답게 기능이나 복원력 면에서 NFTS에 비해서 강력한 기능들을 제공하고 있다. 손상된 데이터를 주기적으로 모니터링하여 추적한 후 자동으로 수정하기 때문에 파일 시스템의 무결성과 데이터 유효성 및 가용성을 향상할 수 있는 장점을 가지고 있다.

ReFS는 안정성 또한 개선되었다. ReFS는 모든 메타데이터 및 파일 데이터를 포함하여 온디스크 구조에서 B+트리를 사용한다. 이러한 온디스크 구조에는 ‘테이블’이라는 개념이 포함되어 참조 수단으로 Object ID가 사용되는데, 모든 테이블을 인덱싱하여 [그림 1]과 같이 디렉터리처럼 표시할 수 있기 때문에 효율적인 사용이 가능하고 확장성에 대한 용이성을 가질 수 있게 된다.

ReFS는 파일 시스템의 안정성을 확보하기 위해서 데이터 접근 방식을 설계할 때 AOW(Allocate-On-Write) 방식을 채택하였다. 기존 NTFS와의 방식과는 달리 변경된 메타데이터 파일의 Page를 기존의 데이터에 수정하지 않고 새로운 위치에서 데이터를 할당하는 방식이다. 따라서 오류 복구 논리를 완벽하게 활용할 수 있으며, NTFS의 트랜잭션보다 안정적이고 효과적으로 트랜잭션을 기록하게 된다.

복원력 측면에서도 높은 수준을 보여주는데 ReFS는 손상된 데이터에 대해서도 자동으로 검사하고 오류를 해결한다. 이는 파일 시스템의 데이터에 대한 무결성과 가용성의 성능 향상을 말해준다. 또한, ReFS는 모든 메타데이터에 대해 B+Tree를 사용하므로 해당 메타데이터에 대한 체크섬(checksum)을 진행한다. 따라서 모든 데이터의 오류들을 검출해 낼 수 있으며 [그림 2]처럼 CHKDSK와 같은 오류 검사 도구 또한 필요하지 않다.

ReFS는 NTFS의 소스 코드를 기반으로 개발되었기 때문에 새로운 시스템 API가 필요하지 않으며, 대부분의 파일 시스템에서 가지는 기존 API 및 기술과 호환성을 지니고 있다. 예를 들어, BitLocker, 접근 제어 목록(Access Control Lists), USN 저널 등 기존 NTFS 기능들을 ReFS에서도 지원한다. 또한, 데이터 미러링 및 스트라이핑을 허용하여 시스템 간에 저장소 공간에서 미러링된 저장소를 주기적으로 읽으며 해당 체크섬을 확인한 뒤 오류를 수정하는 데이터 스크러빙 프로세스(Data Scrubbing process)도 내부적으로 동작하고 있다.

디스크 성능적인 측면에서 ReFS는 NTFS보다 어느 정도 차이가 나지만 눈에 띄게 향상되는 차이는 아니다. [그림 3]과 같이 벤치마크 소프트웨어를 사용하여 ReFS와 NTFS 모두 동일한 조건에서 성능 테스트 시 비슷한 결과를 보여준다. 이처럼 ReFS는 NTFS보다 일반적으로 성능이 더 높지만 모든 면에서 NTFS보다 뛰어나지 않고 사용 환경에서 각 파일시스템의 최적화된 성능 차이도 나타날 수 있다.

ReFS의 장단점은 NTFS의 장단점과 트레이드 오프 관계에 있다. 예를 들어 ReFS에서 두드러지게 나타나는 복원력은 NTFS에서는 도구 및 솔루션 등으로 제한적으로 복원될 수 있지만 ReFS에서는 chkdsk를 사용하지 않고도 메타데이터에 대한 뛰어난 복원력 및 무결성을 제공한다. 반면에 ReFS의 단점은 NTFS의 장점이기 때문에 이는 사용자가 파일 시스템을 선택하는 중요한 요소가 될 수 있다.

3) ReFS 파일 시스템 구조

[그림 4]는 ReFS 볼륨을 Hex 편집기로 확인한 결과이다. 0x03 부터 4바이트 범위에는 ReFS 파일 시스템 이름이 확인되었다. 또한, ReFS에는 “FSRS”라는 식별자도 확인되는데, 이는 파일 시스템 인식 구조(File System Recognition Structure)를 의미하며, 운영 체제가 구조를 인식하여 사용 중인 파일 시스템인 ReFS가 유효한 파일 시스템인지 확인할 수 있는 식별자를 의미한다.

ReFS는 부팅이 불가능한 드라이브이기 때문에, 현재로서는 볼륨 부트 레코드가 파일 시스템에 존재하지 않는다. 하지만, NTFS와 비슷한 점프 지시자 이후 ReFS와 파일 시스템을 식별하는 FSRS의 식별자를 통해서 추후에 ReFS가 부팅 가능한 드라이브로 기능을 가지게 될 것으로 추측한다.

02. ReFS의 운영체제 특장점

1) 데이터에 대한 무결성 스트림

ReFS 파일 시스템은 무결성 스트림이라는 기능을 활용하여 각각 파일에 대한 손상의 원인을 파악하고 빠른 복원력을 자랑한다. 무결성 스트림을 활성화하면, 볼륨 데이터 및 메타데이터에 대한 체크섬을 생성하여 작동하기 때문에 ReFS는 체크섬을 비교하여 개체가 손상되었는지를 확인한다. 하지만, 이러한 기능을 사용하기 위해서는 수동적으로 사용자가 활성화해 줘야 한다.

ReFS는 파일 시스템 메타데이터에 대해 기본적으로 무결성 스트림이라는 것이 활성화되어있기 때문에 다른 파일 시스템에 비해 복원력이 뛰어나다. 하지만, 특정 개체에 대해 무결성 스트림을 확인해 보면, [그림 5]와 같이 비활성화되어있는 것을 확인할 수 있다. 이는 Microsoft에서 Storage 성능에 영향을 미치는 것으로 파일 및 볼륨 수준을 위해 기본적으로 비활성화 상태인 것으로 확인된다.

따라서, 무결성 파일 시스템을 활성화하기 위해서 ‘Set-FileIntegrity’를 사용하여 각 개체에 대해 무결성 스트림을 활성화해 줄 수 있다. [그림 6]과 같이 개별적으로 개체에 대해서 활성화 및 비활성화 작업을 수행할 수 있다.

원활한 복구 작업을 수행하기 위해서는 저장소 중복성 또한 활성화해 줘야 한다. 다시 말해, 저장소에 물리 디스크에 대한 미러링 기능이 필요하다. 이것은 Windows Server Storage Spaces Direct와도 연관성이 있다. 따라서 실사용에서 복잡한 절차가 요구되며, 구현이 매우 어렵다.

하지만, 무결성 스트림과 저장소 중복성 또한 만족한다면 ReFS 파일 시스템 복구가 자동으로 이루어진다. ReFS 파일 시스템은 자동으로 무결성 스커러버 메커니즘을 활용하여 손상을 추적하기 때문이다. 이에 대해 사용자는 ‘Repair-FileIntegrity’를 사용하여 수동적으로 개체에 대해 복구할 수 있다. [그림 7]과 같이 저장소 중복성을 만족하지 못한다면, 복구 명령 작업에 오류가 난다.

[그림 7] 저장소 중복성 에러에 대한 명령어 오류

무결성 스크러버는 정기적으로 볼륨을 검사 및 식별하고 데이터에 접근하기 전에 무결성의 유효성을 자동으로 검사한다. 또한, 자주 접근하지 않는 데이터의 유효성을 검사할 수 있도록 트리거를 설정할 수도 있다. [그림 8]과 같이 사용자가 직접 작업 스케줄러 환경 구성을 변경할 수 있는데, 백그라운드에서 동작하는 무결성 스크러버를 사용자 환경에 맞게 설정할 수 있다.

결과적으로, 데이터의 일관성과 무결성을 유지하며 데이터의 손실과 손상을 방지할 수 있고 저장소 중복성으로 ReFS 파일 시스템의 백그라운드 기능을 통해 자동적 복구가 가능하다. 하지만, 제한된 플랫폼으로써 일반적인 소비자가 사용하기엔 부적합하며, 아직까진 일부 버전에서만 사용이 가능한 점이 있다. 또한, 호환성 문제가 존재하고 성능 제한이 존재할 수도 있어서 기업 환경에서의 ReFS 사용이 유용할 것으로 보인다.

2) ReFSUtil을 통한 데이터 복구

ReFSUtil은 손상된 ReFS 파일 시스템을 진단하고 복구하는데 유용한 도움을 주는 도구이다. 해당 도구는 ‘%SystemRoot%\Windows\System32’에 위치해 있으며 기본적으로 Windows의 최신 버전이라면 실행할 수 있는 도구이다.

해당 명령어의 가장 큰 장점은 사용이 쉽고 빠른 복구이다. 또한, 수동 복구도 지원하기 때문에 적절한 매개변수를 활용하여 사용자가 데이터를 복구할 수 있도록 해준다. 하지만, ReFS 특성상 큰 파일 시스템에 대해 스캐닝을 하므로 예측할 수 없는 결과가 나오기도 하고 복구하기 어려운 데이터도 포함되어 복구되기도 한다. 한 가지 예시로 다음을 살펴보자.

[그림 9]와 같이 ReFS 3.9에서 ReFSUtil 테스트를 진행하였으며 ReFS 파티션에 총 10GB 정도를 할당하였다. 데이터의 무결성과 유효성을 테스트하기 위해서 폴더 및 파일 생성, 수정 및 삭제 등을 진행했으며 프로그램으로 인한 파일 강제 삭제 복구 테스트도 진행하였다.

[그림 10]과 같이 Powershell을 통해 명령어를 입력했으며 다양한 ReFSUtil 옵션 중 빠른 자동 검사를 통해 진행했다. ReFS Salvage를 통해 매개변수 ‘QA’를 사용하여 빠른 스캔 후 복사를 진행했으며 ReFS 대상 볼륨과 작업 디렉터리 및 대상 디렉터리를 사용한다. 대상 볼륨은 E 볼륨으로 해당 볼륨이 손상된 ReFS 파일 시스템이고, 작업 디렉터리는 ‘C:\Temp’로 ReFSUtil 명령어의 로그 파일을 저장한다. 대상 디렉터리인 ‘C:\Recover’는 복구된 파일을 저장하는 저장소 역할을 하므로, 작업이 끝나면, 해당 위치에 복구된 파일들이 위치한다.

[그림 11]과 같이 Recover 폴더 내에는 복구된 파일들이 저장되었으며, 비록 빠른 스캔 명령어일지라도 $RECYCLE.BIN 폴더와 System Volume Information 폴더를 통해서 복구가 잘 된 것을 확인할 수 있다. $RECYCLE.BIN 폴더 내부에는 사용자가 휴지통으로 삭제한 파일까지 복구한 것을 확인할 수 있다. 또한, Temp 폴더 내에는 ‘foundfiles’, ‘metadata’, ‘LCN’ 등이 있으며 각 파일들은 복구에 관한 로그를 보여준다. 볼륨의 서명과 파티션에 대한 파일 스캔 정보를 보여주기 때문에 로그 파일로써 유용한 정보가 될 수 있다.

3) 하드링크(Hardlink) 지원

ReFS 3.5 버전부터 하드링크를 지원하기 시작했다. 하드링크는 유닉스 계통에서 널리 쓰이고 있으며 동일한 데이터를 가리키는 두 개의 논리적인 파일을 만드는 방법이다. 하드링크는 데이터가 존재하는 위치를 직접 가리키고 있기 때문에 속도 측면에서 심볼릭 링크보다 빠르다. 하지만 파일 시스템 외부에 존재하는 파일을 참조할 수 없다는 단점도 가지고 있다.

ReFS의 3.5 이상부터 하드링크를 지원하면서 데이터가 직접 가지는 속도 측면을 향상했다고 볼 수 있다. 또한, 하드링크 특성상 내부 존재의 파일을 참조하기 때문에 ReFS 파일 시스템을 보다 효율성 있도록 빠르게 참조할 수 있다. [그림 12]의 테스트를 통해서 ReFS 3.4 버전에서는 윈도우 하드링크를 지원하지 않는다는 것을 확인할 수 있다.

이러한 ReFS 하드링크 지원의 장점은 데이터 일관성과 시스템 관리 용이성을 만족시킬 수 있다는 점에서 ReFS의 발전을 도모할 수 있다. 또한, 서버에서 중요하게 여기는 백업과 저장 공간의 절약에서 효율적으로 활용할 수 있게 해주며 중복성을 줄여주는 장점을 가지게 된다.

03. ReFS 파일 시스템 저널링

1) 저널링(Journaling) 개념

‘저널링(Journaling)’은 ‘여정‘을 뜻하는 ‘Journey‘에서 파생된 단어로, 파일 시스템에서의 저널링은 모든 변경사항 이력들을 저널 영역에 저장하는 활동을 의미한다. 저장소에 데이터를 저장하기 전에 변경 내역을 기록하기 때문에, 시스템 및 저장소 공간 등에 장애가 발생했을 경우 저널을 통해서 빠른 피해 복구가 가능하다.

ReFS에는 파일 시스템 변경을 기록하는 Change Journal과 트랜잭션 저널링 기능에 대한 Logfile이 존재하여 파일 시스템에 대한 작업 기록을 확인할 수 있다. 해당 저널링에 대한 파일 및 구조는 NTFS의 $UsnJrnl, $LogFile에 유사한 특성이 있다. 해당 파일들은 포렌식 아티팩트로써 활용될 수 있으며 ReFS 개발이 진행되면서 현재까지 연구 중인 기능이다.

ReFS에서 Logfile과 Change Journal이라는 저널링 파일은 기존 NTFS, EXT 및 APFS 파일 시스템과도 유사한 트랜잭션 개념이지만, NTFS 파일 시스템 내부에 존재하는 $UsnJrnl 및 $LogFile과 다른 개념이다. 즉, 변경 및 삭제에 대한 기록은 일부 유사한 동작이 이루어지나 저널링 파일에 대한 개념은 다르다는 것이다.

[그림 13]과 같이 ReFS의 저널링 메커니즘은 파일 및 디렉터리 생성, 변경 등의 이벤트에 대해서 해당 페이지와 관련된 작업이 발생하는 것을 알 수 있다. 이벤트가 발생하면 페이지가 업데이트되므로 업데이트된 페이지는 페이지의 테이블안의 키와 값들이 변경됨을 의미한다. 따라서 모든 이벤트는 하나의 트랜잭션으로 간주하여 정보들로 저장된 뒤 Logfile에 기록된다.

[그림 14]와 같이 메타데이터 파일 내 구조를 확인하면 트랜잭션이 기록되는 Logfile은 Logfile Information Table에 저장된다. 또한 Logfile Information Table은 Object ID Table에 포함되기 때문에, Object ID Table을 해석하면 Logfile Information Table의 위치를 알 수 있다.

Logfile Information Table은 [표 2]와 같이 Row 필드로 나타낼 수 있으며 Logfile의 데이터 영역의 위치 및 크기 정보들을 포함하고 있다. 또한, Logfile의 컨트롤(Control) 영역에 대한 정보를 담고 있어서 마지막 Log Record가 쓰인 위치를 알 수 있다. 따라서 Logfile Information Table을 참조하여 정보를 수집하는 것이 ReFS에 대한 추가 정보를 획득할 수 있다.

ReFS에서는 트랜잭션이 성공적으로 실행되면 해당 기록에 대한 항목이 로깅(Logging) 영역에 기록된다. 기록된 항목에는 트랜잭션에 대한 자세한 작업 및 정보가 포함되어 있다. 또한 해당 기록에는 시점의 상대적 순서를 설명하는 LSN(Log Sequence Number)과 기타 데이터가 저장되어 있다. 이러한 모든 기록에 대한 항목들은 디스크에 기록되기 전에 계산되는 체크섬으로부터 보호된다.

저장하는 데 사용되는 저널링 데이터 크기는 항상 4KiB(4096 바이트)이다. 로깅 영역 내의 오프셋에는 해당 로그 페이지가 존재하는데, 로그 페이지는 모두 동일한 구조를 공유한다. 이러한 목적은 트랜잭션에 대한 실행 작업을 다시 캡슐화하여 로그 페이지에 Redo 데이터를 기록한다. Redo 데이터의 기록은 메타데이터 파일의 Page에서 변경되거나 추가될 각각의 데이터가 Redo Record로 취급된다.

이러한 Redo Record가 모여 하나의 Log Record로 기록되며 Log Record는 Logfile에 저장된다. 결론적으로 Logfile은 Logfile Information Table을 통해 접근하며 Logfile Information Table은 Logfile의 컨트롤 영역을 통해 주소 정보를 가지고 있는 메타데이터 파일이다. 구성도는 [그림 15]와 같이 나타낼 수 있으며 NTFS와는 달리 컨트롤 영역과 데이터 영역이 연속되어 할당되지 않음을 알 수 있다.

Logfile Information Table은 ReFS 파일 시스템 내부에서도 [그림 16]과 같이 찾아볼 수 있다. 0xB4090부터 8바이트에 해당하는 값은 key 값이며, 그 이후 0xB4098의 8바이트는 Value 값으로 “Logfile Information Table”으로 알 수 있다. 0xB40D0 ~ 0xB40D7 오프셋 범위를 통해서 Logfile의 데이터 영역 시작 주소를 확인할 수 있다.

[그림 17]과 같이 Logfile Entry 구조는 위와 같다. 전체 Entry 크기는 120 바이트 크기로 Logfile에서 Log Entry를 식별할 수 있도록 0x00:0x04 범위에 ‘MLog’ 시그니처가 할당되어 있으며 LSN으로 현재 Log Entry와 이전 Log Entry를 확인할 수 있다.

Log Record에 저장되는 데이터는 컨트롤 영역과 데이터 영역에 따라 다르다. 컨트롤 영역에는 NTFS $LogFile과 유사하게 다음 레코드가 할당될 위치 정보에 따른 LSN 정보를 관리하는 반면, 데이터 영역에는 파일 시스템의 트랜잭션 데이터가 저장된 Redo Record로 구성된다. 따라서 Redo Record에 대한 정보를 추적하기 위해서는 데이터 영역에 대한 Log Record에서의 정보를 확인해야 한다.

이러한 컨트롤 영역과 데이터 영역에 대한 구분은 Log Record Header에서 확인할 수 있으며, Type 필드인 0xA8:0xB0 범위에 존재한다. Type 필드는 0x01과 0x02로 구분할 수 있으며, 0x01이면 컨트롤 영역으로 구분할 수 있고 0x02면 데이터 영역으로 구분하여 Redo Record 영역에 트랜잭션 내용이 기록되어 있음을 확인할 수 있다.

Redo Record는 Data offset array, Transaction data로 구성되어 있으며, Redo record header 내에 포함된 Opcode를 통해서 파일 시스템의 작업과 데이터를 추적할 수 있다. Data offset array에는 트랜잭션 데이터들의 위치 정보와 크기를 저장하고 있고, Transaction data는 트랜잭션에 대한 메타데이터 정보를 담고 있으므로 함께 분석을 진행해야 어떤 작업이 진행되었는지 파악이 가능하다.

[그림 19]는 Redo Record의 Opcode를 정리한 것이다. Opcode 및 트랜잭션 데이터 분석을 통해서 실제 어떤 작업을 수행했는지를 확인할 수 있다. Redo Record에 기록되는 Opcode는 파일 생성 및 삭제 등 이벤트 발생 시 패턴으로 동작하며 확인된 Opcode의 패턴을 통해서 어떤 이벤트가 발생했는지 추적할 수 있다.

1) 저널링(Journaling) 포렌식

[그림 21]은 Opcode를 통해서 파일 생성을 확인하였다. “MLog”를 통해 LogFile Entry Header를 확인하고, 0x28~0x2F는 현재 LSN을 나타낸다. 이후 0x30~0x37은 이전의 LSN 정보를 기록하고 0x54~0x57을 통해 Offset to Log Record Header를 알 수 있다.

다시, Offset to Log Record Header가 나타낸 0x78은 곧 Log Record Header의 시작 값이며, 0x78~0x7F는 현재 LSN을 나타내고 0x90~0x97은 이전의 LSN을 나타낸다. 0xA8~0x0AF는 Type을 기록하기 때문에 현재 0x02로 표현한 것은 데이터 영역으로 구분하여 Redo Record 영역에 트랜잭션 내용이 기록되어 있음을 알 수 있다.

따라서 Redo Record를 확인하여 Opcode 값을 확인하면 ‘Redo Insert Row’라는 Operation임을 알 수 있고 해당 파일을 생성하고 있다는 것을 짐작할 수 있다. Redo Record는 Opcode에서 패턴으로 동작하기 때문에 이러한 트랜잭션의 기록을 따라서 구분 분석해야 활동을 확인할 수 있다.

간단한 예시로 [그림 22]는 Redo Record를 확인하여 Opcode의 패턴을 분석하였다. 확인된 Opcode 패턴은 0x02, 0x05, 0x01 으로 파일 이름 변경 Opcode 패턴이 존재했고, 해당 Table 내 파일 이름 변경 내역이 존재하는 것을 확인했다.

이 외에도 [그림 23]과 같이 ReFS 파일 시스템 내에 존재하는 파일 작업을 분석하기 위해서는 각각의 File Index에 대한 로그를 확인한 뒤 Redo Record를 분석하는 것으로 작업 내역을 확인할 수 있다. 또한 데이터 내 어떤 메타데이터 파일이 적용되고 정보를 의미하는지 담고 있으며 파일의 Key 및 Value 값을 포함하고 있기 때문에 파일에 대한 속성 정보를 탐색할 수 있다.

휴지통으로 파일 삭제 시 나타나는 트랜잭션 로그는 $I 파일을 생성한 후 삭제할 파일을 $R 파일로 변경하는 작업이 진행된다. $R 파일은 [그림 24]와 같이 원본 파일의 이름을 재설정하는 것으로 나타나며 이 작업으로 원본 파일이 휴지통으로 삭제된 것을 확인할 수 있다.

04. 마무리

ReFS 저널링 파일 포렌식은 무결성을 강화하고 손상된 파일을 복구하는 데 도움을 줄 수 있다. 또한, 포렌식 분석을 하는 것에 있어 타임라인 및 활동 추적이 가능하고 파일 시스템의 변화를 추적하고 복구하는 데에도 기여를 할 것으로 전망된다. ReFS 파일 시스템을 이해한다면, ReFS의 각 로그 파일뿐만 아니라 ReFS 파일 시스템 동작을 이해하고 정보를 습득하는 데 사용되어 포렌식 조사에 도움이 될 수 있다. 추가로 해당 정보를 통해서 과거 데이터 처리 작업까지 사용할 수 있기 때문에 포렌식에 유용하다.

ReFS는 기존의 NTFS 파일 시스템을 대체하거나 보완하기 위해 설계되었다. ReFS는 데이터 무결성 및 확장성 등에서 개선되었으며 차세대 파일 시스템 표준을 제시하는 역할을 하고 있다. 또한 ReFS는 대량의 데이터와 스토리지 요구를 충족시키는 데에 중요한 역할을 할 것으로 기대받으며, 현대적인 기업과 환경에서 ReFS는 안정성과 확장성을 만족하고 능가할 것으로 보인다. 추가로 ReFS는 지속해서 개선되고 있으며 ReFS가 가지고 있는 한계에 대한 변화와 개발이 필요할 것으로 기대해 본다.

05. 참고

1) ReFS(복원 파일 시스템) 개요
https://learn.microsoft.com/ko-kr/windows-server/storage/refs/refs-overview
2) Forensic Analysis of the Resilient File System (ReFS) Version 3.4
https://d-nb.info/1201551625/34
3) ReFS 저널링 파일 분석
https://www.kci.go.kr/kciportal/ci/sereArticleSearch/ciSereArtiView.kci?sereArticleSearchBean.artiId=ART002513085
4) Intercept Flutter traffic on iOS and Android (HTTP/HTTPS/Dio Pinning)
https://blog.nviso.eu/2022/08/18/intercept-flutter-traffic-on-ios-and-android-http-https-dio-pinning/
5) REFS FILE SYSTEM
https://www.ntfs.com/refs-basics.htm
6) Forensic Investigation of Microsoft's Resilient File System (ReFS) / http://resilientfilesystem.co.uk/index