ဆော့ဖ်ဝဲရေးသားသူအတွက် အလုပ်တစ်ခု သို့မဟုတ် ရောင်းချသူမပါဘဲ လက်ကိုင်စကင်နာများကို ကျွန်ုပ်တို့ မည်သို့အလင်းပြမည်နည်း။

ဟယ်လို။

ကျွန်ုပ်တို့၊ Viktor Antipov နှင့် Ilya Aleshin တို့သည် Python PyUSB မှတစ်ဆင့် USB စက်ပစ္စည်းများနှင့် လုပ်ဆောင်သည့် အတွေ့အကြုံနှင့် reverse engineering အကြောင်း အနည်းငယ်ကို ယနေ့ ဆွေးနွေးပါမည်။

စောပိုငျးကာလ

2019 ခုနှစ်တွင်၊ ရုရှားဖက်ဒရေးရှင်းအစိုးရ၏အမိန့်အမှတ် 224 တွင် “သတ်မှတ်ခြင်းနည်းလမ်းများနှင့် ကုန်ပစ္စည်းများ လည်ပတ်မှုစောင့်ကြည့်ခြင်းဆိုင်ရာ နိုင်ငံတော်သတင်းအချက်အလက်စနစ် အကောင်အထည်ဖော်မှု၏ လက္ခဏာရပ်များဖြင့် တံဆိပ်ကပ်ခြင်းဆိုင်ရာ စည်းမျဉ်းများ အတည်ပြုချက်အရ၊ “ဆေးရွက်ကြီးထွက်ကုန်များနှင့် စပ်လျဉ်း၍ အသက်ဝင်သည်။
1 ခုနှစ် ဇူလိုင်လ 2019 ရက်နေ့မှစတင်၍ ထုတ်လုပ်သူသည် ဆေးရွက်ကြီးတစ်ထုပ်စီကို တံဆိပ်တပ်ရန် လိုအပ်ကြောင်း စာတမ်းတွင် ရှင်းပြထားသည်။ နှင့် တိုက်ရိုက်ဖြန့်ဖြူးသူများသည် universal transfer document (UDD) ကို အကောင်အထည်ဖော်ခြင်းဖြင့် ဤထုတ်ကုန်များကို လက်ခံရမည်ဖြစ်သည်။ စတိုးဆိုင်များသည် ငွေသားစာရင်းမှတစ်ဆင့် တံဆိပ်တပ်ထားသော ကုန်ပစ္စည်းများရောင်းချခြင်းကို မှတ်ပုံတင်ရန် လိုအပ်ပါသည်။

ထို့အပြင်၊ 1 ခုနှစ် ဇူလိုင်လ 2020 ရက်နေ့မှစတင်၍ တံဆိပ်မကပ်ထားသော ဆေးရွက်ကြီးထွက်ကုန်များ ဖြန့်ဝေခြင်းကို တားမြစ်ထားသည်။ ဆိုလိုသည်မှာ စီးကရက်ဘူးများအားလုံးကို အထူး Datamatrix ဘားကုဒ်ဖြင့် အမှတ်အသားပြုရပါမည်။ ထို့အပြင် - အရေးကြီးသောအချက်မှာ Datamatrix သည် သာမန်မဟုတ်သော်လည်း ပြောင်းပြန်ဖြစ်သွားကြောင်း တွေ့ရှိရပါသည်။ ဆိုလိုသည်မှာ အဖြူပေါ်တွင် အနက်ရောင်ကုဒ်မဟုတ်သော်လည်း အပြန်အလှန်ဖြစ်သည်။

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏စကင်နာများကို စမ်းသပ်ခဲ့ပြီး အများစုမှာ ပြန်လည်ပြင်ဆင်ခြင်း/ပြန်လည်လေ့ကျင့်ရန် လိုအပ်ကြောင်း၊ သို့မဟုတ်ပါက ၎င်းတို့သည် ဤဘားကုဒ်ဖြင့် ပုံမှန်အလုပ်မလုပ်နိုင်တော့ကြောင်း တွေ့ရှိရပါသည်။ ကျွန်ုပ်တို့၏ကုမ္ပဏီသည် ကျယ်ပြောလှသောနယ်မြေတွင် ပြန့်ကျဲနေသော စတိုးဆိုင်များစွာရှိသောကြောင့် ဤအဖြစ်အပျက်များသည် ကျွန်ုပ်တို့အား ပြင်းထန်စွာ ခေါင်းကိုက်စေသည်ဟု အာမခံပါသည်။ သောင်းနှင့်ချီသော ငွေသားစာရင်းများ - နှင့် အချိန်အနည်းငယ်သာ။

