تحية للجميع.سنتحدث اليوم ، فيكتور أنتيبوف وإيليا أليشين ، عن تجربتنا مع أجهزة USB من خلال Python PyUSB وقليلاً عن الهندسة العكسية.
خلفية
في عام 2019 ، دخل مرسوم حكومة الاتحاد الروسي رقم 224 "بشأن الموافقة على قواعد وسم منتجات التبغ عن طريق تحديد الهوية وتفاصيل إدخال نظام معلومات الدولة لرصد تداول السلع الخاضعة للتوسيم الإلزامي عن طريق تحديد الهوية فيما يتعلق بمنتجات التبغ".توضح الوثيقة أنه اعتبارًا من 1 يوليو 2019 ، يطلب من الشركات المصنعة تسمية كل عبوة من التبغ. ويجب أن يستلم الموزعون المباشرون هذه المنتجات بتصميم مستند تحويل عالمي (UPD). تحتاج المتاجر ، بدورها ، إلى تسجيل بيع المنتجات المعنونة من خلال السجل النقدي.أيضًا ، اعتبارًا من 1 يوليو 2020 ، يتم حظر منتجات التبغ غير المميزة. هذا يعني أن جميع علب السجائر يجب أن تحمل رمز باركود Datamatrix خاص. و - نقطة مهمة - اتضح أن Datamatrix لن يكون عاديًا ، ولكنه معكوس. هذا ليس رمزًا أسود على أبيض ، بل العكس.لقد اختبرنا الماسحات الضوئية لدينا ، واتضح أن معظمها بحاجة إلى إعادة تحميلها / إعادة تدريبها ، وإلا فهي ببساطة غير قادرة على العمل بشكل طبيعي مع هذا الرمز الشريطي. لقد ضمن لنا هذا التحول في الأحداث صداعًا شديدًا ، لأن شركتنا لديها الكثير من المتاجر المنتشرة في مناطق شاسعة. عشرات الآلاف من المكاتب النقدية - ووقت قليل للغاية.ما الذي ينبغي القيام به؟ هناك خياران. أولاً: يقوم المهندسون في المنشأة بإعادة تحميل وتعديل الماسحات الضوئية يدويًا. ثانيًا: نعمل عن بُعد ، ويفضل أن نغطي العديد من الماسحات الضوئية مرة واحدة في تكرار واحد.من الواضح أن الخيار الأول لم يناسبنا: كان علينا أن ننفق الأموال على الرحلات الميدانية للمهندسين ، ومن الصعب التحكم في العملية وتنسيقها في هذه الحالة. لكن الشيء الأكثر أهمية هو أن الناس سيعملون ، أي أنه من المحتمل أن نرتكب الكثير من الأخطاء ، وعلى الأرجح ، لن يتناسب مع الموعد النهائي.الخيار الثاني جيد للجميع ، إن لم يكن لواحد ولكن. لم يكن لدى بعض البائعين أدوات التفليش عن بُعد التي نحتاجها لجميع أنظمة التشغيل المطلوبة. وبما أن المواعيد النهائية كانت ضيقة ، كان علي أن أفكر برأسي.بعد ذلك ، سنصف كيف طورنا أدوات للماسحات الضوئية المحمولة لنظام التشغيل Debian 9.x OS (لدينا كل شباك دبيان).:
يقول فيكتور أنتيبوف.تعمل الأداة المساعدة الرسمية التي يوفرها البائع تحت Windows ، وفقط مع IE. يمكن وميض الأداة وتكوين الماسح الضوئي.نظرًا لأن النظام المستهدف هو Debian ، فقد قمنا بتثبيت خادم إعادة توجيه USB على خادم Debian وعميل إعادة توجيه usb على Windows. باستخدام أدوات إعادة توجيه USB ، تمت إعادة توجيه الماسح الضوئي من جهاز Linux إلى جهاز Windows.رأيت الأداة المساعدة من بائع Windows الماسح الضوئي وحتى تومض بشكل طبيعي. وبالتالي ، تم التوصل إلى الاستنتاج الأول: لا شيء يعتمد على نظام التشغيل ، الأمر موجود في بروتوكول الوميض.حسنا. تم إطلاق وميض على جهاز Windows ، وتمت إزالة ملف تفريغ على جهاز Linux.لقد حشووا التفريغ في WireShark و ... كانوا حزينين (سأحذف جزءًا من تفاصيل التفريغ ، لا يهمهم).ما أظهر لنا التفريغ:
العناوين 0000-0030 ، استنادًا إلى Wireshark ، هي معلومات خدمة USB.كنا مهتمين بالجزء 0040-0070.لم يكن هناك شيء واضح من إطار إرسال واحد ، باستثناء أحرف MOCFT. تحولت هذه الرموز إلى رموز من ملف البرنامج الثابت ، بالإضافة إلى بقية الرموز حتى نهاية الإطار (تم تمييز ملف البرنامج الثابت):
ما الذي تعنيه الرموز fd 3e 02 01 fe ، أنا شخصياً ، مثل إيليا ، لم يكن لدي أي فكرة.نظرت إلى الإطار التالي (تم حذف معلومات الخدمة هنا ، وتم تمييز ملف البرنامج الثابت):
ما الذي أصبح واضحًا؟ أن البايتين الأولين نوع من الثابت. أكدت جميع الفدرات اللاحقة ذلك ، ولكن قبل نهاية فدرة الإرسال:
دخل هذا الإطار أيضًا في ذهول ، حيث تغير الثابت (المظلل) ، والغريب أنه كان هناك جزء من الملف. يشير حجم البايتات المرسلة للملف إلى أنه تم نقل 1024 بايت. ماذا تعني البايت المتبقية - لم أكن أعرف مرة أخرى.أولا وقبل كل شيء ، مثل لقب BBS قديم ، قمت بمراجعة بروتوكولات النقل القياسية. 1024 بايت ، لم يمر أي بروتوكول. بدأ في دراسة العتاد وتعثر على بروتوكول Xmodem 1K. سمح بإرسال 1024 ، ولكن مع فارق بسيط: في البداية 128 فقط ، وفي حالة عدم وجود أخطاء فقط زاد البروتوكول عدد البايتات المرسلة. كان لي على الفور إرسال 1024 بايت. قررت دراسة بروتوكولات الإرسال ، وتحديدًا X-modem.كان هناك نوعان مختلفان من المودم.أولاً ، تنسيق حزمة XMODEM مع دعم CRC8 (XMODEM الأصلي):
ثانيًا ، تنسيق حزمة XMODEM مع دعم CRC16 (XmodemCRC):
يبدو متشابهًا ، باستثناء SOH ورقم الحزمة و CRC وطول الحزمة.نظرت إلى بداية كتلة الإرسال الثانية (ورأيت مرة أخرى ملف البرنامج الثابت ، ولكن بمسافة بادئة تبلغ 1024 بايت):
رأيت الرأس المألوف fd 3e 02 ، لكن البايتين التاليين تغيروا بالفعل: كان 01 fe ، وأصبح 02 fd. ثم لاحظت أن الكتلة الثانية مرقمة الآن 02 وبالتالي فهي مفهومة: أمامي هو ترقيم كتلة الإرسال. أول انتقال 1024 هو 01 ، والثاني 02 ، والثالث 03 وما إلى ذلك (ولكن في عرافة بالطبع). ولكن ماذا يعني التغيير من fe إلى fd؟ ذكر الدماغ انخفاضا بمقدار 1 ، وذكر الدماغ أن المبرمجين يحسبون من 0 ، وليس من 1. ولكن بعد ذلك لماذا الكتلة الأولى 1 ، وليس 0؟ لم أجد الجواب على هذا السؤال. لكنني فهمت كيف يتم اعتبار الكتلة الثانية. الكتلة الثانية ليست أكثر من FF - (ناقص) رقم الكتلة الأولى. وهكذا ، تم تعيين الكتلة الثانية على أنها = 02 (FF-02) = 02 FD. وأكدت القراءة اللاحقة للتفريغ حدسي.ثم بدأت تظهر الصورة التالية للبرنامج:بداية البرنامجfd 3e 02 - بدء01 FE - عداد إرسالالإرسال (34 كتلة ، يتم إرسال 1024 بايت)fd 3e 1024 بايت من البيانات (مقسمة إلى كتل من 30 بايت).نهاية الإرسالfd 25بقايا البيانات لمحاذاة 1024 بايت.كيف يبدو الإطار النهائي لنقل الكتلة:
fd 25 - إشارة إلى نهاية نقل الكتلة. 2f 52 التالي - بقايا الملف حتى 1024 بايت. 2f 52 ، بناءً على البروتوكول ، هو المجموع الاختباري لـ CRC 16 بت.استنادًا إلى الذاكرة القديمة ، قمت بعمل برنامج في لغة C قام بسحب 1024 بايت من ملف وقراءة CRC 16 بت. أظهر إطلاق البرنامج أن هذا ليس CRC 16 بت. ذهول مرة أخرى - لمدة ثلاثة أيام تقريبًا. طوال هذا الوقت حاولت أن أفهم ما يمكن أن يكون إذا لم يكن المجموع الاختباري. أثناء دراسة مواقع باللغة الإنجليزية ، وجدت أن المودم X يستخدم حساب المجموع الاختباري الخاص به - CRC-CCITT (XModem). لم أجد أي تطبيقات في C لهذه العملية الحسابية ، لكني وجدت موقعًا يقرأ هذا المجموع الاختباري عبر الإنترنت. من خلال تحميل 1024 بايت من ملفي إلى صفحة الويب ، أظهر لي الموقع مجموعة اختبارية تزامنت تمامًا مع المجموع الاختباري من الملف.مرحى! تم حل اللغز الأخير ، والآن كان عليك إنشاء البرامج الثابتة الخاصة بك. ثم نقلت معرفتي (وظلوا في رأسي فقط) إلى إيليا ، المألوفة بالأدوات القوية - Python.إنشاء البرنامج
رواه إيليا العشين.بعد أن تلقيت التعليمات المناسبة ، كنت سعيدًا جدًا.من أين نبدأ؟ صحيح منذ البداية من التفريغ من منفذ USB.قم بتشغيل USB-pcap https://desowin.org/usbpcap/tour.htmlحدد المنفذ الذي يتصل به الجهاز والملف الذي سنحفظ فيه التفريغ.
نقوم بتوصيل الماسح الضوئي بالجهاز حيث تم تثبيت برنامج EZConfigScanning الأصلي لنظام التشغيل Windows.
نجد فيه نقطة إرسال الأوامر إلى الجهاز. ولكن ماذا عن الفرق؟ من أين تحصل عليهم؟عندما يبدأ البرنامج ، يتم استجواب المعدات تلقائيًا (سنرى ذلك لاحقًا قليلاً). وكان هناك الباركود التدريب من وثائق المعدات الرسمية. DEFALT. هذا هو فريقنا.
يتم تلقي البيانات اللازمة. افتح ملف التفريغ من خلال wireshark.حظر عند بدء تشغيل EZConfigScanning. النقاط الحمراء هي أماكن يجب الانتباه إليها.
عندما رأيت كل هذا لأول مرة ، فقدت القلب. مكان الحفر أكثر غير واضح.قليلا من العصف الذهني و- و- و ... آها! في مكب، من هو في و في غير خارج .Googled ما هو URB_INTERRUPT. اكتشفت أن هذه طريقة نقل البيانات. وهناك 4 طرق من هذا القبيل: التحكم ، المقاطعة ، المتزامنة ، السائبة. يمكنك أن تقرأ عنها بشكل منفصل.ويمكن الحصول على عناوين نقاط النهاية في واجهة جهاز USB إما من خلال الأمر "lsusb –v" أو عن طريق pyusb.تحتاج الآن إلى العثور على جميع الأجهزة باستخدام VID هذا. يمكنك البحث بشكل خاص عن طريق VID: PID.
تبدو هكذا:
لذا ، لدينا المعلومات الضرورية: أوامر P_INFO. أو DEFALT ، عناوين كتابة نقطة نهاية الأوامر = 03 وأين يمكن الحصول على نقطة نهاية الإجابة = 86. يبقى فقط لترجمة الأوامر في سداسي عشري.
نظرًا لأننا وجدنا الجهاز بالفعل ، افصله عن kernel ......
واكتب إلى نقطة النهاية بالعنوان 0x03 ،
... ثم اقرأ الرد من نقطة النهاية بالعنوان 0x86.
إجابة منظمة:P_INFOfmt: 1
mode: app
app-present: 1
boot-present: 1
hw-sn: 18072B44CA
hw-rev: 0x20
cbl: 4
app-sw-rev: CP000116BBA
boot-sw-rev: CP000014BAD
flash: 3
app-m_name: Voyager 1450g
boot-m_name: Voyager 1450g
app-p_name: 1450g
boot-p_name: 1450g
boot-time: 16:56:02
boot-date: Oct 16 2014
app-time: 08:49:30
app-date: Mar 25 2019
app-compat: 289
boot-compat: 288
csum: 0x6986
نرى هذه البيانات في dump.pcap.
غرامة! نترجم الباركود النظام إلى سداسي عشري. كل شيء ، وظيفة التدريب جاهزة.ماذا تفعل مع البرامج الثابتة؟ يبدو أن كل شيء هو نفسه ، ولكن هناك فارق بسيط.بعد إزالة تفريغ كامل لعملية التفليش ، فهمنا تقريبًا ما كنا نتعامل معه. هنا مقال عن XMODEM ساعد حقا على فهم كيفية حدوث هذا الاتصال ، وإن كان بعبارات عامة: http://microsin.net/adminstuff/others/xmodem-protocol-overview.html أوصي بقراءته.بالنظر إلى التفريغ ، يمكنك أن ترى أن حجم الإطار هو 1024 ، وأن حجم بيانات URB هو 64.
لذلك ، 1024/64 ، نحصل على 16 سطرًا في كتلة ، ونقرأ ملف البرنامج الثابت بحرف واحد ونشكل كتلة. استكمال سطر واحد في كتلة بأحرف خاصة fd3e02 + رقم كتلة.يتم استكمال الأسطر الـ 14 التالية بـ fd25 + ، باستخدام XMODEM.calc_crc () نحسب المجموع الاختباري للكتلة بالكامل (استغرق الأمر وقتًا طويلاً لفهم أن "FF - 1" هو CSUM) والخط السادس عشر الأخير مكمل بـ fd3e.يبدو أن كل شيء ، اقرأ ملف البرنامج الثابت ، وضرب الكتل ، وافصل الماسح الضوئي من النواة وأرسله إلى الجهاز. ولكن ليس بهذه البساطة. يجب وضع الماسح في وضع البرامج الثابتةبإرساله NEWAPP = '\\ xfd \\ x0a \\ x16 \\ x4e \\ x2c \\ x4e \\ x45 \\ x57 \\ x41 \\ x50 \\ x50 \\ x0d'.من أين يأتي هذا الأمر ؟؟ من التفريغ.
ولكن لا يمكننا إرسال الكتلة بالكامل إلى الماسح الضوئي بسبب تقييد 64:
حسنًا ، الماسح الضوئي في وضع وميض NEWAPP لا يقبل السداسي أيضًا. لذلك من الضروري ترجمة كل سطر bytes_array[253, 10, 22, 78, 44, 78, 69, 87, 65, 80, 80, 13, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
وأرسل هذه البيانات بالفعل إلى الماسح الضوئي.نحصل على الجواب:[2, 1, 0, 0, 0, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
إذا تحققت من المقالة حول XMODEM ، يصبح من الواضح: تم قبول البيانات.
بعد نقل جميع الكتل ، نكمل النقل END_TRANSFER = '\ xfd \ x01 \ x04'.حسنًا ، نظرًا لأن هذه الكتل لا تحمل أي معلومات للأشخاص العاديين ، فسنجعل البرنامج الثابت في الوضع المخفي بشكل افتراضي. وفقط في حالة ، من خلال tqdm سننظم شريط التقدم.
في الواقع ، الباقي صغير. يبقى فقط لف الحل في البرامج النصية للنسخ المتماثل الجماعي في وقت محدد بوضوح ، حتى لا تبطئ عملية العمل في شباك التذاكر ، وإضافة التسجيل.مجموع
بعد قضاء الكثير من الوقت والطاقة والشعر على الرأس ، تمكنا من تطوير الحلول التي نحتاجها ، علاوة على ذلك ، التقينا بالموعد النهائي. في نفس الوقت ، يتم إعادة تفحص أجهزة المسح الضوئي وإعادة تدريبها الآن بشكل مركزي ، ونتحكم بشكل واضح في العملية بأكملها. وفرت الشركة الوقت والمال ، واكتسبنا خبرة لا تقدر بثمن في الهندسة العكسية لهذا النوع من المعدات.