[FileSystem Forensics]Object Identifiers

NTFS version 3.0+ cho phép một phương thức thứ 2 cho việc addressing các files và directories thay cho việc sử dung directory và file name thong thường hoặc MFT entry address. Một ứng dung hoặc OS có thể assign một unique 128-bit object identifier tới file, và nó có thể được sử dung để refer file mặc cho name của nó thay đổi hoặc nó được di chuyển tới volume khác. Microsoft products sử dung object IDs khi chúng nhúng các files bên trong các file khác. File được nhúm sẽ được refer bởi object ID của nó vì vậy nó có thể được tìm thấy thậm chí khi nó bị di chuyển.

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.

Không có sự khác biệt trong các outputs khi hiển thị các allocated files. Để hiểu sâu thêm, bạn mở một hex editor và bắt đầu parsing directory index. Sau khi processing $INDEX_ROOT và $INDEX_ALLOCATION attributes bằng tay, bạn tìm thấy rằng index có cấu trúc được hiển thị trong hình 12.10(A). Bạn thấy index entry trong root của index và metadata của nó là trong MFT entry 31, như bạn có thể thấy trong Hình 12.10 (B). Bạn process $STANDARD_INFORMATION attribute cho MFT entry 31 và tìm thấy các times mà FSA1K hiển thị. Bạn cũng có thể process các times trong $FILE_NAME attribute trong index entry và tìm thấy các times mà DI4K hiển thị. Để tìm ra xem output nào chính xác hơn, bạn so sánh các sequence numbers trong index entry và trong MFT entry. Bạn thấy rằng index entry có một sequence number là 3 và MFT entry có sequence number là 4. Do đó, MFT entry được tái cấp phát sau khi mmm.txt bị xóa, và DI4K tool nhìn thấy điều đó và hiển thị dates từ $FILE_NAME index entry.

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.

Logging area chứa một series các records. Mỗi record có một logical sequence number (LSN) , là một gía trị 64-bit. Các LSNs được cấp phát theo một thứ tự tăng dần. Logging area có một kích thước hữu hạn, và khi không có nhiều không gian ở cuối mỗi file cho một record mới, record được đặt tại đầu của file. Trong tình huống này, record nằm ở đầu của log file sẽ có một LSN lớn hơn record đặt ở cuối file. Nói cách khác, LSN được gán tới một record dựa trên thời điểm record được tạo, không phải dựa trên vị trí mà record được đặt. Các records này không cần thiết bị ghi đè khi log quay vò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ự).

[FileSystem Forensics]Links to Files and Directories

NTFS cho phép một file có nhiều hơn một name, điều này xảy ra khi một hard link được tạo. Một hard link trông không có  bất cứ khác biệt gì từ file ban đầu và được cấp phát một entry trong parent directory entry của nó. Link count trong MFT entry header được tăng lên 1 khi một hard link được tạo, và entry này sẽ không được unallocated cho đến khi link count trở thành 0. Nói cách khác, nếu file name ban đầu bị xoá nhưng hard link vẫn còn tồn tại, file sẽ không bị xóa đi. Một MFT entry sẽ có một $FILE_NAME attribute cho mỗi hard link names của nó. Các hard links có thể được tạo bên trong cùng một volume.

NTFS v3.0+ có một feature được gọi là reparse points mà có thể được sử dụng để link các files, directories, và volumes. Một reparse point là một file đặc biệt hoặc directory mà chứa thông tin về những gì link tới nó. Reparse points có thể link tới các files và directories trên cùng một volume, trên các volumes khác, hoặc trên remote servers. Reparse point còn có thể được sử dụng để mount một volume trên một thư mục thay vì mount nó tại các drive letter ví dụ như 'E:\' . Một symbolic link là một reparse point mà link 2 files với nhau, một junction là một reparse point mà link 2 directories lại với nhau, và một mount point là một reparse point mà link một directory với một volume. Windows Remote Storage Server feature sử dụng các reparse points để mô tả server location của file hoặc directory.

Reparse point là các file đặc biệt, và chúng có một flag set trong $STANDARD_INFORMATION và $FILE_NAME attributes của chúng. Chúng còn có một $REPARSE_POINT attribute mà chứa thông tin về vị trí của target file hoặc directory.

NTFS keep tracks các vị trí reparse point sử dụng một index trong \$Extend\$Reparse file system metadata file. Index được sort bởi file reference của reparse point, nhưng nó không chứa vị trí của target.

Ngoài $Reparse file, NTFS keeps track của mount points trong một $DATA trong root directory, MFT entry 5. $DATA attribute, đặt tên là $MountMgrRemoteDatabase, chứa một danh sách của các target volumes mà được trỏ đến bởi các mount points. $DATA attribute này chỉ được tạo khi một mount point tồn tại trong file system.

[FileSystem Forensics] Indexes

NTFS sử các cấu trúc dữ liệu index trong nhiều hoàn cảnh, và phần này mô tả chúng. Một index trong NTFS là một tập hợp các attributes mà được sắp xếp theo một thứ tự. Ứng dụng phổ biến nhất của một index là trong một directory bởi vì các directories chứa các $FILE_NAME attributes.

Trước phiên bản 3.0 của NTFS (trong Windows 2000), chỉ $FILE_NAME attribute nằm trong một index, nhưng bây giờ có một vài phiên bản  khác sử dụng các indexes và chúng chứa các attributes khác nhau. Ví dụ như security information được lưu trong một index, như là một quota information. Phần này cho ta thấy một index trông như thế nào và cách nó được implement.

B-Trees
Một NTFS sắp xếp các attributes theo một cây, nhất là một B-tree. Một cây là một nhóm các cấu trúc dữ liệu được gọi là các nodes mà được liên kết cùng với nhau như vậy có một head node và nó được rẽ nhánh ra các nodes khác. Xét hình 11.13(A) , ở đó ta thấy node A nằm trên đỉnh và nó liên kết tới các nodes B và C. Node B liên kết tới Node D và E. Một parent node là một node liên kết tới các nodes khác, một child node là một node được liên kết tới. Ví dụ, A là parent node của B và C, những nodes là child node của node A. Một leaf node là một node mà không có các links từ nó. các nodes C, D, và E là các leaves.

