مهمة للمطورين، أو كيف قمنا بتحديث الماسحات الضوئية المحمولة بدون بائع

مرحبا.

سنتحدث نحن، فيكتور أنتيبوف وإيليا أليشين، اليوم عن تجربتنا في العمل مع أجهزة USB عبر Python PyUSB والقليل عن الهندسة العكسية.

قبل التاريخ

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

وأيضًا اعتبارًا من 1 يوليو 2020، يُحظر تداول منتجات التبغ غير الملصقة. وهذا يعني أنه يجب وضع علامة على جميع علب السجائر برمز شريطي خاص بـ Datamatrix. علاوة على ذلك - نقطة مهمة - اتضح أن Datamatrix لن تكون عادية، بل معكوسة. هذا ليس رمزًا أسود على أبيض، بل العكس.

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

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

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

الخيار الثاني مفيد للجميع، إن لم يكن لشيء واحد. لم يكن لدى بعض البائعين أدوات التحديث عن بعد التي نحتاجها لجميع أنظمة التشغيل المطلوبة. وبما أن المواعيد النهائية كانت تنفد، كان علي أن أفكر برأسي.

بعد ذلك، سنخبرك كيف قمنا بتطوير أدوات للماسحات الضوئية المحمولة لنظام التشغيل Debian 9.x (جميع سجلات النقد لدينا موجودة على دبيان).

حل اللغز: كيفية وميض الماسح الضوئي

تقرير فيكتور أنتيبوف.

تعمل الأداة الرسمية التي يقدمها البائع ضمن نظام التشغيل Windows، ومع IE فقط. يمكن للأداة المساعدة وميض الماسح الضوئي وتكوينه.

نظرًا لأن نظامنا المستهدف هو Debian، فقد قمنا بتثبيت خادم USB-Redirector على Debian وعميل USB-Redirector على Windows. باستخدام الأدوات المساعدة لمعيد توجيه USB، قمنا بإعادة توجيه الماسح الضوئي من جهاز Linux إلى جهاز يعمل بنظام Windows.

شاهدت أداة مساعدة من أحد بائعي Windows الماسح الضوئي وقامت بوميضه بشكل طبيعي. وهكذا توصلنا إلى الاستنتاج الأول: لا شيء يعتمد على نظام التشغيل، بل يتعلق الأمر ببروتوكول الوميض.

نعم. قمنا بتشغيل الوميض على جهاز يعمل بنظام Windows، وقمنا بإزالة التفريغ على جهاز Linux.

لقد قمنا بحشو التفريغ في WireShark وشعرنا بالحزن (سأحذف بعض تفاصيل التفريغ، فهي ليست ذات أهمية).

ما أظهره لنا المكب:

العناوين 0000-0030، وفقًا لـ Wireshark، هي معلومات خدمة USB.

كنا مهتمين بالجزء 0040-0070.

لم يكن هناك شيء واضح من إطار إرسال واحد باستثناء أحرف MOCFT. تبين أن هذه الأحرف هي أحرف من ملف البرنامج الثابت، بالإضافة إلى الأحرف المتبقية حتى نهاية الإطار (يتم تمييز ملف البرنامج الثابت):

ما تعنيه الرموز fd 3e 02 01 fe، أنا شخصياً، مثل إيليا، لم يكن لدي أي فكرة.

نظرت إلى الإطار التالي (تمت إزالة معلومات الخدمة هنا، وتم تسليط الضوء على ملف البرنامج الثابت):

ماذا أصبح واضحا؟ أن أول بايتتين هما نوع من الثبات. وأكدت جميع الكتل اللاحقة ذلك، ولكن قبل نهاية كتلة الإرسال:

كان هذا الإطار أيضًا مذهلًا، نظرًا لأن الثابت قد تغير (تم تسليط الضوء عليه)، ومن الغريب أنه كان هناك جزء من الملف. أظهر حجم البايتات المنقولة للملف أنه تم نقل 1024 بايت. لم أكن أعرف مرة أخرى ما تعنيه البايتات المتبقية.

بادئ ذي بدء، باعتباري لقبًا قديمًا لـ BBS، قمت بمراجعة بروتوكولات النقل القياسية. لا يوجد بروتوكول ينقل 1024 بايت. لقد بدأت بدراسة الأجهزة وعثرت على بروتوكول 1K Xmodem. سمح بإرسال 1024، ولكن مع تحذير: في البداية 128 فقط، وفقط في حالة عدم وجود أخطاء، زاد البروتوكول عدد البايتات المرسلة. لقد قمت على الفور بنقل 1024 بايت. قررت أن أدرس بروتوكولات النقل، وتحديداً مودم X.

كان هناك نوعان مختلفان من المودم.

أولاً، تنسيق حزمة 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. أكدت القراءة اللاحقة للتفريغ تخميني.

ثم بدأت الصورة التالية للإرسال في الظهور:

بداية الإرسال
فد 3e 02 - ابدأ
01 FE – عداد الإرسال
النقل (34 قطعة، 1024 بايت منقولة)
fd 3e 1024 بايت من البيانات (مقسمة إلى 30 بايت).
نهاية الإرسال
فد 25

يجب محاذاة البيانات المتبقية إلى 1024 بايت.

كيف يبدو الإطار النهائي لنقل الكتلة:

fd 25 – إشارة لإنهاء إرسال الكتلة. التالي 2f 52 – يصل حجم باقي الملف إلى 1024 بايت. 2f 52، وفقًا للبروتوكول، عبارة عن مجموع اختباري لـ CRC مكون من 16 بت.

من أجل الماضي، قمت بإنشاء برنامج بلغة C يسحب 1024 بايت من ملف ويحسب CRC بحجم 16 بت. أظهر إطلاق البرنامج أن هذا ليس CRC 16 بت. ذهول مرة أخرى - لمدة ثلاثة أيام تقريبًا. طوال هذا الوقت كنت أحاول أن أفهم ما يمكن أن يكون، إن لم يكن المجموع الاختباري. أثناء دراستي لمواقع اللغة الإنجليزية، اكتشفت أن مودم X يستخدم حساب المجموع الاختباري الخاص به - CRC-CCITT (XModem). لم أجد أي تطبيقات لغة C لهذا الحساب، لكنني وجدت موقعًا قام بحساب هذا المجموع الاختباري عبر الإنترنت. بعد نقل 1024 بايت من ملفي إلى صفحة الويب، أظهر لي الموقع مجموعًا اختباريًا يطابق المجموع الاختباري من الملف تمامًا.

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

إنشاء برنامج

تقارير ايليا اليشين.

وبعد أن تلقيت التعليمات المناسبة، كنت "سعيدًا" للغاية.

من أين نبدأ؟ هذا صحيح، من البداية.  من أخذ تفريغ من منفذ USB.

قم بتشغيل USB-pcap https://desowin.org/usbpcap/tour.html

حدد المنفذ الذي يتصل به الجهاز والملف الذي سنحفظ فيه التفريغ.

نقوم بتوصيل الماسح الضوئي بجهاز تم تثبيت برنامج EZConfigScanning الأصلي لنظام التشغيل Windows عليه.

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

تم استلام البيانات اللازمة. افتح dump.pcap عبر wireshark.

الحظر عند بدء تشغيل EZConfigScanning. الأماكن التي تحتاج إلى الاهتمام بها محددة باللون الأحمر.

عندما رأيت كل هذا لأول مرة، فقدت قلبي. ليس من الواضح أين يجب الحفر بعد ذلك.

القليل من العصف الذهني و-و-و... آها! في تفريغ خارج - هل inو in هذا خارج.

لقد بحثت في Google عن URB_INTERRUPT. اكتشفت أن هذه طريقة لنقل البيانات. وهناك 4 طرق من هذا القبيل: التحكم، المقاطعة، المتزامن، السائبة. يمكنك أن تقرأ عنها بشكل منفصل.

ويمكن الحصول على عناوين نقطة النهاية في واجهة جهاز USB إما من خلال الأمر "lsusb –v" أو باستخدام pyusb.

نحتاج الآن إلى العثور على جميع الأجهزة التي تحتوي على VID هذا. يمكنك البحث على وجه التحديد عن طريق VID:PID.

تبدو هكذا:

إذن، لدينا المعلومات الضرورية: أوامر P_INFO. أو DEFALT، يتناول مكان كتابة الأوامر نقطة النهاية=03 ومكان الحصول على نقطة نهاية الاستجابة=86. كل ما تبقى هو تحويل الأوامر إلى ست عشري.

وبما أننا عثرنا على الجهاز بالفعل، فلنفصله عن النواة...

...واكتب إلى نقطة النهاية بالعنوان 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 سطرًا في كتلة، ونقرأ ملف البرنامج الثابت حرفًا واحدًا في كل مرة ونشكل كتلة. استكمال سطر واحد في كتلة بأحرف خاصة fd1e1 + رقم الكتلة.
يتم استكمال الأسطر الـ 14 التالية بـ fd25 +، باستخدام XMODEM.calc_crc() نحسب المجموع الاختباري للكتلة بأكملها (لقد استغرق الأمر الكثير من الوقت لفهم أن "FF – 1" هو CSUM) ويتم استكمال السطر السادس عشر الأخير مع FD16E.

يبدو الأمر كذلك، اقرأ ملف البرنامج الثابت، واضغط على الكتل، وافصل الماسح الضوئي عن النواة وأرسله إلى الجهاز. لكن الأمر ليس بهذه البساطة. يحتاج الماسح الضوئي إلى التبديل إلى وضع البرامج الثابتة،
отправив ему 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 = 'xfdx01x04'.

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

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

مجموع

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

المصدر: www.habr.com