డెవలపర్ కోసం ఒక టాస్క్ లేదా మేము విక్రేత లేకుండా హ్యాండ్‌హెల్డ్ స్కానర్‌లను ఎలా ఫ్లాష్ చేసాము

అందరికీ నమస్కారం.

ఈరోజు, విక్టర్ ఆంటిపోవ్ మరియు ఇల్యా అలెస్హిన్, పైథాన్ PyUSB ద్వారా USB పరికరాలతో పనిచేసిన మా అనుభవాలను మరియు రివర్స్ ఇంజనీరింగ్ గురించి కొద్దిగా పంచుకుంటారు.

పూర్వచరిత్ర

2019లో, "పొగాకు ఉత్పత్తులను గుర్తింపు సాధనాలతో మార్కింగ్ చేయడానికి సంబంధించిన నియమాల ఆమోదం మరియు పొగాకు ఉత్పత్తులకు సంబంధించి తప్పనిసరిగా గుర్తింపు సాధనాలతో మార్కింగ్ చేయవలసిన వస్తువుల ప్రసరణను పర్యవేక్షించడానికి ఒక రాష్ట్ర సమాచార వ్యవస్థను అమలు చేసే ప్రత్యేకతల గురించి" రష్యన్ ప్రభుత్వ తీర్మానం నెం. 224 అమల్లోకి వచ్చింది.
ఈ పత్రం ప్రకారం, జూలై 1, 2019 నుండి, తయారీదారులు ప్రతి పొగాకు ప్యాక్‌పై లేబుల్ వేయడం తప్పనిసరి. ప్రత్యక్ష పంపిణీదారులు ఈ ఉత్పత్తులను యూనివర్సల్ ట్రాన్స్‌ఫర్ డాక్యుమెంట్ (UTD)తో స్వీకరించాలి. దుకాణాలు, తమ వంతుగా, చెక్అవుట్ వద్ద లేబుల్ ఉన్న ఉత్పత్తుల అమ్మకాన్ని నమోదు చేయాలి.

అంతేకాకుండా, జూలై 1, 2020 నుండి, గుర్తు లేని పొగాకు ఉత్పత్తుల చలామణి నిషేధించబడింది. దీని అర్థం, అన్ని సిగరెట్ ప్యాక్‌లపై తప్పనిసరిగా ఒక ప్రత్యేకమైన డేటామాట్రిక్స్ బార్‌కోడ్‌ను ముద్రించాలి. ముఖ్యంగా, ఈ డేటామాట్రిక్స్ ఒక ప్రామాణిక బార్‌కోడ్ కాకుండా, విలోమమైనదిగా ఉంటుందని వెల్లడైంది. అంటే, తెల్లటి కోడ్‌పై నల్లటి కోడ్ కాకుండా, దానికి వ్యతిరేకంగా ఉంటుంది.

మేము మా స్కానర్‌లను పరీక్షించగా, వాటిలో చాలావాటిని తిరిగి ప్రోగ్రామ్ చేయాల్సి లేదా వాటికి తిరిగి శిక్షణ ఇవ్వాల్సి ఉందని తేలింది, లేకపోతే అవి ఈ బార్‌కోడ్‌తో సరిగ్గా పనిచేయవు. మా కంపెనీకి విశాలమైన భూభాగంలో విస్తరించి ఉన్న భారీ సంఖ్యలో దుకాణాలు ఉన్నందున, ఈ పరిణామం మాకు పెద్ద తలనొప్పిని తెచ్చిపెట్టింది. పదివేలకొద్దీ చెక్అవుట్‌లు – మరియు సమయం చాలా తక్కువ.

మనం ఏమి చేయాలి? రెండు మార్గాలు ఉన్నాయి. మొదటిది, సైట్‌లో ఉన్న ఇంజనీర్లు స్కానర్‌లను మాన్యువల్‌గా రీఫ్లాష్ చేసి, ఫైన్-ట్యూన్ చేయడం. రెండవది, మనం రిమోట్‌గా పని చేస్తూ, వీలైతే, ఒకే ప్రయత్నంలో అనేక స్కానర్‌లను పరిశీలించడం.

