વિકાસકર્તા માટેનું કાર્ય, અથવા અમે વિક્રેતા વિના હાથથી પકડેલા સ્કેનરને કેવી રીતે ફ્લેશ કર્યું

બધા ને નમસ્કાર.

અમે, વિક્ટર એન્ટિપોવ અને ઇલ્યા એલેશિન, આજે Python PyUSB દ્વારા USB ઉપકરણો સાથે કામ કરવાના અમારા અનુભવ વિશે અને રિવર્સ એન્જિનિયરિંગ વિશે થોડી વાત કરીશું.

પ્રાગૈતિહાસિક

2019 માં, રશિયન ફેડરેશન નંબર 224 ની સરકારનો હુકમનામું “ઓળખના માધ્યમો સાથે ફરજિયાત લેબલિંગને આધિન માલના પરિભ્રમણ પર દેખરેખ રાખવા માટે રાજ્ય માહિતી પ્રણાલીના અમલીકરણની ઓળખના માધ્યમો અને લક્ષણો સાથે તમાકુ ઉત્પાદનોને લેબલ કરવા માટેના નિયમોની મંજૂરી પર તમાકુ ઉત્પાદનોના સંબંધમાં" અમલમાં આવ્યું.
દસ્તાવેજ સમજાવે છે કે જુલાઈ 1, 2019 થી, ઉત્પાદકોએ તમાકુના દરેક પેકને લેબલ કરવું જરૂરી છે. અને પ્રત્યક્ષ વિતરકોએ સાર્વત્રિક ટ્રાન્સફર દસ્તાવેજ (UDD) ના અમલ સાથે આ ઉત્પાદનો પ્રાપ્ત કરવા આવશ્યક છે. સ્ટોર્સ, બદલામાં, રોકડ રજિસ્ટર દ્વારા લેબલવાળા ઉત્પાદનોના વેચાણની નોંધણી કરવાની જરૂર છે.

ઉપરાંત, 1 જુલાઈ, 2020 થી, લેબલ વગરના તમાકુ ઉત્પાદનોના પરિભ્રમણ પર પ્રતિબંધ છે. આનો અર્થ એ છે કે તમામ સિગારેટના પેક ખાસ ડેટામેટ્રિક્સ બારકોડથી ચિહ્નિત હોવા જોઈએ. તદુપરાંત - એક મહત્વપૂર્ણ મુદ્દો - તે બહાર આવ્યું કે ડેટામેટ્રિક્સ સામાન્ય નહીં, પરંતુ વ્યસ્ત હશે. એટલે કે, સફેદ પર કાળો કોડ નહીં, પરંતુ ઊલટું.

અમે અમારા સ્કેનર્સનું પરીક્ષણ કર્યું, અને તે બહાર આવ્યું કે તેમાંના મોટા ભાગનાને રિફ્લેશ/ફરીથી પ્રશિક્ષિત કરવાની જરૂર છે, અન્યથા તેઓ આ બારકોડ સાથે સામાન્ય રીતે કામ કરી શકતા નથી. ઘટનાઓનો આ વળાંક અમને ગંભીર માથાનો દુખાવોની ખાતરી આપે છે, કારણ કે અમારી કંપની પાસે ઘણા બધા સ્ટોર્સ છે જે વિશાળ પ્રદેશમાં પથરાયેલા છે. હજારો રોકડ રજિસ્ટર - અને ખૂબ જ ઓછો સમય.

શું કરવાનું હતું? બે વિકલ્પો છે. પ્રથમ: ઓન-સાઇટ એન્જિનિયરો મેન્યુઅલી રીફ્લેશ કરે છે અને સ્કેનરને સમાયોજિત કરે છે. બીજું: અમે રિમોટલી કામ કરીએ છીએ અને પ્રાધાન્યમાં, એક જ વારમાં ઘણા સ્કેનર્સને આવરી લઈએ છીએ.

