हम परित्यक्त उपकरणों के लिए USB ड्राइवर लिखते हैं

हाल ही में ईबे पर मुझे दिलचस्प USB डिवाइसेस (एपिफ़ैन VGA2USB LR) का एक बैच मिला, जो VGA इनपुट प्राप्त करता है और एक वेब कैमरा के रूप में USB पर वीडियो भेजता है। मैं इस विचार से बहुत खुश था कि मुझे वीजीए मॉनिटर के साथ फिर से परेशान नहीं करना पड़ेगा, और लिनक्स के लिए घोषित समर्थन दिया, मैंने एक मौका लिया और पूरे बैच को लगभग 20 पाउंड (25 अमेरिकी डॉलर) में खरीदा।

पैकेज प्राप्त करने के बाद, मैंने डिवाइस को कनेक्ट किया, लेकिन इसे सिस्टम में UVC के रूप में प्रदर्शित करने के लिए भी नहीं सोचा था। क्या गलत है?

मैंने निर्माता की वेबसाइट का अध्ययन किया और पाया कि काम करने के लिए एक विशेष ड्राइवर की आवश्यकता थी। मेरे लिए, यह एक नई अवधारणा थी, क्योंकि मेरे लिनक्स वितरण के कर्नेल में आमतौर पर सभी उपकरणों के लिए ड्राइवर होते हैं।

दुर्भाग्य से, इन 4.9 डिवाइसों के लिए ड्राइवर समर्थन लिनक्स 4.9 में समाप्त हो गया। इस प्रकार, मेरा कोई भी सिस्टम इसे नहीं देखेगा (लिनक्स 4.19 पर डेबियन 10 या लिनक्स 5.0 पर एलटीएस उबंटू का नवीनतम संस्करण)।

लेकिन यह तय किया जा सकता है, है ना? बेशक, फाइलें डीकेएमएस पैकेज में आती हैं, जो मांग पर, ड्राइवर को कई सामान्य ड्राइवरों की तरह, स्रोत कोड से इकट्ठा करती हैं ...

यह दुखद है। लेकिन यहां ऐसा नहीं है।

पैकेज के अंदर केवल precompiled बाइनरी vga2usb.o । मैंने इसका अध्ययन करना शुरू किया, रिवर्स इंजीनियरिंग की जटिलता को आश्चर्यचकित किया, और कुछ दिलचस्प लाइनें पाईं:

 $ strings vga2usb.ko | grep 'v2uco' | sort | uniq v2ucom_autofirmware v2ucom_autofirmware_ezusb v2ucom_autofirmware_fpga 

तो क्या यह वास्तव में एफपीजीए -ए-स्टिक है? इस काम को कैसे करना है?

एक और मज़ेदार और थोड़ा परेशान करने वाला डीएसए निजी प्रमुख मापदंडों के साथ लाइन थी। यह मुझे आश्चर्यचकित करता है: यह चालक के अंदर क्या सुरक्षा कर सकता है?

 $ strings vga2usb.ko | grep 'epiphan' | sort | uniq epiphan_dsa_G epiphan_dsa_P epiphan_dsa_Q 

अपने सामान्य वातावरण में ड्राइवर का अध्ययन करने के लिए, मैंने डिवाइस के लिए सीधी पहुँच देने के लिए एक डेबियन 9 वर्चुअल मशीन (अंतिम समर्थित रिलीज़) को उठाया और KVM USB पासस्ट्रॉ को बनाया। फिर मैंने ड्राइवर को स्थापित किया और सुनिश्चित किया कि यह काम करता है।

उसके बाद, मैं देखना चाहता था कि संचार प्रोटोकॉल कैसा दिखता है। मुझे उम्मीद थी कि डिवाइस कच्चे या लगभग कच्चे फ्रेम भेजेगा, क्योंकि इससे यूजर स्पेस के लिए ड्राइवर लिखना आसान होगा।

ऐसा करने के लिए, मैंने वर्चुअल मशीन usbmon पर usbmon मॉड्यूल लोड किया और स्टार्टअप और वीडियो कैप्चर के दौरान डिवाइस से USB ट्रैफ़िक कैप्चर करने के लिए Wireshark लॉन्च किया।



