Stealing Browser Cookies: Bypassing Chrome's Latest Security Measures

Good afternoon everyone. Uh welcome to the current session. Uh current session will be from uh Rafael Felix and we will will be about stealing browser cookies and uh about how to bypass the newest security uh measures by Chrome. A few announcements before we begin. Um we would like to thank you to our um diamond sponsors Adobe and Iikido and uh our to our gold sponsors Formal and Drop Zone AI. Uh it's there to it's it's thanks to them that uh this event is possible and thanks to the volunteers and donors uh that this event is happening. Uh with regards to cell phones, please put them on silent mode. uh this these events are uh streamed with exception of

sky talks and also don't don't take pictures with everyone in the frame. Be reminded that these talks will be later on published uh to the to the YouTube channel. Uh with regards to questions, use the mic uh so so everyone in the stream can hear you later on. And with that, let's get started and uh enjoy the talk. Thank you. Hello. Let me just put my mic up here. Hello guys. Um, so today we'll be talking about stealing browser cookies, bypassing the newest Chrome security measures, which is a very interesting topic uh for all you red teamers out there that want to get those cookies from the browser. So here um we have the content table you

guys you'll see about chromium based browsers you guys will see about gecko based browsers webkit based browsers and the future of browser security um which we'll be talking about device device bound session cookies which is a very um nice implementation to make cookie storage more secure and also we have a live demo of uh proof of concept tool that extracts all of those browsers cookies and other data including um saved accounts. So let's get started here. Um who am I? I am a offensive security lead um with six plus years of experience in our development and an analysis. I work at Hakai offensive security which is a Brazilian company focused on red teaming and offensive security. Um I created

coffee which is a rust based cough loader um that leverages um beacon object files for ease of use. Um I did the puck for the CV 2024 21338 which is an admin to kernel Windows driver exploit and I really like Rust. I really like um bypassing EDR protection. I really like Go, Python and everything that relates to systems programming and bypassing um edr and anti viruses especially um low-level programming. So let's get started with the main main issue. Um the first one is that info stealing m has been a persistent threat. You've guys seen um probably a lot of people getting compromised from those um types of malware. Nowadays, it's very very common to see um that happening.

Session hijacking through cookie theft is more common than ever. Um usually on our operations we um usually we get some cookies from stealers. Um we have our internal um stealer where we can extract um sessions and then um impersonate with um the cookie gathered. Browser vend vendors are constantly implementing sophisticated security measures. Um so yeah um nowadays since chillers are way um famous than before browser vendors are implementing more um hefty security measures to try to um um to to let people not steal this data um that easily. Chrome's latest security measures have significantly reduced um the effectiveness of traditional attacks as I've said. So here we'll get to a quick info data analysis. Um our team at Kimera which is

our threat intel um platform did a quick analysis. We have a ton of uh steeler data counting from 2019 to 2024. Um the key numbers are the 37% year-over-year growth in credential taff. Um 130 million stolen credentials credentials in 2023. 179 million um stolen credentials through October 2024. Um the geographic leaders are Brazil, India and uh those who have a higher um population and uh more digital exposure which is um expected. Um this research gets into how um this data relates to the human development index too. Um which is very cool. If you guys want to see um after the talk, you can save the link on the QR code. And of course um we have uh the

steeler families which red line gets the dominance here. Um it's by far the most famous one and the the one that um stays stay the long on the market. We have SteelC and Luma too. Luma is the newest one. Um we had a record September 2024 spike with that one. Um it's getting way f famous too. Um a lot of people are um delivering mowers which use um the luma steeler family and of course um new variants appear monthly and uh yeah so let's get to chromium based browsers. How do they encrypt the data? Um here I just wanted to show you guys a little bit of the evolution of Chrome security. Um from 2015 to 2020 we had the DPA API

integration which is the data protection API um which Windows provides. So you can encrypt the data with the key which that is present on your computer. Um this was implemented to 2020. Then in 2020 um from 2023 we have the AS 256 GCM encryption of the state key um that had the integration of DP API. On 2023 till 2024 uh Chrome implemented a new encryption called appbound encryption which uh means application bound encryption. So everything that is encrypted gets bound by the application itself making it more secure. Um we'll show you guys later on um how this works but basically you have a service that runs as any author authority system and uh this service encrypts the data with

