Бинарный способ решения проблемы это

Принятие решений на основе бинарных отношений

Использование в задачах принятия решений бинарных отношений основывается на следующих предположениях:

— каждая отдельная альтернатива не может быть оценена единственным числом в независимости от других альтернатив;

— может быть оценена произвольная пара альтернатив (оценка будет состоять в выборе той или иной альтернативы из пары, причём результат оценки в паре не зависит от других альтернатив множества).

Принятие решений на основе бинарных отношений состоит в последовательном представлении пар альтернатив и отбрасывании одной альтернативы из пары. На каком-то шаге останется только одна альтернатива. Она-то и будет считаться принятой.

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

Пример. Допустим, что мы выбираем самую красивую из трех девушек А, В и С. Численные критерии красоты вводить не адекватно, поэтому мы прибегнем к выбору на основе бинарных отношений. Из пары (А, В) мы отдаем предпочтение А; из пары (В, С) – предпочтение В; из пары (А,С) – предпочтение С.

1) Допустим, что первой нам представили пару (А,В). Мы предпочли А, а В «отсеяли». Далее мы сравниваем пару (А,С). Выбираем С. Таким образом, самой красивой признается С.

2) Допустим теперь, что первой нам представили пару (А,С). Мы предпочли С, а А «отсеяли». Далее мы сравниваем пару (В,С). Выбираем В. Таким образом, самой красивой признается В.

3) Допустим, что теперь первой нам представили пару (В,С). Мы предпочли В, а С «отсеяли». Далее мы сравниваем пару (А,В). Выбираем А. Таким образом, самой красивой признается А.

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

Если результат сравнения в паре зависит от наличия других альтернатив во множестве исходных альтернатив, то язык бинарных отношений для принятия решений применять нельзя. В этом случае используются так называемые функции выбора. Объем данного пособия не позволяет нам рассмотреть такой случай задач принятия решений. Описание такого подхода можно найти в[210].

6.7. Принятие решений в условиях определенности (детерминированный выбор), риска и неопределенности.

Ранее мы говорили, что такое деление задач принятия решений происходит на основании полноты и достоверности информации о последствиях выбора.

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

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

Если нам неизвестны все последствия выбора и/или вероятности их появления, то говорят о принятии решений в условиях неопределенности. Рациональных процедур выбора в таком случае практически не существует либо они достаточно трудоемки. В таких случаях в основном используется опыт и интуиция лиц, принимающих решения. В условиях неопределенности обычно действуют, исходя из следующих стратегий:

— избегают неопределенности (игнорируют источники неопределенности и делают ставку на лучший вариант);

— сводят неопределенность к определенности (представляют, что будущее будет таким же, как и прошлое, и принимают решения, исходя из прошлого опыта);

— сокращают неопределенность (собирают дополнительную информацию, снижающую неопределенность; в том числе, ведут переговоры с источниками неопределенности).

Источник

Процесс принятия бинарного решения

3.3.2 Процесс принятия бинарного решения.

В бинарном решении представлены две диаметрально противоположные альтернативы. Обычно это конкурирующие альтернативы, по своему характеру вынуждающие к выбору типа «да/нет», «или/или» (например, открывать еще одну контору или нет). Эти решения отличаются высокой степенью связанной с ними неопределенности. Крайний характер альтернатив заставляет тех, кто принимает решение, занимать полярно противоположные позиции, зачастую парализующие выбор.

Бинарные решения отражают неестественное положение вещей. Эта неестественность вызвана ограничениями, накладываемыми на выбор. Ограничения типа «да/нет», «делать/не делать» резко сужают возможности выбора. Поэтому очень немногие решения следует представлять в таком виде. Считается, что большинство бинарных ситуаций возникает в результате того, что не проведен необходимый анализ проблемы.

Причины возникновения бинарных ситуаций следующие:

1. Переадресовывание принятия решения вышестоящим руководителям.

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

2. Поверхностный анализ проблемы.

Задать вопросы о том, существуют ли различные пути достижения одних и тех же целей, во многих организациях не считается приемлемым типом поведения. В результате бинарное решение становится образом жизни.

3. Нехватка времени для выбора оптимальных решений.

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

4. Оправданность бинарных решений в некоторых случаях.

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

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

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

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

Почему данное решение необходимо?

Почему вы хотите пройти курс обучения?

Какие проблемы это поможет решить?

Какие навыки вы приобретете?

Эти вопросы обуславливают целесообразность рассмотрения причинно-следственных связей между данным решением и необходимостью в решении вообще.

Вместо вопроса: «Ехать ли мне в Чикаго, чтобы пройти данный курс обучения или нет?», поставим следующий: «каким путем мне лучше приобрести необходимые навыки, чтобы повысить квалификацию?».

