একজন ডেভেলপারের জন্য একটি টাস্ক, বা আমরা কীভাবে হ্যান্ড-হোল্ড স্ক্যানারগুলি বিক্রেতা ছাড়াই ফ্ল্যাশ করি৷

হাই সবাই

আজ ভিক্টর অ্যান্টিপভ এবং ইলিয়া আলেশিন পাইথন পাইইউএসবি (PyUSB) ব্যবহার করে ইউএসবি ডিভাইস নিয়ে কাজ করার অভিজ্ঞতা এবং রিভার্স ইঞ্জিনিয়ারিং সম্পর্কে কিছু কথা বলবেন।

প্রাগঐতিহাসিক

২০১৯ সালে, রুশ সরকারের ২২৪ নং প্রস্তাবনা "তামাকজাত পণ্যে শনাক্তকরণ চিহ্ন ব্যবহারের নিয়মাবলী এবং তামাকজাত পণ্যের ক্ষেত্রে বাধ্যতামূলকভাবে শনাক্তকরণ চিহ্ন ব্যবহারের আওতাধীন পণ্যের চলাচল পর্যবেক্ষণের জন্য একটি রাষ্ট্রীয় তথ্য ব্যবস্থা বাস্তবায়নের বিশদ বিবরণের অনুমোদন সংক্রান্ত" কার্যকর হয়।
দলিলটিতে ব্যাখ্যা করা হয়েছে যে, ১ জুলাই, ২০১৯ থেকে প্রস্তুতকারকদের তামাকের প্রতিটি প্যাকেটে লেবেল লাগানো বাধ্যতামূলক। সরাসরি পরিবেশকদের অবশ্যই একটি সার্বজনীন হস্তান্তর নথি (ইউটিডি) সহ এই পণ্যগুলি গ্রহণ করতে হবে। এর ফলস্বরূপ, দোকানগুলিকে চেকআউটে লেবেলযুক্ত পণ্যগুলির বিক্রয় নিবন্ধন করতে হবে।

এছাড়াও, ১ জুলাই, ২০২০ থেকে, চিহ্নবিহীন তামাকজাত পণ্যের প্রচলন নিষিদ্ধ করা হয়েছে। এর অর্থ হলো, সিগারেটের সমস্ত প্যাকেটে একটি বিশেষ ডেটাম্যাট্রিক্স বারকোড অবশ্যই থাকতে হবে। গুরুত্বপূর্ণ বিষয় হলো, এটি প্রকাশ করা হয়েছে যে ডেটাম্যাট্রিক্সটি কোনো সাধারণ বারকোড হবে না, বরং এটি হবে একটি বিপরীতধর্মী বারকোড। অর্থাৎ, সাদা কোডের উপর কালো কোড নয়, বরং তার উল্টোটা।

আমরা আমাদের স্ক্যানারগুলো পরীক্ষা করে দেখলাম যে, সেগুলোর বেশিরভাগকেই পুনরায় প্রোগ্রাম বা প্রশিক্ষণ দেওয়ার প্রয়োজন ছিল, নইলে সেগুলো এই বারকোডটির সাথে ঠিকমতো কাজ করছিল না। এই ঘটনাটি আমাদের জন্য এক বিরাট মাথাব্যথার কারণ হয়ে দাঁড়াল, কারণ আমাদের কোম্পানির বিশাল এলাকা জুড়ে অসংখ্য দোকান ছড়িয়ে ছিটিয়ে আছে। হাজার হাজার চেকআউট – আর হাতে সময় খুবই কম।

আমাদের কী করা উচিত? দুটি বিকল্প আছে। প্রথমত, প্রকৌশলীরা ঘটনাস্থলে থেকে ম্যানুয়ালি স্ক্যানারগুলো রিফ্ল্যাশ এবং ফাইন-টিউন করবেন। দ্বিতীয়ত, দূর থেকে কাজ করা এবং সবচেয়ে ভালো হয় যদি একবারে একাধিক স্ক্যানারের কাজ সম্পন্ন করা যায়।

