jschicht/logfileparserمحلل لـ $LogFile على NTFS
الميزات فك وتفريغ سجلات $LogFile وإدخالات المعاملات. فك تغييرات سمات NTFS. اختياريًا حل جميع معلومات قائمة datarun المتاحة في $LogFile. الخيار: "Reconstruct data runs". استعادة المعاملات من المساحة المهملة داخل $LogFile. اختيار إعادة بناء الرؤوس المفقودة أو التالفة للمعاملات الموجودة في المساحة المهملة. الخيار: "Rebuild header". اختياريًا أيضًا ضبط النتيجة بقيمة مستوى خطأ LSN. الخيار: "LSN error level". تسجيل إلى csv واستيراد إلى قاعدة بيانات sqlite مع عدة جداول. اختياريًا استيراد مخرجات csv من mft2csv إلى قاعدة البيانات. الاختيار من بين 6 تنسيقات مختلفة للطوابع الزمنية. اختيار دقة الطابع الزمني: None و MilliSec و NanoSec. اختيار فاصل الدقة عند millisec. اختيار فاصل الدقة عند nanosec. اختيار تعديل المنطقة للطوابع الزمنية. الافتراضي هو عرض الطوابع الزمنية بتوقيت UTC 0.0. اختيار فاصل المخرجات. الخيار: "Set separator". مخرجات UNICODE أو ANSI قابلة للتكوين. الخيار "Unicode". حجم سجل MFT قابل للتكوين (1024 أو 4096). الخيار "MFT record size". اختياريًا فك معاملات فردية أو معاملات جزئية (fragment). خيار إعادة بناء RCRD من معاملة واحدة أو عدة معاملات (fragments). خيار تكوين $LogFile تالف. مفيد مع RCRD المستخرجة كمدخل. خيار تخطي fixups (لـ $LogFile التالف، عادةً المستخرج من الذاكرة). مخرجات مفصلة verbose في debug.log. قائمة قابلة للتكوين مفصولة بفواصل من lsn لتشغيل معلومات ultra verbose حول معاملات محددة في debug.log. تكوين لنظام تشغيل 32-bit. تكوين لاستخراج البيانات الثنائية لتحديثات البيانات المقيمة. sql مُولَّد تلقائيًا لاستيراد المخرجات إلى قاعدة بيانات MySql. خيار تخطي كل ما يتعلق بـ sqlite3 لتسريع التحليل الكلي. وضع سطر أوامر اختياري. يدعم errorlevel المناسب لبرمجة batch.
الخلفية صُمم NTFS كنظام ملفات قابل للاستعادة. يتم ذلك من خلال تسجيل جميع المعاملات التي تغير بنية وحدة التخزين. لذا فإن أي تغيير في ملف على وحدة التخزين سيتطلب أيضًا تسجيل شيء ما في $LogFile، بحيث يمكن عكسه في حالة فشل النظام في أي وقت. لذلك تُكتب كمية كبيرة من المعلومات في هذا الملف، وبما أنه دائري، فهذا يعني أن المعاملات الجديدة تكتب فوق السجلات الأقدم في الملف. وبالتالي فإن كمية البيانات التاريخية التي يمكن استرجاعها من هذا الملف محدودة إلى حد ما. مرة أخرى، يعتمد ذلك على نوع وحدة التخزين وحجم $LogFile. على قرص النظام لنظام يُستخدم بشكل متكرر، من المحتمل أن تحصل فقط على بضع ساعات من السجل، بينما قرص خارجي/ثانوي يحتوي على ملفات نسخ احتياطي، من المحتمل أن يحتوي على معلومات تاريخية أكثر. وملف بحجم 2MB سيحتوي على سجل أقل بكثير من ملف بحجم 256MB. إذن في أي نطاق حجم يمكن تكوين هذا الملف؟ أي شيء من 256 KB وما فوق. يمكن تكوين الحجم إلى 2 GB بهذه الطريقة، "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 معلومات الإدخال اللازمة لإعادة بناء dataruns
LogFile_DataRunsResolved.csv المخرجات النهائية لـ dataruns المعاد بناؤها
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 مفكوكة لكل من نظام 32bit و 64bit.
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 المفكوكة الموجودة في المساحة المهملة.
LogFile_SlackOpenAttributeTable.csv جميع الإدخالات من معاملات OpenAttributeTableDump المفكوكة الموجودة في المساحة المهملة.
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 (جدول مؤقت يُستخدم عند إعادة إنشاء dataruns). UsnJrnl
الطوابع الزمنية يتم عرض الإعدادات الافتراضية بتوقيت UTC 0.00، وبدقة nanosecond. التنسيق الافتراضي هو YYYY-MM-DD HH:MM:SS:MSMSMS:NSNSNSNS. يمكن تكوينها. تشير الطوابع الزمنية المختلفة إلى: CTime تعني وقت إنشاء الملف. ATime تعني وقت تعديل الملف. MTime تعني وقت تعديل إدخال MFT. RTime تعني وقت آخر وصول للملف.
إعادة بناء dataruns.
العديد من العمليات على نظام الملفات ستُشغّل معاملة في $LogFile. تلك المتعلقة بسمة $DATA، أي محتوى الملف، تم تحديدها حتى الآن على أنها؛
InitializeFileRecordSegment CreateAttribute UpdateMappingPairs SetNewAttributeSizes
كلها تترك معلومات مختلفة في $LogFile. تتصرف تعديلات البيانات المقيمة بشكل مختلف ولا يمكن إعادة بنائها بهذه البساطة، على الأقل على وحدات تخزين NTFS القادمة من إصدارات Windows الحديثة.
InitializeFileRecordSegment هو عندما يتم إنشاء ملف جديد. وبالتالي سيكون لديه سمة $FILE_NAME، بالإضافة إلى محتوى سمة $DATA الأصلي، بما في ذلك dataruns. بما أن $LogFile دائري، والأحداث الأقدم تُكتب فوقها الأحدث، فإن التحدي مع $LogFile هو الحصول على معلومات تعود بعيدًا بما يكفي في الزمن. ومع ذلك، إذا كان InitializeFileRecordSegment موجودًا، فيجب أن نكون قادرين على إعادة بناء كل شيء، لأن جميع السجلات المكتوبة بعده ستكون متاحة أيضًا. سيكون لدينا أيضًا معلومات حول الإزاحة إلى قائمة datarun. هذه إزاحة نسبية تُحسب من بداية سمة $DATA. هذه معلومات مهمة يجب توفرها عند حساب مكان تعديل UpdateMappingPairs في قائمة datarun.
CreateAttribute هي السمة الأصلية عندما تم إنشاؤها لأول مرة (إذا لم تُكتب كجزء من InitializeFileRecordSegment). مع هذه أيضًا، يجب أن نكون قادرين على إعادة بناء dataruns لأن لدينا جميع المعاملات المتاحة لنا. ومع ذلك، هذه لن توفر لنا اسم الملف بحد ذاتها. هنا أيضًا، لدينا الإزاحة إلى قائمة datarun متاحة وهي مفيدة للغاية عند حل UpdateMappingPairs.
UpdateMappingPairs هي معاملة عند إجراء تعديلات على $DATA/dataruns (تغير محتوى الملف). المعلومات الموجودة في هذه المعاملة ليست كاملة، وهي تحتوي فقط على القيم الجديدة المضافة إلى قائمة datarun الموجودة. تحتوي أيضًا على إزاحة نسبية تخبرنا بمكان كتابة التغييرات في قائمة datarun. تُستخدم هذه الإزاحة بالاقتران مع الإزاحة إلى datarun كما هي موجودة في InitializeFileRecordSegment و CreateAttribute.
SetNewAttributeSizes هي معاملة تحتوي على معلومات حول أي تعديلات متعلقة بقيمة الحجم تم إجراؤها على سمة $DATA. هذا مرتبط ارتباطًا وثيقًا بـ UpdateMappingPairs الذي يحتوي فقط على تغييرات datarun.
مع عمليات redo الأربع المختلفة أعلاه يمكن لرقم مرجعي معين (ملف مميز) إعادة بناء بعض تاريخ تغييرات نظام الملفات للملف. بسبب طبيعته الدائرية، لدينا فقط جزء من السجل، الأحدث. يعتمد مدى السجل الذي يمكننا استرجاعه بشكل كبير على نوع وحدة التخزين المستهدفة. إذا كانت وحدة تخزين نظام، فإن أسبوعًا من السجل ربما أكثر مما يمكن توقعه، بينما قرص قابل للإزالة أو خارجي أو ثانوي سيحتوي على سجل أكثر بكثير. وبالتالي قد نعيد بناء السجل الكامل لملف محذوف (مع الكتابة فوق سجل $MFT الخاص به)، وبالتالي إعادة إنشاء قائمة datarun لإجراء الاستعادة عليها. في حالات أخرى قد لا نتمكن من إعادة بناء السجل الكامل، لذا يمكن إعادة بناء قائمة datarun جزئية فقط. ملف csv النهائي مع dataruns المعدلة، LogFile_DatarunsModified.csv، سيعرض dataruns بشكل مختلف.
الشرح: تلك التي تبدأ بـ "!" تشير إلى أن قائمة datarun الكاملة قد أُعيد إنشاؤها. تلك التي تبدأ بـ "?" تشير إلى استعادة جزئية، مع عدد "**" الذي يمثل البايتات المفقودة من قائمة datarun الأصلية.
لتبسيط استعادة ملف بناءً على datarun، يمكن للمرء استخدام PoC المرفق المسمى ExtractFromDataRuns. إنه واضح بذاته إلى حد كبير. فقط املأ قائمة datarun الكاملة، والحجم الحقيقي وحجم init، واسمًا لملف المخرجات. اختياريًا اختر معالجة ملفات الصور (قرص أو قسم). ضع علامة أيضًا إذا تم اكتشاف أي علم مضغوط/sparse. تغذيته بقائمة datarun معاد بناؤها جزئيًا لن تعمل! يرجى ملاحظة أن تدفقات البيانات البديلة يمكن تمييزها بوجود dataname وأيضًا بقيم OffsetInMft مختلفة لمرجع ملف معين.
حزمة التنزيل المنفصلة "SampleTinyNtfsVolume.zip" تحتوي على صورة قسم مع وحدة تخزين NTFS صغيرة لاختبارها. على وحدة التخزين يوجد ملفان غير مقيمين محذوفان وكلاهما تمت الكتابة فوق سجل 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 MB تفرض قيودًا متأصلة ومطلقة على عدد معاملات FS التاريخية. لذا فإن أقراص النظام لديها سجل محدود في $LogFile، بينما الأقراص الخارجية/الثانوية لديها معاملات تاريخية أكثر مخزنة. يمكن زيادة حجم $LogFile باستخدام chkdsk (chkdsk c: /L:262144). التغييرات في بيانات الملفات المقيمة لا تُخزن داخل $LogFile، فقط معلومات أن تغييرًا قد حدث تُخزن.
ملاحظة يحتوي $UsnJrnl على معلومات بطريقة أكثر ودية للبشر. على سبيل المثال كل سجل يحتوي على fileref و filename و timestamp وشرح لما حدث. كما يحتوي على معلومات تاريخية أكثر بكثير من $LogFile، وإن كان بدون الكثير من التفاصيل. إذا كان $UsnJrnl نشطًا، فإن جميع المعاملات المكتوبة إليه خلال دورة حياة إعادة التدوير لـ $LogFile موجودة أيضًا داخل $LogFile. هذا يعني أنه لا يوجد سبب لفك $UsnJrnl من أجل فهم $LogFile بشكل أفضل.
المساحة المهملة في هذا السياق تعني المساحة المهملة المساحة داخل سجل 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-bit مقابل 64-bit. هذا الإعداد مهم لضبطه بشكل صحيح. يعني أي نظام تشغيل تعامل مع وحدة التخزين المستهدفة. النقطة هي أن معالجة OpenAttributeTable تختلف من نظام 32-bit إلى نظام 64-bit. قد تكون هناك بالطبع حالات (على سبيل المثال قرص 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 بشدة المطورين باستخدام وسائل بديلة لتلبية احتياجات تطبيقاتك.[/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، يُلحق النص "Partial update" في حقل TextInformation. لهذا السبب، قد توجد أيضًا قيم مثل 0x0000000000007E-- في LsnUserData. وذلك لأن UpdateResidentValue بحجم 31 بايت يعني أن أول 3 أعضاء من البنية الكاملة مفقودة، وأيضًا بايت واحد من LsnUserData مفقود. البايت المفقود هو "البايت المنخفض"، وبالتالي حرفان/نبلان من "-" لكل منهما، كبديل للإشارة إلى البايت المجهول المفقود (في الواقع مجرد البايت الموجود). إذا كان UpdateResidentValue عند 32 بايت، فلن تكون هناك حاجة إلى أحرف/نبلات بديلة حيث تم توفير LsnUserData الكامل.
debug.log في هذا السجل تُكتب رسائل الأخطاء والمعلومات المطولة. إذا وُجدت قيم أو تعليقات غريبة في المخرجات، فابحث في debug.log عن lsn. عادةً يتم تفريغ المعاملة بأكملها، مما قد يساعد في الفهم. للمساعدة في التحقيقات في المعاملات، قد يكون من المفيد ملء قائمة مفصولة بفواصل من lsn في حقل الإدخال. حينئذ ستُطبع المعلومات المطولة لهذه الـ lsn.
$EA سمة $EA هي مجموعة من أزواج الاسم والقيمة ويُعتقد أنها موجودة للتوافق مع OS/2. نادرًا ما يُرى استخدامها، رغم أن بعض البرمجيات الخبيثة استخدمتها. يمكن أن يكون هناك عدة أزواج لكل سمة، لكن الحد الأقصى لحجمها جميعًا هو 65535 بايت. يمكن أن توجد سمة $EA واحدة فقط لكل ملف. يمكن نشر محتوى أكبر عبر عدة ملفات كما هو موضح في EaTools PoC؛ https://github.com/jschicht/EaTools لا يمكن تعديل سمات $EA الموجودة مباشرة. يمكن إضافة أزواج اسم/قيمة إضافية في أي وقت طالما أن حجم جميع الأزواج أقل من 0xFFFF بايت. السلوك الغريب لهذه السمة هو أن كل محتوى $EA بأكمله يُكتب إلى $LogFile لأي زوج جديد. وهذا ينطبق على محتوى $EA المقيم وغير المقيم على حد سواء. وهذا يعني أنه إذا أُضيف زوج اسم/قيمة ثالث إلى $EA، فستُكتب الأزواج الثلاثة جميعها إلى $LogFile إما عبر UpdateResidentValue أو UpdateNonResidentValue.
Todo تنفيذ المزيد من التحليل للبيانات الموجودة في ntfs.db. حاليًا سيتطلب مستوى معينًا من معرفة NTFS لفهم المخرجات. تفريغ محتوى $EA غير المقيم.
Command line use إذا لم تُقدَّم أي معاملات، فستُطلق واجهة المستخدم الرسومية افتراضيًا. المفاتيح الصالحة هي:
Switches: /LogFileFile: إدخال $LogFile المستخرج. مطلوب ما لم يُستخدم /LogFileFragmentFile:. /LogFileFragmentFile: اختياريًا إدخال جزء $LogFile. يمكن أن يكون أي جزء مكسور يحتوي على معاملة واحدة على الأقل. /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 لتحديد تنسيق الطابع الزمني. ابدأ واجهة المستخدم الرسومية لترى ما تعنيه. الافتراضي هو 6. /TSPrecision: الدقة المستخدمة في الطابع الزمني. القيم الصالحة هي None وMilliSec وNanoSec. الافتراضي هو NanoSec. /TSPrecisionSeparator: الفاصل الذي يوضع في فصل الدقة. الافتراضي هو ".". ابدأ واجهة المستخدم الرسومية لترى ما يعنيه. /TSPrecisionSeparator2: الفاصل الذي يوضع بين MilliSec وNanoSec في دقة الطابع الزمني. الافتراضي هو فارغ/لا شيء. ابدأ واجهة المستخدم الرسومية لترى ما يعنيه. /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.
المناطق الزمنية المتاحة للاستخدام هي: -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
Error levels تم تنفيذ رموز الخروج (الأخطاء) الحالية في وضع سطر الأوامر، مما يجعله أكثر ملاءمة للبرمجة النصية الدفعية.
وبالتالي إذا حصلت على %ERRORLEVEL% == 1 فهذا يعني أنه لم يتم فك ترميز أي شيء، وإذا حصلت على %ERRORLEVEL% == 2 فمن المرجح جدًا أن معامل SectorsPerCluster تم تعيينه بشكل غير صحيح.
Examples: 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.
References: 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