ဘာဆက်လုပ်ရမလဲ။ ရွေးချယ်စရာနှစ်ခုရှိသည်။ ပထမအချက်- ဆိုက်တွင်းရှိ အင်ဂျင်နီယာများသည် စကင်နာများကို လက်ဖြင့် ပြန်လည်စတင်ပြီး ချိန်ညှိပေးသည်။ ဒုတိယ- ကျွန်ုပ်တို့သည် အဝေးမှ အလုပ်လုပ်ပြီး ပိုကောင်းသည်မှာ တစ်ကြိမ်တည်းတွင် စကင်နာများစွာကို တစ်ကြိမ်တည်း ကာမိပါသည်။

ပထမရွေးချယ်မှုမှာ ကျွန်ုပ်တို့အတွက် မသင့်လျော်သည်မှာ ထင်ရှားသည်- ကျွန်ုပ်တို့သည် လာရောက်လည်ပတ်သော အင်ဂျင်နီယာများအတွက် ငွေသုံးစွဲရမည်ဖြစ်ပြီး ဤအခြေအနေတွင် လုပ်ငန်းစဉ်ကို ထိန်းချုပ်ရန်နှင့် ညှိနှိုင်းရန် ခက်ခဲမည်ဖြစ်သည်။ ဒါပေမယ့် အရေးကြီးဆုံးကတော့ လူတွေက အလုပ်ဖြစ်မှာ၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် အမှားအယွင်းများစွာ ခံရနိုင်ချေရှိပြီး နောက်ဆုံးသတ်မှတ်ရက်ကို မပြည့်မီနိုင်ပါ။

ဒုတိယရွေးချယ်မှုသည် တစ်ခုတည်းအတွက်မဟုတ်ပါက လူတိုင်းအတွက်ကောင်းသည်။ အချို့သောရောင်းချသူများသည် လိုအပ်သောလည်ပတ်မှုစနစ်အားလုံးအတွက် ကျွန်ုပ်တို့လိုအပ်သော အဝေးမှ အလင်းပြန်ကိရိယာများ မရှိပါ။ ပြီးတော့ သတ်မှတ်ရက်တွေ ကုန်ဆုံးသွားတော့ ကိုယ့်ခေါင်းနဲ့ကိုယ် တွေးနေရတယ်။

ထို့နောက်၊ ကျွန်ုပ်တို့သည် Debian 9.x OS အတွက် လက်ကိုင်စကင်နာများအတွက် ကိရိယာများကို မည်သို့တီထွင်ခဲ့သည် (ကျွန်ုပ်တို့၏ ငွေသားစာရင်းအားလုံးကို Debian တွင်ရှိသည်) သင့်အား ပြောပြပါမည်။

ပဟေဠိကိုဖြေရှင်းပါ- စကင်နာကို ဖလက်ရှ်လုပ်နည်း

Victor Antipov က တင်ပြထားပါတယ်။

ရောင်းချသူမှပေးသောတရားဝင်အသုံးအဆောင်သည် Windows အောက်တွင်ရှိပြီး IE နှင့်သာအလုပ်လုပ်သည်။ utility သည် စကင်နာကို flash ပြီး configure လုပ်နိုင်သည်။

ကျွန်ုပ်တို့၏ပစ်မှတ်စနစ်သည် Debian ဖြစ်သောကြောင့်၊ ကျွန်ုပ်တို့သည် Debian တွင် usb-redirector ဆာဗာတစ်ခုနှင့် Windows တွင် usb-redirector client ကို ထည့်သွင်းထားသည်။ usb-redirector utilities ကို အသုံးပြု၍ scanner ကို Linux စက်မှ Windows စက်သို့ ပေးပို့ခဲ့သည်။

