Задача для разработчика, или как мы без вендора ручные сканеры прошивали

    Всем привет.

    Мы, Виктор Антипов и Илья Алешин, сегодня расскажем о своем опыте работы с USB-девайсами через Python PyUSB и немного о реверс-инжиниринге.



    Предыстория


    В 2019 году вступило в силу Постановление Правительства РФ № 224 «Об утверждении Правил маркировки табачной продукции средствами идентификации и особенностях внедрения государственной информационной системы мониторинга за оборотом товаров, подлежащих обязательной маркировке средствами идентификации, в отношении табачной продукции».
    Документ объясняет, что с 1 июля 2019 года производители обязаны маркировать каждую пачку табака. А прямые дистрибьюторы должны получать данную продукцию с оформлением универсального передаточного документа (УПД). Магазинам, в свою очередь, необходимо регистрировать продажу маркированной продукции через кассу.

    Также с 1 июля 2020 года оборот немаркированной табачной продукции запрещен. Это означает, что все пачки сигарет должны маркироваться специальным штрихкодом Datamatrix. Причем – важный момент – выяснилось, что Datamatrix будет не обычный, а инверсный. То есть не черный код на белом, а наоборот.

    Мы протестировали наши сканеры, и оказалось, что большую их часть нужно перепрошивать/переобучать, иначе они просто не в состоянии нормально работать с этим штрихкодом. Такой поворот событий гарантировал нам сильную головную боль, потому что у нашей компании очень много магазинов, которые разбросаны по огромной территории. Несколько десятков тысяч касс – и крайне мало времени.

    Что было делать? Варианта два. Первый: инженеры на объекте вручную перепрошивают и донастраивают сканеры. Второй: работаем удаленно и, желательно, охватываем сразу много сканеров за одну итерацию.

    Первый вариант нам, очевидно, не подходил: пришлось бы потратиться на выезды инженеров, да и контролировать и координировать процесс в таком случае сложно. Но самое главное – работали бы люди, то есть потенциально мы получали множество ошибок и, скорее всего, не укладывались в срок.

    Второй вариант всем хорош, если бы не одно но. У некоторых вендоров не оказалось необходимых нам инструментов удаленной перепрошивки для всех требуемых ОС. А так как сроки поджимали, пришлось думать своей головой.

    Дальше расскажем, как мы разрабатывали инструменты для ручных сканеров под ОС Debian 9.x (у нас все кассы на Debian).

    Разгадать загадку: как прошить сканер


    Рассказывает Виктор Антипов.

    Официальная утилита, которую предоставил вендор, работает под Windows, причем только с IE. Утилита умеет прошивать и настраивать сканер.

    Так как целевая система у нас Debian, то поставили на Debian usb-redirector server, на Windows usb-redirector client. При помощи утилит usb-redirector сделали проброс сканера с Linux машины, на Windows машину.

    Утилита от вендора под Windows увидела сканер и даже его нормально прошила. Таким образом, сделали первый вывод: от ОС ничего не зависит, дело в протоколе перепрошивки.

    Ок. На Windows-машине запустили перепрошивку, на Linux-машине сняли dump.

    Запихнули dump в WireShark и… взгрустнули (часть деталей dump я опущу, они никакого интереса не представляют).

    Что нам показал dump:





    Адреса 0000-0030, судя по Wireshark, – служебная информация USB.

    Нас интересовала часть 0040-0070.

    Из одного кадра передачи ничего не было понятно, за исключением символов MOCFT. Эти символы оказались символами из файла прошивки, как, впрочем, и остальные символы до окончания кадра (выделен файл прошивки):



    Что означали символы fd 3e 02 01 fe, лично я, как и Илья, понятия не имел.

    Посмотрел следующий кадр (служебная информация здесь удалена, выделен файл прошивки):



    Что стало ясно? Что первые два байта – некая константа. Все последующие блоки это подтвердили, но до окончания блока передачи:



    Этот кадр тоже ввел в ступор, так как сменилась константа (выделил) и, как ни странно, имелась часть файла. Размер переданных байт файла показывал, что было передано 1024 байта. Что значили остальные байты – я снова не знал.

    Первым делом, как старый BBS-ник, я пересмотрел стандартные протоколы передачи. 1024 байта ни один протокол не передавал. Начал изучать матчасть и наткнулся на протокол 1К Xmodem. Он позволял передавать 1024, но c нюансом: поначалу лишь 128, и только при отсутствии ошибок протокол увеличивал количество передаваемых байт. У меня же сразу была передача 1024 байта. Решил изучать протоколы передачи, а конкретно Х-модем.

    Вариаций модема было две.

    Во-первых, формат пакета XMODEM с поддержкой CRC8 (оригинальный XMODEM):



    Во-вторых, формат пакета XMODEM с поддержкой CRC16 (XmodemCRC):



    С виду похоже, за исключением SOH, номера пакета и CRC и длины посылки.

    Посмотрел начало второго блока передачи (и снова увидел файл прошивки, но уже с отступом в 1024 байта):



    Увидел знакомый заголовок fd 3e 02, но следующие два байта уже изменились: было 01 fe, а стало 02 fd. Тут я заметил, что второй блок теперь нумеруется 02 и таким образом понял: передо мной нумерация блока передачи. Первая 1024 передача – 01, вторая – 02, третья – 03 и так далее (но в hex, естественно). Но что означает изменение с fe на fd? Глаза видели уменьшение на 1, мозг напоминал, что программисты считают с 0, а не с 1. Но тогда почему первый блок 1, а не 0? Ответа на этот вопрос я так и не нашел. Зато понял, как считается второй блок. Второй блок – это не что иное как FF –(минус) номер первого блока. Таким образом, второй блок обозначался как = 02 (FF-02) = 02 FD. Последующее чтение дампа подтвердило мою догадку.

    Тогда стала вырисовываться следующая картина передачи:

    Начало передачи
    fd 3e 02 – Start
    01 FE – счетчик передачи
    Передача (34 блока, передается 1024 байта)
    fd 3e 1024 байта данных (разбитые на блоки по 30 байт).
    Окончание передачи
    fd 25

    Остатки данных для выравнивания до 1024 байта.

    Как выглядит кадр окончания передачи блока:



    fd 25 – сигнал к окончанию передачи блока. Далее 2f 52 – остатки файла до размера 1024 байта. 2f 52, судя по протоколу, – контрольная сумма 16-bit CRC.

    По старой памяти сделал на С программу, которая дергала из файла 1024 байта и считала 16-bit CRC. Запуск программы показал, что это не 16-bit CRC. Снова ступор – примерно на три дня. Все это время я пытался понять, что это может быть такое, если не контрольная сумма. Изучая англоязычные сайты, я обнаружил, что для X-модем используется свой подсчет контрольной суммы – CRC-CCITT (XModem). Реализаций на C данного подсчета я не нашел, но нашел сайт, который в online считал данную контрольную сумму. Перекинув на веб-страничку 1024 байта своего файла, сайт показал мне контрольную сумму, которая полностью совпала с контрольной суммой из файла.

    Ура! Последняя загадка решена, теперь нужно было сделать свою прошивалку. Далее я передал свои знания (а они остались только у меня в голове) Илье, который знаком с мощным инструментарием – Python.

    Создание программы


    Рассказывает Илья Алешин.

    Получив соответствующие инструкции, я очень «обрадовался».

    С чего начать? Правильно, с начала.  Со снятия дампа с USB порта.

    Запускаем USB-pcap https://desowin.org/usbpcap/tour.html

    Выбираем порт, к которому подключено устройство, и файл, куда сохраним dump.



    Подключаем сканер к машине, где установлено родное ПО EZConfigScanning для Windows.



    В нем находим пункт отправки команд на устройство. Но как быть с командами? Где их взять?
    При старте программы оборудование опрашивается автоматически (это мы увидим чуть позже). И еще были обучающие штрихкоды из официальных документов оборудования. DEFALT. Это и есть наша команда.



    Необходимые данные получены. Открываем dump.pcap через wireshark.

    Блок при старте EZConfigScanning. Красным отмечены места, на которые надо обратить внимание.





    Увидев все это в первый раз, я упал духом. Куда копать дальше – непонятно.

    Немного мозгового штурма и-и-и… Ага! В дампе out – это in, а in это out.

    Погуглил, что такое URB_INTERRUPT. Выяснил, что это метод передачи данных. И таких методов 4: control, interrupt, isochronous, bulk. О них можно почитать отдельно.

    А endpoint адреса в интерфейсе USB-девайса можно получить либо через команду «lsusb –v», либо средствами pyusb.

    Теперь надо найти все устройства с таким VID. Можно искать конкретно по VID:PID.



    Выглядит это так:





    Итак, у нас появилась нужная информация: команды P_INFO. или DEFALT, адреса, куда записать команды endpoint=03 и откуда получить ответ endpoint=86. Осталось только перевести команды в hex.





    Так как устройство у нас уже найдено, отключим его от ядра…



    …и выполним запись в endpoint c адресом 0x03,



    … а затем зачитаем ответ из endpoint с адресом 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. Все, функционал обучения готов.

    Как быть с прошивкой? Вроде, все то же самое, но есть нюанс.

    Сняв полный дамп процесса перепрошивки, мы примерно поняли, с чем имеем дело. Вот статья про XMODEM, которая очень помогла понять, как это общение происходит, пусть и в общих чертах: http://microsin.net/adminstuff/others/xmodem-protocol-overview.html Рекомендую прочесть.

    Посмотрев в дамп, можно увидеть, что размер кадра – 1024, а размер URB-data – 64.



    Следовательно – 1024/64 – получаем 16 строк в блоке, читаем файл прошивки по 1 символу и формируем блок. Дополняя 1 строку в блоке спецсимволами fd3e02 + номер блока.
    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 = '\xfd\x01\x04'.

    Ну а так как эти блоки для обычных людей никакой информации не несут, сделаем по умолчанию прошивку в скрытом режиме. И на всякий случай через tqdm организуем прогресбар.



    Собственно, дальше дело за малым. Остается только обернуть решение в скрипты для массового тиражирования в четко заданное время, чтобы не тормозить процесс работы на кассах, и добавить логирование.

    Итог


    Потратив кучу времени и сил и волос на голове, мы сумели разработать нужные нам решения, к тому же уложились в срок. При этом сканеры перепрошиваются и переобучаются теперь централизованно, мы четко контролируем весь процесс. Компания сэкономила время и средства, а мы получили бесценный опыт реверс-инжиниринга оборудования такого типа.
    X5 Retail Group
    Все о цифровой трансформации ритейла

    Comments 47

      +5
      Из за этой маркировки некоторые мелкие европейские производители уже начали отказываться от поставок продукции в Россию, толи ещё будет.
        +1
        Будут импортеры маркировать с помощью наклеек.
          0
          Товар ещё до пересечения границы должен обладать кодом, т.е. клеить придётся за границей.
          Импортёры от такого мягко говоря не в восторге.
            0
            Вы за всех не говорите. Есть импортеры, которые это могут обеспечить. Есть — которые не могут, но научатся. Есть которые закроются.
              0
              Это в любом случае дополнительные траты и усложнение логистики которые не факт что когда нибудь окупятся.
              Покажите мне пальцем на того кому это нравится.
        +2

        Речь идет об одной и единственной модели сканера, ряде моделей или вообще о произвольном наборе, попросту так повезло, что у них у всех начинка одинаковая ?

          +3

          Вот у Вас на картинке вроде honneywell 1450, который и так берёт инверсный код.(или у Вас совсем старые модели)
          Очень странно, что у Вас USB сканера… а не комовские… При том, что Вы говорите о многих магазинах, ведь если
          1.Он работает как клавиатура(HID), то нужно разработчику следить за раскладкой ибо QR
          qwert придёт в ИС как йцуке.
          2.А если работает как эмуляция COM от USB (в Linux видятся как /dev/ttyUSB0 ,/dev/ttyACM0 и т.д), То за раскладкой следить уже не надо, НО Вы теряете важную "фишку" нативного сканера RS-232., работающего от своего автономного блока питания.Если у него не получается считать QR код, он увеличивает яркость(чем не может похвастаться эмуляция USB).И количество верных сработок на порядок у нативного rs-232 выше, чем у USB-COM,

            +1

            Как вы умудрились связать интерфейс подключения и алгоритмы коррекции ошибок внутренней части сканера?

              0

              Умудрился связать, потому как связь действительно есть… если у Вас 3 ларька в обслуживании с 5 сканерами USB,-То нагрузка на поддержку не заметна, а когда 500 компов в обслуживании, вот тут и вылазят все косяки, и если у Вас rs-232, то косяков на порядки меньше.Вы сказали, что у Вас много магазинов… Вот я и удивился простой вещи:
              -Зачем Вы так себя мучаете, когда можно не мучаться.
              Но впрочем это Ваше дело.

                +2
                Я не из x5. Я имел ввиду вот эту фразу
                .Если у него не получается считать QR код, он увеличивает яркость(чем не может похвастаться эмуляция USB)

                  0

                  Извините, я думал Вы автор или причастен к конторе.
                  На самом деле


                  Если у него не получается считать QR код, он увеличивает яркость(чем не может похвастаться эмуляция USB)

                  Это очень Важная фишка.Качество QR кода на сигаретах очень низкое… многие сканера не берут… И вот тут инкрементальное увеличение яркости (а следовательно контрастности QR кода) играет Важную вещь для считывания.
                  В сухом остатке кассир на кассе не мучает ни себя ни покупателя. ожиданием.
                  Т.е кассир со сканером rs-232 работает эффективнее чем кассир с USB(в каком бы режиме USB сканер не работал) при считывании QR.
                  Для больших магазинов это важный показатель.

                    0

                    Просто из комментов непонятно, почему


                    • последовательное увеличение яркости делает драйвер, а не сама железяка
                    • почему через USB нельзя подать команду, которая подаётся RS-232
                      0

                      увеличение яркости делает делает железяка… и именно потому, что есть автономный источник питания… если USB будет так делать… сожгёт USB в компе.

                        0
                        Там подстветка включается чтоли? Там же бликов будет много — это спорное техническое решение.Не понятно. Даже если так, тока в usb для светодиодов достаточно.
                  +2
                  Вы сравнивали одну модель на разных интерфейсах или все же разные модели сканеров с разными же интерфейсами и делает такой вывод?
                    –2

                    Я много работаю с POS оборудованием.И много со сканерами штрихкода.Хорошие сканера (Начиная от 150 $) Ведут себя именно так.Вставил USB кабель(если надо отсканировал настроечный код) И всё QR определённого качества не читает.Меняем кабель в этом же сканере на rs-232… И всё ОК.Я не буду перечислять брэнды и модели… Вот у автора на картинке Honneywell 1450… Он относится к классу хороших сканеров Не знаю зачем автор поста его перепрошивал… он и так берёт инверсный QR код. Так вот эта модель… ведёт себя так как я описал..

                      +2
                      Вы на мой вопрос ответили, спасибо.
                      Мы, как потребители POS оборудования, пошли по пути «найти модель которая без проблем читает вот этот набор шк».

                      А не сталкивались с тем, что имиджевый сканер (с камерой) EAN13 плохо пропечатанный «додумывает»? В том числе и контрольное число.
                        0

                        Я стараюсь брать хорошие сканера и это не типично додумывать.
                        Вообще алгоритм додумывания включён в PDF 417
                        Это старая марка егаиса


                        PDF417 предусматривает полиномиальное кодирование Рида-Соломона дополнительных данных для восстановления информации. Количество дополнительных КС зависит от уровня коррекции ошибок.

                        В очень хороших сканерах (от 2000$) включен этот алгоритм Рида-Соломона и можно часть кода закрыть пальцем.И хороший сканер благодаря этому алгоритму восстановит потери и прочитает правильно.

                          +1
                          Я стараюсь брать хорошие сканера и это не типично додумывать.

                          Да не похоже, что в цене тут дело. Старый дешевый лазерный сканер такой ШК EAN13 или корректно читает или не читает вовсе, а имиджевый в 1-2 считываниях из 10 выдает некорректные данные с пересчитанной контрольной цифрой. Я вижу что ШК фиговый и что ширина линий в месте где неправильно читаются данные больше/меньше чем должна быть. Это именно брак ШК который имеджевый сканер всеми правдами и неправдами пытается прочитать.

                          И судя по ценнику мы говорим в вашем случае про станционарные сканеры. Не наш вариант. Мы ручные используем в наших «ларьках». А тут уже надо учитывать потери от падений сканеров на пол. И не надо писать «дорогие выживают». Люди пальцем сенсорные экраны разбивают, а тут всего лишь уронить удачно надо.
                            +1

                            Додумывать EAN 13 вообще нельзя… можно додумывать то, что входит в спецификацию.(Типа PDF 417)
                            Но… я сталкивался с подобным поведением в ТСД(Терминалах сбора данных) Выяснялось,- он путал UPC с EAN13 (UPC Это американский формат 12 символов (или 11+1(контрольный))).
                            Если Вам пришло 12 символов это оно самое.
                            Но там(в ТСД) можно отключить распознавание форматов.
                            Возможно Ваш сканер путает EAN13-UPC… Именно на сканерах такого не встречал… Было на ТСД.

                              +1
                              Выяснялось,- он путал UPC с EAN13 (UPC Это американский формат 12 символов (или 11+1(контрольный))).
                              рискну предположить, что EAN13 в том случае начинался с нулей или в сканере была отключена передача контрольного символа в EAN13.

                              Если Вам пришло 12 символов это оно самое

                              13
                                0

                                Характер того штрихкода я уже не помню..(Только не в сканере, а в ТСД).
                                А вот то, что Вам пришло 13 символов и при этом неверных Это и вправду странно...EAN13 настолько распространенный формат, что должно работать как "отченаш"
                                … Атоловский сканер что-ли?

                                  +1
                                  Конечно же в ТСД (хоть там и стояла максимально обрезанная начинка от обычного сканера. не в том суть).

                                  Honeywell. Модель сейчас не вспомню. Не занимаюсь ими напрямую сейчас.
                              +2
                              Хоть в EAN13 и есть контролька, но бывают неудачные совпадения, например 2150000280211 и 2150000280877, которые при неудачном угле и качестве печати дают поочередное срабатывание то одного то другого ШК, особенно на изогнутых поверхностях.
                              Скрытый текст
                              image
                              image
                                +1
                                Что-то хабр побил ссылки в картинках, вот сохраненные, а не из генератора
                                Скрытый текст

                                  0
                                  Да картинкой надёжнее, но как не странно ещё не каждый онлайн генератор кодов их правильно формирует. Я намучался с ними пока подобрал более менее стабильно читаемый EAN13(хотя казалось бы что может пойти не так).
                                    0
                                    zint из командной строки вне конкуренции.
                  +1
                  Для информации

                  1 на кассах с линуксом переключение раскладки явление мало вероятное. У кассира просто нет таких кнопок и в самой ОС это отключено
                  2 последнее время эмуляция кома в сканерах с USB это все тот же HID но со специфичным ID и спец префиксом для драйвера по которому тот «ловит» выхлоп сканера и перенаправляет в виртуальный COM. Это не полноценный USB-COM
                    +1

                    Не делайте поспешные выводы
                    У меня все кассы на линуксах.(ИС кроссплатформенная, но флагманская ось linux)
                    И всякое бывает с раскладками.
                    И эмуляция кома это не тот же HID- это эмуляция COM.Не знаю о какой модели вы говорите можем сверить позиции по моделям уже в личке… с какими я работал, вам точно скажу чип.(Linux его классно показывает)

                    +1
                    Изначально сканеры брали для продажи алкогольной продукции, это было более 5 лет назад. Речи про инверсный DM тогда не шло.
                    Годы поставок сканеров разные, в продуктивной среде у нас было как минимум 8 версий прошивок. Пришлось выравнивать. Также у нас есть процедура Patch Management, в соответствии с ней мы всегда работаем на последних версиях.
                      +1
                      1. Мы не работаем со сканером как с клавиатурой, нам нужно знать, какой тип штрихкода у нас на входе.
                      2. Сканер покупали достаточно давно, на тот момент задачи решались на USB без проблем. Насчет использования RS232 и внешних блоков питания. Это отчасти вопрос религий. Для внешнего блока питания требуется дополнительная розетка в ИБП, укладка проводов становится сложной, поскольку надо вести в два места. Оборудование на RS232 плохо дисковерится, надо знать, в какой порт включено устройство, иначе будет аффект на другие устройства (яркий пример – дисплей покупателя: если дисплею что-то не нравится, он начинает писать иероглифами), ну и так далее.

                        +1

                        И не смотря на все эти сложности rs-232 Полностью себя оправдывает, понижая административный ресурс сопровождения.
                        Это тот случай, когда долго запрягать но быстро ехать.
                        Надо просто разработать стандарт… Сканер вставляем всегда в это гнездо.(типа внизу справа :-)) весы в это… индикатор в это.

                      –4

                      Ждём следующего нелепого закона и героическую статью о борьбе с последствиями вместо причин

                        0
                        в данном случае это именно борьба с вендором, кого не волнует удаленная прошивка устройств с бесплатных ОС не зависимо от того, получает ли кто бабло от нововведения закона (скорее всего да) или нет.
                          0
                          Говорить о «заговоре» в данном случае рано, т.к. во первых сканер официально поддерживает datamatrix, во вторых это внезапное изменение законов РФ, на которые ещё не успел отреагировать импортный производитель.
                          Вот где жопка, так это с эвотором, эти какашки чтобы укоротить чек на 2см хотят 2тыр в год с каждого терминала(кассы). И таких примеров «работы» эвотора у меня накопилось десятки.
                            0
                            ничего удивительного при монополии
                              0
                              Да нет какой то особой монополии. Вариантов онлайн касс десятки.
                              Это просто говноконторка для выкачивания денег из бизнеса с хорошей крышей, рекламой уши забили, плюс опыта не было, а теперь хотят деньги даже за такие мелочи вроде округления копеек в сумме. Благо я их брал с последующим возмещением(обошлись как пара криптонакопителей плюс договор с ОФД), но как три-четыре года пройдут буду рассматривать альтернативы. Благо теперь знаю куда смотреть при покупке.
                        +1
                        Неплохо. Наверное стоило бы добавить тег реверс-инжиниринг.
                          0
                          А прошивку то как собираете? или она была и нужно было просто ее с линукса удаленно запулить?

                          EZConfigScanning — если работает только в IE значит это activex модуль. То есть dll-ка. А вось на шарпе написана и открывается чуть ли не в исходный код?
                          Не пробовали ее реверснуть и посмотреть функции вызова протокола? Хотя бы гуглеж облегчило бы все это дело.

                          Есть у вас статистика по сканерам в обороте? Чем руководствовались призакупке оборудования, которое не поддерживает удаленку по линуксу? Наследие?

                          Майнил ли кто на кассах по ночам биткоины?
                            +1
                            Если бы я дружил с Windows, то, наверное, так бы и действовал, но увы, я с Windows – уверенный пользователь Excel.

                            Да, статистика есть. Благодаря полученным результатам по перепрошивке, научились снимать настройки со сканера, так что теперь можем гарантировать, что в магазине не будет проблем.
                            При закупке, руководствовались текущей задачей – продажей алкогольной продукции, и на тот момент она решалась успешно. Так что да, отчасти наследие.

                              +1
                              Не майнили, но идеи были. Есть золотое правило: магазин должен продавать, так что мы кровно заинтересованы в том, чтобы оборудование работало для задач магазина.
                              +1
                              Дилетантский вопрос. Если требовалось только прошить зачем нужно было разбираться с протоколом?
                              Ведь по идее можно снять дамп USB и просто гнать его в устройство, разве нет?
                                +1
                                С дампом не все так просто. В дампе очень много служебной информации USB, USB-шина не позволяет лить информацию просто так, ибо облачает ее в свои спецификации. Также было стойкое ощущение, что прошивка не последняя и придется снова что-то делать.
                                0
                                Сколько времени потратили на решение задачи? Интересно, т.к. занимался аналогичной задачей в Магните.
                                  0

                                  А распечатать код "включение инверсного режима" и просто один раз "пикнуть" сканером, даже не отключая от кассы, не судьба?

                                    0
                                    Там на части сканеров прошивка устаревшая, ещё до создания датаматрикс.
                                    0
                                    3e и 25 — мне кажется длинна значащей части

                                    Only users with full accounts can post comments. Log in, please.