Android က Mobile ေလာကမွာေတာ့ အရမ္းေအာင္ျမင္လွပါတယ္၊ Android သံုး ဖုန္း
tablet နဲ႔ အျခား စက္ပစၥည္း ေတြရဲ့ သယ္ေဆာင္ရလြယ္ကူမူ နဲ႔ လုပ္ငန္းစဥ္တစ္ခု
ကေန အျခား လုပ္ငန္း စဥ္တစ္ခုကို လွ်င္ျမန္စြာေျပာင္းလဲ ႏုိင္မူက Android
ကို ယခုလို ကမၻာ့ အလယ္ မွာ ၀င့္ထယ္
ဂုဏ္တက္ေစခဲ့ပါတယ္၊ ေနရာတိုင္းမွာကို Android မွ android ဆိုၿပီးျဖစ္ေနတဲ့ ေခါတ္ႀကီးပါ၊ Operating System အေနနဲ႔ ၾကည့္မယ္ဆိုရင္လဲ Android က ျပဳျပင္ေျပာင္းလဲရလြယ္ကူတယ္ၿပီး သံုးစြဲ ရသာ အဆင္ေျပတဲ့ အတြက္ Embedded System အမ်ိဳးအစားေတြ အေနနဲ႔ Android က ေရြးခ်ယ္ ဖို႔ အသင့္ေတာ္ဆံုးျဖစ္တယ္၊ Android က open source ျဖစ္တယ္၊ စိတ္ႀကိဳက္ျပဳျပင္ ႏိုင္တယ္ ထပ္ျဖည့္ႏိုင္တယ္၊ အသံုးျပဳသူ ေတြအဖို႔ မ်က္စိနဲ႔ တပ္အပ္ျမင္ႏိုင္ၿပီး ထိေတြ႔ ခိုင္းေစလို႔ရတဲ့ user interface ေတြကို လြယ္ကူစြာ ဖန္တီးႏိုင္တယ္၊
ေရွ႕ကအသံုးျပဳခဲ့တဲ့ industry standard ေတြျဖစ္တဲ့ ျဖည့္စြက္ခ်က္ေတြ ဘာျဖည့္စြက္ခ်က္မွ မပါ၀င္ေသာ embedded linux တို႔ ကုမၼဏီေတြက တည္ေဆာက္ထားတဲ့ operating system ေတြထက္စာရင္ Android operating system က အသံုးျပဳရတာ လြယ္ကူ ၿပီး Develop လုပ္ရတာ အလွ်င္ အျမန္ၿပီးဆံုးေစတဲ့ အတြက္ အလြန္ေကာင္း မြန္တဲ့ Operation System တစ္ခုဆိုတာ ျငင္းလို႔မရပါဘူး၊
ယေန႔ခါတ္အသံုးျပဳေနတဲ့ embedded devices ေတြမွာလဲ Android က ႀကယ္ျပန္႔တဲ့ လက္ေတြ႔ အသံုးျခမူ နယ္ ပယ္ကို စိုးပိုင္ထား ပါေသးတယ္၊ ဥပမာ e-readers ၊ set-top entertainment systems, airline in-flitht entertainment systems, smart televisions, climate control system နဲ႔ point-of-sale system ေတြအားလံုးမွာ Android ကိုအသံုးျပဳထားၾကပါတယ္၊ (ဒါေတြက Android သံုးေနတဲ့ devices ေတြအကုန္မဟုတ္ေသးပါဘူး)၊ ဒီေလာက္က်ယ္ျပန္႔လွတဲ့ Android ကမၻာမွာ ကၽြန္ေတာ္တို႔က ဒီ Android အသံုးျပဳ ပစၥည္းေတြရဲ့ hardware ေတြထဲက အနည္းဆံုး တစ္ခုေလာက္ကို ဘယ္လို တိုက္ခိုက္ ႏိုင္မလဲ ဆိုတာကို ဒီစာအုပ္မွာ မေဖာ္ျပလိုက္ရင္ေတာ့ Android Hack လို႔နာမည္ေပးထားတဲ့ ဒီစာအုပ္ရဲ့ အရသာ မဲ့သြားလိမ့္ပါမယ္၊ ဒါ့ေၾကာင့္ ဒီအခန္းမွာ Hardware တိုက္ခိုက္ဖို႔ နည္းတစ္ခ်ိဳ႕ကို ဥပမာ ျပမယ္၊ reverse engineering သံုး ၿပီး hardware တစ္ခ်ိဳ႕ကိုတိုက္ခိုက္ၾကမယ္၊
Attack vector တစ္ျဖစ္တဲ့ hardware ကို ကိုင္တြယ္ အလုပ္လုပ္ႏိုင္တဲ့ အေျခအေနကို ရရွိေနျခင္းက ပံုမွန္အားျဖင့္ “Game Over” အေနနဲ႔ ယူစႏိုင္ၿပီး Thread model ရဲ နဲ႔ ျဖစ္ေလ့ရွိတဲ့ အႏၱရယ္ ေတြကေန ေရွာ့ေပါ့ေစႏိုင္ပါတယ္၊
အမ်ားစုေသာ အေျခအေနေတြမွာ hardware ကို လက္ေတြ႔ကိုင္တြယ္ အလုပ္လုပ္တဲ့နည္းကိုသံုးၿပီး ေျပာင္ေျမာက္တဲ့ ထင္မွတ္မထားတဲ့ အားနည္းခ်က္ေတြကို ရွာေဖြႏိုင္ပါတယ္၊ ဒီလို hardware ကို လက္ေတြ႔ကိုင္တြယ္ အလုပ္လုပ္တဲ့နည္းဆိုတာက ဥပမာ အေနနဲ႔ router တစ္ခု (သို႔) switch တစ္ခုရဲ့ ကာကြယ္မထားတဲ့ debug port တစ္ခုကို ခ်ိတ္ဆက္ျခင္းမ်ိဳးပါ၊ နားလည္ကၽြမ္းက်င္ရင္ ဒီလို ကာကြယ္ထားမူ တစ္စံုတစ္ရာမရွိတဲ့ debug port တစ္ခုကို ခ်ိတ္ဆက္ အလုပ္လုပ္ႏိုင္ျခင္းက attacker တစ္ေရာက္ကို enbedded encryption keys ကို လြတ္လက္စြာ ရွာေဖြနိုင္ေစျခင္း (သို႔) remote exploitable အားနည္းခ်က္ေတြကိုရွာေဖြေတြ႔ရွိ ႏိုင္ေစမွာျဖစ္ပါတယ္၊
Device ကို လက္ေတြ႔ ထိကိုင္ႏိုင္ၿပီး တိုက္ခိုက္ရျခင္းက Attckers တစ္ေယာက္က reverse engineer နည္းကို သံုးဖို႔ အတြက္ chips ကို ဖယ္ထုတ္လို႔ ရပါတယ္၊ ဒါဆိုရင္ ပိုၿပီး က်ယ္ျပန္႔တဲ့ အစြမ္းေတြကို ရရွိေစမွာျဖစ္သလို device အခ်ိဳ႕ကိုေတာ့ research လုပ္ေန စဥ္အတြင္းမွာ ဆံုးရွံုး ရဖို႔ ရွိပါတယ္၊
ဒီအခန္းမွာေတာ့ အတားအစီးေတြကို နည္းသည္ထက္နည္းသြားေအာင္ လုပ္ၿပီး hardware ေပၚမွာ ရွိေနတဲ့ embedded device security research နဲ႔ ပက္သက္တဲ့ အခ်က္ေတြကို ေလ့လာသြားမွာ ျဖစ္ၿပီး tools အခ်ိဳ႕နဲ႔ techniques (နည္း) အခ်ိဳ႕ကိုသံုးကာ Hardware အားနည္းခ်က္ေတြကိုရွာသြားမွာျဖစ္ပါတယ္၊ target device ကို လက္ေတြ႔ ထိႏိုင္ကိုင္ႏိုင္တဲ့ အေျခအေနကိုသံုးၿပီးေတာ့ hardware interfaces ေတြကိုတိုက္ခိုက္ျခင္းျဖစ္ေစ device မွာပါ၀င္တဲ့ software ေတြကို ရယူျခင္းျဖစ္ေစ ရယူလုပ္ေဆာင္ႏုိင္ပါတယ္၊ hardware အတားအစီးေတြကို ေက်ာ္လႊားႏိုင္ၿပီဆိုရင္ software ေပၚအေျခခံထားတဲ့ exploitation ေတြနဲ႔ reverse-enginnering နည္းေတြကို လဲ ထပ္သံုးႏိုင္ပါၿပီ၊ ဥပမာ firmware တစ္ခုထဲမွာရွိတဲ့ အားနည္းခ်က္ ထိုးေဖာက္လို႔ရႏိုင္မယ့္အခ်က္ကို ရွာေဖြဖို႔ အတြက္ desassembler ကို အသံုးျပဳျခင္း မ်ိဳး တို႔ ကုမၼဏီ ပိုင္ Universal Serial Bus (USB) ကဲ့သို႔ေသာ hardware interface ေတြေပၚမွာ data ေရာက္ရွိျခင္းကို ရွာေဖြမယ့္ proprietarty protocol parser ေတြကို ပါ ေလ့လာႏိုင္ပါၿပီ၊ ဒီနည္းေတြက အလြန္ရိုးရွင္းတယ္၊ ဒီလိုပဲ သိပ္ ၿပီးေလးနက္လြန္းအားႀကီးတဲ့ hardcore electrical engineering အေၾကာင္းေတြလဲ သိစရာ မလိုဘူး၊ debugging, bus monotroing နဲ႔ device emulation တို႔လို နည္း အမ်ားစုက passive ျဖစ္ေပမယ့္ target device ကို အေတာ္ေလးကို အေႏွာင့္ အယွက္ျဖစ္ ေစႏိုင္ပါတယ္၊
Interfacing with Hardware Devices
အားနည္းခ်က္ကို ရွာေဖြဖို႔ ျဖစ္ေစ reverse engineer နည္းကိုသံုးဖို႔ အရင္ဆံုး လုပ္ရမွာကေတာ့ target device ႏွင့္ လက္ေတြ႔ထိ ကိုင္ႏိုင္မူ အေျခအေနမွာ အျပန္အလွန္ ခ်ိတ္ဆက္တထိေတြ႔ႏိုင္မယ့္နည္းလမ္းကို သတ္မွတ္ဖို႔လိုပါတယ္၊ device ေပၚမွာ exposed interfaces ရွိလား ကိုလဲ စမ္းသပ္ရမယ္၊ USB တို႔ memory cards တို႔ ထည့္သြင္း ခ်ိတ္ဆက္ႏိုင္မယ့္ အေပါက္ေတြ port ေတြရွိလား စစ္ရမယ္၊ ဒီလို လူသိမ်ားတဲ့ interfaces ေတြကို ဒီအခန္းရဲ့ ေနာက္ပိုင္းမွာ ရွင္းသြားအံုးမယ္၊ ဒါေပမယ့္ ဒီအပိုင္းမွာေတာ့ Device တစ္ခုကိုဖြင့္လိုက္ရင္ေတြ႔ရယမ့္ printed circuit board(PCB) တစ္ခုမွာပါ၀င္သမွ် အရာေတြထဲက အခ်ိဳ႕ကို ေဆြေႏြးသြားမယ္၊ ဥပမာ ျပျခင္းတို႔ စမ္းသပ္ျခင္းတို႔မတိုင္မွီ ဒီအပိုင္းမွာ အသံုး အမ်ားဆံုး hardware interface ေတြအေၾကာင္းကို အနည္းနယ္ ရွင္းသြားမယ္၊
UART Serial Interfaces
Universal Asynchronous Receiver/Transmitter (UART) interfaces ကေတာ့ embedded devices ေတြမွာ debug output နဲ႔ dagnostic အတြက္ အေတြ႔အမ်ားဆံုး interface တစ္ခုျဖစ္ပါတယ္၊ UART Serial interfaces က communiction standards ေတြျဖစ္တဲ့ (RS-232, RS-422, RS-485, EIA စသျဖင့္) တို႔ထဲက တစ္ခုကို အသံုးျပဳတည္ေဆာက္ထားတာျဖစ္တယ္၊ ဒီ communication standards ေတြက characteristics signals ေတြကဲ့သို႔ေသာ အေသးစိတ္အခ်က္အလက္ေတြကို ကိုင္တြယ္ အလုပ္လုပ္တယ္၊ သူ႔တို႔ရဲ့ အလုပ္ေတြထဲမွာ မတူညီတဲ့ signals ေတြရဲ့ အဓီပါယ္ ၊ signal စတင္ထုတ္လြင့္ျခင္း၊ singnal ထုတ္လြင့္မူ ရပ္တန္႔ျခင္း၊ ခ်ိတ္ဆက္မူ ကို ျပန္လည္စတင္ျခင္း၊ စသျဖင့္လုပ္ငန္းေဆာင္တာမ်ားကိုလုပ္ကိုင္ၾကတယ္၊ ဒီ standards ေတြက timing (data transmit ဘယ္ေလာက္ျမန္ျမန္လုပ္သင့္လဲ ) ဆိုတဲ့ data ထုတ္လြင့္မူ အေႏွး အျမန္ ကိစၥေတြကိုလဲ ထိန္းခ်ဳပ္ႀကသို အခ်ိဳ႕ေသာ အေျခအေနေတြမွာ connectors ေတြရဲ့ အရြယ္အစားနဲ႔ အေသးစိတ္အခ်က္အလက္ေတြကိုလဲ ကိုင္တြယ္ အလုပ္လုပ္ႏိုင္ပါတယ္၊ UART ေတြနဲ႔ ပက္သက္တဲ့ အားသားမူ ေတြ ကြဲျပားမူေတြကို ေလ့လာလိုရင္ေတာ့ အင္တာနက္မွာ စိတ္ႀကိဳက္ရိုက္ရွာေလ့လာလို႔ရပါတယ္။ အခု အတြက္ေတာ့ UART တို႔လို interface ေတြက embedded devices ေတြမွာ သိပ္အသံုး မ်ားတယ္ဆိုတဲ့ အခ်က္ပါ၊ UART က ဘာ့ေၾကာင့္ အသံုးမ်ားရတာတုန္း ဆိုေတာ့
UART ေတြက Controllers ေတြနဲ႔ microprocessors ေတြအၾကားရွဳပ္ေထြး ၿပီး microprocessor တစ္ခုထဲ ထည့္သြင္း တည္ေဆာက္ဖို႔ ေစ်းႀကီးလွတဲ့ intermediary hardware ေတြကို ေက်ာ္ျဖတ္စရာမလိုပဲ data ေတြကို Controllers ေတြနဲ႔ microprocessors ေတြအၾကား အျပန္အလွန္တိုက္ရိုက္ေပးပို႔ႏိုင္မယ့္ အရိုးရွင္ဆံုးနည္းေတြကို ေထာက္ပံ့ထားေပးလို႔႔ပါ၊ ေအာက္က ပံုမွာေတာ့ UART interface တစ္ခုရဲ့ Central Processing Unit (CPU) ကိုတိုက္ရိုက္ ခ်ိတ္ဆက္ပံုကို ေဖာ္ျပထားပါတယ္၊
UART Serial interfaces ကို video cards, keyboard/mice port နဲ႔ network interface card ကဲ့သိုေသာ computers နဲ႔ အဓီက ခ်ိတ္ဆက္မယ့္ နည္းလမ္းေတြမွာ အသံုးျပဳေနခဲ့ၾကၿပီးပါၿပီ၊ ေရွး ကြန္ျပဴတာေတြမွာ keybaord တို႔ mouse တို႔ monitor တို႔ video output တို႔မပါပါဘူး၊ ဒါေြအစား control interface အျဖစ္ serial port တစ္ခု ပါရွိၿပီးေတာ့ သတ္မွတ္ထားတဲ့ “dumb terminal” (Wyse တို႔လို) ကို အသံုးျပဳသူက ခ်ိတ္ဆက္ရပါတယ္၊ ႏွစ္ေပါင္းမ်ားစြာ ၾကာေအာင္ UART serial port ကေန တစ္ဆင့္ အသံုးျပဳတဲ့ ဒီတစ္နည္းထည္းကပဲ computer ရဲ့ command-line console ကို ၀န္ေရာက္ခြင့္ရတဲ့နည္းျဖစ္ခဲ့ရပါတယ္၊ တကယ္ေတာ့ ေရွးက ျပဳလုပ္ခဲ့တဲ့ original Unix concepts stem ေတြအမ်ားစု မွာလဲ ဒီနည္းပဲသံုးတာပါ၊
ဥပမာ အားျဖင့္ Unix နဲ႔ Linux users ေတြက သူတို႔ရဲ့ terminals ေတြကို TTY တစ္ခု ေပၚမွာ run ျခင္းကို ကၽြမ္းက်င္ေနၾကပါၿပီ၊ ဒီနည္းကိုက ေရွ႕၀ေပသနီက Unix sysesm ေတြကို serial connection ကေန TeleType Write (TTY) ကို ခ်ိတ္ဆက္ၿပီး အသံုးျပဳတဲ့နည္းပါ၊ UART serail intefaces က ပံုစံမ်ိဳးစံုနဲ႔ လာႏိုင္ပါတယ္၊ အရိုး ရွင္းဆံုး ဆုိရင္ေတာ့ wire ၃ ၊ ၄ ေခ်ာင္းေလာက္ပါပါမယ္၊ UART ရဲ့ ရိုးရွင္းပံုဆိုတာထဲမွာ ေစ်းႏွဳန္း အရမ္းေပါျခင္းနဲ႔ ေပါ့ပါး ျခင္းတို႔ပါ၀င္ၿပီး circuit design ထဲကို ထည့္သြင္းဖို႔ လဲ လြန္စြာ မွ လြယ္ကူ လွပါတယ္၊ ဒါ့ေၾကာင့္ပဲ UART consoles ေတြကို embedded system အားလံုနည္းပါးမွာေတြ႔ရတာပါ၊ တစ္ခါတစ္ရံ original equipment manufacturers (OEMs) ေတြကေန ထုတ္လုပ္တဲ့ System-on-Chip(Soc) products ေတြထဲ embedded ေတြကို တိုက္ရိုက္ရယူျခင္း မွာလဲ ေတြ႔ႏိုင္တယ္၊ set-top boxes တို႔လို embedded systems ေတြမွာေတာ့ video output ကို ပံုမွန္အားျဖင့္ high-level user interface ကို ရည္ညြန္းပါတယ္၊ ဆက္ရွက္ၿပီးေတာ့ ဒီလို devices ေတြမွာလဲ ကန္႔သတ္ထားတဲ့ user input ေတြရွိတယ္ ဥပမာ dedicated remote လုိမ်ိဳးေပါ့၊ ဒီလို အေျခအေနမွာ ဆိုရင္ေတာ့ market-ready product ေတြမွာ lower-lefvel debug functionality အတြက္ ေရြးခ်ယ္ခြင့္ အခ်ိဳ႕ခ်န္ထားပါလိမ့္မယ္၊ ဒါ့ေၾကာင့္ device ထဲမွာ ျမဳပ္ထားတဲ့ အလြန္ကို debuggin အတြက္ အသံုး၀င္လွေသာ UART serial console ကို developer ေတြဘယ္လို ရွာႏိုင္လာသလဲ ဆိုတာ ကို စဥ္းစားႀကည့္လို႔ရႏုိင္ပါတယ္၊ တကယ္ေတာ့ consumer-grade products ေတြက ဒီ လို interfaces ေတြကို exposed လုပ္ထားတယ္၊ enable လုပ္ေပးထားတယ္၊
What Does an Exposed Serial Interface Mean?
Exposed serial console တစ္ခုကို အသံုးျပဳ၍
Embedded operating system (OS) နဲ႔ intercept လုပ္ျခင္း view ၊ tamper လုပ္၍ တိုက္ရိုက္ ခ်ိ္ဆက္အလုပ္လုပ္ႏိုင္သည့္ျဖစ္ေစ ၊ intra-chip conversation paths ရဲ့ data ေတြကို generate လုပ္ႏိုင္သည္ျဖစ္ေစ ရလာတဲ့ အက်ိဳး ရလဒ္ကေတာ့ အတူတူပါပဲ၊ attack surface ပိုရတာေတြပါပဲ၊ အခန္း ၅ မွာဖတ္ခ့ဲ သလို target attack surface ရဲ့ အရြယ္အစားက အျခား systems ေတြ code ေတြ devices ေတြ users ေတြ အပါ၀င္ သူ႔ကိုယ္ပိုင္ hardware ေတြ နဲ႔ ဘယ္ေလာက္အထိ စိတ္ပိုင္း ခြဲျခား ထားလဲ ဆိုတဲ့ အခ်က္ေပၚမွာ မူတည္ေနပါတယ္၊ ဒီ interface ေတြကို နားလည္သေဘာေပါက္ျခင္းက Adroid မွာသာလွ်င္ Run ေနတဲ့ attack sruface ေတြတင္မကဘဲ အျခား host devices တစ္ခုလံုးရဲ့ attack surface ကိုပိုမို နားလည္ကၽြမ္းက်င္သြားေစမွာပါ၊
Exposed UART on Android and Linux
Embedded Android-base systems မွာေတာ့ exposed UART serail ports မွာ ေတြ႔ရတာ မ်ားပါတယ္၊ ဒီအခ်က္က ေတာ့ underlying operating system ကို တိုက္ရိုက္ ခ်ိတ္ဆက္ဆက္သြယ္ႏိုင္မယ့္ အခ်က္ပါ၊ ဒီစာအုပ္မွာ အေသးစိတ္ ေဆြးေႏြး ခဲ့သလိုပါပဲ၊ Android နဲ႔ တိုက္ရိုက္ခ်ိတ္ဆက္မယ့္ နည္းလမ္းက Android Debug Bridge (ADB) လို႔ေျပာခဲ့ပါတယ္၊ ဒါေပသည့္ UART ကို expose ျဖစ္ေစတဲ့ Kenral compile-time options ကို အသံုးျပဳၿပီး Android-based embedded systems အတြက္ compile လုပ္တာကေတာ့ ေတြ႔ရမ်ားတဲ့ အခ်က္တစ္ခုျဖစ္ပါတယ္၊
CONFIG_SERIAL_MSM
CONFIG_SERIAL_MSM_CONSOLE
ထို႔ေနာက္ေတာ့ boot loader ကိုသံုးမယ္၊ uBoot တို႔ X-Loader တို႔လို ၊ သူတို႔ကို သံုးၿပီးေတာ့ kernal seraial port ရဲ့ configuration options ကို boot-time optin ျဖစ္ေသာ ေအာက္က လို
"console=ttyMSM2,115200n8"
ဒီအေျခအေနမွာဆိုရင္ “stdout” , “stderr” နဲ႔ “debug” ေတြကို serial console သို႔ rout လုပ္မယ္ prints ထုတ္မယ္၊ အကယ္၍ Android သို႔ standard linux နဲ႔ login ေတြက boot sequence ေတြထဲမွာ Run ေနခဲ့ရင္ login prompt ကလဲ ဒီေနရာမွာ ေပၚလာမယ္၊
Configuration setting က အထူးသျဖင့္ Qualcomm MSM-base chipset ေတြအတြက္ compile လုပ္ဖို႔ သီးသန္႔ျဖစ္ပါတယ္၊ ဒါေပမယ့္ အျခား chippsets ေတြအတြက္ သံုးတဲ့အခါလဲ ဒိ idea ကိုပဲ အသံုးျပဳသြားမွာျဖစ္ပါတယ္၊ ဒီ interfaces ေတြႏွင့္ အတူ Device boot ကို ပံုမွန္ေစာင့္ၾကည့္ႏိုင္ပါတယ္ print debug လုပ္ႏိုင္တယ္၊ diagnositc message (syslog (or) dmesg) တို႔လို၊ command shell သံုးၿပီးေတာ့ေတာင္ interface ေတြနဲ႔ ခ်ိတ္ဆက္အလုပ္လုပ္ႏိုင္ပါေသးတယ္၊ ေအာက္က ပံုမွာ set-top box တစ္ခုရဲ့ UART pin ေတြကို ေဖာ္ျပထားပါတယ္
သင့္ေလွ်ာ္တဲ့ pins တစ္ခုကို circut board မွာ ခ်ိတ္ဆက္တဲ့ အခါ ပံု 13-2 မွာျပထားတဲ့ အခ်က္တစ္ခ်ဳ႕ကို အသံုးျပဳ ဦးေဆာင္ၿပီးေတာ့ root shell ကို embedded Android Operating System ေပၚမွာရရွိေစပါတယ္၊ ဒီနည္း အတိုင္းသံုးၿပီးေတာ့ Broadcom-base cable model နဲ႔ Customized Real-time operation system ကို စိတ္ႀကိဳက္ ျပဳျပင္ႏိုင္ပါတယ္၊ Broadcom ရဲ့ UART ေပးမွာ shell interactive မရွိေပမယ့္ Devic Internet Protocol (IP) ကို fuzz လုပ္တဲ့အခါမွာေတာ့ UART ေပၚမွာ stack tracks ကိုေဖာ္ျပေပးလိမ့္မယ္၊ ဒီအခ်က္က exploitation process ကို အတိအက် သတင္းေပးတယ္၊ အခုသံုးတဲ့ device အတြက္ UART pins ကိုေတာ့ ေအာက္က ပံုမွာေတြ႔ႏိုင္ပါတယ္။
ဂုဏ္တက္ေစခဲ့ပါတယ္၊ ေနရာတိုင္းမွာကို Android မွ android ဆိုၿပီးျဖစ္ေနတဲ့ ေခါတ္ႀကီးပါ၊ Operating System အေနနဲ႔ ၾကည့္မယ္ဆိုရင္လဲ Android က ျပဳျပင္ေျပာင္းလဲရလြယ္ကူတယ္ၿပီး သံုးစြဲ ရသာ အဆင္ေျပတဲ့ အတြက္ Embedded System အမ်ိဳးအစားေတြ အေနနဲ႔ Android က ေရြးခ်ယ္ ဖို႔ အသင့္ေတာ္ဆံုးျဖစ္တယ္၊ Android က open source ျဖစ္တယ္၊ စိတ္ႀကိဳက္ျပဳျပင္ ႏိုင္တယ္ ထပ္ျဖည့္ႏိုင္တယ္၊ အသံုးျပဳသူ ေတြအဖို႔ မ်က္စိနဲ႔ တပ္အပ္ျမင္ႏိုင္ၿပီး ထိေတြ႔ ခိုင္းေစလို႔ရတဲ့ user interface ေတြကို လြယ္ကူစြာ ဖန္တီးႏိုင္တယ္၊
ေရွ႕ကအသံုးျပဳခဲ့တဲ့ industry standard ေတြျဖစ္တဲ့ ျဖည့္စြက္ခ်က္ေတြ ဘာျဖည့္စြက္ခ်က္မွ မပါ၀င္ေသာ embedded linux တို႔ ကုမၼဏီေတြက တည္ေဆာက္ထားတဲ့ operating system ေတြထက္စာရင္ Android operating system က အသံုးျပဳရတာ လြယ္ကူ ၿပီး Develop လုပ္ရတာ အလွ်င္ အျမန္ၿပီးဆံုးေစတဲ့ အတြက္ အလြန္ေကာင္း မြန္တဲ့ Operation System တစ္ခုဆိုတာ ျငင္းလို႔မရပါဘူး၊
ယေန႔ခါတ္အသံုးျပဳေနတဲ့ embedded devices ေတြမွာလဲ Android က ႀကယ္ျပန္႔တဲ့ လက္ေတြ႔ အသံုးျခမူ နယ္ ပယ္ကို စိုးပိုင္ထား ပါေသးတယ္၊ ဥပမာ e-readers ၊ set-top entertainment systems, airline in-flitht entertainment systems, smart televisions, climate control system နဲ႔ point-of-sale system ေတြအားလံုးမွာ Android ကိုအသံုးျပဳထားၾကပါတယ္၊ (ဒါေတြက Android သံုးေနတဲ့ devices ေတြအကုန္မဟုတ္ေသးပါဘူး)၊ ဒီေလာက္က်ယ္ျပန္႔လွတဲ့ Android ကမၻာမွာ ကၽြန္ေတာ္တို႔က ဒီ Android အသံုးျပဳ ပစၥည္းေတြရဲ့ hardware ေတြထဲက အနည္းဆံုး တစ္ခုေလာက္ကို ဘယ္လို တိုက္ခိုက္ ႏိုင္မလဲ ဆိုတာကို ဒီစာအုပ္မွာ မေဖာ္ျပလိုက္ရင္ေတာ့ Android Hack လို႔နာမည္ေပးထားတဲ့ ဒီစာအုပ္ရဲ့ အရသာ မဲ့သြားလိမ့္ပါမယ္၊ ဒါ့ေၾကာင့္ ဒီအခန္းမွာ Hardware တိုက္ခိုက္ဖို႔ နည္းတစ္ခ်ိဳ႕ကို ဥပမာ ျပမယ္၊ reverse engineering သံုး ၿပီး hardware တစ္ခ်ိဳ႕ကိုတိုက္ခိုက္ၾကမယ္၊
Attack vector တစ္ျဖစ္တဲ့ hardware ကို ကိုင္တြယ္ အလုပ္လုပ္ႏိုင္တဲ့ အေျခအေနကို ရရွိေနျခင္းက ပံုမွန္အားျဖင့္ “Game Over” အေနနဲ႔ ယူစႏိုင္ၿပီး Thread model ရဲ နဲ႔ ျဖစ္ေလ့ရွိတဲ့ အႏၱရယ္ ေတြကေန ေရွာ့ေပါ့ေစႏိုင္ပါတယ္၊
အမ်ားစုေသာ အေျခအေနေတြမွာ hardware ကို လက္ေတြ႔ကိုင္တြယ္ အလုပ္လုပ္တဲ့နည္းကိုသံုးၿပီး ေျပာင္ေျမာက္တဲ့ ထင္မွတ္မထားတဲ့ အားနည္းခ်က္ေတြကို ရွာေဖြႏိုင္ပါတယ္၊ ဒီလို hardware ကို လက္ေတြ႔ကိုင္တြယ္ အလုပ္လုပ္တဲ့နည္းဆိုတာက ဥပမာ အေနနဲ႔ router တစ္ခု (သို႔) switch တစ္ခုရဲ့ ကာကြယ္မထားတဲ့ debug port တစ္ခုကို ခ်ိတ္ဆက္ျခင္းမ်ိဳးပါ၊ နားလည္ကၽြမ္းက်င္ရင္ ဒီလို ကာကြယ္ထားမူ တစ္စံုတစ္ရာမရွိတဲ့ debug port တစ္ခုကို ခ်ိတ္ဆက္ အလုပ္လုပ္ႏိုင္ျခင္းက attacker တစ္ေရာက္ကို enbedded encryption keys ကို လြတ္လက္စြာ ရွာေဖြနိုင္ေစျခင္း (သို႔) remote exploitable အားနည္းခ်က္ေတြကိုရွာေဖြေတြ႔ရွိ ႏိုင္ေစမွာျဖစ္ပါတယ္၊
Device ကို လက္ေတြ႔ ထိကိုင္ႏိုင္ၿပီး တိုက္ခိုက္ရျခင္းက Attckers တစ္ေယာက္က reverse engineer နည္းကို သံုးဖို႔ အတြက္ chips ကို ဖယ္ထုတ္လို႔ ရပါတယ္၊ ဒါဆိုရင္ ပိုၿပီး က်ယ္ျပန္႔တဲ့ အစြမ္းေတြကို ရရွိေစမွာျဖစ္သလို device အခ်ိဳ႕ကိုေတာ့ research လုပ္ေန စဥ္အတြင္းမွာ ဆံုးရွံုး ရဖို႔ ရွိပါတယ္၊
ဒီအခန္းမွာေတာ့ အတားအစီးေတြကို နည္းသည္ထက္နည္းသြားေအာင္ လုပ္ၿပီး hardware ေပၚမွာ ရွိေနတဲ့ embedded device security research နဲ႔ ပက္သက္တဲ့ အခ်က္ေတြကို ေလ့လာသြားမွာ ျဖစ္ၿပီး tools အခ်ိဳ႕နဲ႔ techniques (နည္း) အခ်ိဳ႕ကိုသံုးကာ Hardware အားနည္းခ်က္ေတြကိုရွာသြားမွာျဖစ္ပါတယ္၊ target device ကို လက္ေတြ႔ ထိႏိုင္ကိုင္ႏိုင္တဲ့ အေျခအေနကိုသံုးၿပီးေတာ့ hardware interfaces ေတြကိုတိုက္ခိုက္ျခင္းျဖစ္ေစ device မွာပါ၀င္တဲ့ software ေတြကို ရယူျခင္းျဖစ္ေစ ရယူလုပ္ေဆာင္ႏုိင္ပါတယ္၊ hardware အတားအစီးေတြကို ေက်ာ္လႊားႏိုင္ၿပီဆိုရင္ software ေပၚအေျခခံထားတဲ့ exploitation ေတြနဲ႔ reverse-enginnering နည္းေတြကို လဲ ထပ္သံုးႏိုင္ပါၿပီ၊ ဥပမာ firmware တစ္ခုထဲမွာရွိတဲ့ အားနည္းခ်က္ ထိုးေဖာက္လို႔ရႏိုင္မယ့္အခ်က္ကို ရွာေဖြဖို႔ အတြက္ desassembler ကို အသံုးျပဳျခင္း မ်ိဳး တို႔ ကုမၼဏီ ပိုင္ Universal Serial Bus (USB) ကဲ့သို႔ေသာ hardware interface ေတြေပၚမွာ data ေရာက္ရွိျခင္းကို ရွာေဖြမယ့္ proprietarty protocol parser ေတြကို ပါ ေလ့လာႏိုင္ပါၿပီ၊ ဒီနည္းေတြက အလြန္ရိုးရွင္းတယ္၊ ဒီလိုပဲ သိပ္ ၿပီးေလးနက္လြန္းအားႀကီးတဲ့ hardcore electrical engineering အေၾကာင္းေတြလဲ သိစရာ မလိုဘူး၊ debugging, bus monotroing နဲ႔ device emulation တို႔လို နည္း အမ်ားစုက passive ျဖစ္ေပမယ့္ target device ကို အေတာ္ေလးကို အေႏွာင့္ အယွက္ျဖစ္ ေစႏိုင္ပါတယ္၊
Interfacing with Hardware Devices
အားနည္းခ်က္ကို ရွာေဖြဖို႔ ျဖစ္ေစ reverse engineer နည္းကိုသံုးဖို႔ အရင္ဆံုး လုပ္ရမွာကေတာ့ target device ႏွင့္ လက္ေတြ႔ထိ ကိုင္ႏိုင္မူ အေျခအေနမွာ အျပန္အလွန္ ခ်ိတ္ဆက္တထိေတြ႔ႏိုင္မယ့္နည္းလမ္းကို သတ္မွတ္ဖို႔လိုပါတယ္၊ device ေပၚမွာ exposed interfaces ရွိလား ကိုလဲ စမ္းသပ္ရမယ္၊ USB တို႔ memory cards တို႔ ထည့္သြင္း ခ်ိတ္ဆက္ႏိုင္မယ့္ အေပါက္ေတြ port ေတြရွိလား စစ္ရမယ္၊ ဒီလို လူသိမ်ားတဲ့ interfaces ေတြကို ဒီအခန္းရဲ့ ေနာက္ပိုင္းမွာ ရွင္းသြားအံုးမယ္၊ ဒါေပမယ့္ ဒီအပိုင္းမွာေတာ့ Device တစ္ခုကိုဖြင့္လိုက္ရင္ေတြ႔ရယမ့္ printed circuit board(PCB) တစ္ခုမွာပါ၀င္သမွ် အရာေတြထဲက အခ်ိဳ႕ကို ေဆြေႏြးသြားမယ္၊ ဥပမာ ျပျခင္းတို႔ စမ္းသပ္ျခင္းတို႔မတိုင္မွီ ဒီအပိုင္းမွာ အသံုး အမ်ားဆံုး hardware interface ေတြအေၾကာင္းကို အနည္းနယ္ ရွင္းသြားမယ္၊
UART Serial Interfaces
Universal Asynchronous Receiver/Transmitter (UART) interfaces ကေတာ့ embedded devices ေတြမွာ debug output နဲ႔ dagnostic အတြက္ အေတြ႔အမ်ားဆံုး interface တစ္ခုျဖစ္ပါတယ္၊ UART Serial interfaces က communiction standards ေတြျဖစ္တဲ့ (RS-232, RS-422, RS-485, EIA စသျဖင့္) တို႔ထဲက တစ္ခုကို အသံုးျပဳတည္ေဆာက္ထားတာျဖစ္တယ္၊ ဒီ communication standards ေတြက characteristics signals ေတြကဲ့သို႔ေသာ အေသးစိတ္အခ်က္အလက္ေတြကို ကိုင္တြယ္ အလုပ္လုပ္တယ္၊ သူ႔တို႔ရဲ့ အလုပ္ေတြထဲမွာ မတူညီတဲ့ signals ေတြရဲ့ အဓီပါယ္ ၊ signal စတင္ထုတ္လြင့္ျခင္း၊ singnal ထုတ္လြင့္မူ ရပ္တန္႔ျခင္း၊ ခ်ိတ္ဆက္မူ ကို ျပန္လည္စတင္ျခင္း၊ စသျဖင့္လုပ္ငန္းေဆာင္တာမ်ားကိုလုပ္ကိုင္ၾကတယ္၊ ဒီ standards ေတြက timing (data transmit ဘယ္ေလာက္ျမန္ျမန္လုပ္သင့္လဲ ) ဆိုတဲ့ data ထုတ္လြင့္မူ အေႏွး အျမန္ ကိစၥေတြကိုလဲ ထိန္းခ်ဳပ္ႀကသို အခ်ိဳ႕ေသာ အေျခအေနေတြမွာ connectors ေတြရဲ့ အရြယ္အစားနဲ႔ အေသးစိတ္အခ်က္အလက္ေတြကိုလဲ ကိုင္တြယ္ အလုပ္လုပ္ႏိုင္ပါတယ္၊ UART ေတြနဲ႔ ပက္သက္တဲ့ အားသားမူ ေတြ ကြဲျပားမူေတြကို ေလ့လာလိုရင္ေတာ့ အင္တာနက္မွာ စိတ္ႀကိဳက္ရိုက္ရွာေလ့လာလို႔ရပါတယ္။ အခု အတြက္ေတာ့ UART တို႔လို interface ေတြက embedded devices ေတြမွာ သိပ္အသံုး မ်ားတယ္ဆိုတဲ့ အခ်က္ပါ၊ UART က ဘာ့ေၾကာင့္ အသံုးမ်ားရတာတုန္း ဆိုေတာ့
UART ေတြက Controllers ေတြနဲ႔ microprocessors ေတြအၾကားရွဳပ္ေထြး ၿပီး microprocessor တစ္ခုထဲ ထည့္သြင္း တည္ေဆာက္ဖို႔ ေစ်းႀကီးလွတဲ့ intermediary hardware ေတြကို ေက်ာ္ျဖတ္စရာမလိုပဲ data ေတြကို Controllers ေတြနဲ႔ microprocessors ေတြအၾကား အျပန္အလွန္တိုက္ရိုက္ေပးပို႔ႏိုင္မယ့္ အရိုးရွင္ဆံုးနည္းေတြကို ေထာက္ပံ့ထားေပးလို႔႔ပါ၊ ေအာက္က ပံုမွာေတာ့ UART interface တစ္ခုရဲ့ Central Processing Unit (CPU) ကိုတိုက္ရိုက္ ခ်ိတ္ဆက္ပံုကို ေဖာ္ျပထားပါတယ္၊
UART Serial interfaces ကို video cards, keyboard/mice port နဲ႔ network interface card ကဲ့သိုေသာ computers နဲ႔ အဓီက ခ်ိတ္ဆက္မယ့္ နည္းလမ္းေတြမွာ အသံုးျပဳေနခဲ့ၾကၿပီးပါၿပီ၊ ေရွး ကြန္ျပဴတာေတြမွာ keybaord တို႔ mouse တို႔ monitor တို႔ video output တို႔မပါပါဘူး၊ ဒါေြအစား control interface အျဖစ္ serial port တစ္ခု ပါရွိၿပီးေတာ့ သတ္မွတ္ထားတဲ့ “dumb terminal” (Wyse တို႔လို) ကို အသံုးျပဳသူက ခ်ိတ္ဆက္ရပါတယ္၊ ႏွစ္ေပါင္းမ်ားစြာ ၾကာေအာင္ UART serial port ကေန တစ္ဆင့္ အသံုးျပဳတဲ့ ဒီတစ္နည္းထည္းကပဲ computer ရဲ့ command-line console ကို ၀န္ေရာက္ခြင့္ရတဲ့နည္းျဖစ္ခဲ့ရပါတယ္၊ တကယ္ေတာ့ ေရွးက ျပဳလုပ္ခဲ့တဲ့ original Unix concepts stem ေတြအမ်ားစု မွာလဲ ဒီနည္းပဲသံုးတာပါ၊
ဥပမာ အားျဖင့္ Unix နဲ႔ Linux users ေတြက သူတို႔ရဲ့ terminals ေတြကို TTY တစ္ခု ေပၚမွာ run ျခင္းကို ကၽြမ္းက်င္ေနၾကပါၿပီ၊ ဒီနည္းကိုက ေရွ႕၀ေပသနီက Unix sysesm ေတြကို serial connection ကေန TeleType Write (TTY) ကို ခ်ိတ္ဆက္ၿပီး အသံုးျပဳတဲ့နည္းပါ၊ UART serail intefaces က ပံုစံမ်ိဳးစံုနဲ႔ လာႏိုင္ပါတယ္၊ အရိုး ရွင္းဆံုး ဆုိရင္ေတာ့ wire ၃ ၊ ၄ ေခ်ာင္းေလာက္ပါပါမယ္၊ UART ရဲ့ ရိုးရွင္းပံုဆိုတာထဲမွာ ေစ်းႏွဳန္း အရမ္းေပါျခင္းနဲ႔ ေပါ့ပါး ျခင္းတို႔ပါ၀င္ၿပီး circuit design ထဲကို ထည့္သြင္းဖို႔ လဲ လြန္စြာ မွ လြယ္ကူ လွပါတယ္၊ ဒါ့ေၾကာင့္ပဲ UART consoles ေတြကို embedded system အားလံုနည္းပါးမွာေတြ႔ရတာပါ၊ တစ္ခါတစ္ရံ original equipment manufacturers (OEMs) ေတြကေန ထုတ္လုပ္တဲ့ System-on-Chip(Soc) products ေတြထဲ embedded ေတြကို တိုက္ရိုက္ရယူျခင္း မွာလဲ ေတြ႔ႏိုင္တယ္၊ set-top boxes တို႔လို embedded systems ေတြမွာေတာ့ video output ကို ပံုမွန္အားျဖင့္ high-level user interface ကို ရည္ညြန္းပါတယ္၊ ဆက္ရွက္ၿပီးေတာ့ ဒီလို devices ေတြမွာလဲ ကန္႔သတ္ထားတဲ့ user input ေတြရွိတယ္ ဥပမာ dedicated remote လုိမ်ိဳးေပါ့၊ ဒီလို အေျခအေနမွာ ဆိုရင္ေတာ့ market-ready product ေတြမွာ lower-lefvel debug functionality အတြက္ ေရြးခ်ယ္ခြင့္ အခ်ိဳ႕ခ်န္ထားပါလိမ့္မယ္၊ ဒါ့ေၾကာင့္ device ထဲမွာ ျမဳပ္ထားတဲ့ အလြန္ကို debuggin အတြက္ အသံုး၀င္လွေသာ UART serial console ကို developer ေတြဘယ္လို ရွာႏိုင္လာသလဲ ဆိုတာ ကို စဥ္းစားႀကည့္လို႔ရႏုိင္ပါတယ္၊ တကယ္ေတာ့ consumer-grade products ေတြက ဒီ လို interfaces ေတြကို exposed လုပ္ထားတယ္၊ enable လုပ္ေပးထားတယ္၊
What Does an Exposed Serial Interface Mean?
Exposed serial console တစ္ခုကို အသံုးျပဳ၍
Embedded operating system (OS) နဲ႔ intercept လုပ္ျခင္း view ၊ tamper လုပ္၍ တိုက္ရိုက္ ခ်ိ္ဆက္အလုပ္လုပ္ႏိုင္သည့္ျဖစ္ေစ ၊ intra-chip conversation paths ရဲ့ data ေတြကို generate လုပ္ႏိုင္သည္ျဖစ္ေစ ရလာတဲ့ အက်ိဳး ရလဒ္ကေတာ့ အတူတူပါပဲ၊ attack surface ပိုရတာေတြပါပဲ၊ အခန္း ၅ မွာဖတ္ခ့ဲ သလို target attack surface ရဲ့ အရြယ္အစားက အျခား systems ေတြ code ေတြ devices ေတြ users ေတြ အပါ၀င္ သူ႔ကိုယ္ပိုင္ hardware ေတြ နဲ႔ ဘယ္ေလာက္အထိ စိတ္ပိုင္း ခြဲျခား ထားလဲ ဆိုတဲ့ အခ်က္ေပၚမွာ မူတည္ေနပါတယ္၊ ဒီ interface ေတြကို နားလည္သေဘာေပါက္ျခင္းက Adroid မွာသာလွ်င္ Run ေနတဲ့ attack sruface ေတြတင္မကဘဲ အျခား host devices တစ္ခုလံုးရဲ့ attack surface ကိုပိုမို နားလည္ကၽြမ္းက်င္သြားေစမွာပါ၊
Exposed UART on Android and Linux
Embedded Android-base systems မွာေတာ့ exposed UART serail ports မွာ ေတြ႔ရတာ မ်ားပါတယ္၊ ဒီအခ်က္က ေတာ့ underlying operating system ကို တိုက္ရိုက္ ခ်ိတ္ဆက္ဆက္သြယ္ႏိုင္မယ့္ အခ်က္ပါ၊ ဒီစာအုပ္မွာ အေသးစိတ္ ေဆြးေႏြး ခဲ့သလိုပါပဲ၊ Android နဲ႔ တိုက္ရိုက္ခ်ိတ္ဆက္မယ့္ နည္းလမ္းက Android Debug Bridge (ADB) လို႔ေျပာခဲ့ပါတယ္၊ ဒါေပသည့္ UART ကို expose ျဖစ္ေစတဲ့ Kenral compile-time options ကို အသံုးျပဳၿပီး Android-based embedded systems အတြက္ compile လုပ္တာကေတာ့ ေတြ႔ရမ်ားတဲ့ အခ်က္တစ္ခုျဖစ္ပါတယ္၊
CONFIG_SERIAL_MSM
CONFIG_SERIAL_MSM_CONSOLE
ထို႔ေနာက္ေတာ့ boot loader ကိုသံုးမယ္၊ uBoot တို႔ X-Loader တို႔လို ၊ သူတို႔ကို သံုးၿပီးေတာ့ kernal seraial port ရဲ့ configuration options ကို boot-time optin ျဖစ္ေသာ ေအာက္က လို
"console=ttyMSM2,115200n8"
ဒီအေျခအေနမွာဆိုရင္ “stdout” , “stderr” နဲ႔ “debug” ေတြကို serial console သို႔ rout လုပ္မယ္ prints ထုတ္မယ္၊ အကယ္၍ Android သို႔ standard linux နဲ႔ login ေတြက boot sequence ေတြထဲမွာ Run ေနခဲ့ရင္ login prompt ကလဲ ဒီေနရာမွာ ေပၚလာမယ္၊
Configuration setting က အထူးသျဖင့္ Qualcomm MSM-base chipset ေတြအတြက္ compile လုပ္ဖို႔ သီးသန္႔ျဖစ္ပါတယ္၊ ဒါေပမယ့္ အျခား chippsets ေတြအတြက္ သံုးတဲ့အခါလဲ ဒိ idea ကိုပဲ အသံုးျပဳသြားမွာျဖစ္ပါတယ္၊ ဒီ interfaces ေတြႏွင့္ အတူ Device boot ကို ပံုမွန္ေစာင့္ၾကည့္ႏိုင္ပါတယ္ print debug လုပ္ႏိုင္တယ္၊ diagnositc message (syslog (or) dmesg) တို႔လို၊ command shell သံုးၿပီးေတာ့ေတာင္ interface ေတြနဲ႔ ခ်ိတ္ဆက္အလုပ္လုပ္ႏိုင္ပါေသးတယ္၊ ေအာက္က ပံုမွာ set-top box တစ္ခုရဲ့ UART pin ေတြကို ေဖာ္ျပထားပါတယ္
သင့္ေလွ်ာ္တဲ့ pins တစ္ခုကို circut board မွာ ခ်ိတ္ဆက္တဲ့ အခါ ပံု 13-2 မွာျပထားတဲ့ အခ်က္တစ္ခ်ဳ႕ကို အသံုးျပဳ ဦးေဆာင္ၿပီးေတာ့ root shell ကို embedded Android Operating System ေပၚမွာရရွိေစပါတယ္၊ ဒီနည္း အတိုင္းသံုးၿပီးေတာ့ Broadcom-base cable model နဲ႔ Customized Real-time operation system ကို စိတ္ႀကိဳက္ ျပဳျပင္ႏိုင္ပါတယ္၊ Broadcom ရဲ့ UART ေပးမွာ shell interactive မရွိေပမယ့္ Devic Internet Protocol (IP) ကို fuzz လုပ္တဲ့အခါမွာေတာ့ UART ေပၚမွာ stack tracks ကိုေဖာ္ျပေပးလိမ့္မယ္၊ ဒီအခ်က္က exploitation process ကို အတိအက် သတင္းေပးတယ္၊ အခုသံုးတဲ့ device အတြက္ UART pins ကိုေတာ့ ေအာက္က ပံုမွာေတြ႔ႏိုင္ပါတယ္။
No comments:
Post a Comment