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 के अनुरूप हैं।