Slack / RAM Slack: почему Windows записывает произвольные байты RAM на диск? Есть ли у Linux тоже?

"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 операционной системы для записи. Вы видите это только с низкоуровневыми инструментами восстановления и криминалистики, потому что такие приложения не получают выгоды от всех оптимизаций, которые вы получаете с буферизованным вводом / выводом.

Недостаток оперативной памяти на самом деле является хорошо известным артефактом цифровой криминалистики.

Действительно, более старые (т.е. Win 95/98) версии Windows записывали блоки памяти по 512 байт. Пожалуйста, не путайте кластерную запись с носителем. Когда я записываю 512-байтовую память, я имею в виду выделенную / захваченную Windows память для записи в 512-байтовых блоках, что составляет кластер носителей данных.

Например, 4096-байтовые кластеры на носителе и файл длиной 2049 байт. Более ранние версии Windows выделяли и захватывали буфер / кэш / память в кусках по 512 байт в памяти для этого файла размером 2049 байт.

Это требует 5 х 512-байтовых блоков памяти. В результате получается 511-байтовый файл, который не был частью 2049-байтового файла. (5 х 512 = 2560, но 2049 / 512 = 4,002).

Так что же в 511-байтовой памяти ( 2560 - 2049 = 511)? В более старых версиях Windows не очищала 511-байтовую часть и записывала ее со всеми 4 КБ. Это то, что в кругах специалистов по криминалистике называют недостатком оперативной памяти.