మొదటి ఎంపిక మాకు స్పష్టంగా సరిపోలేదు: మేము ఇంజనీర్ల సందర్శనల కోసం డబ్బు ఖర్చు చేయాల్సి వచ్చేది, మరియు ఆ ప్రక్రియను పర్యవేక్షించడం, సమన్వయం చేయడం కష్టమయ్యేది. కానీ అన్నింటికన్నా ముఖ్యంగా, దానిలో మనుషుల ప్రమేయం ఉండేది, అంటే మేము బహుశా అనేక పొరపాట్లను ఎదుర్కొని, గడువును కూడా కోల్పోయి ఉండేవాళ్ళం.

ఒక సమస్య లేకపోయి ఉంటే, రెండవ ఎంపిక పరిపూర్ణంగా ఉండేది. అవసరమైన అన్ని ఆపరేటింగ్ సిస్టమ్‌ల కోసం మాకు కావలసిన రిమోట్ ఫ్లాషింగ్ టూల్స్ కొంతమంది విక్రేతల వద్ద లేవు. మరియు గడువులు దగ్గర పడటంతో, మేమే దాన్ని పరిష్కరించుకోవలసి వచ్చింది.

తరువాత, డెబియన్ 9.x తో నడిచే హ్యాండ్‌హెల్డ్ స్కానర్‌ల కోసం మేము టూల్స్‌ను ఎలా అభివృద్ధి చేశామో మీకు తెలియజేస్తాము (మా చెకౌట్‌లన్నీ డెబియన్‌పైనే ఉన్నాయి).

పొడుపు కథను పరిష్కరించండి: స్కానర్‌ను ఎలా ఫ్లాష్ చేయాలి

విక్టర్ ఆంటిపోవ్ కథను చెప్పాడు.

విక్రేత అందించిన అధికారిక యుటిలిటీ విండోస్‌లో పనిచేస్తుంది, కానీ కేవలం ఇంటర్నెట్ ఎక్స్‌ప్లోరర్‌తో మాత్రమే. ఇది స్కానర్‌ను ఫ్లాష్ చేసి, కాన్ఫిగర్ చేయగలదు.

మా లక్ష్య సిస్టమ్ డెబియన్ కాబట్టి, మేము డెబియన్‌లో USB-రీడైరెక్టర్ సర్వర్‌ను మరియు విండోస్‌లో USB-రీడైరెక్టర్ క్లయింట్‌ను ఇన్‌స్టాల్ చేసాము. USB-రీడైరెక్టర్ యుటిలిటీలను ఉపయోగించి, మేము స్కానర్‌ను లైనక్స్ మెషిన్ నుండి విండోస్ మెషిన్‌కు మళ్లించాము.

విక్రేత యొక్క విండోస్ యుటిలిటీ స్కానర్‌ను గుర్తించి, దానిని విజయవంతంగా ఫ్లాష్ కూడా చేసింది. కాబట్టి, మా మొదటి నిర్ధారణ: దీనికి OSతో సంబంధం లేదు; సమస్య ఫ్లాషింగ్ ప్రోటోకాల్‌లో ఉంది.

సరే. మేము విండోస్ మెషీన్‌లో ఫర్మ్‌వేర్ అప్‌డేట్‌ను ప్రారంభించి, లైనక్స్ మెషీన్‌లో డంప్ తీసుకున్నాము.

మేము ఆ డంప్‌ను వైర్‌షార్క్‌లోకి నెట్టాము మరియు... బాధపడ్డాము (డంప్ వివరాలలో కొన్నింటిని నేను వదిలేస్తాను, అవి అంత ఆసక్తికరమైనవి కావు).

