LINUX.ORG.RU

4 байта в конце прошивки

 , , ,


1

1

Имеется устройство Zyxel Keenetic Start В прошивке есть заголовок и там 2 контрольные суммы (одна заголовка а другая ядра) с ними я разобрался и нашел как они считаются через CRC32. В разобранной прошивке нашел файл в файловой системе /sbin/fwupdate, где проверяется эта контрольная сумма (нашел место где она проверяется и отправляет либо ошибка либо успех)

но в конце прошивки есть 4 байта

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
5A 4E 42 47 02 12 00 00 5A 79 58 45 4C 20 4B 65
65 6E 65 74 69 63 20 53 74 61 72 74 20 76 32 2E
30 35 28 41 41 4B 56 2E 30 29 43 34 00 00 00 00
00 00 00 00 00 00 00 00 C4 1C B6 24

скорее всего это еще какая то контрольная сумма, перепробовал много способов докопаться до истины, писал кинетикам и поддержку и на форум. Есть тут те кто разбирается в mips архитектуре или хотя бы подскажет где найти?

Ответ на: комментарий от missxu

прошивка зикселя опенсурс помоему

не на 100% опенсурс, есть закрытые бинарники в её составе! без закрытых бинарников, т.е. на 100% опенсурсе, могут работать лишь 10 роутеров поддерживаемых проектом LibreCMC (форк LEDE для тех роутеров которые в принципе могут работать без блобов) и ни один зиксель в их число не входит:

https://gogs.librecmc.org/libreCMC/libreCMC/src/v1.4/docs/Supported_Hardware.md

anonymous
()
Ответ на: комментарий от anonymous

Как хорошо, что у меня на 100% открытый роутер. Это что-то мне даёт? Нет, мне насрать. В опенсорсе точно такие же дыры и бэкдоры.

anonymous
()
Ответ на: комментарий от anonymous

Это что-то мне даёт?

возможность делать с роутером что угодно, то по факту мини сервер, и там уже двухядерные процы стоят что по производительности близко к *PI девайсам

если тебе не надо не значит что никому не надо

missxu
()

В прошивке есть заголовок и там 2 контрольные суммы (одна заголовка а другая ядра) с ними я разобрался и нашел как они считаются через CRC32.

Если в формате используется CRC32 то это оно и есть. Напиши программу которая от последнего символа (до твоей последней КС) будет считать контрольную сумму передвигаясь к началу файла. Как только значение совпадет с C4 1C B6 24 - ты нашел тот кусок, который нужно просчитывать.

Вангую что это будет Payload после КС заголовка.

PPP328 ★★★★★
()
Ответ на: комментарий от sharki1102

Практически любой блоб - будь это протокол обмена или формат файла разделяется на две части - header и payload. Структура такого блоба обычно такая:

[ HEADER [PAYLOAD LENGTH] [CHECKSUM]<В случае KLV-кодирования CHECKSUM и PAYLOAD LENGTH меняются местами> ][ PAYLOAD [CHECKSUM] ]<Изредка в конце еще одна контрольная сумма, которая считается прям вообще по всему пакету. У вас ее нет>
Payload в данном контексте - это «полезная нагрузка». Ее может и не быть, например, когда весь необходимый ответ уже обозначен тем что есть header, сигнализирующий о том, что устройство получило команду. Иногда туда даже коды ошибок запихивают, но это изврат. Так вот. Вы обнаружили свой HEADER, увидели что можно посчитать его CHECKSUM. Теперь в HEADER вы должны найти поле, обозначающее PAYLOAD LENGTH - то, какого размера у вас дальнейшая полезная нагрузка. Тогда вы берете это количество байт после заголовка, считаете от них контрольную сумму и получаете ту, что у вас сейчас в файле.

PPP328 ★★★★★
()
Ответ на: комментарий от anonymous