मैंने पाया कि जब लॉन्च किया जाता है, तो तस्वीर पर कब्जा करने से पहले डिवाइस पर बड़ी संख्या में छोटे पैकेट प्रसारित किए जाते हैं। यह संभवतः डेटा स्टोरेज के बिना FPGA प्लेटफॉर्म पर आधारित है। कनेक्ट करने के बाद हर बार, ड्राइवर ने फर्मवेयर को FPGA बिटस्ट्रीम के रूप में डिवाइस में स्थानांतरित कर दिया।

मैं इसमें से एक बॉक्स को खोलकर आश्वस्त हुआ:




चूंकि डिवाइस को "डाउनलोड" करने के लिए आपको इसे एक बिटस्ट्रीम / फ़र्मवेयर भेजने की आवश्यकता है, आपको इसके लिए पहले से तैयार बायनेरिज़ में खोजना होगा। मैंने binwalk -x चलाया और कुछ संकुचित वस्तुओं ( binwalk -x तलाश शुरू कर दी। ऐसा करने के लिए, मैंने एक हेक्स अनुक्रम खोज स्क्रिप्ट लिखी - और इंटरसेप्टेड पैकेट से तीन बाइट्स निर्दिष्ट किए।

 $ bash scan.sh "03 3f 55" trying 0.elf trying 30020 trying 30020.zlib trying 30020.zlib.decompressed ... trying 84BB0 trying 84BB0.zlib trying 84BB0.zlib.decompressed trying AA240 trying AA240.zlib trying AA240.zlib.decompressed 000288d0 07 2f 03 3f 55 50 7d 7c 00 00 00 00 00 00 00 00 |./.?UP}|........| trying C6860 trying C6860.zlib 

AA240.zlib फ़ाइल को अनपैक करने के बाद, यह पता चला कि पूर्ण बिटस्ट्रीम के लिए वहां पर्याप्त डेटा नहीं था। इसलिए मैंने फर्मवेयर को यूएसबी पैकेज से हथियाने का फैसला किया।

Tshark और tcpdump दोनों pcap फ़ाइलों से USB पैकेट पढ़ सकते हैं , लेकिन दोनों ही उन्हें आंशिक रूप से बचाते हैं। चूंकि प्रत्येक उपयोगिता में पहेली के अलग-अलग हिस्से थे, इसलिए मैंने एक छोटा प्रोग्राम लिखा जो पैकेट में डिवाइस को वापस चलाने के लिए दोनों कार्यक्रमों के आउटपुट को गो संरचनाओं में जोड़ता है।

इस बिंदु पर, मैंने देखा कि डाउनलोड दो चरणों में होता है: पहला USB नियंत्रक, और फिर FPGA।

मैं कई दिनों से अटका हुआ था: ऐसा लग रहा था कि पूरी बिटस्ट्रीम लोड हो रही है, लेकिन डिवाइस शुरू नहीं हुआ, हालांकि असली ड्राइवर और मेरे सिमुलेशन के पैकेज समान दिखते हैं।

अंत में, मैंने प्रत्येक पैकेट के लिए प्रतिक्रिया समय को ध्यान में रखते हुए समस्या की जांच करके समस्या का हल किया - और एक विशिष्ट पैकेज में एक बड़े समय के अंतर पर ध्यान दिया:



यह पता चला कि एक छोटे टाइपो के कारण , डिवाइस के गलत क्षेत्र में रिकॉर्डिंग हुई। यह मेरे लिए एक सबक होगा कि कैसे मैन्युअल रूप से मान दर्ज करें ...

हालांकि, एलईडी आखिरकार डिवाइस पर झपकी ले गया! बहुत बड़ी उपलब्धि!


डेटा पैकेज को ट्रिगर करने वाले समान पैकेजों को दोहराने में अपेक्षाकृत आसान था, इसलिए मैं यूएसबी बल्क एंडपॉइंट लिख सकता था और डेटा को तुरंत डिस्क में फ्लश कर सकता था!

यहीं से वास्तविक कठिनाइयों की शुरुआत हुई। क्योंकि विश्लेषण के बाद यह पता चला कि डेटा किसी भी तरह से स्पष्ट रूप से एनकोड नहीं किया गया था।

आरंभ करने के लिए, मैं रनटाइम पर ड्राइवर स्टैक ट्रेस का एक मूल विचार प्राप्त करने के लिए पूर्ण भाग गया:



हालाँकि मैं फ़्रेम डेटा के साथ फ़ंक्शंस पकड़ सकता था, लेकिन मैं स्वयं डेटा की एन्कोडिंग को समझ नहीं सका।



असली चालक के अंदर क्या चल रहा है, इसे बेहतर ढंग से समझने के लिए, मैंने एनएसए से भी गिदरा उपकरण की कोशिश की:



हालांकि गिदरा अविश्वसनीय है (जब मैंने पहली बार आईडीए प्रो के बजाय इसका इस्तेमाल किया था), तो यह अभी भी पर्याप्त नहीं है कि मुझे चालक को समझने में मदद मिले। रिवर्स इंजीनियरिंग के लिए एक अलग रास्ते की आवश्यकता थी।

मैंने विंडोज 7 वर्चुअल मशीन को चुनने और विंडोज ड्राइवर पर एक नज़र डालने का फैसला किया, अचानक यह विचारों को फेंक देगा। और फिर मैंने देखा कि उपकरणों के लिए एक एसडीके है। एक उपकरण विशेष रूप से दिलचस्प निकला।

 PS> ls Directory: epiphan_sdk-3.30.3.0007\epiphan\bin Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 10/26/2019 10:57 AM 528384 frmgrab.dll -a--- 10/27/2019 5:41 PM 1449548 out.aw -a--- 10/26/2019 10:57 AM 245760 v2u.exe -a--- 10/26/2019 10:57 AM 94208 v2u_avi.exe -a--- 10/26/2019 10:57 AM 102400 v2u_dec.exe -a--- 10/26/2019 10:57 AM 106496 v2u_dshow.exe -a--- 10/26/2019 10:57 AM 176128 v2u_ds_decoder.ax -a--- 10/26/2019 10:57 AM 90112 v2u_edid.exe -a--- 10/26/2019 10:57 AM 73728 v2u_kvm.exe -a--- 10/26/2019 10:57 AM 77824 v2u_libdec.dll PS> .\v2u_dec.exe Usage: v2u_dec <number of frames> [format] [compression level] <filename> - sets compression level [1..5], - captures and saves compressed frames to a file v2u_dec x [format] <filename> - decompresses frames from the file to separate BMP files 

यह उपकरण आपको एकल फ़्रेम को "हथियाने" की अनुमति देता है, और शुरू में वे संकुचित नहीं होते हैं, ताकि बाद में तेज मशीन पर फ्रेम को संसाधित करना संभव हो। यह लगभग सही है, और मैंने इन असम्पीडित ब्लब्स को प्राप्त करने के लिए यूएसबी पैकेट के अनुक्रम को दोहराया। बाइट्स की संख्या प्रति पिक्सेल लगभग तीन (RGB) के अनुरूप है!

इन छवियों के प्रारंभिक प्रसंस्करण (सिर्फ आउटपुट को स्वीकार करना और इसे आरजीबी पिक्सेल के रूप में लिखना) ने वास्तविक चित्र की कुछ याद ताजा कर दी जो कि डिवाइस को वीजीए के माध्यम से प्राप्त हुई थी:



हेक्स संपादक में कुछ डिबगिंग के बाद, यह पता चला कि प्रत्येक मार्कर को हर 1028 बाइट्स दोहराया जाता है। यह थोड़ा शर्मनाक है कि मैंने एक फिल्टर लिखने में कितना समय बिताया। दूसरी ओर, इस प्रक्रिया में समकालीन कला के कुछ उदाहरणों का आनंद लिया जा सकता है।



तब मुझे महसूस हुआ कि छवि का झुकाव और विरूपण प्रत्येक लाइन पर स्किपिंग और पिक्सेल रैप के कारण होता है (x = 799 x = 800 के बराबर नहीं है)। और फिर, आखिरकार, मुझे लगभग सही छवि मिली, रंग को छोड़कर:



सबसे पहले, मुझे लगा कि वीजीए इनपुट ठोस रंग में फंसने पर अंशांकन समस्या डेटा नमूने के कारण थी। सुधार के लिए, मैंने ऐसी समस्याओं की पहचान करने के लिए एक नई परीक्षण छवि बनाई। हेंडसाइट में , मैं समझता हूं कि आपको फिलिप्स पीएम 5544 टेस्ट कार्ड की तरह कुछ का उपयोग करना था।