DP API and then re-encrypts it um as normal uh user level from 2024 to 2025 we have we have some changes um between as 26 256 GC CM to um shasha 20 poly 33 1305 which is a encryption method used used uh especially on blockchain I think um I don't know why they implemented that one maybe because it's more um optimized or something like that but yeah they changed uh the key and the algorithm on 2024 to 2025 and in the near future um which is already shipped on the Chrome uh dev and Chrome beta beta builds um is device bound session cookies which we'll show you guys later on to uh on how it

works and also some possible attack vectors um some brainstorming here to see if you if you guys can get some idea of um an attack. So let's start with the foundation of Chrome. Um we have the location of the cookies on each operating system. Um I'll be talking about every operating system for every browser. Um in the case of Gecko Firefox um the implementation is crossplatform and Safari of of course had uh its version on Windows but nowadays um it only has on Mac OS. So the main cross plat platform here browser will be Chrome. Um on Windows we have the local app data folder um at Google Chrome user data default for the default profile or um profile um and the

the profile number slash network/cookies. On Mac OS we have the home folder um M library application support Google Chrome default or the same profile number slashcookies and on Linux um this folder is usually onconfiggle chrome um default or profile numbers the database format is SQL3 um with the cookies table containing uh the host key, the name and the encrypted value columns uh where where all cookies are. Um and the master key location finally is stored at the Google Chrome user data local state file which is a JSON file at the OS uh underline crypt encrypted underline key field. So let's get into the application B encryption architecture. Um you guys can see a diagram here straight from the

Google um website actually when they implemented um this this security measure. Uh but here I have some key points for us attackers um on how we can implement um um to steal from application bound. So first you need admin administration uh privileges to run. Then we'll need to um use SE debug privilege. We'll have to elevate our priv our process privilege to access either the LSS process or the wing logon process which um allow for some reason for you to duplicate their token and then for you to assign that token to the current process allowing you to access um any authority system services. Um so then you need to duplicate the the token with the security impersonation

level. Then you need to set the current thread token to the impersonated system token um following the system DP API decrypt of the appbound encrypted key using the crypt unprotect data um sys call. Everything I'm showing here you guys can see later on the repository. Um I I'll leave the QR code at the end of the talk. Um everything is written in Russ that I really like. Um and if you guys can uh want to implement anything um showed here, you guys can do it. Um it's actually a library. It's a crate. So you guys can just import on your project and start um stealing cookies. Um so yeah, we do the decrypt of the

appbound encrypted key. Um then the user decrypt of the result from system decrypt. So we first decrypt as system then um we reverse the token to our normal user access and then we decrypt again as user because it's a twostep um encryption process. So yeah the process involves two-stage um DPI decryption. Um here's the postprocess data function. uh where the magic really happens nowadays. Um on top of the application bound, Chrome uses this branding specific function um which actually does a lot of encryption behind it. Um, since Chromium is open source, you guys can see it there, but I don't know if you guys can see um it has a flag called um Chrome specific branding and we can't

unfortunately see the contents of that function um because it's an internal uh um internal implemented function. But yeah, this function does all the state key encryption on top of the application bound. So here we'll get to some disassembly. Um on the chrome path you guys will f find the elevator service.exe file. On that file um you guys can throw that file on a disassembly and start looking um and understanding how it works. Um so here I have the key initialization function that gets triggered on a class constructor inside the postprocess data function. Um since we don't have access to the source code we need to do this disassembly right. Um and on the right we have the key location um for uh the

elevation service with um the as key the short key and the shasha 20 poly 1305 key. Um both three keys are stored there. Um I changed the structure as you guys can see um to the encryption metadata uh fun structure and we have three um key types stored there. So all the keys we need um to decrypt are there on the disassembly with those keys. Um Chrome then calls the encrypt data function which is inside the postprocess data function that then encrypts the data passed um to it. As you guys can see um here actually is a call um on below get encrypt key handler which is something new they implemented actually I wrote this talk

um two months ago and they changed they changed uh recently and uh this talk is updated so you guys will getting uh the fresh um technique here. Um so yeah here uh we we get the the global encryption metadata map which is the keys and then this this function encrypts um with those keys. So let's get to the format um state state key decryption. So first um when we get the this system user decrypted DP API key you guys will have the key blob which you you can parse first with a four byte header length then header data then four byte content length then the content data which is um the actual state key. So you guys will have to do

