Một file hoặc directory mà có một object ID được gán tới nó có một $OBJECT_ID attribute mà chứa object ID và có thể chứa thông tin về original domain và volume mà chúng được tạo. Nếu bạn muốn tìm một file dựa trên object ID của nó, bạn có thể refer tớ \$Extend\$ObjId index. Index này chứa một entry cho mọi assigned object ID trong file system và đưa ra file reference address cho nó.
Phương thức addressing này có thể ảnh hưởng tới người điều tra bởi vì anh ta cần phải locate một file dựa trên object ID của nó.
Allocation Algorithms
NTFS indexes sử dụng B-trees, có nghĩa là không phải là first hay là next available strategories cho việc cấp phát các data structures. Mặc dù, có những biến thể trong cách một B-tree có thể được implement khi nó cần add và remove các entries. Ý tưởng cơ bản là xác định vị trí trong tree mà files thuộc về và add nó vào. Nếu node có quá nhiều entries, nó được phân chia và một level mới được tạo. Quá trình lặp lại cho đến khi tree này còn nằm trong trạng thái valid. Khi delete một file, entry của nó được remove khỏi tree, và các entries còn lại trong node đó lại được di chuyển. Nếu một node có quá ít entries, nó cố gắng mượn các entries từ các node khác vì vậy tree vẫn cân bằng.
Một directory nhỏ sẽ có một node, và nó sẽ được cấp phát tới $INDEX_ROOT attribute. Khi các entries không fit đủ ở đó, OS sẽ move các entries tới một index record trong một $INDEX_ALLOCATION attribute. Tại điểm này, vẫn chỉ có một node trong B-tree, và $INDEX_ROOT không có các entries bên cạnh một empty entry trỏ tới child node. Khi một index record đầy lên, một record thứ 2 được cấp phát, và $INDEX_ROOT attribute sẽ được sử dụng như là một root nod. Children của nó sẽ là 2 index records. Khi những index records này đầy lên, record thứ 3 được cấp phát, và root sẽ có 3 children.
Trong hệ thống mà tôi thấy, các giá trị thời gian và kích thước trong $FILE_NAME attribute được updated tại cùng một tốc độ như các giá trị trong $STANDARD_INFORMATION attribute trong MFT entry của file.
Analysis Techniques
File name category analysis được tiến thành để locate các files và directories dựa trên các names của chúng. Quá trình này yêu cầu việc locate các directories, xử lý các contents, và locate metadata liên kết với một file.
Phân tích NTFS file names và indexes là một quá trình phức tạp. Bước đầu là locate root directory, directory này nằm ở MFT entry 5. Để process một directory, chúng ta phân tích các contents của $INDEX_ROOT và $INDEX_ALLOCATION attributes và process các index entries. Các attributes này chứa một danh sách được gọi là index records mà tường ứng với các nodes trong một tree. Mỗi index record bao gồm một hay nhiều index entries. Một index record còn có thể chứa các unallocated index entries, và record header nhận diện allocated entry cuối cùng được đặt ở đâu. Allocation status của các index records có thể đươc định nghĩa sử dụng $BITMAP attribute của directory. Các allocated files có thể có các unallocated index entries ngoài các allocated entries của chúng bởi vì các directories được lưu trong B-trees và phải được re-sorted khi các files được thêm vào hay xóa đi.
Một file name có thể tương ứng tới một reparse point, những gì là một pointer hay là một mount point. Mục tiêu của reparse point được định nghĩa trong $REPARSE_POINT attribute của MFT entry. Microsoft định nghĩa một vài kiểu reparse points, nhưng các reparse points khác có thể là đặc trưng ứng dụng. Với Microsoft reparse points, vị trí mục tiêu có thể dễ dàng được đọc bởi vì nó là Unicode.
Analysis Considerations
Unallocated file names có thể gây hiểu lầm trong NTFS. Khi các files được thêm vào và xóa đi khỏi một thư mục, tree được re-sorted, và các entries được moved tới các nodes khác và các vị trí khác bên trong một node. Nó làm cho data từ các file bị xóa tồn tại trong allocated space của một tree node và data từ các deleted files có thể bị ghi đè. Unallocated space của một vài indexes có thể chứa nhiều bản sao của data cho cùng một file. Để xác định xem file đó đã thực sự bị xóa, phần còn lại của các indexes phải được searched để xem coi có một bản sao của file name trong allocated space.
Khi tên của một file bị xóa được tìm thấy, có một vài lợi ích so với các file systems khác. Sequence number trong file reference có thể cho ta thấy rằng MFT entry có được tái cấp phát từ khi file bị xóa đi. Nếu MFT entry được cấp phát, MFT entry data có thể không phải là của file name này. Với các file systems khác, bạn phải đoán xem nó có vẫn đang đồng bộ hay không. Một lợi ích khác đó là $FILE_NAME attribute tồn tại trong index này và chứa một tập hợp đầy đủ các giá trị thời gian và các cờ. Do đó, thậm chí nều một MFT entry được tái cấp phát và dữ liệu từ file này bị ghi đè, chúng ta vẫn có những thông tin cơ bản.
Khi cố gắng xác định những deleted files nào tồn tại trong thư mục, một công cụ phân tích nên kiểm tra 2 vị trí. Vị trí thứ nhất là các vùng không được cấp phát (unallocated areas) của mỗi node trong directory index tree. Vị trí thứ 2 là trong các các MFT entries không được cấp phát (unallocated MFT entries). Nếu một file name bị xoá đi khỏi index nhưng MFT entry của nó vẫn còn tồn tại, chúng ta có thể nhận diện ra rằng nó là bộ phận của directory thông qua việc nhìn vào parent directory MFT address của nó. Đảm bảo rằng công cụ phân tích của bạn sử dụng cả 2 thủ tục trên khi nó hiển thị các deleted file names trong một directory.
Analysis Scenario
Trong suốt quá trình điều tra, ta sử dụng Digital Investigator 4000 (DI4K) và một công cụ khác để xác minh kết quả đó là FSAnalyzer (FSA1K). Computer được phân tích có một NTFS File system, và bạn tìm thấy một directory với nhiều mảnh vật chứng. Bạn quyết định so sánh các directory contents giữa 2 tools và tìm thấy một vài sự khác biệt, đó là
1. deleted file aaa.txt không được hiển thị trong DI4K output, nhưng nó xuất hiện trong FSA1K.
2. Các date và time stamps của mmm.txt file là khác nhau trong 2 outputs. Các times của DI4K thì sớm hơn so với các times của FSA1K.
3. Deleted file www.txt được hiển thị trong DI4K output, nhưng ta không thể thấy nó trong FSA1K.
Vấn đề thứ 3 liên quan tới một file www.txt mới, nhưng bạn không nhìn thấy nó trong index. Nhắc lại về các deleted orphan NTFS files, những gì xảy ra bởi vì một deleted name bị ghi đè trong index. Bạn search qua các MFT entries để tìm một entry có name www.txt thông qua việc thực hiện một lo
Sử dụng layout này, bạn có thể thấy tại sao vấn đề thứ nhất xảy ra. FSA1K in aaa.txt file như là một file bị xóa mặc dù file này được cấp phát. Unallocated entry giống như đã được tạo sau khi một file khác bị xóa, và aaa.txt entry được di chuyển trong node. DI4K mới hơn đã tìm kiếm allocated aaa.txt và không in unallocated entry.
Application Category
NTFS là một file system duy nhất mà ở đó nó cung cấp support cho nhiều features mức ứng dung. Có các features không cần phải included vào trong một file system nhưng mà cho phép hệ điều hành hoặc các ứng dụng có thể run hiệu quả hơn. Nó còn có nghĩa là không một trong các features này là quan trọng với mục đích của file system như là lưu (saving) và lấy (retrieving) các files. Thực tế, một user hoặc ứng dụng có thể disable một vài trong số chúng. Trong phần này chúng ta sẽ thảo luận về các hạn mức đĩa (disk quotas), logging (hoặc file system journaling), và change journaling.
Disk Quotas
NTFS bao gồm việc hỗ trợ các hạn mức không gian đĩa (disk space quotas). Các quotas có thể được setup bởi một administrator để giới hạn lượng không gian đĩa mà mỗi user cấp phát. Bộ phận của quota information được lưu như file system data và data khác được lưu trong các files mức ứng dụng, ví dụ như Windows registry. Trong các versions trước 3.0, có tồn tại một \$Quota file system metadata file trong MFT entry 9, nhưng trong các version 3.0+ một file giống như vậy tồn tại trong \$Extend directory và có thể ở trong bất cứ MFT entry nào.
$Quota file sử dụng 2 indexes để quản lý quota information. Một index được đặt tên $O, và nó phối hợp với một SID với một owner ID (chú ý rằng đó là Windows SID thông thường và không phải là ID chúng ta đã thấy trong security descriptors). Index thứ 2 được đặt tên là $Q và nó phối hợp với một owner ID với các chi tiết bao nhiêu bytes mà được nạp (charged) tới quota của user và bao nhiêu bytes anh ấy được phép.
Analysis Considerations
Quota được tính như là non-essential bởi vì một hệ điều hành không cần sử dụng quota information khi nó sử dụng file system. Ví dụ, một OS khác có thể mount một NTFS file system và không update quota khi một user tạo một file. Quota có thể hữu dụng cho forensic analysis khi cố gắng xác định các users nào lưu một số lượng lớn dữ liệu. Ví dụ, nếu bạn tìm một system với nhiều accounts và một số lượng lớn phim lậu , bạn có thể sử dụng quota files để xác định user nào tạo ra chúng. Bạn có thể có được thông tin giống như vậy khi nhìn vào $STANDARD_INFORMATION attribute của mỗi file. Quota system không được bật lên bởi mặc định, vì vậy dữ liệu này không tồn tại cho hầu hết các hệ thống.
Logging - File System Journaling
Để cải thiện tính đáng tin cậy của một file system, Mirosoft thêm vào journaling tới NTFS. Họ gọi nó là feature logging, nhưng thông thường trong các hệ thống khác gọi là journaling. Một file system journal cho phép một hệ điều hành nhanh chóng mang một file system về một trạng thái clean. File system thường trở nên bị corrupt nếu hệ thống crash trong ghi dữ liệu đang được ghi tới file system. Journal record thông tin về các metadata updates trước khi chúng xảy ra và sau đó record khi các updates được thực hiện. Nếu hệ thống crash trước khi journal record mà update vẫn được thực hiện, hệ điều hành nhanh chóng thay đổi hệ thống ngược về known state.
NTFS log journal file được đặt trong MFT entry 2, được đặt tên là $LogFile. MFT entry này không có bất kỳ attributes đặc biệt nào, và log data được lưu trong $DATA attribute. Tôi phát hiện ra rằng log file có kích thước nằm trong khoảng từ 1 đến 2 phần trăm tổng kích thước của file system.
Log file có 2 sections chính: vùng bắt đầu (starting area) và logging area. Như ta có thể thấy trong Hình 12.11, restarting area chứa 2 bản sao của một cấu trúc dữ liệu mà giúp OS xác định các transactions nào cần được phân tích khi một cleanup được thực hiện. Nó chứa một con trỏ trong logging area cho transaction cuối cùng.
Có rất nhiều kiểu records, nhưng Microsoft mô tả chỉ 2 trong số chúng. Update record là phổ biến nhất và được sử dụng để mô tả một file system transaction trước khi nó xảy ra. Nó còn được sử dụng khi file system transaction được thực hiện. Nhiều transactions yêu cầu nhiều hơn một record bởi vì chúng được chia ra nhiều hoạt động nhỏ hơn, và mỗi hoạt động có một update record. Ví dụ của file system transactions bao gồm
- Tạo một file mới hoặc directory
- Thay đổi nội dung của một file hoặc directory
- Renaming một file hoặc directory
- Thay đổi bất cứ dữ liệu được lưu trong MFT entry của một file hoặc directory (user ID, security settings, và tương tự).
Không có nhận xét nào:
Đăng nhận xét