मैंने चित्र को लैपटॉप में अपलोड किया है, और इसने ऐसी वीजीए तस्वीर तैयार की है:



फिर मुझे 3D रेंडरिंग / शेडर में कुछ पुराने काम की याद आई। यह YUV कलर स्कीम से काफी मिलता-जुलता था।

नतीजतन, मैं YUV साहित्य को पढ़ने में व्यस्त हो गया और याद आया कि आधिकारिक कर्नेल ड्राइवर के रिवर्स इंजीनियरिंग के दौरान, अगर मैं v2ucom_convertI420toBGR24 नामक फ़ंक्शन पर एक ब्रेकपॉइंट v2ucom_convertI420toBGR24 , तो सिस्टम नवीनीकरण की संभावना के बिना क्रैश हो जाएगा। तो शायद इनपुट I420 एन्कोडिंग ( -pix_fmt yuv420p ) था, और आउटपुट RGB था?

अंतर्निहित गो फ़ंक्शन YCbCrToRGB का उपयोग करने के बाद , छवि अचानक मूल के बहुत करीब हो गई।



हमने कर दिखाया! यहां तक ​​कि कच्चे चालक ने 7 फ्रेम प्रति सेकंड का उत्पादन किया। ईमानदारी से, यह मेरे लिए पर्याप्त है, क्योंकि मैं केवल बैकअप डिस्प्ले के रूप में दुर्घटना के मामले में वीजीए का उपयोग करता हूं।

तो, अब हम इस डिवाइस को अच्छी तरह से जानते हैं कि इसे शुरू करने के लिए एल्गोरिथ्म की व्याख्या करने के लिए बहुत शुरुआत से:

1. आपको USB नियंत्रक को इनिशियलाइज़ करना होगा । जानकारी की मात्रा को देखते हुए, वास्तव में, ड्राइवर इसे डाउनलोड करने के लिए कोड पास करता है।
   
2. जब आप USB लोड करना समाप्त करते हैं, तो डिवाइस USB बस से डिस्कनेक्ट हो जाएगा और एक पल के बाद एक USB समापन बिंदु के साथ वापस आ जाएगा।
   
3. अब आप FPGA बिटस्ट्रीम , प्रत्येक नियंत्रण हस्तांतरण के लिए एक 64-बाइट USB पैकेट भेज सकते हैं।
   
4. हस्तांतरण के अंत में, डिवाइस पर संकेतक हरे रंग का झपकी देगा। इस बिंदु पर, आप भेज सकते हैं कि पैरामीटर (ओवरस्कैन और अन्य गुणों) के अनुक्रम की तरह क्या लगता है।
   
5. फिर फ्रेम प्राप्त करने के लिए नियंत्रण पैकेज चलाएँ, पैकेज निर्दिष्ट अनुमति। यदि आप वाइडस्क्रीन इनपुट के लिए 4: 3 फ्रेम के लिए अनुरोध भेजते हैं, तो यह आमतौर पर फ्रेम को नुकसान पहुंचाएगा।

उपयोग में अधिकतम आसानी के लिए, मैंने ड्राइवर में एक छोटा वेब सर्वर लागू किया। ब्राउज़र-आधारित MediaRecorder API के माध्यम से , यह स्क्रीन से स्ट्रीम से वीडियो फ़ाइल में आसानी से रिकॉर्ड करता है।



प्रायोगिक कोड की गुणवत्ता के अपरिहार्य दावों को रोकते हुए, मैं तुरंत कहूंगा: मुझे इस पर गर्व नहीं है। संभवतः, वह ऐसी अवस्था में है, जो स्वीकार्य उपयोग के लिए मेरे लिए पर्याप्त है।

लिनक्स और OSX के लिए कोड और रेडीमेड बिल्ड GitHub पर हैं ।

यहां तक ​​कि अगर कोई भी कभी भी कार्यक्रम शुरू नहीं करता है, तो मेरे लिए यह यूएसबी प्रोटोकॉल, कर्नेल डीबगिंग, मॉड्यूल रिवर्स इंजीनियरिंग और वीडियो डिकोडिंग प्रारूप के माध्यम से आकर्षक यात्रा का एक नरक था! यदि आप इन चीजों को पसंद करते हैं, तो आप अन्य ब्लॉग पोस्ट देख सकते हैं।