משימה למפתח, או איך הבזקנו סורקים ידניים ללא ספק

שלום לכולם.

אנחנו, ויקטור אנטיפוב ואיליה אלשין, היום נדבר על הניסיון שלנו בעבודה עם התקני USB דרך Python PyUSB וקצת על הנדסה לאחור.

פרהיסטוריה

בשנת 2019, צו של ממשלת הפדרציה הרוסית מס' 224 "על אישור הכללים לסימון מוצרי טבק עם אמצעי זיהוי ותכונות של יישום מערכת מידע ממלכתית לניטור מחזור הסחורות הכפופות לתיוג חובה עם אמצעי זיהוי ביחס למוצרי טבק" נכנסו לתוקף.
המסמך מסביר כי החל מ-1 ביולי 2019, היצרנים מחויבים לסמן כל חפיסת טבק. ומפיצים ישירים חייבים לקבל מוצרים אלה עם ביצוע מסמך העברה אוניברסלי (UDD). חנויות, בתורן, צריכות לרשום את מכירת המוצרים המסומנים דרך הקופה.

כמו כן, החל מ-1 ביולי 2020 אסורה תפוצה של מוצרי טבק ללא תווית. המשמעות היא שכל חפיסות הסיגריות חייבות להיות מסומנות בברקוד Datamatrix מיוחד. יתרה מכך - נקודה חשובה - התברר שה-Datamatrix לא יהיה רגיל, אלא הפוך. כלומר, לא קוד שחור על גבי לבן, אלא להיפך.

בדקנו את הסורקים שלנו, והתברר שלרובם יש צורך לרענן/להכשיר מחדש, אחרת הם פשוט לא מסוגלים לעבוד כרגיל עם הברקוד הזה. השתלשלות העניינים הזו הבטיחה לנו כאב ראש קשה, כי לחברה שלנו יש הרבה חנויות הפזורות על פני שטח עצום. כמה עשרות אלפי קופות רושמות - ומעט מאוד זמן.

מה היה צריך לעשות? ישנן שתי אפשרויות. ראשית: המהנדסים באתר מרעננים מחדש ומכוונים את הסורקים באופן ידני. שנית: אנו עובדים מרחוק ורצוי, מכסים סורקים רבים בו-זמנית באיטרציה אחת.

האפשרות הראשונה, כמובן, לא התאימה לנו: נצטרך להוציא כסף על ביקור מהנדסים, ובמקרה הזה יהיה קשה לשלוט ולתאם את התהליך. אבל הדבר החשוב ביותר הוא שאנשים יעבדו, כלומר, אנחנו עלולים לקבל הרבה שגיאות, וסביר להניח שלא נעמוד בדד-ליין.

האפשרות השנייה טובה לכולם, אם לא לדבר אחד. לחלק מהספקים לא היו את כלי ההבהוב המרוחקים שהיינו צריכים עבור כל מערכות ההפעלה הנדרשות. ומכיוון שהמועדים אזלו, נאלצתי לחשוב בראש שלי.

לאחר מכן, נספר לכם כיצד פיתחנו כלים עבור סורקים ידניים עבור מערכת ההפעלה Debian 9.x (כל הקופות שלנו נמצאות בדביאן).

פתור את החידה: איך מבזקים סורק

מדווח ויקטור אנטיפוב.

כלי השירות הרשמי שסופק על ידי הספק עובד תחת Windows, ורק עם IE. כלי השירות יכול להבהב ולהגדיר את הסורק.

מכיוון שמערכת היעד שלנו היא דביאן, התקנו שרת usb-redirector בדביאן ולקוח usb-redirector ב-Windows. באמצעות כלי עזר ל-usb-redirector, העברנו את הסורק ממכשיר לינוקס למחשב Windows.

כלי עזר של ספק Windows ראה את הסורק ואף הבזיק אותו כרגיל. לפיכך, הגענו למסקנה הראשונה: שום דבר לא תלוי במערכת ההפעלה, זה עניין של פרוטוקול מהבהב.

בסדר. הרצנו את ההבהוב במכונת Windows, והסרנו את ה-dump במכונת לינוקס.

דחפנו את המזבלה לתוך 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. קריאה שלאחר מכן של המזבלה אישרה את הניחוש שלי.

ואז החלה לצוץ התמונה הבאה של השידור:

תחילת השידור
fd 3e 02 - התחל
01 FE – מונה שידור
העברה (34 בלוקים, 1024 בתים הועברו)
fd 3e 1024 בתים של נתונים (מחולקים לבלוקים של 30 בתים).
סוף השידור
fd 25

הנתונים הנותרים יש ליישור ל-1024 בתים.

איך נראית מסגרת קצה תמסורת הבלוק:

fd 25 - אות לסיום שידור בלוק. הבא 2f 52 - שאר הקובץ בגודל של עד 1024 בתים. 2f 52, אם לשפוט לפי הפרוטוקול, הוא סכום ביקורת של 16 סיביות CRC.

