Мы неоднократно писали о том, как снимать образы современных накопителей, какие для этого нужны условия и аппаратное обеспечение, а также о том, как добиться максимальной скорости. На этот раз мы решили сосредоточиться исключительно на скоростях работы с E01 — самым распространённым форматом, который используется повсеместно. Поскольку полноценный криминалистический образ должен сопровождаться контрольными суммами, мы проверяли программы в реальных условиях с обязательным подсчётом хэш-сумм. В этой статье мы кратко разберём ключевые факторы, которые ускоряют или тормозят процесс снятия данных, а затем покажем сводные таблицы производительности со свежими результатами наших тестов популярных программ для снятия образов.

Как снимаются образы: блокираторы записи

Криминалисты в лаборатории не работают с оригинальным носителем напрямую — это главное правило цифровой криминалистики. Одно случайное изменение файла, и улики могут быть испорчены или безвозвратно потеряны. Работа ведётся с копией данных, для чего создаётся точный образ — копия диска, которая сохраняется в файл. Чтобы операционная система или сам следователь случайно ничего не записали на исходный накопитель, он обязательно подключается через аппаратный блокиратор записи; мы производим собственные устройства для этой цели (модели для SATA и NVMe; блокиратор для USB находится на стадии испытаний). Блокиратор гарантирует, что данные останутся в первозданном виде. В этом тестировании блокиратор мы не использовали, чуть ниже мы объясним причину.

Форматы: RAW и E01

Мы уже разбирали скорости прямого копирования накопителей в прошлых статьях (см. Как добиться максимальной скорости при снятии образов дисков и Когда скорость имеет значение), но в первую очередь тестировали чистую скорость копирования в несжатый формат RAW, и без подсчёта контрольных сумм. В то же время такое тестирование не отражает реалий криминалистической лаборатории: данные редко сохраняются в несжатом виде, и контрольные суммы считать нужно. Поэтому сегодня мы сфокусируемся на другом сценарии. Речь пойдёт о сохранении данных в формат E01 (Expert Witness Format). Несмотря на возраст, этот формат продолжает выполнять свою функцию, а главное — его поддерживают все криминалистические пакеты на рынке.

У формата две ключевые особенности: сжатие и контрольные суммы. Со сжатием всё понятно, оно помогает сэкономить место на целевом диске, особенно если исследуемый накопитель заполнен лишь частично. А вот с контрольными суммами — интереснее. Спецификация E01 предписывает считать сразу две контрольные суммы: MD5 и SHA-1. Популярный инструмент FTK Imager в принципе не позволяет пользователю отключить эту функцию. В утилитах OSForensics и нашем Elcomsoft Disk Imager (EDI) подсчёт хэш-сумм можно убрать, однако для максимально честного сравнения производительности мы принудительно включили обе контрольные суммы во всех программах. В конце концов, мы считаем хэш-суммы при снятии образа не для галочки — это профессиональная необходимость.

Тестовый стенд

Чтобы получить объективные цифры, мы собрали современный и мощный стенд. Мы взяли достаточно производительный компьютер, который не станет узким местом при обработке данных, подобрали качественные кабели и быстрые качественные адаптеры.

Характеристики стенда:

• Intel Core Ultra 7 255H (6P+8E, 1800 MHz)
• 32GB DDR5
• SSD: Samsung SSD 990 PRO 4TB (~7 GB/s)

Для самих тестов мы подготовили три разных накопителя, которые примерно отражают типичные сценарии из практики криминалистов: обычный USB-накопитель (Orico UFSD-LD 256 GB), классический твердотельный диск с интерфейсом SATA (Samsung SSD 860 PRO 512GB) и высокоскоростной NVMe SSD (Samsung SSD 980 PRO 250GB).

USB-накопитель мы подключали напрямую к порту USB 3.0, диски SATA и NVMe — к порту USB 4.0 через 10-гигабитные контроллеры (это — теоретический предел для SATA, а для NVMe — предел, достижимый на современных блокираторах записи). Кабель использовался сертифицированный USB 4.

Главное в любом сравнении — равные условия для всех участников. Мы тщательно проверили настройки каждой программы. Везде, где это возможно, мы задали самый быстрый уровень сжатия. Мы сделали это намеренно, чтобы ни одна программа не получила преимущества за счёт отказа от компрессии, и в то же время ни одна не тратила лишние ресурсы на избыточную компрессию.

Факторы, влияющие на скорость снятия образа

Скорость копирования упирается в четыре базовых фактора:

1. Скорость оборудования. Сюда входят контроллеры материнской платы, порты, кабели и адаптеры. Единственное слабое звено может повлиять на производительность всей системы, имейте это в виду!
2. Пропускная способность интерфейса самого диска. Очевидно, что старый флеш-накопитель отдаст данные медленнее, чем современный диск NVMe.
3. Эффективность ПО. Отражает, насколько грамотно разработчики написали код для чтения, хэширования и записи. В числе факторов — поддержка современных наборов инструкций (например, для ускорения подсчёта контрольных сумм SHA-1) и многопоточности (параллельные неблокирующие операции чтения, записи и подсчёта контрольных сумм).
4. Содержимое диска. Это самый непредсказуемый фактор: пустые блоки и считываются быстрее, и сжимаются лучше.

Сразу сделаем важную оговорку: в этих тестах мы намеренно исключили из цепочки аппаратные блокираторы записи. Поскольку наша главная цель — измерить чистую производительность именно программного обеспечения, мы убрали любые промежуточные устройства, которые могли бы исказить финальные цифры.

Последний фактор — содержимое диска — делает тестирование достаточно сложной задачей. Дело в том, что алгоритм сжатия, который работает внутри формата E01, оптимизирован для мгновенной обработки пустого пространства, заполненного нулями. Если вы начнёте снимать образ с чистого диска, скорость окажется совершенно нереалистичной, не имеющей ничего общего с действительностью. В то же время пустые блоки в реальных условиях, разумеется, есть, и на типичном исследуемом накопителе их может быть достаточно много — иногда больше половины всего объёма. Соответственно, мы приняли волевое решение: тестовые накопители заполнить реальными данными (не случайно сгенерированным цифровым шумом, который практически несжимаем) приблизительно на 80%. Мы установили Windows, поместили несколько архивов (которые алгоритм физически не сможет сжать сильнее) и добавили файлов в обычных для среднего пользователя форматах — от изображений до офисных документов. Получился типичный диск среднестатистического пользователя.

Практический совет: настройки сжатия в криминалистических программах не всегда понятны, а их изменение не всегда приводит к ожидаемому результату. К примеру, FTK Imager предлагает варианты сжатия от 0 (без сжатия) до 9 (максимум). Мы настоятельно рекомендуем всегда выбирать настройку «Fast» (это уровень 1). Почему? Если установить настройку компрессии на максимум, вы заставите процессор выполнять лишнюю работу, но выигрыш в итоговом размере файла составит от силы единицы процентов; времени на создание образа вы потратите в несколько раз больше. Это бессмысленная трата времени, поэтому с нашей точки зрения «быстрый» уровень сжатия — единственный разумный выбор для формата E01.

Почему одни программы работают быстрее других

Создание побитовой копии кажется элементарной задачей только на первый взгляд. На деле процесс снятия образа состоит из четырёх ресурсоёмких шагов: программа должна считать блок данных с диска, вычислить для него контрольные суммы, сжать этот блок и только затем записать готовый результат в файл.

Сделать всё это быстро — сложная инженерная задача, где дьявол кроется в деталях. Разработчикам необходимо грамотно подобрать размер буфера чтения и записи. Огромную роль играет способ подсчёта хэш-сумм: кто-то использует стандартный открытый код, кто-то оптимизирует алгоритмы на низком уровне, а кто-то идёт дальше и задействует прямые аппаратные инструкции процессора для ускорения расчёта SHA-1. Аналогичной тонкой настройки требует и алгоритм компрессии.

Современные процессоры оснащены множеством ядер, причём сегодня они часто делятся на производительные и энергоэффективные. Чтобы выжать максимум скорости, нужно выстроить многопоточный конвейер. Задачи нужно грамотно распределить: пока одно ядро читает данные с исследуемого накопителя, другие будут вычислять контрольные суммы, упаковывать информацию и записывать её на диск. Сложность состоит в том, что каждая из этих задач требует разных вычислительных ресурсов: скорость чтения ограничивается внешними факторами, подсчёт SHA-1 завершится быстрее подсчёта MD5, даже если две этих хэш-суммы считать параллельными потоками (а многие производители считают сначала одну, а потом — другую); наконец, сжатие данных работает медленнее всего. Сжатые данные нужно будет сохранить — и эта скорость тоже конечна; любой из перечисленных потоков может затормозить весь процесс.

Если продукт написан без учёта этих нюансов, возникает узкое место — быстрый NVMe-диск будет простаивать в ожидании, пока процессор закончит обсчитывать очередной блок данных. В Elcomsoft Disk Imager мы потратили много времени, оптимизируя архитектуру конвейера, чтобы исключить любые простои — и даже сейчас процесс оптимизации продолжается.