Các trees hữu dụng bởi vì chúng có thể được sử dụng dễ dàng để sắp xếp và tìm dữ liệu. Hình 11.13 (B) hiển thị cùng một tree như là tree phía bên tay trái, nhưng bây giờ là với các giá trị được gán cho mỗi node. Nếu bạn đang cố gắng từ kiếm một giá trị, bạn nên so sánh nó với root node. Nếu root node lớn hơn, chúng ta nên tìm kiếm child node phía bên tay trái. Nếu root node nhỏ hơn, chúng ta tìm kiếm child node phía bên tay phải. Ví dụ, nếu muốn tìm giá trị 6 , chúng ta so sánh nó với root node, có giá trị là 7. Node này lớn hơn, vì vậy chúng ta đi tới các child phía bên trái và so sánh với giá trị của nó, là 5. Node này nhỏ hơn nên ta đi tới child phía bên tay phải và ta đã tìm được giá trị cần tìm. Chúng ta đã tìm được giá trị với chỉ 3 phép so sánh. Chúng ta có thể tìm được giá trị 9 chỉ trong 2 phép so sánh thay vì 5 nếu giá trị được lưu trong một list.

NTFS sử dụng B-trees, tương tự với binary tree mà chúng ta mới thấy, nhưng có thể nhiều 2 children trên một node. Thông thường, số lượng children mà một node có dựa trên bao nhiêu giá trị mỗi node có thể lưu. Ví dụ, trong binary tree chúng ta lưu một giá trị trong mỗi node và có 2 children. Nếu chúng ta có thể lưu 5 giá trị trong mỗi node, chúng ta có thể có 6 children.

có nhiều biến thể của B-trees, và có các rules mà tôi sẽ mô tả ở đây bởi vì mục đích của phần này là để mô tả các concepts của chúng, không nhắm tới việc mô tả cách bạn có thể tạo một B-tree.

Trong Hình 11.14 hiển trị một B-tree với các names thay cho các số. Node A chứa 3 giá trị và 4 children. Nếu bạn đang muốn tìm kiếm file ggg.txt, bạn có thể nhìn vào các giá trị trong root node và xác định name theo alphabe nằm trong khoảng giữa eee.txt và lll.txt. Do đó, chúng ta xử lý node C và nhìn vào các giá trị của nó. Chúng tìm thấy file name trong node này.

Nào hãy phức tạp hóa vấn đề lên bằng cách nhìn vào cách các giá trị được thêm vào và xóa đi. Đó là một khái niệm quan trọng bởi vì nó giải thích tại sao các file names bị xóa rất khó để tìm thấy trong NTFS. Chúng tôi giả sử chúng ta chỉ có thể fit 3 file names trên node, và file jjj.txt được thêm vào. Thoạt nghe có vẻ dễ, nhưng bạn sẽ nhìn thấy kết quả là việc 2 nodes bị xóa đi và 5 nodes mới được tạo ra. Khi chúng ta locate nơi jjj.txt nên fit, chúng ta nhận diện được nó nên nằm tại cuối node C, theo sau iii.txt name. Hình 11.15 phía trên đỉnh cho ta thấy tình huống này, nhưng không may mắn thay, có 4 names trong node này, và nó chỉ có thể fit được 3. Do đó chúng ta chia đôi node C, di chuyển ggg.txt lên một cấp độ , và tạo các nodes F và G với các resulting names từ node C. Bạn có thể thấy hình 11.15 phía dưới.

Không may mắn thay, node A có 4 giá trị trong nó. Vì vậy chúng ta chia đôi nó và di chuyển ggg.txt tới node trên đỉnh. Kết quả cuối cùng có thể thấy trong Hình 11.16. Thêm một node làm cho di chuyển các nodes A và C và thêm vào các nodes F, G, H, I và J. Bất cứ dữ liệu còn lại nào trong các nodes A và C từ các files bị xóa phía trước đều đi mất.

Bây giờ xóa đi zzz.txt file. Hành động này remove name từ node E và không yêu cầu bất cứ thay đổi nào khác. Phụ thuộc vào việc triển khai, các chi tiết của zzz.txt vẫn có thể tồn tại trong node và có thể được phục hồi.

Để làm cho sự việc càng khó khăn hơn, xét xem nếu fff.txt bị xóa đi. Node F trở thành trống rỗng, và chúng ta cần fill vào nó. Chúng ta move eee.txt từ node I tới node F và move bbb.txt từ node B tới node I. Điều này tạo một tree mà vẫn cân bằng nơi tất cả các leaves vẫn có cùng một khoảng cách từ node H. Kết quả các bạn có thể thấy trong Figure 11.17.

Node B sẽ chứa bbb.txt trong không gian không được cấp phát (unallocated space) của nó bởi vì bbb.txt được move tới node I. Công cụ phân tích của chúng ta có thể hiển thị bbb.txt bị xóa, nhưng thực sự không phải như vậy. Nó đơn giản là bị moved bởi vì fff.txt bị xóa.

Quá trình thêm và xóa các giá trị từ tree cho ta thấy sự phức tạp của nó.

[File System Forensics] NTFS concepts

Everthing is a File
Một trong các khái niệm quan trọng cần biết để hiểu về thiết kế của NTFS đó là dữ liệu quan trọng được cấp phát cho các files. Dữ liệu này bao gồm dữ liệu quản trị file system cơ bản (basic file system administrative data) mà thường được ẩn trong các file systems khác. Thực tế, các files mà chứa administrative data có thể được đặt ở bất cứ đâu trong volume, giống như bất cứ file bình thường nào. Do đó, một NTFS file system không có một layout cụ thể giống như các file systems khác. Toàn bộ file system được xét như là một data area, và bất cứ sector nào cũng có thể được cấp phát tới một file. Chỉ có một layout nhất quán là các sectors đầu tiên chứa boot sector và boot code.

MFT Concepts
Master File Table (MFT) là trái tim của NTFS bởi vì nó chứa thông tin của tất cả các files và các thư mục. Mọi file và thư mục có ít nhất một entry trong bảng này, và chính các entries cũng thực sự đơn giản. Chúng có kích thước 1KB, nhưng chỉ 42 bytes đầu tiên có một mục đích được định nghĩa sẵn. Các bytes còn lại lưu các thuộc tính (attributes), đây là những cấu trúc dữ liệu nhỏ mà có một mục đích rất cụ thể. Ví dụ, một thuộc tính được sử dụng để lưu tên file, và một thuộc tính khác được sử dụng để lưu nội dung của file. Hình 11.1 biểu diễn layout cơ bản của một MFT entry ở đó có một vài thông tin header và 3 thuộc tính.

Microsoft gọi mỗi entry trong bảng là một file record, nhưng trong bài viết chúng ta gọi mỗi entry là MFT entry. Mỗi entry được gán cho một địa chỉ dựa trên vị trí của nó trong bảng, bắt đầu từ 0. Đến nay, tất cả các entries có kích thước là 1024 bytes, nhưng kích thước chính xác được định nghĩa trong boot sector.

