spiralbl0ck/browser-pwning-Правильная хорошо структурированная документация для начала работы с pwning Chrome и pwning V8.
Правильно структурированная документация для начала изучения chrome pwning & v8 pwning
Как организован этот документ
Браузеры — одна из самых используемых технологий сегодня. На каждом серийном компьютере, если мы просто подключим и будем использовать, увидим установленный браузер. Именно поэтому с точки зрения атакующего и модели угроз очень выгодно, если атакующий способен скомпрометировать браузер через вредоносную страницу. Учитывая вышеизложенные аргументы, я выбираю для изучения JavaScript-движок Google, в частности v8.
Учитывая огромный масштаб проекта v8, в качестве отправной точки я выбираю интерпретатор, а именно d8. Хотя по d8 уже проведено множество исследований, мы надеемся найти хотя бы одну ошибку, а если нет — иметь возможность продвинуться в исследовании эксплуатации браузеров, поскольку v8 предоставляет отправную точку для базовых стратегий разработки эксплойтов, используемых при эксплуатации браузеров.
Ещё одна причина, по которой я выбираю v8 в качестве цели, — это то, что он используется во многих браузерах.
Если заглянуть под капот, мы увидим, что этот движок используется и в MicrosoftEdge, так что есть шанс получить несколько вознаграждений за bug bounty. В качестве базовой операционной системы исследователь будет использовать смесь Windows и Linux, поскольку нет ограничений на получение шелла — ошибки v8 позволяют выполнять код через wasm-страницы, и это не привязано к какой-либо конкретной платформе.
К сожалению, хотя эксплуатируемая ошибка в v8 и привела бы к выполнению кода, мы не сможем выполнить какой-либо код из-за песочницы, и поэтому мы получим выполнение кода в контексте рендерера, что не позволит нам выполнять код на машине. Для этого нам понадобится ещё один эксплойт для песочницы, а значит, нам нужна полная цепочка эксплойтов для взлома системы.
Таким образом, мы определяем следующие цели, чтобы начать заниматься взломом браузеров:
На первом этапе проекта необходимо собрать как можно больше знаний об архитектуре Chrome и о том, как каждый компонент взаимодействует с другими. Чтобы лучше понять это, нам нужно разбить проект Chromium на несколько подкомпонентов, чтобы мы могли изолировать всё и проанализировать должным образом. Точнее, на сколько подкомпонентов разбивается каждый из следующих компонентов
Теперь самый логичный первый шаг — понять архитектуру Chromium. Итак, мы хотим эксплуатировать браузер, но что происходит, когда мы впервые запускаем браузер? После запуска исполняемого файла Chromium этот исполняемый файл запускает несколько процессов.
Порядок и их названия следующие:
Первый называется content-процесс. Что делает этот процесс?
Теперь, когда мы вкратце знаем, что он делает, пришло время углубиться в него:
Итак, как минимум в Windows Chromium работает следующим образом: он компилирует файлы в DLL, а затем загружает её в память. Таким образом, основная логика браузера Chromium находится в chromium.dll.
Это также подтверждается кодом
.
Это взято из chrome_exe_main_win.cc, и если вам интересно прочитать весь код, он находится в chromium/src/chrome/app. Дальше по ходу выполнения мы видим, что он вызывает MakeMainDllLoader(), чтобы вызвать класс загрузчика DLL, после чего запускает «загрузчик», то есть загружает chrome.dll, и при необходимости перезапускает его с нужными командными строками. Чтобы продолжить анализ загрузчика, нужно понять его код, который находится в том же каталоге в файле mail_dll_loader_win.cc. Прокрутив файл до самого конца, мы видим вызов MakeMainDllLoader, который в зависимости от вашей версии вызывает ChromeDllLoader или ChromiumDllLoader.
Мы видим, что ChromiumDllLoader — это класс, который наследуется от MainDllLoader. Из определения видно, что этот класс просто загружает DLL на основе аргументов, переданных в командную строку, и типа процесса
.
Анализируя метод Launch, мы можем понять некоторые вещи, которые происходят до запуска chrome.dll: Из этого комментария мы можем понять, что "// Launching is a matter of loading the right dll and calling the entry point. // Derived classes can add custom code in the OnBeforeLaunch callback." Запуск Chrome — это загрузка набора DLL, которые фактически выполняют работу. Во-вторых, он принимает аргументы, переданные в командную строку, а затем инициализирует службы песочницы.
.
Сначала он проверяет, является ли браузер инициатором инициализации песочницы, затем проверяет, был ли процесс, вызвавший инициализацию песочницы, вызван как служба облачной печати. Он также проверяет, был ли передан --no-sandbox бинарнику, что в основном сообщает бинарнику, что не нужно запускаться в песочнице. Он проверяет, было ли установлено что-либо из этого, и если какое-либо из условий истинно, вызывает песочницу с соответствующими опциями. Затем в конце мы добираемся до
что нам и интересно — это обёртка для вызова chrome_main.
Теперь посмотрим, что он делает. Откроем chromium.dll в binja
Основываясь на этой картинке с https://blogs.igalia.com/jaragunde/files/2019/03/chrome-init-sequence.png, мы имеем приблизительное представление о том, что искать в binja
Это так граф выглядит в binja
.
Чтобы лучше отследить его, поищите функцию ChromeMain. Это основная (она же ядро) логика Chrome. Внутри неё мы видим вышеупомянутые фазы того, как chrome.dll работает при запуске:
Здесь мы видим, что сначала он вызывает некоторые функции, такие как sub_180001420,sub_180017020,sub_180017020, которые выполняют проверки, чтобы выяснить детали того, как Chrome был установлен/скомпилирован. Используя исходный код, мы можем отследить их атрибуты. Первая функция, sub_180001420, соответствует UmaHistogramEnumeration, далее у нас есть sub_180017020, которая является InitializeFromPrimaryModule, а третья и последняя sub_180017020 — это chrome_main_delegate.
Мы постоянно повторяем chrome_main_delegate, но так и не определили, каково его назначение. ChromeMainDelegate — это класс, который наследуется от ContentMainDelegate и в основном предоставляет функции, связанные с запуском, и обработку вызовов процессов. !Если хотите, вы можете реализовать собственный интерфейс ContentMainDelegate, чтобы изменить поведение модуля Content по умолчанию, и использовать собственный класс ChromeMainDelegate в Chromium для настройки поведения процесса запуска.
Внутри него есть несколько вызовов функций, которые выполняют XOR над некоторыми областями данных и объединяют их с некоторым реестром, чтобы получить некоторые параметры запуска Chrome
.
Также обратите внимание, что функция sub_180001510 создаёт ссылку на scoped pointer с двумя колбэками. Не особенно важное действие, но интересно узнать, что такое BindStateBase. Мы будем часто встречать его в базовом коде Chrome.
Теперь вы можете задаться вопросом, что делают последние три строки, а именно
делают. Итак, первая строка в основном создаёт для замыканий (Closures). Что такое замыкание (closure) вообще?! Ну, если цитировать mozilla dev: "замыкание — это комбинация функции, объединённой вместе со ссылками на её окружающее состояние (лексическое окружение). Другими словами, замыкание даёт вам доступ к области видимости внешней функции из внутренней. В JavaScript замыкания создаются при каждом создании функции, в момент создания функции." Если говорить человеческим языком, это функция внутри функции, которая обращается к переменной внутри внешней функции. Например: .
Итак, по сути, это гарантирует, что замыкание будет выполнено. А остальные две строки просто задают определённое поведение для дампов, когда chrome — вставь сюда
Идём дальше: он проверяет свою версию во время выполнения, и если она не совпадает, он падает, и мы переходим к разбору командной строки
Заглянув внутрь sub_184171800, мы видим, что она не такая уж большая Сначала она принимает аргументы, переданные текущему процессу, затем вызывает функцию, которая принимает StringPiece — по сути, класс-обёртку для std::string, но немного более крутую, и эта функция в основном проверяет, был ли бинарник вызван в режиме headless, сравнивает, является ли имя запущенного бинарника chrome, проверяет, установлена ли USE_HEADLESS_CHROME, и затем переходит к следующему шагу, который называется content main.
Основываясь на предоставленных аргументах, задача content main — запустить соответствующую оболочку.
Если мы не передаём никаких аргументов оболочке, поток выполнения переходит к .
Чтобы понять, что он делает, нам нужно обратиться к его исходному коду. Мы можем найти его в
Нам придётся прокрутить до самого низа, и там мы найдём определение функции ContentMain. Там мы видим, что она вызывает две функции. Одна инициализирует ContentMainRunner — класс, который обрабатывает всё «создание процессов» в контексте создания браузерного IPC, SQLite, сети и всего остального. А другая в основном проверяет тип подпроцессов и передаёт его классу ContentMainRunner.
Теперь давайте сделаем шаг назад, чтобы понять поток кода. Сначала рассмотрим RunContentProcess, поскольку ContentMainRunner довольно сложен. Первое, что он делает, — создаёт GlobalActivityTracker. Омг !!! вы угадали, Google следит за вами :))) Нет, шучу, пожалуйста, не подавайте на меня в суд, Google. Но если серьёзно, он отслеживает каждый поток (это трекер потоков) и делает пару милых вещей для улучшения отладки, например: что по сути означает, что для каждого потока будет уникальное целое число, используемое в качестве идентификатора, чтобы лучше понять, что привело к падению процесса.
напр.:```
kTypeIdActivityTracker = 0x5D7381AF + 4, // SHA1(ActivityTracker) v4
kTypeIdUserDataRecord = 0x615EDDD7 + 3, // SHA1(UserDataRecord) v3
kTypeIdGlobalLogMessage = 0x4CF434F9 + 1, // SHA1(GlobalLogMessage) v1
kTypeIdProcessDataRecord = kTypeIdUserDataRecord + 0x100,
отслеживание стадии жизненного цикла процесса, которая определяется как```
// The phases are generic and may have meaning to the tracker.
PROCESS_PHASE_UNKNOWN = 0,
PROCESS_LAUNCHED = 1,
PROCESS_LAUNCH_FAILED = 2,
PROCESS_EXITED_CLEANLY = 10,
PROCESS_EXITED_WITH_CODE = 11,
// Add here whatever is useful for analysis.
PROCESS_SHUTDOWN_STARTED = 100,
PROCESS_MAIN_LOOP_STARTED = 101,
регистрируют как можно скорее выход процесса, сохраняют информацию о модуле, то есть когда загружается модуль (компонент Chromium), и, по сути, та же функциональность повторяется, но для разных потоков и классов. Если вам интересно, вы можете найти это в chromium/src/base/debug/activity_tracker.h
Затем проверяется, вызывалась ли "Main()" ранее. Я думаю, здесь имеется в виду, вызывалась ли ранее ChromeMain(). По сути, проверяется, были ли переданы какие-либо аргументы процессу контента, с которыми он был вызван. И если они были, они гарантируют, что процесс браузера получит те же аргументы. Затем они проверяют особенности платформы, и в случае обнаружения Windows инициализируют собственный обработчик с помощью CreateATLModuleIfNeeded, затем та же история: проверка особенностей платформы, и они передают аргументы с помощью SetupCRT, и мы доходим до части, где инициализируем IPC, чтобы можно было общаться с другими процессами после того, как мы их породили. Вот код, отвечающий за это. Мы не будем вдаваться в его подробности, так как вернёмся к этому позже и обсудим механизм IPC Chrome более детально. Пока просто знайте: это механизм, обеспечивающий взаимодействие между мультиархитектурными процессами Chrome. И если вы не знаете, что означает IPC, — это межпроцессное взаимодействие (inter process communication).
.
Затем он «пересылает», а точнее задаёт аргументы для UI с помощью ui::RegisterPathProvider, вызывает трекер и получает результат через content_main_runner->Initialize(std::move(params)), создаёт родительскую консоль (я думаю, имеется в виду, что создаётся родительский процесс), выполняет ещё несколько проверок, и затем мы подходим к важной части: 
.
Здесь мы видим вызов функции IsSubprocess. 
По сути, чтобы избежать старого шаблонного кода, она в одной функции проверяет тип процесса, полученного из командной строки, и если был передан какой-либо параметр, она выбирает из следующего и создаёт соответствующий процесс.```
return type == switches::kGpuProcess ||
type == switches::kPpapiPluginProcess ||
type == switches::kRendererProcess ||
type == switches::kUtilityProcess || type == switches::kZygoteProcess;
Оттуда мы переходим к `content_main_runner->Run();`, который по сути и делает всю магию. Давайте заглянем под капот. Итак, `content_main_runner` — это класс `ContentMainRunner`, ну.., который можно найти в `content\app\content_main_runner_impl.cc`
Чтобы реально понять поток выполнения для этого, нам нужно рассматривать его снизу вверх. И, как уже было сказано, мы снова прокручиваем вниз и обнаруживаем, что на самом деле `ContentMainRunner::Create()` вызывает `ContentMainRunnerImpl::Create()`; что даёт нам понимание того, что на самом деле нам придётся искать определение `ContentMainRunnerImpl`, а не `ContentMainRunner`, которое мы находим в `content_main_runner_impl.h` в той же уже упомянутой папке.
Мы видим, что он наследуется от `ContentMainRunner`, и видны его основные методы. На самом деле здесь не так уж много всего, поскольку его поведение в основном переопределяется в `content_main_runner_impl.cc`
Внутри `content_main_runner_impl.cc`, внутри метода run, он сначала делает некоторые проверки с помощью `DCHECK` (что это за функция, чёрт возьми? (```The CHECK() macro will cause an immediate crash if its condition is not met. DCHECK() is like CHECK() but is only compiled in when DCHECK_IS_ON is true (debug builds and some bot configurations, but not end-user builds).``` цитаты из google docs :) )), чтобы убедиться, что установлены `is_initialized`, `content_main_params_`, `is_shutdown_`.
После этого он получает аргументы и определяет тип, о котором я упоминал ранее
Затем, в случае, если мы не можем его найти, мы вызываем `InitializeFieldTrialAndFeatureList()` `delegate_->PostFieldTrialInitialization();` и отправляем это как сообщение через mojo.
 .
Далее он устанавливает кое-что для ui
опять же на основе того, что было передано в командной строке, и вызывает `RegisterMainThreadFactories`, что является обёрткой для `RegisterUtilityMainThreadFactory`, которая только устанавливает `g_utility_main_thread_factory`, которая, судя по названию, создаёт главный поток, который является своего рода watcher'ом для остальных потоков, и наконец запускает браузерный процесс. 
Если вы мне не верите, вот Chromium, дизассемблированный в binja, и мы также увидим немного анализа памяти этого.
Нам повезло: у нас есть chome.exe.pdb, который даёт нам отладочные символы, и нам не придётся мучиться при реверсе бинарника.
Поскольку мы работаем с chrome на windows, главной точкой входа для программы является wWinMain:
Вот как выглядит граф
.
Сама функция огромная, и поэтому я покажу только необходимые её части. После ряда инициализаций мы доходим до места, где вызывается `MakeMainDllLoader()`
, а что она делает, мы уже объяснили. Итак, как нам динамически отладить chrome и доказать всё, что я уже упомянул? Сначала мы загружаем его в windbg, затем используем lm и ищем имя исполняемого файла. После этого мы ищем функцию с именем chrome!MakeMainDllLoader, ставим точку останова и позволяем выполнению идти.. Заходим внутрь неё  даём ей выполняться, пока она не дойдёт до ret, и выходим из неё, попадая в chrome!wWinMain+0x764 . Затем мы позволяем ей выполняться до chrome!MainDllLoader::Launch и входим в неё. Оттуда мы ставим bp на chrome!MainDllLoader::Load, чтобы увидеть, как chrome.dll загружается в память. И, как мы видим, одной из первых загруженных вещей была chrome.dll  Отсюда ход анализа тот же, и полный анализ памяти останется как упражнение для читателя. Для особой цели я выполню анализ до того момента, когда процесс content почти завершён, и прямо перед запуском браузерного процесса я остановлюсь. Цель этого — просто показать, как ipc начинает взаимодействовать между процессами. Теперь после загрузки dll нам нужно найти инструкцию call rax. Я вывел 0x40 инструкций из текущего eip после загрузки dll.. По этому адресу находится то, что мы ищем, а именно chrome!ChromeMain.
Оттуда мы хотим поставить точку останова на , что по сути является большой проверкой перед переходом в content!content::ContentMain. Оттуда мы хотим перейти через несколько инструкций и попасть в content!content::ContentMain. Мы хотим войти внутрь и остановиться на content!content::RunContentProcess мы хотим войти внутрь и поставить bp на content!content::ContentMainRunnerImpl::Run+0x430, и как только мы перешагнём через  мы видим запуск mojo ipc и делаем вывод, что следующий процесс, а именно браузерный процесс, отвечает за фактическую реализацию браузера и обработку всех остальных процессов.
===============================================================================================
2.
В прошлый раз мы остановились после понимания content-процесса. Сегодня мы займёмся браузерным процессом.
Это процесс, который запускается после content-процесса, и это второй процесс из запускаемых chrome.
Давайте кратко его опишем:
* Мы можем считать его основным процессом, поскольку content-процесс — это скорее процедура инициализации и проверка зависимостей, и он запускается content-процессом.
* Он остаётся живым на протяжении всего времени жизни браузера.
* Он является центральным координатором всех процессов и работает с наивысшим уровнем привилегий, доступным браузеру.
* Поскольку он работает с наивысшими привилегиями, в случае, если другим процессам нужно выполнить операцию более высокого уровня, этот запрос обрабатывается браузерным процессом.
* Он управляет такими функциями, как адресная строка, закладки и кнопки назад/вперёд/перезагрузки. Поскольку это самый привилегированный процесс, он не доверяет данным, переданным ему любым из других процессов.
* Также обрабатывает привилегированные операции, такие как UI, сеть или файловое хранилище, для других процессов при необходимости.
Теперь, когда мы вкратце знаем, что он делает, пора углубиться в него:
Наш путь начинается в `src\content\app` в файле под названием content_main_runner_impl.cc, в функции `int ContentMainRunnerImpl::RunBrowser(MainFunctionParams main_params,bool start_minimal_browser)`, и первой операцией, которую она выполняет, как мы видим, является `TRACE_EVENT_INSTANT0` .
Что это? И вообще, что такое trace-функция? Если мы перейдём по ссылке https://lwn.net/Articles/379903/, то увидим, что они определяют это так , немного абстрагируясь, мы можем прийти к выводу, что trace-функция — это функция, которая записывает данные в конкретной точке кадра стека. Она делает не только запись стека выполнения функции, но и может записывать локальные переменные последней выполненной функции. Теперь, когда мы знаем, что такое trace-функция, посмотрим, что делает наша.
Если мы перейдём по ссылке https://chromium.googlesource.com/chromium/src/base/trace_event/common/+/refs/heads/main/trace_event_common.h, то увидим, что они определяют её как функцию, единственная цель которой — «отслеживание производительности приложения и использования ресурсов». Углубляясь дальше, чтобы понять, что она делает, мы видим, что это макрос, и он определён так . Чуть выше макроса мы видим краткое определение, которое говорит, что он немедленно записывает одно событие с именем «name» с 0, 1 или 2 аргументами. И если категория соответствующего события не включена, он ничего не делает. Мы видим, что в качестве параметров у нас есть «startup» как основная категория, и как подсистема — «ContentMainRunnerImpl::RunBrowser(begin)», а третий параметр — `TRACE_EVENT_SCOPE_THREAD`, который равен `#define TRACE_EVENT_SCOPE_THREAD (static_cast<unsigned char>(2 << 2))`; я думаю, что, судя по значению, это идентификатор соответствующего мгновенного события. По сути, это просто трассирует (логирует) тот факт, что мы вошли в функцию RunBrowser. Затем у нас есть проверка, запущен ли уже главный цикл браузера, и если он уже запущен, мы выходим из функции  . Затем мы устанавливаем флаг, и после этого мы попадаем в довольно интересную часть кода. Мы проверяем, есть ли поддержка механизма mojo_ipc, и если есть, мы используем ShouldCreateFeatureList, который создаёт список функций с разными процессами, пытается их инициализировать и, наконец, пытается инициализировать функции mojo.. Затем мы создаём пул потоков. Что такое пул потоков?!? Цитируя википедию: «паттерн проектирования программного обеспечения для достижения параллелизма выполнения в компьютерной программе». Более корректно объясняется так: «пул потоков поддерживает несколько потоков, ожидающих задачи для параллельного выполнения под управлением супервизорной программы» (это тоже цитата из википедии). Если объяснить более наглядно, представьте две линии людей, работающих на фабрике. Назовём их линия a и линия b. Все они управляются начальником. Назовём его линия c. Теперь линия b должна ждать, пока линия a закончит свою работу, и получить уведомление от линии c, чтобы начать работать. То же самое касается линии a. И это пул потоков. Вот также небольшой пример на C . Это бесстыдно взято с https://stackoverflow.com/questions/15752659/thread-pooling-in-c11 . Далее у нас есть вызов `PreBrowserMain();`, который выполняет некоторую специфичную для платформы инициализацию, и после этого мы доходим до момента, где вызывается `BrowserTaskExecutor::Create()`;
. Давайте подробно разберём, что он делает, так как имя довольно интересное, и, полагаясь на обоснованное предположение, можно понять, что это может быть интересно. Наш обходной путь начинается внутри файла content/browser/scheduler/browser_task_executor.h, где мы обнаруживаем, что `BrowserTaskExecutor` — это класс, который должен «сопоставлять base::TaskTraits с фактическими очередями задач для браузерного процесса». Пройдём немного дальше по файлу, и сначала мы видим  он наследуется от `BaseBrowserTaskExecutor`. Теперь, чтобы понять, что такое `BrowserTaskExecutor`, нужно понять `BaseBrowserTaskExecutor`. Мы видим, что он наследуется от `TaskExecutor`. К счастью для нас, мы видим, что он переопределяет методы `TaskExecutor` с переопределяемым свойством, что означает, что они будут переопределены другими вызовами методов позже. Но для любопытных: мы можем найти его в base/task/task_executor.h, и если мы его изучим, то узнаем, что `TaskExecutor` — это класс, который «может выполнять Tasks с определённым идентификатором расширения TaskTraits»  .
Что такое task и что такое tasktraits. Мы уже упоминали, что такое task, но для освежения: это один из процессов chrome, а теперь что такое TaskTraits? Они находятся в base/task/task_traits.h и определяются следующим образом: «инкапсулируют информацию о задаче, которая помогает пулу потоков принимать лучшие решения о планировании». Возвращаясь к нашему `BrowserTaskExecutor`. Метод, который мы вызываем, — это Create(), и его анализ выглядит следующим образом 
сначала проверяется, нужно ли выполнять текущую задачу из SingleThreadTaskRunner. То есть нужно ли выполнять эту задачу с использованием независимого потока. Мы делаем это, получая указатель на tls. Затем мы инициализируем ui и потоковый планировщик. По сути, здесь мы инициализируем планировщик для будущих событий, связанных с ui..
И это всё для этой функции. Продолжая анализ content_main_runner_impl.cc, мы переходим сюда.
Ищем файл класса variations ids provider, мы находим его в `components/variations/variations_ids_provider.h`, и там видим кое-что довольно интересное. Он включает файл `.mojom.h`. Его определение можно найти в `Debug/gen/components/variations/` variations.mojom.h, что означает, что он относится к механизму ipc. Теперь, просматривая фактическое определение класса, мы видим комментарий, который гласит: «Вспомогательный класс для поддержания состояния клиентских экспериментов и метрик, передаваемых в пользовательских HTTP-заголовках запросов». Изучив его поведение и исходное определение, мы делаем вывод, что он просто используется как маркер для функции, который отмечает, что «параметр signed-in передаётся в GetClientDataHeaders()», что означает, что где-то в стеке выполнения есть вызов GetClientDataHeaders, и позже он будет вызван с параметром. Затем мы выполняем `delegate_->PostEarlyInitialization(!!main_params.ui_task);`, что просто отправляет через mojo ipc сообщение о необходимости запуска задач ui. Мы делаем ещё инициализацию  и затем переходим к вызову RunBrowserProcessMain.  . Если вы, как и я, надеялись, что именно здесь мы увидим запуск gui, вы ошибаетесь. Цитата от мастера Угвея . Затем мы идём и делаем ещё несколько проверок, и мы попадаем в BrowserMain. Проходя по нему, он выполняет некоторую трассировку, и затем мы попадаем в место, где мы фактически запускаем gui. Теперь, если вы мне не верите, вам придётся немного потерпеть до динамического анализа. Затем мы переходим к методу Run, который как раз то, что нам интересно, а после него мы перейдём к следующему пункту понимания браузерного процесса. Но пока давайте сделаем ещё один короткий крюк и исследуем, как создаётся метод Initialize. Сразу видно, что он трассирует выполнение метода init, и перед этим создаёт гистограмму. Затем мы проверяем флаг initialization_started_, чтобы увидеть, дошли ли мы до стадии инициализации, и если нет, мы инициализируем skia — графическую библиотеку, используемую chrome, запускаем «таймер» для подсчёта секунд, потраченных на выполнение этого метода, для последующего использования в гистограмме, проверяем, передали ли мы бинарю параметр ожидания подключения отладчика к процессу, и, наконец, запускаем notification_service_, который, по обоснованному предположению, уведомит главный watcher пула потоков о том, когда запускать сервис. . Затем мы инициализируем необходимые шрифты для chrome и создаём mainbrowserloop, который является координатором всех процессов, и мы перепрыгиваем через три метода, которые не представляют для нас интереса:
main_loop_->CreateStartupTasks();
int result_code = main_loop_->GetResultCode();
отсюда нам интересно зайти в CreateStartupTasks. Оттуда мы смотрим на content\browser\browser_main_loop.cc, нас интересует startup_task_runner_->RunAllTasksNow();, который находится внутри метода CreateStartupTasks. startup_task_runner_ — это `StartupTaskRunner`, который находится в том же каталоге внутри файла startup_task_runner.cc. Теперь, если мы изучим метод RunAllTasksNow, мы увидим, что он просто перебирает все задачи и выполняет их
==========================================================================================
Время для динамического анализаТеперь, чтобы поймать рендерер, нам нужно будет запустить бинарник в windbg. Это легко достигается через File->Open Executable и передачей --renderer-startup-dialog --no-sandbox --wait-for-debugger-children=renderer --renderer-process-limit=1 в качестве аргументов.. Затем мы ставим bp на content!content::StartupTaskRunner::RunAllTasksNow+0x88, чтобы поймать IPC-сообщения и позже рендерер. Просто для справки: так должен выглядеть ваш отладчик после однократного запуска  . Вы должны увидеть сообщение о том, что Chrome запущен в полноценном браузерном режиме. Оттуда вы считаете от одного до пяти, то есть запускаете его ещё четыре раза. И тогда вы должны увидеть что-то вроде . Я рекомендую использовать procmon, чтобы вы могли отслеживать процесс рендерера при его запуске. После этого вы подключаете его к другому отладчику, и если вы использовали указанные выше аргументы, вы должны увидеть всплывающее окно с PID рендерера. Оттуда вы захотите поставить bp на base!base::RunLoop::Run. К сожалению, по какой-то причине нельзя поставить breakpoint на content!content::RendererMain. Возможно, потому что мы подключаемся к процессу сразу после того, как он выходит из функции RendererMain, и он выполняется потоком. В любом случае, вот как выглядит IPC после четырёх запусков.. Это указывает на то, что GUI запущен. А вот как выглядит IPC после запуска процесса рендерера.. Затем мы ставим bp на
content!content::StartupTaskRunner::RunAllTasksNow+0x88 и content!content::RunOtherNamedProcessTypeMain. Пусть он работает.
============================================================================================================
3. Теперь, что касается второй части анализа процесса браузера: мы дошли до момента, когда сможем понимать и отлаживать рендерер, но пока не пойдём туда. Я специально оставил ещё одну функцию для анализа после RunBrowserProcessMain — теоретически она идёт после RunBrowser, но, как вы помните, RunBrowser — это обёртка над RunBrowserProcessMain. Итак, я оставил за кадром то, что в файле content_main_runner_impl.cc в папке src/content/app есть ещё одна функция, которая вызывается после того, как мы порождаем рендерер, и называется RunOtherNamedProcessTypeMain. Этот процесс отвечает за запуск всех остальных процессов.. Теперь давайте разберёмся, что происходит в коде. Мы видим, что её прототип выглядит так , что указывает на то, что она принимает аргументы, переданные в cmdline, ожидаемый тип процесса и делегат Chrome. Затем мы переходим к началу функции, где есть макроопределение для проверки особенностей платформы и определения, для какого процесса создавать обработчик событий. То есть проверяется, выполняет ли она некие функции для консольного процесса или для процесса браузера. . Затем мы итерируем по переданным процессам, сравниваем со списком известных процессов и запускаем соответствующий процесс.  Если мы не находим соответствующий процесс, значит, это кастомный процесс, реализованный кем-то.
Вот ссылка на реализацию кастомного процесса, и мы будем использовать этот пример для второй части динамического анализа. https://bitbucket.org/chromiumembedded/cef/wiki/Tutorial .
=====================================================================
Динамический анализ
Первая часть динамического анализа начинается так: сначала запустите из cmd.exe с правами администратора следующую команду: windbg.exe chrome.exe -G -o --renderer-startup-dialog --no-sandbox --wait-for-debugger-children=renderer --renderer-process-limit=1 --allow-pre-commit-input --allow-sandbox-debugging . После этого установите .childdbg 1, чтобы мы могли отлаживать новые порождённые дочерние процессы. По сути, приведённая выше команда означает «убедиться, что вы подключены ко всем дочерним процессам». Отдельное спасибо @spoofyroot и @_coreDump за то, что указали мне правильное направление в многопроцессной отладке. Вот как это должно выглядеть после установки .childdbg 1  Так как мне не удалось каким-либо другим способом запечатлеть, что происходит дальше, я снял видео, в котором объясню, что происходит дальше. https://streamable.com/9t4iof . По сути, после того как мы в последний раз запускаем content!content::StartupTaskRunner::RunAllTasksNow+0x88, мы порождаем новые процессы, которые обрабатывают некоторые IPC-вещи, и нам придётся продолжать ставить bp на content!content::RunContentProcess, пока он не сработает. Это то, что я называю «осознанным методом проб и ошибок» :)) .
=====================================================================
4. Анализ рендерера
!Дисклеймер
Хотя мы будем анализировать код рендерера, мы также немного окунёмся в код Blink, чтобы правильно понять, что происходит в рендерере.
Пока я писал эту часть курса, я понял, что забыл кратко описать, что это такое и зачем мы вообще в это смотрим. Как мы знаем, это третий процесс, запускаемый Chromium, и он называется рендерером. Но почему он называется «рендерером»? Он так называется потому, что его работа — рендерить (рисовать) всё, что мы видим на веб-сайте. По сути, это причина, по которой ваша таблица выглядит как таблица, когда вы заходите на веб-сайт, или ваш CSS позволяет настраивать фрагмент текста. Или почему ваш JS способен творить чёрную магию*. Ещё одна важная причина, по которой мы анализируем это, — именно отсюда берётся большинство багов. Будь то HTML, CSS, JS или любой другой компонент, все они находятся в разделе Blink на chrome bugs.chromium.org.
* Существует несколько процессов рендерера. Отдельный процесс для каждой вкладки, открытой в данный момент в браузере.
* Этот процесс управляет всем, что находится внутри самой вкладки веб-сайта.
* Начиная с 2018 года iframe получил обновление, благодаря которому все они могут иметь вкладки. И каждая вкладка iframe имеет отдельный процесс рендерера. Это называется Site-Isolation.
* Его задача — разбирать веб-сайт, отрисовывать на экране то, что находится внутри веб-сайта, например таблицы, изображения, а также выполнять JavaScript.
* Он находится в песочнице (sandbox).
* В его основе лежит движок рендеринга под названием Blink.
* Создаёт и обрабатывает схемы URL, такие как: chrome://, devtools://, chrome-error://.
* Инициализирует движок Blink, который фактически выполняет весь парсинг и основную работу для процесса рендерера.
В прошлый раз мы завершили анализ процесса браузера, и теперь настал момент, которого все мы ждали, — перейти к анализу рендерера. Когда я экспериментировал с Chromium, мне удалось вызвать крах, и я получил следующий стек-трейс.  Исходя из этого, мы знаем, что наш путь начинается с content::RendererMain, который находится в `\content\renderer\renderer_main.cc` . Как вы догадались, отправная точка — RendererMain. Давайте начнём с анализа того, как она определена, и немного заглянем внутрь неё  . Мы видим, что она принимает параметр типа MainFunctionParams, что означает, что эта функция принимает переданные бинарнику аргументы. Далее мы добавляем точку трассировки, чтобы знать, что мы дошли до вызова RendererMain, а затем разыменовываем значение parameters и сохраняем его в command_line. Затем у нас есть несколько макросов, которые проверяют специфичную для платформы архитектуру, которые мы можем игнорировать , мы проверяем значение, переданное в kTimeZoneForTesting, — это часовой пояс для тестирования, а затем мы знакомимся с новым классом и типом данных под названием ICU.
Теперь, если мы поищем, где находится определение этого, мы приходим на https://unicode-org.github.io/icu-docs . Если мы посмотрим на начало файла, где находится директива include, мы увидим, что это сторонняя библиотека. Итак, до сих пор мы знаем, что это сторонняя библиотека, которая занимается интернациональными компонентами для Unicode, то есть мы используем её для поддержки Unicode. Ок, но что делает эта функция? Заглянув на https://unicode-org.github.io/icu-docs , мы видим , то есть она устанавливает часовой пояс по умолчанию на основе того, что мы передали в качестве параметров. Затем мы инициализируем библиотеку Skia и обрабатываем --renderer-startup-dialog
. Затем нас встречает новый класс RendererMainPlatformDelegate.
Что это делает? Что ж, во-первых, нужно уточнить, что это абстрактный класс, зависящий от платформы. В нашем случае он находится в /content/renderer внутри файла renderer_main_platform_delegate_win.cc . Выглядит он так
. Итак, мы можем заключить, что это вспомогательная функция, которая включает sandbox, а в случае передачи --no-sandbox выполняет необходимые действия — и на этом всё. Затем мы устанавливаем имя нашего потока в CrRendererMain. Затем мы встречаем ещё один новый класс под названием RenderThread. 
Опять же, поскольку мы в основном не знаем, что он делает, давайте немного его изучим. Наш путь к пониманию того, как выглядит RendererThread, начинается с content/public/renderer/render_thread.h. Заглянув внутрь файла render_thread.h, мы видим, что он определён так . Из всего этого файла нас интересует IsMainThread, который определён в файле rendere_thread.cc и выглядит так  (добавить длинное описание этого механизма). Продолжая анализ кода рендерера, мы видим самый ожидаемый момент: наконец-то мы видим код Blink. Первый из них — он инициализирует библиотеку.. За кулисами функция выглядит так . Теперь возникает естественный вопрос: что это за классы, чёрт возьми? Что такое WTF и Platform. К счастью, документация Blink действительно рассказывает нам, что это.
https://docs.google.com/document/d/1aitSOucL0VHZa9Z2vbRJSyAIsAz24kX8LFByQ5xQnUg/edit . Глядя на «Directory structure and dependencies», мы можем сделать вывод, что platform — это класс, который помогает с геометрией и графикой. Теперь о классах WTF и Partitions. Документация Blink также говорит о WTF: он происходит из Web Template Framework и в значительной степени является «обёрткой» над STL-библиотекой, например: «это базовая библиотека для Blink, предоставляющая множество базовых функциональностей, таких как контейнеры, строковые библиотеки, механизмы подсчёта ссылок, функторы, примитивы потоков и т.д.» (цитаты из документации Blink (https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/blink/renderer/platform/wtf/README.md)).Добавь ещё деталей о Blink.
Ок, продолжая анализ renderer_main.cc, мы снова видим нечто, о чём мы не знаем, что оно делает, и это  Добавь детали завтра.Затем мы вызываем .Затем мы проверяем, включили ли мы поддержку плагинов при компиляции, и если да — загружаем их.
 Затем мы выполняем ещё несколько проверок, которые я решил пропустить, потому что объяснение становится довольно длинным, и на данном этапе они не обязательны. Но в версии TL;DR это проверка того, включать ли sandbox перед инициализацией RenderProcess.И затем мы наконец добираемся до . (добавь остальные детали об остальных функциях). Хотя это и не конец анализа рендерера, мы можем считать это отправной точкой собственно анализа рендерера, потому что, как мы увидим позже, здесь происходит большая часть интересного, так что можно считать это кодом рендерера. Нас интересует RenderThreadImpl, который выглядит так . Из всего этого кода нас интересует функция Init(), которая выглядит так:
, но она гораздо длиннее. :) К сожалению, мы не можем захватить её на одном скриншоте, поэтому мы захватили её начало. Кроме того, всё, что происходит после InitializeWebKit(), не очень нас интересует, поскольку большая часть этого — просто IPC-общение с GPU-процессом, который сейчас не в нашем поле зрения. Нам улыбнулась удача, потому что в этой функции мы также поймали одну из интересующих нас функций, а именно InitializeWebKit(), которая опять же выглядит так . Мы немного отклонимся от нашей задачи объяснения renderer_main.cc, чтобы лучше понять, что происходит внутри InitializeWebKit. Я знаю, что это сложно понять, но потерпите, пока мы пытаемся навести порядок в этом бардаке. Итак, мы видим, что InitializeWebKit() начинается с взятия всех аргументов, переданных этому процессу, затем мы проверяем, включили ли мы при компиляции -dENABLE_VTUNE_JIT_INTERFACE, и если да, то проверяем переданный в cmdline параметр enable-vtune-support. Что это за хрень? Мы поискали в Google и нашли ссылку на https://www.intel.com/content/www/us/en/develop/documentation/vtune-help/top.html , и на этой странице сказано: «это инструмент анализа производительности для последовательных и многопоточных приложений». Так что, TL;DR, это то, что улучшает производительность вашего Chrome.Затем мы инициализируем Blink . Теперь, чтобы понять процесс инициализации Blink, давайте кратко объясним, поскольку в следующей главе мы рассмотрим Blink подробно. Нас встречает ещё один незнакомый класс — RendererBlinkPlatformImpl, который выглядит так
 и находится в