Windows ရောင်းချသူမှ အသုံးဝင်မှုတစ်ခုသည် စကင်နာကို မြင်ပြီး ပုံမှန်အတိုင်းပင် မီးတောက်နေပါသည်။ ထို့ကြောင့် ကျွန်ုပ်တို့ ပထမကောက်ချက်ချခဲ့သည်- OS ပေါ်တွင် ဘာမှမမူတည်ပါ၊ ၎င်းသည် flashing protocol ၏ကိစ္စဖြစ်သည်။

အိုကေတယ်နော်။ ကျွန်ုပ်တို့သည် Windows စက်ပေါ်တွင် မှိတ်တုတ်မှိတ်တုတ်မှိတ်တုတ်ပြခြင်းကို လုပ်ဆောင်ခဲ့ပြီး Linux စက်ရှိ အမှိုက်ပုံးကို ဖယ်ရှားခဲ့သည်။

အမှိုက်ပုံကြီးကို WireShark ထဲသို့ထည့်လိုက်သည်... စိတ်မကောင်းဖြစ်မိသည် (အမှိုက်ပုံ၏အသေးစိတ်အချက်အချို့ကို ကျွန်ုပ်ချန်လှပ်ထားလိုက်သည်၊ ၎င်းတို့သည် စိတ်ဝင်စားစရာမဟုတ်ပါ)။

အမှိုက်ပုံကြီးက ကျွန်ုပ်တို့ကို ပြထားသည်-

Wireshark မှ ဆုံးဖြတ်သော လိပ်စာများသည် 0000-0030 သည် USB ဝန်ဆောင်မှု အချက်အလက်ဖြစ်သည်။

အပိုင်း 0040-0070 ကို စိတ်ဝင်စားခဲ့ကြတယ်။

MOCFT ဇာတ်ကောင်များမှလွဲ၍ ထုတ်လွှင့်မှုဘောင်တစ်ခုမှ ဘာမှမရှင်းလင်းပါ။ ဤအက္ခရာများသည် ဖန်းဝဲလ်ဖိုင်မှ ဇာတ်ကောင်များအပြင် ဖရိန်အဆုံးအထိ ကျန်ရှိသော ဇာတ်ကောင်များအဖြစ် ပြောင်းလဲသွားသည် (ဖိုင်းဝဲဖိုင်ကို မီးမောင်းထိုးပြထားသည်)

fd 3e 02 01 fe သင်္ကေတတွေက ဘာကိုဆိုလိုလဲ၊ Ilya လိုမျိုး ပုဂ္ဂိုလ်ရေးအရတော့ မသိခဲ့ပါဘူး။

အောက်ပါဘောင်ကို ကြည့်လိုက်သည် (ဝန်ဆောင်မှုအချက်အလက်ကို ဤနေရာတွင် ဖယ်ရှားလိုက်သည်၊ ဖိုင်းဝဲဖိုင်ကို မီးမောင်းထိုးပြထားသည်)

ဘာတွေ ရှင်းသွားတာလဲ။ ပထမနှစ်ဘိုက်သည် ကိန်းသေတစ်မျိုးဖြစ်သည်။ နောက်ဆက်တွဲလုပ်ကွက်များအားလုံးက ၎င်းကိုအတည်ပြုသော်လည်း ထုတ်လွှင့်မှုပိတ်ဆို့ခြင်းမပြီးဆုံးမီ-

အဆက်မပြတ်ပြောင်းလဲသွားသည် (မီးမောင်းထိုးပြထားသည်) နှင့် ထူးဆန်းလောက်အောင်ပင်၊ ဖိုင်၏တစ်စိတ်တစ်ပိုင်းရှိသောကြောင့် ဤဘောင်သည် အံ့သြစရာဖြစ်ခဲ့သည်။ ဖိုင်၏ လွှဲပြောင်းထားသော ဘိုက်များ၏ အရွယ်အစားသည် 1024 bytes များကို လွှဲပြောင်းထားကြောင်း ပြသခဲ့သည်။ ကျန်ရှိသော ဘိုက်များ ဘာကိုဆိုလိုသည်ကို ကျွန်တော် မသိခဲ့ပြန်သည်။