Giống như mọi thứ trong NTFS, MFT là một file. Vậy thì MFT cũng có một entry cho chính nó. Entry đầu tiên trong bảng được đặt tên là $MFT, và nó mô tả vị trí trên đĩa của MFT. Thực tế, đó là nơi duy nhất mà ở đó vị trí của MFT được mô tả. Vị trí bắt đầu của MFT được xác định trong boot sector mà thường xuyên được đặt trong sector đầu tiên của file system. Bạn có thể nhìn thấy trong Hình 11.2 ở đó boot sector được sử dụng để tìm MFT entry đầu tiên, entry này cho ta thấy MFT được phân mảnh và đi từ clusters 32 tới 34 và 56 tới 58. Giống như FAT, NTFS sử dụng clusters để nhóm các sectors liên tiếp lại với nhau.

Theo Microsoft, MFT khởi đầu nhỏ nhất có thể và mở rộng khi nhiều entries được cần tới. Theo lý thuyết, một OS có thể tạo một lượng "cứng" các entries khi file system được tạo, nhưng Microsoft cho phép dễ dàng tạo file system lớn hơn khi nhiều không gian được thêm vào từ việc mở rộng volume (volume spanning). Microsoft không xóa đi các MFT entries mà chúng đã tạo.

MFT Entry Contents
Kích thước của mỗi MFT được định nghĩa trong boot sector, nhưng tất cả các versions của Windows sử dụng kích thước là 1024 bytes. 42 bytes đầu tiên của cấu trúc dữ liệu chứa 12 fields, và 982 bytes còn lại là không được cấu trúc và có thể được fill với các attributes. Bạn có thể nghĩ MFT entry như là một cái hộp lớn được sử dụng để lưu tài sản của bạn. Phía bên ngoài hộp là thông tin cơ bản, ví dụ như là tên của bạn và địa chỉ. Thông tin cơ bản tương đương với các trường được gán cứng của MFT entry. Phía bên trong hộp ban đầu thì trống rỗng, nhưng nó có thể được sử dụng để lưu bất cứ thứ gì miễn là nó ở trong một container nhỏ hơn hộp. Điều này tương tự như cách một MFT entry có một kiến trúc bên trong và nó chứa một vài attributes mà chứa thông tin xác định.

Trường đầu tiên trong MFT entry là signature, và một standard entry sẽ có một chuỗi ASCII "FILE.". Nếu một lỗi được tìm ra trong entry này, nó có thể có một chuỗi là "BAAD." Cũng có một trường flag để nhận diện xem entry đang được sử dụng và entry là cho một thư mục. Trạng thái cấp phát của MFT entry có thể được xác đinhj từ $BITMAP attribute trong $MFT file.

Nếu một file không thể fit các attributes của nó trong một entry, nó có thể sử dụng nhiều entries. Khi điều này xảy ra, entry đầu tiên được gọi là base file record, hay là base MFT entry, và mỗi entries phía sau chứa địa chỉ của base entry trong một trong các trường gán cứng của nó.

MFT Entry Addresses
Mỗi MFT entry được đánh địa chỉ tuần tự sử dụng một giá trị 48-bit, và entry đầu tiên có địa chỉ là 0. Địa chỉ MFT cực đại thay đổi theo sự lớn lên của MFT và được xác định bang cách chia kích thước của mỗi entry cho $MFT. Microsoft gọi địa chỉ tuần tự này là file number.

Mỗi MFT entry còn có một số tuần tự (sequence number) 16-bit và được tăng lên khi entry này được cấp phát. Ví dụ, xét MFT entry 313 với một sequence number là 1. File mà cấp phát entry 313 bị xóa, và entry này được tái cấp phát tới một file mới. Khi entry này được tái cấp phát, nó có một sequence number mới là 2. MFT entry và sequence number được kết hợp, với sequence number là 16 bits cao , để tạo nên một file reference address có độ dài 64-bit, như trong Hình 11.3

NTFS sử dụng file reference address để refer tơis các MFT entries bởi vì sequence number là cho việc xác định xác định khi một file system trong trạng thái lỗi (corrupt state) dễ dàng hơn. Ví dụ, nếu hệ thống crash tại một vài điểm trong khi các cấu trúc dữ liệu khác nhau cho một file đang được cấp phát, sequence number có thể xác định một cấu trúc dữ liệu có chứa một MFT entry address hay không bởi vì file trước đó đã sử dụng nó hoặc nó là một phần của file mới. Chúng ta cũng có thể sử dụng nó để khôi phục nội dung bị xóa. Ví dụ, nếu chúng ta có một cấu trúc dữ liệu chưa được cấp phát với một file reference number trong nó, chúng ta có thể xác định MFT entry được tái cấp phát từ khi cấu trúc dữ liệu này sử dụng nó. Sequence number có thể hữu dụng trong suốt quá trình điều tra.

