книги хакеры / журнал хакер / ха-292_Optimized

ПАВЕЛ ЖОВНЕР

ОПРОБЛЕМАХ РАЗРАБОТКИ, НОВОМ МАРКЕТПЛЕЙСЕ

ИСЛЕДУЮЩЕМ FLIPPER

Не забудь подписаться на телеграм-канал Дани Шеповалова «Вечерний Даня», чтобы не пропускать новые авторские материалы, и заглядывай на danya.ru.

—Все смотрят на тебя и думают: надо, как Паша, нарисовать какой-нибудь девайс на листе бумаги... Хотя подожди, девайсы же не на бумаге, наверное, рисуются. Какой вы софт используете?

—Мы пользуемся очень много чем. Для трассировки электроники это в

основном Altium Designer. Плюс Altium 365 — это как GitHub, только для «Аль-

тиума» — там есть коммиты, версионность, релизы. По части софта — прошивка написана на C. Внутри команды каждый использует свою среду разработки. У нас своя система для сборки прошивки. Для планирования интерфейсов мы используем Miro, мы писали в блоге об этом. Там же можно найти про разработку интерфейсов и глянуть красивые майндмапы из пиксельных экранов. Мобильные приложения у нас нативные: для Android — на Kotlin, для iOS — на Swift. Промдизайн в CATIA делаем. А так очень много разного софта используем...

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

—Изначально мы взяли очень свежий чип STM32WB55, который не был

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

—Чипов всегда хватало?

—Нет, конечно. Когда начался весь этот коллапс с кремнием, у нас тупо

не было чипов, чтобы что-то производить. Мы просто сидели какое-то время

иничего не делали. А потом еще оказалось, что чипов нет теперь для экранов

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

—А что с адовыми продажами?

—В продажах самое стремное — это сама доставка, особенно доставка в...

да вообще доставка — это жесть. То у нас арестовали контейнер, то уничтожили груз, то «Флипперы» не пускали куда-то. Самый дикий ад — все, что связано с доставкой в Россию. СДЭК этот кошмарный, потом арест груза, какие-то постоянные проблемы. Мы по триста раз собирали адреса для доставки. Люди уже переехали, начался весь этот геополитический треш. В общем, доставка — это самое ужасное, с чем мы столкнулись. Очень тяжело было жить с ощущением, что есть еще тысячи людей, которым не прислали их купленные устройства. Но сейчас мы доставили всё, в том числе и в России.

—Допустим, ты переубедил не всех. Кто-то по-прежнему намерен спроектировать собственный девайс и произвести его в Китае. Есть советы и лайфхаки?

—Тут в двух словах не ответить. Это все равно что отвечать на вопрос «А

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

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

—Типа человек поселяется в Шэньчжэне, ищет поставщиков и подрядчиков, торгуется с ними, потом трагедии с бракованными партиями и всякое такое?

—У нас не совсем такой случай, у нас уже до этого был опыт производства,

и люди из топ-менеджмента находятся в Китае. Они знают язык и погружены

вкитайскую культуру. Раньше ведь мы занимались производством устройств как контрактной разработкой для других компаний, то есть была пачка наработанных контактов и подрядчики на примете. Есть литьевые фабрики, которые льют пластик, есть производители электроники, есть несколько фабрик, на которых мы тестируем что-то, печатаем тестовые «грязные» писибихи

(PCB — printed circuit board, печатная схема).

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

Наверное, проще всего подмазаться к кому-то, кто уже наладил процесс. Поработать какое-то время совместно, набрать контакты. На самом деле рынок в Китае очень непрозрачный. Например, как вкатиться в разработку 1С, более-менее понятно, а чтобы вкатиться в производство электроники

вКитае, никаких рецептов нет. А ведь помимо завода есть еще поставщики компонентов. Это тоже отдельная история, с ними надо отдельно выстраивать отношения...

—А что за контрактная разработка для других компаний?

—Можно зайти на сайт компании Design Heroes и посмотреть, какие проекты

были до «Флиппера». Например, парковочные датчики для компании Nwave. Мобильные базовые станции для Fairwaves. Разные устройства делали. Какие-то из них были на «Кикстартере», например проект Monument. И я с ребятами тоже иногда работал, прошивку делал для каких-то демок. Еще есть компания Objectlab, она была до Design Heroes. Там всё: от датчиков до вендинговых аппаратов. По Москве стоят такие тележки, продающие мороженое, — мы участвовали в их дизайне. Но электронику тогда почти не делали. В основном промдизайн, корпуса, литье и прочее.

—На «Флипперы» у вас по-прежнему дикий спрос? Или стало спокойнее?

—Сейчас мы производим около 40 тысяч устройств в месяц. Продаем при-

мерно столько же, даже чуть-чуть меньше. То есть спрос и предложение примерно выровнялись. Хотим продавать чуть больше, может быть, нарастить еще производство, может быть, оставить как есть. TechCrunch на днях писал, что мы собираемся в этом году продать на 80 миллионов долларов. Надеюсь, что получится 100, но хотя бы 80.

—Хотя бы 80 миллионов долларов, ладно... А откуда в основном покупатели идут?

—Сейчас очень много дает всякая «органика». В «Тиктоке» у нас око-

ло 800 миллионов просмотров. Да и просто сарафанка по интернету. Мы только сейчас потихоньку начинаем тратиться на маркетинг. До этого все шло само по себе — органически. Да и мы все время были в ситуации, когда спрос превышает предложение. Все, что мы произвели, сразу продалось, и дальше продавать уже нечего, поэтому не было смысла тратиться на рекламу. Сейчас мы начали наращивать объемы и постепенно начинаем строить планы продаж.