Идея поехать на курсы в Чикаго остается приемлемой в более широком наборе альтернатив таких как: повышение квалификации на рабочем месте, посещение других курсов, овладение смежными профессиями, обучение в университете и т. д. В результате становится легче принять решение, а для сравнительной оценки альтернатив можно воспользоваться стандартными методами выбора.

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

Бинарные решения отличаются от других типов решений тем, что они накладывают жесткие ограничения на ситуацию принятия решения. Противопоставление, вызываемое самой природой альтернатив, может способствовать не объективности, а искажению данных. В любом случае руководитель или коллегиальный орган должен стремиться изменить тип решения с бинарного на стандартный. Если бинарная постановка действительно необходима, то выбор можно делать посредством шагов:

1. Постановка цели решения.

2. Выявление потенциальных результатов.

3. Установление критериев решения

4. Разделение критериев и сравнение альтернатив «да» и «нет».

5. Выявление и оценка риска.

3.3.3 Процесс принятия многовариантного решения.

Стандартный процесс принятия решения предполагает, что управляющий задаёт набор критериев, и затем сравнивает в соответствии с ними каждую данную альтернативу с каждой другой. Но если 300 альтернатив.

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

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

При принятии многовариантного решения, используется тот же метод оценки альтернатив по желательным характеристикам, что и в случае принятия стандартного решения. Наиболее важная характеристика получает наивысшую оценку (например. 10), а остальные критерии ранжируются относительно неё.

Сложность принятия многовариантного решения проявляется в первую очередь при использовании желательных критериев. В стандартной процедуре желательные характеристики используются для определения относительной ценности альтернатив. Но это неосуществимо в ситуации, когда альтернативы чередуются одна за другой, а их список очень велик. Чтобы преодолеть эту трудность, нужно использовать желательные критерии не в виде относительных, а в виде абсолютных измерителей ценности альтернатив. Это значит, что необходимо оценивать каждую альтернативу индивидуально и сопоставлять её не с другими альтернативами, а с неким идеальным образцом. Для этого суммируем оценки по всем критериям.

Источник

«И невозможное возможно»: превращаем черный ящик в белый с помощью бинарного анализа

По оценкам антивирусной компании McAfee, общемировой ущерб от киберпреступлений в 2017 году составил около $600 млрд, что эквивалентно 0.8% мирового ВВП. Мы живем в век информационных технологий, спецификой которого стала стремительная интеграция всемирной сети и интернет-технологий во все сферы деятельности человека. Сейчас киберпреступления уже не являются чем-то из ряда вон выходящим. Данные статистики демонстрируют рост киберпреступности в геометрической прогрессии.

Уязвимость приложений превратилась в серьезную проблему: по данным Министерства внутренней безопасности США, более 90% успешных кибератак реализуется с использованием различных брешей в приложениях. Самыми известными способами эксплуатации уязвимостей являются:

• внедрение SQL-кода,
• переполнение буфера,
• межсайтовый скриптинг,
• использование небезопасной конфигурации.

Анализ программного обеспечения (ПО) на наличие недекларированных возможностей (НДВ) и уязвимостей – основная технология, позволяющая обеспечить безопасность приложения.
Говоря о классических и устоявшихся технологиях анализа ПО на уязвимости и НДВ (на предмет соответствия требованиям информационной безопасности), можно выделить:

• статический анализ кода (Static Application Security Testing);
• динамический анализ кода (Dynamic Application Security Testing).

Есть еще IAST (интерактивный анализ), однако он по сути является динамическим (в процессе анализа дополнительный агент наблюдает, что происходит во время выполнения приложения). RASP (самозащита приложений Runtime), который также иногда упоминается в ряду средств анализа, является скорее средством защиты.

Динамический анализ (метод «Черного ящика») представляет собой проверку программы во время ее выполнения. У этого подхода можно выделить следующие преимущества.

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

Но есть и недостатки.

1. Неполное покрытие кода, в связи с чем существуют риски пропущенных уязвимостей. Например, динамическим анализом не получится найти уязвимости, связанные с использование слабой криптографии или закладки типа «временная бомба».
2. Необходимость запуска приложения, что в некоторых случаях может быть непросто. Для запуска приложения может потребоваться сложная конфигурация и настройка различных интеграций. Более того, чтобы результаты были максимально верными, необходимо воспроизвести «боевую среду», но полностью это реализовать, не навредив при этом ПО, сложно.

Статический анализ (метод «Белого ящика») представляет собой тип тестирования программы, при котором не происходит выполнение программы.

