Max-Forwards HTTP header ⏳
Во многих приложениях запросы проходят через цепочку прокси, балансировщиков и кэшей. Это скрытый слой инфраструктуры, который часто остаётся «невидимым» — а зря.
Один из способов подсветить эту цепочку — заголовок
По стандарту он применяется к методам
💙 По разным ответам при разных значениях
💙 Иногда запросы начинают вести себя по-разному → можно увидеть несогласованную конфигурацию, нестабильные фильтры, проблемные балансировщики
💙 Это помогает находить расхождения в маршрутизации и потенциальные точки обхода
Кейс редкий, но в правильный момент — очень показательный. Попробуй отправить💡
Во многих приложениях запросы проходят через цепочку прокси, балансировщиков и кэшей. Это скрытый слой инфраструктуры, который часто остаётся «невидимым» — а зря.
Один из способов подсветить эту цепочку — заголовок
Max-Forwards. Если отправить запрос с этим заголовком, можно ограничить количество промежуточных узлов, которые обработают запрос. По стандарту он применяется к методам
TRACE и OPTIONS, но в реальных системах встречается куда шире. Вот почему это полезно:Max-Forwards можно понять, сколько прокси стоит перед приложениемКейс редкий, но в правильный момент — очень показательный. Попробуй отправить
TRACE / или OPTIONS / с разными значениями Max-Forwards и сравни ответы — иногда цепочка раскрывается сама Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7🤔3🫡1
Упрощаем обработку приложений APK / XAPK / APKM / DEX / JAR / WAR с помощью BFScan ⚡️
Когда разбираешь мобильное приложение, главная боль — собрать карту API. Proxy ловит не всё, OpenAPI нет, код обфусцирован, запросы раскиданы по 20 классам.
📦 BFScan решает эту проблему. Это статический анализатор, который вытаскивает HTTP-запросы, эндпоинты, параметры и даже черновую OpenAPI-спеку прямо из APK / XAPK / APKM / DEX / JAR / WAR.
🎯 Что вытаскивает
⚫️ URL, пути, токены, API-ключи и другие подозрительные строки
⚫️ Сырые HTTP-запросы
⚫️ OpenAPI-спецификацию (по аннотациям и конфигам)
⚫️ Захардкоженные секреты
🔍 Что анализирует
Клиентские библиотеки:
⚫️ Retrofit
⚫️ Ktorfit
⚫️ Feign
Серверные фреймворки и аннотации:
⚫️ Spring Web
⚫️ JAX-RS / Jakarta REST
⚫️ Jakarta Servlets
⚫️ Micronaut
⚫️ Struts 1/2
⚫️ Ktor routing
⚫️ Play Framework
⚫️ Swagger / OpenAPI-аннотации
⚫️ web.xml / jetty.xml
🧵 Что удобно для реверса
⚫️ Автоматически декомпилирует даже обфусцированный код через
⚫️ Сшивает роуты, методы, параметры и тела запросов
⚫️ Даёт готовую базу для тестирования API, даже если приложение — чёрный ящик
🧪 Зачем багхантеру
⚫️ Быстрое перечисление скрытых методов API
⚫️ Поиск забытых эндпоинтов, внутренних роутов, legacy-методов
⚫️ Детект захардкоженных секретов → токены бэкенда, тестовые креды, Firebase-ключи
⚫️ Расширение поверхности атаки для мобилок и веба
⚫️ Отличная база для SSRF, IDOR, авторизационных багов, parameter pollution
Когда разбираешь мобильное приложение, главная боль — собрать карту API. Proxy ловит не всё, OpenAPI нет, код обфусцирован, запросы раскиданы по 20 классам.
📦 BFScan решает эту проблему. Это статический анализатор, который вытаскивает HTTP-запросы, эндпоинты, параметры и даже черновую OpenAPI-спеку прямо из APK / XAPK / APKM / DEX / JAR / WAR.
🎯 Что вытаскивает
🔍 Что анализирует
Клиентские библиотеки:
Серверные фреймворки и аннотации:
🧵 Что удобно для реверса
jadx🧪 Зачем багхантеру
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍3
Выполняем JS-код внутри <noscript><noscript> 💨
Внутри тега
Это приводит к интересному эффекту. Если написать что-то вроде:
то последовательность внутри не считается JS-комментарием, и не считается HTML-элементом, а попадает под категорию «некорректный HTML-тег»💲
HTML-парсер пытается «исправить» такую конструкцию — он удаляет невалидный HTML,
оставляя от исходного текста только:
Внутри тега
<noscript><noscript> браузер обрабатывает содержимое не как HTML, а как JavaScript-код. При этом действует важное правило парсера:Внутри <noscript> только текстовые узлы становятся JavaScript-кодом.
Комментарии или вложенные SVG/HTML-элементы удаляются парсером.
Это приводит к интересному эффекту. Если написать что-то вроде:
<noscript><noscript>al<//looks like js comment>ert(document.domain)</noscript>
или
<noscript><noscript>al</h1>ert(document.domain)</noscript>
то последовательность внутри не считается JS-комментарием, и не считается HTML-элементом, а попадает под категорию «некорректный HTML-тег»
HTML-парсер пытается «исправить» такую конструкцию — он удаляет невалидный HTML,
оставляя от исходного текста только:
al + ert(document.domain) → alert(document.domain)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10
Если в ходе рекона ты нашел файл ⤵️
В быстрой проверке поможет NPM Dependency Confusion Validator — новый инструмент от JSMon🔥
package.json, возможно, некоторые внутренние пакеты уязвимы для атаки, связанной с dependency confusion В быстрой проверке поможет NPM Dependency Confusion Validator — новый инструмент от JSMon
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤4
Необычное поведение href: как ограниченный DOM Clobbering превратить в полноценный Client-Side Path Traversal 🌫
Если в🚨
🟡 В обычном случае приложение и фильтры (например, DOMPurify) блокируют все протоколы, кроме
🟡 Но при использовании формы
🟡 Это делает возможным обращение к эндпоинтам или выполнение действий, которые при нормальном парсинге URL были бы невозможны.
Идём дальше: почти любые символы после🏃
Если в
href указать невалидный протокол вроде ftp:: или https::, браузер перестаёт интерпретировать атрибут как URL. Это полностью ломает ожидаемую логику проверки протоколов и открывает дополнительные векторы атак http и https.https:: строка уже не считается URL, и проверки протокола не срабатывают.Идём дальше: почти любые символы после
: приводят к аналогичному результату — браузер прекращает парсинг как URL и оставляет значение как обычный текст Please open Telegram to view this post
VIEW IN TELEGRAM
❤6
Unicode-суррогаты: как один битый символ превращается в обход валидации 🔡
В некоторых системах одиночные Unicode-суррогаты работают необычно: валидатор пропускает их как обычные буквы, а внутренние сервисы преобразуют их в вопросительный знак.
В ряде баз данных💭
Багхантер Krzysztof Balas нашел публичный эндпоинт, который отдавал данные пользователя, если ввести:
⚫️ дату рождения,
⚫️ фамилию,
⚫️ ZIP-код.
Авторизация не требовалась. После первого репорта разрабы закрыли все спецсимволы, URL-encoding и даже «юникодные аналоги» запрещённых символов.
Но осталось кое-что ещё — одиночные Unicode-суррогаты, например
, то парсеры UTF-8 не смогут корректно отобразить Unicode-суррогаты, которые часто используются в эмодзи с low и high парами. Все, что ты получаешь при попытке их отобразить, — это символ замены Юникода.
Некоторые парсеры, по-видимому, идут еще дальше и упрощают символ замены до вопросительного знака (💡
В некоторых системах одиночные Unicode-суррогаты работают необычно: валидатор пропускает их как обычные буквы, а внутренние сервисы преобразуют их в вопросительный знак.
В ряде баз данных
? — это wildcard. Так и возникает уязвимость, которая даёт доступ к данным Юникод использует диапазон символов U+0000–U+10FFFF. Но старый формат UTF-16 не мог напрямую закодировать все символы выше U+FFFF, поэтому придумали специальный механизм — суррогаты. Есть два типа:
High surrogates — старшие суррогаты
Диапазон: U+D800–U+DBFF
Low surrogates — младшие суррогаты
Диапазон: U+DC00–U+DFFF
По отдельности они не являются валидными символами. Но если записать их пару (high + low), то вместе они кодируют один символ за пределами базовой области Unicode (например эмодзи).
Пример: эмодзи 😄 — это комбинация двух суррогатов в UTF-16.
Багхантер Krzysztof Balas нашел публичный эндпоинт, который отдавал данные пользователя, если ввести:
Авторизация не требовалась. После первого репорта разрабы закрыли все спецсимволы, URL-encoding и даже «юникодные аналоги» запрещённых символов.
Но осталось кое-что ещё — одиночные Unicode-суррогаты, например
\udc2a. Если отправить что-то вроде:"lastname": "D\udc2a\udc2a",
"zipcode": "1\udc2a\udc2a\udc2a\udc2a"
, то парсеры UTF-8 не смогут корректно отобразить Unicode-суррогаты, которые часто используются в эмодзи с low и high парами. Все, что ты получаешь при попытке их отобразить, — это символ замены Юникода.
Некоторые парсеры, по-видимому, идут еще дальше и упрощают символ замены до вопросительного знака (
?), что и приводит к возникновению уязвимости Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥2🤯2
Как слияние HTML-атрибутов превращается в рабочий XSS-вектор ⚡️
У страницы может быть только один🎨
Поскольку некоторые санитайзеры могут не учитывать механизм объединения атрибутов, можно использовать эту фичу для разделения XSS-вектора по нескольким тегам:
После парсинга браузер сформирует единый
1⃣
2⃣ Когда анимация завершается, событие
3⃣ Санитайзер может пропустить такой пэйлоад, так как опасные атрибуты находятся в разных местах и выглядят безвредно по отдельности.
➡️ При написании поста вдохновились этим исследованием
У страницы может быть только один
<html> и один <body>. Если определить большее количество, их атрибуты будут объединены с атрибутами первого элемента Поскольку некоторые санитайзеры могут не учитывать механизм объединения атрибутов, можно использовать эту фичу для разделения XSS-вектора по нескольким тегам:
<body style=animation:x id='First Body Tag'>
<body onanimationend=alert(this.id)>
<style>@keyframes x{
После парсинга браузер сформирует единый
<body>, в результате чего:style=animation:x активирует фиктивную CSS-анимацию.onanimationend вызывает JavaScript.Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11
Малоизвестные техники для масштабного перечисления поддоменов 🔥
Активная DNS-разведка обычно сводится к следующему набору:
❌ хороший словарь (Assetnote, SecLists и т.д.),
❌ список «проверенных» публичных рекурсивных DNS-серверов,
❌ инструмент для массовых DNS-запросов: massdns, puredns, shuffledns.
Публичные DNS-серверы слушают UDP/53 и принимают запросы со всего интернета. Многие из них перегружены, неправильно настроены, либо намеренно возвращают ложные ответы.
Результат — шум,
Что лучше?
Запросы напрямую к авторитативному DNS-серверу почти всегда лучше, чем использование публичных рекурсивных резолверов.
Техники для глубокой разведки💃
1️⃣ ENTs и NOERROR
В DNS есть промежуточное состояние, которое большинство инструментов игнорирует: Empty Non-Terminals. Они возвращают
Отлично подходят для поиска скрытых поддеревьев и позволяют избежать бесполезного фаззинга.
2️⃣ NSEC / NSEC3 zone walking
NSEC формирует связанный список валидных имён, поэтому обход зоны тривиален с инструментами вроде ldns-walk. NSEC3 хеширует имена, но всё ещё позволяет:
▪️ собирать хешированные метки,
▪️ офлайн брутфорсить их с помощью инструментов вроде nsec3map,
▪️ восстанавливать структуру зоны.
3️⃣ ICANN CZDS
CZDS предоставляет полные файлы зон для множества gTLD. Если твой таргет использует редкий TLD, часто можно получить все домены в зоне и сразу получить качественные точки старта для перечисления.
🔗 Пост вдохновлен этой презентацией
Активная DNS-разведка обычно сводится к следующему набору:
Публичные DNS-серверы слушают UDP/53 и принимают запросы со всего интернета. Многие из них перегружены, неправильно настроены, либо намеренно возвращают ложные ответы.
Результат — шум,
NOERROR там, где должен быть NXDOMAIN, и куча мусорных поддоменов.Что лучше?
Запросы напрямую к авторитативному DNS-серверу почти всегда лучше, чем использование публичных рекурсивных резолверов.
Если тебе нужно просто резолвить список поддоменов — используй zdns. Он в целом быстрее и надёжнее , чем dnsx.
Техники для глубокой разведки
В DNS есть промежуточное состояние, которое большинство инструментов игнорирует: Empty Non-Terminals. Они возвращают
NOERROR / NODATA и незаметно показывают, какие ветки иерархии реально существуют. Отлично подходят для поиска скрытых поддеревьев и позволяют избежать бесполезного фаззинга.
NSEC формирует связанный список валидных имён, поэтому обход зоны тривиален с инструментами вроде ldns-walk. NSEC3 хеширует имена, но всё ещё позволяет:
CZDS предоставляет полные файлы зон для множества gTLD. Если твой таргет использует редкий TLD, часто можно получить все домены в зоне и сразу получить качественные точки старта для перечисления.
🔗 Пост вдохновлен этой презентацией
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤5
Распространенные векторы атак race condition в веб-приложениях 🤔
Race condition редко находятся автоматическими сканерами. Это уязвимости не про пэйлоад, а про тайминг, состояние и бизнес-логику.
Проще, когда есть доступ к исходникам. Но на практике багхантер почти всегда работает вслепую — через поведение приложения.
Ниже — два рабочих вектора, которые чаще всего выстреливают💸
HTTP/1.1 last-byte синхронизация
Атака эксплуатирует то, как сервер обрабатывает частично отправленные запросы.
Сценарий:
✅ Открыть первый запрос и удерживать соединение (не отправлять весь контент сразу).
✅ Отправить второй запрос в момент, когда первый ещё обрабатывается.
✅ Добиться перекрытия операций проверки и изменения состояния.
Так ломаются проверки лимитов, купоны, списания и другие бизнес-процессы.
HTTP/2 single-packet атаки
HTTP/2 ускоряет запросы, но даёт атакующему контроль над таймингом.
Сценарий:
✅ Отправлять несколько запросов по одному соединению, удерживая часть данных.
✅ После паузы завершить все запросы одновременно одним TCP-пакетом.
✅ Минимизировать сетевой джиттер и повысить стабильность гонки.
Метод особенно эффективен против логики, не рассчитанной на параллельность.
Что можно сломать
Последствия race condition чаще всего логические:
➖ двойное списание средств;
➖ повторное применение купонов и бонусов;
➖ обход ограничений и лимитов;
➖ неконсистентное состояние данных,
➖ DoS и ошибки контроля доступа,
По импакту такие баги часто уходят в high или critical.
P. S. Для эксплуатации используй Burp Suite Turbo Intruder, а практику оттачивай на Web Security Academy😓
Race condition редко находятся автоматическими сканерами. Это уязвимости не про пэйлоад, а про тайминг, состояние и бизнес-логику.
Проще, когда есть доступ к исходникам. Но на практике багхантер почти всегда работает вслепую — через поведение приложения.
Ниже — два рабочих вектора, которые чаще всего выстреливают
HTTP/1.1 last-byte синхронизация
Атака эксплуатирует то, как сервер обрабатывает частично отправленные запросы.
Сценарий:
Так ломаются проверки лимитов, купоны, списания и другие бизнес-процессы.
HTTP/2 single-packet атаки
HTTP/2 ускоряет запросы, но даёт атакующему контроль над таймингом.
Сценарий:
Метод особенно эффективен против логики, не рассчитанной на параллельность.
Что можно сломать
Последствия race condition чаще всего логические:
По импакту такие баги часто уходят в high или critical.
P. S. Для эксплуатации используй Burp Suite Turbo Intruder, а практику оттачивай на Web Security Academy
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🤔2❤1
Почему в ходе разведке нельзя игнорировать редиректы ❓
Мы привыкли к подходу:
💡 Предположим, во время разведки тебе под руку попался странный ресурс:
⚫️ В имени нет названия компании
⚫️ Но он делает 302-редирект на домен компании
⚫️ Домен не резолвится
Формально он не входит в скоуп, но фактически может являться частью инфраструктуры.
Как помогает urlscan.io
urlscan.io позволяет смотреть на цель как на систему, а не как на один URL. Он показывает:
⚫️ Все редиректы и переходы
⚫️ Домены и IP, с которыми общается страница
⚫️ Загружаемые JS, CSS и сторонние ресурсы
⚫️ Сookies, DOM, JS-переменные
⚫️ Облачные ресурсы, которые не видно через DNS
Таким образом, даже если домен не резолвится, редирект или связанный ресурс всё равно может существовать.
Почему это расширяет скоуп🥳
Когда ты анализируешь редиректы:
✔️ В скоуп попадают активы без прямой связи по имени
✔️ Находятся облачные ресурсы, забытые хосты, dev-стенды
✔️ Появляется возможность связать тот самый непонятный ресурс с целевой организацией
Мы привыкли к подходу:
Есть домен в скоупе — смотрим его. Нет в скоупе — идем дальше.
Что, если подойти к процессу поиска багов в стиле red team?
Формально он не входит в скоуп, но фактически может являться частью инфраструктуры.
Как помогает urlscan.io
urlscan.io позволяет смотреть на цель как на систему, а не как на один URL. Он показывает:
Таким образом, даже если домен не резолвится, редирект или связанный ресурс всё равно может существовать.
Почему это расширяет скоуп
Когда ты анализируешь редиректы:
Иногда самое интересное — между запросами, а не в ответе💲
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥2🤔2
В HTTP-запросах почти всегда есть мусор:
автогенерированные заголовки, дубликаты, лишний контекст. Удалять их по одному и каждый раз проверять ответ — слишком долго💤
Header Guardian (Burp Suite) или Squash (Caido) автоматически очистят запросы от ненужных заголовков, оставляя только то, что реально влияет на поведение сервера.
🏃♂️ При активации Squash запускает фоновую задачу, которая:
⚫️ Отправляет исходный запрос
⚫️ Итеративно удаляет параметры запроса, поля формы, JSON и заголовки (включая отдельные файлы cookie)
⚫️ Сравнивает ответы, чтобы выявить инвариантное поведение
⚫️ Сохраняет только те поля, которые необходимы для сохранения исходного ответа
⚫️ Отправляет минимизированный запрос в новую вкладку Replay для просмотра и тестирования
автогенерированные заголовки, дубликаты, лишний контекст. Удалять их по одному и каждый раз проверять ответ — слишком долго
Header Guardian (Burp Suite) или Squash (Caido) автоматически очистят запросы от ненужных заголовков, оставляя только то, что реально влияет на поведение сервера.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤19🥴2
Автоматизация покрывает известные баги, новые — находит ручной анализ 💡
6 ручных кейсов для поиска новых векторов атак👇
1️⃣ Переосмысление «невозможного»
Ищи в документации формулировки вида «X не может делать Y». Это не запрет — это предположение разработчиков.
Часто именно здесь:
⚫️ Ошибки в ролевых моделях
⚫️ Обходы проверок
⚫️ Слабые enforcement-механизмы
2️⃣ Обход paywall’ов
Купи доступ один раз. Проанализируй, какие API-запросы реально включают платные фичи.
Дальше:
⚫️ Повтори их с бесплатного аккаунта
⚫️ Проверь, нет ли только фронтенд-проверок
Да, не все программы это принимают. Но финансовый ущерб = реальный риск для бизнеса.
3️⃣ «А что это за библиотека?»
Нашел интересный эндпоинт — начинай фаззить, чтобы бэкенд вернул какие-то ошибки: копируй точный текст ошибки/исключения и ищи в GitHub, чтобы понять, какая именно библиотека используется.
Дальше:
⚫️ Изучай исходники
⚫️ Смотри закрытые issues
⚫️ Проверяй зависимости
4️⃣ Ломай UI-логику
Создавай состояния, которые UI «не должен» показывать.
Не ограничивайся
⚫️ Меняй значения постепенно
⚫️ Подставляй неожиданные коды подписки
⚫️ Меняй баланс, статусы, флаги
Смотри, как приложение реагирует, а не что рисует UI.
5️⃣ Используй приложение как обычный пользователь
Медленно. Вручную. Через прокси. Параллельно фиксируй идеи:
⚫️ HTML запрещён при регистрации — а при редактировании профиля?
⚫️ UI блокирует — а API?
⚫️ Один флоу проверил, а альтернативный?
Логика пользователя ≠ логика разработчика.
6️⃣ Анализируй ответы сервера
Сравнивай, что вернул бэкенд, а что — фронт.
Типичные находки:
⚫️ Скрытые данные на фронте
⚫️ Флаги beta-фич
⚫️ «Странные» свойства без UI
Фронт часто просто не показывает лишнее, но сервер уже всё выдал.
6 ручных кейсов для поиска новых векторов атак
Ищи в документации формулировки вида «X не может делать Y». Это не запрет — это предположение разработчиков.
Часто именно здесь:
Купи доступ один раз. Проанализируй, какие API-запросы реально включают платные фичи.
Дальше:
Да, не все программы это принимают. Но финансовый ущерб = реальный риск для бизнеса.
Нашел интересный эндпоинт — начинай фаззить, чтобы бэкенд вернул какие-то ошибки: копируй точный текст ошибки/исключения и ищи в GitHub, чтобы понять, какая именно библиотека используется.
Дальше:
Создавай состояния, которые UI «не должен» показывать.
Не ограничивайся
false → true:Смотри, как приложение реагирует, а не что рисует UI.
Медленно. Вручную. Через прокси. Параллельно фиксируй идеи:
Логика пользователя ≠ логика разработчика.
Сравнивай, что вернул бэкенд, а что — фронт.
Типичные находки:
Фронт часто просто не показывает лишнее, но сервер уже всё выдал.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8❤3
По реакциям
По репостам
По комментариям
Дальше — больше
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10🔥2❤🔥1
Первичный анализ любого APK-файла: советы багхантеру 📞
Если в скоуп багбаунти-программы входят мобилки — никогда не проходи мимо. Вот основные шаги перед началом анализа исходников:
1️⃣ Проверка подлинности и целостности APK
Прежде чем тратить время на анализ, убедись, что код подлинный:
Команда выводит отпечаток сертификата подписи — сравни его с официальной версией.
2️⃣ Распаковка и анализ структуры APK с помощью APKTool
APKTool разбирает APK на читаемые компоненты: манифест с разрешениями и компонентами, ресурсы интерфейса и конфигурации, а также Smali-код — представление логики приложения на уровне байткода.
3️⃣ Распаковка APK
В результате появится структура:
⚫️ AndroidManifest.xml — декларация компонентов, разрешений и настроек
⚫️ res/ — ресурсы интерфейса, строки, XML-конфигурации
⚫️ smali/ — дизассемблированный байткод
⚫️ lib/ — нативные библиотеки под разные архитектуры
⚫️ assets/ — дополнительные файлы: базы данных, конфиги, медиа
4️⃣ Извлечение полезной информации из ресурсов
Ресурсы часто раскрывают больше, чем планировали разработчики. Изучай
Пример:
Такие эндпоинты часто защищены слабее прода. Нередко они принимают боевые токены или допускают обход аутентификации.
5️⃣ Автоматический парсинг URL
Вместо ручного просмотра используй apk2url:
Тулза автоматически парсит все URL из кода и ресурсов, формируя список потенциальных API-точек для дальнейшего исследования.
Теперь ты понимаешь структуру приложения: его компоненты, разрешения и точки взаимодействия с сетью. Но структура не показывает логические ошибки и реальное поведение кода — для этого нужно разбираться в реализации💡
Если в скоуп багбаунти-программы входят мобилки — никогда не проходи мимо. Вот основные шаги перед началом анализа исходников:
Прежде чем тратить время на анализ, убедись, что код подлинный:
apksigner verify --print-certs target.apk
Команда выводит отпечаток сертификата подписи — сравни его с официальной версией.
APKTool разбирает APK на читаемые компоненты: манифест с разрешениями и компонентами, ресурсы интерфейса и конфигурации, а также Smali-код — представление логики приложения на уровне байткода.
Прежде чем читать код, нужно понять архитектуру приложения. Какие компоненты доступны извне? Какие разрешения запрашиваются? Какие ресурсы могут утекать? APKTool отвечает на эти вопросы.
apktool d target.apk -o target_unpacked
В результате появится структура:
Ресурсы часто раскрывают больше, чем планировали разработчики. Изучай
res/values/strings.xml, res/xml/ и другие файлы — туда нередко попадают staging-серверы, dev-эндпоинты и внутренние API.Пример:
<string name="api_base_url">https://api-staging.target.com</string>
<string name="debug_endpoint">https://internal-admin.target.com</string>
Такие эндпоинты часто защищены слабее прода. Нередко они принимают боевые токены или допускают обход аутентификации.
Вместо ручного просмотра используй apk2url:
git clone https://github.com/n0mi1k/apk2url
./apk2url.sh /path/to/target.apk
Тулза автоматически парсит все URL из кода и ресурсов, формируя список потенциальных API-точек для дальнейшего исследования.
Теперь ты понимаешь структуру приложения: его компоненты, разрешения и точки взаимодействия с сетью. Но структура не показывает логические ошибки и реальное поведение кода — для этого нужно разбираться в реализации
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤4👍4