spiralbl0ck/browser-pwning-Una documentazione ben strutturata per iniziare con il pwning di Chrome e il pwning di V8.
Una documentazione adeguata e ben strutturata per iniziare con il chrome pwning & il v8 pwning
Come è organizzato questo documento
I browser sono una delle tecnologie più utilizzate oggi. Su ogni computer standard, se facciamo plug and play vedremo un browser installato. Ecco perché, dalla prospettiva di un attaccante e di un modello di minaccia, è molto gratificante se l'attaccante riesce a compromettere il browser tramite una pagina dannosa. Dati gli argomenti precedenti, ho scelto di studiare il motore JavaScript di Google, in particolare v8.
Data la natura gigantesca del progetto v8, ho scelto come punto di partenza l'interprete, cioè d8. Sebbene su d8 sia già stata fatta una ricerca approfondita, speriamo di trovare almeno un bug e, in caso contrario, di poter andare avanti con la ricerca sullo sfruttamento dei browser, poiché v8 fornisce il terreno di ingresso per le strategie di base dello sviluppo di exploit utilizzate nell'esploitazione dei browser.
Un altro motivo per cui ho scelto v8 come bersaglio è che è usato su più browser.
Se guardiamo sotto il cofano, possiamo vedere che il motore è usato anche in MicrosoftEdge, quindi c'è la possibilità di multipli premi bug bounty. Per quanto riguarda il sistema operativo sottostante, il ricercatore userà un mix di Windows e Linux, poiché non ci sono restrizioni in termini di ottenimento di una shell, dato che i bug di v8 consentono l'esecuzione di codice tramite pagine wasm e non sono legati a una piattaforma specifica.
Purtroppo, anche se un bug sfruttato in v8 comporterebbe l'esecuzione di codice, non saremo in grado di eseguire alcun codice a causa della sandbox, e pertanto otterremmo l'esecuzione di codice nel contesto del renderer, il che non ci permetterebbe di eseguire codice sulla macchina. Per quello avremmo bisogno di un altro exploit per la sandbox, quindi avremmo bisogno di una full chain per compromettere il sistema.
E quindi definiamo i seguenti obiettivi per poter iniziare con il browser hacking
Nella prima fase del progetto è necessario raccogliere quante più conoscenze possibili riguardo all'architettura di Chrome e a come ogni componente interagisce con gli altri. Per capire meglio questo, dobbiamo suddividere il Progetto Chromium in più sottocomponenti in modo da poter isolare tutto e analizzarlo correttamente. Più precisamente, in quanti sottocomponenti si suddivide ciascuno dei seguenti componenti
Ora, il passo più logico per un primo passo è capire l'architettura di Chromium. Ok, quindi vogliamo sfruttare il browser, ma cosa succede quando avviamo il browser? Beh, dopo aver fatto clic sull'eseguibile di Chromium, l'eseguibile avvia alcuni processi.
L'ordine e i loro nomi sono i seguenti:
Il primo si chiama content process. Cosa fa questo processo?
Ora che sappiamo brevemente cosa fa, è il momento di approfondire:
Quindi, il modo in cui Chromium funziona, almeno su Windows, è che compila i file in una dll e poi la carica in memoria. Quindi la logica principale del browser Chromium è in chromium.dll.
Questo è confermato anche dal codice
.
Questo è tratto da chrome_exe_main_win.cc e se sei curioso di leggere tutto il codice si trova in chromium/src/chrome/app . Ok, proseguendo con l'esecuzione possiamo vedere che chiama MakeMainDllLoader() per chiamare la classe che carica la dll; dopo di che lancia il "loader", cioè carica la chrome.dll e, se necessario, la riavvia con le necessarie righe di comando. Per analizzare ulteriormente il Loader dobbiamo capire il suo codice, che si trova nella stessa directory, nel file mail_dll_loader_win.cc. Scorrendo fino in fondo al file possiamo vedere la chiamata a MakeMainDllLoader che a sua volta chiama, in base alla versione che hai, ChromeDllLoader o ChromiumDllLoader.
Possiamo vedere che ChromiumDllLoader è una classe che eredita da . Dalla definizione possiamo vedere che la classe semplicemente carica la dll in base agli argomenti passati alla riga di comando e al tipo di processo
.
Analizzando il metodo Launch possiamo capire alcune cose che accadono prima che chrome.dll parta: possiamo capire da questo commento che "// Launching is a matter of loading the right dll and calling the entry point. // Derived classes can add custom code in the OnBeforeLaunch callback." lanciare chrome è una questione di caricare un mucchio di dll che fanno effettivamente il lavoro. In secondo luogo, prende gli argomenti passati alla riga di comando e inizializza i servizi sandbox.
.
Prima controlla se è il browser a chiamare l'inizializzazione della sandbox, poi controlla se il processo che ha chiamato l'inizializzazione della sandbox è stato avviato come servizio di cloud print. Controlla anche se è stato passato al binario, il che dice fondamentalmente al binario di non girare in una sandbox. Controlla se uno qualsiasi di questi era impostato e, se uno dei due è vero, chiama la sandbox con le rispettive opzioni. Poi alla fine arriviamo a
che è ciò che ci interessa, questo rappresenta il wrapper per chiamare .
tracciando una fase del ciclo di vita di un processo che è definita come```
// 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 appena possibile quando un processo esce, salva le informazioni relative al modulo, cioè quando un modulo (ovvero un componente di Chromium) viene caricato, e fondamentalmente la stessa funzionalità si ripete ma diversa per thread e classi differenti. Nel caso fossi interessato, puoi trovarlo in chromium/src/base/debug/activity_tracker.h
Successivamente controlla se "Main()" è stata chiamata prima. Qui penso intendano se ChromeMain() è stata chiamata prima. Controllano sostanzialmente se al processo content sono stati passati degli argomenti. E nel caso lo sia stato, si assicurano che il processo browser riceva gli stessi argomenti. Poi controllano le specifiche di piattaforma e, nel caso venga rilevato Windows, inizializzano il proprio handler chiamando CreateATLModuleIfNeeded; poi è la stessa storia: controllano le specifiche di piattaforma e passano gli argomenti usando SetupCRT e arriviamo alla parte in cui inizializziamo l'IPC per poter parlare con gli altri processi dopo averli generati. Ecco il codice responsabile di questo. Non entreremo nei dettagli, perché torneremo più avanti a discutere più a fondo del meccanismo IPC di Chrome. Per ora sappi solo che questo è il meccanismo che facilita la comunicazione tra i processi multi-architettura di Chrome. E nel caso non sapessi cosa significa IPC, sta per inter-process communication.
.
Poi quello che fa è "inoltrare" più che impostare gli argomenti per la UI usando ui::RegisterPathProvider, chiama il tracker e ottiene il risultato usando content_main_runner->Initialize(std::move(params)), crea una console padre, che suppongo voglia dire che creano un processo padre, fa qualche altro controllo e poi arriviamo alla parte importante, cioè 
.
Qui vediamo una chiamata a una funzione chiamata IsSubprocess. 
In pratica, per evitare il vecchio codice boilerplate, controlla in un'unica funzione il tipo di processo che riceve dalla riga di comando e, nel caso sia stata passata un'opzione, sceglie tra i seguenti e crea il processo corrispondente.```
return type == switches::kGpuProcess ||
type == switches::kPpapiPluginProcess ||
type == switches::kRendererProcess ||
type == switches::kUtilityProcess || type == switches::kZygoteProcess;
Da lì arriviamo a content_main_runner->Run(); che in sostanza fa tutta la magia. Esaminiamolo sotto il cofano. Quindi content_main_runner è della classe ContentMainRunner, ovviamente.. che si trova in `content\app\content_main_runner_impl.cc`
Per riuscire davvero a capire il flusso del codice dobbiamo leggerlo dal basso verso l'alto. Detto questo, scorriamo di nuovo verso il basso e scopriamo che in realtà `ContentMainRunner::Create()` chiama `ContentMainRunnerImpl::Create()`; il che ci fa capire che dovremo cercare la definizione di ContentMainRunnerImpl e non quella di ContentMainRunner, che troviamo in `content_main_runner_impl.h` nella stessa cartella già menzionata.
Vediamo che eredita da ContentMainRunner e che possiamo vederne i metodi principali. In realtà non c'è molto qui, dato che il suo comportamento è per lo più sovrascritto in `content_main_runner_impl.cc`
Dentro `content_main_runner_impl.cc`, nel metodo run, prima fa alcuni controlli usando DCHECK (che diavolo è questa funzione? (```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).``` citazioni dai documenti Google :)) per verificare che is_initialized, content_main_params_, is_shutdown_ siano impostati.
Successivamente ottiene gli argomenti e determina il tipo di cui ho parlato prima
Poi, nel caso non riusciamo a trovarlo, chiamiamo InitializeFieldTrialAndFeatureList() e delegate_->PostFieldTrialInitialization(); e lo inviamo come messaggio usando mojo.
 .