—С эквайрингом все окей? Вроде вам в PayPal были должны?

—Совсем недавно в PayPal вернули последние 300 тысяч долларов и нав-

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

—А чем тогда порекомендуешь пользоваться, если не помойкой?

—Тут зависит от специфики бизнеса. Я вообще не тот человек, которого нуж-

но слушать в этом плане, потому что у нас специфичный продукт: в Stripe нас, к примеру, просто банят по своим внутренним соображениям. Если вы продаете алкоголь, парфюм, автомобили, страховки, там будут совершенно разные эквайринги. Тут компетентно что-то сказать очень сложно. Знаю историю, как в PayPal забанили программу для macOS — Little Snitch — за то, что у них в письме с серийным номером для активации была последовательность букв, в которой PayPal разглядел некое террористическое слово. Вот такой бывает абсурд.

—Какие самые необычные применения Flipper Zero, о которых вы узнали уже от пользователей?

—Я однажды увидел, как пьезодинамиком открывают какой-то ультраз-

вуковой замок. Но наверное, это можно сделать с помощью динамика телефона. А еще меня удивило, что «Флиппер» считывает чипы домашних животных, — мы это совсем не задумывали. Мы даже не знали, что так можно: там другая частота — не 125, а 134 килогерца. Но наша антенна все равно позволяет такой резонанс делать, и считывание работает, хоть и не очень хорошо — приходится целиться.

А еще меня удивила функция инфракрасного приемника для компьютера. Это когда ты подключаешь «Флиппер» к компьютеру по USB, ставишь девайс инфракрасным окошком в свою сторону и можешь управлять компьютером с пульта телевизора. «Флиппер» обнаруживается как HID-устройство, принимает сигналы и управляет всем, чем захочешь. Можно нажать Play и включить музыку или кнопкой Next слайды переключать, на остальные кнопки тоже что-то назначить. Я даже удивился, почему я до этого не додумался.

—Сколько примерно человек в мире что-то пилят под «Флиппер»?

—Мне очень сложно сказать, сколько реально людей. У нас в Discord что-то

в районе 50–100 тысяч человек, и всегда что-то активно обсуждают. Людей, которые реально программируют что-то полезное, а не просто Hello World, наверное, в районе сотни, может быть — две сотни из нашего полумиллионного комьюнити. Для Flipper написано около 60 приложений. Кстати, скоро мы откроем маркетплейс. Через мобильное приложение Flipper можно будет ставить программы, написанные сторонними разработчиками. И любой желающий сможет отправить нам свой FAP — Flipper Application Package.

—Как выглядит команда Flipper Zero?

—Команда у нас примерно из 50 человек. Мы сейчас хантим людей, может

быть, к концу года станет раза в два больше. У нас уникальный коллектив и по составу, и по демографическому признаку, и по этническому. Мы очень ЛГБТ-френдли. Вообще, я считаю, в СНГ нет команд, которые делают что-то подобное тому, что делаем мы. Ну, может быть, Яндекс.

Мы всё разрабатываем внутри, ин-хаус, пошагово. Сначала — промышленный дизайн, то есть придумываем, как будут выглядеть формы. Затем конструктив — то есть как устройство собирается, как шурупы вкручиваются, где ребра жесткости, как детали будут из пресс-формы вытаскиваться и так далее. Дальше разрабатываем электронику: сами платы трассируем, строим тестировочные линии вокруг этого. Это важный этап, потому что наладить производственную линию — это не просто отрассировать плату в «Альтиуме».

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

Flipper — для iOS и для Android.

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

—Flipper Zero изначально планировался как младшая модель, в дополнение к Flipper One с полноценным процессором, Linux и Wi-Fi. К этим планам возвращаетесь хотя бы в мыслях? Я читал, что ты хотел отказаться от повторения истории с разработкой, но, может, это морально была какая-то низшая точка, которая теперь пройдена?

—Мы сейчас работаем над Flipper One, но пока не совсем понимаем, каким

он должен быть. Мы хотим вообще жирный комбайн с FPGA и SDR, в котором все протоколы можно будет определить программно, но пока есть сомнения, будут ли покупать устройство за 300–500 долларов.

Так что проект в активном R&D, но пока нет понимания по важным частям. Например, не выбрали модуль Wi-Fi, потому что все существующие чипы, пригодные для атак, уже устарели. Возможно, придется спонсировать разработку своего драйвера. В общем, увидим!

ФАЗЗИМ JS-ДВИЖКИ ПРИ ПОМОЩИ FUZZILLI

Раньше фаззить движки JavaScript (те самые, что позволяют делать в браузере падающий снег или разрабатывать бэкенды на Node.js) было сложно. Мутации JS-кода приводили к синтаксическим ошибкам, что серьезно замедляло работу. Семплы отбрасывались движком, и приходилось генерировать новые и новые. На помощь пришли фаззеры на основе грамматики, но их применение тоже не назовешь легким.

В 2019 году исследователь безопасности saelo публично открыл свою разработку — фаззер Fuzzilli. Идея была в том, чтобы вместо JavaScript генерировать подобие байт-кода, которое будет проще подвергать мутациям. Собственно, хоть в названии и обыгран сорт пасты, происходит оно от FuzzIL — Fuzzing Intermediate Language, промежуточный язык для фаззинга.

Fuzzilli

СТЕНД

