Sema kila mtu
Sisi, Victor Antipov na Ilya Aleshin, leo tutazungumza kuhusu uzoefu wetu wa kufanya kazi na vifaa vya USB kupitia Python PyUSB na kidogo kuhusu uhandisi wa reverse.
kabla ya historia
Mnamo mwaka wa 2019, Agizo la Serikali ya Shirikisho la Urusi No. 224 "Kwa idhini ya Sheria za kuweka lebo ya bidhaa za tumbaku na njia za utambulisho na sifa za utekelezaji wa mfumo wa habari wa serikali kwa ufuatiliaji wa mzunguko wa bidhaa chini ya uwekaji lebo ya lazima kwa njia za kitambulisho. kuhusiana na bidhaa za tumbakuβ ilianza kutumika.
Hati hiyo inaeleza kuwa kuanzia Julai 1, 2019, watengenezaji wanatakiwa kuweka lebo kila pakiti ya tumbaku. Na wasambazaji wa moja kwa moja lazima wapokee bidhaa hizi kwa utekelezaji wa hati ya uhamishaji wa ulimwengu wote (UDD). Maduka, kwa upande wake, yanahitaji kusajili uuzaji wa bidhaa zilizo na lebo kupitia rejista ya fedha.
Pia, kuanzia Julai 1, 2020, mzunguko wa bidhaa za tumbaku zisizo na lebo ni marufuku. Hii ina maana kwamba pakiti zote za sigara lazima ziweke alama kwa msimbo maalum wa Datamatrix. Aidha - hatua muhimu - ikawa kwamba Datamatrix haitakuwa ya kawaida, lakini inverse. Hiyo ni, sio nambari nyeusi kwenye nyeupe, lakini kinyume chake.
Tulijaribu vichanganuzi vyetu, na ikawa kwamba vingi vinahitaji kuonyeshwa upya/kufundishwa upya, vinginevyo haviwezi kufanya kazi kwa kawaida na msimbopau huu. Zamu hii ya matukio ilituhakikishia maumivu makali ya kichwa, kwa sababu kampuni yetu ina maduka mengi ambayo yametawanyika katika eneo kubwa. Makumi kadhaa ya maelfu ya rejista za pesa - na wakati mdogo sana.
Nini kilipaswa kufanywa? Kuna chaguzi mbili. Kwanza: wahandisi walio kwenye tovuti huangaza upya na kurekebisha vichanganuzi. Pili: tunafanya kazi kwa mbali na, ikiwezekana, hufunika skana nyingi mara moja kwa kurudia mara moja.
Chaguo la kwanza, kwa wazi, halikuwafaa kwetu: tutalazimika kutumia pesa kwa wahandisi wa kutembelea, na katika kesi hii itakuwa ngumu kudhibiti na kuratibu mchakato. Lakini jambo la muhimu zaidi ni kwamba watu wangefanya kazi, yaani, tunaweza kupata makosa mengi na, uwezekano mkubwa, tusifikie tarehe ya mwisho.
Chaguo la pili ni nzuri kwa kila mtu, ikiwa sio kwa jambo moja. Wachuuzi wengine hawakuwa na zana za kuangaza za mbali tulizohitaji kwa mifumo yote ya uendeshaji inayohitajika. Na kwa kuwa tarehe za mwisho zilikuwa zikiisha, ilibidi nifikirie kwa kichwa changu mwenyewe.
Kisha, tutakuambia jinsi tulivyotengeneza zana za vichanganuzi vinavyoshikiliwa kwa mkono vya Debian 9.x OS (rejista zetu zote za pesa ziko kwenye Debian).
Tatua kitendawili: jinsi ya kuangaza kichanganuzi
Victor Antipov anaripoti.
Huduma rasmi iliyotolewa na muuzaji inafanya kazi chini ya Windows, na tu na IE. Huduma inaweza kuwaka na kusanidi kichanganuzi.
Kwa kuwa mfumo wetu tunaolenga ni Debian, tulisakinisha seva ya kielekeza upya usb kwenye Debian na mteja wa kielekeza upya usb kwenye Windows. Kwa kutumia huduma za usb-redirector, tulisambaza kichanganuzi kutoka kwa mashine ya Linux hadi kwa mashine ya Windows.
Huduma kutoka kwa muuzaji wa Windows iliona skana na hata kuiwasha kawaida. Kwa hivyo, tulifanya hitimisho la kwanza: hakuna kitu kinategemea OS, ni suala la itifaki inayowaka.
SAWA. Tuliendesha mwako kwenye mashine ya Windows, na tukaondoa dampo kwenye mashine ya Linux.
Tulijaza dampo kwenye WireShark na... tukahuzunika (nitaacha baadhi ya maelezo ya dampo, hayana maslahi yoyote).
Kile dampo lilituonyesha:
Anwani 0000-0030, kwa kuzingatia Wireshark, ni maelezo ya huduma ya USB.
Tulipendezwa na sehemu 0040-0070.
Hakuna kilichokuwa wazi kutoka kwa fremu moja ya usambazaji isipokuwa kwa herufi za MOCFT. Wahusika hawa waligeuka kuwa wahusika kutoka kwa faili ya firmware, pamoja na wahusika waliobaki hadi mwisho wa sura (faili ya firmware imeangaziwa):
Nini alama fd 3e 02 01 fe zilimaanisha, mimi binafsi, kama Ilya, sikujua.
Niliangalia sura ifuatayo (habari ya huduma imeondolewa hapa, faili ya firmware imeangaziwa):
Ni nini kilidhihirika? Kwamba ka mbili za kwanza ni aina fulani ya mara kwa mara. Vitalu vyote vilivyofuata vilithibitisha hili, lakini kabla ya mwisho wa kizuizi cha maambukizi:
Sura hii pia ilikuwa ya kustaajabisha, kwani mara kwa mara ilikuwa imebadilika (iliyoangaziwa) na, isiyo ya kawaida, kulikuwa na sehemu ya faili. Saizi ya baiti zilizohamishwa za faili zilionyesha kuwa baiti 1024 zilihamishwa. Sikujua tena kaiti zilizobaki zilimaanisha nini.
Kwanza kabisa, kama jina la utani la zamani la BBS, nilikagua itifaki za kawaida za upitishaji. Hakuna itifaki iliyopitishwa baiti 1024. Nilianza kusoma vifaa na nikapata itifaki ya 1K Xmodem. Iliruhusu kusambaza 1024, lakini kwa tahadhari: mwanzoni tu 128, na tu ikiwa hapakuwa na makosa, itifaki iliongeza idadi ya byte zilizopitishwa. Mara moja nilikuwa na uhamisho wa ka 1024. Niliamua kusoma itifaki za maambukizi, na haswa X-modemu.
Kulikuwa na tofauti mbili za modem.
Kwanza, umbizo la kifurushi cha XMODEM na usaidizi wa CRC8 (XMODEM asilia):
Pili, umbizo la pakiti ya XMODEM yenye usaidizi wa CRC16 (XmodemCRC):
Inaonekana sawa, isipokuwa SOH, nambari ya kifurushi na CRC na urefu wa kifurushi.
Niliangalia mwanzo wa kizuizi cha pili cha maambukizi (na tena nikaona faili ya firmware, lakini tayari imeingizwa na ka 1024):
Niliona kichwa kinachojulikana fd 3e 02, lakini byte mbili zilizofuata zilikuwa tayari zimebadilika: ilikuwa 01 fe, na ikawa 02 fd. Kisha niliona kwamba block ya pili sasa ilikuwa namba 02 na hivyo kueleweka: mbele yangu ilikuwa hesabu ya kuzuia maambukizi. Gia ya kwanza ya 1024 ni 01, ya pili ni 02, ya tatu ni 03 na kadhalika (lakini kwa hex, bila shaka). Lakini mabadiliko kutoka fe hadi FD yanamaanisha nini? Macho yaliona kupungua kwa 1, ubongo ulikumbusha kwamba waandaaji wa programu wanahesabu kutoka 0, si 1. Lakini basi kwa nini ni block ya kwanza 1, na si 0? Bado sijapata jibu la swali hili. Lakini nilielewa jinsi kizuizi cha pili kinahesabiwa. Kizuizi cha pili sio zaidi ya FF - (minus) nambari ya kizuizi cha kwanza. Kwa hivyo, block ya pili iliteuliwa kama = 02 (FF-02) = 02 FD. Usomaji uliofuata wa dampo ulithibitisha nadhani yangu.
Kisha picha ifuatayo ya maambukizi ilianza kujitokeza:
Kuanza kwa maambukizi
fd 3e 02 - Anza
01 FE - kidhibiti cha maambukizi
Uhamisho (vitalu 34, baiti 1024 zimehamishwa)
fd 3e 1024 bytes ya data (imegawanywa katika vitalu 30 vya byte).
Mwisho wa maambukizi
fd 25
Data iliyosalia kupangiliwa kwa baiti 1024.
Muundo wa mwisho wa usambazaji wa block unaonekanaje:
fd 25 - ishara ya kukomesha maambukizi ya kuzuia. 2f 52 inayofuata - faili iliyosalia hadi baiti 1024 kwa ukubwa. 2f 52, kwa kuzingatia itifaki, ni hundi ya 16-bit CRC.
Kwa ajili ya nyakati za zamani, nilifanya programu katika C ambayo ilivuta baiti 1024 kutoka kwa faili na kuhesabu CRC ya 16-bit. Uzinduzi wa programu ulionyesha kuwa hii sio CRC ya 16-bit. Stupor tena - kwa muda wa siku tatu. Wakati huu wote nilikuwa nikijaribu kuelewa inaweza kuwa nini, ikiwa sio hundi. Nilipokuwa nikisoma tovuti za lugha ya Kiingereza, niligundua kuwa X-modemu hutumia hesabu yake ya hundi - CRC-CCITT (XModem). Sikupata utekelezwaji wowote wa C wa hesabu hii, lakini nilipata tovuti ambayo ilihesabu hundi hii mtandaoni. Baada ya kuhamisha byte 1024 za faili yangu hadi kwenye ukurasa wa wavuti, tovuti ilinionyesha hundi inayolingana kabisa na hundi kutoka kwa faili.
Hooray! Kitendawili cha mwisho kilitatuliwa, sasa nilihitaji kutengeneza firmware yangu mwenyewe. Kisha, nilipitisha ujuzi wangu (na ulibakia tu kichwani) kwa Ilya, ambaye anafahamu zana yenye nguvu ya Python.
Kuunda programu
Ilya Aleshin anaripoti.
Baada ya kupokea maagizo yanayofaa, nilifurahi sana.
Wapi kuanza? Hiyo ni kweli, tangu mwanzo. ο Kutoka kuchukua dampo kutoka kwa lango la USB.
Fungua USB-pcap
Chagua bandari ambayo kifaa kimeunganishwa na faili ambapo tutahifadhi dampo.
Tunaunganisha kichanganuzi kwenye mashine ambapo programu asili ya EZConfigScanning ya Windows imesakinishwa.
Ndani yake tunapata kipengee cha kutuma amri kwa kifaa. Lakini vipi kuhusu timu? Ninaweza kuzipata wapi?
Wakati programu inapoanza, vifaa vinapigwa kura moja kwa moja (tutaona hii baadaye kidogo). Na kulikuwa na barcode za mafunzo kutoka kwa hati rasmi za vifaa. HALISI. Hii ni timu yetu.
Data muhimu imepokelewa. Fungua dump.pcap kupitia wireshark.
Zuia unapoanzisha EZConfigScanning. Maeneo unayohitaji kuzingatia yamewekwa alama nyekundu.
Kuona haya yote kwa mara ya kwanza, nilipoteza moyo. Haijulikani wazi wapi kuchimba ijayo.
Kujadiliana kidogo na-na-na... Aha! Katika dampo nje - Je, inNa in hii nje.
Nilitafuta URB_INTERRUPT ni nini. Niligundua kuwa hii ni njia ya kuhamisha data. Na kuna njia 4 kama hizo: kudhibiti, kukatiza, isochronous, wingi. Unaweza kusoma juu yao tofauti.
Na anwani za mwisho katika kiolesura cha kifaa cha USB zinaweza kupatikana ama kupitia amri ya "lsusb -v" au kutumia pyusb.
Sasa tunahitaji kupata vifaa vyote vilivyo na VID hii. Unaweza kutafuta hasa kwa VID:PID.
Inaonekana kama hii:
Kwa hivyo, tunayo habari muhimu: amri za P_INFO. au DEFALT, anwani mahali pa kuandika amri endpoint=03 na mahali pa kupata majibu endpoint=86. Kinachobaki ni kubadilisha amri kuwa hex.
Kwa kuwa tayari tumepata kifaa, hebu tukitenganishe kutoka kwa kernel...
...na uandike hadi mwisho na anwani 0x03,
... na kisha usome jibu kutoka kwa mwisho na anwani 0x86.
Jibu lenye muundo:
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: 0x6986Tunaona data hii katika dump.pcap.
Kubwa! Badilisha misimbopau ya mfumo kuwa hex. Hiyo ndiyo yote, utendaji wa mafunzo uko tayari.
Vipi kuhusu firmware? Kila kitu kinaonekana kuwa sawa, lakini kuna nuance.
Baada ya kuchukua hatua kamili ya mchakato wa kuangaza, tulielewa kwa ufupi tulichokuwa tunashughulikia. Hapa kuna nakala kuhusu XMODEM, ambayo ilisaidia sana kuelewa jinsi mawasiliano haya yanavyotokea, ingawa kwa jumla: Ninapendekeza kuisoma.
Ukiangalia dampo, unaweza kuona kwamba saizi ya fremu ni 1024, na saizi ya data ya URB ni 64.
Kwa hivyo - 1024/64 - tunapata mistari 16 kwenye kizuizi, soma faili ya firmware herufi 1 kwa wakati mmoja na kuunda kizuizi. Inakamilisha mstari 1 kwenye kizuizi chenye herufi maalum fd3e02 + nambari ya kizuizi.
Laini 14 zinazofuata zinaongezewa fd25 +, kwa kutumia XMODEM.calc_crc() tunahesabu hundi ya block nzima (ilichukua muda mrefu kuelewa kwamba "FF - 1" ni CSUM) na ya mwisho, ya 16 inaongezewa. pamoja na fd3e.
Inaweza kuonekana kuwa hivyo, soma faili ya firmware, piga vizuizi, ukata skana kutoka kwa kernel na upeleke kwenye kifaa. Lakini si rahisi hivyo. Kichanganuzi kinahitaji kubadilishwa kwa hali ya firmware,
ΠΎΡΠΏΡΠ°Π²ΠΈΠ² Π΅ΠΌΡ NEWAPP = β\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0dβ.
Hii timu inatoka wapi?? Kutoka kwenye dampo.
Lakini hatuwezi kutuma kizuizi kizima kwa kichanganuzi kwa sababu ya kikomo cha 64:
Kweli, kichanganuzi katika modi ya NEWAPP inayomulika haikubali hex. Kwa hivyo, itabidi utafsiri kila mstari 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]Na kisha tuma data hii kwa skana.
Tunapata jibu:
[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]Ukiangalia makala kuhusu XMODEM, itakuwa wazi: data imekubaliwa.
Baada ya vizuizi vyote kuhamishwa, tunakamilisha uhamishaji END_TRANSFER = 'xfdx01x04'.
Naam, kwa kuwa vitalu hivi havibeba taarifa yoyote kwa watu wa kawaida, tutaweka firmware katika hali ya siri kwa default. Na ikiwezekana, tutapanga upau wa maendeleo kupitia tqdm.
Kwa kweli, basi ni suala la vitu vidogo. Kilichobaki ni kufunga suluhisho katika hati za kurudiwa kwa wingi kwa wakati uliowekwa wazi, ili usipunguze mchakato wa kufanya kazi kwenye malipo, na kuongeza ukataji miti.
Jumla ya
Baada ya kutumia muda mwingi na jitihada na nywele juu ya vichwa vyetu, tuliweza kuendeleza ufumbuzi tuliohitaji, na pia tulikutana na tarehe ya mwisho. Wakati huo huo, skana sasa zimerejeshwa na kufunzwa tena katikati, tunadhibiti kwa uwazi mchakato mzima. Kampuni iliokoa muda na pesa, na tulipata uzoefu wa thamani sana katika vifaa vya uhandisi vya reverse vya aina hii.
Chanzo: mapenzi.com