some programming here um to check first the flag type. Uh the flag bite is at the start of the content data after after the length fields. So the first bite is going to be the flag and then we are going to check this flag. Um because we have three flags uh means uh that chrome is doing backwards compatibility. So um keys that were created on older version of versions of chrome will also work um on this algorithm here. So first we have flag type one that uses a hard-coded as key with GCM mode which is uh the oldest one. Uh here we get the content data format. We have the one byte flag 12 byt iv 32 byt cipher text

and the 16 byt tag. Um for flag type two um he's using the uh the most recent one but not the actual most recent one um which is the uh shasha 20 poly 1305 key um which follows the same format one by flag uh 12 byt iv 32 byt cipher text and uh 16 byt tag. Nowadays, Chrome implemented the crypto next generation API which Windows um implemented to be a replacement I think um for the data protection API um and then Chrome implemented it since I think they saw it was uh stable and uh every computer had it. Um so yeah um we CNG decrypt encrypted AS key um which is in uh which is in the key blob. Then we

short process with the hardcoded key. Um this is actually a difference here. Um on flag type one and two we use the hard-coded key to decrypt using an algorithm. Now we are doing a simple short process with the hard-coded key which is present um on that on those key on that key table I showed you guys um before. So yeah uh and the same format too of the of the flat of the content data. Um then we decrypt verify the cipher text tag to get the v20 m master key which is actually the state key we used to do the cookie decryption. Cookies on Chrome are encry encrypted using AS256 GCM2. So here I have a diagram um if you guys

uh can understand barrier here. So first we start with admin privileges. Then we enable SC debug privilege. We find a process in which we can duplicate a N authority system token. We then duplicate that token, impersonate it as system, read the local state JSON um extract um the key, remove the application bound header because on the start um actually this is based 64 encoded. So you need to decode the the base 64. Um then remove the the header, right? and then um system DPAPI decrypt and then user DPI decrypt parse the key blob structure check the flag type as I showed you guys and depending on the flag type we can decrypt it verify um with the key uh we we've gathered on

the disassembly and then finally get the v20 uh master key. So here we'll get to the cookie format and decryption because cookies are encrypted and then with this key we've gathered um we can now decrypt the cookie. I've also added a simple diagram there uh if you guys like that um it's easier to understand too because um there's a lot of things um you you guys going to see especially on Firefox um the encryption is very complicated. Um so we connected the cookie SQLite database in read only mode uh query for the for the cookies um with with the encrypted value then the cookie also has a structure. So we have a three bytes on

the start which uh defines in which version the cookie was saved. That actually counts as backwards compatibility since someone can um obviously have older cookies um when they saved uh when there they were saved on older versions of Chrome. So having uh this check also have uh helps getting the most data possible. Um so yeah we have the V20 um V11 or V10 versions for older cookies. V20 is um as you can see the newest one. So then the cookies follow followed by a 12 by IV a variable cipher text and the 16 byt tag as usual. We then create the cipher um AES 256 GCM. We use the extracted 12 byt IV as nons for the ASGCM decrypt and verify

the cipher texts with 16 byt authentication tag skip the first 32 bytes of decrypted result which um for database base versions higher than 24 um in case of uh last year roughly um the newest ones the cookies are now followed by um the host key on the on the start. So you have to validate the host key then skip the 32 bytes to decode the remaining bytes and get the final cookie value. So yeah I say here the decrypted payload contains the shot 256 hash of the domain followed by cookie value. We then repeat the process for every other cookie as you guys can see on the diagram too. So let's get to Mac OS. U Mac OS is a

bit different here. Um, we have uh an encryption passphrase saved on keychain um which makes it a little bit more secure um because keychain on Mac OS actually works. Um Chrome safe storage here um is the name of the saved um keychain item. We then use a different algorithm now passage based key derivation function two with a fixed salt called salty salt for some reason and a 103 iterations to derive the as 128 key. Um so we followed the same process we connected the chrome's cookies SQLite database um with the extracted master key from keychain. Um to be clear you have to get the keychain key um then decrypt decode with base 64 then decrypt with passwordbased key

derivation function two. So we query the cookies where the encrypted value starts um with the same um caveat here with the v20 v11 v10 versions. Um the cookie structure is very similar actually but the the only difference is that on Mac OS um it doesn't use as uh 256 GCM it uses AS 12 28 CBC um encrypted data with PKCS7 padding. So we then create the cipher. Um the IV is actually um a fixed IV of 16 space characters um which is 0x20 and then we use the key um extracted from the keychain process as the key. We then remove the version prefix which is the v20 um decrypt the cipher text and remove the bks7 padding from the result.