Тестирование производительности

Результаты тестирования мы свели в две таблицы. Для прямого сравнения мы взяли FTK Imager — лидера по популярности в криминалистическом сообществе, и OSForensics — инструмент, который долгое время заслуженно считался самым быстрым на рынке.

Время снятия образа (в секундах):

Средняя скорость (в МБ/с):

Цифры показывают, что наш EDI уверенно обошёл обоих конкурентов с серьёзным отрывом. И чем быстрее работает физический накопитель, тем заметнее разница в эффективности программ. Обратите внимание на результаты работы с NVMe-накопителями: наш EDI показал среднюю скорость в 455 МБ/с. Мы обогнали некогда лидирующий OSForensics почти на 100 мегабайт в секунду, а классический FTK Imager остался далеко позади. На практике это означает, что при копировании терабайтного накопителя следователь сэкономит массу времени.

В поисках бутылочного горлышка

И всё-таки мы не удержались и провели ещё ряд тестов, подключив тот же самый NVMe-диск через качественный адаптер с интерфейсом USB 4 (40 Гбит/с). На синтетических тестах скорости с этим адаптером получаются такие:

Таким образом, мы исключили один из факторов, влияющих на скорость создания образа. В реальности OSForensics и Elcomsoft Disk Imager снимают образ с такого диска со скоростью примерно 2 ГБ/с (разумеется, в формате RAW, и без подсчёта хэшей), так что остаётся разобраться со сжатием E01 и подсчётом хэшей. И тут мы получили несколько очень интересных результатов.

Во-первых, общая скорость выросла во всех продуктах. В FTK Imager и OSForensics примерно на четверть, а в EDI почти в полтора раза (до 656 МБ/с).

Во-вторых, сравнив скорости при создании RAW и E01 без подсчёта хэшей, мы увидили сколько ресурсов уходит исключительно на компрессию. OSForensic при использовании упомянутого адаптера с 2.2 ГБ/с до 742 МБ/с; наш EDI — с 1866 МБ/с до 969 МБ/с.

Наконец, подсчёт хэшей. Увы, алгоритм MD5 довольно медленный, и именно он (ну, наряду с компрессией конечно) сильно просаживает скорость копирования. От цифр уже немного рябит в глазах, но нельзя не поделиться последней: если считать только SHA-1, то у нас в EDI скорость падает всего на 10%, до 1786 МБ/с. А вот так выглядит график чтения диска, когда процессы плохо синхронизированы, и подсчёт хэша (да, в данном случае конечно же MD5) не даёт читать данные на полной скорости — обратите внимание на «зубцы»:

Резервы по оптимизации компрессии ещё есть (у всех программ, включая нашу: процессор не нагружается в полную силу, и можно более эффективно задействовать все ядра). А вот с MD5 мало что можно сделать, поскольку хэш считается последовательно, и в несколько потоков реализовать не получится — но мы всё же постараемся ускорить.

С небес на землю: как работают лаборатории

Для тестирования мы использовали достаточно мощный компьютер, подобрав оптимальную конфигурацию. Посмотрим правде в глаза: вряд ли в реальных условиях у специалиста будет время и желание тратить подобные усилия на подбор и проверку компонентов. На практике криминалистам часто приходится работать за далеко не новыми компьютерами. Слабые процессоры с трудом справляются с одновременным чтением, хэшированием и упаковкой, а вместо современных высокоскоростных интерфейсов под рукой оказываются обычные порты стандарта USB 3.0.

Слабым звеном часто становится целевой накопитель — то, куда сохраняется образ. Специалисты часто записывают сотни гигабайт улик на внешние переносные жёсткие диски или сохраняют их по сети на локальное сетевое хранилище (NAS). Даже если лаборатория сделала невероятное и потратила солидный бюджет на 10-гигабитную сеть, внутри самого NAS всё равно работают обычные механические жёсткие диски; типичная скорость записи на массив RAID5 или RAID6 из 6-8 дисков — порядка 300-400 мегабайт в секунду.

В результате мы видим грустную картину. Буфер любого размера заполняется за секунды, после чего скорость копирования падает. Отлично оптимизированный софт будет простаивать, ожидая, пока целевой накопитель сохранит входящий поток данных. Глядя на это, мы задаёмся риторическим вопросом: как коллеги вообще умудряются работать в таких условиях? Ведь слабое или неправильно подобранное оборудование способно свести на нет все усилия по оптимизации программного обеспечения, превращая работу в постоянное ожидание.