# MediaChunks

chunk_id: 184_chunk_44
chunk_text:
| another key from the same hotel? Um we could speculate that there's a way to do it. I don't 2284.90s - 2288.30s | know if I would do it via brute forcing because it is pretty painful like you have to 2288.30s - 2293.54s | physically move the device you know across the lock each time. Um but as I said like the USB 2293.54s - 2297.62s | port seemed pretty interesting to us and there may be a way to like get that info from it. Uh 2297.66s - 2305.50s | we just didn't look at that surface at all really so. Thanks. Two questions um one are you 2305.50s - 2313.94s | staying at Resort World? Two is Resort World a Safelock co- hotel? I'm sorry I couldn't hear 2313.94s - 2322.58s | the question. The second one was uh is Resort World a Safelock hotel? Yeah I. We've we've 2322.58s - 2326.42s | both stayed at Resort World and uh we believe it's been fixed there. I believe all the cards 2326.42s - 2336.44s | are ultralight C there so. So for the uh legacy encoder that uh Dormakaba is replacing um it 2336.44s - 2341.30s | appears that that can also write ultralight C. So do you know why they replaced that 2341.30s - 2346.84s | encoder? I'm sorry I think the mic is a little low so I'm having trouble hearing the 2346.84s - 2350.92s | question sorry. Sorry I was saying um so for the legacy encoder that Dormakaba is 2350.92s - 2355.88s | replacing it appears that with the system 6000 software it can also read and write the 2355.88s - 2360.92s | ultralight C cards. So do you know like what additional security they got by replacing it? 2362.12s - 2367.08s | Um they told us that they added a secure element to the new encoder um we didn't we didn't look 2367.08s - 2371.96s | and they didn't tell us on exactly how that's used um but I think that was part of the reason 2371.96s - 2376.20s | um I'm not sure if the old encoders support ultralight C or not as well. I'm not sure. 2377.64s - 2383.00s | I think the older system supported other cards not just Minecraft Classic I think they had 2383.00s - 2387.64s | even support for ultralight for a while and just


chunk_id: 184_chunk_45
chunk_text:
| appears that that can also write ultralight C. So do you know why they replaced that 2341.30s - 2346.84s | encoder? I'm sorry I think the mic is a little low so I'm having trouble hearing the 2346.84s - 2350.92s | question sorry. Sorry I was saying um so for the legacy encoder that Dormakaba is 2350.92s - 2355.88s | replacing it appears that with the system 6000 software it can also read and write the 2355.88s - 2360.92s | ultralight C cards. So do you know like what additional security they got by replacing it? 2362.12s - 2367.08s | Um they told us that they added a secure element to the new encoder um we didn't we didn't look 2367.08s - 2371.96s | and they didn't tell us on exactly how that's used um but I think that was part of the reason 2371.96s - 2376.20s | um I'm not sure if the old encoders support ultralight C or not as well. I'm not sure. 2377.64s - 2383.00s | I think the older system supported other cards not just Minecraft Classic I think they had 2383.00s - 2387.64s | even support for ultralight for a while and just no one really seemed to use it like all of the 2387.64s - 2395.59s | software deployments we've seen were Minecraft Classic. Thank you awesome talk. Hi I've read 2395.59s - 2401.59s | my photos card and it's not my fair but it's ST chip do you know if it's valuable or not? 2403.11s - 2409.27s | ST chip? It's quite difficult to understand the questions up here but. I have a card with ST chip 2409.27s - 2415.59s | not my fair. Did you look at those? I haven't looked at any hotels that had ST chips in them 2415.59s - 2423.43s | but maybe Iceman knows about this specific card for a moment. I don't know sorry. Okay thank you. 2432.50s - 2437.54s | Now he's gonna heckle us. Hi I'm Iceman I have a question to you. 2440.26s - 2444.66s | Uh no the ST card is not vulnerable in that sense yes it's true but 2444.66s - 2452.42s | Jen Benjamin Dupree did some work with it. Awesome fucking research I'm in awe by it. 2453.30s - 2466.92s | It's amazing. I bow to the gods of RD hacking but to be honest it was Minecraft


chunk_id: 184_chunk_46
chunk_text:
no one really seemed to use it like all of the 2387.64s - 2395.59s | software deployments we've seen were Minecraft Classic. Thank you awesome talk. Hi I've read 2395.59s - 2401.59s | my photos card and it's not my fair but it's ST chip do you know if it's valuable or not? 2403.11s - 2409.27s | ST chip? It's quite difficult to understand the questions up here but. I have a card with ST chip 2409.27s - 2415.59s | not my fair. Did you look at those? I haven't looked at any hotels that had ST chips in them 2415.59s - 2423.43s | but maybe Iceman knows about this specific card for a moment. I don't know sorry. Okay thank you. 2432.50s - 2437.54s | Now he's gonna heckle us. Hi I'm Iceman I have a question to you. 2440.26s - 2444.66s | Uh no the ST card is not vulnerable in that sense yes it's true but 2444.66s - 2452.42s | Jen Benjamin Dupree did some work with it. Awesome fucking research I'm in awe by it. 2453.30s - 2466.92s | It's amazing. I bow to the gods of RD hacking but to be honest it was Minecraft Classic and 2466.92s - 2471.64s | you did do have .NET so I think that's cheating I thought you would done more hardware. 2473.00s - 2478.04s | With that said give them a well-rounded applause for us they are fucking amazing. 2478.44s - 2488.81s | I guess that's it. All right thank you so much appreciate it.


chunk_id: 184_chunk_47
chunk_text:
Classic and 2466.92s - 2471.64s | you did do have .NET so I think that's cheating I thought you would done more hardware. 2473.00s - 2478.04s | With that said give them a well-rounded applause for us they are fucking amazing. 2478.44s - 2488.81s | I guess that's it. All right thank you so much appreciate it.


chunk_id: 185_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=8oAxv7UBZJA", "title": "DEF CON 32 - Atomic Honeypot-A MySQL Honeypot That Drops Shells - Alexander Rubin, Martin Rakhmanov", "description": "Meet an attacking MySQL honepot which can \u201cAttack the attackers\u201d. In 2023 we have found a CVE (CVE-2023-21980) in MySQL that allows a rogue MySQL \u201cserver\u201d to attack a client connecting to it; attack meaning RCE on the client side. Since then we were thinking on how to use it for good. One obvious application is to create a honeypot which will attack the attackers. In 2024 we have found another RCE in mysqldump utility (CVE-2024-21096), so we have created a rogue MySQL server and weaponized it with a chain of 3 vulnerabilities: 1/ arbitrary file read 2/ RCE from 2023 (CVE-2023- 21980) 3/ the new RCE (CVE-2024-21096). With this atomic honeypot we were able to discover 2 new attacks against MySQL server. Using arbitrary file read vulnerability in MySQL we were able to download and analyze the attackers' code and then execute an \u201cattack against attackers\u201d using a chain of exploits.\n\nCVE-2023-21980 CVE-2024-21096", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 1318, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 6.88s | This text was transcribed using whisper model: large-v2 attack. We know that bots are everywhere, they're scanning your servers, they're doing it fast, 6.88s - 13.51s | and database servers is obviously a big target. So we have um create uh we have created a high 17.25s - 22.25s | interaction MySQL honeypot. So we create a tool that mimics the database, implements 22.25s - 27.25s | MySQL protocol, and those bots start connecting to this honeypot. So we need to understand 35.64s - 40.64s | the MySQL protocol. And MySQL protocol, unlike other database protocols, actually a 43.18s - 48.18s | server initiated. So if we just start a TCP server, then it will not be enough. If you connect 48.88s - 53.88s | to your MySQL server using Telnet, on the port 3306, you will see this. And this is what 59.72s - 65.62s | MySQL server provides for the client to be able to connect. It specifies the version, it 65.62s - 70.64s | specifies salt, it specifies a client plugin. So listening to the port, a TCP server is not 70.64s - 75.64s | enough. So what we did to create the high interaction MySQL honeypot is we used the 81.98s - 86.98s | Python module. The


chunk_id: 185_chunk_1
chunk_text:
that bots are everywhere, they're scanning your servers, they're doing it fast, 6.88s - 13.51s | and database servers is obviously a big target. So we have um create uh we have created a high 17.25s - 22.25s | interaction MySQL honeypot. So we create a tool that mimics the database, implements 22.25s - 27.25s | MySQL protocol, and those bots start connecting to this honeypot. So we need to understand 35.64s - 40.64s | the MySQL protocol. And MySQL protocol, unlike other database protocols, actually a 43.18s - 48.18s | server initiated. So if we just start a TCP server, then it will not be enough. If you connect 48.88s - 53.88s | to your MySQL server using Telnet, on the port 3306, you will see this. And this is what 59.72s - 65.62s | MySQL server provides for the client to be able to connect. It specifies the version, it 65.62s - 70.64s | specifies salt, it specifies a client plugin. So listening to the port, a TCP server is not 70.64s - 75.64s | enough. So what we did to create the high interaction MySQL honeypot is we used the 81.98s - 86.98s | Python module. The Python provides, there is a module called MySQL mimic. It implements 89.66s - 94.66s | MySQL protocol, it's a really powerful thing. Uh and you can do lots of things with it. So 95.62s - 100.62s | from there, we started the honeypot, and we start receiving the connections. So you start 103.86s - 110.40s | the honeypot as a fake MySQL server on an open port from the internet. And you start 110.40s - 115.94s | receiving the connections. And you can see lots of information about the connection 115.94s - 120.94s | actually. Like the HTTP protocol, MySQL protocol also have this client version record, 121.94s - 126.94s | and stuff like that. So this is called attributes. MySQL provides a lot of attributes as a 131.04s - 136.08s | part of the connection. That's part of protocol. We have client version, OS, and stuff 136.08s - 142.28s | like that. So we started the honeypot and we immediately see the fingerprints of the 142.28s - 148.56s | connections. And you can see the version of the client library, you can see the operating 148.58s - 153.58s | system, you can see all other stuff. This is very


chunk_id: 185_chunk_2
chunk_text:
Python provides, there is a module called MySQL mimic. It implements 89.66s - 94.66s | MySQL protocol, it's a really powerful thing. Uh and you can do lots of things with it. So 95.62s - 100.62s | from there, we started the honeypot, and we start receiving the connections. So you start 103.86s - 110.40s | the honeypot as a fake MySQL server on an open port from the internet. And you start 110.40s - 115.94s | receiving the connections. And you can see lots of information about the connection 115.94s - 120.94s | actually. Like the HTTP protocol, MySQL protocol also have this client version record, 121.94s - 126.94s | and stuff like that. So this is called attributes. MySQL provides a lot of attributes as a 131.04s - 136.08s | part of the connection. That's part of protocol. We have client version, OS, and stuff 136.08s - 142.28s | like that. So we started the honeypot and we immediately see the fingerprints of the 142.28s - 148.56s | connections. And you can see the version of the client library, you can see the operating 148.58s - 153.58s | system, you can see all other stuff. This is very useful actually. Now from there, the 156.46s - 161.46s | part two is what kind of attacks we have. We have seen from this honeypot, high 167.06s - 174.04s | interaction honeypot, we see two major attacks on MySQL. The first is an attempt to own 174.06s - 179.46s | MySQL server and create a backdoor. This is actually pretty well known attack, and there's a 179.46s - 184.46s | blog post about that. What is interesting about that is we can see right away that it's using a 187.70s - 192.70s | very old MySQL client version. It's actually only works for older servers as well. So the second 196.24s - 201.24s | is even more interesting attack. It's a ransomware. It tries to download your data, basically 201.78s - 206.78s | brute force the password first, then connects, tries to download the data, and then drops the 211.58s - 218.60s | databases and asks for ransom. So this is exactly the same thing. We see the fingerprints. We see 218.60s - 224.60s | what OS version, we see what the client is using. So now from there, we started an atomic version 225.08s - 230.08s | of the


chunk_id: 185_chunk_3
chunk_text:
useful actually. Now from there, the 156.46s - 161.46s | part two is what kind of attacks we have. We have seen from this honeypot, high 167.06s - 174.04s | interaction honeypot, we see two major attacks on MySQL. The first is an attempt to own 174.06s - 179.46s | MySQL server and create a backdoor. This is actually pretty well known attack, and there's a 179.46s - 184.46s | blog post about that. What is interesting about that is we can see right away that it's using a 187.70s - 192.70s | very old MySQL client version. It's actually only works for older servers as well. So the second 196.24s - 201.24s | is even more interesting attack. It's a ransomware. It tries to download your data, basically 201.78s - 206.78s | brute force the password first, then connects, tries to download the data, and then drops the 211.58s - 218.60s | databases and asks for ransom. So this is exactly the same thing. We see the fingerprints. We see 218.60s - 224.60s | what OS version, we see what the client is using. So now from there, we started an atomic version 225.08s - 230.08s | of the honeypot. Honeypot that strikes back. So what we want to do, our goal is actually 238.42s - 243.42s | interact with those attacks. And our goal was to see what they're doing, how they do that, and 246.00s - 251.00s | potentially download the code, the malicious code that they're using. So our atomic honeypot 251.34s - 257.34s | now strikes back. What do we have? So we have been juggling with different CVEs in MySQL client. 265.22s - 271.22s | And we have arbitrary file read, which is a super old issue. We have the remote code execution 272.22s - 278.22s | where MySQL server attacks you. We actually found that issue a year ago, 2023. We have 283.80s - 289.80s | presented it and we can use that to actually execute code on the client. And then finally, this 290.16s - 296.16s | year, we have found another issue in MySQL client utility. We reported it to Oracle. This is a 302.04s - 309.48s | second remote code execution in MySQL client. All right. So MySQL server attacks MySQL client. 314.02s - 320.02s | This is how it works. There are two things here. The first thing is


chunk_id: 185_chunk_4
chunk_text:
honeypot. Honeypot that strikes back. So what we want to do, our goal is actually 238.42s - 243.42s | interact with those attacks. And our goal was to see what they're doing, how they do that, and 246.00s - 251.00s | potentially download the code, the malicious code that they're using. So our atomic honeypot 251.34s - 257.34s | now strikes back. What do we have? So we have been juggling with different CVEs in MySQL client. 265.22s - 271.22s | And we have arbitrary file read, which is a super old issue. We have the remote code execution 272.22s - 278.22s | where MySQL server attacks you. We actually found that issue a year ago, 2023. We have 283.80s - 289.80s | presented it and we can use that to actually execute code on the client. And then finally, this 290.16s - 296.16s | year, we have found another issue in MySQL client utility. We reported it to Oracle. This is a 302.04s - 309.48s | second remote code execution in MySQL client. All right. So MySQL server attacks MySQL client. 314.02s - 320.02s | This is how it works. There are two things here. The first thing is that we have a MySQL server 321.56s - 327.56s | client arbitrary file read. And we create a server. And then your client connects to a server. And 329.34s - 335.34s | the server will request a file. So we can have an arbitrary file read from the client. The second is 338.94s - 344.52s | the one that we found a year ago and we presented it at last year. There are lots of details 344.52s - 350.96s | there. And basically, the prerequisite of this attack is that you need to have the shared 350.98s - 357.46s | library uploaded to the client first. Then, whatever the connection will be established, you 357.46s - 363.46s | can actually take that client connection to execute your shared library. You don't need to 366.30s - 372.30s | execute the shared library itself. You just need to have that file on the client. And finally, we 374.10s - 380.58s | have found this year, we have found a new issue in MySQL client utility. And then I will 380.60s - 386.60s | invite Martin, my colleague Martin, to explain how it works. And this is the first time we're 387.98s -


chunk_id: 185_chunk_5
chunk_text:
that we have a MySQL server 321.56s - 327.56s | client arbitrary file read. And we create a server. And then your client connects to a server. And 329.34s - 335.34s | the server will request a file. So we can have an arbitrary file read from the client. The second is 338.94s - 344.52s | the one that we found a year ago and we presented it at last year. There are lots of details 344.52s - 350.96s | there. And basically, the prerequisite of this attack is that you need to have the shared 350.98s - 357.46s | library uploaded to the client first. Then, whatever the connection will be established, you 357.46s - 363.46s | can actually take that client connection to execute your shared library. You don't need to 366.30s - 372.30s | execute the shared library itself. You just need to have that file on the client. And finally, we 374.10s - 380.58s | have found this year, we have found a new issue in MySQL client utility. And then I will 380.60s - 386.60s | invite Martin, my colleague Martin, to explain how it works. And this is the first time we're 387.98s - 396.09s | releasing the details about this CVE. Martin? Hi. So let's jump into this CVE. As you probably 399.93s - 405.93s | know, MySQL dump is a tool which allows you to produce logical backups of a database. Script 406.39s - 412.39s | tables and other objects and data to be transferred to another server. So this is an example 418.27s - 424.27s | how you can use MySQL dump together with MySQL. You just pipe the output of MySQL dump to 426.43s - 432.47s | MySQL to recreate a database on another server. And this is pretty close to what official 432.49s - 438.49s | documentation says. Where is the problem? MySQL utility allows you to use so-called meta 440.93s - 446.93s | comments. For example, if you do backslash, exclamation mark, and then space and a comment, it's 448.63s - 455.27s | going to execute a shell comment on a computer where the MySQL tool is running. So the CVE 455.27s - 461.27s | itself is about tricking MySQL dump to emit such a shell comment, for example. So the CVE 462.47s - 468.47s | is a tool which allows you to use MySQL dump together with


chunk_id: 185_chunk_6
chunk_text:
396.09s | releasing the details about this CVE. Martin? Hi. So let's jump into this CVE. As you probably 399.93s - 405.93s | know, MySQL dump is a tool which allows you to produce logical backups of a database. Script 406.39s - 412.39s | tables and other objects and data to be transferred to another server. So this is an example 418.27s - 424.27s | how you can use MySQL dump together with MySQL. You just pipe the output of MySQL dump to 426.43s - 432.47s | MySQL to recreate a database on another server. And this is pretty close to what official 432.49s - 438.49s | documentation says. Where is the problem? MySQL utility allows you to use so-called meta 440.93s - 446.93s | comments. For example, if you do backslash, exclamation mark, and then space and a comment, it's 448.63s - 455.27s | going to execute a shell comment on a computer where the MySQL tool is running. So the CVE 455.27s - 461.27s | itself is about tricking MySQL dump to emit such a shell comment, for example. So the CVE 462.47s - 468.47s | is a tool which allows you to use MySQL dump together with MySQL. So how this works exactly? By 468.47s - 474.47s | default, MySQL dump tries to process everything it receives from a server. But it's not a case 474.47s - 480.49s | for the version. As you can see, there is a version string coming from a server, and it is emitted 480.49s - 486.49s | as a comment in the output of MySQL dump. But this is not processed, this is not sanitized, and 486.91s - 492.91s | this is sent back to output as is. We can leverage this by simply creating our own server, the 495.95s - 501.71s | patched version of a server. As you can see here, I just replaced a version with a hard-coded 501.71s - 507.39s | string, a new line, and then my comment of choice to be executed on the machine. Here, I just 507.39s - 513.19s | created a file. And if you could tell that to this patched server, you will see this. In red, you 513.21s - 519.21s | will see our comment. And then, this is output of a MySQL dump. We have a comment execution for 522.01s - 528.01s | this vulnerability. All we need to


chunk_id: 185_chunk_7
chunk_text:
MySQL. So how this works exactly? By 468.47s - 474.47s | default, MySQL dump tries to process everything it receives from a server. But it's not a case 474.47s - 480.49s | for the version. As you can see, there is a version string coming from a server, and it is emitted 480.49s - 486.49s | as a comment in the output of MySQL dump. But this is not processed, this is not sanitized, and 486.91s - 492.91s | this is sent back to output as is. We can leverage this by simply creating our own server, the 495.95s - 501.71s | patched version of a server. As you can see here, I just replaced a version with a hard-coded 501.71s - 507.39s | string, a new line, and then my comment of choice to be executed on the machine. Here, I just 507.39s - 513.19s | created a file. And if you could tell that to this patched server, you will see this. In red, you 513.21s - 519.21s | will see our comment. And then, this is output of a MySQL dump. We have a comment execution for 522.01s - 528.01s | this vulnerability. All we need to do is to provide a fake server. So we have created a honey pot, 531.55s - 537.55s | which is a Python code, which allows you to exploit this specific vulnerability, and also the 537.91s - 543.91s | plugin-loading vulnerability by passing specific configuration options to this honey pot. The goal 548.89s - 554.89s | is simple. We try to run code on the clients who connect to our honey pot by leveraging these 556.67s - 566.03s | vulnerabilities. And here's a demo. So let's see. We have a payload script, a VBS script, which 566.03s - 572.03s | will be running on Windows, which just pops up a message, you have been pwned. Now, we start our 575.99s - 581.99s | honey pot and pass a payload. And also, we start a HTTP server. And once MySQL dump is executed on 583.67s - 589.67s | Windows now, the version is 36, which is one version before the latest, we get this pwned message. 601.69s - 606.69s | That's it. Back to you, Alex. 606.69s - 612.69s | Thank you very much. All right. So now, we successfully pwned the client. We were able to 614.77s - 620.77s | do


chunk_id: 185_chunk_8
chunk_text:
do is to provide a fake server. So we have created a honey pot, 531.55s - 537.55s | which is a Python code, which allows you to exploit this specific vulnerability, and also the 537.91s - 543.91s | plugin-loading vulnerability by passing specific configuration options to this honey pot. The goal 548.89s - 554.89s | is simple. We try to run code on the clients who connect to our honey pot by leveraging these 556.67s - 566.03s | vulnerabilities. And here's a demo. So let's see. We have a payload script, a VBS script, which 566.03s - 572.03s | will be running on Windows, which just pops up a message, you have been pwned. Now, we start our 575.99s - 581.99s | honey pot and pass a payload. And also, we start a HTTP server. And once MySQL dump is executed on 583.67s - 589.67s | Windows now, the version is 36, which is one version before the latest, we get this pwned message. 601.69s - 606.69s | That's it. Back to you, Alex. 606.69s - 612.69s | Thank you very much. All right. So now, we successfully pwned the client. We were able to 614.77s - 620.77s | do this because we were actually trying to figure out and scratching our heads, how do we actually 625.81s - 631.81s | attack those bad guys? So, back to the two attacks that we have been working with. The first attack, this 636.49s - 642.49s | is what we have captured, a fingerprint. Right? So, from the fingerprint itself, we can already see 645.73s - 651.73s | what we can or cannot do. So, arbitrary file read, we know this is old version. We know that it will work. 655.11s - 661.11s | Remote code execution with a plugin, we don't know. We will try it out. And there is no MySQL dump in this 662.39s - 668.39s | particular attack, so we will not be able to use the newest version. So, how do we use the arbitrary file 668.95s - 674.95s | read? Arbitrary file read is super easy. There is a tool that you can download from the internet, from the 676.83s - 682.83s | GitHub. You start this tool and you simply specify the file that you want to download from the client. 685.19s - 691.19s | Again, the client will be connecting to the server. This


chunk_id: 185_chunk_9
chunk_text:
this because we were actually trying to figure out and scratching our heads, how do we actually 625.81s - 631.81s | attack those bad guys? So, back to the two attacks that we have been working with. The first attack, this 636.49s - 642.49s | is what we have captured, a fingerprint. Right? So, from the fingerprint itself, we can already see 645.73s - 651.73s | what we can or cannot do. So, arbitrary file read, we know this is old version. We know that it will work. 655.11s - 661.11s | Remote code execution with a plugin, we don't know. We will try it out. And there is no MySQL dump in this 662.39s - 668.39s | particular attack, so we will not be able to use the newest version. So, how do we use the arbitrary file 668.95s - 674.95s | read? Arbitrary file read is super easy. There is a tool that you can download from the internet, from the 676.83s - 682.83s | GitHub. You start this tool and you simply specify the file that you want to download from the client. 685.19s - 691.19s | Again, the client will be connecting to the server. This is fake server. And then we will be able to read the file. 691.75s - 697.75s | So, this is how the client arbitrary file read works. I will go through this real quick. So, you have this, I 707.47s - 713.47s | download this tool. I start this tool on port 3306. And I request a password. And now, I am connecting 714.47s - 720.47s | from my machine with the old version of MySQL. And I connect into this fake server. And here I go. I got the 729.07s - 735.07s | file. So, I obtained this file. This is an old attack. Now, how can we use that? What we want to do is, we 735.07s - 743.25s | want to first understand which version of Windows those attackers, those bots are using. There are a 750.63s - 756.63s | number of ways how you can determine the version of Windows by downloading the file. So, we started this 758.81s - 764.81s | file list and we determined that this is really old version of Windows. This is Windows Server 2003. 767.31s - 773.31s | Alright, so with this attack, we were able to understand and get


chunk_id: 185_chunk_10
chunk_text:
is fake server. And then we will be able to read the file. 691.75s - 697.75s | So, this is how the client arbitrary file read works. I will go through this real quick. So, you have this, I 707.47s - 713.47s | download this tool. I start this tool on port 3306. And I request a password. And now, I am connecting 714.47s - 720.47s | from my machine with the old version of MySQL. And I connect into this fake server. And here I go. I got the 729.07s - 735.07s | file. So, I obtained this file. This is an old attack. Now, how can we use that? What we want to do is, we 735.07s - 743.25s | want to first understand which version of Windows those attackers, those bots are using. There are a 750.63s - 756.63s | number of ways how you can determine the version of Windows by downloading the file. So, we started this 758.81s - 764.81s | file list and we determined that this is really old version of Windows. This is Windows Server 2003. 767.31s - 773.31s | Alright, so with this attack, we were able to understand and get more details about what the attackers are 774.95s - 780.95s | using. Now, let's try the remote code execution. The remote code execution is, actually on Windows you need 784.49s - 790.49s | DLL. We need to deliver that DLL to the attacker's machines, to the client, to be able to trigger it. So, we 791.05s - 797.05s | started to think, how do we deliver this code? Again, DLL doesn't need to be triggered on the client. We are 804.03s - 810.03s | triggering through the remote code execution. What we did is, we collected the fingerprint, the actual 812.37s - 818.37s | commands that the server, the client, is running, is trying to run on the server. And what we did is, we 820.55s - 826.55s | can see that what they are trying to do is, they are trying to download the malicious code on the server. So, 830.93s - 836.93s | they are running an FTP server on their own machine. And we know the password, the username, and the port of 839.67s - 845.67s | the server. So, we started creating the simulation. Here's our plan of attack. We will upload the DLL to a


chunk_id: 185_chunk_11
chunk_text:
more details about what the attackers are 774.95s - 780.95s | using. Now, let's try the remote code execution. The remote code execution is, actually on Windows you need 784.49s - 790.49s | DLL. We need to deliver that DLL to the attacker's machines, to the client, to be able to trigger it. So, we 791.05s - 797.05s | started to think, how do we deliver this code? Again, DLL doesn't need to be triggered on the client. We are 804.03s - 810.03s | triggering through the remote code execution. What we did is, we collected the fingerprint, the actual 812.37s - 818.37s | commands that the server, the client, is running, is trying to run on the server. And what we did is, we 820.55s - 826.55s | can see that what they are trying to do is, they are trying to download the malicious code on the server. So, 830.93s - 836.93s | they are running an FTP server on their own machine. And we know the password, the username, and the port of 839.67s - 845.67s | the server. So, we started creating the simulation. Here's our plan of attack. We will upload the DLL to a 846.39s - 852.39s | public location on the client, on the actual server, Windows 2003. And then we will run the honey pot, wait 860.31s - 865.81s | for the connection, and through the connection we will trigger that DLL so we will have the remote code 865.81s - 870.81s | execution. So, we created this RCE via the simulation. So, this is how it could work. First of all, we 875.93s - 881.93s | have, we are connecting to FTP server here, simulating that we are connecting to the actual machine. We do the 887.07s - 895.12s | demo, demo, now we will put our evil DLL. And now, after we put the evil DLL in a public location, then we will 900.30s - 906.30s | start the server, the honey pot. This is the server that is running on the server. So, this is the server. 907.74s - 913.74s | We run the startup script. We specify the plug-in dir, public documents, and then this thing will actually 917.32s - 923.32s | trigger the execution of our DLL via the directory traversal. I don't have much time to explain this attack, but 927.90s - 933.90s | this has


chunk_id: 185_chunk_12
chunk_text:
846.39s - 852.39s | public location on the client, on the actual server, Windows 2003. And then we will run the honey pot, wait 860.31s - 865.81s | for the connection, and through the connection we will trigger that DLL so we will have the remote code 865.81s - 870.81s | execution. So, we created this RCE via the simulation. So, this is how it could work. First of all, we 875.93s - 881.93s | have, we are connecting to FTP server here, simulating that we are connecting to the actual machine. We do the 887.07s - 895.12s | demo, demo, now we will put our evil DLL. And now, after we put the evil DLL in a public location, then we will 900.30s - 906.30s | start the server, the honey pot. This is the server that is running on the server. So, this is the server. 907.74s - 913.74s | We run the startup script. We specify the plug-in dir, public documents, and then this thing will actually 917.32s - 923.32s | trigger the execution of our DLL via the directory traversal. I don't have much time to explain this attack, but 927.90s - 933.90s | this has been explained last year. You can actually see the recording from the HIDBI. Basically, there is a 934.06s - 940.06s | plug-in dir in MySQL and the file name, and we use the directory traversal to actually trigger DLL open, 943.40s - 949.40s | which, or load library on Windows, which is in the server. Now, I'm listening on the port, and now here's my 951.88s - 956.88s | DDL. My DDL is displaying the text and actually create the, um, um, the dialogue. So, this is the 964.16s - 970.16s | code. Here's how it works. So, we have this MySQL command line utility, and we have the evil DLL, uh, 975.14s - 981.14s | uploaded to the client. Now, the client, in this simulation, that's the bad actor. They are connecting to us, 984.04s - 990.04s | and here's, here we go. We actually executed the code, remote code execution. Thank you. Alright, so, 992.37s - 1001.98s | this is done. We demonstrated arbitrarily file read. We demonstrated remote code execution, uh, with a plug-in. 1006.82s - 1012.82s | So, the second attack is even more interesting. Now, from the fingerprint, what do we see? We see this


chunk_id: 185_chunk_13
chunk_text:
been explained last year. You can actually see the recording from the HIDBI. Basically, there is a 934.06s - 940.06s | plug-in dir in MySQL and the file name, and we use the directory traversal to actually trigger DLL open, 943.40s - 949.40s | which, or load library on Windows, which is in the server. Now, I'm listening on the port, and now here's my 951.88s - 956.88s | DDL. My DDL is displaying the text and actually create the, um, um, the dialogue. So, this is the 964.16s - 970.16s | code. Here's how it works. So, we have this MySQL command line utility, and we have the evil DLL, uh, 975.14s - 981.14s | uploaded to the client. Now, the client, in this simulation, that's the bad actor. They are connecting to us, 984.04s - 990.04s | and here's, here we go. We actually executed the code, remote code execution. Thank you. Alright, so, 992.37s - 1001.98s | this is done. We demonstrated arbitrarily file read. We demonstrated remote code execution, uh, with a plug-in. 1006.82s - 1012.82s | So, the second attack is even more interesting. Now, from the fingerprint, what do we see? We see this is 1015.16s - 1021.16s | later versions of MySQL client. We know that this remote code execution via plug-in will not work, but we 1026.10s - 1031.12s | see immediately is that it's using MySQL dump. This is the utility. We actually found a way to, to do the, the 1034.48s - 1040.86s | code execution. And then again, we were scratching our heads, and then we decide, well, let's collect 1040.86s - 1045.86s | more information. Let's understand how this attack is being, uh, executed. So, this is what we see. The, the 1046.02s - 1052.02s | application that connects to, uh, our server, right, it, um, uh, connects to the server, do the show 1058.46s - 1063.46s | databases, and then what it will do is it will run, it will execute MySQL dump utility and, uh, pass the 1064.46s - 1069.46s | database and the table name. So, basically what it do, the, the goal of this thing is to download the 1082.34s - 1087.34s | database so that they can actually claim that they download your data. But, we can see that the only 1087.50s - 1092.50s | downloaded 10 records. So, don't pay, obviously, right?


chunk_id: 185_chunk_14
chunk_text:
is 1015.16s - 1021.16s | later versions of MySQL client. We know that this remote code execution via plug-in will not work, but we 1026.10s - 1031.12s | see immediately is that it's using MySQL dump. This is the utility. We actually found a way to, to do the, the 1034.48s - 1040.86s | code execution. And then again, we were scratching our heads, and then we decide, well, let's collect 1040.86s - 1045.86s | more information. Let's understand how this attack is being, uh, executed. So, this is what we see. The, the 1046.02s - 1052.02s | application that connects to, uh, our server, right, it, um, uh, connects to the server, do the show 1058.46s - 1063.46s | databases, and then what it will do is it will run, it will execute MySQL dump utility and, uh, pass the 1064.46s - 1069.46s | database and the table name. So, basically what it do, the, the goal of this thing is to download the 1082.34s - 1087.34s | database so that they can actually claim that they download your data. But, we can see that the only 1087.50s - 1092.50s | downloaded 10 records. So, don't pay, obviously, right? Don't pay. Those guys don't have your data. 1100.98s - 1107.32s | They claim that they have downloaded, backed it up, backed your database, but they didn't. They only 1107.32s - 1112.32s | have 10 records. Right? And then from here, we were started brainstorming. Can we download the code 1112.78s - 1117.78s | via arbitrary file read? No. Can we execute code via plugin? Actually, no as well. Right? We know 1124.76s - 1129.76s | because this is the newer versions. So, we started looking again how this attack is being handled. So, we 1132.20s - 1138.16s | see that's the using MySQL, MyADB connector, right? This is from the fingerprint. This should be 1138.18s - 1144.86s | some application there, right? And then suddenly, MySQL dump connects to our server. So, they 1144.86s - 1149.86s | probably do some execution of the MySQL dump and then we see back, we see that the application 1153.36s - 1158.36s | connects back. So, we also see this. Again, we are providing the server. Whatever client will 1158.48s - 1163.48s | execute, we will see immediately. And this is what we see. This is our table that we generated. It's 1169.42s


chunk_id: 185_chunk_15
chunk_text:
Don't pay. Those guys don't have your data. 1100.98s - 1107.32s | They claim that they have downloaded, backed it up, backed your database, but they didn't. They only 1107.32s - 1112.32s | have 10 records. Right? And then from here, we were started brainstorming. Can we download the code 1112.78s - 1117.78s | via arbitrary file read? No. Can we execute code via plugin? Actually, no as well. Right? We know 1124.76s - 1129.76s | because this is the newer versions. So, we started looking again how this attack is being handled. So, we 1132.20s - 1138.16s | see that's the using MySQL, MyADB connector, right? This is from the fingerprint. This should be 1138.18s - 1144.86s | some application there, right? And then suddenly, MySQL dump connects to our server. So, they 1144.86s - 1149.86s | probably do some execution of the MySQL dump and then we see back, we see that the application 1153.36s - 1158.36s | connects back. So, we also see this. Again, we are providing the server. Whatever client will 1158.48s - 1163.48s | execute, we will see immediately. And this is what we see. This is our table that we generated. It's 1169.42s - 1174.42s | send it up, up, back to us. So, maybe if this is what they're doing, maybe we can actually do a 1178.42s - 1183.42s | command injection. And we started experimenting with this. We created a fake database, a schema 1184.06s - 1189.06s | name as a database in MySQL. We created this, a classical command injection. And uh, we were 1195.64s - 1200.64s | surprised. It actually worked. So, we used the command injection on this client attack, right? On 1204.80s - 1210.62s | this board, just like this, and we receive all the information uh, out of this command back to 1210.66s - 1215.66s | us. So, we downloaded the evil code from those attackers. This is how it is looking like. It's a 1220.10s - 1225.10s | MySQL dump. We have a command injection here and here's what we see. We got the evil code. So, it's 1227.44s - 1232.44s | a Python script. It's a Python script that connects to your database, try to brute force the 1232.64s - 1237.64s | password, and then execute the MySQL dump. The multiple injections. We were looking at this 1242.08s - 1247.08s | code and we


chunk_id: 185_chunk_16
chunk_text:
- 1174.42s | send it up, up, back to us. So, maybe if this is what they're doing, maybe we can actually do a 1178.42s - 1183.42s | command injection. And we started experimenting with this. We created a fake database, a schema 1184.06s - 1189.06s | name as a database in MySQL. We created this, a classical command injection. And uh, we were 1195.64s - 1200.64s | surprised. It actually worked. So, we used the command injection on this client attack, right? On 1204.80s - 1210.62s | this board, just like this, and we receive all the information uh, out of this command back to 1210.66s - 1215.66s | us. So, we downloaded the evil code from those attackers. This is how it is looking like. It's a 1220.10s - 1225.10s | MySQL dump. We have a command injection here and here's what we see. We got the evil code. So, it's 1227.44s - 1232.44s | a Python script. It's a Python script that connects to your database, try to brute force the 1232.64s - 1237.64s | password, and then execute the MySQL dump. The multiple injections. We were looking at this 1242.08s - 1247.08s | code and we were like, well, there are multiple places where you can execute the command. Alright, 1249.52s - 1254.52s | so we successfully, we achieved our goal, but not the way we thought originally. We executed the 1254.72s - 1259.72s | command injection. How do you try that at home? Uh, I'm pretty sure this will be fixed shortly, so 1268.36s - 1275.20s | you need to try it right now if you want to see what it looks like. Uh, and you don't even need a 1275.20s - 1280.20s | tool. You can start a MySQL database server, any version, you will create a root with no 1280.86s - 1285.86s | password. This is a born version of MySQL server, right? You don't care if they will be 1290.84s - 1295.84s | downloading your data. I'm done almost. And then you open that and this is the injections that you 1297.48s - 1302.48s | will do. Create database, put it in a backticks, and that's it. This is how you will be able to 1302.48s - 1307.70s | attack, uh, the bad guys. Alright, this is done. All done. So, new CVE details and thank you.


chunk_id: 185_chunk_17
chunk_text:
were like, well, there are multiple places where you can execute the command. Alright, 1249.52s - 1254.52s | so we successfully, we achieved our goal, but not the way we thought originally. We executed the 1254.72s - 1259.72s | command injection. How do you try that at home? Uh, I'm pretty sure this will be fixed shortly, so 1268.36s - 1275.20s | you need to try it right now if you want to see what it looks like. Uh, and you don't even need a 1275.20s - 1280.20s | tool. You can start a MySQL database server, any version, you will create a root with no 1280.86s - 1285.86s | password. This is a born version of MySQL server, right? You don't care if they will be 1290.84s - 1295.84s | downloading your data. I'm done almost. And then you open that and this is the injections that you 1297.48s - 1302.48s | will do. Create database, put it in a backticks, and that's it. This is how you will be able to 1302.48s - 1307.70s | attack, uh, the bad guys. Alright, this is done. All done. So, new CVE details and thank you.


chunk_id: 186_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=BN07rjaNqXk", "title": "DEF CON 32 - The Way To Android Root: Exploiting Smartphone GPU - Xiling Gong, Eugene Rodionov", "description": "GPU security is a vital area of mobile security highlighted both by public security research as well as by in-the-wild attacks. Due to the high complexity of the GPU software/firmware along with a widely available attack surface, issues in GPU provide strong exploitation primitives for local privilege escalation attacks by the code running in unprivileged context.\n\nIn this talk, we will focus our research on the Qualcomm Adreno GPU, which is a very popular GPU implementation in mobile devices. We will do a deep dive into Adreno GPU kernel module implementation focusing on the most recent GPU versions, reveal its complex and new attack surfaces, and discuss vulnerabilities we discovered in this component.\n\nIn total we identified 9+ exploitable vulnerabilities in Adreno GPU driver leading to kernel code execution and affecting Qualcomm-based devices using the latest GPU models. We will demonstrate the exploitation of one of the race condition issues on a fully-patched widely used Android device to obtain root privileges from zero-permission application with 100% success rate.\n\nAndroid kernel mitigations such as CFI and W^X create significant hurdles for exploiting vulnerabilities in kernel to achieve code execution. Also race condition usually means unstable, low success rate. We'll explain how we overcome these challenges with a novel, generic exploit method that leverages GPU features to achieve arbitrary physical memory read/write. This technique bypasses key mitigations (CFI, W^X) and has broader implications for kernel heap buffer overflows. We will cover the technical details of the exploitation, and especially the novel generic exploit method.\n\nWe will also discuss the action items that the vendors could take to minimize the impact of this exploit method, as well as general methods to improve the overall security status of the GPU.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2778, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.59s - 3.07s | This text was transcribed using whisper model: large-v2 OK. 3.07s - 5.67s | OK, sorry for that. 5.67s - 7.35s | Good afternoon, everyone. 7.35s - 8.75s | My name is Xuexin. 8.75s - 10.63s | I'm the manager of Android Red team. 14.11s - 18.27s | Today, I'm really honored to present you 18.27s - 20.19s | the way to Android root exploiting 20.19s - 26.25s | your GPU on smartphone with these two gentlemen. 26.25s - 29.41s | This


chunk_id: 186_chunk_1
chunk_text:
vulnerabilities in kernel to achieve code execution. Also race condition usually means unstable, low success rate. We'll explain how we overcome these challenges with a novel, generic exploit method that leverages GPU features to achieve arbitrary physical memory read/write. This technique bypasses key mitigations (CFI, W^X) and has broader implications for kernel heap buffer overflows. We will cover the technical details of the exploitation, and especially the novel generic exploit method.\n\nWe will also discuss the action items that the vendors could take to minimize the impact of this exploit method, as well as general methods to improve the overall security status of the GPU.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2778, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.59s - 3.07s | This text was transcribed using whisper model: large-v2 OK. 3.07s - 5.67s | OK, sorry for that. 5.67s - 7.35s | Good afternoon, everyone. 7.35s - 8.75s | My name is Xuexin. 8.75s - 10.63s | I'm the manager of Android Red team. 14.11s - 18.27s | Today, I'm really honored to present you 18.27s - 20.19s | the way to Android root exploiting 20.19s - 26.25s | your GPU on smartphone with these two gentlemen. 26.25s - 29.41s | This is Shilin Gong, our security researcher. 29.41s - 33.25s | And he actually did most of the technical work. 33.25s - 35.53s | So big credit to him. 35.53s - 39.25s | And also next to Shilin is our tech lead, Eugene Rodionov. 39.25s - 42.37s | Eugene did a lot of work to help us create the slides 42.37s - 44.77s | and make sure our demo runs smoothly. 44.77s - 48.06s | Big shout out to him. 48.06s - 51.66s | So our story dated back to the earliest year 51.66s - 58.62s | when Shilin decided to take a look at Qualcomm GPU drivers. 58.62s - 60.78s | But before we go into details, here's 60.78s - 62.82s | a brief introduction of our team. 62.82s - 66.14s | So we are the Android Red team. 66.14s - 69.94s | Our goal is to increase the Android and Pixel security. 69.94s - 75.34s | And we do this by simulating adversaries attacking 75.34s - 77.34s | Android key features. 77.34s - 81.78s | And our work can be broken down into a couple of different ways. 81.78s - 85.50s | Most obviously, we do offensive security research


chunk_id: 186_chunk_2
chunk_text:
is Shilin Gong, our security researcher. 29.41s - 33.25s | And he actually did most of the technical work. 33.25s - 35.53s | So big credit to him. 35.53s - 39.25s | And also next to Shilin is our tech lead, Eugene Rodionov. 39.25s - 42.37s | Eugene did a lot of work to help us create the slides 42.37s - 44.77s | and make sure our demo runs smoothly. 44.77s - 48.06s | Big shout out to him. 48.06s - 51.66s | So our story dated back to the earliest year 51.66s - 58.62s | when Shilin decided to take a look at Qualcomm GPU drivers. 58.62s - 60.78s | But before we go into details, here's 60.78s - 62.82s | a brief introduction of our team. 62.82s - 66.14s | So we are the Android Red team. 66.14s - 69.94s | Our goal is to increase the Android and Pixel security. 69.94s - 75.34s | And we do this by simulating adversaries attacking 75.34s - 77.34s | Android key features. 77.34s - 81.78s | And our work can be broken down into a couple of different ways. 81.78s - 85.50s | Most obviously, we do offensive security research review 85.50s - 89.50s | to verify our breaking security assumptions, which 89.50s - 91.82s | means finding bugs. 91.82s - 94.78s | And we scale our work by developing 94.78s - 100.38s | tools such as continuous fuzzing or static analysis. 100.38s - 105.02s | And once we find issues, we develop proof of concept 105.02s - 107.94s | just to show the real world impact, 107.94s - 110.58s | as some issues are not so straightforward 110.58s - 113.30s | to see their impact. 113.30s - 116.38s | Lastly, while we are developing the exploits, 116.38s - 118.50s | we're also assessing the efficacy 118.50s - 120.82s | of the security mitigations that our feature 120.82s - 124.58s | team implemented. 124.58s - 128.30s | The more pain we experience during our work, 128.30s - 131.66s | the more security our end user will gain. 131.66s - 134.98s | So we are literally making our work harder 134.98s - 139.91s | to help end users. 139.91s - 141.71s | So here's today's agenda. 141.71s - 146.03s | We'll first talk about the GPU and security background. 146.03s - 149.07s | And then we'll go through the Qualcomm Adrena


chunk_id: 186_chunk_3
chunk_text:
review 85.50s - 89.50s | to verify our breaking security assumptions, which 89.50s - 91.82s | means finding bugs. 91.82s - 94.78s | And we scale our work by developing 94.78s - 100.38s | tools such as continuous fuzzing or static analysis. 100.38s - 105.02s | And once we find issues, we develop proof of concept 105.02s - 107.94s | just to show the real world impact, 107.94s - 110.58s | as some issues are not so straightforward 110.58s - 113.30s | to see their impact. 113.30s - 116.38s | Lastly, while we are developing the exploits, 116.38s - 118.50s | we're also assessing the efficacy 118.50s - 120.82s | of the security mitigations that our feature 120.82s - 124.58s | team implemented. 124.58s - 128.30s | The more pain we experience during our work, 128.30s - 131.66s | the more security our end user will gain. 131.66s - 134.98s | So we are literally making our work harder 134.98s - 139.91s | to help end users. 139.91s - 141.71s | So here's today's agenda. 141.71s - 146.03s | We'll first talk about the GPU and security background. 146.03s - 149.07s | And then we'll go through the Qualcomm Adrena GPU 149.07s - 151.71s | introduction, talking about its architecture 151.71s - 153.91s | and where the issue patterns are. 153.91s - 157.19s | And then we'll dive into very technical details 157.19s - 160.91s | for the CVE-2024-23380 and how we 160.91s - 164.43s | exploit to gain root privilege. 164.43s - 167.55s | Lastly, we'll conclude our talk with the methodology 167.55s - 172.42s | discussions. 172.42s - 177.94s | So before we jump into engagement, 177.94s - 180.50s | usually we need to ask ourselves questions. 180.50s - 182.70s | Why do we look into this one? 182.70s - 186.26s | The reason is that, compared to the Android ecosystem, 186.26s - 188.62s | our team is very small. 188.62s - 193.86s | So we want to spend our time into the most impactful areas. 193.86s - 196.06s | So why GPU drivers? 196.06s - 199.06s | Here, we think these are the answers to that question. 199.06s - 202.30s | The biggest one is there is no permission 202.30s - 207.86s | required for applications to look into GPU driver. 207.86s - 210.16s | On the right side, you can see a diagram. 210.16s - 212.76s


chunk_id: 186_chunk_4
chunk_text:
GPU 149.07s - 151.71s | introduction, talking about its architecture 151.71s - 153.91s | and where the issue patterns are. 153.91s - 157.19s | And then we'll dive into very technical details 157.19s - 160.91s | for the CVE-2024-23380 and how we 160.91s - 164.43s | exploit to gain root privilege. 164.43s - 167.55s | Lastly, we'll conclude our talk with the methodology 167.55s - 172.42s | discussions. 172.42s - 177.94s | So before we jump into engagement, 177.94s - 180.50s | usually we need to ask ourselves questions. 180.50s - 182.70s | Why do we look into this one? 182.70s - 186.26s | The reason is that, compared to the Android ecosystem, 186.26s - 188.62s | our team is very small. 188.62s - 193.86s | So we want to spend our time into the most impactful areas. 193.86s - 196.06s | So why GPU drivers? 196.06s - 199.06s | Here, we think these are the answers to that question. 199.06s - 202.30s | The biggest one is there is no permission 202.30s - 207.86s | required for applications to look into GPU driver. 207.86s - 210.16s | On the right side, you can see a diagram. 210.16s - 212.76s | And the unprivileged applications, 212.76s - 216.04s | whatever user space library they call OpenGL, Vulkan, 216.04s - 220.68s | anything else, those libraries talk into the device node 220.68s - 223.96s | directly in the application's process. 223.96s - 226.44s | So that means this device driver has to be 226.44s - 228.44s | exposed to the application. 228.44s - 230.80s | So no permission required. 230.80s - 233.36s | This is the biggest problem. 233.36s - 237.68s | And this is why researchers love GPU drivers. 237.68s - 242.88s | Next one, GPU driver performance is the key. 242.88s - 246.52s | And because of that, they need to have some powerful functions 246.52s - 248.60s | to do this. 248.60s - 250.96s | The most important one is that they usually 250.96s - 254.00s | have access to the system physical RAMs 254.00s - 257.28s | and so that they can map in memories from user space 257.28s - 261.72s | to kernel space and to the hardware without copying them. 261.72s - 263.92s | This is a very powerful primitive, 263.92s - 266.64s | and attackers want them. 266.64s - 270.00s | We'll explain more


chunk_id: 186_chunk_5
chunk_text:
| And the unprivileged applications, 212.76s - 216.04s | whatever user space library they call OpenGL, Vulkan, 216.04s - 220.68s | anything else, those libraries talk into the device node 220.68s - 223.96s | directly in the application's process. 223.96s - 226.44s | So that means this device driver has to be 226.44s - 228.44s | exposed to the application. 228.44s - 230.80s | So no permission required. 230.80s - 233.36s | This is the biggest problem. 233.36s - 237.68s | And this is why researchers love GPU drivers. 237.68s - 242.88s | Next one, GPU driver performance is the key. 242.88s - 246.52s | And because of that, they need to have some powerful functions 246.52s - 248.60s | to do this. 248.60s - 250.96s | The most important one is that they usually 250.96s - 254.00s | have access to the system physical RAMs 254.00s - 257.28s | and so that they can map in memories from user space 257.28s - 261.72s | to kernel space and to the hardware without copying them. 261.72s - 263.92s | This is a very powerful primitive, 263.92s - 266.64s | and attackers want them. 266.64s - 270.00s | We'll explain more later why it's powerful. 270.00s - 274.20s | And lastly, again, because of the performance requirement, 274.20s - 279.08s | this involves high complexity code in the GPU driver. 279.08s - 282.60s | And because of that, it's really, really hard 282.60s - 284.36s | to develop bug-free code. 284.36s - 286.96s | I'm not sure if anybody here write bug-free code. 286.96s - 288.80s | Raise your hand if you did. 288.80s - 291.92s | Wow, very brave. 291.92s - 295.42s | Anyway, and it's even harder to fix an issue. 295.42s - 298.66s | And it's very common that you fix an issue, 298.66s - 300.86s | but it's not 100% fixed. 300.86s - 303.02s | There's still something left over. 303.02s - 306.06s | And oh, even worse, you fixed one issue, 306.06s - 311.43s | and you introduced another new issue, or two issues. 311.43s - 314.21s | So this high complexity is another reason 314.21s - 317.79s | one look into this area. 317.79s - 322.19s | But why Qualcomm GPU? 322.19s - 328.01s | Hello? 328.01s - 345.41s | There's an audio problem. 345.41s - 345.97s | Hello? 345.97s - 348.49s | Hello? 348.49s


chunk_id: 186_chunk_6
chunk_text:
later why it's powerful. 270.00s - 274.20s | And lastly, again, because of the performance requirement, 274.20s - 279.08s | this involves high complexity code in the GPU driver. 279.08s - 282.60s | And because of that, it's really, really hard 282.60s - 284.36s | to develop bug-free code. 284.36s - 286.96s | I'm not sure if anybody here write bug-free code. 286.96s - 288.80s | Raise your hand if you did. 288.80s - 291.92s | Wow, very brave. 291.92s - 295.42s | Anyway, and it's even harder to fix an issue. 295.42s - 298.66s | And it's very common that you fix an issue, 298.66s - 300.86s | but it's not 100% fixed. 300.86s - 303.02s | There's still something left over. 303.02s - 306.06s | And oh, even worse, you fixed one issue, 306.06s - 311.43s | and you introduced another new issue, or two issues. 311.43s - 314.21s | So this high complexity is another reason 314.21s - 317.79s | one look into this area. 317.79s - 322.19s | But why Qualcomm GPU? 322.19s - 328.01s | Hello? 328.01s - 345.41s | There's an audio problem. 345.41s - 345.97s | Hello? 345.97s - 348.49s | Hello? 348.49s - 349.29s | I can use this one. 349.29s - 349.79s | All right. 349.79s - 350.29s | All right. 355.10s - 359.86s | OK, we have issues, so we fix them. 359.86s - 362.14s | So why Qualcomm? 362.14s - 365.30s | Qualcomm is one of the most important smartphone SoC 365.30s - 369.90s | vendors, and many devices use the Qualcomm SoCs. 369.90s - 374.70s | And on those SoCs, Adreno GPU is the one used the most. 374.70s - 379.62s | And last one is, this applies to all GPUs, 379.62s - 384.78s | that GPU is a very actively developing area because 384.98s - 386.94s | all the requirements, all the games 386.94s - 391.66s | keep having high resolutions, faster speed, faster FPS. 391.66s - 393.98s | So there's lots of development happening 393.98s - 398.46s | that involves revolutions in the architecture, hardware, 398.46s - 399.62s | software. 399.62s - 402.94s | And coincidentally, we noticed that there 402.94s - 407.02s | is a new architecture recently in the Qualcomm GPU. 407.02s - 411.10s | New architecture, new software means new bugs. 411.10s - 414.26s | So we want to take a look and


chunk_id: 186_chunk_7
chunk_text:
- 349.29s | I can use this one. 349.29s - 349.79s | All right. 349.79s - 350.29s | All right. 355.10s - 359.86s | OK, we have issues, so we fix them. 359.86s - 362.14s | So why Qualcomm? 362.14s - 365.30s | Qualcomm is one of the most important smartphone SoC 365.30s - 369.90s | vendors, and many devices use the Qualcomm SoCs. 369.90s - 374.70s | And on those SoCs, Adreno GPU is the one used the most. 374.70s - 379.62s | And last one is, this applies to all GPUs, 379.62s - 384.78s | that GPU is a very actively developing area because 384.98s - 386.94s | all the requirements, all the games 386.94s - 391.66s | keep having high resolutions, faster speed, faster FPS. 391.66s - 393.98s | So there's lots of development happening 393.98s - 398.46s | that involves revolutions in the architecture, hardware, 398.46s - 399.62s | software. 399.62s - 402.94s | And coincidentally, we noticed that there 402.94s - 407.02s | is a new architecture recently in the Qualcomm GPU. 407.02s - 411.10s | New architecture, new software means new bugs. 411.10s - 414.26s | So we want to take a look and see what's the difference, 414.26s - 419.44s | and is there any issues there. 419.44s - 424.84s | And another study we did before we look into our source code, 424.84s - 427.36s | I mean, not our source, Qualcomm source code, 427.36s - 431.24s | is to check the security bulletins 431.24s - 434.08s | and understand any historical issues. 434.08s - 435.84s | And here's a chart that we manually 435.84s - 439.92s | created from the Qualcomm security bulletin. 439.92s - 442.84s | The size of the bars might look a little bit scary, 442.84s - 445.64s | but you can see the numbers actually are single digits. 446.08s - 450.36s | There's not a lot of issues, but my point here 450.36s - 454.12s | is that you can see this is more like constant issues 454.12s - 456.88s | happening every quarter. 456.88s - 460.16s | So this chart gives us a little bit of confidence 460.16s - 465.76s | that if we look into the code, we might as well find issues. 465.76s - 467.64s | Oh, by the way, I forgot to mention, 467.64s - 470.68s | all our work is based on


chunk_id: 186_chunk_8
chunk_text:
see what's the difference, 414.26s - 419.44s | and is there any issues there. 419.44s - 424.84s | And another study we did before we look into our source code, 424.84s - 427.36s | I mean, not our source, Qualcomm source code, 427.36s - 431.24s | is to check the security bulletins 431.24s - 434.08s | and understand any historical issues. 434.08s - 435.84s | And here's a chart that we manually 435.84s - 439.92s | created from the Qualcomm security bulletin. 439.92s - 442.84s | The size of the bars might look a little bit scary, 442.84s - 445.64s | but you can see the numbers actually are single digits. 446.08s - 450.36s | There's not a lot of issues, but my point here 450.36s - 454.12s | is that you can see this is more like constant issues 454.12s - 456.88s | happening every quarter. 456.88s - 460.16s | So this chart gives us a little bit of confidence 460.16s - 465.76s | that if we look into the code, we might as well find issues. 465.76s - 467.64s | Oh, by the way, I forgot to mention, 467.64s - 470.68s | all our work is based on the open source Qualcomm drivers. 470.68s - 472.24s | So everything is public. 472.24s - 476.33s | There's no private information involved. 476.33s - 479.41s | Among all those issues, there are quite some high profile 479.41s - 484.17s | issues disclosed and talked by previous security researchers. 484.17s - 489.13s | These talks are great, and we learn a lot from the talks. 489.13s - 491.57s | Really big credit to them for helping 491.57s - 497.37s | us to jump into an area we never looked at before. 497.37s - 500.81s | And now we look back into the just recent three months. 500.81s - 504.17s | Here are all the issues reported to Qualcomm, 504.17s - 508.09s | disclosed by Qualcomm security bulletin. 508.09s - 512.09s | Our security researcher, Xilin, did a little bit analysis 512.09s - 515.73s | and focused on the last two columns. 515.73s - 519.17s | You can see the tech area, mostly many of the issues 519.17s - 522.05s | are focusing on IOMMUs. 522.05s - 524.05s | That matches to our previous assumption 524.05s - 527.29s | that, OK, physical memory is the key. 527.29s - 532.53s | And also,


chunk_id: 186_chunk_9
chunk_text:
the open source Qualcomm drivers. 470.68s - 472.24s | So everything is public. 472.24s - 476.33s | There's no private information involved. 476.33s - 479.41s | Among all those issues, there are quite some high profile 479.41s - 484.17s | issues disclosed and talked by previous security researchers. 484.17s - 489.13s | These talks are great, and we learn a lot from the talks. 489.13s - 491.57s | Really big credit to them for helping 491.57s - 497.37s | us to jump into an area we never looked at before. 497.37s - 500.81s | And now we look back into the just recent three months. 500.81s - 504.17s | Here are all the issues reported to Qualcomm, 504.17s - 508.09s | disclosed by Qualcomm security bulletin. 508.09s - 512.09s | Our security researcher, Xilin, did a little bit analysis 512.09s - 515.73s | and focused on the last two columns. 515.73s - 519.17s | You can see the tech area, mostly many of the issues 519.17s - 522.05s | are focusing on IOMMUs. 522.05s - 524.05s | That matches to our previous assumption 524.05s - 527.29s | that, OK, physical memory is the key. 527.29s - 532.53s | And also, very subjective, but based on Xilin's experience, 532.53s - 536.05s | most of the issues are easy to exploit. 536.05s - 540.37s | And once exploited, they are pretty stable. 540.37s - 542.69s | Attackers want the stabilities. 542.69s - 546.90s | They want their code to be good. 546.90s - 549.06s | So over the course of our engagement, 549.06s - 553.06s | Xilin has identified more than nine issues. 553.06s - 556.42s | We report all the issues to Qualcomm immediately. 556.42s - 560.70s | And today, we're going to talk about CVE-2024-23380. 560.70s - 563.22s | This is one of the issues we reported. 563.22s - 566.38s | This issue has been patched and published 566.38s - 569.14s | in the security bulletin of July 2024. 569.14s - 572.18s | And Qualcomm communicated to all the device vendors 572.18s - 575.42s | in April before the disclosure. 575.42s - 578.62s | So go to their security bulletins. 578.62s - 580.86s | You can see what's affecting devices. 580.86s - 583.58s | But don't worry if your device is affected. 583.58s - 585.22s | And check your security patch level. 585.22s - 588.94s | If it's July or


chunk_id: 186_chunk_10
chunk_text:
very subjective, but based on Xilin's experience, 532.53s - 536.05s | most of the issues are easy to exploit. 536.05s - 540.37s | And once exploited, they are pretty stable. 540.37s - 542.69s | Attackers want the stabilities. 542.69s - 546.90s | They want their code to be good. 546.90s - 549.06s | So over the course of our engagement, 549.06s - 553.06s | Xilin has identified more than nine issues. 553.06s - 556.42s | We report all the issues to Qualcomm immediately. 556.42s - 560.70s | And today, we're going to talk about CVE-2024-23380. 560.70s - 563.22s | This is one of the issues we reported. 563.22s - 566.38s | This issue has been patched and published 566.38s - 569.14s | in the security bulletin of July 2024. 569.14s - 572.18s | And Qualcomm communicated to all the device vendors 572.18s - 575.42s | in April before the disclosure. 575.42s - 578.62s | So go to their security bulletins. 578.62s - 580.86s | You can see what's affecting devices. 580.86s - 583.58s | But don't worry if your device is affected. 583.58s - 585.22s | And check your security patch level. 585.22s - 588.94s | If it's July or later, it's fixed. 588.94s - 592.06s | And from here, I'll hand over to Xilin 592.06s - 594.46s | to talk about technical details and how we 594.46s - 599.42s | exploit to gain root privilege. 599.42s - 602.20s | XILIN LIU. 602.20s - 604.44s | Yeah, thank you, Xilin. 604.44s - 613.44s | So I'll quickly introduce the basic knowledge of Andrino GPU. 613.44s - 616.44s | So here is the basic architecture. 616.44s - 620.84s | You can see in the middle is the KGSL driver, 620.84s - 624.68s | which is a glue between the user space and the hardware. 624.68s - 627.88s | So from the perspective of the user space, 627.88s - 631.40s | we will have a set of interfaces. 631.40s - 633.80s | The first one is a context, which 633.80s - 638.28s | is used to identify user space application 638.28s - 643.08s | and also to manage the GPU driver or hardware resources. 643.08s - 644.88s | And also, the user space maybe want 644.88s - 648.04s | to share memory with the GPU hardware. 648.04s - 650.48s | So we will have memory interfaces. 650.48s - 652.40s | There are


chunk_id: 186_chunk_11
chunk_text:
later, it's fixed. 588.94s - 592.06s | And from here, I'll hand over to Xilin 592.06s - 594.46s | to talk about technical details and how we 594.46s - 599.42s | exploit to gain root privilege. 599.42s - 602.20s | XILIN LIU. 602.20s - 604.44s | Yeah, thank you, Xilin. 604.44s - 613.44s | So I'll quickly introduce the basic knowledge of Andrino GPU. 613.44s - 616.44s | So here is the basic architecture. 616.44s - 620.84s | You can see in the middle is the KGSL driver, 620.84s - 624.68s | which is a glue between the user space and the hardware. 624.68s - 627.88s | So from the perspective of the user space, 627.88s - 631.40s | we will have a set of interfaces. 631.40s - 633.80s | The first one is a context, which 633.80s - 638.28s | is used to identify user space application 638.28s - 643.08s | and also to manage the GPU driver or hardware resources. 643.08s - 644.88s | And also, the user space maybe want 644.88s - 648.04s | to share memory with the GPU hardware. 648.04s - 650.48s | So we will have memory interfaces. 650.48s - 652.40s | There are three types of memory. 652.40s - 656.32s | The basic memory, the user space memory, the DMA memory. 656.32s - 659.44s | And previously, we also have the sparse memory. 659.44s - 664.48s | But now, this sparse memory already not used anymore. 664.48s - 668.12s | And the user space also want to send the customer GPU 668.12s - 669.92s | commands to the GPU hardware. 669.92s - 673.52s | So we will have some commands interfaces. 673.52s - 676.40s | And also, the user space want to get 676.40s - 678.44s | synced with the GPU hardware. 678.44s - 681.76s | So we will have synchronization interfaces. 681.76s - 685.84s | To accomplish these tasks in the GPU driver, 685.84s - 688.20s | we will have a command queue, which 688.20s - 691.32s | receives commands from the user space. 691.32s - 693.88s | And then the software dispatcher will 693.88s - 696.52s | get the command from the queue and add 696.52s - 702.20s | the necessary informations and maybe modify the GPU command 702.20s - 704.92s | and then send them to the ring buffer. 704.92s - 708.00s | There is a simple firmware in the


chunk_id: 186_chunk_12
chunk_text:
three types of memory. 652.40s - 656.32s | The basic memory, the user space memory, the DMA memory. 656.32s - 659.44s | And previously, we also have the sparse memory. 659.44s - 664.48s | But now, this sparse memory already not used anymore. 664.48s - 668.12s | And the user space also want to send the customer GPU 668.12s - 669.92s | commands to the GPU hardware. 669.92s - 673.52s | So we will have some commands interfaces. 673.52s - 676.40s | And also, the user space want to get 676.40s - 678.44s | synced with the GPU hardware. 678.44s - 681.76s | So we will have synchronization interfaces. 681.76s - 685.84s | To accomplish these tasks in the GPU driver, 685.84s - 688.20s | we will have a command queue, which 688.20s - 691.32s | receives commands from the user space. 691.32s - 693.88s | And then the software dispatcher will 693.88s - 696.52s | get the command from the queue and add 696.52s - 702.20s | the necessary informations and maybe modify the GPU command 702.20s - 704.92s | and then send them to the ring buffer. 704.92s - 708.00s | There is a simple firmware in the GPU hardware, 708.00s - 711.48s | which will receive commands from the ring buffer 711.48s - 713.52s | and send the command to the hardware. 713.52s - 718.68s | So GPU customer commands will be run in the GPU hardware. 718.68s - 722.16s | Also, we will have something like the global buffer, 722.16s - 726.16s | the registers to control the GPU hardware. 726.16s - 728.08s | For memory management, we will have 728.08s - 732.28s | a memory pool and MMU for the user space memory 732.28s - 738.16s | and IOMMU for control the GPU memory. 738.16s - 741.04s | So this is the new architecture starting 741.08s - 745.72s | from generation seven in the later generation. 745.72s - 750.48s | You can see we have lots of new stuff in red color. 750.48s - 753.76s | The most important change is the software dispatcher 753.76s - 756.44s | is replaced by the hardware scheduler, which 756.44s - 761.44s | means the GPU command comes from the user space. 761.44s - 763.64s | We are not to be sent to the ring buffer directly 763.64s - 765.12s | by the driver. 765.12s - 768.48s | The


chunk_id: 186_chunk_13
chunk_text:
GPU hardware, 708.00s - 711.48s | which will receive commands from the ring buffer 711.48s - 713.52s | and send the command to the hardware. 713.52s - 718.68s | So GPU customer commands will be run in the GPU hardware. 718.68s - 722.16s | Also, we will have something like the global buffer, 722.16s - 726.16s | the registers to control the GPU hardware. 726.16s - 728.08s | For memory management, we will have 728.08s - 732.28s | a memory pool and MMU for the user space memory 732.28s - 738.16s | and IOMMU for control the GPU memory. 738.16s - 741.04s | So this is the new architecture starting 741.08s - 745.72s | from generation seven in the later generation. 745.72s - 750.48s | You can see we have lots of new stuff in red color. 750.48s - 753.76s | The most important change is the software dispatcher 753.76s - 756.44s | is replaced by the hardware scheduler, which 756.44s - 761.44s | means the GPU command comes from the user space. 761.44s - 763.64s | We are not to be sent to the ring buffer directly 763.64s - 765.12s | by the driver. 765.12s - 768.48s | The driver will not touch the ring buffer anymore. 768.48s - 772.76s | Instead, the driver will send this command directly 772.76s - 774.96s | to a HiFi command queue. 774.96s - 778.24s | So there is a simple firmware. 778.24s - 783.52s | And this firmware will take over and finish the job previously 783.52s - 785.28s | finished by the driver. 785.28s - 789.12s | So a lot of software dispatcher jobs 789.12s - 791.32s | will be moved to the firmware. 791.32s - 793.80s | So we don't have the source code of the firmware. 793.80s - 798.04s | So I can just guess that this job previously 798.04s - 800.28s | finished by the software dispatcher 800.28s - 801.88s | will move to the firmware. 801.88s - 807.00s | But how it works and whether there are any vulnerabilities, 807.00s - 809.04s | I have no idea now. 809.04s - 813.20s | And also to coordinate with these new features, 813.20s - 817.28s | some other new features like the hardware fence is added. 817.28s - 819.96s | Previously, we only have the software fence. 819.96s - 822.64s | Now we also have hardware fence. 822.64s -


chunk_id: 186_chunk_14
chunk_text:
driver will not touch the ring buffer anymore. 768.48s - 772.76s | Instead, the driver will send this command directly 772.76s - 774.96s | to a HiFi command queue. 774.96s - 778.24s | So there is a simple firmware. 778.24s - 783.52s | And this firmware will take over and finish the job previously 783.52s - 785.28s | finished by the driver. 785.28s - 789.12s | So a lot of software dispatcher jobs 789.12s - 791.32s | will be moved to the firmware. 791.32s - 793.80s | So we don't have the source code of the firmware. 793.80s - 798.04s | So I can just guess that this job previously 798.04s - 800.28s | finished by the software dispatcher 800.28s - 801.88s | will move to the firmware. 801.88s - 807.00s | But how it works and whether there are any vulnerabilities, 807.00s - 809.04s | I have no idea now. 809.04s - 813.20s | And also to coordinate with these new features, 813.20s - 817.28s | some other new features like the hardware fence is added. 817.28s - 819.96s | Previously, we only have the software fence. 819.96s - 822.64s | Now we also have hardware fence. 822.64s - 826.96s | There, we introduce a lot of new code, new features, 826.96s - 830.96s | and also a new hardware fence queue and new hardware fence 830.96s - 831.84s | event here. 834.48s - 838.20s | For the memory, we will have a new virtual buffer object. 838.20s - 840.76s | You can see here, this is a new VBO. 840.76s - 843.68s | And the previously ARM, IOMMU, you 843.68s - 846.92s | will replace it by the Qualcomm-owned IOMMU. 846.92s - 850.56s | So these new features will, of course, 850.56s - 852.76s | enhance the GPU capability. 852.76s - 860.19s | But also, we introduce lots of new attack surface. 860.19s - 864.31s | If you want to look into some new vulnerability, 864.31s - 867.83s | you can start from the new features. 867.83s - 870.79s | Here, I'll also introduce the memory management. 870.79s - 874.23s | You can see here is the basic memory management 874.23s - 876.19s | called a basic memory object. 876.19s - 878.07s | So it's used in most of the cases 878.07s - 881.91s | you want to share some memory to the GPU from the user space.


chunk_id: 186_chunk_15
chunk_text:
826.96s | There, we introduce a lot of new code, new features, 826.96s - 830.96s | and also a new hardware fence queue and new hardware fence 830.96s - 831.84s | event here. 834.48s - 838.20s | For the memory, we will have a new virtual buffer object. 838.20s - 840.76s | You can see here, this is a new VBO. 840.76s - 843.68s | And the previously ARM, IOMMU, you 843.68s - 846.92s | will replace it by the Qualcomm-owned IOMMU. 846.92s - 850.56s | So these new features will, of course, 850.56s - 852.76s | enhance the GPU capability. 852.76s - 860.19s | But also, we introduce lots of new attack surface. 860.19s - 864.31s | If you want to look into some new vulnerability, 864.31s - 867.83s | you can start from the new features. 867.83s - 870.79s | Here, I'll also introduce the memory management. 870.79s - 874.23s | You can see here is the basic memory management 874.23s - 876.19s | called a basic memory object. 876.19s - 878.07s | So it's used in most of the cases 878.07s - 881.91s | you want to share some memory to the GPU from the user space. 882.75s - 885.03s | You request a basic memory object. 885.03s - 885.99s | It's a basic. 885.99s - 888.27s | So it's used in most of the cases. 888.27s - 889.91s | You call this our control. 889.91s - 892.87s | And then you set a parameter to tell the driver 892.87s - 895.19s | how much physical pages you want. 895.19s - 897.75s | Then the driver will allocate this number 897.75s - 899.59s | of physical pages for you. 899.59s - 902.15s | And then the second step, the driver 902.15s - 906.71s | will allocate address range in the GPU virtual address space. 906.71s - 911.07s | So you can see here, we have this virtual GPU address. 911.07s - 915.95s | And then the GPU driver will set this physical to virtual 915.95s - 917.23s | mapping for you. 917.23s - 920.51s | So at this time, the GPU hardware 920.51s - 924.15s | will be able to access to the physical page using this GPU 924.15s - 926.03s | virtual address. 926.03s - 928.39s | And in most of the cases, the user space 928.39s - 931.67s | will also want to access to


chunk_id: 186_chunk_16
chunk_text:
882.75s - 885.03s | You request a basic memory object. 885.03s - 885.99s | It's a basic. 885.99s - 888.27s | So it's used in most of the cases. 888.27s - 889.91s | You call this our control. 889.91s - 892.87s | And then you set a parameter to tell the driver 892.87s - 895.19s | how much physical pages you want. 895.19s - 897.75s | Then the driver will allocate this number 897.75s - 899.59s | of physical pages for you. 899.59s - 902.15s | And then the second step, the driver 902.15s - 906.71s | will allocate address range in the GPU virtual address space. 906.71s - 911.07s | So you can see here, we have this virtual GPU address. 911.07s - 915.95s | And then the GPU driver will set this physical to virtual 915.95s - 917.23s | mapping for you. 917.23s - 920.51s | So at this time, the GPU hardware 920.51s - 924.15s | will be able to access to the physical page using this GPU 924.15s - 926.03s | virtual address. 926.03s - 928.39s | And in most of the cases, the user space 928.39s - 931.67s | will also want to access to the physical page. 931.67s - 935.39s | So the user space will do memory map 935.39s - 937.51s | on this basic memory object. 937.51s - 939.51s | And then the driver will help you 939.51s - 944.19s | to set up the physical page to virtual mapping, 944.19s - 945.67s | so through the MMU. 945.67s - 948.75s | So at this time, the physical page 948.75s - 952.75s | can be accessed from both the GPU hardware and the user 952.75s - 953.79s | space. 953.79s - 955.87s | So that's the basic memory object. 955.87s - 958.63s | The driver will manage all the objects in the kernel 958.63s - 962.91s | and also manage the back-end physical memory. 962.91s - 965.87s | And here is the second type of memory object. 965.87s - 967.95s | It's called the user space memory. 967.95s - 971.55s | So suppose you already have a user space memory. 971.55s - 973.19s | You have a back-end physical memory. 973.19s - 976.23s | You can use this user space memory object 976.23s - 981.83s | to import memory from the user space into the GPU hardware. 981.83s - 984.51s | And


chunk_id: 186_chunk_17
chunk_text:
the physical page. 931.67s - 935.39s | So the user space will do memory map 935.39s - 937.51s | on this basic memory object. 937.51s - 939.51s | And then the driver will help you 939.51s - 944.19s | to set up the physical page to virtual mapping, 944.19s - 945.67s | so through the MMU. 945.67s - 948.75s | So at this time, the physical page 948.75s - 952.75s | can be accessed from both the GPU hardware and the user 952.75s - 953.79s | space. 953.79s - 955.87s | So that's the basic memory object. 955.87s - 958.63s | The driver will manage all the objects in the kernel 958.63s - 962.91s | and also manage the back-end physical memory. 962.91s - 965.87s | And here is the second type of memory object. 965.87s - 967.95s | It's called the user space memory. 967.95s - 971.55s | So suppose you already have a user space memory. 971.55s - 973.19s | You have a back-end physical memory. 973.19s - 976.23s | You can use this user space memory object 976.23s - 981.83s | to import memory from the user space into the GPU hardware. 981.83s - 984.51s | And here is the third type of memory. 984.51s - 986.95s | It's called a virtual buffer object. 986.95s - 992.55s | From the name virtual, you maybe guess that it's virtual. 992.55s - 995.27s | So for this type of memory, it doesn't 995.27s - 999.23s | have its own back-end physical memory. 999.23s - 1002.43s | So you call this out control with this flag. 1002.43s - 1007.07s | Then the driver will simply allocate a GPU virtual address 1007.07s - 1008.07s | for you. 1008.07s - 1011.51s | And then it will map this virtual address 1011.51s - 1013.35s | to a dummy zero page. 1013.35s - 1015.27s | So it's a dummy zero page. 1015.27s - 1018.03s | It's just a placeholder. 1018.03s - 1021.59s | Of course, you can access it to the virtual memory 1021.59s - 1022.71s | in the GPU hardware. 1022.71s - 1023.91s | But it's no effect. 1023.91s - 1026.83s | Whatever you read or write will have no effect. 1026.83s - 1028.83s | It's just a zero page. 1028.83s - 1030.15s | It will have no effect. 1030.15s - 1033.51s | So how to use this virtual buffer object? 1033.51s -


chunk_id: 186_chunk_18
chunk_text:
here is the third type of memory. 984.51s - 986.95s | It's called a virtual buffer object. 986.95s - 992.55s | From the name virtual, you maybe guess that it's virtual. 992.55s - 995.27s | So for this type of memory, it doesn't 995.27s - 999.23s | have its own back-end physical memory. 999.23s - 1002.43s | So you call this out control with this flag. 1002.43s - 1007.07s | Then the driver will simply allocate a GPU virtual address 1007.07s - 1008.07s | for you. 1008.07s - 1011.51s | And then it will map this virtual address 1011.51s - 1013.35s | to a dummy zero page. 1013.35s - 1015.27s | So it's a dummy zero page. 1015.27s - 1018.03s | It's just a placeholder. 1018.03s - 1021.59s | Of course, you can access it to the virtual memory 1021.59s - 1022.71s | in the GPU hardware. 1022.71s - 1023.91s | But it's no effect. 1023.91s - 1026.83s | Whatever you read or write will have no effect. 1026.83s - 1028.83s | It's just a zero page. 1028.83s - 1030.15s | It will have no effect. 1030.15s - 1033.51s | So how to use this virtual buffer object? 1033.51s - 1039.63s | You can actually map a basic memory object into this VBO. 1039.63s - 1044.67s | So suppose you already have two basic memory object, A and B. 1044.67s - 1048.47s | Both of them have their own back-end physical memory. 1048.47s - 1052.69s | You can bind these two basic memory object into this VBO. 1052.69s - 1055.45s | So you call this bindRangeOutControl. 1055.45s - 1057.73s | Then the driver will do the work. 1057.73s - 1061.05s | The first step, the driver will remove any existing 1061.05s - 1063.05s | mapping from the VBO. 1063.05s - 1066.33s | Here, we already mapped the zero page to the VBO. 1066.33s - 1068.45s | So this mapping will be removed. 1068.45s - 1072.05s | If you have previously mapped any other basic memory 1072.05s - 1077.73s | object to this VBO, so this map will also be removed. 1077.73s - 1081.49s | So the first step, we will remove any existing mapping 1081.49s - 1082.97s | from the VBO. 1082.97s - 1085.33s | And then we will get a connection 1085.33s - 1089.93s | between this basic memory object and the VBO. 1089.93s - 1093.37s | So the


chunk_id: 186_chunk_19
chunk_text:
1039.63s | You can actually map a basic memory object into this VBO. 1039.63s - 1044.67s | So suppose you already have two basic memory object, A and B. 1044.67s - 1048.47s | Both of them have their own back-end physical memory. 1048.47s - 1052.69s | You can bind these two basic memory object into this VBO. 1052.69s - 1055.45s | So you call this bindRangeOutControl. 1055.45s - 1057.73s | Then the driver will do the work. 1057.73s - 1061.05s | The first step, the driver will remove any existing 1061.05s - 1063.05s | mapping from the VBO. 1063.05s - 1066.33s | Here, we already mapped the zero page to the VBO. 1066.33s - 1068.45s | So this mapping will be removed. 1068.45s - 1072.05s | If you have previously mapped any other basic memory 1072.05s - 1077.73s | object to this VBO, so this map will also be removed. 1077.73s - 1081.49s | So the first step, we will remove any existing mapping 1081.49s - 1082.97s | from the VBO. 1082.97s - 1085.33s | And then we will get a connection 1085.33s - 1089.93s | between this basic memory object and the VBO. 1089.93s - 1093.37s | So the driver will know that there is a connection. 1093.37s - 1096.57s | Somebody is using this basic memory object. 1096.57s - 1099.33s | So this object cannot be freed. 1099.33s - 1100.93s | And also, the driver will help you 1100.93s - 1104.69s | to find out the physical memory page of this basic memory 1104.69s - 1105.73s | object. 1105.73s - 1110.45s | And then the driver will help you to set up this connection. 1111.37s - 1114.05s | Here is the physical memory to virtual mapping. 1114.05s - 1118.57s | We'll map this physical page into the VBO's region 1118.57s - 1121.49s | at a specified offset. 1121.49s - 1126.17s | And also, the driver will continue these two steps, 1126.17s - 1129.97s | find all the basic memory object you want, 1129.97s - 1132.97s | and get all the connections between the basic memory 1132.97s - 1134.65s | object and the VBO. 1134.65s - 1139.13s | And then map all the physical pages to this VBO. 1139.17s - 1144.81s | So that's the basic memory object binding to the VBO. 1144.81s - 1151.89s | It's very powerful and flexible, but also very vulnerable. 1151.89s - 1157.13s |


chunk_id: 186_chunk_20
chunk_text:
driver will know that there is a connection. 1093.37s - 1096.57s | Somebody is using this basic memory object. 1096.57s - 1099.33s | So this object cannot be freed. 1099.33s - 1100.93s | And also, the driver will help you 1100.93s - 1104.69s | to find out the physical memory page of this basic memory 1104.69s - 1105.73s | object. 1105.73s - 1110.45s | And then the driver will help you to set up this connection. 1111.37s - 1114.05s | Here is the physical memory to virtual mapping. 1114.05s - 1118.57s | We'll map this physical page into the VBO's region 1118.57s - 1121.49s | at a specified offset. 1121.49s - 1126.17s | And also, the driver will continue these two steps, 1126.17s - 1129.97s | find all the basic memory object you want, 1129.97s - 1132.97s | and get all the connections between the basic memory 1132.97s - 1134.65s | object and the VBO. 1134.65s - 1139.13s | And then map all the physical pages to this VBO. 1139.17s - 1144.81s | So that's the basic memory object binding to the VBO. 1144.81s - 1151.89s | It's very powerful and flexible, but also very vulnerable. 1151.89s - 1157.13s | You can see here we have this CVE-2024-23380, 1157.13s - 1162.73s | which happens when you bind a basic memory object into a VBO. 1162.73s - 1165.01s | So we will take a look at the code. 1165.01s - 1167.13s | You can see when we do the binding, 1167.13s - 1171.41s | we will get a connection between this basic memory 1171.41s - 1172.57s | object and the VBO. 1172.57s - 1175.61s | So the connection is finished by this function, 1175.61s - 1177.45s | intervalTreeInsert. 1177.45s - 1182.33s | So insert this basic memory object into the VBO. 1182.33s - 1188.49s | Then we will get a physical page and virtual address mapping. 1188.49s - 1192.85s | We will set up this mapping using this function, 1192.85s - 1195.93s | mmuMapChild. 1196.93s - 1200.93s | Of course, we will have to protect our global status. 1200.93s - 1205.93s | So we will use this mutex lock to protect the interval tree. 1205.93s - 1209.97s | So this interval tree is a global status. 1209.97s - 1212.05s | This will be protected by the lock. 1212.05s - 1214.73s | And when we finish, we will do unlock. 1214.73s -


chunk_id: 186_chunk_21
chunk_text:
You can see here we have this CVE-2024-23380, 1157.13s - 1162.73s | which happens when you bind a basic memory object into a VBO. 1162.73s - 1165.01s | So we will take a look at the code. 1165.01s - 1167.13s | You can see when we do the binding, 1167.13s - 1171.41s | we will get a connection between this basic memory 1171.41s - 1172.57s | object and the VBO. 1172.57s - 1175.61s | So the connection is finished by this function, 1175.61s - 1177.45s | intervalTreeInsert. 1177.45s - 1182.33s | So insert this basic memory object into the VBO. 1182.33s - 1188.49s | Then we will get a physical page and virtual address mapping. 1188.49s - 1192.85s | We will set up this mapping using this function, 1192.85s - 1195.93s | mmuMapChild. 1196.93s - 1200.93s | Of course, we will have to protect our global status. 1200.93s - 1205.93s | So we will use this mutex lock to protect the interval tree. 1205.93s - 1209.97s | So this interval tree is a global status. 1209.97s - 1212.05s | This will be protected by the lock. 1212.05s - 1214.73s | And when we finish, we will do unlock. 1214.73s - 1219.41s | And here, the vulnerabilities, this physical to virtual mapping 1219.41s - 1222.25s | is also a global resource, so it should also 1222.25s - 1224.33s | be protected by the lock. 1224.37s - 1227.13s | But you can see here, this physical to virtual mapping 1227.13s - 1229.09s | is outside of the lock. 1229.09s - 1233.61s | So it's possible, from the driver's perspective, 1233.61s - 1236.49s | we already have this basic memory object 1236.49s - 1238.93s | connected to the VBO. 1238.93s - 1241.41s | When we do the physical to virtual mapping, 1241.41s - 1245.01s | this connection might be removed by somebody else. 1245.01s - 1247.97s | So that's the vulnerability. 1247.97s - 1249.61s | Let's take a look at the fix. 1249.61s - 1253.41s | You can see the fix simply moves this physical 1253.41s - 1255.93s | to virtual mapping inside of the lock. 1255.93s - 1258.13s | It's very simple fix. 1258.13s - 1260.77s | It just protects this mapping. 1260.77s - 1263.53s | So that's the vulnerability. 1263.53s - 1266.69s | Let's take a look at how to trigger this vulnerability. 1266.69s - 1271.77s | We will need two


chunk_id: 186_chunk_22
chunk_text:
1219.41s | And here, the vulnerabilities, this physical to virtual mapping 1219.41s - 1222.25s | is also a global resource, so it should also 1222.25s - 1224.33s | be protected by the lock. 1224.37s - 1227.13s | But you can see here, this physical to virtual mapping 1227.13s - 1229.09s | is outside of the lock. 1229.09s - 1233.61s | So it's possible, from the driver's perspective, 1233.61s - 1236.49s | we already have this basic memory object 1236.49s - 1238.93s | connected to the VBO. 1238.93s - 1241.41s | When we do the physical to virtual mapping, 1241.41s - 1245.01s | this connection might be removed by somebody else. 1245.01s - 1247.97s | So that's the vulnerability. 1247.97s - 1249.61s | Let's take a look at the fix. 1249.61s - 1253.41s | You can see the fix simply moves this physical 1253.41s - 1255.93s | to virtual mapping inside of the lock. 1255.93s - 1258.13s | It's very simple fix. 1258.13s - 1260.77s | It just protects this mapping. 1260.77s - 1263.53s | So that's the vulnerability. 1263.53s - 1266.69s | Let's take a look at how to trigger this vulnerability. 1266.69s - 1271.77s | We will need two threads, one to the mapping, to the binding, 1271.77s - 1274.33s | binding a basic memory object to the VBO. 1274.33s - 1278.09s | And at the same time, somebody else do the unbinding. 1278.09s - 1279.53s | So look at the code. 1279.53s - 1281.69s | You can see, when do the binding, 1281.69s - 1283.77s | we are getting into this add range. 1283.77s - 1286.45s | This is the function we just read. 1286.45s - 1287.97s | You can see, we have the lock. 1287.97s - 1293.33s | We will insert the basic memory object into the VBO. 1293.33s - 1295.97s | Then we unlock and do the physical mapping. 1295.97s - 1299.53s | And another thread, you do the unbinding. 1299.53s - 1302.85s | You can see, it's just the reverse of the binding. 1302.85s - 1309.01s | You will have a lock, and then you remove the binding, 1309.01s - 1311.61s | and then you do the unlock. 1311.61s - 1314.45s | So here is how we trigger the vulnerability. 1314.45s - 1318.41s | We have two threads, thread A, running, and lock, 1318.41s - 1323.73s | and then undo the tree insert and do


chunk_id: 186_chunk_23
chunk_text:
threads, one to the mapping, to the binding, 1271.77s - 1274.33s | binding a basic memory object to the VBO. 1274.33s - 1278.09s | And at the same time, somebody else do the unbinding. 1278.09s - 1279.53s | So look at the code. 1279.53s - 1281.69s | You can see, when do the binding, 1281.69s - 1283.77s | we are getting into this add range. 1283.77s - 1286.45s | This is the function we just read. 1286.45s - 1287.97s | You can see, we have the lock. 1287.97s - 1293.33s | We will insert the basic memory object into the VBO. 1293.33s - 1295.97s | Then we unlock and do the physical mapping. 1295.97s - 1299.53s | And another thread, you do the unbinding. 1299.53s - 1302.85s | You can see, it's just the reverse of the binding. 1302.85s - 1309.01s | You will have a lock, and then you remove the binding, 1309.01s - 1311.61s | and then you do the unlock. 1311.61s - 1314.45s | So here is how we trigger the vulnerability. 1314.45s - 1318.41s | We have two threads, thread A, running, and lock, 1318.41s - 1323.73s | and then undo the tree insert and do the unlock. 1323.73s - 1327.21s | And at the same time, we can run thread B, 1327.21s - 1331.21s | because it's unlocked, so the thread B can run in. 1331.21s - 1334.61s | Then we get the lock removed and unlock. 1334.61s - 1337.17s | And finally, we do the mapping. 1337.17s - 1342.17s | So here is the detailed vulnerability. 1342.17s - 1345.49s | We run thread A. We acquire the mutex. 1345.49s - 1346.37s | Then we connect. 1346.37s - 1349.17s | You can see this connection is set up. 1349.17s - 1352.57s | So we connect the basic memory object to the VBO 1352.57s - 1354.57s | and release the lock. 1354.57s - 1357.45s | Then we get to thread B. Thread B also 1357.45s - 1359.33s | acquires the same mutex. 1359.33s - 1362.33s | And you can see this connection between the basic memory 1362.33s - 1364.97s | object and the VBO is removed. 1364.97s - 1370.65s | So this is thread B, unbinding, and release the mutex. 1370.65s - 1374.41s | Then we get back to thread A. The thread A 1374.41s - 1380.13s | will map the victim's physical page to this


chunk_id: 186_chunk_24
chunk_text:
the unlock. 1323.73s - 1327.21s | And at the same time, we can run thread B, 1327.21s - 1331.21s | because it's unlocked, so the thread B can run in. 1331.21s - 1334.61s | Then we get the lock removed and unlock. 1334.61s - 1337.17s | And finally, we do the mapping. 1337.17s - 1342.17s | So here is the detailed vulnerability. 1342.17s - 1345.49s | We run thread A. We acquire the mutex. 1345.49s - 1346.37s | Then we connect. 1346.37s - 1349.17s | You can see this connection is set up. 1349.17s - 1352.57s | So we connect the basic memory object to the VBO 1352.57s - 1354.57s | and release the lock. 1354.57s - 1357.45s | Then we get to thread B. Thread B also 1357.45s - 1359.33s | acquires the same mutex. 1359.33s - 1362.33s | And you can see this connection between the basic memory 1362.33s - 1364.97s | object and the VBO is removed. 1364.97s - 1370.65s | So this is thread B, unbinding, and release the mutex. 1370.65s - 1374.41s | Then we get back to thread A. The thread A 1374.41s - 1380.13s | will map the victim's physical page to this virtual address. 1380.13s - 1383.97s | So because from the driver's perspective, 1383.97s - 1390.53s | the basic memory object already have no connection with VBO, 1390.53s - 1392.21s | so it can be freed. 1392.21s - 1396.09s | So we can delete the basic memory object in the driver. 1396.09s - 1400.05s | So all the resource related with this basic memory object 1400.05s - 1403.45s | could be freed, as well as the back-end physical memory. 1403.45s - 1406.41s | You can see this page has been freed. 1406.41s - 1409.17s | But the connection here, the connection 1409.17s - 1411.61s | between the physical memory and the virtual address 1411.61s - 1413.09s | is still mapped. 1413.09s - 1414.49s | So it's still there. 1414.49s - 1415.85s | That's the vulnerability. 1415.85s - 1419.17s | So we have run this code sequence 1419.17s - 1423.53s | and triggered the vulnerability. 1423.53s - 1428.37s | It's a physical page used after free. 1428.37s - 1431.97s | So we can read and write to free the physical page. 1431.97s - 1433.57s | You can see we can read and write 1433.57s - 1439.37s | to this free the physical


chunk_id: 186_chunk_25
chunk_text:
virtual address. 1380.13s - 1383.97s | So because from the driver's perspective, 1383.97s - 1390.53s | the basic memory object already have no connection with VBO, 1390.53s - 1392.21s | so it can be freed. 1392.21s - 1396.09s | So we can delete the basic memory object in the driver. 1396.09s - 1400.05s | So all the resource related with this basic memory object 1400.05s - 1403.45s | could be freed, as well as the back-end physical memory. 1403.45s - 1406.41s | You can see this page has been freed. 1406.41s - 1409.17s | But the connection here, the connection 1409.17s - 1411.61s | between the physical memory and the virtual address 1411.61s - 1413.09s | is still mapped. 1413.09s - 1414.49s | So it's still there. 1414.49s - 1415.85s | That's the vulnerability. 1415.85s - 1419.17s | So we have run this code sequence 1419.17s - 1423.53s | and triggered the vulnerability. 1423.53s - 1428.37s | It's a physical page used after free. 1428.37s - 1431.97s | So we can read and write to free the physical page. 1431.97s - 1433.57s | You can see we can read and write 1433.57s - 1439.37s | to this free the physical page from the GPU's virtual address. 1439.37s - 1442.29s | And also, it's a worst condition issue. 1442.29s - 1446.33s | We require the two threads to do binding and unbinding 1446.33s - 1448.85s | at the same time. 1448.85s - 1453.49s | And here, let's summarize the exploit primitive. 1453.49s - 1456.41s | We have a physical page used after free. 1456.41s - 1459.57s | We return this physical virtual mapping. 1459.57s - 1463.09s | So we can access free the physical page. 1463.09s - 1466.85s | And this vulnerability is pretty stable. 1466.85s - 1472.85s | Usually, when we trigger used after free issue or rate 1472.85s - 1476.17s | condition issue, we have to trigger it multiple times. 1476.21s - 1479.33s | So it's very dangerous you trigger this issue 1479.33s - 1483.21s | because it will cause the system status, wrong status, 1483.21s - 1484.77s | maybe crash the kernel. 1484.77s - 1486.77s | But this issue is pretty stable. 1486.77s - 1488.65s | You can trigger it multiple times 1488.65s - 1493.73s | without worrying about it fails or causing any crash. 1493.73s - 1497.97s | And also, we have a method to get the


chunk_id: 186_chunk_26
chunk_text:
page from the GPU's virtual address. 1439.37s - 1442.29s | And also, it's a worst condition issue. 1442.29s - 1446.33s | We require the two threads to do binding and unbinding 1446.33s - 1448.85s | at the same time. 1448.85s - 1453.49s | And here, let's summarize the exploit primitive. 1453.49s - 1456.41s | We have a physical page used after free. 1456.41s - 1459.57s | We return this physical virtual mapping. 1459.57s - 1463.09s | So we can access free the physical page. 1463.09s - 1466.85s | And this vulnerability is pretty stable. 1466.85s - 1472.85s | Usually, when we trigger used after free issue or rate 1472.85s - 1476.17s | condition issue, we have to trigger it multiple times. 1476.21s - 1479.33s | So it's very dangerous you trigger this issue 1479.33s - 1483.21s | because it will cause the system status, wrong status, 1483.21s - 1484.77s | maybe crash the kernel. 1484.77s - 1486.77s | But this issue is pretty stable. 1486.77s - 1488.65s | You can trigger it multiple times 1488.65s - 1493.73s | without worrying about it fails or causing any crash. 1493.73s - 1497.97s | And also, we have a method to get the feedback 1497.97s - 1500.17s | whether this issue is triggered or not. 1500.17s - 1503.45s | If it's not triggered, we will get this feedback. 1503.45s - 1506.09s | And if it's triggered, then we know 1507.01s - 1510.61s | so that we can know exactly how many pages we have controlled. 1510.61s - 1513.61s | This will make our exploit more stable. 1513.61s - 1516.93s | And this issue is pretty easy to trick. 1516.93s - 1519.57s | Without any special tricks, you don't 1519.57s - 1521.85s | have to adjust the thread priority 1521.85s - 1524.37s | or add more entries to the list. 1524.37s - 1527.25s | You can easily trigger this issue. 1527.25s - 1532.65s | So this is a pretty nice exploit primitive. 1532.65s - 1538.73s | So far, we have tricked the vulnerability. 1538.73s - 1543.25s | We have controlled a lot of physical memory pages. 1543.25s - 1547.57s | The questions became the following question. 1547.57s - 1550.05s | Suppose we already controlled a large amount 1550.05s - 1551.93s | of physical memory page. 1551.93s - 1553.41s | What are we going to do? 1553.41s - 1555.69s | There are lots of answers


chunk_id: 186_chunk_27
chunk_text:
feedback 1497.97s - 1500.17s | whether this issue is triggered or not. 1500.17s - 1503.45s | If it's not triggered, we will get this feedback. 1503.45s - 1506.09s | And if it's triggered, then we know 1507.01s - 1510.61s | so that we can know exactly how many pages we have controlled. 1510.61s - 1513.61s | This will make our exploit more stable. 1513.61s - 1516.93s | And this issue is pretty easy to trick. 1516.93s - 1519.57s | Without any special tricks, you don't 1519.57s - 1521.85s | have to adjust the thread priority 1521.85s - 1524.37s | or add more entries to the list. 1524.37s - 1527.25s | You can easily trigger this issue. 1527.25s - 1532.65s | So this is a pretty nice exploit primitive. 1532.65s - 1538.73s | So far, we have tricked the vulnerability. 1538.73s - 1543.25s | We have controlled a lot of physical memory pages. 1543.25s - 1547.57s | The questions became the following question. 1547.57s - 1550.05s | Suppose we already controlled a large amount 1550.05s - 1551.93s | of physical memory page. 1551.93s - 1553.41s | What are we going to do? 1553.41s - 1555.69s | There are lots of answers and solutions 1555.69s - 1558.17s | for an experienced kernel hacker. 1558.17s - 1561.53s | For example, we can supply lots of this structure 1561.53s - 1564.09s | created into the kernel heap and then 1564.09s - 1566.61s | modify the UID and the GID. 1566.61s - 1570.09s | We can also supply lots of structure file 1570.09s - 1573.01s | and then modify the file permission. 1573.01s - 1577.89s | And also, we can use this kernel space memory mirroring attack. 1577.89s - 1581.33s | So we can modify and control the GPU page table 1581.33s - 1584.37s | and then do the mirroring. 1584.37s - 1587.45s | Here, we will introduce our new method. 1587.45s - 1594.41s | So we are spraying structure KGS memory description. 1594.41s - 1596.57s | So you can see on the right, we are 1596.57s - 1601.41s | spraying this structure, KGS memory entry. 1601.41s - 1604.61s | It contains the target structure we want to spray. 1604.61s - 1607.21s | It contains the memory description structure. 1607.21s - 1610.05s | Also, it contains metadata. 1610.05s - 1612.05s | And for this memory description, we 1612.05s - 1615.65s | can see they have


chunk_id: 186_chunk_28
chunk_text:
and solutions 1555.69s - 1558.17s | for an experienced kernel hacker. 1558.17s - 1561.53s | For example, we can supply lots of this structure 1561.53s - 1564.09s | created into the kernel heap and then 1564.09s - 1566.61s | modify the UID and the GID. 1566.61s - 1570.09s | We can also supply lots of structure file 1570.09s - 1573.01s | and then modify the file permission. 1573.01s - 1577.89s | And also, we can use this kernel space memory mirroring attack. 1577.89s - 1581.33s | So we can modify and control the GPU page table 1581.33s - 1584.37s | and then do the mirroring. 1584.37s - 1587.45s | Here, we will introduce our new method. 1587.45s - 1594.41s | So we are spraying structure KGS memory description. 1594.41s - 1596.57s | So you can see on the right, we are 1596.57s - 1601.41s | spraying this structure, KGS memory entry. 1601.41s - 1604.61s | It contains the target structure we want to spray. 1604.61s - 1607.21s | It contains the memory description structure. 1607.21s - 1610.05s | Also, it contains metadata. 1610.05s - 1612.05s | And for this memory description, we 1612.05s - 1615.65s | can see they have a physical address and a size. 1615.65s - 1618.41s | So why we are using this method? 1618.41s - 1621.01s | The first reason is easy to spray. 1621.01s - 1625.25s | You can simply call this GPU allocator control. 1625.25s - 1626.89s | Then you can spray a large amount 1626.89s - 1629.45s | of this structure in the kernel. 1629.45s - 1633.09s | And also, because we have this metadata, 1633.09s - 1635.49s | this is fully controlled by the user space. 1635.49s - 1638.61s | So the user space can set a unique metadata 1638.61s - 1642.61s | so that it can be defined easily in the memory. 1642.61s - 1646.05s | And it's easy to use and very useful. 1646.05s - 1648.53s | You can spray this structure and then 1648.53s - 1650.69s | modify the physical address. 1650.69s - 1653.61s | And then do memory map in the user space. 1653.61s - 1655.57s | When you do memory map, you will be 1655.57s - 1659.53s | able to map the physical address to user space. 1659.53s - 1662.85s | And also, if you check the result of the memory map, 1662.85s - 1666.01s | then


chunk_id: 186_chunk_29
chunk_text:
a physical address and a size. 1615.65s - 1618.41s | So why we are using this method? 1618.41s - 1621.01s | The first reason is easy to spray. 1621.01s - 1625.25s | You can simply call this GPU allocator control. 1625.25s - 1626.89s | Then you can spray a large amount 1626.89s - 1629.45s | of this structure in the kernel. 1629.45s - 1633.09s | And also, because we have this metadata, 1633.09s - 1635.49s | this is fully controlled by the user space. 1635.49s - 1638.61s | So the user space can set a unique metadata 1638.61s - 1642.61s | so that it can be defined easily in the memory. 1642.61s - 1646.05s | And it's easy to use and very useful. 1646.05s - 1648.53s | You can spray this structure and then 1648.53s - 1650.69s | modify the physical address. 1650.69s - 1653.61s | And then do memory map in the user space. 1653.61s - 1655.57s | When you do memory map, you will be 1655.57s - 1659.53s | able to map the physical address to user space. 1659.53s - 1662.85s | And also, if you check the result of the memory map, 1662.85s - 1666.01s | then you know whether your exploit is working or not. 1666.01s - 1671.25s | So you can easily know how the exploit works. 1671.25s - 1673.53s | And there's one extra bonus. 1673.53s - 1675.33s | It's possible you use this method 1675.33s - 1678.09s | to bypass the KSR directly. 1678.09s - 1680.09s | Even if you don't have a KSR, you 1680.09s - 1683.21s | can use this method to bypass the KSR. 1683.21s - 1686.09s | We will discuss this later. 1686.09s - 1691.33s | Now, suppose we already have a physical page controlled. 1691.33s - 1693.53s | Like this, we control this physical page. 1693.53s - 1697.69s | And in this page, we have our package structure, 1697.69s - 1700.41s | memory entry, which contains the metadata 1700.41s - 1702.81s | so that we can find this metadata. 1702.81s - 1708.65s | And then we find this memory description structure. 1708.65s - 1712.73s | In this structure, it will have a physical address 1712.73s - 1715.29s | and a size and ops. 1715.29s - 1717.57s | We will modify these three fields. 1717.57s - 1719.17s | We will modify the physical address 1719.17s - 1722.97s | to


chunk_id: 186_chunk_30
chunk_text:
you know whether your exploit is working or not. 1666.01s - 1671.25s | So you can easily know how the exploit works. 1671.25s - 1673.53s | And there's one extra bonus. 1673.53s - 1675.33s | It's possible you use this method 1675.33s - 1678.09s | to bypass the KSR directly. 1678.09s - 1680.09s | Even if you don't have a KSR, you 1680.09s - 1683.21s | can use this method to bypass the KSR. 1683.21s - 1686.09s | We will discuss this later. 1686.09s - 1691.33s | Now, suppose we already have a physical page controlled. 1691.33s - 1693.53s | Like this, we control this physical page. 1693.53s - 1697.69s | And in this page, we have our package structure, 1697.69s - 1700.41s | memory entry, which contains the metadata 1700.41s - 1702.81s | so that we can find this metadata. 1702.81s - 1708.65s | And then we find this memory description structure. 1708.65s - 1712.73s | In this structure, it will have a physical address 1712.73s - 1715.29s | and a size and ops. 1715.29s - 1717.57s | We will modify these three fields. 1717.57s - 1719.17s | We will modify the physical address 1719.17s - 1722.97s | to the physical address of the kernel 1722.97s - 1725.51s | and the size to the kernel size. 1725.51s - 1729.25s | And also, we will modify the ops from the KSR ops 1729.25s - 1733.45s | to this continuous ops. 1733.45s - 1735.73s | Why we will modify this ops? 1735.73s - 1736.93s | Look at the new ops. 1736.93s - 1739.13s | You can see it have a VM folder. 1739.13s - 1756.84s | This is used when we do a new continuous ops, which 1756.84s - 1759.60s | contains a new VM folder. 1759.64s - 1764.84s | So when the user space do memory mapping on this memory object, 1764.84s - 1769.32s | it will get a user space virtual address, 1769.32s - 1773.08s | which the user space can access to the virtual address. 1773.08s - 1775.92s | But at the first time, when the user space access 1775.92s - 1779.24s | to the address, because the physical to virtual mapping 1779.24s - 1783.68s | is not set up yet, so it will get into a VM folder. 1783.68s - 1786.16s | So the driver will get into the VM folder 1786.16s - 1788.48s | to set


chunk_id: 186_chunk_31
chunk_text:
the physical address of the kernel 1722.97s - 1725.51s | and the size to the kernel size. 1725.51s - 1729.25s | And also, we will modify the ops from the KSR ops 1729.25s - 1733.45s | to this continuous ops. 1733.45s - 1735.73s | Why we will modify this ops? 1735.73s - 1736.93s | Look at the new ops. 1736.93s - 1739.13s | You can see it have a VM folder. 1739.13s - 1756.84s | This is used when we do a new continuous ops, which 1756.84s - 1759.60s | contains a new VM folder. 1759.64s - 1764.84s | So when the user space do memory mapping on this memory object, 1764.84s - 1769.32s | it will get a user space virtual address, 1769.32s - 1773.08s | which the user space can access to the virtual address. 1773.08s - 1775.92s | But at the first time, when the user space access 1775.92s - 1779.24s | to the address, because the physical to virtual mapping 1779.24s - 1783.68s | is not set up yet, so it will get into a VM folder. 1783.68s - 1786.16s | So the driver will get into the VM folder 1786.16s - 1788.48s | to set up the physical to virtual mapping 1788.48s - 1789.76s | and look at the code. 1789.76s - 1792.12s | You can see this mapping is quite simple. 1792.12s - 1795.72s | It just gets the physical address we just modified. 1795.72s - 1798.68s | So it will use the physical address we want 1798.68s - 1802.80s | and then map this physical address to the user space. 1802.80s - 1806.24s | So if we modify this physical address 1806.24s - 1809.32s | to the kernel physical address, then the kernel memory 1809.32s - 1811.72s | will be mapped to the user space. 1811.72s - 1815.24s | So we can do arbitrary read write to the kernel memory. 1815.24s - 1820.24s | So that's why we use this structure memory description 1820.24s - 1824.20s | and how the exploit works. 1824.20s - 1826.44s | Let's summarize the exploitation. 1826.44s - 1829.32s | So we trigger the vulnerability, and then we 1829.32s - 1831.68s | get a controlled physical page. 1831.68s - 1835.44s | We repeat this step 200 times. 1835.44s - 1839.40s | Then we get 200 physical pages controlled. 1839.40s - 1841.72s | Then we can get to the next


chunk_id: 186_chunk_32
chunk_text:
up the physical to virtual mapping 1788.48s - 1789.76s | and look at the code. 1789.76s - 1792.12s | You can see this mapping is quite simple. 1792.12s - 1795.72s | It just gets the physical address we just modified. 1795.72s - 1798.68s | So it will use the physical address we want 1798.68s - 1802.80s | and then map this physical address to the user space. 1802.80s - 1806.24s | So if we modify this physical address 1806.24s - 1809.32s | to the kernel physical address, then the kernel memory 1809.32s - 1811.72s | will be mapped to the user space. 1811.72s - 1815.24s | So we can do arbitrary read write to the kernel memory. 1815.24s - 1820.24s | So that's why we use this structure memory description 1820.24s - 1824.20s | and how the exploit works. 1824.20s - 1826.44s | Let's summarize the exploitation. 1826.44s - 1829.32s | So we trigger the vulnerability, and then we 1829.32s - 1831.68s | get a controlled physical page. 1831.68s - 1835.44s | We repeat this step 200 times. 1835.44s - 1839.40s | Then we get 200 physical pages controlled. 1839.40s - 1841.72s | Then we can get to the next step. 1841.72s - 1846.00s | We can force the system memory into a low memory status. 1846.00s - 1849.36s | So all the used kernel memory, all the caches 1849.36s - 1854.40s | will be returned to the system, including the physical pages 1854.40s - 1855.44s | that we controlled. 1855.44s - 1861.12s | So the 200 pages will also be returned to the kernel. 1861.12s - 1862.84s | Then we get to the next step. 1862.84s - 1865.36s | We do kernel heap spray using the structure 1865.36s - 1867.44s | we just described. 1867.44s - 1872.00s | So if we are lucky, some of the entries 1872.00s - 1874.60s | will be located in the controller page. 1874.60s - 1883.24s | So we can find these structures in the controller page 1883.24s - 1885.56s | using the metadata we just assert. 1885.56s - 1890.08s | So we can scan the controller memory and find the structure. 1890.08s - 1891.80s | And then we get this structure. 1891.80s - 1895.02s | You can see on the right, we get the memory description 1895.02s - 1898.22s | structure, which contains the physical address side 1898.22s - 1900.30s | and the


chunk_id: 186_chunk_33
chunk_text:
step. 1841.72s - 1846.00s | We can force the system memory into a low memory status. 1846.00s - 1849.36s | So all the used kernel memory, all the caches 1849.36s - 1854.40s | will be returned to the system, including the physical pages 1854.40s - 1855.44s | that we controlled. 1855.44s - 1861.12s | So the 200 pages will also be returned to the kernel. 1861.12s - 1862.84s | Then we get to the next step. 1862.84s - 1865.36s | We do kernel heap spray using the structure 1865.36s - 1867.44s | we just described. 1867.44s - 1872.00s | So if we are lucky, some of the entries 1872.00s - 1874.60s | will be located in the controller page. 1874.60s - 1883.24s | So we can find these structures in the controller page 1883.24s - 1885.56s | using the metadata we just assert. 1885.56s - 1890.08s | So we can scan the controller memory and find the structure. 1890.08s - 1891.80s | And then we get this structure. 1891.80s - 1895.02s | You can see on the right, we get the memory description 1895.02s - 1898.22s | structure, which contains the physical address side 1898.22s - 1900.30s | and the ops we want to modify. 1900.30s - 1905.54s | And here, one thing you can see, the ops is a pointer. 1905.54s - 1909.82s | It's a point to something in the kernel memory. 1909.82s - 1913.06s | So if we read this ops out, then we 1913.06s - 1916.10s | can get the KSL information. 1916.10s - 1920.78s | So in our exploiter, we bypass the KSL at this step. 1920.78s - 1924.06s | So we can bypass the KSL here, and then 1924.06s - 1925.70s | get to the next step. 1925.70s - 1929.10s | We can modify the physical address, modify the size, 1929.10s - 1930.90s | modify the ops. 1930.90s - 1933.14s | We will modify the kernel physical address 1933.14s - 1935.50s | to the kernel physical address, and the size 1935.50s - 1936.78s | to the kernel size. 1936.78s - 1939.54s | Then finally, we can map the whole kernel memory 1939.54s - 1941.10s | to the user space. 1941.10s - 1943.66s | Then we can do arbitrary read-write to the kernel 1943.66s - 1945.74s | memory in the user space. 1945.74s - 1948.86s | So that's the exploiter. 1948.86s - 1954.38s | We


chunk_id: 186_chunk_34
chunk_text:
ops we want to modify. 1900.30s - 1905.54s | And here, one thing you can see, the ops is a pointer. 1905.54s - 1909.82s | It's a point to something in the kernel memory. 1909.82s - 1913.06s | So if we read this ops out, then we 1913.06s - 1916.10s | can get the KSL information. 1916.10s - 1920.78s | So in our exploiter, we bypass the KSL at this step. 1920.78s - 1924.06s | So we can bypass the KSL here, and then 1924.06s - 1925.70s | get to the next step. 1925.70s - 1929.10s | We can modify the physical address, modify the size, 1929.10s - 1930.90s | modify the ops. 1930.90s - 1933.14s | We will modify the kernel physical address 1933.14s - 1935.50s | to the kernel physical address, and the size 1935.50s - 1936.78s | to the kernel size. 1936.78s - 1939.54s | Then finally, we can map the whole kernel memory 1939.54s - 1941.10s | to the user space. 1941.10s - 1943.66s | Then we can do arbitrary read-write to the kernel 1943.66s - 1945.74s | memory in the user space. 1945.74s - 1948.86s | So that's the exploiter. 1948.86s - 1954.38s | We can actually expand this method to a more generic case. 1954.38s - 1960.18s | Suppose you have kernel heap buffer overflow, 1960.18s - 1962.02s | or you have a risk condition issue, 1962.02s - 1967.58s | you can also use this method to make your exploiter easier. 1967.58s - 1971.62s | The first step, you can spray a large amount of this memory 1971.62s - 1974.58s | descript into the kernel heap. 1974.58s - 1977.14s | And then you trigger your vulnerability. 1977.14s - 1980.62s | Suppose you have a kernel heap overflow issue. 1980.62s - 1985.42s | You can overflow it from here into this ops. 1985.42s - 1990.22s | Then you can control the physical address and ops. 1990.22s - 1992.30s | And then you can try to do memory 1992.30s - 1995.58s | map on this memory object. 1995.58s - 1997.58s | If you are lucky, you succeed. 1997.58s - 2001.38s | Then you can map the whole kernel physical memory 2001.38s - 2002.70s | to the user space. 2002.70s - 2005.66s | But if you are not lucky, you can try it again and again 2005.74s - 2007.50s | until you succeed. 2007.50s - 2012.46s |


chunk_id: 186_chunk_35
chunk_text:
can actually expand this method to a more generic case. 1954.38s - 1960.18s | Suppose you have kernel heap buffer overflow, 1960.18s - 1962.02s | or you have a risk condition issue, 1962.02s - 1967.58s | you can also use this method to make your exploiter easier. 1967.58s - 1971.62s | The first step, you can spray a large amount of this memory 1971.62s - 1974.58s | descript into the kernel heap. 1974.58s - 1977.14s | And then you trigger your vulnerability. 1977.14s - 1980.62s | Suppose you have a kernel heap overflow issue. 1980.62s - 1985.42s | You can overflow it from here into this ops. 1985.42s - 1990.22s | Then you can control the physical address and ops. 1990.22s - 1992.30s | And then you can try to do memory 1992.30s - 1995.58s | map on this memory object. 1995.58s - 1997.58s | If you are lucky, you succeed. 1997.58s - 2001.38s | Then you can map the whole kernel physical memory 2001.38s - 2002.70s | to the user space. 2002.70s - 2005.66s | But if you are not lucky, you can try it again and again 2005.74s - 2007.50s | until you succeed. 2007.50s - 2012.46s | So that's how we expand this method to a more generic case. 2012.46s - 2016.26s | And maybe you remember we have a bonus, 2016.26s - 2019.70s | which we can bypass the case using this method. 2019.70s - 2022.82s | So look at the structure carefully. 2022.82s - 2027.22s | You may find that there are lots of kernel points, 2027.22s - 2031.54s | like the page table is a pointer and the host PTR. 2031.54s - 2033.30s | And also we have the SGT. 2033.30s - 2035.90s | You might think, oh, we will need 2035.90s - 2038.50s | to get a case information first. 2038.50s - 2043.58s | We have to point this point to a digital address. 2043.58s - 2047.30s | But in fact, you don't have to worry about this field. 2047.30s - 2048.94s | Because in most of the case, if you 2048.94s - 2052.70s | don't call some special control by yourself, 2052.70s - 2056.10s | these fields are not used in most of the case. 2056.10s - 2061.22s | So you can just overwrite these fields with a capital value 2061.22s - 2062.70s | or whatever you want. 2062.70s - 2065.90s |


chunk_id: 186_chunk_36
chunk_text:
So that's how we expand this method to a more generic case. 2012.46s - 2016.26s | And maybe you remember we have a bonus, 2016.26s - 2019.70s | which we can bypass the case using this method. 2019.70s - 2022.82s | So look at the structure carefully. 2022.82s - 2027.22s | You may find that there are lots of kernel points, 2027.22s - 2031.54s | like the page table is a pointer and the host PTR. 2031.54s - 2033.30s | And also we have the SGT. 2033.30s - 2035.90s | You might think, oh, we will need 2035.90s - 2038.50s | to get a case information first. 2038.50s - 2043.58s | We have to point this point to a digital address. 2043.58s - 2047.30s | But in fact, you don't have to worry about this field. 2047.30s - 2048.94s | Because in most of the case, if you 2048.94s - 2052.70s | don't call some special control by yourself, 2052.70s - 2056.10s | these fields are not used in most of the case. 2056.10s - 2061.22s | So you can just overwrite these fields with a capital value 2061.22s - 2062.70s | or whatever you want. 2062.70s - 2065.90s | You can just overwrite the page table, the host PTR, 2065.90s - 2067.78s | and the GPU address. 2067.78s - 2071.06s | All this stuff are not used. 2071.06s - 2073.90s | The only thing you care about is the physical address, 2073.90s - 2076.30s | the size, and the ops. 2076.30s - 2079.10s | You might all think, oh, here we have the ops. 2079.10s - 2080.82s | It's also a pointer. 2080.82s - 2083.98s | So you have to know the original value, 2083.98s - 2086.74s | or you have to know the ASR information. 2086.74s - 2091.90s | But actually, no, you don't have to know the KSR information. 2091.90s - 2094.22s | You look at the original value carefully. 2094.22s - 2097.10s | You can see this is the original value, 2097.10s - 2101.34s | and this is the target value we want to modify. 2101.34s - 2105.30s | You can see that the high bytes are actually the same. 2105.30s - 2106.62s | Why are they the same? 2106.62s - 2111.02s | Because the KSR is based on the page. 2111.02s - 2112.10s | It's page-based. 2112.10s - 2115.86s | So if the two function


chunk_id: 186_chunk_37
chunk_text:
You can just overwrite the page table, the host PTR, 2065.90s - 2067.78s | and the GPU address. 2067.78s - 2071.06s | All this stuff are not used. 2071.06s - 2073.90s | The only thing you care about is the physical address, 2073.90s - 2076.30s | the size, and the ops. 2076.30s - 2079.10s | You might all think, oh, here we have the ops. 2079.10s - 2080.82s | It's also a pointer. 2080.82s - 2083.98s | So you have to know the original value, 2083.98s - 2086.74s | or you have to know the ASR information. 2086.74s - 2091.90s | But actually, no, you don't have to know the KSR information. 2091.90s - 2094.22s | You look at the original value carefully. 2094.22s - 2097.10s | You can see this is the original value, 2097.10s - 2101.34s | and this is the target value we want to modify. 2101.34s - 2105.30s | You can see that the high bytes are actually the same. 2105.30s - 2106.62s | Why are they the same? 2106.62s - 2111.02s | Because the KSR is based on the page. 2111.02s - 2112.10s | It's page-based. 2112.10s - 2115.86s | So if the two function points are in the same page, 2115.86s - 2120.50s | so they have the same high bytes that are in the same page. 2120.50s - 2122.98s | So all these bytes are the same. 2122.98s - 2124.86s | So you can actually ignore these bytes 2124.86s - 2128.70s | and overwrite from the beginning to the lowest byte, 2128.70s - 2130.14s | overwrite it to here. 2130.14s - 2133.02s | Then you don't have to care about the KSR. 2133.02s - 2135.78s | So that's how we bypass the KSR. 2135.78s - 2139.62s | And once in here, you can see the lowest byte already 2139.62s - 2141.78s | known from the kernel firmware. 2141.78s - 2145.54s | So you don't have to acquire additional information. 2145.54s - 2149.66s | You can bypass the KSR and get the expert working. 2149.66s - 2152.86s | You just overwrite to the lowest byte 2152.86s - 2155.74s | and ignore the high bytes. 2155.74s - 2158.18s | Yeah, that's how we bypass the KSR. 2158.18s - 2161.10s | And in some case, maybe you are not so lucky. 2161.10s - 2164.38s | You get the following situation. 2164.38s - 2166.58s | You can


chunk_id: 186_chunk_38
chunk_text:
points are in the same page, 2115.86s - 2120.50s | so they have the same high bytes that are in the same page. 2120.50s - 2122.98s | So all these bytes are the same. 2122.98s - 2124.86s | So you can actually ignore these bytes 2124.86s - 2128.70s | and overwrite from the beginning to the lowest byte, 2128.70s - 2130.14s | overwrite it to here. 2130.14s - 2133.02s | Then you don't have to care about the KSR. 2133.02s - 2135.78s | So that's how we bypass the KSR. 2135.78s - 2139.62s | And once in here, you can see the lowest byte already 2139.62s - 2141.78s | known from the kernel firmware. 2141.78s - 2145.54s | So you don't have to acquire additional information. 2145.54s - 2149.66s | You can bypass the KSR and get the expert working. 2149.66s - 2152.86s | You just overwrite to the lowest byte 2152.86s - 2155.74s | and ignore the high bytes. 2155.74s - 2158.18s | Yeah, that's how we bypass the KSR. 2158.18s - 2161.10s | And in some case, maybe you are not so lucky. 2161.10s - 2164.38s | You get the following situation. 2164.38s - 2166.58s | You can see it's not in the same page, 2166.58s - 2169.34s | but in the source code, they're near each other. 2169.34s - 2172.98s | So in most of our case, the original value 2172.98s - 2175.18s | is near the target value. 2175.18s - 2178.18s | So it's just like a 4-bit difference. 2178.18s - 2181.54s | So for 4-bit, it's just a 16 possibility. 2181.54s - 2183.94s | You can try 16 times. 2183.94s - 2187.26s | So you can undo the brute force for 16 times. 2187.26s - 2189.30s | Then you can bypass the KSR. 2189.30s - 2194.66s | So that's how we bypass the KSR, and that's the exploit. 2194.66s - 2197.30s | We'll get to the demo. 2197.30s - 2198.66s | The demo is online. 2198.66s - 2201.86s | You can view the demo online. 2201.86s - 2203.62s | Also, we'll play it here. 2203.62s - 2208.54s | You can see here, when we record this demo, 2208.54s - 2212.66s | we are recording it on a pretty famous smartphone 2212.66s - 2216.86s | using the latest Qualcomm SoC, using 2216.86s - 2222.46s | Snapdragon generation 8 with the latest security patching. 2222.46s - 2225.22s


chunk_id: 186_chunk_39
chunk_text:
see it's not in the same page, 2166.58s - 2169.34s | but in the source code, they're near each other. 2169.34s - 2172.98s | So in most of our case, the original value 2172.98s - 2175.18s | is near the target value. 2175.18s - 2178.18s | So it's just like a 4-bit difference. 2178.18s - 2181.54s | So for 4-bit, it's just a 16 possibility. 2181.54s - 2183.94s | You can try 16 times. 2183.94s - 2187.26s | So you can undo the brute force for 16 times. 2187.26s - 2189.30s | Then you can bypass the KSR. 2189.30s - 2194.66s | So that's how we bypass the KSR, and that's the exploit. 2194.66s - 2197.30s | We'll get to the demo. 2197.30s - 2198.66s | The demo is online. 2198.66s - 2201.86s | You can view the demo online. 2201.86s - 2203.62s | Also, we'll play it here. 2203.62s - 2208.54s | You can see here, when we record this demo, 2208.54s - 2212.66s | we are recording it on a pretty famous smartphone 2212.66s - 2216.86s | using the latest Qualcomm SoC, using 2216.86s - 2222.46s | Snapdragon generation 8 with the latest security patching. 2222.46s - 2225.22s | That will start with the shell user. 2225.22s - 2228.26s | Of course, you can also use untracked application user. 2228.26s - 2229.86s | It's no difference. 2229.86s - 2232.50s | So we are trying to get a root shell. 2232.50s - 2237.38s | Of course, we don't have a root privilege now, so this fails. 2237.38s - 2239.30s | We will start our exploit. 2239.30s - 2242.02s | And the first step is to trigger the vulnerability 2242.02s - 2246.54s | and control a large amount of physical pages. 2246.54s - 2249.14s | So we trigger the vulnerability again and again. 2249.14s - 2253.38s | And here, we think we have enough pages. 2253.38s - 2255.58s | So now you can see we have controlled 2255.58s - 2257.30s | enough physical pages. 2257.30s - 2259.22s | Then we go to the next step. 2259.22s - 2261.78s | We trigger a system no memory. 2261.78s - 2265.22s | We allocate a lot of memory from the user space. 2265.22s - 2270.38s | So all the cached memory, all the system memory, 2270.38s - 2273.82s | unused system memory will be returned to the kernel. 2273.82s - 2276.06s | So


chunk_id: 186_chunk_40
chunk_text:
| That will start with the shell user. 2225.22s - 2228.26s | Of course, you can also use untracked application user. 2228.26s - 2229.86s | It's no difference. 2229.86s - 2232.50s | So we are trying to get a root shell. 2232.50s - 2237.38s | Of course, we don't have a root privilege now, so this fails. 2237.38s - 2239.30s | We will start our exploit. 2239.30s - 2242.02s | And the first step is to trigger the vulnerability 2242.02s - 2246.54s | and control a large amount of physical pages. 2246.54s - 2249.14s | So we trigger the vulnerability again and again. 2249.14s - 2253.38s | And here, we think we have enough pages. 2253.38s - 2255.58s | So now you can see we have controlled 2255.58s - 2257.30s | enough physical pages. 2257.30s - 2259.22s | Then we go to the next step. 2259.22s - 2261.78s | We trigger a system no memory. 2261.78s - 2265.22s | We allocate a lot of memory from the user space. 2265.22s - 2270.38s | So all the cached memory, all the system memory, 2270.38s - 2273.82s | unused system memory will be returned to the kernel. 2273.82s - 2276.06s | So we can do heap spray. 2276.06s - 2280.02s | We create a lot of these VBO entries. 2280.02s - 2281.82s | And then we are lucky. 2281.82s - 2287.14s | Some of the VBO entries will be located in the controller page. 2287.14s - 2289.58s | So we scan the controller page. 2289.58s - 2294.02s | And then we can find this controlled object. 2294.02s - 2298.18s | You can see we found one controlled memory description 2298.18s - 2299.06s | object. 2299.06s - 2301.94s | So this object has a physical address, size, 2301.94s - 2303.62s | and the ops we want. 2303.62s - 2308.86s | So we can patch this structure, the ops. 2308.86s - 2310.62s | We will modify the physical address. 2310.62s - 2314.70s | You can see this A801 is actually 2314.70s - 2316.54s | the kernel physical address. 2316.54s - 2318.46s | And the size is the kernel size. 2318.46s - 2321.78s | So we have patched the structure. 2321.78s - 2325.14s | And now we can do memory map, map this structure 2325.14s - 2327.34s | to the user space. 2327.34s - 2330.78s | So we can map the whole kernel memory to


chunk_id: 186_chunk_41
chunk_text:
we can do heap spray. 2276.06s - 2280.02s | We create a lot of these VBO entries. 2280.02s - 2281.82s | And then we are lucky. 2281.82s - 2287.14s | Some of the VBO entries will be located in the controller page. 2287.14s - 2289.58s | So we scan the controller page. 2289.58s - 2294.02s | And then we can find this controlled object. 2294.02s - 2298.18s | You can see we found one controlled memory description 2298.18s - 2299.06s | object. 2299.06s - 2301.94s | So this object has a physical address, size, 2301.94s - 2303.62s | and the ops we want. 2303.62s - 2308.86s | So we can patch this structure, the ops. 2308.86s - 2310.62s | We will modify the physical address. 2310.62s - 2314.70s | You can see this A801 is actually 2314.70s - 2316.54s | the kernel physical address. 2316.54s - 2318.46s | And the size is the kernel size. 2318.46s - 2321.78s | So we have patched the structure. 2321.78s - 2325.14s | And now we can do memory map, map this structure 2325.14s - 2327.34s | to the user space. 2327.34s - 2330.78s | So we can map the whole kernel memory to the user space 2330.78s - 2333.38s | and patch the kernel memory. 2333.38s - 2335.86s | Here we have patched the kernel version. 2335.86s - 2339.50s | And also we patched some of the code in the kernel. 2339.50s - 2340.98s | So we can get a root. 2340.98s - 2344.34s | So you can see now we are the root user. 2344.34s - 2346.86s | So that's the demo. 2346.86s - 2350.17s | Yeah. 2350.17s - 2351.01s | Thank you. 2351.01s - 2355.13s | I will transfer to Eugene for the next content. 2355.13s - 2356.73s | Thank you very much, Shilin. 2356.73s - 2358.69s | And with that, I will be speaking 2358.69s - 2361.77s | about the last section of this presentation, how 2361.77s - 2364.81s | we found this vulnerability, which methodology is 2364.81s - 2367.61s | applicable when you are doing bug hunting for GPU kernel 2367.61s - 2372.81s | modules, and what we can do to improve security of the GPU 2372.81s - 2375.65s | in the mobile space. 2375.65s - 2378.01s | Well, first of all, we identified this vulnerability 2378.01s - 2380.85s | via manual code review when we were doing patch


chunk_id: 186_chunk_42
chunk_text:
the user space 2330.78s - 2333.38s | and patch the kernel memory. 2333.38s - 2335.86s | Here we have patched the kernel version. 2335.86s - 2339.50s | And also we patched some of the code in the kernel. 2339.50s - 2340.98s | So we can get a root. 2340.98s - 2344.34s | So you can see now we are the root user. 2344.34s - 2346.86s | So that's the demo. 2346.86s - 2350.17s | Yeah. 2350.17s - 2351.01s | Thank you. 2351.01s - 2355.13s | I will transfer to Eugene for the next content. 2355.13s - 2356.73s | Thank you very much, Shilin. 2356.73s - 2358.69s | And with that, I will be speaking 2358.69s - 2361.77s | about the last section of this presentation, how 2361.77s - 2364.81s | we found this vulnerability, which methodology is 2364.81s - 2367.61s | applicable when you are doing bug hunting for GPU kernel 2367.61s - 2372.81s | modules, and what we can do to improve security of the GPU 2372.81s - 2375.65s | in the mobile space. 2375.65s - 2378.01s | Well, first of all, we identified this vulnerability 2378.01s - 2380.85s | via manual code review when we were doing patch analysis. 2380.85s - 2383.05s | And by patch analysis, essentially, 2383.05s - 2385.77s | we use a collective term where we 2385.77s - 2388.13s | look at the security fixes, which 2388.13s - 2390.81s | are published in the Android Qualcomm Security Bulletin. 2390.81s - 2393.25s | We also look at the security research published 2393.25s - 2395.09s | by other security researchers. 2395.09s - 2397.13s | And this is very important for such complex cases 2397.13s - 2400.69s | and big targets such as GPU, because the state is very big. 2400.69s - 2403.17s | And as Shilin explained earlier in this presentation, 2403.17s - 2404.49s | there is a lot of moving parts. 2404.49s - 2407.33s | So in order to have a holistic understanding, 2407.49s - 2413.69s | it's important to read others' blog reports 2413.69s - 2418.41s | to better understand the domain in this area. 2418.41s - 2420.17s | Originally, we wanted to put on the slide 2420.17s - 2423.09s | a very cool chain of vulnerabilities, which 2423.09s - 2425.65s | we did variant analysis for. 2425.65s - 2428.13s | So for example, Qualcomm internally 2428.13s - 2429.81s | identified one of the issues.


chunk_id: 186_chunk_43
chunk_text:
analysis. 2380.85s - 2383.05s | And by patch analysis, essentially, 2383.05s - 2385.77s | we use a collective term where we 2385.77s - 2388.13s | look at the security fixes, which 2388.13s - 2390.81s | are published in the Android Qualcomm Security Bulletin. 2390.81s - 2393.25s | We also look at the security research published 2393.25s - 2395.09s | by other security researchers. 2395.09s - 2397.13s | And this is very important for such complex cases 2397.13s - 2400.69s | and big targets such as GPU, because the state is very big. 2400.69s - 2403.17s | And as Shilin explained earlier in this presentation, 2403.17s - 2404.49s | there is a lot of moving parts. 2404.49s - 2407.33s | So in order to have a holistic understanding, 2407.49s - 2413.69s | it's important to read others' blog reports 2413.69s - 2418.41s | to better understand the domain in this area. 2418.41s - 2420.17s | Originally, we wanted to put on the slide 2420.17s - 2423.09s | a very cool chain of vulnerabilities, which 2423.09s - 2425.65s | we did variant analysis for. 2425.65s - 2428.13s | So for example, Qualcomm internally 2428.13s - 2429.81s | identified one of the issues. 2429.81s - 2432.13s | They published a fix in their security bulletin. 2432.13s - 2436.21s | Then a security researcher looked at this fix. 2436.21s - 2439.57s | They found another related issue in this area. 2439.57s - 2442.37s | They wrote a blog post and published it. 2442.37s - 2445.77s | While looking at these two fixes by Qualcomm and the security 2445.77s - 2448.73s | researcher, we managed to identify another problem 2448.73s - 2451.69s | in the related area. 2451.69s - 2453.85s | But later, we decided to remove this information, 2453.85s - 2457.97s | because the issue might still be under remediation 2457.97s - 2460.97s | and not to tip off the folks working 2460.97s - 2462.61s | on the other side of the fence. 2462.61s - 2464.53s | We decided to put this quote here, 2464.53s - 2466.81s | which I think reflects the idea which we 2466.81s - 2470.54s | would like to convey in the slide. 2470.54s - 2472.50s | While speaking about methodologies, 2472.50s - 2474.50s | we cannot skip fuzzing, because fuzzing 2474.50s - 2477.06s | is one of the central methodologies we use. 2477.06s - 2479.54s | This is one


chunk_id: 186_chunk_44
chunk_text:
2429.81s - 2432.13s | They published a fix in their security bulletin. 2432.13s - 2436.21s | Then a security researcher looked at this fix. 2436.21s - 2439.57s | They found another related issue in this area. 2439.57s - 2442.37s | They wrote a blog post and published it. 2442.37s - 2445.77s | While looking at these two fixes by Qualcomm and the security 2445.77s - 2448.73s | researcher, we managed to identify another problem 2448.73s - 2451.69s | in the related area. 2451.69s - 2453.85s | But later, we decided to remove this information, 2453.85s - 2457.97s | because the issue might still be under remediation 2457.97s - 2460.97s | and not to tip off the folks working 2460.97s - 2462.61s | on the other side of the fence. 2462.61s - 2464.53s | We decided to put this quote here, 2464.53s - 2466.81s | which I think reflects the idea which we 2466.81s - 2470.54s | would like to convey in the slide. 2470.54s - 2472.50s | While speaking about methodologies, 2472.50s - 2474.50s | we cannot skip fuzzing, because fuzzing 2474.50s - 2477.06s | is one of the central methodologies we use. 2477.06s - 2479.54s | This is one of the most efficient and productive ways 2479.54s - 2483.42s | of finding bugs in the modern complicated software 2483.42s - 2484.50s | and the firmware. 2484.50s - 2488.58s | And there is a lot of benefits, I think, 2488.58s - 2489.74s | quite obvious for fuzzing. 2489.74s - 2491.66s | So on this slide, particularly, we 2491.74s - 2494.94s | will focus on challenges applicable to fuzzing GPU 2494.94s - 2501.90s | targets and think about how can we overcome those 2501.90s - 2504.30s | or how can we solve them. 2504.30s - 2509.50s | So first of all, to enable efficient fuzzing of the GPU 2509.50s - 2513.94s | drivers, there is a lot of dependence on the hardware. 2513.94s - 2516.10s | As we have seen, this particular vulnerability 2516.10s - 2518.62s | is in the misconfiguration of the IOMMU. 2518.62s - 2521.66s | So in order to theoretically find this vulnerability, 2521.66s - 2523.62s | we would need to do on-device fuzzing. 2523.62s - 2525.66s | And although this is possible, this 2525.66s - 2528.14s | makes fuzzing a little bit less scalable, 2528.14s - 2529.86s | because we would actually need to run it 2529.86s


chunk_id: 186_chunk_45
chunk_text:
of the most efficient and productive ways 2479.54s - 2483.42s | of finding bugs in the modern complicated software 2483.42s - 2484.50s | and the firmware. 2484.50s - 2488.58s | And there is a lot of benefits, I think, 2488.58s - 2489.74s | quite obvious for fuzzing. 2489.74s - 2491.66s | So on this slide, particularly, we 2491.74s - 2494.94s | will focus on challenges applicable to fuzzing GPU 2494.94s - 2501.90s | targets and think about how can we overcome those 2501.90s - 2504.30s | or how can we solve them. 2504.30s - 2509.50s | So first of all, to enable efficient fuzzing of the GPU 2509.50s - 2513.94s | drivers, there is a lot of dependence on the hardware. 2513.94s - 2516.10s | As we have seen, this particular vulnerability 2516.10s - 2518.62s | is in the misconfiguration of the IOMMU. 2518.62s - 2521.66s | So in order to theoretically find this vulnerability, 2521.66s - 2523.62s | we would need to do on-device fuzzing. 2523.62s - 2525.66s | And although this is possible, this 2525.66s - 2528.14s | makes fuzzing a little bit less scalable, 2528.14s - 2529.86s | because we would actually need to run it 2529.86s - 2531.74s | on the hardware versus, let's say, 2531.74s - 2533.82s | pure software fuzzing, which can scale 2533.82s - 2536.18s | with the number of the fuzzing cores. 2536.18s - 2538.46s | This is not a limitation, but this 2538.46s - 2541.78s | is one of the interesting observations, 2541.78s - 2544.86s | because I know that there are some other GPU vendors which 2544.86s - 2546.74s | enable building their kernel mode 2546.74s - 2549.58s | components in the architecture-independent way. 2549.58s - 2551.66s | So basically, there is a separation 2551.66s - 2553.34s | between software and hardware logic, 2553.34s - 2558.98s | so it's possible to build driver and run it 2558.98s - 2562.22s | without the hardware to be able to test and fuzz 2562.22s - 2565.50s | the generic functionality implemented in the software. 2565.50s - 2567.90s | And another approach is using the emulation-based fuzzing 2567.90s - 2569.78s | to have an emulator for that. 2569.78s - 2572.78s | But I guess this is a little bit more complicated approach, 2572.78s - 2574.98s | because this requires manual work in order 2574.98s - 2576.98s | to understand how the hardware actually works,


chunk_id: 186_chunk_46
chunk_text:
- 2531.74s | on the hardware versus, let's say, 2531.74s - 2533.82s | pure software fuzzing, which can scale 2533.82s - 2536.18s | with the number of the fuzzing cores. 2536.18s - 2538.46s | This is not a limitation, but this 2538.46s - 2541.78s | is one of the interesting observations, 2541.78s - 2544.86s | because I know that there are some other GPU vendors which 2544.86s - 2546.74s | enable building their kernel mode 2546.74s - 2549.58s | components in the architecture-independent way. 2549.58s - 2551.66s | So basically, there is a separation 2551.66s - 2553.34s | between software and hardware logic, 2553.34s - 2558.98s | so it's possible to build driver and run it 2558.98s - 2562.22s | without the hardware to be able to test and fuzz 2562.22s - 2565.50s | the generic functionality implemented in the software. 2565.50s - 2567.90s | And another approach is using the emulation-based fuzzing 2567.90s - 2569.78s | to have an emulator for that. 2569.78s - 2572.78s | But I guess this is a little bit more complicated approach, 2572.78s - 2574.98s | because this requires manual work in order 2574.98s - 2576.98s | to understand how the hardware actually works, 2576.98s - 2584.18s | in order to be able to emulate it in the emulator. 2584.18s - 2585.90s | This particular issue was identified 2585.90s - 2589.22s | in the MMU and IOMMU domain. 2589.22s - 2591.14s | And this is actually a very common pattern 2591.14s - 2594.22s | in the GPU bugs reported these days, 2594.22s - 2597.38s | where the physical pages for the back-end storage 2597.38s - 2599.98s | are released back to the kernel, while at the same time, 2599.98s - 2603.54s | there is a mapping in the IOMMU for the GPU, 2604.54s - 2607.90s | which maps these released pages back to the virtual address 2607.90s - 2608.90s | space of the GPU. 2608.90s - 2611.02s | And this is very difficult to detect with fuzzing, 2611.02s - 2612.94s | because this doesn't lead to any crash. 2612.94s - 2616.22s | Even if we are lucky enough to hit the race condition here, 2616.22s - 2618.86s | still, there is no sanitizers which 2618.86s - 2623.38s | would report us that, hey, you have dangling MMU 2623.38s - 2625.50s | entries in the page tables. 2625.50s - 2626.74s | So this is one


chunk_id: 186_chunk_47
chunk_text:
2576.98s - 2584.18s | in order to be able to emulate it in the emulator. 2584.18s - 2585.90s | This particular issue was identified 2585.90s - 2589.22s | in the MMU and IOMMU domain. 2589.22s - 2591.14s | And this is actually a very common pattern 2591.14s - 2594.22s | in the GPU bugs reported these days, 2594.22s - 2597.38s | where the physical pages for the back-end storage 2597.38s - 2599.98s | are released back to the kernel, while at the same time, 2599.98s - 2603.54s | there is a mapping in the IOMMU for the GPU, 2604.54s - 2607.90s | which maps these released pages back to the virtual address 2607.90s - 2608.90s | space of the GPU. 2608.90s - 2611.02s | And this is very difficult to detect with fuzzing, 2611.02s - 2612.94s | because this doesn't lead to any crash. 2612.94s - 2616.22s | Even if we are lucky enough to hit the race condition here, 2616.22s - 2618.86s | still, there is no sanitizers which 2618.86s - 2623.38s | would report us that, hey, you have dangling MMU 2623.38s - 2625.50s | entries in the page tables. 2625.50s - 2626.74s | So this is one thing. 2626.74s - 2630.46s | So probably manual instrumentation of the driver 2630.46s - 2632.18s | with such checks would help. 2632.22s - 2635.46s | But again, this is manual work, which makes it less scalable. 2635.46s - 2638.54s | GPU has a very complicated state machine. 2638.54s - 2640.46s | As we have seen, there is multiple components. 2640.46s - 2642.50s | And sometimes, in order to hit certain functions, 2642.50s - 2648.18s | we would need to have a set of syscalls executed 2648.18s - 2649.46s | in a very precise sequence. 2649.46s - 2651.82s | Or if we're speaking about fuzzing with syscaller, 2651.82s - 2653.94s | probably this is additional custom syscalls, 2653.94s - 2656.02s | which needs to be written for that. 2656.02s - 2660.82s | And of course, fuzzing concurrency, concurrent code 2660.86s - 2663.34s | is not straightforward. 2663.34s - 2665.86s | Because there are some problems with reproducing 2665.86s - 2669.58s | and problems with hitting those vulnerabilities. 2672.70s - 2674.58s | Probably the final slide before we wrap it up, 2674.58s - 2676.42s | the ultimate mitigations question mark. 2676.42s - 2677.26s | Why question mark? 2677.26s - 2680.66s | Because,


chunk_id: 186_chunk_48
chunk_text:
thing. 2626.74s - 2630.46s | So probably manual instrumentation of the driver 2630.46s - 2632.18s | with such checks would help. 2632.22s - 2635.46s | But again, this is manual work, which makes it less scalable. 2635.46s - 2638.54s | GPU has a very complicated state machine. 2638.54s - 2640.46s | As we have seen, there is multiple components. 2640.46s - 2642.50s | And sometimes, in order to hit certain functions, 2642.50s - 2648.18s | we would need to have a set of syscalls executed 2648.18s - 2649.46s | in a very precise sequence. 2649.46s - 2651.82s | Or if we're speaking about fuzzing with syscaller, 2651.82s - 2653.94s | probably this is additional custom syscalls, 2653.94s - 2656.02s | which needs to be written for that. 2656.02s - 2660.82s | And of course, fuzzing concurrency, concurrent code 2660.86s - 2663.34s | is not straightforward. 2663.34s - 2665.86s | Because there are some problems with reproducing 2665.86s - 2669.58s | and problems with hitting those vulnerabilities. 2672.70s - 2674.58s | Probably the final slide before we wrap it up, 2674.58s - 2676.42s | the ultimate mitigations question mark. 2676.42s - 2677.26s | Why question mark? 2677.26s - 2680.66s | Because, well, I guess suggesting mitigations for GPU 2680.66s - 2683.06s | is really not straightforward. 2683.06s - 2688.58s | And this is more about thinking in points about how can we 2688.58s - 2691.58s | make GPU security better in the mobile space. 2691.58s - 2693.82s | First of all, one of the major points 2693.82s - 2696.82s | why GPU is so attractive is because it is widely 2696.82s - 2699.10s | accessible to untrusted code. 2699.10s - 2702.02s | Because the untrusted code can directly open the driver 2702.02s - 2704.66s | and send arbitrary data to it. 2704.66s - 2708.70s | Android is very known for using IPC and binder in order 2708.70s - 2710.26s | to isolate components. 2710.26s - 2714.30s | So maybe one of the ideas is to move a GPU from in-process hull 2714.30s - 2715.70s | into the out-of-process hull. 2715.70s - 2718.18s | I know this will impact performance. 2718.18s - 2720.18s | And performance is very important for GPU. 2720.18s - 2722.38s | This might create some backward compatibility issues. 2722.38s - 2724.42s | But this is one of the ideas to think about. 2724.42s - 2728.02s | And additionally,


chunk_id: 186_chunk_49
chunk_text:
well, I guess suggesting mitigations for GPU 2680.66s - 2683.06s | is really not straightforward. 2683.06s - 2688.58s | And this is more about thinking in points about how can we 2688.58s - 2691.58s | make GPU security better in the mobile space. 2691.58s - 2693.82s | First of all, one of the major points 2693.82s - 2696.82s | why GPU is so attractive is because it is widely 2696.82s - 2699.10s | accessible to untrusted code. 2699.10s - 2702.02s | Because the untrusted code can directly open the driver 2702.02s - 2704.66s | and send arbitrary data to it. 2704.66s - 2708.70s | Android is very known for using IPC and binder in order 2708.70s - 2710.26s | to isolate components. 2710.26s - 2714.30s | So maybe one of the ideas is to move a GPU from in-process hull 2714.30s - 2715.70s | into the out-of-process hull. 2715.70s - 2718.18s | I know this will impact performance. 2718.18s - 2720.18s | And performance is very important for GPU. 2720.18s - 2722.38s | This might create some backward compatibility issues. 2722.38s - 2724.42s | But this is one of the ideas to think about. 2724.42s - 2728.02s | And additionally, the usage of memory-safe languages 2728.02s - 2732.26s | in the driver, I think, based on our experience, 2732.26s - 2736.06s | they might mitigate the majority of root causes, which 2736.06s - 2738.70s | lead to problems such as integer overflows, 2738.70s - 2744.26s | or in this particular case, integer race conditions. 2744.26s - 2747.30s | And I think with that, we hit almost end of our time. 2747.30s - 2750.14s | And last slide, thank you very much for your attention. 2750.14s - 2753.10s | A small, shameless marketing plug here. 2753.10s - 2756.58s | We have our Android offset with google.com, 2756.58s - 2758.90s | where we publish our security research. 2758.90s - 2762.50s | And with that, yeah, I think we're 2762.50s - 2765.94s | happy to take any questions here on stage or offline using 2765.94s - 2768.90s | this content information here. 2768.90s - 2770.82s | Thank you very much.


chunk_id: 186_chunk_50
chunk_text:
the usage of memory-safe languages 2728.02s - 2732.26s | in the driver, I think, based on our experience, 2732.26s - 2736.06s | they might mitigate the majority of root causes, which 2736.06s - 2738.70s | lead to problems such as integer overflows, 2738.70s - 2744.26s | or in this particular case, integer race conditions. 2744.26s - 2747.30s | And I think with that, we hit almost end of our time. 2747.30s - 2750.14s | And last slide, thank you very much for your attention. 2750.14s - 2753.10s | A small, shameless marketing plug here. 2753.10s - 2756.58s | We have our Android offset with google.com, 2756.58s - 2758.90s | where we publish our security research. 2758.90s - 2762.50s | And with that, yeah, I think we're 2762.50s - 2765.94s | happy to take any questions here on stage or offline using 2765.94s - 2768.90s | this content information here. 2768.90s - 2770.82s | Thank you very much.


chunk_id: 187_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=z33TSv9EXBQ", "title": "DEF CON 32 - Nano Enigma Uncovering the Secrets in eFuse Memories - Michal Grygarek, Martin Petr", "description": "For years, eFuse-based memories were used to store sensitive information such as encryption keys, passwords, and other potentially confidential pieces of information. This practice was encouraged by several vendors who leverage such memory types for protecting the debugging interfaces using a password or for official way to store encryption keys for external flash memories.\n\nHowever, with the advances in technology and threat actors\u2019 creativity, eFuse-based memories may take a hard hit on their confidentiality assurance as their physical properties could allow for a relatively easy extraction of the stored information.\n\nIn this talk we will walk you through the journey of revealing one such data storage from decapsulating the chip itself, delayering it using common household items all the way to using advanced tools such as Scanning Electron Microscope (SEM) to read value of an encryption key and thus break the confidentiality of the encrypted flash memory.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2286, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 5.84s | This text was transcribed using whisper model: large-v2 I'd like to welcome you on our talk, Nano Enigma, Uncovering the Secrets within EFUSE 5.84s - 10.50s | Memories. Uh first of all, allow me a brief introduction. Uh my name is Martin and I'm here 10.50s - 15.74s | together with my colleague Michal. We also have a third partner in crime named Hayan, 15.74s - 20.88s | however he couldn't come here with us so we just have pre-recorded message from him. Uh we 20.88s - 24.88s | all work in the embedded system security testing team that's based in Prague, Czech 24.88s - 29.66s | Republic, which is under Accenture Umbrella and we all have different fields of focus. So 29.68s - 33.98s | for me that's reverse engineering, so I'm usually that person that wants that firmware 33.98s - 40.46s | image unencrypted. So making me shut up was partial motivation of this talk. Uh I'm pretty 40.46s - 44.26s | sure the other guys will tell you briefly about themselves when their time comes so I'm 44.26s - 48.90s | just gonna jump straight ahead into the overview. Uh we have it in the title, we will be 48.90s - 54.04s | talking about EFUSES and EFUSE is an electronic component which is just


chunk_id: 187_chunk_1
chunk_text:
Uncovering the Secrets within EFUSE 5.84s - 10.50s | Memories. Uh first of all, allow me a brief introduction. Uh my name is Martin and I'm here 10.50s - 15.74s | together with my colleague Michal. We also have a third partner in crime named Hayan, 15.74s - 20.88s | however he couldn't come here with us so we just have pre-recorded message from him. Uh we 20.88s - 24.88s | all work in the embedded system security testing team that's based in Prague, Czech 24.88s - 29.66s | Republic, which is under Accenture Umbrella and we all have different fields of focus. So 29.68s - 33.98s | for me that's reverse engineering, so I'm usually that person that wants that firmware 33.98s - 40.46s | image unencrypted. So making me shut up was partial motivation of this talk. Uh I'm pretty 40.46s - 44.26s | sure the other guys will tell you briefly about themselves when their time comes so I'm 44.26s - 48.90s | just gonna jump straight ahead into the overview. Uh we have it in the title, we will be 48.90s - 54.04s | talking about EFUSES and EFUSE is an electronic component which is just uh 2 points 54.04s - 59.54s | interconnected with a connection that has a property that it burns or terminates when 59.56s - 64.66s | the current flowing through it exceeds certain threshold. Uh this is really useful when 64.66s - 68.76s | you want to protect your home appliances from over current and but it's also really 68.76s - 73.30s | useful when you want to create something called one time programmable memory. Because if 73.30s - 79.60s | you represent bits with EFUSES, once you change state of a bit from 0 to 1, you cannot 79.60s - 86.42s | ever unchange it back to 0. This basically means that you you can change the the state of 86.46s - 91.26s | the device permanently. This is really useful for security because now you can use these 91.26s - 97.10s | types of memories to for example disable debugging interfaces or enable secure boot or 97.10s - 102.74s | put there public keys for secure boot. However some manufacturers took it one step further 102.74s - 107.68s | and they actually use these EFUSE based memories for storing information that requires 107.68s - 113.36s | confidentiality protection. Uh


chunk_id: 187_chunk_2
chunk_text:
uh 2 points 54.04s - 59.54s | interconnected with a connection that has a property that it burns or terminates when 59.56s - 64.66s | the current flowing through it exceeds certain threshold. Uh this is really useful when 64.66s - 68.76s | you want to protect your home appliances from over current and but it's also really 68.76s - 73.30s | useful when you want to create something called one time programmable memory. Because if 73.30s - 79.60s | you represent bits with EFUSES, once you change state of a bit from 0 to 1, you cannot 79.60s - 86.42s | ever unchange it back to 0. This basically means that you you can change the the state of 86.46s - 91.26s | the device permanently. This is really useful for security because now you can use these 91.26s - 97.10s | types of memories to for example disable debugging interfaces or enable secure boot or 97.10s - 102.74s | put there public keys for secure boot. However some manufacturers took it one step further 102.74s - 107.68s | and they actually use these EFUSE based memories for storing information that requires 107.68s - 113.36s | confidentiality protection. Uh meaning that you can find there also flash memory 113.36s - 118.60s | encryption keys or passwords for debugging interfaces. Uh but since I mentioned that 118.60s - 124.10s | that connection burns or terminates, there's actual physical change inside that component. 124.10s - 128.58s | So how do you protect confidentiality of something that could be observed through 128.58s - 132.78s | microscope? Because for example if I Google EFUSE microscope, you're gonna get all the 132.78s - 139.28s | images like burned and unburned examples. So the protection measure you you mainly used 139.28s - 145.08s | in some of the chips we looked at was layering. So layering is normal way of making chips 145.08s - 150.12s | where you stack components on top of each other. However if you put that EFUSE based memory 150.12s - 154.50s | in the very bottom layer, you can then consider it protection because you can't directly 154.50s - 160.80s | observe it. Uh this is based mainly on an assumption that performing the layering process, 160.80s - 165.98s | so removing carefully the layers from the chip so that you can extract information from it 165.98s - 171.48s |


chunk_id: 187_chunk_3
chunk_text:
meaning that you can find there also flash memory 113.36s - 118.60s | encryption keys or passwords for debugging interfaces. Uh but since I mentioned that 118.60s - 124.10s | that connection burns or terminates, there's actual physical change inside that component. 124.10s - 128.58s | So how do you protect confidentiality of something that could be observed through 128.58s - 132.78s | microscope? Because for example if I Google EFUSE microscope, you're gonna get all the 132.78s - 139.28s | images like burned and unburned examples. So the protection measure you you mainly used 139.28s - 145.08s | in some of the chips we looked at was layering. So layering is normal way of making chips 145.08s - 150.12s | where you stack components on top of each other. However if you put that EFUSE based memory 150.12s - 154.50s | in the very bottom layer, you can then consider it protection because you can't directly 154.50s - 160.80s | observe it. Uh this is based mainly on an assumption that performing the layering process, 160.80s - 165.98s | so removing carefully the layers from the chip so that you can extract information from it 165.98s - 171.48s | is very complex and expensive process. But we are here at DEF CON because we have proved 171.48s - 177.78s | this assumption wrong and we will demonstrate you all these techniques on an ESP32 chip 177.78s - 183.90s | from Espressif. However keep in mind that all of what we will be presenting here is also 183.90s - 188.90s | generally applicable to just about any chip that is using an EFUSE based memory. And with 188.90s - 194.00s | that uh I would like to pass my word to Michal who's gonna walk you to the details of the 194.00s - 205.58s | ATT&CK. Hello my name is Michal Grigarek and I'm also proud uh sorry I'm also a part 205.58s - 212.66s | of Accenture Prague. At first I must say I'm really proud to be here on this stage to present 212.66s - 223.97s | you results of our work. So my colleague Martin just explained what EFUSE is for and now let's 224.03s - 230.63s | take a look more closely how we can observe these structures in much more detail and what 230.63s - 242.71s | technologies and skills we will need. First we


chunk_id: 187_chunk_4
chunk_text:
is very complex and expensive process. But we are here at DEF CON because we have proved 171.48s - 177.78s | this assumption wrong and we will demonstrate you all these techniques on an ESP32 chip 177.78s - 183.90s | from Espressif. However keep in mind that all of what we will be presenting here is also 183.90s - 188.90s | generally applicable to just about any chip that is using an EFUSE based memory. And with 188.90s - 194.00s | that uh I would like to pass my word to Michal who's gonna walk you to the details of the 194.00s - 205.58s | ATT&CK. Hello my name is Michal Grigarek and I'm also proud uh sorry I'm also a part 205.58s - 212.66s | of Accenture Prague. At first I must say I'm really proud to be here on this stage to present 212.66s - 223.97s | you results of our work. So my colleague Martin just explained what EFUSE is for and now let's 224.03s - 230.63s | take a look more closely how we can observe these structures in much more detail and what 230.63s - 242.71s | technologies and skills we will need. First we must decapsulate the chip. Decapsulation is 242.71s - 249.43s | the process when we extract the silicon plate from the from the epoxy housing. Of course 249.43s - 256.43s | there exist some other material for for housings but for purposes this presentation we only 256.43s - 268.13s | consider only epoxy materials. There we see four basic techniques for decapsulation. Thermal, 268.13s - 278.37s | chemical, laser and plasma. Thermal method, this method use only a blowtorch or heat gun. Simply 278.43s - 286.83s | heat up the epoxy housing and then slowly and carefully break it and obtain the epoxy, 286.83s - 297.03s | sorry epoxy silicon plate. Chemical decapsulation use concentrate chemicals, concentrate acid to 297.03s - 307.17s | dissolve the epoxy housings. Laser etching use a strong laser beam to vaporize the epoxy material 307.17s - 317.55s | but this method is quite risky because it is very easy to burn the silicon plate and my problem 317.55s - 329.37s | lies in the heat deposition to the sample. And the last plasma one, this process involves ionized 329.47s - 340.37s | gas or plasma to selective etching of materials. So due to its availability and


chunk_id: 187_chunk_5
chunk_text:
must decapsulate the chip. Decapsulation is 242.71s - 249.43s | the process when we extract the silicon plate from the from the epoxy housing. Of course 249.43s - 256.43s | there exist some other material for for housings but for purposes this presentation we only 256.43s - 268.13s | consider only epoxy materials. There we see four basic techniques for decapsulation. Thermal, 268.13s - 278.37s | chemical, laser and plasma. Thermal method, this method use only a blowtorch or heat gun. Simply 278.43s - 286.83s | heat up the epoxy housing and then slowly and carefully break it and obtain the epoxy, 286.83s - 297.03s | sorry epoxy silicon plate. Chemical decapsulation use concentrate chemicals, concentrate acid to 297.03s - 307.17s | dissolve the epoxy housings. Laser etching use a strong laser beam to vaporize the epoxy material 307.17s - 317.55s | but this method is quite risky because it is very easy to burn the silicon plate and my problem 317.55s - 329.37s | lies in the heat deposition to the sample. And the last plasma one, this process involves ionized 329.47s - 340.37s | gas or plasma to selective etching of materials. So due to its availability and good traceability 340.37s - 349.21s | we decided to use chemical method of decapsulation. Especially we used concentrated acid. In our case 349.21s - 361.45s | concentrated acid means 96% of concentration which must be heated to the approximately 361.67s - 370.39s | 150 degrees Fahrenheit. The chemical methods can be effectively combined with laser ablation. At 370.39s - 377.75s | first laser removes a large part of the housing and then the remaining can be dissolved in the 377.75s - 395.27s | acid. This short process during the exposure to the acid which is needed. The acid will dissolve 395.27s - 407.17s | the housing residue and leaving only the dye. Of course we must use appropriate protective 407.55s - 418.59s | equipment. After this process we obtain a beautiful etched chip suitable for other investigation. 418.59s - 436.69s | Because the chip has typically metallization on its two layers, we do not see any internal layers 436.75s - 447.87s | at the first. So we must etch the surface to obtain these structures and this process is 447.87s - 457.03s | called de-layering. Again we have seen on this slide four types of basic method of de-layering. 457.21s


chunk_id: 187_chunk_6
chunk_text:
good traceability 340.37s - 349.21s | we decided to use chemical method of decapsulation. Especially we used concentrated acid. In our case 349.21s - 361.45s | concentrated acid means 96% of concentration which must be heated to the approximately 361.67s - 370.39s | 150 degrees Fahrenheit. The chemical methods can be effectively combined with laser ablation. At 370.39s - 377.75s | first laser removes a large part of the housing and then the remaining can be dissolved in the 377.75s - 395.27s | acid. This short process during the exposure to the acid which is needed. The acid will dissolve 395.27s - 407.17s | the housing residue and leaving only the dye. Of course we must use appropriate protective 407.55s - 418.59s | equipment. After this process we obtain a beautiful etched chip suitable for other investigation. 418.59s - 436.69s | Because the chip has typically metallization on its two layers, we do not see any internal layers 436.75s - 447.87s | at the first. So we must etch the surface to obtain these structures and this process is 447.87s - 457.03s | called de-layering. Again we have seen on this slide four types of basic method of de-layering. 457.21s - 468.25s | Mechanical is the cheapest and starting about $100. Chemical, when we consider only chemical it is 468.25s - 480.09s | also not expensive. Laser ablation uses very short precise femtoseconds pulses of laser beam to 481.03s - 491.67s | ablate the surface but it is quite costly starting at 50k USD. And the last, the plasma. This is 491.67s - 500.15s | simply the nanomachining using an ion beam. It offers maximum precision but comes of course 500.15s - 512.52s | with maximum price tag as well. Due to cost effectiveness we choose to mechanical etching 512.58s - 522.38s | with a wet stone. I just slide a piece of silicon with my finger over the stone. Of course we must 522.38s - 531.78s | use a grinding stone with highest possible grit size. In our case it is 8000 grit. Of course it 531.78s - 541.26s | requires some skill and I personally mastered it around 10 samples. Too much pressure quickly 541.26s - 549.24s | obtain the background and it means we must start again. But with patience and systematic polishing 549.24s - 561.36s | we can obtain beautiful etched chip within 30 minutes or


chunk_id: 187_chunk_7
chunk_text:
- 468.25s | Mechanical is the cheapest and starting about $100. Chemical, when we consider only chemical it is 468.25s - 480.09s | also not expensive. Laser ablation uses very short precise femtoseconds pulses of laser beam to 481.03s - 491.67s | ablate the surface but it is quite costly starting at 50k USD. And the last, the plasma. This is 491.67s - 500.15s | simply the nanomachining using an ion beam. It offers maximum precision but comes of course 500.15s - 512.52s | with maximum price tag as well. Due to cost effectiveness we choose to mechanical etching 512.58s - 522.38s | with a wet stone. I just slide a piece of silicon with my finger over the stone. Of course we must 522.38s - 531.78s | use a grinding stone with highest possible grit size. In our case it is 8000 grit. Of course it 531.78s - 541.26s | requires some skill and I personally mastered it around 10 samples. Too much pressure quickly 541.26s - 549.24s | obtain the background and it means we must start again. But with patience and systematic polishing 549.24s - 561.36s | we can obtain beautiful etched chip within 30 minutes or 1 hour. Unfortunately wet stone etching 561.36s - 572.56s | alone isn't enough. Our stone has grain size about 2 microns but for the final stage it is necessary 572.56s - 584.10s | to use a diamond lapping foil which grain size has less than 0.5 microns. These foils made a 584.10s - 591.26s | significant difference providing much more smoother surface and of course reducing the number of 591.26s - 607.67s | scratches. I tried to prepare the sample on the industrial machine costing around 65 KSV and as we 607.67s - 616.91s | see on these pictures mostly the same results can be achieved when I use wet knife etching stone and 616.91s - 629.00s | the lapping foils purchased on Aliexpress for 100 bucks. Another important task is to locate the 629.00s - 640.84s | eFuse memory bank itself. The largest part of the chip is taken up by logical circuits. It is easily 640.84s - 654.88s | identified and can be skipped. The other radio frequency part is good visible too and can be skipped. 654.88s - 664.56s | And the rest we left with the rectangle purple areas and these are memory types such as


chunk_id: 187_chunk_8
chunk_text:
1 hour. Unfortunately wet stone etching 561.36s - 572.56s | alone isn't enough. Our stone has grain size about 2 microns but for the final stage it is necessary 572.56s - 584.10s | to use a diamond lapping foil which grain size has less than 0.5 microns. These foils made a 584.10s - 591.26s | significant difference providing much more smoother surface and of course reducing the number of 591.26s - 607.67s | scratches. I tried to prepare the sample on the industrial machine costing around 65 KSV and as we 607.67s - 616.91s | see on these pictures mostly the same results can be achieved when I use wet knife etching stone and 616.91s - 629.00s | the lapping foils purchased on Aliexpress for 100 bucks. Another important task is to locate the 629.00s - 640.84s | eFuse memory bank itself. The largest part of the chip is taken up by logical circuits. It is easily 640.84s - 654.88s | identified and can be skipped. The other radio frequency part is good visible too and can be skipped. 654.88s - 664.56s | And the rest we left with the rectangle purple areas and these are memory types such as RAM, flash and our 664.68s - 677.06s | eFuses. The eFuse memory cells is essentially a fuse which is conductive structures with a weak point. 677.06s - 688.18s | In our case it's looking like some triangle with a line going through it. It's looking like a flag maybe. 688.18s - 696.48s | And at approximately 500 times magnification clear repeating isolated structures of our eFuses become 696.48s - 708.02s | visible. They are relatively small and each eFuse represents once bit is smaller than 1 micron. We have 708.02s - 719.50s | successfully located these eFuse banks on ESP32 version S2, S3 and C6. It is positioned slightly differently 719.50s - 736.16s | on the C6 but the construction is the same. And now optical microscopy. Observation with optical microscopy 736.16s - 745.36s | has its limits. Maximum resolution of optical microscopy is around 400 nanometers which corresponds with 745.36s - 757.80s | 2000 times magnification. That is nearly physical limits. This magnification is suitable for locating our 758.64s - 770.93s | structures, our eFuse bank. And on well-prepared sample we can even see if the eFuse is burned or not or programmed 770.93s - 781.05s | or not.


chunk_id: 187_chunk_9
chunk_text:
RAM, flash and our 664.68s - 677.06s | eFuses. The eFuse memory cells is essentially a fuse which is conductive structures with a weak point. 677.06s - 688.18s | In our case it's looking like some triangle with a line going through it. It's looking like a flag maybe. 688.18s - 696.48s | And at approximately 500 times magnification clear repeating isolated structures of our eFuses become 696.48s - 708.02s | visible. They are relatively small and each eFuse represents once bit is smaller than 1 micron. We have 708.02s - 719.50s | successfully located these eFuse banks on ESP32 version S2, S3 and C6. It is positioned slightly differently 719.50s - 736.16s | on the C6 but the construction is the same. And now optical microscopy. Observation with optical microscopy 736.16s - 745.36s | has its limits. Maximum resolution of optical microscopy is around 400 nanometers which corresponds with 745.36s - 757.80s | 2000 times magnification. That is nearly physical limits. This magnification is suitable for locating our 758.64s - 770.93s | structures, our eFuse bank. And on well-prepared sample we can even see if the eFuse is burned or not or programmed 770.93s - 781.05s | or not. The term burned is fitting because when we program data into the eFuse memory bits during 781.05s - 792.37s | programmation going current through the fuse and physically change its structures and these changes are 792.37s - 803.74s | observable by optical or scanning electron microscopy technology. For the size comparison a human hair is 100 803.74s - 815.58s | times bigger than our eFuses. In order to read their states correctly and repeatedly we of course need 815.58s - 822.54s | some much more advanced imaging technique. And it is scanning electron microscopy which provides much more 822.54s - 833.14s | higher resolution. Scanning electron microscopy provides approximately 100 times better resolution. As I said 833.14s - 841.50s | since optical microscopy has a resolution around 400 nanometers, scanning electron microscopy has a resolution 841.54s - 850.78s | approximately 5 nanometers which corresponds to magnification 100,000 times. Of course these parameters can apply 850.78s - 860.38s | specifically to our scanning electron microscope. It is Hitachi FlexSAM. The image compares the level of detail we can 860.38s - 870.30s | achieve with these methods and the difference is significant. This is what the eFuse looks like at even higher


chunk_id: 187_chunk_10
chunk_text:
The term burned is fitting because when we program data into the eFuse memory bits during 781.05s - 792.37s | programmation going current through the fuse and physically change its structures and these changes are 792.37s - 803.74s | observable by optical or scanning electron microscopy technology. For the size comparison a human hair is 100 803.74s - 815.58s | times bigger than our eFuses. In order to read their states correctly and repeatedly we of course need 815.58s - 822.54s | some much more advanced imaging technique. And it is scanning electron microscopy which provides much more 822.54s - 833.14s | higher resolution. Scanning electron microscopy provides approximately 100 times better resolution. As I said 833.14s - 841.50s | since optical microscopy has a resolution around 400 nanometers, scanning electron microscopy has a resolution 841.54s - 850.78s | approximately 5 nanometers which corresponds to magnification 100,000 times. Of course these parameters can apply 850.78s - 860.38s | specifically to our scanning electron microscope. It is Hitachi FlexSAM. The image compares the level of detail we can 860.38s - 870.30s | achieve with these methods and the difference is significant. This is what the eFuse looks like at even higher 870.30s - 879.06s | magnification using a large electron microscope. This image shows the 3D structure which essentially looks like a 879.06s - 889.06s | printed circuit board. Everything is visible at the nanoscale. On the right image we see detail of unburned eFuse, 889.10s - 904.82s | clear eFuse representing logical zero and on the left image we see burned eFuse representing logical one. Once we obtain 904.82s - 914.30s | higher resolution images of our eFuses we can read the data stored in them. In my initial experiments I manually 914.30s - 928.18s | transcribed the data to the Excel bit by bit, fuse by fuse, which was extremely time consuming and it requires intense 928.18s - 942.90s | focus to avoid error because bits look very similar. It takes about 10 hours to read one bit of 4096 bits and 942.90s - 952.90s | additionally mapping the logical memory address to a specific cell on the silicon die was also very, very challenging. I had to 952.90s - 963.70s | carefully read and transcript about 20 kilobytes of data before we had enough for our analysis. It truly feels like a forensic 963.70s - 972.22s | investigation.


chunk_id: 187_chunk_11
chunk_text:
870.30s - 879.06s | magnification using a large electron microscope. This image shows the 3D structure which essentially looks like a 879.06s - 889.06s | printed circuit board. Everything is visible at the nanoscale. On the right image we see detail of unburned eFuse, 889.10s - 904.82s | clear eFuse representing logical zero and on the left image we see burned eFuse representing logical one. Once we obtain 904.82s - 914.30s | higher resolution images of our eFuses we can read the data stored in them. In my initial experiments I manually 914.30s - 928.18s | transcribed the data to the Excel bit by bit, fuse by fuse, which was extremely time consuming and it requires intense 928.18s - 942.90s | focus to avoid error because bits look very similar. It takes about 10 hours to read one bit of 4096 bits and 942.90s - 952.90s | additionally mapping the logical memory address to a specific cell on the silicon die was also very, very challenging. I had to 952.90s - 963.70s | carefully read and transcript about 20 kilobytes of data before we had enough for our analysis. It truly feels like a forensic 963.70s - 972.22s | investigation. And now my colleague demonstrates how to assign a logical address to a physical location of given memory. 973.22s - 985.99s | Thank you Michal for extracting all this data during your vacation. Now that we have the raw data we have to somewhat put meaning to it so that we have 985.99s - 993.55s | some useful information out of it. The best place to start with is documentation because it actually mentions a lot of information about both 993.55s - 1001.15s | logical and physical alignment of the memory. From the logical perspective it will tell us that there are 11 of eFuse blocks and that blocks zero, 1001.15s - 1010.35s | one and two are used for system purposes. These basically store MAC address, chip ID and chip configuration that you can set. The rest of the 1010.35s - 1017.71s | blocks are user programmable, meaning you could put whatever you want there, however their primary purpose is actually to store the secure boot 1017.71s - 1025.99s | keys or the flash memory encryption keys. From the physical perspective the information is a little scarce, but it will tell us that there are 1025.99s - 1035.55s |


chunk_id: 187_chunk_12
chunk_text:
And now my colleague demonstrates how to assign a logical address to a physical location of given memory. 973.22s - 985.99s | Thank you Michal for extracting all this data during your vacation. Now that we have the raw data we have to somewhat put meaning to it so that we have 985.99s - 993.55s | some useful information out of it. The best place to start with is documentation because it actually mentions a lot of information about both 993.55s - 1001.15s | logical and physical alignment of the memory. From the logical perspective it will tell us that there are 11 of eFuse blocks and that blocks zero, 1001.15s - 1010.35s | one and two are used for system purposes. These basically store MAC address, chip ID and chip configuration that you can set. The rest of the 1010.35s - 1017.71s | blocks are user programmable, meaning you could put whatever you want there, however their primary purpose is actually to store the secure boot 1017.71s - 1025.99s | keys or the flash memory encryption keys. From the physical perspective the information is a little scarce, but it will tell us that there are 1025.99s - 1035.55s | four backups of block zero, meaning that any single eFuse burned in block zero will actually result in four actual fuses burned. And blocks one to 1035.55s - 1044.23s | ten are using Reed-Solomon coding scheme for automatic error correction. This is just 12 bytes added to each of the blocks, uh but it could prove 1044.23s - 1052.15s | useful in case we cause some damage during the delayering process so we'll talk about that briefly later. So with that, let's summarize what we 1052.15s - 1060.03s | want to know. We have a lot of bits we now need to assign them to the bytes, then we want to take those bytes, put them in the correct order and 1060.03s - 1069.91s | have them assigned in the blocks and then voila, we will have our flash memory encryption key. To do that we performed several experiments and the 1069.91s - 1078.15s | first one was a really stupid one and I came up with it. And it was like let's burn values FF into the first block of an eFuses so that we can locate 1078.15s - 1086.83s | where it is. However at that time we


chunk_id: 187_chunk_13
chunk_text:
four backups of block zero, meaning that any single eFuse burned in block zero will actually result in four actual fuses burned. And blocks one to 1035.55s - 1044.23s | ten are using Reed-Solomon coding scheme for automatic error correction. This is just 12 bytes added to each of the blocks, uh but it could prove 1044.23s - 1052.15s | useful in case we cause some damage during the delayering process so we'll talk about that briefly later. So with that, let's summarize what we 1052.15s - 1060.03s | want to know. We have a lot of bits we now need to assign them to the bytes, then we want to take those bytes, put them in the correct order and 1060.03s - 1069.91s | have them assigned in the blocks and then voila, we will have our flash memory encryption key. To do that we performed several experiments and the 1069.91s - 1078.15s | first one was a really stupid one and I came up with it. And it was like let's burn values FF into the first block of an eFuses so that we can locate 1078.15s - 1086.83s | where it is. However at that time we didn't really know how painful it is to actually read them so we kind of wasted this experiment because if you burn 1086.83s - 1096.19s | only FF values you can very well detect where the first block is but you really can't detect how the bit assignment works inside these bytes and how the byte 1096.19s - 1106.07s | order works in the blocks because that information just doesn't exist in such a memory. So we quickly transitioned to the second experiment. In this case we 1106.07s - 1114.71s | were a bit smarter so we burned in unique patterns into the eFuse blocks and these unique patterns had something in common and that is that the most 1114.71s - 1125.67s | significant bits of all of the bytes in these patterns were set to 1, either 3 or 4 of them. This was because just from an overview of the memory, if you look at 1125.67s - 1134.99s | the middle picture, the big one, you can see a lot of red color in the upper portion, those are the 1s and that the lower portion has a lot of variety in it. You may 1134.99s - 1144.75s


chunk_id: 187_chunk_14
chunk_text:
didn't really know how painful it is to actually read them so we kind of wasted this experiment because if you burn 1086.83s - 1096.19s | only FF values you can very well detect where the first block is but you really can't detect how the bit assignment works inside these bytes and how the byte 1096.19s - 1106.07s | order works in the blocks because that information just doesn't exist in such a memory. So we quickly transitioned to the second experiment. In this case we 1106.07s - 1114.71s | were a bit smarter so we burned in unique patterns into the eFuse blocks and these unique patterns had something in common and that is that the most 1114.71s - 1125.67s | significant bits of all of the bytes in these patterns were set to 1, either 3 or 4 of them. This was because just from an overview of the memory, if you look at 1125.67s - 1134.99s | the middle picture, the big one, you can see a lot of red color in the upper portion, those are the 1s and that the lower portion has a lot of variety in it. You may 1134.99s - 1144.75s | think there's an ASCII text written at the bottom line, at the bottom of the picture, there are no hidden messages, this is purely coincidence. But if we take the 1144.75s - 1154.71s | only useful information from the very first experiment and filter out in those Excel files the rows that were associated with the first block, we can clearly see our 1154.71s - 1163.99s | pattern. So in this case we now know that the bits are organized in columns with the most significant bits in the upper portion of the memory and we also know the byte 1163.99s - 1173.63s | and the NS inside the blocks. This is enough for us to just extract any information we want from these memories. We did several other experiments, mainly to 1173.63s - 1184.19s | confirm that the memory is working the same way also on the other lines of the chip, so we did on S2, S3, C6, as Michal was saying. And the third one I'm showing you 1184.19s - 1195.19s | here isn't really interesting from the memory layout evaluation, but it's rather interesting because of those white fields there. Again I am to blame


chunk_id: 187_chunk_15
chunk_text:
| think there's an ASCII text written at the bottom line, at the bottom of the picture, there are no hidden messages, this is purely coincidence. But if we take the 1144.75s - 1154.71s | only useful information from the very first experiment and filter out in those Excel files the rows that were associated with the first block, we can clearly see our 1154.71s - 1163.99s | pattern. So in this case we now know that the bits are organized in columns with the most significant bits in the upper portion of the memory and we also know the byte 1163.99s - 1173.63s | and the NS inside the blocks. This is enough for us to just extract any information we want from these memories. We did several other experiments, mainly to 1173.63s - 1184.19s | confirm that the memory is working the same way also on the other lines of the chip, so we did on S2, S3, C6, as Michal was saying. And the third one I'm showing you 1184.19s - 1195.19s | here isn't really interesting from the memory layout evaluation, but it's rather interesting because of those white fields there. Again I am to blame for that, because when you do the 1195.19s - 1206.03s | layering on the whetstone and you don't clean the whetstone you have a debris that's left there and when you keep scratching with your finger you create these gigantic canyons in 1206.03s - 1218.07s | that memory where the e-fuses are just completely gone. In this case that Reed-Solomon automatic error correction could actually prove useful to recover the information, however for like 1218.07s - 1228.11s | future proofing these methods we rather spend the time on improving the layering method because for example block 0 here doesn't have any automatic error correction and the other 1228.15s - 1242.17s | chips don't have that as well. It was just that in case of ESP32, if you do some damage to the chip you can actually recover for it using this automatic error correction. Uh so now this image will show you the layout of the 1242.17s - 1257.17s | memory so the full green row at the top and the bottom of the picture and 6 others, full green rows in between, that's block 0 so that's where those 4 times duplicated values actually go to. Uh for example


chunk_id: 187_chunk_16
chunk_text:
for that, because when you do the 1195.19s - 1206.03s | layering on the whetstone and you don't clean the whetstone you have a debris that's left there and when you keep scratching with your finger you create these gigantic canyons in 1206.03s - 1218.07s | that memory where the e-fuses are just completely gone. In this case that Reed-Solomon automatic error correction could actually prove useful to recover the information, however for like 1218.07s - 1228.11s | future proofing these methods we rather spend the time on improving the layering method because for example block 0 here doesn't have any automatic error correction and the other 1228.15s - 1242.17s | chips don't have that as well. It was just that in case of ESP32, if you do some damage to the chip you can actually recover for it using this automatic error correction. Uh so now this image will show you the layout of the 1242.17s - 1257.17s | memory so the full green row at the top and the bottom of the picture and 6 others, full green rows in between, that's block 0 so that's where those 4 times duplicated values actually go to. Uh for example if you 1257.17s - 1262.17s | disable JTAG, that's where 4 e-fuses will be burned. And the 1262.17s - 1265.21s | rest of the colorful blocks, and I'm sorry for using too many 1265.21s - 1268.21s | shades of green, but I'm bad with colors. Anyway, the rest of 1268.21s - 1270.91s | this color of, uh, the rest of the blocks here are the user 1270.91s - 1275.01s | writable blocks. Most tutorials on the internet will just tell 1275.01s - 1279.49s | you please put your encryption key into the purple one here. So 1279.49s - 1283.89s | that's where we will be focusing the most. Uh, but once you know 1283.89s - 1286.13s | the alignment of the blocks, it doesn't really matter which 1286.13s - 1289.09s | blocks you extract. You just get the coordinates from the 1289.09s - 1293.07s | extracted data. Uh, the biggest problem at this point was that 1293.07s - 1296.81s | Michal refused to read that manually, uh, anymore after 1296.81s - 1301.21s | whatever amount of bits he read. So we had to turn to our machine 1301.21s - 1304.71s | learning guru to help us automate the process. Uh,


chunk_id: 187_chunk_17
chunk_text:
if you 1257.17s - 1262.17s | disable JTAG, that's where 4 e-fuses will be burned. And the 1262.17s - 1265.21s | rest of the colorful blocks, and I'm sorry for using too many 1265.21s - 1268.21s | shades of green, but I'm bad with colors. Anyway, the rest of 1268.21s - 1270.91s | this color of, uh, the rest of the blocks here are the user 1270.91s - 1275.01s | writable blocks. Most tutorials on the internet will just tell 1275.01s - 1279.49s | you please put your encryption key into the purple one here. So 1279.49s - 1283.89s | that's where we will be focusing the most. Uh, but once you know 1283.89s - 1286.13s | the alignment of the blocks, it doesn't really matter which 1286.13s - 1289.09s | blocks you extract. You just get the coordinates from the 1289.09s - 1293.07s | extracted data. Uh, the biggest problem at this point was that 1293.07s - 1296.81s | Michal refused to read that manually, uh, anymore after 1296.81s - 1301.21s | whatever amount of bits he read. So we had to turn to our machine 1301.21s - 1304.71s | learning guru to help us automate the process. Uh, his 1304.71s - 1307.25s | name is Hayan and he unfortunately couldn't be here 1307.25s - 1311.05s | with us. Uh, but he prerecorded the message, uh, prerecorded his 1311.05s - 1314.39s | part of the presentation, which I'll try to play now. There's 1314.39s - 1319.59s | about a 50% chance it's going to play. Uh, if it does not, I 1319.59s - 1322.25s | will still play it and I'll try to comment it. So you will not 1322.25s - 1323.93s | learn anything useful. So let's see. 1325.87s - 1328.93s | Hello, I'm Hayan Eri, security database senior analyst in 1328.93s - 1331.87s | Accenture. And also I'm doing a PhD in music, which I learned 1331.87s - 1334.91s | in the four violin clubs. I will go through the automation 1334.91s - 1338.95s | process and show you finally a demo about it. Let's go. 1339.91s - 1344.95s | Instead of a visual reading of the effuses from the images, we 1344.95s - 1347.95s | automated the process. We started from the output of 1347.95s - 1351.75s | microscope, where there are around 200 images for each one. 1352.59s - 1355.69s | First we stitched these


chunk_id: 187_chunk_18
chunk_text:
his 1304.71s - 1307.25s | name is Hayan and he unfortunately couldn't be here 1307.25s - 1311.05s | with us. Uh, but he prerecorded the message, uh, prerecorded his 1311.05s - 1314.39s | part of the presentation, which I'll try to play now. There's 1314.39s - 1319.59s | about a 50% chance it's going to play. Uh, if it does not, I 1319.59s - 1322.25s | will still play it and I'll try to comment it. So you will not 1322.25s - 1323.93s | learn anything useful. So let's see. 1325.87s - 1328.93s | Hello, I'm Hayan Eri, security database senior analyst in 1328.93s - 1331.87s | Accenture. And also I'm doing a PhD in music, which I learned 1331.87s - 1334.91s | in the four violin clubs. I will go through the automation 1334.91s - 1338.95s | process and show you finally a demo about it. Let's go. 1339.91s - 1344.95s | Instead of a visual reading of the effuses from the images, we 1344.95s - 1347.95s | automated the process. We started from the output of 1347.95s - 1351.75s | microscope, where there are around 200 images for each one. 1352.59s - 1355.69s | First we stitched these images to get only one image per one, 1356.03s - 1359.67s | then pre-processing before applying the machine learning, 1359.87s - 1362.27s | then applying the machine learning object detection model, 1362.63s - 1368.43s | then extracting the effuses values into the arrays. 1369.91s - 1373.51s | The microscope provides high resolution images when working 1373.51s - 1378.31s | in zigzag mode. In zigzag mode, the microscope scans the palm in 1378.31s - 1382.31s | zigzag line, as we see here in the figure, generating around 1382.59s - 1389.43s | 200 images for each one. Each image is 2,560 by 1,920. We can 1389.43s - 1393.03s | see this image is high resolution image as we can 1393.03s - 1396.23s | distinguish between the off effuse, which is the default 1396.31s - 1403.39s | state, and the blown one, which is the on case. We keep margin 1403.39s - 1411.27s | by 35% between images to avoid wasting any pixels. Then we 1411.27s - 1417.03s | stitch these images to get one image per bank. But when using 1417.31s - 1422.51s | the embedded stitching tool in the microscope, we get bad 1422.55s - 1426.67s | stitching. For example, there


chunk_id: 187_chunk_19
chunk_text:
images to get only one image per one, 1356.03s - 1359.67s | then pre-processing before applying the machine learning, 1359.87s - 1362.27s | then applying the machine learning object detection model, 1362.63s - 1368.43s | then extracting the effuses values into the arrays. 1369.91s - 1373.51s | The microscope provides high resolution images when working 1373.51s - 1378.31s | in zigzag mode. In zigzag mode, the microscope scans the palm in 1378.31s - 1382.31s | zigzag line, as we see here in the figure, generating around 1382.59s - 1389.43s | 200 images for each one. Each image is 2,560 by 1,920. We can 1389.43s - 1393.03s | see this image is high resolution image as we can 1393.03s - 1396.23s | distinguish between the off effuse, which is the default 1396.31s - 1403.39s | state, and the blown one, which is the on case. We keep margin 1403.39s - 1411.27s | by 35% between images to avoid wasting any pixels. Then we 1411.27s - 1417.03s | stitch these images to get one image per bank. But when using 1417.31s - 1422.51s | the embedded stitching tool in the microscope, we get bad 1422.55s - 1426.67s | stitching. For example, there is misalignment between zero and 1426.67s - 1430.43s | one, or two, one, two, two, or between first row and second 1430.43s - 1435.95s | row. The reason behind this misalignment is that the margin 1435.99s - 1441.75s | is theoretically 35%. But practically speaking is 1442.35s - 1447.67s | something random around this value. That's why we suggested 1448.07s - 1452.63s | a new stitching method. In this method, to stitch two images, 1452.63s - 1455.11s | one and two, we define comparison strip in the first 1455.11s - 1461.43s | image and look for the similar strip in a stitching area in the 1461.43s - 1466.47s | second image. A stitching area is plus minus 200 pixels around 1466.47s - 1471.43s | the margin line. When defining the similar strip, we determine 1471.43s - 1475.35s | the margin accurately and also the vertical shift between 1475.35s - 1478.75s | images. Here we can see the result of stitching image one 1478.75s - 1483.23s | and two. The advantage of this method is to accurate, but 1483.27s - 1488.59s | downside is the long time it takes. For example, to stitch 1488.71s - 1492.87s | 200 images to constitute


chunk_id: 187_chunk_20
chunk_text:
is misalignment between zero and 1426.67s - 1430.43s | one, or two, one, two, two, or between first row and second 1430.43s - 1435.95s | row. The reason behind this misalignment is that the margin 1435.99s - 1441.75s | is theoretically 35%. But practically speaking is 1442.35s - 1447.67s | something random around this value. That's why we suggested 1448.07s - 1452.63s | a new stitching method. In this method, to stitch two images, 1452.63s - 1455.11s | one and two, we define comparison strip in the first 1455.11s - 1461.43s | image and look for the similar strip in a stitching area in the 1461.43s - 1466.47s | second image. A stitching area is plus minus 200 pixels around 1466.47s - 1471.43s | the margin line. When defining the similar strip, we determine 1471.43s - 1475.35s | the margin accurately and also the vertical shift between 1475.35s - 1478.75s | images. Here we can see the result of stitching image one 1478.75s - 1483.23s | and two. The advantage of this method is to accurate, but 1483.27s - 1488.59s | downside is the long time it takes. For example, to stitch 1488.71s - 1492.87s | 200 images to constitute one bank image, it will take around 1492.87s - 1496.95s | five hours. Here we can see the result of stitching for one 1496.95s - 1505.83s | bank image. Its high resolution image is 34,000 by 12,000 image. 1506.63s - 1511.91s | To effectively use AI to extract the fuses, we use Jetson 1511.91s - 1517.19s | Ajax Orion from NVIDIA. It has 64 gigabyte RAM and 2048 CUDA 1517.19s - 1522.79s | cores and 64 tensor cores, which makes it good for the image 1522.79s - 1528.15s | based AI projects like object detection projects. We use also 1528.19s - 1533.15s | MobileNet SSD model, which provides a balance between speed 1533.15s - 1539.51s | and accuracy. This model is trained to detect fuses in the 1539.51s - 1542.79s | images in terms of the coordinates of the fuses in the 1542.79s - 1547.39s | images. Also, it's a class whether it is on or off. Here 1548.39s - 1553.99s | the example of on if-use and this is off if-use, which is the 1554.03s - 1561.39s | default state of the if-use. What is the optimal input of the 1561.39s - 1567.55s | model? We read from the


chunk_id: 187_chunk_21
chunk_text:
one bank image, it will take around 1492.87s - 1496.95s | five hours. Here we can see the result of stitching for one 1496.95s - 1505.83s | bank image. Its high resolution image is 34,000 by 12,000 image. 1506.63s - 1511.91s | To effectively use AI to extract the fuses, we use Jetson 1511.91s - 1517.19s | Ajax Orion from NVIDIA. It has 64 gigabyte RAM and 2048 CUDA 1517.19s - 1522.79s | cores and 64 tensor cores, which makes it good for the image 1522.79s - 1528.15s | based AI projects like object detection projects. We use also 1528.19s - 1533.15s | MobileNet SSD model, which provides a balance between speed 1533.15s - 1539.51s | and accuracy. This model is trained to detect fuses in the 1539.51s - 1542.79s | images in terms of the coordinates of the fuses in the 1542.79s - 1547.39s | images. Also, it's a class whether it is on or off. Here 1548.39s - 1553.99s | the example of on if-use and this is off if-use, which is the 1554.03s - 1561.39s | default state of the if-use. What is the optimal input of the 1561.39s - 1567.55s | model? We read from the MobileNet SSD model documents, the 1567.59s - 1571.91s | optimal size for training and also for inference is 300 by 1571.91s - 1578.03s | 300. Also, we should meet another condition, which is the 1578.71s - 1583.83s | object, which is if-use size to the image size should be bigger 1583.83s - 1587.71s | than predefined ratio. This ratio, in our case, is defined 1587.71s - 1593.99s | using practical experience. It is 0.04. Here we can see the 1593.99s - 1598.55s | example of the optimal image and we can see also the size of the 1598.71s - 1603.55s | if-use regarding to the image size. We meet these two 1603.55s - 1607.79s | conditions using resizing and tiling. When tiling the 1607.83s - 1612.15s | stitched image, we keep 100 pixels overlapping between 1612.15s - 1617.55s | tiles to be sure that the whole size of if-use is exist, at 1617.55s - 1624.31s | least in one tile. When training the model, we used 3500 training 1624.31s - 1628.55s | tiles with balanced number between on and off fuses. We 1628.55s - 1634.03s | used CFAT tool, which is a web-based AI free tool to 1634.03s - 1637.99s


chunk_id: 187_chunk_22
chunk_text:
MobileNet SSD model documents, the 1567.59s - 1571.91s | optimal size for training and also for inference is 300 by 1571.91s - 1578.03s | 300. Also, we should meet another condition, which is the 1578.71s - 1583.83s | object, which is if-use size to the image size should be bigger 1583.83s - 1587.71s | than predefined ratio. This ratio, in our case, is defined 1587.71s - 1593.99s | using practical experience. It is 0.04. Here we can see the 1593.99s - 1598.55s | example of the optimal image and we can see also the size of the 1598.71s - 1603.55s | if-use regarding to the image size. We meet these two 1603.55s - 1607.79s | conditions using resizing and tiling. When tiling the 1607.83s - 1612.15s | stitched image, we keep 100 pixels overlapping between 1612.15s - 1617.55s | tiles to be sure that the whole size of if-use is exist, at 1617.55s - 1624.31s | least in one tile. When training the model, we used 3500 training 1624.31s - 1628.55s | tiles with balanced number between on and off fuses. We 1628.55s - 1634.03s | used CFAT tool, which is a web-based AI free tool to 1634.03s - 1637.99s | annotate the if-uses. Here we can see example of annotation. 1638.03s - 1642.07s | We use different colors when drawing boxes about the on and 1642.07s - 1648.67s | off if-uses. The training results, the detection accuracy 1648.71s - 1654.23s | 99%, the classification accuracy 97% and also we got fake 1654.23s - 1658.79s | detection where non-if-use objects are detected as if-uses, 1659.07s - 1663.39s | but these fake detections will be resolved during the post 1663.43s - 1669.59s | processing after prediction. Now we have stitched image. What 1669.59s - 1675.75s | do we do to extract the if-uses? First, we tile this stitched 1675.75s - 1680.35s | image to 2500 tiles. Then we apply the inference using the 1680.35s - 1685.35s | trained machine learning model. The inference results for each 1685.35s - 1690.91s | tiles are three things. First, the continuous of if-uses in the 1690.91s - 1693.83s | tile and also the classification of the if-uses 1693.83s - 1698.07s | whether they are on or off and also the confidence score which 1698.07s - 1701.67s | corresponds to how the machine learning model is confident 1701.75s - 1706.59s | about the classification. These three


chunk_id: 187_chunk_23
chunk_text:
| annotate the if-uses. Here we can see example of annotation. 1638.03s - 1642.07s | We use different colors when drawing boxes about the on and 1642.07s - 1648.67s | off if-uses. The training results, the detection accuracy 1648.71s - 1654.23s | 99%, the classification accuracy 97% and also we got fake 1654.23s - 1658.79s | detection where non-if-use objects are detected as if-uses, 1659.07s - 1663.39s | but these fake detections will be resolved during the post 1663.43s - 1669.59s | processing after prediction. Now we have stitched image. What 1669.59s - 1675.75s | do we do to extract the if-uses? First, we tile this stitched 1675.75s - 1680.35s | image to 2500 tiles. Then we apply the inference using the 1680.35s - 1685.35s | trained machine learning model. The inference results for each 1685.35s - 1690.91s | tiles are three things. First, the continuous of if-uses in the 1690.91s - 1693.83s | tile and also the classification of the if-uses 1693.83s - 1698.07s | whether they are on or off and also the confidence score which 1698.07s - 1701.67s | corresponds to how the machine learning model is confident 1701.75s - 1706.59s | about the classification. These three things, results from all 1706.59s - 1711.15s | the tiles will be re-aggregated again on the stitched image. 1712.39s - 1718.71s | Then the duplicates will be removed with keeping only the 1718.75s - 1724.35s | highest confidence score. Finally, any if-use with 1724.59s - 1730.39s | confidence score less than 95% will be visually checked. 1732.19s - 1737.63s | Finally, we will use dbScan clustering method to define the 1737.67s - 1743.23s | outliers out of the columns and remove them. Then we use another 1743.23s - 1748.35s | clustering method to group the if-uses in columns and exporting 1748.55s - 1754.39s | their values into the arrays 1s and 0s. We repeat the same 1754.39s - 1759.11s | process for another bank as we know there are lower bank and 1759.11s - 1764.83s | upper bank. Finally, we will get a 64 by 64 array and then we'll 1764.83s - 1771.11s | go through the next steps as my colleagues explained. We will 1771.15s - 1777.63s | extract the encryption key from the array and use this key to 1777.67s - 1782.19s | decrypt the encrypted firmware. We will see these steps in the 1782.19s - 1797.01s |


chunk_id: 187_chunk_24
chunk_text:
things, results from all 1706.59s - 1711.15s | the tiles will be re-aggregated again on the stitched image. 1712.39s - 1718.71s | Then the duplicates will be removed with keeping only the 1718.75s - 1724.35s | highest confidence score. Finally, any if-use with 1724.59s - 1730.39s | confidence score less than 95% will be visually checked. 1732.19s - 1737.63s | Finally, we will use dbScan clustering method to define the 1737.67s - 1743.23s | outliers out of the columns and remove them. Then we use another 1743.23s - 1748.35s | clustering method to group the if-uses in columns and exporting 1748.55s - 1754.39s | their values into the arrays 1s and 0s. We repeat the same 1754.39s - 1759.11s | process for another bank as we know there are lower bank and 1759.11s - 1764.83s | upper bank. Finally, we will get a 64 by 64 array and then we'll 1764.83s - 1771.11s | go through the next steps as my colleagues explained. We will 1771.15s - 1777.63s | extract the encryption key from the array and use this key to 1777.67s - 1782.19s | decrypt the encrypted firmware. We will see these steps in the 1782.19s - 1797.01s | demo. Let's go. We have firmware image where the main program 1797.37s - 1802.09s | prints periodically the sentence Hello Las Vegas. This firmware 1802.13s - 1805.37s | is encrypted. That's why when we look for Hello World, we can 1805.37s - 1814.90s | find nothing. Here we will see the images of lower bank and 1814.90s - 1823.46s | upper bank of the chip holding the encrypted firmware. Here are 1823.46s - 1831.62s | the images of lower bank before stitching. Here the image of 1832.26s - 1838.70s | stitched lower bank. You can see the high resolution of the 1838.70s - 1844.42s | stitched image. Now we will apply the if-use detection 1844.86s - 1851.30s | script. This script will go through the stitched lower bank 1851.30s - 1855.26s | and upper bank, do pre-processing, tiling of the 1855.26s - 1860.82s | images, and prepare the images to be optimal input for the 1860.86s - 1866.22s | model. These tiles will be stored in the folder for 1866.22s - 1876.70s | inference, this folder. Now, the script will run the machine 1876.70s - 1883.46s | learning model, which is trained. This model will do the 1883.46s - 1891.82s


chunk_id: 187_chunk_25
chunk_text:
demo. Let's go. We have firmware image where the main program 1797.37s - 1802.09s | prints periodically the sentence Hello Las Vegas. This firmware 1802.13s - 1805.37s | is encrypted. That's why when we look for Hello World, we can 1805.37s - 1814.90s | find nothing. Here we will see the images of lower bank and 1814.90s - 1823.46s | upper bank of the chip holding the encrypted firmware. Here are 1823.46s - 1831.62s | the images of lower bank before stitching. Here the image of 1832.26s - 1838.70s | stitched lower bank. You can see the high resolution of the 1838.70s - 1844.42s | stitched image. Now we will apply the if-use detection 1844.86s - 1851.30s | script. This script will go through the stitched lower bank 1851.30s - 1855.26s | and upper bank, do pre-processing, tiling of the 1855.26s - 1860.82s | images, and prepare the images to be optimal input for the 1860.86s - 1866.22s | model. These tiles will be stored in the folder for 1866.22s - 1876.70s | inference, this folder. Now, the script will run the machine 1876.70s - 1883.46s | learning model, which is trained. This model will do the 1883.46s - 1891.82s | inference and detect the if-uses classes on and off, and 1891.82s - 1895.86s | also the confidence scores of the classifications. Starting 1895.86s - 1912.81s | from the upper bank, then the lower bank script will store all 1912.81s - 1916.29s | of these inference results or in-folder inference results. 1917.65s - 1923.77s | Now the script will ask for visually checking the if-uses 1924.05s - 1927.53s | where there are different classifications due to tiles 1927.53s - 1933.29s | overlapping. For the lower bank, we have 11 if-uses should be 1933.29s - 1941.91s | checked. The checking should be whether the if-use unbound 1941.91s - 1953.29s | means off or bound means on or not if-use. For the upper bank, 1953.29s - 1974.14s | we have zero if-uses to be checked. Visually, if the if-use 1974.46s - 1980.02s | with confidence score is then 95%. We have eight if-uses to be 1980.02s - 2008.82s | checked in the lower bank and 13 in the upper bank. After that, 2008.82s - 2012.38s | the script will show us the distribution of the if-uses in 2012.38s - 2020.22s | the image. We can note that no outliers and also in


chunk_id: 187_chunk_26
chunk_text:
| inference and detect the if-uses classes on and off, and 1891.82s - 1895.86s | also the confidence scores of the classifications. Starting 1895.86s - 1912.81s | from the upper bank, then the lower bank script will store all 1912.81s - 1916.29s | of these inference results or in-folder inference results. 1917.65s - 1923.77s | Now the script will ask for visually checking the if-uses 1924.05s - 1927.53s | where there are different classifications due to tiles 1927.53s - 1933.29s | overlapping. For the lower bank, we have 11 if-uses should be 1933.29s - 1941.91s | checked. The checking should be whether the if-use unbound 1941.91s - 1953.29s | means off or bound means on or not if-use. For the upper bank, 1953.29s - 1974.14s | we have zero if-uses to be checked. Visually, if the if-use 1974.46s - 1980.02s | with confidence score is then 95%. We have eight if-uses to be 1980.02s - 2008.82s | checked in the lower bank and 13 in the upper bank. After that, 2008.82s - 2012.38s | the script will show us the distribution of the if-uses in 2012.38s - 2020.22s | the image. We can note that no outliers and also in the upper 2020.22s - 2026.66s | bank. As everything is okay, the script will export the values 2026.66s - 2036.71s | of if-uses as zeros at once. The script also will extract the 2036.71s - 2041.67s | flush key file, which contains the encryption keys of the 2041.67s - 2051.19s | firmware and here the 64 by 64 array of ones and zeros. We will 2051.19s - 2055.35s | use the flush key file to decrypt the encrypted firmware 2055.71s - 2063.59s | and get the decrypt.bin file, which is the decrypted firmware. 2069.54s - 2077.06s | Here is the decrypted.bin file. We should look for hello in this 2077.06s - 2086.94s | file. We should find something. And here we are. Thanks. I will 2086.94s - 2090.90s | go back to my colleagues to conclude the presentation. 2093.39s - 2096.63s | Okay, I know it's 3am in Prague, but Haijan, if you're watching, 2096.63s - 2103.23s | thanks for the video. Now to conclude real quick. If you have 2103.23s - 2108.23s | an information that you would like to store, if you like have 2108.23s - 2110.75s | an information that you would like to keep secret and


chunk_id: 187_chunk_27
chunk_text:
the upper 2020.22s - 2026.66s | bank. As everything is okay, the script will export the values 2026.66s - 2036.71s | of if-uses as zeros at once. The script also will extract the 2036.71s - 2041.67s | flush key file, which contains the encryption keys of the 2041.67s - 2051.19s | firmware and here the 64 by 64 array of ones and zeros. We will 2051.19s - 2055.35s | use the flush key file to decrypt the encrypted firmware 2055.71s - 2063.59s | and get the decrypt.bin file, which is the decrypted firmware. 2069.54s - 2077.06s | Here is the decrypted.bin file. We should look for hello in this 2077.06s - 2086.94s | file. We should find something. And here we are. Thanks. I will 2086.94s - 2090.90s | go back to my colleagues to conclude the presentation. 2093.39s - 2096.63s | Okay, I know it's 3am in Prague, but Haijan, if you're watching, 2096.63s - 2103.23s | thanks for the video. Now to conclude real quick. If you have 2103.23s - 2108.23s | an information that you would like to store, if you like have 2108.23s - 2110.75s | an information that you would like to keep secret and you need 2110.75s - 2114.75s | to store it in a chip and you have a choice to do so, please 2114.75s - 2118.87s | do not put it in any fuse-based memory. In the case of ESP32 2118.87s - 2121.91s | chip, if you want to encrypt the flash memory, and you really 2121.91s - 2125.39s | should if you want to, you have no other choices. So in this 2125.39s - 2128.67s | case, you should use countermeasures such as using a 2128.67s - 2133.55s | unique key per each chip, not just use the same key for every 2133.55s - 2138.59s | device. If you have a choice to store it in some HSM module, 2138.59s - 2142.35s | physical unclonable functional protected memory or anti-fuses, 2142.35s - 2146.67s | whatever you have, it would be a better way. Because any fuse 2146.67s - 2151.15s | based memory is just readable based on its physical 2151.15s - 2154.67s | properties. And the readability protection methods such as 2154.67s - 2158.71s | layering, they do increase the effort by putting obstacles in 2158.71s - 2161.59s | between the malicious actor and the information that you're 2161.59s - 2165.19s


chunk_id: 187_chunk_28
chunk_text:
you need 2110.75s - 2114.75s | to store it in a chip and you have a choice to do so, please 2114.75s - 2118.87s | do not put it in any fuse-based memory. In the case of ESP32 2118.87s - 2121.91s | chip, if you want to encrypt the flash memory, and you really 2121.91s - 2125.39s | should if you want to, you have no other choices. So in this 2125.39s - 2128.67s | case, you should use countermeasures such as using a 2128.67s - 2133.55s | unique key per each chip, not just use the same key for every 2133.55s - 2138.59s | device. If you have a choice to store it in some HSM module, 2138.59s - 2142.35s | physical unclonable functional protected memory or anti-fuses, 2142.35s - 2146.67s | whatever you have, it would be a better way. Because any fuse 2146.67s - 2151.15s | based memory is just readable based on its physical 2151.15s - 2154.67s | properties. And the readability protection methods such as 2154.67s - 2158.71s | layering, they do increase the effort by putting obstacles in 2158.71s - 2161.59s | between the malicious actor and the information that you're 2161.59s - 2165.19s | trying to protect. They don't prevent reading. In this case, 2165.19s - 2167.95s | we had to destroy the chip in process of recovering this 2167.95s - 2172.51s | information. But since our goal was to recover an unencrypted 2172.51s - 2175.83s | firmware image, we didn't really care about that, because we 2175.83s - 2180.39s | don't need it to run, we just want to read the firmware. The 2180.39s - 2184.07s | assumption about the delay ring being expensive, complex and 2184.07s - 2189.31s | whatnot has basically been destroyed. Because if you have a 2189.31s - 2195.99s | sink, whetstone, and at least two fingers, you could do that 2196.27s - 2199.51s | in your home conditions. And if you also can rent a microscope 2199.51s - 2202.55s | on your local university for a couple hours to just scan some 2202.71s - 2206.95s | location on chip, then you can do the recovery of the 2206.95s - 2212.11s | information at home. So it's rather easy and cheap, if you're 2212.11s - 2216.03s | willing to sacrifice a bit of your fingers. Are there two 2216.03s - 2220.31s | things I'd like to point out


chunk_id: 187_chunk_29
chunk_text:
| trying to protect. They don't prevent reading. In this case, 2165.19s - 2167.95s | we had to destroy the chip in process of recovering this 2167.95s - 2172.51s | information. But since our goal was to recover an unencrypted 2172.51s - 2175.83s | firmware image, we didn't really care about that, because we 2175.83s - 2180.39s | don't need it to run, we just want to read the firmware. The 2180.39s - 2184.07s | assumption about the delay ring being expensive, complex and 2184.07s - 2189.31s | whatnot has basically been destroyed. Because if you have a 2189.31s - 2195.99s | sink, whetstone, and at least two fingers, you could do that 2196.27s - 2199.51s | in your home conditions. And if you also can rent a microscope 2199.51s - 2202.55s | on your local university for a couple hours to just scan some 2202.71s - 2206.95s | location on chip, then you can do the recovery of the 2206.95s - 2212.11s | information at home. So it's rather easy and cheap, if you're 2212.11s - 2216.03s | willing to sacrifice a bit of your fingers. Are there two 2216.03s - 2220.31s | things I'd like to point out still. The first one is to thank 2220.31s - 2223.71s | to Espressif, because they allowed us to have this talk. And 2223.71s - 2226.31s | the communication with them was really smooth. So thanks for 2226.31s - 2230.27s | that. And finally, I'd like to admit to a lie, because at the 2230.27s - 2234.71s | very beginning, I told you that if you burn an eFuse from state 2234.71s - 2241.51s | zero to one, you cannot unburn it. I lied because you can. But 2241.51s - 2244.51s | the processes around this are really complex and really 2244.51s - 2248.79s | expensive. So I'd like to keep this as a separate topic for 2248.79s - 2254.27s | perhaps next time. And we can transition into the Q&A session, 2254.27s - 2257.79s | which as I've heard, we will be doing as we will be going. But 2257.79s - 2262.75s | wait, we also have a giveaway. We have 20 decapsulated ESP32 2262.75s - 2266.83s | chips in a vials that look like that they hold some bacteria, 2266.83s - 2271.31s | but we promise that they did not. And we could just take them 2271.31s - 2275.23s


chunk_id: 187_chunk_30
chunk_text:
still. The first one is to thank 2220.31s - 2223.71s | to Espressif, because they allowed us to have this talk. And 2223.71s - 2226.31s | the communication with them was really smooth. So thanks for 2226.31s - 2230.27s | that. And finally, I'd like to admit to a lie, because at the 2230.27s - 2234.71s | very beginning, I told you that if you burn an eFuse from state 2234.71s - 2241.51s | zero to one, you cannot unburn it. I lied because you can. But 2241.51s - 2244.51s | the processes around this are really complex and really 2244.51s - 2248.79s | expensive. So I'd like to keep this as a separate topic for 2248.79s - 2254.27s | perhaps next time. And we can transition into the Q&A session, 2254.27s - 2257.79s | which as I've heard, we will be doing as we will be going. But 2257.79s - 2262.75s | wait, we also have a giveaway. We have 20 decapsulated ESP32 2262.75s - 2266.83s | chips in a vials that look like that they hold some bacteria, 2266.83s - 2271.31s | but we promise that they did not. And we could just take them 2271.31s - 2275.23s | and try the layering process at home if you want to, or you just 2275.23s - 2278.83s | as a souvenir. So thank you for attention. And we will be 2278.83s - 2280.15s | answering questions as we go.


chunk_id: 187_chunk_31
chunk_text:
| and try the layering process at home if you want to, or you just 2275.23s - 2278.83s | as a souvenir. So thank you for attention. And we will be 2278.83s - 2280.15s | answering questions as we go.


chunk_id: 188_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=sfma7ymwmdA", "title": "DEF CON 32 - Bug Hunting In VMware Device Virtualization - JiaQing Huang, Hao Zheng, Yue Liu", "description": "In this presentation, we will unveil a new attack surface: Device Virtualization in VMKernel. This isan unknown territory that has not been explored by security researchers to date. During the reverse engineering of the VMware Hypervisor, we discovered 8 vulnerabilities related to device virtualization, 3 of them have been assigned CVE number (some vulnerabilities have even been successfully exploited in Tianfu Cup), and the remaining 5 of our vulnerabilities have been officially confirmed by VMware.\n\nFirstly we will delve into the loading process of vmm, the implementation of data sharing between vmm and vmx, and VMware's UserRPC, which facilitates communication between the Hypervisor and the Host. These mechanisms are crucial in virtual device emulation.\n\nThen We will explain security issues in various parts of the USB system, including the host controller, VUsb middleware, and VUsb backend devices, based on the vulnerabilities we have unearthed.\n\nIn the end, We will primarily discuss the similarities and differences in SCSI-related device emulation in the virtual disk system between VMware Workstation and ESXi Additionally, we will cover design flaws related to disk device emulation that we discovered in VMKernel.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2351, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.36s - 11.52s | This text was transcribed using whisper model: large-v2 We are excited to share our talk with you and also feel a little disappointed for we 11.52s - 14.96s | cannot arrive at DEF CON in person. 14.96s - 20.00s | And we do hope our talk will serve as a guide for anyone who's looking to start VMware security 20.00s - 21.00s | research. 21.00s - 28.40s | Firstly, allow me to introduce us to you. 28.40s - 33.80s | My name is Jiaxin Huang, and Hao Zheng and me are both security researchers of Tenggong 33.80s - 36.36s | team at Xianxin Group. 36.36s - 41.12s | And we are both interested in reverse engineering and visualization security. 41.12s - 49.20s | Yueliu is our team leader, and our team consists of lots of people interested in viral security 49.20s - 50.20s | domain. 50.20s - 53.56s | And we have a website to post our blog on it. 53.56s - 57.96s | So if you are interested in it, make sure to follow us. 57.96s - 65.20s | And


chunk_id: 188_chunk_1
chunk_text:
we discovered in VMKernel.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2351, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.36s - 11.52s | This text was transcribed using whisper model: large-v2 We are excited to share our talk with you and also feel a little disappointed for we 11.52s - 14.96s | cannot arrive at DEF CON in person. 14.96s - 20.00s | And we do hope our talk will serve as a guide for anyone who's looking to start VMware security 20.00s - 21.00s | research. 21.00s - 28.40s | Firstly, allow me to introduce us to you. 28.40s - 33.80s | My name is Jiaxin Huang, and Hao Zheng and me are both security researchers of Tenggong 33.80s - 36.36s | team at Xianxin Group. 36.36s - 41.12s | And we are both interested in reverse engineering and visualization security. 41.12s - 49.20s | Yueliu is our team leader, and our team consists of lots of people interested in viral security 49.20s - 50.20s | domain. 50.20s - 53.56s | And we have a website to post our blog on it. 53.56s - 57.96s | So if you are interested in it, make sure to follow us. 57.96s - 65.20s | And if you have any questions, feel free to DM or email us. 65.20s - 66.60s | Here's the short story. 66.60s - 69.96s | Let's describe our visualization backcounting journey. 69.96s - 76.32s | We actually started to research visualization security from the end of 2022. 76.32s - 81.76s | And in that time, we basically know nothing about visualization. 81.76s - 85.24s | So why are we interested in it? 85.24s - 89.60s | Because visualization is involved in lots of hacking contests. 89.60s - 93.28s | And it's a very hard, very challenging target. 93.28s - 98.88s | And for myself, I want to reverse engineer it and learn how it works. 98.88s - 102.30s | So what have we achieved in last year? 102.30s - 108.80s | We successfully escaped from the paralyzed desktop on GeekCon 2023. 108.80s - 115.44s | And we reported lots of workstation EXXI bugs to VMware. 115.44s - 125.41s | And we learned a lot, not just about visualization, but about the whole architecture of the entire 125.41s - 126.41s | computer. 126.41s - 129.21s | So what can we bring to you today? 129.21s - 135.09s | Firstly, we will introduce


chunk_id: 188_chunk_2
chunk_text:
if you have any questions, feel free to DM or email us. 65.20s - 66.60s | Here's the short story. 66.60s - 69.96s | Let's describe our visualization backcounting journey. 69.96s - 76.32s | We actually started to research visualization security from the end of 2022. 76.32s - 81.76s | And in that time, we basically know nothing about visualization. 81.76s - 85.24s | So why are we interested in it? 85.24s - 89.60s | Because visualization is involved in lots of hacking contests. 89.60s - 93.28s | And it's a very hard, very challenging target. 93.28s - 98.88s | And for myself, I want to reverse engineer it and learn how it works. 98.88s - 102.30s | So what have we achieved in last year? 102.30s - 108.80s | We successfully escaped from the paralyzed desktop on GeekCon 2023. 108.80s - 115.44s | And we reported lots of workstation EXXI bugs to VMware. 115.44s - 125.41s | And we learned a lot, not just about visualization, but about the whole architecture of the entire 125.41s - 126.41s | computer. 126.41s - 129.21s | So what can we bring to you today? 129.21s - 135.09s | Firstly, we will introduce the VMware visualization architecture to you. 135.09s - 141.77s | Most people hunting bugs directly from debugging the virtual device is code, but we choose 141.77s - 143.89s | to take a bigger view. 143.89s - 149.41s | We studied it from reverse engineering the whole VMware visualization architecture. 149.41s - 154.29s | And this helped us to figure out which code and how they can be influenced by the guest 154.29s - 155.69s | OS. 155.69s - 161.05s | And hopefully, it will bring some new idea to you. 161.05s - 167.33s | And later, we will use the bugs that we found in USB visualization and SCSI visualization 167.33s - 172.41s | to explain the possible source of 3D in virtual device. 172.41s - 179.01s | And anyway, a virtual device is still the most cost-effective choice in visualization 179.01s - 180.01s | bug hunting. 180.01s - 190.08s | Okay, let's start the first part, VMware Hypervisor Reverse Engineering. 190.08s - 195.40s | If you are new to VMware visualization, I do have some tips for you. 195.40s - 202.12s | The most important binary on VMware workstation or EXXI is VMX. 202.12s - 208.44s | It is


chunk_id: 188_chunk_3
chunk_text:
the VMware visualization architecture to you. 135.09s - 141.77s | Most people hunting bugs directly from debugging the virtual device is code, but we choose 141.77s - 143.89s | to take a bigger view. 143.89s - 149.41s | We studied it from reverse engineering the whole VMware visualization architecture. 149.41s - 154.29s | And this helped us to figure out which code and how they can be influenced by the guest 154.29s - 155.69s | OS. 155.69s - 161.05s | And hopefully, it will bring some new idea to you. 161.05s - 167.33s | And later, we will use the bugs that we found in USB visualization and SCSI visualization 167.33s - 172.41s | to explain the possible source of 3D in virtual device. 172.41s - 179.01s | And anyway, a virtual device is still the most cost-effective choice in visualization 179.01s - 180.01s | bug hunting. 180.01s - 190.08s | Okay, let's start the first part, VMware Hypervisor Reverse Engineering. 190.08s - 195.40s | If you are new to VMware visualization, I do have some tips for you. 195.40s - 202.12s | The most important binary on VMware workstation or EXXI is VMX. 202.12s - 208.44s | It is responsible for starting the virtual machine and contains most of virtual device 208.44s - 209.44s | code. 209.44s - 215.96s | And no matter it is EXXI or workstation, their VMX is identical. 215.96s - 219.68s | And basically, just use different system API. 219.68s - 224.60s | And in this part, we will use workstation for example. 224.60s - 231.20s | And also, debugging VMware workstation on the Windows can be much easier. 231.20s - 239.60s | OpenVM tools shares a lot of code with VMX, like IO function, event loop, and this can 239.60s - 243.80s | really speed up your reverse engineering procedure. 243.92s - 252.48s | And also, as a beginner, you may need to collect CVs, papers, device documents, and even check 252.48s - 254.60s | the QEMU code. 254.60s - 261.00s | Just utilize every information you can find to reverse engineering. 261.00s - 265.80s | So first question, where should we start? 265.80s - 271.40s | If you already learned something about Hypervisor, there's always a loop that handles switching 271.40s - 273.92s | or switch out of virtual machine. 273.92s - 281.92s | So we will locate the loop code and start


chunk_id: 188_chunk_4
chunk_text:
responsible for starting the virtual machine and contains most of virtual device 208.44s - 209.44s | code. 209.44s - 215.96s | And no matter it is EXXI or workstation, their VMX is identical. 215.96s - 219.68s | And basically, just use different system API. 219.68s - 224.60s | And in this part, we will use workstation for example. 224.60s - 231.20s | And also, debugging VMware workstation on the Windows can be much easier. 231.20s - 239.60s | OpenVM tools shares a lot of code with VMX, like IO function, event loop, and this can 239.60s - 243.80s | really speed up your reverse engineering procedure. 243.92s - 252.48s | And also, as a beginner, you may need to collect CVs, papers, device documents, and even check 252.48s - 254.60s | the QEMU code. 254.60s - 261.00s | Just utilize every information you can find to reverse engineering. 261.00s - 265.80s | So first question, where should we start? 265.80s - 271.40s | If you already learned something about Hypervisor, there's always a loop that handles switching 271.40s - 273.92s | or switch out of virtual machine. 273.92s - 281.92s | So we will locate the loop code and start reverse engineering the Hypervisor from there. 281.92s - 288.24s | Also, we know that VMX is a user mode process. 288.24s - 291.64s | So it should access the kernel for switching. 291.64s - 294.36s | So they should have a kernel module. 294.36s - 298.56s | And on Windows, it's VMX86. 298.56s - 307.64s | And if we are talking about the EXXI, it just directly communicates with the VM kernel. 307.64s - 313.64s | And tools such as API monitor can help us analyze the communication process between 313.64s - 320.69s | the VMX and the host OS kernel. 320.69s - 328.25s | So of course, the OS lock screen can help us to figure out the meaning of the device 328.25s - 331.86s | IO control. 331.86s - 336.46s | So it won't be hard to locate the main loop code. 336.46s - 342.98s | You can see that VMX uses the IO control ROM VM switch into the virtual machine. 342.98s - 348.58s | And it's blocked until the virtual machine needs to force you to help. 348.58s - 354.18s | The VMX will get the return code of the IO control ROM VM and call


chunk_id: 188_chunk_5
chunk_text:
reverse engineering the Hypervisor from there. 281.92s - 288.24s | Also, we know that VMX is a user mode process. 288.24s - 291.64s | So it should access the kernel for switching. 291.64s - 294.36s | So they should have a kernel module. 294.36s - 298.56s | And on Windows, it's VMX86. 298.56s - 307.64s | And if we are talking about the EXXI, it just directly communicates with the VM kernel. 307.64s - 313.64s | And tools such as API monitor can help us analyze the communication process between 313.64s - 320.69s | the VMX and the host OS kernel. 320.69s - 328.25s | So of course, the OS lock screen can help us to figure out the meaning of the device 328.25s - 331.86s | IO control. 331.86s - 336.46s | So it won't be hard to locate the main loop code. 336.46s - 342.98s | You can see that VMX uses the IO control ROM VM switch into the virtual machine. 342.98s - 348.58s | And it's blocked until the virtual machine needs to force you to help. 348.58s - 354.18s | The VMX will get the return code of the IO control ROM VM and call the corresponding 354.18s - 360.86s | user RPC handler to handle the virtual machine request. 360.86s - 364.22s | So what is the user RPC? 364.22s - 372.02s | And it's a mechanism that VMware designed for VMM to interact with VMX on host. 372.02s - 379.38s | And very similar to Hypercall, but on user space process VMX. 379.38s - 383.66s | User RPC contains lots of code related to device emulation. 383.66s - 389.50s | And basically, it is the start of device emulation. 389.50s - 395.78s | And it will only take one argument, which is user RPC block pointer. 395.78s - 399.18s | And it's a shared area memory region. 399.18s - 405.06s | Shared area is another mechanism for shared data with VMX and VMM. 405.06s - 412.58s | You may not be able to see some data be changed in VMX because they may be modified in VMM. 412.58s - 418.42s | So if we want to know what is passed in user RPC block, we should figure out how the shared 418.42s - 421.69s | area works. 421.69s - 429.05s | The implementation of shared area is related to creation and loading of


chunk_id: 188_chunk_6
chunk_text:
the corresponding 354.18s - 360.86s | user RPC handler to handle the virtual machine request. 360.86s - 364.22s | So what is the user RPC? 364.22s - 372.02s | And it's a mechanism that VMware designed for VMM to interact with VMX on host. 372.02s - 379.38s | And very similar to Hypercall, but on user space process VMX. 379.38s - 383.66s | User RPC contains lots of code related to device emulation. 383.66s - 389.50s | And basically, it is the start of device emulation. 389.50s - 395.78s | And it will only take one argument, which is user RPC block pointer. 395.78s - 399.18s | And it's a shared area memory region. 399.18s - 405.06s | Shared area is another mechanism for shared data with VMX and VMM. 405.06s - 412.58s | You may not be able to see some data be changed in VMX because they may be modified in VMM. 412.58s - 418.42s | So if we want to know what is passed in user RPC block, we should figure out how the shared 418.42s - 421.69s | area works. 421.69s - 429.05s | The implementation of shared area is related to creation and loading of VMM. 429.05s - 436.69s | So we need to study it from the initialization process and pay attention to every memory 436.69s - 438.49s | location cost. 438.49s - 446.94s | And also remember to check the interaction between VMware VMX and VMX86. 446.94s - 455.10s | We will notice that there is a EOF object called VMM block embedded into VMX binary. 455.10s - 460.74s | Also there are lots of VMM extensions stored in VMM block section. 460.74s - 463.54s | And these are also EOF object. 463.54s - 472.18s | VMX will link them with VMM block in memory to construct the actual VMM binary according 472.18s - 476.77s | to the user's configuration. 476.77s - 481.41s | Okay, let's take a look at the VMM block. 481.41s - 490.09s | We can see there are predefined export symbols such as user RPC block and their corresponding 490.09s - 494.97s | mapping address in the shared per-VCPU VMX section. 494.97s - 499.01s | And some virtual devices require the shared memory too. 499.01s - 504.13s | So VMX will define this export symbol in it too. 504.17s - 510.05s | After these symbols have been defined, VMX


chunk_id: 188_chunk_7
chunk_text:
VMM. 429.05s - 436.69s | So we need to study it from the initialization process and pay attention to every memory 436.69s - 438.49s | location cost. 438.49s - 446.94s | And also remember to check the interaction between VMware VMX and VMX86. 446.94s - 455.10s | We will notice that there is a EOF object called VMM block embedded into VMX binary. 455.10s - 460.74s | Also there are lots of VMM extensions stored in VMM block section. 460.74s - 463.54s | And these are also EOF object. 463.54s - 472.18s | VMX will link them with VMM block in memory to construct the actual VMM binary according 472.18s - 476.77s | to the user's configuration. 476.77s - 481.41s | Okay, let's take a look at the VMM block. 481.41s - 490.09s | We can see there are predefined export symbols such as user RPC block and their corresponding 490.09s - 494.97s | mapping address in the shared per-VCPU VMX section. 494.97s - 499.01s | And some virtual devices require the shared memory too. 499.01s - 504.13s | So VMX will define this export symbol in it too. 504.17s - 510.05s | After these symbols have been defined, VMX will calculate the total size of shared area 510.05s - 515.17s | memories and allocate the corresponding memory space. 515.17s - 523.25s | Now we have seen how shared memory were allocated, but how do VMM access them? 523.25s - 527.61s | You will notice that VMM block has two sections. 527.61s - 534.37s | One of them contains VMM's GDT information and the other contains the VMM's virtual address 534.37s - 538.52s | mapping information. 538.52s - 546.08s | And combined with this information, we will see VMX is responsible for allocating memory 546.08s - 551.40s | and building the page table structures based on VMM block's information. 551.40s - 559.52s | And VMX86 will further populate the page table information and allow the VMM EOF file, which 559.52s - 562.68s | is constructed by VMX. 562.68s - 570.84s | And VMX, VMM block, VMX86 work together to build the VMM's environment and mapping the 570.84s - 574.76s | host allocated address to VMM's virtual address. 574.76s - 580.72s | So if you need to know how to manipulate data in shared area region, you will need to check 580.72s - 584.48s | the VMM's code. 584.48s - 590.24s


chunk_id: 188_chunk_8
chunk_text:
will calculate the total size of shared area 510.05s - 515.17s | memories and allocate the corresponding memory space. 515.17s - 523.25s | Now we have seen how shared memory were allocated, but how do VMM access them? 523.25s - 527.61s | You will notice that VMM block has two sections. 527.61s - 534.37s | One of them contains VMM's GDT information and the other contains the VMM's virtual address 534.37s - 538.52s | mapping information. 538.52s - 546.08s | And combined with this information, we will see VMX is responsible for allocating memory 546.08s - 551.40s | and building the page table structures based on VMM block's information. 551.40s - 559.52s | And VMX86 will further populate the page table information and allow the VMM EOF file, which 559.52s - 562.68s | is constructed by VMX. 562.68s - 570.84s | And VMX, VMM block, VMX86 work together to build the VMM's environment and mapping the 570.84s - 574.76s | host allocated address to VMM's virtual address. 574.76s - 580.72s | So if you need to know how to manipulate data in shared area region, you will need to check 580.72s - 584.48s | the VMM's code. 584.48s - 590.24s | And VMX choose to run which user RPC code handler is depending on the return code of 590.24s - 593.26s | the IO control VM run. 593.26s - 598.86s | So it's time for us to check how VMWare's VMM switch works. 598.86s - 603.94s | And the most important structure is cross page. 603.94s - 612.34s | It's a one page size memory region allocated for each vCPU by VMX86. 612.34s - 619.10s | And it's responsible for storing the context between VMM and the host. 619.10s - 625.02s | Just like the VM says, VMCS in Intel VT. 625.02s - 633.78s | We can check the monitor loader section to see its virtual address on the VMM's environment. 633.78s - 643.98s | When VMX code IO control run VM, it will cause the VMX86 cause the host switch to VMM code 644.30s - 652.34s | and saving the crew and CPU state to cross page and restore the VMM's CPU state. 652.34s - 659.08s | And the operation to switch out is the opposite of this process. 659.08s - 666.12s | Now we can check the VMM's code to see user RPC is implemented through the platform


chunk_id: 188_chunk_9
chunk_text:
| And VMX choose to run which user RPC code handler is depending on the return code of 590.24s - 593.26s | the IO control VM run. 593.26s - 598.86s | So it's time for us to check how VMWare's VMM switch works. 598.86s - 603.94s | And the most important structure is cross page. 603.94s - 612.34s | It's a one page size memory region allocated for each vCPU by VMX86. 612.34s - 619.10s | And it's responsible for storing the context between VMM and the host. 619.10s - 625.02s | Just like the VM says, VMCS in Intel VT. 625.02s - 633.78s | We can check the monitor loader section to see its virtual address on the VMM's environment. 633.78s - 643.98s | When VMX code IO control run VM, it will cause the VMX86 cause the host switch to VMM code 644.30s - 652.34s | and saving the crew and CPU state to cross page and restore the VMM's CPU state. 652.34s - 659.08s | And the operation to switch out is the opposite of this process. 659.08s - 666.12s | Now we can check the VMM's code to see user RPC is implemented through the platform user 666.12s - 667.12s | code. 667.12s - 675.64s | It saves the user RPC opcode and the platform code invocation number 100 to the cross page. 675.64s - 685.60s | And the platform code 100 will cause the VMX86 to return the user RPC code to VMX. 685.60s - 693.68s | So when IO control run VM returned, VMX can call the corresponding user RPC code handler. 693.68s - 702.16s | Also whenever VMM prepare to call user RPC, you will see VMM modify the user RPC block 702.16s - 707.97s | to transfer data to VMX process. 707.97s - 713.69s | So now we finally understand the whole user RPC implementation. 713.69s - 722.49s | And based on this knowledge, we are able to further reverse engineering the device visualization. 722.49s - 730.81s | For port IO emulation, VMM will reserve the x86 IO instructions and may attempt to use 730.81s - 737.32s | the user RPC to call VMX to process. 737.32s - 743.40s | And not all of the port IO callback will be registered in VMX process. 743.40s - 750.02s | There are some devices implement their IO callback in VMM. 750.02s - 759.18s |


chunk_id: 188_chunk_10
chunk_text:
user 666.12s - 667.12s | code. 667.12s - 675.64s | It saves the user RPC opcode and the platform code invocation number 100 to the cross page. 675.64s - 685.60s | And the platform code 100 will cause the VMX86 to return the user RPC code to VMX. 685.60s - 693.68s | So when IO control run VM returned, VMX can call the corresponding user RPC code handler. 693.68s - 702.16s | Also whenever VMM prepare to call user RPC, you will see VMM modify the user RPC block 702.16s - 707.97s | to transfer data to VMX process. 707.97s - 713.69s | So now we finally understand the whole user RPC implementation. 713.69s - 722.49s | And based on this knowledge, we are able to further reverse engineering the device visualization. 722.49s - 730.81s | For port IO emulation, VMM will reserve the x86 IO instructions and may attempt to use 730.81s - 737.32s | the user RPC to call VMX to process. 737.32s - 743.40s | And not all of the port IO callback will be registered in VMX process. 743.40s - 750.02s | There are some devices implement their IO callback in VMM. 750.02s - 759.18s | For MMM IO, in most cases, VMX associates the memory region with an ID and implement 759.18s - 764.04s | the callback in VMM. 764.60s - 772.20s | Most MMM IO functions in VMM automatically will call user RPC to handle the device emulation. 772.20s - 777.56s | But they may access the shared area to transfer data to VMX. 777.56s - 784.16s | So you need to check the code in VMM to understand what happened when you access the MMM IO region 784.16s - 788.24s | in guest machine. 788.24s - 794.76s | Also, physical memory access is another important part we need to analyze. 794.76s - 800.52s | We will not discuss too much about the memory mapping structure, but you should know that 800.52s - 805.40s | on Windows, the main guest memory is mapped as a file. 805.40s - 811.24s | And on EXXI, it is mapped by vmkernel. 811.24s - 817.68s | When VMX gets the physical memory region object, it will first check the object's type. 817.68s - 824.75s | And in most cases, it will directly access the point field. 824.75s - 833.83s | And the last interesting thing is we also


chunk_id: 188_chunk_11
chunk_text:
For MMM IO, in most cases, VMX associates the memory region with an ID and implement 759.18s - 764.04s | the callback in VMM. 764.60s - 772.20s | Most MMM IO functions in VMM automatically will call user RPC to handle the device emulation. 772.20s - 777.56s | But they may access the shared area to transfer data to VMX. 777.56s - 784.16s | So you need to check the code in VMM to understand what happened when you access the MMM IO region 784.16s - 788.24s | in guest machine. 788.24s - 794.76s | Also, physical memory access is another important part we need to analyze. 794.76s - 800.52s | We will not discuss too much about the memory mapping structure, but you should know that 800.52s - 805.40s | on Windows, the main guest memory is mapped as a file. 805.40s - 811.24s | And on EXXI, it is mapped by vmkernel. 811.24s - 817.68s | When VMX gets the physical memory region object, it will first check the object's type. 817.68s - 824.75s | And in most cases, it will directly access the point field. 824.75s - 833.83s | And the last interesting thing is we also found that on EXXI's VMM, some virtual devices 833.83s - 837.79s | MMM IO will not always call user RPC. 837.79s - 843.35s | They will call user RPC only when hosted emulation is enabled. 843.35s - 851.87s | Instead of using user RPC to interact with VMX, they use vmk code directly call vmkernel 851.87s - 855.51s | to handle device emulation. 855.51s - 861.83s | So although VMX are identical on EXXI and Workstation, 861.83s - 869.19s | virtual device emulation code won't always be the same by default. 869.19s - 881.77s | And basically, this graph describes the result of our VMware hypervisor analysis. 881.77s - 887.53s | Anyway, it is important for you to check the VMM code when you reverse engineering the 887.53s - 889.93s | device visualization. 889.93s - 897.41s | If you are not sure where device's data comes from, you can go check the VMM's code. 897.41s - 904.97s | If you are not sure how to trigger the device's code, you can go check the VMM's code. 904.97s - 916.00s | And if you want to find some new device's code, go check the VMM's code. 916.00s - 926.97s | Okay,


chunk_id: 188_chunk_12
chunk_text:
found that on EXXI's VMM, some virtual devices 833.83s - 837.79s | MMM IO will not always call user RPC. 837.79s - 843.35s | They will call user RPC only when hosted emulation is enabled. 843.35s - 851.87s | Instead of using user RPC to interact with VMX, they use vmk code directly call vmkernel 851.87s - 855.51s | to handle device emulation. 855.51s - 861.83s | So although VMX are identical on EXXI and Workstation, 861.83s - 869.19s | virtual device emulation code won't always be the same by default. 869.19s - 881.77s | And basically, this graph describes the result of our VMware hypervisor analysis. 881.77s - 887.53s | Anyway, it is important for you to check the VMM code when you reverse engineering the 887.53s - 889.93s | device visualization. 889.93s - 897.41s | If you are not sure where device's data comes from, you can go check the VMM's code. 897.41s - 904.97s | If you are not sure how to trigger the device's code, you can go check the VMM's code. 904.97s - 916.00s | And if you want to find some new device's code, go check the VMM's code. 916.00s - 926.97s | Okay, let's enter in the second part, VMWare device visualization bug hunting. 926.97s - 929.45s | Let's start from the USB part. 929.45s - 934.73s | Basically, we can divide the USB emulation into three parts. 934.73s - 944.93s | USB host controller emulation, like EHCI, EHCI, XHCI. 944.93s - 948.77s | The second part, VUSB emulation. 948.77s - 952.93s | These are objects described in the USB specification. 952.93s - 960.85s | For example, URB object, USB pipe object, and USB port object. 960.85s - 965.73s | And the third part, VUSB backend device emulation. 965.73s - 977.33s | And these are actual USB devices, such as Bluetooth, HID, and RNG, and so on. 977.33s - 986.17s | So as you can see, when guests want to access the USB device, it will need to put data in 986.17s - 993.25s | memory and access the host controller MMIO space, which will trigger the VMM handles 993.49s - 999.49s | MMIO access, causing the corresponding user RPC co-handler in VMX. 999.49s - 1007.73s | Then it will convert the data into URB object, and eventually processed by the backend USB 1007.73s - 1008.73s | device. 1008.73s - 1015.45s | If


chunk_id: 188_chunk_13
chunk_text:
let's enter in the second part, VMWare device visualization bug hunting. 926.97s - 929.45s | Let's start from the USB part. 929.45s - 934.73s | Basically, we can divide the USB emulation into three parts. 934.73s - 944.93s | USB host controller emulation, like EHCI, EHCI, XHCI. 944.93s - 948.77s | The second part, VUSB emulation. 948.77s - 952.93s | These are objects described in the USB specification. 952.93s - 960.85s | For example, URB object, USB pipe object, and USB port object. 960.85s - 965.73s | And the third part, VUSB backend device emulation. 965.73s - 977.33s | And these are actual USB devices, such as Bluetooth, HID, and RNG, and so on. 977.33s - 986.17s | So as you can see, when guests want to access the USB device, it will need to put data in 986.17s - 993.25s | memory and access the host controller MMIO space, which will trigger the VMM handles 993.49s - 999.49s | MMIO access, causing the corresponding user RPC co-handler in VMX. 999.49s - 1007.73s | Then it will convert the data into URB object, and eventually processed by the backend USB 1007.73s - 1008.73s | device. 1008.73s - 1015.45s | If it tries to access a USB device plugged in the host machine, it will also need another 1015.45s - 1018.01s | service to help. 1018.01s - 1025.08s | And we actually find bugs in all these three parts. 1025.08s - 1034.00s | The first bug is in the host controller part, and it's an uninitialized memory. 1034.00s - 1038.52s | Before we start it, let me just explain some concepts. 1038.52s - 1045.36s | In control transfer, a USB device accepts a type of request called a standard device 1045.36s - 1051.36s | request, which begins in the format offset setup packet. 1051.36s - 1062.52s | So it will be 8 bytes at least, and it has a WLAN field, in the case of subsequent data. 1062.52s - 1067.64s | The USB device may use this type of data, but the host controller does not transfer 1067.64s - 1070.36s | data based on this unit. 1070.36s - 1079.20s | For example, in UHCI, data is transferred in units of transfer descriptors. 1079.20s - 1088.16s | So when VMX handles the UHCI emulation, it retrieves the first TD on Quickhead, and extracts 1088.16s - 1094.40s | the WLAN field from the


chunk_id: 188_chunk_14
chunk_text:
it tries to access a USB device plugged in the host machine, it will also need another 1015.45s - 1018.01s | service to help. 1018.01s - 1025.08s | And we actually find bugs in all these three parts. 1025.08s - 1034.00s | The first bug is in the host controller part, and it's an uninitialized memory. 1034.00s - 1038.52s | Before we start it, let me just explain some concepts. 1038.52s - 1045.36s | In control transfer, a USB device accepts a type of request called a standard device 1045.36s - 1051.36s | request, which begins in the format offset setup packet. 1051.36s - 1062.52s | So it will be 8 bytes at least, and it has a WLAN field, in the case of subsequent data. 1062.52s - 1067.64s | The USB device may use this type of data, but the host controller does not transfer 1067.64s - 1070.36s | data based on this unit. 1070.36s - 1079.20s | For example, in UHCI, data is transferred in units of transfer descriptors. 1079.20s - 1088.16s | So when VMX handles the UHCI emulation, it retrieves the first TD on Quickhead, and extracts 1088.16s - 1094.40s | the WLAN field from the setup packet, and uses this size to determine the size of data 1094.40s - 1097.72s | buffer for URB object. 1097.72s - 1104.52s | After allocation is finished, it will copy the data into URB object, and they do lots 1104.52s - 1108.96s | of checks to prevent buffer overflow. 1109.00s - 1111.88s | Let's back to the allocation process. 1111.88s - 1119.88s | It's actually when we're depending on the target USB device you are transferring to. 1119.88s - 1127.60s | A different type of backend USB device will result in URB object with different fields. 1127.60s - 1133.72s | For example, HID device will allocate URB object with all the additional fields besides 1133.72s - 1136.52s | the data buffer of the URB. 1136.68s - 1145.67s | Also, HID device will use Matlock for data allocation. 1145.67s - 1148.59s | So there are some problems here. 1148.59s - 1155.31s | Allocating WLAN-sized URB doesn't mean you will get WLAN-sized data from guest sub-ITDs. 1155.31s - 1159.31s | And Matlock allocation lets the memory un-initialized. 1159.31s - 1165.19s | Also backend USB device will return data through the same URB buffer, so it will eventually 1165.19s - 1171.16s |


chunk_id: 188_chunk_15
chunk_text:
setup packet, and uses this size to determine the size of data 1094.40s - 1097.72s | buffer for URB object. 1097.72s - 1104.52s | After allocation is finished, it will copy the data into URB object, and they do lots 1104.52s - 1108.96s | of checks to prevent buffer overflow. 1109.00s - 1111.88s | Let's back to the allocation process. 1111.88s - 1119.88s | It's actually when we're depending on the target USB device you are transferring to. 1119.88s - 1127.60s | A different type of backend USB device will result in URB object with different fields. 1127.60s - 1133.72s | For example, HID device will allocate URB object with all the additional fields besides 1133.72s - 1136.52s | the data buffer of the URB. 1136.68s - 1145.67s | Also, HID device will use Matlock for data allocation. 1145.67s - 1148.59s | So there are some problems here. 1148.59s - 1155.31s | Allocating WLAN-sized URB doesn't mean you will get WLAN-sized data from guest sub-ITDs. 1155.31s - 1159.31s | And Matlock allocation lets the memory un-initialized. 1159.31s - 1165.19s | Also backend USB device will return data through the same URB buffer, so it will eventually 1165.19s - 1171.16s | let the HIP data leak to the guest OS. 1171.16s - 1177.52s | And the second bug is user-after-free appeared in BUSB emulation code. 1177.52s - 1183.04s | Again, let's first explain some concepts. 1183.04s - 1191.72s | In XHCI, there is a structure called device context which stores the USB device status. 1191.72s - 1197.48s | It is constructed by device load context and end-point context. 1197.48s - 1202.20s | Device load context holds the USB device information. 1202.20s - 1205.44s | End-point context holds the information for a single end-point. 1205.44s - 1210.04s | Also, each end-point has one or more transfer rings. 1210.04s - 1215.32s | They are transfer request blocks on the transfer rings. 1215.32s - 1220.28s | And XHCI transfer data are based on this unit. 1220.28s - 1225.20s | In order to explain this bug, we need to look back at an older bug. 1225.20s - 1228.40s | And the old bug's part is very interesting. 1228.40s - 1233.84s | It only alters the sequence between the calls to release transfer ring and the code that 1233.84s - 1238.32s | assign values to end-point context. 1238.32s - 1244.34s | Let's first figure out how


chunk_id: 188_chunk_16
chunk_text:
let the HIP data leak to the guest OS. 1171.16s - 1177.52s | And the second bug is user-after-free appeared in BUSB emulation code. 1177.52s - 1183.04s | Again, let's first explain some concepts. 1183.04s - 1191.72s | In XHCI, there is a structure called device context which stores the USB device status. 1191.72s - 1197.48s | It is constructed by device load context and end-point context. 1197.48s - 1202.20s | Device load context holds the USB device information. 1202.20s - 1205.44s | End-point context holds the information for a single end-point. 1205.44s - 1210.04s | Also, each end-point has one or more transfer rings. 1210.04s - 1215.32s | They are transfer request blocks on the transfer rings. 1215.32s - 1220.28s | And XHCI transfer data are based on this unit. 1220.28s - 1225.20s | In order to explain this bug, we need to look back at an older bug. 1225.20s - 1228.40s | And the old bug's part is very interesting. 1228.40s - 1233.84s | It only alters the sequence between the calls to release transfer ring and the code that 1233.84s - 1238.32s | assign values to end-point context. 1238.32s - 1244.34s | Let's first figure out how transfer ring release works. 1244.34s - 1251.66s | Firstly, it will get transfer ring object from the end-point context. 1251.66s - 1258.02s | Second, it will retrieve the VUSB device object based on the USB port number saved 1258.02s - 1261.90s | in the device load context. 1261.90s - 1269.34s | Then it will obtain the VUSB pipe object from the VUSB device object based on the end-point 1269.34s - 1270.86s | ID. 1270.86s - 1277.66s | And after that, it will release all the URB object on that VUSB pipe object. 1277.66s - 1283.53s | And finally, it will release the transfer ring object. 1283.53s - 1292.05s | Also, it will release the possible URB object on back-end USB device in case there may be 1292.05s - 1296.79s | dangling pointer on back-end USB device. 1296.79s - 1299.71s | So it seems no problems here. 1299.71s - 1307.51s | However, it's actually not the URB object could become the dangling pointer. 1307.51s - 1313.15s | It is because that the transfer ring object pointer is not only hold by the end-point 1313.15s - 1314.15s | context. 1314.15s - 1320.95s | A URB object also holds a point that point


chunk_id: 188_chunk_17
chunk_text:
transfer ring release works. 1244.34s - 1251.66s | Firstly, it will get transfer ring object from the end-point context. 1251.66s - 1258.02s | Second, it will retrieve the VUSB device object based on the USB port number saved 1258.02s - 1261.90s | in the device load context. 1261.90s - 1269.34s | Then it will obtain the VUSB pipe object from the VUSB device object based on the end-point 1269.34s - 1270.86s | ID. 1270.86s - 1277.66s | And after that, it will release all the URB object on that VUSB pipe object. 1277.66s - 1283.53s | And finally, it will release the transfer ring object. 1283.53s - 1292.05s | Also, it will release the possible URB object on back-end USB device in case there may be 1292.05s - 1296.79s | dangling pointer on back-end USB device. 1296.79s - 1299.71s | So it seems no problems here. 1299.71s - 1307.51s | However, it's actually not the URB object could become the dangling pointer. 1307.51s - 1313.15s | It is because that the transfer ring object pointer is not only hold by the end-point 1313.15s - 1314.15s | context. 1314.15s - 1320.95s | A URB object also holds a point that point to a field of transfer ring object. 1320.95s - 1327.79s | And this field is responsible for tracking the corresponding TRP when XHCI return the 1327.79s - 1332.80s | USB device response to the guest. 1332.80s - 1339.52s | And before the patch, XHCI command-like configure end-point could modify the end-point context 1339.52s - 1344.40s | contents before releasing the transfer ring. 1344.40s - 1351.00s | So it may lead the type stored in end-point context mismatch with the VUSB pipe object 1351.00s - 1354.20s | type. 1354.20s - 1361.56s | And this will cause the function return without a VUSB pipe object and left the URB object 1361.56s - 1365.92s | on that VUSB pipe object not be freed. 1365.92s - 1373.56s | And the previous pointer now becomes the dangling pointer and causing user after free. 1373.56s - 1382.32s | So now our question is, after this patch, is it possible to make the VUSB pipe object 1382.32s - 1385.36s | mismatch again? 1385.36s - 1392.12s | We know VMX will need to check the port number stored in slot context to find the VUSB device 1392.12s - 1393.68s | object. 1393.68s - 1400.84s | So if we


chunk_id: 188_chunk_18
chunk_text:
to a field of transfer ring object. 1320.95s - 1327.79s | And this field is responsible for tracking the corresponding TRP when XHCI return the 1327.79s - 1332.80s | USB device response to the guest. 1332.80s - 1339.52s | And before the patch, XHCI command-like configure end-point could modify the end-point context 1339.52s - 1344.40s | contents before releasing the transfer ring. 1344.40s - 1351.00s | So it may lead the type stored in end-point context mismatch with the VUSB pipe object 1351.00s - 1354.20s | type. 1354.20s - 1361.56s | And this will cause the function return without a VUSB pipe object and left the URB object 1361.56s - 1365.92s | on that VUSB pipe object not be freed. 1365.92s - 1373.56s | And the previous pointer now becomes the dangling pointer and causing user after free. 1373.56s - 1382.32s | So now our question is, after this patch, is it possible to make the VUSB pipe object 1382.32s - 1385.36s | mismatch again? 1385.36s - 1392.12s | We know VMX will need to check the port number stored in slot context to find the VUSB device 1392.12s - 1393.68s | object. 1393.68s - 1400.84s | So if we can modify the port number, it may lead VMX find a wrong VUSB device object. 1400.84s - 1407.86s | So in that case, it will also find a wrong VUSB pipe object. 1407.86s - 1412.16s | We do have address device command can make this possible. 1412.16s - 1417.36s | You can see the address device command only modifies the slot context and the control 1417.36s - 1420.60s | end-point context. 1420.60s - 1425.32s | So firstly, we finish the device configuration process. 1425.32s - 1430.12s | And we create the transfer ring on non-control end-point. 1430.12s - 1434.64s | And then we transfer URB data on these transfer rings. 1434.64s - 1441.20s | In the end, we use the address device command on that device to modify the device port number. 1441.24s - 1446.40s | Now, if we try to release the transfer ring on that end-point, it will fail to find the 1446.40s - 1451.24s | right VUSB pipe object and causing UAF again. 1451.24s - 1457.00s | So this is a bug that happens between host controller and the VUSB emulation. 1457.00s - 1465.44s | And the cause is it fails to manage the object lifetime in


chunk_id: 188_chunk_19
chunk_text:
can modify the port number, it may lead VMX find a wrong VUSB device object. 1400.84s - 1407.86s | So in that case, it will also find a wrong VUSB pipe object. 1407.86s - 1412.16s | We do have address device command can make this possible. 1412.16s - 1417.36s | You can see the address device command only modifies the slot context and the control 1417.36s - 1420.60s | end-point context. 1420.60s - 1425.32s | So firstly, we finish the device configuration process. 1425.32s - 1430.12s | And we create the transfer ring on non-control end-point. 1430.12s - 1434.64s | And then we transfer URB data on these transfer rings. 1434.64s - 1441.20s | In the end, we use the address device command on that device to modify the device port number. 1441.24s - 1446.40s | Now, if we try to release the transfer ring on that end-point, it will fail to find the 1446.40s - 1451.24s | right VUSB pipe object and causing UAF again. 1451.24s - 1457.00s | So this is a bug that happens between host controller and the VUSB emulation. 1457.00s - 1465.44s | And the cause is it fails to manage the object lifetime in VUSB emulation. 1465.44s - 1470.60s | And the third bug is in the USB backend device emulation. 1470.60s - 1479.38s | And it is out-of-boundary will be triggered within the system API. 1479.38s - 1481.98s | Let's start with some concepts. 1481.98s - 1489.22s | The guest OS communicates with the smart card through the virtual smart card reader. 1489.22s - 1496.94s | And the guest OS uses CCID protocol to interact with the virtual smart card reader. 1496.94s - 1503.66s | The application data units, APD, serve as the payload for interaction between the smart 1503.66s - 1507.02s | card reader and the smart card. 1507.02s - 1513.38s | And you can see their relationship are very like the host controller and the USB device. 1513.38s - 1522.10s | And you may already seen that both of these data structure has the length field. 1522.10s - 1528.70s | And it is always need to be careful handling this length field. 1528.70s - 1534.82s | VMware do checks whether the message length field of CCID protocol match the length field 1534.82s - 1535.82s | of command APD. 1535.82s - 1543.86s | But it fails to verify whether these two fields


chunk_id: 188_chunk_20
chunk_text:
VUSB emulation. 1465.44s - 1470.60s | And the third bug is in the USB backend device emulation. 1470.60s - 1479.38s | And it is out-of-boundary will be triggered within the system API. 1479.38s - 1481.98s | Let's start with some concepts. 1481.98s - 1489.22s | The guest OS communicates with the smart card through the virtual smart card reader. 1489.22s - 1496.94s | And the guest OS uses CCID protocol to interact with the virtual smart card reader. 1496.94s - 1503.66s | The application data units, APD, serve as the payload for interaction between the smart 1503.66s - 1507.02s | card reader and the smart card. 1507.02s - 1513.38s | And you can see their relationship are very like the host controller and the USB device. 1513.38s - 1522.10s | And you may already seen that both of these data structure has the length field. 1522.10s - 1528.70s | And it is always need to be careful handling this length field. 1528.70s - 1534.82s | VMware do checks whether the message length field of CCID protocol match the length field 1534.82s - 1535.82s | of command APD. 1535.82s - 1543.86s | But it fails to verify whether these two fields conform to the size of URP buffer. 1543.86s - 1550.62s | It directly uses this field as arguments to call the Windows S card transmit API. 1550.62s - 1556.74s | Clearly, S card transmits cannot check whether the length match the data buffer. 1556.74s - 1562.34s | So it will out-of-bound access to the heap data and write it to the smart card on your 1562.34s - 1563.34s | host. 1563.34s - 1566.94s | Also, you may be able to read it back. 1566.94s - 1572.34s | So it's kind of interesting. 1572.34s - 1579.10s | Okay, in conclusion, it's very challenging to defend such complex system. 1579.18s - 1587.22s | VUSB emulation can be attacked, USB device emulation can be attacked, and host controller 1587.22s - 1589.86s | emulation can be attacked too. 1589.86s - 1600.62s | Also, we still have cases cannot present, but you can defer the binary to found. 1600.62s - 1605.14s | And maybe more attack scenarios in the future. 1605.14s - 1615.14s | We will be plugging EVO USB device and leverage the VMX to execute the code, or leverage local 1615.14s - 1621.02s | USB service to privilege the escalation. 1621.02s - 1625.06s


chunk_id: 188_chunk_21
chunk_text:
conform to the size of URP buffer. 1543.86s - 1550.62s | It directly uses this field as arguments to call the Windows S card transmit API. 1550.62s - 1556.74s | Clearly, S card transmits cannot check whether the length match the data buffer. 1556.74s - 1562.34s | So it will out-of-bound access to the heap data and write it to the smart card on your 1562.34s - 1563.34s | host. 1563.34s - 1566.94s | Also, you may be able to read it back. 1566.94s - 1572.34s | So it's kind of interesting. 1572.34s - 1579.10s | Okay, in conclusion, it's very challenging to defend such complex system. 1579.18s - 1587.22s | VUSB emulation can be attacked, USB device emulation can be attacked, and host controller 1587.22s - 1589.86s | emulation can be attacked too. 1589.86s - 1600.62s | Also, we still have cases cannot present, but you can defer the binary to found. 1600.62s - 1605.14s | And maybe more attack scenarios in the future. 1605.14s - 1615.14s | We will be plugging EVO USB device and leverage the VMX to execute the code, or leverage local 1615.14s - 1621.02s | USB service to privilege the escalation. 1621.02s - 1625.06s | And anyway, that's the USB part. 1625.06s - 1631.46s | And next part will be presented by my colleague. 1631.46s - 1637.98s | And we will show you that how SCSI works different on ESXi and Workstation by default. 1637.98s - 1644.96s | Hello, everyone. 1644.96s - 1645.96s | I'm Zhenghao. 1645.96s - 1649.72s | I'm the speaker on this topic. 1649.72s - 1655.76s | Now it's my turn to expose VMkernel, a whole new attack surface. 1655.76s - 1663.04s | But I will first talk about some differences between ESXi and Workstation. 1663.04s - 1668.48s | Because our new attack surface is hidden in these small differences. 1668.48s - 1679.24s | ESXi is a Type-1 hypervisor that runs directly on the host's physical hardware, while Workstation 1679.24s - 1689.20s | is a Type-2 hypervisor that is installed on top of an existing host operating system. 1689.20s - 1695.96s | Workstation supports more configurations and devices than ESXi, which means that in 1695.96s - 1704.16s | certain situations, Workstation can be audited at more points than ESXi. 1704.16s - 1713.36s | In some specific devices, the data flow direction of ESXi and Workstation is different. 1713.52s - 1723.56s |


chunk_id: 188_chunk_22
chunk_text:
| And anyway, that's the USB part. 1625.06s - 1631.46s | And next part will be presented by my colleague. 1631.46s - 1637.98s | And we will show you that how SCSI works different on ESXi and Workstation by default. 1637.98s - 1644.96s | Hello, everyone. 1644.96s - 1645.96s | I'm Zhenghao. 1645.96s - 1649.72s | I'm the speaker on this topic. 1649.72s - 1655.76s | Now it's my turn to expose VMkernel, a whole new attack surface. 1655.76s - 1663.04s | But I will first talk about some differences between ESXi and Workstation. 1663.04s - 1668.48s | Because our new attack surface is hidden in these small differences. 1668.48s - 1679.24s | ESXi is a Type-1 hypervisor that runs directly on the host's physical hardware, while Workstation 1679.24s - 1689.20s | is a Type-2 hypervisor that is installed on top of an existing host operating system. 1689.20s - 1695.96s | Workstation supports more configurations and devices than ESXi, which means that in 1695.96s - 1704.16s | certain situations, Workstation can be audited at more points than ESXi. 1704.16s - 1713.36s | In some specific devices, the data flow direction of ESXi and Workstation is different. 1713.52s - 1723.56s | Next, I will take SCSI device emulation as an example to demonstrate the vulnerabilities 1723.56s - 1731.72s | on different attack surfaces caused by different data flow orientations. 1731.72s - 1736.48s | This is an overview of the SCSI data flow. 1736.48s - 1742.36s | You can see that there are two paths for writing data to the disk. 1742.36s - 1747.04s | One through VMkernel and one through VMX. 1747.04s - 1757.80s | These are two completely different code paths, belonging to ESXi and Workstation, respectively. 1757.80s - 1765.36s | The specific code path of SCSI in Workstation is shown in the figure. 1765.36s - 1777.28s | If the user calls the MPI function SCSIORequest command, it will enter the LSILogic MPO process 1777.28s - 1787.84s | SCSIOMessage function, where it will confirm whether the environment is the hosted emulation. 1788.00s - 1799.76s | Finally, the LSILogic hosted process SCSIOMessage function calls the relevant handler in VMX 1799.76s - 1803.32s | through user RPC. 1803.32s - 1811.40s | The specific code path of SCSI in ESXi is shown in the figure. 1811.40s - 1821.92s | ESXi divides the situation into whether the environment itself is in hosted emulation. 1821.92s


chunk_id: 188_chunk_23
chunk_text:
Next, I will take SCSI device emulation as an example to demonstrate the vulnerabilities 1723.56s - 1731.72s | on different attack surfaces caused by different data flow orientations. 1731.72s - 1736.48s | This is an overview of the SCSI data flow. 1736.48s - 1742.36s | You can see that there are two paths for writing data to the disk. 1742.36s - 1747.04s | One through VMkernel and one through VMX. 1747.04s - 1757.80s | These are two completely different code paths, belonging to ESXi and Workstation, respectively. 1757.80s - 1765.36s | The specific code path of SCSI in Workstation is shown in the figure. 1765.36s - 1777.28s | If the user calls the MPI function SCSIORequest command, it will enter the LSILogic MPO process 1777.28s - 1787.84s | SCSIOMessage function, where it will confirm whether the environment is the hosted emulation. 1788.00s - 1799.76s | Finally, the LSILogic hosted process SCSIOMessage function calls the relevant handler in VMX 1799.76s - 1803.32s | through user RPC. 1803.32s - 1811.40s | The specific code path of SCSI in ESXi is shown in the figure. 1811.40s - 1821.92s | ESXi divides the situation into whether the environment itself is in hosted emulation. 1821.92s - 1828.76s | If it's in hosted emulation, it's the same as the Workstation path. 1828.76s - 1838.32s | Otherwise, it goes to LSILogic VMk process SCSIOMessage. 1838.32s - 1846.16s | Go to VMkernel through VMk core arguments. 1846.16s - 1856.20s | Because of this small code gap, ESXi has a new attack surface that Workstation does not have. 1856.20s - 1865.20s | Next, I will introduce the vulnerabilities I found on these two different paths. 1865.20s - 1875.24s | The first vulnerability we will talk about is located in VMX, and the official description 1875.24s - 1880.84s | is out-of-bounds read-write vulnerability. 1880.84s - 1889.80s | As a tool for storing data, stability is the most critical and basic requirement for disks. 1890.20s - 1898.84s | VMware implements corresponding disk verification capabilities in device emulation. 1898.84s - 1907.60s | One of the disk verification capabilities is to detect data corruption through checksum. 1907.60s - 1912.96s | This is where the vulnerability occurs. 1912.96s - 1919.08s | Before we start, let's first introduce a SCSI command. 1919.08s - 1930.28s | In the SCSI command reference menu, there is a command called write16 that allows the 1930.28s - 1938.32s | operation


chunk_id: 188_chunk_24
chunk_text:
- 1828.76s | If it's in hosted emulation, it's the same as the Workstation path. 1828.76s - 1838.32s | Otherwise, it goes to LSILogic VMk process SCSIOMessage. 1838.32s - 1846.16s | Go to VMkernel through VMk core arguments. 1846.16s - 1856.20s | Because of this small code gap, ESXi has a new attack surface that Workstation does not have. 1856.20s - 1865.20s | Next, I will introduce the vulnerabilities I found on these two different paths. 1865.20s - 1875.24s | The first vulnerability we will talk about is located in VMX, and the official description 1875.24s - 1880.84s | is out-of-bounds read-write vulnerability. 1880.84s - 1889.80s | As a tool for storing data, stability is the most critical and basic requirement for disks. 1890.20s - 1898.84s | VMware implements corresponding disk verification capabilities in device emulation. 1898.84s - 1907.60s | One of the disk verification capabilities is to detect data corruption through checksum. 1907.60s - 1912.96s | This is where the vulnerability occurs. 1912.96s - 1919.08s | Before we start, let's first introduce a SCSI command. 1919.08s - 1930.28s | In the SCSI command reference menu, there is a command called write16 that allows the 1930.28s - 1938.32s | operation of 8-byte logical block address and 4-byte transfer length. 1938.32s - 1948.52s | This shows that we can use this command to access any address in the 64-bit space, provided 1948.52s - 1952.92s | there is no disk capacity limit check. 1952.92s - 1962.20s | VMware did not implement the disk capacity limit check in its disk verification program 1962.20s - 1964.92s | implementation. 1964.92s - 1973.56s | As can be seen in the figure, after applying for a heap of a corresponding size according 1973.72s - 1985.40s | to the disk capacity, only the operation is checked to see if it is a read or write operation. 1985.40s - 1989.88s | Obviously, this is a heap overflow. 1989.88s - 1999.88s | The write16 and other read and write commands in the SCSI command reference menu allow us 1999.88s - 2003.72s | to access any 8-byte address. 2003.72s - 2011.97s | This allows us to easily perform arbitrary read and write operations. 2011.97s - 2020.53s | The vulnerability we will discuss next is located in VMkernel, and the official description 2020.53s - 2024.37s | is out-of-bounds read. 2024.37s - 2029.73s | Still start with the SCSI command reference menu. 2029.81s


chunk_id: 188_chunk_25
chunk_text:
of 8-byte logical block address and 4-byte transfer length. 1938.32s - 1948.52s | This shows that we can use this command to access any address in the 64-bit space, provided 1948.52s - 1952.92s | there is no disk capacity limit check. 1952.92s - 1962.20s | VMware did not implement the disk capacity limit check in its disk verification program 1962.20s - 1964.92s | implementation. 1964.92s - 1973.56s | As can be seen in the figure, after applying for a heap of a corresponding size according 1973.72s - 1985.40s | to the disk capacity, only the operation is checked to see if it is a read or write operation. 1985.40s - 1989.88s | Obviously, this is a heap overflow. 1989.88s - 1999.88s | The write16 and other read and write commands in the SCSI command reference menu allow us 1999.88s - 2003.72s | to access any 8-byte address. 2003.72s - 2011.97s | This allows us to easily perform arbitrary read and write operations. 2011.97s - 2020.53s | The vulnerability we will discuss next is located in VMkernel, and the official description 2020.53s - 2024.37s | is out-of-bounds read. 2024.37s - 2029.73s | Still start with the SCSI command reference menu. 2029.81s - 2038.69s | In the SCSI command reference menu, there is a command called unmap, which can unmap 2038.69s - 2044.53s | one or more logical basic addresses. 2044.53s - 2054.77s | The structure of unmap itself is relatively complex and is divided into three parts. 2054.77s - 2062.37s | unmap command, unmap parameter list, and unmap block descriptor. 2062.37s - 2071.57s | Let's first look at the structure definition of unmap command in the SCSI command reference 2071.57s - 2073.01s | menu. 2073.01s - 2082.05s | The focus of the figure is the parameter length, which indicates the total length of the unmapped 2082.13s - 2085.09s | parameter data. 2085.09s - 2093.73s | The unmapped parameter list is divided into two parts, unmapped parameter list header 2093.73s - 2098.05s | and unmapped block descriptor data. 2098.05s - 2106.37s | The unmapped parameter list header consists of three fields, unmapped data length, unmapped 2106.37s - 2111.49s | block descriptor data length, and reserved. 2111.49s - 2119.49s | The unmapped block descriptor consists of two fields, unmapped logical block address 2119.49s - 2123.33s | and number of logical blocks. 2123.33s - 2131.01s | These two fields indicate the starting address and


chunk_id: 188_chunk_26
chunk_text:
- 2038.69s | In the SCSI command reference menu, there is a command called unmap, which can unmap 2038.69s - 2044.53s | one or more logical basic addresses. 2044.53s - 2054.77s | The structure of unmap itself is relatively complex and is divided into three parts. 2054.77s - 2062.37s | unmap command, unmap parameter list, and unmap block descriptor. 2062.37s - 2071.57s | Let's first look at the structure definition of unmap command in the SCSI command reference 2071.57s - 2073.01s | menu. 2073.01s - 2082.05s | The focus of the figure is the parameter length, which indicates the total length of the unmapped 2082.13s - 2085.09s | parameter data. 2085.09s - 2093.73s | The unmapped parameter list is divided into two parts, unmapped parameter list header 2093.73s - 2098.05s | and unmapped block descriptor data. 2098.05s - 2106.37s | The unmapped parameter list header consists of three fields, unmapped data length, unmapped 2106.37s - 2111.49s | block descriptor data length, and reserved. 2111.49s - 2119.49s | The unmapped block descriptor consists of two fields, unmapped logical block address 2119.49s - 2123.33s | and number of logical blocks. 2123.33s - 2131.01s | These two fields indicate the starting address and length of the block that the user wants 2131.01s - 2133.89s | to unmap. 2133.97s - 2142.93s | This is an open view of the three unmapped structures so that everyone can easily understand 2142.93s - 2147.33s | the structure of the unmapped command. 2147.33s - 2156.53s | The three structures are very closely related, and we will focus on parameter list length 2156.53s - 2160.77s | and unmapped block descriptor data length. 2160.85s - 2164.05s | Those fields indicate the length. 2164.05s - 2171.89s | Unmapped block descriptor data length indicates the length of all subsequent unmapped block 2171.89s - 2174.69s | descriptors. 2174.69s - 2182.53s | Parameter list length includes not only the length of all unmapped block descriptors, 2182.53s - 2188.93s | but also the length of the unmapped parameter list header. 2188.93s - 2197.25s | Let's see how VMware implements the unmapped command according to the SCSI commands reference 2197.25s - 2199.81s | menu. 2199.81s - 2208.21s | Before actually running the unmapped command, the vscsi-check-unmapped-cmd function will 2208.21s - 2210.77s | be entered first. 2210.77s - 2219.09s | In this function, a heap of the corresponding size is requested according to the parameter 2219.09s -


chunk_id: 188_chunk_27
chunk_text:
length of the block that the user wants 2131.01s - 2133.89s | to unmap. 2133.97s - 2142.93s | This is an open view of the three unmapped structures so that everyone can easily understand 2142.93s - 2147.33s | the structure of the unmapped command. 2147.33s - 2156.53s | The three structures are very closely related, and we will focus on parameter list length 2156.53s - 2160.77s | and unmapped block descriptor data length. 2160.85s - 2164.05s | Those fields indicate the length. 2164.05s - 2171.89s | Unmapped block descriptor data length indicates the length of all subsequent unmapped block 2171.89s - 2174.69s | descriptors. 2174.69s - 2182.53s | Parameter list length includes not only the length of all unmapped block descriptors, 2182.53s - 2188.93s | but also the length of the unmapped parameter list header. 2188.93s - 2197.25s | Let's see how VMware implements the unmapped command according to the SCSI commands reference 2197.25s - 2199.81s | menu. 2199.81s - 2208.21s | Before actually running the unmapped command, the vscsi-check-unmapped-cmd function will 2208.21s - 2210.77s | be entered first. 2210.77s - 2219.09s | In this function, a heap of the corresponding size is requested according to the parameter 2219.09s - 2226.45s | list length, and all the unmapped data is copied to the heap. 2226.45s - 2235.33s | After the unmapped data is copied, the content of the data will be checked, but it forgets 2235.41s - 2242.93s | to check the relationship between parameter list length and unmapped block descriptor 2242.93s - 2252.05s | data length, and the number of unmapped block descriptors is determined based on the unmapped 2252.05s - 2254.93s | block descriptor data length. 2254.93s - 2263.01s | The user can set a special parameter list to carry a large number of unmapped block 2263.01s - 2268.69s | descriptors, but only check the first unmapped block descriptor. 2270.69s - 2274.53s | Check completed, enter the actual use stage. 2275.57s - 2284.85s | According to the code in the figure, parameter list length is used as the boundary length, 2284.85s - 2292.85s | which allows the previously unchecked unmapped block descriptor to be put into use. 2293.97s - 2302.45s | The unchecked logical block size is used as the size variable in the code shown in the 2302.45s - 2307.01s | figure, and overviews out-of-bounds read. 2307.01s - 2316.61s | In fact, it is this out-of-bounds read


chunk_id: 188_chunk_28
chunk_text:
2226.45s | list length, and all the unmapped data is copied to the heap. 2226.45s - 2235.33s | After the unmapped data is copied, the content of the data will be checked, but it forgets 2235.41s - 2242.93s | to check the relationship between parameter list length and unmapped block descriptor 2242.93s - 2252.05s | data length, and the number of unmapped block descriptors is determined based on the unmapped 2252.05s - 2254.93s | block descriptor data length. 2254.93s - 2263.01s | The user can set a special parameter list to carry a large number of unmapped block 2263.01s - 2268.69s | descriptors, but only check the first unmapped block descriptor. 2270.69s - 2274.53s | Check completed, enter the actual use stage. 2275.57s - 2284.85s | According to the code in the figure, parameter list length is used as the boundary length, 2284.85s - 2292.85s | which allows the previously unchecked unmapped block descriptor to be put into use. 2293.97s - 2302.45s | The unchecked logical block size is used as the size variable in the code shown in the 2302.45s - 2307.01s | figure, and overviews out-of-bounds read. 2307.01s - 2316.61s | In fact, it is this out-of-bounds read that actually causes the crash, not the so-called 2316.61s - 2318.05s | out-of-bounds read. 2318.53s - 2326.37s | Regarding the new attack surface of VMkernel, I have summarized the following three major 2326.37s - 2326.93s | points. 2327.65s - 2337.57s | Modify the existing sandbox protection mechanism, elevate the current process privileges, virtual 2337.57s - 2338.61s | machine escape. 2339.65s - 2342.53s | OK, thank you for your listening. 2342.53s - 2348.85s | If you have any problem, you can contact us with Twitter.


chunk_id: 188_chunk_29
chunk_text:
that actually causes the crash, not the so-called 2316.61s - 2318.05s | out-of-bounds read. 2318.53s - 2326.37s | Regarding the new attack surface of VMkernel, I have summarized the following three major 2326.37s - 2326.93s | points. 2327.65s - 2337.57s | Modify the existing sandbox protection mechanism, elevate the current process privileges, virtual 2337.57s - 2338.61s | machine escape. 2339.65s - 2342.53s | OK, thank you for your listening. 2342.53s - 2348.85s | If you have any problem, you can contact us with Twitter.


chunk_id: 189_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=zGgPm2LeM8A", "title": "DEF CON 32 - DC101 - Panel", "description": "What you need to know to get the most out of your first DEF CON.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2708, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 6.82s | This text was transcribed using whisper model: large-v2 My name is Nikita. I am the Director of Content and Coordination for DEF CON. I am the 6.82s - 11.82s | Chief Hacker Wrangler. Um so I handle a lot of the logistical operations for DEF CON as well 15.56s - 22.56s | as um sort of wrangle a lot of the department leads like that you see here. I wanted to 22.56s - 27.56s | start out with um a little quick introduction and then give you a brief overview. Um we 28.56s - 33.56s | have um a null value Drew. Yeah. Did I just dox him? I just. You said his name. I'm so 37.74s - 42.74s | sorry. Oh man. Then we have. That's how we start this off. This is going great. That 44.88s - 49.88s | too. Then we have Grifter. Grifter is the lead for our contest and uh events for DEF 50.08s - 55.08s | CON and then we have Ada who runs our wonderful hotline program and um I have some notes 63.06s - 68.30s | here and I will be perfectly honest with you I am a nervous speaker so I'm clutching 68.30s - 73.10s | the podium. You're doing great. I mean I'm like you're it's fantastic. Is she doing 73.10s - 80.21s | great? Absolutely. I thought that cheering would make you more nervous. Did it work? A 80.21s - 85.95s | little bit. Alright. Alright. Thank you. Back me up when we do that again. Okay. So 85.95s - 94.27s | um some things I wanted to let you know is that um if you are looking for something to 94.27s - 99.27s | do um you can come to this facility between 8 a.m. and 2 a.m. So we are open that whole 102.45s - 108.01s | entire time so if you are bored in your hotel room and you don't know anybody you can come 108.01s - 113.01s | down. There's some social events tonight. There's parties. There's people that are just 113.01s - 119.09s | sitting around hacking on stuff. Um I'm plenty


chunk_id: 189_chunk_1
chunk_text:
50.08s - 55.08s | CON and then we have Ada who runs our wonderful hotline program and um I have some notes 63.06s - 68.30s | here and I will be perfectly honest with you I am a nervous speaker so I'm clutching 68.30s - 73.10s | the podium. You're doing great. I mean I'm like you're it's fantastic. Is she doing 73.10s - 80.21s | great? Absolutely. I thought that cheering would make you more nervous. Did it work? A 80.21s - 85.95s | little bit. Alright. Alright. Thank you. Back me up when we do that again. Okay. So 85.95s - 94.27s | um some things I wanted to let you know is that um if you are looking for something to 94.27s - 99.27s | do um you can come to this facility between 8 a.m. and 2 a.m. So we are open that whole 102.45s - 108.01s | entire time so if you are bored in your hotel room and you don't know anybody you can come 108.01s - 113.01s | down. There's some social events tonight. There's parties. There's people that are just 113.01s - 119.09s | sitting around hacking on stuff. Um I'm plenty of people to talk to. Plenty of things to do. 119.09s - 125.83s | Lots of stuff happens at night that is just unplanned and um it's always fun to see what 125.83s - 132.73s | people come up with every year but um we have things like laser Tetris. We have um multiple 132.75s - 140.19s | parties so if you are here just because these halls close at 6 p.m. doesn't mean the rest of 140.19s - 145.21s | Defcon does. So from 8 a.m. to 2 a.m. and then in our hall in the halls that you're in now are 148.91s - 153.91s | open from 10 to 6 so villages, contests, those are those all close around at 6. Um oh we have 153.91s - 158.91s | one really really important rule and usually we refer to it as the 3-2-1 rule and that means 165.11s - 170.11s | 3 hours of sleep, 2 meals, 1 shower. Now we're kind of all getting on in our age and um this is 174.39s - 179.39s | my 21st Defcon. Speak for yourself I'm spring chicken. And I can't do 3 hours of sleep 179.61s - 184.61s |


chunk_id: 189_chunk_2
chunk_text:
of people to talk to. Plenty of things to do. 119.09s - 125.83s | Lots of stuff happens at night that is just unplanned and um it's always fun to see what 125.83s - 132.73s | people come up with every year but um we have things like laser Tetris. We have um multiple 132.75s - 140.19s | parties so if you are here just because these halls close at 6 p.m. doesn't mean the rest of 140.19s - 145.21s | Defcon does. So from 8 a.m. to 2 a.m. and then in our hall in the halls that you're in now are 148.91s - 153.91s | open from 10 to 6 so villages, contests, those are those all close around at 6. Um oh we have 153.91s - 158.91s | one really really important rule and usually we refer to it as the 3-2-1 rule and that means 165.11s - 170.11s | 3 hours of sleep, 2 meals, 1 shower. Now we're kind of all getting on in our age and um this is 174.39s - 179.39s | my 21st Defcon. Speak for yourself I'm spring chicken. And I can't do 3 hours of sleep 179.61s - 184.61s | anymore so I have made an executive decision to therefore mandate that it is now 6 hours of 188.39s - 193.39s | sleep. So 6 hours of sleep, 2 meals, and 1 shower every day. Please. I advocate for uh 6 hours of 196.33s - 201.33s | sleep. 3 meals, 2 showers. Last night I got 3 hours and 3 minutes of sleep. I am killing it. 202.29s - 209.78s | It's important to take care of yourself. Las Vegas is really big. It's hot outside. There's lots 212.22s - 216.92s | of traveling. Um it's really easy to get dehydrated. It's one of the number 1 things that 216.92s - 221.70s | happens to people when they're not feeling well at Defcon. It's because you are dehydrated and 221.70s - 226.70s | speaking from personal personal experience here you need to drink water or you might die. So 227.12s - 232.12s | drink water. Um another thing another rule is listen to the goons. I'm sure you guys have 235.30s - 242.86s | noticed the goons in the hallways directing you to the left to the right. Whoever just made 242.86s - 247.86s | that announcement I heard. Um


chunk_id: 189_chunk_3
chunk_text:
anymore so I have made an executive decision to therefore mandate that it is now 6 hours of 188.39s - 193.39s | sleep. So 6 hours of sleep, 2 meals, and 1 shower every day. Please. I advocate for uh 6 hours of 196.33s - 201.33s | sleep. 3 meals, 2 showers. Last night I got 3 hours and 3 minutes of sleep. I am killing it. 202.29s - 209.78s | It's important to take care of yourself. Las Vegas is really big. It's hot outside. There's lots 212.22s - 216.92s | of traveling. Um it's really easy to get dehydrated. It's one of the number 1 things that 216.92s - 221.70s | happens to people when they're not feeling well at Defcon. It's because you are dehydrated and 221.70s - 226.70s | speaking from personal personal experience here you need to drink water or you might die. So 227.12s - 232.12s | drink water. Um another thing another rule is listen to the goons. I'm sure you guys have 235.30s - 242.86s | noticed the goons in the hallways directing you to the left to the right. Whoever just made 242.86s - 247.86s | that announcement I heard. Um listen to them and if they're yelling it's only to get your 250.40s - 255.40s | attention. Um never really to be unkind intentionally. Um if you do have any problems 263.32s - 270.16s | with goons you can either email feedback at Defcon.org or you can call the hotline and um we'll 270.16s - 275.16s | get to that. Um Defcon is about trying new things. Um we're all noobs here. Even me. I may be 282.58s - 287.58s | 21 years but I still consider myself a noob at lots of stuff and that's cool. That's okay. Um 288.28s - 293.28s | it's a choose your own adventure here. You don't have to think oh I have to have this 296.66s - 300.52s | checklist. I have to go to talks. I have to go to this village. I have to go to that village. I 300.52s - 306.70s | have to go to that village. You if you find something that you are interested in 1 the talks 306.70s - 313.70s | will be online later. So you can catch them later. You can catch up later. But also find your 313.72s - 320.06s | people. Find


chunk_id: 189_chunk_4
chunk_text:
listen to them and if they're yelling it's only to get your 250.40s - 255.40s | attention. Um never really to be unkind intentionally. Um if you do have any problems 263.32s - 270.16s | with goons you can either email feedback at Defcon.org or you can call the hotline and um we'll 270.16s - 275.16s | get to that. Um Defcon is about trying new things. Um we're all noobs here. Even me. I may be 282.58s - 287.58s | 21 years but I still consider myself a noob at lots of stuff and that's cool. That's okay. Um 288.28s - 293.28s | it's a choose your own adventure here. You don't have to think oh I have to have this 296.66s - 300.52s | checklist. I have to go to talks. I have to go to this village. I have to go to that village. I 300.52s - 306.70s | have to go to that village. You if you find something that you are interested in 1 the talks 306.70s - 313.70s | will be online later. So you can catch them later. You can catch up later. But also find your 313.72s - 320.06s | people. Find the thing that gets you really jazzed up. And you'll know it when you find it. 320.06s - 326.48s | You'll know when you don't really want to leave an area. Don't. It's okay. It'll all that other 326.48s - 331.48s | stuff will be here next year. Um have fun. Uh try new things. And there's a lot of things. 334.82s - 341.18s | One of the things about our villages and and to a degree a lot of our contests is I try to 341.20s - 348.20s | ensure that no matter where you are at DAF CON you can have 0 knowledge about a subject. It 348.20s - 354.82s | doesn't matter what village it is. They have a something that you can walk in and you can 354.82s - 359.82s | learn. You can go in. Do a thing. Have a workshop. Do a an activity. Build a badge. Um work 362.80s - 368.06s | a solution out for something. Right off the street anybody's grandmother can come in and learn 368.08s - 373.08s | something new and then walk walk out the better or more curious or for it. Um so don't be 376.08s -


chunk_id: 189_chunk_5
chunk_text:
the thing that gets you really jazzed up. And you'll know it when you find it. 320.06s - 326.48s | You'll know when you don't really want to leave an area. Don't. It's okay. It'll all that other 326.48s - 331.48s | stuff will be here next year. Um have fun. Uh try new things. And there's a lot of things. 334.82s - 341.18s | One of the things about our villages and and to a degree a lot of our contests is I try to 341.20s - 348.20s | ensure that no matter where you are at DAF CON you can have 0 knowledge about a subject. It 348.20s - 354.82s | doesn't matter what village it is. They have a something that you can walk in and you can 354.82s - 359.82s | learn. You can go in. Do a thing. Have a workshop. Do a an activity. Build a badge. Um work 362.80s - 368.06s | a solution out for something. Right off the street anybody's grandmother can come in and learn 368.08s - 373.08s | something new and then walk walk out the better or more curious or for it. Um so don't be 376.08s - 381.08s | afraid to ask questions. Don't be afraid to say I don't I don't know how to do this. Show me. Or 383.50s - 389.36s | um hey I'm really interested in this but I don't want to do it alone. It's okay to collaborate. 389.36s - 395.60s | And it's okay to compete too. We have things like scavenger hunt which are absolutely amazing 395.62s - 400.98s | for going out and meeting people and trying new things. Getting these new experiences. Things 400.98s - 405.98s | that you're not going to get at other conferences because we are so very unique as a culture, as a 409.40s - 414.40s | community, as a conference that we have so many things that you can do to collaborate. 419.10s - 424.00s | Can I make a comment on that too? Um so you're saying like yeah go out and try new things. Do 424.24s - 429.38s | new things. I I think something that I hear really often is people will say oh well I don't know 429.38s - 433.78s | anything about that. Like so it's like oh you should go check out the aerospace village. And 433.78s


chunk_id: 189_chunk_6
chunk_text:
381.08s | afraid to ask questions. Don't be afraid to say I don't I don't know how to do this. Show me. Or 383.50s - 389.36s | um hey I'm really interested in this but I don't want to do it alone. It's okay to collaborate. 389.36s - 395.60s | And it's okay to compete too. We have things like scavenger hunt which are absolutely amazing 395.62s - 400.98s | for going out and meeting people and trying new things. Getting these new experiences. Things 400.98s - 405.98s | that you're not going to get at other conferences because we are so very unique as a culture, as a 409.40s - 414.40s | community, as a conference that we have so many things that you can do to collaborate. 419.10s - 424.00s | Can I make a comment on that too? Um so you're saying like yeah go out and try new things. Do 424.24s - 429.38s | new things. I I think something that I hear really often is people will say oh well I don't know 429.38s - 433.78s | anything about that. Like so it's like oh you should go check out the aerospace village. And 433.78s - 438.92s | they're like but I don't know anything about that. And it's like there's this misconception that 438.92s - 445.92s | you're going there to um use your vast amount of knowledge of the aerospace industry to it. That's 445.92s - 450.44s | that's not what that's about. The people who are in there and creating the villages are really 450.44s - 456.72s | excited about sharing what they know with you. So you can walk in with absolutely no knowledge. I 456.72s - 461.38s | hear people say things like oh I don't really go to DEF CON because I'm not very technical. And 461.38s - 466.38s | it's like it's not necessarily about just being technical. It's about going, learning, growing and 469.10s - 474.00s | again trying new things. You may be the best car hacker that exists and you don't know because 474.00s - 478.94s | you've never given it a shot. So go in and just approach somebody and say I've never done 478.94s - 484.18s | anything with this before. Can somebody show me? And if they don't immediately show you they'll 484.18s - 488.68s | point you to the person who


chunk_id: 189_chunk_7
chunk_text:
- 438.92s | they're like but I don't know anything about that. And it's like there's this misconception that 438.92s - 445.92s | you're going there to um use your vast amount of knowledge of the aerospace industry to it. That's 445.92s - 450.44s | that's not what that's about. The people who are in there and creating the villages are really 450.44s - 456.72s | excited about sharing what they know with you. So you can walk in with absolutely no knowledge. I 456.72s - 461.38s | hear people say things like oh I don't really go to DEF CON because I'm not very technical. And 461.38s - 466.38s | it's like it's not necessarily about just being technical. It's about going, learning, growing and 469.10s - 474.00s | again trying new things. You may be the best car hacker that exists and you don't know because 474.00s - 478.94s | you've never given it a shot. So go in and just approach somebody and say I've never done 478.94s - 484.18s | anything with this before. Can somebody show me? And if they don't immediately show you they'll 484.18s - 488.68s | point you to the person who will. So just don't be shy. I know it's difficult for us. It's very 488.68s - 495.22s | prevalent that we're introverted in this in this community, in this industry and all those things. 495.22s - 500.86s | Just just try. Just go up and be like I don't know how to do this. Will somebody show me? And you 500.86s - 505.84s | can have some of the best experiences. I know that's been huge personally for me and for my own 505.84s - 511.74s | growth as a person and as a hacker. Just walking up and being like what are you doing? What does 511.74s - 517.74s | that mean? And then watching the other person get excited about sharing that with you. So yeah. 519.08s - 525.62s | Yeah in my opinion the the only precursor or prerequisite for attending DEF CON successfully is a 525.62s - 531.36s | willingness to learn. If you're not willing to learn, why are you here? Everyone's willing to 531.36s - 539.92s | help. The $25 chicken tenders. Yes. That's why they're here. Or the $30 burgers. Yeah I agree with 539.92s - 546.80s | that. And I would say


chunk_id: 189_chunk_8
chunk_text:
will. So just don't be shy. I know it's difficult for us. It's very 488.68s - 495.22s | prevalent that we're introverted in this in this community, in this industry and all those things. 495.22s - 500.86s | Just just try. Just go up and be like I don't know how to do this. Will somebody show me? And you 500.86s - 505.84s | can have some of the best experiences. I know that's been huge personally for me and for my own 505.84s - 511.74s | growth as a person and as a hacker. Just walking up and being like what are you doing? What does 511.74s - 517.74s | that mean? And then watching the other person get excited about sharing that with you. So yeah. 519.08s - 525.62s | Yeah in my opinion the the only precursor or prerequisite for attending DEF CON successfully is a 525.62s - 531.36s | willingness to learn. If you're not willing to learn, why are you here? Everyone's willing to 531.36s - 539.92s | help. The $25 chicken tenders. Yes. That's why they're here. Or the $30 burgers. Yeah I agree with 539.92s - 546.80s | that. And I would say that I've noticed some people their first DEF CON say you can see when 546.80s - 554.64s | they've been they've been shut down before and they say I'm sorry sorry I'm going on a rant. Don't 554.64s - 559.72s | be sorry. That's what we're all here for. Go on the damn rant. Say the thing. Tell us what you're 559.72s - 567.98s | excited about. Talk about it. Because we're all like that. We're all here for a reason. And I I 567.98s - 572.82s | feel like I've heard it bunches and bunches of times. People they come and they're like I found my 572.82s - 580.16s | people. Yeah. And that's why we've got people who have been gooning for so long. It's because we 580.16s - 587.20s | found our people. We want to make sure everybody else does too. So. Grifter. Yes. What type of 587.20s - 594.56s | contests do we have this year? I'm so glad you asked me that question Nikita. As the head of the 594.56s - 601.86s | contest and events here at DEF CON. Honestly we've got everything. If you for me I like our motto for 601.86s


chunk_id: 189_chunk_9
chunk_text:
that I've noticed some people their first DEF CON say you can see when 546.80s - 554.64s | they've been they've been shut down before and they say I'm sorry sorry I'm going on a rant. Don't 554.64s - 559.72s | be sorry. That's what we're all here for. Go on the damn rant. Say the thing. Tell us what you're 559.72s - 567.98s | excited about. Talk about it. Because we're all like that. We're all here for a reason. And I I 567.98s - 572.82s | feel like I've heard it bunches and bunches of times. People they come and they're like I found my 572.82s - 580.16s | people. Yeah. And that's why we've got people who have been gooning for so long. It's because we 580.16s - 587.20s | found our people. We want to make sure everybody else does too. So. Grifter. Yes. What type of 587.20s - 594.56s | contests do we have this year? I'm so glad you asked me that question Nikita. As the head of the 594.56s - 601.86s | contest and events here at DEF CON. Honestly we've got everything. If you for me I like our motto for 601.86s - 607.12s | the contest and events is not one talk not even one. All right. And Nikita mentioned that a little 607.12s - 615.16s | bit. I'm sorry I say to the head of content. But but our our thing is that you can watch the talks 615.16s - 622.50s | later on YouTube but you won't have the people that are here sitting around you at home. They may be 622.50s - 630.08s | watching you but they're just not there in the room. Yeah that's good for your anxiety. Anyway. So I 630.08s - 634.46s | always say like go and try the things that are here that you can't have when you're when you're gone. 634.46s - 637.80s | Now that doesn't mean if there's something that you're super passionate about and you know there's a 637.80s - 644.80s | talk that you want to see or your friend is speaking go support you know yell woo out in the crowd. But 645.34s - 652.12s | but genuinely like for me one of the things that I enjoyed the most about DEF CON in the early years 652.12s - 660.74s | that I was coming was


chunk_id: 189_chunk_10
chunk_text:
- 607.12s | the contest and events is not one talk not even one. All right. And Nikita mentioned that a little 607.12s - 615.16s | bit. I'm sorry I say to the head of content. But but our our thing is that you can watch the talks 615.16s - 622.50s | later on YouTube but you won't have the people that are here sitting around you at home. They may be 622.50s - 630.08s | watching you but they're just not there in the room. Yeah that's good for your anxiety. Anyway. So I 630.08s - 634.46s | always say like go and try the things that are here that you can't have when you're when you're gone. 634.46s - 637.80s | Now that doesn't mean if there's something that you're super passionate about and you know there's a 637.80s - 644.80s | talk that you want to see or your friend is speaking go support you know yell woo out in the crowd. But 645.34s - 652.12s | but genuinely like for me one of the things that I enjoyed the most about DEF CON in the early years 652.12s - 660.74s | that I was coming was competing in a contest like it forced me to get outside of my comfort zone forced 660.74s - 668.62s | me to interact with strangers frankly right. Who all you know use spooky names and and work on things 668.62s - 677.70s | that I didn't know how to do like I a contest is what introduced me to lock picking like I just I there 677.70s - 683.38s | was a part of a contest that I didn't know how to do it and I was like oh no and I couldn't get past a 683.38s - 689.44s | certain thing and eventually I got help from someone else and then I was like okay that's something I 689.44s - 694.74s | need to learn. So I I went and bought a bunch of picks and I spent the next year picking locks so that 694.74s - 699.78s | when I came back the next year to compete in the contest I knew when I hit that bar I would be ready to go 699.78s - 708.46s | right so it forced me to continue to develop myself. So we have everything from again aerospace type of car 708.46s


chunk_id: 189_chunk_11
chunk_text:
competing in a contest like it forced me to get outside of my comfort zone forced 660.74s - 668.62s | me to interact with strangers frankly right. Who all you know use spooky names and and work on things 668.62s - 677.70s | that I didn't know how to do like I a contest is what introduced me to lock picking like I just I there 677.70s - 683.38s | was a part of a contest that I didn't know how to do it and I was like oh no and I couldn't get past a 683.38s - 689.44s | certain thing and eventually I got help from someone else and then I was like okay that's something I 689.44s - 694.74s | need to learn. So I I went and bought a bunch of picks and I spent the next year picking locks so that 694.74s - 699.78s | when I came back the next year to compete in the contest I knew when I hit that bar I would be ready to go 699.78s - 708.46s | right so it forced me to continue to develop myself. So we have everything from again aerospace type of car 708.46s - 715.02s | hacking or just plain weird like the scavenger hunt and I love the scavenger hunt. I ran it for years back 715.02s - 719.76s | when we were at the Alexis Park. Didn't you create it? What's that? Didn't you create it? No Pinguino 719.76s - 724.26s | created it. Oh okay. Yeah I didn't create it. Pinguino created it she ran it for a couple of years and then 724.26s - 730.76s | she reached out to me and said I'm not going to be able to be at DEF CON can you take this over and so we 730.76s - 736.86s | just we we removed answer it who is it no answer it answer it on stage answer it on stage do it please 736.86s - 743.64s | please please do it. Oh Nikita it would have been weird. Oh keep DEF CON weird. So speaking of the 743.64s - 749.84s | scavenger hunt we just put a bunch of really weird stuff on there and so when you see somebody doing 749.86s - 758.90s | something incredibly odd it might be the scavenger hunt or they might just be neuro spicy I don't


chunk_id: 189_chunk_12
chunk_text:
- 715.02s | hacking or just plain weird like the scavenger hunt and I love the scavenger hunt. I ran it for years back 715.02s - 719.76s | when we were at the Alexis Park. Didn't you create it? What's that? Didn't you create it? No Pinguino 719.76s - 724.26s | created it. Oh okay. Yeah I didn't create it. Pinguino created it she ran it for a couple of years and then 724.26s - 730.76s | she reached out to me and said I'm not going to be able to be at DEF CON can you take this over and so we 730.76s - 736.86s | just we we removed answer it who is it no answer it answer it on stage answer it on stage do it please 736.86s - 743.64s | please please do it. Oh Nikita it would have been weird. Oh keep DEF CON weird. So speaking of the 743.64s - 749.84s | scavenger hunt we just put a bunch of really weird stuff on there and so when you see somebody doing 749.86s - 758.90s | something incredibly odd it might be the scavenger hunt or they might just be neuro spicy I don't know but but go 758.90s - 767.18s | and and compete in things that push you to learn new skills or just push you to keep DEF CON weird and I know 767.18s - 775.12s | we all try to do that. So I have another question for you. How many black badges do you have and what are they 775.14s - 781.84s | and how can you get them. Yeah I don't know how many. How many do I have Nikita. You tell me since you're the one who 781.84s - 790.26s | tells me. I've given up at this point. Okay so normally I mean how many have you won. How many have I won personally. 790.30s - 799.56s | Three. So I competed in a contest. Oh what's a black badge you ask. A black badge is when you certain contests will be 799.58s - 808.14s | given a black badge for the winner of that contest and that gets you free entry into DEF CON for life. And that started at 808.14s - 816.22s | DEF CON I guess 10 technically or 9 technically because somebody got it for the cyber ethical challenge or something and


chunk_id: 189_chunk_13
chunk_text:
know but but go 758.90s - 767.18s | and and compete in things that push you to learn new skills or just push you to keep DEF CON weird and I know 767.18s - 775.12s | we all try to do that. So I have another question for you. How many black badges do you have and what are they 775.14s - 781.84s | and how can you get them. Yeah I don't know how many. How many do I have Nikita. You tell me since you're the one who 781.84s - 790.26s | tells me. I've given up at this point. Okay so normally I mean how many have you won. How many have I won personally. 790.30s - 799.56s | Three. So I competed in a contest. Oh what's a black badge you ask. A black badge is when you certain contests will be 799.58s - 808.14s | given a black badge for the winner of that contest and that gets you free entry into DEF CON for life. And that started at 808.14s - 816.22s | DEF CON I guess 10 technically or 9 technically because somebody got it for the cyber ethical challenge or something and 816.22s - 824.60s | then the next year we had actual black badges. So it started really at DEF CON 10 and has gone ever since. And no one 824.60s - 831.98s | knows which contest is going to get that up front. And that's on purpose. We want you to compete in the contest that are of 831.98s - 840.34s | interest to you. And then maybe you might win a black badge versus just being like oh that contest gets a black badge. I'll 840.34s - 842.84s | focus on that. Right. Yeah. 845.36s - 852.16s | 18 by the way. That's the number of badges. There are 18 black badges. Eight of them go to CTF. The rest of them go to the 852.16s - 860.04s | rest of the contest. The black badge is also known as the uber badge. Uber. Yeah. So that could be you. I mean super in German. 860.24s - 869.51s | One of you out here. Does that mean that. Hello German friends. No. Scheisse. Ada. 874.34s - 882.90s | Many fans. And thank you. Just the ones in the front row. What. I would like to ask you a couple


chunk_id: 189_chunk_14
chunk_text:
816.22s - 824.60s | then the next year we had actual black badges. So it started really at DEF CON 10 and has gone ever since. And no one 824.60s - 831.98s | knows which contest is going to get that up front. And that's on purpose. We want you to compete in the contest that are of 831.98s - 840.34s | interest to you. And then maybe you might win a black badge versus just being like oh that contest gets a black badge. I'll 840.34s - 842.84s | focus on that. Right. Yeah. 845.36s - 852.16s | 18 by the way. That's the number of badges. There are 18 black badges. Eight of them go to CTF. The rest of them go to the 852.16s - 860.04s | rest of the contest. The black badge is also known as the uber badge. Uber. Yeah. So that could be you. I mean super in German. 860.24s - 869.51s | One of you out here. Does that mean that. Hello German friends. No. Scheisse. Ada. 874.34s - 882.90s | Many fans. And thank you. Just the ones in the front row. What. I would like to ask you a couple of questions. What is 882.90s - 892.46s | hotline. So hotline is a service that's been going for five DEF CONs now but that's seven years. So you know canceled DEF CONs 892.46s - 903.06s | unfortunately. You can call it for a number of things. We have people who are there all throughout the con to answer your questions 903.06s - 916.06s | about various information things but even more so if you have conduct issues with anybody we can call and talk to us. If you are in a 916.06s - 925.82s | crisis if you're having a panic attack if you are not feeling comfortable at con if you just need somebody to talk to they're trained to 925.82s - 930.50s | handle all of those things. And that's why the front row is screaming at me. Yeah. 930.50s - 943.86s | I personally can say that there are a lot of people who are very happy for what hotline does. And I know that you spent several weeks doing 943.86s - 953.78s | training with our goons with volunteers to talk about how to escalate a call how to deescalate a call how to you know


chunk_id: 189_chunk_15
chunk_text:
of questions. What is 882.90s - 892.46s | hotline. So hotline is a service that's been going for five DEF CONs now but that's seven years. So you know canceled DEF CONs 892.46s - 903.06s | unfortunately. You can call it for a number of things. We have people who are there all throughout the con to answer your questions 903.06s - 916.06s | about various information things but even more so if you have conduct issues with anybody we can call and talk to us. If you are in a 916.06s - 925.82s | crisis if you're having a panic attack if you are not feeling comfortable at con if you just need somebody to talk to they're trained to 925.82s - 930.50s | handle all of those things. And that's why the front row is screaming at me. Yeah. 930.50s - 943.86s | I personally can say that there are a lot of people who are very happy for what hotline does. And I know that you spent several weeks doing 943.86s - 953.78s | training with our goons with volunteers to talk about how to escalate a call how to deescalate a call how to you know deal with the things 953.78s - 964.22s | that hotline is there for for our attendees. And I just think that's amazing. They actually start. I start looking for people in February. We 964.22s - 974.86s | pick people early March. They start class late March. They go once a week every week until DEF CON. So it's a little extensive but it's also the 974.86s - 985.70s | same training that I did when I used to work for suicide prevention hotlines. So they can help you with anything. You can just call and talk if 985.70s - 1000.98s | you need to. Yeah. And why did hotline start. Hotline started in 2018 and the year before. We had an issue where someone came forward with an 1000.98s - 1011.62s | issue. The goon who tried to take the incident from her didn't know how to handle it properly. So he's looking for me because I come from a background in 1011.62s - 1023.90s | psychology. Suicide prevention hotline. And couldn't find me. And when he finally found me, she had disappeared. And at that point in time, all of the 1023.90s - 1033.14s | people at DEF CON


chunk_id: 189_chunk_16
chunk_text:
deal with the things 953.78s - 964.22s | that hotline is there for for our attendees. And I just think that's amazing. They actually start. I start looking for people in February. We 964.22s - 974.86s | pick people early March. They start class late March. They go once a week every week until DEF CON. So it's a little extensive but it's also the 974.86s - 985.70s | same training that I did when I used to work for suicide prevention hotlines. So they can help you with anything. You can just call and talk if 985.70s - 1000.98s | you need to. Yeah. And why did hotline start. Hotline started in 2018 and the year before. We had an issue where someone came forward with an 1000.98s - 1011.62s | issue. The goon who tried to take the incident from her didn't know how to handle it properly. So he's looking for me because I come from a background in 1011.62s - 1023.90s | psychology. Suicide prevention hotline. And couldn't find me. And when he finally found me, she had disappeared. And at that point in time, all of the 1023.90s - 1033.14s | people at DEF CON were like, how can we make this not happen again? How can we get somebody who's going through that someplace to talk to so they can come 1033.14s - 1044.22s | forward and they can feel comfortable from the comfort of their hotel room if they need to. And that's sort of where we came from. Just someplace with a 1044.22s - 1054.78s | comforting voice to talk to. Yeah. I'm sure you take a lot of like serious calls, serious things that you, you know, but what is your kind of corkiest, your 1054.78s - 1066.10s | weirdest, your funniest? I have to say we do get calls from people trapped in back of house. If you find a door and you don't know where it goes to, I highly 1066.10s - 1076.70s | recommend not going in it. I, on the other hand, say go through the door. Do it. You may get trapped. We've already had one this year. And we've had a few in the 1076.70s - 1088.30s | past. Strange doors may lead to a bunch of locked rooms that you can't get out of. Go through the door. But Holloween is there for you


chunk_id: 189_chunk_17
chunk_text:
were like, how can we make this not happen again? How can we get somebody who's going through that someplace to talk to so they can come 1033.14s - 1044.22s | forward and they can feel comfortable from the comfort of their hotel room if they need to. And that's sort of where we came from. Just someplace with a 1044.22s - 1054.78s | comforting voice to talk to. Yeah. I'm sure you take a lot of like serious calls, serious things that you, you know, but what is your kind of corkiest, your 1054.78s - 1066.10s | weirdest, your funniest? I have to say we do get calls from people trapped in back of house. If you find a door and you don't know where it goes to, I highly 1066.10s - 1076.70s | recommend not going in it. I, on the other hand, say go through the door. Do it. You may get trapped. We've already had one this year. And we've had a few in the 1076.70s - 1088.30s | past. Strange doors may lead to a bunch of locked rooms that you can't get out of. Go through the door. But Holloween is there for you to make sure that you find your way 1088.30s - 1102.02s | out. You have a backup. They'll come get you. Go through the door. Facilities might come get you too. And they might not like you after that. Nikita, can I go up there? No, please. No. Can 1102.02s - 1111.10s | someone take me? No, please. No. Somebody turn off this mic. Immediately. No. 1111.58s - 1129.55s | I know he wakes up every morning and chooses violence. He really does. He is. Get up. I mean, he's like, he's like a little kitten. Oh, I'm getting up there. I'm throwing it down. Selfie kicked out of 1129.55s - 1159.92s | facilities. That's only if you get caught. And no, I don't know. But that's my boy right there. I bet. Let me ask you a question. Tell us a little bit about what Hacker Tracker is. Obviously, an app that tracks hackers now. Can it track them across the rafters? Only if they're up there and they're not. 1162.24s - 1192.12s | Hacker Tracker is the conference information app for DEF CON and numerous other conferences. DEF CON is the biggest by far. We were started by


chunk_id: 189_chunk_18
chunk_text:
to make sure that you find your way 1088.30s - 1102.02s | out. You have a backup. They'll come get you. Go through the door. Facilities might come get you too. And they might not like you after that. Nikita, can I go up there? No, please. No. Can 1102.02s - 1111.10s | someone take me? No, please. No. Somebody turn off this mic. Immediately. No. 1111.58s - 1129.55s | I know he wakes up every morning and chooses violence. He really does. He is. Get up. I mean, he's like, he's like a little kitten. Oh, I'm getting up there. I'm throwing it down. Selfie kicked out of 1129.55s - 1159.92s | facilities. That's only if you get caught. And no, I don't know. But that's my boy right there. I bet. Let me ask you a question. Tell us a little bit about what Hacker Tracker is. Obviously, an app that tracks hackers now. Can it track them across the rafters? Only if they're up there and they're not. 1162.24s - 1192.12s | Hacker Tracker is the conference information app for DEF CON and numerous other conferences. DEF CON is the biggest by far. We were started by Whitney maybe a decade ago. I joined the team in DC 27, I believe it was. We're the ones that provide the schedule to you. Please install Hacker Tracker on your phone. We don't actually track hackers. It doesn't matter how many comments we get on 1192.12s - 1201.00s | Google or Apple asking us to track hackers. We're not going to do it. It's an open source app. You can read our source if you want. It's on GitHub. 1203.12s - 1211.32s | So tracking hackers is not a feature. But what is your favorite feature about or your newest features about Hacker Tracker? 1213.54s - 1233.54s | So the newest features are a more easy way to see contests and events and parties so that you can just look at the list of them on screen rather than having to search through the schedule for them. And this year we added a feedback option for all of the official content. So please use that feature. 1234.98s - 1237.54s | And how does the feedback? How does the feedback work? 1237.54s - 1267.32s | As soon as this talk starts, you're short a few minutes after, I think. You


chunk_id: 189_chunk_19
chunk_text:
Whitney maybe a decade ago. I joined the team in DC 27, I believe it was. We're the ones that provide the schedule to you. Please install Hacker Tracker on your phone. We don't actually track hackers. It doesn't matter how many comments we get on 1192.12s - 1201.00s | Google or Apple asking us to track hackers. We're not going to do it. It's an open source app. You can read our source if you want. It's on GitHub. 1203.12s - 1211.32s | So tracking hackers is not a feature. But what is your favorite feature about or your newest features about Hacker Tracker? 1213.54s - 1233.54s | So the newest features are a more easy way to see contests and events and parties so that you can just look at the list of them on screen rather than having to search through the schedule for them. And this year we added a feedback option for all of the official content. So please use that feature. 1234.98s - 1237.54s | And how does the feedback? How does the feedback work? 1237.54s - 1267.32s | As soon as this talk starts, you're short a few minutes after, I think. You can open the talk. Just search for it if you don't already have it open in Hacker Tracker. A button will appear at the bottom. Just clearly says submit feedback. We've, Ada and I, have worked closely to select the questions. Our big question we want to know is, quote unquote, is it hacker? Courtesy of DT. 1271.16s - 1272.12s | Give me my microphone back. 1272.12s - 1298.20s | So please click yes on that or we're all going to be fired. So just say yes, positive feedback. And you know, the what is hacker thing, I can speak to that a little bit, is that it's really important to Jeff that we maintain hacker culture, even though InfoSec has expanded to be so great compared to what it was, you know, back when this was started. 1298.92s - 1327.32s | Now all of our hackers are in InfoSec. We still we're finding things that people want to share things. But we are not an InfoSec conference. We are not about that. And so sometimes what is hacker can be what is just the curious nature of what you found and how and why. And it's not for a


chunk_id: 189_chunk_20
chunk_text:
can open the talk. Just search for it if you don't already have it open in Hacker Tracker. A button will appear at the bottom. Just clearly says submit feedback. We've, Ada and I, have worked closely to select the questions. Our big question we want to know is, quote unquote, is it hacker? Courtesy of DT. 1271.16s - 1272.12s | Give me my microphone back. 1272.12s - 1298.20s | So please click yes on that or we're all going to be fired. So just say yes, positive feedback. And you know, the what is hacker thing, I can speak to that a little bit, is that it's really important to Jeff that we maintain hacker culture, even though InfoSec has expanded to be so great compared to what it was, you know, back when this was started. 1298.92s - 1327.32s | Now all of our hackers are in InfoSec. We still we're finding things that people want to share things. But we are not an InfoSec conference. We are not about that. And so sometimes what is hacker can be what is just the curious nature of what you found and how and why. And it's not for a corporation. It's not for your job. It's not for anybody. But you and the information and sharing that knowledge so that it is open and free. Now, obviously, we like, you know, 1327.40s - 1328.68s | like what's behind that door. 1333.62s - 1344.66s | I will say that when we were told that are we were supposed to find out, is it hacker? We kind of just walked around for a while going, is it hacker? Is it hacker? Is it hacker? Is this hacker? 1346.66s - 1348.78s | Yeah, we're not tracking those. 1349.78s - 1363.10s | I realized that I said courtesy of DT. Since this is a one on one panel, you may not know much about DEF CON. DT is the dark tangent, or Jeff. He is Nikita's boss. 1364.78s - 1365.90s | Sometimes my boss. 1367.90s - 1368.62s | Sometimes 1369.50s - 1385.26s | So this, I don't know if you can see that it says definitely not a tracker. And it has a tile in it. Because the number one question asked to the contest and events goon is where is grifter? Or have you seen grifter? And so this year, they low


chunk_id: 189_chunk_21
chunk_text:
corporation. It's not for your job. It's not for anybody. But you and the information and sharing that knowledge so that it is open and free. Now, obviously, we like, you know, 1327.40s - 1328.68s | like what's behind that door. 1333.62s - 1344.66s | I will say that when we were told that are we were supposed to find out, is it hacker? We kind of just walked around for a while going, is it hacker? Is it hacker? Is it hacker? Is this hacker? 1346.66s - 1348.78s | Yeah, we're not tracking those. 1349.78s - 1363.10s | I realized that I said courtesy of DT. Since this is a one on one panel, you may not know much about DEF CON. DT is the dark tangent, or Jeff. He is Nikita's boss. 1364.78s - 1365.90s | Sometimes my boss. 1367.90s - 1368.62s | Sometimes 1369.50s - 1385.26s | So this, I don't know if you can see that it says definitely not a tracker. And it has a tile in it. Because the number one question asked to the contest and events goon is where is grifter? Or have you seen grifter? And so this year, they low jacked me. 1385.26s - 1396.22s | So all of them have access to a shared link that will tell them where I am in the facility at any given time, or if I've left my hotel. So hacker tracker. 1397.82s - 1414.06s | He has not given me that link. And I don't know to next year, it will be revised so that he has a boundary zone. So instead, he will have to remain in a certain area or it will go off. And he will get a few warnings, almost like how I trained my dog. 1415.50s - 1417.02s | Dog not to leave the yard. 1418.38s - 1443.58s | It's a good time to do it. He will get a shock. That's my you know what I might just create that next year. We will have a button to shock grifter. Can you shock him? And the more people who who vote to shock you, you'll get a shot. Push the button. How much does the FF get for every time I get shocked? How much do you want to get? Let's talk. You guys were talking right now. I'm serious. I will arrange this. It will


chunk_id: 189_chunk_22
chunk_text:
jacked me. 1385.26s - 1396.22s | So all of them have access to a shared link that will tell them where I am in the facility at any given time, or if I've left my hotel. So hacker tracker. 1397.82s - 1414.06s | He has not given me that link. And I don't know to next year, it will be revised so that he has a boundary zone. So instead, he will have to remain in a certain area or it will go off. And he will get a few warnings, almost like how I trained my dog. 1415.50s - 1417.02s | Dog not to leave the yard. 1418.38s - 1443.58s | It's a good time to do it. He will get a shock. That's my you know what I might just create that next year. We will have a button to shock grifter. Can you shock him? And the more people who who vote to shock you, you'll get a shot. Push the button. How much does the FF get for every time I get shocked? How much do you want to get? Let's talk. You guys were talking right now. I'm serious. I will arrange this. It will have DEF CON weird. 1444.54s - 1465.18s | $5. So you have it has to be done on the catwalk. You have a hacker tracker. Does it know your elevation? Like how can you get caught if it doesn't? That's a good question. Oh, yeah. Does it track his elevation? They can't see me up there. Yes, they can. Right through that window. 1465.18s - 1473.47s | Getting up there. He's not. When you get stuck, you can call hotline. 1475.39s - 1492.67s | He would get stuck too. This is the part of the panel where we like to take questions from the audience. And we have a microphone there in the middle aisle. And you are free to ask any question you want to ask. And we will try to do our best to answer it. 1492.75s - 1505.31s | Seriously, and with respect, he noticed I looked at him. I have tiny chickens for people to ask questions. All right. All right. What does the chicken sound like? Chicken? 1507.07s - 1521.90s | I don't know. I don't want that. Do it. Are they transcribing this live? I don't know. Transcription right now. I was a chicken


chunk_id: 189_chunk_23
chunk_text:
have DEF CON weird. 1444.54s - 1465.18s | $5. So you have it has to be done on the catwalk. You have a hacker tracker. Does it know your elevation? Like how can you get caught if it doesn't? That's a good question. Oh, yeah. Does it track his elevation? They can't see me up there. Yes, they can. Right through that window. 1465.18s - 1473.47s | Getting up there. He's not. When you get stuck, you can call hotline. 1475.39s - 1492.67s | He would get stuck too. This is the part of the panel where we like to take questions from the audience. And we have a microphone there in the middle aisle. And you are free to ask any question you want to ask. And we will try to do our best to answer it. 1492.75s - 1505.31s | Seriously, and with respect, he noticed I looked at him. I have tiny chickens for people to ask questions. All right. All right. What does the chicken sound like? Chicken? 1507.07s - 1521.90s | I don't know. I don't want that. Do it. Are they transcribing this live? I don't know. Transcription right now. I was a chicken sound. What is what do they type when when she does the chicken sound? Do the chicken sound? What did they type? 1522.86s - 1540.06s | Nothing. Do it louder. They didn't get it. They're glaring at us from offstage. I was a moderately sane person about two rubber chickens ago. They're little. You know, after that, um, give me that chicken. Those dang things. 1540.06s - 1568.22s | If anybody doesn't have a question, I found these cute little camp talk conversation question cards, gather around and make new friends with camp talk. And we are often referred to as the part of hacker summer camp, which is, you know, besides Black Hat, DEF CON. So if people don't come up soon, I'm going to start asking them random questions from the from the deck. 1568.22s - 1600.67s | Question. We've got one, which is, we've got to take it. Yes, she should have a chicken. Oh, that's can she have a date? That's that was hacker shit right there. That is that is it. That is it. Next year. We need need to be more specific. Good. Ask questions. Um, I've been I've been gooning for 23 years.


chunk_id: 189_chunk_24
chunk_text:
sound. What is what do they type when when she does the chicken sound? Do the chicken sound? What did they type? 1522.86s - 1540.06s | Nothing. Do it louder. They didn't get it. They're glaring at us from offstage. I was a moderately sane person about two rubber chickens ago. They're little. You know, after that, um, give me that chicken. Those dang things. 1540.06s - 1568.22s | If anybody doesn't have a question, I found these cute little camp talk conversation question cards, gather around and make new friends with camp talk. And we are often referred to as the part of hacker summer camp, which is, you know, besides Black Hat, DEF CON. So if people don't come up soon, I'm going to start asking them random questions from the from the deck. 1568.22s - 1600.67s | Question. We've got one, which is, we've got to take it. Yes, she should have a chicken. Oh, that's can she have a date? That's that was hacker shit right there. That is that is it. That is it. Next year. We need need to be more specific. Good. Ask questions. Um, I've been I've been gooning for 23 years. So it's a long time you what you say 21 years. We've been around a while. How many years? 1601.67s - 1605.67s | Six years. That's all right. And how many years? 1605.67s - 1608.67s | Uh, let's see. I've been working for 10 this year. 1608.67s - 1610.67s | You're gonna retire, aren't you? 1610.67s - 1611.67s | No, no, no. 1611.67s - 1612.67s | Yeah. 1612.67s - 1616.67s | But I've been around since the rib days. 1616.67s - 1617.67s | All right. Nice. 1618.67s - 1639.67s | There's a lot of DEF CON experience up here as also as attendees. And I mentioned something and I'll tell you what what I'm what that means what I said at 10 years if you've been a goon for 10 years you can retire and when you retire you get a gold badge like a gold goon badge and you can come to DEF CON for free for life just like the black badge because you put in your 10 years. 1639.67s - 1659.67s | So I will also add to that. So if you see somebody like Nikita who has 20 years on their patch on their lanyard like


chunk_id: 189_chunk_25
chunk_text:
So it's a long time you what you say 21 years. We've been around a while. How many years? 1601.67s - 1605.67s | Six years. That's all right. And how many years? 1605.67s - 1608.67s | Uh, let's see. I've been working for 10 this year. 1608.67s - 1610.67s | You're gonna retire, aren't you? 1610.67s - 1611.67s | No, no, no. 1611.67s - 1612.67s | Yeah. 1612.67s - 1616.67s | But I've been around since the rib days. 1616.67s - 1617.67s | All right. Nice. 1618.67s - 1639.67s | There's a lot of DEF CON experience up here as also as attendees. And I mentioned something and I'll tell you what what I'm what that means what I said at 10 years if you've been a goon for 10 years you can retire and when you retire you get a gold badge like a gold goon badge and you can come to DEF CON for free for life just like the black badge because you put in your 10 years. 1639.67s - 1659.67s | So I will also add to that. So if you see somebody like Nikita who has 20 years on their patch on their lanyard like they could have stopped doing this a long time ago and just started coming. So when you see any number above 10 they love this right they choose to do this and that doesn't mean that somebody has been doing it six years doesn't love it. 1659.67s - 1674.67s | I'm sure there will be a 10 year patch and a 15 year patch and 25 year patch right like so. So, the people who are are wearing those patches they they love being here so, you know, approach them ask them questions. 1674.67s - 1692.43s | How do you become a goon? 1692.43s - 1693.43s | Okay. 1693.43s - 1697.43s | Would you like a chicken? It's happening right now. You're becoming a goon. 1697.43s - 1700.43s | This is this is how you're chosen. 1700.43s - 1710.43s | So that is a very good question and I will say right now we are in a transition period where we are trying to come up with a formal application process to become a goon. 1710.43s - 1718.43s | Traditionally in the past you would become a goon because you went out and you said I can help with that.


chunk_id: 189_chunk_26
chunk_text:
they could have stopped doing this a long time ago and just started coming. So when you see any number above 10 they love this right they choose to do this and that doesn't mean that somebody has been doing it six years doesn't love it. 1659.67s - 1674.67s | I'm sure there will be a 10 year patch and a 15 year patch and 25 year patch right like so. So, the people who are are wearing those patches they they love being here so, you know, approach them ask them questions. 1674.67s - 1692.43s | How do you become a goon? 1692.43s - 1693.43s | Okay. 1693.43s - 1697.43s | Would you like a chicken? It's happening right now. You're becoming a goon. 1697.43s - 1700.43s | This is this is how you're chosen. 1700.43s - 1710.43s | So that is a very good question and I will say right now we are in a transition period where we are trying to come up with a formal application process to become a goon. 1710.43s - 1718.43s | Traditionally in the past you would become a goon because you went out and you said I can help with that. 1718.43s - 1738.43s | And you and the person was like fuck yeah I need help with that come on over here and you developed trust you developed a relationship with a goon you started working with them they're like hey you're you're helpful can you come back next year and be a goon and that's usually how it happened or it's like I know a guy a friend knows a guy they recommend each other. 1738.43s - 1764.43s | But over the years we have like 600 goons now and we don't want it just to be someone you know to in order to get to be a goon. So if you are an attendee and you don't know a goon, you know, go out make friends with goons we love it, but we also want a process that is a little bit more open to to apply to. 1764.43s - 1784.43s | I will say that 10 years ago I watched a panel about women at DEF CON and CJ the guy who was in charge of the SOC said we just need more women to be SOC goons and we don't know how to get them and


chunk_id: 189_chunk_27
chunk_text:
1718.43s - 1738.43s | And you and the person was like fuck yeah I need help with that come on over here and you developed trust you developed a relationship with a goon you started working with them they're like hey you're you're helpful can you come back next year and be a goon and that's usually how it happened or it's like I know a guy a friend knows a guy they recommend each other. 1738.43s - 1764.43s | But over the years we have like 600 goons now and we don't want it just to be someone you know to in order to get to be a goon. So if you are an attendee and you don't know a goon, you know, go out make friends with goons we love it, but we also want a process that is a little bit more open to to apply to. 1764.43s - 1784.43s | I will say that 10 years ago I watched a panel about women at DEF CON and CJ the guy who was in charge of the SOC said we just need more women to be SOC goons and we don't know how to get them and I just literally stood up and said I do that job and he said email me. 1784.43s - 1785.43s | Yeah. 1785.43s - 1786.43s | 10 years later I'm still here. 1787.43s - 1815.43s | It was last night actually my my best friend was saying to me that she heard from a couple of people that were having a conversation and they said yeah DEF CON is not the same as what it used to be and that they feel like that we've become more diverse and they actually felt safer here because of our diversity and also because of our wonderful programs like hotline and you know we have all of our goons now. 1816.43s - 1819.43s | Oh please answer it. Come on. Do it this time. Who is it? Who is it? 1819.43s - 1820.43s | Who is it? 1820.43s - 1822.43s | It's the lead I got not the lead I wanted. 1823.43s - 1824.43s | Let's go. 1824.43s - 1825.43s | Hello? 1825.43s - 1826.43s | Put them near the speaker. 1826.43s - 1833.43s | You're on stage. You're on stage right now with me. I'm giving a talk. You had the audacity to


chunk_id: 189_chunk_28
chunk_text:
I just literally stood up and said I do that job and he said email me. 1784.43s - 1785.43s | Yeah. 1785.43s - 1786.43s | 10 years later I'm still here. 1787.43s - 1815.43s | It was last night actually my my best friend was saying to me that she heard from a couple of people that were having a conversation and they said yeah DEF CON is not the same as what it used to be and that they feel like that we've become more diverse and they actually felt safer here because of our diversity and also because of our wonderful programs like hotline and you know we have all of our goons now. 1816.43s - 1819.43s | Oh please answer it. Come on. Do it this time. Who is it? Who is it? 1819.43s - 1820.43s | Who is it? 1820.43s - 1822.43s | It's the lead I got not the lead I wanted. 1823.43s - 1824.43s | Let's go. 1824.43s - 1825.43s | Hello? 1825.43s - 1826.43s | Put them near the speaker. 1826.43s - 1833.43s | You're on stage. You're on stage right now with me. I'm giving a talk. You had the audacity to call me. 1836.43s - 1837.43s | Make them say hi. 1837.43s - 1838.43s | What do you want to say to the audience? 1839.43s - 1841.43s | See if I put you on speaker. Hold on. 1841.43s - 1842.43s | Say it loud. Okay. 1842.43s - 1843.43s | Go ahead. 1843.43s - 1855.32s | Hello audience. I want to help rectify the situation that is people modifying the lighting situation inside of the entire hall. 1856.32s - 1857.32s | Boring. 1857.32s - 1862.32s | You have to put me on blast for that. I'll deal with that when I'm off stage. 1863.32s - 1866.32s | Bye now. Bye. No, they're boring. Hang on right now. They're boring. 1868.32s - 1871.32s | Boring. No, you're boring. You're boring. Goodbye. You're cut off. 1872.32s - 1873.32s | That's another question. 1873.32s - 1875.32s | As I was talking to him, someone else was calling me. 1877.32s - 1879.70s | What was I saying? 1879.70s - 1880.70s | I have no idea. 1881.70s - 1883.70s | This is what peer pressure will get to you. 1885.70s - 1886.70s | Diversity at DefCon. 1886.70s - 1887.70s | You said a best friend. 1888.70s -


chunk_id: 189_chunk_29
chunk_text:
call me. 1836.43s - 1837.43s | Make them say hi. 1837.43s - 1838.43s | What do you want to say to the audience? 1839.43s - 1841.43s | See if I put you on speaker. Hold on. 1841.43s - 1842.43s | Say it loud. Okay. 1842.43s - 1843.43s | Go ahead. 1843.43s - 1855.32s | Hello audience. I want to help rectify the situation that is people modifying the lighting situation inside of the entire hall. 1856.32s - 1857.32s | Boring. 1857.32s - 1862.32s | You have to put me on blast for that. I'll deal with that when I'm off stage. 1863.32s - 1866.32s | Bye now. Bye. No, they're boring. Hang on right now. They're boring. 1868.32s - 1871.32s | Boring. No, you're boring. You're boring. Goodbye. You're cut off. 1872.32s - 1873.32s | That's another question. 1873.32s - 1875.32s | As I was talking to him, someone else was calling me. 1877.32s - 1879.70s | What was I saying? 1879.70s - 1880.70s | I have no idea. 1881.70s - 1883.70s | This is what peer pressure will get to you. 1885.70s - 1886.70s | Diversity at DefCon. 1886.70s - 1887.70s | You said a best friend. 1888.70s - 1891.70s | We used to all wear different colored shirts depending on what we did. 1891.70s - 1893.70s | Info booth would have a green shirt. 1894.70s - 1896.70s | Sock would have a red shirt. 1896.70s - 1897.70s | Speaker ops would blue. 1897.70s - 1899.70s | We used to color code what we did. 1901.70s - 1903.70s | The rest of the goons blended in. 1904.70s - 1909.70s | It felt like people didn't see the diversity of our real goon stuff, which is absolutely amazing. 1909.70s - 1912.70s | I've never really experienced that anywhere else. 1913.70s - 1914.70s | Any other con even. 1917.70s - 1920.70s | That guy has a question, so I'm going to stop talking. 1936.09s - 1937.09s | Really quick before she answers. 1937.09s - 1938.09s | They're really light. 1938.09s - 1940.09s | You just pick them up and carry them. 1940.09s - 1941.09s | No. 1942.09s - 1943.09s | I knew it. 1946.09s - 1947.09s | Come at me, front row. 1947.09s - 1948.09s | I'm ready. 1948.09s - 1949.09s | Would you like your chicken? 1950.09s - 1952.09s | I made sure that you can have multiple colors. 1952.09s


chunk_id: 189_chunk_30
chunk_text:
1891.70s | We used to all wear different colored shirts depending on what we did. 1891.70s - 1893.70s | Info booth would have a green shirt. 1894.70s - 1896.70s | Sock would have a red shirt. 1896.70s - 1897.70s | Speaker ops would blue. 1897.70s - 1899.70s | We used to color code what we did. 1901.70s - 1903.70s | The rest of the goons blended in. 1904.70s - 1909.70s | It felt like people didn't see the diversity of our real goon stuff, which is absolutely amazing. 1909.70s - 1912.70s | I've never really experienced that anywhere else. 1913.70s - 1914.70s | Any other con even. 1917.70s - 1920.70s | That guy has a question, so I'm going to stop talking. 1936.09s - 1937.09s | Really quick before she answers. 1937.09s - 1938.09s | They're really light. 1938.09s - 1940.09s | You just pick them up and carry them. 1940.09s - 1941.09s | No. 1942.09s - 1943.09s | I knew it. 1946.09s - 1947.09s | Come at me, front row. 1947.09s - 1948.09s | I'm ready. 1948.09s - 1949.09s | Would you like your chicken? 1950.09s - 1952.09s | I made sure that you can have multiple colors. 1952.09s - 1953.09s | In case you don't want pink. 1957.09s - 1958.09s | Put my psychology hat back on. 1959.09s - 1964.09s | There's some research that suggests that we tend to lose girls in middle school. 1965.09s - 1970.09s | They may be brilliant at math and sciences in elementary school. 1970.09s - 1972.09s | But in middle school, they're told girls don't do that. 1973.09s - 1989.09s | So my priority has always been going into the middle schools and teaching soldering or coding or making fun projects and trying to get the girls involved at that point. 1989.09s - 1992.09s | I know there's a lot of work being done in that space. 1992.09s - 2005.09s | So even if you talk to your local high schools and middle schools, you might find that there's already a girls program for STEM where you could come in and talk to them about what it is you do and maybe lead them through a cool project. 2006.09s - 2008.09s | Like I said, soldering and coding. 2009.09s - 2018.09s | We made little necklaces that have little space invaders on them when I did one of my projects with


chunk_id: 189_chunk_31
chunk_text:
- 1953.09s | In case you don't want pink. 1957.09s - 1958.09s | Put my psychology hat back on. 1959.09s - 1964.09s | There's some research that suggests that we tend to lose girls in middle school. 1965.09s - 1970.09s | They may be brilliant at math and sciences in elementary school. 1970.09s - 1972.09s | But in middle school, they're told girls don't do that. 1973.09s - 1989.09s | So my priority has always been going into the middle schools and teaching soldering or coding or making fun projects and trying to get the girls involved at that point. 1989.09s - 1992.09s | I know there's a lot of work being done in that space. 1992.09s - 2005.09s | So even if you talk to your local high schools and middle schools, you might find that there's already a girls program for STEM where you could come in and talk to them about what it is you do and maybe lead them through a cool project. 2006.09s - 2008.09s | Like I said, soldering and coding. 2009.09s - 2018.09s | We made little necklaces that have little space invaders on them when I did one of my projects with the middle schoolers. 2018.09s - 2024.09s | So they're excited and ready to do the work, but we really have to keep them going. 2025.09s - 2034.09s | Yeah, I think I know like for my daughter, there's this like perception that you can't be like a girly girl, but also be into tech, which just isn't true at all. 2034.09s - 2039.09s | And she started to feel some of that pressure from her peers, like where they were like, oh, like you do this, you do that. 2039.09s - 2041.09s | And she's like to her, it was just completely normal. 2042.09s - 2051.09s | Grew up in a house around it all the time, is a hardcore gamer, like just in her brain, none of this is not normal to just do all the time. 2051.09s - 2057.09s | But then from her own friends at that same age that you were talking about, and she is a very girly girl. 2057.09s - 2062.09s | But then was like, oh, well, like her friends would be like, oh, where did you get this like makeup organizer? 2062.09s - 2064.09s | And she's like, I 3D printed it,


chunk_id: 189_chunk_32
chunk_text:
the middle schoolers. 2018.09s - 2024.09s | So they're excited and ready to do the work, but we really have to keep them going. 2025.09s - 2034.09s | Yeah, I think I know like for my daughter, there's this like perception that you can't be like a girly girl, but also be into tech, which just isn't true at all. 2034.09s - 2039.09s | And she started to feel some of that pressure from her peers, like where they were like, oh, like you do this, you do that. 2039.09s - 2041.09s | And she's like to her, it was just completely normal. 2042.09s - 2051.09s | Grew up in a house around it all the time, is a hardcore gamer, like just in her brain, none of this is not normal to just do all the time. 2051.09s - 2057.09s | But then from her own friends at that same age that you were talking about, and she is a very girly girl. 2057.09s - 2062.09s | But then was like, oh, well, like her friends would be like, oh, where did you get this like makeup organizer? 2062.09s - 2064.09s | And she's like, I 3D printed it, right? 2064.09s - 2066.09s | Like, or where did you get whatever? 2066.09s - 2068.09s | And they're like, you 3D printed it. 2068.09s - 2070.09s | And she's like, oh, yeah, you can just make it yourself. 2070.09s - 2072.09s | Look at all these cool designs, we can make this, we can make this. 2072.09s - 2076.09s | And they're like, oh, wait, maybe I judged this too quickly. 2076.09s - 2080.09s | Yeah, I remember when I was in high school, and I was very good at math. 2080.09s - 2082.09s | And then I went into college. 2082.09s - 2092.09s | Throughout that whole period, I felt like I had to be a tomboy because that was what if I wanted to be able to enjoy video games and technology, I had to be a tomboy. 2092.09s - 2094.09s | And finally, I gave up on that. 2094.09s - 2096.09s | And I said, screw it, like skirts and dresses. 2096.09s - 2108.09s | So find those ways in which you can bring technology and games and those kinds of things into their space. 2108.09s - 2115.09s | Yeah, and you have to you have to


chunk_id: 189_chunk_33
chunk_text:
right? 2064.09s - 2066.09s | Like, or where did you get whatever? 2066.09s - 2068.09s | And they're like, you 3D printed it. 2068.09s - 2070.09s | And she's like, oh, yeah, you can just make it yourself. 2070.09s - 2072.09s | Look at all these cool designs, we can make this, we can make this. 2072.09s - 2076.09s | And they're like, oh, wait, maybe I judged this too quickly. 2076.09s - 2080.09s | Yeah, I remember when I was in high school, and I was very good at math. 2080.09s - 2082.09s | And then I went into college. 2082.09s - 2092.09s | Throughout that whole period, I felt like I had to be a tomboy because that was what if I wanted to be able to enjoy video games and technology, I had to be a tomboy. 2092.09s - 2094.09s | And finally, I gave up on that. 2094.09s - 2096.09s | And I said, screw it, like skirts and dresses. 2096.09s - 2108.09s | So find those ways in which you can bring technology and games and those kinds of things into their space. 2108.09s - 2115.09s | Yeah, and you have to you have to meet them on their level to you have to say things like, wow, you really got a lot of drip today. 2116.09s - 2118.09s | I'm really impressed by your riz. 2118.09s - 2122.09s | And no cap, no cap, for real, for real. 2122.09s - 2127.09s | But Skibidi Toilet, Skibidi, Skibidi Ohio, Skibidi Riz. 2127.09s - 2129.09s | Facts, no printer. 2129.09s - 2134.09s | Whoever has to type this, I feel so sorry. 2134.09s - 2135.09s | That's right. 2135.09s - 2136.09s | Oh, that's amazing. 2136.09s - 2140.09s | Yeah, it's just very mid, you know. 2140.09s - 2142.09s | Ask us a camp question. 2142.09s - 2143.09s | Okay. 2143.09s - 2144.09s | Oh, there's a question. 2144.09s - 2145.09s | Oh, okay. 2145.09s - 2146.09s | It's a regular question. 2146.09s - 2147.09s | Sorry. 2149.09s - 2150.09s | I pickles. 2150.09s - 2151.09s | Love it. 2151.09s - 2154.36s | Welcome. 2154.36s - 2155.36s | Well, 2189.58s - 2190.58s | we'll help you. 2190.58s - 2193.58s | So I'm here specifically for one thing. 2193.58s - 2195.58s | I didn't tell my story. 2197.58s - 2201.58s | My story, because I'd like to


chunk_id: 189_chunk_34
chunk_text:
meet them on their level to you have to say things like, wow, you really got a lot of drip today. 2116.09s - 2118.09s | I'm really impressed by your riz. 2118.09s - 2122.09s | And no cap, no cap, for real, for real. 2122.09s - 2127.09s | But Skibidi Toilet, Skibidi, Skibidi Ohio, Skibidi Riz. 2127.09s - 2129.09s | Facts, no printer. 2129.09s - 2134.09s | Whoever has to type this, I feel so sorry. 2134.09s - 2135.09s | That's right. 2135.09s - 2136.09s | Oh, that's amazing. 2136.09s - 2140.09s | Yeah, it's just very mid, you know. 2140.09s - 2142.09s | Ask us a camp question. 2142.09s - 2143.09s | Okay. 2143.09s - 2144.09s | Oh, there's a question. 2144.09s - 2145.09s | Oh, okay. 2145.09s - 2146.09s | It's a regular question. 2146.09s - 2147.09s | Sorry. 2149.09s - 2150.09s | I pickles. 2150.09s - 2151.09s | Love it. 2151.09s - 2154.36s | Welcome. 2154.36s - 2155.36s | Well, 2189.58s - 2190.58s | we'll help you. 2190.58s - 2193.58s | So I'm here specifically for one thing. 2193.58s - 2195.58s | I didn't tell my story. 2197.58s - 2201.58s | My story, because I'd like to see today in case I have to stop. 2202.58s - 2203.58s | Because 2206.58s - 2207.58s | so 2215.58s - 2217.58s | I have my questions. 2218.58s - 2221.98s | Let me just say 2222.98s - 2223.98s | my stocking story. 2223.98s - 2225.98s | So if I'm being struck, I'm being hacked. 2225.98s - 2227.98s | And then I'm being struck, I'm being hacked. 2227.98s - 2228.98s | And that's just how it goes. 2228.98s - 2229.98s | It's not how it is. 2229.98s - 2232.98s | But we're GPS tracking on multiple vehicles. 2232.98s - 2234.98s | But we're bugging on vehicles. 2234.98s - 2236.98s | I can literally be hurting a child out of my fart. 2238.98s - 2240.98s | Computer hacking, intelligent hacking. 2240.98s - 2243.98s | And we can never stop it. 2243.98s - 2246.98s | So we call this, it has my name spelled, we're gonna stop it. 2246.98s - 2247.98s | We're gonna stop it. 2247.98s - 2248.98s | What is the word for stopping? 2248.98s - 2249.98s | It's a food stocking. 2249.98s - 2251.98s | We've got a lot of different food stockings. 2251.98s - 2253.98s | I'm writing a podcast.


chunk_id: 189_chunk_35
chunk_text:
see today in case I have to stop. 2202.58s - 2203.58s | Because 2206.58s - 2207.58s | so 2215.58s - 2217.58s | I have my questions. 2218.58s - 2221.98s | Let me just say 2222.98s - 2223.98s | my stocking story. 2223.98s - 2225.98s | So if I'm being struck, I'm being hacked. 2225.98s - 2227.98s | And then I'm being struck, I'm being hacked. 2227.98s - 2228.98s | And that's just how it goes. 2228.98s - 2229.98s | It's not how it is. 2229.98s - 2232.98s | But we're GPS tracking on multiple vehicles. 2232.98s - 2234.98s | But we're bugging on vehicles. 2234.98s - 2236.98s | I can literally be hurting a child out of my fart. 2238.98s - 2240.98s | Computer hacking, intelligent hacking. 2240.98s - 2243.98s | And we can never stop it. 2243.98s - 2246.98s | So we call this, it has my name spelled, we're gonna stop it. 2246.98s - 2247.98s | We're gonna stop it. 2247.98s - 2248.98s | What is the word for stopping? 2248.98s - 2249.98s | It's a food stocking. 2249.98s - 2251.98s | We've got a lot of different food stockings. 2251.98s - 2253.98s | I'm writing a podcast. 2253.98s - 2255.98s | I'm writing whatever it takes. 2255.98s - 2256.98s | But I'm writing a podcast. 2256.98s - 2258.98s | So if you find me here, 2258.98s - 2259.98s | just call on me. 2260.98s - 2261.98s | Step on me. 2261.98s - 2262.98s | Get this person out of my life. 2262.98s - 2264.98s | He's been in my life for 20 years. 2264.98s - 2265.98s | He's an actual employer. 2265.98s - 2267.98s | I'm not going to introduce him. 2267.98s - 2272.98s | Is there anyone here who would? 2272.98s - 2278.94s | We have several different villages. 2278.94s - 2283.94s | You could try from crypto privacy to the social engineering village. 2283.94s - 2287.94s | We should definitely maybe connect you with someone after the talk. 2287.94s - 2291.94s | It sounds like this is a little bit more detailed than a question. 2291.94s - 2294.94s | And happy to work with you afterwards. 2309.27s - 2310.27s | Noted. 2310.27s - 2311.27s | Okay. 2311.27s - 2312.27s | All right. 2312.27s - 2313.27s | Thank you. 2313.27s - 2315.27s | Thank you. 2315.27s - 2319.76s | Okay. 2319.76s - 2320.76s | All right.


chunk_id: 189_chunk_36
chunk_text:
2253.98s - 2255.98s | I'm writing whatever it takes. 2255.98s - 2256.98s | But I'm writing a podcast. 2256.98s - 2258.98s | So if you find me here, 2258.98s - 2259.98s | just call on me. 2260.98s - 2261.98s | Step on me. 2261.98s - 2262.98s | Get this person out of my life. 2262.98s - 2264.98s | He's been in my life for 20 years. 2264.98s - 2265.98s | He's an actual employer. 2265.98s - 2267.98s | I'm not going to introduce him. 2267.98s - 2272.98s | Is there anyone here who would? 2272.98s - 2278.94s | We have several different villages. 2278.94s - 2283.94s | You could try from crypto privacy to the social engineering village. 2283.94s - 2287.94s | We should definitely maybe connect you with someone after the talk. 2287.94s - 2291.94s | It sounds like this is a little bit more detailed than a question. 2291.94s - 2294.94s | And happy to work with you afterwards. 2309.27s - 2310.27s | Noted. 2310.27s - 2311.27s | Okay. 2311.27s - 2312.27s | All right. 2312.27s - 2313.27s | Thank you. 2313.27s - 2315.27s | Thank you. 2315.27s - 2319.76s | Okay. 2319.76s - 2320.76s | All right. 2320.76s - 2321.76s | Cool. 2321.76s - 2322.76s | Thank you. 2323.76s - 2324.76s | Thanks. 2324.76s - 2327.84s | What you got? 2327.84s - 2328.84s | Give me a camp question. 2328.84s - 2329.84s | Let's go. 2331.84s - 2339.84s | What is the funniest or most unusual nickname you've ever heard for a camp counselor? 2340.84s - 2341.84s | What would your nickname? 2341.84s - 2342.84s | Oh, my gosh. 2342.84s - 2344.84s | I can tell you, but I'd have to out myself. 2345.84s - 2346.84s | Do it. 2349.15s - 2351.15s | This is I'm going to regret this so much, though. 2352.15s - 2353.15s | You know what? 2353.15s - 2355.15s | This is this for my boy. 2355.15s - 2356.15s | Okay. 2356.15s - 2360.15s | So when I first started, when you started as a goon back in the day, in the early single 2360.15s - 2363.15s | digit DEF CON days, everybody started as a sock goon. 2363.15s - 2367.15s | You had to start in security, put your time in, and then you'd go on to something else. 2367.15s - 2369.15s | So I started out as a security goon. 2369.15s


chunk_id: 189_chunk_37
chunk_text:
2320.76s - 2321.76s | Cool. 2321.76s - 2322.76s | Thank you. 2323.76s - 2324.76s | Thanks. 2324.76s - 2327.84s | What you got? 2327.84s - 2328.84s | Give me a camp question. 2328.84s - 2329.84s | Let's go. 2331.84s - 2339.84s | What is the funniest or most unusual nickname you've ever heard for a camp counselor? 2340.84s - 2341.84s | What would your nickname? 2341.84s - 2342.84s | Oh, my gosh. 2342.84s - 2344.84s | I can tell you, but I'd have to out myself. 2345.84s - 2346.84s | Do it. 2349.15s - 2351.15s | This is I'm going to regret this so much, though. 2352.15s - 2353.15s | You know what? 2353.15s - 2355.15s | This is this for my boy. 2355.15s - 2356.15s | Okay. 2356.15s - 2360.15s | So when I first started, when you started as a goon back in the day, in the early single 2360.15s - 2363.15s | digit DEF CON days, everybody started as a sock goon. 2363.15s - 2367.15s | You had to start in security, put your time in, and then you'd go on to something else. 2367.15s - 2369.15s | So I started out as a security goon. 2369.15s - 2374.15s | And then Russ was like, hey, I'll bring you into the vendors as soon as you put your time 2374.15s - 2375.15s | in security. 2375.15s - 2377.15s | And I was like, yeah, that sounds great. 2377.15s - 2379.15s | I love hanging out in the vendor area. 2379.15s - 2381.15s | I was a vendor at the time. 2381.15s - 2383.15s | Oh, I'm going to say this in public. 2383.15s - 2384.15s | And then I met I met Romer. 2384.15s - 2386.15s | So our good friend Romer. 2386.15s - 2392.15s | So so Russ introduces me to Romer and he says, hey, Romer, this is Grifter. 2392.15s - 2395.15s | And at the time I was younger and handsome. 2395.15s - 2399.15s | And so so Romer said no. 2400.15s - 2403.15s | And he was like, you're too good looking to have a cool handle. 2403.15s - 2406.15s | Your new handle is Nutsack. 2407.15s - 2413.15s | And Romer and Russ called me Nutsack and have continued to do so for 20 plus years. 2413.15s - 2414.15s | And yeah. 2414.15s - 2418.15s | So what's the nickname for the


chunk_id: 189_chunk_38
chunk_text:
- 2374.15s | And then Russ was like, hey, I'll bring you into the vendors as soon as you put your time 2374.15s - 2375.15s | in security. 2375.15s - 2377.15s | And I was like, yeah, that sounds great. 2377.15s - 2379.15s | I love hanging out in the vendor area. 2379.15s - 2381.15s | I was a vendor at the time. 2381.15s - 2383.15s | Oh, I'm going to say this in public. 2383.15s - 2384.15s | And then I met I met Romer. 2384.15s - 2386.15s | So our good friend Romer. 2386.15s - 2392.15s | So so Russ introduces me to Romer and he says, hey, Romer, this is Grifter. 2392.15s - 2395.15s | And at the time I was younger and handsome. 2395.15s - 2399.15s | And so so Romer said no. 2400.15s - 2403.15s | And he was like, you're too good looking to have a cool handle. 2403.15s - 2406.15s | Your new handle is Nutsack. 2407.15s - 2413.15s | And Romer and Russ called me Nutsack and have continued to do so for 20 plus years. 2413.15s - 2414.15s | And yeah. 2414.15s - 2418.15s | So what's the nickname for the camp counselor? 2418.15s - 2419.15s | Nutsack. 2419.15s - 2420.15s | Nutsack. 2420.15s - 2421.15s | Nutsack. 2423.15s - 2424.15s | I have a funny story. 2424.15s - 2425.15s | You're welcome. 2425.15s - 2426.15s | You ask the question. 2426.15s - 2428.15s | But there was someone lining up for a question. 2428.15s - 2436.90s | Sure. 2439.90s - 2440.90s | OK. 2440.90s - 2441.90s | That happens a lot. 2442.90s - 2450.40s | It's happening. 2450.40s - 2451.40s | Oh, sorry. 2451.40s - 2455.16s | What the hell is that? 2455.16s - 2456.16s | I don't know what. 2456.16s - 2477.42s | Happy to to direct you to our frequently asked questions on the CFP page where we go through what we're looking for for talks. 2477.42s - 2479.42s | It seems like Grifter wants to say a few words. 2479.42s - 2480.42s | So I have. 2480.42s - 2483.42s | So so I have some advice on that as well. 2483.42s - 2484.42s | You want chicken? 2485.42s - 2486.42s | The thing about like so. 2486.42s - 2492.42s | So I've served on multiple review boards for DEF CON, for Black Hat, other conferences as well.


chunk_id: 189_chunk_39
chunk_text:
camp counselor? 2418.15s - 2419.15s | Nutsack. 2419.15s - 2420.15s | Nutsack. 2420.15s - 2421.15s | Nutsack. 2423.15s - 2424.15s | I have a funny story. 2424.15s - 2425.15s | You're welcome. 2425.15s - 2426.15s | You ask the question. 2426.15s - 2428.15s | But there was someone lining up for a question. 2428.15s - 2436.90s | Sure. 2439.90s - 2440.90s | OK. 2440.90s - 2441.90s | That happens a lot. 2442.90s - 2450.40s | It's happening. 2450.40s - 2451.40s | Oh, sorry. 2451.40s - 2455.16s | What the hell is that? 2455.16s - 2456.16s | I don't know what. 2456.16s - 2477.42s | Happy to to direct you to our frequently asked questions on the CFP page where we go through what we're looking for for talks. 2477.42s - 2479.42s | It seems like Grifter wants to say a few words. 2479.42s - 2480.42s | So I have. 2480.42s - 2483.42s | So so I have some advice on that as well. 2483.42s - 2484.42s | You want chicken? 2485.42s - 2486.42s | The thing about like so. 2486.42s - 2492.42s | So I've served on multiple review boards for DEF CON, for Black Hat, other conferences as well. 2492.42s - 2500.42s | And what is a pattern that I see is that people will do incredible research like they do this incredible research. 2500.42s - 2507.42s | And then when they go to fill out the CFP submission, they will spend basically the bare minimum amount of time filling it out. 2507.42s - 2510.42s | Like you've spent a year doing the research. 2510.42s - 2517.42s | Put the time in to explain what it is you did and why it's important and why other people should hear about it. 2517.42s - 2525.42s | Often, you know, the abstract will be confusing or the bio of the individual will be longer than the abstract. 2525.42s - 2527.42s | The outline is not detailed. 2527.42s - 2529.42s | When we say detailed, we mean detailed. 2529.42s - 2532.42s | Show us what you're going to talk about at each stage of the talk. 2532.42s - 2537.42s | If you have a slide for something, I want to see a breakdown of what's going to be on that slide. 2537.42s - 2538.42s | What are you going to talk about? 2538.42s - 2539.42s | So really, that's it. 2539.42s -


chunk_id: 189_chunk_40
chunk_text:
2492.42s - 2500.42s | And what is a pattern that I see is that people will do incredible research like they do this incredible research. 2500.42s - 2507.42s | And then when they go to fill out the CFP submission, they will spend basically the bare minimum amount of time filling it out. 2507.42s - 2510.42s | Like you've spent a year doing the research. 2510.42s - 2517.42s | Put the time in to explain what it is you did and why it's important and why other people should hear about it. 2517.42s - 2525.42s | Often, you know, the abstract will be confusing or the bio of the individual will be longer than the abstract. 2525.42s - 2527.42s | The outline is not detailed. 2527.42s - 2529.42s | When we say detailed, we mean detailed. 2529.42s - 2532.42s | Show us what you're going to talk about at each stage of the talk. 2532.42s - 2537.42s | If you have a slide for something, I want to see a breakdown of what's going to be on that slide. 2537.42s - 2538.42s | What are you going to talk about? 2538.42s - 2539.42s | So really, that's it. 2539.42s - 2549.42s | If you put the time in to do all that research, take a fraction of that time to fill out the CFP and give us an idea of why it should come to the main stage. 2549.42s - 2554.68s | Okay. 2554.68s - 2555.68s | Grifter. 2555.68s - 2557.68s | Actually, you know what? 2557.68s - 2560.68s | You've gotten lots of questions. 2560.68s - 2562.68s | You. 2562.68s - 2564.68s | Do you have a pet? 2564.68s - 2565.68s | What kind? 2565.68s - 2567.68s | What's its name? 2567.68s - 2569.68s | Its name is Grifter. 2569.68s - 2572.99s | What's the funniest trick your pet can do? 2572.99s - 2576.99s | This is a hard question because I don't have a pet other than Grifter. 2576.99s - 2577.99s | Where did you grow up? 2577.99s - 2580.99s | What was the street address of where you grew up? 2580.99s - 2582.99s | Your mother's maiden name? 2582.99s - 2584.99s | You didn't ask me my social. 2584.99s - 2587.99s | The last four of your social. 2587.99s - 2590.99s | I think we have another question. 2590.99s - 2591.99s | Probably our last one. 2591.99s


chunk_id: 189_chunk_41
chunk_text:
2549.42s | If you put the time in to do all that research, take a fraction of that time to fill out the CFP and give us an idea of why it should come to the main stage. 2549.42s - 2554.68s | Okay. 2554.68s - 2555.68s | Grifter. 2555.68s - 2557.68s | Actually, you know what? 2557.68s - 2560.68s | You've gotten lots of questions. 2560.68s - 2562.68s | You. 2562.68s - 2564.68s | Do you have a pet? 2564.68s - 2565.68s | What kind? 2565.68s - 2567.68s | What's its name? 2567.68s - 2569.68s | Its name is Grifter. 2569.68s - 2572.99s | What's the funniest trick your pet can do? 2572.99s - 2576.99s | This is a hard question because I don't have a pet other than Grifter. 2576.99s - 2577.99s | Where did you grow up? 2577.99s - 2580.99s | What was the street address of where you grew up? 2580.99s - 2582.99s | Your mother's maiden name? 2582.99s - 2584.99s | You didn't ask me my social. 2584.99s - 2587.99s | The last four of your social. 2587.99s - 2590.99s | I think we have another question. 2590.99s - 2591.99s | Probably our last one. 2591.99s - 2592.99s | Yeah. 2592.99s - 2614.86s | I can't answer that in a minute. 2614.86s - 2616.86s | Yeah, I definitely can't answer that either. 2616.86s - 2619.86s | They're all long stories. 2619.86s - 2621.86s | I like T-Rex fights. 2621.86s - 2622.86s | T-Rex fights are fun. 2622.86s - 2623.86s | T-Rex fights are good. 2623.86s - 2624.86s | I've seen a T-Rex fight before. 2624.86s - 2625.86s | Naked guy. 2625.86s - 2626.86s | Naked guy. 2626.86s - 2627.86s | Naked guy was super weird. 2627.86s - 2632.86s | I found out recently how he became Naked Guy, so we should talk about that. 2632.86s - 2633.86s | Yeah, I did too. 2633.86s - 2634.86s | Trevor Forget. 2634.86s - 2636.86s | Trevor Forget. 2636.86s - 2638.86s | The cockroach that we had a whole thing about. 2638.86s - 2642.86s | So the things we can't talk about, like to set a bar. 2642.86s - 2647.86s | At DEFCON 11 on the scavenger hunt list, it said streak through Grifter's talk. 2647.86s - 2649.86s | And there were three. 2649.86s - 2653.86s | And one of them hugged me on stage. 2653.86s - 2655.86s | And


chunk_id: 189_chunk_42
chunk_text:
- 2592.99s | Yeah. 2592.99s - 2614.86s | I can't answer that in a minute. 2614.86s - 2616.86s | Yeah, I definitely can't answer that either. 2616.86s - 2619.86s | They're all long stories. 2619.86s - 2621.86s | I like T-Rex fights. 2621.86s - 2622.86s | T-Rex fights are fun. 2622.86s - 2623.86s | T-Rex fights are good. 2623.86s - 2624.86s | I've seen a T-Rex fight before. 2624.86s - 2625.86s | Naked guy. 2625.86s - 2626.86s | Naked guy. 2626.86s - 2627.86s | Naked guy was super weird. 2627.86s - 2632.86s | I found out recently how he became Naked Guy, so we should talk about that. 2632.86s - 2633.86s | Yeah, I did too. 2633.86s - 2634.86s | Trevor Forget. 2634.86s - 2636.86s | Trevor Forget. 2636.86s - 2638.86s | The cockroach that we had a whole thing about. 2638.86s - 2642.86s | So the things we can't talk about, like to set a bar. 2642.86s - 2647.86s | At DEFCON 11 on the scavenger hunt list, it said streak through Grifter's talk. 2647.86s - 2649.86s | And there were three. 2649.86s - 2653.86s | And one of them hugged me on stage. 2653.86s - 2655.86s | And I'm willing to talk about that. 2655.86s - 2658.86s | So you can imagine what we're going to talk about after this. 2658.86s - 2660.86s | I really enjoyed the- 2660.86s - 2661.86s | I think we'll need the couch. 2661.86s - 2666.86s | He'll need to lay down and talk about his feelings. 2666.86s - 2671.86s | I enjoyed that the chairs that we had with the beans in it, 2671.86s - 2673.86s | that they had to figure out how to get them out. 2673.86s - 2677.86s | They were like, one of the things you have to do for this contest 2677.86s - 2681.86s | is figure out how to get the chairs out without anybody stopping you. 2681.86s - 2682.86s | Yeah. 2682.86s - 2683.86s | All right. 2683.86s - 2685.86s | Well, that is it for us. 2685.86s - 2687.86s | Oh, there's a question. 2687.86s - 2696.71s | That was amazing. 2696.71s - 2697.71s | Oh, you know what? 2697.71s - 2698.71s | So good. 2698.71s - 2699.71s | Seven seconds. 2699.71s - 2701.71s | I was wrapping it up, sir. 2701.71s - 2702.71s | So good. 2702.71s - 2703.71s | Thank you. 2703.71s


chunk_id: 189_chunk_43
chunk_text:
I'm willing to talk about that. 2655.86s - 2658.86s | So you can imagine what we're going to talk about after this. 2658.86s - 2660.86s | I really enjoyed the- 2660.86s - 2661.86s | I think we'll need the couch. 2661.86s - 2666.86s | He'll need to lay down and talk about his feelings. 2666.86s - 2671.86s | I enjoyed that the chairs that we had with the beans in it, 2671.86s - 2673.86s | that they had to figure out how to get them out. 2673.86s - 2677.86s | They were like, one of the things you have to do for this contest 2677.86s - 2681.86s | is figure out how to get the chairs out without anybody stopping you. 2681.86s - 2682.86s | Yeah. 2682.86s - 2683.86s | All right. 2683.86s - 2685.86s | Well, that is it for us. 2685.86s - 2687.86s | Oh, there's a question. 2687.86s - 2696.71s | That was amazing. 2696.71s - 2697.71s | Oh, you know what? 2697.71s - 2698.71s | So good. 2698.71s - 2699.71s | Seven seconds. 2699.71s - 2701.71s | I was wrapping it up, sir. 2701.71s - 2702.71s | So good. 2702.71s - 2703.71s | Thank you. 2703.71s - 2706.34s | Want a chicken? 2706.34s - 2707.34s | Thanks.


chunk_id: 190_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=krIOAKQhsGY", "title": "DEF CON 32 - Encrypted newspaper ads in the 19th century - Elonka Dunin, Klaus Schmeh", "description": "Between 1850 and 1855, the London-based newspaper The Times published over 50 encrypted advertisements apparently intended for the same recipient. As we know today, the ads in that series were meant for the sea captain Richard Collinson, who at the time was on a mission in the Canadian Arctic trying to solve a captivating mystery: What happened to the lost John Franklin expedition? While Collinson never reached his goal, he established a secure worldwide communication system, which was unique for its time.\n\nBefore his departure, Collinson's family was taught how to encrypt brief reports about what was going on at home and to publish these messages as mysterious ads in \u201cThe Times\u201d once a month. The cipher used was a modified version of a system based on a signal-book of the Royal Navy. As the circulation of The Times stretched far beyond the UK, Collinson would have the chance to get his hands on a copy even at the remotest of ports.\n\nOver a century later, the Collinson ads were finally broken in the 1990s. Over the last two years, the lecturers of this talk continued this work, with a goal of decrypting all of the ads and placing them in their appropriate geographic and cultural context.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2655, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 6.24s | This text was transcribed using whisper model: large-v2 Welcome. So, it's a pleasure to be back at DEF CON. It's been a few years. Today, we're 6.24s - 15.24s | going to talk about encrypted ads from the 19th century. And my name is Ilan Kadunin. 15.24s - 24.08s | Hello, and my name is Klaus Schmee. I'm a German computer scientist. I work for a company 24.08s - 33.24s | named Eviden, a European IT security company. I'm also a crypto and crypto history expert. 33.24s - 38.84s | And we have written a couple of books together. Most recently, this one came out in September 38.84s - 49.08s | 2023 from No Starch Press. And if you go down to the east vendor hall, number 29, they may 49.08s - 55.88s | have one copy left. At least, that's what we saw when we checked earlier. So, encrypted 55.88s - 63.22s | newspaper ads. Just kind of


chunk_id: 190_chunk_1
chunk_text:
lecturers of this talk continued this work, with a goal of decrypting all of the ads and placing them in their appropriate geographic and cultural context.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2655, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 6.24s | This text was transcribed using whisper model: large-v2 Welcome. So, it's a pleasure to be back at DEF CON. It's been a few years. Today, we're 6.24s - 15.24s | going to talk about encrypted ads from the 19th century. And my name is Ilan Kadunin. 15.24s - 24.08s | Hello, and my name is Klaus Schmee. I'm a German computer scientist. I work for a company 24.08s - 33.24s | named Eviden, a European IT security company. I'm also a crypto and crypto history expert. 33.24s - 38.84s | And we have written a couple of books together. Most recently, this one came out in September 38.84s - 49.08s | 2023 from No Starch Press. And if you go down to the east vendor hall, number 29, they may 49.08s - 55.88s | have one copy left. At least, that's what we saw when we checked earlier. So, encrypted 55.88s - 63.22s | newspaper ads. Just kind of giving you a general idea. This is something that was very popular 63.22s - 69.52s | in the 19th century. Usually, they were sent back and forth between lovers. Sometimes they 69.52s - 74.92s | were used for business reasons. And there were a couple of books that were written. 74.92s - 82.60s | This is one from 2006 by Gene Palmer. It was the pseudonym for Tony Gaffney. And he 82.60s - 89.76s | lists about 1,000 of these ads. Many of them have been solved. Not all of them. He doesn't 89.76s - 96.56s | provide solutions for all of them. And here's a couple more. You can see. And the one on 96.56s - 102.64s | the right we thought was interesting because it had an encrypted section at the top. And 102.64s - 110.48s | then at the bottom, it said, this will be intelligible if read in connection with my 110.48s - 120.36s | communication published in this column on the 8th instrument this month. So, we went 120.36s - 128.80s | back and we checked. And it gave us no clues. It does look like it's a transposition 128.80s - 136.96s | cipher. But


chunk_id: 190_chunk_2
chunk_text:
giving you a general idea. This is something that was very popular 63.22s - 69.52s | in the 19th century. Usually, they were sent back and forth between lovers. Sometimes they 69.52s - 74.92s | were used for business reasons. And there were a couple of books that were written. 74.92s - 82.60s | This is one from 2006 by Gene Palmer. It was the pseudonym for Tony Gaffney. And he 82.60s - 89.76s | lists about 1,000 of these ads. Many of them have been solved. Not all of them. He doesn't 89.76s - 96.56s | provide solutions for all of them. And here's a couple more. You can see. And the one on 96.56s - 102.64s | the right we thought was interesting because it had an encrypted section at the top. And 102.64s - 110.48s | then at the bottom, it said, this will be intelligible if read in connection with my 110.48s - 120.36s | communication published in this column on the 8th instrument this month. So, we went 120.36s - 128.80s | back and we checked. And it gave us no clues. It does look like it's a transposition 128.80s - 136.96s | cipher. But this one remains unsolved. Here are a couple other interesting ones. This one 136.96s - 149.86s | sort of looks like a Bible code. Also unsolved. And these two clearly related between tissy 149.86s - 159.86s | and jabber. Also unsolved. And here's a colleague of ours, D.J. Mueller. He decided to look 159.86s - 168.14s | in the French newspaper, Le Figaro, and he found thousands of encrypted ads in the French 168.14s - 174.06s | language, at least of the ones he could solve. We actually met him a few weeks ago in 174.06s - 183.10s | Switzerland. And he has this lovely database. He has found so far, looking at the years 183.10s - 195.37s | from 1875 to 1896, 3,700 cipher messages. Only 62% have been broken so far. Here are a 195.37s - 210.86s | couple. And this one was interesting because you can tell if you dig into it, it's a 210.86s - 217.30s | combination of what we call clear text. And then if you look at the numbers in between, it's 217.30s - 223.66s | all five digit numbers. And someone into codes will go, aha, well, that looks like a 223.66s


chunk_id: 190_chunk_3
chunk_text:
this one remains unsolved. Here are a couple other interesting ones. This one 136.96s - 149.86s | sort of looks like a Bible code. Also unsolved. And these two clearly related between tissy 149.86s - 159.86s | and jabber. Also unsolved. And here's a colleague of ours, D.J. Mueller. He decided to look 159.86s - 168.14s | in the French newspaper, Le Figaro, and he found thousands of encrypted ads in the French 168.14s - 174.06s | language, at least of the ones he could solve. We actually met him a few weeks ago in 174.06s - 183.10s | Switzerland. And he has this lovely database. He has found so far, looking at the years 183.10s - 195.37s | from 1875 to 1896, 3,700 cipher messages. Only 62% have been broken so far. Here are a 195.37s - 210.86s | couple. And this one was interesting because you can tell if you dig into it, it's a 210.86s - 217.30s | combination of what we call clear text. And then if you look at the numbers in between, it's 217.30s - 223.66s | all five digit numbers. And someone into codes will go, aha, well, that looks like a 223.66s - 230.58s | code book code. But we haven't found which code book. We've looked at the code books from 230.58s - 236.10s | that time period. There are some in French and some in English. But haven't found 236.10s - 241.54s | anything that works. It's possible that we haven't found the right code book. It's 241.54s - 247.86s | possible that there's some sort of super encryption going on. So, you know, take a five 247.86s - 252.66s | digit code and you add one to it or divide it by two or something like that. But for whatever 252.66s - 262.82s | reason, we haven't found it. Now, this one is a musical mystery. Ce qu'on ne peut se dire ni 262.82s - 269.82s | s'écrire, on peut le chanter. Do mi, do mi, do re, re fa, re fa, re mi, et cetera, et 269.82s - 278.70s | cetera. Vous avez compris? Which in English means that which cannot be said nor written can be 278.70s - 284.42s | sung. And then we put what we think are the notes there and have you have have you 284.42s - 292.66s | understood. So, then we also


chunk_id: 190_chunk_4
chunk_text:
- 230.58s | code book code. But we haven't found which code book. We've looked at the code books from 230.58s - 236.10s | that time period. There are some in French and some in English. But haven't found 236.10s - 241.54s | anything that works. It's possible that we haven't found the right code book. It's 241.54s - 247.86s | possible that there's some sort of super encryption going on. So, you know, take a five 247.86s - 252.66s | digit code and you add one to it or divide it by two or something like that. But for whatever 252.66s - 262.82s | reason, we haven't found it. Now, this one is a musical mystery. Ce qu'on ne peut se dire ni 262.82s - 269.82s | s'écrire, on peut le chanter. Do mi, do mi, do re, re fa, re fa, re mi, et cetera, et 269.82s - 278.70s | cetera. Vous avez compris? Which in English means that which cannot be said nor written can be 278.70s - 284.42s | sung. And then we put what we think are the notes there and have you have have you 284.42s - 292.66s | understood. So, then we also mapped it to a musical staff here. We didn't have any 292.66s - 299.30s | indication of, you know, what the signature was or the duration of the notes. So, we just kind 299.30s - 312.54s | of picked something that seemed to fit. And if sound works, we'll play it for you. Makes it 312.54s - 317.94s | much more clear. I'm going to play it once more so you can kind of map it to the do mi, do mi, 317.94s - 330.74s | do re. So, there's a couple things that could be going on here. One is that it could be related 330.74s - 337.90s | to a language called Solresol, which had been invented in France a little earlier by a Frenchman. 337.90s - 344.70s | It was an artificial language that was based on notes. So, I went and I looked for anyone today 344.70s - 351.18s | that might know Solresol. I went on Discord. You can find everything on Discord. So, I found a 351.18s - 356.14s | Solresol community and I asked them if they could read it, if they could understand it. And they 356.14s - 360.06s | said no.


chunk_id: 190_chunk_5
chunk_text:
mapped it to a musical staff here. We didn't have any 292.66s - 299.30s | indication of, you know, what the signature was or the duration of the notes. So, we just kind 299.30s - 312.54s | of picked something that seemed to fit. And if sound works, we'll play it for you. Makes it 312.54s - 317.94s | much more clear. I'm going to play it once more so you can kind of map it to the do mi, do mi, 317.94s - 330.74s | do re. So, there's a couple things that could be going on here. One is that it could be related 330.74s - 337.90s | to a language called Solresol, which had been invented in France a little earlier by a Frenchman. 337.90s - 344.70s | It was an artificial language that was based on notes. So, I went and I looked for anyone today 344.70s - 351.18s | that might know Solresol. I went on Discord. You can find everything on Discord. So, I found a 351.18s - 356.14s | Solresol community and I asked them if they could read it, if they could understand it. And they 356.14s - 360.06s | said no. And I said, well, if it means anything, it's probably like, I love you, I miss you, why 360.06s - 365.46s | haven't you written to me? And they said no. They still couldn't understand it. So, it's also 365.46s - 372.42s | possible. I have some fans that are into classical music and they said, you know, this sounds like a 372.42s - 379.90s | practice at the beginning of choir. What the choir, the singers will use to kind of get in shape for 379.90s - 388.58s | the choir. So, maybe all this means is see you soon at choir practice. We don't know. There's just a 388.58s - 395.78s | lot of theories on it. So, this one still remains officially unsolved. There are many more encrypted 395.78s - 401.94s | ads. Again, most of them are from the late 19th century. Most are broken. Some are not. And 401.98s - 404.10s | there's still a lot of research being done on it. 406.86s - 414.70s | Okay, let's now look at a series of encrypted newspaper ads from the 19th century. All of these 414.70s - 423.10s | were published in the Times. There were


chunk_id: 190_chunk_6
chunk_text:
And I said, well, if it means anything, it's probably like, I love you, I miss you, why 360.06s - 365.46s | haven't you written to me? And they said no. They still couldn't understand it. So, it's also 365.46s - 372.42s | possible. I have some fans that are into classical music and they said, you know, this sounds like a 372.42s - 379.90s | practice at the beginning of choir. What the choir, the singers will use to kind of get in shape for 379.90s - 388.58s | the choir. So, maybe all this means is see you soon at choir practice. We don't know. There's just a 388.58s - 395.78s | lot of theories on it. So, this one still remains officially unsolved. There are many more encrypted 395.78s - 401.94s | ads. Again, most of them are from the late 19th century. Most are broken. Some are not. And 401.98s - 404.10s | there's still a lot of research being done on it. 406.86s - 414.70s | Okay, let's now look at a series of encrypted newspaper ads from the 19th century. All of these 414.70s - 423.10s | were published in the Times. There were over 50 of these newspaper ads. Here you see one. It was 423.10s - 433.02s | published in 1853. If we have a closer look, this one is the same. We clearly see that it is 433.02s - 443.30s | encrypted. And there's no obvious way to decipher this message. So, it's certainly not clear what it 443.30s - 454.62s | means. Let's now go ahead for 130 years to the year 1980. In 1980, the Times, so the same 454.66s - 461.18s | newspaper, published one of these messages again. Apparently, they didn't realize that there was a 461.18s - 467.74s | whole series of these messages. So, they only found one. And they wondered what it meant. And so, 467.74s - 475.06s | they published it. And they challenged their readers to solve it. But there was no success. So, 475.06s - 482.34s | apparently, none of the Times readers in 1980 was able to break this encryption. The only thing 482.34s - 491.70s | that was found out is that these numbers and letters that are marked here probably referred to latitude 491.70s - 500.02s | and longitude. And it leads to a place in northern Canada.