પ્રથમ વિકલ્પ, દેખીતી રીતે, અમારા માટે યોગ્ય ન હતો: અમારે મુલાકાત લેનાર એન્જિનિયરો પર નાણાં ખર્ચવા પડશે, અને આ કિસ્સામાં પ્રક્રિયાને નિયંત્રિત અને સંકલન કરવું મુશ્કેલ બનશે. પરંતુ સૌથી મહત્વની બાબત એ છે કે લોકો કામ કરશે, એટલે કે, અમને સંભવિતપણે ઘણી બધી ભૂલો મળશે અને, સંભવતઃ, સમયમર્યાદા પૂરી નહીં થાય.

બીજો વિકલ્પ દરેક માટે સારો છે, જો એક વસ્તુ માટે નહીં. કેટલાક વિક્રેતાઓ પાસે તમામ જરૂરી ઓપરેટિંગ સિસ્ટમ્સ માટે જરૂરી રિમોટ ફ્લેશિંગ ટૂલ્સ નથી. અને સમયમર્યાદા પૂરી થઈ રહી હોવાથી, મારે મારા પોતાના માથા સાથે વિચારવું પડ્યું.

આગળ, અમે તમને કહીશું કે અમે ડેબિયન 9.x ​​OS (અમારા તમામ રોકડ રજિસ્ટર ડેબિયન પર છે) માટે હેન્ડ-હેલ્ડ સ્કેનર્સ માટે સાધનો કેવી રીતે વિકસાવ્યા.

કોયડો ઉકેલો: સ્કેનર કેવી રીતે ફ્લેશ કરવું

વિક્ટર એન્ટિપોવ અહેવાલ આપે છે.

વિક્રેતા દ્વારા પૂરી પાડવામાં આવેલ સત્તાવાર ઉપયોગિતા Windows હેઠળ અને માત્ર IE સાથે કામ કરે છે. ઉપયોગિતા સ્કેનરને ફ્લેશ અને ગોઠવી શકે છે.

અમારી લક્ષ્ય સિસ્ટમ ડેબિયન હોવાથી, અમે ડેબિયન પર યુએસબી-રીડાયરેક્ટર સર્વર અને વિન્ડોઝ પર યુએસબી-રીડાયરેક્ટર ક્લાયંટ ઇન્સ્ટોલ કર્યું છે. usb-redirector ઉપયોગિતાઓનો ઉપયોગ કરીને, અમે સ્કેનરને Linux મશીનમાંથી Windows મશીન પર ફોરવર્ડ કર્યું.

વિન્ડોઝ વિક્રેતાની ઉપયોગિતાએ સ્કેનર જોયું અને તેને સામાન્ય રીતે ફ્લેશ પણ કર્યું. આમ, અમે પ્રથમ નિષ્કર્ષ કાઢ્યો: OS પર કંઈપણ નિર્ભર નથી, તે ફ્લેશિંગ પ્રોટોકોલની બાબત છે.

બરાબર. અમે Windows મશીન પર ફ્લેશિંગ ચલાવ્યું, અને Linux મશીન પરનો ડમ્પ દૂર કર્યો.

અમે ડમ્પને વાયરશાર્કમાં સ્ટફ કર્યો અને... દુઃખી થઈ ગયા (હું ડમ્પની કેટલીક વિગતો છોડીશ, તેમાં કોઈ રસ નથી).

ડમ્પ અમને શું બતાવ્યું:

એડ્રેસ 0000-0030, વાયરશાર્ક દ્વારા નક્કી કરવામાં આવે છે, યુએસબી સેવા માહિતી છે.

અમને ભાગ 0040-0070 માં રસ હતો.

MOCFT અક્ષરો સિવાય એક ટ્રાન્સમિશન ફ્રેમમાંથી કંઈ સ્પષ્ટ ન હતું. આ અક્ષરો ફર્મવેર ફાઇલમાંથી અક્ષરો હોવાનું બહાર આવ્યું છે, તેમજ ફ્રેમના અંત સુધી બાકીના અક્ષરો (ફર્મવેર ફાઇલ પ્રકાશિત થયેલ છે):

fd 3e 02 01 fe પ્રતીકોનો અર્થ શું છે, મને અંગત રીતે, ઇલ્યાની જેમ, કોઈ ખ્યાલ નહોતો.