למען הזמנים של פעם, יצרתי תוכנית ב-C שמשכה 1024 בתים מקובץ וחישבה CRC של 16 סיביות. הפעלת התוכנית הראתה שלא מדובר ב-CRC של 16 סיביות. שוב קהה - למשך כשלושה ימים. כל הזמן הזה ניסיתי להבין מה זה יכול להיות, אם לא סכום צ'ק. תוך כדי לימוד אתרים בשפה האנגלית, גיליתי שהמודם X משתמש בחישוב סכום ביקורת משלו - CRC-CCITT (XModem). לא מצאתי יישום C של החישוב הזה, אבל מצאתי אתר שחישב את סכום הבדיקה הזה באינטרנט. לאחר העברת 1024 בתים מהקובץ שלי לדף האינטרנט, האתר הראה לי סכום בדיקה שתואם לחלוטין את סכום הבדיקה מהקובץ.

הידד! החידה האחרונה נפתרה, עכשיו הייתי צריך ליצור קושחה משלי. לאחר מכן, העברתי את הידע שלי (והוא נשאר רק בראשי) לאיליה, שמכיר את ערכת הכלים העוצמתית Python.

יצירת תוכנית

מדווח איליה אלשין.

לאחר שקיבלתי את ההנחיות המתאימות, הייתי מאוד "מאושר".

איפה להתחיל? נכון, מההתחלה.  מלקיחת dump מיציאת ה-USB.

הפעל את USB-pcap https://desowin.org/usbpcap/tour.html

בחר את היציאה אליה המכשיר מחובר ואת הקובץ שבו נשמור את ה-dump.

אנו מחברים את הסורק למכונה שבה מותקנת התוכנה המקורית EZConfigScanning עבור Windows.

בו אנו מוצאים את הפריט לשליחת פקודות למכשיר. אבל מה עם קבוצות? איפה אני יכול להשיג אותם?
כאשר התוכנית מתחילה, הציוד מתבצע באופן אוטומטי (נראה זאת מעט מאוחר יותר). והיו ברקודים לאימון ממסמכי ציוד רשמיים. פיגור. זה הצוות שלנו.

הנתונים הדרושים התקבלו. פתח את dump.pcap דרך wireshark.

חסום בעת הפעלת EZConfigScanning. מקומות שאתה צריך לשים לב אליהם מסומנים באדום.

כשראיתי את כל זה בפעם הראשונה, איבדתי את הלב. לא ברור היכן לחפור הלאה.

קצת סיעור מוחות ו-ו-ו... אהה! במזבלה הַחוּצָה - זה inו - in זה הַחוּצָה.

חיפשתי בגוגל מה זה URB_INTERRUPT. גיליתי שזו שיטת העברת נתונים. ויש 4 שיטות כאלה: שליטה, פסיקה, איזוכרונית, בתפזורת. ניתן לקרוא עליהם בנפרד.

ואת כתובות נקודות הקצה בממשק התקן ה-USB ניתן להשיג באמצעות הפקודה "lsusb -v" או באמצעות pyusb.

כעת עלינו למצוא את כל המכשירים עם ה-VID הזה. אתה יכול לחפש ספציפית לפי VID:PID.

זה נראה כך:

אז יש לנו את המידע הדרוש: פקודות P_INFO. או DEFALT, כתובות היכן לכתוב פקודות endpoint=03 והיכן להשיג את התגובה endpoint=86. כל מה שנותר הוא להמיר את הפקודות ל-hex.

מכיוון שכבר מצאנו את המכשיר, בואו ננתק אותו מהקרנל...

...וכתוב לנקודת הקצה עם כתובת 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.

גדול! המרת ברקודים של המערכת ל-hex. זהו, פונקציונליות האימון מוכנה.

מה לגבי הקושחה? הכל נראה אותו דבר, אבל יש ניואנס.

לאחר שלקחנו dump מוחלט של תהליך ההבהוב, הבנו בערך עם מה יש לנו עסק. הנה מאמר על XMODEM, שהיה מאוד מועיל בהבנת איך התקשורת הזו מתרחשת, אם כי במונחים כלליים: http://microsin.net/adminstuff/others/xmodem-protocol-overview.html אני ממליץ לקרוא.

בהסתכלות על ה-dump, אתה יכול לראות שגודל המסגרת הוא 1024, וגודל הנתונים URB הוא 64.

לכן – 1024/64 – אנו מקבלים 16 שורות בבלוק, קוראים את קובץ הקושחה 1 תו בכל פעם ויוצרים בלוק. משלים שורה אחת בבלוק עם תווים מיוחדים fd1e3 + מספר בלוק.
14 השורות הבאות מתווספות עם fd25 +, באמצעות XMODEM.calc_crc() אנו מחשבים את סכום הבדיקה של הבלוק כולו (לקח הרבה זמן להבין ש"FF – 1" הוא CSUM) והשורה האחרונה, ה-16 מתווספת עם fd3e.

נראה שזהו זה, קרא את קובץ הקושחה, לחץ על הבלוקים, נתק את הסורק מהקרנל ושלח אותו למכשיר. אבל זה לא כל כך פשוט. יש להעביר את הסורק למצב קושחה,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
מאיפה הצוות הזה?? מהמזבלה.

אבל אנחנו לא יכולים לשלוח בלוק שלם לסורק בגלל מגבלת 64:

ובכן, הסורק במצב מהבהב NEWAPP אינו מקבל hex. לכן, תצטרך לתרגם כל שורה 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