В ходе этого практического занятия мы извлечём прошивку из зарядной станции для электромобилей, разберёмся в ней и в итоге эмулируем её, чтобы мы могли взаимодействовать с сервисами в реальном времени.
Присоединяйтесь к нам на этом практическом демо Unblob — гибкого экстрактора прошивки. В ходе этого воркшопа мы извлечём прошивку из зарядной станции для электромобилей, разберём её внутреннее устройство и в итоге эмулируем её, чтобы иметь возможность взаимодействовать с сервисами в реальном времени. Unblob работает как с аппаратными, так и с загружаемыми версиями прошивки, так что у нас богатая среда для работы. Предварительный опыт не требуется, сессия подходит для любого уровня подготовки, и мы с нетерпением ждём встречи с вами.
Наша цель — контроллер зарядной станции для электромобилей от Phoenix Contact. Подробнее о нём можно узнать здесь.
CHARX control modular, AC-контроллер заряда, со встроенной системой Linux, IEC 61851-1, режим работы: автономный, клиент, сервер,
Интерфейсы:
- Ethernet (2x)
- Сотовая связь (4G/2G)
- Системная шина CHARX control modular
- MICRO-USB type C
Протоколы связи:
- OCPP 1.6J
- Modbus/TCP
- MQTT
Подключаемые периферийные устройства:
- Счётчик электроэнергии
- RFID
- Контроль остаточного тока постоянного тока
- Крепление на DIN-рейку
Для этого воркшопа нам понадобится несколько инструментов. Вы можете установить их,
запустив скрипт 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 работает путём определения чанков данных внутри файлов. Если чанк — это
сжатый поток, он распаковывается. Если это файловая система или архив — он
извлекается. Если извлечение или распаковка прошли успешно, чанк,
вырезанный на диск, удаляется для освобождения места.
Здесь чанк SquashFS версии 4 little-endian был вырезан на диск, извлечён
и удалён. Файлы (а следовательно, и директории извлечения) именуются
по схеме `{start_offset}-{end_offset}.{type}`.
Мы видим, что после файловой системы squashfs появляется 11 КБ «неизвестного» чанка.```
./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
Мы можем видеть манифест в открытом виде, shell-скрипт, одну MBR и файловую систему EXT4:```
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 содержит всё, что связано с загрузкой и ОС (ядро 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 немного жадный и извлечёт ELF-файл и CPIO-архив
из ядра Linux (`zImage`), они соответствуют минимальному ядру и 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
Let's do a bit of exploration by using a different set of unblob's options:```
unblob -e /tmp/out -f -k -d 3 --report /tmp/report.json
--log /tmp/unblob.log CHARXSEC3XXXSoftwareBundleV190.raucb
Here we keep extracting (`-e`) to `/tmp/out` but we force (`-f`) overwrite
while keeping (`-k`) carved out chunks but limiting recursion depth (`-d`) to
3. We write a detailed report (`--report`) to `/tmp/report.json` and log file
(`--log`) to `/tmp/unblob.log`.
Take a look at the log file, you'll see the inner working of unblob.
Файл отчёта содержит подробную информацию об анализируемых файлах (размер, тип файла, путь, magic, mime-type, хэши MD5/SHA1/SHA256), фрагментах (размер, смещения, распределение энтропии) и задачах (извлечение, декомпрессия, вырезание). С помощью небольшого количества Python можно создавать хорошие визуализации на основе этих файлов отчётов.
Вы можете создать их самостоятельно с помощью python-скрипта `diagram.py`, доступного в этом репозитории:```
python3 diagram.py /tmp/report.json sunburst
python3 diagram.py /tmp/report.json treemap
Эти команды откроют в браузере страницу с визуализацией на основе plotly, как показано ниже:
Теперь, когда у нас есть лучшее представление о том, что находится внутри, пора перечислить, что нам нужно для корректной эмуляции устройства.
В идеале нам нужно собрать следующие сведения:
Чтобы получить некоторые сведения о платформе, CPU и архитектуре, мы можем заглянуть в блобы дерева устройств, встроенные в прошивку.
В разделе VFAT находятся следующие DTB:``` 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
Мы можем определить версию ядра Linux, выполнив grep в разделе VFAT, содержащем сжатое ядро:```
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).
Эмуляция пользовательского пространства обычно ограничена, но это отличный способ исследовать, отлаживать
и эксплуатировать конкретные бинарные файлы. Мы настоятельно рекомендуем вам ознакомиться с
[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
- Выпуск ядра = версия ядра + строка `CONFIG_LOCALVERSION`.
- SMP = `CONFIG_SMP`
- PREEMPT = `CONFIG_PREEMPT`
- mod_unload = `CONFIG_MODULE_UNLOAD`
- modversions = `CONFIG_MODVERSIONS`
- ARMv7 thumb2 p2v8 = `MODULE_ARCH_VERMAGIC` (связано с архитектурой, для которой скомпилировано ядро, а значит, связано с переданной опцией компилятора/архитектуры.)
Когда у нас есть извлечённый исходный код ядра, мы можем пропатчить его, чтобы он не был таким жёстким при сравнении строк 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")) {
Возможно, это не пригодится в долгосрочной перспективе, но хорошо подходит для тестирования, поскольку между vermagic нашего ядра и vermagic модуля есть небольшие расхождения. Модули (в большинстве случаев) всё равно загрузятся.
ПРИМЕЧАНИЕ: здесь мы предоставляем уже собранное ядро, соответствующее требованиям целевой системы, так что вам не нужно компилировать его самостоятельно. Оно было собрано с помощью внутреннего скрипта, который:
multi_v7_defconfig для начальной конфигурацииkernel/module.cVIRTIO и конкретных подсистем, таких как USB или CANBUSДавайте разберём различные параметры нашей команды qemu-system-arm. Ядро мы передаём следующим образом:```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 \
`BOOT_PARAMS` задаются в `config.ini` и соответствуют фактической команде
загрузки ядра bootcmd, с двумя небольшими адаптациями (путь к консоли и путь к rootfs).
### Сеть
Теперь, когда у нас есть работающая эмулируемая система, пора настроить сеть. Целевое устройство имеет следующее:
- два интерфейса Ethernet (`eth0` и `eth1`)
- один интерфейс CANbus (`can0`)
- один USB-интерфейс, который может работать как Ethernet поверх USB (`usb0`)
- сотовый модем Qualcomm High Sierra (`ppp0`)
Эмуляция сотового модема и USB-интерфейсов доставляет массу неудобств с QEMU, и для работы
устройства она не обязательна, поскольку эти интерфейсы «опциональны».
Интерфейс 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} \
Интерфейс CANBUS — это просто PCI-интерфейс, подключаемый следующим образом:```
-object can-bus,id=canbus0
-device kvaser_pci,canbus=canbus0
-object can-host-socketcan,id=canhost0,if=can0,canbus=canbus0 \
На рисунке ниже показано, как выглядит сетевая конфигурация:
Если вы хотите попробовать межконтроллерную связь, соединив их последовательно (daisy-chain), как рекомендует 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
Затем вы можете подключиться по SSH к эмулируемому устройству, используя пользователя `user-app`:```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 controller по какой-то причине.