મેં નીચેની ફ્રેમ પર જોયું (સેવા માહિતી અહીં દૂર કરવામાં આવી છે, ફર્મવેર ફાઇલ પ્રકાશિત કરવામાં આવી છે):

શું સ્પષ્ટ થયું? કે પ્રથમ બે બાઇટ્સ અમુક પ્રકારના સ્થિર છે. બધા અનુગામી બ્લોક્સે આની પુષ્ટિ કરી, પરંતુ ટ્રાન્સમિશન બ્લોકના અંત પહેલા:

આ ફ્રેમ પણ મૂંઝવતી હતી, કારણ કે સતત બદલાઈ ગયો હતો (હાઈલાઈટ) અને, વિચિત્ર રીતે, ફાઇલનો એક ભાગ હતો. ફાઇલના સ્થાનાંતરિત બાઇટ્સનું કદ દર્શાવે છે કે 1024 બાઇટ ટ્રાન્સફર કરવામાં આવી હતી. મને ફરીથી ખબર ન હતી કે બાકીના બાઇટ્સનો અર્થ શું છે.

સૌ પ્રથમ, જૂના BBS ઉપનામ તરીકે, મેં માનક ટ્રાન્સમિશન પ્રોટોકોલ્સની સમીક્ષા કરી. કોઈ પ્રોટોકોલ 1024 બાઇટ્સ ટ્રાન્સમિટ નથી. મેં હાર્ડવેરનો અભ્યાસ કરવાનું શરૂ કર્યું અને 1K Xmodem પ્રોટોકોલ પર આવ્યો. તે 1024 ટ્રાન્સમિટ કરવાની મંજૂરી આપે છે, પરંતુ ચેતવણી સાથે: શરૂઆતમાં ફક્ત 128, અને જો ત્યાં કોઈ ભૂલો ન હોય તો જ, પ્રોટોકોલે પ્રસારિત બાઈટની સંખ્યામાં વધારો કર્યો. મારી પાસે તરત જ 1024 બાઇટ્સનું ટ્રાન્સફર હતું. મેં ટ્રાન્સમિશન પ્રોટોકોલ્સ અને ખાસ કરીને એક્સ-મોડેમનો અભ્યાસ કરવાનું નક્કી કર્યું.

મોડેમની બે ભિન્નતા હતી.

પ્રથમ, CRC8 સપોર્ટ સાથે XMODEM પેકેજ ફોર્મેટ (મૂળ XMODEM):