File System Metadata Files
Bởi vì mọi byte trong volume đều được cấp phát tới một file, có sự tồn tại của các files lưu dữ liệu quản trị file system (filesystem's administrative data). Microsoft gọi những files này là metadata files, nhưng điều này có thể gây ra nhầm lẫn bởi vì chúng ta có refer tới file metadata. Chúng ta sẽ tạm gọi những files mang dữ liệu quản trị này là file system metadata files.

Microsoft dành riêng 16 MFT entries đầu tiên cho các file system metadata files. Các entries được dự trữ mà không được sử dụng ở trong một trạng thái được cấp phát (allocated state) và chỉ có những thông tin tổng quát. Mọi file system metadata file được liệt kê trong root directory, mặc dù chúng thường ẩn đi với hầu hết users. Tên của mỗi file system metadata file bắt đầu với "$", và kí tự đầu tiên được viết hoa. Table 11.1 liệt kê các file system metadata cùng với description của chúng để tiện cho việc tham khảo.

 

MFT Entry Attribute Concepts

Một MFT entry có một kiến trúc nhỏ bên trong và hầu hết được sử dụng để lưu các attributes , đầy là các cấu trúc dữ liệu mà lưu một kiểu dữ liệu chỉ định. Có nhiều kiểu attributes, và mỗi attribute có kiến trúc bên trong của riêng nó. Ví dụ, có các attribute cho tên file, thời gian, ngày tháng và thậm chí là nội dung của nó. Đó là một trong những điểm khác biệt của NTFS so với các file system khác. Hầu hết các file systems tồn tại để đọc và ghi nội dung file, nhưng NTFS tồn tại để đọc và ghi các attributes, một trong các attribute đó là nội dung file.

Xét một điều tương tự trước đây một MFT entry như là một hộp lớn mà ban đầu trống rỗng bên trong. Các attributes tương tự như những hộp nhỏ bên trong hộp lớn mà ở đó các hộp nhỏ có thể là bất cứ hình thù nào để lưu đối tượng. Ví dụ, một chiếc mũ có thể được lưu trong một hộp ngắn, và một poster có thể được lưu trong một hộp dài.

Trong khi mỗi kiểu của attribute lưu một kiểu dữ liệu khác nhau, tất cả các attributes có 2 phần: header và content. Hình 11.4 thể hiện một MFT entry với 4 cặp header và content. Header là chung và chuẩn đối với tất cả các attributes. Content là cụ thể đối với kiểu attribute và có thể có bất cứ kích thước nào. Nếu bạn nghĩ về một điều tương tự như những cái hộp, luôn luôn có những thông tin cơ bản giống nhau phía ngoài mỗi hộp nhỏ, nhưng hình dáng của mỗi hộp có thể khác nhau.

 

Attribute Headers

Attribute header nhận diện kiểu của attribute, kích thước của nó, và tên của nó. Nó cũng có các flags để nhận dạng nếu giá trị này được nén hoặc được mã hóa. Attribute type là một số nhận dạng dựa trên kiểu dữ liệu. Một MFT entry có thể có nhiều attributes của cùng một kiểu.

Một vài attributes có thể được một name và nó được lưu với định dạng UTF-16 Unicode trong attribute header. Một attribute còn có một giá trị định dạng được gán cho nó mà là duy nhất đối với MFT entry đó. Nếu một entry có nhiều hơn một attribute của cùng một kiểu, identifier này có thể được sử dụng để phân biệt giữa chúng.

 

Attribute Content

Content của attribute có thể có bất cứ định dạng và kích thước nào. Ví dụ, một trong số các attributes được sử dụng để lưu content của một file, vì vậy nó có thể có kích thước là một vài MB hoặc một vài GB. Vấn đề là không thực tế khi lưu lượng dữ liệu như thế này trong một MFT entry, những gì chỉ có kích cỡ là 1024 bytes.

 

Để giải quyết vấn đề này, NTFS cung cấp 2 vị trí mà attribute content có thể được lưu. Một resident attribute lưu content của nó trong MFT entry với attribute header. Điều này thực hiện được đối với chỉ các attributes nhỏ. Một non-resident attribute lưu content của nó tron một external cluster trong file system. Header của attribute nhận diện rằng attribute là resident hay non-resident. Nếu một attribute là resident, content sẽ lập tức theo sau header. Nếu attribute là non-resident, header sẽ đưa cho các cluster addresses. Trong Hình 11.5 chúng ta thấy ví dụ MFT entry mà chúng ta thấy trước đây, nhưng attribute thứ 3 là quá lớn đê fit trong MFT, và nó cấp phát cluster 829.

Non-resident attributes được lưu trong các cluster runs, đây là các clusters liên tiếp và run được document sử dụng địa chỉ cluster băt đầu (starting cluster address) và chiều dài run (run length). Ví dụ, nếu một attribute cấp phát tới các clusters 48, 49, 50, 51 và 52, nó phải có một run bắt đầu ở cluster 48 với length là 5. Nếu attribute này cũng cấp phát tới các clusters 80 và 81, nó có một run thứ 2 mà bắt đầu ở cluster 80 với length là 2. Run thứ 3 bắt đầu tại cluster 56 và có length là 4. Bạn có thể thấy trong Hình 11.6

NTFS sử dụng các thuật ngữ Logical Cluster Number (LCN) (giống như logical file system address) và Virtual Cluster Number (VCN) (giống như logical file address) để biểu diễn các địa chỉ.

Standard Attribute Types
Chúng ta đã nói về các thuật ngữ chung cho các kiểu attribute. Bây giờ chúng tôi sẽ nói về những thứ cơ bản của một vài standard attributes.

Như đã được đề cập trước đây, một số (number) được định nghĩa cho mỗi kiểu của attribute, và Microsoft sắp xếp các attributes trong một entry sử dụng số này. Các standard attributes có một giá trị kiểu (type value) mặc định được gán cho chúng, nhưng chúng ta sẽ thấy sau này là nó có thể được định nghĩa lại trong $AttrDef file system metadata file. Ngoài số này ra, mỗi attribute type có một name, và name này là in hoa bắt đầu với "$". Một vài kiểu attribute mặc định và identifiers của chúng có trong Table 11.2. Không phải mọi attribute types và identifiers sẽ tồn tại cho mọi file.

Gần như mọi allocated MFT entry có một $FILE_NAME và một $STANDARD_INFORMATION type attribute. Một ngoại lệ là các non-base MFT entries. Attribute $FILE_NAME chứa tên file, kích thước, và thông tin thời gian. $STANDARD_INFORMATION attribute chứa thông tin về thời gian, quyền sở hữu (ownership), và security. Attribute sau tồn tại đối với mọi file và directory bởi vì nó chứa dữ lieu cần để thực thi data security và các hạn mức (quotas). Trong một nghĩa trừu tượng, không có dữ liệu quan trọng trong attribute này, nhưng các application-level features của file system yêu cầu phải có nó ở đó. Cả 2 attributes này luôn luôn là resident.

Mọi file có một $DATA attribute, trong đó có file content. Nếu content có kích thước vượt quá 700 bytes, nó trở thành non-resident và được lưu trong các external clusters. Khi một file có nhiều hơn một $DATA attribute, các attributes bổ sung thỉnh thoảng được đề cập tới như là alternate data streams (ADS). $DATA attribute mặc định được tạo khi một file được tạo không có một name liên kết với nó, nhưng các $DATA attributes bổ sung phải có một name. Chú ý rằng attribute name là khác với type name. Ví dụ, $DATA là attribute type, và attribute's name có thể là "fred". Một vài tools, bao gồm The Sleuth Kit (TSK) , sẽ gán tên "$Data" cho $DATA attribute mặc định.

Mọi directory có một $INDEX_ROOT attribute mà chứa thông tin về các files và các subdirectories mà được đặt trong nó. Nếu directory quá lớn, $INDEX_ALLOCATION và $BITMAP attributes còn được sử dụng để lưu thông tin. Rối rắm hơn nữa là khi một directory có một $DATA attribute ngoài $INDEX_ROOT attribute. Hay nói cách khác, một directory có thể chứa cả file content và một danh sách các files của nó và các subdirectories. $DATA attribute có thể lưu bất cứ content nào mà một ứng dụng hay một user muốn lưu ở đó. $INDEX_ROOT và $INDEX_ALLOCATION attributes cho một directory thường có name "$I30."

Figure 11.7. cho ta thấy ví dụ MFT entry mà chúng ta đã sử dụng trước đó, và các attributes của nó có những names và types. Nó có 3 standard file attributes. Trong ví dụ này, tất cả các attributes là resident.

Other Attribute Concepts
Trong những phần trước chúng ta đã nhắc đến các khái niệm cơ bản mà được áp dụng cho tất cả các NTFS attributes. Mặc dù không phải mọi attribute đều là cơ bản, và phần này chúng ta sẽ đề cập tới các khái niệm nâng cao hơn. Cụ thể là, chúng ta xem coi điều gì sẽ xảy ra khi một file có quá nhiều attributes và xem các cách thức mà các contents của một attribute được nén (compressed) và được mã hóa (encrypted).

Base MFT entries
Một file có có tới 65,536 attributes (bởi vì indentifier có 16 bit), vì vậy có thể cần nhiều hơn một MFT entry để lưu tất cả attribute headers (thậm chí non-resident attributes cần các header của chúng ở trong MFT entry). Khi các MFT entries bổ sung được cấp phát cho một file, MFT entry ban đầu trở thành base MFT entry . Các non-base entries sẽ có base entry's address trong một trong những trường của MFT entry.

Base MFT entry sẽ có một $ATTRIBUTE_LIST type attribute mà chứa một danh sách với mỗi file's attributes và MFT address có thể được tìm thấy ở đây. Các non-base MFT entries không có $FILE_NAME và $STANDARD_INFORMATION attributes trong chúng.

Sparse Attributes
NTFS có thể giảm lượng không gian được cần bởi một file thông qua việc lưu một vài non-resident $DATA attribute như là sparse. Một sparse attribute là một attribute mà trong đó các clusters mà chứa toàn zero không được ghi lên đĩa. Thay vào đó, một run đặc biệt được tạo ra cho các zero clusters. Thông thường, một run chứa vị trí bắt đầu cluster (starting cluster location) và kích thước, nhưng một sparse run chỉ chứa kích thước và không có starting location. Cũng có một flag mà ám chỉ rằng một attribute là sparse.

Ví dụ, xét một file mà nên chiếm 12 clusters. 5 clusters đầu tiên là non-zero, 3 clusters tiếp theo chứa zero, và 4 clusters cuối cùng là non-zero. Khi lưu như một attribute thông thường , một run có độ dài 12 được tạo cho file, như trong Figure 11.8(A). Khi lưu như một sparse attribute, 3 runs được tạo và chỉ 9 clusters được cấp phát, như ta có thể thấy trong Figure 11.8(B)

[Forensics] Volume Shadow Copies

Bài viết được dịch từ cuấn Windows Forensic Analysis Toolkit

Giới thiệu
Mỗi lần một phiên bản mới của Windows được đưa ra thì y như là có những thoáng rùng mình nhẹ trong cộng đồng forensics. Những câu hỏi được đặt ra như: những tính năng mới nào được đưa vào trong phiên bản sắp tới ? Có những thử thách gì mà chúng ta phải đối mặt ? Một vài sự thay đổi chỉ là thứ yếu; ví dụ, cấu trúc nhị phân của Windows Registry không thay đổi giữa nhiều phiên bản, từ Windows 2000 cho đến Windows , mặc dù cách Registry được sử dụng (ví dụ, nơi các keys được đặt, các keys và các giá trị gì được tạo và thay đổi, vân vân) bởi OS và các apps thay đổi trong nhiều trường hợp. Những sự thay đổi khác có thể khá quan trọng, ví dụ như những sự thay đổi xuất phát từ phía trong liên quan tới cách Windows hoạt động.

"VOLUME SHADOW COPIES" là gì ?
Volume Shadow Copies (VSCs) là một trong các khía cạnh mới và có vẻ đáng ngại của Windows OSs (nhất là, Windows XP, trong một cách hạn chế, và nhiều hơn với Vista và Windows 7) mà có thể tác động quan trọng tới việc phân tích. VSCs quan trọng và hấp dẫn trong vai trò là nguồn của các artifacts.

Với việc đưa ra Windows XP, Microsoft giới thiệu Volume Shadow Copy Service (VSS) để cung cấp các chức năng backup các files hệ thống quan trọng nhằm hỗ trợ cho việc khôi phục dữ liệu. Với Windows XP, các users và administrators đã thấy được chức năng này như là các System Restore Points mà được tạo một cách tự động dưới nhiều điều kiện khác nhau (ví dụ, mỗi 24 giờ đồng hồ, khi một driver được cài đặt, vân vân), và cũng có thể tạo một cách thủ công, như mô tả trong hình 1.

Như trong Hình 1, users ngoài việc tạo ra các Restore Points, chúng còn có thể restore computer về thời điểm trước đó. Điều này tỏ ra hữu dụng trong trường hợp khi một user cài đặt một thứ gì đó (app, driver, ...) mà không may rằng hệ thống hoạt động không như mong đợi, hoặc hệ thống có thể bị lây nhiễm malware. Users có thể revert các tính năng lõi của hệ thống của họ về trạng thái lúc trước khi cài đặt thong qua tính năng System Restore, khôi phục một cách hiệu quả về trạng thái phía trước. Tuy nhiên, System Restore Points không back up mọi thứ trên hệ thống; ví dụ, các files dữ liệu của user không được back up (và do đó không được restore), và tất cả dữ liệu (nhất là passwords) trong SAM hive của Registry không được back up, và bạn có thể không muốn các users restore các hệ thống của họ về những mốc thời gian phía trước và có thể họ sẽ không truy cập được vào hệ thống của họ nữa , như một password lúc trước (những gì có thể khó nhớ ) được restore.

Vì vậy, trong khi System Restore Points chứng tỏ rằng chúng hữu dụng khi các users cần recover các hệ thống của họ về trạng thái phía trước, chúng thực hiện rất ít việc back up user data và cung cấp truy nhập tới các bản sao lúc trúc của các files khác. Từ góc nhìn của forensic, rất nhiều dữ liệu lịch sử có thể lấy được từ System Restore Points, bao gồm các backed-up system files và các Registry hives. Analysts vẫn cần phải hiểu về cách các backed-up files có thể được "ánh xạ" tới các filenames ban đầu nhưng thực tế là các files được back up có giá trị trong chính nó.

Hình 1. Tính năng System Restore Point trong Windows XP

 



 Với việc đưa ra Vista, tính năng được cung cấp thông qua VSS để hỗ trợ cho các services như là Windows Backup và System Restore được mở rộng. Cụ thể, số lượng và kiểu dữ liệu được capture bởi System Restore được mở rộng thêm bao gồm các block-level, incremental "snapshots" của một hệ thống (chỉ thông tin được chỉnh sửa mới được record) tại một thời điểm cho trước. Các "snapshots" này, được biết đến như là Volume Shadow Copies, xuất hiện theo một cách khác đối với user. VSCs hoạt động tại block level bên trong file system, backing up và cung cấp truy nhập tới các phiên bản trước đây của hệ thống và các user data files bên trong một volume cụ thể. Như với System Restore Points, các backups thực sự là trong suốt với user, nhưng với VSCs, user có thể restore các phiên bản trước đây của files thông qua Previous Versions shell extension, như trong Hình 2.

Okay, vậy nó có ý nghĩa gì đối với forensic analysts? Từ góc nhìn của một analyst , có rất nhiều thông tin lịch sử bên trong các backed-up files. Truy cập tới những files này không chỉ cung cấp dữ liệu lịch sử (ví dụ, các nội dung trước đây, etc.) mà việc phân tích thêm có thể được tiến hành thông qua việc so sánh các phiên bản có sẵn qua thời gian.

Registry Keys
Như mong đợi, có một vài Registry keys mà có tác động trực tiếp lên performance của VSS, dịch vụ mà hỗ trợ các chức năng khác nhau mà dẫn tới VSCs. Đó là một Windows service, primary key là :
HKLM\System\CurrentControlSet\Services\VSS

Vài dòng cho những ngày cuối cấp

Nhớ những năm cuối cấp 3, những ngày cuối chia tay bạn bè, cũng lên mạng viết linh tinh (thời yahoo blog :)).
Những câu nói "Buổi cuối cùng rùi mày à", "éo biết sau này có gặp lại nhau không ?", "Ra trường tính ở lại hay về quê ?", "Được nhiêu chấm rùi có được khá không ?"... Cảm thấy bâng khuâng! Buổi cuối cùng rùi, gặp nhau không à ? chưa chắc!, nhưng chắc một điều rằng những bạn bè dù tiếp xúc it hay nhiều mình sẽ luôn nhớ. Những kỉ niệm thời sinh viên sẽ theo mãi. Vẫn mong rằng 1 năm chúng ta có thể họp nhau lại một lần, có thể ngồi chậm rãi mà hồi lại những năm tháng ấy. Chúc chúng ta có thể hoàn thành kì thực tập cũng như đồ án tốt nghiệp thật thành công.

