Текст создан искуственным интеллектом. Естественный не использовался.

Огромное количество людей сидели и ждали когда же наконец у них появится кнопка “бабло”, чтобы можно было ее нажать и из волшебной коробочки начали сыпаться деньги. И вот, с приходом “искуственного интеллекта” кажется такая коробочка появилась. Теперь любой мамкин хакер, папкин реверсер и бабкин внук может купить подписку на механическую пианину за $20, закинуть туда все мобильные приложения которые он выкачал из багбаунти программы и ждать когда прозойдет волшебство. А оно обязательно произойдет. Добрый бот, перед тем как забанить аккаунт за нарушение политики использования сервиса, одарит незадачливого “исследователя” отчетом с кучей уязвимостей уровня High и даже Critical. Счастливцу останется только отнести отчет на ББ платформу и передать в заботливые руки триажеров, которые от стресса уже третий раз за этот день ходили трогать траву…

А что не так то?! Ведь XBOW же! Ведь Mythos! Ведь “too dangerous to release!!! Ты че пес?!

Как обстоят дела на самом деле

Я где-то видел интересное мнение о том, чем является AI для любого кто им пользуется: это множитель. Если пользователь, как специалист — полный ноль, то нужно ли говорить что будет при умножении на ноль?

И это свойство проявляется буквально в каждом аспекте использования AI инструментов. При этом я сейчас не говорю о качестве, галлюцинациях и всем таком прочем. Про это сказано достаточно. Результат может быть качественным, но никогда сам по себе. Тем более если мы говорим о каком-то многоэтапном процессе.

Приведу еще одну аналогию (люблю я это дело!): автоматический кузнечный молот (он же пневматический ковочный молот). Если дать его человеку, который до этого ни разу в жизни не ковал (ну или каждое утро ходил в офис мимо кузницы :D), то результат будет плачевный. Вероятно и для человека тоже.

Если же человек профессиональный кузнец, то… результат тоже будет не отличный потому что эта штука тоже требует освоения. Но когда профессионал ее освоит, то производительность его труда вырастет в разы. Хотя конечно всегда найдутся люди, которые скажут, что это уже не кузнечное дело, нет души и т.д. и т.п.

Поэтому никакие волшебные AI инструменты, никакие подписки за 20, 100, 200, 5000 баксов не заменят профессиональный опыт. По крайней мере в перспективе ближайших лет. Наверное, со временем, мы научимся перекладывать наш опыт в эту механическую пианину чтобы она играла ровно ту музыку, которую мы от нее ожидаем, но пока такого нет и близко.

Подумайте вот еще над какой мыслью: если бы подписка на AI скажем за $5000 и ворох “автопентестеров” с гитхаба решали бы проблему поиска уязвимостей в софте, то почему все крупные вендоры еще не закрыли свои ББ программы? Зачем им постоянно платить вам, если они могут поставить себе это в пайплайн и находить то же самое что и вы?

Значит AI бесполезно для мобильного похека? Нет.

Ищем пользу

Самой главной проблемой для меня в любом анализе приложений является рутина. Ее довольно много и я так и не научился ее любить. Впрочем она есть не только в анализе, но и в разработке приложений. Еще неизвестно где ее больше =)

Тут важно сразу понять одну вещь: поиск критических уязвимостей в системах это не рутина. По определению. Это всегда отчасти творческий процесс. Но вот путь к критической уязвимости обычно содержит ряд рутинных моментов, которые тратят ментальные силы исследователя делая процесс более длительным чем он мог бы быть.

Долгое время для борьбы с рутиной все прогрессивное IT сообщество применяло автоматизацию. Это был прямо Cвятой Грааль в поисках которого рождались целые отделы и даже профессии. Но у автоматизации была проблема: ее нужно было сначала создать. Кому-то нужно было заниматься только рутиной чтобы другим было хорошо. Впрочем люди желающие такой судьбы находились всегда, поэтому в целом все это катилось в какое-то светлое будущее и (почти)всех все устраивало.