ပထမဆုံးအနေနဲ့၊ BBS နာမည်ဟောင်းတစ်ခုအနေနဲ့၊ စံဂီယာပရိုတိုကောတွေကို ပြန်သုံးသပ်ခဲ့တယ်။ ပရိုတိုကော 1024 bytes ထုတ်လွှင့်ခြင်းမရှိပါ။ ဟာ့ဒ်ဝဲကို စတင်လေ့လာခဲ့ပြီး 1K Xmodem ပရိုတိုကောကို တွေ့ခဲ့ပါတယ်။ ၎င်းသည် 1024 ကိုထုတ်လွှင့်ခွင့်ပြုသော်လည်းသတိပေးချက်တစ်ခုအနေဖြင့်- ပထမတွင် 128 သာရှိပြီး အမှားအယွင်းများမရှိပါက၊ ပရိုတိုကောသည် ပို့လွှတ်သောဘိုက်အရေအတွက်ကို တိုးစေပါသည်။ ငါချက်ချင်း 1024 bytes လွှဲပြောင်းမှုရခဲ့တယ်။ ဂီယာပရိုတိုကောများနှင့် အထူးသဖြင့် X-modem ကိုလေ့လာရန် ဆုံးဖြတ်ခဲ့သည်။

မိုဒမ်၏ အမျိုးအစားနှစ်မျိုးရှိသည်။

ပထမ၊ CRC8 ပံ့ပိုးမှုဖြင့် XMODEM ပက်ကေ့ဂျ်ဖော်မတ် (မူရင်း XMODEM)။

ဒုတိယအနေဖြင့်၊ CRC16 ပံ့ပိုးမှု (XmodemCRC) ပါသော XMODEM ပက်ကတ်ဖော်မတ်။

SOH၊ ပက်ကေ့ဂျ်နံပါတ်နှင့် CRC နှင့် ပက်ကေ့ခ်ျအရှည်မှလွဲ၍ ၎င်းသည် ဆင်တူသည်။

ဒုတိယ ထုတ်လွှင့်မှု ပိတ်ဆို့ခြင်း၏အစကို ငါကြည့်ခဲ့သည် (ဖန်းဝဲဖိုင်ကို ထပ်မံတွေ့လိုက်ရသည်၊ သို့သော် 1024 bytes ဖြင့် ကည့်နေပြီ)။

ရင်းနှီးပြီးသား header fd 3e 02 ကိုတွေ့ခဲ့တယ်၊ ဒါပေမယ့် နောက်နှစ် bytes က ပြောင်းသွားပါပြီ- 01 fe ဖြစ်ပြီး 02 fd ဖြစ်သွားပါတယ်။ နောက်တော့ ဒုတိယဘလောက်ကို အခု နံပါတ် 02 လို့ သတိထားမိတော့ နားလည်သွားတယ်၊ ငါ့ရှေ့မှာ ဂီယာဘလောက်နံပါတ်ကို နံပါတ်တပ်ထားတယ်။ ပထမ 1024 ဂီယာ 01 ၊ ဒုတိယက 02 ၊ တတိယက 03 ဖြစ်သွားပြီ (ဒါပေမယ့် hex မှာတော့ ဟုတ်ပါတယ်)။ သို့သော် fe မှ fd သို့ပြောင်းလဲခြင်းဆိုသည်မှာ အဘယ်နည်း။ မျက်လုံးများက 1 ဖြင့် လျော့ကျသွားသည်ကို ဦးနှောက်က သတိပြုမိသည်၊ ပရိုဂရမ်မာများက 0 မှ 1 ကို မဟုတ်ဘဲ 1 မှ ရေတွက်ကြောင်း သတိပေးသည်။ သို့သော် ပထမ block 0 သည် အဘယ်ကြောင့် 02 မဟုတ်သနည်း။ ဒီမေးခွန်းရဲ့ အဖြေကို ကျွန်တော် အခုထိ မတွေ့သေးဘူး။ ဒါပေမယ့် ဒုတိယဘလောက်ကို ဘယ်လိုရေတွက်တယ်ဆိုတာ ကျွန်တော်နားလည်ပါတယ်။ ဒုတိယဘလောက်သည် ပထမဘလောက်၏နံပါတ် (အနုတ်) FF ထက်မပိုပါ။ ထို့ကြောင့် ဒုတိယဘလောက်ကို = 02 (FF-02) = XNUMX FD အဖြစ် သတ်မှတ်ခဲ့သည်။ အမှိုက်ပုံကြီး၏ နောက်ဆက်တွဲကို ဖတ်ရင်း ကျွန်ုပ်၏ ခန့်မှန်းချက်ကို အတည်ပြုခဲ့သည်။