1. Полное покрытие кода, что приводит к поиску большего количества уязвимостей.
2. Отсутствие зависимости от среды, в которой будет производиться выполнение программы.
3. Возможность внедрения тестирования на начальных этапах написания кода модуля или программы при отсутствии исполняемых файлов. Это позволяет уже на старте разработки гибко интегрировать подобное решение в SDLC (Software Development Life Cycle ꟷ жизненный цикл разработки ПО).

Единственным недостатком метода является наличие ложных срабатываний: необходимость оценки, указывает ли анализатор на реальную ошибку, или есть вероятность, что это срабатывание ложное.

Как мы видим, у обоих методов анализа есть как преимущества, так и недостатки. Однако возможно ли каким-либо образом использовать плюсы этих методов, минимизируя при этом недостатки? Да, если применить бинарный анализ – поиск уязвимостей в исполняемых файлах методом статического анализа.

Бинарный анализ или технология анализа исполняемых файлов

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

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

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

Немного про термины

Мы говорим про анализ исполняемых файлов, в которых нет информации отладки (debug info). С debug info задача серьезно упрощается, но если есть debug info, то и исходный код, скорее всего, тоже есть, и задача становится неактуальной.

В этой статье мы называем анализ байткода Java также бинарным анализом, хотя это не совсем корректно. Делаем это для упрощения текста. Безусловно, задача анализа байткода JVM проще анализа бинарного кода C/C++ и Objective-C/Swift. Но общая схема анализа схожа в случае байткода и бинарного кода. Основные сложности, описанные в статье, относятся именно к анализу бинарного кода.

Декомпиляция – это процесс восстановления исходного кода из бинарного кода. Можно говорить про элементы обратной трансляции — дизассемблирование (получение ассемблерного кода из двоичного образа), трансляция ассемблера в трехадресный код или другое представление, восстановление конструкций уровня исходного кода.

Обфускация – преобразования, которые сохраняют функциональность исходного кода, но затрудняют декомпиляцию и понимание полученного бинарного образа. Деобфускация – обратное преобразование. Обфускация может применяться как на уровне исходного кода, так и на уровне бинарного кода.

Как смотреть результаты?

Начнем немного с конца, но вопрос о просмотре результатов бинарного анализа обычно задается в первую очередь.

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

В процессе декомпиляции, даже если мы декомпилируем байткод JVM, часть информации восстанавливается некорректно, поэтому сам анализ происходит на представлении, близком к бинарному коду. Соответственно, встает вопрос: как, находя уязвимости в бинарном коде, локализовать их в исходнике? Решение задачи для байткода JVM мы описывали в статье о поиске уязвимостей в байткоде Java. Решение для бинарного кода аналогичное, то есть вопрос технический.

Повторим важную оговорку — мы говорим про анализ бинарного кода без debug info. В случае присутствия debug info задача существенно упрощается.

Основной вопрос, который нам задают про отображение результатов – достаточно ли декомпилированного кода для того, чтобы понять и локализовать уязвимость?

Ниже приведем несколько мыслей на этот счет.

1. Если мы говорим про байткод JVM, то в общем случае ответ «да» – качество декомпиляции для байткода велико. Практически всегда можно разобраться, в чем уязвимость.
2. Что может помешать качественной локализации уязвимости, так это простая обфускация типа переименования имен классов и функций. Однако, на практике часто оказывается, что важнее понять уязвимость, чем определить, в каком она файле. Локализация нужна тогда, когда кто-то может исправить уязвимость, но в таком случае разработчик и по декомпилированному коду поймет, где уязвимость.
3. Когда мы говорим про анализ бинарного кода (например, C++), конечно, все гораздо сложнее. Не существует инструмента, который полностью восстанавливает случайный C++ код. Однако особенность нашего случая в том, что нам не нужно потом компилировать код: нам нужно качество, достаточное для понимания уязвимости.
4. Чаще всего можно добиться качества декомпиляции, достаточного для понимания найденной уязвимости. Для этого нужно решать немало сложных задач, но решить их можно (ниже кратко про это расскажем).
5. Для C/C++ еще сложнее с локализацией уязвимости — названия символов во многом утрачиваются в процессе компиляции, восстановить их нельзя.
6. Чуть лучше ситуация в Objective-C – там имена функций есть, и локализовать уязвимость проще.
7. Особняком стоят вопросы обфускации. Есть ряд сложных преобразований, которые могут усложнить декомпиляцию и отображение уязвимостей. На практике оказывается, что хороший декомпилятор справляется с большей частью запутывающих преобразований (помним, что нам нужно качество кода, достаточного для понимания уязвимости).

В качестве вывода — чаще всего получается показать уязвимость так, чтобы ее можно было понять и верифицировать.

