onekey-sec/firmware-workshopइस कार्यशाला सत्र में, हम एक EV चार्जर से फर्मवेयर निकालेंगे, फर्मवेयर की गहराई से जांच करेंगे, और अंततः उसे एम्यूलेट करेंगे ताकि हम वास्तविक समय में सेवाओं के साथ इंटरैक्ट कर सकें।
Unblob, लचीले फर्मवेयर एक्सट्रैक्टर के इस प्रायोगिक डेमो में शामिल हों। इस वर्कशॉप सत्र के दौरान, हम एक EV चार्जर से फर्मवेयर निकालेंगे, फर्मवेयर में गहराई से जाँच करेंगे, और अंततः इसे एमुलेट करेंगे ताकि हम वास्तविक समय में सेवाओं के साथ इंटरैक्ट कर सकें। Unblob हार्डवेयर और डाउनलोड करने योग्य दोनों प्रकार के फर्मवेयर पर काम करता है, इसलिए हमारे पास एक समृद्ध लक्ष्य वातावरण है। किसी पूर्व अनुभव की आवश्यकता नहीं है, यह सत्र सभी कौशल स्तरों के लिए उपयुक्त है और हम आपको वहाँ देखने के लिए उत्सुक हैं।
हमारा लक्ष्य Phoenix Contact का एक इलेक्ट्रिक वाहन चार्जिंग स्टेशन कंट्रोलर है। इसके बारे में अधिक विवरण आप यहाँ पा सकते हैं।
CHARX control modular, AC चार्जिंग कंट्रोलर, एम्बेडेड Linux सिस्टम के साथ, IEC 61851-1, ऑपरेटिंग मोड: Stand-Alone, Client, Server,
इंटरफेस:
- Ethernet (2x)
- Cellular communication (4G/2G)
- CHARX control modular system bus
- MICRO-USB type C
संचार प्रोटोकॉल:
- OCPP 1.6J
- Modbus/TCP
- MQTT
कनेक्ट करने योग्य बाह्य उपकरण:
- Energy meter
- RFID
- DC residual current detection
- DIN rail mounting
इस वर्कशॉप में हमें कुछ टूल्स की आवश्यकता है। आप उन्हें
install-prerequisites स्क्रिप्ट चलाकर इस प्रकार इंस्टॉल कर सकते हैं:```sh
./install-prerequisites
## फर्मवेयर प्राप्त करना
फर्मवेयर विक्रेता की वेबसाइट से प्राप्त किया जा सकता है। इस रिपॉजिटरी में `download-firmware` नामक एक स्क्रिप्ट है जिसका उपयोग आप ब्राउज़र खोले बिना फर्मवेयर खींचने के लिए कर सकते हैं।
हमारा आज का ध्यान विक्रेता द्वारा प्रदान किए गए फर्मवेयर पर है क्योंकि इसमें हमें जो कुछ भी चाहिए वह सब कुछ मौजूद है। लेकिन एक समान वर्कफ़्लो को लाइव डिवाइस से निकाले गए मेमोरी डंप पर भी लागू किया जा सकता है। यहाँ दिलचस्प बात यह है कि हम वास्तविक डिवाइस की आवश्यकता के बिना भी निकाल सकते हैं, अन्वेषण कर सकते हैं, और अनुकरण कर सकते हैं।
## Unblob के साथ निष्कर्षण
आइए यह सुनिश्चित करके शुरू करें कि सभी निर्भरताएँ उपलब्ध हैं:```
unblob --show-external-dependencies
The following executables found installed, which are needed by unblob:
7z ✓
debugfs ✓
jefferson ✓
lz4 ✓
lziprecover ✓
lzop ✓
sasquatch ✓
sasquatch-v4be ✓
simg2img ✓
ubireader_extract_files ✓
ubireader_extract_images ✓
unar ✓
zstd ✓
अब हम unblob के साथ फ़र्मवेयर निकाल सकते हैं:``` unblob CHARXSEC3XXXSoftwareBundleV190.raucb
एक अच्छे लैपटॉप पर निष्कर्षण में लगभग 3 मिनट लगते हैं। आपको एक प्रगति पट्टी ऊपर बढ़ती दिखनी चाहिए:
जब निष्कर्षण पूरा हो जाता है, तो `CHARXSEC3XXXSoftwareBundleV190.raucb_extract`
नामक एक निर्देशिका दिखाई देनी चाहिए। आप उसमें जाकर
सामग्री सूचीबद्ध कर सकते हैं।
### चंक्स, अज्ञात चंक्स
Unblob फ़ाइलों के भीतर डेटा के चंक्स की पहचान करके काम करता है। यदि कोई चंक एक
संपीड़ित स्ट्रीम है, तो उसे डीकंप्रेस किया जाता है। यदि यह एक फ़ाइल सिस्टम या संग्रह है, तो उसे
एक्सट्रैक्ट किया जाता है। यदि एक्सट्रैक्शन या डीकंप्रेसन सफल होता है, तो डिस्क पर
carve किया गया चंक स्थान वापस पाने के लिए हटा दिया जाता है।
यहाँ, एक SquashFS संस्करण 4 लिटिल-एंडियन चंक को डिस्क पर carve किया गया, एक्सट्रैक्ट किया गया
और हटा दिया गया। फ़ाइलों (और इसलिए निष्कर्षण निर्देशिकाओं) का नामकरण
`{start_offset}-{end_offset}.{type}` नामकरण प्रणाली के अनुसार किया जाता है।
हम देख सकते हैं कि squashfs फ़ाइल सिस्टम के बाद 11KB का "unknown" चंक दिखाई देता है।```
./0-132173824.squashfs_v4_le_extract
./132173824-132184833.unknown
आप यह देखने के लिए इस पर binwalk चला सकते हैं कि इसमें क्या है:```
binwalk 132173824-132184833.unknown
0 0x0 Object signature in DER format (PKCS header length: 4, sequence length: 10997 58 0x3A Certificate in DER format (x509 v3), header length: 4, sequence length: 4372 4434 0x1152 Certificate in DER format (x509 v3), header length: 4, sequence length: 4387
आप openssl के साथ प्रमाणपत्रों की जांच कर सकते हैं:```
dd if=132173824-132184833.unknown bs=1 skip=58 | openssl x509 -in /dev/stdin -inform der -noout -text
dd if=132173824-132184833.unknown bs=1 skip=4434 | openssl x509 -in /dev/stdin -inform der -noout -text
इसका मतलब है कि फ़र्मवेयर संभवतः विक्रेता की निजी कुंजी से हस्ताक्षरित होते हैं ताकि डिवाइस यह सुनिश्चित कर सकें कि फ़र्मवेयर प्रामाणिक हैं।
यह unblob का एक लाभ है, अज्ञात अज्ञात को ज्ञात अज्ञात में बदलना जिनकी जाँच की जा सकती है।
आइए अपने squashfs फ़ाइल सिस्टम की सामग्री देखें:``` ls -al 0-132173824.squashfs_v4_le_extract total 460532 drwxrwxr-x 4 kali kali 4096 dec 5 09:51 . drwxrwxr-x 3 kali kali 4096 dec 5 09:51 .. -rw-rw-r-- 1 kali kali 20971520 sep 8 09:59 bootimg.vfat drwxrwxr-x 3 kali kali 4096 dec 5 09:51 bootimg.vfat_extract -rwxrwxr-x 1 kali kali 2654 sep 19 2022 hook -rw-rw-r-- 1 kali kali 442 sep 8 09:59 manifest.raucm -rw-rw-r-- 1 kali kali 450584576 sep 8 09:59 root.ext4 drwxrwxr-x 22 kali kali 4096 sep 8 09:57 root.ext4_extract
हम एक plaintext manifest, एक shell script, एक MBR और एक EXT4 filesystem देख सकते हैं:```
find -maxdepth 1 -type f -exec file {} \;
./manifest.raucm: ASCII text
./hook: a /usr/bin/env sh script, ASCII text executable
./bootimg.vfat: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, reserved sectors 4, root entries 512, sectors 40960 (volumes <=32 MB), Media descriptor 0xf8, sectors/FAT 40, sectors/track 63, heads 255, hidden sectors 163158016, reserved 0x1, serial number 0xd09aad9c, label: "KERNEL ", FAT (16 bit)
./root.ext4: Linux rev 1.0 ext4 filesystem data, UUID=8ed19606-02c4-42e7-9cfb-1a2839f93ec4 (extents) (large files) (huge files)
दोनों bootimg.vfat और root.ext4 को unblob द्वारा संभाला और निकाला गया। VFAT पार्टीशन में बूट और OS (Linux कर्नेल, DTB, TEE) से संबंधित सब कुछ शामिल है:```
oftree: Device Tree Blob version 17, size=27469, boot CPU=0, string block size=1657, DT structure block size=25756
tee.bin: data
zImage: Linux kernel ARM boot executable zImage (little-endian)
zImage-imx6ul-ksp0632.dtb: Device Tree Blob version 17, size=27469, boot CPU=0, string block size=1657, DT structure block size=25756
आप देखेंगे कि unblob थोड़ा लालची है और यह Linux कर्नेल (`zImage`) से एक ELF फ़ाइल और एक CPIO
आर्काइव निकालेगा, ये न्यूनतम
कर्नेल और ramdisk के अनुरूप हैं।
EXT4 फ़ाइलसिस्टम में रूट फ़ाइलसिस्टम होता है जिसे Linux
कर्नेल बूट के समय माउंट करता है:```
ls -alh root.ext4_extract
total 88K
drwxrwxr-x 22 kali kali 4,0K sep 8 09:57 .
drwxrwxr-x 4 kali kali 4,0K dec 5 09:51 ..
drwxrwxr-x 2 kali kali 4,0K dec 5 09:51 bin
drwxrwxr-x 3 kali kali 4,0K dec 5 09:51 boot
drwxrwxr-x 16 kali kali 4,0K sep 8 09:56 data
drwxrwxr-x 2 kali kali 4,0K jul 18 00:09 dev
drwxrwxr-x 53 kali kali 4,0K dec 5 09:51 etc
drwxrwxr-x 18 kali kali 4,0K sep 8 09:56 home
drwxrwxr-x 2 kali kali 4,0K jul 18 03:13 identity
drwxrwxr-x 9 kali kali 4,0K dec 5 09:51 lib
drwxrwxr-x 2 kali kali 4,0K jul 18 03:14 log
drwxrwxr-x 2 kali kali 4,0K sep 8 09:57 lost+found
drwxrwxr-x 2 kali kali 4,0K jul 18 00:09 media
drwxrwxr-x 2 kali kali 4,0K jul 18 00:09 mnt
drwxrwxr-x 2 kali kali 4,0K jul 18 00:09 proc
drwxrwxr-x 2 kali kali 4,0K sep 8 09:57 run
drwxrwxr-x 2 kali kali 4,0K dec 5 09:51 sbin
drwxrwxr-x 2 kali kali 4,0K jul 18 03:14 sdcard
drwxrwxr-x 2 kali kali 4,0K jul 18 00:09 sys
drwxrwxrwx 2 kali kali 4,0K jul 18 00:09 tmp
drwxrwxr-x 11 kali kali 4,0K sep 8 09:56 usr
drwxrwxr-x 11 kali kali 4,0K dec 5 09:51 var
आइए unblob के विकल्पों के एक अलग सेट का उपयोग करके थोड़ा अन्वेषण करें:```
unblob -e /tmp/out -f -k -d 3 --report /tmp/report.json
--log /tmp/unblob.log CHARXSEC3XXXSoftwareBundleV190.raucb
यहाँ हम `/tmp/out` में निकालना (`-e`) जारी रखते हैं, लेकिन हम (`-f`) से अधिलेखन को बलपूर्वक करते हैं
जबकि (`-k`) से निकाले गए चंकों को बनाए रखते हैं, परंतु पुनरावृत्ति गहराई (`-d`) को
3 तक सीमित करते हैं। हम एक विस्तृत रिपोर्ट (`--report`) को `/tmp/report.json` पर और लॉग फ़ाइल
(`--log`) को `/tmp/unblob.log` पर लिखते हैं।
लॉग फ़ाइल पर एक नज़र डालें, आपको unblob की आंतरिक कार्यप्रणाली दिखाई देगी।
रिपोर्ट फ़ाइल में विश्लेषित फाइलों (आकार, फ़ाइल
प्रकार, पथ, magic, mime-type, MD5/SHA1/SHA256 हैश), चंक (आकार, ऑफ़सेट,
एन्ट्रॉपी वितरण) और कार्यों (निष्कर्षण, विघटन, carving) के बारे में विस्तृत जानकारी होती है।
थोड़ी Python की सहायता से इन रिपोर्ट फ़ाइलों से अच्छे विज़ुअलाइज़ेशन उत्पन्न करना
संभव है।
आप इन्हें इस रिपॉजिटरी में उपलब्ध `diagram.py` पायथन स्क्रिप्ट से स्वयं बना सकते
हैं:```
python3 diagram.py /tmp/report.json sunburst
python3 diagram.py /tmp/report.json treemap
ये कमांड ब्राउज़र में एक पेज खोलेंगे जिसमें नीचे दिए गए उदाहरणों जैसा plotly-आधारित विज़ुअलाइज़ेशन होगा:
अब जब हमें अंदर की चीज़ों की बेहतर समझ हो गई है, तो यह सूचीबद्ध करने का समय आ गया है कि हमें डिवाइस का सही एमुलेशन करने के लिए क्या चाहिए।
आदर्श रूप से, हमें ये जानकारी एकत्र करनी होगी:
प्लेटफ़ॉर्म, CPU और आर्किटेक्चर के बारे में कुछ विवरण पाने के लिए, हम फर्मवेयर में एम्बेडेड डिवाइस ट्री ब्लॉब्स को देख सकते हैं।
VFAT पार्टीशन में, हमारे पास ये DTBs हैं:``` oftree: Device Tree Blob version 17, size=27469, boot CPU=0, string block size=1657, DT structure block size=25756 zImage-imx6ul-ksp0632.dtb: Device Tree Blob version 17, size=27469, boot CPU=0, string block size=1657, DT structure block size=25756
ये फ़ाइलें डिवाइस ट्रीज़ का बाइनरी प्रतिनिधित्व हैं। हम `device-tree-compiler` का उपयोग करके उनके प्लेनटेक्स्ट स्रोत को पुनर्प्राप्त कर सकते हैं:```
dtc -I dtb -o zImage-imx6ul-ksp0632.dts zImage-imx6ul-ksp0632.dtb
dtc -I dtb -o oftree.dts oftree
DTS पर एक नज़र डालें, और आपको जल्द ही मॉडल जैसे दिलचस्प विवरण मिलेंगे:``` /dts-v1/;
/ { #address-cells = <0x01>; #size-cells = <0x01>; model = "Phytec phyBOARD-Segin i.MX6 UltraLite"; <----- right here compatible = "phytec,imx6ul-pbacd-10\0phytec,imx6ul-pcl063\0fsl,imx6ul";
सीपीयू:```
cpus {
#address-cells = <0x01>;
#size-cells = <0x00>;
cpu@0 {
compatible = "arm,cortex-a7"; <---- here
device_type = "cpu";
reg = <0x00>;
clock-latency = <0xee6c>;
operating-points = <0xa9ec0 0x137478 0x80e80 0x11edd8 0x60ae0 0xfa3e8 0x30570 0xe7ef0>;
fsl,soc-operating-points = <0xa9ec0 0x137478 0x80e80 0x11edd8 0x60ae0 0x11edd8 0x30570 0x11edd8>;
clocks = <0x01 0x5d 0x01 0x1a 0x01 0x26 0x01 0xdb 0x01 0x38 0x01 0x39 0x01 0x19>;
clock-names = "arm\0pll2_bus\0pll2_pfd2_396m\0secondary_sel\0step\0pll1_sw\0pll1_sys";
arm-supply = <0x02>;
soc-supply = <0x03>;
dc-supply = <0x04>;
};
};
या यहाँ तक कि परिधीय उपकरण:``` --snip-- ethernet@2188000 { compatible = "fsl,imx6ul-fec\0fsl,imx6q-fec"; reg = <0x2188000 0x4000>; interrupts = <0x00 0x76 0x04 0x00 0x77 0x04>; clocks = <0x01 0x90 0x01 0x91 0x01 0x30 0x01 0x2c 0x01 0x2c>; clock-names = "ipg\0ahb\0ptp\0enet_clk_ref\0enet_out"; fsl,num-tx-queues = <0x01>; fsl,num-rx-queues = <0x01>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <0x23>; phy-mode = "rmii"; phy-handle = <0x24>;
mdio {
#address-cells = <0x01>;
#size-cells = <0x00>;
ethernet-phy@1 {
reg = <0x01>;
interrupt-parent = <0x0b>;
interrupts = <0x02 0x08>;
micrel,led-mode = <0x01>;
clocks = <0x01 0x2c>;
clock-names = "rmii-ref";
status = "okay";
linux,phandle = <0x24>;
phandle = <0x24>;
};
ethernet-phy@2 {
reg = <0x03>;
micrel,led-mode = <0x01>;
clocks = <0x01 0x2d>;
clock-names = "rmii-ref";
status = "okay";
linux,phandle = <0x13>;
phandle = <0x13>;
};
};
};
--snip-- flexcan@2090000 { compatible = "fsl,imx6ul-flexcan\0fsl,imx6q-flexcan"; reg = <0x2090000 0x4000>; interrupts = <0x00 0x6e 0x04>; clocks = <0x01 0x94 0x01 0x95>; clock-names = "ipg\0per"; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <0x0f>; xceiver-supply = <0x10>; };
flexcan@2094000 { compatible = "fsl,imx6ul-flexcan\0fsl,imx6q-flexcan"; reg = <0x2094000 0x4000>; interrupts = <0x00 0x6f 0x04>; clocks = <0x01 0x96 0x01 0x97>; clock-names = "ipg\0per"; status = "disabled"; };
### Linux कर्नेल संस्करण की जानकारी
हम संपीड़ित कर्नेल वाले VFAT विभाजन के भीतर grep करके Linux कर्नेल संस्करण की पहचान कर सकते हैं:```
grep 'Linux version' . -ra
./zImage_extract/7296-6371487.lzo_extract/7296-6371487:
Linux version 5.15.195 (oe-user@oe-host) (gcc version 8.3.0 (GCC)) #1 SMP PREEMPT
./zImage_extract/7296-6371487.lzo_extract/7296-6371487:
Linux version %s (%s)Bluetooth subsystem version %u.%uHCI socket registration failed
एक और तरीका है EXT4 रूट फाइलसिस्टम में कर्नेल मॉड्यूल देखना:```
modinfo ./CHARXSEC3XXXSoftwareBundleV190.raucb_extract/0-138014720.squashfs_v4_le_extract/root.ext4_extract/lib/modules/5.15.195/kernel/net/bluetooth/bnep/bnep.ko.xz
filename: ./CHARXSEC3XXXSoftwareBundleV190.raucb_extract/0-138014720.squashfs_v4_le_extract/root.ext4_extract/lib/modules/5.15.195/kernel/net/bluetooth/bnep/bnep.ko.xz
alias: bt-proto-4
license: GPL
version: 1.3
description: Bluetooth BNEP ver 1.3
author: Marcel Holtmann [email protected]
srcversion: 86266D360814678CE0C94E9
depends:
intree: Y
name: bnep
vermagic: 5.15.195 preempt mod_unload modversions ARMv7 thumb2 p2v8
parm: compress_src:Compress sources headers (bool)
parm: compress_dst:Compress destination headers (bool)
## एमुलेशन
हमारे पास फर्मवेयर पैकेज के भीतर पहले से संकलित कर्नेल हो सकता है, लेकिन यह
कर्नेल विशेष रूप से एक विशेष मशीन के लिए संकलित किया गया है (Phytec
phyBOARD-Segin i.MX6 UltraLite)।
इस कर्नेल का ठीक से उपयोग करने के लिए, हमें इस कर्नेल को एक
एमुलेशन पर चलाने में सक्षम होना होगा जो उस सटीक मशीन का है जिसके लिए इसे संकलित किया गया है। यह समय-गहन है
यदि यह पहले से QEMU मशीनों की सूची में सूचीबद्ध नहीं है। नोट: एक इवैलुएशन बोर्ड
मशीन QEMU में उपलब्ध है (`mcimx6ul-evk - Freescale i.MX6UL Evaluation Kit
(Cortex-A7)`) लेकिन यह बिल्कुल मेल नहीं खाती है।
इसके बजाय, सिद्धांत रूप में, हम एक QEMU मशीन चुन सकते हैं, और विभिन्न मेटाडेटा का उपयोग कर सकते हैं जो हमें
फर्मवेयर इमेज में मिलते हैं, उस मशीन के लिए कर्नेल को कॉन्फ़िगर और बिल्ड करने हेतु,
जो हमारे फाइलसिस्टम में सब कुछ चलाने में भी सक्षम होगा, मूल के
जितना संभव हो उतना निकट।
यहाँ से, हमारे पास कुछ विकल्प हैं:
- *यूज़र स्पेस एमुलेशन*: हम अपने स्वयं के कस्टम ramfs/rootfs में बूट कर सकते हैं, फिर
लक्ष्य फर्मवेयर rootfs को लोड कर सकते हैं और उसमें chroot करके एमुलेट कर सकते हैं।
- *फुल सिस्टम एमुलेशन*: हम लक्ष्य फर्मवेयर rootfs को बूट करने का प्रयास कर सकते हैं
सीधे (इसे सीधे QEMU मशीन को पास करके)।
यूज़र स्पेस एमुलेशन आमतौर पर सीमित होता है लेकिन विशेष बाइनरीज़ की जांच, डिबगिंग,
और उनका शोषण (exploit) करने का एक शानदार तरीका है। हम दृढ़ता से अनुशंसा करते हैं कि आप
[EMUX](https://github.com/therealsaumil/emux) को Saumil Shah से देखें, आपकी सभी
यूज़रस्पेस एमुलेशन आवश्यकताओं के लिए।
फिर भी, हमें अभी भी एक कर्नेल की आवश्यकता है जो QEMU मशीन के भीतर बूट होगा, जो
लक्ष्य फर्मवेयर की अपेक्षाओं से यथासंभव निकटता से मेल खाता है।
### QEMU मशीनें
सामान्य-उद्देश्य वाली मशीनों के लिए केवल कुछ ही उम्मीदवार हैं जो
लचीलापन प्रदान करते हैं। काफी प्रयोग के बाद, `virt`
(https://qemu.readthedocs.io/en/latest/system/arm/virt.html) हमारे उद्देश्यों के लिए एक
अच्छा लचीलापन/शक्ति अनुपात रखता प्रतीत होता है।
किसी दिए गए QEMU मशीन के लिए कर्नेल बनाते समय, संभवतः हमारे लिए यह सबसे अच्छा है कि हम
यह सुनिश्चित करें कि हम सामान्य virtio डिवाइस का उपयोग कर सकें जो QEMU बंडल करता है। इस
कॉन्फ़िग में, इनका अर्थ निम्न में से एक या अधिक हो सकता है:```
CONFIG_VIRTIO=y
CONFIG_SCSI_VIRTIO=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BLK=y
और भी बहुत कुछ! यह सूची अधूरी है।
हमारे लिए ऐसे कर्नेल का उपयोग करना लाभदायक है जिसका vermagic स्ट्रिंग समान (या कम से कम बहुत समान) हो। सिस्टम के भीतर सभी प्रकार के घटक कर्नेल के vermagic की जाँच कर रहे हो सकते हैं, और यदि यह अपेक्षित से भिन्न है तो विफल हो सकते हैं। यह कर्नेल मॉड्यूल में सबसे आम है - एक कर्नेल आमतौर पर उस मॉड्यूल को लोड करने से इनकार कर देगा जिसके पास अपने से मेल खाने वाला vermagic नहीं है। जबकि हम कर्नेल स्तर पर इसे अनदेखा करने के लिए कर्नेल को पैच कर सकते हैं, फिर भी हमें स्ट्रिंग के प्रारंभिक “kernel release” भाग को कर्नेल मॉड्यूल के रिलीज़ स्ट्रिंग से मेल खाना होगा, क्योंकि यह modules.dep के लिए खोज पथ के रूप में उपयोग किया जाता है।
Phoenix Contact फर्मवेयर में, vermagic 5.15.195 preempt mod_unload modversions ARMv7 thumb2 p2v8 है।
vermagic स्ट्रिंग एक प्रारूप में होती है जैसे (include/linux/vermagic.h से):```c
#define VERMAGIC_STRING
UTS_RELEASE " "
MODULE_VERMAGIC_SMP MODULE_VERMAGIC_PREEMPT
MODULE_VERMAGIC_MODULE_UNLOAD MODULE_VERMAGIC_MODVERSIONS
MODULE_ARCH_VERMAGIC
- Kernel release = कर्नेल संस्करण + `CONFIG_LOCALVERSION` स्ट्रिंग।
- SMP = `CONFIG_SMP`
- PREEMPT = `CONFIG_PREEMPT`
- mod_unload = `CONFIG_MODULE_UNLOAD`
- modversions = `CONFIG_MODVERSIONS`
- ARMv7 thumb2 p2v8 = `MODULE_ARCH_VERMAGIC` (उस आर्किटेक्चर से संबंधित जिसके लिए कर्नेल संकलित किया गया है, इसलिए पारित किए गए compiler/arch विकल्प से संबंधित है।)
एक बार हमारे पास निकाला गया कर्नेल सोर्स हो, तो हम इसे पैच कर सकते हैं ताकि vermagic स्ट्रिंग्स की तुलना करने में यह इतना कठोर न हो। kernel/module.c में, हम सिर्फ return -ENOEXEC को कमेंट आउट कर सकते हैं:```diff
} else if (!same_magic(modmagic, vermagic, info->index.vers)) {
pr_err("%s: version magic '%s' should be '%s'\n", info->name, modmagic, vermagic);
- return -ENOEXEC;
+ // return -ENOEXEC;
}
if (!get_modinfo(info, "intree")) {
यह लंबे समय में आवश्यक रूप से उपयोगी नहीं हो सकता है, लेकिन यह परीक्षण के लिए अच्छा है, जब तक हमारे kernel vermagic और module vermagic के बीच थोड़ी विसंगतियाँ हैं। Modules (अधिकतर) फिर भी load हो जाएँगे।
NOTE: यहाँ हम एक पहले से built kernel प्रदान करते हैं जो target आवश्यकताओं से मेल खाता है ताकि आपको स्वयं एक compile करने की आवश्यकता न पड़े। इसे एक in-house script से build किया गया था जो:
multi_v7_defconfig को call करता हैkernel/module.c में vermagic checking code को patch करता हैVIRTIO options और USB या CANBUS जैसे विशिष्ट subsystems को enable करने के लिए config को patch करता हैआइए अपने qemu-system-arm command के विभिन्न parameters पर गौर करें। हम kernel को इस प्रकार प्रदान करते हैं:```sh
qemu-system-arm -M virt,highmem=off
-m ${AVAILABLE_MEM_GB}G -smp ${CPU_CORES} -cpu cortex-a15
-kernel zImage
EXT4 फ़ाइलसिस्टम इमेज एक SCSI डिस्क के रूप में संलग्न है:```sh
-device virtio-scsi-device \
-device scsi-hd,drive=SystemDisk \
-drive file=${FIRMWARE_IMAGE},format=raw,if=none,id=SystemDisk
हम इस तरह एक उचित कंसोल आउटपुट सेट करते हैं:```sh
-append "${BOOT_PARAMS}"
-no-reboot
-nographic
-serial mon:stdio \
The `BOOT_PARAMS` को `config.ini` में सेट किया जाता है और यह वास्तविक kernel bootcmd के अनुरूप होते हैं, जिनमें दो छोटे अनुकूलन (console path और rootfs path) शामिल हैं।
### नेटवर्किंग
अब जब हमारे पास एक कार्यशील अनुकरणित सिस्टम है, तो नेटवर्किंग सेट करने का समय आ गया है। लक्ष्य में निम्नलिखित हैं:
- दो Ethernet इंटरफेस (`eth0` और `eth1`)
- एक CANbus इंटरफेस (`can0`)
- एक USB इंटरफेस जो USB पर Ethernet के रूप में कार्य कर सकता है (`usb0`)
- एक Qualcomm High Sierra सेलुलर मॉडेम (`ppp0`)
QEMU के साथ सेलुलर मॉडेम और USB इंटरफेस का अनुकरण करना कष्टकारी है, और डिवाइस संचालन के लिए वास्तव में आवश्यक नहीं है क्योंकि वे इंटरफेस "वैकल्पिक" हैं। CAN इंटरफेस नियंत्रक को अन्य नियंत्रकों या चार्जिंग स्टेशनों से बात करने की अनुमति देने के लिए है। `eth0` इंटरफेस डिफ़ॉल्ट रूप से DHCP लीज़ का अनुरोध करके अपस्ट्रीम कनेक्टिविटी प्रदान करता है, जबकि `eth1` को 192.168.4.1 पर सेट किया गया है और यह तब उपलब्ध रहता है जब आप कई नियंत्रकों को डेज़ी चेन करना चाहते हैं।
Ethernet इंटरफेस को TAP इंटरफेस के रूप में सेट किया जाता है और इस प्रकार जोड़ा जाता है:```
-netdev tap,id=tap0net,ifname=${ETH_1},script=no,downscript=no \
-device virtio-net-device,netdev=tap0net,mac=${ETH_1_MAC} \
-netdev tap,id=tap1net,ifname=${ETH_0},script=no,downscript=no \
-device virtio-net-device,netdev=tap1net,mac=${ETH_0_MAC} \
The CANBUS इंटरफ़ेस केवल एक PCI इंटरफ़ेस है, जो इस प्रकार जुड़ा हुआ है:```
-object can-bus,id=canbus0
-device kvaser_pci,canbus=canbus0
-object can-host-socketcan,id=canhost0,if=can0,canbus=canbus0 \
नीचे दिया गया आरेख दर्शाता है कि नेटवर्क सेटअप कैसा दिखता है:
यदि आप Phoenix Contact द्वारा अनुशंसित अनुसार उन्हें डेज़ी-चेन करके इंटर-कंट्रोलर संचार आज़माना चाहते हैं, तो आप कुछ इस तरह का उपयोग कर सकते हैं:
## तैयार ? सेट. लॉन्च !
अब जब सब कुछ अपनी जगह पर है, तो इसे चालू करने का समय आ गया है!
सबसे पहले, आपको सभी नेटवर्क इंटरफेस को इस तरह सेटअप करना होगा:```
sudo ./ifup.sh
सुनिश्चित करें कि आपका अपस्ट्रीम इंटरफ़ेस config.ini में सही ढंग से सेट है:```
OUT_IF="eth0"
आप फिर एमुलेटर लॉन्च कर सकते हैं:```
sudo ./launch.sh
आपको प्राप्त पते लॉग में दिखाई देंगे:``` Dec 5 10:07:46 ev3000 daemon.info avahi-daemon[1047]: Registering new address record for 192.168.4.1 on eth1.IPv4. Dec 5 10:07:46 ev3000 daemon.info avahi-daemon[1047]: Registering new address record for 192.168.88.181 on eth0.IPv4.
### SSH के माध्यम से पहुँच
आप फिर `user-app` उपयोगकर्ता का उपयोग करके अनुकरणित डिवाइस में SSH कर सकते हैं:```sh
ssh [email protected]
पासवर्ड "user" है। पहले लॉगिन पर आपको इसे बदलने के लिए बाध्य किया जाएगा:```sh ssh [email protected] The authenticity of host '192.168.88.181 (192.168.88.181)' can't be established. ED25519 key fingerprint is SHA256:qMupzEehNFpx6eaGZ4d3AY5Jlms3Pmxh3/yg9OGA28o. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.88.181' (ED25519) to the list of known hosts. [email protected]'s password: WARNING: Your password has expired. You must change your password now and login again! Changing password for user-app Old password: Enter the new password (minimum of 5 characters) Please use a combination of upper and lower case letters and numbers. New password: Re-enter new password: passwd: password changed. Connection to 192.168.88.181 closed.
### वेब इंटरफ़ेस
आप वेब इंटरफ़ेस को http://192.168.4.1 पर एक्सेस कर सकते हैं। डिवाइस बूट होने के दौरान यह एक त्रुटि संदेश दिखा सकता है। एक बार सब कुछ चालू हो जाने पर आपको यह देखना चाहिए:
आप निम्नलिखित खातों से लॉगिन कर सकते हैं:
| उपयोगकर्ता नाम | पासवर्ड |
|----------|----------|
| manufacturer | manufacturer |
| operator | operator |
### CAN ट्रैफ़िक
जब सब कुछ चालू हो जाता है, तो आप नियंत्रक द्वारा उत्सर्जित CAN ट्रैफ़िक को कैप्चर कर सकते हैं:```
candump -i can0
can0 701 [1] 00000101
can0 701 [1] 00000101
can0 701 [1] 00000101
can0 701 [1] 00000101
can0 701 [1] 00000101
can0 701 [1] 00000101
नोट: ऐसा प्रतीत होता है कि QEMU संस्करण 8.x को CAN नियंत्रक जोड़ने में किसी कारण से कुछ कठिनाइयाँ आ रही हैं।