Для стенда нам понадобится виртуальная машина на Linux. Можно скачать готовую виртуалку с сайта osboxes.org, выбрав дистрибутив по вкусу. Я в статье буду использовать Ubuntu 22.

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

Из инструментов понадобится Git, язык программирования Swift (не путать с певицей), а также весь тулчейн, нужный для сборки JS-движка. Но об этом поговорим чуть позже.

Пока же запускай виртуалку и вводи свой пароль.

Password=osboxes.org

echo $Password | sudo -S apt update

sudo apt upgrade -y

Update и upgrade

Фаззинг — это такой метод тестирования, при котором в ПО вводят неправильные, неожиданные или рандомизированные данные, а фаззер отслеживает падения, срабатывания встроенных утверждений (assert) и утечки памяти.

Важный параметр в фаззинге — это покрытие кода. По сути это процент задействованного кода программы при выполнении определенного набора тестов.

Фаззинг можно разделить на «тупой», или неструктурированный, и «умный», или структурированный. Когда фаззер ничего не знает о структуре входных данных программы, то это тупой фаззинг. Если знает — умный.

Создание входных данных делится на генерацию и мутацию. Генерация — это когда данные создают полностью с нуля, мутация — когда изменяют име-

Тестирование методом черного ящика означает полное отсутствие данных о структуре программы, в таком случае фаззер создает рандомизированные входные данные.

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

Еще «ящик» может быть серым. В таком случае мы применяем инструментацию кода вместо анализа программы. Это позволяет получать информацию о программе без анализа. То есть что-то среднее между белым и черным ящиком. Получается, можно быстро генерировать входные данные, но при этом узнать информацию о покрытии кода.

Фаззер Fuzzilli относится как раз к третьему виду. По типу генерации входных данных он совмещает в себе генерацию и мутацию. По типу фаззинга он скорее «умный».

JavaScript-движки

Основные части движка JavaScript — это парсер, интерпретатор и компилятор.

JS-пайплайн

Все начинается с парсинга исходного кода на JavaScript. Строится абстрактное синтаксическое дерево (AST). На его основе создается байт-код. Затем интерпретатор выполняет байт-код.

Во время выполнения записывается разная информация — pro ling data. В дальнейшем она используется при компиляции байт-кода в машинный. Этим занимается компилятор.

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

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

Подробнее о работе движков JS — в презентации

«JavaScript engines: The Good Parts» (PDF, WebArchive).

ПОДГОТОВКА ФАЗЗЕРА

Fuzzilli поставляется в виде исходного кода, написанного на языке Swift.

Для скачивания исходников понадобится Git, для сборки Fuzzilli — пакеты GCC, Binutils и, конечно, исходники фаззера. Ставим зависимости и клонируем репозиторий Fuzzilli.

Password=osboxes.org

echo $Password | sudo -S apt update

sudo apt install git binutils gcc -y

git clone https://github.com/googleprojectzero/fuzzilli

Клонируем репозиторий

Теперь переходим на сайт Swift в раздел Download и ищем релиз для своего дистрибутива. Для Ubuntu 22 качаем релиз Ubuntu 22.04 x86_64.

Swift

Распаковываем архив и копируем папку usr, чтобы установить Swift. После этого убеждаемся, что все корректно настроено.

Вот мини-скрипт для ленивых. Если читаешь эту статью спустя много лет, поменяй переменные SwiftUrl на соответствующий URL со страницы Swift.

#Установка Swift Password=osboxes.org

SwiftUrl=https://download.swift.org/swift-5.8.1-release/ubuntu2204/ swift-5.8.1-RELEASE/swift-5.8.1-RELEASE-ubuntu22.04.tar.gz SwiftTar=$(echo $SwiftUrl | sed 's:.*/::') SwiftFolder=${SwiftTar%.tar.gz}

#Переходим домой

cd $HOME

# Качаем архив wget $SwiftUrl

# Извлекаем

tar -xzf $SwiftTar

# Устанавливаем

echo $Password | sudo -S cp -r $SwiftFolder/usr /

# Удаляем архив rm $SwiftTar

# Удаляем папку

rm -rf $SwiftFolder

# Тестовый запуск swift --version

Установка Swift

Теперь мы готовы к сборке фаззера. Переходим в папку Fuzzilli и запускаем сборку.

cd fuzzilli && swift build -c release

Собираем Fuzzilli

Фаззер готов. Можно почитать раздел помощи, если есть желание.

swift run -c release FuzzilliCli --help

Переходим к подготовке JS-движков. На главной странице репозитория инструкция гласит: «Скачайте исходный код движка. Скомпилируйте его, как описано в инструкции к нему в папке Targets». Для каждого движка там есть отдельная папка, в которой указано, как собрать движок для фаззинга.

Продолжение статьи →

СБОРКА И ФАЗЗИНГ V8

Теория

Начнем с движка браузера Google Chrome, он называется V8. Это движок JavaScript и WebAssembly, разработанный в Google, распространяется с открытым исходным кодом, написан на C++. Используется в Chrome, Node.js и множестве дериватив Chrome.

Разработали этот движок в датском городе Орхус, а ведущего разработчика зовут Ларс Бак. Бак занимался разработкой языка Self, а также HotSpot — виртуальной машины Java. Поэтому многое из наработок Self перекочевало в V8. Например, та же JIT-компиляция или «карты» объектов

(maps).

Подробнее — в научной работе, которая легла в основу Self: «An Ef cient Implementation of SELF, a Dynamically-Typed Object-Oriented Language Based on Prototypes» (PDF, WebArchive).