ఆ చెత్తకుప్ప మాకు చూపించినది:

వైర్‌షార్క్ ప్రకారం, 0000-0030 చిరునామాలు USB సేవా సమాచారం.

మాకు 0040-0070 భాగంపై ఆసక్తి ఉండేది.

MOCFT చిహ్నాలు తప్ప, ఆ ఒక్క ట్రాన్స్‌మిషన్ ఫ్రేమ్ నుండి ఏమీ స్పష్టంగా లేదు. ఈ చిహ్నాలు ఫర్మ్‌వేర్ ఫైల్ నుండి వచ్చినవని తేలింది, ఫ్రేమ్ చివరి వరకు ఉన్న మిగిలిన చిహ్నాలు కూడా అలాగే ఉన్నాయి (ఫర్మ్‌వేర్ ఫైల్ హైలైట్ చేయబడింది):

వ్యక్తిగతంగా, ఇల్యా లాగే నాకు కూడా fd 3e 02 01 fe అనే చిహ్నాలకు అర్థం ఏమిటో తెలియదు.

నేను ఈ క్రింది ఫ్రేమ్‌ను చూశాను (ఇక్కడ సర్వీస్ సమాచారం తీసివేయబడింది, ఫర్మ్‌వేర్ ఫైల్ హైలైట్ చేయబడింది):

ఏమి స్పష్టమైంది? మొదటి రెండు బైట్‌లు ఒక రకమైన స్థిరాంకం అని. ఆ తర్వాత వచ్చిన బ్లాక్‌లన్నీ దీనిని ధృవీకరించాయి, కానీ ట్రాన్స్‌మిషన్ బ్లాక్ ముగిసే వరకు కాదు:

ఈ ఫ్రేమ్ కూడా నన్ను గందరగోళానికి గురిచేసింది, ఎందుకంటే (హైలైట్ చేయబడిన) స్థిరాంకం మారిపోయింది మరియు విచిత్రంగా, ఫైల్‌లోని కొంత భాగం కూడా ఉంది. బదిలీ చేయబడిన బైట్‌ల పరిమాణం 1024 బైట్‌లు బదిలీ చేయబడ్డాయని చూపించింది. మిగిలిన బైట్‌ల అర్థం ఏమిటో—మళ్ళీ, నాకు ఏమాత్రం తెలియలేదు.

ఒక అనుభవజ్ఞుడైన BBSerగా, నేను చేసిన మొదటి పని ప్రామాణిక ట్రాన్స్‌మిషన్ ప్రోటోకాల్‌లను సమీక్షించడం. వాటిలో ఏదీ 1024 బైట్‌లను ప్రసారం చేయలేకపోయింది. నేను హార్డ్‌వేర్‌పై పరిశోధన ప్రారంభించి, అనుకోకుండా 1K Xmodem ప్రోటోకాల్‌ను కనుగొన్నాను. అది 1024 బైట్‌లను అనుమతించింది, కానీ ఒక మెలిక ఉంది: ప్రారంభంలో, కేవలం 128 మాత్రమే, మరియు ఎటువంటి లోపాలు లేకపోతేనే ప్రోటోకాల్ ప్రసారం చేసే బైట్‌ల సంఖ్యను పెంచుతుంది. నేను వెంటనే 1024 బైట్‌లను ప్రసారం చేయడం ప్రారంభించాను. నేను ట్రాన్స్‌మిషన్ ప్రోటోకాల్‌లను, ప్రత్యేకంగా Xmodemను అధ్యయనం చేయాలని నిర్ణయించుకున్నాను.

మోడెమ్‌లో రెండు రకాలు ఉండేవి.

మొదట, CRC8 మద్దతుతో కూడిన XMODEM ప్యాకెట్ ఫార్మాట్ (అసలైన XMODEM):