প্রথম বিকল্পটি স্পষ্টতই আমাদের জন্য অনুপযুক্ত ছিল: আমাদের প্রকৌশলীদের পরিদর্শনের জন্য অর্থ ব্যয় করতে হতো এবং প্রক্রিয়াটি পর্যবেক্ষণ ও সমন্বয় করা কঠিন হতো। কিন্তু সবচেয়ে গুরুত্বপূর্ণ বিষয় হলো, এতে লোকবল জড়িত থাকতো, যার ফলে আমরা সম্ভাব্য অসংখ্য ত্রুটির সম্মুখীন হতাম এবং সম্ভবত নির্ধারিত সময়সীমাও পার করে ফেলতাম।

দ্বিতীয় বিকল্পটি নিখুঁত হতো, কিন্তু একটি সমস্যা ছিল। কিছু বিক্রেতার কাছে আমাদের প্রয়োজনীয় সমস্ত অপারেটিং সিস্টেমের জন্য দরকারি রিমোট ফ্ল্যাশিং টুল ছিল না। আর যেহেতু সময়সীমা খুব কম ছিল, তাই আমাদের নিজেদেরই এর সমাধান বের করতে হয়েছিল।

এরপরে, আমরা আপনাদের জানাবো কিভাবে আমরা ডেবিয়ান ৯.এক্স চালিত হ্যান্ডহেল্ড স্ক্যানারের জন্য টুল তৈরি করেছি (আমাদের সমস্ত চেকআউট ডেবিয়ানে করা হয়েছে)।

ধাঁধাটি সমাধান করুন: কীভাবে একটি স্ক্যানার ফ্ল্যাশ করবেন

ভিক্টর অ্যান্টিপভ গল্পটি বলেছেন।

বিক্রেতার দেওয়া অফিসিয়াল ইউটিলিটিটি উইন্ডোজে কাজ করে, কিন্তু শুধুমাত্র ইন্টারনেট এক্সপ্লোরারের সাথে। এটি স্ক্যানারটিকে ফ্ল্যাশ ও কনফিগার করতে পারে।

যেহেতু আমাদের টার্গেট সিস্টেম ডেবিয়ান, তাই আমরা ডেবিয়ানে ইউএসবি-রিডাইরেক্টর সার্ভার এবং উইন্ডোজে ইউএসবি-রিডাইরেক্টর ক্লায়েন্ট ইনস্টল করেছি। ইউএসবি-রিডাইরেক্টর ইউটিলিটি ব্যবহার করে, আমরা স্ক্যানারটিকে লিনাক্স মেশিন থেকে উইন্ডোজ মেশিনে রিডাইরেক্ট করেছি।

বিক্রেতার উইন্ডোজ ইউটিলিটি স্ক্যানারটি শনাক্ত করেছে এবং সফলভাবে ফ্ল্যাশও করেছে। সুতরাং, আমাদের প্রথম সিদ্ধান্ত হলো: এর সাথে অপারেটিং সিস্টেমের কোনো সম্পর্ক নেই; সমস্যাটি ফ্ল্যাশিং প্রোটোকলের মধ্যেই রয়েছে।

ঠিক আছে। আমরা উইন্ডোজ মেশিনে ফার্মওয়্যার আপডেট শুরু করেছি এবং লিনাক্স মেশিনটি ডাম্প করেছি।

আমরা ডাম্পটি ওয়্যারশার্কে ঢুকিয়ে দিলাম এবং... মনটা খারাপ হয়ে গেল (ডাম্পের কিছু বিবরণ আমি বাদ দিচ্ছি, ওগুলো আগ্রহের বিষয় নয়)।

ডাম্পটি আমাদের যা দেখিয়েছে:

Wireshark অনুযায়ী, 0000-0030 অ্যাড্রেসগুলো হলো USB সার্ভিস সংক্রান্ত তথ্য।

আমরা 0040-0070 অংশটিতে আগ্রহী ছিলাম।

