Перейти к содержимому
Калькуляторы

murder

Пользователи
  • Публикации

    12
  • Зарегистрирован

  • Посещение

Все публикации пользователя murder


  1. Как выяснилось не всё: 1) Точка доступа AccessPoint (wlan3) не поднимается если wlan1 не подключился к DM WiFi_7a22 2) Даже если AccessPoint поднимется, к ней невозможно подключиться (на Android пишет "Доступ к сети запрещён") это исправил, установив галочку "default authentificate"
  2. Здравствуйте. Имеется WiFi-микроскоп, который работает как точка доступа, данные MJPEG передаются по UDP. Хочу сделать сделать проброс в локальную сеть через микротик. Конфиг микротика: /interface wireless security-profiles add authentication-types=wpa2-eap name=Open supplicant-identity="" /interface wireless set [ find default-name=wlan1 ] antenna-gain=10 band=2ghz-b/g/n country=\ kazakhstan default-forwarding=no disabled=no distance=indoors frequency=\ auto installation=indoor security-profile=Open ssid="DM WiFi_7a22" \ station-roaming=enabled wireless-protocol=802.11 add default-authentication=no disabled=no keepalive-frames=disabled \ mac-address=66:D1:54:B8:B8:97 master-interface=wlan1 multicast-buffering=\ disabled name=wlan3 ssid=AccessPoint wds-cost-range=0 wds-default-cost=0 \ wps-mode=disabled /ip dhcp-client add add-default-route=no interface=wlan1 /ip firewall nat add action=masquerade chain=srcnat dst-address=192.168.29.1 src-address=192.168.2.0/24 add action=dst-nat chain=dstnat src-address=192.168.29.1 to-addresses=192.168.2.250 Windows: route add 192.168.29.1 mask 255.255.255.255 192.168.2.1 192.168.29.1 - микроскоп (жёстко прошит, не настраивается) 192.168.2.1 - микротик 192.168.2.250 - компьютер DM WiFi_7a22 - SSID микроскопа AccessPoint - SSID локальной сети Всё работает, но мне не нравится жёсткое указание адреса 192.168.2.250. Как сделать его динамическим?
  3. Вот что выводит unsquashfs с ключом -stat Found a valid SQUASHFS 4:0 superblock on ZISA.hsqs. Creation or last append time Tue May 9 11:47:50 2017 Filesystem size 2299.59 Kbytes (2.25 Mbytes) Compression xz xz: error reading stored compressor options from filesystem! Block size 262144 Filesystem is exportable via NFS Inodes are compressed Data is compressed Fragments are compressed Always-use-fragments option is not specified Xattrs are not stored Duplicates are removed Number of fragments 21 Number of inodes 727 Number of ids 1 То есть опции xz он прочитать не может однако распаковывает файл и без них. Добавлено: Думаю можно сделать так: 1) изменить в исходниках mksquashfs структуру comp_opts, чтобы она была размером в 12 байт (уже сделано) 2) запаковать этой утилитой файловую систему с указанием правильного размера словаря и фильтров. 3) в получившемся файле заменить структуру comp_opts на ту, которая была в оригинале. Теперь вопрос: как узнать размер словаря и фильтры? Вот выдрал маленький xz-stream (кажется это fragment table в упакованном виде), какой у него размер словаря? Это читал, но там нормально описаны только заголовки потока и блоков, а формат LZMA2-данных, которые как раз и содержат нужную информацию, описан не полностью. xz.xz
  4. Вот так уже понятнее, но всё ещё не понятно /* * store any compressor specific options after the superblock, * and set the COMP_OPT flag to show that the filesystem has * compressor specfic options */ Добавлено: Насколько я понял из исходников, то если использовать ключ -Xbcj или -Xdict-size, то будет установлен флаг SQUASHFS_COMP_OPT и сразу после заголовка squashfs будут сохранены: (размер структуры) | (1<<15) Сама структура struct comp_opts { int dictionary_size; int flags; }; Биты поля flags устанавливаются в соответствии с указанными в ключе -Xbcj фильтрами. Номера битов для фильтров такие: x86 = 0 powerpc = 1 ia64 = 2 arm = 3 armthumb = 4 sparc = 5 unknown = 6 В оригинальном файле: Размер структуры почему-то 12 вместо 8 dictionary_size = 14 00 09 00 = 589844 (больше размера блока) flags = 90 00 40 00 = вообще непонятно А вот если посмотреть запакованный мною файл, то там всё соответствует исходникам. Делаю вывод, что использовалось что-то не стандартное. Кроме того поле bytes_used суперблока в оригинале содержит весь размер данных, включая выравнивание (от чего 7-zip и выводит предупреждение), а у меня только размер полезных данных и выравнивается в оригинале через 0xFF, а у меня через 0x00. Что характерно испанцы модифицировали прошивку и у них всё соответствует оригиналу (на email и на форуме микротик не отвечают).
  5. Будем разбираться - вот заголовок squashfs 4.3: struct squashfs_super_block { unsigned int s_magic; unsigned int inodes; unsigned int mkfs_time /* time of filesystem creation */; unsigned int block_size; unsigned int fragments; unsigned short compression; unsigned short block_log; unsigned short flags; unsigned short no_ids; unsigned short s_major; unsigned short s_minor; squashfs_inode_t root_inode; long long bytes_used; long long id_table_start; long long xattr_table_start; long long inode_table_start; long long directory_table_start; long long fragment_table_start; long long lookup_table_start; }; Меня интересует поле flags - в исходном файле оно равно 0x6C0. Вот определение флагов (они определены номерами битов): /* Filesystem flags */ #define SQUASHFS_NOI 0 #define SQUASHFS_NOD 1 #define SQUASHFS_CHECK 2 #define SQUASHFS_NOF 3 #define SQUASHFS_NO_FRAG 4 #define SQUASHFS_ALWAYS_FRAG 5 #define SQUASHFS_DUPLICATE 6 #define SQUASHFS_EXPORT 7 #define SQUASHFS_NOX 8 #define SQUASHFS_NO_XATTR 9 #define SQUASHFS_COMP_OPT 10 Соответственно 0x6C0 это SQUASHFS_EXPORT+SQUASHFS_DUPLICATE+SQUASHFS_NO_XATTR+SQUASHFS_COMP_OPT. Теперь бы узнать, что такое SQUASHFS_COMP_OPT.
  6. Покопал uImage в Hex-редакторе и понял, что squashfs не имеет к нему никакого отношения - контрольная сумма там для lzma-блока, причём этот блок тоже выровнен по размеру.   Так всё-же как узнать точные параметры упаковки squashfs? Есть какие-нибудь утилиты помимо 7-zip, которые выводят информацию о файле? Интересует поле "характеристики" в 7-zip - что означает 0x600?
  7. Ну да - так и есть, размер кратен 256 Кб. Так мне просто вставить перепакованную файловую систему в прошивку и пересчитать 3 контрольных суммы CRC (1 по смещению 0x68 и 2 в заголовке uImage)? Есть ещё вот такое описание формата uImage - там написано, что может быть произвольное количество хешей для каждого файла внутри uImage, посчитанных одним из 3 алгоритмов на выбор, надеюсь здесь такого нет.
  8. Поставил Antix - работаю в нём. Никак не могу подобрать комбинацию опций mksquashfs, чтобы получить 0x600 в характеристиках. Ключ -nopad даёт 0x400, -x-noattrs даёт 0x200 по логике их комбинация должна давать 0x600, но получается 0x200. Кстати вырезал sqhuashfs из файла, чтобы unsquashfs работал и теперь binwalk выводит "compression: xz". В оригинальном файле в конце зачем-то добавлено 4515 байт со значением 0xFF. Так что наверное размер имеет значение. У меня же после перепаковки файл получается настолько большим, что даже если убрать этот мусор перепакованный файл будет больше оригинала.
  9. Меня беспокоит "non-standard type definition", в 7-zip метод сжатия отображается как XZ. Поэксперементировал тут со сжатием и моя догадка о правах на исполнение подтвердилась - нужно перепаковывать из под linux. Перепаковал файл без изменений и вот, что показывает 7-zip: Как видно в оригинале используется более эффективный алгоритм сжатия, кроме того есть непонятки с полем "характеристики".
  10. И ещё вопрос: при запаковке как mksquashfs выставит права и владельца для файлов? Если я буду распаковывать/паковать из под Windows через Cygwin права ведь выставятся не правильно (в Windows нет атрибута разрешения на выполнение)?
  11. @avkghost Не совсем так - проверка CRC происходит при "cgi/upload_image", код проверки находится в \usr\local\lib\libinfra.so (функция VOS_ImageVerify). Вкратце CRC32 для всего файла хранится по смещению 0x68, перед расчётом новой CRC её нужно обнулить. Я поменял версию и производителя в заголовке, но это ничего не дало - в web-интерфейсе и в микротике отображаются старые данные. Эти данные также хранятся в файлах version и show_version на squashfs. Теперь вот не знаю с какими параметрами и какой версией mksquashfs запаковывать обратно, binwalk вроде-бы пишет version 4.0. Ну и конечно для замены squashfs нужно пресчитать вторую CRC в заголовке uImage.
  12. Здравствуйте. Пытаюсь модифицировать прошивку сабжа, чтобы он выглядел для OLT как HUAWEI HG8245H. SN уже изменён через telnet. Теперь нужно поменять MAC-адрес на WAN-интерфейсе, версию ПО, вендора и модель устройства. Прошивка основана на OpenWRT, однако файл /etc/config/network находится на squashfs и просто так из консоли не меняется. Версия ПО и вендор указаны в заголовке файла и при простой замене в HEX-редакторе устройство такой файл не принимает - где-то есть контрольная сумма. Вот, что выдал binwalk 0 0x0 Copyright string: " 2000-2010 T&W. All rights reserved.rved." 1024 0x400 uImage header, header size: 64 bytes, header CRC: 0xFFCC4335, created: Thu Oct 23 10:41:47 2014, image size: 1184490 bytes, Data Address: 0x80002000, Entry Point: 0x80002000, data CRC: 0x46E9464C, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "OpenWrtLinux-3.10.12-svn24709" 1088 0x440 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 3481980 bytes 1311232 0x140200 Squashfs filesystem, little endian, version 4.0, compression:lzma (non-standard type definition), size: 2354781 bytes, 727 inodes, blocksize: 262144 bytes, created: Tue May 9 11:47:50 2017 unsquashfs не может распознать файл, но 7-zip делает это без проблем и распаковывает squashfs. Подскажите как запаковать изменённую прошивку обратно в образ с пересчётом контрольных сумм. Прошивка во вложении. TW2362H-CDEL-TW-R01B010Dffa43ac3-CN.squashfs.upf