બીજું, CRC16 સપોર્ટ સાથે XMODEM પેકેટ ફોર્મેટ (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 બાઇટ્સ ખેંચે છે અને 16-બીટ સીઆરસીની ગણતરી કરે છે. પ્રોગ્રામ લોન્ચ કરીને બતાવ્યું કે આ 16-બીટ સીઆરસી નથી. ફરીથી મૂર્ખ - લગભગ ત્રણ દિવસ માટે. આ બધો સમય હું એ સમજવાનો પ્રયત્ન કરી રહ્યો હતો કે ચેકસમ નહીં તો શું હોઈ શકે. અંગ્રેજી-ભાષાની સાઇટ્સનો અભ્યાસ કરતી વખતે, મેં શોધ્યું કે એક્સ-મોડેમ તેની પોતાની ચેકસમ ગણતરીનો ઉપયોગ કરે છે - CRC-CCITT (XModem). મને આ ગણતરીના કોઈપણ C અમલીકરણ મળ્યા નથી, પરંતુ મને એક સાઇટ મળી છે જેણે આ ચેકસમની ઓનલાઇન ગણતરી કરી હતી. મારી ફાઇલના 1024 બાઇટ્સ વેબ પૃષ્ઠ પર સ્થાનાંતરિત કર્યા પછી, સાઇટે મને એક ચેકસમ બતાવ્યું જે ફાઇલમાંથી ચેકસમ સાથે સંપૂર્ણપણે મેળ ખાતું હતું.

હુરે! છેલ્લી કોયડો ઉકેલાઈ ગઈ હતી, હવે મારે મારું પોતાનું ફર્મવેર બનાવવાની જરૂર છે. આગળ, મેં મારું જ્ઞાન (અને તે ફક્ત મારા મગજમાં જ રહ્યું) ઇલ્યાને આપ્યું, જે શક્તિશાળી ટૂલકીટ પાયથોનથી પરિચિત છે.

એક કાર્યક્રમ બનાવી રહ્યા છે

ઇલ્યા એલેશિન અહેવાલ આપે છે.

યોગ્ય સૂચનાઓ મળ્યા પછી, હું ખૂબ જ “ખુશ” હતો.

ક્યાંથી શરૂઆત કરવી? તે સાચું છે, શરૂઆતથી.  યુએસબી પોર્ટમાંથી ડમ્પ લેવાથી.

USB-pcap લોંચ કરો https://desowin.org/usbpcap/tour.html

તે પોર્ટ પસંદ કરો કે જેમાં ઉપકરણ જોડાયેલ છે અને તે ફાઇલ જ્યાં આપણે ડમ્પને સાચવીશું.

અમે સ્કેનરને મશીન સાથે જોડીએ છીએ જ્યાં Windows માટે મૂળ EZConfigScanning સોફ્ટવેર ઇન્સ્ટોલ કરેલું છે.

તેમાં આપણે ઉપકરણને આદેશો મોકલવા માટેની આઇટમ શોધીએ છીએ. પરંતુ ટીમો વિશે શું? હું તેમને ક્યાંથી મેળવી શકું?
જ્યારે પ્રોગ્રામ શરૂ થાય છે, ત્યારે સાધનો આપમેળે મતદાન થાય છે (આપણે થોડી વાર પછી જોઈશું). અને સત્તાવાર સાધનોના દસ્તાવેજોમાંથી તાલીમ બારકોડ હતા. DEFALT. આ અમારી ટીમ છે.

જરૂરી ડેટા પ્રાપ્ત થયો છે. wireshark દ્વારા dump.pcap ખોલો.

EZConfigScanning શરૂ કરતી વખતે અવરોધિત કરો. તમારે જે સ્થાનો પર ધ્યાન આપવાની જરૂર છે તે લાલ રંગમાં ચિહ્નિત થયેલ છે.

આ બધું પહેલીવાર જોઈને હું હ્રદય ગુમાવી બેઠો. આગળ ક્યાં ખોદવું તે સ્પષ્ટ નથી.

થોડું મંથન અને-અને-અને... અહા! ડમ્પમાં બહાર - છે inઅને in તે બહાર.

મેં ગૂગલ કર્યું કે URB_INTERRUPT શું છે. મને જાણવા મળ્યું કે આ એક ડેટા ટ્રાન્સફર પદ્ધતિ છે. અને આવી 4 પદ્ધતિઓ છે: નિયંત્રણ, વિક્ષેપ, આઇસોક્રોનસ, બલ્ક. તમે તેમના વિશે અલગથી વાંચી શકો છો.

અને USB ઉપકરણ ઈન્ટરફેસમાં એન્ડપોઈન્ટ એડ્રેસ ક્યાં તો “lsusb –v” આદેશ દ્વારા અથવા pyusb નો ઉપયોગ કરીને મેળવી શકાય છે.

હવે આપણે આ VID સાથેના તમામ ઉપકરણો શોધવાની જરૂર છે. તમે ખાસ કરીને VID:PID દ્વારા શોધી શકો છો.

તે આના જેવું દેખાય છે:

તેથી, અમારી પાસે જરૂરી માહિતી છે: P_INFO આદેશો. અથવા DEFALT, આદેશો ક્યાં લખવા તે સરનામાં endpoint=03 અને જવાબ ક્યાંથી મેળવવો endpoint=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 લીટીઓ મળે છે, ફર્મવેર ફાઇલને એક સમયે 1 અક્ષર વાંચો અને એક બ્લોક બનાવો. ખાસ અક્ષરો fd1e3 + બ્લોક નંબર સાથે બ્લોકમાં 02 લીટીને પૂરક બનાવવી.
આગળની 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