La cosa successiva che fa è impostare alcune cose per la ui
di nuovo in base a ciò che è stato passato dalla riga di comando, e chiama RegisterMainThreadFactories, che è un wrapper per RegisterUtilityMainThreadFactory, che imposta solo g_utility_main_thread_factory che, dal nome, penso crei il thread principale, cioè il thread che fa da osservatore per tutti gli altri thread, e infine lancia il processo del browser. 
Nel caso non ti fidi di me, ecco chromium disassemblato in binja e vedremo anche un po' di analisi in memoria di questo.
Fortuna nostra, abbiamo chome.exe.pdb che ci permette di avere i simboli di debug e non avremo alcuna difficoltà nel fare reverse engineering del binario.
Dato che lavoriamo con chrome su Windows, il punto di ingresso principale del programma è wWinMain:
Ecco come appare il grafo
.
La funzione in sé è enorme e quindi mostrerò solo le parti necessarie. Dopo una serie di inizializzazioni arriviamo a un punto in cui chiama `MakeMainDllLoader()`
, di cui abbiamo già spiegato cosa fa. Giusto, quindi come facciamo a fare debug dinamico di chrome e dimostrare tutto ciò che ho già menzionato? Prima lo carichiamo in windbg, poi usiamo lm e cerchiamo il nome dell'eseguibile. Dopodiché cerchiamo una funzione chiamata chrome!MakeMainDllLoader, impostiamo un breakpoint e lasciamo proseguire l'esecuzione.. Entriamo al suo interno , la lasciamo girare finché non raggiunge ret, e usciamo finendo in chrome!wWinMain+0x764 . Poi la lasciamo girare fino a chrome!MainDllLoader::Launch e ci entriamo dentro. Da lì mettiamo un breakpoint su chrome!MainDllLoader::Load per vedere come chrome.dll viene caricata in memoria. E come possiamo vedere, tra le prime cose caricate c'è chrome.dll . Da qui il flusso dell'analisi è lo stesso e l'analisi completa in memoria sarà lasciata come esercizio al lettore. Per uno scopo speciale farò l'analisi fino al punto in cui il content process è quasi completo e mi fermerò subito prima dell'avvio del browser process. Lo scopo è solo mostrare come l'IPC inizia a comunicare tra i processi. Dopo il caricamento della dll, dobbiamo cercare un'istruzione call rax. Quello che ho fatto è stato elencare 0x40 istruzioni a partire dall'eip corrente dopo il caricamento della dll.. A quell'indirizzo c'è in realtà ciò che stiamo cercando, cioè chrome!ChromeMain.
Da lì vogliamo fermarci su  che è fondamentalmente un grosso controllo prima di saltare in content!content::ContentMain. Da lì vogliamo superare qualche istruzione e raggiungere content!content::ContentMain. Vogliamo entrare e fermarci su content!content::RunContentProcess, vogliamo entrare e impostare un breakpoint su content!content::ContentMainRunnerImpl::Run+0x430 e appena superiamo  vediamo partire mojo ipc e concludiamo che il processo successivo, cioè il browser process, è responsabile dell'implementazione effettiva del browser e della gestione di tutti gli altri processi.
===============================================================================================
2.
La volta scorsa ci eravamo fermati dopo aver capito il content process. oggi andremo sul browser process
è il processo che viene avviato dopo il content process ed è il secondo nei processi avviati da chrome.
Descriviamolo brevemente:
* possiamo considerarlo il processo principale, dato che il content process è più una routine di inizializzazione con qualche controllo delle dipendenze, ed è avviato dal content process
* rimane in vita per l'intera durata del browser.
* È il coordinatore centrale di tutti i processi e opera al più alto livello di privilegio disponibile per il browser.
* poiché gira al più alto livello di privilegio, se altri processi devono eseguire un'operazione di livello superiore, la richiesta viene gestita dal browser process.
* Controlla funzionalità come la barra degli indirizzi, i segnalibri e i pulsanti indietro/avanti/ricarica. Dato che è il processo con più privilegi, non si fida dei dati che riceve dagli altri processi.
* gestisce anche operazioni privilegiate come UI, rete o storage del filesystem per gli altri processi quando necessario.
Ora che sappiamo brevemente cosa fa, è il momento di approfondire:
Il nostro viaggio inizia in `src\content\app` in un file chiamato content_main_runner_impl.cc, alla funzione int ContentMainRunnerImpl::RunBrowser(MainFunctionParams main_params,bool start_minimal_browser). La prima operazione che esegue è una TRACE_EVENT_INSTANT0 .
Cos'è? Prima di tutto, cos'è una trace function? Beh, se andiamo su https://lwn.net/Articles/379903/ possiamo vedere che la definiscono come , facendo un po' di astrazione possiamo concludere che una trace function è una funzione che registra dati in un punto specifico di uno stackframe. Non si limita a registrare lo stack di esecuzione della funzione, ma può registrare anche le variabili locali dell'ultima funzione eseguita. Ora che sappiamo cos'è una trace function, vediamo cosa fa la nostra.
Se andiamo su https://chromium.googlesource.com/chromium/src/base/trace_event/common/+/refs/heads/main/trace_event_common.h vediamo che la definiscono come una funzione il cui unico scopo è "tracking application performance and resource usage". Andando un po' più a fondo per capire cosa fa, vediamo che è una macro ed è definita come . Possiamo vedere una breve definizione sopra la macro che dice che registra un singolo evento chiamato "name" immediatamente, con 0, 1 o 2 argomenti. E nel caso la categoria dell'evento non sia abilitata, non fa nulla. Possiamo vedere che come parametri abbiamo "startup" come categoria principale e come sottosistema abbiamo "ContentMainRunnerImpl::RunBrowser(begin)" e il terzo parametro è TRACE_EVENT_SCOPE_THREAD che è "#define TRACE_EVENT_SCOPE_THREAD (static_cast<unsigned char>(2 << 2))" che, penso in base al valore, sia un id per il rispettivo evento istantaneo. Quindi in sostanza ciò che fa è semplicemente tracciare (loggare) il fatto che siamo entrati con la nostra esecuzione nella funzione RunBrowser. Poi abbiamo un controllo per vedere se il main loop del browser è già partito e nel caso sia già partito usciamo dalla funzione  . Poi impostiamo un flag e dopo di che arriviamo a una parte piuttosto interessante del codice. Controlliamo se abbiamo supporto per il meccanismo mojo_ipc e in tal caso usiamo ShouldCreateFeatureList che crea una feature list, prova a inizializzare i vari processi e infine cerca di inizializzare le funzionalità di mojo.. Poi creiamo un threadpool. Ma che cavolo è un threadpool??! Citando da wikipedia: "a software design pattern for achieving concurrency of execution in a computer program". Spiegato in modo più corretto "a thread pool maintains multiple threads waiting for tasks to be allocated for concurrent execution by the supervising program" (anche questa è una citazione da wikipedia"). Spiegato ancora meglio, immagina due linee di persone che lavorano in una fabbrica. Chiamiamole linea a e linea b. Sono tutte supervisionate da un capo. Chiamiamolo linea c. La linea b deve aspettare che la linea a finisca il proprio lavoro ed essere avvisata dalla linea c per poter lavorare. E lo stesso vale per la linea a. E questo è un threadpool. Ecco anche un piccolo esempio in c . È preso spudoratamente da https://stackoverflow.com/questions/15752659/thread-pooling-in-c11 .Poi abbiamo una chiamata a PreBrowserMain(); che fa alcune inizializzazioni specifiche della piattaforma e dopo di che arriviamo a un punto in cui chiamiamo `BrowserTaskExecutor::Create()`;
. Facciamo un tuffo profondo in ciò che fa, dato che il nome è piuttosto interessante e basandoci su un'ipotesi ragionevole possiamo renderci conto che potrebbe essere interessante. La nostra deviazione inizia dentro content/browser/scheduler/browser_task_executor.h dove scopriamo che BrowserTaskExecutor è una classe che dovrebbe "to map base::TaskTraits to actual task queues for the browser process". Andando un po' più avanti nel file, prima di tutto  eredita da BaseBrowserTaskExecutor. Quindi ora, per capire cos'è BrowserTaskExecutor, dobbiamo capire BaseBrowserTaskExecutor. Possiamo vedere che eredita da TaskExecutor. Fortunatamente per noi, vediamo che sovrascrive i metodi di TaskExecutor con proprietà sovrascrivibili, il che significa che verranno sovrascritti da altre chiamate a metodi in seguito. Ma solo per i curiosi là fuori, possiamo trovarlo in base/task/task_executor.h e se lo ispezioniamo possiamo scoprire che TaskExecutor è una classe che " can execute Tasks with a specific TaskTraits extension id  .
Cosa sono un task e i tasktraits. Abbiamo già menzionato cos'è un task, ma per rinfrescare: è uno dei processi di chrome, e ora cosa sono i TaskTraits? Si trovano in base/task/task_traits.h e sono definiti come segue "encapsulate information about a task that helps the thread pool make better scheduling decisions." Tornando al nostro BrowserTaskExecutor. Il metodo che chiamiamo è Create() e la sua analisi è la seguente 
prima controlla se il task corrente deve essere eseguito da un SingleThreadTaskRunner. cioè se dobbiamo eseguire questo task usando un thread indipendente. Lo facciamo ottenendo un puntatore al tls. Poi inizializziamo una ui e uno scheduler di thread. In pratica qui inizializziamo uno scheduler per eventi futuri relativi alla ui..
E questo è tutto per quella funzionalità. Proseguendo con l'analisi di content_main_runner_impl.cc arriviamo qui.
cercando il file della classe variations ids provider lo troviamo in `components/variations/variations_ids_provider.h`, e lì vediamo qualcosa di piuttosto interessante. include un file `.mojom.h`. Possiamo trovare la sua definizione in `Debug/gen/components/variations/` variations.mojom.h , il che significa che ha a che fare con il meccanismo ipc. Ora andando sulla definizione effettiva della classe vediamo un commento che la descrive come "A helper class for maintaining client experiments and metrics state transmitted in custom HTTP request headers." guardando il suo comportamento e la definizione del sorgente concludiamo che è semplicemente usato come marcatore per una funzione, che segnala che "signed-in parameter supplied to GetClientDataHeaders()", il che significa che da qualche parte nello stack di esecuzione c'è una chiamata a GetClientDataHeaders e successivamente verrà chiamata con un parametro. Poi facciamo delegate_->PostEarlyInitialization(!!main_params.ui_task); che semplicemente invia all'ipc di mojo il fatto che deve avviare i task della ui. facciamo altre inizializzazioni  e poi arriviamo a chiamare RunBrowserProcessMain.  . Se speravi come me che fosse qui che vediamo partire la gui, ti sbagli. Una citazione di maestro oogwgay . Poi andiamo avanti e facciamo altri controlli e arriviamo a BrowserMain. esaminandolo vediamo che fa un po' di tracing e poi arriviamo a che è il punto in cui avviamo davvero la gui. Ora, nel caso non ti fidi di me, dovrai avere un po' più di pazienza finché non arriviamo all'analisi dinamica. Poi arriviamo al metodo Run, che è la parte che ci interessa, e successivamente arriveremo al nostro prossimo punto per capire il browser process. Ma per ora facciamo un'altra breve deviazione e indaghiamo su come viene creato il metodo Initialize. Subito vediamo che traccia l'esecuzione del metodo init e prima ancora crea un istogramma. Poi controlliamo il flag initialization_started_ per vedere se siamo arrivati alla fase di inizializzazione e in caso contrario inizializziamo skia, che è la libreria grafica usata da chrome, avviamo un "timer" per contare i secondi trascorsi per eseguire questo metodo per usarli successivamente in un istogramma, controlliamo se abbiamo passato un parametro al binario per aspettare che il debugger si attacchi al processo e infine avviamo un notification_service_ che, usando un'ipotesi ragionevole, notificherà al watcher principale del threadpool quando avviare un servizio. . Poi inizializziamo i font necessari per chrome e creiamo il mainbrowserloop, che è il coordinatore di tutti i processi, e saltiamo tre metodi che non presentano alcun interesse per noi main_loop_->CreateStartupTasks();
int result_code = main_loop_->GetResultCode(); . Da qui ciò che ci interessa è entrare in CreateStartupTasks. Da lì guardiamo content\browser\browser_main_loop.cc, e siamo interessati a startup_task_runner_->RunAllTasksNow(); che si trova dentro il metodo createstartuptask. starup_task_runner_ è uno StartupTaskRunner che si trova nella stessa directory dentro il file startup_task_runner.cc. Ora se ispezioniamo il metodo RunAllTasksNow vediamo che ciò che fa è semplicemente iterare su tutti i task ed eseguirli
==========================================================================================
Tempo per un po' di analisi dinamicaOra, per catturare il renderer, dovremo avviare il binario in windbg. Questo è semplicemente ottenibile facendo File->Open Executable e passando --renderer-startup-dialog --no-sandbox --wait-for-debugger-children=renderer --renderer-process-limit=1 come argomenti.. Impostiamo quindi un bp a content!content::StartupTaskRunner::RunAllTasksNow+0x88 così possiamo catturare i messaggi ipc e successivamente il renderer. Solo come riferimento, ecco come dovrebbe apparire il tuo dbg dopo averlo eseguito una volta  . Dovresti vedere il messaggio "chrome is running in full browser mode". Da lì conti da uno a cinque, quindi lo esegui altre quattro volte. E poi dovresti vedere qualcosa come . Raccomando di usare procmon per monitorare il processo renderer quando si avvia. Dopo di che lo agganci a un altro debugger e, nel caso tu abbia usato gli argomenti precedenti, dovresti vedere un messaggio popup che ti indica il pid del renderer. Da lì vorrai impostare un bp a base!base::RunLoop::Run. Sfortunatamente non puoi fermarti a content!content::RendererMain per qualche motivo. Forse perché agganciamo il processo subito dopo che esce dalla funzione renderemain ed è eseguito da un thread. In ogni caso, ecco come appare l'ipc dopo quattro esecuzioni.. Questo indica che la gui è stata avviata. Ed ecco come appare l'ipc dopo l'avvio del processo renderer.. Impostiamo quindi un bp a
content!content::StartupTaskRunner::RunAllTasksNow+0x88 e content!content::RunOtherNamedProcessTypeMain. Lascialo eseguire
============================================================================================================
3.Ora, per la seconda parte dell'analisi del processo browser, siamo arrivati al punto in cui saremo in grado di comprendere e fare debug del renderer, ma non ci arriviamo ancora. Ho lasciato esplicitamente un'altra funzione da analizzare dopo RunBrowserProcessMain; beh, teoricamente è dopo RunBrowser, ma come forse ricorderai, RunBrowser è un wrapper per RunBrowserProcessMain. Ora, ciò che ho lasciato fuori è che nel file chiamato content_main_runner_impl.cc nella cartella src/content/app c'è un'altra funzione che viene chiamata dopo che generiamo il renderer e si chiama RunOtherNamedProcessTypeMain. Questo processo è responsabile dell'esecuzione di tutti gli altri processi.. Ora capiamo cosa succede nel codice. Vediamo che il suo prototipo è , il che indica che prenderà gli argomenti passati alla cmdline, quale tipo di processo aspettarsi e un chrome delegate. Arriviamo quindi all'inizio della funzione dove c'è una definizione di macro per verificare le specificità della piattaforma e controllare per quale processo istanziare un event handler. Cioè per verificare se esegue alcune funzioni per il processo console o per il processo browser. . Iteriamo quindi sui processi passati e li confrontiamo con un elenco di processi noti ed eseguiamo il processo corrispondente.  Nel caso in cui non otteniamo il processo corrispondente, allora è un processo personalizzato implementato da qualcuno
Ecco un link per implementare un processo personalizzato e useremo questo esempio per la seconda parte dell'analisi dinamica . https://bitbucket.org/chromiumembedded/cef/wiki/Tutorial .
=====================================================================
Parte di analisi dinamica
La prima parte dell'analisi dinamica inizia come segue: prima esegui da un cmd.exe con diritti di amministratore il seguente 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 . Dopo di che imposta .childdbg 1 così possiamo fare debug dei nuovi processi figli generati. In sostanza, ciò che fa il comando precedente è "assicurati di essere agganciato a tutti i processi figli". Un ringraziamento va a @spoofyroot e @_coreDump per avermi indirizzato nella giusta direzione con il debug multiprocesso. Ecco come dovrebbe apparire dopo aver impostato .childdbg 1  Dato che non sono riuscito a catturare in nessun altro modo cosa succede dopo, ho fatto un video in cui spiego cosa succede. https://streamable.com/9t4iof . Fondamentalmente, dopo l'ultima esecuzione di content!content::StartupTaskRunner::RunAllTasksNow+0x88 generiamo nuovi processi che gestiscono roba ipc e dovremo continuare a impostare un bp a content!content::RunContentProcess finché non lo colpisce. Questo è ciò che chiamo tentativi ed errori ragionati :)) .
=====================================================================
4.Analisi del Renderer
!Avvertenza
Mentre eseguiremo l'analisi del codice del Renderer, ci addentreremo un po' anche nel codice di blink per capire cosa succede esattamente nel renderer
Mentre scrivevo questa parte del corso, mi sono reso conto di aver dimenticato di descrivere brevemente cosa fa questo processo e perché mai dovremmo guardarlo. Come sappiamo, questo è il terzo processo avviato da chromium e si chiama renderer. Ma perché si chiama "renderer"? Si chiama così perché il suo compito è rendere (disegnare) tutto ciò che vediamo su un sito web. Fondamentalmente è il motivo per cui la tua tabella sembra una tabella quando visiti un sito web, o il tuo css permette di personalizzare un pezzo di testo, o perché il tuo js è in grado di fare magie nere*. Un altro importante motivo per cui lo analizziamo è che è da qui che provengono la maggior parte dei bug. Che parliamo di html, css, js o qualsiasi altro componente, li vedrai tutti sotto blink su chrome bugs.chromium.org
* Ci sono più processi renderer. Un processo completamente separato per ogni scheda che il browser ha attualmente aperto.
* Questo processo controlla qualsiasi cosa all'interno della scheda del sito web effettivo
* a partire dal 2018, gli iframe hanno ricevuto un aggiornamento in cui tutti possono avere schede. e così ogni scheda di un iframe ha un processo renderer individuale. Questa cosa si chiama Site-Isolation
* La sua responsabilità è analizzare un sito web, disegnare sullo schermo ciò che il sito web contiene al suo interno, es. tabelle, immagini, eseguire javascript
* è in sandbox
* al suo interno usa un motore di rendering chiamato Blink.
* crea e gestisce url-schemes come: chrome://, devtools://, chrome-error://
* Inizializza il motore Blink che farà effettivamente tutto il parsing e il lavoro pesante per il processo renderer.
L'ultima volta ci eravamo lasciati dopo aver finito l'analisi del processo browser e ora è arrivato il momento che tutti aspettavamo di passare alla parte di analisi del renderer. Già, mentre giocavo con chromium sono riuscito a farlo crashare e ho ottenuto il seguente stack trace.  Sulla base di questo sappiamo che il nostro viaggio inizia a content::RendererMain che si trova in `\content\renderer\renderer_main.cc` . Hai indovinato, il punto di partenza è RendererMain. Iniziamo analizzando come è definita e un po' del suo interno  . Possiamo vedere che accetta un parametro di tipo MainFunctionParams, il che significa che questa funzione accetterà gli argomenti passati al binario. Poi aggiungiamo un trace point così possiamo sapere che siamo arrivati a chiamare RendererMain, e quindi dereferenziamo il valore di parameters e lo salviamo in command_line. Poi abbiamo alcune macro che controllano l'architettura specifica della piattaforma, che possiamo ignorare , controlliamo il valore passato a kTimeZoneForTesting che è un fuso orario da usare per i test, poi incontriamo una nuova classe e un nuovo tipo di dato chiamato icu.
Ora, cercando una qualsiasi fonte di definizione per questo, arriviamo a https://unicode-org.github.io/icu-docs . Se guardiamo l'inizio del file dove si trova la direttiva include, possiamo vedere che è una libreria di terze parti. Quindi fino ad ora sappiamo che è una libreria di terze parti che gestisce componenti internazionali per unicode, cioè la usiamo per il supporto unicode. Ok, ma cosa fa quella funzione? Andando su https://unicode-org.github.io/icu-docs vediamo , cioè imposta il fuso orario predefinito in base a ciò che impostiamo come parametri. Poi inizializziamo la libreria skia e gestiamo --renderer-startup-dialog
. Poi incontriamo una nuova classe, RendererMainPlatformDelegate.
Cosa fa? Beh, prima di tutto dobbiamo specificare che è una classe astratta specifica per piattaforma. Nel nostro caso si troverà in /content/renderer dentro il file chiamato renderer_main_platform_delegate_win.cc . Si presenta così
. Quindi possiamo concludere che è solo una funzione helper che abilita la sandbox, e nel caso passiamo --no-sandbox esegue le azioni necessarie e basta. Poi impostiamo il nome del nostro thread a CrRendererMain. Poi incontriamo un'altra nuova classe chiamata RenderThread. 
Di nuovo, dato che fondamentalmente non sappiamo cosa fa, esploriamola un po'. La nostra ricerca per capire come è fatto RendererThread inizia da content/public/renderer/render_thread.h. Guardando dentro il file render_thread.h vediamo che è definita come . Di tutto quel file siamo interessati a IsMainThread, che è definita nel file rendere_thread.cc e appare così  (aggiungi una lunga descrizione su questo meccanismo). Ora, proseguendo con l'analisi del codice del renderer, possiamo vedere il momento più atteso: finalmente vediamo un po' di codice di blink. Il primo del suo genere, e quello che fa è inizializzare la libreria.. Dietro le quinte la funzione si presenta così . Ora la domanda naturale che sorge è: che diavolo sono queste classi? Cosa sono WTF e Platform. Fortunatamente, i documenti di blink ci dicono effettivamente cosa sono.
https://docs.google.com/document/d/1aitSOucL0VHZa9Z2vbRJSyAIsAz24kX8LFByQ5xQnUg/edit . Guardando "Directory structure and dependencies" possiamo dedurre che platform è una classe che aiuta con geometria e grafica. Passiamo ora alle classi WTF e Partitions. I documenti di Blink dicono anche di WTF: deriva da Web Template Framework ed è in pratica un "wrapper" della libreria stl, nel senso che "è una libreria di base per Blink che fornisce una varietà di funzionalità di base, come contenitori, librerie di stringhe, meccanismi di conteggio dei riferimenti, funtori, primitive di threading ecc." (citazioni dai documenti di blink (https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/blink/renderer/platform/wtf/README.md)). Aggiungi altri dettagli su blink
Ok, ora proseguendo con l'analisi di renderer_main.cc vediamo di nuovo qualcosa di cui non sappiamo cosa faccia, ed è  Aggiungi dettagli domani. Poi chiamiamo . Poi controlliamo se abbiamo abilitato i plugin durante la compilazione e, in caso affermativo, li carichiamo.
 Poi facciamo altri controlli che ho deciso di saltare perché la spiegazione si sta facendo piuttosto lunga e non sono necessari in questa fase. Ma in versione TL;DR servono a capire se abilitare o meno la sandbox prima dell'inizializzazione di RenderProcess. E infine arriviamo a . (aggiungi il resto dei dettagli sul resto delle funzioni). Anche se questa non è la fine dell'analisi del renderer, possiamo considerarla il punto di partenza dell'analisi vera e propria del renderer, perché come vedremo più avanti è qui che succede la maggior parte delle cose interessanti, quindi possiamo considerarla come il codice del renderer. Siamo interessati a RenderThreadImpl, che appare così . Di tutto quel codice siamo interessati alla funzione Init(), che appare così:
, ma è molto più lunga. :) sfortunatamente non possiamo catturarla in una singola immagine, e quindi ne abbiamo catturato l'inizio. A parte questo, tutto il resto che succede dopo InitializeWebKit() non è realmente di nostro interesse, dato che per la maggior parte è solo comunicazione ipc con il processo gpu, che al momento non è nel nostro radar. La fortuna ci sorride perché in quella funzione abbiamo catturato anche una delle funzioni a cui siamo interessati, precisamente InitializeWebKit(), che ancora una volta appare così . Ci allontaniamo un po' dalla nostra missione di spiegare renderer_main.cc per capire meglio cosa succede dentro InitializeWebKit. Ora, so che è tanto da capire, ma abbi pazienza mentre cerchiamo di dare un senso a questo pasticcio. Quindi vediamo che InitializeWebKit() inizia prendendo qualunque argomento sia stato passato a questo processo; poi controlliamo se abbiamo abilitato durante la compilazione -dENABLE_VTUNE_JIT_INTERFACE, e in caso affermativo controlliamo l'opzione passata alla cmdline, cioè enable-vtune-support. Che diavolo è? Abbiamo cercato su google e abbiamo trovato un link a https://www.intel.com/content/www/us/en/develop/documentation/vtune-help/top.html e in quella pagina dice che è: "uno strumento di analisi delle prestazioni per applicazioni seriali e multithread". Quindi in breve, qualcosa che migliora le prestazioni del tuo chrome. Poi inizializziamo blink . Ora, per capire il processo di inizializzazione di blink, spieghiamo brevemente dato che entreremo nei dettagli nel prossimo capitolo, che esaminerà blink in profondità. Incontriamo un'altra classe che ci è estranea, cioè RendererBlinkPlatformImpl, che appare così
 e si trova in