[File System Forensics] Volume Analysis

Bài dịch từ cuấn File System Analysis

Trong bài viết chúng ta thảo luận về việc phân tích volume. Phân tích volume cần việc xem xét các cấu trúc dữ liệu mà liên quan tới việc phân vùng (partitioning) và lắp ghép (assembling) các bytes trong các thiết bị lưu trữ do vậy chúng ta có được các volumes. Các volumes được sử dụng để lưu file system hoặc cấu trúc dữ liệu khác. Trong phần này chúng ta tiếp cận các khái niệm của phân tích volume và thảo luận các nguyên lý mà áp dụng cho tất cả các kiểu hệ thống volume. Trong các bài tiếp theo chúng ta thảo luận về các kiểu phân vùng và lắp ghép các hệ thống

Giới thiệu
Phương tiện lưu trữ kĩ thuật số được tổ chức để cho phép việc lấy dữ liệu được hiệu quả. Trải nghiệm phổ biến nhất với một volume là khi chúng ta cài đặt Microsoft Windows và tạo các phân vùng (partitions) trên đĩa cứng. Quá trình cài đặt là quá trình tạo các phân vùng chính và phân vùng logic, và cuối cùng trong các bước cài đặt máy tính liệt kê một danh sách các "drives" hoặc "volumes" để lưu trữ dữ liệu. Một quá trình tương tự xảy ra khi cài đặt một hệ điều hành UNIX, và nó trở nên phổ biến trong các môi trường lưu trữ rộng lớn để sử dụng các phần mềm quản lý volume để có nhiều đĩa xuất hiện như là chúng bao gồm một đĩa lớn.