ထို့နောက် ထုတ်လွှင့်မှု၏ အောက်ဖော်ပြပါပုံ ထွက်ပေါ်လာသည် ။

ဂီယာစတင်
fd 3e 02 – စတင်ပါ။
01 FE - ဂီယာကောင်တာ
လွှဲပြောင်းခြင်း (34 တုံး၊ 1024 bytes လွှဲပြောင်း)
fd 3e ဒေတာ 1024 bytes (30 byte blocks များ)။
ကူးစက်မှုအဆုံးသတ်
fd ၂၅

ကျန်ဒေတာကို 1024 bytes သို့ ချိန်ညှိရန်။

ဘလောက်ဂီယာအဆုံးဘောင်က ဘယ်လိုပုံစံလဲ-

fd 25 – ပိတ်ဆို့ထုတ်လွှင့်မှုကို အဆုံးသတ်ရန် အချက်ပြခြင်း။ နောက်တစ်ခု 2f 52 - ကျန်ဖိုင်၏အရွယ်အစားမှာ 1024 bytes အထိရှိသည်။ 2f 52 သည် ပရိုတိုကောကို အဆုံးအဖြတ်ပေးသော 16-bit CRC checksum ဖြစ်သည်။

ရှေးယခင်ကအတွက်၊ ဖိုင်တစ်ခုမှ 1024 bytes ကိုဆွဲထုတ်ပြီး 16-bit CRC ကို တွက်ချက်သည့် C တွင် ကျွန်တော်လုပ်ဆောင်ခဲ့သည်။ ပရိုဂရမ်ကို စတင်လိုက်သောအခါ ၎င်းသည် 16-bit CRC မဟုတ်ပါ။ မူးနောက်ပြန်သည် - သုံးရက်ခန့်။ ချက်ဆမ်မဟုတ်ရင် ဘာဖြစ်နိုင်မလဲဆိုတာ နားလည်ဖို့ ဒီအချိန်တိုင်း ကြိုးစားနေခဲ့တယ်။ အင်္ဂလိပ်ဘာသာ ဆိုက်များကို လေ့လာနေစဉ် X-modem သည် ၎င်း၏ကိုယ်ပိုင် checksum တွက်ချက်မှု - CRC-CCITT (XModem) ကို အသုံးပြုကြောင်း တွေ့ရှိခဲ့သည်။ ဤတွက်ချက်မှု၏ C အကောင်အထည်ဖော်မှုများကို ကျွန်ုပ်မတွေ့ခဲ့ပါ၊ သို့သော် ဤ checksum ကို အွန်လိုင်းတွင် တွက်ချက်သည့်ဆိုက်တစ်ခုကို ကျွန်ုပ်တွေ့ရှိခဲ့သည်။ ကျွန်ုပ်၏ဖိုင်၏ 1024 bytes ကို ဝဘ်စာမျက်နှာသို့ လွှဲပြောင်းပြီးနောက်၊ ဆိုက်သည် ကျွန်ုပ်အား ဖိုင်မှ checksum နှင့် လုံးဝကိုက်ညီသည့် checksum တစ်ခုကို ပြသခဲ့သည်။