без закрытых бинарников прекрасно работают старые ралинки (типа 305х), в сдк вайфай дрова в сырцах к ним бывали. вот только лицензия - проприетарная, потому - ни в какие libre* не попадают.

а еще вообще без блобов работают все атеросы, искаропки. а девайсов на них - куда поболее тех 10 штук что перечислены в сей поделке.

NiTr0 ★★★★★
()
Ответ на: комментарий от missxu

а что, блоб вайфайки при нормальном сдк этому помешает?

не, если ручки из жопки, и вкрутить в вендор сдк/сдк производителя что-то непосильная задача, то тут да, пичаль-беда...

NiTr0 ★★★★★
()
Ответ на: комментарий от PPP328

1) неизветно с каким полиномом считается та самая CRC32

2) неизвестно какое initial value загружается при подсчете CRC

3) CRC - далеко не пофиг порядок следования слов (т.е. CRC32 от строки «12345678» будет совсем не той же что от строки «56781234»)

NiTr0 ★★★★★
()
Ответ на: комментарий от anonymous

Как минимум даёт возможность всегда сидеть на новом ядре с закрытыми уязвимостями. Даже если производитель забил на апдейты.

Дыры есть везде, да, поэтому главный вопрос в скорости закрытия (ибо между «знают только тру-хакеры» и «знает каждый школьник» таки есть разница).

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от missxu

вот структура моей прошивки:

---------------------------------------
image
---------------------------------------

kernel

---------------------------------------


null

----------------------------------------

squashFS

----------------------------------------

null

----------------------------------------
footer+{4 загадочных байта}
----------------------------------------

надо перебирать с последнего символа squashFS до footerа и потом на увеличение в сторону начала?

sharki1102
() автор топика
Ответ на: комментарий от sharki1102

это структура ЛЮБОЙ прошивки уже лет 20 как

я без понятия что ты делаешь и зачем

мои советы были-тыкай исходники OpenWRT там есть поддержка зикселей, и твой лоадер ничем не отличается

можешь скачать одну из прошивок для другого зикселя https://openwrt.org/toh/start
например для кинетика https://openwrt.org/toh/hwdata/zyxel/zyxel_keenetic (внизу страницы) и посмотреть сгенерированый образ OpenWRT сравнив со своим

missxu
()
Ответ на: комментарий от KivApple

как много вы знаете уязвимостей сетевого стека скажем для 2.6.32 ядра? другие уязвимости (типа эскалации привилегий и т.п.) по определению не волнуют.

и да, при смене штатного 2.6.х на последнее-распоследнее 4.18 скажем, на старых девайсах с 8-16 килобайт кеша и SDRAM, производительность легко может упасть эдак в 2-3 раза :)

NiTr0 ★★★★★
()
Ответ на: комментарий от missxu

что, таки я угадал что ручки из жопки, коль так пригорело?

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

От чего же она упадёт? Эффективность говнокода в последних версиях ядра только повышалась, и компилятор, опять же, всё лучше справляется.

anonymous
()
Ответ на: комментарий от anonymous

да банальное распухание структур ядра новыми полями, рост cache misses при тормозной памяти (да-да, 16-бит 133-166МГц SDRAM - это вам не это) + общее распухание кода ядра в несколько раз...

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

Сейчас стало очень можливо урезать ядро на предмет лишних полей и оверхэда структур, раньше такого не было. А само ядро можно сделать едва ли не меньше, чем прежде.

anonymous
()
Ответ на: комментарий от anonymous

тихо тихо

это пятизвездочный иксперд по всем вопросам, и телепат по совместительству

у меня от такого роутер умер, пишу с калькулятора

missxu
()
Ответ на: комментарий от anonymous

да-да, вот только наблюдается это лишь в теории, на практике - 4.18 в несколько раз медленнее в роутинге на раритетах типа ar71xx/rt305x в сравнении с 2.6.2х веткой, и объем ядра в несколько раз больше. если хотите - можете взять и сравнить.

NiTr0 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.