كلمة المرور صحيحة… لكن التشفير لا يحتاجها ؟

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

هنا يتغير السؤال من «ما مدى قوة خوارزمية التشفير؟» إلى «من أين جاء المفتاح، ومن يستطيع الوصول إليه؟». قد تستخدم البرمجية خوارزمية قوية، وتنتج بيانات مشفّرة تبدو عشوائية، وتمنع لقطات الشاشة، ومع ذلك يستطيع شخص يملك نسخة من برنامج العرض استخراج المفتاح واستعادة الملفات من دون معرفة كلمة المرور التي اختارها المستخدم.

هذا بالضبط ما ظهر في بحث نشره Xusheng Li بتاريخ 22 أكتوبر 2026 حول أربع حالات من برامج حماية وحدات التخزين. باستخدام التحليل العكسي، وتصحيح التنفيذ المسجّل، ومساعدة وكيل ذكاء اصطناعي متصل بأداة تحليل الملفات التنفيذية، كشف الباحث مسارات متعددة تنتهي بالنتيجة نفسها: وجود تشفير لا يعني بالضرورة وجود حماية مرتبطة بسرّ المستخدم.

#لا تبدأ بالخوارزمية… ابدأ بحدود الثقة

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

أما حين تصبح كلمة المرور مجرد شرط داخل الواجهة، بينما يحتفظ البرنامج بمفتاح التشفير في مكان آخر، فنحن لا نواجه مشكلة في واجهة الدخول فقط؛ بل خللًا في تصميم علاقة المصادقة بالتشفير.

تصميم مرتبط بكلمة مرور المستخدم:
User Password -> Password-based KDF -> Key/Unwrap Key -> File Decryption

تصميم يفصل كلمة المرور عن مفتاح المحتوى:
User Password -> UI Check -> Allow Viewer
Embedded Secret ------------> File Key -> File Decryption

الفرق بين المسارين هو نقطة الانطلاق المناسبة لكل حالة تالية. والمثير أن الخلل لم يظهر بالطريقة نفسها في جميع المنتجات: أحيانًا عبر حسابات داخلية بكلمات مرور ثابتة، وأحيانًا عبر مفتاح مضمّن، وأحيانًا عبر دالة تجزئة معدلة تخفي سرًا ثابتًا بدل اشتقاق المفتاح من كلمة مرور المستخدم.

#الحالة الأولى: حسابان لا تراهما الواجهة، لكنهما يفكّان الملفات

بدأ الباحث مع منتج YutianDun الذي تبيعه SecZure. يتعامل البرنامج مع الملفات المشفّرة بطريقة تجعلها مخفية عن Windows Explorer، ثم يفتحها من خلال عارض خاص يروّج لقيود على النسخ والطباعة والتقاط الشاشة. هذه القيود تصعّب النسخ المعتاد، لكنها لا تعني أن المحتوى يبقى مشفّرًا طوال الوقت؛ فالعارض لا يستطيع عرض صفحة أو مستند قبل الحصول على البايتات المفكوك تشفيرها.

في دراسة سابقة، استخدم الباحث Time-Travel Debugging (TTD)، وهي تقنية تسجّل التنفيذ لإعادة فحصه لاحقًا. أظهر التسجيل أن البرنامج يجري اعتراضًا لدوال نظام الملفات NtCreateFile وNtReadFile داخل عملية قارئ ملفات PDF، بحيث يحصل القارئ على البيانات بعد فك تشفيرها. ولهذا نجح إدخال مكتبة DLL داخل العملية نفسها في قراءة البيانات التي لم تكن عملية أخرى تستطيع الوصول إليها بالطريقة ذاتها.

هذه نتيجة مهمة، لكنها ليست الخلل الأكبر. فقد انتقل البحث من مراقبة مكان ظهور النص المفكوك إلى سؤال أكثر تحديدًا: كيف تُشتق مفاتيح الملفات؟

#تتبع المفتاح من كلمة المرور إلى بايتات الملف

بحسب التحليل المنشور، تستخدم البرمجية سلسلة شبيهة بما يلي. هذا تمثيل مبسّط للمنطق المستخرج من البرنامج، وليس تطبيقًا مكتملًا للتشغيل:

credential = MD5(b"[SECZURE]" + password).hexdigest().upper().encode("ascii")
wrap_key = HMAC_MD5(credential, credential).hexdigest().upper()[:16].encode("ascii")

identifier = AES_128_ECB_decrypt(
    wrap_key,
    hex_decode(administrator_record.wrapped_identifier)
).rstrip(b"\0")