And then the same thing for database versions higher than 24. The decrypted payload contains sha shot 20 uh 56 um hash of the domain followed by cookie value. We then decode the remaining bytes as utf8 to get the final cookie value and the process repeats for each encrypted cookie in the database. Okay. Um so on Linux um it's actually quite similar. Um on Linux we have an opal um choice um to use keyring um go genome key ring or kw wallet under the same name chrome safe storage or if no key ring is installed on the system um the passphrase is actually peanuts for some reason too. Um we then use the PB key um DF2

passwordbased key derivation function 2 with a fixed salt um salty salt and one iteration this time to derive the key. The same process repeats um the IV for the cipher is 16 space characters which are which is Z 0x20. We then remove the version prefix. Decrypt the cipher tags. Remove the PKCS7 padding and follow the same um thing here for the database version which is the shot uh 256 hash of the domain. We decode as UTF8 and then we get um the final decrypted cookie um also with the diagram here if you guys like that. So yeah, what about other Chromium based browsers? We've talked about Chromium, Google Chrome, Chrome Canary, ChromeDev, Chrome Beta, everything that relates to

Chrome, but not Brave, Microsoft Edge, and those other browsers. Um, actually they are even weaker. Um, as postprocess data is a branded implementation. Um, only Chrome does this way. Braven Edge only implements the application B encryption. Um so then we can just get the last 32 bytes of the decrypted result which is the system user um decryption from DP API um to get the state key for decryption and of course the same cookie decryption um for accounts you may ask um it's actually the same decryption as the cookies um so thank you thank you Chrome um here um let's start with the gecko um the gecko is a Um it's a bit hard actually. Um so

let's see how they encrypt browser data. Um let's start with the the same format the foundation um uh cookie location on Windows uh app data Mozilla Firefox profiles on Firefox. Actually the profiles folder has a lot of other uh subdirectories which are um the different profiles. So you can just iterate it um using your code um more easily. Actually one trick for Chrome on inside local state file you actually have an array of all saved profiles um that really helps when parsing uh different profile names because um the folder has a lot of files. It's not just a profile folder. Um so on Mac OS it's on library application support Firefox profiles profile um the same format on Linux

uh.mosilla firefox any profile that is present on that folder. So yeah cookie storage is in cookies.sqlite SQLite database with the MOS cookies table account storage is in logging.json JSON which is a bit different. Um we're not using SQLite now. We are storing the login at a JSON file with B 64 encoded encrypted credentials. The master key data is stored on a file called key4. DB as as a SQLite database too with the meta meta data and network secure service private tables which is NSS which is a very old implementation by Firefox. Um we have no centralized local state file like Chromium browsers profile based architecture um with individual profile directories. Um and here is the

this is tough um Firefox stores their cookies as plain texts. So no encryption applied. Um only saved login accounts and passwords are encrypted. Um, so yeah, so I actually searched to see if uh Firefox is trying to implement something for the cookies. Um, here's someone creating a request um for the implementation of DBSC. And uh here we have Simon saying the proposal seems sound but it's not clear that is a good investment of engineering time. So yeah, we uh we have the cookies in plain text for Firefox um for now. So yeah, let's get to the encryption overview. Uh Firefox stores the credentials in two main locations as I've said um key4.db which contains the

encrypted master key and login json containing the encrypted usernames and passwords. Um the the encryption flow is actually following this process. Um we have the master password, the master key, the individual credential keys and then the plain text. Um each credential is encrypted se separately with a an unique salt and three different encryption methods are supported. Um this is done in order to uh do backwards compat compatibility too. um because first Firefox implemented a really legacy um encry encryption method and now um we have a bit more modern um and more secure um encryption method. So yeah um let's get to the master key extraction. Um so we open the key for DB database. Um the global sal is present

there um and it's used for all derivations. Um the encrypted validation contains the password check string. So you have to check for that to see if it's valid. Um encrypted master key um which is present on the database too and validation constant uh that must be equal to the specific value. Um validate the database integrity. Um we then decrypt the validation data which we check that must contain the password check. Um then we check the validation constant that must be equal to key underline len which is uh 2 48 a bunch of zeros and then one I I'll show you guys later. Um so we then extract the final master key decry the master key

