هذه المقالة مخصصة لدراسة بنية ملف القرص الصلب لمسجل فيديو ذي ثماني قنوات لغرض الاستخراج الجماعي لملفات الفيديو. في نهاية المقال يتم تنفيذ البرنامج المقابل في C.
مسجل الفيديو (DVR المختصر) QCM-08DL يستخدم في أنظمة المراقبة بالفيديو ويسمح بتسجيل الفيديو والصوت ثماني القنوات. هذا النموذج ، في رأيي ، هو واحد من أرخص وأسرع عملية في الوقت نفسه. تنسيق ضغط الفيديو هو تنسيق H264 الشائع. للصوت ، تنسيق الضغط هو ADPCM. يتم تسجيل الفيديو والصوت على محرك الأقراص الصلبة SATA (HDD) لجهاز الكمبيوتر القياسي المثبت داخل DVR. باستخدام DVR نفسه ، من الممكن عرض التسجيلات من خلال البحث عنها حسب التاريخ والوقت. أيضا ، من الممكن استخراج البيانات إلى ملف على وسيط خارجي. أولاً ، إلى محرك أقراص USB متصل بواجهة USB الخاصة بـ DVR. ثانيًا - إلى الكمبيوتر عبر واجهة WEB الخاصة بـ DVR. اسم الملف الناتج طويل ، ويتضمن تاريخ التسجيل ووقت البدء والانتهاء وقناة التسجيل ومعلومات إضافية أخرى. ملحق الملف هو ".264". أوضح لي فحص محتويات هذا الملف أن حاوية الوسائط التي يتم فيها تعبئة تدفقات الصوت والفيديو بعيدة عن المعيار. يمكن فتح مثل هذا الملف باستخدام المشغل الذي يأتي مع DVR. اللاعب غير مريح للغاية. ولكن أيضًا ، يمكنك استخدام برنامج إعادة التعبئة إلى حاوية AVI ، المضمنة أيضًا. يعيد هذا البرنامج تجميع دفق الفيديو ، ويتركه بتنسيق H264. ويتحول دفق الصوت من ADMCM إلى PCM ، مما يزيد من حجمه 4 مرات. والنتيجة هي ملف .avi يمكن تشغيله بواسطة أي لاعب قياسي. ألاحظ على الفور أن برنامج إعادة التعبئة هذا غير مريح للغاية. يسمح لك بإجراء العمليات على ملف واحد فقط. لإعادة حزم مجموعة من الملفات عليك فتحها بدورها.
تم تعيين المهام التالية.
- احصل على إمكانية الوصول إلى جميع ملفات .264 من القرص الثابت لجهاز تسجيل الفيديو الرقمي عن طريق توصيل القرص الثابت بجهاز الكمبيوتر.
- لدراسة الخوارزمية التي يعمل من خلالها برنامج إعادة التعبئة 264-avi القياسي وإنشاء نفس البرنامج الذي سيؤدي نفس العمليات ، ولكن ليس على واحدة ، ولكن على مجموعة كاملة من الملفات ، بنقرة واحدة.
قد تبدو المهمة الأولى ، للوهلة الأولى ، بسيطة للغاية: ما عليك سوى توصيل محرك الأقراص الصلبة بالكمبيوتر وفتح الأقسام في Explorer. ومع ذلك ، هناك مطبات. هذه المقالة مخصصة للمهمة الأولى.
لقد علمت مسبقًا مسبقًا أن غلاف برنامج متحكم DVR يعتمد على نظام تشغيل مشابه لنظام Linux. لذلك ، فإن تقسيم القرص الصلب سيكون على الأرجح شبيهًا بنظام Linux. لذلك ، تحتاج إلى كمبيوتر Linux. في حالتي ، تبلغ سعة القرص الصلب 1 تيرابايت ، كمبيوتر يعمل بنظام OS Xubuntu. بعد توصيل محرك الأقراص الصلبة بالكمبيوتر ، تمكنت من رؤية قسم واحد فقط لكل عدة غيغابايت. من الواضح أن هذا ليس ما تحتاجه. يوجد بداخل القسم العديد من المجلدات بتنسيق الاسم "YYYY-MM-DD" المقابلة لتواريخ السجلات. يوجد داخل كل مجلد العديد من الملفات المقابلة للإدخالات. ملفات بنفس الاسم تم الحصول عليها عند الاستخراج من DVR. ومع ذلك ، حجمها أصغر عدة مرات وليس الامتداد .264 ، ولكن .nvr. يجب افتراض أن ملفات nvr نفسها هي مفاتيح لملفات 264 المقابلة (أو تدفقات الوسائط الخاصة بها) ، والتي توجد محتوياتها على مساحة محرك الأقراص الصلبة الرئيسية. قمت بنسخ البيانات من مجلد الملف إلى وسيط منفصل لمزيد من البحث.
لقد استخدمت الكثير من أدوات البرمجيات للبحث: محرر قرص (وهو أيضًا محرر ملف ثنائي) DiskExplorer (استخدمت WinHex لاحقًا) ، MS Excel لإجراء العمليات الحسابية الإضافية وتحديد النتائج ، بيئة برمجة Dev-C ++ لكتابة برامج وحدة التحكم الإضافية والنهائية ، إلخ. في هذه المقالة سأحاول التحدث عن هذا الإجراء.
أولاً ، انظر إلى أول قطاع من محركات الأقراص الصلبة (قطاع واحد (1 LBA) يأخذ 512 بايت). يحتوي هذا القطاع ، كقاعدة عامة ، على بنية MBR. يتضمن محمل إقلاع وجدول أساسي لأقسام المحتويات. هيكل هذا القطاع ، بالإضافة إلى هيكل وصف القسم ، موضح أدناه (مأخوذ من ويكيبيديا).
في حالة الأقراص الصلبة التي تم التحقيق فيها ، لدينا ما يلي. بالنظر إلى الشكل أدناه واتباع الجداول أعلاه ، نرى أن أداة تحميل التشغيل مفقودة. لكننا مهتمون أكثر بجدول التقسيم. يتم تمييزه في إطار أحمر. آخر وحدتي بايت (تعبئة زرقاء) - توقيع MBR. يمكنك أن ترى من جدول الأقسام أن القرص مقسم إلى قسمين. رمز نوع القسم الأول (تعبئة صفراء) هو 0x0B. هذا قسم FAT32. رمز نوع الثاني (تعبئة برتقالية) هو 0x83. هذا هو أحد أقسام Linux (بمعنى EXT). بايت رمز نوع التقسيم محاطة بدائرة باللون الأزرق.
يتم أدناه فك تشفير قطاع MBR مع جدول الأقسام ومعلماتها أدناه.
مع الانتباه إلى حجم الأقسام (حساب عدد القطاعات بالجيجابايت) ، من السهل تخمين أنه على الكمبيوتر مع نظام التشغيل Xubuntu كان القسم الأول الذي احتل جزءًا صغيرًا من مساحة القرص. بالمناسبة ، تم عرض القسم الأول فقط في نظام التشغيل Windows XP ، ولكن لم يتم فتحه من المستكشف. ولماذا لم يظهر قسم Linux الثاني على نظام Xubuntu OS؟
بعد دراسة هيكل وتنظيم نظام ملفات Linux سابقًا باستخدام EXT2 كمثال ، بدأت في دراسة القسم الثاني.
كما ترى من جدول القسم ، يبدأ القسم الثاني بقطاع 16016805. يشير دليل نظام الملفات EXT2 إلى وجود ما يسمى الكتلة الفائقة ، والتي تقع على 1024 بايت من بداية القسم (أي قطاعين من البداية). ومع ذلك ، كان القطاع 16016805 + 2 = 16016807 فارغًا. لكن القطاع الأول 16016805 في هيكله يشبه الكتلة الفائقة. لكن محتوياته لا تتوافق تمامًا مع وصف محتويات superblock من الدليل. الكتلة الفائقة هي الكتلة الرئيسية ، والتي تحتوي على نوع من الجدول للثوابت والمعلمات المختلفة لعمل نظام الملفات: عناوين المواضع وأحجام الكتل الضرورية الأخرى ، على وجه الخصوص ، رؤوس سجلات الملفات والأدلة. قادني المزيد من البحث في هذا القسم إلى استنتاج واحد فقط: يستخدم DVR نظام الملفات الفريد الخاص به.
في المستقبل ، قررت أن ألقي نظرة على القطاع الأول من القسم الأول (القطاع 63) والتمرير لأسفل. تم العثور على محتوى القطاع 65 (قطاعان أدناه) الذي يشبه تمامًا محتويات Superblock FS EXT2 ، الموصوفة في الدليل. أدى المزيد من البحث إلى استنتاج أن القسم الأول من HDD DVR هو قسم EXT2 ، الذي تم عرضه على نظام Xubuntu OS ، بغض النظر عن علامة 0x08 (وليس EXT) في جدول المحتويات! وبالتالي ، فإن القسم الأول من محرك الأقراص الثابتة DVR هو قسم EXT2 ، حيث يتم تسجيل ملفات nvr ، وهي مفاتيح تسجيلات الفيديو المطلوبة.
سأكتب بإيجاز عن بنية ملفات .264 ، التي قمت أيضًا بفحصها سابقًا. ستكون هذه المعلومات مطلوبة في المستقبل لدراسة القسم الثاني من محرك الأقراص الثابتة. كما هو الحال في أي حاوية وسائط ، في "264" يوجد رأس يحتوي على معلومات الخدمة وعلامات الوسائط ، بالإضافة إلى تدفقات الصوت والفيديو التي تتبع في كتل صغيرة واحدة تلو الأخرى. عند إزاحة 0x84 بايت من بداية الملف ، يتم تسجيل الكلمة الأساسية "MDVR96NT_2_R". قبل هذه الكلمة توجد وحدات بايت تتعلق بتاريخ ووقت التسجيل. لكن هذه المعلومات واردة في اسم الملف ، وبالتالي ، فهي لا تستحق اهتمامًا خاصًا هنا. بعد ذلك يأتي الكثير من الأصفار. تنشأ المعلومات الرئيسية مع تدفقات الصوت والفيديو عند إزاحة 65.536 بايت. تبدأ كتل تدفق الفيديو برأس من 8 بايت "01dcH264" (وجد أيضًا "00dcH264"). تصف وحدات البايت الأربعة التالية حجم الكتلة الحالية لدفق الفيديو بالبايت. بعد 4 بايت من الأصفار (00 00 00 00) ، تبدأ كتلة دفق الفيديو نفسها. تحتوي كتل التدفق الصوتي على العنوان "03wb" (على الرغم من أنه وفقًا لملاحظاتي ، فإن الحرف الأول من الرأس في بعض الحالات لم يكن بالضرورة "0"). بعد - 12 بايت من المعلومات التي لم أحسبها بعد. بدءًا من 17 بايت - دفق صوتي بطول ثابت 160 بايت. لا توجد علامات في نهاية الملف.
نشرع في دراسة هيكل الملفات والأدلة الموجودة على القسم الأول من محرك الأقراص الصلبة. كما ذكر أعلاه ، تم نسخ محتويات القسم إلى وسيط منفصل من خلال مستكشف منتظم في نظام التشغيل Xununtu. في كل دليل (دليل) ، بالإضافة إلى ملفات nvr ، يوجد ملف ثنائي واحد يسمى "file_list". إذا حكمنا من خلال الاسم ، فإنه يحتوي على معلومات حول قائمة الملفات في الدليل الحالي. افتح هذا الملف في المحرر الثنائي (انظر الشكل أدناه). لقد بحثت في بنية هذا الملف ، ولا يوجد شيء مثير للاهتمام هنا. لا يحتوي الملف على أي معلومات تتعلق بموقع تدفقات الوسائط المطلوبة. ومع ذلك ، سأكتب بإيجاز عن هذا الهيكل. أول 32 بايت رأس مع بعض الثوابت. ترتبط البايتات الـ 16 التالية بالتاريخ والوقت وعدد الملفات في الدليل الحالي. ويتبع ذلك 48 بايت من الثوابت. التالي - 8 بايت من الثوابت ، تشير إلى بداية سجل الملف. بعد ذلك ، تشير 96 بايت إلى المسار الكامل لملف nvr ، بما في ذلك اسمه. التالي - 24 بايت تتعلق بالوقت (عدد الثواني المنقضية من بداية اليوم وبداية ونهاية الفيديو) وسمات أخرى للفيديو. وهكذا ، عن طريق القياس ، لجميع ملفات nvr في الدليل الحالي. عددهم يساوي عدد مقاطع الفيديو لليوم الحالي ، المشار إليه باسم الدليل الحالي. ما هو هذا الملف؟ على ما يبدو ، لتسريع البحث عن الفيديو داخل واجهة DVR.
دعنا ننتقل إلى دراسة بنية ملفات nvr نفسها. يظهر شكل أحد هذه الملفات في محرر ثنائي (بتعبير أدق في محرر سداسي عشري) في الشكل أدناه. دون الخوض في تفاصيل وصف بنية المحتوى (التي ظل جزء منها لغزا بالنسبة لي) ، أبرزت المعلمات الأساسية ، وهي المفتاح الذي يمكن العثور عليه. هذه هي قيم 32 بت (4 بايت) ، تقع كل 32 بايت ، بدءًا من البايت عند الإزاحة 40. في الشكل يتم تمييزها باللون الأحمر. في المستقبل ، أصبحت مقتنعًا بأن هذا يكفي تمامًا لمفتاح مقاطع الفيديو. أذكرك أن 4 بايت من قيمة هذه المعلمة الرئيسية تقع من الأدنى إلى الأعلى ، ولكن ليس العكس! يرجع هذا الترميز إلى بنية معالج الكمبيوتر. يوضح المثال في الشكل أول ملف nvr للدليل الأول. وهو يتوافق مع أول تسجيل فيديو بواسطة DVR. من الواضح أن قيم المعلمات ، التي دعوتها بالمفتاح ، في المثال أعلاه تشكل سلسلة من الأعداد الصحيحة ، بدءًا من الصفر وتتجه بترتيب تصاعدي. فحص ملفات nvr الأخرى ، وبالنظر إلى هذه البايتات المحددة فيها ، تم أيضًا رؤية الأعداد الصحيحة ، تصاعديًا. لكن هذا التسلسل بدأ بشكل طبيعي ليس من الصفر بعد الآن ، وفي بعض الحالات لوحظت فجوات في رقم أو رقمين في بعض الأماكن. على سبيل المثال (أرقام من الجرافة): 435 ، 436 ، 438 ، 439 ، 442 ، ... (أو بالنظام الست عشري: B3010000 ، B4010000 ، B6010000 ، B7010000 ، BA010000 ، ...).
حدث مثل هذا التسلسل مع الإغفالات على ملفات nvr المقابلة لمقاطع الفيديو التي سجلها DVR في وقت واحد من قناتين أو أكثر. هذا ، على سبيل المثال ، إذا كان التسلسل "435 ، 436 ، 438 ، 439 ، 442 ، ..." يشير إلى فيديو من قناة ، فإن القيم المفقودة (437 ، 440 ، 441) سوف تتعلق بالفيديو من قناة أخرى ، والتي تم تنفيذها في نفس نقطة في الوقت المناسب. أنا نفسي مقتنع بهذا من خلال عرض ومقارنة ملفات nvr المقابلة ، بناءً على أسمائهم. ليس هناك شك في أن الأرقام المذكورة أعلاه تشكل أرقام بعض الأجزاء المتعلقة بمقاطع الفيديو. يبقى فقط لكشف العلاقة بين هذه الأرقام وإحداثيات مساحة القرص التي توجد عليها البيانات.
أيضا ، كان لمعرفة بالضبط ما هي البيانات التي يتم تقسيمها إلى الأجزاء المرقمة أعلاه؟ الافتراض الأول - البيانات هي تدفقات الصوت والفيديو ، والتي يتم تمثيلها في الحاوية 264 بواسطة كتل قصيرة ، وكما قيل ، فإن كتل دفق الفيديو لها أحجام مختلفة. في الوقت نفسه ، يجمع DVR هذه التدفقات ويجمعها في حاوية 264 في مرحلة استخراج تسجيلات الفيديو إلى وسائط خارجية. والافتراض الثاني هو أن DVR يحزم تدفقات الصوت والفيديو في حاوية 264 في البداية وأثناء التقاط الفيديو. وفي الوقت نفسه ، تم كتابة بيانات ملف .264 التي تم إنشاؤها بالفعل إلى محرك الأقراص الثابتة ، والتي كانت ستنتهي نتيجة لاستخراجها إلى وسيط خارجي. استكشاف مساحة القرص الصلب في مكان ما في منتصف القسم الثاني ، إلى جانب وحدات بايت من تدفقات الصوت والفيديو ورؤوسها من نفس النوع الموجود في الحاوية 264 ، جئت أيضًا عبر رؤوس الحاوية نفسها: MDVR96NT_2_R. بعد هذا العنوان ، كان هناك أيضًا العديد من وحدات البايت من الأصفار. بشكل عام ، أظهرت الدراسة أن هناك خيارًا ثانيًا للاثنين أعلاه. لذلك ، للحصول على ملف .264 المطلوب ، على الأرجح ، تحتاج فقط إلى ربط جميع الأجزاء التي تحتوي أرقامها في ملف nvr المقابل.
لنبدأ البحث عن العلاقة بين رقم المقطع والإحداثيات على محرك الأقراص الثابتة.
بداية بيانات الحاوية 264 المقابلة لأول تسجيل فيديو (حيث يبدأ ترقيم الأجزاء من الصفر) باستخدام أدوات البحث التي وجدتها في القطاع 16046629 (29824 قطاعًا من بداية القسم). يمكننا أن نفترض ما يسمى بالمعلمة التحيز الأولي ، الذي سيشارك في الصيغة التي تصف الاعتماد المطلوب.
لنأخذ ملفين nvr مطابقين لمقاطع الفيديو من قنوات مختلفة التقطها DVR في نفس الوقت. للقيام بذلك ، ألق نظرة على أسماء الملفات. على سبيل المثال ، تم تسجيل مقاطع الفيديو التي يشير إليها الملفان "ch00000000000001-150330-160937-161035-02p101000000.nvr" و "ch00000000000004-150330-160000-163000-00p004000000.nvr" في وقت واحد. الرقم القياسي الأول هو التسجيل من القناة الأولى من الساعة 16:09:37 إلى الساعة 16:10:35. الرقم القياسي الثاني هو رقم قياسي من القناة الرابعة من الساعة 16:00:00 إلى 16:30:00 بتوقيت. تم إدخال كلا الإدخالين في 30 مارس 2015. على الخط الزمني ، من الواضح أن الفاصل الزمني للسجل الأول هو مجموعة فرعية من الفاصل الزمني للسجل الثاني. آخذ أيضًا في الاعتبار حقيقة أنه في فترة زمنية أقصر (عند تقاطع فترتين) ، لم يقم DVR بإجراء التقاط الفيديو من أي من القنوات الست الأخرى. تصفح محتويات ملفات nvr. سوف نتأكد من أن الأرقام المفقودة (أرقام القطع) في الملف الطويل الثاني موجودة بالضرورة في الملف القصير الأول ، بشكل كامل وتام. باستخدام DVR بالطريقة المعتادة ، تحتاج إلى استخراج واحد على الأقل من ملفات .264 التي تمت الإشارة إليها بواسطة ملفات nvr التي تم التحقيق فيها مقدمًا. لنفترض أنه تم استخراج "ch00000000000001-150330-160937-161035-02p101000000.264". افتحه في المحرر الثنائي. كما ذكرنا سابقًا ، في بداية هذا الملف ، قبل الكلمة الأساسية "MDVR96NT_2_R" ، توجد وحدات بايت فريدة تتوافق مع تاريخ ووقت تسجيل الفيديو الوارد في هذا الملف. نقوم بشطب كل هذه وحدات البايت ، بدءًا من غير الصفر وانتهاءً بالرأس (كلما كانت سلسلة البايت الفريدة الخاصة بتسجيل الفيديو هذا أقصر ، كان ذلك أفضل). أيضًا ، اكتب إزاحة سلسلة البايتات هذه من بداية الملف. وتجدر الإشارة إلى أنه في بداية ملف .264 المستخرج هناك 4 بايت إضافية من الأصفار. أصبح هذا ملحوظًا بمقارنة أول 512 بايت من ملف .264 وقطاع مساحة القرص التي تبدأ منها محتويات أحد ملفات .264 (يبدأ دائمًا أي ملف من أي نظام ملفات تقريبًا في بداية القطاع ، علاوة على ذلك ، كتلة). بمعنى ، يتم نقل المعلومات الموجودة في ملف .264 مسبقًا بمقدار 4 بايت إلى اليمين. الحجم (بالبايت) لأي ملف .264 هو مضاعف 512 فقط بعد طرح الرقم 4 من الحجم أولاً. لنبدأ البحث عن القطاع الذي يبدأ منه ملف .264 الذي تم التحقيق فيه. ابدأ في وظيفة البحث في محرر القرص. في حقل القيمة المطلوبة ، أدخل سلسلة فريدة من وحدات البايت المشطوبة مسبقًا. لتسريع البحث ، أدخل قيمة الإزاحة في حقل "البحث بالإزاحة" ، وطرح سابقًا 4. ابدأ البحث. بعد ساعات قليلة ، نجح البحث. نكتب رقم القطاع الذي يوجد فيه العنوان الفريد. فليكن هذا هو قيمة s. نحن ننظر إلى محتويات ملف nvr لهذا الفيديو. نقوم بشطب رقم الجزء الأول (4 بايت عند الإزاحة 40). فليكن هذا هو قيمة ب. في المجموع ، في حين أننا نعرف رقم قطاع القرص (16046629) لرقم المقطع الصفري (في أول تسجيل فيديو) وعدد القطاع الموجود للأقراص لرقم المقطع b الذي تم شطبه للتو. يمكنك حساب حجم المقطع المقدر: (s-16046629) / (b-0). بعد الحساب ، حصلت على القيمة 128. وبالتالي ، فإن حجم المقطع يساوي 128 قطاع قرص (LBA) ، أو 128 * 512 = 65536 بايت!
أجريت تجربة أخرى مثيرة للاهتمام أخيرًا لتبديد جميع الشكوك. موصوف أدناه.
من بداية القطاعات ، نختار منطقة على القرص بحجم مشابه لحجم ملف .264 الذي يبدأ بهذا القطاع. إذا كانت تخميناتي صحيحة ، فستقع أجزاء من ملف .264 آخر ، الذي تم التقاطه على محرك الأقراص الثابتة في وقت واحد مع الملف الأول ، في المنطقة المحددة. احفظ هذه المنطقة في ملف (إنشاء صورة). قص الصورة الناتجة إلى ملفات بحجم 65.536 بايت (حجم المقطع). يمكن القيام بذلك باستخدام وظيفة "تقسيم الملف" في Total Commander. فليكن القطع M1 ، M2 ، M3 ، .... وبالمثل ، قطعنا ملف .264 المدروس (الذي تم استخراجه بطريقة سهلة الاستخدام من DVR) ، ولكن أولاً إزالة 4 بايت من الأصفار أولاً. فليكن القطع K1 ، K2 ، K3 ، .... باستخدام وظيفة "مقارنة بالمحتوى" في Total Commander ، نقارن بدورنا بين أجزاء الصورة والقطع من ملف .264. (M1 مع K1 ، M2 مع K2 ، وما إلى ذلك) ، مسترشدة بأرقام المقطع من ملف nvr المقابل. والنتيجة هي ما يلي.
لنفترض (أرقام من الجرافة) ، فإن سلسلة الأرقام في nvr هي كما يلي: 435 ، 436 ، 438 ، 439 ، 442 ، ... في هذه الحالة ، M1 = K1 ، M2 = K2 ، M4 = K3 ، M5 = K4 ، M8 = K5 ، .... أي أن الأجزاء التي تم تقسيم ملف الصورة إليها وتبين أن الملف .264 يساوي بعضها البعض ، مع مراعاة التقدم المقابل في عدد أجزاء ملف الصورة ، وفقًا للإغفالات في التسلسل. ها هي!في المجموع ، حصلنا على الاعتماد المقدر: S = 16046629 + 128 * d ، حيث d هو رقم المقطع في ملف nvr ، و S هو رقم القطاع على القرص الصلب ، بدءًا من بداية القرص الذي تبدأ منه محتويات المقطع. حجم القطاع - 128 قطاعات. لا تأخذ الصيغة المذكورة أعلاه بعين الاعتبار وجود القسم الثاني. تم العثور على التبعية فقط لمثال محدد من HDD إلى 1TB. ربما إذا وضعت سعة مختلفة في DVR HDD ، فستلقي الثوابت نظرة مختلفة.للتحقق من صحة الصيغة ، نقوم بحساب موضع الجزء الأول من ملف .264 التعسفي الآخر ، مسترشداً بملف nvr المقابل. مع الانتباه إلى التاريخ والوقت في اسم الملف ، قارنهم بالبايت الأول في رأس .264 الموجود على القطاع المحسوب. تتوافق وحدات البايت المشفرة بشكل فردي مع الرقم والشهر والسنة والساعات والدقائق والثواني مع البيانات المؤقتة في اسم الملف. لذلك ، "ضرب المسمار"! نحسب في ملف nvr المقابل لملف .264 المستخرج مقدمًا ، عدد مقاطع cs. بشكل عام ، يكون عددهم cs = sf / 32-1 ، حيث sf هو حجم ملف nvr. إذا كان الملف .264 يتكون من مقاطع cs ، فيجب أن يكون حجمه مساوياً لـ cs * 65536 + 4 (عدد الأجزاء ضرب حجم المقطع بالبايت ، بالإضافة إلى 4 من نفس وحدات البايت من الأصفار). وهو كذلك حقًا!ومع ذلك ، حاول استكشاف القسم الثاني. كما أشرنا سابقًا ، يوجد شيء مشابه للكتلة الفائقة مباشرة في القطاع الأول من القسم (16016805). وتم اكتشاف نسخته الدقيقة من قبل سبعة قطاعات أدناه (16016812). من الواضح أن المعلومات الأساسية غير الصفرية موجودة في القطاع الأول من الكتلة الفائقة. يظهر الشكل في محرر القرص في الشكل أدناه.
تمكنت من فك تشفير جزء من معلمات 4 بايت. يتم تمييز تاريخ ووقت تركيب القسم باللون الأزرق. يتم عرض التاريخ والوقت في ترميز خاص "وقت يونكس" (عدد الثواني المنقضية منذ منتصف ليل 1 يناير 1970). في المثال أعلاه ، يتوافق "03 7E 74 54" (القيمة العشرية 1416920579) مع "Tue، 25 Nov 2014 13:02:59 GMT". لترجمة القيم ، استخدمت آلة حاسبة خاصة عبر الإنترنت. القيمة 65536 محاطة بدائرة في الإطار البنفسجي. من الممكن أن يشير مترجم نظام الملفات داخل برنامج DVR إلى هذا الموضع من الكتلة الفائقة عند قراءة حجم الكتلة (في السياق السابق ، دعوت مقاطع القطع). يتم تمييز القيم 1. في الإطار الأخضر. من المحتمل أن تشير إحداها إلى موضع بداية ما يسمى. الصورة النقطية (في عدد الكتل من بداية القسم). في الواقعمقدما ، تم العثور على بداية المعلومات التي تبدو وكأنها صورة نقطية على القطاع 16016933 (16016805 + 128 * 1). تم تمييز القيمة 233 في إطار أحمر ، وهذا هو بالضبط موضع بداية تسجيلات الفيديو .264 هذه من بداية القسم: 16016805 + 128 * 233 = 16046629.أي أن القسم الثاني يمكن أن يطلق عليه قسم مقطوع ومعدل قليلاً من EXT2. يحتوي على superblock ، نسخة منه ، صورة نقطية. ولكن لا يوجد ما يسمى ب. عقد المعلومات المقابلة لسجلات الملف. يحتوي القسم على بيانات ملفات .264 (دفق الصوت والفيديو) ، ولكن عُقد المعلومات (دعنا نقول ذلك) لهذه البيانات موجودة في ملفات nvr في القسم الأول. ربما هناك صياغة أكثر كفاءة؟ لكن هذا ليس مهمًا بالنسبة لي.دعنا نكتب برنامجًا بسيطًا للاستخراج الجماعي لملفات .264. يجب أن أقول على الفور أنني لا أملك الكثير من الخبرة في البرمجة على Windows. يقوم البرنامج بمسح جميع ملفات nvr التي تم نسخها مسبقًا إلى قسم 1 تيرابايت من القرص الصلب الجديد. من خلال تحليلها ، يقوم البرنامج بإنشاء ملف .264 بنفس الاسم في نفس الدليل ، وذلك باستخدام الوصول إلى قطاعات القرص الصلب الأصلي. في السابق ، تم إنشاء مجلد باسم "DVR" في قسم فارغ من محرك الأقراص الثابتة الجديد ، حيث يتم وضع المجلدات حسب التواريخ ، والتي يتم نسخها "بالطريقة المعتادة" في Linux. كان من الممكن تضمين هذا البرنامج خوارزمية للعمل مع قسم Linux الأول للوصول إلى ملفات nvr حتى لا تضطر إلى نسخها مسبقًا. ويمكنك إضافة ميزات أخرى مناسبة. نعم ، كان ذلك ممكنًا ، ولكن في تلك اللحظة أردت أن أفعل كل شيء في أسرع وقت ممكن.لم أستخدم العودية لمسح الدلائل ، نظرًا لأن تنسيق الدلائل ثابت ولديه مستويان من المرفقات. وبناءً على ذلك ، قمت بتطبيق دورتين: تشغيل من خلال المجلدات حتى تنتهي ، وتشغيل من خلال الملفات في كل مجلد بنفس الحالة. لقراءة الملفات ، استخدمت وظيفة fopen. للعمل مع قطاعات HDD ، استخدمت وظيفة WinAPI مشابهة للعمل مع الملفات. دعنا ننتقل إلى رمز البرنامج.تحتاج المكتبات مثل هذا.#include <windows.h> #include <stdio.h> #include <string.h>
وقمت بنسخ هذه الوظائف بالكامل من بعض المنتديات.
HANDLE openDevice(int device) { HANDLE handle = INVALID_HANDLE_VALUE; if (device <0 || device >99) return INVALID_HANDLE_VALUE; char _devicename[20]; sprintf(_devicename, "\\\\.\\PhysicalDrive%d", device);
تحتوي وظيفة النسخ على صيغة اعتماد خطي ، والتي ظهرت في النظرية أعلاه.
void copy(HANDLE device, HANDLE file, unsigned long int s){ LONG HPos; LONG LPos; __int64 sector; sector = 16046629+128*s; HPos = (sector*512)>>32; LPos = (sector*512); SetFilePointer (device, LPos, &HPos, FILE_BEGIN); DWORD dwBytesRead; DWORD dwBytesWritten; unsigned char buf[65536]; ReadFile(device, buf, 65536, &dwBytesRead, NULL); WriteFile(file, buf, dwBytesRead, &dwBytesWritten, NULL); }
الوظيفة الرئيسية بسيطة للغاية.
int main(){ HANDLE hdd = openDevice(1);
على جهاز كمبيوتر قديم مزود بمعالج Pentium 4 ووحدة تحكم PCI SATA ، نجح البرنامج في نقل قرص صلب كامل يحتوي على عدة آلاف من ملفات .264 في المتوسط لمدة 7 ساعات. على جهاز كمبيوتر جديد - أسرع ثلاث مرات. كما أشرت من قبل ، البرنامج ليس عالميًا ، يتم تعديل جميع الثوابت والمتغيرات حسب حالتي المحددة من HDD إلى 1TB. ومع ذلك ، يمكنك العمل أكثر قليلاً وجعلها عالمية ، رسم واجهة رسومية لها.
في الجزء الثاني من المقالة سأكتب كيفية "القيام بذلك بنفسك" لإعادة التعبئة من الحاوية "264" إلى الحاوية "avi" القياسية.