file_key = HMAC_MD5(identifier, identifier).hexdigest().upper()[:16].encode("ascii")
plaintext = AES_128_ECB_decrypt(file_key, ciphertext)

تظهر هنا مشكلتان تستحقان التدقيق. الأولى استخدام MD5 وHMAC-MD5 ضمن اشتقاق سريع بدل آلية مخصصة لإبطاء تخمين كلمات المرور مثل PBKDF2 مع معاملات مناسبة. والثانية اقتطاع 16 خانة سداسية عشرية نصية لاستخدامها مفتاحًا بطول 16 بايت. صحيح أن الحقل يبلغ 128 بت من حيث الطول، لكن كل خانة نصية لا تحمل إلا 4 بتات من المعلومات، ولذلك لا يمكن أن تتجاوز مساحة القيم المحتملة 64 بت.

16 hexadecimal characters × 4 bits per character = 64 bits
16 ASCII bytes × 8 bits per byte                  = 128-bit field length

لكن المشكلة الحاسمة لم تكن محاولة استنفاد 2^64 احتمالًا. أثناء فحص سجل التنفيذ، لاحظ الباحث دخول حساب داخلي باسم Buffer قبل إدخال كلمة مرور المدير، مستخدمًا كلمة مرور افتراضية. لم يكن هذا الحساب ظاهرًا في شاشة إدارة المستخدمين، ومع ذلك امتلك نسخة أخرى ملفوفة من معرّف المحتوى نفسه.

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

Administrator -> password-dependent wrapped identifier ---+
Buffer        -> default password -> wrapped identifier ---+--> Content Identifier
System        -> fixed password   -> wrapped identifier ---+           |
                                                                    v
                                                              AES File Key
                                                                    |
                                                                    v
                                                                Plaintext

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

#الحالة الثانية: AES-256 على العلبة، ومفتاح ثابت داخل الملف التنفيذي

انتقل البحث إلى برنامج NetacFileLock، الذي سبق للباحث أن تتبّع آلية تشفيره باستخدام TTD. هذه المرة استعان بـCodex، وطلب منه تحليل نظام التشفير عبر Binary Ninja MCP. وخلال نحو سبع دقائق من التحليل الثابت، وصل الوكيل إلى المشكلة الأساسية: البرنامج يهيّئ AES-256 بمفتاح طوله 32 بايتًا ومضمّن في الملف التنفيذي نفسه.

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

User Password ----> Password Verification ----> Access Decision

Hardcoded 32-byte Key --------------------------> AES-256 Decryption

إذًا، وصف المنتج بأنه يستخدم AES-256 ليس كاذبًا بالضرورة؛ المشكلة أنه يجيب عن سؤال مختلف. هو يصف خوارزمية التشفير، ولا يثبت أن المفتاح سرّي، أو أنه مشتق من كلمة مرور المستخدم، أو أنه يختلف بين المستخدمين والأجهزة.

ولم يتوقف التحليل عند المفتاح المضمّن. رصد الباحث أيضًا تخزين كلمة مرور المستخدم في سجلات تشخيصية، واستخدام MD5 للتحقق من كلمة المرور، واستخدام تجزئة MD5 غير مرتبطة بمفتاح باعتبارها توقيعًا للملف، ومفتاح ثابت آخر في خيار SM4. كما ظهرت معالجة مستقلة لكتل حجمها 16 بايتًا دون متجه تهيئة أو ربط بين الكتل، وهو سلوك يشبه ECB ويكشف أنماط البيانات المتكررة بدل إخفائها كما ينبغي.

ثم ظهرت مفاجأة أخرى في نمط التشفير السريع. كان الباحث قد لاحظ سابقًا أن جزءًا من ملف الاختبار بقي غير مشفّر. كشف التحليل أن نمط Fast Mode يتعامل جزئيًا مع الملفات التي تتجاوز 1,024 بايت من صيغ متعددة، وليس مع ملفات PDF وحدها. ومن بين الصيغ المشمولة:

PNG, JPEG, GIF, TIFF, DWG, PSD, PST, DBX, Office, MDB, WPD,
PDF, ZIP, RAR, WAV, AVI, RAM, RM, MPEG, MOV, ASF, MIDI

هذا لا يعني أن كل ملف كبير يُشفّر ثلثه تحديدًا؛ نسبة الثلث كانت ملاحظة في عينة الاختبار. لكن النتيجة العامة أكثر وضوحًا: وجود وضع سريع يترك أجزاء من البيانات بلا تشفير يغيّر ضمانات السرية، بصرف النظر عن اسم الخوارزمية.