Но тут в наш уютный мир ворвались LLM и как-то подозрительно быстро эволюционировали до состояния, когда это уже не просто отвечалка на вопросы, а волшебная коробочка, которая может автоматизировать какие-то действия по запросу на естественном языке. Да еще и править собственные ошибки в скриптах. Красота же! Ну и это даже почти всегда работает.

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

Другая проблема это — нехватка информации. Анализ мобильных приложений, на самом деле, требует экспертизы в большом количестве дисциплин и впихнуть это все в одну голову довольно тяжело. Ответом на эту проблему стали различные “хактриксы”, “читшиты”, “чеклисты” и прочие “топ 25 приемов как похекать мобильное приложение”. Да что там, я и сам грешен, но другого выхода действительно не было. Нам нужно было что-то, что позволит без высокой ментальной нагрузки получать полезную информацию и профессионально расти.

Потом стало понятно, что даже вот такой дистилированной информации уже так много, что сигнал сам становится шумом. Это нужно было привести в какой-то порядок. Так появились персональные базы знаний. Кто-то даже решил, что публиковать такие базы это неплохая идея. Не буду осуждать, но для меня польза от этого действия довольно сомнительна. Почему я так думаю станет понятно позже.

Прелесть такой базы в том, что туда можно складывать инфу разной степени проработанности, но чем более проработанная инфа туда попадает тем полезнее к этому потом возвращаться. Классический антипаттерн при ведении такой базы знаний: тянуть туда любую херабору и никак потом ее не трансформировать. Сохранять целые страницы или даже сайты, закидывать диаграммы без описания. Все это превращает такую базу в помойку. Вроде бы очевидно, но люди все равно тяготеют к такому способу ведения персональных баз знаний. А секрет прост: качественное ведение такой базы это дополнительная ментальная нагрузка. А мозг такое не любит! Прочитать статью, вынуть из нее полезное, оформить в виде документа, добавить туда дополнительную информацию, свои рассуждения, связать с другими документами. Все это р-а-б-о-т-а. Мало кто хочет это делать. Вот если бы была такая штука, которая по запросу может выдать дистилированную инфу на любую тему, а потом еще по серии уточняющих запросов добавить туда всякие уточнения, выводы, развилки… Oh wait…. 🙃

Да-да, это оно самое. Волшебная коробочка, которая ответит на любой вопрос. Не всегда точно, не всегда в тему, но настолько красиво, что закачаешься. Ей хочется верить.

И все же я выступаю ЗА то чтобы использовать LLM для обучения или ситуативного получения нужной информации. Это гораздо быстрее чем искать в поисковике или в книгах. А главное: в большинстве случаев вы получаете ровно то, что просите. Если умеете спрашивать конечно. Но об этом как-нибудь в другой раз.

Приведу еще один пример, который, как мне кажется, я придумал сам =)

Мы, программисты прошлого®, при изучении какой-то новой технологии, языка или фреймворка - любили часами сидеть в медитациях на тему “а как с этим принято работать тут?”. Все это сопровождалось чтением документации, форумов, а иногда и книг. При этом путь к результату все еще был довольно тернист. И твоя эффективность всегда определялась тем насколько хорошо и быстро ты умеешь добывать нужную информацию. Помнит еще кто-нибудь все эти “12 лайфхаков поиска в Google, о которых не знает 90% пользователей”? =) При всем при этом, твои текущие знания и опыт оказывали лишь косвенное влияние на результат. Когда-то больше, когда-то меньше. И вот теперь, у современных программистов есть возможность очень быстро создавать мостики между своими прошлыми знаниями и тем что они изучают прямо сейчас.

Допустим вы умеете хорошо верстать экраны под Android и начали осваивать iOS разработку (зачем оно вам надо это дело десятое). Программистам прошлого нужно было буквально с нуля сидеть и курить как все устроено в этом забавном и диковатом iOS мире. А теперь можно вкинуть в нейронку свой же сверстанный экран и сказать “Перепиши на iOS, используй лучшие практики верстки под эту платформу. Объясни все детали реализации”. Да, железная голова может ошибиться и сделать не так как надо. Но первый барьер вы уже прошли. И сделали это с потрясающей скоростью. А это дорогого стоит.