Движок состоит из интерпретатора Ignition, неоптимизирующего компилятора Sparkplug и оптимизирующего компилятора TurboFan.

Пайплайн V8

Сборка

В папке Targets/V8 нам предлагают следовать инструкциям с сайта. Но я не буду утомлять ими, а скомпилирую все в один мини-скрипт.

#Подготовка и сборка V8 Password=osboxes.org

echo $Password | sudo -S apt update

#Переходим домой

cd $HOME

# Качаем репозиторий depot_tools

git clone https://chromium.googlesource.com/chromium/tools/depot_ tools.git

# Добавляем в PATH

echo "PATH=$HOME/depot_tools:$PATH" >> ~/.bashrc source ~/.bashrc

# Качаем исходники gclient

fetch v8 cd v8/

gclient sync

#Ставим зависимости (update — так как скрипт попросит ввести пароль) echo $Password | sudo -S apt update

./build/install-build-deps.sh

#Билдим при помощи скрипта из папки фаззера

$HOME/fuzzilli/Targets/V8/fuzzbuild.sh

Сборка V8

Скрипт переходит в домашний каталог пользователя, затем ставит depot_tools (для скачивания и сборки V8), качает и компилирует исходный код движка V8. Сборка займет какое-то время, зависит от ресурсов машины. Можешь пока сделать небольшую разминку.

Фаззинг

Приступаем наконец к самому фаззингу. Для этого нужно выполнить следующую команду:

#Запускаем Fuzzilli

#Отключаем дампы

echo $Password | sudo -S sysctl -w 'kernel.core_pattern=|/bin/false'

#Переходим в папку Fuzzilli cd $HOME/fuzzilli

#Запускаем

swift run -c release FuzzilliCli --profile=v8 --resume --storagePath= $HOME/fuzzilli-storage-v8 $HOME/v8/out/fuzzbuild/d8

Начинаем фаззить V8

Основные настройки — это профиль движка (--profile=v8), возврат к предыдущей сессии фаззинга (--resume) и хранилище, куда фаззер будет сохранять свои данные (--storagePath). Там будут храниться найденные краши, корпус семплов и прочая информация.

Периодически он будет выводить статистику фаззинга. В основном интересны количество найденных крашей (Crashes Found) и процент покрытия кода (Coverage).

Статус фаззинга

СБОРКА И ФАЗЗИНГ SPIDERMONKEY

Теория

Переходим к JavaScript-двиглу Firefox.

SpiderMonkey — это потомок первого в мире движка JavaScript. Его релиз состоялся аж в 1995 году! Изначально он разработан Бренданом Айком в компании Netscape. Первые версии были написаны на C, но в дальнейшем код переписали на C++.

Вот структура SpiderMonkey. Парсер производит байт-код. Интерпретатор JavaScript этот байт-код выполняет. Baseline-интерпретатор занимается созданием инлайнового кеша. Baseline-компилятор создает неоптимизированный машинный код. WarpMonkey — оптимизированный машинный код.

Пайплайн SpiderMonkey

Сборка

В инструкции пишут, что нужно просто клонировать репозиторий Gecko и запустить fuzzbuild.

Но на самом деле надо применить патчи из папки Patches. И только после этого билдить. К тому же запускать fuzzbuild нужно не из js/src, а из рута

gecko-dev.

Что ж, приступаем. Нам понадобится curl и компилятор Rust для сборки движка.

#Подготовка и сборка SpiderMonkey Password=osboxes.org

cd $HOME

#Ставим curl

echo $Password | sudo -S apt install curl -y

# Ставим Rust

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs -o install. sh

sh ./install.sh -y

source "$HOME/.cargo/env"

# Клонируем

git clone https://github.com/mozilla/gecko-dev.git

# Заходим

cd gecko-dev/js/src

# Патчим

