لطالما كنت مهتمًا بموضوع ترخيص وحدات التحكم في الوسائط في بوابة Stalker ، ولكن لم يكن ذلك من قبل. في أحد الأيام حصلت بطريق الخطأ على بادئة Infomir MAG250 وقررت معالجة هذه المشكلة.تدريب
بادئ ذي بدء ، قمت بتفكيك البادئة ، ملحومة الكبل بالموصل وتوصيله بالكمبيوتر. بعد إطلاق البرنامج النهائي ، سررت مع U-Boot المألوف. يمكن أيضًا مقاطعة عملية التمهيد بالضغط على أي مفتاح (عادة ما تقوم الشركة المصنعة بتعطيل مثل هذه الرقائق ويجب عليك قضاء الكثير من الوقت لإحضار U-Boot إلى الحالة المطلوبة). كان الوصول إلى امتيازات الجذر متاحًا أيضًا عبر ssh.
تم تجهيز وحدة التحكم بذاكرة DRAM بسعة 256 ميجابايت ومحركين فلاش ، NOR 1 MB و NAND 256 MB. مع NOR ، يتم تحميل U-Boot في العملية ، والتي تقوم بتحميل kernel ونظام الملفات من NAND.دالة Getuid ()
تخول البادئة نفسها في بوابة Stalker ، وترسل مجموعة من أي معلومات ، على سبيل المثال ، النوع ، إصدار البرنامج الثابت ، إصدار الجهاز ، الرقم التسلسلي ، إلخ. ولكني كنت مهتمًا بشكل خاص بالمعلمة device_id ، التي أصدرتها الدالة gSTB.GetUID (). للوهلة الأولى ، كانت تجزئة مثل SHA256 أو MD5. بالرجوع إلى الوثائق الرسمية soft.infomir.com/stbapi/JS/v343/gSTB.html#.GetUID ، يمكن أن تستغرق الوظيفة ما يصل إلى معلمتين ، ولكن أول شيء كنت مهتمًا به كان الخيار بدون معلمات. عن طريق تحميل stbapp في IDA ، يمكننا بسهولة العثور على هذه الوظيفة.
عند الذهاب إلى أبعد من ذلك قليلاً ، نرى لحظة مثيرة للاهتمام
هنا ، يخصص البرنامج 0x41 بايت من الذاكرة ، ويلغيها ، ويستدعي وظيفة السائق / dev / stapi / stevt_ioctl ، ويمررها هذه القطعة من الذاكرة والمعلمة 0xC004C919. لذلك ، يكون برنامج تشغيل stevt_ioctl معين مسؤولاً عن إنشاء UID. للتحقق من ذلك ، قمت برسم هذا الرمز بسرعة:
عند تشغيله على وحدة التحكم ، رأيت UID مألوفًا.stevt_ioctl
الخطوة التالية هي تفكيك برنامج التشغيل stapi_ioctl_stripped.ko ، الموجود في / root / modules. نقوم بتحميل برنامج التشغيل في IDA ونعثر على المعالج 0xC004C919 ioctl (دعوت هذه الوظيفة calcHash).
هناك ثلاث نقاط مثيرة للاهتمام. أولاً ، يتم نسخ 0x41 بايت من الذاكرة من مساحة المستخدم إلى مساحة kernel (وهذا هو بالضبط ما يتم إرساله من قبل المستخدم وفي حالتنا تتكون من أصفار) ، تسمى وظيفة get_mem_type(على طول النواة نفسها) والنتيجة (مرة أخرى 0x41 بايت) يتم نسخها إلى منطقة عنوان المستخدم. للعثور على عنوان دالة get_mem_type ، رأيت احتمالين: مجرد إلقاء نظرة على ملف / proc / kallsysms ، على أمل ألا يكون الوصول مقيدًا ، أو حسنًا ، أو خلاف ذلك ، اكتب تجميعًا في مجمّع للسائق نفسه والذي سيعرض قيمة التسجيل r0 في المكان الصحيح. وقد نظرت في / إجراءات / kallsysms، كانت مفاجأة سارة لي وجدت عنوان get_mem_type 0x8080E380 وظيفة .النواة
لمزيد من التحليل ، ستحتاج إلى تحليل النواة. يمكن العثور على النواة نفسها في البرامج الثابتة للشركة المصنعة ، أو يمكنك إزالة التفريغ باستخدام U-Boot
أو تحميل القسم المطلوب.استنادًا إلى معلومات U-Boot ، يتم تحميل kernel عند 0x80800000 ونقطة الإدخال عند 0x80801000. نقوم بتحميل النواة في المؤسسة الدولية للتنمية ونجد دالة get_mem_type .بعد تحليل الشفرة ، اكتشفت هذا القسم الذي يُرجح أن يُرجع UID.
لذلك يتم تخزين UID في 0x80D635EC. بعد ذلك ، نحن نبحث في المؤسسة الدولية للتنمية ، حيث يتم تشكيل هذه القيمة. كان هذا في دالة init_board_extra (لن أترجم القائمة الكاملة)
إذن هذه هي القيمة غير المعروفة نفسها في عنوان سجل r4 الذي يتم حساب تجزئة الفائدة منه (fill_hash بالمناسبة تم حلها بواسطة SHA256). كنت متشوقًا حقًا لمعرفة ما كان عليه ، وسرعان ما كتبت مقالة في المجمع ، والتي ، من خلال وظيفة printk ، أعادت محتويات الذاكرة على عنوان التسجيل r2. بعد تعديل النواة بهذه الطريقة ، قمت بإنشاء صورة جديدة وحمّلتها على محرك أقراص USB. وفي مجموعة U-Boot الطرفية:usb start
fatload usb 0:1 80000000 uImage
bootm
ولكن بعد الفريق الأخير ، كان هذا الحزن ينتظرني
، ورفض U-Boot بأدب شحن نواة جديدة.تحرير U-Boot
لإقناع U-Boot بتشغيل نواة بلدي ، قررت تصحيحه في الذاكرة باستخدام الأمر mw نفسه . للبدء ، قمت بعمل تفريغ كامل لفلاش NOR ، الذي يقع في 0xA0000000. بعد أن دفعت التفريغ إلى المؤسسة الدولية للتنمية ، اكتشفت عنوان الذاكرة حيث نسخ U-Boot نفسه. كان 0x8FD00000. مرة أخرى ، بعد أن أفرغت هذا الجزء من الذاكرة وتشغيل IDA ، وجدت بسهولة وظيفة فحص التوقيع. إذا كان كل شيء صحيحًا ، فقد عادت 0. علاوة على ذلك ، تم استدعاؤها في مكانين مختلفين.
ما فعلته هذه الوظيفة بالضبط لم يكن مثيرا للاهتمام بالنسبة لي. كانت تحتاج فقط إلى إرجاع 0 مثل هذا:mov #0x0, r0
rts
nop
كان الرمز المقابل لـ U-Boot الآن كما يلي:usb start
mw.l 8fd0ec08 000b200a;
mw.l 8fd0ec0c 00900009
fatload usb 0:1 80000000 uImage
bootm
ثم قام U-Boot بسعادة بتحميل نواة بلدي ، والتي صدرتEF0F3A38FF7FD567012016J04501200:1a:79:23:7e:2MAG250pq8UK0DAOQD1JzpmBx1Vwdb58f9jP7SN
تحليل كامل
إذن ، مما تتكون UID؟ كان هناك عدد غير معروف من 8 بايت ، الرقم التسلسلي لوحدة التحكم ، عنوان MAC ، نوع وحدة التحكم وقطعة من القمامة. يبقى معرفة نوع الرقم غير المعروف ومن أين أتت القمامة. عدت إلى دالة init_board_extra مرة أخرى .تم أخذ رقم غير معروف من قسم الرمز هذا:
هنا ، باستخدام دالة __ioremap ، وصلت النواة إلى الذاكرة الفعلية عند 0x00000000 (التي كانت عنوان NOR للفلاش) ، وكتبت 0x0F إلى 0x00000000 ، ثم 0x98 إلى 0x000000AA وقراءة 8 بايت بدءًا من 0x000000C2. وما هو؟ هذه هي أوامر بروتوكول CFI التي تواصلت معها النواة مع NOR. جلبت 0x0F NOR إلى حالتها الأصلية ، ومع وجود أمر تبديل 0x98 تعديل CFI. في هذه الوحدة ، على العنوان 0x000000C2 هو رمز منطقة الأمان أو رقم الجهاز الفريد 64 بت. أولئك. رقم غير معروف هو رقم فلاش NOR فريد. ما يلي هو تفريغ تعريف CFI.
يمكنك عمل تفريغك مباشرة في U-Boot عن طريق الإعدادmw.w a0000000 f0
mw.w a00000aa 98
md.b a1000000 100
كانت قطعة القمامة مجرد مجموعة أحرف عادية مكونة من 32 بايت مخيطًا في النواة نفسها
، وتمت معالجة هذه القمامة قبل استخدام وظيفة التشفير swap_pairs ، والتي غيرت ببساطة موضع البايتات[0x00000003]<->[0x0000000F]
[0x00000005]<->[0x0000001F]
[0x00000009]<->[0x00000002]
[0x0000000A]<->[0x0000001D]
[0x00000010]<->[0x00000015]
[0x00000004]<->[0x00000013]
[0x0000000D]<->[0x00000018]
استنادًا إلى المعلومات الواردة ، أجرؤ على افتراض أن قاعدة بيانات الشركة المصنعة تحتوي على معلومات حول كل فلاش NOR ID والرقم التسلسلي المقابل وعنوان MAC.بالطبع ، من المستحيل تحديد كل هذا ، ولكن يمكنك كتابة برنامجك الخاص ، والذي سيحاكي وحدة التحكم بالكامل.