একমাত্র ট্রান্সমিশন ফ্রেমটি থেকে MOCFT প্রতীকগুলো ছাড়া আর কিছুই স্পষ্ট ছিল না। দেখা গেল যে এই প্রতীকগুলো ফার্মওয়্যার ফাইল থেকে এসেছে, এবং ফ্রেমের শেষ পর্যন্ত বাকি প্রতীকগুলোও সেখান থেকেই এসেছে (ফার্মওয়্যার ফাইলটি হাইলাইট করা আছে):

ব্যক্তিগতভাবে, ইলিয়ার মতোই আমারও কোনো ধারণা ছিল না যে fd 3e 02 01 fe প্রতীকগুলোর অর্থ কী।

আমি নিম্নলিখিত ফ্রেমটি দেখলাম (এখান থেকে পরিষেবা সংক্রান্ত তথ্য মুছে ফেলা হয়েছে, ফার্মওয়্যার ফাইলটি হাইলাইট করা হয়েছে):

কী স্পষ্ট হলো? যে প্রথম দুটি বাইট এক ধরনের ধ্রুবক। পরবর্তী সমস্ত ব্লক এটি নিশ্চিত করেছে, কিন্তু ট্রান্সমিশন ব্লকের একেবারে শেষে এসে তা স্পষ্ট হয়:

এই ফ্রেমটিও আমাকে বিভ্রান্ত করেছিল, কারণ ধ্রুবকটি (হাইলাইট করা) পরিবর্তিত হয়েছিল এবং আশ্চর্যের বিষয় হলো, ফাইলটির একটি অংশ সেখানে উপস্থিত ছিল। স্থানান্তরিত বাইটগুলোর আকার থেকে দেখা যাচ্ছিল যে ১০২৪ বাইট স্থানান্তরিত হয়েছে। বাকি বাইটগুলোর অর্থ কী—সে সম্পর্কেও আমার কোনো ধারণা ছিল না।

একজন অভিজ্ঞ বিবিএস ব্যবহারকারী হিসেবে আমি প্রথমেই যা করেছিলাম, তা হলো প্রচলিত ট্রান্সমিশন প্রোটোকলগুলো পর্যালোচনা করা। সেগুলোর কোনোটিই ১০২৪ বাইট প্রেরণ করতে পারত না। আমি হার্ডওয়্যার নিয়ে গবেষণা শুরু করি এবং ঘটনাক্রমে ১কে এক্সমোডেম প্রোটোকলটির সন্ধান পাই। এটি ১০২৪ বাইট প্রেরণের সুযোগ দিত, কিন্তু একটি শর্ত ছিল: প্রাথমিকভাবে মাত্র ১২৮ বাইট, এবং কোনো ত্রুটি না থাকলেই কেবল প্রোটোকলটি প্রেরিত বাইটের পরিমাণ বাড়াত। আমি সাথে সাথেই ১০২৪ বাইট প্রেরণ করতে পারছিলাম। আমি ট্রান্সমিশন প্রোটোকল, বিশেষ করে এক্সমোডেম নিয়ে পড়াশোনা করার সিদ্ধান্ত নিলাম।

মোডেমটির দুটি সংস্করণ ছিল।

প্রথমত, CRC8 সমর্থন সহ XMODEM প্যাকেট ফরম্যাট (মূল XMODEM):

দ্বিতীয়ত, CRC16 সমর্থন সহ XMODEM প্যাকেট ফরম্যাট (XmodemCRC):

SOH, প্যাকেজ নম্বর, CRC এবং প্যাকেজের দৈর্ঘ্য ছাড়া বাকি সব দিক দিয়ে দেখতে একই রকম।

আমি দ্বিতীয় ট্রান্সমিশন ব্লকের শুরুতে তাকালাম (এবং আবারও ফার্মওয়্যার ফাইলটি দেখলাম, কিন্তু ১০২৪ বাইটের একটি ইনডেন্ট সহ):