Trong suốt quá trình điều tra số, thông thường thì ta thu được ảnh của toàn bộ đĩa (disk image) và import image này vào các công cụ phân tích. Nhiều công cụ điều tra số tự động cắt (break) disk image ra thành các partitions, nhưng thỉnh thoảng chúng cũng gặp phải những vấn đề. Các khái niệm trong bài dịch này sẽ giúp một người điều tra hiểu các chi tiết về một công cụ đang làm điều gì và tại sao nó gặp phải các vấn đề nếu một đĩa bị lỗi. Ví dụ, khi các partitions trên đĩa bị xóa hoặc bị xóa đổi do nghi ngờ hay là một công cụ đơn giản không thể xác định vị trí một partition. Các thủ tục trong bài này cũng có thể hữu dụng khi phân tích các sectors mà không được cấp phát tới một partition.

Background

Các khái niệm Volume
Các hệ thống volume có 2 khái niệm trung tâm. Một là để lắp ghép (assemble) nhiều volumes lưu trữ thành một volume lưu trữ và khái niệm còn lại đó là để phân vùng (partition) các volumes lưu trữ vào trong các partitions độc lập với nhau. Thuật ngữ "partition" và "volume" thường được sử dụng thường xuyên cùng nhau, nhưng tôi sẽ đưa ra một sự khác biệt giữa chúng.

Một volume là một tập hợp các sectors có thể đánh địa chỉ mà một hệ điều hành (OS) hoặc một ứng dụng có thể sử dụng để lưu trữ dữ liệu. Các sectors trong một volume không cần phải là các sectors liên tiếp trên thiết bị lưu trữ vật lý; thay vào đó, chúng chỉ cần gửi đi một dấu ấn (impression) để cho thấy rằng chúng là gì. Một volume cũng có thể là kết quả của việc lắp ghép và sáp nhập các volumes nhỏ hơn.

Lý thuyết chung của các partitions
Một trong các khái niệm trong hệ thống volume là tạo ra các partitions. Một partition là một tập hợp các sectors liên tục trong một volume. Rõ ràng theo định nghĩa thì một partition cũng là một volume, là một khái niệm con trong khái niệm của volume, điều đó là lý do tại sao chúng ta hay bị nhầm lẫn. Tôi sẽ đề cập tới volume như là một partition được xác định vị trí như là một volume cha của partition. Các partitions được sử dụng trong nhiều hoàn cảnh, bao gồm

• Một vài file systems có một kích thước tối đa nhỏ hơn so với các đĩa cứng
• Nhiều laptops sử dụng một partition đặc biệt để lưu nội dung bộ nhớ khi hệ thống đi vào trạng thái sleep.
• Các hệ thống UNIX sử dụng các partitions khác nhau cho các thư mục khác nhau để giảm thiểu tối đa tác động cuả việc hư hỏng file system
• Các hệ thống dựa trên IA32 mà có nhiều hệ điều hành, ví dụ như Microsoft Windows và Linux, có thể yêu cầu các partitions khác nhau cho mỗi hệ điều hành

