Сразу приступаем к анализу файлов, структуры которых хорошо известны. В данном случае удобно использовать для анализа DBF файлы из базы 1С, так как структура их весьма предсказуема. Возьмем файл 1SENTRY.DBF.BLOCKED (журнал бухгалтерских проводок), размер данного файла 53 044 658 байт



Рассматривая шифрованный DBF файл, обращаем внимание на то, что первые 0x35 байт не зашифрованы, так как присутствует заголовок, характерный для данного типа файлов, и наблюдаем часть описания первого поля записи. Произведем расчет размера файла. Для этого возьмем: WORD по смещению 0x08, содержимое которого равно 0x04C1 (в нем указан размер заголовка DBF файла), WORD по смещению 0x0A, содержимое которого равно 0x0130 (в нем указан размер одной записи в базе), DWORD по смещению 0x04, содержимое которого равно 0x0002A995 (количество записей), и 0x01 – размер конечного маркера. Решим пример: 0x0130*0x0002A995+0x04C1+1=0x0032965B2 (53 044 658) байт. Размер файла, согласно записи файловой системы, соответствует расчетному на основании информации в заголовке DBF файла. Выполним аналогичные проверки для нескольких DBF файлов и удостоверимся, что размер файла не был изменен вредоносным ПО.

Анализ содержимого DBF показывает, что небольшие файлы начиная со смещения 0x35 зашифрованы целиком, а крупные нет.



Начиная со смещения 0x00132CB5 обнаруживаем отсутствие признаков шифрования до конца файла, выполнив проверки в иных крупных файлах подтверждаем предположение, что целиком шифруются только файлы менее 0x00132CB5 (1 256 629) байт. Многие авторы вредоносного ПО выполняют частичное шифрование файлов с целью сокращения времени искажения пользовательских данных. Руководствуются вероятно тем, чтобы их вредоносный код за минимальное время нанес максимально возможный ущерб пользователю.

Приступим к анализу алгоритма шифрования



На месте заголовков полей DBF файла присутствуют почти одинаковые последовательности из 16 байт (смещения 0x50, 0x70, 0x90), также видим частичное повторение последовательностей из 16 байт (смещения 0x40,0x60,0x80), в которых есть отличия только в байтах, где должно прописываться имя поля и тип поля.

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

Исходя из особенностей строения заголовков DBF файлов и изменений байт в последовательностях, можно сделать предположение, что шифрование выполнено посредством XOR операции над данными с неким паттерном. Также можно сделать предположение, исходя из длины повторяющихся последовательностей, что длина паттерна 16 байт (128 бит). Заголовок базы равен 0x04C1 байт, размер описания одного поля в заголовке 0х20 (32) байт. Из этого следует, что заголовок данного DBF файла содержит (0x4C1-0x21)/0x20=0x25 (37) описаний полей. На рисунке подчеркнуты красным фрагменты записей двух полей начиная со смещения 0x10, которые в случае 1С как правило имеют нулевые значения, кроме самого 0x10 (так как по этому смещению указывается размер поля), на основании этого можно полагать, что уже имеем 15 из 16 байт ключа шифрования 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xXX 0xAF 0x45 0x6A 0xB7.

Для нахождения последнего байта в ключе возьмем другой фрагмент этого же DBF файла.


На рисунке обратим внимание на нулевой столбец, точнее на его нешифрованную часть, и видим, что там преобладает значение 0x20 (код пробела согласно ASCII таблицы). Соответственно, и в шифрованной части столбца будет преобладать некое одинаковое значение. Легко заметить, что это 0xFA. Для получения оригинального значения недостающего байта ключа необходимо выполнить 0xFA xor 0x20=0xDA.

Подставив полученное значение на недостающую позицию, получим полный ключ 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xDA 0xAF 0x45 0x6A 0xB7.

После выполнения процедуры xor операции с полученным ключом над шифрованными участками получили оригинальное содержимое файла



Для окончательного контроля проведем операцию расшифровки zip архива, затем распакуем архив. Если все файлы извлеклись и не возникало ошибки CRC для какого-либо файла, то можно окончательно подтвердить корректность ключа. И финальным этапом будет распаковка остальных файлов согласно технического задания.

Данный пример говорит о том, что вероятно не все высказывания авторов вредоносного программного обеспечения правдивы. И нередко можно решить задачу восстановления пользовательских данных посредством анализа измененных данных.

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

Автор: hddmasters
Источник: Хабрахабр