ဟူး! နောက်ဆုံး ပဟေဠိကို ဖြေရှင်းပြီးပါပြီ၊ ယခု ကျွန်ုပ်သည် ကျွန်ုပ်၏ကိုယ်ပိုင် firmware ပြုလုပ်ရန် လိုအပ်နေပြီဖြစ်သည်။ ထို့နောက်တွင်၊ အစွမ်းထက်သောကိရိယာကိရိယာ Python နှင့်ရင်းနှီးသော Ilya အား ကျွန်ုပ်၏အသိပညာကို (၎င်းသည် ကျွန်ုပ်၏ခေါင်းထဲတွင်သာကျန်ရှိတော့သည်) သို့ ပေးပို့ခဲ့သည်။

ပရိုဂရမ်တစ်ခုဖန်တီးခြင်း။

Ilya Aleshin သတင်းပေးပို့ထားပါတယ်။

သင့်လျော်သော ညွှန်ကြားချက်များကို လက်ခံရရှိပြီးနောက် ကျွန်ုပ်သည် အလွန် “ပျော်ပါသည်။”

ဘယ်မှာစရမလဲ။ အစကတည်းက မှန်တယ်။  USB အပေါက်မှ အမှိုက်ပုံးကို ယူခြင်းမှ။

USB-pcap ကိုဖွင့်ပါ။ https://desowin.org/usbpcap/tour.html

စက်နှင့်ချိတ်ဆက်ထားသည့် ဆိပ်ကမ်းနှင့် အမှိုက်ပုံးကို သိမ်းဆည်းမည့် ဖိုင်ကို ရွေးပါ။

Windows အတွက် မူရင်း EZConfigScanning ဆော့ဖ်ဝဲကို ထည့်သွင်းထားသည့် စကင်နာကို ကျွန်ုပ်တို့ ချိတ်ဆက်ထားသည်။

၎င်းတွင် ကျွန်ုပ်တို့သည် စက်သို့ ညွှန်ကြားချက်များ ပေးပို့ရန် အရာကို တွေ့ရှိရသည်။ ဒါပေမယ့် အသင်းတွေကော။ သူတို့ကို ဘယ်မှာရနိုင်မလဲ။
ပရိုဂရမ် စတင်သောအခါ၊ စက်ပစ္စည်းများကို အလိုအလျောက် ကောက်ယူသည် (၎င်းကို ကျွန်ုပ်တို့ အနည်းငယ်ကြာသောအခါ တွေ့ရပါမည်)။ တရားဝင် စက်ကိရိယာ စာရွက်စာတမ်းများမှ လေ့ကျင့်ရေး ဘားကုဒ်များ ပါရှိခဲ့သည်။ DeFALT။ ဒါက ကျွန်တော်တို့အဖွဲ့ပါ။

လိုအပ်သော အချက်အလက်များကို လက်ခံရရှိပြီးဖြစ်သည်။ wireshark မှတဆင့် dump.pcap ကိုဖွင့်ပါ။

EZConfigScanning စတင်သောအခါတွင် ပိတ်ပါ။ သတိထားရမည့်နေရာများကို အနီရောင်ဖြင့် မှတ်သားထားသည်။

ဒါတွေအားလုံး ပထမဦးဆုံးမြင်လိုက်ရတော့ ငါစိတ်ပျက်သွားတယ်။ နောက်ဘယ်မှာတူးရမှန်း မရှင်းဘူး။

နည်းနည်းတော့ ဖောက်ထွက်ပြီး... Aha! အမှိုက်ပုံကြီးထဲမှာ ထွက် - ဒီ inနှင့် in က ထွက်.

ငါ URB_INTERRUPT ဆိုတာကို google လိုက်ကြည့်တယ်။ ဒါက ဒေတာလွှဲပြောင်းတဲ့ နည်းလမ်းတစ်ခုလို့ ကျွန်တော် သိလိုက်ရတယ်။ ထိန်းချုပ်မှု၊ နှောင့်ယှက်မှု၊ isochronous၊ အစုလိုက် စသည်တို့ဖြစ်သည်။ ၎င်းတို့အကြောင်း သီးခြားဖတ်နိုင်သည်။