Xét một hệ thống Microsoft Windows với một đĩa cứng. Volume đĩa cứng được phân vùng thành 3 volumes nhỏ hơn, và mỗi volume có một file system. Windows gán các tên C, D, và E cho mỗi volume. Chúng ta có thể nhìn thấy trong Hình 1.

Hình 1. Một volume đĩa cứng được tổ chức thành 3 partitons và mỗi partitions được gán các tên volumes



Mỗi hệ điều hành và nền tảng phần cứng thì sử dụng một phương thức phân vùng khác nhau. Các hệ thống phân vùng phổ biến các một hay nhiều bảng, và mỗi entry của bảng mô tả một partition. Dữ liệu trong entry sẽ có sector bắt đầu của partition. Hình 2 cho ta một bảng mẫu với 3 partitions

Hình 2. Một bảng cơ bản với các entries cho start, end và type của mỗi partition



Mục đích của một hệ thống phân vùng là để tổ chức layout của một volume; do đó, chỉ dữ liệu cần thiết là vị trí bắt đầu và kết thúc cho mỗi partition. Một hệ thống partition không thể phục vụ mục đích của nó nếu các giá trị này bị lỗi hoặc là không tồn tại. Tất cả các trường khác, ví dụ như trường type và description, là các trường không cần thiết và có thể sai.

Trong hầu hết các trường hợp, sector đầu tiên và cuối cùng của một partition không chứa bất cứ thứ gì nhận dạng chúng là các sectors rìa. Khi các cấu trúc hệ thống partition đang bị mất, các ranh giới partition có thể đoán được sử dung hiểu biết về những gì được lưu bên trong partition.

Chú ý rằng một hệ thống partition phụ thuộc vào hệ điều hành và không phụ thuộc vào kiểu interface trên đĩa cứng. Do đó, một hệ thống Windows sử dụng cùng một hệ thống partition không quan tâm về đĩa sử dụng AT Attachment interface (ATA/IDE) hay là một Small Computer Systems Interface (SCSI)

Việc sử dụng các Volumes trong UNIX
Các hệ thống UNIX thường không sử dụng các volumes theo cách mà hệ điều hành Microsoft Windows làm. Phần này dành cho những users không quen thuộc với UNIX, và nó cung cấp một overview về cách các volumes được sử dụng trong UNIX.

Trong UNIX, user không thấy được một vài "drives", ví dụ như C: và D:. Thay vào đó, user được thấy một chuỗi các thư mục mà bắt đầu bằng thư mục root, hoặc /. Các thu mục con của / hoặc là các thư mục con trong cùng một file system, hoặc chúng là các mouting points cho các file systems mới và các volumes mới . Ví dụ, một CD-ROM có thể được biểu diễn là E: drive trong Windows, nhưng nó có thể được mount tại /mnt/cdrom trong Linux. Điều này cho phép user thay đổi các drives thông qua việc thay đôỉ các thư mục, và trong nhiều trường hợp user không biết những gì chúng làm. Hình 3 cho ta thấy cách đĩa cứng và CD volumes được truy cập trong Windows và UNIX

Hình 3. Các mount points của 2 volumes và một CD-ROM trong (A) Microsoft Windows và (B) UNIX system



Để giảm thiểu tác động của việc lỗi drive và để cải thiện tính hiệu quả, UNIX thường phân vùng mỗi đĩa thành một vài volumes. Một volume cho thư mục root (/) lưu thông tin cơ bản, một volume riêng rẽ có thể tồn tại cho các thư mục home của user (/home/), và các ứng dụng có thể được xác định trong volume của riêng chúng (/usr/). Tất cả các hệ thống là duy nhất và có thể có một volume và cơ chế mouting hoàn toàn khác. Một vài hệ thống sử dụng chỉ một volume lớn cho thư mục root và không phân đoạn (segment) hệ thống.

Lý thuyết chung của lắp ghép Volume
Các hệ thống lớn hơn sử dụng các kĩ thuật lắp ghép volume để làm cho nhiều đĩa trông giống như một. Một động lực cho việc làm đó là để thêm tính dư thừa trong trường hợp một đĩa hư. Nếu dữ liệu được ghi vào nhiều hơn một đĩa, có tồn tại một bản sao backup nếu một đĩa hư. Một động lực khác đó là dễ dàng hơn khi thêm nhiều không gian lưu trữ. Việc mở rộng (volume spanning) thực hiện thông qua việc kết hợp tổng thể không gian lưu trữ của nhiều volumes vì vậy một volume lớn được tạo ra. Các đĩa bổ sung có thể được thêm vào volume lớn mà không tác động gì đến dữ liệu đã tồn tại.

Nào hãy cùng điểm nhanh một ví dụ. Hình 4 trình bày một ví dụ bao gồm 2 disk volumes với tổng cộng 3 partitions. Partition 1 được gán với một volume tên C: và một thiết bị phần cứng xử lý partition 2 và 3. Thiết bị phần cứng xuất ra một volume lớn, và được tổ chức thành 2 partitions. Chú ý rằng trong trường hợp này thiết bị phần cứng không cung cấp tính đáng tin cậy, chỉ là một volume lớn hơn.

Hình 4. Một hệ thống volume mà sáp nhập 2 partitions vào trong một volume và phân vùng nó

 



Đánh địa chỉ Sector
Chúng ta đã từng thảo luận về cách tìm địa chỉ sector. Phương thức phổ biến nhất đó là sử dụng địa chỉ LBA của nó, địa chỉ này là một con số bắt đầu từ 0 tại sector đầu tiên của đĩa. Địa chỉ này là địa chỉ vật lý của một sector.

Một volume là một tập hợp các sectors, và chúng ta cần gán một địa chỉ cho chúng. Một logical volume address là địa chỉ của một sector xét tương đối với bắt đầu của volume của nó. Chú ý rằng bởi vì một đĩa là một volume, địa chỉ  vật lý là giống như địa chỉ logic của volume đối với disk volume. Các vị trí bắt đầu và kết thúc của các partitions được mô tả sử dụng các địa chỉ logic của volume (logical volume address).

