jschicht/logfileparserПарсер для $LogFile на NTFS
Возможности Декодирование и дамп записей $LogFile и записей транзакций. Декодирование изменений атрибутов NTFS. Опциональное разрешение всей доступной информации списка datarun в $LogFile. Опция: "Reconstruct data runs". Восстановление транзакций из свободного пространства (slack space) внутри $LogFile. Возможность восстановления отсутствующих или повреждённых заголовков транзакций, найденных в slack. Опция: "Rebuild header". Опциональная дополнительная тонкая настройка результата с помощью значения уровня ошибки LSN. Опция: "LSN error level". Запись в csv и импорт в базу данных sqlite с несколькими таблицами. Опциональный импорт csv-вывода mft2csv в базу данных. Выбор среди 6 различных форматов временных меток. Выбор точности временных меток: None, MilliSec и NanoSec. Выбор разделителя точности на уровне миллисекунд. Выбор разделителя точности на уровне наносекунд. Выбор корректировки региона для временных меток. По умолчанию временные метки представляются в UTC 0.0. Выбор разделителя вывода. Опция: "Set separator". Настраиваемый вывод UNICODE или ANSI. Опция "Unicode". Настраиваемый размер записи MFT (1024 или 4096). Опция "MFT record size". Опциональное декодирование отдельных транзакций или частичных транзакций (фрагментов). Опция восстановления RCRD из одной или нескольких транзакций (фрагментов). Опция настройки для повреждённого $LogFile. Полезна при использовании вырезанных (carved) RCRD в качестве входных данных. Опция пропуска fixup (для повреждённого $LogFile, обычно вырезанного из памяти). Подробный детальный вывод в debug.log. Настраиваемый список lsn, разделённых запятыми, для запуска сверхдетальной информации о конкретных транзакциях в debug.log. Конфигурация для 32-битной ОС. Конфигурация для извлечения бинарных данных обновлений резидентных данных. Автоматически сгенерированный sql для импорта вывода в базу данных MySql. Опция пропуска всего, связанного с sqlite3, для ускорения общего парсинга. Опциональный режим командной строки. Поддерживает errorlevel, подходящий для пакетных сценариев.
Предыстория NTFS спроектирована как восстанавливаемая файловая система. Это достигается за счёт журналирования всех транзакций, изменяющих структуру тома. Таким образом, любое изменение файла на томе потребует, чтобы что-то было записано и в $LogFile, чтобы это можно было откатить в случае сбоя системы в любой момент. Поэтому в этот файл записывается много информации, и поскольку он циклический, это означает, что новые транзакции перезаписывают более старые записи в файле. Таким образом, объём исторических данных, которые можно извлечь из этого файла, несколько ограничен. Опять же, это зависит от типа тома и размера $LogFile. На системном диске часто используемой системы вы, вероятно, получите лишь несколько часов истории, тогда как внешний/вторичный диск с файлами резервных копий, вероятно, будет содержать больше исторической информации. А файл размером 2 МБ будет содержать гораздо меньше истории, чем файл размером 256 МБ. Так в каком диапазоне размеров можно настроить этот файл? От 256 КБ и выше. Настроить размер до 2 ГБ можно так: "chkdsk D: /L:2097152". Как большой размер файла журнала влияет на производительность, выходит за рамки этого текста. Установить его меньше 2048 обычно невозможно. Однако это возможно путём патча untfs.dll: http://code.google.com/p/mft2csv/wiki/Tiny_NTFS
Введение Этот парсер декодирует и выгружает множество информации о транзакциях из $LogFile в NTFS. Генерируется несколько csv-файлов, а также база данных sqlite с именем ntfs.db, содержащая всю соответствующую информацию. Вывод чрезвычайно детальный и очень низкоуровневый, что означает, что для его понимания требуются приличные знания NTFS. В настоящее время обрабатываются следующие типы Redo-транзакций с осмысленным декодированием вывода:
InitializeFileRecordSegment CreateAttribute DeleteAttribute UpdateResidentValue UpdateNonResidentValue UpdateMappingPairs SetNewAttributeSizes AddindexEntryRoot DeleteindexEntryRoot AddIndexEntryAllocation DeleteIndexEntryAllocation WriteEndOfIndexBuffer SetIndexEntryVcnRoot SetIndexEntryVcnAllocation UpdateFileNameRoot UpdateFileNameAllocation SetBitsInNonresidentBitMap ClearBitsInNonresidentBitMap OpenNonresidentAttribute OpenAttributeTableDump AttributeNamesDump DirtyPageTableDump TransactionTableDump UpdateRecordDataRoot UpdateRecordDataAllocation CompensationlogRecord
Список поддерживаемых в настоящее время атрибутов: $STANDARD_INFORMATION $ATTRIBUTE_LIST $FILE_NAME $OBJECT_ID $SECURITY_DESCRIPTOR $VOLUME_NAME $VOLUME_INFORMATION $DATA $INDEX_ROOT $INDEX_ALLOCATION $REPARSE_POINT $EA_INFORMATION $EA $LOGGED_UTILITY_STREAM
То есть, по сути, поддерживаются все атрибуты.
Объяснение различных генерируемых выходных данных:
LogFile.csv: Основной csv, генерируемый парсером.
LogFile_DataRuns.csv Входная информация, необходимая для восстановления datarun.
LogFile_DataRunsResolved.csv Итоговый вывод восстановленных datarun.
LogFile_INDX_I30.csv Все выгруженные и декодированные записи индексов (IndexRoot/IndexAllocation).
LogFileJoined.csv То же, что и LogFile.csv, но с присоединённой информацией об именах файлов из $UsnJrnl или csv-файла mft2csv.
MFTRecords.bin Фиктивный $MFT, воссозданный на основе найденных записей MFT в транзакциях InitializeFileRecordSegment. Можно применить к нему mft2csv (не забудьте правильно настроить "broken MFT" и "Fixups").
LogFile_lfUsnJrnl.csv Записи для $UsnJrnl, которые были декодированы внутри $LogFile.
LogFile_UndoWipe_INDX_I30.csv Все операции отмены (undo) для очистки индексов каталогов (INDX).
LogFile_AllTransactionHeaders.csv Все заголовки декодированных транзакций.
LogFile_BitsInNonresidentBitMap.csv Все декодированные операции SetBitsInNonresidentBitMap.
LogFile_DirtyPageTable32bit.csv и LogFile_DirtyPageTable64bit.csv Все записи в каждой декодированной операции DirtyPageTableDump как для 32-битной, так и для 64-битной ОС.
LogFile_Mft_ObjectId_Entries.csv Декодированные атрибуты $ObjectId.
LogFile_ObjIdO.csv Все декодированные данные из системного файла $ObjId:$O.
LogFile_OpenAttributeTable.csv Все записи в каждой декодированной операции OpenAttributeTableDump.
LogFile_QuotaO.csv Все декодированные данные из системного файла $Quota:$O.
LogFile_QuotaQ.csv Все декодированные данные из системного файла $Quota:$Q.
LogFile_RCRD.csv Все заголовки декодированных записей RCRD.
LogFile_ReparseR.csv Все декодированные данные из системного файла $Reparse:$R.
LogFile_SecureSDH.csv Все декодированные данные из системного файла $Secure:$SDH.
LogFile_SecureSII.csv Все декодированные данные из системного файла $Secure:$SII.
LogFile_SecurityDescriptors.csv Декодированные дескрипторы безопасности. Источником может быть $SECURITY_DESCRIPTOR или $Secure:$SDS.
LogFile_SlackAttributeNamesDump.csv Все записи из декодированных транзакций AttributeNamesDump, найденных в свободном пространстве (slack space).
LogFile_SlackOpenAttributeTable.csv Все записи из декодированных транзакций OpenAttributeTableDump, найденных в свободном пространстве (slack space).
LogFile_TransactionTable.csv Декодированные транзакции TransactionTableDump.
LogFile_Filenames.csv Все разрешённые имена файлов с MftRef, MftRefSeqNo и Lsn.
LogFile_TxfData.csv Декодированные данные из $DATA:$TXF_DATA в $LOGGED_UTILITY_STREAM.
LogFile_UpdateFileName_I30.csv Все декодированные данные операций UpdateFileNameRoot и UpdateFileNameAllocation как для redo-, так и для undo-операций.
LogFile_CompensationlogRecord.csv Все декодированные данные CompensationlogRecord. Не актуально для nt5.x.
Ntfs.db Файл базы данных sqlite с таблицами, почти эквивалентными вышеуказанным csv-файлам. База данных содержит 5 таблиц: DataRuns IndexEntries LogFile LogFileTmp (временная таблица, используемая при восстановлении datarun). UsnJrnl
Временные метки По умолчанию представляются в UTC 0.00 и с наносекундной точностью. Формат по умолчанию — YYYY-MM-DD HH:MM:SS:MSMSMS:NSNSNSNS. Их можно настроить. Различные временные метки означают: CTime означает время создания файла (File Create Time). ATime означает время изменения файла (File Modified Time). MTime означает время изменения записи MFT (MFT Entry modified Time). RTime означает время последнего доступа к файлу (File Last Access Time).
Восстановление datarun.
Многие операции в файловой системе вызывают транзакцию в $LogFile. Те, что относятся к атрибуту $DATA, то есть к содержимому файла, на данный момент идентифицированы как:
InitializeFileRecordSegment CreateAttribute UpdateMappingPairs SetNewAttributeSizes
Все они оставляют различную информацию в $LogFile. Модификации резидентных данных ведут себя иначе и не могут быть восстановлены просто так, по крайней мере на томах NTFS, происходящих из современных версий Windows.
InitializeFileRecordSegment — это когда создаётся новый файл. Таким образом, он будет иметь атрибут $FILE_NAME, а также исходное содержимое атрибута $DATA, включая datarun. Поскольку $LogFile циклический, и более старые события перезаписываются более новыми, задача с $LogFile состоит в том, чтобы получить информацию достаточно далеко назад во времени. Однако, если InitializeFileRecordSegment присутствует, то мы должны быть в состоянии восстановить всё, поскольку все записи, записанные после этого, также будут доступны. У нас также будет информация о смещении к списку datarun. Это относительное смещение, вычисляемое от начала атрибута $DATA. Это важная информация, которую нужно иметь при вычислении того, где в списке datarun UpdateMappingPairs произвёл свою модификацию.
CreateAttribute — это исходный атрибут, когда он был впервые создан (если не был записан как часть InitializeFileRecordSegment). С ним тоже мы должны быть в состоянии восстановить datarun, поскольку у нас доступны все транзакции. Однако сам по себе он не предоставит нам имя файла. Здесь тоже у нас есть доступное смещение к списку datarun, что чрезвычайно полезно при решении UpdateMappingPairs.
UpdateMappingPairs — это транзакция, когда выполняются модификации $DATA/datarun (содержимое файла изменилось). Информация, найденная в этой транзакции, неполна, и она содержит только новые значения, добавленные к существующему списку datarun. Она также содержит относительное смещение, которое сообщает нам, где в списке datarun были записаны изменения. Это смещение используется в сочетании со смещением к datarun, найденным в InitializeFileRecordSegment и CreateAttribute.
SetNewAttributeSizes — это транзакция, которая содержит информацию о любых модификациях, связанных со значениями размера, выполненными для атрибута $DATA. Это тесно связано с UpdateMappingPairs, который содержит только изменения datarun.
С помощью вышеуказанных 4 различных redo-операций можно для заданного ссылочного номера (конкретного файла) восстановить часть истории изменений файловой системы для файла. Из-за её цикличности у нас есть только часть истории, самая последняя. Объём истории, который мы можем извлечь, сильно зависит от того, каким является целевой том. Если это системный том, то неделя истории — это, вероятно, больше, чем вы могли бы ожидать, тогда как съёмный, внешний или вторичный диск будет содержать гораздо больше истории. Таким образом, мы можем восстановить полную историю удалённого файла (у которого запись $MFT была перезаписана) и, в свою очередь, воссоздать список datarun для выполнения восстановления. В других случаях мы можем быть не в состоянии восстановить полную историю, поэтому может быть восстановлен только частичный список datarun. Итоговый csv-файл с скорректированными datarun, LogFile_DatarunsModified.csv, будет отображать datarun иначе.
Объяснение: Те, что начинаются с "!", указывают, что полный список datarun был воссоздан. Те, что начинаются с "?", указывают на частичное восстановление, при этом количество "**" представляет отсутствующие байты исходного списка datarun.
Чтобы упростить восстановление файла на основе datarun, можно использовать прилагаемый PoC под названием ExtractFromDataRuns. Он довольно самоочевиден. Просто введите полный список datarun, реальный размер и начальный размер, а также имя для выходного файла. Опционально выберите обработку образов файлов (диска или раздела). Также отметьте, если был обнаружен какой-либо флаг сжатия/разреженности. Подача ему частично восстановленного списка datarun не сработает! Обратите внимание, что альтернативные потоки данных можно различить по наличию dataname, а также по различающимся значениям OffsetInMft для заданного fileref.
Отдельный загружаемый пакет "SampleTinyNtfsVolume.zip" содержит образ раздела с небольшим томом NTFS для тестирования на нём. На томе есть 2 удалённых нерезидентных файла, у обоих записи MFT перезаписаны новыми файлами. Любое приличное программное обеспечение для восстановления, основанное на поиске сигнатур, должно быть в состоянии восстановить jpg-файл (Tulips.jpg), потому что он непрерывный. Однако они, скорее всего, не определят его имя файла или что-либо ещё о файле. Второй файл, вероятно, не будет восстановим с помощью стандартных инструментов, потому что он фрагментирован (сжат), и из-за перезаписи его записи MFT восстановление файла без списка datarun невозможно. Используя PoC, мы можем идентифицировать имя файла (suspicious.zip) и извлечь его в идеальном виде (не волнуйтесь, он содержит только одно из образцовых изображений, поставляемых с Windows). Прочитайте файл readme.DataRunsResolved.txt для получения подробностей об образцовом образе и о том, как интерпретировать вывод и восстанавливать файлы.
Чего мы достигли с помощью этого — это восстановление фрагментированных файлов, у которых запись MFT перезаписана. Поскольку мы восстановили частичную/полную историю datarun, мы можем с уверенностью (по крайней мере, если восстановлена полная история) определить, принадлежали ли данные из свободного пространства файла данному файлу или нет.
Ограничение. Восстановление datarun нарушено с UNICODE (ANSI в порядке). Импорт вывода Mft2Csv нарушен, если csv в UNICODE (ANSI в порядке). Частичные обновления IndexRecords (IndexRoot/IndexAllocation) очень трудно интерпретировать, так как у нас, вероятно, нет знания об исходном индексе. Полные записи, однако, в порядке. Цикличность 65-мегабайтного файла накладывает внутреннее и абсолютное ограничение на количество исторических транзакций ФС. Таким образом, системные диски имеют ограниченную историю в $LogFile, тогда как внешние/вторичные диски имеют больше сохранённых исторических транзакций. Можно увеличить размер $LogFile с помощью chkdsk (chkdsk c: /L:262144). Изменения данных резидентных файлов не сохраняются в $LogFile, сохраняется только информация о том, что изменение было выполнено.
Примечание $UsnJrnl содержит информацию в более удобном для человека виде. Например, каждая запись содержит fileref, имя файла, временную метку и объяснение того, что произошло. Он также содержит гораздо больше исторической информации, чем $LogFile, хотя и без большого количества деталей. Если $UsnJrnl активен, то все транзакции, записанные в него в течение жизненного цикла переработки $LogFile, также присутствуют в $LogFile. Это означает, что нет причин декодировать $UsnJrnl, чтобы лучше понять $LogFile.
Свободное пространство (Slack space) В этом контексте свободное пространство означает пространство внутри записи RCRD, которое является остатком в записи за пределами последней транзакции. Я не думаю, что это описывалось ранее, поэтому позвольте мне объяснить. Свободное пространство тома — это неиспользуемое пространство между концом файловой системы и концом раздела, на котором находится файловая система. Свободное пространство записи MFT в некотором роде то же самое, но относится к пространству, найденному после сигнатуры конца записи (0xFFFFFFFF) вплоть до физического конца записи (0x400 или 0x1000). И свободное пространство внутри $LogFile — это, таким образом, пространство, найденное за пределами последней транзакции и вплоть до конца записи RCRD (обычно 0x1000). Эти транзакции из свободного пространства фактически находятся там с момента до того, как $LogFile был переработан (перезаписан). Существует также алгоритм, идентифицирующий допустимые транзакции из свободного пространства. Кроме того, может существовать также несколько слоёв такого свободного пространства. Пример: Допустим, последняя транзакция в данной записи RCRD закончилась на смещении 0x00007D27. От этого смещения и до 0x00007FFF у нас есть 0x2D8 байт свободного пространства. Затем может оказаться, что байты, начинающиеся с 0x00007D28, не являются допустимым заголовком транзакции, потому что они находятся в середине транзакции. Программа тогда (если настроена на это) попытается перестроить псевдозаголовок с допустимыми значениями, чтобы декодировать транзакцию. Если ей не удаётся перестроить какой-либо допустимый заголовок, она считает, что слишком много информации из исходного заголовка потеряно, и будет рассматривать эти байты как потерянные, и продолжит сканирование остальной части свободного пространства на предмет любого допустимого заголовка транзакции. Потерянные байты будут записаны в debug.log для вашего исследования. С другой стороны, если ей удалось перестроить допустимый заголовок, информация об этом будет найдена в поле lf_TextInformation. Допустим, она идентифицировала транзакцию, начинающуюся на смещении 0x00007D48 и с размером 0xB0. Затем сразу после неё на смещении 0x00007DF8 с размером 0xE0 была идентифицирована ещё одна хорошая транзакция. Однако на смещении 0x00007ED8 не было допустимого заголовка транзакции. Это означает, что мы теперь находимся на втором слое свободного пространства внутри этой записи RCRD. Теперь допустим, что программа после повторного сканирования смогла идентифицировать допустимый заголовок транзакции на смещении 0x00007F18. Эта транзакция будет отмечена в csv значением 2 в поле FromRcrdSlack. Однако учтите, что общий размер транзакции выводит смещение за пределы размера записи RCRD. По сути, это была бы частично восстановленная транзакция, которая может декодироваться нормально, но будет найдена со значением 1 в поле IncompleteTransaction. Помните, что debug.log очень детален и поможет понять декодированный вывод, особенно то, что исходит из свободного пространства.
Конфигурация 32-бит против 64-бит. Эту настройку важно установить правильно. Она означает, какая ОС обрабатывала целевой том. Дело в том, что обработка OpenAttributeTable отличается для 32-битной и 64-битной ОС. Конечно, могут быть случаи (например, usb-диск), когда том обрабатывался несколькими разными ОС, и в этом случае может быть сложно установить эту настройку на 100% правильно. Начиная с версии 2.0.0.8 был реализован механизм автоопределения. Однако всё же рекомендуется попытаться установить эту конфигурацию правильно. В поле TextEinformation будет напечатано сообщение "Mixed OS detected", когда он обнаружит формат OpenAttributeTableDump, отличающийся от конфигурации, или когда будут обнаружены оба типа. В любом случае может быть полезно заглянуть в LogFile_OpenAttributeTable.csv, чтобы оценить вывод. Если вы видите записи со столбцами, содержащими странные значения, то, возможно, эта конкретная настройка неверна. Если так, то большинство значений будут сильно искажены. Например, большинство полей AttributeType будут UNKNOWN, Lsn не входит в текущий диапазон, MftRef слишком велик, а MftRefSeqNo равен 0. Учтите, что AttributeType разрешается как UNKNOWN для неинициализированных записей в таблице, но их легко заметить, так как все значения после AllocatedOrNextFree равны 0, и это совершенно допустимо. Эти проблемы, похоже, исправлены с помощью автоопределения, реализованного в версии 2.0.0.8.Извлечение обновлений резидентных атрибутов (UpdateResidentValue). Операция UpdateResidentValue предназначена для обновления содержимого резидентных атрибутов. Настройка "Extract resident updates of min size" позволит вам извлечь бинарные изменения резидентного атрибута. Поле ввода задаёт минимальный размер в байтах для извлечения. Наиболее интересное применение этой функции, вероятно, связано с томами, обрабатываемыми Nt5.x (XP, 2003), где полные обновления атрибута $DATA (обычное содержимое файла) хранятся в полях redo и undo с помощью UpdateResidentValue. Файлы с резидентным содержимым $DATA — это файлы меньшего размера, максимум 744 байта (при размере записи MFT 1024), но обычно меньше. Извлечённые данные записываются в подпапку с именем ResidentExtract. Выходные файлы именуются по следующей логике: MFT($MFTRef)$OffsetInMft$AttributeOffset_LSN($Lsn)$Operation.bin. Например, MFT(1643)_0x0098_0x00B8_LSN(1415242628)redo.bin означало бы запись MFT номер 1643, смещение целевого атрибута в MFT равно 0x98, смещение изменения внутри целевого атрибута равно 0xB8, LSN транзакции равен 1415242628, и это была операция redo. Таким образом, извлечения для операций undo содержат данные по этому смещению до изменения. Активация этой функции вызовет некоторый нерелевантный и неинтересный вывод. Большинство ложных срабатываний фильтруются автоматически, но некоторые неизбежны. Например, могут быть включены обновления $INDEX_ROOT, $ATTRIBUTE_LIST и $BITMAP. Однако можно вручную отследить атрибуты, чтобы отфильтровать не-$DATA, сравнив OffsetInMft с тем, что найдено в соответствующем InitializeFileRecordSegment или, если применимо, в самой $MFT. Начиная с версии 2.0.0.13 добавлено извлечение $EA. См. примечание об атрибутах $EA.
Filenames csv Начиная с версии 2.0.0.6 была реализована новая функция для выгрузки всех идентифицированных имён файлов. Источником этих записей являются InitializeFileRecordSegment, UpdateNonResidentValue, AddindexEntryRoot, DeleteindexEntryRoot, AddIndexEntryAllocation, DeleteIndexEntryAllocation и WriteEndOfIndexBuffer. Таким образом, csv с этими именами файлов, LogFile_FileNames.csv, содержит восстановленную историю всех имён файлов, MftRef и MftRefSeqNo за время существования истории $LogFile. Таким образом, вы сможете увидеть все различные имена файлов, которые имела данная запись MFT в течение временного промежутка, охваченного $LogFile. При переименовании файла MftrefSeqNo не увеличивается. Когда запись MFT помечается как удалённая, а позже используется повторно, MftRefSeqNo увеличивается на единицу при новой инициализации.
$TXF_DATA При использовании Transactional NTFS (TxF) будут встречаться вхождения именованного потока $TXF_DATA в атрибуте $LOGGED_UTILITY_STREAM. Он всегда резидентный, и их может быть несколько на файл. Использование не распространено, и Microsoft фактически поощряет альтернативные методы. [quote]Microsoft strongly recommends developers utilize alternative means to achieve your applications needs.[/quote]. Похоже, лишь немногие механизмы обновления программного обеспечения используют его. Каждый файл/папка, созданные с его помощью, получают уникальный fileref (не путать с номерами записей MFT). Этот уникальный fileref — это то имя, которое файл получит при последующем удалении (и перемещении в папку $Extend$RmMetadata$Txf). Стандартный безымянный атрибут $DATA файла $Tops содержит информацию о том, куда в $TxfLogContainer00000000000000000001 пойдёт следующая транзакция. Именованный поток $DATA $T файла $Tops содержит фактические данные (от транзакционных файловых операций), которые перерабатываются. Внутри $TXF_DATA также есть поле под названием LsnUserData, которое является смещением в $TxfLogContainer00000000000000000001, где находится гораздо больше деталей транзакции. LsnNtfsMetadata также содержит смещение в тот же файл $TxfLogContainer00000000000000000001. Обратите внимание, что эти смещения могут быть изменены на более позднем этапе, и тогда на них ссылаются в операции UpdateResidentValue в $LogFile. Поле MftRef_RM_Root — это номер записи файла корня диспетчера ресурсов, ответственного за транзакцию, связанную с этим файлом (по умолчанию 5, что является корневым каталогом). Для обновлений $TXF_DATA через UpdateResidentValue в поле TextInformation добавляется текст "Partial update". По этой причине в LsnUserData также могут присутствовать значения вида 0x0000000000007E--. Это связано с тем, что UpdateResidentValue размером 31 байт означает, что отсутствуют первые 3 члена полной структуры, а также отсутствует 1 байт из LsnUserData. Отсутствующий байт — это "младший байт", таким образом, 2 символа/ниббла по "-" каждый, в качестве замены для указания отсутствующего неизвестного байта (фактически просто существующего байта). Если бы UpdateResidentValue был размером 32 байта, то символы/нибблы замены не потребовались бы, так как полный LsnUserData был бы предоставлен.
debug.log В этом журнале записываются сообщения об ошибках и подробная информация. Если в выводе обнаружены странные значения или комментарии, поищите в debug.log по lsn. Обычно выгружается вся транзакция, что может помочь понять ситуацию. Для содействия исследованиям транзакций может быть полезно заполнить разделённый запятыми список lsn в поле ввода. Тогда для этих lsn будет выведена подробная информация.
$EA Атрибут $EA представляет собой набор пар имя-значение и, как считается, существует для совместимости с OS/2. Он редко встречается в использовании, хотя некоторые вредоносные программы его применяли. На атрибут может приходиться несколько пар, но максимальный размер всех составляет 65535 байт. На файл может быть только 1 атрибут $EA. Содержимое большего размера может быть распределено по нескольким файлам, как показано в PoC EaTools; https://github.com/jschicht/EaTools Существующие атрибуты $EA не могут быть напрямую изменены. Дополнительные пары имя/значение могут быть добавлены в любое время, пока размер всех пар ниже 0xFFFF байт. Странное поведение этого атрибута заключается в том, что всё содержимое всего $EA записывается в $LogFile при любой новой паре. Это касается как резидентного, так и нерезидентного содержимого $EA. Это означает, что если к $EA добавляется третья пара имя/значение, все 3 пары записываются в $LogFile либо через UpdateResidentValue, либо через UpdateNonResidentValue.
Todo Реализовать больше анализа данных, присутствующих в ntfs.db. В настоящее время для понимания вывода потребуется определённый уровень знаний NTFS. Выгружать нерезидентное содержимое $EA.
Использование из командной строки Если параметры не указаны, по умолчанию запускается GUI. Допустимые ключи:
Ключи: /LogFileFile: Входной извлечённый $LogFile. Обязателен, если не используется /LogFileFragmentFile:. /LogFileFragmentFile: Опционально входной фрагмент $LogFile. Может быть любым повреждённым фрагментом, содержащим как минимум 1 транзакцию. /MftCsvFile: Выходной csv последнего Mft2Csv. Опционально. /OutputPath: Выходной путь для всего вывода парсера. По умолчанию — каталог программы. /TimeZone: Строковое значение для часового пояса. См. примечания ниже для допустимых значений. /OutputFormat: Выходной формат csv. Допустимые значения: l2t, BodyFile, all. /BrokenMft: Булево значение для обработки MFT с плохим форматом. По умолчанию 0. Может быть 0 или 1. /SkipFixups: Булево значение для пропуска fixups. В первую очередь используется с дампами памяти. По умолчанию 0. Может быть 0 или 1. /Separator: Разделитель для использования в csv. По умолчанию | /Unicode: Булево значение для декодирования строк unicode. По умолчанию 0. Может быть 0 или 1. /TSFormat: Целое число от 1 до 6 для указания формата временной метки. Запустите gui, чтобы увидеть, что они означают. По умолчанию 6. /TSPrecision: Какую точность использовать во временной метке. Допустимые значения: None, MilliSec и NanoSec. По умолчанию NanoSec. /TSPrecisionSeparator: Разделитель, помещаемый при отделении точности. По умолчанию ".". Запустите gui, чтобы увидеть, что это означает. /TSPrecisionSeparator2: Разделитель, помещаемый между MilliSec и NanoSec в точности временной метки. По умолчанию пустой/отсутствует. Запустите gui, чтобы увидеть, что это означает. /TSErrorVal: Пользовательское значение ошибки для помещения при ошибках декодирования временной метки. Значение по умолчанию — '0000-00-00 00:00:00', что совместимо с MySql и представляет недопустимое значение временной метки для NTFS. /ReconstructDataruns: Булево значение для указания, следует ли выполнять реконструкцию dataruns. По умолчанию 0. Может быть 0 или 1. /MftRecordSize: Размер записей MFT. Допустимые значения: 1024 и 4096. По умолчанию 1024. /RebuildHeadersSlack: Булево значение для указания, следует ли пытаться восстановить заголовок из повреждённых транзакций, восстановленных из slack. По умолчанию 0. Может быть 0 или 1. /SectorsPerCluster: Количество секторов на кластер. По умолчанию 8. Может быть 1,2,4,8,16,32,64 и 128. /LsnErrorLevel: Значение от 0 до 1 (100%), как порог для идентификации допустимой/недопустимой транзакции из slack, на основе предыдущего lsn. По умолчанию 0.1 (10%). /SourceIs32bit: Булево значение для указания, происходит ли том из 32-битной системы. По умолчанию 0 (x64). Может быть 0 или 1. /ExtractDataUpdates: Булево значение для указания, следует ли выполнять извлечение резидентного содержимого данных. По умолчанию 0. Может быть 0 или 1. /ExtractDataUpdatesSize: Значение для установки минимального размера в байтах для того, что извлекать. Используется только с настройкой ExtractDataUpdates. По умолчанию 2 (байта) как минимум. /VerboseLsnList: Разделённый запятыми список lsn, которые активируют подробный режим. Подробная информация журналирования находится в debug.log. /SkipSqlite3: Булево значение для указания, должен ли парсер пропускать все операции sqlite3. Если сгенерированный ntfs.db (реконструкция dataruns, импорт mft csv) не используется, это можно безопасно игнорировать/опустить. По умолчанию 0. Может быть 0 или 1. /VerifyFragment: Булево значение для активации простой проверки только фрагмента, а не полного парсера. Может быть 0 или 1. По умолчанию будет записывать исправленный фрагмент в OutFragment.bin, если иное не указано в /OutFragmentName: /OutFragmentName: Имя выходного файла для записи исправленного фрагмента, если /VerifyFragment: установлен в 1. Если опущено, имя файла по умолчанию — OutFragment.bin. /SkipFixups: Булево значение для пропуска fixups. Используется с реконструированными фрагментами. См. примеры. По умолчанию 0. Может быть 0 или 1. /BrokenLogFile: Булево значение для обработки $LogFile как повреждённого. Используется с реконструированными RCRD и обходит несколько проверок валидации. По умолчанию 0. Может быть 0 или 1.
Доступные для использования TimeZone: -12.00 -11.00 -10.00 -9.30 -9.00 -8.00 -7.00 -6.00 -5.00 -4.30 -4.00 -3.30 -3.00 -2.00 -1.00 0.00 1.00 2.00 3.00 3.30 4.00 4.30 5.00 5.30 5.45 6.00 6.30 7.00 8.00 8.45 9.00 9.30 10.00 10.30 11.00 11.30 12.00 12.45 13.00 14.00
Уровни ошибок Текущие коды выхода (ошибок) были реализованы в режиме командной строки, что делает его более подходящим для пакетных сценариев.
Таким образом, если вы получаете %ERRORLEVEL% == 1, это означает, что ничего не было декодировано, а если вы получаете %ERRORLEVEL% == 2, то, скорее всего, параметр SectorsPerCluster был задан неверно.
Примеры: LogFileParser.exe /LogFileFile:c:\temp$LogFile /TimeZone:2.00 /MftRecordSize:4096 /ExtractDataUpdates:1 /ExtractDataUpdatesSize:8 /SectorsPerCluster:64 /TSFormat:1 /TSPrecision:NanoSec /Unicode:1 LogFileParser.exe /LogFileFile:c:\temp$LogFile /TimeZone:-5.00 /MftRecordSize:1024 /SectorsPerCluster:1 /TSFormat:1 /TSPrecision:MilliSec /Unicode:0 LogFileParser.exe /LogFileFile:c:\temp$LogFile /TSFormat:3 /ReconstructDataruns:1 LogFileParser.exe /LogFileFile:c:\temp$LogFile /TimeZone:7.00 /MftRecordSize:1024 /TSFormat:2 /TSPrecision:None /SourceIs32bit:1 LogFileParser.exe /LogFileFile:c:\temp$LogFile /TimeZone:7.00 /MftRecordSize:1024 /TSFormat:2 /TSPrecision:None /SourceIs32bit:1 /SkipSqlite3:1 LogFileParser.exe /LogFileFile:c:\temp$LogFile /OutputPath:E:\LFP-Output LogFileParser.exe /LogFileFile:c:\temp$LogFile /MftCsvFile:c:\temp$MFT LogFileParser.exe /LogFileFragmentFile:c:\temp\fragment.bin /OutputPath:E:\LFP-Output LogFileParser.exe /LogFileFragmentFile:c:\temp\fragment.bin /OutputPath:E:\LFP-Output /VerifyFragment:1 LogFileParser.exe /LogFileFragmentFile:c:\temp\fragment.bin /OutputPath:E:\LFP-Output /VerifyFragment:1 /OutFragmentName:FragmentsRCRDCollection.bin LogFileParser.exe /LogFileFile:E:\LFP-Output\FragmentsRCRDCollection.bin /OutputPath:E:\LFP-Output /SkipFixups:1 /BrokenLogFile:1
Последний пример — базовый, использующий общие значения по умолчанию, которые во многих случаях работают вполне нормально. Также совместим с импортом MySql.
Ссылки: Windows Internals 6th Edition http://www.opensource.apple.com/source/ntfs/ntfs-80/kext/ntfs_logfile.h https://dl.dropbox.com/s/c0u980a53ipaq7h/CEIC-2012_Anti-Anti_Forensics.pptx?dl=1