আমি একটি পরিচিত হেডার দেখলাম, fd 3e 02, কিন্তু পরের দুটি বাইট ইতিমধ্যেই বদলে গিয়েছিল: এটি ছিল 01 fe, এখন 02 fd। তখন আমি লক্ষ্য করলাম যে দ্বিতীয় ব্লকটির নম্বর এখন 02, এবং এভাবেই বুঝতে পারলাম: এটি একটি ট্রান্সফার ব্লকের নম্বরিং। প্রথম 1024 ট্রান্সফার হলো 01, দ্বিতীয়টি 02, তৃতীয়টি 03, এবং এভাবেই চলতে থাকে (অবশ্যই হেক্সে)। কিন্তু fe থেকে fd-তে এই পরিবর্তনের অর্থ কী? আমার চোখ দেখল ১ কমে গেছে, আমার মস্তিষ্ক মনে করিয়ে দিল যে প্রোগ্রামাররা ০ থেকে গণনা করে, ১ থেকে নয়। কিন্তু তাহলে প্রথম ব্লকটি ১ কেন, ০ নয় কেন? আমি এই প্রশ্নের উত্তর কখনোই খুঁজে পাইনি। কিন্তু আমি বুঝতে পেরেছিলাম দ্বিতীয় ব্লকটি কীভাবে গণনা করা হয়। দ্বিতীয় ব্লকটি আর কিছুই নয়, প্রথম ব্লকের নম্বর থেকে FF – (বিয়োগ)। এইভাবে, দ্বিতীয় ব্লকটিকে = 02 (FF-02) = 02 FD হিসাবে চিহ্নিত করা হয়েছিল। পরবর্তীতে ডাম্পটি পড়ে আমার অনুমানটি নিশ্চিত হয়েছিল।

এরপর সম্প্রচারটির নিম্নলিখিত চিত্রটি ফুটে উঠতে শুরু করল:

সংক্রমণ শুরু
fd 3e 02 – শুরু
01 FE – ট্রান্সমিশন কাউন্টার
প্রেরণ (৩৪টি ব্লক, ১০২৪ বাইট স্থানান্তরিত)
fd 3e ১০২৪ বাইট ডেটা (৩০-বাইট ব্লকে বিভক্ত)।
সংক্রমণ শেষ
fd 25

ডেটা এখনও ১০২৪ বাইটে বিন্যস্ত করা বাকি আছে।

ব্লক ট্রান্সমিশন ফ্রেমের শেষ প্রান্তটি দেখতে কেমন:

fd 25 হলো ব্লক ট্রান্সমিশন শেষ করার সংকেত। এরপর 2f 52 হলো ১০২৪ বাইট পর্যন্ত ফাইলের অবশিষ্ট অংশ। প্রোটোকল অনুযায়ী, 2f 52 হলো ১৬-বিটের CRC চেকসাম।

অভ্যাসবশত, আমি C-তে একটি প্রোগ্রাম তৈরি করেছিলাম যা একটি ফাইল থেকে ১০২৪ বাইট ডেটা নিয়ে ১৬-বিটের CRC গণনা করত। প্রোগ্রামটি চালানোর পর দেখা গেল যে এটি ১৬-বিটের CRC নয়। আবারও আমি প্রায় তিন দিন ধরে কিংকর্তব্যবিমূঢ় হয়ে ছিলাম। এই পুরোটা সময় আমি এটা বোঝার চেষ্টা করছিলাম যে, যদি এটি চেকসাম না হয়, তাহলে আর কী হতে পারে। ইংরেজি ভাষার ওয়েবসাইটগুলোতে গবেষণা করতে গিয়ে আমি জানতে পারলাম যে, এক্স-মোডেম (X-modem) তাদের নিজস্ব চেকসাম গণনা পদ্ধতি ব্যবহার করে—CRC-CCITT (XModem)। আমি এই গণনার কোনো C ইমপ্লিমেন্টেশন খুঁজে পাইনি, কিন্তু এমন একটি ওয়েবসাইট খুঁজে পেয়েছিলাম যা অনলাইনে এই চেকসামটি গণনা করত। তাদের ফাইল থেকে ১০২৪ বাইট একটি ওয়েব পেজে আপলোড করার পর, ওয়েবসাইটটি আমাকে এমন একটি চেকসাম দেখায় যা ফাইল থেকে পাওয়া চেকসামের সাথে পুরোপুরি মিলে যায়।