with the global salt and then take the first um 24 bytes as the final encryption key. Um so yeah as I've said we have three encryption schemas. Um first actually we have to parse an ASN one structure which is just um another binary format to organize data especially data which um is the uh relates to uh encryption and cryptography. Um so yeah we have three um encryption schemas. We have network security services passwordbased encryption which is the legacy uh 3 um encryption. Uh we have the meta PBE password based encryption which is the modern AES and then we have the login passwordbased encryption which is a simple um triple D um encryption. Um I'll get to the meta PB for now. If you

guys want to see about the NSS and the logging you guys can see the repository. I'm just not gonna talk about them now because um I'll take very long here. Um and those methods are not being used nowadays. It's just there for backwards compatibility. So yeah. Um here we have the AS256 CBC algorithm. Um the key derivation is actually based key derivation function 2 followed by a HMAC followed by SHA 256 256 sorry with 100,000 um iterations. Um the key size is 32 bytes and the IV size is of course 16 bytes. Um here I have a diagram um if that helps too. um the key derivation pro process for modern PB keydf2 um we have the base password with

then which then follows um as sha1 of the global salt which is present on key4.tb TB. Um we then uh call PBKDF2 which HMAC uh and then SHA 256 with the base password with with which is the SHA one of the global salt um the entry salt which is present uh specifically on the uh meta PB implementation on the meta m metadata um table on the key for DB uh 100k iterations 32 bytes the IV constru constructed separately from from the parts of the AS1 um structure. Okay, so let's get to the decryption process. Um we then first read the login JSON um decode the base 64 um prediction blobs, get the row ASN1 structure on the

on the table. We then parse the ASN1 structure, identify the encryption schema and extract the salt. Um we then generate the decryption key apply um applying appropriate key derivation which for the modern one is the HMAX chain with PB key DF2. We then use the global salt with the extracted entry salt from the table and then we generate encryption key and IV followed by that we get the decrypt and validate. Um we apply the block cipher with um AS256 ABC in the case of the mo one. We remove the PKC CA PKCS7 padding and then we convert the bytes to UTF8. Uh the result is the plain text username and password. In this case, Firefox only encrypts the password. The

username you guys can see as plain text. Um so here I have the whole diagram of the process. Um if you guys want um I'll be releasing uh this slide on the GitHub repository. I'll show you guys in the end. Um and you guys can take a look uh more uh with more call u because it's very actually very overwhelming. Sorry, it's a bit uh it's a bit uh messed on the below, but it's going to be okay. um webkit based browsers. How do they encrypt and decrypt browser data? So let's get to the foundation on cookie loc cookie location uh on Mac OS. Actually on Mac OS some applications implement webkit 2. So you'll find this

these cookies on library http stoages and binary cookies files. Uh that's very interesting actually because I can see some applications for example even PowerPoint that I'm using right now has some cookies there which is very nice to take a look if you guys want to do something with Microsoft accounts just saying um library containers come Apple Safari which uh is the new folder for for Safari before Safari didn't run on a container container environment now it runs so we have to access this folder. Um to be very clear um the application has to have full um disk access um from the TCC permission. So you can just execute it um and be happy. Yeah, of

course you're going to do some fishing to make the user um accept that the application can have full disk access or exploit TCC of course. So yeah um data library cookies cookies.binary binary cookies file. Um the cookie storage is in binary cookies file format. Account storage is in keychain more complex exploitation. Um cookies are stored in plain text. No encryption applied. So yeah, it's just a binary format uh a fancy format that you can parse and get the cookie data in plain text. No encryption applied. So yeah um we have the magic which which is cook for some reason. Maybe because it's cookie. Um I don't know. Um page count, page sizes array. Then per page,

we have the start code of 000000 one 0 0. Um we then loop the cookie count, cookie offsets. Um and the end code is when it gets to 000000. Um cookie record 44 byt header plus strings. Um we have the size of four, a no four, flags four, and a note four. Um each content is followed by four bytes each. So we have the domain name, path, value, comment offsets and the end header of course. Um the expiry time and the creation time is eight bytes and variable strings are new terminated domain name path value and comment. Um the flags in this case is 0x0000 none 0x01 secure 0x04 http only and 0x05 both. Um the time stamp is a