#الحالة الثالثة: حين يصبح إخفاء الملفات على exFAT بديلًا وهميًا عن الأمان

اختبر الباحث بعد ذلك KakaSoft USB Copy Protection 5.6.0.299، وهو منتج يقدّم ثلاثة مستويات للحماية. ولم تكن أسماؤها كافية للحكم على ما يحدث تحت الغطاء:

في الوضع المتوسط، لا تحتاج إلى مساحة مفاتيح ضخمة لفهم المشكلة؛ بايت واحد يعني 256 قيمة محتملة. كما أن تواقيع الملفات المعروفة تسمح باستنتاج مفتاح XOR من مقارنة بايتات البداية المتوقعة بالبايتات المشوّشة. أما بقية الملف بعد الجزء الأول، فتظل كما كانت.

ولأن المستوى الأعلى يبدو أكثر جدية، اختار الباحث Highest وحمى ملفًا نصيًا صغيرًا. عند فتح الوحدة بالطريقة المعتادة، لم يظهر سوى البرنامج المطلوب لقراءة الملفات المحمية.

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

#الملفات لم تختفِ: هي موجودة داخل شجرة أسماء غير اعتيادية

بدل الاعتماد على ما يعرضه Windows Explorer، حلّل الوكيل سجلات الدلائل الخام في نظام الملفات exFAT. ظهرت بنية مخفية تستخدم سمات hidden وsystem وأسماء مصممة لإرباك معالجة المسارات الاعتيادية:

USB root
└── HPSafeBox                             [hidden + system]
    ├── desktop.ini                       [hidden + system]
    ├── con.{d3e34b21-9d75-101a-8c3d-00aa001a1652}
    └── Important Folder
        └── Com1.{d3e34b21-9d75-101a-8c3d-00aa001a1652}
            └── \x7f\x7f\uE347..           [unusual UTF-16 name]
                ├── Info.bd
                ├── Daily.db
                └── NLLastF                 [hidden + system]
                    └── test.txt.txt       [667 bytes]

يجمع أحد المسارات بين الاسم المحجوز COM1 ولاحقة تشبه CLSID، بينما يبدأ اسم دليل آخر بمحرفَي DEL بالقيمة 0x7F ثم محرف من نطاق Unicode الخاص U+E347. هذه تفاصيل مزعجة لمعالجة المسارات الاعتيادية في ويندوز، لكنها لا تجعل البايتات غير موجودة على القرص.

من هنا انتقل التحليل من إخفاء الملفات إلى تنسيق حاوية التشفير نفسها. عند فحص الملف المشفّر، ظهرت البنية التالية:

Offset 0x000: 8-byte salt
Offset 0x008: 8-byte Blowfish-CBC IV
Offset 0x010: ciphertext
Offset 0x250: 75-byte trailer (in the 667-byte sample)

وبداية البيانات ونهايتها احتوتا على مؤشرات قابلة للقراءة ضمن التذييل:

00000000: a0 ea 96 ca 0e 03 f0 98 0b 3e ad 18 99 a7 e3 9d
00000010: 08 b2 f6 55 b7 2f 47 3c 0e 66 2b a9 1f 82 97 c8
...
00000280: 00 00 00 0e 6b 61 6b 61 65 6e 63 72 79 70 74 69
00000290: 6f 6e 08 42 6c 6f 77 46 69 73 68

Readable trailer strings: "kakaencryption", "BlowFish"

وجود salt وIV مستقلين لكل ملف يوحي بتصميم أكثر نضجًا من المفتاح الثابت المباشر. لكن السؤال الحقيقي بقي: ما السر الذي يدخل إلى اشتقاق مفتاح Blowfish؟

#MD5 معدّل لا يعني مفتاحًا أفضل

كان البرنامج مكتوبًا بلغة Delphi ويعمل ببنية 32 بت. بتتبع الصنف TBlowfishEncryption، توصّل التحليل إلى مسار اشتقاق المفتاح التالي:

Embedded Seed
     |
     v
Modified MD5
     |
     v
Fixed Internal Password ----+
                            |
Per-file Salt --------------+--> RIPEMD-128 --> Blowfish File Key

Per-file IV ------------------------------------> Blowfish-CBC

بصيغة شبه برمجية:

internal_password = modified_md5(embedded_seed)
file_key = RIPEMD_128(salt + internal_password)
plaintext = blowfish_cbc_decrypt(file_key, iv, ciphertext)