Khi chúng ta bắt đầu nói về nội dung của một partition, có một lớp khác của các địa chỉ logic của volume. Các địa chỉ này là tương đối so với bắt đầu của một partition và không phải là bắt đầu của đĩa hay là parent volume. Chúng tôi sẽ phân biệt chúng thông qua việc đặt ở trước từ volume với từ "disk" hoặc "partition". Hình 5 cho ta thấy một ví dụ ở đó có 2 partitions và một không gian không được phân vùng (unpartitioned space) giữa chúng. Partition đầu tiên bắt đầu ở sector 0, vì vậy các địa chỉ logical partition volume là giống như các địa chỉ logical disk volume. Partition thứ 2 băt đầu ở sector vật lý 864 và các địa chỉ logical disk volume của các sectors này lớn hơn các địa chỉ logical partition volume của chúng.

Hình 5. Địa chỉ logical partition volume là tương đối so với bắt đầu của partition trong khi địa chỉ logical disk volume là tương đối so với bắt đầu của đĩa



Analysis Basics
Phân tích volume xảy ra thường xuyên, mặc dù nhiều nhà điều tra không thể nhận ra nó. Trong nhiều trường hợp, một investigator cần toàn bộ đĩa và import image vào trong các phần mềm phân tích của anh ấy để nhìn thấy nội dung của file system. Để nhận dạng nơi file system bắt đầu và kết thúc, các bảng partition phải được phân tích.

Một điều quan trọng nữa đó là phân tích partition layout của volume bởi vì không phải tất cả các sectors cần phải được gán vào một partition, và chúng có thể chứa dữ liệu từ một file system trước đó hoặc một mối nghi ngờ nếu đó cố gắng ẩn đi. Trong một vài trường hợp, hệ thống partition có thể bị lỗi hoặc bị xóa, và các công cụ được tự động hóa sẽ không làm việc.

Các kĩ thuật phân tích
Lý thuyết cơ bản của volume là đơn giản. Đối với các hệ thống phân vùng, chúng ta muốn xác định vị trí của các bảng partition và xử lý chúng để nhận dạng layout. Thông tin layout sau đó được cung cấp cho công cụ phân tích file system mà cần biết offset của một partition, hoặc nó có thể được in ra cho user do đó cô ta có thể xác định những dữ liệu gì nên được phân tích. Trong một vài trường hợp, dữ liệu trong một partition hoặc giữa các partitions cần được lấy ra từ parent volume. Để phân tích dữ liệu trong một partition, chúng ta cần xét xem kiểu dữ liệu của nó là gì. Nói chung, nó là một file system, chúng tôi sẽ trình bày trong những bài tiếp theo.

Để phân tích các thành phần lắp ghép (assembly components) của một volume system, chúng ta cần định vị và xử lý các cấu trúc dữ liệu mà mô tả những volumes được sáp nhập và cách chúng được sáp nhập. Có nhiều cách để các volumes có thể được sáp nhập.

Kiểm tra tính nhất quán
Khi phân tích các volume systems, có thể hữu ích khi kiểm tra mỗi partition liên quan thế nào tới các partitions khác. Điều này có thể phục vụ như là một cuộc kiểm tra sự tỉnh toán (sanity check) để xác định một nơi nào đó chứng cứ có thể được định vị bên cạnh việc nó xuất hiện trong mỗi partition. Hầu hết các partition systems không yêu cầu các entries được sắp xếp theo thứ tự, vì vậy bạn hay một công cụ phân tích nên sắp xếp chúng dựa trên vị trí bắt đầu và kết thúc trước khi bạn thực hiện các việc kiểm tra tính toàn vẹn.

Việc kiểm tra đầu tiên sẽ nhìn vào partition cuối cùng và so sánh vị trí kết thúc của nó với cuối cùng của parent volume. Lý tưởng nhất thì nó nên là sector cuối cùng của volume. Hình 6 cho ta thấy một tình huống mà ở đó partition sau cùng kết thúc trước cuối cùng của volume, và có các sectors có thể chứa các dữ liệu ẩn hay là bị xóa.

Hình 6. năm ví dụ về cách 2 partitions có thể được tổ chức tương quan lẫn nhau. Ba ví dụ đầu tiên là hợp lệ, 2 ví dụ cuối cùng là không hợp lệ.



Dạng tiếp theo của việc kiểm tra sanity là so sánh các sectors bắt đầu và kết thúc của các partitions liên tục, và có 4 tình huống xảy ra. Tình huống thứ nhất, hiển thị trong Hình 6b, là hợp lệ, và có các sectors nằm giữa 2 partitions mà không ở trong một partition. Các non-partitioned sectors có thể được sử dụng để ẩn dữ liệu và nên được phân tích. Tình huống thứ 2, ta có thể thấy trong hình 6c, là trường hợp mà hầu hết mọi system có, và partition thứ 2 bắt đầu ngay sau partition đầu tiên.

Tình huống thứ 3, có thể thấy trong Hình 6d, đây là tình huống không hợp lệ, partition thứ 2 bắt đầu khi mà partition 1 chưa kết thúc. Điều này tạo ra một sự chồng chéo, và trong nhiều trường hợp nó là một điềm báo rằng bảng partition bị lỗi. Để xác định partition nào là đúng, bạn cần phân tích dữ liệu bên trong mỗi partition. Partition thứ 2 nằm bên trong partition đầu tiên, các nội dung của mỗi partition cần được phân tích để xác định xem lỗi nằm ở đâu.

Trích xuất nội dung Partition
Một vài công cụ yêu cầu một partition image như là input, hoặc chúng ta có thể muốn trích xuất dữ liệu trong hay là ở giữa các partitions tới một file riểng lẻ. Phần này sẽ trình bày cách trích xuất dữ liệu, và các kĩ thuật trong phần này được áp dụng cho tất cả các partition systems. Trích xuất dữ liệu làm một quá trình đơn giản khi đã biết được layout. Chúng tôi sẽ trình bày cách thực hiện điều này thông qua công cụ dd .

Công cụ dd là một công cụ dựa trên command line và yêu cầu một vài thông số (arguments). Chúng ta sẽ cần những thông số sau để trích xuất nội dung partition:

• if: disk image để đọc
• of: file để ghi ra kết quả
• bs: kích thước của block cho mỗi lần đọc, 512 bytes là mặc định
• skip: số lượng blocks cần bỏ qua trước khi đọc, mỗi cho kích thước bs
• count: số lượng blocks để sao chép từ input tới output, mỗi đối với kích thước bs

Trong nhiều trường hợp, chúng ta sẽ muốn sử dụng block size là 512 byte bởi vì đó là kích thước của một sector. Mặc định block size cho dd cũng là 512 bytes, nhưng an toàn hơn thì bạn nên chỉ định rõ ràng. Chúng ta sẽ sử dụng skip flag để chỉ định sector bắt đầu nơi mà partition bắt đầu và count flag để chỉ định bao nhiêu sectors ở trong partition.