content/renderer/renderer_blink_platform_impl.cc . In base al nome possiamo concludere che è una classe astratta implementata in base alla piattaforma e possiamo anche vedere che eredita da  Esaminando cosa fa effettivamente RendererBlinkPlatformImpl, vediamo che controlla la piattaforma e in base ai risultati del controllo imposta un flag, poi controlla se il thread corrente è un RendererThread ottenendo un puntatore al tls
blah blah blah, vedi se aggiungi altro contenuto sulle classi. Poi arriviamo a qualcosa che forse tutti aspettavamo: il primo pezzo di codice v8. Che è . Cosa fa? Prima di tutto sappiamo dai documenti che un v8::isolate è un'istanza del motore V8. Cioè (una copia indipendente del runtime V8, che include un heap manager, un garbage collector, ecc.) non sufficiente per eseguire script. vediamo blink::MainThreadIsolate() definita come
 che si trova nel file blink/renderer/platform/bindings/v8_per_isolate_data.cc , che a sua volta V8PerIsolateData::MainThreadIsolate() appare così
 , V8PerIsolateData che, come avrai intuito, è anche essa una
classe che si trova in bindings/core/v8/V8PerIsolateData.h appare più o meno come blah blah blah, aggiungi dettagli. Poi controlliamo se abbiamo passato kDisableThreadedCompositing (aggiungi domani come è fatto realmente il flag) alla command line. nel caso in cui non l'abbiamo passato, avviamo un thread compositor. Che diavolo è? Citando da https://frontendmasters.com/courses/web-performance/the-compositor-thread/ , è un thread il cui "unico compito è disegnare bitmap, prenderle, inviarle alla GPU e metterle sullo schermo". Poi registriamo quello che viene chiamato scheme. In pratica ti ricordi quando guardi il codice sorgente e hai qualcosa davanti all'url, tipo: "view-source:website" . Sì, in realtà è gestito dal renderer. E ci sono molti altri di questi scheme. Cosa intendono con registrare? Non ne sono ancora sicuro, ma penso intendano qualcosa come: ehi, questa è una cosa che voglio che tu gestisca quando l'utente arriva e fa questa cosa. Comunque, ecco come appare. aggiungi più dettagli. bene, ora quando aggiungo, dettaglia anche l'ultimo pezzo di codice 
. blah blah blah e finalmente siamo arrivati alla parte finale di renderer_main, aggiorna con i dettagli
=====================================================================
Parte di analisi dinamicaOra, per poterlo debuggare dinamicamente, nel caso tu sia un novellino come me, vorrai eseguire windbg da cmd.exe come segue: 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 impostare .childdbg 1 per poter debuggare il processo figlio generato. Da lì vorrai eseguire bp content!content::RendererMain e lasciarlo eseguire per circa 5 o 6 volte. (modifica per fare riferimento al 4 nel video, è più chiaro così) dopo di che arriviamo a .
MainDllLoader
--no-sandbox
chrome_mainOra vediamo cosa fa. apriamo chromium.dll in binja.
Basandoci su questa immagine da https://blogs.igalia.com/jaragunde/files/2019/03/chrome-init-sequence.png abbiamo un'idea approssimativa di cosa dovremmo cercare in binja.
Ecco come appare il grafico in binja
.
Per riuscire a rintracciarlo meglio, cerca una funzione chiamata ChromeMain. Questa è la logica principale (aka core) di Chrome. Al suo interno possiamo vedere le fasi già menzionate di come chrome.dll viene eseguita all'avvio:
Qui possiamo vedere che prima chiama alcune funzioni come sub_180001420,sub_180017020,sub_180017020, che fanno alcuni controlli per vedere alcuni dettagli su come chrome è stato installato/compilato. Usando il codice sorgente possiamo tracciare i loro attributi. La prima funzione, sub_180001420, corrisponde a UmaHistogramEnumeration, poi abbiamo sub_180017020 che è InitializeFromPrimaryModule e la terza e ultima sub_180017020 è chrome_main_delegate.
Continuiamo a ripetere chrome_main_delegate ma non abbiamo mai definito quale sia il suo scopo. ChromeMainDelegate è una classe che eredita da ContentMainDelegate e fornisce principalmente funzioni relative all'avvio e l'elaborazione delle chiamate di processo. Se vuoi, puoi implementare un'interfaccia ContentMainDelegate personalizzata per cambiare il comportamento predefinito del modulo Content e usare una classe ChromeMainDelegate personalizzata in Chromium per personalizzare il comportamento del processo di avvio.
Al suo interno ci sono alcune chiamate a funzioni che fanno uno xor su alcune regioni di dati e le concatenano con alcuni registry per ottenere alcune opzioni riguardanti l'avvio di chrome
.
Nota anche che la funzione sub_180001510 crea un riferimento a puntatore scoped con due callback. Non è una cosa davvero importante, ma è interessante imparare cos'è un BindStateBase. Lo incontreremo spesso nel basecode di chrome.
Ora ti starai chiedendo cosa fanno le ultime tre righe, precisamente
do. Quindi la prima riga crea fondamentalmente un std::unique_ptr<> per le closure. WTF è una closure!? Beh, se dovessimo citare da Mozilla Dev: "una closure è la combinazione di una funzione insieme (racchiusa) con riferimenti al suo stato circostante (l'ambiente lessicale). In altre parole, una closure ti dà accesso allo scope di una funzione esterna da una funzione interna. In JavaScript, le closure vengono create ogni volta che viene creata una funzione, al momento della creazione della funzione." Se dovessimo usare un linguaggio umano, è una funzione dentro una funzione che accede a una variabile all'interno della funzione esterna. Es.
.
Quindi in sostanza fa sì che la closure venga eseguita. e le altre due righe impostano solo un comportamento specifico per i dump quando chrome crashes.InstallDetails::Get().VersionMismatch() patch qui
Andando avanti, controlla la propria versione in esecuzione e, nel caso non corrisponda, va in crash e arriviamo al parsing della riga di comando 
Entrando in sub_184171800 possiamo vedere che non è così grande 
Prima prende gli argomenti passati al processo corrente, poi chiama una funzione che prende una StringPiece, fondamentalmente un wrapper di classe per std::string ma un po' più figo, e quella funzione controlla fondamentalmente se il binario è stato chiamato headless, confronta se il nome del binario che è stato eseguito è chrome, controlla se USE_HEADLESS_CHROME è impostato e poi va avanti al passo successivo che è content main.
In base agli argomenti forniti, il compito di content main è avviare la rispettiva shell.
Ora, nel caso in cui non forniamo alcun argomento alla shell, il flusso di esecuzione va a 
.
Per capire cosa fa, dobbiamo verificarne il codice sorgente. Possiamo trovarlo in /src/content/app/content_main.cc
Dovremo scorrere fino in fondo e lì troveremo la definizione della funzione ContentMain. Lì vediamo che chiama due funzioni. Una che inizializza un ContentMainRunner, che è la classe che gestisce tutta la "creazione di processi" nel contesto della creazione del browser, di ipc sqli net e del resto. E l'altra che fondamentalmente controlla il tipo di sottoprocessi e lo passa alla classe ContentMainRunner.
Ora facciamo un passo indietro per capire il flusso di codice. Prima esaminiamo RunContentProcess perché ContentMainRunner è piuttosto complesso. La prima cosa che fa è creare un GlobalActivityTracker. Omg !!! avete indovinato, Google ti traccia :))) Nah, sto scherzando, per favore non citatemi in giudizio, Google. Ma parlando sul serio, questo tiene traccia di ogni thread, cioè è un thread tracker, e fa un paio di cose carine per un debugging migliore, come:
che in sostanza significa che ci sarà un intero univoco usato come identificatore per ogni thread per capire meglio cosa causa l'interruzione del processo.
ad es:```
kTypeIdActivityTracker = 0x5D7381AF + 4, // SHA1(ActivityTracker) v4
kTypeIdUserDataRecord = 0x615EDDD7 + 3, // SHA1(UserDataRecord) v3
kTypeIdGlobalLogMessage = 0x4CF434F9 + 1, // SHA1(GlobalLogMessage) v1
kTypeIdProcessDataRecord = kTypeIdUserDataRecord + 0x100,