То же самое касается экстраполяции любого имеющегося у вас опыта. Понимаете как эффективно находить IPC баги в Android? Составляете запрос и говорите, что дескать “я люблю и умею находить вот такое на Android, хочу находить такие же баги на iOS, опиши разницу в подходах к поиску такого класса уязвимостей” и т.д.

Однако, важно понимать: все это работает только если у вас достаточно опыта чтобы оценить качество всех те баек, которые вам при этом расскажет LLM. Множитель, помним?

Так, автоматизация рутины есть, удобный поисковик по “знаниям” есть. Вроде бы можно и в бой… Отнюдь!

Не хватало только волшебного слова…

Или “секретного ингредиента”, как больше нравится. Поработав со всеми этими AI чудесами, я быстро понял, что на их фоне, даже студентка третьего курса смотрится более стабильно в своем настроении и предпочтениях. Нельзя так просто взять, вкинуть туда приложеньку и “оно там дальше само”. Поэтому нужно то, что называется harness. Я не возьмусь рассуждать о глубинах глубин, что можно так называть а что нельзя. Мне удобно об этом думать как о некой программной (это супер важно!) инфраструктуре вокруг LLM.

Почему я особенно выделяю понятие “программной”? Да потому что LLM не хватает детерминированности. И нужно что-то, что будет “держать в узде” всю эту историю. В противном случае, работать все будет очень плохо.

В задачи harness-а я также включаю предварительную обработку данных. Если что-то можно сделать детерменированно, то это нужно сделать детерминированно. Можно вкинуть APK-шку в LLM и попросить найти все экспортированные activity и оно даже в целом с этим справится. Но зачем греть атмосферу если это очень понятная и тысячи раз решенная задача? Точно также, не надо закидывать в LLM бинарные файлы и просить найти там уязвимости переполнения буфера. Да, вам может повезти и LLM каким-то чудом может найти какие-то признаки, но это сомнительный путь. Гораздо более правильно отдать в LLM хотя бы ассемблер, а то и декомпилированный код на C. Но об этом далее.

Причина делать именно так, хорошо понятна тем кто знаком с нюансами работы LLM. Для остальных поясню: LLM чаще видела уязвимый код на ассемблере чем в виде машинных кодов. В этом суть.

Задача такого harness это помочь LLM перейти в нужное состояние, чтобы активировались нужные веса. И тот, кто дочитал до этих строк уже начинает смекать насколько все непросто и как далеко мы ушли от точки “вкинул апк -> получил отчет -> отнес на ББ”. Именно так и обстоят дела в реальности. Это инструмент. Хороший инструмент. Но он не работает сам по себе.

AI assisted pentest

Те, кто прошел стадию вайб-пентестера и не отвалился по пути, приходят примерно к тем же выводам, которые я изложил выше. Но переход дается тяжело, поэтому мечты о кнопке “бабло” не покидают умы людей. Так появляется следующая идея: построение пайплайнов управляемых AI. Типа ок, давайте решим часть задач детерминированно, но пусть этот делает “цифровой двойник”, а я буду сидеть на лазурном берегу и пить чего-нибудь прохладительное. Помню в начале нулевых похожие байки рассказывали фриланс-биржи =) О том как можно не работать на дядю, жить где угодно, выполнять заказы и жить в кайф. Давненько я фрилансеров не видел. Все уехали жить в кайф наверное =)

Надо объяснять почему это не работает? Подумайте сами. А я дам небольшую подсказку:

Правильный путь, на мой взгляд это аугментация специалистов c помощью AI. Высвобождение их ментальных ресурсов для действительно сложных задач и прорывных исследований. Пайплайны, впрочем, никуда не деваются в этом случае. Просто смещается фокус. Можно воспринимать как это некую эволюцию сканеров безопасности. Когда задачей человека является триаж уязвимостей и дальнейшие шаги по работе с ними. В случае с AI, наша задача — получить более качественный результат чем способен дать сканер, что ускорит дальнейший триаж и реагирование.