రెండవది, CRC16 మద్దతుతో కూడిన XMODEM ప్యాకెట్ ఫార్మాట్ (XmodemCRC):

SOH, ప్యాకేజీ నంబర్, CRC మరియు ప్యాకేజీ పొడవు మినహా మిగతాదంతా ఒకేలా కనిపిస్తుంది.

నేను రెండవ ట్రాన్స్‌మిషన్ బ్లాక్ ప్రారంభాన్ని చూశాను (మరియు మళ్ళీ ఫర్మ్‌వేర్ ఫైల్‌ను చూశాను, కానీ 1024 బైట్‌ల ఇండెంట్‌తో):

నాకు fd 3e 02 అనే ఒక సుపరిచితమైన హెడర్ కనిపించింది, కానీ దాని తర్వాతి రెండు బైట్లు అప్పటికే మారిపోయాయి: అది 01 fe నుండి 02 fd గా మారింది. అప్పుడు రెండవ బ్లాక్‌కు ఇప్పుడు 02 అని సంఖ్య ఇవ్వబడిందని నేను గమనించాను, దానితో నాకు అర్థమైంది: ఇది ఒక ట్రాన్స్‌ఫర్ బ్లాక్ యొక్క సంఖ్యీకరణ అని. మొదటి 1024 ట్రాన్స్‌ఫర్‌కు 01, రెండవదానికి 02, మూడవదానికి 03, ఆ విధంగా కొనసాగుతుంది (అయితే, ఇది హెక్స్‌లో ఉంటుంది). కానీ fe నుండి fd కి మారడం అంటే ఏమిటి? నా కళ్ళకు 1 తగ్గుదల కనిపించింది, ప్రోగ్రామర్లు 1 నుండి కాకుండా 0 నుండి లెక్కిస్తారని నా మెదడు నాకు గుర్తుచేసింది. అయితే అలాంటప్పుడు మొదటి బ్లాక్‌కు 0 కాకుండా 1 ఎందుకు ఉంది? ఈ ప్రశ్నకు సమాధానం నాకు ఎప్పటికీ దొరకలేదు. కానీ రెండవ బ్లాక్‌ను ఎలా లెక్కిస్తారో నాకు అర్థమైంది. రెండవ బ్లాక్ అంటే 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 చెక్‌సమ్.

అలవాటుగా, నేను ఒక ఫైల్ నుండి 1024 బైట్‌లను తీసుకుని, 16-బిట్ CRCని లెక్కించే ఒక ప్రోగ్రామ్‌ను C భాషలో తయారు చేశాను. ఆ ప్రోగ్రామ్‌ను రన్ చేయగా, అది 16-బిట్ CRC కాదని తేలింది. మళ్ళీ, నేను దాదాపు మూడు రోజుల పాటు తికమకపడ్డాను. ఈ సమయమంతా, అది చెక్‌సమ్ కాకపోతే మరేమై ఉంటుందో అని తెలుసుకోవడానికి ప్రయత్నిస్తూనే ఉన్నాను. ఆంగ్ల భాషా వెబ్‌సైట్‌లలో పరిశోధన చేస్తుండగా, X-మోడెమ్ దాని స్వంత చెక్‌సమ్ లెక్కింపును—CRC-CCITT (XModem)—ఉపయోగిస్తుందని నేను కనుగొన్నాను. ఈ లెక్కింపు యొక్క C ఇంప్లిమెంటేషన్‌లు ఏవీ నాకు దొరకలేదు, కానీ ఆన్‌లైన్‌లో ఈ చెక్‌సమ్‌ను లెక్కించే ఒక వెబ్‌సైట్‌ను కనుగొన్నాను. దాని ఫైల్‌లోని 1024 బైట్‌లను ఒక వెబ్ పేజీకి అప్‌లోడ్ చేసిన తర్వాత, ఆ వెబ్‌సైట్ నాకు ఫైల్‌లోని చెక్‌సమ్‌తో పూర్తిగా సరిపోలిన ఒక చెక్‌సమ్‌ను చూపించింది.