MAC format. So you have to convert for Unix epoch. Here I have the diagram too. Um we open the cookie binder cookie. We check if the magic is cook. Um if not it's not valid. If it is, we got we get the page count, page sizes. Each page um the start, the cookie count, the cookie offsets on the end. Then um for each page, we for each cookie we get the 44 byt header, the string offsets, um we then extract the strings, clean um the nose um then get the time stamps, convert the time, um the size and flags, and then we assemble and we have the plain text cookie. Um you guys can actually see um the code on the

repository if that helps to to understand um myself um especially I really like to read the code to understand what's happening um and actually on uh the browser voyage which is the tool I'm going to be publishing um uses a crate called binary cookies reader um so you guys can open that crate and see how uh he implements um this for so yeah um let's get to the future of browser security um unwelcome DBSC here um so here I have a simple diagram showing how the process works first um the user login to a page um Chrome then generates a key pair which is a public and private key um this private key is stored on TPM which is the trusted

platform module chip um when the cookie expires because it it um creates a a short-lived cookie um uh every time. So when it it expires um we get the http 401 unauthorized cook uh chrome then pauses the request um requests the private key from TPN. Um it validates the proof of possession of the of that private key. Um then Chrome presents proof to the server. Um the server validates uh this proof and then we get uh a new short-lived cookie and then the process um goes on uh forever which is actually a very fancy implementation here. Um so yeah hardware backed session security um cryp cryptographic key pair associated with user's device short-lived cookies um with automated

refresh and proof of possession required for for cookie renewal. Um this is um this one is actually very important. The user needs to have a computer with compat uh that's compat compatible with um TPM. um because nowadays um not all computers actually have a TPN chip especially um laptops which are more old. So yeah, this only applies for those who have TPM. So yeah um I'll do some brainstorming brainstorming here um of possible attack vectors. Um first of all if you guys want to see more information about DBSC and their um whole process uh for implementing you guys can scan this QR code on the screen. So yeah, um let's get to to some possible attack factors.

Um TPM key extraction which requires possible physical access um for the chip or some sort of administrative access u maybe correlating to the TPM driver modification here um that we modify the TPM kernel driver for Windows um or any other operating system uh DB GBSC implements in the future. Um and then we can maybe get um the private key on the TPM uh virtual memory memory extraction. Uh maybe on the process of Chrome writing this private key to the TPM maybe we can um we can middleman I don't know um requires possibly process injection or memory dumping um and of course a mware during the registration process. Um if a M is present during the session

registration, it can extract the private key as it's generated as I've said. So yeah, um here's browser voyage. You guys can scan the QR code to access um the GitHub repository. Um it's a Rust project implementing everything mentioned on this presentation. It acts as a crate, so you can implement it in your Rust project too. Um, and a tactic. Actually, this was for Defcon because I'm going to do a red team village. Um, I'll do a tactic a tactic at red team village. If you guys want to be there, um, I can help um you guys more closely on the implementation. So, yeah, let's get to some uh live demo here. Uh, I actually have um, if you

guys can see here, a terminal with browser voyage opened. Um to run the project we we can execute cargo run as release and then um it runs it looks for all browsers inside my machine. Let me get some here. Um so yeah we ext extracted data from from Chrome. Um no Microsoft Edge installed here. Um extracted some cookies from Brave. Extracted um some credentials from Safari. um so f from Firefox and all of this data is saved to the browser data export folder. Um of course you have a command line interface here. Let me just get here. So yeah um you have you you can set which browsers you want to extract the content um uh that you want to extract

cookies credentials um history or all. In this case, history is not yet implemented, but it's very easy even if you guys want to help um with the development process. You guys can um the the repository is licensed with Ginu GPL v3. So if you guys want to implement the history is just uh history escalite um with no encryption at all at all. Um the format you want to export JSON, CSV or XML, the output variables, debug trace um and of course help or version. Um I'll get to the browser data export folder. You guys can see here um all the browsers exported. Um I show you guys um the Brave one. Of course um those cookies are not real

uh out cookies. Um I just I just installed Brave and opened google.com and it already saves some cookies here as you guys can see. And as you guys can see um the browser extracted in this case was Brave um with the default profile, the host, the name, the value, the path, the expiry and if it's secure. So yeah, that's it. Um thank you. If you guys have some any questions, um I'm here um to answer them. Thank you.