git apply $HOME/fuzzilli/Targets/Spidermonkey/Patches/* cd $HOME/gecko-dev

# Собираем $HOME/fuzzilli/Targets/Spidermonkey/fuzzbuild.sh

Rust установлен

Билдим

Фаззинг

После того как движок собран, можем запустить фаззинг из папки fuzzilli. Команды запуска и параметры фаззера те же, кроме профиля и исполняемого файла.

#Запуск Fuzzilli

#Отключаем дампы

echo $Password | sudo -S sysctl -w 'kernel.core_pattern=|/bin/false'

#Переходим в папку Fuzzilli cd $HOME/fuzzilli

#Запускаем

swift run -c release FuzzilliCli --profile=spidermonkey --resume --storagePath=$HOME/fuzzilli-storage-sm $HOME/gecko-dev/obj- fuzzbuild/dist/bin/js

Фаззим SpiderMonkey

СБОРКА И ФАЗЗИНГ JAVASCRIPTCORE

Ну и наконец, JavaScriptCore — JavaScript-движок браузера Safari.

Теория

Вообще, можно сказать, что это потомок JavaScript-движка KJS из браузера Konqueror, входящего в KDE. Проект WebKit стартовал в 2001 году как форк от KHTML и KJS.

Пайплайн у него самый сложный, четырехуровневый.

•LLint или Low Level Interpreter — это просто интерпретатор байт-кода, сгенерированного из исходного кода JavaScript.

•Далее идет немного оптимизирующий компилятор Baseline. Оба они собирают информацию, необходимую для дальнейших оптимизаций машинного кода.

•Следующий компонент — DFG JIT (Data Flow Graph Just In Time). Он отве-

чает за повышение оптимизации машинного кода.

•Ну и FTL JIT (Faster Than Light), генерирует наиболее оптимизированный машинный код.

Пайплайн KJS

Сборка

Смотрим, что пишут в Targets по поводу JavaScriptCore.

Нужно клонировать код из репозитория WebKit, накатить патчи и запустить fuzzbuild.sh. Для сборки потребуется установить Clang и зависимости. В папке Tools есть готовые скрипты для этого. Качаем, ставим все необходимое, патчим, билдим. Как обычно, вот скрипт:

#Подготовка и сборка JavaScriptCore Password=osboxes.org

cd $HOME

#Качаем исходный код

git clone https://github.com/WebKit/WebKit.git

# Ставим зависимости cd WebKit

echo $Password | sudo -S apt update sudo apt install clang -y Tools/gtk/install-dependencies

# Патчим

git apply ../fuzzilli/Targets/JavaScriptCore/Patches/*

# Билдим $HOME/fuzzilli/Targets/JavaScriptCore/fuzzbuild.sh

Сборка JSC

Фаззинг

Когда сборка движка будет закончена, можем запускать фаззинг. Поехали!

#Запуск Fuzzilli

#Отключаем дампы

echo $Password | sudo -S sysctl -w 'kernel.core_pattern=|/bin/false'

#Переходим в папку Fuzzilli cd $HOME/fuzzilli

#Запускаем

swift run -c release FuzzilliCli --profile=jsc --resume --storagePath =$HOME/fuzzilli-storage-jsc $HOME/WebKit/FuzzBuild/Debug/bin/jsc

Фаззинг JavaScriptCore

Все работает. Осталось дождаться интересных крашей!

ВЫВОДЫ

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

впапку Targets):

•JerryScript;

•QuickJS;

•Qt QJSEngine;

•XS;

•duktape.

Их можешь попробовать пофаззить самостоятельно.

•Coverage Guided Fuzzing for JavaScript Engines Thesis (PDF)

•Видео с O ensiveCon19

•Слайды O ensiveCon19 (PDF)

•How Fuzzilli Works

•Репозиторий Fuzzilli на GitHub

ИЩЕМ СТРУКТУРЫ ЯЗЫКОВ ВЫСОКОГО УРОВНЯ

В ПРОГРАММАХ ДЛЯ X86-64

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

Перед тобой уже во второй раз обновленная версия цикла «Фундаментальные основы хакерства». В 2018 году Юрий Язев изменил текст Криса Касперски для соответствия новым версиям Windows и Visual Studio, а теперь внес правки с учетом отладки программ для 64-разрядной архитектуры.

Читай также улучшенные версии прошлых статей цикла:

1.Учимся анализировать программы для x86-64 с нуля

2.Используем отладчик для анализа 64-разрядных программ в Windows

3.Находим реальные адреса инструкций в исполняемых файлах x86-64

4.Осваиваем разные способы поиска защит в программах для x86-64

5.Мастер-класс по анализу исполняемых файлов в IDA Pro

Все новые версии статей доступны без платной подписки.

Цикл «Фундаментальные основы хакерства» со всеми обновлениями опубликован в виде книги, купить ее по выгодной цене ты можешь на сайте издательства «Солон-пресс».

Современные дизассемблеры достаточно интеллектуальны и львиную долю распознавания ключевых структур берут на себя. В частности, IDA Pro успешно справляется с идентификацией стандартных библиотечных функций, локальных переменных, адресуемых через регистр RSP, case-ветвлений и прочего. Однако порой IDA ошибается, вводя исследователя в заблуждение, к тому же высокая стоимость IDA Pro не всегда оправдывает применение. Например, студентам, изучающим ассемблер (а лучшее средство изучения ассемблера — дизассемблирование чужих программ), «Ида» едва ли по карману.

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

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

Материалы к статье на GitHub

ИДЕНТИФИКАЦИЯ ФУНКЦИЙ

Функция (также называемая процедурой или подпрограммой) — основная структурная единица процедурных и объектно ориентированных языков, поэтому дизассемблирование кода обычно начинается с отождествления функций и идентификации передаваемых им аргументов. Строго говоря, термин «функция» присутствует не во всех языках, но даже там, где он присутствует, его определение варьируется от языка к языку.

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

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

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

Инструкция CALL закидывает адрес следующей за ней инструкции на вершину стека, а RET стягивает и передает на него управление. Тот адрес, на который указывает инструкция CALL, и есть адрес начала функции. А замыкает функцию инструкция RET (но внимание: не всякий RET обозначает конец функции!).

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

НЕПОСРЕДСТВЕННЫЙ ВЫЗОВ ФУНКЦИИ

Просматривая дизассемблерный код, находим все инструкции CALL — содержимое их операнда и будет искомым адресом начала функции. Адрес невиртуальных функций, вызываемых по имени, вычисляется еще на стадии компиляции, и операнд инструкции CALL в таких случаях представляет собой непосредственное значение. Благодаря этому адрес начала функции выявляется простым синтаксическим анализом: ищем контекстным поиском все подстроки CALL и запоминаем (записываем) непосредственные операнды. Рассмотрим следующий пример (Listing1):

void func(); int main()

{

int a; func(); a=0x666; func();

}

void func()

{

int a; a++;

}

Чтобы откомпилировать пример для 64-битной платформы, надо открыть соответствующую консоль — x64 Native Tools Command Prompt for VS — и уже в ней выполнить команду

cl.exe main.cpp /EHcs

Результат компиляции в IDA Pro должен выглядеть приблизительно так:

Вот мы выловили инструкцию call с непосредственным операндом, представляющим собой адрес начала функции. Точнее, ее смещение в кодовом сегменте (в данном случае в сегменте .text). Теперь можно перейти к строке . text:0000000140001000 и, дав функции собственное имя, заменить операнд инструкции call конструкцией «call Имямоейфункции».

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

Судя по адресам, «наша функция» в листинге расположена выше функции main:

На эту строку ссылаются операнды нескольких инструкций call.Следовательно, это адрес начала «нашей функции».

Как видишь, все очень просто.

ВЫЗОВ ФУНКЦИИ ПО УКАЗАТЕЛЮ

Однако задача заметно усложняется, если программист (или компилятор) использует косвенные вызовы функций, передавая их адрес в регистре и динамически вычисляя его (адрес, а не регистр!) на стадии выполнения программы. Именно так, в частности, реализована работа с виртуальными функциями, однако в любом случае компилятор должен каким-то образом сохранить адрес функции в коде. Значит, его можно найти и вычислить! Еще проще загрузить исследуемое приложение в отладчик, установить на «подследственную» инструкцию CALL точку останова и, дождавшись всплытия отладчика, посмотреть, по какому адресу она передаст управление. Рассмотрим следующий пример (Listing2):

int func()

{

return 0;

}

int main()

{

int (*a)(); a = func; a();

}

Результат его компиляции должен в общем случае выглядеть так (функция main):

Вот инструкция CALL, осуществляющая косвенный вызов функции по адресу, содержащемуся в ячейке [rsp+38h+var_18]. Как узнать, что же там содержится? Поднимем глазки строчкой выше и обнаружим: lea rax, loc_140001000. Ага! Значит, управление передается по смещению loc_140001000, где располагается адрес начала функции! Теперь осталось только дать функции осмысленное имя.

Продолжение статьи →

ИЩЕМ СТРУКТУРЫ ЯЗЫКОВ ВЫСОКОГО УРОВНЯ В ПРОГРАММАХ ДЛЯ X86-64

ВЫЗОВ ФУНКЦИИ ПО УКАЗАТЕЛЮ С КОМПЛЕКСНЫМ ВЫЧИСЛЕНИЕМ ЦЕЛЕВОГО АДРЕСА

В некоторых достаточно немногочисленных программах встречается и косвенный вызов функции с комплексным вычислением ее адреса. Рассмотрим следующий пример (Listing3):

int func_1()

{

return 0;

}

int func_2()

{

return 0;

}

int func_3()

{

return 0;

}

int main()

{

int x;

int a[3]={(int) func_1,(int) func_2, (int) func_3}; int (*f)();

for (x=0;x < 3;x++)

{

f=(int (*)()) a[x]; f();

}

}

Результат дизассемблирования этого кода в общем случае должен выглядеть так:

000000014000106E ; ----------------------------------------------

В строке call [rsp+58h+var_30] происходит косвенный вызов функции. А что у нас в [rsp+58h+var_30]? Поднимаем глаза на одну строку вверх — в [rsp+58h+var_30] у нас значение rax. А чему же равен сам rax? Прокручиваем еще одну строку вверх — rax равен содержимому ячейки [ rsp+rax*4+58h+var_28]. Вот дела! Мало того, что нам надо узнать содержимое этой ячейки, так еще и предстоит вычислить ее адрес!

Чему равен RAX в этом выражении? Содержимому [rsp+58h+var_38]. А оно чему равно? «Сейчас выясним...» — бормочем мы себе под нос, прокручивая экран дизассемблера вверх. Ага, нашли: в строке 0x140001074 в него загружается содержимое EAX! Какая радость! И долго мы будем так блуждать по коду?

Конечно, можно, потратив неопределенное количество времени, усилий и бодрящего напитка, реконструировать весь ключевой алгоритм целиком (тем более что мы практически подошли к концу анализа), но где гарантия, что при этом не будут допущены ошибки?

Гораздо быстрее и надежнее загрузить исследуемую программу в отладчик, установить бряк на строку .text:000000014000108E и, дождавшись всплытия окна отладчика, посмотреть, что у нас расположено в ячейке [rsp+58h+var_30]. Отладчик будет всплывать трижды, причем каждый раз показывать новый адрес! Заметим, что определить этот факт в дизассемблере можно только после полной реконструкции алгоритма.

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

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

Воспользуемся средствами IDA и посмотрим, что загружается в ячейки памяти [rsp+…]. А это как раз адреса трех наших функций, последовательно размещенных компилятором друг за дружкой:

«РУЧНОЙ» ВЫЗОВ ФУНКЦИИ ИНСТРУКЦИЕЙ JMP

Самый тяжелый случай представляют собой «ручные» вызовы функции командой JMP с предварительной засылкой в стек адреса возврата. Вызов через

JMP в общем случае выглядит так: PUSH ret_addrr / JMP func_addr, где ret_addrr и func_addr — непосредственные или косвенные адреса возврата и начала функции соответственно. Кстати, заметим, что команды PUSH и JMP не всегда следуют одна за другой и порой бывают разделены другими командами.

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

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

(Listing4):

int funct()

{

return 0;

}

int main()

{

__asm

{

LEA ESI, return_addr

PUSH ESI

JMP funct return_addr:

}

}

Поскольку присутствующее в этом коде ключевое слово asm платформенно зависимое и поддерживается только на x86, скомпилируем этот пример 32битным компилятором. Результат компиляции в общем случае должен выглядеть так:

Смотри, казалось бы, тривиальный безусловный переход, что в нем такого? Ан нет! Это не простой переход, это замаскированный вызов функции! Откуда он следует? Давай-ка перейдем по смещению sub_401000 и посмотрим:

Как ты думаешь, куда этот ret возвращает управление? Естественно, по адресу, лежащему на верхушке стека. А что у нас лежит на стеке? PUSH EBP из строки 0x401000, обратно выталкивается инструкцией POP из строки 0x401005... Возвращаемся назад, к месту безусловного перехода, и начинаем медленно прокручивать экран дизассемблера вверх, отслеживая все обращения к стеку. Ага, попалась птичка!

Инструкция PUSH ESI из строки 40101A закидывает на вершину стека содержимое регистра ESI, а он сам, в свою очередь, строкой выше принимает «на грудь» значение loc_401020 — это и есть адрес начала функции, вызываемой командой JMP (вернее, не адрес, а смещение, но это не принципиально важно):

АВТОМАТИЧЕСКАЯ ИДЕНТИФИКАЦИЯ ФУНКЦИЙ ПОСРЕДСТВОМ IDA PRO

Дизассемблер IDA Pro способен анализировать операнды инструкций CALL, что позволяет ему автоматически разбивать программу на функции. Причем IDA вполне успешно справляется с большинством косвенных вызовов. Между тем современные версии дизассемблера на раз-два справляются с комплексными и «ручными» вызовами функций командой JMP.

«Ида» успешно распознала «ручной» вызов функции

ПРОЛОГ

На платформе IA-32 большинство неоптимизирующих компиляторов помещают в начало функции следующий код, называемый прологом:

push ebp

mov ebp, esp

sub esp, xx

К сожалению, на x64 нет такой стройной последовательности инструкций. У каждой функции пролог существенно отличается. Поэтому рассмотрим пролог функций для x86.

В общих чертах назначение пролога сводится к следующему: если регистр EBP используется для адресации локальных переменных (как часто и бывает), то перед использованием он должен быть сохранен в стеке (иначе вызываемая функция «сорвет крышу» материнской), затем в EBP копируется текущее значение регистра указателя вершины стека (ESP) — происходит так называемое открытие кадра стека, и значение ESP уменьшается на размер области памяти, выделенной под локальные переменные.

Последовательность PUSH EBP / MOV EBP,ESP / SUB ESP,xx может служить хорошей сигнатурой, чтобы найти все функции в исследуемом файле, включая и те, на которые нет прямых ссылок. Такой прием, в частности, использует в своей работе IDA Pro, однако оптимизирующие компиляторы умеют адресовать локальные переменные через регистр ESP и используют EBP, как и любой другой регистр общего назначения. Пролог оптимизированных функций состоит из одной лишь команды SUB ESP, xxx — последовательность слишком короткая для использования ее в качестве сигнатуры функции, увы. Более подробный рассказ об эпилогах функций нас ждет впереди.

Продолжение статьи →

ИЩЕМ СТРУКТУРЫ ЯЗЫКОВ ВЫСОКОГО УРОВНЯ В ПРОГРАММАХ ДЛЯ X86-64

ЭПИЛОГ

С эпилогом такая же ситуация, на x64 отсутствует постоянная последовательность инструкций. Однако, поскольку 32-битных приложений так много, что их придется анализировать еще вечность, нам необходимо знать, как выглядит эпилог в программах на x86.

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

Эпилог 1:

Эпилог 2:

Важно отметить: между командами POP EBP / ADD ESP, xxx и MOV ESP,EBP / POP EBP могут находиться и другие команды — они не обязательно должны следовать вплотную друг к другу. Поэтому для поиска эпилогов контекстный поиск непригоден — требуется применять поиск по маске.

Если функция написана с учетом соглашения PASCAL, то ей приходится самостоятельно очищать стек от аргументов. В подавляющем большинстве случаев это делается инструкцией RET n, где n — количество байтов, снимаемых из стека после возврата. Функции же, соблюдающие С-соглашение, предоставляют очистку стека вызывающему их коду и всегда оканчиваются командой RET. API-функции Windows представляют собой комбинацию соглашений С и Pascal — аргументы заносятся в стек справа налево, но очищает стек сама функция.

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

Также нельзя забывать и о том, что компиляторы обычно (но не всегда!) не помещают в исполняемый файл код, никогда не получающий управления. Иначе говоря, у функции будет всего один эпилог, а все находящееся после первого return будет выброшено как ненужное. Между тем не стоит спешить вперед паровоза. Откомпилируем с параметрами по умолчанию следующий пример (Listing5):

int func(int a)

{

return a++; a=1/a; return a;

}

int main()

{

func(1);

}

Откомпилированный результат будет выглядеть так (приведен код только функции func):

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

(Listing6):

int func(int a)

{

if (a != 0) return a++;

return 1/a;

}

int main()

{

func(1);

}

Результат компиляции (только func):

.text:

00401016; Инкрементированное значение помещаем в аргумент,

.text:00401023; Расширяем EAX до EDX:EAX (нужно для деления).

.text:00401023 cdq

.text:00401024; Деление EDX:EAX, где находится 1, на аргумент,

Как и в предыдущем случае, компилятор создал только один эпилог. Обрати внимание: в начале функции в строке 0x401004 аргумент сравнивается с нулем, если условие выполняется, происходит переход на метку loc_40101E, где выполняется деление, за которым сразу следует эпилог. Если же условие в строке 0x401004 не соблюдено, выполняется сложение и происходит безусловный прыжок на эпилог.

Специальное замечание

Начиная с процессора 80286, в наборе команд появились две инструкции — ENTER и LEAVE, предназначенные специально для открытия и закрытия кадра стека. Однако они практически никогда не используются современными компиляторами. Почему?

Причина в том, что ENTER и LEAVE очень медлительны, намного медлитель-

нее PUSH EBP / MOV EBP,ESP / SUB ESB, xxx и MOV ESP,EBP / POP EBP. Так,

на старом добром Pentium ENTER выполняется за десять тактов, а приведенная последовательность команд — за семь. Аналогично LEAVE требует пять тактов, хотя ту же операцию можно выполнить за два (и даже быстрее, если разделить MOV ESP,EBP / POP EBP какой-нибудь командой).

Поэтому современный исследователь никогда не столкнется ни с ENTER, ни с LEAVE. Хотя помнить об их назначении будет нелишне. Мало ли, вдруг придется дизассемблировать древние программы или программы, написанные на ассемблере, — не секрет, что многие пишущие на ассемблере очень плохо знают тонкости работы процессора и их «ручная оптимизация» заметно уступает компилятору по производительности.

«ГОЛЫЕ» (NAKED) ФУНКЦИИ

Компилятор Microsoft Visual C++ поддерживает нестандартный квалификатор naked, позволяющий программистам создавать функции без пролога и эпилога. Компилятор даже не помещает в конце функции RET, и это приходится делать «вручную», прибегая к ассемблерной вставке __asm{ret} (использование return не приводит к желаемому результату).

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

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

CALL.

ИДЕНТИФИКАЦИЯ ВСТРАИВАЕМЫХ (INLINE) ФУНКЦИЙ

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

Чем плоха развертка функций для исследования программы? Прежде всего, она увеличивает размер материнской функции и делает ее код менее наглядным — вместо CALL / TEST EAX,EAX / JZ xxx с бросающимся в глаза условным переходом мы видим кучу ничего не напоминающих инструкций, в логике работы которых еще предстоит разобраться.

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

Рассмотрим следующий пример, чтобы увидеть, как компилятор оптимизирует встраиваемую функцию (Listing7):

#include <stdio.h>

inline int max(int a, int b)

{

if(a > b) return a;

return b;

}

int main(int argc, char **argv)

{

printf("%x\n",max(0x666,0x777)); printf("%x\n",max(0x666,argc)); printf("%x\n",max(0x666,argc)); return 0;

}

Результат его компиляции будет иметь следующий вид (функция main):

0000000140001009; к передаче в качестве параметров другой функции.

.text:000000014000101C; Возвращенный предыдущей функцией результат

.text:000000014000101C; передаем функции printf вместе с форматной

.text:0000000140001025; История повторяется, происходит подготовка

.text:0000000140001025; параметров для вызова функции.

.text:000000014000102E; Вызов «встраиваемой» функции max,

.text:000000014000102E; но, как мы видим, встраиваемой она не стала.

.text:0000000140001041; Подготовка параметров для вызова функции max.

«Так-так», — шепчем себе под нос. И что же он тут накомпилировал? Встраиваемую функцию представил в виде обычной! Вот дела! Компилятор забил на наше желание сделать функцию встраиваемой (мы ведь написали модификатор inline).

Ситуацию не исправляет даже использование параметров компилятора: / Od или /Oi. Первый служит для отключения оптимизации, второй — для создания встраиваемых функций. Такими темпами компилятор вскоре будет генерировать код, угодный собственным предпочтениям или предпочтениям его разработчика, а не программиста, его использующего!

Остальное ты можешь увидеть в комментариях к дизассемблированному листингу. Сравнивающая функция max в дизассемблированном виде будет выглядеть так:

.text:0000000140001078; Сравнение значений, переданных в параметрах.

000000014000107C; Если первый операнд меньше второго или равен ему,

.text:000000014000107C; переходим на метку, где возвращается второй

.text:0000000140001080; В обратном случае возвращаем первый операнд.

Здесь тоже все важные фрагменты прокомментированы.

Напоследок предлагаю откомпилировать и рассмотреть следующий пример (Listing8). Он немного усложнен по сравнению с предыдущим, в нем в качестве одного из значений для сравнения используется аргумент командной строки, который преобразуется из строки в число и при выводе обратно.

#include <iostream> #include <sstream> #include <string> using namespace std;

// Встраиваемая функция нахождения максимума. inline string max(int a, int b)

{

int val = (a > b) ? a : b; stringstream stream;

// Преобразуем значение в hex-число. stream << "0x" << hex << val;

string res = stream.str(); return res;

}

int main(int argc, char **argv)

{

cout << max(0x666, 0x777) << endl; string par = argv[1];

int val;

//Если впереди параметра есть символы '0x', if (par.substr(0, 2) == "0x")

//тогда это hex-число.

val = stoi(argv[1], nullptr, 16); else

// В ином случае это dec-число. val = stoi(argv[1], nullptr, 10); cout << max(0x666, val) << endl; cout << max(0x666, val) << endl; return 0;

}

VS Code

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

Следующим действием программа берет параметр командной строки. Она различает числа двух форматов: десятичные и шестнадцатеричные, определяя их по отсутствию или наличию префикса 0x. Два последующих оператора идентичны, в них происходят вызовы функции max, которой оба раза передаются одинаковые параметры: 0x666 и параметр командной строки, преобразованный из строки в число. Эти два последовательных оператора, как и в прошлый раз, позволят нам проследить вызовы функции.

Вывод приложения

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

ВЫВОДЫ

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

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