হুররে! শেষ ধাঁধাটার সমাধান হয়ে গেল, এখন আমার নিজের ফার্মওয়্যার তৈরি করার দরকার ছিল। এরপর, আমি আমার জ্ঞান (যা কেবল আমার মাথায়ই ছিল) ইলিয়ার কাছে হস্তান্তর করলাম, যে পাইথন নামক একটি শক্তিশালী টুলকিটের সাথে পরিচিত।

একটি প্রোগ্রাম তৈরি করা

ইলিয়া আলেশিন গল্পটি বলছেন।

প্রাসঙ্গিক নির্দেশনাগুলো পেয়ে আমি অত্যন্ত “আনন্দিত” হয়েছিলাম।

কোথা থেকে শুরু করবেন? ঠিক ধরেছেন, একেবারে গোড়া থেকে।  ইউএসবি পোর্টটি বাদ দিয়ে।

ইউএসবি-পিক্যাপ চালু করুন https://desowin.org/usbpcap/tour.html

ডিভাইসটি যে পোর্টের সাথে সংযুক্ত আছে সেটি এবং যে ফাইলে আমরা ডাম্পটি সংরক্ষণ করব তা নির্বাচন করুন।

আমরা স্ক্যানারটিকে এমন একটি মেশিনের সাথে সংযুক্ত করি যেখানে উইন্ডোজের জন্য নিজস্ব EZConfigScanning সফটওয়্যারটি ইনস্টল করা আছে।

সেখানে আমরা ডিভাইসটিতে কমান্ড পাঠানোর অপশন পাই। কিন্তু কমান্ডগুলো কী? আমি সেগুলো কোথায় পাব?
প্রোগ্রামটি শুরু হলে, সরঞ্জামটি স্বয়ংক্রিয়ভাবে কোয়েরি করা হয় (আমরা এটি একটু পরে দেখব)। সরঞ্জামটির অফিসিয়াল ডকুমেন্টেশন থেকে প্রশিক্ষণ বারকোডও ছিল। ডিফল্ট। এটি আমাদের দল।

প্রয়োজনীয় ডেটা সংগ্রহ করা হয়েছে। Wireshark ব্যবহার করে dump.pcap ফাইলটি খুলুন।

EZConfigScanning শুরু হলে ব্লক করুন। যেসব অংশে মনোযোগ প্রয়োজন, সেগুলো লাল রঙে চিহ্নিত করা হয়েছে।

এই সবকিছু প্রথমবার দেখে আমি হতাশ হয়ে পড়লাম। এরপর কোথায় খনন করব তা স্পষ্ট ছিল না।

একটু চিন্তাভাবনা করার পর... আহা! আবর্জনার স্তূপে। বাইরে - হয় inএবং in এটা বাইরে.

আমি URB_INTERRUPT লিখে গুগল সার্চ করে জানতে পারলাম যে এটি একটি ডেটা ট্রান্সফার পদ্ধতি। এই পদ্ধতির চারটি ধরন রয়েছে: কন্ট্রোল, ইন্টারাপ্ট, আইসোক্রোনাস এবং বাল্ক। আপনি এগুলো সম্পর্কে আলাদাভাবে পড়ে নিতে পারেন।

এবং ইউএসবি ডিভাইস ইন্টারফেসের এন্ডপয়েন্ট অ্যাড্রেসটি “lsusb –v” কমান্ডের মাধ্যমে অথবা pyusb ব্যবহার করে পাওয়া যায়।

এখন আমাদের এই VID যুক্ত সমস্ত ডিভাইস খুঁজে বের করতে হবে। আপনি VID:PID ব্যবহার করে নির্দিষ্টভাবে অনুসন্ধান করতে পারেন।

এটা দেখে মনে হচ্ছে:

সুতরাং, আমাদের কাছে প্রয়োজনীয় তথ্য রয়েছে: P_INFO বা DEFALT কমান্ডগুলো, কমান্ডগুলো লেখার ঠিকানা (এন্ডপয়েন্ট=03) এবং প্রতিক্রিয়া গ্রহণের ঠিকানা (এন্ডপয়েন্ট=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 আমি এটি পড়ার সুপারিশ করছি।

ডাম্পটি দেখলে বোঝা যায় যে, ফ্রেম সাইজ হলো ১০২৪ এবং ইউআরবি-ডেটা সাইজ হলো ৬৪।

অতএব – ১০২৪/64 – আমরা একটি ব্লকে ১৬টি লাইন পাই, ফার্মওয়্যার ফাইলটি থেকে একবারে একটি করে অক্ষর পড়ি এবং ব্লকটি তৈরি করি। আমরা ব্লকের শেষে বিশেষ অক্ষর fd3e02 + ব্লক নম্বরটি যুক্ত করি।
আমরা পরবর্তী ১৪টি লাইনের সাথে fd25 + যুক্ত করি, XMODEM.calc_crc() ব্যবহার করে পুরো ব্লকটির চেকসাম গণনা করি (এটা বুঝতে অনেক সময় লেগেছিল যে “FF – 1” হলো CSUM) এবং শেষ, অর্থাৎ ১৬তম লাইনের সাথে fd3e যুক্ত করি।

দেখে মনে হতে পারে যে এটুকুই: ফার্মওয়্যার ফাইলটি পড়ুন, ব্লকগুলোতে ক্লিক করুন, কোর থেকে স্ক্যানারটির সংযোগ বিচ্ছিন্ন করুন এবং ডিভাইসটিতে পাঠিয়ে দিন। কিন্তু ব্যাপারটা এত সহজ নয়। স্ক্যানারটিকে ফার্মওয়্যার মোডে আনতে হবে।
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
এই কমান্ডটি কোথা থেকে আসে? একটি ডাম্প থেকে।

কিন্তু ৬৪-এর সীমাবদ্ধতার কারণে আমরা পুরো ব্লকটি স্ক্যানারে পাঠাতে পারি না:

এবং 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]

আপনি যদি এক্সমোডেম সম্পর্কিত নিবন্ধটি দেখেন, তাহলে বিষয়টি পরিষ্কার হয়ে যাবে: ডেটা পাওয়া গেছে।

সমস্ত ব্লক স্থানান্তরিত হয়ে গেলে, আমরা স্থানান্তরটি সম্পন্ন করি END_TRANSFER = 'xfdx01x04'।

যেহেতু এই ব্লকগুলো সাধারণ মানুষকে কোনো তথ্য দেয় না, তাই আমরা ডিফল্টভাবে ফার্মওয়্যারটি স্টিলথ মোডে চালাব। আর সাবধানতার জন্য, আমরা tqdm ব্যবহার করে একটি প্রোগ্রেস বার সেট আপ করব।

এখন শুধু বাকি আছে সমাধানটিকে স্ক্রিপ্টের মধ্যে আবদ্ধ করা, যাতে একটি সুস্পষ্ট সময়ে ব্যাপক হারে এটি স্থাপন করা যায় এবং চেকআউট প্রক্রিয়ার গতি কমে না যায়, আর লগিং যুক্ত করা।

ফলাফল

প্রচুর সময় ও শ্রম বিনিয়োগের পর, আমরা আমাদের প্রয়োজনীয় সমাধানগুলো তৈরি করতে সক্ষম হয়েছি এবং নির্ধারিত সময়সীমাও মেনে চলেছি। অধিকন্তু, স্ক্যানারগুলো এখন কেন্দ্রীয়ভাবে পুনঃপ্রোগ্রাম ও পুনঃপ্রশিক্ষণ দেওয়া হয়, যা আমাদের পুরো প্রক্রিয়াটির উপর নিখুঁত নিয়ন্ত্রণ প্রদান করে। কোম্পানিটির সময় ও অর্থ সাশ্রয় হয়েছে এবং আমরা এই ধরনের যন্ত্রপাতির রিভার্স ইঞ্জিনিয়ারিং বিষয়ে অমূল্য অভিজ্ঞতা অর্জন করেছি।

উত্স: www.habr.com