హుర్రే! చివరి చిక్కుముడి కూడా విప్పబడింది, ఇప్పుడు నేను నా స్వంత ఫర్మ్‌వేర్‌ను సృష్టించుకోవలసి వచ్చింది. ఆ తర్వాత, నా తలలో మాత్రమే మిగిలిపోయిన నా జ్ఞానాన్ని, పైథాన్ అనే శక్తివంతమైన టూల్‌కిట్‌తో పరిచయం ఉన్న ఇల్యాకు అందించాను.

ప్రోగ్రామ్‌ను సృష్టించడం

ఇల్యా అలేశిన్ ఈ కథను చెబుతున్నారు.

సంబంధిత సూచనలు అందుకున్న తర్వాత, నేను చాలా సంతోషించాను.

ఎక్కడ మొదలు పెట్టాలి? అవును, మొదటి నుంచే.  USB పోర్ట్‌ను తొలగించడం ద్వారా.

USB-pcapను ప్రారంభించండి https://desowin.org/usbpcap/tour.html

పరికరం కనెక్ట్ చేయబడిన పోర్ట్‌ను మరియు మనం డంప్‌ను సేవ్ చేసే ఫైల్‌ను ఎంచుకోండి.

విండోస్ కోసం స్థానిక EZConfigScanning సాఫ్ట్‌వేర్ ఇన్‌స్టాల్ చేయబడిన మెషీన్‌కు మేము స్కానర్‌ను కనెక్ట్ చేస్తాము.

అక్కడ పరికరానికి ఆదేశాలు పంపే ఎంపిక మనకు కనిపిస్తుంది. కానీ ఆ ఆదేశాల సంగతేంటి? వాటిని నేను ఎక్కడ పొందగలను?
ప్రోగ్రామ్ ప్రారంభమైనప్పుడు, పరికరం స్వయంచాలకంగా ప్రశ్నించబడుతుంది (దీనిని మనం కొద్దిసేపటి తర్వాత చూస్తాము). పరికరం యొక్క అధికారిక డాక్యుమెంటేషన్ నుండి శిక్షణ బార్‌కోడ్‌లు కూడా ఉన్నాయి. DEFALT. ఇది మా బృందం.

అవసరమైన డేటా సేకరించబడింది. Wireshark ఉపయోగించి dump.pcapను తెరవండి.

EZConfigScanning ప్రారంభమైనప్పుడు నిరోధించండి. శ్రద్ధ అవసరమైన ప్రాంతాలు ఎరుపు రంగులో హైలైట్ చేయబడతాయి.

ఇదంతా మొదటిసారి చూసి నాకు నిరుత్సాహం కలిగింది. తర్వాత ఎక్కడ తవ్వాలో స్పష్టంగా అర్థం కాలేదు.

కొంచెం ఆలోచించగా... ఆహా! చెత్తకుప్పలో బయటకు - ఉంది inమరియు in ఇది బయటకు.

నేను URB_INTERRUPT గురించి గూగుల్‌లో వెతకగా, అది ఒక డేటా బదిలీ పద్ధతి అని తెలిసింది. ఈ పద్ధతులలో నాలుగు ఉన్నాయి: కంట్రోల్, ఇంటరప్ట్, ఐసోక్రోనస్ మరియు బల్క్. మీరు వాటి గురించి విడివిడిగా చదువుకోవచ్చు.

మరియు 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 లైన్లు లభిస్తాయి, ఫర్మ్‌వేర్ ఫైల్‌ను ఒక్కో అక్షరాన్ని చదువుతూ బ్లాక్‌ను ఏర్పరుస్తాము. ఆ బ్లాక్‌లో 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 ఫ్లాషింగ్ మోడ్‌లో హెక్స్‌ను అంగీకరించదు. కాబట్టి, మీరు 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