Сложности и детали бинарного анализа

Тут уже не будем говорить про байткод: все интересное про него уже сказали выше. Самое интересное – это анализ настоящего бинарного кода. Здесь мы будем говорить про анализ C/C++, Objective-C и Swift как пример.

Существенные сложности возникают уже при дизассемблировании. Важнейший этап – разделение бинарного образа на подпрограммы. Далее выделить в подпрограммах инструкции ассемблера – дело техники. Подробно мы писали про это в статье для журнала «Вопросы кибербезопасности №1(14) – 2016», здесь опишем кратко.

Как пример, будем говорить про архитектуру x86. В ней инструкции не обладают фиксированной длиной. В бинарных образах отсутствует четкое разделение на секции кода и данных: таблицы импорта, таблицы виртуальных функций могут находиться в секции кода, таблицы переходов могут находиться в промежутках между базовыми блоками функций в секции кода. Соответственно, нужно уметь отделить код от данных и понять, где начинаются и где заканчиваются подпрограммы.

Наиболее распространены два метода решения задачи определения стартовых адресов подпрограмм. В первом методе адреса подпрограмм определяются по стандартному прологу (для архитектуры x86 – это push ebp; mov ebp, esp). Во втором методе происходит рекурсивный обход секции кода от точки входа с распознаванием инструкций вызова подпрограмм. Обход осуществляется за счет распознавания инструкций перехода. Также применяют комбинации описанных методов, когда рекурсивный обход запускается из найденных по прологу стартовых адресов.

На практике оказывается, что такие подходы дают достаточно низкий процент распознанного кода, так как стандартный пролог есть далеко не у всех функций, и существуют косвенные вызовы и переходы.

Базовые алгоритмы можно улучшить следующими эвристиками.

1. На большой тестовой базе образов найти более точный список прологов (новые прологи или вариации стандартных).
2. Можно автоматически находить таблицы виртуальных функций, и из них забирать стартовые адреса подпрограмм.
3. Стартовые адреса подпрограмм и некоторые другие конструкции можно находить, исходя из участков бинарного кода, связанного с механизмом обработки исключений.
4. Верифицировать стартовые адреса можно с помощью поиска этих адресов в образе и с помощью распознавания инструкций вызова.
5. Для поиска границ можно делать рекурсивный обход подпрограммы с распознаванием инструкций от стартового адреса. Есть сложность с косвенными переходами и no-return функциями. Помочь может анализ таблицы импортов и рапознавание switch-конструкций.

Еще одна важная штука, которую нужно делать при обратной трансляции, чтобы потом нормально искать уязвимость, – это распознавать стандартные функции в бинарном образе. Стандартные функции могут быть статически линкованы в образ, а могут быть даже заинлайнены. Основной алгоритм распознавания – это поиск по сигнатурам с вариациями, для решения можно предложить адаптированный алгоритм Ахо-Корасик. Чтобы собрать сигнатуры, нужно заранее проанализировать образы библиотек, собранные с разными условиями, и выделить их них неизменяющиеся байты.

Что дальше

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

Дальше происходит много всего интересного. Кратко скажем об основных задачах. Подробно рассказывать не будем: в деталях кроется либо ноу-хау, про которое мы тут явным образом писать не можем, либо не очень интересные технические и инженерные решения.

1. Преобразование ассемблерного кода в промежуточное представление, на котором можно проводить анализ. Можно использовать различные байткоды. Для C-языков хорошим выбором кажется LLVM. LLVM активно поддерживается и разрабатывается сообществом, инфраструктура, в том числе полезная для статического анализа, на данный момент внушительно развита. На этом этапе есть огромное количество деталей, на которые нужно обратить внимание. Например, нужно детектировать, какие переменные адресуются в стеке, чтобы не множить сущности в полученном представлении. Нужно настроить оптимальное отображение наборов инструкций ассемблера в инструкции байткода.
2. Восстановление конструкций высокого уровня (например, циклов, ветвлений). Чем точнее получится восстановить исходные конструкции из ассемблерного кода, тем лучше будет качество анализа. Восстановление таких конструкций происходит с помощью применения элементов теории графов на CFG (графе потока управления) и некоторых других графических представлений программы.
3. Проведение алгоритмов статического анализа. Тут есть подробности. В целом, не очень важно, получили мы внутреннее представление из исходника или из бинарника — мы все также должны построить CFG, применить алгоритмы анализа потока данных и другие алгоритмы, свойственные статике. Есть некоторые особенности при анализе представления, полученного из бинарника, но они скорее технические.

Выводы

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

Статья подготовлена в соавторстве с Антоном Прокофьевым, аналитиком Solar appScreener

Источник