لاحظ ما لا يظهر في هذه المعادلة: كلمة المرور التي أدخلها المستخدم في الواجهة. وجود salt متغيّر لا يعالج مشكلة أن السر الأساسي مُشتق من ثابت داخل التطبيق، لأنه يمكن تكرار الحساب بعد استرداد ذلك الثابت.

بل حاولت البرمجية إخفاء طبيعة هذا الاشتقاق بتعديل خطوات MD5 نفسها. في الجولة الثالثة من التنفيذ التقليدي، تتكرر قيم التدوير بهذا الترتيب:

Standard MD5 round-three rotations:
4, 11, 16, 23, 4, 11, 16, 23

KakaSoft modified rotations:
4, 11, 16, 16, 4, 11, 11, 4

الصورة: اختلاف معاملات التدوير داخل تنفيذ MD5 المعدّل كما ظهر في التحليل العكسي.

كما بدّلت البرمجية ترتيب المحارف المستخدمة لتحويل ناتج التجزئة إلى تمثيل سداسي عشري. التنفيذ المعتاد يستخدم:

static const char hex[] = "0123456789ABCDEF";
out[i * 2]     = hex[digest[i] >> 4];
out[i * 2 + 1] = hex[digest[i] & 0x0f];

بينما استخدمت البرمجية جدولًا مختلفًا:

1903642857ACBEDF

الصورة: جدول المحارف المعدّل؛ تغيير تمثيل البايتات ليس بديلًا عن حماية مفتاح التشفير.

من المهم الفصل بين الأمرين: تغيير ترتيب محارف العرض هو استبدال رمزي، أما تعديل معاملات التدوير فيغيّر ناتج التجزئة الخام مقارنة بتنفيذ MD5 القياسي. وفي الحالتين، لا تنتج حماية حقيقية إذا كان الإدخال الحاسم ثابتًا ومتوافرًا داخل الملف التنفيذي.

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

استغرق استخراج ملفات المثبّت وفحص الخوارزمية نحو دقيقتين ثم سبع دقائق. وبعد توفير الوحدة المحمية فعليًا، احتاج الوكيل قرابة 26 دقيقة وست رسائل قصيرة إضافية لإيجاد الملف المخفي، وفهم اشتقاق المفتاح المعدّل، والتحقق من استعادة المحتوى. لم يكن مجرد تخمين من النموذج؛ بل فرضية تحولت إلى نتيجة قابلة للاختبار.

#الحالة الرابعة: كلمة المرور تتحكم في العارض… لا في البيانات

الحالة الأخيرة كانت Nexcopy Copy Secure، بإعداد جرى من خلال Drive Wizard 1.0.81. احتوت الوحدة على عارضين لنظامَي Windows وmacOS، وكان عارض ماك يحتفظ بأسماء دوال Objective-C مفيدة في تتبع المنطق البرمجي.

في واجهة Finder ظهرت برامج العرض فقط:

الصورة: واجهة وحدة Nexcopy؛ البرامج الظاهرة ليست دليلًا كافيًا على سلامة تخزين المفاتيح.

استُخدم في هذه الحالة 3DES-CBC بثلاثة مفاتيح. كانت هناك تهيئة مشفّرة تحتوي معلومات الوصول إلى المحتوى، ويمكن للعارض فكها باستخدام قيمة ثابتة بطول 32 بايتًا مضمّنة في التطبيق. وبمجرد كشف تلك التهيئة، ظهر مفتاح المحتوى ومتجه التهيئة اللازمان لاستعادة الملف.

بلغ طول ملف التهيئة المشفّر في العينة 324 بايتًا، وطول الملف المحمي 140 بايتًا. ابتدأ كلاهما بعلامة ASCII ثابتة طولها 36 بايتًا؛ وما تبقّى في ملف الاختبار كان 104 بايتات من النص المشفّر بعد الحشو. أما التهيئة فاحتوت بعد العلامة على 288 بايتًا مشفّرًا.

بعد فك ملف التهيئة، ظهرت حقول من الشكل التالي، مع اختصار قيمة المفتاح في هذا العرض:

vid=FA6E
pid="8598"
prefix="7015A1496E"
key="6CF96891..."
password="123456"
start=\Mac Viewer.app\Data

