Это райтап об одном из заданий, которое мы приготовили для отборочного этапа CTFZone, прошедшего в конце ноября. О процессе подготовки к квалификации можно прочитать здесь.

Вы начинаете с двумя файлами: decrypt_flag.py и ntfs_volume.raw. Давайте взглянем на скрипт. Он открывает файл c именем key.bin, а затем при помощи цикла пробует взять из каждого смещения внутри файла бинарную строку размером 34 байта, которая затем используется в качестве входных данных для функции PBKDF2. Каждый возвращенный ключ используется в качестве XOR-ключа для расшифровывания вшитой в код зашифрованной строки. Если в расшифрованной форме ее хеш MD5 совпадает с заранее определенным значением, скрипт использует полученные данные, чтобы сформировать и напечатать флаг.

Начиная с Windows 8 пользователи операционной системы могут заметить в журнале системных событий такое сообщение: «The access history in hive […] was cleared updating [...] keys and creating [...] modified pages». Что же скрывается за этим сообщением?

Можно ли создать такой ключ реестра, который будет виден в Windows в составе активного (подключенного) реестра, но не будет виден программам, работающим с неактивным (отключенным) реестром? Оказывается, если у вас есть возможность изменить лишь одну переменную ядра (например, с помощью драйвера), то да, способ есть.

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

Впервые точки остановки для ключей реестра появились в Windows XP, где была реализована возможность исполнения ядром инструкции int 3 при открытии ключа реестра с пометкой (отладочным флагом) BREAK_ON_OPEN или при создании подключа в составе такого ключа.

Являются ли аппаратные блокираторы записи более надежными по сравнению с программными?

Предисловие

Проведение криминалистических исследований при расследовании инцидентов информационной безопасности, производство судебных экспертиз и многие другие направления деятельности, связанные с компьютерной криминалистикой, требуют максимально возможного сохранения целостности исследуемых данных. Для этого используются блокираторы записи — программы или устройства, не позволяющие записать что-либо на исследуемый накопитель. Необходимость применения таких средств происходит как из требований процессуального законодательства (например, УПК РФ), так и из различных рекомендаций методического и иного характера, а также из стандартов (например, СТО БР ИББС-1.3-2016). Некоторые аспекты функционирования блокираторов записи и будут рассмотрены в настоящей статье.


Один из ранних аппаратных блокираторов записи (2002 год)

В конце 2010 года Грем Белл и Ричард Боддингтон опубликовали работу «Solid State Drives: The Beginning of the End for Current Practice in Digital Forensic Recovery?» («Твердотельные накопители: начало конца существующим методам судебного восстановления данных?»), которая вызвала неоднозначную реакцию интернет-сообщества. И хотя обсуждаемая в указанной статье особенность работы твердотельных накопителей была впервые озвучена в 2008 году на конференции DEFCON 16, исследована специалистами компании Майкрософт и представлена на конференции разработчиков машинных носителей информации в 2009-м [1, 6-й слайд] и даже упомянута на российских семинарах в 2010-м [2, слайды 10 и 11], признание проблемы и серьезное обсуждение этих особенностей в сообществе криминалистов пришлись на март 2011 года.

В этой заметке я постараюсь рассказать об особенностях работы носителей информации, основанных на использовании флеш-памяти, через призму компьютерной криминалистики.