Часть триажа, кстати, вполне можно отдать LLМ если предварительно заморочиться с моделью угроз. Потому что нейросетка неизбежно будет натягивать сову на глобус и фантазировать на тему “ах вот если бы эта activity была экспортирована, мы бы тогда тут и так и эдак и вот тебе эксплойт”. Подход LLM-as-a-Judge позволяет отстреливать подобные вещи и они просто не дойдут до человека.

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

• Поиск конкретного сценария в мобильном приложении
• Анализ потоков данных на “границах миров” (JVM->JNI, JMV->Network и т.п.)
• Восстановление алгоритмов и даже целых подсистем до состояния “можно запустить”

До эпохи AI это все требовало довольно серьезных усилий, хорошо настроенного рабочего окружения и опыта. Сейчас такую работу довольно эффективно способен выполнять “аугментированный мидл”. И это лютый win-win на самом деле. Потому что мидл теперь получает задачи, до которых его раньше бы и близко не допустили (потому что результат бестолковый был бы), а значит может быстрее набираться опыта и расти как профессионал. Компания (или заказчик) получает более качественный результат силами той же самой команды.

<… а тут должно быть много слов про окупаемость, про то что Microsoft отказывается от AI и вообще кожанные дешевле чем токены …>

Убедил! Куда нажимать? Кому платить? Мне такое надо!

Если у вас возникли похожие вопросы, то вернитесь и перечитайте всю статью еще раз. А потом еще. И так до полного просветления. Нет волшебной кнопки. Есть работа, которую надо делать. И ваша личная трансформация или трансформация вашей команды должна проходить путем некоторой естественной эволюции. Возьмите свои задачи и начните их решать держа в голове именно путь аугментации специалистов, а не их замены или аутсорсинга задач в волшебную коробочку. Придумайте подходы, которые будут работать для вас, прогоните их через кучу проектов, постепенно улучшайте то что есть. В этой области пока дикий запад. Никто вам не даст AI инструмент который будет всегда хорошо работать для ваших задач. Не верите? Ну тогда толпы инфоцыган из AI стартапов к вашим услугам =)

Впрочем это не значит, что нет готовых решений стоящих внимания. Они есть. Просто все они требуют адаптации. Да блин, посчитайте количество дизассемблеров. Неужели за столько лет нельзя было написать тот самый, который работает хорошо? =) Так вот с AI дела обстоят еще хуже. И вы уже знаете почему. Ну я надеюсь…

Немного практики для тех, кто достиг просветления

Сначала я не планировал включать в эту статью вообще ничего конкретного. Инфы о том как решать те или иные задачи c помощью LLM в интернетах уже вагон. Можно еще и у LLM спросить ;) Но я все же решил накидать немного тезисов, которые точно помогут любому встающему на путь использования AI в задачах анализа мобильных приложений.

• Специализация и гранулярность сильно улучшают результат. Агент “mobile security expert” — плохо, “android/iOS security expert” — хорошо
• Много активных MCP в сессии — плохо. Они забивают контекстное окно
• Много навыков — ок. Но нужно вдумчиво делать описания чтобы они не активировались хаотично
• Системный промт задает “личность” агента, правила (AGENTS.md) фиксируют нормы поведения в конкретном месте
• Промты на русском — ок, но лучше на английском. Если пишете на русском, то пишите проще.
• Работа с кодом через MCP декомпилятора/IDE всегда лучше чем grep. Потому что xref-ы это ключ к успеху.
• Делегирование задач саб-агентам не роскошь, а средство борьбы с деградацией контекстного окна
• Сила LLM именно в семантической, а не синтаксической работе с кодом

И самое главное — не стесняйтесь создавать что-то свое. В этой области пока что дикий запад, поэтому создавать “велосипеды” тут все еще легально. Удачи!

Ссылки

• Что такое Harness? Полный разбор на примере Claude Code, OpenAI и LangChain
• LLM-as-a-Judge
• Synthesizing Multi-Agent Harnesses for Vulnerability Discovery

Смотрите также