Анализ сигнатур

Многие API снабжают каждый запрос производным токеном — хешем или HMAC от метода, URL, тела, куки и общего секрета. Анализ сигнатур восстанавливает этот способ вывода офлайн, по уже импортированным захватам, чтобы при replay токен можно было пересчитывать заново, а не копировать устаревшее значение. Всё выполняется локально в рабочей области; наружу ничего не отправляется. Используйте это только на системах, которые вам разрешено тестировать.

Открытие вкладки Signature

Функция находится в рабочем пространстве API: откройте захват и переключитесь на вкладку Signature (восьмая по счёту). Она просматривает все видимые сессии и выводит список полей-кандидатов — токенов, меняющихся от запроса к запросу и заслуживающих исследования. На каждой карточке показаны имя поля, эндпоинт, бейдж расположения (Header / Cookie / Query parameter), кодировка, число запросов и доля уникальных значений.

Ввод текста в поле поиска фильтрует по имени поля или эндпоинту. Раскройте карточку, чтобы увидеть flip-анализ, наблюдаемые значения, тестировщик схем и шаблон хука Frida. Двойная активация карточки переходит к её первому запросу-образцу.

Как обнаруживаются кандидаты

По каждому эндпоинту просматриваются все заголовки запросов (кроме Cookie), параметры строки запроса и куки. Значение становится кандидатом, когда:

• его имя совпадает с подсказкой о сигнатуре (sign, signature, sig, hash, digest, hmac, mac, checksum) либо оно похоже на высокоэнтропийный hex / base64 / base64url;
• оно достаточно длинное — не менее 12 символов для заголовков и параметров запроса, не менее 8 для куки (усечённые токены бывают короткими), и не более 512;
• оно меняется как минимум в 70% запросов к этому эндпоинту (для поля нужно не менее 2 запросов).

Корреляционные и trace-идентификаторы (x-request-id, x-correlation-id, traceparent, x-csrf-token и тому подобное) занесены в denylist — они меняются в каждом запросе, но сигнатурами не являются. Кандидаты оцениваются по шкале 0–1 по подсказке в имени, кодировке, длине дайджеста (32/40/64 hex-нибблов = MD5/SHA-1/SHA-256) и изменчивости, а затем сортируются по оценке.

[!NOTE] Токены в куки — граждане первого класса. Производное значение внутри заголовка Cookie обнаруживается так же, как поле заголовка или строки запроса, а окружающие куки сохраняются как контекст образца, чтобы можно было проверять межполевые конструкции.

Корреляция входов через flip-анализ

При раскрытии карточки запускается flip-анализ по не более чем 12 образцам. Он сравнивает каждую пару захваченных запросов и классифицирует каждый компонент запроса:

Отслеживаемые компоненты — method, path, body, а также каждый query:<name>, header:<name> и cookie:<name>. Летучие заголовки (date, user-agent, authorization, content-length, host и подобные) исключены из корреляции заголовков. Скоррелированные компоненты показываются бейджами; исключённые перечисляются в разделе «Ruled out». Так вы узнаёте, какие поля канонизация действительно читает, прежде чем тратить время на брутфорс.

Брутфорс классических канонизаций

Блок Offline canonicalization brute-force прогоняет библиотеку типовых конструкций по образцам кандидата (до 8) и сообщает обо всех схемах, воспроизводящих наблюдаемые токены. Введите секреты-кандидаты по одному на строку в wordlist и нажмите Test schemes.

Классические схемы покрывают MD5, SHA-1, SHA-256, HMAC-MD5, HMAC-SHA-1 и HMAC-SHA-256 поверх канонизаций вида:

• отсортированные параметры запроса (a=1&b=2), сырые или URL-декодированные;
• секрет в конце, в начале или в обёртке (secret + params + secret);
• sorted params + "&key=" + secret;
• path + timestamp + MD5(body) и method + path + timestamp + body;
• HMAC(secret, method\npath\ntimestamp\nSHA-256(body)).

Дайджесты сравниваются в нижнем регистре hex, верхнем регистре hex, base64 и base64url (хвостовое дополнение = игнорируется). Для каждого совпадения показываются matched/total запросов, использованный секрет и точная каноническая строка, воспроизведшая первый образец. Схема, совпавшая по всем образцам, вызывает тост «Signature scheme recovered».

Восстановление конструкций с префиксом и усечением

Некоторые токены — вообще не хеши компонентов запроса, а хеши другого захваченного поля. Поиск хешей с префиксом нацелен на конструкции вида:

prefix + HASH(secret + <another field> + prefix)[dropN:]

Он ограничен уравнением по длине. Для hex-дайджестов observedLength = prefixLength + (digestHexLength - dropN), что сводит жизнеспособные формы (хеш, длина префикса, drop) к горстке вариантов на кандидата. Поиск перебирает MD5/SHA-1/SHA-256 по самым распространённым захваченным полям (до 16, исключая корреляционные ID и само поле сигнатуры), несколько порядков secret/field/prefix, длины префикса 0–8 с шагом 2 и drop до 16. Непустой префикс должен меняться между образцами — это отличает настоящий случайный префикс от просто усечённого хеша.

Канонический пример — кука fgssca-goldapple: случайный префикс из 4 hex-символов, за которым следует sha1(appSecret + gsscCookie + prefix) с отброшенными первыми 4 hex-символами. Успешное совпадение сообщает алгоритм, секрет и derived from: cookie:<name> — а flip-анализ показывает это поле как скоррелированный вход.

Построение wordlist секретов

Wordlist предзаполняется добычей из захватов: собираются значения полей, чьи имена похожи на секреты (secret, appkey, api_key, client_secret, salt и подобные), затем добавляется небольшой встроенный словарь (secret, password, changeme, key, API_SECRET, …). Список можно свободно редактировать — добавляйте всё, что удалось извлечь из бандла приложения или JS. Поиск с префиксом также пробует пустой секрет и ограничивает список 32 записями.

[!TIP] Если ни одна схема не совпала, кнопка Copy Frida hook template на карточке даёт готовый скрипт, который хукает javax.crypto.Mac, java.security.MessageDigest и SecretKeySpec, логирует их входы и выходы и помечает любой дайджест, чья длина совпадает с наблюдаемым токеном. Подключите его к приложению, следите за строками [sig-trace] и подайте залогированную каноническую строку обратно в wordlist.

Передача результатов в replay

Когда схема восстановлена, превратите её в вычисляемое поле, чтобы replay пересчитывал токен при каждой отправке. Поля схемы exampleInput и derived from напрямую отображаются на DSL вычисляемых полей — ссылки на поля вида cookie:name, header:name, query:name и body, плюс функции sha1 / sha256 / md5 / HMAC и пайп усечения skip:N. Приведённая выше конструкция fgssca-goldapple превращается в:

{{ p = randomHex:4; p + sha1(fgsscSecret + cookie:gssca-goldapple + p) | skip:4 }}

Полное описание DSL — в /docs/ru/replay/variables/, а подключение вычисляемых полей к запросу replay — в /docs/ru/replay/workbench/.