يحتوي حقل key في العينة على 24 بايتًا لمفتاح 3DES تليها 8 بايتات لمتجه التهيئة IV. أما حقل password فكان إعدادًا منفصلًا لواجهة الاستخدام، وليس مدخلًا مطلوبًا لبناء مفتاح المحتوى. حتى إن عارض ماك قارن كلمة المرور المدخلة بالنص المخزن باستخدام الدالة:

isEqualToString:

يمكن تلخيص مسار التنفيذ بهذه الصورة:

Embedded 32-byte value
         |
         v
Decrypt encrypted configuration
         |
         +----> Content Key + IV ----> 3DES-CBC ----> Plaintext
         |
         +----> UI Password ---------> String comparison
         |
         +----> USB identifiers -----> Software device check

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

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

وبحسب التقرير، استغرق تحليل هذه الحالة نحو عشر دقائق وخمس رسائل توجيهية للوكيل.

#ماذا أثبتت الحالات الأربع، وماذا لم تثبت؟

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

#كيف فحص الوكيل هذه المنتجات في دقائق؟

ليس السر في أن النموذج «عرف كلمة المرور». الأدق أنه ساعد على تقليص الوقت اللازم للوصول إلى الأجزاء المهمة من البرنامج، ثم ربطها ببعضها. في تطبيق تقليدي، قد يقضي الباحث وقتًا طويلًا في البحث عن موضع قراءة الملف، أو دالة اشتقاق المفتاح، أو مسار فك تهيئة مخفية. هنا كان بإمكان الوكيل استخدام Binary Ninja MCP لاستكشاف الملفات التنفيذية، والتنقل بين استدعاءات الدوال، وفحص الشيفرة شبه المصدرية، واختبار فرضيات محددة.

مثلًا، عندما يظهر استدعاء AES أو Blowfish، لا يكفي تسجيل اسم الخوارزمية. السؤال التالي هو: من مرّر المفتاح إلى الدالة؟ هل جاءت البايتات من إدخال المستخدم، أم من ثابت في قسم البيانات، أم من ملف تهيئة، أم من قيمة حُسبت في مرحلة سابقة؟ وبعد تحديد مصدر المفتاح، يعود الفحص إلى الوراء حتى يصل إلى الحدّ الأمني الذي يفترض أن يمنع استعادته.

وفي التحقيقات على ملفات تجريبية يملكها الباحث، تبدأ معاينة الحاوية غالبًا بخطوات بسيطة لتحديد نوع الملف، والبحث عن علامات تنسيق، ومراجعة البايتات الخام قبل تفسيرها:

# Linux: inspect a local test sample
file protected_sample.bin
xxd -g 1 -l 128 protected_sample.bin
strings -a protected_sample.bin | grep -Ei 'blowfish|encrypt|password|key'

# Windows PowerShell: inspect a local test sample
Format-Hex -Path .\protected_sample.bin | Select-Object -First 12

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

وما يجعل Time-Travel Debugging مفيدًا هنا هو قدرته على الإجابة عن سؤال مكمل للتحليل الثابت: من أين جاءت هذه البايتات أثناء التنفيذ الفعلي؟. يمكن تتبع البيانات المفكوكة عند وصولها إلى قارئ المستندات، أو العودة إلى اللحظة التي جرى فيها تحميل المفتاح، بدل محاولة استنتاج كل شيء من الشيفرة وحدها. الجمع بين المسارين أكثر موثوقية من الاكتفاء بإجابة نموذج لغوي عن ملف تنفيذي لم يُختبر.

#المشكلة ليست في عدد البتات المكتوب على العلبة

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

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

الجزء اللافت في بحث Xusheng Li ليس فقط عدد الثغرات، بل سرعة الانتقال من ادعاء تسويقي إلى فرضية دقيقة ثم إلى إثبات عملي. الذكاء الاصطناعي لم يجعل قواعد التشفير مختلفة، ولم يُغنِ عن التحقق. لكنه اختصر مسافة طويلة بين رؤية AES-256 داخل البرنامج وبين اكتشاف أن المفتاح الذي يفك الملفات لم يكن سرًا للمستخدم من الأساس.

وفي النهاية، لا يهم أن يكون الملف «مخفيًا» أو «مقفولًا» أو «مشفّرًا بأعلى إعداد» إذا كان البرنامج الذي يحميه يحمل، في داخله، كل ما يلزم لفتحه.

المصدر الأساسي للبحث والصور: Xusheng Li — Discovering a Backdoor and Flaws in More Encrypted USB Drives, Binary Ninja, 22 October 2026.

عرض سابق لمنهجية التحليل: Breaking Encrypted USB Drives with Time-Travel Debugging — RE//verse 2026.