تقنية

بصمة ملف التنزيل: كيف تختار القيمة المرجعية قبل المطابقة؟

المقارنات الثلاث في تجربة الملفين المحليين أ وب.
نتائج حسبناها لملفات التدريب؛ لا تصف تنزيلا من ناشر.

بحر العلوم · تقنية · ملفات التنزيل

اختر القيمة المنشورة للملف المقصود والخوارزمية نفسها، ثم قارنها بالبصمة المحسوبة. توضح وثائق Microsoft هذا الفصل بين القيمة المنشورة وحساب الملف. [1]

الخلاصة السريعة

  • طابق الملف والإصدار والخوارزمية قبل مقارنة القيم. [1]
  • وثق أصل قائمة البصمات وفق طريقة الناشر. [2]
  • في تجربتنا، اختيار سطر مختلف غيّر نتيجة المقارنة.
  • سجل ما تحقق فعلا، ولا تنسب للتجربة فحصا لم تنفذه.

ابدأ بسطر المرجع الصحيح

في إرشادات Ubuntu، تُوثق هوية مفتاح التوقيع، ثم يُتحقق من توقيع قائمة SHA256SUMS، وبعد ذلك تُقارن بصمة الصورة بالقائمة. هذه مراحل مختلفة؛ وجود سلسلة محارف بجوار رابط لا ينفذها تلقائيا. [2]

خصص خانتين: الملف وإصداره وخوارزميته؛ ثم مصدر القيمة وإجراء التحقق المنفذ فعلا.

سلسلة توثيق المفتاح وتوقيع القائمة ثم مقارنة الملف.
خطوات التحقق في دليل Ubuntu؛ لم تنفذها تجربة الملفات المحلية. [2]

تجربة محلية: ثلاثة ملفات وسطران

أنشأنا لهذه المقالة ملفين نصيين صغيرين ونسخة مطابقة للأول باسم آخر. لا تمثل الملفات حزم برامج منشورة؛ بياناتها مؤلفة، ولم ننزلها من الإنترنت. يحتوي الأول السطر bahr-check|edition=A|cards=12، ويستبدل الثاني A بحرف B. أضفنا في نهاية كل سطر بايت الانتقال إلى سطر جديد، واستعملنا محارف ASCII؛ حجم كل ملف 30 بايتا.

حسبنا القيم فعلا باستخدام Get-FileHash مع SHA256، ثم أكدنا النتائج بحساب مستقل في Python. هذه هي القيم الكاملة التي قارناها، دون الاكتفاء بأول أحرفها. سميت النسخة المعاد تسميتها renamed-copy.txt، وبقيت بايتاتها مطابقة للأول في الفحص المحلي.

الملفSHA256 المحسوبة
cards-a.txt153D00E9588841104F778000593691676332A0C8B0E3A51236BCDFC301E71F9E
cards-b.txtDCCE999E5B213FE07500265980CB82B62B40D3F80AA3EFB5001888625E02FD7D
renamed-copy.txt153D00E9588841104F778000593691676332A0C8B0E3A51236BCDFC301E71F9E

ثلاث مقارنات من السجل نفسه

في المقارنة الأولى، اخترنا cards-a.txt وقيمته المرجعية التي حسبناها محليا؛ ظهرت المطابقة. وفي الثانية أبقينا القيمة المرجعية الأولى، لكن قارناها بحساب cards-b.txt؛ اختلفت القيمتان. لم تتغير سلامة عملية الحساب بين المحاولتين؛ الذي تغير هو الملف المرتبط بالسطر المختار في ورقة التدريب.

في المقارنة الثالثة اخترنا الملف الثاني وقيمته هو، فظهرت المطابقة. وعند فحص renamed-copy.txt وجدنا قيمة الأول كاملة. لا يثبت هذا أن الاسم الجديد اسم إصدار منشور؛ نحن نعرف علاقة النسخ هنا لأننا أنشأناها وفحصنا بايتاتها، لا لأن التسمية أقنعتنا بذلك.

الفرق بين نتيجتي المقارنة الثانية والثالثة يوضح خطأ في اختيار المرجع داخل هذا التمرين. لا نحوله إلى قصة عن عطب تنزيل أو عبث مهاجم، لأننا لم ننفذ تنزيلا أصلا. كما أن تساوي حجمي الملفين، ثلاثين بايتا لكل منهما، لم يجعل القيمتين اللتين حسبناهما متساويتين.

احسب الملف الذي تشير إليه الورقة

يحسب الأمر التالي SHA256 لمسار تختاره؛ LiteralPath يعامل الاسم حرفيا. بدّل المسار التوضيحي بمسار ملفك. [1]

سجل المسار والنتيجة بجوار السطر المقصود في الجدول. هذا أمر للقراءة والحساب؛ لا ينفذ الملف.

Get-FileHash -LiteralPath 'D:\Example\cards-a.txt' -Algorithm SHA256

[1]

احتفظ بسجل يصف حدود النتيجة

نختم ورقة المثال بأربع خانات: الملف المختار، والسطر المرجعي، ونتيجة المقارنة، وما لم ننفذه. نملأ الأخيرة هنا بوضوح: لم ننزل حزمة، ولم نفحص توقيعا، ولم نجر فحص برمجيات ضارة. النتيجة المحفوظة تخص الملفات الصغيرة المحددة وأداة الحساب التي استعملناها، ولا تتحول إلى شهادة لبرنامج آخر.

احفظ القيم كاملة مع أسماء ملفاتها، وأعد الحساب بعد تعديل الملف.

أُعدّ هذا المقال بمساعدة الذكاء الاصطناعي وراجعته أدوات ذكاء اصطناعي. لا يُنسب إلى مراجع بشري أو خبير مستقل. منهجية المحتوى.