spiralbl0ck/browser-pwning-Uma documentação adequada e bem estruturada para começar com chrome pwning e v8 pwning
Uma documentação adequada e bem estruturada para começar com chrome pwning & v8 pwning
Como este documento está organizado
Navegadores são uma das tecnologias mais usadas hoje em dia. Em todo computador de prateleira, se simplesmente conectarmos e usarmos, veremos um navegador instalado. É por isso que, do ponto de vista de um atacante e de uma perspectiva de modelo de ameaças, é muito recompensador se o atacante conseguir comprometer o navegador através de uma página maliciosa. Dados os argumentos acima, escolhi estudar o Motor JavaScript do Google, particularmente o v8.
Dada a natureza gigantesca do projeto do v8, escolhi como ponto de partida o interpretador, nomeadamente o d8. Embora uma pesquisa extensa já tenha sido feita sobre o d8, esperamos encontrar pelo menos um bug e, se não, conseguir avançar com a pesquisa sobre exploração de navegadores, já que o v8 fornece o terreno de entrada para as estratégias básicas de desenvolvimento de exploits usadas na exploração de navegadores.
Outra razão pela qual escolhi o v8 como alvo é que ele é usado em vários navegadores.
Se olharmos por baixo do capô, podemos ver que o motor também é usado no MicrosoftEdge, então há uma chance de múltiplos prêmios de bug bounty. Para o sistema operacional subjacente, o pesquisador usará uma mistura de Windows e Linux, já que não há restrição em termos de obter um shell, pois bugs do v8 permitem execução de código através de páginas wasm e isso não está vinculado a nenhuma plataforma específica.
Infelizmente, embora um bug explorado no v8 resulte em execução de código, não conseguiremos executar nenhum código devido à sandbox e, assim, obteríamos execução de código no contexto do renderer, o que não nos permitiria executar código na máquina. Para isso, precisaríamos de outro exploit para a sandbox; portanto, precisaríamos de uma cadeia completa para explorar o sistema.
E assim definimos os seguintes objetivos para conseguir começar com hacking de navegadores
Na primeira fase do projeto, é necessário reunir o máximo de conhecimento sobre a Arquitetura do Chrome e como cada componente interage com os outros. Para entender melhor isso, precisamos dividir o Projeto Chromium em vários subcomponentes, de modo que possamos isolar tudo e analisá-lo adequadamente. Mais precisamente, em quantos subcomponentes cada um dos seguintes componentes se divide
Agora, o passo mais lógico para um primeiro passo é entender a arquitetura do Chromium. Então, ok, queremos explorar o navegador, mas o que acontece quando iniciamos o navegador pela primeira vez? Bem, depois de clicar no executável do Chromium, o executável inicia alguns processos.
A ordem e seus nomes são os seguintes:
O primeiro é chamado de content process. O que esse processo faz ?
Agora que sabemos brevemente o que ele faz, é hora de nos aprofundarmos nele:
Então, a forma como o Chromium funciona, pelo menos no Windows, é que ele compila os arquivos em uma dll e, depois disso, carrega-a na memória. Portanto, a lógica central do navegador Chromium está em chromium.dll.
Isso também é confirmado pelo código
.
Isso é retirado de chrome_exe_main_win.cc e, se você estiver curioso para ler o código inteiro, ele está localizado em chromium/src/chrome/app . Ok, descendo na execução, podemos ver que ele chama MakeMainDllLoader() para chamar a classe de dll carregada; depois disso, ele inicia o "loader", ou seja, carrega o chrome.dll e, se necessário, o reinicia com as linhas de comando necessárias. Para analisar melhor o Loader, precisamos entender seu código, que está no mesmo diretório, no arquivo mail_dll_loader_win.cc.Descendo até o final do arquivo, podemos ver a chamada a MakeMainDllLoader, que, por sua vez, chama, com base na versão que você tem, ChromeDllLoader ou ChromiumDllLoader.
Podemos ver que ChromiumDllLoader é uma classe que herda de MainDllLoader. Podemos ver pela definição que a classe simplesmente carrega a dll com base nos argumentos passados para cmdline e no tipo de processo
.
Analisando o método Launch, podemos entender algumas coisas que acontecem antes de o chrome.dll iniciar: Podemos entender deste comentário que "// Launching is a matter of loading the right dll and calling the entry point. // Derived classes can add custom code in the OnBeforeLaunch callback." lançar o chrome é uma questão de carregar um monte de dlls que realmente fazem o trabalho. Em segundo lugar, ele pega os argumentos passados para a linha de comando e, além disso, inicializa os serviços de sandbox.
.
Primeiro, ele verifica se é o navegador que está chamando a inicialização da sandbox; depois, verifica se o processo que chamou a inicialização da sandbox foi chamado como um serviço de impressão na nuvem. Ele também verifica se --no-sandbox foi passado para o binário, o que basicamente diz ao binário para não executar em uma sandbox. Ele verifica se alguma dessas opções foi definida e, se alguma for verdadeira, chama a sandbox com as respectivas opções. Então, no final, chegamos a
que é o que nos interessa, representando o wrapper para chamar chrome_main.
Agora vamos ver o que ele faz. Abrimos o chromium.dll no binja
Com base nesta imagem de https://blogs.igalia.com/jaragunde/files/2019/03/chrome-init-sequence.png temos uma ideia aproximada do que devemos procurar no binja
É assim que o grafo se parece no binja
.
Para conseguir rastrear melhor, procure uma função chamada ChromeMain. Esta é a lógica principal (também conhecida como core) do chrome. Dentro dela, podemos ver as fases acima mencionadas de como o chrome.dll é executado na inicialização:
Aqui podemos ver que ele primeiro chama algumas funções como sub_180001420, sub_180017020, sub_180017020, que fazem algumas verificações para ver detalhes sobre como o chrome foi instalado/compilado. Usando o código-fonte, podemos rastrear seus atributos. A primeira função, sub_180001420, corresponde a UmaHistogramEnumeration; em seguida, temos sub_180017020, que é InitializeFromPrimaryModule; e a terceira e última, sub_180017020, é chrome_main_delegate.
Continuamos repetindo chrome_main_delegate, mas nunca definimos qual é o seu propósito. ChromeMainDelegate é uma classe que herda de ContentMainDelegate e fornece principalmente funções relacionadas à inicialização e ao processamento de chamadas de processo. !Caso você queira, pode implementar uma interface ContentMainDelegate personalizada para alterar o comportamento padrão do módulo Content e usar uma classe ChromeMainDelegate personalizada no Chromium para personalizar o comportamento do processo de inicialização.
Dentro dela, há algumas chamadas de função que fazem xor em algumas regiões de dados e as concatenam com algum registro para obter algumas opções sobre a inicialização do chrome
.
Observe também que a função sub_180001510 está criando uma referência de ponteiro com escopo (scoped pointer) com dois callbacks. Não é realmente importante o que ela faz, mas é interessante aprender o que é um BindStateBase. Vamos encontrá-lo muito no código-base do chrome.
Agora você pode estar se perguntando o que fazem as últimas três linhas, precisamente
fazem. Então, a primeira linha basicamente cria um para Closures. WTF é um closure!? Bem, se fosse citar do Mozilla Dev" closure é a combinação de uma função agrupada (incluída) com referências ao seu estado ao redor (o ambiente léxico). Em outras palavras, um closure dá a você acesso ao escopo de uma função externa a partir de uma função interna. Em JavaScript, closures são criados toda vez que uma função é criada, no momento da criação da função." Se fosse usar linguagem humana, é uma função dentro de uma função que acessa uma variável dentro da função externa. Eg .
Então, em essência, ele garante que o closure será executado. E as outras duas linhas apenas definem um comportamento específico para dumps quando o chrome patchuie aici
Indo mais adiante, ele verifica sua versão em tempo de execução e, caso ela não corresponda, ele trava e chegamos à análise da linha de comando
Entrando em sub_184171800, podemos ver que não é tão grande Primeiro, ele pega os argumentos passados para o processo atual; depois, chama uma função que recebe uma StringPiece, basicamente um wrapper de classe para std::string, mas um pouco mais legal, e essa função basicamente verifica se o binário foi chamado com headless, compara se o nome do binário que foi executado é chrome, verifica se USE_HEADLESS_CHROME está definido e então avança para o próximo passo, que é content main.
Com base nos argumentos fornecidos , o trabalho do content main é iniciar o shell respectivo.
Agora, caso não forneçamos nenhum argumento ao shell, o fluxo de execução vai para .
Para entender o que ele faz, precisamos verificar a fonte dele. Podemos encontrá-la em
Teremos que rolar até o final e lá encontraremos a definição da função ContentMain. Lá, vemos que ela chama duas funções. Uma que inicializa um ContentMainRunner, que é a classe que lida com toda a "criação de processos" no contexto de criar o browser, ipc, sqli, net e o resto. E a outra que basicamente verifica o tipo de subprocessos e os alimenta para a classe ContentMainRunner.
Agora vamos dar um passo atrás para entender o fluxo de código. Primeiro, vamos examinar o RunContentProcess, pois o ContentMainRunner é bastante complexo. O primeiro passo que ele dá é criar um GlobalActivityTracker. Omg !!! você adivinhou, o Google rastreia você :))) Não, brincadeira, por favor não me processe, Google. Mas falando sério, ele rastreia cada thread, sendo um rastreador de threads, e faz algumas coisas interessantes para melhorar a depuração, como: o que, em essência, significa que haverá um inteiro exclusivo usado como identificador para cada thread, para entender melhor o que faz o processo quebrar.
eg:```
kTypeIdActivityTracker = 0x5D7381AF + 4, // SHA1(ActivityTracker) v4
kTypeIdUserDataRecord = 0x615EDDD7 + 3, // SHA1(UserDataRecord) v3
kTypeIdGlobalLogMessage = 0x4CF434F9 + 1, // SHA1(GlobalLogMessage) v1
kTypeIdProcessDataRecord = kTypeIdUserDataRecord + 0x100,
tracking a process life stage which is defined as```
// 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,
Registra assim que um processo é encerrado, salva as informações sobre o módulo, ou seja, quando um módulo (um componente do Chromium) é carregado e, basicamente, a mesma funcionalidade se repete, mas de forma diferente para threads e classes distintas. Se você estiver interessado, pode encontrá-lo em chromium/src/base/debug/activity_tracker.h
Em seguida, verifica se "Main()" foi chamado antes. Acho que aqui eles querem dizer se ChromeMain() foi chamado antes. Basicamente, eles verificam se algum comando foi passado ao processo de conteúdo quando ele foi chamado com argumentos. E, caso tenha sido, garantem que o processo do navegador receberá os mesmos argumentos. Então eles verificam especificidades da plataforma e, caso o Windows seja encontrado, inicializam o próprio handler fazendo CreateATLModuleIfNeeded; depois é a mesma história de verificar especificidades da plataforma e passar os argumentos usando SetupCRT, até chegarmos à parte em que inicializamos o IPC para podermos conversar com os outros processos depois de os termos gerado. Aqui está o código responsável por isso. Não vamos entrar em detalhes sobre ele, pois voltaremos a este ponto mais adiante, discutindo com mais profundidade o mecanismo de IPC do Chrome. Por enquanto, basta saber que este é o mecanismo que facilita a comunicação entre os processos da arquitetura multi-processos do Chrome. E caso você não saiba o que significa IPC, é Inter-Process Communication (comunicação entre processos).
.
Então, o que ele faz é "encaminhar" (em vez de definir) os argumentos para a interface do usuário usando ui::RegisterPathProvider, chamar o tracker e obter o resultado usando content_main_runner->Initialize(std::move(params)), criar um console pai, que eu acho que querem dizer que criam um processo pai, faz mais algumas verificações e então chegamos à parte importante, que é 
.
Aqui vemos uma chamada a uma função chamada IsSubprocess. 
o que ela faz, basicamente, para evitar o código boilerplate antigo, é verificar em uma única função o tipo de processo que recebe na linha de comando e, caso uma opção tenha sido passada, ela escolhe entre as seguintes e cria o respectivo processo.```
return type == switches::kGpuProcess ||
type == switches::kPpapiPluginProcess ||
type == switches::kRendererProcess ||
type == switches::kUtilityProcess || type == switches::kZygoteProcess;
A partir daí chegamos a `content_main_runner->Run()`, que em essência faz toda a mágica. Vamos examiná-lo por baixo dos panos. Então, `content_main_runner` é da classe ContentMainRunner, duhh..., que pode ser encontrada em `content\app\content_main_runner_impl.cc`
Para realmente conseguirmos entender o fluxo de código disso, temos que pegá-lo de baixo para cima. Dito isso, rolamos a página novamente e descobrimos que, na verdade, `ContentMainRunner::Create()` chama `ContentMainRunnerImpl::Create()`; o que nos faz perceber que, na verdade, teremos que procurar pela definição de `ContentMainRunnerImpl`, não de `ContentMainRunner`, que encontramos em `content_main_runner_impl.h` na mesma pasta já mencionada.
Vemos que ela herda de ContentMainRunner e podemos ver seus métodos principais. Realmente não há muita coisa aqui, pois seu comportamento é majoritariamente sobrescrito em `content_main_runner_impl.cc`
Dentro de `content_main_runner_impl.cc`, no método run, ele primeiro faz algumas verificações usando DCHECK (que diabos é essa função? (```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).``` citações dos docs do Google :) )) para ver se is_initialized,content_main_params_,is_shutdown_ estão definidos.
Depois, ele pega os argumentos e determina o tipo que mencionei anteriormente
Então, caso não encontremos isso, chamamos InitializeFieldTrialAndFeatureList() delegate_->PostFieldTrialInitialization(); e o enviamos como mensagem usando mojo.
 .
Em seguida, o que ele faz é definir algumas coisas para a ui
novamente com base no que foi passado na linha de comando, e chama RegisterMainThreadFactories, que é um wrapper para RegisterUtilityMainThreadFactory, que apenas define g_utility_main_thread_factory, que, pelo nome, eu acho que cria a thread principal, que é como a thread que observa as demais threads, e finalmente lança o processo do navegador. 
Caso você não confie em mim, aqui está o Chromium desmontado no Binja, e também veremos um pouco de análise em memória disso.
Para nossa sorte, temos chome.exe.pdb, que nos permite ter símbolos de depuração e não teremos nenhuma dor ao reverter o binário.
Como trabalhamos com o Chrome no Windows, o entry point principal do programa é wWinMain:
Aqui está como o grafo se parece
.
A função em si é enorme e tal, então só mostrarei as partes necessárias dela. Depois de um monte de inicializações, chegamos a um ponto em que ela chama `MakeMainDllLoader()`
, que já explicamos o que ela faz. Certo, então como depuramos o Chrome dinamicamente e provamos tudo o que já mencionei? Primeiro, carregamos ele no windbg e, em seguida, lm e procuramos pelo nome do executável.Depois disso, procuramos por uma função chamada chrome!MakeMainDllLoader, definimos um bp e deixamos a execução seguir.. entramos nela  deixamos ela rodar até atingir ret, saímos dela e chegamos em chrome!wWinMain+0x764 . Então deixamos rodar até chrome!MainDllLoader::Launch e entramos nela. A partir daí, definimos um bp em chrome!MainDllLoader::Load para ver como chrome.dll é carregado na memória. E, como podemos ver, entre as primeiras coisas que foram carregadas estava chrome.dll  A partir daqui, o fluxo da análise é o mesmo, e a análise completa em memória ficará como exercício para o leitor. Para um propósito especial, farei a análise até o ponto em que o processo de conteúdo está quase concluído e, bem antes de o processo do navegador iniciar, pararei ali. O objetivo disso é apenas mostrar como o IPC começa a se comunicar entre si. Agora, após o carregamento da DLL, teremos que procurar por uma instrução call rax. O que fiz foi listar 0x40 instruções a partir do eip atual após carregar a DLL.. nesse endereço, na verdade, está o que procuramos, que é chrome!ChromeMain.
A partir daí, queremos parar em  que é basicamente uma grande verificação antes de pular para content!content::ContentMain. de lá, queremos avançar algumas instruções e atingir content!content::ContentMain. queremos entrar e parar em content!content::RunContentProcess queremos entrar e definir um bp em content!content::ContentMainRunnerImpl::Run+0x430 e, assim que passarmos por ela  vemos o IPC do mojo iniciando e concluímos que o próximo processo, também conhecido como processo do navegador, é responsável pela implementação real do navegador e pelo gerenciamento de todos os outros processos.
===============================================================================================
2.
Da última vez, paramos depois de entender o processo de conteúdo. Hoje vamos para o processo do navegador.
É o processo que inicia após o processo de conteúdo e é o segundo entre os processos iniciados pelo Chrome.
Vamos descrevê-lo brevemente:
* podemos considerá-lo o processo principal, já que o processo de conteúdo é mais uma rotina de inicialização e verificação de dependências, e ele é iniciado pelo processo de conteúdo
* ele permanece vivo durante todo o tempo de vida do navegador.
* Ele é o coordenador central de todos os processos e opera no nível mais alto de privilégio disponível para o navegador.
* como ele roda nos níveis mais altos de privilégio, caso outros processos precisem realizar uma operação de nível mais alto, essa solicitação é tratada pelo processo do navegador.
* Ele controla recursos como a barra de endereços, favoritos e os botões voltar/avançar/recarregar. Como é o processo mais privilegiado, ele não confia nos dados fornecidos por nenhum dos outros processos.
* também lida com operações privilegiadas, como interface do usuário, rede ou armazenamento no sistema de arquivos para os outros processos, quando necessário.
Agora que sabemos brevemente o que ele faz, é hora de nos aprofundarmos mais nele:
Nossa jornada começa em `src\content\app`, em um arquivo chamado content_main_runner_impl.cc, na função int ContentMainRunnerImpl::RunBrowser(MainFunctionParams main_params,bool start_minimal_browser). A primeira operação que ela executa, como vemos, é um TRACE_EVENT_INSTANT0 .
O que é isso? Antes disso, o que é uma função de rastreamento? Bem, se formos até https://lwn.net/Articles/379903/ podemos ver que eles a definem como , fazendo uma pequena abstração, podemos chegar à conclusão de que uma função de rastreamento é uma função que registra dados em um ponto específico de um stack frame. Ela faz mais do que registrar a pilha de execução da função; ela pode registrar variáveis locais da última função executada.Agora que sabemos o que é uma função de rastreamento, vamos ver o que a nossa faz.
Se formos até https://chromium.googlesource.com/chromium/src/base/trace_event/common/+/refs/heads/main/trace_event_common.h veremos que eles a definem como uma função cujo único propósito é "rastrear o desempenho do aplicativo e o uso de recursos". Indo um pouco mais a fundo para entendermos o que ela faz, vemos que é uma macro e está definida como . Podemos ver uma definição curta acima da macro que diz que ela registra um único evento chamado "name" imediatamente, com 0, 1 ou 2 argumentos. E, caso a categoria do evento pertencente não esteja habilitada, ela não faz nada.Podemos ver que, como parâmetros, temos "startup" como categoria principal e, como subsistema, temos "ContentMainRunnerImpl::RunBrowser(begin)"; e o terceiro parâmetro é TRACE_EVENT_SCOPE_THREAD, que é "#define TRACE_EVENT_SCOPE_THREAD (static_cast<unsigned char>(2 << 2))", o que, com base no valor, acho que é um id para o respectivo evento instantâneo. então, em essência, o que isso faz é simplesmente rastrear (registrar) o fato de que entramos com nossa execução na função RunBrowser. Em seguida, temos uma verificação para ver se o loop principal do navegador já foi iniciado e, caso já tenha sido iniciado, saímos da função  . Então definimos um flag e, depois disso, chegamos a uma parte bastante interessante do código. Verificamos se temos suporte ao mecanismo mojo_ipc e, caso tenhamos, usamos ShouldCreateFeatureList, que cria uma lista de recursos com diferentes processos, tenta inicializá-los e, finalmente, tenta inicializar os recursos do mojo.. Então criamos um thread pool. Que diabos é um thread pool???! Citando a Wikipedia: "um padrão de projeto de software para alcançar concorrência de execução em um programa de computador". Explicado de forma mais adequada: "um thread pool mantém várias threads aguardando tarefas a serem alocadas para execução concorrente pelo programa supervisor" (ainda esta citação da Wikipedia). Explicado de forma mais adequada, imagine duas linhas de pessoas trabalhando em uma fábrica. Vamos chamá-las de linha a e linha b. Todas são supervisionadas por um chefe. Vamos chamá-lo de linha c. Agora, a linha b tem que esperar a linha a terminar seu trabalho e ser notificada pela linha c para poder trabalhar. E o mesmo vale para a linha a. E é isso que um thread pool é. Aqui está também um pequeno exemplo em C . Isso foi descaradamente tirado de https://stackoverflow.com/questions/15752659/thread-pooling-in-c11 .Em seguida, temos uma chamada a `PreBrowserMain()`, que faz algumas inicializações específicas da plataforma e, depois disso, chegamos a um ponto em que chamamos `BrowserTaskExecutor::Create()`;
. Vamos mergulhar a fundo no que ela faz, já que o nome é bastante interessante e, confiando em um palpite fundamentado, podemos perceber que isso pode ser interessante. Nosso desvio começa dentro de content/browser/scheduler/browser_task_executor.h, onde descobrimos que BrowserTaskExecutor é uma classe que supostamente "mapeia base::TaskTraits para filas de tarefas reais do processo do navegador". Descendo um pouco mais no arquivo, primeiro  ela herda de BaseBrowserTaskExecutor. Então, agora, para entender o que é BrowserTaskExecutor, precisamos entender BaseBrowserTaskExecutor. Podemos ver que ela herda de TaskExecutor. Felizmente para nós, vemos que ela sobrescreve os métodos de TaskExecutor com propriedade de sobrescrita, o que significa que eles serão sobrescritos por outras chamadas de métodos posteriormente. Mas, apenas para os curiosos, podemos encontrá-la em base/task/task_executor.h e, se a inspecionarmos, descobriremos que TaskExecutor é uma classe que " pode executar Tarefas com um id de extensão TaskTraits específico  .
O que é uma tarefa e o que são TaskTraits? Já mencionamos o que é uma tarefa, mas, para recapitular, é um dos processos do Chrome; e agora, o que são TaskTraits? Elas estão localizadas em base/task/task_traits.h e são definidas da seguinte forma: "encapsulam informações sobre uma tarefa que ajudam o thread pool a tomar melhores decisões de agendamento". Voltando ao nosso BrowserTaskExecutor. O método que chamamos é Create() e sua análise é a seguinte 
Primeiro, ele verifica se a tarefa atual precisa ser executada a partir de um SingleThreadTaskRunner, ou seja, se precisamos executar essa tarefa usando uma thread independente. Fazemos isso obtendo um ponteiro para o TLS. Em seguida, inicializamos uma ui e um agendador de threads. Basicamente, aqui inicializamos um agendador para eventos futuros relacionados à ui..
E é só isso para esse recurso. Continuando com a análise do content_main_runner_impl.cc, chegamos aqui.
Procurando pelo arquivo da classe variations ids provider, nós o encontramos em `components/variations/variations_ids_provider.h`; lá vemos algo bastante interessante. Ele inclui um arquivo `.mojom.h`. Podemos encontrar sua definição em `Debug/gen/components/variations/` variations.mojom.h, o que significa que tinha algo a ver com o mecanismo de IPC. Agora, examinando a definição real da classe, vemos um comentário que a descreve como "uma classe auxiliar para manter o estado de experimentos e métricas do cliente transmitido em cabeçalhos de solicitação HTTP personalizados". Observando seu comportamento e a definição de origem, concluímos que ela é simplesmente usada como um marcador para uma função, que marca que "o parâmetro signed-in fornecido a GetClientDataHeaders()", o que significa que em algum lugar na pilha de execução há uma chamada a GetClientDataHeaders e, mais tarde, ela será chamada com um parâmetro. Em seguida, fazemos `delegate_->PostEarlyInitialization(!!main_params.ui_task);`, que simplesmente envia para o IPC do mojo que ele deve iniciar as tarefas de ui. Fazemos mais inicializações  e então chegamos à chamada de RunBrowserProcessMain.  . Se você esperava, como eu, que é aqui que vemos a GUI começando, você está errado. Uma citação do mestre Oogway . Então seguimos e fazemos mais algumas verificações e chegamos a BrowserMain. analisando-a, ela faz algum rastreamento e então chegamos a que é onde realmente iniciamos a GUI. Agora, caso você não confie em mim, terá que ser um pouco mais paciente até chegarmos à análise dinâmica. Em seguida, chegamos ao método Run, que é o que realmente nos interessa; depois disso, chegaremos ao nosso próximo ponto para entender o processo do navegador. Mas, por enquanto, vamos fazer outro pequeno desvio e investigar como o método Initialize é criado. Logo de cara, vemos que ele rastreia a execução do método init e, antes disso, cria um histograma. Então verificamos o flag initialization_started_ para ver se chegamos ao estágio de inicialização e, caso não tenhamos chegado, inicializamos o Skia, que é a biblioteca gráfica usada pelo Chrome, iniciamos um "timer" para contar os segundos decorridos para executar este método, para uso posterior em um histograma, verificamos se passamos um parâmetro para o binário esperar o depurador anexar ao processo e, finalmente, iniciamos um notification_service_, que, usando um palpite fundamentado, notificará o watcher principal do thread pool de quando iniciar um serviço. . Em seguida, inicializamos as fontes necessárias para o Chrome e criamos o mainbrowserloop, que é o coordenador de todos os processos, e pulamos três métodos que não nos interessam: main_loop_->CreateStartupTasks();
int result_code = main_loop_->GetResultCode(); . A partir daqui, o que nos interessa é entrar em CreateStartupTasks. De lá, olhamos para content\browser\browser_main_loop.cc; estamos interessados em startup_task_runner_->RunAllTasksNow();, que está dentro do método createstartuptask. startup_task_runner_ é um StartupTaskRunner, que está localizado no mesmo diretório, dentro do arquivo startup_task_runner.cc. Agora, se inspecionarmos o método RunAllTasksNow, vemos que o que ele faz é simplesmente iterar sobre todas as tarefas e executá-las
==========================================================================================
Hora de um pouco de análise dinâmicaAgora, para apanhar o renderer, teremos de iniciar o binário no windbg. Isso é simplesmente alcançável fazendo File->Open Executable e passando --renderer-startup-dialog --no-sandbox --wait-for-debugger-children=renderer --renderer-process-limit=1 como argumentos.. Definimos então um bp em content!content::StartupTaskRunner::RunAllTasksNow+0x88 para podermos apanhar as mensagens ipc e mais tarde o renderer. Apenas como ponto de referência, é assim que o seu dbg deve ficar depois de o executar uma vez  . Deve ver a mensagem "chrome is running in full browser mode". A partir daí, conta de um a 5 para o executares mais quatro vezes. E então deves ver algo como . Recomendo usar o procmon para poderes monitorizar o processo do renderer quando ele inicia. Depois disso, ligas-lo a outro debugger e, caso tenhas usado os argumentos acima, deves ver uma caixa de mensagem a aparecer indicando o pid do renderer. A partir daí, vais querer definir um bp em base!base::RunLoop::Run. Infelizmente, não se consegue interromper em content!content::RendererMain por alguma razão. Talvez porque ligamos o processo logo após ele sair da função renderemain e é executado por uma thread. Independentemente disso, aqui está como o ipc fica após quatro execuções.. Isto indica que a gui foi iniciada. E aqui está como o ipc fica depois de o processo renderer iniciar.. Definimos então um bp em
content!content::StartupTaskRunner::RunAllTasksNow+0x88 e content!content::RunOtherNamedProcessTypeMain. Deixamos correr
============================================================================================================
3. Agora, para a segunda parte da análise do processo do browser, chegámos ao ponto em que seremos capazes de entender e depurar o renderer, mas ainda não vamos por aí. Deixei deliberadamente mais uma função para analisar depois de RunBrowserProcessMain; bem, teoricamente é depois de RunBrowser, mas como deves lembrar-te, RunBrowser é um wrapper para RunBrowserProcessMain. O que deixei de fora é que no ficheiro chamado content_main_runner_impl.cc na pasta src/content/app existe outra função que é chamada depois de spawnarmos o renderer e chama-se RunOtherNamedProcessTypeMain. Este processo é responsável por executar todos os outros processos.. Agora vamos perceber o que acontece no código. Vemos que o seu protótipo é , o que indica que recebe os argumentos passados à cmdline, o tipo de processo esperado e um chrome delegate. Chegamos então ao início da função onde temos uma definição de macro para verificar especificidades da plataforma e verificar para qual processo instanciar um event handler, ou seja, verificar se executa algumas funções para o processo de consola ou para o processo do browser. . Iteramos então sobre os processos passados e comparamo-los com uma lista de processos conhecidos e executamos o processo respetivo. . Caso não obtenhamos o processo respetivo, então é um processo personalizado implementado por alguém
Aqui está um link para implementar processos personalizados e usaremos este exemplo para a segunda parte da análise dinâmica. https://bitbucket.org/chromiumembedded/cef/wiki/Tutorial .
=====================================================================
Parte de Análise Dinâmica
A primeira parte da análise dinâmica começa da seguinte forma: primeiro executa a partir de um cmd.exe com direitos de administrador o seguinte comando: 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 . Depois disso define .childdbg 1 para podermos depurar novos processos filhos criados. Em essência, o que o comando acima faz é "garantir que estás ligado a todos os processos filhos". Um agradecimento vai para @spoofyroot e @_coreDump por me apontarem na direção certa com a depuração multiprocesso. Aqui está como deve ficar depois de definir .childdbg 1 . Como não consegui capturar de nenhuma outra forma o que acontece a seguir, fiz um vídeo onde explico o que se segue. https://streamable.com/9t4iof . Basicamente, depois de executarmos pela última vez content!content::StartupTaskRunner::RunAllTasksNow+0x88, spawnamos novos processos que tratam de algumas coisas de ipc e teremos de continuar a definir um bp em content!content::RunContentProcess até ele o atingir. É a isto que chamo tentativa e erro educada:)) .
=====================================================================
4. Análise do Renderer
!Aviso
Embora façamos a análise do código do Renderer, vamos também mergulhar um pouco no código do blink para percebermos o que acontece corretamente no renderer
Enquanto escrevia esta parte do curso, percebi que me esqueci de descrever brevemente o que isto faz e porque sequer olhamos para isto. Como sabemos, este é o terceiro processo iniciado pelo chromium e chama-se renderer. Mas porque se chama "renderer"? Chama-se assim porque o seu trabalho é renderizar(desenhar) tudo o que vemos num site. Basicamente, é esta a razão pela qual a tua tabela parece uma tabela quando navegas num site, ou o teu css torna possível personalizar um pedaço de texto. Ou porque o teu js é capaz de fazer magia negra*. Outra razão importante pela qual analisamos isto é porque é daqui que vem a maioria dos bugs. Quer falemos de html, css, js ou qualquer outro componente, vê-los-ás todos sob blink em chrome bugs.chromium.org
* Existem mais processos renderer. Um processo totalmente separado para cada separador que o browser tem atualmente aberto.
* Este processo controla tudo o que está dentro do separador do site propriamente dito
* a partir de 2018, o iframe recebeu uma atualização onde todos podem ter separadores. E assim, cada separador de um iframe tem um processo renderer individual. Isto chama-se Site-Isolation
* A sua responsabilidade é analisar um site, desenhar no teu ecrã o que o site contém, ex. tabelas, imagens, executar javascript
* está isolado (sandboxed)
* no núcleo, usa um motor de renderização chamado Blink.
* cria e trata esquemas de url tais como: chrome://, devtools://, chrome-error://
* Inicializa o motor Blink que fará de facto toda a análise e o trabalho pesado para o processo renderer.
Da última vez que ficámos, terminámos a análise do processo do browser e agora chegou o momento que todos esperávamos para fazer a parte da análise do renderer. Certo, quando andava a brincar com o chromium, consegui fazer com que ele crashasse e obtive o seguinte stack trace. . Com base nisto, sabemos que a nossa jornada começa em content::RendererMain, que está localizado em `\content\renderer\renderer_main.cc`. Adivinhas-te, o ponto de partida é RendererMain. Vamos começar por analisar como está definido e um pouco do seu interior . Podemos ver que aceita um parâmetro do tipo MainFunctionParams, o que significa que esta função aceitará os argumentos passados ao binário. A seguir, adicionamos um trace point para sabermos que chegámos à chamada de RendererMain, e depois desreferenciamos o valor de parameters e guardamo-lo em command_line. Depois temos algumas macros que verificam a arquitetura específica da plataforma, que podemos ignorar , verificamos o valor passado para kTimeZoneForTesting, que é um fuso horário a usar para testes, e depois encontramos uma nova classe e tipo de dados chamado icu.
Agora, ao procurar qualquer fonte de definição para isso, chegamos a https://unicode-org.github.io/icu-docs . Se olharmos para o início do ficheiro onde está a diretiva include, vemos que é uma biblioteca de terceiros. Portanto, até agora sabemos que é uma biblioteca de terceiros que lida com componentes internacionais para unicode, ou seja, usamo-la para suporte a unicode. Ok, mas o que faz essa função? Indo a https://unicode-org.github.io/icu-docs vemos , ou seja, define o fuso horário padrão com base no que definimos como parâmetros. Depois inicializamos a biblioteca skia e tratamos de --renderer-startup-dialog
. Somos então apresentados a uma nova classe, RendererMainPlatformDelegate.
O que isto faz? Bem, primeiro temos de especificar que é uma classe abstrata específica da plataforma. No nosso caso, estará localizada em /content/renderer dentro do ficheiro chamado renderer_main_platform_delegate_win.cc . Tem este aspeto
. Então podemos concluir que tudo isto é uma função auxiliar que ativa a sandbox caso passemos --no-sandbox, faz as ações necessárias e é só isso. Depois definimos o nome da nossa thread para CrRendererMain. Depois encontramos mais uma nova classe chamada RenderThread. 
De novo, como basicamente não sabemos o que faz, vamos explorá-lo um pouco. A nossa busca para perceber como o RendererThread se parece começa em content/public/renderer/render_thread.h. Olhando para dentro do ficheiro render_thread.h, vemos que está definido como . De todo aquele ficheiro, estamos interessados em IsMainThread, que está definida no ficheiro rendere_thread.cc e tem este aspeto  (adiciona uma longa descrição sobre este mecanismo). Agora, continuando com a análise do código do rendere, podemos ver o momento mais aguardado: finalmente chegamos a ver algum código do blink. O primeiro do género e o que faz é inicializar a biblioteca.. Nos bastidores, a função tem este aspeto . Agora a pergunta natural que surge é: que raios são essas classes? O que é WTF e Platform. Felizmente, a documentação do blink diz-nos o que são.
https://docs.google.com/document/d/1aitSOucL0VHZa9Z2vbRJSyAIsAz24kX8LFByQ5xQnUg/edit . Olhando para "Directory structure and dependencies", podemos deduzir que platform é uma classe que ajuda com geometria e gráficos. Agora sobre as classes WTF e Partitions. A documentação do blink também diz sobre WTF: vem de Web Template Framework e é basicamente um "wrapper" da biblioteca stl, como em "é uma biblioteca base para o Blink que fornece uma variedade de funcionalidades básicas, como contentores, bibliotecas de strings, mecanismos de contagem de referências, functores, primitivas de threading, etc."(citações dos docs do blink(https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/blink/renderer/platform/wtf/README.md)). Adiciona mais detalhes sobre o blink
Ok, continuando com a análise de renderer_main.cc, vemos algo novamente que não sabemos o que faz e é . Adiciona detalhes amanhã. Chamamos então . Verificamos então se ativámos plugin na compilação e, caso tenhamos ativado, carregamo-los.
. Fazemos então mais algumas verificações que decidi não explicar porque se estaria a tornar uma explicação bastante longa e não são necessárias nesta fase. Mas numa versão TL;DR é para saber se se deve ativar ou não a sandbox antes da inicialização do RenderProcess. E então finalmente chegamos a .(adiciona o resto dos detalhes sobre o resto das funções). Embora este não seja o fim da análise do renderer, podemos considerá-lo o ponto de partida da análise real do rendere, porque, como veremos mais tarde, aqui acontece a maioria das coisas interessantes, por isso podemos considerá-lo como o código do renderer. Estamos interessados em RenderThreadImpl, que tem este aspeto . De todo esse código, estamos interessados na função Init(), que tem este aspeto:
, mas é muito mais longa. :) Infelizmente, não a conseguimos capturar numa única imagem e, por isso, capturámos o seu início. Além disso, tudo o resto que acontece a partir de InitializeWebKit() não é realmente do nosso interesse, pois na sua maioria é apenas comunicação ipc com o processo gpu, que não está no nosso radar neste momento. A sorte sorri-nos, porque nessa função apanhámos também uma das funções que nos interessam, precisamente InitializeWebKit(), que novamente tem este aspeto . Divagamos um pouco da nossa missão de explicar renderer_main.cc para melhor compreender o que acontece dentro de InitializeWebKit. Agora, sei que é muito para entender, mas tenham paciência comigo enquanto tentamos dar algum sentido a esta confusão. Então vemos que InitializeWebKit() começa por receber quaisquer argumentos passados a este processo; depois verificamos se ativámos -dENABLE_VTUNE_JIT_INTERFACE na compilação e, caso tenhamos ativado, verificamos a opção passada à cmdline chamada enable-vtune-support. O que raios é isso? Pesquisámos no google e encontrámos um link para https://www.intel.com/content/www/us/en/develop/documentation/vtune-help/top.html e nessa página diz que é: "is a performance analysis tool for serial and multithreaded applications". Então, tl;dr é algo que melhora o desempenho do teu chrome. Depois inicializamos o blink . Agora, para perceber o processo de inicialização do blink, vamos explicar brevemente, já que entraremos em detalhe no próximo capítulo, que analisará o blink em profundidade. Somos recebidos por outra classe que nos é estranha, RendererBlinkPlatformImpl, que tem este aspeto
 e pode ser encontrada em
content/renderer/renderer_blink_platform_impl.cc . Com base no nome, podemos concluir que é uma classe abstrata implementada consoante a plataforma e também podemos ver que herda de  Analisando o que RendererBlinkPlatformImpl realmente faz, vemos que verifica a plataforma e, com base nos resultados da verificação, marca uma flag, depois verifica se a thread atual é uma RendererThread ao obter um ponteiro para o tls
blá blá blá vê se adicionas mais conteúdo sobre as classes. Chegamos então a algo que todos talvez estivéssemos à espera e é o primeiro pedaço de código v8. Que é . O que isto faz? Primeiro, sabemos pela documentação que um v8::isolate é uma instância do motor V8, ou seja (uma cópia independente do runtime V8, incluindo um gestor de heap, um garbage collector, etc.) não suficiente para executar scripts. Vemos blink::MainThreadIsolate() definido como
 que está no ficheiro blink/renderer/platform/bindings/v8_per_isolate_data.cc , que por sua vez V8PerIsolateData::MainThreadIsolate() tem este aspeto
 , V8PerIsolateData que, como adivinhas, também é uma
classe que se encontra em bindings/core/v8/V8PerIsolateData.h e tem aproximadamente este aspeto blá blá blá adiciona detalhes. Verificamos então se passámos kDisableThreadedCompositing(adiciona amanhã como é que a flag se parece de facto)para a linha de comandos. Caso não tenhamos passado, iniciamos uma thread de compositor. O que raios é isso? Citando https://frontendmasters.com/courses/web-performance/the-compositor-thread/ , é uma thread cujo "único trabalho é desenhar bitmaps, pegar nos bitmaps, enviá-los para a GPU, colocá-los no ecrã". Registamos então o que se chama um scheme.. Basicamente, lembras-te de quando vês o código-fonte e tens algo antes do url como: "view-source:website" . Sim, isso é tratado pelo renderer. E há mais destes schemes. O que querem dizer com registar? Ainda não tenho a certeza, mas acho que querem dizer: "ei, isto é algo que quero que trates quando o utilizador vier e fizer esta coisa". De qualquer forma, é assim que se parece.. adiciona mais detalhes. bom, agora quando adicionares, detalha também a última peça de código 
. balh balsdld e finalmente chegámos à parte final de renderer_main atualiza com detalhes
=====================================================================
Parte de Análise DinâmicaAgora, para depurá-lo dinamicamente, caso você seja tão noob quanto eu, você vai querer executar o windbg a partir do cmd.exe da seguinte forma 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", e defina .childdbg 1 para conseguir depurar o processo filho gerado. A partir daí, você vai querer usar o comando bp content!content::RendererMain e deixá-lo rodar por umas 5 ou 6 vezes. (modifique e faça referência ao 4 no vídeo, porque assim fica mais claro) depois disso chegamos a .
std::unique_ptr<>
crashes.InstallDetails::Get().VersionMismatch()
/src/content/app/content_main.cc