Можно поправить это место в бинарнике wsc https://github.com/drygdryg/Tenda-A...Space/cbb/src/wps/rtk/src/txpkt.c#L2856-L2857 Code: TagSize = strlen(pCtx->manufacturer); pMsg = add_tlv(pMsg, TAG_MANUFACTURER, TagSize, (void *)pCtx->manufacturer); на Code: TagSize = strlen(pCtx->pin_code); pMsg = add_tlv(pMsg, TAG_MANUFACTURER, TagSize, (void *)pCtx->pin_code); Там два байта всего. И вместо manufacturer будет виден pin.
Но я Вам советовал не совсем это, точнее даже совсем не это: или Также обратите внимание, что в моей последней цитате, вариант "затем" не перекрывает "сперва" (при желании, их можно поменять местами, но не исключить первый). UP На перебор всех вариантов из 4 символов, с вашей реализацией потребуется ~21 час. Но, повторюсь, СНАЧАЛА желательно проверить строки "\x00\x00\x00\x00" и "\xFF\xFF\xFF\xFF", затем эти же строки, но длиной от 1 до, скажем, 256 символов (бОльшая длина менее вероятна и не факт, что корректно пройдёт через HMAC), и только потом приступать к полному перебору (что, скорее всего, не понадобится). А DeltaSeed я бы пробовал в такой последовательности: 1,2,3,0,4,5...
Походу, вопрос: а как собрать pixi под Винду? И что есть mode 2,4,5 (eCos*) и где они подробно описаны?
Попытаюсь перебрать все размещения байтов (от 0 до 255), если хватит терпения и времени Проблемка в том, что это займёт действительно много времени на одном ядре (256^1+256^2+256^3+256^4=4311810304 комбинаций), и, как говорил @binarymaster, разумно было бы модифицировать Hashcat для этих целей (насколько это сложно, не знаю), но пока что у меня нет совместимого с ним железа.
Т.е., строки "\x00\x00\x00\x00" и "\xFF\xFF\xFF\xFF" Вы уже пробовали, и они не подошли? Для каких целей? В нашем случае, когда E-Hash1=E-Hash2, достаточно ОДИН РАЗ сбрутить этот "ПИН" (точнее, халф), ибо он будет одинаковым для всех глючных устройств.
Попробую в скором времени, в первую очередь их, разумеется. Спасибо за совет, сделал: пропатчил бинарник wscd, глядя на исходники, нашёл смещение от pCtx для пин-кода и заменил им смещение manufacturer. Но возникла проблема при запаковке прошивки: на этом роутере SquashFS, причём не простая, а с вендорскими патчами от Realtek: для распаковки добрые люди создали набор патчей для unsquashfs, а вот чтобы запаковать, я использую обычную mksquashfs, и в итоге роутер не принимает прошивку, где ФС запакованна ею. Spoiler: binwalk - анализ исходной прошивки Code: $ binwalk -e netis\(WF2419\)-V2.2.41694.bin DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 11280 0x2C10 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2371584 bytes 633954 0x9AC62 Squashfs filesystem, big endian, version 2.0, size: 2280896 bytes, 417 inodes, blocksize: 65536 bytes, created: 2017-05-16 06:29:47 Spoiler: binwalk - анализ перепакованной прошивки Code: $ binwalk firmware_with_patched_wscd.bin DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 11280 0x2C10 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2371584 bytes 633954 0x9AC62 Squashfs filesystem, little endian, version 4.0, compression:gzip, size: 2724689 bytes, 394 inodes, blocksize: 65536 bytes, created: 2020-11-17 20:23:55 Возможно, нужно попробовать более старую версию mksquashfs (текущая генерирует файлы версии 4.0, а в роутере 2.0), буду экспериментировать. РЕД: попробовал собрать более старые версии squashfs-tools из исходников — они просто отказываются собираться с современным компилятором в современном окружении. Видимо, придётся искать какой-нибудь старый дистрибутив либо SDK.
Лучше ориентироваться на первый вызов strlen() в send_wsc_M1() и send_wsc_M3(). А не на структуры в исходниках. Там два числа 0xae43(manufacturer) и 0xadb4(pin) для прошивки версии V2.2.41694, до патча wscd md5: d7bd12a5304c4d28a96e70a853ccbee4 Firmware mod kit вроде бы распаковывает / запаковывает, но там еще в конце есть контрольная сумма, которую надо пересчитать. Алгоритм такой-же как здесь (id хидеров другие): https://forum.antichat.ru/threads/480969/#post-4422553 Я бы предложил сначала просто распаковать, запаковать не модифицируя, пересчитать crc, залить в роутер, если всё ок - заливать патченную.
Сверил wscd в вашей прошивке с пропатченным мною — MD5 совпадают. Перепаковал прошивку, только заменив wscd, собрал с помощью squqashfs-2.1 из firmware-mod-kit (я вижу, вы тоже этой же версией запаковали) — размер образа squashfs вышел на 400 КиБ больше, чем оригинальный. Перепакованная прошивка: https://transfiles.ru/07i03 Вижу, что у вас размер перепакованной ФС близок к оригинальной, как вы её запаковывали?
Запаковывал firmware-mod-kit. У вас просто образ squqashfs получился, а в прошивке ещё хидеры должны быть, как в оригинале, и firmware-mod-kit должна была об этом позаботится. У меня так, во всяком случае.
Походу, заметил в pixi странную фичу: Seed ES1 зачем-то ищется в обе стороны от Seed N1 (а не только вперёд), что вдвое замедляет работу: Code: [DEBUG] src/pixiewps.c: 948:main(): Debugging enabled [DEBUG] src/pixiewps.c: 951:main(): Mode is auto (no --mode specified) [DEBUG] src/pixiewps.c: 977:main(): Modes: 3 (RTL819x), 0 (), 0 (), 0 (), 0 () [DEBUG] src/pixiewps.c:1128:main(): Trying with E-S1: 10d4d83e4e9a19b97470e4d14515c3a2 [DEBUG] src/pixiewps.c:1128:main(): Trying with E-S1: 10d4d83e4e9a19b97470e4d14515c3a2 [DEBUG] src/pixiewps.c:1245:main(): * Mode: 3 (RTL819x) [DEBUG] src/pixiewps.c:1278:main(): Start: 1606071849 (Sun Nov 22 19:04:09 2020 UTC) [DEBUG] src/pixiewps.c:1281:main(): End: 0 (Thu Jan 1 00:00:00 1970 UTC) [DEBUG] src/pixiewps.c: 117:crack_thread_rtl(): Seed N1 found (1604666682) [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666682 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666683 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666681 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666684 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666680 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666685 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666679 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666686 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666678 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666687 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666677 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666688 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666676 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666689 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666675 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666690 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666674 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666691 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666673 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666692 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666672 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666693 [DEBUG] src/pixiewps.c: 389:find_rtl_es1(): Trying Seed E-S1: 1604666671^C Это баг, или такое где-то бывает нужно?
@VasiliyP, @4Fun Коль уж патчите прошивку, хорошо бы сделать, чтобы M5 отправлялся при любом (невалидном) пине, и посмотреть точный ES1
Так задумано Spoiler Как видите, если вы перебираете полный диапазон дат, в качестве старта выбирается дата, несколько выше текущей (Sun Nov 22 19:04:09 2020 UTC в вашем логе).
Да, но это утверждение из другой оперы: диапазон дат (заданный ключами --force, --[c]statr/end или +-сутки по умолчанию) используется только при поиске seed-N1. А seed-ES1 всегда, независимо от параметров, ищется в диапазоне (seed-N1 +- MODE3_TRIES), т.е., +- 10 минут. Так что мой вопрос "это баг, или фича?" остаётся в силе и сводится к вопросу: существуют ли в природе дивайсы, у которых seed-ES1 < seed-N1 (в mode3)? Прошу всех, кто в курсе, прояснить эту ситуацию.
Здесь боролись за расширение диапазона (увеличили константу MODE3_TRIES), и эффект был достигнут, но опять же, в директном направлении. А о целесообразности направления ретроградного там вроде ни слова. Или я невнимательно прочитал? PS Поскольку такое поведение явно предусмотрено авторами, тогда это уже не баг, а идеоголическая ошибка. Что не снимает вопроса.
Это одно и то же. Если роутер может перевести время вперёд, точно так же он может его перевести и назад. Разве это не очевидно? Update: To overcome this problem a small window of seeds forward in time and one backwards (clocks can skew in either direction), should be tested for E-S1 and E-S2. Currently, such window exists but only in the future for a small number of seconds
@VasiliyP, благодарю, теперь всё ясно Занялся этим сам. Проверил: 1) все монотонные строки (из одного повторяющегося символа) длиной от 1 до 2048 байт; 2) все комбинации длиной 1, 2 и 3 символа; 3) все комбинации из 4 символов в пределах +4 секунд от N1; 4) psk=0 Больше идей нет. Теперь надежда только на прошивку.
