"File Slack" относится к данным между последним байтом файла и концом кластера. Обычно он содержит любой битовый шаблон, используемый ОС для представления нераспределенной памяти.
"Drive Slack" относится к кластерам, которые были освобождены, но не перезаписаны. Это может также относиться к нераспределенному пространству, которое больше не попадает в границы раздела.
"RAM Slack" - я никогда раньше не слышал этот термин. Похоже, что все ресурсы, которые я нахожу, цитируются или взяты из книги Альберта Дж. Марселлы младшего и Дуга Менендеса «Кибер-криминалистика: полевое руководство для сбора, изучения и сохранения доказательств компьютерных преступлений».
Я прочитал главу, где используется термин. Несмотря на то, что он был защищен авторским правом в 2010 году, он ссылается на то, как DOS и Windows 95/98 делали вещи. Это не было актуально уже более десяти лет. Я мог бы читать это вне контекста, хотя. В любом случае, эта книга является источником этого термина.
Windows хранит данные на диске в кластерах. Кластер обычно содержит 8 секторов по 512 байт каждый, то есть 4096 байт или 4 кбайт.
Это верно в случае устаревших накопителей и накопителей 4K "расширенного формата". Размер сектора действительно равен 4 КБ на 4K "родных" дисках, поэтому для этих дисков существует соотношение 1:1 между секторами и кластерами.
Большие файлы разделяются на несколько кластеров, когда оставшаяся часть файла не заполняет весь кластер, это оставшееся неиспользуемое пространство в конце кластера называется "слабым местом".
Тоже правильно.
Windows всегда записывает 512-байтовые блоки сразу, поэтому первый только частично используемый сектор должен быть заполнен перед записью на диск.
Это неверно Винда не пишет в блоках; только кластеры. Он будет записывать данные любого произвольного размера, но они будут кратны размеру кластера (обычно 4 КБ). Единственный раз, когда Windows заботится о секторах / блоках, это когда нужно вычислить адрес LBA. Это делает драйвер диска низкого уровня, а не драйвер файловой системы. На самом деле очень неэффективно делать чтение / запись в 512-байтовых блоках. Он работает против внутренних аппаратных кешей накопителя. Выполнение dd в Linux с размером блока 512 байт подтвердит это. Это на порядок медленнее при чтении и записи.
По любой причине Windows решает выбрать случайную последовательность из оперативной памяти, чтобы заполнить этот сектор.
Тоже неверно. Windows напишет все, что находится в буфере. Почти каждое приложение (включая драйвер файловой системы) выделяет свежую память из кучи при записи в выходной буфер. Когда приложение выделяет память, оно делает это на страницах, которые (угадайте, что!) 4 КБ в размере. Нераспределенная память обычно представлена повторяющимся битовым шаблоном (не 00 или FF), так что именно это будет записано в конец кластера, если он не заполнен. В тех случаях, когда выходной буфер приложения является модифицированной копией входного буфера, резервная копия будет содержать все данные, которые входной буфер имел в нем.
Оставшиеся неиспользуемые сектора в частично используемом кластере остаются неизменными и сохраняют байты, которые они имели ранее, которые могут быть частями ранее удаленного файла в этом месте. Это называется провисание диска.
Тоже неверно. Windows всегда выполняет полную кластерную фиксацию, даже если изменен только один байт данных. Это правда , что высвобождены кластеры имеют все данные , в них было раньше. Windows не заботится об обнулении освобожденных кластеров. Но ничего этого не происходит на уровне секторов.
4KB - это волшебное число. Страницы памяти 4 КБ. Буферы ввода / вывода составляют 4 КБ. Сектора 4KB сейчас. Даже аппаратное обеспечение привода оптимизировано для запросов ввода-вывода, которые составляют 4 КБ (или несколько их кратных).
Все современные операционные системы работают таким образом (Windows, Linux и OS X). Единственными исключениями из приведенных выше правил являются приложения, в которых диск открыт для прямого доступа. Они полностью игнорируют вызовы API операционной системы для записи. Вы видите это только с низкоуровневыми инструментами восстановления и криминалистики, потому что такие приложения не получают выгоды от всех оптимизаций, которые вы получаете с буферизованным вводом / выводом.