USB ကိရိယာ၏ မျက်နှာပြင်ရှိ အဆုံးမှတ်လိပ်စာများကို “lsusb –v” အမိန့်ဖြင့် သို့မဟုတ် pyusb ကို အသုံးပြု၍ ရနိုင်သည်။

ယခု ကျွန်ုပ်တို့သည် ဤ VID ပါသည့် စက်ပစ္စည်းအားလုံးကို ရှာဖွေရန် လိုအပ်ပါသည်။ VID:PID ဖြင့် အထူးရှာဖွေနိုင်ပါသည်။

ဒါဟာတူ:

ထို့ကြောင့်၊ ကျွန်ုပ်တို့တွင် လိုအပ်သော အချက်အလက် ရှိသည်- P_INFO ညွှန်ကြားချက်များ။ သို့မဟုတ် DEFALT၊ commands endpoint=03 ရေးရမည့်နေရာတွင် လိပ်စာနှင့် တုံ့ပြန်မှု endpoint=86 ရရှိမည့်နေရာ။ ကျန်သည်မှာ command များကို hex သို့ပြောင်းရန်ဖြစ်သည်။

စက်ပစ္စည်းကိုကျွန်ုပ်တို့တွေ့ရှိပြီးဖြစ်သောကြောင့်၊ ၎င်းကို kernel မှအဆက်ဖြတ်ကြပါစို့။

...လိပ်စာ 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 သို့ပြောင်းပါ။ ဒါပဲ၊ လေ့ကျင့်ရေးလုပ်ဆောင်ချက်က အဆင်သင့်ဖြစ်နေပါပြီ။

Firmware ကကော? အားလုံးက အတူတူပဲလို့ ထင်ရပေမယ့် ကွဲလွဲချက်တော့ ရှိပါတယ်။

မီးမှိတ်တုတ်မှိတ်တုတ်ဖြစ်စဉ်ကို ပြီးပြည့်စုံသော အမှိုက်ပုံးကို ယူပြီးနောက်၊ ကျွန်ုပ်တို့ ကိုင်တွယ်ဖြေရှင်းနေသည်များကို အကြမ်းဖျင်း သဘောပေါက်ပါသည်။ ဤသည်မှာ ယေဘူယျအသုံးအနှုန်းများဖြင့်သော်လည်းကောင်း ဤဆက်သွယ်မှုဖြစ်ပေါ်လာပုံကို နားလည်ရာတွင် အလွန်အထောက်အကူဖြစ်စေသော XMODEM အကြောင်း ဆောင်းပါးတစ်ပုဒ်ဖြစ်ပါသည်။ http://microsin.net/adminstuff/others/xmodem-protocol-overview.html အဲဒါကို ဖတ်ဖို့ အကြံပေးပါတယ်။

အမှိုက်ပုံကြီးကို ကြည့်လိုက်ရင် ဖရိန်အရွယ်အစားက 1024 ဖြစ်ပြီး URB-ဒေတာအရွယ်အစားက 64 ဖြစ်တာကို တွေ့နိုင်ပါတယ်။

ထို့ကြောင့် - ၁၀၂၄/64 - ကျွန်ုပ်တို့သည် ဘလောက်တစ်ခုတွင် စာကြောင်း 16 ကြောင်းရသည်၊ firmware ဖိုင်ကို တစ်ကြိမ်လျှင် 1 စာလုံးကိုဖတ်ပြီး block တစ်ခုဖွဲ့စည်းပါ။ အထူးအက္ခရာ fd1e3 + ဘလောက်နံပါတ်ပါသော ဘလောက်တစ်ခုတွင် စာကြောင်း 02 ကြောင်းကို ဖြည့်စွက်ခြင်း။
ကျွန်ုပ်တို့သည် XMODEM.calc_crc() ကို အသုံးပြု၍ နောက် 14 ကြောင်းကို fd25 + ဖြင့် ဖြည့်စွက်ထားပြီး၊ ကျွန်ုပ်တို့သည် block တစ်ခုလုံး၏ checksum ကို တွက်ချက်သည် (“FF – 1” သည် CSUM ဖြစ်သည်ကို နားလည်ရန် အချိန်များစွာယူခဲ့ရသည်) နှင့် နောက်ဆုံး၊ 16 ခုမြောက် စာကြောင်းကို ဖြည့်စွက်ထားသည်။ fd3e နဲ့