content/renderer/renderer_blink_platform_impl.cc . Исходя из названия, мы можем заключить, что это абстрактный класс, который реализуется в зависимости от платформы, и мы также видим, что он наследуется от  Просматривая, что именно делает RendererBlinkPlatformImpl, мы видим, что он проверяет платформу и затем по результатам проверки устанавливает флаг, затем проверяет, является ли текущий поток RendererThread, получая указатель на TLS.
бла-бла-бла, посмотри, добавить ли ещё контента о классах. Затем мы приходим к тому, чего все мы, возможно, ждали, — это первый кусок кода V8. Вот он . Что это делает? Прежде всего, мы знаем из документации, что v8::isolate — это экземпляр движка V8. То есть (независимая копия V8 runtime, включая менеджер кучи, сборщик мусора и т.д.), которой недостаточно для выполнения скриптов. Мы видим, что blink::MainThreadIsolate() определён как
, который находится в файле blink/renderer/platform/bindings/v8_per_isolate_data.cc , и в свою очередь V8PerIsolateData::MainThreadIsolate() выглядит так
 , V8PerIsolateData, который, как вы догадались, тоже является классом, находится в bindings/core/v8/V8PerIsolateData.h и выглядит примерно так бла-бла-бла, добавь детали. Затем мы проверяем, передали ли мы kDisableThreadedCompositing (завтра добавь, как на самом деле выглядит флаг) в командную строку. Если нет — мы запускаем поток компоновщика. Что это такое? Цитируя https://frontendmasters.com/courses/web-performance/the-compositor-thread/ , это поток, чья «единственная задача — рисовать битмапы, отправлять их на GPU и выводить на экран». Затем мы регистрируем так называемую схему. В принципе, помните, когда вы просматриваете исходный код, перед URL есть что-то вроде: "view-source:website" . Да, это как раз обрабатывается рендерером. И таких схем больше. Что значит «регистрировать»? Я пока не уверен, но думаю, это означает: «эй, я хочу, чтобы ты обработал это, когда пользователь придёт и сделает это». В любом случае, выглядит это так. добавь больше деталей. хорошо, сейчас добавлю детали и для последнего куска кода 
. бла-бла и наконец мы добрались до финальной части renderer_main, обнови с деталями
=====================================================================
Динамический анализТеперь, чтобы иметь возможность динамически отлаживать его, если ты такой же новичок, как и я, тебе нужно запустить windbg из cmd.exe следующим образом: windbg.exe chrome.exe -G -o --renderer-startup-dialog --no-sandbox --wait-for-debugger-children=renderer --renderer-process-limit=1 --allow-pre-commit-input --allow-sandbox-debugging --time-zone-for-testing="US/Pacific", и установить .childdbg 1, чтобы можно было отлаживать порождённый дочерний процесс. Далее нужно поставить bp content!content::RendererMain и дать ему выполниться примерно 5 или 6 раз. (измени, чтобы ссылаться на 4-е видео, так понятнее) после этого мы попадаем на .
std::unique_ptr<>
crashes.InstallDetails::Get().VersionMismatch()
/src/content/app/content_main.cc