Comments 16
Я почему-то от заголовка ожидал, что автор найдет в прошивке код, который сливает инфу производителю… А тут мануал по binwalk. Ну, спасибо ;)
Насчет версии 3.3.8 с одной стороны конечно верно…
С другой стороны у Keenetic неофициально поддерживаются ветки 2.11 и 2.16 с бекпортами свежих исправлений, но ядро при этом остается выглядеть как 3.4.113 — с осени 2016 эта версия не менялась.
Потому нужно осторожно судить о реальном положении дел чисто по цифрам.
По поводу энтропии — это всего лишь rootfs, сжатый в lzma или xz — у него энтропия как у потока случайных чисел.
Регулярно выковыривал какие-то левые скрипты с бинарниками с дефолтных прошивок китайской компании ZBT. Детально не анализировал, но явные бекдоры. Устройства всегда покупались напрямую с фабрики.
А почему у официального образа есть OpenWRT в названии?
image name: «MIPS OpenWrt Linux-3.3.8»
Потому что 90% прошивок роутеров сделаны на основе старых версий OpenWRT, с заменой luci на свой собственный web интерфейс (а иногда и просто с luci)

Ага, у меня было знатное дежавю при столкновении с промышленными роутерами Телтоники.

бывают устройства и поинтереснее где openWRT, но замаскированный, и не самой новой версии, которую еще и не обновишь без перепиливания того что на ней нагородили в рамках отечественных разработок при ограниченном бюджете (все освоили до инженеров)…
Не понимаю как из
23296 0x5B00 LZMA compressed data, properties: 0x5D, dictionary size:
8388608 bytes, uncompressed size: 97476 bytes
64968 0xFDC8 XML document, version: «1.0»

Получили
dd if=archer-c7.bin of=u-boot.bin.lzma bs=1 skip=23296 count=41162

Со смещением все просто а вот с размером не пойму.

Я так понимаю размеры взяты из заголовка, из выхлопа первого применения binwalk.
У меня все повторяется до следующей команды, вплоть до идентичного выхлопа:
dd if=uImage of=Image.lzma bs=1 skip=72
После чего unlzma пишет что архив прврежден.
Кто то извлёк из образа корректный архив?


Единственное отличие со статьей это имя загруженного архива, оно отличается, все размеры соответствуют статье, но нет уверенности что сейчас на сайте не битый образ.

count=41162

У меня путем несложных вычислений получается 41672.
Отсюда вопрос что я не так понимаю.

Вы считаете, что полезная нагрузка от начала одной секции и до начала другой, тут же от конца полезной нагрузки до начала следующей секции могут идти байты хлама, то есть надо смотреть не разницу между смещениями секций, а размер указанный в выхлопе binwalk.

И эта мысль была. Потому и интересно как из выхлопа
23296 0x5B00 LZMA compressed data, properties: 0x5D, dictionary size:
8388608 bytes, uncompressed size: 97476 bytes
64968 0xFDC8 XML document, version: «1.0»

получилось значение count=41162.

Просто у вас не весь выхлоп
23232 0x5AC0 uImage header, header size: 64 bytes, header CRC: 0x386C2BD5, created: 2019-05-20 10:45:17, image size: 41162 bytes, Data Address: 0x80010000, Entry Point: 0x80010000, data CRC: 0xC9CD1E38, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: "u-boot image"
23296 0x5B00 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 97476 byte


Вы заголовок пропускаете, а там написано — image size: 41162 bytes

Не понимаю, почему "unlzma Image.lzma" не работает, а "Binwalk -e Image.lzma" работает корректно?
lzma properties 0x5D это обычный архив lzma судя по всему, а что за формат properties 0x6D?

Only those users with full accounts are able to leave comments. Log in, please.