ဒါပဲ၊ firmware ဖိုင်ကိုဖတ်ပါ၊ ဘလောက်များကိုနှိပ်ပါ၊ စကင်နာကို kernel မှအဆက်ဖြတ်ပြီး စက်သို့ပို့ပါ။ ဒါပေမယ့် ဒီလောက်မရိုးရှင်းပါဘူး။ စကင်နာကို firmware မုဒ်သို့ပြောင်းရန် လိုအပ်သည်၊
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
ဒီအဖွဲ့ ဘယ်ကလာတာလဲ?? အမှိုက်ပုံကြီးထဲက။

သို့သော် 64 ကန့်သတ်ချက်ကြောင့် စကင်နာသို့ ဘလောက်တစ်ခုလုံး မပို့နိုင်ပါ။

ကောင်းပြီ၊ NEWAPP မှိတ်တုတ်မှိတ်တုတ်မုဒ်ရှိ scanner သည် 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'။

ကောင်းပြီ၊ ဤဘလောက်များသည် သာမန်လူများအတွက် မည်သည့်အချက်အလက်မျှ မသယ်ဆောင်သောကြောင့်၊ ကျွန်ုပ်တို့သည် မူရင်းအတိုင်း ဝှက်ထားသောမုဒ်တွင် firmware ကို ထည့်သွင်းပါမည်။ အခြေအနေတွင်၊ ကျွန်ုပ်တို့သည် tqdm မှတဆင့် တိုးတက်မှုဘားတစ်ခုကို စုစည်းပါမည်။

တကယ်တော့ ဒါက အသေးအဖွဲ ကိစ္စပါ။ ကျန်ရှိနေသေးသည်မှာ ငွေရှင်းခြင်းလုပ်ငန်းစဥ်ကို နှေးကွေးစေရန်နှင့် စာရင်းသွင်းခြင်းတို့ကို ထည့်သွင်းခြင်းမပြုရန် ရှင်းရှင်းလင်းလင်းသတ်မှတ်ထားသော အချိန်တစ်ခုတွင် အစုလိုက်အပြုံလိုက်ပုံတူပွားခြင်းအတွက် ဖြေရှင်းချက်ကို scripts များတွင် ထုပ်ပိုးရန်ဖြစ်သည်။

ရလဒ်

ကျွန်ုပ်တို့၏ ဦးခေါင်းပေါ်တွင် အချိန်နှင့် အားစိုက်ထုတ်မှုများစွာကို သုံးစွဲခြင်းဖြင့် ကျွန်ုပ်တို့လိုအပ်သော ဖြေရှင်းချက်များကို တီထွင်နိုင်ခဲ့ပြီး နောက်ဆုံးသတ်မှတ်ရက်ကိုလည်း ပြည့်မီနိုင်ခဲ့သည်။ တစ်ချိန်တည်းမှာပင်၊ ယခုအခါ စကင်နာများကို ပြန်လည်ဆန်းသစ်ထားပြီး ဗဟိုတွင် ပြန်လည်လေ့ကျင့်ထားပြီး၊ လုပ်ငန်းစဉ်တစ်ခုလုံးကို ကျွန်ုပ်တို့ ရှင်းလင်းစွာ ထိန်းချုပ်ထားသည်။ ကုမ္ပဏီသည် အချိန်နှင့်ငွေကို သက်သာစေပြီး ဤအမျိုးအစားပြောင်းပြန် အင်ဂျင်နီယာစက်ပစ္စည်းများတွင် တန်ဖိုးမဖြတ်နိုင်သော အတွေ့အကြုံကို ရရှိခဲ့ပါသည်။

source: www.habr.com