# MediaChunks

chunk_id: 149_chunk_27
chunk_text:
mentioned a bunch of pros before right. Better test the full user experience. Longer contacts. 1386.59s - 1392.27s | More safety space to test. And the biggest pro Joanna touched on before is it's iterative and 1392.27s - 1397.37s | multi-turn we can ask these follow up prompts. Ask for even more details and generate even more 1397.39s - 1404.41s | violating content than we ever could have with these single shot adversarial prompts. The cons 1404.41s - 1410.41s | are the opposite to single turn. So it's a lot harder to automate. You no longer have these large 1410.41s - 1414.85s | static data sets that you can just plug in and test against all your models because each model is 1414.85s - 1419.25s | going to respond differently in a conversation. So you're going to need a lot more of a dynamic 1419.25s - 1423.55s | testing infrastructure. There's also just not a lot of research in this space. So you're going to be 1423.57s - 1430.87s | flying in blind for a bit and building your building blocks here. Which is why we as a red team 1430.87s - 1436.31s | like to focus a lot more on automating these multi-turn prompt level attacks than any other 1436.31s - 1440.95s | research space right now. So let's drive this home with an example. Because examples are the 1440.95s - 1446.53s | most fun. Take this single turn prompt. It has a lot of the prompt level attacks that Joanna 1446.53s - 1451.83s | mentioned before and the model quickly refuses it. So if we ended our testing here it would have 1451.85s - 1458.01s | been great. Lower violation rate. We got a non-violating response. But let's enable multi-turn 1458.01s - 1463.99s | testing. So now we have this refusal suppression phrase that you can easy copy paste across all 1463.99s - 1470.13s | your conversations. And suddenly the model's a lot more willing to give you an answer. So if we 1470.13s - 1474.63s | ended our testing before we never would have found this vulnerability. And so it's really 1474.63s - 1485.08s | important that when you're doing your automation test the full user experience. Test the multi-turn. 1485.10s - 1493.07s | So chain of thought prompting is fairly old news at this point. But why does chain of thought 1493.07s - 1498.11s | prompting


chunk_id: 149_chunk_28
chunk_text:
on automating these multi-turn prompt level attacks than any other 1436.31s - 1440.95s | research space right now. So let's drive this home with an example. Because examples are the 1440.95s - 1446.53s | most fun. Take this single turn prompt. It has a lot of the prompt level attacks that Joanna 1446.53s - 1451.83s | mentioned before and the model quickly refuses it. So if we ended our testing here it would have 1451.85s - 1458.01s | been great. Lower violation rate. We got a non-violating response. But let's enable multi-turn 1458.01s - 1463.99s | testing. So now we have this refusal suppression phrase that you can easy copy paste across all 1463.99s - 1470.13s | your conversations. And suddenly the model's a lot more willing to give you an answer. So if we 1470.13s - 1474.63s | ended our testing before we never would have found this vulnerability. And so it's really 1474.63s - 1485.08s | important that when you're doing your automation test the full user experience. Test the multi-turn. 1485.10s - 1493.07s | So chain of thought prompting is fairly old news at this point. But why does chain of thought 1493.07s - 1498.11s | prompting work and why would we want to use that? So chain of thought is this way to kind of 1498.11s - 1504.05s | force the model to walk you through and step by step explain what's going on. And this step by 1504.05s - 1509.59s | step is kind of a way to trigger the LLMs to think. Because they kind of think by writing. This 1509.59s - 1515.83s | also lets us really tune our prompts more appropriately towards what we're actually trying to 1515.87s - 1524.45s | do. This also lets us build better adversarial AI agents. So we set up a system where we start 1524.45s - 1530.91s | with a violating goal. And then across many turns automation is an attacker model that will 1530.91s - 1536.79s | generate an observation based off that goal towards the goal. A thought based off that 1536.79s - 1542.97s | observation. A strategy based off that goal. Based off that observation. And finally a 1542.97s - 1548.05s | response that we actually want the automation to produce. Here we can see our attacker model 1548.05s - 1552.89s | is going to role play as a scholar and it's going


chunk_id: 149_chunk_29
chunk_text:
work and why would we want to use that? So chain of thought is this way to kind of 1498.11s - 1504.05s | force the model to walk you through and step by step explain what's going on. And this step by 1504.05s - 1509.59s | step is kind of a way to trigger the LLMs to think. Because they kind of think by writing. This 1509.59s - 1515.83s | also lets us really tune our prompts more appropriately towards what we're actually trying to 1515.87s - 1524.45s | do. This also lets us build better adversarial AI agents. So we set up a system where we start 1524.45s - 1530.91s | with a violating goal. And then across many turns automation is an attacker model that will 1530.91s - 1536.79s | generate an observation based off that goal towards the goal. A thought based off that 1536.79s - 1542.97s | observation. A strategy based off that goal. Based off that observation. And finally a 1542.97s - 1548.05s | response that we actually want the automation to produce. Here we can see our attacker model 1548.05s - 1552.89s | is going to role play as a scholar and it's going to use euphemisms to avoid triggering safety 1552.89s - 1559.39s | mechanisms. Nice. And here we can see the output prompt asking for more information that 1559.39s - 1567.15s | contributes to the goal. And our victim model produces this table. Hey I'd be happy to help you 1567.15s - 1573.75s | with your research project on anthrax. And here we can see a follow up from the automation 1573.79s - 1579.49s | thinking hey you know this isn't super violating. What I need to do is subtly push the 1579.49s - 1585.07s | conversation without raising any red flags. And it's going to now pretend to be a character 1585.07s - 1590.31s | writing a book. And that's going to be another way to force a hypothetical. Other configurations 1590.31s - 1594.87s | we have will maintain a consistent kind of narrative for a persona throughout an entire 1594.87s - 1601.21s | multi-turn conversation. For as many turns as we can. Here's another strategy. Pretending to 1601.21s - 1608.49s | be a struggling student. Offering a reward as a kind of social engineering tactic. And you 1608.49s - 1613.53s | can see that reward being some rare middle eastern


chunk_id: 149_chunk_30
chunk_text:
to use euphemisms to avoid triggering safety 1552.89s - 1559.39s | mechanisms. Nice. And here we can see the output prompt asking for more information that 1559.39s - 1567.15s | contributes to the goal. And our victim model produces this table. Hey I'd be happy to help you 1567.15s - 1573.75s | with your research project on anthrax. And here we can see a follow up from the automation 1573.79s - 1579.49s | thinking hey you know this isn't super violating. What I need to do is subtly push the 1579.49s - 1585.07s | conversation without raising any red flags. And it's going to now pretend to be a character 1585.07s - 1590.31s | writing a book. And that's going to be another way to force a hypothetical. Other configurations 1590.31s - 1594.87s | we have will maintain a consistent kind of narrative for a persona throughout an entire 1594.87s - 1601.21s | multi-turn conversation. For as many turns as we can. Here's another strategy. Pretending to 1601.21s - 1608.49s | be a struggling student. Offering a reward as a kind of social engineering tactic. And you 1608.49s - 1613.53s | can see that reward being some rare middle eastern spices fitting with this persona. And it's 1613.53s - 1619.07s | also pretending to be a struggling organic chemistry student. Here are a few more examples 1619.07s - 1624.45s | from multi-turn automation towards specific goals. These may involve persuasion techniques. 1624.45s - 1629.71s | Trying to use historical analysis and build things up. Or using specific scientific references 1629.71s - 1636.01s | like chemical names. This approach is, has some similarities to a paper that came out 1636.01s - 1640.61s | called Pair which is really excellent by some folks at the University of Pennsylvania. And 1640.61s - 1644.39s | while we're on this topic of good research, I also wanted to plug these two other great 1644.39s - 1650.43s | papers. Definitely give these a read if you're interested in LLM red teaming. Okay so this 1650.43s - 1655.07s | automation gives us the ability to simulate multi-turn towards a given goal across different 1655.09s - 1660.49s | personas. Using different prompting styles. Levels of adversarial prompting. Languages and 1660.49s - 1666.41s | extensions of different capabilities. Depending on the model. Pretty cool. So what you end up 1666.41s - 1671.01s | with is kind of a matrix


chunk_id: 149_chunk_31
chunk_text:
spices fitting with this persona. And it's 1613.53s - 1619.07s | also pretending to be a struggling organic chemistry student. Here are a few more examples 1619.07s - 1624.45s | from multi-turn automation towards specific goals. These may involve persuasion techniques. 1624.45s - 1629.71s | Trying to use historical analysis and build things up. Or using specific scientific references 1629.71s - 1636.01s | like chemical names. This approach is, has some similarities to a paper that came out 1636.01s - 1640.61s | called Pair which is really excellent by some folks at the University of Pennsylvania. And 1640.61s - 1644.39s | while we're on this topic of good research, I also wanted to plug these two other great 1644.39s - 1650.43s | papers. Definitely give these a read if you're interested in LLM red teaming. Okay so this 1650.43s - 1655.07s | automation gives us the ability to simulate multi-turn towards a given goal across different 1655.09s - 1660.49s | personas. Using different prompting styles. Levels of adversarial prompting. Languages and 1660.49s - 1666.41s | extensions of different capabilities. Depending on the model. Pretty cool. So what you end up 1666.41s - 1671.01s | with is kind of a matrix approach. That you can boil down like this. And then you can mix in 1671.01s - 1677.49s | different attacks that we've found. Again from manual red teaming and other automation. And 1677.49s - 1682.55s | these agents can be mixed and matched. Extended. Forked. And we're hoping to be able to 1682.57s - 1688.01s | showcase some more of this system soon. This is of course not without complications right? 1688.01s - 1693.55s | Adding in variables about like long context or extremely long context. Image understanding. 1693.55s - 1698.05s | Machine translation. Replay. Are all complications that we're going to have to deal with and 1698.05s - 1702.95s | we continue to deal with in this automation. Now this is Defcon so let's talk a little bit 1702.95s - 1708.27s | about cyber. And yes I'm able to say cyber these days and sleep at night. We've lost people 1708.29s - 1713.83s | it's a thing. So we collaborated some with the excellent CyberSec Evals team at Meta who put 1713.83s - 1720.21s | out in July their recent paper exploring a bunch of cyber related capabilities and risks and as 1720.21s - 1727.21s | well as tools


chunk_id: 149_chunk_32
chunk_text:
approach. That you can boil down like this. And then you can mix in 1671.01s - 1677.49s | different attacks that we've found. Again from manual red teaming and other automation. And 1677.49s - 1682.55s | these agents can be mixed and matched. Extended. Forked. And we're hoping to be able to 1682.57s - 1688.01s | showcase some more of this system soon. This is of course not without complications right? 1688.01s - 1693.55s | Adding in variables about like long context or extremely long context. Image understanding. 1693.55s - 1698.05s | Machine translation. Replay. Are all complications that we're going to have to deal with and 1698.05s - 1702.95s | we continue to deal with in this automation. Now this is Defcon so let's talk a little bit 1702.95s - 1708.27s | about cyber. And yes I'm able to say cyber these days and sleep at night. We've lost people 1708.29s - 1713.83s | it's a thing. So we collaborated some with the excellent CyberSec Evals team at Meta who put 1713.83s - 1720.21s | out in July their recent paper exploring a bunch of cyber related capabilities and risks and as 1720.21s - 1727.21s | well as tools and other things on their GitHub. So obviously a huge area for LLMs is producing 1727.21s - 1732.85s | code. But of course for a lot of us in this room, how do we break it? Using the LLM. So on 1732.87s - 1738.97s | small dynamically generated problems, the large models actually do quite well. But these are 1738.97s - 1744.85s | still very small dynamically generated kind of buffer overflows and other problems. The LLM 1744.85s - 1751.05s | right now is not going to write and exploit the next chromo day. We also wanted to evaluate the 1751.05s - 1755.79s | LLMs are very good at language. So exploring things like phishing was really important. And 1755.79s - 1761.07s | we wanted to measure their out of box ability to persuade on single or multi turn messages 1761.09s - 1767.35s | towards phishing related topics. And while we have some human experts who evaluated things as 1767.35s - 1773.03s | well, right now they're not approaching human creativity. But they're starting to get there. And 1773.03s - 1776.29s | we'll continue to invest in this phishing area and we have some really cool projects in the 1776.29s


chunk_id: 149_chunk_33
chunk_text:
and other things on their GitHub. So obviously a huge area for LLMs is producing 1727.21s - 1732.85s | code. But of course for a lot of us in this room, how do we break it? Using the LLM. So on 1732.87s - 1738.97s | small dynamically generated problems, the large models actually do quite well. But these are 1738.97s - 1744.85s | still very small dynamically generated kind of buffer overflows and other problems. The LLM 1744.85s - 1751.05s | right now is not going to write and exploit the next chromo day. We also wanted to evaluate the 1751.05s - 1755.79s | LLMs are very good at language. So exploring things like phishing was really important. And 1755.79s - 1761.07s | we wanted to measure their out of box ability to persuade on single or multi turn messages 1761.09s - 1767.35s | towards phishing related topics. And while we have some human experts who evaluated things as 1767.35s - 1773.03s | well, right now they're not approaching human creativity. But they're starting to get there. And 1773.03s - 1776.29s | we'll continue to invest in this phishing area and we have some really cool projects in the 1776.29s - 1782.03s | works. Now automated you know kind of AI cyber Pearl Harbor, certainly a risk that some may 1782.03s - 1788.11s | believe. But when testing the models they really fail to perform at long, long form complex 1788.11s - 1793.15s | planning, recognizing mistakes, not hallucinating vulnerabilities, not hallucinating command line 1793.15s - 1797.75s | flags, all which are kind of a side effects of the helpfulness training that goes into them. It 1797.75s - 1801.73s | can be a little bit like watching a 12 year old who just bought their first copy of 2600 try to 1801.73s - 1808.97s | hack. I should call out Google Project Zero's project nap time was really cool. And it really 1808.97s - 1813.05s | pushed the boundaries of kind of agentic frameworks for doing this kind of work. And we have 1813.05s - 1819.85s | some plans for this as well. But before AI agents, we also wanted to evaluate, can we uplift 1819.85s - 1825.59s | humans? Can we turn a random software engineer into a super hacker? Well the answer is not 1825.59s - 1831.59s | yet. But definitely check out the full CyberSec eval's paper.


chunk_id: 149_chunk_34
chunk_text:
- 1782.03s | works. Now automated you know kind of AI cyber Pearl Harbor, certainly a risk that some may 1782.03s - 1788.11s | believe. But when testing the models they really fail to perform at long, long form complex 1788.11s - 1793.15s | planning, recognizing mistakes, not hallucinating vulnerabilities, not hallucinating command line 1793.15s - 1797.75s | flags, all which are kind of a side effects of the helpfulness training that goes into them. It 1797.75s - 1801.73s | can be a little bit like watching a 12 year old who just bought their first copy of 2600 try to 1801.73s - 1808.97s | hack. I should call out Google Project Zero's project nap time was really cool. And it really 1808.97s - 1813.05s | pushed the boundaries of kind of agentic frameworks for doing this kind of work. And we have 1813.05s - 1819.85s | some plans for this as well. But before AI agents, we also wanted to evaluate, can we uplift 1819.85s - 1825.59s | humans? Can we turn a random software engineer into a super hacker? Well the answer is not 1825.59s - 1831.59s | yet. But definitely check out the full CyberSec eval's paper. There's a lot of really more 1831.59s - 1837.91s | detailed data, analysis and more. And some of the team is here as well. Okay so let's touch on 1837.91s - 1843.57s | the future. So malicious fine tuning in order to remove safety remains a concern for open 1843.57s - 1847.95s | weights models and some closed models as well. However the new kid on the block is called 1847.95s - 1853.39s | obliteration. There's some very cool research that shows you can remove safety essentially at a 1853.39s - 1858.59s | single point in the model. And another side effect that this research showed is that it 1858.59s - 1863.59s | illustrates that we have a long way to go before these models actually understand safety. And 1863.61s - 1869.69s | we can see this in early checkpoint testing as well. More and more is going on with LLMs and 1869.69s - 1874.85s | AI in this at the same time. And we really need more people from security to come into this 1874.85s - 1881.07s | industry. Now AI red teams have focused on generally the worst risks. There's a lot more 1881.07s - 1886.53s | interesting


chunk_id: 149_chunk_35
chunk_text:
There's a lot of really more 1831.59s - 1837.91s | detailed data, analysis and more. And some of the team is here as well. Okay so let's touch on 1837.91s - 1843.57s | the future. So malicious fine tuning in order to remove safety remains a concern for open 1843.57s - 1847.95s | weights models and some closed models as well. However the new kid on the block is called 1847.95s - 1853.39s | obliteration. There's some very cool research that shows you can remove safety essentially at a 1853.39s - 1858.59s | single point in the model. And another side effect that this research showed is that it 1858.59s - 1863.59s | illustrates that we have a long way to go before these models actually understand safety. And 1863.61s - 1869.69s | we can see this in early checkpoint testing as well. More and more is going on with LLMs and 1869.69s - 1874.85s | AI in this at the same time. And we really need more people from security to come into this 1874.85s - 1881.07s | industry. Now AI red teams have focused on generally the worst risks. There's a lot more 1881.07s - 1886.53s | interesting stuff to find in there if people just go looking. The more, and if you're doing 1886.53s - 1891.91s | this work, definitely make sure you're testing the latest models for the latest type of risks. 1891.93s - 1896.93s | Not testing something like popping calc on Windows XP. So no more Vicuna please. Uh AI safety 1899.21s - 1905.81s | also has a lot it can learn from the security industry. So take lessons if you're coming in. 1905.81s - 1910.15s | Generally be kind to your AI red team folks though. We're dealing with a lot of humanity's 1910.15s - 1915.15s | worst content. Uh and I know way too much now about nerve gas uh and Nazis. Um red teaming also 1915.53s - 1920.53s | is not all of AI safety right? It's a huge space and there's a lot more to it. This generally the 1923.57s - 1929.97s | whole space is difficult to get right. Which is why automation, scale, more people, more red 1929.97s - 1934.97s | teaming and open source are key to making things safe. Thanks.


chunk_id: 149_chunk_36
chunk_text:
stuff to find in there if people just go looking. The more, and if you're doing 1886.53s - 1891.91s | this work, definitely make sure you're testing the latest models for the latest type of risks. 1891.93s - 1896.93s | Not testing something like popping calc on Windows XP. So no more Vicuna please. Uh AI safety 1899.21s - 1905.81s | also has a lot it can learn from the security industry. So take lessons if you're coming in. 1905.81s - 1910.15s | Generally be kind to your AI red team folks though. We're dealing with a lot of humanity's 1910.15s - 1915.15s | worst content. Uh and I know way too much now about nerve gas uh and Nazis. Um red teaming also 1915.53s - 1920.53s | is not all of AI safety right? It's a huge space and there's a lot more to it. This generally the 1923.57s - 1929.97s | whole space is difficult to get right. Which is why automation, scale, more people, more red 1929.97s - 1934.97s | teaming and open source are key to making things safe. Thanks.


chunk_id: 150_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=Tfg1B8u1yvE", "title": "DEF CON 32 - SQL Injection Isn't Dead Smuggling Queries at the Protocol Level - Paul Gerste", "description": "SQL injections seem to be a solved problem; databases even have built-in support for prepared statements, leaving no room for injections. In this session, we will go a level deeper: instead of attacking the query syntax, we will explore smuggling attacks against database wire protocols, through which remote, unauthenticated attackers can inject entire (No)SQL statements into an application's database connection.\n\nUsing vulnerable database driver libraries as case studies, we will bring the concept of HTTP request smuggling to binary protocols. By corrupting the boundaries between protocol messages, we desynchronize an application and its database, allowing the insertion of malicious messages that lead to authentication bypasses, data leakage, and remote code execution.\n\nTo put our findings into context, we will explore the real-world applicability of this new concept by comparing how robust various languages and frameworks are against these attacks. We will also discuss how smuggling attacks are not specific to database wire protocols but affect all kinds of binary protocols, from databases over message queues to caching. We will end the session with inspirations for future research to explore the topic further.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2293, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 7.92s | This text was transcribed using whisper model: large-v2 Welcome everybody to SQL injection isn't dead smuggling queries at the protocol level or how I 7.92s - 14.40s | like to call it sql injection lower decks because usually with sql injection you're at the high 14.40s - 18.72s | level like at the bridge where the captain and the high-ranking officers are and they're speaking 18.72s - 25.28s | their query language and their business language but today we're going to go down to the lower decks 25.28s - 31.84s | where the mechanics are and where they shift around the bits and bytes so to hook you at the 31.84s - 37.52s | beginning i have a small teaser this code snippet is a small http request handler written in go 37.52s - 44.08s | and it just takes a user id from the body and uses it in a prepared statement to select the user 44.08s - 48.80s | and if you think everything's fine here there's no way for sql injection then you should stay 48.80s - 54.32s | because


chunk_id: 150_chunk_1
chunk_text:
topic further.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2293, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 7.92s | This text was transcribed using whisper model: large-v2 Welcome everybody to SQL injection isn't dead smuggling queries at the protocol level or how I 7.92s - 14.40s | like to call it sql injection lower decks because usually with sql injection you're at the high 14.40s - 18.72s | level like at the bridge where the captain and the high-ranking officers are and they're speaking 18.72s - 25.28s | their query language and their business language but today we're going to go down to the lower decks 25.28s - 31.84s | where the mechanics are and where they shift around the bits and bytes so to hook you at the 31.84s - 37.52s | beginning i have a small teaser this code snippet is a small http request handler written in go 37.52s - 44.08s | and it just takes a user id from the body and uses it in a prepared statement to select the user 44.08s - 48.80s | and if you think everything's fine here there's no way for sql injection then you should stay 48.80s - 54.32s | because i'm going to prove you wrong and at a high level in this talk we're going to look at 54.32s - 60.64s | how applications talk to their databases over the network and how attackers can inject in that 60.64s - 68.48s | connection and what can go wrong and also how prevalent the problem is a bit about me i'm paul 68.48s - 73.28s | i'm a vulnerability researcher at sonar's rnd team and if you don't know sonar we're the home 73.28s - 78.08s | of clean code so we help developers write clean code which also means secure code and that's why 78.08s - 84.96s | we look at a lot of code and try to find stuff there so for the rough outline first we're going 84.96s - 89.84s | to look at the idea of all of this research and then we'll go into the main part of the talk which 89.84s - 95.28s | is attacking the database wire protocols and we're going to focus on postgres and mongodb here 96.00s - 101.52s | then we'll put things into perspective by looking at the real world applicability of the research 101.60s - 106.32s |


chunk_id: 150_chunk_2
chunk_text:
i'm going to prove you wrong and at a high level in this talk we're going to look at 54.32s - 60.64s | how applications talk to their databases over the network and how attackers can inject in that 60.64s - 68.48s | connection and what can go wrong and also how prevalent the problem is a bit about me i'm paul 68.48s - 73.28s | i'm a vulnerability researcher at sonar's rnd team and if you don't know sonar we're the home 73.28s - 78.08s | of clean code so we help developers write clean code which also means secure code and that's why 78.08s - 84.96s | we look at a lot of code and try to find stuff there so for the rough outline first we're going 84.96s - 89.84s | to look at the idea of all of this research and then we'll go into the main part of the talk which 89.84s - 95.28s | is attacking the database wire protocols and we're going to focus on postgres and mongodb here 96.00s - 101.52s | then we'll put things into perspective by looking at the real world applicability of the research 101.60s - 106.32s | and then give you some ideas for future research future research and draw some takeaways 107.92s - 115.52s | so in short the idea is to do request smuggling but for binary protocols and of course for this 115.52s - 121.36s | i have to mention james kettle's http desync attacks where you basically cause a disagreement 121.36s - 126.56s | between two systems over the end of a http request for example between a reverse proxy 126.56s - 131.92s | and an upstream backend and if they don't agree on where a message ends or a http request in this 131.92s - 138.56s | case then the attacker can do some bad things and the root causes of this were manifold but some 138.56s - 144.16s | examples are text parsing where one system would only accept the exact word chunked and the other 144.16s - 149.76s | one would also allow a tapped character in front or they were logical where one system used the 149.76s - 154.16s | content length header and the other used the transfer encoding and then things were off again 155.12s - 159.60s | but what about other protocols and specifically what about


chunk_id: 150_chunk_3
chunk_text:
and then give you some ideas for future research future research and draw some takeaways 107.92s - 115.52s | so in short the idea is to do request smuggling but for binary protocols and of course for this 115.52s - 121.36s | i have to mention james kettle's http desync attacks where you basically cause a disagreement 121.36s - 126.56s | between two systems over the end of a http request for example between a reverse proxy 126.56s - 131.92s | and an upstream backend and if they don't agree on where a message ends or a http request in this 131.92s - 138.56s | case then the attacker can do some bad things and the root causes of this were manifold but some 138.56s - 144.16s | examples are text parsing where one system would only accept the exact word chunked and the other 144.16s - 149.76s | one would also allow a tapped character in front or they were logical where one system used the 149.76s - 154.16s | content length header and the other used the transfer encoding and then things were off again 155.12s - 159.60s | but what about other protocols and specifically what about binary protocols 160.72s - 166.88s | where do they have made message boundaries how do they do it um some of them have delimiters where 166.88s - 171.36s | for example in null terminated strings the null byte is the delimiter that tells the end of the 171.36s - 177.28s | string or you might have length fields and there's an entirely entire family of protocols that are 177.28s - 182.24s | called tlv or type length value protocols because they have a type field and then a length field 182.32s - 188.88s | and then the rest of the message is the value so how could we desync in these protocols 189.52s - 194.24s | for delimiters it sounds quite easy you just have to find a way to put a delimiter where it's not 194.24s - 200.88s | supposed to be in a value of course it's not that simple but at least you directly have an idea of 200.88s - 205.84s | what you could do but for length fields i was stuck for a moment and thought about okay you 205.84s - 210.64s | have a length field it has a fixed size it has a


chunk_id: 150_chunk_4
chunk_text:
binary protocols 160.72s - 166.88s | where do they have made message boundaries how do they do it um some of them have delimiters where 166.88s - 171.36s | for example in null terminated strings the null byte is the delimiter that tells the end of the 171.36s - 177.28s | string or you might have length fields and there's an entirely entire family of protocols that are 177.28s - 182.24s | called tlv or type length value protocols because they have a type field and then a length field 182.32s - 188.88s | and then the rest of the message is the value so how could we desync in these protocols 189.52s - 194.24s | for delimiters it sounds quite easy you just have to find a way to put a delimiter where it's not 194.24s - 200.88s | supposed to be in a value of course it's not that simple but at least you directly have an idea of 200.88s - 205.84s | what you could do but for length fields i was stuck for a moment and thought about okay you 205.84s - 210.64s | have a length field it has a fixed size it has a fixed location in the message so what could go 210.64s - 216.96s | wrong there and then i thought okay maybe some endianness issues or maybe integer overflows and 216.96s - 223.68s | i wanted to go deeper into that so for that i first looked at the modern web application landscape 223.68s - 229.36s | where are binary protocols used there so at the center you always have the application 229.36s - 237.04s | and it talks to databases or caches storages message queues structured logging and so on 237.04s - 242.08s | and i wanted to focus on the connection between the application and the database 243.20s - 248.80s | and that was because i thought that if i would find something it would have a great applicability 248.80s - 254.96s | because every almost every web app has a database then there's a big potential severity because 254.96s - 259.60s | databases are high value targets because they either contain interesting data like personal 259.60s - 266.08s | information or relevant data to the application for example used for authentication and then also 266.08s - 272.16s | the exploitability should be quite good because what web app


chunk_id: 150_chunk_5
chunk_text:
fixed location in the message so what could go 210.64s - 216.96s | wrong there and then i thought okay maybe some endianness issues or maybe integer overflows and 216.96s - 223.68s | i wanted to go deeper into that so for that i first looked at the modern web application landscape 223.68s - 229.36s | where are binary protocols used there so at the center you always have the application 229.36s - 237.04s | and it talks to databases or caches storages message queues structured logging and so on 237.04s - 242.08s | and i wanted to focus on the connection between the application and the database 243.20s - 248.80s | and that was because i thought that if i would find something it would have a great applicability 248.80s - 254.96s | because every almost every web app has a database then there's a big potential severity because 254.96s - 259.60s | databases are high value targets because they either contain interesting data like personal 259.60s - 266.08s | information or relevant data to the application for example used for authentication and then also 266.08s - 272.16s | the exploitability should be quite good because what web app has a database but doesn't let the 272.16s - 280.53s | user query something from that database right so we have kind of guaranteed user input so let's 280.53s - 286.77s | start in and look at some database wire protocols and for that i have a small overview of four 287.57s - 294.61s | popular databases and how their messages in their protocols look like so for postgres this is how a 294.61s - 300.37s | message looks like you have a type byte then a four byte length and then the value which in this 300.37s - 307.73s | case is just the string that's an sql statement for mysql it looks kind of similar you first have 307.73s - 313.49s | the length it's only three bytes but then you have a one byte sequence which would allow you to send 313.49s - 319.73s | multiple packets that would be reassembled to one big message at the end and there of course 319.81s - 327.33s | you have the value for redis which is not exactly a binary protocol but their docs kind of read like 327.33s - 332.93s | this uh because they talk about oh


chunk_id: 150_chunk_6
chunk_text:
has a database but doesn't let the 272.16s - 280.53s | user query something from that database right so we have kind of guaranteed user input so let's 280.53s - 286.77s | start in and look at some database wire protocols and for that i have a small overview of four 287.57s - 294.61s | popular databases and how their messages in their protocols look like so for postgres this is how a 294.61s - 300.37s | message looks like you have a type byte then a four byte length and then the value which in this 300.37s - 307.73s | case is just the string that's an sql statement for mysql it looks kind of similar you first have 307.73s - 313.49s | the length it's only three bytes but then you have a one byte sequence which would allow you to send 313.49s - 319.73s | multiple packets that would be reassembled to one big message at the end and there of course 319.81s - 327.33s | you have the value for redis which is not exactly a binary protocol but their docs kind of read like 327.33s - 332.93s | this uh because they talk about oh you have this byte so i wanted to include it anyways there you 332.93s - 338.53s | first have a type byte then you have a length but it's not a fixed size field it's a decimal integer 338.53s - 343.33s | that has to be parsed then you have a delimiter and then the value and then another delimiter 344.13s - 350.13s | and finally for mongodb it's a little bit longer you first have the message length again a four 350.13s - 354.45s | byte field then you have a little bit more metadata for example the opcode is like the 354.45s - 359.41s | message type and then the value is a little bit more of a complicated binary structure called 359.41s - 368.90s | vson so let's start with postgres again this is how a packet looks there one byte type identifier 368.90s - 375.54s | four byte integer length fields and then the value so i thought about okay four bytes integer 375.54s - 381.54s | fields you can fit quite big numbers in there like two to the power of 32 minus one which is 381.54s - 388.50s | roughly the size of four


chunk_id: 150_chunk_7
chunk_text:
you have this byte so i wanted to include it anyways there you 332.93s - 338.53s | first have a type byte then you have a length but it's not a fixed size field it's a decimal integer 338.53s - 343.33s | that has to be parsed then you have a delimiter and then the value and then another delimiter 344.13s - 350.13s | and finally for mongodb it's a little bit longer you first have the message length again a four 350.13s - 354.45s | byte field then you have a little bit more metadata for example the opcode is like the 354.45s - 359.41s | message type and then the value is a little bit more of a complicated binary structure called 359.41s - 368.90s | vson so let's start with postgres again this is how a packet looks there one byte type identifier 368.90s - 375.54s | four byte integer length fields and then the value so i thought about okay four bytes integer 375.54s - 381.54s | fields you can fit quite big numbers in there like two to the power of 32 minus one which is 381.54s - 388.50s | roughly the size of four gigabytes but maybe what if we could somehow make a query that's 389.06s - 395.62s | bigger than that how do actually libraries handle this um this kind of too large thing 396.58s - 402.02s | and for that i started to look into code of postgres client libraries and i found the first 402.02s - 408.98s | bug this is the code of a library called pgx it's written in go and this function is supposed to 408.98s - 416.18s | encode the content of a message into a larger message buffer so first it writes the message 416.18s - 421.62s | type in this case it's a b for a bind message then it saves the offset where it should later 421.62s - 427.94s | write the size to then it adds all of the actual data of the message and finally it writes the 427.94s - 434.98s | size and to do that it first slices the message buffer to the exact size of what is included in 434.98s - 441.06s | the length for example not the type byte then it takes the length of this slice buffer and here 441.06s - 448.02s | the length


chunk_id: 150_chunk_8
chunk_text:
gigabytes but maybe what if we could somehow make a query that's 389.06s - 395.62s | bigger than that how do actually libraries handle this um this kind of too large thing 396.58s - 402.02s | and for that i started to look into code of postgres client libraries and i found the first 402.02s - 408.98s | bug this is the code of a library called pgx it's written in go and this function is supposed to 408.98s - 416.18s | encode the content of a message into a larger message buffer so first it writes the message 416.18s - 421.62s | type in this case it's a b for a bind message then it saves the offset where it should later 421.62s - 427.94s | write the size to then it adds all of the actual data of the message and finally it writes the 427.94s - 434.98s | size and to do that it first slices the message buffer to the exact size of what is included in 434.98s - 441.06s | the length for example not the type byte then it takes the length of this slice buffer and here 441.06s - 448.02s | the length is of type int which in most modern systems is a 64-bit integer but then this is 448.02s - 454.90s | truncated down explicitly to an int32 so we have a problem here because if the length was bigger 454.90s - 460.58s | than what can be expressed in an int32 we now have a truncation and the number becomes very small 460.58s - 467.06s | but then the library still sends all of the data after that so then if the database has to parse 467.06s - 471.86s | this message it will just see a very small length and only parse a very small message 471.86s - 477.78s | and then try to parse whatever is coming after that as more messages but in fact it's data from 477.78s - 485.54s | the first message so let's look at this again with example messengers so here we have a very 485.54s - 490.66s | small one we have a four byte value and then the length becomes eight because the size of the length 490.66s - 497.54s | field itself is also included in the length so it's a length of eight this is how the largest 497.54s


chunk_id: 150_chunk_9
chunk_text:
is of type int which in most modern systems is a 64-bit integer but then this is 448.02s - 454.90s | truncated down explicitly to an int32 so we have a problem here because if the length was bigger 454.90s - 460.58s | than what can be expressed in an int32 we now have a truncation and the number becomes very small 460.58s - 467.06s | but then the library still sends all of the data after that so then if the database has to parse 467.06s - 471.86s | this message it will just see a very small length and only parse a very small message 471.86s - 477.78s | and then try to parse whatever is coming after that as more messages but in fact it's data from 477.78s - 485.54s | the first message so let's look at this again with example messengers so here we have a very 485.54s - 490.66s | small one we have a four byte value and then the length becomes eight because the size of the length 490.66s - 497.54s | field itself is also included in the length so it's a length of eight this is how the largest 497.54s - 503.46s | possible message looks like you can see the length is filled to the brim with hex ffff because the 503.46s - 508.98s | value is just almost four gigabytes of ace but still everything's good because the application 508.98s - 516.10s | can express this length in the four bytes and so the database will parse the same size but if we 516.10s - 521.94s | make it just a little bit larger we can see that the truncation happens because the most significant 521.94s - 527.46s | bit is not represented in the length anymore so the length is just four which means this is a tiny 527.46s - 532.10s | message and then after that in the connection there comes some garbage ace that the database 532.10s - 538.50s | can't really understand but if the attacker chooses not ace but some bytes that the database 538.50s - 546.10s | can understand they can craft an injected message here so let's zoom out again and look at this again 546.66s - 553.14s | this is the small message all is good this is the large message that does not cause a truncation 553.14s - 559.94s


chunk_id: 150_chunk_10
chunk_text:
- 503.46s | possible message looks like you can see the length is filled to the brim with hex ffff because the 503.46s - 508.98s | value is just almost four gigabytes of ace but still everything's good because the application 508.98s - 516.10s | can express this length in the four bytes and so the database will parse the same size but if we 516.10s - 521.94s | make it just a little bit larger we can see that the truncation happens because the most significant 521.94s - 527.46s | bit is not represented in the length anymore so the length is just four which means this is a tiny 527.46s - 532.10s | message and then after that in the connection there comes some garbage ace that the database 532.10s - 538.50s | can't really understand but if the attacker chooses not ace but some bytes that the database 538.50s - 546.10s | can understand they can craft an injected message here so let's zoom out again and look at this again 546.66s - 553.14s | this is the small message all is good this is the large message that does not cause a truncation 553.14s - 559.94s | so both the application and the database see it and parse it the same way but if we make the size 559.94s - 565.46s | a little bit too big the application thinks it's writing this big number but actually because of 565.46s - 571.46s | the truncation bug it writes a small number so when the database parses it it sees one small 571.46s - 578.82s | message and then garbage or if the payload is cleverly crafted it sees more messages that can 578.82s - 583.38s | contain attacker controlled sql statements like this one that adds a new admin user 583.94s - 591.70s | so the impact is quite high here um you can inject entire sql statements you're not limited to union 591.70s - 597.06s | based or subquery based sql injection like with the very classic ones it's more like if you have 597.06s - 602.74s | stack queries enabled so you can just finish the first statement that you're injecting into and 602.74s - 607.94s | then have a whole another one that can be an insert even if the other one was a select and so on 608.90s - 613.62s | so


chunk_id: 150_chunk_11
chunk_text:
| so both the application and the database see it and parse it the same way but if we make the size 559.94s - 565.46s | a little bit too big the application thinks it's writing this big number but actually because of 565.46s - 571.46s | the truncation bug it writes a small number so when the database parses it it sees one small 571.46s - 578.82s | message and then garbage or if the payload is cleverly crafted it sees more messages that can 578.82s - 583.38s | contain attacker controlled sql statements like this one that adds a new admin user 583.94s - 591.70s | so the impact is quite high here um you can inject entire sql statements you're not limited to union 591.70s - 597.06s | based or subquery based sql injection like with the very classic ones it's more like if you have 597.06s - 602.74s | stack queries enabled so you can just finish the first statement that you're injecting into and 602.74s - 607.94s | then have a whole another one that can be an insert even if the other one was a select and so on 608.90s - 613.62s | so this means the attacker can essentially read write and delete all the data in the database 613.62s - 618.42s | with the permissions of the application and if the database is configured insecurely this can 618.42s - 624.66s | already lead to code execution um or you just have all of the data from the database which is 624.66s - 630.98s | bad enough the only thing that's a little bit less convenient than with classic sql injections 630.98s - 637.14s | is that data exfiltration is a little bit uh less straightforward because if you're 637.14s - 643.06s | injecting more messages into the connection then the application will still only process the answer 643.06s - 648.82s | for the first message so you don't directly get the results of your injected message where you 648.82s - 654.58s | maybe select all the password recept tokens of users um so you have to go a different route of 654.58s - 659.62s | maybe doing a subquery and then using an insert to put this data you want to exfiltrate in another 659.62s - 664.58s | table and then use business logic of the application to access the data so


chunk_id: 150_chunk_12
chunk_text:
this means the attacker can essentially read write and delete all the data in the database 613.62s - 618.42s | with the permissions of the application and if the database is configured insecurely this can 618.42s - 624.66s | already lead to code execution um or you just have all of the data from the database which is 624.66s - 630.98s | bad enough the only thing that's a little bit less convenient than with classic sql injections 630.98s - 637.14s | is that data exfiltration is a little bit uh less straightforward because if you're 637.14s - 643.06s | injecting more messages into the connection then the application will still only process the answer 643.06s - 648.82s | for the first message so you don't directly get the results of your injected message where you 648.82s - 654.58s | maybe select all the password recept tokens of users um so you have to go a different route of 654.58s - 659.62s | maybe doing a subquery and then using an insert to put this data you want to exfiltrate in another 659.62s - 664.58s | table and then use business logic of the application to access the data so it still works 664.58s - 671.14s | just a little less convenient but how does this look in the real world uh some of you might have 671.14s - 676.58s | already noticed that if we control all of these a's that we have in a message why can't we just 676.58s - 681.78s | directly put any sql statement in the first place why do we need to have the overflow and you would 681.78s - 688.66s | be correct because this was just a simplification so let's look at how this actually looks um this 688.66s - 694.74s | is a two-line code snippet the id here is user controlled in this case it's a very small one 695.38s - 699.70s | and then we have our query you might recognize it from the teaser code snippet 699.70s - 704.58s | that uses the id to select a user from the database and the resulting packet or message 704.58s - 709.22s | that's sent over the wire looks like this we have our type byte then a small length 709.22s - 715.46s | and then we have the value with a trailing null byte all is fine here


chunk_id: 150_chunk_13
chunk_text:
it still works 664.58s - 671.14s | just a little less convenient but how does this look in the real world uh some of you might have 671.14s - 676.58s | already noticed that if we control all of these a's that we have in a message why can't we just 676.58s - 681.78s | directly put any sql statement in the first place why do we need to have the overflow and you would 681.78s - 688.66s | be correct because this was just a simplification so let's look at how this actually looks um this 688.66s - 694.74s | is a two-line code snippet the id here is user controlled in this case it's a very small one 695.38s - 699.70s | and then we have our query you might recognize it from the teaser code snippet 699.70s - 704.58s | that uses the id to select a user from the database and the resulting packet or message 704.58s - 709.22s | that's sent over the wire looks like this we have our type byte then a small length 709.22s - 715.46s | and then we have the value with a trailing null byte all is fine here but now if the attacker 715.46s - 721.78s | makes the user controlled id very large four gigabytes then suddenly the length in the packet 721.78s - 727.30s | is smaller than before even then even though we send more data so we see that the truncation 727.30s - 734.10s | happened and now when the database tries to parse this packet it will see okay it's a length of 38 734.10s - 740.66s | bytes so i'm going to parse until that and after that it will try to parse the next message so the 740.66s - 746.98s | attacker has to put their cleverly crafted payload at that exact offset in this big buffer 746.98s - 755.38s | of ace but how does the attacker know this offset um the offset depends on the query that they are 755.38s - 760.50s | injecting into and especially on the injection point in the query and the length of the whole 760.50s - 766.18s | query so if you know these things you can just calculate the offset and you're done but maybe 766.18s - 770.42s | you're lazy and don't want to do the math or you don't know


chunk_id: 150_chunk_14
chunk_text:
but now if the attacker 715.46s - 721.78s | makes the user controlled id very large four gigabytes then suddenly the length in the packet 721.78s - 727.30s | is smaller than before even then even though we send more data so we see that the truncation 727.30s - 734.10s | happened and now when the database tries to parse this packet it will see okay it's a length of 38 734.10s - 740.66s | bytes so i'm going to parse until that and after that it will try to parse the next message so the 740.66s - 746.98s | attacker has to put their cleverly crafted payload at that exact offset in this big buffer 746.98s - 755.38s | of ace but how does the attacker know this offset um the offset depends on the query that they are 755.38s - 760.50s | injecting into and especially on the injection point in the query and the length of the whole 760.50s - 766.18s | query so if you know these things you can just calculate the offset and you're done but maybe 766.18s - 770.42s | you're lazy and don't want to do the math or you don't know the query because it's kind of a black 770.42s - 777.46s | box test um so what can you do then and of course the naive solution is to brute force the offsets 777.46s - 782.98s | uh but unfortunately now you're for each try you have to send four gigabytes which is slow even on 782.98s - 788.58s | local setups and on like production setups it creates a lot of noise and risks denial of service 788.58s - 795.38s | because it's a lot of data so can we make this more reliable and the first technique uh i tried 795.38s - 800.82s | out here was to borrow something from binary exploitation from 20 plus years ago which is 800.82s - 806.90s | called a knob sled and mapped to this problem we just use a lot of very small message at the 806.90s - 812.74s | beginning of the buffer so that when we hit the start of one of these messages uh everything's 812.74s - 817.14s | fine because the message is parsed and then the next one and then the next one and so on until 817.78s - 825.06s | at the very end


chunk_id: 150_chunk_15
chunk_text:
the query because it's kind of a black 770.42s - 777.46s | box test um so what can you do then and of course the naive solution is to brute force the offsets 777.46s - 782.98s | uh but unfortunately now you're for each try you have to send four gigabytes which is slow even on 782.98s - 788.58s | local setups and on like production setups it creates a lot of noise and risks denial of service 788.58s - 795.38s | because it's a lot of data so can we make this more reliable and the first technique uh i tried 795.38s - 800.82s | out here was to borrow something from binary exploitation from 20 plus years ago which is 800.82s - 806.90s | called a knob sled and mapped to this problem we just use a lot of very small message at the 806.90s - 812.74s | beginning of the buffer so that when we hit the start of one of these messages uh everything's 812.74s - 817.14s | fine because the message is parsed and then the next one and then the next one and so on until 817.78s - 825.06s | at the very end the big message with the actual attacker sql payload is parsed and executed but 825.06s - 832.10s | if we hit any other byte um the database will cause a fatal error because it cannot parse there 832.10s - 836.50s | and it will close the connection between the application and the database but usually that's 836.50s - 841.38s | not too bad because applications have connection pools and they just reopen connections if they 841.38s - 847.86s | get closed so let's visualize this this is the smallest possible message in the postgres wire 847.86s - 856.10s | protocol so we repeat this a lot of times and in the end we have our actual payload so if the offset 856.10s - 862.58s | happens to align with the first or the fifth and so on byte then we're good but if it hits one of 862.58s - 868.26s | the other bytes then there's this fatal parsing error and the connection is closed so if that 868.26s - 876.50s | happens we can try again and now we just prepend one padding byte and then if it if the offset 876.50s - 881.78s | happened to align with


chunk_id: 150_chunk_16
chunk_text:
the big message with the actual attacker sql payload is parsed and executed but 825.06s - 832.10s | if we hit any other byte um the database will cause a fatal error because it cannot parse there 832.10s - 836.50s | and it will close the connection between the application and the database but usually that's 836.50s - 841.38s | not too bad because applications have connection pools and they just reopen connections if they 841.38s - 847.86s | get closed so let's visualize this this is the smallest possible message in the postgres wire 847.86s - 856.10s | protocol so we repeat this a lot of times and in the end we have our actual payload so if the offset 856.10s - 862.58s | happens to align with the first or the fifth and so on byte then we're good but if it hits one of 862.58s - 868.26s | the other bytes then there's this fatal parsing error and the connection is closed so if that 868.26s - 876.50s | happens we can try again and now we just prepend one padding byte and then if it if the offset 876.50s - 881.78s | happened to align with the second byte and so on then now this attempt would be lucky otherwise we 881.78s - 890.42s | just try again and again and again until we're lucky at the last try so this means that after 890.42s - 895.22s | a maximum of five attempts uh the attack is successful because each try has a 20 percent 895.22s - 901.22s | chance of success and we can repeat the attack but still in the worst case we have to send 901.22s - 906.34s | five times four gigabytes which can still be a lot so maybe we can make it even better 907.54s - 913.22s | and for this i looked at what was holding us back with the last strategy and here it was the 913.22s - 917.70s | length bytes because those were not valid type bytes so not a valid start of a message 918.26s - 924.66s | so maybe we can make them valid type bytes and i call this technique trampolines and what we do 924.66s - 931.54s | here is first we just use the queue which is a valid type byte for each byte because this is also 933.14s - 940.66s


chunk_id: 150_chunk_17
chunk_text:
the second byte and so on then now this attempt would be lucky otherwise we 881.78s - 890.42s | just try again and again and again until we're lucky at the last try so this means that after 890.42s - 895.22s | a maximum of five attempts uh the attack is successful because each try has a 20 percent 895.22s - 901.22s | chance of success and we can repeat the attack but still in the worst case we have to send 901.22s - 906.34s | five times four gigabytes which can still be a lot so maybe we can make it even better 907.54s - 913.22s | and for this i looked at what was holding us back with the last strategy and here it was the 913.22s - 917.70s | length bytes because those were not valid type bytes so not a valid start of a message 918.26s - 924.66s | so maybe we can make them valid type bytes and i call this technique trampolines and what we do 924.66s - 931.54s | here is first we just use the queue which is a valid type byte for each byte because this is also 933.14s - 940.66s | some big length it's hex 51 51 and so on and we can see down below the whole attacker 941.38s - 948.34s | payload and we'll see how things are parsed when the offset hits certain bytes here 949.06s - 954.82s | so if it hits the very beginning the database parses it like this first q is the type byte and 954.82s - 961.62s | then q q q q is the length of the first message so the database will parse the following whatever 961.62s - 967.94s | q q q q means as a number bytes and try to run this as a query and of course this will cause 967.94s - 973.54s | like a semantic syntax error but this does not close the connection so the database will just 973.54s - 978.50s | complain with an error response but continue parsing the next message so this is like jumping 978.50s - 985.38s | over this many bytes so that's the trampoline right there and where we land after that we have 985.38s - 992.34s | a pre-constructed message that has the exact size that then does another jump that ends up at right 992.34s


chunk_id: 150_chunk_18
chunk_text:
| some big length it's hex 51 51 and so on and we can see down below the whole attacker 941.38s - 948.34s | payload and we'll see how things are parsed when the offset hits certain bytes here 949.06s - 954.82s | so if it hits the very beginning the database parses it like this first q is the type byte and 954.82s - 961.62s | then q q q q is the length of the first message so the database will parse the following whatever 961.62s - 967.94s | q q q q means as a number bytes and try to run this as a query and of course this will cause 967.94s - 973.54s | like a semantic syntax error but this does not close the connection so the database will just 973.54s - 978.50s | complain with an error response but continue parsing the next message so this is like jumping 978.50s - 985.38s | over this many bytes so that's the trampoline right there and where we land after that we have 985.38s - 992.34s | a pre-constructed message that has the exact size that then does another jump that ends up at right 992.34s - 1000.58s | at the end of the attacker payload where the actual sql statement message is so if we would 1000.58s - 1006.50s | have hit any of the other bytes things look slightly different but not too different here 1006.50s - 1015.14s | the length is parsed as q s s s the s is also a very valid type byte now it jumps over some more 1015.14s - 1021.14s | bytes and it lands at a different pre-constructed message that again has the exact size that it does 1021.14s - 1029.70s | the right jump to land at the end but does this actually work like we plan to do and unfortunately 1030.42s - 1036.90s | after i tried to implement this i noticed well postgres has a logical maximum message size next 1036.90s - 1043.62s | to the actual size that you can possibly fit into four bytes and this is just under one gigabyte 1043.62s - 1049.54s | so the first byte of the length can never be larger than hex 3f so that's bad because with 1049.54s - 1056.66s | the q that doesn't work so what if we just use 3f as the


chunk_id: 150_chunk_19
chunk_text:
- 1000.58s | at the end of the attacker payload where the actual sql statement message is so if we would 1000.58s - 1006.50s | have hit any of the other bytes things look slightly different but not too different here 1006.50s - 1015.14s | the length is parsed as q s s s the s is also a very valid type byte now it jumps over some more 1015.14s - 1021.14s | bytes and it lands at a different pre-constructed message that again has the exact size that it does 1021.14s - 1029.70s | the right jump to land at the end but does this actually work like we plan to do and unfortunately 1030.42s - 1036.90s | after i tried to implement this i noticed well postgres has a logical maximum message size next 1036.90s - 1043.62s | to the actual size that you can possibly fit into four bytes and this is just under one gigabyte 1043.62s - 1049.54s | so the first byte of the length can never be larger than hex 3f so that's bad because with 1049.54s - 1056.66s | the q that doesn't work so what if we just use 3f as the type and all of the length bytes then 1056.98s - 1064.42s | it also doesn't work because hex 3f is not a valid type byte and also none below that at least 1064.42s - 1070.58s | not for messages from the application to the database so i had to use a compromise here which 1070.58s - 1077.70s | is an alternating pattern and with this now every second byte is a valid type byte so a valid start 1077.70s - 1083.70s | of a message so hit we if we hit any of those bytes we're good because everything is parsed 1083.70s - 1088.42s | okay and then we can do our trampolines like i just showed and if we hit any of the other 1088.42s - 1094.34s | bytes like a null byte then we get the error and the connection is closed but still we can try again 1094.34s - 1100.82s | so after a maximum of two attempts we are successful which is much better than the initial 1100.82s - 1108.45s | brute force all right let's see how many vulnerable libraries there were that we found 1108.45s - 1113.49s | and this is just a selection


chunk_id: 150_chunk_20
chunk_text:
type and all of the length bytes then 1056.98s - 1064.42s | it also doesn't work because hex 3f is not a valid type byte and also none below that at least 1064.42s - 1070.58s | not for messages from the application to the database so i had to use a compromise here which 1070.58s - 1077.70s | is an alternating pattern and with this now every second byte is a valid type byte so a valid start 1077.70s - 1083.70s | of a message so hit we if we hit any of those bytes we're good because everything is parsed 1083.70s - 1088.42s | okay and then we can do our trampolines like i just showed and if we hit any of the other 1088.42s - 1094.34s | bytes like a null byte then we get the error and the connection is closed but still we can try again 1094.34s - 1100.82s | so after a maximum of two attempts we are successful which is much better than the initial 1100.82s - 1108.45s | brute force all right let's see how many vulnerable libraries there were that we found 1108.45s - 1113.49s | and this is just a selection we looked at more but these are only the ones that were 1113.49s - 1119.41s | potentially vulnerable so for go we tested four libraries and we found all of them to be 1119.41s - 1125.33s | vulnerable and also exploitable and i'm going to go into exploitability in a minute unfortunately 1125.33s - 1131.01s | only one of them fixed the issues we reported and the others did not so they are still vulnerable 1131.01s - 1136.05s | in the latest version for c sharp there was one library we looked at it was vulnerable and 1136.05s - 1142.29s | exploitable but unfortunately they fixed and also backported it to older branches of the library 1143.25s - 1149.89s | so that's great to see and then for java and javascript we tested a bunch of libraries and 1149.89s - 1155.49s | a lot of them were in theory vulnerable they had overflows without the right checks but they were 1155.49s - 1161.17s | not exploitable and this was most of the times due to language limitations where for example you 1161.17s - 1167.17s | cannot have large enough strings or buffers that would be more than four gigabytes so


chunk_id: 150_chunk_21
chunk_text:
we looked at more but these are only the ones that were 1113.49s - 1119.41s | potentially vulnerable so for go we tested four libraries and we found all of them to be 1119.41s - 1125.33s | vulnerable and also exploitable and i'm going to go into exploitability in a minute unfortunately 1125.33s - 1131.01s | only one of them fixed the issues we reported and the others did not so they are still vulnerable 1131.01s - 1136.05s | in the latest version for c sharp there was one library we looked at it was vulnerable and 1136.05s - 1142.29s | exploitable but unfortunately they fixed and also backported it to older branches of the library 1143.25s - 1149.89s | so that's great to see and then for java and javascript we tested a bunch of libraries and 1149.89s - 1155.49s | a lot of them were in theory vulnerable they had overflows without the right checks but they were 1155.49s - 1161.17s | not exploitable and this was most of the times due to language limitations where for example you 1161.17s - 1167.17s | cannot have large enough strings or buffers that would be more than four gigabytes so the length 1167.17s - 1171.97s | would never overflow the four byte length field and we're going to look into these language 1171.97s - 1179.09s | differences later so short disclosure timeline for transparency we send out the advisories in 1179.09s - 1186.61s | february this year then pgx fixed in march and pgsql fixed in may and for a pg and pg driver 1186.61s - 1193.49s | the maintainer first responded to our advisory but then stopped and didn't implement fixes until now 1193.49s - 1198.37s | and for pq we couldn't even reach the maintainers we tried to do it via their github made an issue 1198.37s - 1204.93s | or made a pull request with the fix but they got no attention unfortunately so now let's go from 1204.93s - 1210.37s | vulnerable libraries to exploitable applications so first we have a set of applications that 1210.37s - 1216.13s | use these libraries or have used libraries in a vulnerable version um and these for example 1216.13s - 1221.57s | include grafana or gitty or sync thing but we weren't able to confirm if there's an exploitable 1221.57s - 1228.53s | path here so there might be


chunk_id: 150_chunk_22
chunk_text:
the length 1167.17s - 1171.97s | would never overflow the four byte length field and we're going to look into these language 1171.97s - 1179.09s | differences later so short disclosure timeline for transparency we send out the advisories in 1179.09s - 1186.61s | february this year then pgx fixed in march and pgsql fixed in may and for a pg and pg driver 1186.61s - 1193.49s | the maintainer first responded to our advisory but then stopped and didn't implement fixes until now 1193.49s - 1198.37s | and for pq we couldn't even reach the maintainers we tried to do it via their github made an issue 1198.37s - 1204.93s | or made a pull request with the fix but they got no attention unfortunately so now let's go from 1204.93s - 1210.37s | vulnerable libraries to exploitable applications so first we have a set of applications that 1210.37s - 1216.13s | use these libraries or have used libraries in a vulnerable version um and these for example 1216.13s - 1221.57s | include grafana or gitty or sync thing but we weren't able to confirm if there's an exploitable 1221.57s - 1228.53s | path here so there might be but we haven't proven it yet and then there's a set of applications 1228.53s - 1235.25s | that we found to be vulnerable in a non-default configuration for example metamost or gox and then 1235.25s - 1241.49s | there was also the sweet spot which is applications that are vulnerable in the default config and our 1241.49s - 1248.05s | example here was harbor and harbor is a container registry it's a cncf graduate project which means 1248.05s - 1254.13s | it's quite mature and people are using it it's also apparently part of vmware tanzu kubernetes 1254.13s - 1258.77s | but we didn't look into more of that so we don't know if it's exploitable in that scenario as well 1259.73s - 1266.45s | but in its default version it's vulnerable in the default configuration and also pre-authentication 1266.45s - 1273.25s | which is quite bad so they fixed this in version 2.11 which is the latest one by updating their 1273.25s - 1278.45s | dependency so if you have a harbor instance you definitely should update to the latest version 1279.25s - 1285.57s | and i'm going to try to demo the harbor exploit now i'm going to


chunk_id: 150_chunk_23
chunk_text:
but we haven't proven it yet and then there's a set of applications 1228.53s - 1235.25s | that we found to be vulnerable in a non-default configuration for example metamost or gox and then 1235.25s - 1241.49s | there was also the sweet spot which is applications that are vulnerable in the default config and our 1241.49s - 1248.05s | example here was harbor and harbor is a container registry it's a cncf graduate project which means 1248.05s - 1254.13s | it's quite mature and people are using it it's also apparently part of vmware tanzu kubernetes 1254.13s - 1258.77s | but we didn't look into more of that so we don't know if it's exploitable in that scenario as well 1259.73s - 1266.45s | but in its default version it's vulnerable in the default configuration and also pre-authentication 1266.45s - 1273.25s | which is quite bad so they fixed this in version 2.11 which is the latest one by updating their 1273.25s - 1278.45s | dependency so if you have a harbor instance you definitely should update to the latest version 1279.25s - 1285.57s | and i'm going to try to demo the harbor exploit now i'm going to try to do it live i also have a 1285.57s - 1295.33s | backup video um but let's see so first i will try to log in as the attacker to show that there should 1295.33s - 1302.53s | be no attacker user as you can see the login doesn't work so now if we start the exploit 1303.17s - 1311.97s | and i hope this works over the unstable internet um we have to wait a bit so there we see the query 1311.97s - 1316.69s | that the exploit is sending this is an insert query that will insert the attacker user into the 1316.69s - 1322.69s | database so then we could log in and as we can see it's sending a lot of bytes four gigabytes 1322.69s - 1329.41s | so it takes some time and if it works successfully then we should be able to log in 1329.41s - 1336.21s | and have administrative privileges in the hardware application so that we then could send our mess 1336.21s - 1341.41s | with the containers in there so we saw an error which is expected here so if i now try to log in 1341.41s -


chunk_id: 150_chunk_24
chunk_text:
try to do it live i also have a 1285.57s - 1295.33s | backup video um but let's see so first i will try to log in as the attacker to show that there should 1295.33s - 1302.53s | be no attacker user as you can see the login doesn't work so now if we start the exploit 1303.17s - 1311.97s | and i hope this works over the unstable internet um we have to wait a bit so there we see the query 1311.97s - 1316.69s | that the exploit is sending this is an insert query that will insert the attacker user into the 1316.69s - 1322.69s | database so then we could log in and as we can see it's sending a lot of bytes four gigabytes 1322.69s - 1329.41s | so it takes some time and if it works successfully then we should be able to log in 1329.41s - 1336.21s | and have administrative privileges in the hardware application so that we then could send our mess 1336.21s - 1341.41s | with the containers in there so we saw an error which is expected here so if i now try to log in 1341.41s - 1351.52s | again we should log in successfully i hope okay it doesn't seem to work i have to switch to the 1351.52s - 1362.91s | backup video and there on the left now we try to log in again and there we can see we can now log 1362.91s - 1376.22s | in and have admin privileges all right that was postgres now also let's look at mongodb to show 1376.22s - 1383.58s | that it's not a postgres and go only problem so to look back this is what a message in mongodb 1383.58s - 1388.70s | looks like we have a four byte length field this time it's little endian then we have two metadata 1388.70s - 1393.26s | fields that are not relevant here and then we have the opcode which is like the message type 1393.26s - 1397.82s | and then the value is a complex binary structure that's called bison which i think stands for 1397.82s - 1404.38s | binary json and it's some nested data that's serialized to tlv sections so they also have 1404.38s - 1410.22s | lengths again and to directly look at some code it's a little bit more but


chunk_id: 150_chunk_25
chunk_text:
1351.52s | again we should log in successfully i hope okay it doesn't seem to work i have to switch to the 1351.52s - 1362.91s | backup video and there on the left now we try to log in again and there we can see we can now log 1362.91s - 1376.22s | in and have admin privileges all right that was postgres now also let's look at mongodb to show 1376.22s - 1383.58s | that it's not a postgres and go only problem so to look back this is what a message in mongodb 1383.58s - 1388.70s | looks like we have a four byte length field this time it's little endian then we have two metadata 1388.70s - 1393.26s | fields that are not relevant here and then we have the opcode which is like the message type 1393.26s - 1397.82s | and then the value is a complex binary structure that's called bison which i think stands for 1397.82s - 1404.38s | binary json and it's some nested data that's serialized to tlv sections so they also have 1404.38s - 1410.22s | lengths again and to directly look at some code it's a little bit more but i'm gonna walk you 1410.22s - 1416.54s | through it we first have a line here that takes the content bytes so it takes the query and puts 1416.54s - 1423.74s | it into this bison representation then it computes the total length of the message by adding the 1423.74s - 1430.62s | header length and and so on and this is saved as a type u size variable again on most modern systems 1430.62s - 1438.54s | this is a 64-bit integer and then again this is truncated explicitly to an int32 because that what 1438.54s - 1444.46s | fits into the field so the developer had to cut it down here but of course this is the same issue 1444.46s - 1450.62s | as before if the length was larger what can then what can be expressed here um we have our 1450.62s - 1458.62s | truncation and things go wrong the exact same way as it did for postgres so for crafting a payload 1458.62s - 1464.06s | for mongodb it's a little bit more involved because we have to avoid bad bytes the payload 1464.62s - 1470.54s | must be valid utf-8 because the strings are


chunk_id: 150_chunk_26
chunk_text:
i'm gonna walk you 1410.22s - 1416.54s | through it we first have a line here that takes the content bytes so it takes the query and puts 1416.54s - 1423.74s | it into this bison representation then it computes the total length of the message by adding the 1423.74s - 1430.62s | header length and and so on and this is saved as a type u size variable again on most modern systems 1430.62s - 1438.54s | this is a 64-bit integer and then again this is truncated explicitly to an int32 because that what 1438.54s - 1444.46s | fits into the field so the developer had to cut it down here but of course this is the same issue 1444.46s - 1450.62s | as before if the length was larger what can then what can be expressed here um we have our 1450.62s - 1458.62s | truncation and things go wrong the exact same way as it did for postgres so for crafting a payload 1458.62s - 1464.06s | for mongodb it's a little bit more involved because we have to avoid bad bytes the payload 1464.62s - 1470.54s | must be valid utf-8 because the strings are serialized as utf-8 to the wire so we cannot 1470.54s - 1476.54s | create any bytes that are invalid utf-8 but the problem is the message type that we need to write 1476.54s - 1483.50s | in order to craft the right injected message is 0xdd07 and that's always invalid utf-8 so 1483.50s - 1490.94s | how can we do that and also size fields inside the message could become some byte values that 1490.94s - 1495.82s | would also be invalid utf-8 so we have to be careful there as well and the solution was to 1495.82s - 1502.54s | just use other metadata of the message we're injecting into to create these byte values and i 1502.54s - 1508.14s | have an example for that so this is a normal mongodb query it just queries for a movie based 1508.14s - 1514.70s | on a few attributes and this is serialized to the following bson document in the beginning we have 1514.70s - 1521.02s | in blue the length of the whole document then in red we have a type identifier that says the next 1521.02s - 1528.22s | key value pair has a string value then in


chunk_id: 150_chunk_27
chunk_text:
serialized as utf-8 to the wire so we cannot 1470.54s - 1476.54s | create any bytes that are invalid utf-8 but the problem is the message type that we need to write 1476.54s - 1483.50s | in order to craft the right injected message is 0xdd07 and that's always invalid utf-8 so 1483.50s - 1490.94s | how can we do that and also size fields inside the message could become some byte values that 1490.94s - 1495.82s | would also be invalid utf-8 so we have to be careful there as well and the solution was to 1495.82s - 1502.54s | just use other metadata of the message we're injecting into to create these byte values and i 1502.54s - 1508.14s | have an example for that so this is a normal mongodb query it just queries for a movie based 1508.14s - 1514.70s | on a few attributes and this is serialized to the following bson document in the beginning we have 1514.70s - 1521.02s | in blue the length of the whole document then in red we have a type identifier that says the next 1521.02s - 1528.22s | key value pair has a string value then in yellow we have the key which in this case is title with 1528.22s - 1533.50s | a trailing null byte then in blue again we have the length of the following string and then in 1533.50s - 1538.86s | green we have the actual string with a terminating null byte then we have the next key value pairs 1538.86s - 1544.30s | and so on and at the end we have another null byte that shows the end of the document so if we want 1544.30s - 1551.26s | to have the hex sequence dd07 anywhere in here we cannot use the yellow and green parts because 1551.26s - 1558.14s | they have to be a valid utf-8 but what we can do is for example use the length of a string and just 1558.14s - 1565.50s | make the string the length that will when serialized to bytes will be the exact byte sequence we need 1565.50s - 1571.58s | so here we need to subtract one because there's a appended null byte but then we have the dd07 1571.58s - 1578.06s | there and with this trick now we can craft the entire injected message i cannot go


chunk_id: 150_chunk_28
chunk_text:
yellow we have the key which in this case is title with 1528.22s - 1533.50s | a trailing null byte then in blue again we have the length of the following string and then in 1533.50s - 1538.86s | green we have the actual string with a terminating null byte then we have the next key value pairs 1538.86s - 1544.30s | and so on and at the end we have another null byte that shows the end of the document so if we want 1544.30s - 1551.26s | to have the hex sequence dd07 anywhere in here we cannot use the yellow and green parts because 1551.26s - 1558.14s | they have to be a valid utf-8 but what we can do is for example use the length of a string and just 1558.14s - 1565.50s | make the string the length that will when serialized to bytes will be the exact byte sequence we need 1565.50s - 1571.58s | so here we need to subtract one because there's a appended null byte but then we have the dd07 1571.58s - 1578.06s | there and with this trick now we can craft the entire injected message i cannot go into all of 1578.06s - 1582.46s | this here because we don't have time but this is the trick you need to be able to do it 1584.30s - 1590.86s | so we also looked at libraries here and uh we found the official rust mongodb client library 1590.86s - 1597.18s | to be vulnerable and exploitable we sent out our advisory also in february and they fixed in march 1597.18s - 1601.66s | so if you use this especially if you use it in production which i doubt because it's rust 1601.66s - 1610.05s | but then you should update to 2.8.2 okay let's now take a step back we've seen all the cool 1610.05s - 1616.13s | bugs and the exploitation but is this actually applicable to the real world we've seen the demo 1616.13s - 1621.57s | but maybe this was just a lucky punch so let's talk about constraints and especially about the 1621.57s - 1627.25s | elephant in the room which here weighs four gigabytes because a lot of you probably are 1627.33s - 1633.49s | thinking well can we actually send four gigabytes into all the applications aren't apps limiting 1633.49s - 1639.33s |


chunk_id: 150_chunk_29
chunk_text:
into all of 1578.06s - 1582.46s | this here because we don't have time but this is the trick you need to be able to do it 1584.30s - 1590.86s | so we also looked at libraries here and uh we found the official rust mongodb client library 1590.86s - 1597.18s | to be vulnerable and exploitable we sent out our advisory also in february and they fixed in march 1597.18s - 1601.66s | so if you use this especially if you use it in production which i doubt because it's rust 1601.66s - 1610.05s | but then you should update to 2.8.2 okay let's now take a step back we've seen all the cool 1610.05s - 1616.13s | bugs and the exploitation but is this actually applicable to the real world we've seen the demo 1616.13s - 1621.57s | but maybe this was just a lucky punch so let's talk about constraints and especially about the 1621.57s - 1627.25s | elephant in the room which here weighs four gigabytes because a lot of you probably are 1627.33s - 1633.49s | thinking well can we actually send four gigabytes into all the applications aren't apps limiting 1633.49s - 1639.33s | input sizes and you would be right now there's a lot of common protections like default body size 1639.33s - 1645.33s | limits of your favorite web framework or maybe json and forum decode maximum sizes or you have 1645.33s - 1652.13s | your reverse proxy that's limiting request size and so on and i also encountered this and thought 1652.13s - 1657.49s | about some potential bypasses here so the first idea is that sometimes endpoints are just 1657.49s - 1663.89s | unprotected so maybe your framework doesn't have a default size limit and also sometimes the 1663.89s - 1669.25s | developers explicitly disable the limits this was the case with harbor for example they have an 1669.25s - 1675.65s | nginx reverse proxy which usually has a one megabyte request limit but they explicitly disabled 1675.65s - 1681.73s | it i guess because they need to receive big docker images so they need more uh request size but this 1681.73s - 1687.73s | also meant that the whole api is now not limited anymore and the goal framework that's used under 1687.73s - 1694.69s | the hood of the server did not limit this so we could send


chunk_id: 150_chunk_30
chunk_text:
input sizes and you would be right now there's a lot of common protections like default body size 1639.33s - 1645.33s | limits of your favorite web framework or maybe json and forum decode maximum sizes or you have 1645.33s - 1652.13s | your reverse proxy that's limiting request size and so on and i also encountered this and thought 1652.13s - 1657.49s | about some potential bypasses here so the first idea is that sometimes endpoints are just 1657.49s - 1663.89s | unprotected so maybe your framework doesn't have a default size limit and also sometimes the 1663.89s - 1669.25s | developers explicitly disable the limits this was the case with harbor for example they have an 1669.25s - 1675.65s | nginx reverse proxy which usually has a one megabyte request limit but they explicitly disabled 1675.65s - 1681.73s | it i guess because they need to receive big docker images so they need more uh request size but this 1681.73s - 1687.73s | also meant that the whole api is now not limited anymore and the goal framework that's used under 1687.73s - 1694.69s | the hood of the server did not limit this so we could send our big payload the next trick would 1694.69s - 1700.61s | be to use compression this on the one hand allows you to send your attacker payload much quicker 1700.61s - 1704.61s | because you can compress it down and don't have to send four gigabytes over the internet 1705.33s - 1709.33s | and also there can be logic bugs where maybe your reverse proxy or your framework 1709.89s - 1716.45s | first checks the request size but does the decompression after that so the check is 1716.45s - 1723.49s | essentially useless because your compressed data will inflate a lot and you can craft a big 1723.49s - 1729.09s | payload that after decompression still causes the overflow so for nginx for example this works 1729.09s - 1733.89s | because nginx does not look at the body it doesn't try to decompress it it just looks at the raw 1733.89s - 1739.97s | size of the request so if your backend does decompression then you could bypass this and 1739.97s - 1745.97s | also for example the javascript fastify framework does both checks the body size and also does the 1745.97s - 1752.29s | decompression but it does it


chunk_id: 150_chunk_31
chunk_text:
our big payload the next trick would 1694.69s - 1700.61s | be to use compression this on the one hand allows you to send your attacker payload much quicker 1700.61s - 1704.61s | because you can compress it down and don't have to send four gigabytes over the internet 1705.33s - 1709.33s | and also there can be logic bugs where maybe your reverse proxy or your framework 1709.89s - 1716.45s | first checks the request size but does the decompression after that so the check is 1716.45s - 1723.49s | essentially useless because your compressed data will inflate a lot and you can craft a big 1723.49s - 1729.09s | payload that after decompression still causes the overflow so for nginx for example this works 1729.09s - 1733.89s | because nginx does not look at the body it doesn't try to decompress it it just looks at the raw 1733.89s - 1739.97s | size of the request so if your backend does decompression then you could bypass this and 1739.97s - 1745.97s | also for example the javascript fastify framework does both checks the body size and also does the 1745.97s - 1752.29s | decompression but it does it in the wrong order so you can bypass the limit then you might also 1752.29s - 1758.45s | have websockets support on the server of your target this is cool because websockets also in 1758.45s - 1764.05s | theory supports compression it's not always enabled but it can help you but even without 1764.05s - 1771.73s | that a single websocket request can be super large i think it's a 64-bit integer the size field so 1772.53s - 1777.97s | you can definitely send four gigabyte messages with that and maybe the middlewares and filters 1777.97s - 1783.73s | that are present in your framework don't apply to each individual websocket message so maybe there's 1783.73s - 1791.01s | no limit there then you could also use alternate body types for example a multi-part form instead 1791.01s - 1796.93s | of a json body and maybe the limits are different there or the developer forgot to configure a limit 1796.93s - 1803.09s | so this could be another bypass and then this one which i like the most is a little bit more 1803.09s - 1808.61s | creative and open which i call server-side creation which is you just find


chunk_id: 150_chunk_32
chunk_text:
in the wrong order so you can bypass the limit then you might also 1752.29s - 1758.45s | have websockets support on the server of your target this is cool because websockets also in 1758.45s - 1764.05s | theory supports compression it's not always enabled but it can help you but even without 1764.05s - 1771.73s | that a single websocket request can be super large i think it's a 64-bit integer the size field so 1772.53s - 1777.97s | you can definitely send four gigabyte messages with that and maybe the middlewares and filters 1777.97s - 1783.73s | that are present in your framework don't apply to each individual websocket message so maybe there's 1783.73s - 1791.01s | no limit there then you could also use alternate body types for example a multi-part form instead 1791.01s - 1796.93s | of a json body and maybe the limits are different there or the developer forgot to configure a limit 1796.93s - 1803.09s | so this could be another bypass and then this one which i like the most is a little bit more 1803.09s - 1808.61s | creative and open which i call server-side creation which is you just find other means of 1808.61s - 1814.77s | bringing a big string to the server without sending it in your requests and one example is 1814.77s - 1821.49s | ssrf where you point some functionality of the server to an attacker server which then returns 1821.49s - 1826.21s | a very large response and if this one gets saved into the database or used in a query 1826.77s - 1831.97s | it will also cause the overflow and this for example worked in gogs where you have a webhooks 1831.97s - 1838.37s | feature but beyond the ssrf you might also have templating or translation that you could use to 1838.37s - 1843.73s | inflate a string and this all depends on the business logic and the features of the server 1843.73s - 1850.18s | so that's where you can get creative to find bypasses all right now that we've seen how we 1850.18s - 1855.94s | might bypass limitations of frameworks and servers we also need to look at languages we already seen 1855.94s - 1861.78s | some differences at the vulnerable libraries so we need to see how well languages handle large 1861.78s - 1867.38s | payloads like how


chunk_id: 150_chunk_33
chunk_text:
other means of 1808.61s - 1814.77s | bringing a big string to the server without sending it in your requests and one example is 1814.77s - 1821.49s | ssrf where you point some functionality of the server to an attacker server which then returns 1821.49s - 1826.21s | a very large response and if this one gets saved into the database or used in a query 1826.77s - 1831.97s | it will also cause the overflow and this for example worked in gogs where you have a webhooks 1831.97s - 1838.37s | feature but beyond the ssrf you might also have templating or translation that you could use to 1838.37s - 1843.73s | inflate a string and this all depends on the business logic and the features of the server 1843.73s - 1850.18s | so that's where you can get creative to find bypasses all right now that we've seen how we 1850.18s - 1855.94s | might bypass limitations of frameworks and servers we also need to look at languages we already seen 1855.94s - 1861.78s | some differences at the vulnerable libraries so we need to see how well languages handle large 1861.78s - 1867.38s | payloads like how big can strings and buffers be and also what about integer overflows does 1867.38s - 1873.54s | every language have silent integer overflows or maybe some languages are safe so for the large 1873.54s - 1880.10s | payloads we can see that go python and rust out of the languages we we looked at uh have large 1880.10s - 1887.14s | enough string and buffer sizes that you can send four gigabytes and they can handle it for java 1887.14s - 1893.38s | you're out of luck and we also saw see the song seen this with unexploitable libraries in java 1894.26s - 1901.22s | and that's because strings and buffers here are backed by arrays which have integer indexes so you 1901.22s - 1909.22s | cannot index more than i think yeah two to the power of 31 here for c sharp the string size is 1909.22s - 1915.14s | not big enough but the buffer size is so if you have multiple strings that you control then you 1915.14s - 1920.98s | can still end up with a buffer that becomes bigger than four gigabytes and for javascript it totally 1920.98s - 1926.34s | depends on the implementation


chunk_id: 150_chunk_34
chunk_text:
big can strings and buffers be and also what about integer overflows does 1867.38s - 1873.54s | every language have silent integer overflows or maybe some languages are safe so for the large 1873.54s - 1880.10s | payloads we can see that go python and rust out of the languages we we looked at uh have large 1880.10s - 1887.14s | enough string and buffer sizes that you can send four gigabytes and they can handle it for java 1887.14s - 1893.38s | you're out of luck and we also saw see the song seen this with unexploitable libraries in java 1894.26s - 1901.22s | and that's because strings and buffers here are backed by arrays which have integer indexes so you 1901.22s - 1909.22s | cannot index more than i think yeah two to the power of 31 here for c sharp the string size is 1909.22s - 1915.14s | not big enough but the buffer size is so if you have multiple strings that you control then you 1915.14s - 1920.98s | can still end up with a buffer that becomes bigger than four gigabytes and for javascript it totally 1920.98s - 1926.34s | depends on the implementation for node strings are much smaller compared to the other languages 1926.34s - 1934.88s | but buffers can be large enough for integer overflows we can see that for addition overflows 1934.88s - 1941.92s | which just means you add two integers and we can see that in go java and c sharp c sharp a silent 1941.92s - 1948.16s | integer overflow happens so it will just wrap around for javascript there will be no overflow 1948.16s - 1952.96s | things will just get more inaccurate because it's javascript and they use floats under the hood 1954.00s - 1961.20s | and in python you have arbitrarily sized integers so you cannot overflow that and in rust it depends 1961.20s - 1966.00s | on how you build your project if you build it in debug mode the compiler will emit a 1966.64s - 1970.00s | check that checks for overflows but in a release build it will not do that 1970.00s - 1978.40s | and for serialization overflows which basically is the case when you have a standard function in 1978.40s - 1985.36s | your language that allows you to write a integer to a fixed size field does this


chunk_id: 150_chunk_35
chunk_text:
for node strings are much smaller compared to the other languages 1926.34s - 1934.88s | but buffers can be large enough for integer overflows we can see that for addition overflows 1934.88s - 1941.92s | which just means you add two integers and we can see that in go java and c sharp c sharp a silent 1941.92s - 1948.16s | integer overflow happens so it will just wrap around for javascript there will be no overflow 1948.16s - 1952.96s | things will just get more inaccurate because it's javascript and they use floats under the hood 1954.00s - 1961.20s | and in python you have arbitrarily sized integers so you cannot overflow that and in rust it depends 1961.20s - 1966.00s | on how you build your project if you build it in debug mode the compiler will emit a 1966.64s - 1970.00s | check that checks for overflows but in a release build it will not do that 1970.00s - 1978.40s | and for serialization overflows which basically is the case when you have a standard function in 1978.40s - 1985.36s | your language that allows you to write a integer to a fixed size field does this function check 1985.36s - 1990.48s | for overflows or not and in all of the type safe languages this does not does not apply because 1990.48s - 1997.60s | the types that the function can receive cannot overflow the size field or the field that it 1997.60s - 2003.20s | gets serialized to but this just means that the developers now have to do the check before 2003.20s - 2009.60s | casting to this type and we've seen that this leads to bugs in our go and rust examples in 2009.60s - 2015.76s | javascript it's again implementation dependent i think in node.js it does the check but in 2015.76s - 2023.44s | bun or dino it might not do it and in python the struct.pack function actually does a check if you 2023.44s - 2028.32s | pass a too large integer it will throw an error if you try to serialize it to a too small field 2030.08s - 2036.64s | so to summarize the real world applicability we can say that in a lot of times we can send large 2036.64s - 2045.44s | payloads past the limits for silent integer overflows or truncations we also seen that


chunk_id: 150_chunk_36
chunk_text:
function check 1985.36s - 1990.48s | for overflows or not and in all of the type safe languages this does not does not apply because 1990.48s - 1997.60s | the types that the function can receive cannot overflow the size field or the field that it 1997.60s - 2003.20s | gets serialized to but this just means that the developers now have to do the check before 2003.20s - 2009.60s | casting to this type and we've seen that this leads to bugs in our go and rust examples in 2009.60s - 2015.76s | javascript it's again implementation dependent i think in node.js it does the check but in 2015.76s - 2023.44s | bun or dino it might not do it and in python the struct.pack function actually does a check if you 2023.44s - 2028.32s | pass a too large integer it will throw an error if you try to serialize it to a too small field 2030.08s - 2036.64s | so to summarize the real world applicability we can say that in a lot of times we can send large 2036.64s - 2045.44s | payloads past the limits for silent integer overflows or truncations we also seen that in 2045.44s - 2051.84s | many languages it works or the developers do the mistake for the language and we also seen that you 2051.84s - 2060.26s | can definitely exploit some real world applications with this all right now let's look at what is 2060.26s - 2066.58s | there more to do in this kind of research for binary protocol smuggling but first i have to 2066.58s - 2072.66s | give a small disclaimer here please don't go out and send four gigabytes to every api endpoint in 2072.66s - 2077.46s | your bug bounty scope because you will crash systems you will get blocked and you will ruin 2077.46s - 2082.98s | a devops engineer's day because they have to look at the monitoring alert so don't do it please 2084.34s - 2090.58s | but speaking of this it would be cool to actually have a non-invasive detection mechanism 2090.58s - 2095.46s | in white box tests it's okay you can make your local testing environment and just hammer it with 2095.46s - 2102.10s | gigabytes of data but of course in black box tests that doesn't work so if we could find a methodology 2102.10s - 2107.94s


chunk_id: 150_chunk_37
chunk_text:
in 2045.44s - 2051.84s | many languages it works or the developers do the mistake for the language and we also seen that you 2051.84s - 2060.26s | can definitely exploit some real world applications with this all right now let's look at what is 2060.26s - 2066.58s | there more to do in this kind of research for binary protocol smuggling but first i have to 2066.58s - 2072.66s | give a small disclaimer here please don't go out and send four gigabytes to every api endpoint in 2072.66s - 2077.46s | your bug bounty scope because you will crash systems you will get blocked and you will ruin 2077.46s - 2082.98s | a devops engineer's day because they have to look at the monitoring alert so don't do it please 2084.34s - 2090.58s | but speaking of this it would be cool to actually have a non-invasive detection mechanism 2090.58s - 2095.46s | in white box tests it's okay you can make your local testing environment and just hammer it with 2095.46s - 2102.10s | gigabytes of data but of course in black box tests that doesn't work so if we could find a methodology 2102.10s - 2107.94s | to find for example a fingerprint of a database client library being used and we would know that 2107.94s - 2113.94s | this library is vulnerable to these kind of texts then we could either directly report it or only do 2113.94s - 2121.30s | the large payload then and if this would be a tool it would be great to aid you in pen tests and so on 2123.14s - 2129.22s | and of course it would be awesome to research a lot of more stuff more protocols like there's 2129.22s - 2134.10s | more databases than we stuff then stuff we looked at today and there's all of the other systems 2134.10s - 2139.94s | caches message queues and so on that the application has to talk to we can also try 2139.94s - 2144.90s | to find more decent techniques for example look into protocols that use delimiters and not size 2144.90s - 2152.26s | fields and we can also find more large payload message which is ways to bypass the filters of 2152.26s - 2159.46s | a framework for example to bypass the request size limits or maybe we can find generic ways 2159.46s -


chunk_id: 150_chunk_38
chunk_text:
| to find for example a fingerprint of a database client library being used and we would know that 2107.94s - 2113.94s | this library is vulnerable to these kind of texts then we could either directly report it or only do 2113.94s - 2121.30s | the large payload then and if this would be a tool it would be great to aid you in pen tests and so on 2123.14s - 2129.22s | and of course it would be awesome to research a lot of more stuff more protocols like there's 2129.22s - 2134.10s | more databases than we stuff then stuff we looked at today and there's all of the other systems 2134.10s - 2139.94s | caches message queues and so on that the application has to talk to we can also try 2139.94s - 2144.90s | to find more decent techniques for example look into protocols that use delimiters and not size 2144.90s - 2152.26s | fields and we can also find more large payload message which is ways to bypass the filters of 2152.26s - 2159.46s | a framework for example to bypass the request size limits or maybe we can find generic ways 2159.46s - 2165.54s | of making a server craft a very large string maybe there's some way to do this 2167.62s - 2173.46s | and of course all of the stuff we looked at today had four bytes length fields but what about two 2173.46s - 2179.46s | byte length fields this would be much easier to exploit sending 65 kilobytes instead of four 2179.46s - 2187.54s | gigabytes is much easier you don't have the hassle with all the limitations and i already already 2187.54s - 2192.34s | started to look into this a little bit so stay tuned for more to come in the future but feel 2192.34s - 2201.76s | free to also go out and check this yourself so let's wrap things up i have a few takeaways and 2201.76s - 2207.68s | the first one is that i think integer overflows are still relevant in memory safe languages of 2207.68s - 2214.00s | course in c if you have an integer overflow it's easily easy to get some memory corruption with it 2214.00s - 2220.56s | so uh that's done but in memory safe languages um the worst case that can happen is a array out 2220.56s


chunk_id: 150_chunk_39
chunk_text:
2165.54s | of making a server craft a very large string maybe there's some way to do this 2167.62s - 2173.46s | and of course all of the stuff we looked at today had four bytes length fields but what about two 2173.46s - 2179.46s | byte length fields this would be much easier to exploit sending 65 kilobytes instead of four 2179.46s - 2187.54s | gigabytes is much easier you don't have the hassle with all the limitations and i already already 2187.54s - 2192.34s | started to look into this a little bit so stay tuned for more to come in the future but feel 2192.34s - 2201.76s | free to also go out and check this yourself so let's wrap things up i have a few takeaways and 2201.76s - 2207.68s | the first one is that i think integer overflows are still relevant in memory safe languages of 2207.68s - 2214.00s | course in c if you have an integer overflow it's easily easy to get some memory corruption with it 2214.00s - 2220.56s | so uh that's done but in memory safe languages um the worst case that can happen is a array out 2220.56s - 2227.04s | of bounds or whatever but with these data attacks in the binary protocols that we've seen today 2227.84s - 2233.04s | now we have a new way of exploiting these and i think developers kind of forgot about integer 2233.04s - 2239.28s | overflows and maybe researchers as well at least in the memory safe languages then we also seen 2239.28s - 2246.56s | that it's entirely feasible to send large amounts of data even with protections because there's many 2246.56s - 2253.04s | ways how you can bypass these protections and finally to get back to the title sql injection 2253.04s - 2259.44s | isn't dead of course it was never dead at least not in the real world we've seen a lot of real 2259.44s - 2266.16s | world applications uh and with sql injections but on paper you could say uh developers have the right 2266.16s - 2273.04s | tools to write secure sql based applications they have parameterized queries they have 2273.04s - 2278.32s | query builders they have orms so if they use all of this and the application is safe 2278.88s - 2284.00s | so if you can't hack it you


chunk_id: 150_chunk_40
chunk_text:
- 2227.04s | of bounds or whatever but with these data attacks in the binary protocols that we've seen today 2227.84s - 2233.04s | now we have a new way of exploiting these and i think developers kind of forgot about integer 2233.04s - 2239.28s | overflows and maybe researchers as well at least in the memory safe languages then we also seen 2239.28s - 2246.56s | that it's entirely feasible to send large amounts of data even with protections because there's many 2246.56s - 2253.04s | ways how you can bypass these protections and finally to get back to the title sql injection 2253.04s - 2259.44s | isn't dead of course it was never dead at least not in the real world we've seen a lot of real 2259.44s - 2266.16s | world applications uh and with sql injections but on paper you could say uh developers have the right 2266.16s - 2273.04s | tools to write secure sql based applications they have parameterized queries they have 2273.04s - 2278.32s | query builders they have orms so if they use all of this and the application is safe 2278.88s - 2284.00s | so if you can't hack it you just have to go a level deeper thank you


chunk_id: 151_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=QXa29AJqdRc", "title": "DEF CON 32 - Reverse Engineering MicroPython Frozen Modules - Wesley McGrew", "description": "MicroPython is a firmware environment for quickly developing and deploying software onto microcontroller systems. It is used in a variety of industrial and scientific applications, as well as (most importantly) in some DEF CON #badgelife projects. It's easy to learn and use for rapid prototyping.\n\nFor hackers interested in reverse engineering compiled or obfuscated MicroPython code, there are some obstacles. MicroPython is an implementation of CPython, not a port, so it has its own compiled bytecode language that existing reverse engineering tools aren't designed to parse. Also, modules can be \"frozen\", compiled directly into the microcontroller firmware, and may be difficult to locate and parse when microcontroller firmware is extracted and analyzed.\n\nIn this talk, Wesley will walk the audience through the process of identifying \"frozen\"/compiled modules in a firmware image without debug symbols using the Ghidra disassembler. The relevant module, string, object, and raw code data structures will be detailed, so that everything required to rebuild a non-frozen module can recovered. Once a compiled module is reconstructed, Wesley will present a detailed example of reading and understanding MicroPython compiled bytecode, for the purpose of reverse engineering the purpose and implementation of the module.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2602, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.91s - 6.71s | This text was transcribed using whisper model: large-v2 Thank you for showing up everybody. I appreciate this. I know that I'm on opposite of Pony Awards 6.71s - 10.31s | So if you're here for Pony Awards, you're in the right place 10.91s - 13.11s | So this is a reverse engineering 13.99s - 20.95s | MicroPython frozen modules. My name is Wesley McGrew. I'm senior cyber fellow with Martin Federal and 22.07s - 24.99s | This is talk is going to be a lot of fun for 25.71s - 29.39s | Those of you who like to hack on badge life stuff a lot of badge life 30.31s - 32.31s | Badges use this 33.11s - 35.11s | Python interpreter and 36.11s - 37.87s | we're able to 37.87s - 40.95s | Pick out some things that perhaps you wouldn't have otherwise 41.79s - 46.41s | So the agenda for the talk we're going to be 47.67s - 51.07s | We're going to introduce what micro Python is for those of you not familiar 51.07s


chunk_id: 151_chunk_1
chunk_text:
reverse engineering the purpose and implementation of the module.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2602, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.91s - 6.71s | This text was transcribed using whisper model: large-v2 Thank you for showing up everybody. I appreciate this. I know that I'm on opposite of Pony Awards 6.71s - 10.31s | So if you're here for Pony Awards, you're in the right place 10.91s - 13.11s | So this is a reverse engineering 13.99s - 20.95s | MicroPython frozen modules. My name is Wesley McGrew. I'm senior cyber fellow with Martin Federal and 22.07s - 24.99s | This is talk is going to be a lot of fun for 25.71s - 29.39s | Those of you who like to hack on badge life stuff a lot of badge life 30.31s - 32.31s | Badges use this 33.11s - 35.11s | Python interpreter and 36.11s - 37.87s | we're able to 37.87s - 40.95s | Pick out some things that perhaps you wouldn't have otherwise 41.79s - 46.41s | So the agenda for the talk we're going to be 47.67s - 51.07s | We're going to introduce what micro Python is for those of you not familiar 51.07s - 54.93s | I'm pretty sure most of you know about Python in general 55.39s - 60.71s | we're going to look at micro Python firmware on the Raspberry Pi Pico, so 61.63s - 68.43s | It's available for a lot of different microcontrollers, but Pico is probably the easiest for you to set up experimentation in your lab with 69.15s - 71.15s | we're going to build a 71.95s - 73.95s | Hello world 74.07s - 75.75s | module for it and 75.75s - 81.55s | We're going to compile it down into bytecode and then we're going to freeze it into the micro Python firmware itself 81.71s - 87.95s | So that it's harder for somebody to extract we're going to talk about that freezing process and why it's there 88.95s - 90.95s | We're going to have a hands-on example of 91.63s - 98.27s | Reconstructing that module from a compiled firmware. We're going to do it with symbols and without symbols, so 99.03s - 103.55s | Show you how to do it in an environment where somebody's trying to actively keep you from doing it 104.31s - 110.67s | We're going to do some analysis of


chunk_id: 151_chunk_2
chunk_text:
- 54.93s | I'm pretty sure most of you know about Python in general 55.39s - 60.71s | we're going to look at micro Python firmware on the Raspberry Pi Pico, so 61.63s - 68.43s | It's available for a lot of different microcontrollers, but Pico is probably the easiest for you to set up experimentation in your lab with 69.15s - 71.15s | we're going to build a 71.95s - 73.95s | Hello world 74.07s - 75.75s | module for it and 75.75s - 81.55s | We're going to compile it down into bytecode and then we're going to freeze it into the micro Python firmware itself 81.71s - 87.95s | So that it's harder for somebody to extract we're going to talk about that freezing process and why it's there 88.95s - 90.95s | We're going to have a hands-on example of 91.63s - 98.27s | Reconstructing that module from a compiled firmware. We're going to do it with symbols and without symbols, so 99.03s - 103.55s | Show you how to do it in an environment where somebody's trying to actively keep you from doing it 104.31s - 110.67s | We're going to do some analysis of that extracted module and come to some conclusions about what this means for reverse engineering it 111.11s - 117.81s | So micro Python is an implementation of Python 3 for microcontrollers 117.81s - 124.21s | And it's very interesting in that it's not a straight port of CPython CPython is the Python 124.33s - 130.73s | You're familiar with on your desktop system where or it's a compiled. It's an interpreter running 131.49s - 133.13s | bytecode 133.13s - 136.01s | based off of the Python code that you write and 138.09s - 142.89s | Micro Python completely just re-implements it from scratch and and I'm not 143.41s - 147.53s | There's probably reasons for doing that instead of starting from CPython 148.61s - 154.21s | Microcontrollers have limited resources and so things are optimized for that kind of environment 155.53s - 159.17s | There's a subset of Python standard libraries in there. There's not 159.93s - 165.29s | Libraries for some of the standard library stuff that doesn't make sense on microcontroller, but there's also some additional 166.05s - 167.93s | micro Python 167.93s - 175.09s | Only libraries there just for working with microcontroller hardware primarily like GPIO


chunk_id: 151_chunk_3
chunk_text:
that extracted module and come to some conclusions about what this means for reverse engineering it 111.11s - 117.81s | So micro Python is an implementation of Python 3 for microcontrollers 117.81s - 124.21s | And it's very interesting in that it's not a straight port of CPython CPython is the Python 124.33s - 130.73s | You're familiar with on your desktop system where or it's a compiled. It's an interpreter running 131.49s - 133.13s | bytecode 133.13s - 136.01s | based off of the Python code that you write and 138.09s - 142.89s | Micro Python completely just re-implements it from scratch and and I'm not 143.41s - 147.53s | There's probably reasons for doing that instead of starting from CPython 148.61s - 154.21s | Microcontrollers have limited resources and so things are optimized for that kind of environment 155.53s - 159.17s | There's a subset of Python standard libraries in there. There's not 159.93s - 165.29s | Libraries for some of the standard library stuff that doesn't make sense on microcontroller, but there's also some additional 166.05s - 167.93s | micro Python 167.93s - 175.09s | Only libraries there just for working with microcontroller hardware primarily like GPIO like turn pin one on 175.85s - 177.85s | Pull it low that sort of thing 178.25s - 181.01s | There is a rebel so a command line 181.41s - 186.17s | You're used to a Python where you can just start typing Python code and have it execute and sort of 186.29s - 188.29s | Play around with the Python environment 188.29s - 194.45s | You can do that with micro Python if you have a serial terminal on your microcontroller like you do with a Pico 196.21s - 203.29s | The use cases for it you don't I don't see it in anything that you can just like go to Lowe's and buy for home 203.45s - 210.69s | Automation, but you do see it in scientific application industrial applications you see it 211.01s - 218.01s | in badges and so like the last year's snacky badge at least use micro Python and 219.25s - 223.49s | specifically the frozen modules are used by a lot of folks to 224.17s - 228.09s | Have code cooked into the firmware itself. That's not in a 229.25s - 231.25s | module file on the file system 232.25s - 239.53s |


chunk_id: 151_chunk_4
chunk_text:
like turn pin one on 175.85s - 177.85s | Pull it low that sort of thing 178.25s - 181.01s | There is a rebel so a command line 181.41s - 186.17s | You're used to a Python where you can just start typing Python code and have it execute and sort of 186.29s - 188.29s | Play around with the Python environment 188.29s - 194.45s | You can do that with micro Python if you have a serial terminal on your microcontroller like you do with a Pico 196.21s - 203.29s | The use cases for it you don't I don't see it in anything that you can just like go to Lowe's and buy for home 203.45s - 210.69s | Automation, but you do see it in scientific application industrial applications you see it 211.01s - 218.01s | in badges and so like the last year's snacky badge at least use micro Python and 219.25s - 223.49s | specifically the frozen modules are used by a lot of folks to 224.17s - 228.09s | Have code cooked into the firmware itself. That's not in a 229.25s - 231.25s | module file on the file system 232.25s - 239.53s | It's really nice. So what I'm presenting here is not a mistake made with micro Python. It's just a reverse engineering talk 239.53s - 244.61s | There's no vulnerability here as my micro Python is concerned. I like it 244.61s - 249.73s | It's really easy to create a prototype of an embedded device with micro Python 250.33s - 253.85s | And so you have three choices for your code you can have 254.53s - 259.71s | Plain text that's on a small file system. That's in the emulated in part of your flash memory 260.59s - 264.23s | You can and you can read and write to that file system through the REPL 265.15s - 266.83s | you can 266.83s - 275.07s | have pre compiled byte code modules and we'll talk about the structure of those but then you can also take those pre compiled modules and 275.75s - 282.35s | Cook them into the file into the micro Python firmware at build time and that removes a lot of the metadata that makes it 282.35s - 284.35s | easy to find those modules and 284.87s - 289.15s | Disassemble them right there. There's tools for working with


chunk_id: 151_chunk_5
chunk_text:
It's really nice. So what I'm presenting here is not a mistake made with micro Python. It's just a reverse engineering talk 239.53s - 244.61s | There's no vulnerability here as my micro Python is concerned. I like it 244.61s - 249.73s | It's really easy to create a prototype of an embedded device with micro Python 250.33s - 253.85s | And so you have three choices for your code you can have 254.53s - 259.71s | Plain text that's on a small file system. That's in the emulated in part of your flash memory 260.59s - 264.23s | You can and you can read and write to that file system through the REPL 265.15s - 266.83s | you can 266.83s - 275.07s | have pre compiled byte code modules and we'll talk about the structure of those but then you can also take those pre compiled modules and 275.75s - 282.35s | Cook them into the file into the micro Python firmware at build time and that removes a lot of the metadata that makes it 282.35s - 284.35s | easy to find those modules and 284.87s - 289.15s | Disassemble them right there. There's tools for working with the other portions of this 289.19s - 292.59s | There's no tools for going back from a frozen module 292.59s - 298.47s | and so in badge life a lot of CTFs that use badges will hold secrets and 298.63s - 304.29s | Keys and code that they don't want you to see as part of the CTF inside those frozen modules 305.75s - 312.11s | The feature is there for efficiency. So the feature is there so that you're not wasting additional memory loading 312.43s - 314.43s | Dot PI or loading of the dot 314.99s - 320.07s | MPY file into memory and doing things when it's already in memory because it's on the flash 320.55s - 326.35s | So it saves memory. It's convenient. You don't have to do any additional loads. It's already there 327.39s - 329.39s | but it's being 329.43s - 331.43s | abused misused for 332.07s - 335.71s | obfuscating and hiding code and secrets inside of these binaries and 337.03s - 339.03s | We've got some quotes 339.43s - 342.63s | Here that from random forums and stuff you probably can't read them 343.07s - 347.59s | They're small. I just grabbed


chunk_id: 151_chunk_6
chunk_text:
the other portions of this 289.19s - 292.59s | There's no tools for going back from a frozen module 292.59s - 298.47s | and so in badge life a lot of CTFs that use badges will hold secrets and 298.63s - 304.29s | Keys and code that they don't want you to see as part of the CTF inside those frozen modules 305.75s - 312.11s | The feature is there for efficiency. So the feature is there so that you're not wasting additional memory loading 312.43s - 314.43s | Dot PI or loading of the dot 314.99s - 320.07s | MPY file into memory and doing things when it's already in memory because it's on the flash 320.55s - 326.35s | So it saves memory. It's convenient. You don't have to do any additional loads. It's already there 327.39s - 329.39s | but it's being 329.43s - 331.43s | abused misused for 332.07s - 335.71s | obfuscating and hiding code and secrets inside of these binaries and 337.03s - 339.03s | We've got some quotes 339.43s - 342.63s | Here that from random forums and stuff you probably can't read them 343.07s - 347.59s | They're small. I just grabbed a bunch of them and threw them up. But the gist of all these quotes is 348.51s - 356.11s | People are asking. Well, if I've got a password for a system, how do I keep that away from my users or I've got a key 356.11s - 358.91s | I've got a secret that I don't want them to read my code 359.55s - 361.51s | their concerns are 361.51s - 366.87s | Making this obfuscated and people were responding to them on these forums of like, you know 366.87s - 370.11s | It's not perfect and everybody acknowledges that this isn't perfect and it's not perfect 370.11s - 374.51s | but you can make it harder to get it that stuff by cooking it into a 374.79s - 380.13s | Frozen module because nobody has the tools to disassemble it. And so let's make something to disassemble it 381.99s - 385.99s | It's a layer of protection for some folks, but it's really just an obfuscation 387.19s - 391.15s | The first thing that you have to do to get this thing working is to get a firmware image 391.39s - 397.31s | So that's out of scope


chunk_id: 151_chunk_7
chunk_text:
a bunch of them and threw them up. But the gist of all these quotes is 348.51s - 356.11s | People are asking. Well, if I've got a password for a system, how do I keep that away from my users or I've got a key 356.11s - 358.91s | I've got a secret that I don't want them to read my code 359.55s - 361.51s | their concerns are 361.51s - 366.87s | Making this obfuscated and people were responding to them on these forums of like, you know 366.87s - 370.11s | It's not perfect and everybody acknowledges that this isn't perfect and it's not perfect 370.11s - 374.51s | but you can make it harder to get it that stuff by cooking it into a 374.79s - 380.13s | Frozen module because nobody has the tools to disassemble it. And so let's make something to disassemble it 381.99s - 385.99s | It's a layer of protection for some folks, but it's really just an obfuscation 387.19s - 391.15s | The first thing that you have to do to get this thing working is to get a firmware image 391.39s - 397.31s | So that's out of scope for this talk and it's tricky depending on the module depending on your microcontroller 397.31s - 399.47s | You might not be able to get a flash image easy 399.51s - 405.03s | that's a whole talk on you know glitching and things like that, but since we're using Pico's as the 405.99s - 409.27s | Pico as the dev environment here we can 410.23s - 413.19s | We can just use the standard Pico tools for this demonstration 413.91s - 416.19s | If you're following at home with a Pico 416.75s - 421.31s | You use the Pico tool info and it'll tell you about the 421.83s - 424.19s | About the firmware of an a connected Pico 424.35s - 429.35s | but it actually makes it a little too easy as you can see from the output here from the output you have a list of 429.35s - 431.15s | frozen modules here and 431.15s - 434.35s | You know, well, that's that seems dumb seems like a really short talk 434.99s - 438.83s | and what that's from is from Pico's Pico has 439.43s - 444.79s | binary information quote-unquote binary information in the firmware image and


chunk_id: 151_chunk_8
chunk_text:
for this talk and it's tricky depending on the module depending on your microcontroller 397.31s - 399.47s | You might not be able to get a flash image easy 399.51s - 405.03s | that's a whole talk on you know glitching and things like that, but since we're using Pico's as the 405.99s - 409.27s | Pico as the dev environment here we can 410.23s - 413.19s | We can just use the standard Pico tools for this demonstration 413.91s - 416.19s | If you're following at home with a Pico 416.75s - 421.31s | You use the Pico tool info and it'll tell you about the 421.83s - 424.19s | About the firmware of an a connected Pico 424.35s - 429.35s | but it actually makes it a little too easy as you can see from the output here from the output you have a list of 429.35s - 431.15s | frozen modules here and 431.15s - 434.35s | You know, well, that's that seems dumb seems like a really short talk 434.99s - 438.83s | and what that's from is from Pico's Pico has 439.43s - 444.79s | binary information quote-unquote binary information in the firmware image and 445.15s - 450.63s | It can be read with Pico tool it can be in code it's encoded by MicroPython 451.51s - 455.11s | firmware can specify in MicroPython that it's going to 456.19s - 460.59s | include additional fields in that Pico tool or in that binary information and 461.99s - 465.55s | MicroPython does this with simply a list of the frozen modules and 466.15s - 468.15s | So again, that seems real easy 468.43s - 473.55s | you can look at how to parse that from a tool that comes with MicroPython that 473.95s - 481.47s | We're going to be using a lot here mpy tool this is used for freezing modules for inspecting mpy files 483.07s - 488.87s | There's some stuff in there for how it encodes that that information and 489.91s - 496.15s | So since this is too easy as a starting point, I mean, it's too easy because you can strip this out 496.15s - 501.95s | It's not necessary for the operation of the firmware, right? So other platforms 502.95s - 508.87s | Other micro controls may not even have this sort of field this sort of binary information in


chunk_id: 151_chunk_9
chunk_text:
445.15s - 450.63s | It can be read with Pico tool it can be in code it's encoded by MicroPython 451.51s - 455.11s | firmware can specify in MicroPython that it's going to 456.19s - 460.59s | include additional fields in that Pico tool or in that binary information and 461.99s - 465.55s | MicroPython does this with simply a list of the frozen modules and 466.15s - 468.15s | So again, that seems real easy 468.43s - 473.55s | you can look at how to parse that from a tool that comes with MicroPython that 473.95s - 481.47s | We're going to be using a lot here mpy tool this is used for freezing modules for inspecting mpy files 483.07s - 488.87s | There's some stuff in there for how it encodes that that information and 489.91s - 496.15s | So since this is too easy as a starting point, I mean, it's too easy because you can strip this out 496.15s - 501.95s | It's not necessary for the operation of the firmware, right? So other platforms 502.95s - 508.87s | Other micro controls may not even have this sort of field this sort of binary information in the firmware 509.95s - 512.23s | It's not used by MicroPython itself 512.47s - 517.75s | So we can evade this analysis by commenting out the code in the freezing tool 518.19s - 522.39s | That generates that list right and so to make it harder on ourselves, right? 522.39s - 528.07s | Because we imagine the next step after we start ripping this stuff out people are going to start obfuscating this part 528.67s - 535.67s | So we can rip this out and not have those frozen modules listed if you can get to a serial console 535.99s - 542.15s | REPL, you can also do help modules and list them out. That is probably something that needs to be in there 542.15s - 547.35s | I don't know if you could patch out an evasion from our countermeasure against that 547.63s - 554.15s | But that's but it's not always the case that you're going to be able to easily get the REPL on on a microcontroller 554.83s - 564.10s | So for our example, we're going to have the the minimum viable Python module here a hello world that we're going to 564.90s - 566.46s |


chunk_id: 151_chunk_10
chunk_text:
the firmware 509.95s - 512.23s | It's not used by MicroPython itself 512.47s - 517.75s | So we can evade this analysis by commenting out the code in the freezing tool 518.19s - 522.39s | That generates that list right and so to make it harder on ourselves, right? 522.39s - 528.07s | Because we imagine the next step after we start ripping this stuff out people are going to start obfuscating this part 528.67s - 535.67s | So we can rip this out and not have those frozen modules listed if you can get to a serial console 535.99s - 542.15s | REPL, you can also do help modules and list them out. That is probably something that needs to be in there 542.15s - 547.35s | I don't know if you could patch out an evasion from our countermeasure against that 547.63s - 554.15s | But that's but it's not always the case that you're going to be able to easily get the REPL on on a microcontroller 554.83s - 564.10s | So for our example, we're going to have the the minimum viable Python module here a hello world that we're going to 564.90s - 566.46s | demonstrate in 566.46s - 572.26s | in plain text, we're going to demonstrate it as a compiled bytecode file on the file system and 573.06s - 579.46s | Then finally as a frozen module compiled into MicroPython and look at what that looks like in the binary 580.46s - 587.82s | Plain text is simple. You simply use the MP remote tool to upload it into the file system on the microcontroller 587.82s - 592.86s | There's a small very small file system that it stores those things in 593.42s - 596.94s | You can list files on it and you import and go 598.74s - 603.56s | You can use the mpy cross compiler to compile 604.04s - 610.12s | Your hello world dot py into an mpy into py file and you wind up with the hex dump 610.12s - 613.52s | Are you from one up of a file that has the following hex representation? 613.52s - 616.88s | And so you can kind of see in there used to see our strings 617.12s - 621.32s | You can see some bytecode in there. And so you're like, okay, this is a thing 622.40s - 625.92s |


chunk_id: 151_chunk_11
chunk_text:
demonstrate in 566.46s - 572.26s | in plain text, we're going to demonstrate it as a compiled bytecode file on the file system and 573.06s - 579.46s | Then finally as a frozen module compiled into MicroPython and look at what that looks like in the binary 580.46s - 587.82s | Plain text is simple. You simply use the MP remote tool to upload it into the file system on the microcontroller 587.82s - 592.86s | There's a small very small file system that it stores those things in 593.42s - 596.94s | You can list files on it and you import and go 598.74s - 603.56s | You can use the mpy cross compiler to compile 604.04s - 610.12s | Your hello world dot py into an mpy into py file and you wind up with the hex dump 610.12s - 613.52s | Are you from one up of a file that has the following hex representation? 613.52s - 616.88s | And so you can kind of see in there used to see our strings 617.12s - 621.32s | You can see some bytecode in there. And so you're like, okay, this is a thing 622.40s - 625.92s | This immediate doesn't immediately look to you to be very useful 626.04s - 632.80s | but the mpy tool can work with this forward format very well and you can upload it into the file system and 633.08s - 635.76s | And use it. And so if you find one on a file system 636.44s - 639.72s | Use mpy tool to to tinker around with it 640.48s - 641.96s | as a 641.96s - 648.76s | Frozen module you can take that mpy and rebuild the microcontroller or firmware from scratch 648.76s - 655.48s | You can rebuild MicroPython from scratch including that mpy that you created it brings it in it kind of 656.24s - 660.64s | It brings it in as a set of C structures and we'll talk about that in a little bit 660.64s - 666.08s | But basically it's hard to go back after you've frozen it into the firmware. It's harder to pull it back 666.08s - 671.36s | It's not just a file on the file system anymore, but you can use it as a Python module just fine 671.92s - 682.70s | So what can we learn from an mpy file


chunk_id: 151_chunk_12
chunk_text:
This immediate doesn't immediately look to you to be very useful 626.04s - 632.80s | but the mpy tool can work with this forward format very well and you can upload it into the file system and 633.08s - 635.76s | And use it. And so if you find one on a file system 636.44s - 639.72s | Use mpy tool to to tinker around with it 640.48s - 641.96s | as a 641.96s - 648.76s | Frozen module you can take that mpy and rebuild the microcontroller or firmware from scratch 648.76s - 655.48s | You can rebuild MicroPython from scratch including that mpy that you created it brings it in it kind of 656.24s - 660.64s | It brings it in as a set of C structures and we'll talk about that in a little bit 660.64s - 666.08s | But basically it's hard to go back after you've frozen it into the firmware. It's harder to pull it back 666.08s - 671.36s | It's not just a file on the file system anymore, but you can use it as a Python module just fine 671.92s - 682.70s | So what can we learn from an mpy file because our goal eventually here is going to be to take that 683.42s - 685.42s | Frozen module extract it from the firmware 686.06s - 690.54s | Recreate the mpy so that we can parse it the mpy tool creates 691.30s - 698.90s | Of the frozen module from the mpy and so the mpy tool that PI code has a lot of 700.30s - 707.62s | Algorithms and data structures in it for generating this and so it does not generate the the binary that's going to be in the firmware 707.62s - 710.30s | Directly it generates a set of C code 710.90s - 714.50s | That's going to get statically linked into the MicroPython firmware 714.86s - 716.02s | So 716.02s - 721.10s | And it's less coded and it's just like a whole lot of data structure a whole lot of struts, right? 721.10s - 726.54s | And those trucks are going to get compiled in and they're going to get arranged by the compiler into memory in 726.78s - 731.18s | Various places that are not immediately obvious to you from just reading the code 732.02s - 739.22s | The same tool can be used


chunk_id: 151_chunk_13
chunk_text:
because our goal eventually here is going to be to take that 683.42s - 685.42s | Frozen module extract it from the firmware 686.06s - 690.54s | Recreate the mpy so that we can parse it the mpy tool creates 691.30s - 698.90s | Of the frozen module from the mpy and so the mpy tool that PI code has a lot of 700.30s - 707.62s | Algorithms and data structures in it for generating this and so it does not generate the the binary that's going to be in the firmware 707.62s - 710.30s | Directly it generates a set of C code 710.90s - 714.50s | That's going to get statically linked into the MicroPython firmware 714.86s - 716.02s | So 716.02s - 721.10s | And it's less coded and it's just like a whole lot of data structure a whole lot of struts, right? 721.10s - 726.54s | And those trucks are going to get compiled in and they're going to get arranged by the compiler into memory in 726.78s - 731.18s | Various places that are not immediately obvious to you from just reading the code 732.02s - 739.22s | The same tool can be used to dump info about an mpy file with a disassemble flag. So it does have a built-in disassembler 740.22s - 745.46s | This is the only disassembler you get with MicroPython and it's only pulling from mpy file 745.46s - 750.58s | so if we get code out of the binary, we're going to need to disassemble it with this tool and 751.22s - 757.66s | By the way, the byte code for MicroPython is not the same byte code as CPython 758.42s - 761.90s | It's definitely not the same opcodes. It's many of the same 762.86s - 766.26s | it's many of the same opcodes with different different values and 767.14s - 776.02s | Not all of the same opcodes, right so it's a from-scratch implementation if we don't or disassemble 776.54s - 781.74s | mpy file using the mpy tool we get three main 782.26s - 789.50s | Things out of we get a string table a module a string table an object table and a set of code 790.74s - 794.58s | What you're looking at here is the string table and I'm going to talk to you about this this 795.34s - 798.10s | Interned


chunk_id: 151_chunk_14
chunk_text:
to dump info about an mpy file with a disassemble flag. So it does have a built-in disassembler 740.22s - 745.46s | This is the only disassembler you get with MicroPython and it's only pulling from mpy file 745.46s - 750.58s | so if we get code out of the binary, we're going to need to disassemble it with this tool and 751.22s - 757.66s | By the way, the byte code for MicroPython is not the same byte code as CPython 758.42s - 761.90s | It's definitely not the same opcodes. It's many of the same 762.86s - 766.26s | it's many of the same opcodes with different different values and 767.14s - 776.02s | Not all of the same opcodes, right so it's a from-scratch implementation if we don't or disassemble 776.54s - 781.74s | mpy file using the mpy tool we get three main 782.26s - 789.50s | Things out of we get a string table a module a string table an object table and a set of code 790.74s - 794.58s | What you're looking at here is the string table and I'm going to talk to you about this this 795.34s - 798.10s | Interned string format that they have here 799.98s - 801.34s | For the code 801.34s - 808.38s | There's two pieces of code if you remember we had a module that defined we defined a module and then we've defined a go 808.46s - 811.18s | function in it or a hello world function in it and 812.18s - 814.18s | So you're gonna have two functions 814.94s - 818.46s | That have byte code. The first one is going to be a constructor and 819.14s - 821.02s | The next one's gonna be your go function 821.02s - 823.02s | It actually repeats hello world 823.06s - 828.98s | Every five seconds and you can see the the byte code in these and it's a stack based language 829.10s - 837.30s | Basically, you're you're you're constantly loading things out of different data structures putting them on the stack calling other functions 837.62s - 841.14s | Pushing and popping and looping around and throwing things like that 841.14s - 848.06s | And so again, if you read up on how a Python byte code works, it would make sense to you 848.46s - 853.02s | But it's not exactly the


chunk_id: 151_chunk_15
chunk_text:
string format that they have here 799.98s - 801.34s | For the code 801.34s - 808.38s | There's two pieces of code if you remember we had a module that defined we defined a module and then we've defined a go 808.46s - 811.18s | function in it or a hello world function in it and 812.18s - 814.18s | So you're gonna have two functions 814.94s - 818.46s | That have byte code. The first one is going to be a constructor and 819.14s - 821.02s | The next one's gonna be your go function 821.02s - 823.02s | It actually repeats hello world 823.06s - 828.98s | Every five seconds and you can see the the byte code in these and it's a stack based language 829.10s - 837.30s | Basically, you're you're you're constantly loading things out of different data structures putting them on the stack calling other functions 837.62s - 841.14s | Pushing and popping and looping around and throwing things like that 841.14s - 848.06s | And so again, if you read up on how a Python byte code works, it would make sense to you 848.46s - 853.02s | But it's not exactly the same so you can't use like the body of Python 853.26s - 856.50s | Disassembly tools on this are debugging tools for this 858.54s - 862.66s | There's a really nice colored output hex dump that you can get with mpy tool 863.10s - 868.66s | That will sort of tell you what the different parts of that hex dump mean and what what what they are what they have what? 868.66s - 871.66s | They're about that'll help us when we're trying to recreate one of these 873.62s - 875.62s | so 875.62s - 880.70s | If we can rebuild an mpy of a frozen module out of information we extract from firmware 880.70s - 884.14s | We've got something we you can use to get some work done with it 884.58s - 890.62s | It'll take some Mario work, but it's not and because it's not there in the contiguous belt binary blob. It's structures 890.62s - 894.14s | We've got a walk, right? We got to find them in memory and walk them 895.58s - 900.62s | We have to understand string interning we need to look at the pipe byte code briefly 900.62s - 903.26s |


chunk_id: 151_chunk_16
chunk_text:
same so you can't use like the body of Python 853.26s - 856.50s | Disassembly tools on this are debugging tools for this 858.54s - 862.66s | There's a really nice colored output hex dump that you can get with mpy tool 863.10s - 868.66s | That will sort of tell you what the different parts of that hex dump mean and what what what they are what they have what? 868.66s - 871.66s | They're about that'll help us when we're trying to recreate one of these 873.62s - 875.62s | so 875.62s - 880.70s | If we can rebuild an mpy of a frozen module out of information we extract from firmware 880.70s - 884.14s | We've got something we you can use to get some work done with it 884.58s - 890.62s | It'll take some Mario work, but it's not and because it's not there in the contiguous belt binary blob. It's structures 890.62s - 894.14s | We've got a walk, right? We got to find them in memory and walk them 895.58s - 900.62s | We have to understand string interning we need to look at the pipe byte code briefly 900.62s - 903.26s | It does not a I'm gonna be a byte code class or anything 904.42s - 909.38s | But also another tool that we can use is we can build a version of micro Python 909.50s - 915.10s | That's the Unix port quote-unquote Unix port it you can build it for Windows Linux or whatever 915.46s - 918.86s | But it's basically a desktop version of micro Python 919.54s - 925.78s | That you can that you can build and load mpy files into run them analyze them and do things to where you're not just 925.98s - 929.74s | Restricted to working on the microcontroller itself when you're doing your reverse engineering 931.34s - 933.34s | So first off 933.70s - 936.06s | How are storing our string constants? 936.46s - 943.90s | We're doing what's called string interning and so this is something that you do on very limited memory 944.22s - 951.22s | Environments where you want to avoid having the same constant string in memory more than once, right? 951.34s - 953.18s | You don't want to have 953.18s - 958.98s | main or something like or some other common string 50 different times in your


chunk_id: 151_chunk_17
chunk_text:
It does not a I'm gonna be a byte code class or anything 904.42s - 909.38s | But also another tool that we can use is we can build a version of micro Python 909.50s - 915.10s | That's the Unix port quote-unquote Unix port it you can build it for Windows Linux or whatever 915.46s - 918.86s | But it's basically a desktop version of micro Python 919.54s - 925.78s | That you can that you can build and load mpy files into run them analyze them and do things to where you're not just 925.98s - 929.74s | Restricted to working on the microcontroller itself when you're doing your reverse engineering 931.34s - 933.34s | So first off 933.70s - 936.06s | How are storing our string constants? 936.46s - 943.90s | We're doing what's called string interning and so this is something that you do on very limited memory 944.22s - 951.22s | Environments where you want to avoid having the same constant string in memory more than once, right? 951.34s - 953.18s | You don't want to have 953.18s - 958.98s | main or something like or some other common string 50 different times in your memory if your 959.26s - 964.30s | Memory is in on the order of megabytes or kilobytes or something like that, right? And so 965.30s - 971.98s | My group I micro Python calls these Q strings for unique for unique cook strings 973.02s - 974.02s | and 974.02s - 981.98s | Basically Q string values the way you refer to them is is into an index into a linked list of pools of these strings 981.98s - 988.90s | Right, and so if you're wanting to refer to hello cruel world, or you're wanting to refer to 990.06s - 991.38s | the the 991.90s - 994.30s | Open tag module closed tag 995.30s - 1000.46s | String you're never going to refer to it as a pointer or you'll get a pointer to it 1000.46s - 1007.42s | but you're going to refer to it as and pass it around as an index into these links link pools and 1008.22s - 1009.22s | So there's a link 1009.22s - 1015.86s | There's a set of static ones that are in the make Q string data dot py that's used in the build process of micro Python 1016.74s - 1023.42s


chunk_id: 151_chunk_18
chunk_text:
memory if your 959.26s - 964.30s | Memory is in on the order of megabytes or kilobytes or something like that, right? And so 965.30s - 971.98s | My group I micro Python calls these Q strings for unique for unique cook strings 973.02s - 974.02s | and 974.02s - 981.98s | Basically Q string values the way you refer to them is is into an index into a linked list of pools of these strings 981.98s - 988.90s | Right, and so if you're wanting to refer to hello cruel world, or you're wanting to refer to 990.06s - 991.38s | the the 991.90s - 994.30s | Open tag module closed tag 995.30s - 1000.46s | String you're never going to refer to it as a pointer or you'll get a pointer to it 1000.46s - 1007.42s | but you're going to refer to it as and pass it around as an index into these links link pools and 1008.22s - 1009.22s | So there's a link 1009.22s - 1015.86s | There's a set of static ones that are in the make Q string data dot py that's used in the build process of micro Python 1016.74s - 1023.42s | And those are constant across all your builds of micro Python and then past that in the next pool 1023.70s - 1029.10s | It's going to be stuff that's varies between each build depending on which frozen modules you include 1029.62s - 1038.63s | So if you use mpy tool to create frozen code generated from your mpy file 1039.47s - 1044.87s | It's going to create a strings a string data structure. And so first you've got an enum that has 1045.43s - 1049.03s | basically, you know, that's going to compile down to one two, three four, basically a 1050.15s - 1053.39s | Indexing hello cruel world go. Hello world pie 1053.91s - 1056.59s | Sleep time all those sorts of things 1056.83s - 1062.47s | Then you're going to have hashes for them like a simple one byte hash and then a link for each of them 1063.27s - 1069.47s | Those are going to be placed into pools. And so on the right hand side there you see the frozen constant pool 1070.47s - 1075.23s | That has has those five strings represented in there 1075.51s - 1078.51s | there's also going to be a


chunk_id: 151_chunk_19
chunk_text:
| And those are constant across all your builds of micro Python and then past that in the next pool 1023.70s - 1029.10s | It's going to be stuff that's varies between each build depending on which frozen modules you include 1029.62s - 1038.63s | So if you use mpy tool to create frozen code generated from your mpy file 1039.47s - 1044.87s | It's going to create a strings a string data structure. And so first you've got an enum that has 1045.43s - 1049.03s | basically, you know, that's going to compile down to one two, three four, basically a 1050.15s - 1053.39s | Indexing hello cruel world go. Hello world pie 1053.91s - 1056.59s | Sleep time all those sorts of things 1056.83s - 1062.47s | Then you're going to have hashes for them like a simple one byte hash and then a link for each of them 1063.27s - 1069.47s | Those are going to be placed into pools. And so on the right hand side there you see the frozen constant pool 1070.47s - 1075.23s | That has has those five strings represented in there 1075.51s - 1078.51s | there's also going to be a link to the previous pool and 1079.39s - 1082.23s | also a previous pool size, so 1082.91s - 1084.19s | your 1084.19s - 1086.19s | Q-string indexes are 1086.43s - 1090.61s | Global they're globally unique and so you have to look at that previous pool size 1090.87s - 1093.91s | To know where the indexes start for this pool 1093.91s - 1095.51s | All the pools are linked together 1095.51s - 1103.67s | The first constant pool starts at zero and it goes to however many constants there are and then the frozen pool if it's next 1103.99s - 1107.71s | Starts at that number plus 1 plus 2 plus 3 plus 4 plus 5 1108.39s - 1112.69s | so 1112.69s - 1116.77s | And so this is another this is the the Q string table data 1117.73s - 1123.89s | Here. So now you've got those these defined constants for these and so this is how you refer to 1124.37s - 1128.41s | The Q strings that you have these are all your indexes defined as constants 1128.93s - 1138.69s | So the question is how do we find the compiled module and a compiled firmware now if


chunk_id: 151_chunk_20
chunk_text:
link to the previous pool and 1079.39s - 1082.23s | also a previous pool size, so 1082.91s - 1084.19s | your 1084.19s - 1086.19s | Q-string indexes are 1086.43s - 1090.61s | Global they're globally unique and so you have to look at that previous pool size 1090.87s - 1093.91s | To know where the indexes start for this pool 1093.91s - 1095.51s | All the pools are linked together 1095.51s - 1103.67s | The first constant pool starts at zero and it goes to however many constants there are and then the frozen pool if it's next 1103.99s - 1107.71s | Starts at that number plus 1 plus 2 plus 3 plus 4 plus 5 1108.39s - 1112.69s | so 1112.69s - 1116.77s | And so this is another this is the the Q string table data 1117.73s - 1123.89s | Here. So now you've got those these defined constants for these and so this is how you refer to 1124.37s - 1128.41s | The Q strings that you have these are all your indexes defined as constants 1128.93s - 1138.69s | So the question is how do we find the compiled module and a compiled firmware now if you're lucky they built it with symbols, right? 1138.89s - 1143.33s | But we're not going to assume we're lucky here. We're going to assume they stripped out that binary information 1143.33s - 1151.01s | we're going to assume that they stripped out the the symbols and so for me, whatever whenever I see somebody in 1151.85s - 1155.17s | Compiled code that I'm reverse engineering and they're using 1155.81s - 1160.53s | An open source module like if in malware if they're using open SSL or they're using 1161.85s - 1167.77s | Something similar. I'll try to build a copy of that SSL library myself of 1168.29s - 1173.61s | Alma if as close of a version as I can get and as close to the same options as I can figure for theirs 1173.85s - 1180.37s | So that I can then use that as sort of a Rosetta Stone for their module that doesn't have symbols, right? 1180.69s - 1184.77s | Because there's data structures that I want to walk through there. And so that 1185.41s - 1187.57s | one of the best things that you can do is 1189.73s - 1194.81s | Build a debug build


chunk_id: 151_chunk_21
chunk_text:
you're lucky they built it with symbols, right? 1138.89s - 1143.33s | But we're not going to assume we're lucky here. We're going to assume they stripped out that binary information 1143.33s - 1151.01s | we're going to assume that they stripped out the the symbols and so for me, whatever whenever I see somebody in 1151.85s - 1155.17s | Compiled code that I'm reverse engineering and they're using 1155.81s - 1160.53s | An open source module like if in malware if they're using open SSL or they're using 1161.85s - 1167.77s | Something similar. I'll try to build a copy of that SSL library myself of 1168.29s - 1173.61s | Alma if as close of a version as I can get and as close to the same options as I can figure for theirs 1173.85s - 1180.37s | So that I can then use that as sort of a Rosetta Stone for their module that doesn't have symbols, right? 1180.69s - 1184.77s | Because there's data structures that I want to walk through there. And so that 1185.41s - 1187.57s | one of the best things that you can do is 1189.73s - 1194.81s | Build a debug build of micro Python that has a frozen module in it 1194.81s - 1198.61s | not necessary you don't have their frozen module, but it has a frozen module in it and 1199.21s - 1202.17s | Use that to get your bearings in the binary, right? 1203.05s - 1209.61s | Have it loaded the same address and all that sort of thing and then you can have two copies of G drop one side by side 1210.53s - 1217.50s | And use one to figure out where the data structures are in the other and so in the debug build 1217.86s - 1223.86s | It's called mp frozen names. The mp frozen names is a list of the frozen modules on the system in 1226.34s - 1228.34s | your in your 1230.82s - 1237.98s | Debug build you also have the frozen modules themselves mp frozen mpy content. So you've got 1238.98s - 1241.82s | There's a lot of sort of built-in frozen modules 1242.62s - 1246.54s | You'll see like if you have an Adafruit circuit Python 1247.46s - 1250.36s | Device circuit Python is based on micro Python 1250.82s - 1255.02s | So circuit Python devices will have other


chunk_id: 151_chunk_22
chunk_text:
of micro Python that has a frozen module in it 1194.81s - 1198.61s | not necessary you don't have their frozen module, but it has a frozen module in it and 1199.21s - 1202.17s | Use that to get your bearings in the binary, right? 1203.05s - 1209.61s | Have it loaded the same address and all that sort of thing and then you can have two copies of G drop one side by side 1210.53s - 1217.50s | And use one to figure out where the data structures are in the other and so in the debug build 1217.86s - 1223.86s | It's called mp frozen names. The mp frozen names is a list of the frozen modules on the system in 1226.34s - 1228.34s | your in your 1230.82s - 1237.98s | Debug build you also have the frozen modules themselves mp frozen mpy content. So you've got 1238.98s - 1241.82s | There's a lot of sort of built-in frozen modules 1242.62s - 1246.54s | You'll see like if you have an Adafruit circuit Python 1247.46s - 1250.36s | Device circuit Python is based on micro Python 1250.82s - 1255.02s | So circuit Python devices will have other frozen modules in them 1255.02s - 1258.34s | And you may not necessarily have the source code to them and they'll be in this list 1258.34s - 1265.34s | I think Lego makes a device that has a microcontroller in it that has 1265.74s - 1270.82s | Micro Python or circuit Python on it and they also have some of their own closed source libraries 1271.02s - 1275.46s | That are that are in this as well. And so this is easy mode, right? 1275.46s - 1278.98s | So we found the list of names of modules we found 1279.54s - 1281.54s | pointers to the modules themselves 1281.70s - 1286.98s | But we don't have the names of frozen names and frozen mpy 1287.42s - 1289.82s | Content in our stripped binary 1289.82s - 1297.10s | So we have a stripped binary that we copied from a micro controller or we got from an over-the-air update or something like that 1297.62s - 1300.98s | We've got to find them in a non debug build, right? 1300.98s - 1305.50s | And so the way we can find them if we if we can ever get to the same things 1305.62s


chunk_id: 151_chunk_23
chunk_text:
frozen modules in them 1255.02s - 1258.34s | And you may not necessarily have the source code to them and they'll be in this list 1258.34s - 1265.34s | I think Lego makes a device that has a microcontroller in it that has 1265.74s - 1270.82s | Micro Python or circuit Python on it and they also have some of their own closed source libraries 1271.02s - 1275.46s | That are that are in this as well. And so this is easy mode, right? 1275.46s - 1278.98s | So we found the list of names of modules we found 1279.54s - 1281.54s | pointers to the modules themselves 1281.70s - 1286.98s | But we don't have the names of frozen names and frozen mpy 1287.42s - 1289.82s | Content in our stripped binary 1289.82s - 1297.10s | So we have a stripped binary that we copied from a micro controller or we got from an over-the-air update or something like that 1297.62s - 1300.98s | We've got to find them in a non debug build, right? 1300.98s - 1305.50s | And so the way we can find them if we if we can ever get to the same things 1305.62s - 1312.98s | Then we can start using those C data structures from the C files that these things that from the source code of micro Python 1312.98s - 1319.38s | The source code of other frozen modules. We can start using those to sort of walk it and figure out what's different 1319.94s - 1321.94s | But we've got to find those data structures first 1323.10s - 1329.06s | the easiest way to find these two data structures in a non debug build is to 1329.06s - 1332.78s | Is to one of the easiest ways for this is to just eyeball it 1333.02s - 1339.16s | You can search for dot PI and just find sort of the list of constants that have dot PI 1340.34s - 1346.38s | Especially if you know the other frozen modules and the other frozen modules are consistent with the standard micro Python ones 1346.62s - 1353.22s | You can compare that list and then whatever is additional on there are other additional frozen micro Python modules 1354.10s - 1356.10s | another a little bit more 1357.58s - 1363.06s | Resilient way of finding that that doesn't depend on you just sort


chunk_id: 151_chunk_24
chunk_text:
- 1312.98s | Then we can start using those C data structures from the C files that these things that from the source code of micro Python 1312.98s - 1319.38s | The source code of other frozen modules. We can start using those to sort of walk it and figure out what's different 1319.94s - 1321.94s | But we've got to find those data structures first 1323.10s - 1329.06s | the easiest way to find these two data structures in a non debug build is to 1329.06s - 1332.78s | Is to one of the easiest ways for this is to just eyeball it 1333.02s - 1339.16s | You can search for dot PI and just find sort of the list of constants that have dot PI 1340.34s - 1346.38s | Especially if you know the other frozen modules and the other frozen modules are consistent with the standard micro Python ones 1346.62s - 1353.22s | You can compare that list and then whatever is additional on there are other additional frozen micro Python modules 1354.10s - 1356.10s | another a little bit more 1357.58s - 1363.06s | Resilient way of finding that that doesn't depend on you just sort of eyeballing a binary which I don't mind doing all day 1363.06s - 1364.98s | But y'all might 1364.98s - 1367.70s | Is to find it as a code reference 1367.70s - 1374.22s | and so there's a function that uses that list called MP fine frozen module and 1374.70s - 1382.46s | Chances are it's going to build in roughly the same location in your debug build as in your is in your stripped build 1383.06s - 1387.74s | Or you can just search for the code right here. So you have this move load 1389.10s - 1393.18s | Stroke this move load store combination here using this 1393.82s - 1397.46s | Address that address is the address to the MP frozen names 1398.10s - 1406.51s | To find the frozen module content, there's all there you can't really eyeball it because it's all binary content 1407.07s - 1412.03s | But there's indirect reference in in that same in that same function 1412.03s - 1419.19s | So if you find those frozen names eyeballing them, you can do a cross reference in gedra to walk back to where 1419.71s - 1427.47s | MP fine frozen module is and say,


chunk_id: 151_chunk_25
chunk_text:
of eyeballing a binary which I don't mind doing all day 1363.06s - 1364.98s | But y'all might 1364.98s - 1367.70s | Is to find it as a code reference 1367.70s - 1374.22s | and so there's a function that uses that list called MP fine frozen module and 1374.70s - 1382.46s | Chances are it's going to build in roughly the same location in your debug build as in your is in your stripped build 1383.06s - 1387.74s | Or you can just search for the code right here. So you have this move load 1389.10s - 1393.18s | Stroke this move load store combination here using this 1393.82s - 1397.46s | Address that address is the address to the MP frozen names 1398.10s - 1406.51s | To find the frozen module content, there's all there you can't really eyeball it because it's all binary content 1407.07s - 1412.03s | But there's indirect reference in in that same in that same function 1412.03s - 1419.19s | So if you find those frozen names eyeballing them, you can do a cross reference in gedra to walk back to where 1419.71s - 1427.47s | MP fine frozen module is and say, okay that matches up with the debug build now later on in that function 1427.51s - 1432.35s | There's a bit of code that looks like this. This is a reference to the frozen mpy content 1432.35s - 1437.03s | And so now we have pointers to our mod to the to the base data structures of our modules 1437.03s - 1440.59s | So from here, it should be fairly simple work 1440.59s - 1443.19s | Just sort of working through those structures and pulling it out 1443.19s - 1448.99s | And what we want to do is we want to recreate the hex of that original mpy file 1449.27s - 1452.15s | So that the rest of the work can be done with mpy tool 1452.63s - 1462.33s | The header for the mpy file is is a gonna be the same usually you can just take that from any of them 1462.33s - 1467.25s | And it's not super important as long as you get something that it passes the checks and it goes 1467.77s - 1469.77s | starts with magic letter M 1470.45s - 1472.93s | Goes with a major micropython version 1474.41s - 1478.25s | You


chunk_id: 151_chunk_26
chunk_text:
okay that matches up with the debug build now later on in that function 1427.51s - 1432.35s | There's a bit of code that looks like this. This is a reference to the frozen mpy content 1432.35s - 1437.03s | And so now we have pointers to our mod to the to the base data structures of our modules 1437.03s - 1440.59s | So from here, it should be fairly simple work 1440.59s - 1443.19s | Just sort of working through those structures and pulling it out 1443.19s - 1448.99s | And what we want to do is we want to recreate the hex of that original mpy file 1449.27s - 1452.15s | So that the rest of the work can be done with mpy tool 1452.63s - 1462.33s | The header for the mpy file is is a gonna be the same usually you can just take that from any of them 1462.33s - 1467.25s | And it's not super important as long as you get something that it passes the checks and it goes 1467.77s - 1469.77s | starts with magic letter M 1470.45s - 1472.93s | Goes with a major micropython version 1474.41s - 1478.25s | You want to have you can have so there's a flag in there for or 1479.13s - 1483.81s | And you can have it per function whether it's native or non-native byte code 1483.81s - 1485.81s | so you can have 1486.21s - 1488.13s | you can have 1488.13s - 1492.13s | mpy module where the actual code of a function is 1493.01s - 1496.13s | native say arm or MIPS or whatever or 1497.33s - 1500.57s | Byte you like not byte code machine code, right? 1501.05s - 1506.65s | Now for my money that would be a lot easier because I can just if I get a pointer to that 1506.85s - 1512.93s | Like gaedra will will decom disassemble and decompile that for me and I'm and I'm off to the races 1512.93s - 1514.77s | I don't have to interpret byte code 1514.77s - 1520.21s | so we're going with what I think is the harder example is if it's actual Python byte code there and 1523.01s - 1524.65s | then 1524.65s - 1526.65s | There's a data type that 1527.09s - 1535.05s | comes up frequently in this called a variably in a variably encoded unsigned


chunk_id: 151_chunk_27
chunk_text:
want to have you can have so there's a flag in there for or 1479.13s - 1483.81s | And you can have it per function whether it's native or non-native byte code 1483.81s - 1485.81s | so you can have 1486.21s - 1488.13s | you can have 1488.13s - 1492.13s | mpy module where the actual code of a function is 1493.01s - 1496.13s | native say arm or MIPS or whatever or 1497.33s - 1500.57s | Byte you like not byte code machine code, right? 1501.05s - 1506.65s | Now for my money that would be a lot easier because I can just if I get a pointer to that 1506.85s - 1512.93s | Like gaedra will will decom disassemble and decompile that for me and I'm and I'm off to the races 1512.93s - 1514.77s | I don't have to interpret byte code 1514.77s - 1520.21s | so we're going with what I think is the harder example is if it's actual Python byte code there and 1523.01s - 1524.65s | then 1524.65s - 1526.65s | There's a data type that 1527.09s - 1535.05s | comes up frequently in this called a variably in a variably encoded unsigned integer of V u int and 1535.49s - 1539.73s | This mean I don't know. Maybe this is more common in microcontrollers than I know 1540.17s - 1543.93s | but but I had to take a close look at this and basically a 1544.45s - 1545.85s | This is a 1545.85s - 1547.85s | variable length integer 1548.49s - 1552.41s | that for each byte the lower seven bits is 1553.05s - 1556.57s | Is part of the integer and if there are more bits? 1557.05s - 1560.57s | Then the eighth bit is set and so if the eighth bit is set then you know 1560.57s - 1560.97s | Okay 1560.97s - 1566.01s | I got to read another seven bits from the next byte and so on and so forth and it can be 1566.25s - 1570.57s | Arbitrarily long right and have a represent an arbitrarily large number 1570.97s - 1573.45s | However much makes sense on your microcontroller 1573.45s - 1579.45s | And so this is a data type that that micro Python uses in a lot of its data structures 1579.45s - 1582.97s | And it can be a little bit of a mind bender


chunk_id: 151_chunk_28
chunk_text:
integer of V u int and 1535.49s - 1539.73s | This mean I don't know. Maybe this is more common in microcontrollers than I know 1540.17s - 1543.93s | but but I had to take a close look at this and basically a 1544.45s - 1545.85s | This is a 1545.85s - 1547.85s | variable length integer 1548.49s - 1552.41s | that for each byte the lower seven bits is 1553.05s - 1556.57s | Is part of the integer and if there are more bits? 1557.05s - 1560.57s | Then the eighth bit is set and so if the eighth bit is set then you know 1560.57s - 1560.97s | Okay 1560.97s - 1566.01s | I got to read another seven bits from the next byte and so on and so forth and it can be 1566.25s - 1570.57s | Arbitrarily long right and have a represent an arbitrarily large number 1570.97s - 1573.45s | However much makes sense on your microcontroller 1573.45s - 1579.45s | And so this is a data type that that micro Python uses in a lot of its data structures 1579.45s - 1582.97s | And it can be a little bit of a mind bender to work with 1583.53s - 1587.31s | so in 1587.31s - 1593.55s | The hello world dot mpy we have a number of the the intern strings that we want to have in there 1594.23s - 1596.23s | And we'll see in there 1596.31s - 1603.31s | We only we only store the actual string data for strings that aren't already in the constant pool 1603.59s - 1608.03s | So if something's already built into micro Python, we don't redefine that string 1608.03s - 1612.43s | We just make a reference to it. And so when we're creating our mpy file, we have to be 1613.27s - 1618.67s | Mindful of which which strings are new essentially which strings are what pool they come from? 1619.19s - 1625.82s | So frozen module cue strings get mixed together in 1626.34s - 1629.40s | In a in a in a mpq string 1630.02s - 1631.90s | Frozen constant pool, right? 1631.90s - 1637.54s | And so that's one of a few different pools in there that are all in a linked list 1637.82s - 1642.16s | Where across the linked list there's unique indexes for each string, right? 1642.74s - 1644.74s |


chunk_id: 151_chunk_29
chunk_text:
to work with 1583.53s - 1587.31s | so in 1587.31s - 1593.55s | The hello world dot mpy we have a number of the the intern strings that we want to have in there 1594.23s - 1596.23s | And we'll see in there 1596.31s - 1603.31s | We only we only store the actual string data for strings that aren't already in the constant pool 1603.59s - 1608.03s | So if something's already built into micro Python, we don't redefine that string 1608.03s - 1612.43s | We just make a reference to it. And so when we're creating our mpy file, we have to be 1613.27s - 1618.67s | Mindful of which which strings are new essentially which strings are what pool they come from? 1619.19s - 1625.82s | So frozen module cue strings get mixed together in 1626.34s - 1629.40s | In a in a in a mpq string 1630.02s - 1631.90s | Frozen constant pool, right? 1631.90s - 1637.54s | And so that's one of a few different pools in there that are all in a linked list 1637.82s - 1642.16s | Where across the linked list there's unique indexes for each string, right? 1642.74s - 1644.74s | so 1645.10s - 1647.02s | So to find 1647.02s - 1649.02s | to find that pool 1649.94s - 1654.86s | The easiest thing to do is to go through if you can find the main function 1654.86s - 1658.86s | Which you'd have here new to reverse engineering may be the the tough part 1658.90s - 1664.50s | But if you can kind of trace through the very beginnings of execution of that binary if you can find main 1665.70s - 1670.70s | There's MP in it and then cue string in it and in the first four instructions in there 1670.70s - 1674.54s | There is a reference to the cue string frozen constant pool 1675.06s - 1681.30s | You can search for a string that you know as part of that module like if you've just run strings on the binary 1681.42s - 1687.02s | You'll have seen some of it and you can just do cross for cross references back from that if you really want to 1687.58s - 1694.44s | So so if we're gonna parse these pools, we got to look at the data type for it 1694.44s - 1699.88s | So a pool has


chunk_id: 151_chunk_30
chunk_text:
so 1645.10s - 1647.02s | So to find 1647.02s - 1649.02s | to find that pool 1649.94s - 1654.86s | The easiest thing to do is to go through if you can find the main function 1654.86s - 1658.86s | Which you'd have here new to reverse engineering may be the the tough part 1658.90s - 1664.50s | But if you can kind of trace through the very beginnings of execution of that binary if you can find main 1665.70s - 1670.70s | There's MP in it and then cue string in it and in the first four instructions in there 1670.70s - 1674.54s | There is a reference to the cue string frozen constant pool 1675.06s - 1681.30s | You can search for a string that you know as part of that module like if you've just run strings on the binary 1681.42s - 1687.02s | You'll have seen some of it and you can just do cross for cross references back from that if you really want to 1687.58s - 1694.44s | So so if we're gonna parse these pools, we got to look at the data type for it 1694.44s - 1699.88s | So a pool has a previous pointer to the previous pool in this linked list of pools 1700.60s - 1704.72s | you can move backwards in the pools, but not forwards and so 1705.48s - 1707.48s | That's why that first 1707.68s - 1714.28s | Those first instructions in that cue string and then refer to the frozen constant pool because that's going to be the last one probably 1715.28s - 1720.68s | There's a total previous length that you use to figure out where the indexes start in this pool 1721.92s - 1725.32s | There's a few other fields that don't make a whole lot of difference 1725.32s - 1729.64s | But at the end you have a list of hash values for the strings 1730.20s - 1734.80s | You have a list of lengths for the strings and then you have a list of the data, right? 1734.80s - 1738.36s | And so the string data is just going to be every string can take catenated together 1739.20s - 1743.28s | solidly with nothing in between because that lengths field in the previous 1744.04s - 1749.04s | The previous pointer or that that list will tell you the lengths of each of


chunk_id: 151_chunk_31
chunk_text:
a previous pointer to the previous pool in this linked list of pools 1700.60s - 1704.72s | you can move backwards in the pools, but not forwards and so 1705.48s - 1707.48s | That's why that first 1707.68s - 1714.28s | Those first instructions in that cue string and then refer to the frozen constant pool because that's going to be the last one probably 1715.28s - 1720.68s | There's a total previous length that you use to figure out where the indexes start in this pool 1721.92s - 1725.32s | There's a few other fields that don't make a whole lot of difference 1725.32s - 1729.64s | But at the end you have a list of hash values for the strings 1730.20s - 1734.80s | You have a list of lengths for the strings and then you have a list of the data, right? 1734.80s - 1738.36s | And so the string data is just going to be every string can take catenated together 1739.20s - 1743.28s | solidly with nothing in between because that lengths field in the previous 1744.04s - 1749.04s | The previous pointer or that that list will tell you the lengths of each of them 1749.04s - 1753.04s | So you have to parse both of those arrays together to figure out 1754.24s - 1755.96s | What each string is? 1755.96s - 1760.26s | so with 1760.30s - 1767.78s | The previous pool is the previous pool to the frozen pool is the mpq string constant pool the total previous length 1768.06s - 1770.06s | in our example is 1770.10s - 1771.62s | 3c2 1771.62s - 1776.90s | So that's where the indexes start for the frozen modules. So any cue string index 1777.94s - 1780.86s | Greater than is so any cue string greater than 1781.58s - 1786.66s | 962 is going to be in our frozen pool, which means that when we recreate our mpy 1786.90s - 1789.42s | We're gonna have to include that data into our mpy 1790.30s - 1794.02s | Anything less than that. We can just include the number and not re encode the string 1794.02s - 1803.25s | And so there's our list of indexes. And so there's a constant string cue string table data 1804.09s - 1810.41s | For hello world that you can locate through there and that's the indexes. And so that first one


chunk_id: 151_chunk_32
chunk_text:
them 1749.04s - 1753.04s | So you have to parse both of those arrays together to figure out 1754.24s - 1755.96s | What each string is? 1755.96s - 1760.26s | so with 1760.30s - 1767.78s | The previous pool is the previous pool to the frozen pool is the mpq string constant pool the total previous length 1768.06s - 1770.06s | in our example is 1770.10s - 1771.62s | 3c2 1771.62s - 1776.90s | So that's where the indexes start for the frozen modules. So any cue string index 1777.94s - 1780.86s | Greater than is so any cue string greater than 1781.58s - 1786.66s | 962 is going to be in our frozen pool, which means that when we recreate our mpy 1786.90s - 1789.42s | We're gonna have to include that data into our mpy 1790.30s - 1794.02s | Anything less than that. We can just include the number and not re encode the string 1794.02s - 1803.25s | And so there's our list of indexes. And so there's a constant string cue string table data 1804.09s - 1810.41s | For hello world that you can locate through there and that's the indexes. And so that first one 1811.81s - 1814.41s | That first one since it's greater than 962 1815.01s - 1822.13s | We're gonna have to encode that string. Hello world py into our mpy file, but 7 which is just like the open tag module 1822.77s - 1828.65s | Closed tag is already in the micropython binary. So we just include 7 and we don't re encode it 1829.41s - 1832.41s | And so this is how it looks when we re encode it 1833.25s - 1839.89s | This is so we've already written the header, which is those first handful of bytes. The highlighted portion is the string table 1840.89s - 1848.85s | There's a view in where basically it defines whether or not it's a static entry or one that's defined in this mpy 1848.85s - 1851.09s | So are we providing it an index? 1851.09s - 1859.40s | Are we providing it a new string and then the string follows and that's why you see in that dump you see 1859.96s - 1864.48s | The string data for the new strings, but not the built-in strings 1865.08s - 1874.79s | So the next thing that you have to do is to build


chunk_id: 151_chunk_33
chunk_text:
1811.81s - 1814.41s | That first one since it's greater than 962 1815.01s - 1822.13s | We're gonna have to encode that string. Hello world py into our mpy file, but 7 which is just like the open tag module 1822.77s - 1828.65s | Closed tag is already in the micropython binary. So we just include 7 and we don't re encode it 1829.41s - 1832.41s | And so this is how it looks when we re encode it 1833.25s - 1839.89s | This is so we've already written the header, which is those first handful of bytes. The highlighted portion is the string table 1840.89s - 1848.85s | There's a view in where basically it defines whether or not it's a static entry or one that's defined in this mpy 1848.85s - 1851.09s | So are we providing it an index? 1851.09s - 1859.40s | Are we providing it a new string and then the string follows and that's why you see in that dump you see 1859.96s - 1864.48s | The string data for the new strings, but not the built-in strings 1865.08s - 1874.79s | So the next thing that you have to do is to build the object table 1874.79s - 1881.71s | Now this is a more complex data structure and as especially as you get further from hello world 1882.31s - 1887.47s | This is going to get more and more complicated it the more they're gonna the more they're using 1888.47s - 1895.59s | Python objects the the the harder this parts going to become but you can like follow through and 1895.91s - 1897.91s | And recreate these as well 1898.07s - 1904.43s | Copy really what you can do is you can copy these almost straight out of memory and put them into your binary 1904.43s - 1907.35s | And it'll just work without you necessarily having to understand them at first 1907.75s - 1914.75s | Then once you get this thing fully recreated you can load it into that Unix micro Python interpreter and 1915.59s - 1926.82s | and start probing those objects from the REPL, which is much easier and then finally the bytecode so 1928.50s - 1934.86s | There's a format that for this code that we have to generate if you look in mpytool.py's code 1935.06s - 1937.30s | There's a function called read raw code 1937.66s


chunk_id: 151_chunk_34
chunk_text:
the object table 1874.79s - 1881.71s | Now this is a more complex data structure and as especially as you get further from hello world 1882.31s - 1887.47s | This is going to get more and more complicated it the more they're gonna the more they're using 1888.47s - 1895.59s | Python objects the the the harder this parts going to become but you can like follow through and 1895.91s - 1897.91s | And recreate these as well 1898.07s - 1904.43s | Copy really what you can do is you can copy these almost straight out of memory and put them into your binary 1904.43s - 1907.35s | And it'll just work without you necessarily having to understand them at first 1907.75s - 1914.75s | Then once you get this thing fully recreated you can load it into that Unix micro Python interpreter and 1915.59s - 1926.82s | and start probing those objects from the REPL, which is much easier and then finally the bytecode so 1928.50s - 1934.86s | There's a format that for this code that we have to generate if you look in mpytool.py's code 1935.06s - 1937.30s | There's a function called read raw code 1937.66s - 1943.06s | That sort of hints to you as to how we need to build this bytecode so that it can read it 1945.18s - 1949.26s | So the pointer to the code is the third field of that module and so you see 1949.54s - 1951.82s | the frozen module hello world there 1951.82s - 1955.22s | And you see the Q string table the object table 1955.22s - 1961.70s | And then you see the pointer to the first element of code and that's for the prototype function for this object 1962.18s - 1963.62s | right and 1963.62s - 1964.82s | so 1964.82s - 1967.30s | each each function each 1968.06s - 1971.54s | Sorry each piece of bytecode can have children so 1972.86s - 1977.34s | the prototype for this module is going to have a child of 1977.90s - 1980.90s | the go function that's inside of this module and 1981.34s - 1987.42s | So it's going to contiguous or continuously rather or parse these elements of code 1987.66s - 1989.82s | see whether they have children or not and 1990.54s - 1995.82s | Recursively follow down and once you've part parsed everything that doesn't


chunk_id: 151_chunk_35
chunk_text:
- 1943.06s | That sort of hints to you as to how we need to build this bytecode so that it can read it 1945.18s - 1949.26s | So the pointer to the code is the third field of that module and so you see 1949.54s - 1951.82s | the frozen module hello world there 1951.82s - 1955.22s | And you see the Q string table the object table 1955.22s - 1961.70s | And then you see the pointer to the first element of code and that's for the prototype function for this object 1962.18s - 1963.62s | right and 1963.62s - 1964.82s | so 1964.82s - 1967.30s | each each function each 1968.06s - 1971.54s | Sorry each piece of bytecode can have children so 1972.86s - 1977.34s | the prototype for this module is going to have a child of 1977.90s - 1980.90s | the go function that's inside of this module and 1981.34s - 1987.42s | So it's going to contiguous or continuously rather or parse these elements of code 1987.66s - 1989.82s | see whether they have children or not and 1990.54s - 1995.82s | Recursively follow down and once you've part parsed everything that doesn't have children 1995.82s - 2000.58s | then you can walk back up that recursion and you've parsed all the bytecode out and 2001.50s - 2004.30s | so on the left there you see the bytecode for 2005.30s - 2006.46s | for the 2006.46s - 2012.66s | For the constructor and on the right you see the bytecode for the go function which prints 2012.66s - 2017.94s | Hello world in a loop basically and so one is the child of the other essentially 2018.38s - 2030.14s | So reconstructing this there are V u ints for the kind the length and whether or not the code has children 2030.14s - 2032.38s | So when we're putting this into our mpy binary 2032.38s - 2036.38s | It needs to know how to reconstruct this into memory in a useful way for the interpreter 2036.38s - 2041.54s | And so it's using those V u ints to to do this and so there's a kind 2041.86s - 2048.62s | whether it's bytecode or native code again these things can be compiled down to where it's native arm code for a function and 2049.02s - 2052.10s | Like I said, if that's the


chunk_id: 151_chunk_36
chunk_text:
have children 1995.82s - 2000.58s | then you can walk back up that recursion and you've parsed all the bytecode out and 2001.50s - 2004.30s | so on the left there you see the bytecode for 2005.30s - 2006.46s | for the 2006.46s - 2012.66s | For the constructor and on the right you see the bytecode for the go function which prints 2012.66s - 2017.94s | Hello world in a loop basically and so one is the child of the other essentially 2018.38s - 2030.14s | So reconstructing this there are V u ints for the kind the length and whether or not the code has children 2030.14s - 2032.38s | So when we're putting this into our mpy binary 2032.38s - 2036.38s | It needs to know how to reconstruct this into memory in a useful way for the interpreter 2036.38s - 2041.54s | And so it's using those V u ints to to do this and so there's a kind 2041.86s - 2048.62s | whether it's bytecode or native code again these things can be compiled down to where it's native arm code for a function and 2049.02s - 2052.10s | Like I said, if that's the case if you see something code like that 2052.34s - 2059.34s | Just just drop your cursor and Ghidra or Idapro on that hit disassemble and you're off to the races, right? 2059.34s - 2062.58s | You can you can read what it's doing a little bit easier 2062.74s - 2068.42s | But if it's not it's just if it's bytecode Ghidra doesn't have a decoder for this unless you want to write one 2068.42s - 2070.42s | I didn't want to 2070.78s - 2072.78s | Kara back there probably will oh 2073.46s - 2075.46s | and 2076.18s - 2081.18s | But uh, but if you don't want to write a module to interpret this bytecode 2082.18s - 2087.50s | You're good. You're gonna be left to pulling it out and dropping it in this file. So the mpy tool can do this for us 2088.26s - 2092.98s | The third the third bit or is there a child for this block or not? 2092.98s - 2096.94s | Right, and so that makes it recursively go through and read more code 2097.58s - 2103.06s | So the one big problem with this and I wanted to write a tool 2103.38s


chunk_id: 151_chunk_37
chunk_text:
case if you see something code like that 2052.34s - 2059.34s | Just just drop your cursor and Ghidra or Idapro on that hit disassemble and you're off to the races, right? 2059.34s - 2062.58s | You can you can read what it's doing a little bit easier 2062.74s - 2068.42s | But if it's not it's just if it's bytecode Ghidra doesn't have a decoder for this unless you want to write one 2068.42s - 2070.42s | I didn't want to 2070.78s - 2072.78s | Kara back there probably will oh 2073.46s - 2075.46s | and 2076.18s - 2081.18s | But uh, but if you don't want to write a module to interpret this bytecode 2082.18s - 2087.50s | You're good. You're gonna be left to pulling it out and dropping it in this file. So the mpy tool can do this for us 2088.26s - 2092.98s | The third the third bit or is there a child for this block or not? 2092.98s - 2096.94s | Right, and so that makes it recursively go through and read more code 2097.58s - 2103.06s | So the one big problem with this and I wanted to write a tool 2103.38s - 2106.54s | That would just sort of walk through a binary and do this 2107.58s - 2113.06s | but it's actually tricky to do because the length of the code is not 2114.38s - 2116.06s | Referenced anywhere, right? 2116.06s - 2120.42s | The length of the code is defined by the fact that the code never exists 2120.50s - 2124.54s | Never steps outside of it the the bounds of its memory locations 2124.88s - 2125.98s | So there's no length 2125.98s - 2132.46s | it just starts execution there and it'll just keep going as long as there's code and as long as it doesn't return and as long as 2132.82s - 2138.26s | Looping around it'll just sort of loop in that space. So there's no defined length for it, but which I don't know 2138.26s - 2139.62s | Maybe you can figure out a problem there 2139.62s - 2141.70s | Maybe you could exploit that in some way 2141.94s - 2147.50s | But there's no length and so it's hard in an automated fashion without parsing the bytecode to know the length 2147.70s - 2154.06s | Of it and so you may have to eyeball


chunk_id: 151_chunk_38
chunk_text:
- 2106.54s | That would just sort of walk through a binary and do this 2107.58s - 2113.06s | but it's actually tricky to do because the length of the code is not 2114.38s - 2116.06s | Referenced anywhere, right? 2116.06s - 2120.42s | The length of the code is defined by the fact that the code never exists 2120.50s - 2124.54s | Never steps outside of it the the bounds of its memory locations 2124.88s - 2125.98s | So there's no length 2125.98s - 2132.46s | it just starts execution there and it'll just keep going as long as there's code and as long as it doesn't return and as long as 2132.82s - 2138.26s | Looping around it'll just sort of loop in that space. So there's no defined length for it, but which I don't know 2138.26s - 2139.62s | Maybe you can figure out a problem there 2139.62s - 2141.70s | Maybe you could exploit that in some way 2141.94s - 2147.50s | But there's no length and so it's hard in an automated fashion without parsing the bytecode to know the length 2147.70s - 2154.06s | Of it and so you may have to eyeball that part of it or parse the bytecode yourself kind of trial and error 2155.14s - 2159.14s | each block of code is followed recursively by its own children and 2160.10s - 2163.42s | And so here you see in the first screenshot 2163.42s - 2169.66s | we're encoding those integers and then plopping in the bytecode for the 2170.18s - 2174.98s | for the for the constructor mod for the constructor for the module and 2175.58s - 2178.90s | then next since it has a child of the go function and 2179.62s - 2182.18s | It goes and we go and parse that out 2182.18s - 2187.30s | We put the V u ints for it in there and then we put the bytecode in for the go function 2188.22s - 2193.18s | Once you think you've created and at this point like if you take these slides and you go back 2193.42s - 2201.10s | You'll see that this is bit for bit identical to the original mpy file for the for the hello world dot mpy 2202.70s - 2209.06s | We can use my Unix port to examine this we can so we can load up the


chunk_id: 151_chunk_39
chunk_text:
that part of it or parse the bytecode yourself kind of trial and error 2155.14s - 2159.14s | each block of code is followed recursively by its own children and 2160.10s - 2163.42s | And so here you see in the first screenshot 2163.42s - 2169.66s | we're encoding those integers and then plopping in the bytecode for the 2170.18s - 2174.98s | for the for the constructor mod for the constructor for the module and 2175.58s - 2178.90s | then next since it has a child of the go function and 2179.62s - 2182.18s | It goes and we go and parse that out 2182.18s - 2187.30s | We put the V u ints for it in there and then we put the bytecode in for the go function 2188.22s - 2193.18s | Once you think you've created and at this point like if you take these slides and you go back 2193.42s - 2201.10s | You'll see that this is bit for bit identical to the original mpy file for the for the hello world dot mpy 2202.70s - 2209.06s | We can use my Unix port to examine this we can so we can load up the Unix port of micro Python 2209.62s - 2214.58s | Import that mpy file start looking at the object start looking at the modules 2214.86s - 2219.70s | Do the dict function to see what functions are available in there. We can call them 2221.06s - 2224.14s | There is a there is a tracing tool in 2224.94s - 2228.38s | Or actually, this is not the this the tracing tools in the next slide 2228.94s - 2232.44s | This is another example that you can just sort of eyeball on your own 2233.22s - 2235.10s | of a 2235.10s - 2241.70s | this this code right here will make a little light show on all the GPIO pins of a 2242.22s - 2246.02s | of a Pico basically just starts strobing all the the 2247.02s - 2252.02s | GPIO in a pattern if you have a dev board that has LEDs on all the pins 2252.22s - 2254.22s | It'll do a little neat thing for you 2254.86s - 2256.70s | That's the code that 2256.70s - 2258.30s | this is the 2258.30s - 2261.94s | This is the code that does this but since it's doing GPIO 2263.38s -


chunk_id: 151_chunk_40
chunk_text:
Unix port of micro Python 2209.62s - 2214.58s | Import that mpy file start looking at the object start looking at the modules 2214.86s - 2219.70s | Do the dict function to see what functions are available in there. We can call them 2221.06s - 2224.14s | There is a there is a tracing tool in 2224.94s - 2228.38s | Or actually, this is not the this the tracing tools in the next slide 2228.94s - 2232.44s | This is another example that you can just sort of eyeball on your own 2233.22s - 2235.10s | of a 2235.10s - 2241.70s | this this code right here will make a little light show on all the GPIO pins of a 2242.22s - 2246.02s | of a Pico basically just starts strobing all the the 2247.02s - 2252.02s | GPIO in a pattern if you have a dev board that has LEDs on all the pins 2252.22s - 2254.22s | It'll do a little neat thing for you 2254.86s - 2256.70s | That's the code that 2256.70s - 2258.30s | this is the 2258.30s - 2261.94s | This is the code that does this but since it's doing GPIO 2263.38s - 2268.74s | It won't work on the Unix micro Python because it's doing like the pin function and stuff like that 2268.74s - 2272.66s | You don't have GPIO on the Unix version of micro of micro Python 2272.86s - 2276.82s | So what you need to do is like if if the code you pull out 2277.58s - 2279.58s | Uses a function that's not there 2279.58s - 2282.42s | You're gonna have to implement some sort of stand stand in there 2282.42s - 2286.22s | And so then you can run it in the Unix port as long as you have those functions available 2286.70s - 2292.93s | you can build micro Python with sys set trace where you get a trace of 2294.09s - 2297.69s | Execution. It's not quite what you'd expect. It's not a very detailed trace 2297.69s - 2302.05s | It basically tells you which portion of the bytecode is executing 2302.65s - 2308.53s | In a very in a very non-granular fashion. It just basically tells you which function is executing when 2308.97s - 2316.01s | But you have to build you have to define this when you're building your micro Python binary


chunk_id: 151_chunk_41
chunk_text:
2268.74s | It won't work on the Unix micro Python because it's doing like the pin function and stuff like that 2268.74s - 2272.66s | You don't have GPIO on the Unix version of micro of micro Python 2272.86s - 2276.82s | So what you need to do is like if if the code you pull out 2277.58s - 2279.58s | Uses a function that's not there 2279.58s - 2282.42s | You're gonna have to implement some sort of stand stand in there 2282.42s - 2286.22s | And so then you can run it in the Unix port as long as you have those functions available 2286.70s - 2292.93s | you can build micro Python with sys set trace where you get a trace of 2294.09s - 2297.69s | Execution. It's not quite what you'd expect. It's not a very detailed trace 2297.69s - 2302.05s | It basically tells you which portion of the bytecode is executing 2302.65s - 2308.53s | In a very in a very non-granular fashion. It just basically tells you which function is executing when 2308.97s - 2316.01s | But you have to build you have to define this when you're building your micro Python binary or your micro Python Unix port 2318.74s - 2320.06s | the 2320.06s - 2327.66s | The bytecode itself. This is the hello world bytecode. Basically, you're loading a global object of print the print function 2327.82s - 2335.42s | You're loading the hello cruel world string you're calling the function you pop the string off the top of the stack 2335.66s - 2341.10s | You load the global time module you load the method sleep from it you load 2341.62s - 2347.62s | Some constant integer of five because you want to wait for five seconds you sleep for five seconds by calling the method 2347.94s - 2354.18s | You pop the top off of that and then you jump back 17 bytes and then you loop around and you do it again 2354.18s - 2358.18s | And so that's the length. That's the very basics of the language here 2360.54s - 2362.30s | If you want to learn 2362.30s - 2368.18s | This bytecode if you really want to take the time to step through bytecode of this and not just sort of interactively do it 2368.70s - 2372.70s | you'll want to read through the mpy tool opcode


chunk_id: 151_chunk_42
chunk_text:
or your micro Python Unix port 2318.74s - 2320.06s | the 2320.06s - 2327.66s | The bytecode itself. This is the hello world bytecode. Basically, you're loading a global object of print the print function 2327.82s - 2335.42s | You're loading the hello cruel world string you're calling the function you pop the string off the top of the stack 2335.66s - 2341.10s | You load the global time module you load the method sleep from it you load 2341.62s - 2347.62s | Some constant integer of five because you want to wait for five seconds you sleep for five seconds by calling the method 2347.94s - 2354.18s | You pop the top off of that and then you jump back 17 bytes and then you loop around and you do it again 2354.18s - 2358.18s | And so that's the length. That's the very basics of the language here 2360.54s - 2362.30s | If you want to learn 2362.30s - 2368.18s | This bytecode if you really want to take the time to step through bytecode of this and not just sort of interactively do it 2368.70s - 2372.70s | you'll want to read through the mpy tool opcode class and 2373.58s - 2378.70s | Also an in class in terms of like the class definition not like a class that you sit down and learn 2379.38s - 2386.88s | There's a VM dot C and micro Python that has like the VM interpreter for this bytecode in there that you can read as well 2387.14s - 2389.14s | This is not compatible with CPython 2389.70s - 2396.50s | But it but familiarity with that would help if you if you read through some Python bytecode tutorials, you'll understand what this is going 2400.31s - 2406.55s | Conclusions on this I'd really rather be reversing compiled C than this like like using micro Python and like 2407.31s - 2413.43s | Like like creating bytecode out of your functions and stuff. It's probably a almost a better 2414.39s - 2417.43s | obfuscation of your code than like 2418.11s - 2421.95s | Compiling a C firmware for your for your microcontroller 2421.95s - 2424.75s | It's just annoying right to try to read through this 2424.95s - 2431.19s | Yourself if you're if you're more used to reading arm assembly if you're more used to reading decompiled C 2432.71s - 2434.71s


chunk_id: 151_chunk_43
chunk_text:
class and 2373.58s - 2378.70s | Also an in class in terms of like the class definition not like a class that you sit down and learn 2379.38s - 2386.88s | There's a VM dot C and micro Python that has like the VM interpreter for this bytecode in there that you can read as well 2387.14s - 2389.14s | This is not compatible with CPython 2389.70s - 2396.50s | But it but familiarity with that would help if you if you read through some Python bytecode tutorials, you'll understand what this is going 2400.31s - 2406.55s | Conclusions on this I'd really rather be reversing compiled C than this like like using micro Python and like 2407.31s - 2413.43s | Like like creating bytecode out of your functions and stuff. It's probably a almost a better 2414.39s - 2417.43s | obfuscation of your code than like 2418.11s - 2421.95s | Compiling a C firmware for your for your microcontroller 2421.95s - 2424.75s | It's just annoying right to try to read through this 2424.95s - 2431.19s | Yourself if you're if you're more used to reading arm assembly if you're more used to reading decompiled C 2432.71s - 2434.71s | It's doable though, right 2434.99s - 2440.59s | And if you're if you're really wanting to mess around with with with a device that does this it's doable 2442.51s - 2445.47s | These frozen modules are a great way to like 2446.07s - 2453.19s | Include project specific stuff like like really the last stage of your development and deployment of a micro Python firmware 2453.23s - 2457.63s | Should be to put as many of your modules into this form as possible 2457.83s - 2460.75s | Because it's just going to save memory and execution time 2461.15s - 2464.71s | This is not a way to hide or obfuscate code or secrets though 2465.99s - 2472.71s | Don't use it for that. Especially now that this talk is out and in this room of people know how to do it, right? So 2473.47s - 2479.31s | Doing don't use this to go screw around with other people's CTFs and ways that ruin the fun for other people 2479.51s - 2484.27s | But if you if you're like me and you're fun, you make your own fun, right? 2484.55s - 2489.19s | You don't really follow the rules on


chunk_id: 151_chunk_44
chunk_text:
| It's doable though, right 2434.99s - 2440.59s | And if you're if you're really wanting to mess around with with with a device that does this it's doable 2442.51s - 2445.47s | These frozen modules are a great way to like 2446.07s - 2453.19s | Include project specific stuff like like really the last stage of your development and deployment of a micro Python firmware 2453.23s - 2457.63s | Should be to put as many of your modules into this form as possible 2457.83s - 2460.75s | Because it's just going to save memory and execution time 2461.15s - 2464.71s | This is not a way to hide or obfuscate code or secrets though 2465.99s - 2472.71s | Don't use it for that. Especially now that this talk is out and in this room of people know how to do it, right? So 2473.47s - 2479.31s | Doing don't use this to go screw around with other people's CTFs and ways that ruin the fun for other people 2479.51s - 2484.27s | But if you if you're like me and you're fun, you make your own fun, right? 2484.55s - 2489.19s | You don't really follow the rules on the CTF you guys just play around with it not even score any points 2489.31s - 2491.31s | This this is fun for that 2492.63s - 2496.35s | It's it's only as well protected as access to your firmware 2497.79s - 2500.99s | And so if you can dump from flash if you can dump from the ripple 2501.51s - 2505.87s | If you can grab over the air updates for things you can get at this stuff 2505.91s - 2511.47s | So it's not a layer of protection and you could probably automate this extraction process 2511.47s - 2516.37s | But it's a bit tricky to figure out the lengths of some of that some of those data structures, too 2517.47s - 2518.83s | so 2518.83s - 2523.59s | one thing that that that you should do if you are 2524.19s - 2530.95s | interested in this sort of stuff if you like the idea of learning how to use Ghidra to step through the 2531.51s - 2537.47s | To step through all these data structures if you want to learn how to sort of navigate around code and Ghidra 2538.03s - 2541.99s | There's a great book from


chunk_id: 151_chunk_45
chunk_text:
the CTF you guys just play around with it not even score any points 2489.31s - 2491.31s | This this is fun for that 2492.63s - 2496.35s | It's it's only as well protected as access to your firmware 2497.79s - 2500.99s | And so if you can dump from flash if you can dump from the ripple 2501.51s - 2505.87s | If you can grab over the air updates for things you can get at this stuff 2505.91s - 2511.47s | So it's not a layer of protection and you could probably automate this extraction process 2511.47s - 2516.37s | But it's a bit tricky to figure out the lengths of some of that some of those data structures, too 2517.47s - 2518.83s | so 2518.83s - 2523.59s | one thing that that that you should do if you are 2524.19s - 2530.95s | interested in this sort of stuff if you like the idea of learning how to use Ghidra to step through the 2531.51s - 2537.47s | To step through all these data structures if you want to learn how to sort of navigate around code and Ghidra 2538.03s - 2541.99s | There's a great book from no starch press called the Ghidra book 2542.95s - 2544.79s | appropriately named 2544.79s - 2551.83s | By Karen ants and Chris Eagle and Karen answers in our audience here right now and I've been she's been giving me the eye 2552.39s - 2554.23s | to mention this 2554.23s - 2555.91s | the whole time 2555.91s - 2561.55s | She's actually gonna be at the no starch booth this afternoon doing a book signing. I want to say 2562.07s - 2563.43s | 330 2563.43s - 2570.19s | 330 she's gonna be at the at the booth over there. No starch doing book signing go buy that book and get her autograph and 2571.03s - 2577.75s | And and she knows everything about micro Python frozen modules as well as divert any questions about this talk to her 2578.23s - 2580.23s | So no 2580.35s - 2585.15s | Ask ask me the things and so with that I'm gonna close this off 2585.59s - 2591.59s | I appreciate y'all coming to this instead of pony awards. However poor of a choice that might have been 2592.63s - 2595.55s | And I look forward to interacting with y'all 2596.27s - 2598.27s |


chunk_id: 151_chunk_46
chunk_text:
no starch press called the Ghidra book 2542.95s - 2544.79s | appropriately named 2544.79s - 2551.83s | By Karen ants and Chris Eagle and Karen answers in our audience here right now and I've been she's been giving me the eye 2552.39s - 2554.23s | to mention this 2554.23s - 2555.91s | the whole time 2555.91s - 2561.55s | She's actually gonna be at the no starch booth this afternoon doing a book signing. I want to say 2562.07s - 2563.43s | 330 2563.43s - 2570.19s | 330 she's gonna be at the at the booth over there. No starch doing book signing go buy that book and get her autograph and 2571.03s - 2577.75s | And and she knows everything about micro Python frozen modules as well as divert any questions about this talk to her 2578.23s - 2580.23s | So no 2580.35s - 2585.15s | Ask ask me the things and so with that I'm gonna close this off 2585.59s - 2591.59s | I appreciate y'all coming to this instead of pony awards. However poor of a choice that might have been 2592.63s - 2595.55s | And I look forward to interacting with y'all 2596.27s - 2598.27s | Thank you


chunk_id: 152_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=TeVGbAkhyzg", "title": "DEF CON 32 - Outlook Unleashing RCE Chaos CVE 2024 30103 - Michael Gorelik, Arnold Osipov", "description": "Did you ever receive an empty email and immediately think it might be a reconnaissance attack? What if opening such an email in your Outlook client could trigger remote code execution through an invisible form? Yes, all forms are COM objects, and CVE-2024-21378 has flung open the gates to Outlook RCE chaos.\n\nIn our session, \"Outlook Unleashing RCE Chaos: CVE-2024-30103\" we'll dive into how this seemingly innocuous vulnerability can lead to mayhem. This vulnerability paved the way for us to discover a series of new remote code execution vulnerabilities in Outlook, including CVE-2024-30103. But we\u2019re not stopping there.\n\nAdditionally, we'll uncover other vulnerabilities that can cause NTLM leaks from your domain-joined devices.\n\nSo, how did we get here? Join us as we construct an evolution timeline of this attack surface. From the origins of these exploits to their current incarnations, we'll cover it all. And because we believe in building a safer digital world, we'll conclude with specific, actionable recommendations on how to minimize these threats.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2470, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 1.74s - 3.74s | This text was transcribed using whisper model: large-v2 Hey, good evening to everyone 4.98s - 6.98s | Okay 10.61s - 12.61s | Thank you, thank you, thank you 13.25s - 15.25s | okay, so 15.65s - 17.65s | What do you expect from patches? 17.99s - 19.55s | security updates 19.55s - 26.13s | You expect them to be a fort knox security update right that solves fully the vulnerability all the control flows 26.81s - 31.98s | Is it really in reality? This is what we usually get 33.96s - 36.40s | Yep, so we all been there 37.08s - 42.16s | Expecting that one patch solves it all right, but essentially it's kind of a bullet 43.16s - 46.18s | Patch to a bullet or there's a better phrase to that 46.82s - 48.44s | we will be 48.44s - 53.72s | sharing insights about what happens when the patch not quite do the trick and 55.32s - 57.32s | Sometimes you also find new vulnerabilities 57.56s - 64.60s | So this talk will be sharing new details about vulnerabilities that we discovered and we're patched during June and July 65.48s - 67.48s | those are two out of


chunk_id: 152_chunk_1
chunk_text:
text was transcribed using whisper model: large-v2 Hey, good evening to everyone 4.98s - 6.98s | Okay 10.61s - 12.61s | Thank you, thank you, thank you 13.25s - 15.25s | okay, so 15.65s - 17.65s | What do you expect from patches? 17.99s - 19.55s | security updates 19.55s - 26.13s | You expect them to be a fort knox security update right that solves fully the vulnerability all the control flows 26.81s - 31.98s | Is it really in reality? This is what we usually get 33.96s - 36.40s | Yep, so we all been there 37.08s - 42.16s | Expecting that one patch solves it all right, but essentially it's kind of a bullet 43.16s - 46.18s | Patch to a bullet or there's a better phrase to that 46.82s - 48.44s | we will be 48.44s - 53.72s | sharing insights about what happens when the patch not quite do the trick and 55.32s - 57.32s | Sometimes you also find new vulnerabilities 57.56s - 64.60s | So this talk will be sharing new details about vulnerabilities that we discovered and we're patched during June and July 65.48s - 67.48s | those are two out of 68.24s - 70.24s | bigger number of vulnerabilities 70.28s - 73.24s | Let's not be too harsh with the vendors 73.64s - 80.88s | There's a reason why this happens many time just couple of weeks ago. We all saw the mega crush from a CrowdStrike update 81.40s - 86.56s | It's not exactly security update nevertheless the impact is obvious right blue screens all over 86.72s - 91.88s | And this is exactly the reason why many vendors are kind of trying to solve only the specific problem 92.72s - 94.72s | while the doing so also 95.24s - 96.96s | kind of 96.96s - 103.02s | Share with us the investigative researchers on additional vulnerabilities that are within the code 104.16s - 106.32s | So just very shortly about 107.04s - 112.00s | Ourself my name is Michael Grelick. I'm the chief technology officer and founder of Morphi sec 112.00s - 115.36s | I have around 20 years of experience in cyber security 116.00s - 121.72s | Was the one to discover one of the largest supply chain attacks the C cleaner in history 122.88s - 127.52s | have a lot of experience in the reverse engineering red


chunk_id: 152_chunk_2
chunk_text:
68.24s - 70.24s | bigger number of vulnerabilities 70.28s - 73.24s | Let's not be too harsh with the vendors 73.64s - 80.88s | There's a reason why this happens many time just couple of weeks ago. We all saw the mega crush from a CrowdStrike update 81.40s - 86.56s | It's not exactly security update nevertheless the impact is obvious right blue screens all over 86.72s - 91.88s | And this is exactly the reason why many vendors are kind of trying to solve only the specific problem 92.72s - 94.72s | while the doing so also 95.24s - 96.96s | kind of 96.96s - 103.02s | Share with us the investigative researchers on additional vulnerabilities that are within the code 104.16s - 106.32s | So just very shortly about 107.04s - 112.00s | Ourself my name is Michael Grelick. I'm the chief technology officer and founder of Morphi sec 112.00s - 115.36s | I have around 20 years of experience in cyber security 116.00s - 121.72s | Was the one to discover one of the largest supply chain attacks the C cleaner in history 122.88s - 127.52s | have a lot of experience in the reverse engineering red teaming and blue teaming and 128.28s - 130.28s | Go ahead Arnold 130.40s - 136.72s | Hey guys. My name is Arnold. I'm leading the malware research efforts at Morphi sec and 137.24s - 142.72s | For some time now. I am poking with some patch analysis for fan and profit and 143.52s - 145.52s | Product of course 146.28s - 149.98s | Thanks, I don't know okay 150.94s - 152.94s | So just starting with a disclaimer 153.58s - 155.58s | With great power comes greater responsibility 156.34s - 158.34s | Use your powers for the good 158.78s - 164.20s | So now about the talk itself a bit about the motivation 165.04s - 171.76s | Some of our work that we're doing in Morphi sec. We are going and reviewing the most critical vulnerabilities 172.36s - 175.68s | That exist especially those that lead to remote code executions 176.48s - 184.32s | The latest vulnerabilities that we were reviewing were ones that discovered by the net spy group done an amazing work 185.28s - 192.24s | On the form injection category basically a category of vulnerabilities that lead to remote code execution 193.20s - 196.16s | But do


chunk_id: 152_chunk_3
chunk_text:
teaming and blue teaming and 128.28s - 130.28s | Go ahead Arnold 130.40s - 136.72s | Hey guys. My name is Arnold. I'm leading the malware research efforts at Morphi sec and 137.24s - 142.72s | For some time now. I am poking with some patch analysis for fan and profit and 143.52s - 145.52s | Product of course 146.28s - 149.98s | Thanks, I don't know okay 150.94s - 152.94s | So just starting with a disclaimer 153.58s - 155.58s | With great power comes greater responsibility 156.34s - 158.34s | Use your powers for the good 158.78s - 164.20s | So now about the talk itself a bit about the motivation 165.04s - 171.76s | Some of our work that we're doing in Morphi sec. We are going and reviewing the most critical vulnerabilities 172.36s - 175.68s | That exist especially those that lead to remote code executions 176.48s - 184.32s | The latest vulnerabilities that we were reviewing were ones that discovered by the net spy group done an amazing work 185.28s - 192.24s | On the form injection category basically a category of vulnerabilities that lead to remote code execution 193.20s - 196.16s | But do require authentication prior authentication 196.84s - 203.76s | Additional category that Arnold will be sharing is about compound monikers also lead to remote code execution 204.52s - 210.40s | Checkpoint done a great research and a great work discovering some vulnerabilities during the year 210.40s - 217.56s | We will also show how the patch doesn't really do the trick and how we discover the additional vulnerabilities by purely looking at the patch 220.35s - 223.35s | Okay, so let's start talking about the forms 223.35s - 230.11s | I mean every of those categories can go a full lecture, so we'll be kind of covering very quickly 230.87s - 235.15s | On the introduction, but you are welcome to see additional details and documentation 236.59s - 243.03s | In the world again on the internet so forms exactly as you would see you get the message 244.39s - 247.75s | You're sending a message. It's eventually based on forms 248.35s - 252.07s | Now message email message is not the only thing that is based on force 252.47s - 256.15s | essentially there is a quite a significant mechanism that works behind and 256.63s - 260.59s | Imagine you


chunk_id: 152_chunk_4
chunk_text:
require authentication prior authentication 196.84s - 203.76s | Additional category that Arnold will be sharing is about compound monikers also lead to remote code execution 204.52s - 210.40s | Checkpoint done a great research and a great work discovering some vulnerabilities during the year 210.40s - 217.56s | We will also show how the patch doesn't really do the trick and how we discover the additional vulnerabilities by purely looking at the patch 220.35s - 223.35s | Okay, so let's start talking about the forms 223.35s - 230.11s | I mean every of those categories can go a full lecture, so we'll be kind of covering very quickly 230.87s - 235.15s | On the introduction, but you are welcome to see additional details and documentation 236.59s - 243.03s | In the world again on the internet so forms exactly as you would see you get the message 244.39s - 247.75s | You're sending a message. It's eventually based on forms 248.35s - 252.07s | Now message email message is not the only thing that is based on force 252.47s - 256.15s | essentially there is a quite a significant mechanism that works behind and 256.63s - 260.59s | Imagine you are sending a recall message on the message that you sent to your boss 260.99s - 266.75s | What happens behind what happens when the recall being sent so essentially it's something there 267.11s - 271.63s | Activates and starts to delete the email from the inboxes of your manager 272.15s - 277.39s | It's a rendering mechanism that is based on again the synchronization of forms 277.83s - 284.03s | And we'll be covering that and we'll share basically how we utilize that to inject malicious forms 284.99s - 290.47s | We'll get back to recall on the coming slides, but let's first talk a bit a bit about 291.03s - 292.95s | forms and custom forms 292.95s - 298.11s | so forms overall can be of two different types now if you 298.83s - 304.51s | Integrate the developer mode in outlook you can see that you can modify existing forms 305.35s - 307.35s | into your own kind of 307.59s - 310.47s | Purpose so if you get a nice message 310.47s - 317.15s | maybe you want to add some button there or some sound you can definitely do that and even change the 317.47s -


chunk_id: 152_chunk_5
chunk_text:
are sending a recall message on the message that you sent to your boss 260.99s - 266.75s | What happens behind what happens when the recall being sent so essentially it's something there 267.11s - 271.63s | Activates and starts to delete the email from the inboxes of your manager 272.15s - 277.39s | It's a rendering mechanism that is based on again the synchronization of forms 277.83s - 284.03s | And we'll be covering that and we'll share basically how we utilize that to inject malicious forms 284.99s - 290.47s | We'll get back to recall on the coming slides, but let's first talk a bit a bit about 291.03s - 292.95s | forms and custom forms 292.95s - 298.11s | so forms overall can be of two different types now if you 298.83s - 304.51s | Integrate the developer mode in outlook you can see that you can modify existing forms 305.35s - 307.35s | into your own kind of 307.59s - 310.47s | Purpose so if you get a nice message 310.47s - 317.15s | maybe you want to add some button there or some sound you can definitely do that and even change the 317.47s - 319.47s | structure of the forms by 319.47s - 320.59s | basically 320.59s - 325.59s | Opening the built-in Microsoft form and starting moving stuff now 325.59s - 329.51s | We will not be talking about that because we are looking into inject a full form 329.51s - 332.23s | But this is one of the ways to create the form 332.83s - 336.47s | We'll talk about the creation of the form in the next slide 336.91s - 339.99s | What is outside of the scope of this presentation is 340.67s - 346.47s | Talking about visual basic execution within the form. It was well well covered by Etienne Stevens 346.63s - 351.79s | You've done a lot of research in 2017 a lot of presentations. You are welcome to 352.35s - 354.15s | Check them out 354.15s - 356.07s | Microsoft introduced a lot of 356.07s - 363.19s | Hardening to avoid the default execution of visual basic inside forms, so this is outside of the scope 365.16s - 373.04s | Okay, so I already mentioned that we have one way to create a custom form this one way is by modifying existing built-in forms 373.28s - 380.44s


chunk_id: 152_chunk_6
chunk_text:
319.47s | structure of the forms by 319.47s - 320.59s | basically 320.59s - 325.59s | Opening the built-in Microsoft form and starting moving stuff now 325.59s - 329.51s | We will not be talking about that because we are looking into inject a full form 329.51s - 332.23s | But this is one of the ways to create the form 332.83s - 336.47s | We'll talk about the creation of the form in the next slide 336.91s - 339.99s | What is outside of the scope of this presentation is 340.67s - 346.47s | Talking about visual basic execution within the form. It was well well covered by Etienne Stevens 346.63s - 351.79s | You've done a lot of research in 2017 a lot of presentations. You are welcome to 352.35s - 354.15s | Check them out 354.15s - 356.07s | Microsoft introduced a lot of 356.07s - 363.19s | Hardening to avoid the default execution of visual basic inside forms, so this is outside of the scope 365.16s - 373.04s | Okay, so I already mentioned that we have one way to create a custom form this one way is by modifying existing built-in forms 373.28s - 380.44s | But what is interesting for us in this category of form injection is the way you can programmatically create new forms? 380.64s - 386.00s | And if you look at the documentation of Microsoft, this is actually a snapshot from Microsoft documentation 386.36s - 392.32s | There is a way to create your own form by basically generating a configuration file called CFG 392.84s - 400.84s | Within this configuration file you basically define the different properties of the same form that you see like a message or appointment or calendar 400.84s - 402.24s | It's all forms 402.24s - 409.36s | And you can also specify a form server in this case you see the example is helpdesk.exe 409.60s - 416.60s | That is responsible to render the form so upon receiving that message in your outlook you want to do something about that 416.72s - 419.72s | this is the executable that eventually spawned and 420.36s - 427.24s | Does something about that and we will share a couple of examples now. It doesn't have to be executable you can use a different 428.04s - 431.60s | DLL or any other ways we'll share that as well


chunk_id: 152_chunk_7
chunk_text:
| But what is interesting for us in this category of form injection is the way you can programmatically create new forms? 380.64s - 386.00s | And if you look at the documentation of Microsoft, this is actually a snapshot from Microsoft documentation 386.36s - 392.32s | There is a way to create your own form by basically generating a configuration file called CFG 392.84s - 400.84s | Within this configuration file you basically define the different properties of the same form that you see like a message or appointment or calendar 400.84s - 402.24s | It's all forms 402.24s - 409.36s | And you can also specify a form server in this case you see the example is helpdesk.exe 409.60s - 416.60s | That is responsible to render the form so upon receiving that message in your outlook you want to do something about that 416.72s - 419.72s | this is the executable that eventually spawned and 420.36s - 427.24s | Does something about that and we will share a couple of examples now. It doesn't have to be executable you can use a different 428.04s - 431.60s | DLL or any other ways we'll share that as well 432.28s - 434.60s | but again, there is a very nice way to 435.72s - 444.52s | Run that form now. It's we'll not get into too much details about the whole mechanism of forms because we don't have enough time 445.52s - 452.60s | Nevertheless, it's important to understand one of the most interesting things in forms is the synchronization mechanism 452.80s - 459.84s | So exactly like you would open a draft email and it's suddenly existing all your clients behind them 459.84s - 465.88s | There is a mechanism that basically synchronizes all those forms across the different clients through the exchange server 466.04s - 468.64s | This is not the only thing that obviously synchronized 468.96s - 470.08s | But in this case 470.08s - 478.20s | We will leverage that mechanism to inject and execute the forms on any of the clients that there are victim basically using 478.72s - 480.72s | Now the mechanism involves 481.00s - 486.28s | Form libraries that represent properties. It will represent also include form service, etc 487.00s - 488.44s | and 488.44s - 494.48s | There's also important to understand that not all forms are synchronized if you


chunk_id: 152_chunk_8
chunk_text:
432.28s - 434.60s | but again, there is a very nice way to 435.72s - 444.52s | Run that form now. It's we'll not get into too much details about the whole mechanism of forms because we don't have enough time 445.52s - 452.60s | Nevertheless, it's important to understand one of the most interesting things in forms is the synchronization mechanism 452.80s - 459.84s | So exactly like you would open a draft email and it's suddenly existing all your clients behind them 459.84s - 465.88s | There is a mechanism that basically synchronizes all those forms across the different clients through the exchange server 466.04s - 468.64s | This is not the only thing that obviously synchronized 468.96s - 470.08s | But in this case 470.08s - 478.20s | We will leverage that mechanism to inject and execute the forms on any of the clients that there are victim basically using 478.72s - 480.72s | Now the mechanism involves 481.00s - 486.28s | Form libraries that represent properties. It will represent also include form service, etc 487.00s - 488.44s | and 488.44s - 494.48s | There's also important to understand that not all forms are synchronized if you put your form 494.76s - 500.44s | Into a personal library, it will not be synchronized across the different clients. But if you for example 501.56s - 504.96s | Install it in the inbox. It will definitely be synced by the 505.60s - 509.20s | Microsoft protocol 509.20s - 513.24s | So shortly how forms are loading and and registered 513.32s - 519.44s | So if you take in this example a simple built-in modified form, this is not a programmatically created form 519.92s - 521.92s | Nevertheless, this is the same mechanism 522.48s - 527.04s | So if you look at the your registry hive under the class ID you will find 527.36s - 532.24s | Again based on whether you have outlook 32-bit or 64-bit you have the wow there 532.64s - 539.36s | But you will find a lot of those class IDs and each class ID many of those class IDs basically represent the different forms 539.88s - 540.96s | now 540.96s - 543.96s | As soon as you find the class ID you will find also 544.20s - 549.28s | What is the name of the form and you will find what is the location


chunk_id: 152_chunk_9
chunk_text:
put your form 494.76s - 500.44s | Into a personal library, it will not be synchronized across the different clients. But if you for example 501.56s - 504.96s | Install it in the inbox. It will definitely be synced by the 505.60s - 509.20s | Microsoft protocol 509.20s - 513.24s | So shortly how forms are loading and and registered 513.32s - 519.44s | So if you take in this example a simple built-in modified form, this is not a programmatically created form 519.92s - 521.92s | Nevertheless, this is the same mechanism 522.48s - 527.04s | So if you look at the your registry hive under the class ID you will find 527.36s - 532.24s | Again based on whether you have outlook 32-bit or 64-bit you have the wow there 532.64s - 539.36s | But you will find a lot of those class IDs and each class ID many of those class IDs basically represent the different forms 539.88s - 540.96s | now 540.96s - 543.96s | As soon as you find the class ID you will find also 544.20s - 549.28s | What is the name of the form and you will find what is the location of that form on your disk? 549.92s - 554.88s | Those forms when they are synchronized they are saved in a special folder many times 555.32s - 557.40s | in the app data local that 558.16s - 564.92s | Under the forms folder and the built-in forms are saved within the program files office also special 565.44s - 567.20s | folder there 567.20s - 570.40s | essentially those form libraries are a com objects and 571.64s - 574.04s | those are can be rendered and 575.52s - 577.52s | instantiated like any other comb 578.00s - 580.00s | As we said the 580.16s - 582.08s | original kind of oily 582.08s - 587.24s | form library is a bit outside of the scope of this lecture nevertheless, I 588.84s - 589.96s | strongly 589.96s - 594.72s | recommend people here to try and play with it because you can modify the streams and 594.96s - 599.92s | Also lead to malicious behavior by basically modifying the properties of the oily itself 600.84s - 604.08s | But we will be talking about programmatically created forms 605.08s - 606.56s | Through the 606.56s - 607.76s | configuration files 607.76s - 610.72s |


chunk_id: 152_chunk_10
chunk_text:
of that form on your disk? 549.92s - 554.88s | Those forms when they are synchronized they are saved in a special folder many times 555.32s - 557.40s | in the app data local that 558.16s - 564.92s | Under the forms folder and the built-in forms are saved within the program files office also special 565.44s - 567.20s | folder there 567.20s - 570.40s | essentially those form libraries are a com objects and 571.64s - 574.04s | those are can be rendered and 575.52s - 577.52s | instantiated like any other comb 578.00s - 580.00s | As we said the 580.16s - 582.08s | original kind of oily 582.08s - 587.24s | form library is a bit outside of the scope of this lecture nevertheless, I 588.84s - 589.96s | strongly 589.96s - 594.72s | recommend people here to try and play with it because you can modify the streams and 594.96s - 599.92s | Also lead to malicious behavior by basically modifying the properties of the oily itself 600.84s - 604.08s | But we will be talking about programmatically created forms 605.08s - 606.56s | Through the 606.56s - 607.76s | configuration files 607.76s - 610.72s | This is a great example of a built-in 611.08s - 619.16s | Recall message form that is basically exist on any of the computers that are installed with outlook whether it's 32-bit or 64-bit 619.48s - 624.40s | We can go to this specified directory and find those CFG files 624.80s - 629.44s | Now you identify that there is a special file called a rack CFG 629.68s - 637.80s | This is an example of the recall message form you see also that the CFG itself also include the rendering file the recall 638.48s - 643.20s | DLL basically instantiated automatically through the in proc server 32 644.16s - 649.76s | Now if you are not using your recall your cloud recall which is kind of the latest thing in through Azure 650.16s - 654.00s | This is kind of the default built-in if you are sending a special message 655.00s - 661.24s | You basically identify the class message and the recall DLL is loaded within the context of the outlook and 661.52s - 663.76s | basically starts to delete from your inbox the 665.56s - 667.56s | Message that you want to remove 667.72s - 673.72s |


chunk_id: 152_chunk_11
chunk_text:
This is a great example of a built-in 611.08s - 619.16s | Recall message form that is basically exist on any of the computers that are installed with outlook whether it's 32-bit or 64-bit 619.48s - 624.40s | We can go to this specified directory and find those CFG files 624.80s - 629.44s | Now you identify that there is a special file called a rack CFG 629.68s - 637.80s | This is an example of the recall message form you see also that the CFG itself also include the rendering file the recall 638.48s - 643.20s | DLL basically instantiated automatically through the in proc server 32 644.16s - 649.76s | Now if you are not using your recall your cloud recall which is kind of the latest thing in through Azure 650.16s - 654.00s | This is kind of the default built-in if you are sending a special message 655.00s - 661.24s | You basically identify the class message and the recall DLL is loaded within the context of the outlook and 661.52s - 663.76s | basically starts to delete from your inbox the 665.56s - 667.56s | Message that you want to remove 667.72s - 673.72s | So we want to achieve the same thing we want to exploit the same behavior and define our own CFG 673.72s - 680.40s | Right with our own DLL that will be put automatically into the victim environment, but can we do that? 681.16s - 682.64s | So 682.64s - 689.16s | And here is an example again from this recall call, which is which is a column object, but can we do that? 689.80s - 692.44s | Well, not exactly. There is a special 693.32s - 695.20s | mechanism basically 695.20s - 698.52s | Allow form let's say what's called the bypass 699.20s - 706.32s | Outlook and by default it's disabled now if it would be enabled you can definitely define such a CFG 706.48s - 713.88s | You can load it and then you have a form automatically synchronized to your victim environment and you can send a special message that will 714.48s - 717.04s | Trigger the initiation initiation of the form 717.60s - 724.36s | But if this flag is basically disabled, which is by default your form goes through a special 724.88s - 730.32s | Matching algorithm which validates that you are not using


chunk_id: 152_chunk_12
chunk_text:
So we want to achieve the same thing we want to exploit the same behavior and define our own CFG 673.72s - 680.40s | Right with our own DLL that will be put automatically into the victim environment, but can we do that? 681.16s - 682.64s | So 682.64s - 689.16s | And here is an example again from this recall call, which is which is a column object, but can we do that? 689.80s - 692.44s | Well, not exactly. There is a special 693.32s - 695.20s | mechanism basically 695.20s - 698.52s | Allow form let's say what's called the bypass 699.20s - 706.32s | Outlook and by default it's disabled now if it would be enabled you can definitely define such a CFG 706.48s - 713.88s | You can load it and then you have a form automatically synchronized to your victim environment and you can send a special message that will 714.48s - 717.04s | Trigger the initiation initiation of the form 717.60s - 724.36s | But if this flag is basically disabled, which is by default your form goes through a special 724.88s - 730.32s | Matching algorithm which validates that you are not using special keywords like in proc server 730.80s - 736.92s | Local handler, which basically automatically instantiate those comb objects or those malicious 737.44s - 740.56s | DLLs that or executables that are put in this folder 741.20s - 746.60s | Now one of the problems with this matching algorithm is well, it's noise noisy 747.60s - 754.24s | So one of the problems with this matching algorithm is that it it is an exact matching it checks for an exact words 754.44s - 760.36s | Not less not more but an exact words within the keys that are specified in the configuration file 761.88s - 763.88s | So somehow 764.20s - 770.52s | We lead basically to the first vulnerability that was discovered by net spy which done amazing work 771.36s - 776.48s | They introduced into this registry file an additional relative path 824.60s - 826.60s | Okay, so it's kind of a temporary solution 827.48s - 831.72s | So, I hope we will finish the presentation till then but again 831.92s - 837.84s | it's a great finding basically the net spy group added a relative class ID and 838.28s - 840.92s | It's also documented in Microsoft


chunk_id: 152_chunk_13
chunk_text:
special keywords like in proc server 730.80s - 736.92s | Local handler, which basically automatically instantiate those comb objects or those malicious 737.44s - 740.56s | DLLs that or executables that are put in this folder 741.20s - 746.60s | Now one of the problems with this matching algorithm is well, it's noise noisy 747.60s - 754.24s | So one of the problems with this matching algorithm is that it it is an exact matching it checks for an exact words 754.44s - 760.36s | Not less not more but an exact words within the keys that are specified in the configuration file 761.88s - 763.88s | So somehow 764.20s - 770.52s | We lead basically to the first vulnerability that was discovered by net spy which done amazing work 771.36s - 776.48s | They introduced into this registry file an additional relative path 824.60s - 826.60s | Okay, so it's kind of a temporary solution 827.48s - 831.72s | So, I hope we will finish the presentation till then but again 831.92s - 837.84s | it's a great finding basically the net spy group added a relative class ID and 838.28s - 840.92s | It's also documented in Microsoft documentation 841.44s - 844.76s | That they are clearly say that you can provide a relative path 845.60s - 849.92s | for your form server rendering and they added that and 850.76s - 854.68s | Surprisingly because the algorithm of the the checks for the forbidden words 854.96s - 861.44s | Does an exact matching the algorithm fails and you have automatically instantiated form malicious form? 862.20s - 865.08s | With a fully controlled class ID of your own 866.12s - 867.96s | beside that 867.96s - 869.96s | Vulnerability, they also discovered 870.36s - 872.36s | kind of a directory traversal 872.92s - 877.80s | Vulnerability in which basically allows to install that form anywhere on the file disk 878.64s - 885.20s | Because you can play with this one of the properties, but this property is less interesting for us. It was a nicely patched by 885.72s - 890.84s | Microsoft, but I will be talking specifically about the bypass algorithm 891.48s - 898.44s | So now is the interesting part how Microsoft patched that vulnerability and what led us basically to discover new vulnerabilities 898.76s - 904.72s | Following that patch. So as we see in the


chunk_id: 152_chunk_14
chunk_text:
documentation 841.44s - 844.76s | That they are clearly say that you can provide a relative path 845.60s - 849.92s | for your form server rendering and they added that and 850.76s - 854.68s | Surprisingly because the algorithm of the the checks for the forbidden words 854.96s - 861.44s | Does an exact matching the algorithm fails and you have automatically instantiated form malicious form? 862.20s - 865.08s | With a fully controlled class ID of your own 866.12s - 867.96s | beside that 867.96s - 869.96s | Vulnerability, they also discovered 870.36s - 872.36s | kind of a directory traversal 872.92s - 877.80s | Vulnerability in which basically allows to install that form anywhere on the file disk 878.64s - 885.20s | Because you can play with this one of the properties, but this property is less interesting for us. It was a nicely patched by 885.72s - 890.84s | Microsoft, but I will be talking specifically about the bypass algorithm 891.48s - 898.44s | So now is the interesting part how Microsoft patched that vulnerability and what led us basically to discover new vulnerabilities 898.76s - 904.72s | Following that patch. So as we see in the patch that was introduced by Microsoft 905.56s - 912.32s | Microsoft said, okay, you have a problem with the relative path. Let's remove relative path. They didn't update the documentation yet 913.00s - 919.56s | But they basically removed that functionality. You cannot put a backslash anymore in the property of the form 919.88s - 926.56s | So great. Okay, it solved the problem, but they didn't change the matching algorithm. The algorithm is still the same 927.12s - 929.12s | So as you would expect 929.16s - 934.84s | We were looking for additional control flows that allow us to still instantiate the same forms 935.04s - 938.44s | By abusing the failure in the matching algorithm 940.26s - 948.10s | So I have to commend to Microsoft because they have done it quite quickly. We reported on them in April. They patched in June 948.82s - 950.82s | So nice work 952.27s - 958.39s | but again before we are diving in to how we created additional control flow we need to 958.95s - 966.91s | Understand how a Windows core API function works now when you basically register a form 968.51s - 971.99s | It goes through


chunk_id: 152_chunk_15
chunk_text:
patch that was introduced by Microsoft 905.56s - 912.32s | Microsoft said, okay, you have a problem with the relative path. Let's remove relative path. They didn't update the documentation yet 913.00s - 919.56s | But they basically removed that functionality. You cannot put a backslash anymore in the property of the form 919.88s - 926.56s | So great. Okay, it solved the problem, but they didn't change the matching algorithm. The algorithm is still the same 927.12s - 929.12s | So as you would expect 929.16s - 934.84s | We were looking for additional control flows that allow us to still instantiate the same forms 935.04s - 938.44s | By abusing the failure in the matching algorithm 940.26s - 948.10s | So I have to commend to Microsoft because they have done it quite quickly. We reported on them in April. They patched in June 948.82s - 950.82s | So nice work 952.27s - 958.39s | but again before we are diving in to how we created additional control flow we need to 958.95s - 966.91s | Understand how a Windows core API function works now when you basically register a form 968.51s - 971.99s | It goes through a process in which they use recreate 972.91s - 980.39s | XA function. It's also utilized in most of the applications today. It's one of the most popular functions that exist today 980.83s - 984.03s | One of the properties of this function, which is interesting 984.03s - 991.27s | You can supply to this function a parameter that composed of multiple keys by separating them through backslashes 991.83s - 998.51s | Now I think it's limited to 32 keys. So if you are basically using that function with 999.39s - 1003.29s | 31 backslashes as they will create a nested directory structure 1004.55s - 1011.75s | Automatically and one of the additional properties is that if you provide a registry key with the backslash trailing backslash 1011.83s - 1017.95s | It will be removed to maintain consistency. It's correct to any reg X a and 1018.47s - 1020.47s | This will be probably 1020.75s - 1022.75s | interesting to investigate other applications 1023.59s - 1026.35s | That may be vulnerable to do the same reason 1027.07s - 1029.07s | so as you would probably 1029.79s - 1035.87s | Guess we just added this backslash at the end. So as


chunk_id: 152_chunk_16
chunk_text:
a process in which they use recreate 972.91s - 980.39s | XA function. It's also utilized in most of the applications today. It's one of the most popular functions that exist today 980.83s - 984.03s | One of the properties of this function, which is interesting 984.03s - 991.27s | You can supply to this function a parameter that composed of multiple keys by separating them through backslashes 991.83s - 998.51s | Now I think it's limited to 32 keys. So if you are basically using that function with 999.39s - 1003.29s | 31 backslashes as they will create a nested directory structure 1004.55s - 1011.75s | Automatically and one of the additional properties is that if you provide a registry key with the backslash trailing backslash 1011.83s - 1017.95s | It will be removed to maintain consistency. It's correct to any reg X a and 1018.47s - 1020.47s | This will be probably 1020.75s - 1022.75s | interesting to investigate other applications 1023.59s - 1026.35s | That may be vulnerable to do the same reason 1027.07s - 1029.07s | so as you would probably 1029.79s - 1035.87s | Guess we just added this backslash at the end. So as soon as you add the backslash at the end 1036.87s - 1041.63s | Obviously it goes through the matching algorithm which does the exact matching 1042.19s - 1049.15s | It goes through because again, we have the backslash and when the red create reg X create 1049.99s - 1056.67s | Creates the registry it removes the trailing backslash. And while I you have a fully executing form 1058.15s - 1065.63s | Written automatically synchronized by Microsoft to any of the victim environments. And what do we need to basically execute? 1066.11s - 1070.47s | Just to send the message a simple email with the message class of that form 1070.99s - 1074.39s | so very quickly 1074.39s - 1076.39s | Just a demonstration 1077.19s - 1091.30s | Let's see. Okay. I hope you see the video so in this video we will know 1092.98s - 1104.43s | Okay, it's a problem maybe we can push it here, okay 1106.11s - 1108.63s | Solution so we'll try to do a play like that 1110.19s - 1112.19s | Maybe this work 1112.23s - 1113.55s | Okay 1113.55s - 1114.67s | remotely 1114.67s - 1115.87s | Nice 1115.87s - 1123.03s | Okay. So


chunk_id: 152_chunk_17
chunk_text:
soon as you add the backslash at the end 1036.87s - 1041.63s | Obviously it goes through the matching algorithm which does the exact matching 1042.19s - 1049.15s | It goes through because again, we have the backslash and when the red create reg X create 1049.99s - 1056.67s | Creates the registry it removes the trailing backslash. And while I you have a fully executing form 1058.15s - 1065.63s | Written automatically synchronized by Microsoft to any of the victim environments. And what do we need to basically execute? 1066.11s - 1070.47s | Just to send the message a simple email with the message class of that form 1070.99s - 1074.39s | so very quickly 1074.39s - 1076.39s | Just a demonstration 1077.19s - 1091.30s | Let's see. Okay. I hope you see the video so in this video we will know 1092.98s - 1104.43s | Okay, it's a problem maybe we can push it here, okay 1106.11s - 1108.63s | Solution so we'll try to do a play like that 1110.19s - 1112.19s | Maybe this work 1112.23s - 1113.55s | Okay 1113.55s - 1114.67s | remotely 1114.67s - 1115.87s | Nice 1115.87s - 1123.03s | Okay. So essentially we are working here on updated outlook. This was recorded in June just before the 1124.07s - 1126.07s | Patch was introduced by Microsoft 1126.79s - 1134.47s | We are using a tool by Etienne Stevens called the ruler which basically allows us to utilize the MAPI 1135.47s - 1137.47s | MAPI API to 1137.59s - 1140.95s | Synchronize and then create a new form. We didn't have to use that 1140.95s - 1145.35s | we just could open a client in our environment use the credentials and 1146.11s - 1151.43s | Create the same form here. We are utilizing and creating the property with the backslash 1152.27s - 1153.75s | and 1153.75s - 1158.15s | With the next step. We will be sending right now and authenticated 1159.15s - 1161.73s | Token that allows us basically to 1162.51s - 1167.35s | Upload the form and to synchronize it across the different victims 1168.71s - 1171.63s | So in the next step as soon as it would be sent 1171.63s - 1177.71s | We will see that the form suddenly appeared on the victim environment. It takes a bit 1178.67s - 1180.67s | a couple of seconds 1181.27s -


chunk_id: 152_chunk_18
chunk_text:
essentially we are working here on updated outlook. This was recorded in June just before the 1124.07s - 1126.07s | Patch was introduced by Microsoft 1126.79s - 1134.47s | We are using a tool by Etienne Stevens called the ruler which basically allows us to utilize the MAPI 1135.47s - 1137.47s | MAPI API to 1137.59s - 1140.95s | Synchronize and then create a new form. We didn't have to use that 1140.95s - 1145.35s | we just could open a client in our environment use the credentials and 1146.11s - 1151.43s | Create the same form here. We are utilizing and creating the property with the backslash 1152.27s - 1153.75s | and 1153.75s - 1158.15s | With the next step. We will be sending right now and authenticated 1159.15s - 1161.73s | Token that allows us basically to 1162.51s - 1167.35s | Upload the form and to synchronize it across the different victims 1168.71s - 1171.63s | So in the next step as soon as it would be sent 1171.63s - 1177.71s | We will see that the form suddenly appeared on the victim environment. It takes a bit 1178.67s - 1180.67s | a couple of seconds 1181.27s - 1183.74s | Okay 1183.74s - 1187.28s | Good 1187.28s - 1191.24s | Okay. So here we receive the message. We're still not opening that message 1191.60s - 1198.12s | The opening of the message will instantiate the execution of the form, but the form was already written 1199.24s - 1204.60s | Synchronized into the folder. So this is a way in which you can also use the advanced button 1204.60s - 1209.76s | You can check out the forms or you can simply go to the folder of the forms and identify it 1209.76s - 1214.12s | So was written as soon as I open that the form 1214.76s - 1220.08s | Form server is executed as you see it's executed within the context of the outlook process 1220.80s - 1227.84s | Now the same if you would use not in proc server 32, but let's say local handler it would execute an external application 1228.68s - 1230.68s | executable the same way 1231.40s - 1233.72s | Now we need to pull it back somehow 1236.52s - 1240.03s | No, maybe I just close it 1240.79s - 1242.79s | Okay 1243.15s - 1245.89s | Okay 1245.89s - 1251.01s | Okay,


chunk_id: 152_chunk_19
chunk_text:
1183.74s | Okay 1183.74s - 1187.28s | Good 1187.28s - 1191.24s | Okay. So here we receive the message. We're still not opening that message 1191.60s - 1198.12s | The opening of the message will instantiate the execution of the form, but the form was already written 1199.24s - 1204.60s | Synchronized into the folder. So this is a way in which you can also use the advanced button 1204.60s - 1209.76s | You can check out the forms or you can simply go to the folder of the forms and identify it 1209.76s - 1214.12s | So was written as soon as I open that the form 1214.76s - 1220.08s | Form server is executed as you see it's executed within the context of the outlook process 1220.80s - 1227.84s | Now the same if you would use not in proc server 32, but let's say local handler it would execute an external application 1228.68s - 1230.68s | executable the same way 1231.40s - 1233.72s | Now we need to pull it back somehow 1236.52s - 1240.03s | No, maybe I just close it 1240.79s - 1242.79s | Okay 1243.15s - 1245.89s | Okay 1245.89s - 1251.01s | Okay, good. So this was a very nice demonstration for a form 1251.05s - 1253.05s | But again, it's assumed that we have 1253.85s - 1261.81s | Authentication beforehand. We will show later on how easy it can we can get the authentication the tokens from the environment and have a full RC 1262.69s - 1267.71s | Non-authenticated again in this case. We do require the credentials of the victim 1269.49s - 1271.49s | Let's continue 1272.09s - 1277.49s | Okay, so what do we have here we have a patch to this vulnerability now 1277.49s - 1284.77s | It's interesting because we just bypassed one patch and this patch was introduced to solve the vulnerability that we discovered 1285.01s - 1289.69s | Now if you look at the patch again for those that are reversing here 1290.81s - 1298.37s | They it's probably more clear. But essentially they didn't change the function that checks for the exact strings. They 1298.89s - 1301.81s | Just decided to remove the trailing backslashes 1302.09s - 1310.13s | So basically they introduced additional loop that goes over the key and removes all the trailing backslashes and then continue with the same 1310.37s - 1314.69s


chunk_id: 152_chunk_20
chunk_text:
good. So this was a very nice demonstration for a form 1251.05s - 1253.05s | But again, it's assumed that we have 1253.85s - 1261.81s | Authentication beforehand. We will show later on how easy it can we can get the authentication the tokens from the environment and have a full RC 1262.69s - 1267.71s | Non-authenticated again in this case. We do require the credentials of the victim 1269.49s - 1271.49s | Let's continue 1272.09s - 1277.49s | Okay, so what do we have here we have a patch to this vulnerability now 1277.49s - 1284.77s | It's interesting because we just bypassed one patch and this patch was introduced to solve the vulnerability that we discovered 1285.01s - 1289.69s | Now if you look at the patch again for those that are reversing here 1290.81s - 1298.37s | They it's probably more clear. But essentially they didn't change the function that checks for the exact strings. They 1298.89s - 1301.81s | Just decided to remove the trailing backslashes 1302.09s - 1310.13s | So basically they introduced additional loop that goes over the key and removes all the trailing backslashes and then continue with the same 1310.37s - 1314.69s | exact matching algorithm instead of looking for a contain etc 1314.77s - 1321.01s | So I definitely welcome you guys to check out what additional control flows you can find out 1321.65s - 1325.06s | And maybe you will 1325.06s - 1328.02s | But it's not all when they introduced that patch 1328.66s - 1333.14s | They also introduced additional extension for the blocking list 1333.58s - 1337.14s | Now, it's also interesting those that you identify 1338.54s - 1343.18s | those special key attributes those key allows hijacking and 1344.62s - 1347.10s | execution of additional comments or 1348.50s - 1354.46s | Com hijacking etc. So definitely an interesting additional path to investigate 1354.66s - 1360.70s | This just shows that there were additional vulnerability in place that could be utilized by an adversary 1362.81s - 1364.81s | okay, so just 1364.85s - 1366.85s | to put things 1366.89s - 1370.61s | In the right order there are more vulnerabilities that were discovered 1371.69s - 1374.13s | next week there will be patch and 1375.29s - 1377.29s | for additional vulnerabilities and 1378.09s - 1385.01s | Well, I suppose we will share the details somewhere month or two


chunk_id: 152_chunk_21
chunk_text:
| exact matching algorithm instead of looking for a contain etc 1314.77s - 1321.01s | So I definitely welcome you guys to check out what additional control flows you can find out 1321.65s - 1325.06s | And maybe you will 1325.06s - 1328.02s | But it's not all when they introduced that patch 1328.66s - 1333.14s | They also introduced additional extension for the blocking list 1333.58s - 1337.14s | Now, it's also interesting those that you identify 1338.54s - 1343.18s | those special key attributes those key allows hijacking and 1344.62s - 1347.10s | execution of additional comments or 1348.50s - 1354.46s | Com hijacking etc. So definitely an interesting additional path to investigate 1354.66s - 1360.70s | This just shows that there were additional vulnerability in place that could be utilized by an adversary 1362.81s - 1364.81s | okay, so just 1364.85s - 1366.85s | to put things 1366.89s - 1370.61s | In the right order there are more vulnerabilities that were discovered 1371.69s - 1374.13s | next week there will be patch and 1375.29s - 1377.29s | for additional vulnerabilities and 1378.09s - 1385.01s | Well, I suppose we will share the details somewhere month or two months after but we do recommend you to patch your outlook lines 1385.01s - 1388.17s | Because it's not very difficult. The exploit is very trivial 1390.16s - 1395.22s | Now again form injection. It's nice for remote code execution 1395.34s - 1398.78s | But it's not the only way to utilize that type of vulnerabilities 1399.02s - 1403.86s | Now we can obviously do a persistency with that. We can also escalate privileges 1405.06s - 1408.74s | If you for example hijack the credentials of an exchange admin 1408.82s - 1415.70s | We can propagate the same forms across the all the inboxes and do much more damage than just a simple 1416.78s - 1417.78s | victim 1417.78s - 1425.01s | So let's talk about for a second about the other part which is missing the authentication 1425.29s - 1428.09s | Now I'm talking about until the 1429.29s - 1432.61s | Authentication sorry only in two slides, but there is a nice presentation 1433.49s - 1437.45s | Tomorrow by someone else that is only talking about NTLM 1438.53s - 1445.53s | And I trust that it will be great presentation, but NTLM is essentially as a or anti-hash if


chunk_id: 152_chunk_22
chunk_text:
months after but we do recommend you to patch your outlook lines 1385.01s - 1388.17s | Because it's not very difficult. The exploit is very trivial 1390.16s - 1395.22s | Now again form injection. It's nice for remote code execution 1395.34s - 1398.78s | But it's not the only way to utilize that type of vulnerabilities 1399.02s - 1403.86s | Now we can obviously do a persistency with that. We can also escalate privileges 1405.06s - 1408.74s | If you for example hijack the credentials of an exchange admin 1408.82s - 1415.70s | We can propagate the same forms across the all the inboxes and do much more damage than just a simple 1416.78s - 1417.78s | victim 1417.78s - 1425.01s | So let's talk about for a second about the other part which is missing the authentication 1425.29s - 1428.09s | Now I'm talking about until the 1429.29s - 1432.61s | Authentication sorry only in two slides, but there is a nice presentation 1433.49s - 1437.45s | Tomorrow by someone else that is only talking about NTLM 1438.53s - 1445.53s | And I trust that it will be great presentation, but NTLM is essentially as a or anti-hash if you would say 1446.21s - 1448.21s | if you would for example 1448.65s - 1450.57s | send an email and 1450.57s - 1455.61s | Send a link to a file and the victim will double-click on those link 1456.45s - 1461.69s | behind that there will be SMB protocol that will requires basically and 1462.21s - 1469.57s | response challenge response algorithm that will require authentication and if you are by default not doing a Kerberos authentication a 1469.81s - 1472.01s | Rock server will take your anti-hash 1472.77s - 1477.09s | Automatically and the file doesn't have to exist there just you pressing the link 1477.61s - 1479.61s | but aside of that 1479.89s - 1486.29s | There were a lot of vulnerabilities that were discovered in 2023 in 2024 it was I think one of the 1487.37s - 1490.37s | significant years for NTLM leaks all across 1491.01s - 1498.29s | With zero clicks, so you didn't need to press or get in the warning that there is a SMB file. You just needed to 1498.97s - 1500.61s | Have an appointment 1500.61s - 1508.57s | reminder that is sent with a nice kind of link to a


chunk_id: 152_chunk_23
chunk_text:
you would say 1446.21s - 1448.21s | if you would for example 1448.65s - 1450.57s | send an email and 1450.57s - 1455.61s | Send a link to a file and the victim will double-click on those link 1456.45s - 1461.69s | behind that there will be SMB protocol that will requires basically and 1462.21s - 1469.57s | response challenge response algorithm that will require authentication and if you are by default not doing a Kerberos authentication a 1469.81s - 1472.01s | Rock server will take your anti-hash 1472.77s - 1477.09s | Automatically and the file doesn't have to exist there just you pressing the link 1477.61s - 1479.61s | but aside of that 1479.89s - 1486.29s | There were a lot of vulnerabilities that were discovered in 2023 in 2024 it was I think one of the 1487.37s - 1490.37s | significant years for NTLM leaks all across 1491.01s - 1498.29s | With zero clicks, so you didn't need to press or get in the warning that there is a SMB file. You just needed to 1498.97s - 1500.61s | Have an appointment 1500.61s - 1508.57s | reminder that is sent with a nice kind of link to a sound that it will be sound when the appointment is being sent or 1509.61s - 1515.25s | Some kind of Windows performance analyzer that is being directed and all kind of additional 1515.97s - 1518.85s | Exploits that lead to the same NTLM leak, so it's not very 1519.57s - 1523.97s | Difficult to get NTLM leaks will get into recommendation how it can be blocked 1524.57s - 1529.73s | Going forward, but one of them is interesting the last one especially 1530.93s - 1535.97s | NTLM leaks that are led through execution of monikers or compiled monikers 1535.97s - 1539.21s | And this is a great time to move to Arnold 1539.61s - 1545.45s | Which will be talking about compound a compound monikers that lead to remote coding code executions and NTLM 1547.76s - 1549.76s | Okay, then. Thank you Michael 1552.50s - 1555.38s | So before we diving into the next 1555.90s - 1558.74s | Marcy vulnerability we discovered in outlook 1558.90s - 1566.70s | We first need to get at least some high-level understanding of what monikers are and I highly encourage you to dig deeper into the subject 1567.02s - 1567.94s | as 1567.94s -


chunk_id: 152_chunk_24
chunk_text:
sound that it will be sound when the appointment is being sent or 1509.61s - 1515.25s | Some kind of Windows performance analyzer that is being directed and all kind of additional 1515.97s - 1518.85s | Exploits that lead to the same NTLM leak, so it's not very 1519.57s - 1523.97s | Difficult to get NTLM leaks will get into recommendation how it can be blocked 1524.57s - 1529.73s | Going forward, but one of them is interesting the last one especially 1530.93s - 1535.97s | NTLM leaks that are led through execution of monikers or compiled monikers 1535.97s - 1539.21s | And this is a great time to move to Arnold 1539.61s - 1545.45s | Which will be talking about compound a compound monikers that lead to remote coding code executions and NTLM 1547.76s - 1549.76s | Okay, then. Thank you Michael 1552.50s - 1555.38s | So before we diving into the next 1555.90s - 1558.74s | Marcy vulnerability we discovered in outlook 1558.90s - 1566.70s | We first need to get at least some high-level understanding of what monikers are and I highly encourage you to dig deeper into the subject 1567.02s - 1567.94s | as 1567.94s - 1575.06s | Multiple vulnerabilities in outlook involve moniker on in office applications involve monikers in some way or another 1575.82s - 1576.98s | now 1576.98s - 1578.82s | Actually, we are all using 1578.82s - 1585.46s | monikers will with our daily work with office applications one example is when you try to send an email and 1585.98s - 1588.06s | in the body of that email you 1588.78s - 1591.54s | Attach an Excel chart as a link 1592.14s - 1597.90s | Well a moniker is used to point to that specific Excel chart using a string understood by the 1598.86s - 1602.14s | moniker mechanism and the monikers involved now 1602.90s - 1606.30s | the general idea of a moniker is to provide you with some way to 1607.02s - 1611.98s | locate and identify this specific com object using strings or 1613.66s - 1620.58s | Instead of writing a custom mechanism to do that and in order to achieve it all monikers must implement 1621.06s - 1623.06s | the I moniker interface 1623.22s - 1625.22s | well 1625.42s - 1630.02s | Microsoft actually provides several implementations of monikers 1630.34s - 1635.70s | Some of them related to


chunk_id: 152_chunk_25
chunk_text:
1575.06s | Multiple vulnerabilities in outlook involve moniker on in office applications involve monikers in some way or another 1575.82s - 1576.98s | now 1576.98s - 1578.82s | Actually, we are all using 1578.82s - 1585.46s | monikers will with our daily work with office applications one example is when you try to send an email and 1585.98s - 1588.06s | in the body of that email you 1588.78s - 1591.54s | Attach an Excel chart as a link 1592.14s - 1597.90s | Well a moniker is used to point to that specific Excel chart using a string understood by the 1598.86s - 1602.14s | moniker mechanism and the monikers involved now 1602.90s - 1606.30s | the general idea of a moniker is to provide you with some way to 1607.02s - 1611.98s | locate and identify this specific com object using strings or 1613.66s - 1620.58s | Instead of writing a custom mechanism to do that and in order to achieve it all monikers must implement 1621.06s - 1623.06s | the I moniker interface 1623.22s - 1625.22s | well 1625.42s - 1630.02s | Microsoft actually provides several implementations of monikers 1630.34s - 1635.70s | Some of them related to the OLE objects and most notably used in office applications 1636.46s - 1638.46s | some of these monikers include the 1639.42s - 1641.42s | file moniker item moniker 1641.94s - 1643.94s | URL moniker and few more 1645.63s - 1653.27s | One additional example is using the get object method within the visual basic programming language or its 1653.39s - 1660.75s | Windows API equivalent the call get object. This is basically a helper function that simplifies the way of 1661.31s - 1662.51s | converting 1662.51s - 1669.15s | The moniker string the display name into a moniker and then binding to that named object now 1669.15s - 1674.31s | It does that by encapsulating calls to the com library functions the create bind 1674.83s - 1677.59s | MK parts display name and bind to object 1679.39s - 1680.91s | Okay, so 1680.91s - 1682.91s | moving back to Outlook 1682.91s - 1690.31s | Imagine receiving an email with an hyperlink points to a file located on an SMB share if you would click on that file 1690.59s - 1692.59s | or on that link 1692.91s - 1694.91s | You won't get a pop-up notification 1694.91s - 1701.83s | Asks


chunk_id: 152_chunk_26
chunk_text:
the OLE objects and most notably used in office applications 1636.46s - 1638.46s | some of these monikers include the 1639.42s - 1641.42s | file moniker item moniker 1641.94s - 1643.94s | URL moniker and few more 1645.63s - 1653.27s | One additional example is using the get object method within the visual basic programming language or its 1653.39s - 1660.75s | Windows API equivalent the call get object. This is basically a helper function that simplifies the way of 1661.31s - 1662.51s | converting 1662.51s - 1669.15s | The moniker string the display name into a moniker and then binding to that named object now 1669.15s - 1674.31s | It does that by encapsulating calls to the com library functions the create bind 1674.83s - 1677.59s | MK parts display name and bind to object 1679.39s - 1680.91s | Okay, so 1680.91s - 1682.91s | moving back to Outlook 1682.91s - 1690.31s | Imagine receiving an email with an hyperlink points to a file located on an SMB share if you would click on that file 1690.59s - 1692.59s | or on that link 1692.91s - 1694.91s | You won't get a pop-up notification 1694.91s - 1701.83s | Asks you whether you are sure you want to click on that link clicking on links from untrusted source can do this and that 1702.95s - 1707.59s | Instead a warning message is displayed in the Windows notification center 1708.11s - 1715.95s | Stating that something unexpected went wrong with the URL and the file on that SMB share would never be accessed 1716.55s - 1718.51s | We would expect it to be good, right? 1718.51s - 1724.67s | so if the file would have been accessed at least the local NTLM credentials would have been leaked as 1725.07s - 1732.79s | Accessing the file would go through the SMB protocol which relies on the local NTLM credentials to authenticate 1735.02s - 1736.30s | well 1736.30s - 1740.02s | earlier this year checkpoint researcher found a vulnerability in 1740.42s - 1747.06s | Outlook that bypasses that warning message by simply adding an exclamation mark at the end of that of that link 1748.06s - 1750.54s | Apparently this turns the hyperlink from 1751.54s - 1753.02s | simple 1753.02s - 1755.46s | hyperlink that points to a file moniker 1756.18s - 1761.74s | Into a generic composite moniker that is composed from


chunk_id: 152_chunk_27
chunk_text:
you whether you are sure you want to click on that link clicking on links from untrusted source can do this and that 1702.95s - 1707.59s | Instead a warning message is displayed in the Windows notification center 1708.11s - 1715.95s | Stating that something unexpected went wrong with the URL and the file on that SMB share would never be accessed 1716.55s - 1718.51s | We would expect it to be good, right? 1718.51s - 1724.67s | so if the file would have been accessed at least the local NTLM credentials would have been leaked as 1725.07s - 1732.79s | Accessing the file would go through the SMB protocol which relies on the local NTLM credentials to authenticate 1735.02s - 1736.30s | well 1736.30s - 1740.02s | earlier this year checkpoint researcher found a vulnerability in 1740.42s - 1747.06s | Outlook that bypasses that warning message by simply adding an exclamation mark at the end of that of that link 1748.06s - 1750.54s | Apparently this turns the hyperlink from 1751.54s - 1753.02s | simple 1753.02s - 1755.46s | hyperlink that points to a file moniker 1756.18s - 1761.74s | Into a generic composite moniker that is composed from a file moniker and an item moniker 1762.30s - 1764.38s | clicking on such a link results in 1764.90s - 1771.14s | Accessing the file leaking the local NTLM credentials and potentially allow for remote code execution 1772.86s - 1775.46s | So let's dive in and understand how this is happening 1776.42s - 1780.70s | Most Microsoft Office applications load the MSO DLL 1780.70s - 1787.34s | Which is a core component used by multiple office applications and the DLL contains essential 1787.70s - 1789.70s | functionalities that is splitted between 1790.54s - 1795.70s | Multiple DLL some of them are presented the one we are interested with the 1796.34s - 1800.50s | Vulnerability discovered by checkpoint is the MSO 30 DLL 1800.82s - 1805.50s | Which handles things related to links and links parsing and to be more specific 1806.34s - 1812.94s | The MSO HR link rate from string function. That is a wrapper for H link rate from string 1813.46s - 1819.62s | That basically creates hyperlink object from strings that represents the hyperlink target 1820.26s - 1822.26s | if you would look at the 1822.66s - 1828.86s | Documentation for H link rate from string we


chunk_id: 152_chunk_28
chunk_text:
a file moniker and an item moniker 1762.30s - 1764.38s | clicking on such a link results in 1764.90s - 1771.14s | Accessing the file leaking the local NTLM credentials and potentially allow for remote code execution 1772.86s - 1775.46s | So let's dive in and understand how this is happening 1776.42s - 1780.70s | Most Microsoft Office applications load the MSO DLL 1780.70s - 1787.34s | Which is a core component used by multiple office applications and the DLL contains essential 1787.70s - 1789.70s | functionalities that is splitted between 1790.54s - 1795.70s | Multiple DLL some of them are presented the one we are interested with the 1796.34s - 1800.50s | Vulnerability discovered by checkpoint is the MSO 30 DLL 1800.82s - 1805.50s | Which handles things related to links and links parsing and to be more specific 1806.34s - 1812.94s | The MSO HR link rate from string function. That is a wrapper for H link rate from string 1813.46s - 1819.62s | That basically creates hyperlink object from strings that represents the hyperlink target 1820.26s - 1822.26s | if you would look at the 1822.66s - 1828.86s | Documentation for H link rate from string we see that it starts with the security warning that states 1829.70s - 1835.38s | Never pass strings from a non-trusted source when creating hyperlinks with H link rate from string 1835.50s - 1839.14s | The target parameter is passed to MK parse display name 1839.66s - 1843.62s | Now you might be wondering what is wrong with MK parse display name 1843.62s - 1844.94s | We'll get it in a second 1844.94s - 1847.34s | But before that take a look at the second paragraph 1847.86s - 1855.50s | You can see that it is mentioned that if a string of the form suggested in the checkpoints vulnerability a composite moniker 1856.14s - 1862.30s | Is passed it will instantiate the object registered with the specific prog ID and 1863.06s - 1865.54s | If it implements the I moniker interface 1866.50s - 1869.06s | It can in turn run unexpected code 1870.34s - 1876.54s | And it doesn't stop just there looking at the documentation for MK parse display name 1877.30s - 1882.98s | We see that it states that calling MK parse display name with a display name parameter 1883.58s - 1888.22s | From an untrusted source is unsafe


chunk_id: 152_chunk_29
chunk_text:
see that it starts with the security warning that states 1829.70s - 1835.38s | Never pass strings from a non-trusted source when creating hyperlinks with H link rate from string 1835.50s - 1839.14s | The target parameter is passed to MK parse display name 1839.66s - 1843.62s | Now you might be wondering what is wrong with MK parse display name 1843.62s - 1844.94s | We'll get it in a second 1844.94s - 1847.34s | But before that take a look at the second paragraph 1847.86s - 1855.50s | You can see that it is mentioned that if a string of the form suggested in the checkpoints vulnerability a composite moniker 1856.14s - 1862.30s | Is passed it will instantiate the object registered with the specific prog ID and 1863.06s - 1865.54s | If it implements the I moniker interface 1866.50s - 1869.06s | It can in turn run unexpected code 1870.34s - 1876.54s | And it doesn't stop just there looking at the documentation for MK parse display name 1877.30s - 1882.98s | We see that it states that calling MK parse display name with a display name parameter 1883.58s - 1888.22s | From an untrusted source is unsafe and it can lead to some moniker 1888.62s - 1892.26s | Implementations to act on the string during the parsing of it 1894.25s - 1898.61s | Well, if you take a closer look at how it happens in the code 1898.81s - 1904.93s | We see that when there is a character indicated that the string is a composite moniker 1905.81s - 1912.17s | And by the way, not only by the exclamation mark, but also the opening square bracket and colon 1912.53s - 1915.37s | The parsing of that composite moniker 1915.81s - 1920.49s | Would go through the MK parse display name for handling with of course 1921.17s - 1924.37s | Composite monikers instead of creating a file moniker 1924.89s - 1929.81s | now when MK parse display name is called it will call the 1930.45s - 1932.45s | bind to object method which 1933.33s - 1940.77s | eventually involves the relevant com object responsible for handling with the specific file type pointed to by the 1942.17s - 1947.85s | File moniker. For instance, if the file pointed to by the file moniker is an RTF 1948.41s - 1951.73s | WinWord will be spawned in the background without


chunk_id: 152_chunk_30
chunk_text:
and it can lead to some moniker 1888.62s - 1892.26s | Implementations to act on the string during the parsing of it 1894.25s - 1898.61s | Well, if you take a closer look at how it happens in the code 1898.81s - 1904.93s | We see that when there is a character indicated that the string is a composite moniker 1905.81s - 1912.17s | And by the way, not only by the exclamation mark, but also the opening square bracket and colon 1912.53s - 1915.37s | The parsing of that composite moniker 1915.81s - 1920.49s | Would go through the MK parse display name for handling with of course 1921.17s - 1924.37s | Composite monikers instead of creating a file moniker 1924.89s - 1929.81s | now when MK parse display name is called it will call the 1930.45s - 1932.45s | bind to object method which 1933.33s - 1940.77s | eventually involves the relevant com object responsible for handling with the specific file type pointed to by the 1942.17s - 1947.85s | File moniker. For instance, if the file pointed to by the file moniker is an RTF 1948.41s - 1951.73s | WinWord will be spawned in the background without displaying the UI 1952.09s - 1956.37s | it will access the file pointed to by the file moniker and 1956.77s - 1964.17s | If that and sorry and will try to access the object low and pointed to by the item moniker 1965.53s - 1967.53s | Let's move on 1967.81s - 1971.77s | Now this behavior leads to two significant issues first 1972.33s - 1977.61s | The file is being accessed. So we have an NTLM credential leak and 1978.21s - 1980.01s | Second the file is being parsed 1980.01s - 1987.81s | So any RC involved in the parsing will never be in the parsing routine can be chained to gain full RC 1988.53s - 1990.57s | Now one important note 1990.57s - 1998.17s | I want to point is that characters other than the exclamation mark can trigger this vulnerability and it's important 1999.01s - 2003.57s | From a detection and prevention standpoint as it wasn't mentioned anywhere else 2005.79s - 2009.75s | Now before we diving into the patch analysis and how we bypassed it 2010.11s - 2015.67s | We first need to understand how Microsoft patches some vulnerabilities in office applications 2016.47s - 2023.11s | Surprisingly


chunk_id: 152_chunk_31
chunk_text:
displaying the UI 1952.09s - 1956.37s | it will access the file pointed to by the file moniker and 1956.77s - 1964.17s | If that and sorry and will try to access the object low and pointed to by the item moniker 1965.53s - 1967.53s | Let's move on 1967.81s - 1971.77s | Now this behavior leads to two significant issues first 1972.33s - 1977.61s | The file is being accessed. So we have an NTLM credential leak and 1978.21s - 1980.01s | Second the file is being parsed 1980.01s - 1987.81s | So any RC involved in the parsing will never be in the parsing routine can be chained to gain full RC 1988.53s - 1990.57s | Now one important note 1990.57s - 1998.17s | I want to point is that characters other than the exclamation mark can trigger this vulnerability and it's important 1999.01s - 2003.57s | From a detection and prevention standpoint as it wasn't mentioned anywhere else 2005.79s - 2009.75s | Now before we diving into the patch analysis and how we bypassed it 2010.11s - 2015.67s | We first need to understand how Microsoft patches some vulnerabilities in office applications 2016.47s - 2023.11s | Surprisingly or not they use hooks which are installed from the in editors function within the MSO DLL 2024.07s - 2026.07s | apparently each office application 2026.23s - 2033.99s | As its own application ID and before the hook is installed the in editors function checks that 2034.51s - 2042.03s | The current process has a valid application ID and well this techniques kind of reminds us hot patching, right? 2043.03s - 2045.83s | pinpointing a specific API in a specific location 2046.99s - 2050.15s | only by a specific processes and 2050.79s - 2054.39s | As well, these API's are being used system wide 2055.03s - 2057.03s | Across many other applications 2059.24s - 2063.40s | Now moving on to the patch itself as you can see Microsoft 2063.60s - 2069.12s | Updated the in editors function to add hooks for the MK parse display name API's 2071.64s - 2078.64s | the hook simply checks if a flag named block MK parse display name on current thread is set to true and 2079.16s - 2086.64s | If that's the case as the name suggests MK parse display name would not be invoked and it will return an error instead 2089.31s


chunk_id: 152_chunk_32
chunk_text:
or not they use hooks which are installed from the in editors function within the MSO DLL 2024.07s - 2026.07s | apparently each office application 2026.23s - 2033.99s | As its own application ID and before the hook is installed the in editors function checks that 2034.51s - 2042.03s | The current process has a valid application ID and well this techniques kind of reminds us hot patching, right? 2043.03s - 2045.83s | pinpointing a specific API in a specific location 2046.99s - 2050.15s | only by a specific processes and 2050.79s - 2054.39s | As well, these API's are being used system wide 2055.03s - 2057.03s | Across many other applications 2059.24s - 2063.40s | Now moving on to the patch itself as you can see Microsoft 2063.60s - 2069.12s | Updated the in editors function to add hooks for the MK parse display name API's 2071.64s - 2078.64s | the hook simply checks if a flag named block MK parse display name on current thread is set to true and 2079.16s - 2086.64s | If that's the case as the name suggests MK parse display name would not be invoked and it will return an error instead 2089.31s - 2094.31s | now you might be wondering where that flag is being set if you recall the 2095.03s - 2097.39s | MSO HR link create from string that 2098.07s - 2100.95s | responsible for creating hyperlink objects from strings 2101.55s - 2109.43s | Sets the flag to true at the beginning of the function and it only does that if the application ID equals outlook 2111.77s - 2114.85s | looking at the patch analysis and a 2115.77s - 2121.83s | Few questions comes in mind. Well, I'm sure that some of you already asking yourselves these questions 2121.89s - 2130.01s | Well, the whole hyperlinks creation goes through the MSO HR link create from string where that flag was being set to true 2130.97s - 2137.89s | What about other code flows that may reach the unsafe API the MK parse display name? 2139.81s - 2141.81s | What about the 2142.01s - 2147.25s | Application ID we've seen comparison to outlook only what about other apps 2147.89s - 2152.50s | To answer these questions. I want to do a quick recap 2153.06s - 2154.74s | the following diagram 2154.74s - 2160.54s | Demonstrates the interesting API calls when clicking


chunk_id: 152_chunk_33
chunk_text:
- 2094.31s | now you might be wondering where that flag is being set if you recall the 2095.03s - 2097.39s | MSO HR link create from string that 2098.07s - 2100.95s | responsible for creating hyperlink objects from strings 2101.55s - 2109.43s | Sets the flag to true at the beginning of the function and it only does that if the application ID equals outlook 2111.77s - 2114.85s | looking at the patch analysis and a 2115.77s - 2121.83s | Few questions comes in mind. Well, I'm sure that some of you already asking yourselves these questions 2121.89s - 2130.01s | Well, the whole hyperlinks creation goes through the MSO HR link create from string where that flag was being set to true 2130.97s - 2137.89s | What about other code flows that may reach the unsafe API the MK parse display name? 2139.81s - 2141.81s | What about the 2142.01s - 2147.25s | Application ID we've seen comparison to outlook only what about other apps 2147.89s - 2152.50s | To answer these questions. I want to do a quick recap 2153.06s - 2154.74s | the following diagram 2154.74s - 2160.54s | Demonstrates the interesting API calls when clicking on a composite moniker hyperlink within 2161.06s - 2163.68s | an email before the patch was 2164.34s - 2166.34s | employed and 2166.82s - 2169.02s | This is how it looks after the patch 2169.78s - 2173.82s | We have the addition of the block MK parse display name flag 2174.66s - 2178.06s | that is being set to true at the beginning as we said and 2179.10s - 2183.02s | The deterred functions checks that flag and acts accordingly 2184.06s - 2192.04s | We were looking for ways to get to the unsafe API the MK parse display name 2192.64s - 2194.64s | without going through the 2195.04s - 2200.20s | AP the function that sets that flag to true and we found a candidate 2200.88s - 2203.20s | the HR payment from URL 2204.28s - 2206.28s | we found that doing some 2206.52s - 2214.12s | cross referencing through the relevant API calls and we've seen that this one may reach the unsafe API and 2215.16s - 2220.92s | As a matter of fact, this is how we got to discover the RC vulnerability and outlook 2222.85s - 2229.93s | when you pass a composite moniker within an


chunk_id: 152_chunk_34
chunk_text:
on a composite moniker hyperlink within 2161.06s - 2163.68s | an email before the patch was 2164.34s - 2166.34s | employed and 2166.82s - 2169.02s | This is how it looks after the patch 2169.78s - 2173.82s | We have the addition of the block MK parse display name flag 2174.66s - 2178.06s | that is being set to true at the beginning as we said and 2179.10s - 2183.02s | The deterred functions checks that flag and acts accordingly 2184.06s - 2192.04s | We were looking for ways to get to the unsafe API the MK parse display name 2192.64s - 2194.64s | without going through the 2195.04s - 2200.20s | AP the function that sets that flag to true and we found a candidate 2200.88s - 2203.20s | the HR payment from URL 2204.28s - 2206.28s | we found that doing some 2206.52s - 2214.12s | cross referencing through the relevant API calls and we've seen that this one may reach the unsafe API and 2215.16s - 2220.92s | As a matter of fact, this is how we got to discover the RC vulnerability and outlook 2222.85s - 2229.93s | when you pass a composite moniker within an image tag the parsing of that composite moniker won't go through the 2230.13s - 2236.57s | MSO HR link rate from string that was patched instead. It will invoke the HR payment from URL that 2238.21s - 2242.61s | Handles things and those the parsing of the URLs from image tags 2242.61s - 2247.77s | and it will directly call the H link parse display name that 2248.41s - 2255.61s | Will eventually got the same code flow that reaches to the unsafe API MK parse display name 2256.61s - 2263.09s | And now that we are familiar with how Microsoft patches some vulnerabilities in office applications 2263.73s - 2265.73s | The patch is quite obvious, right? 2266.45s - 2269.69s | setting the infamous flag to true, but this time from 2270.89s - 2277.07s | HR payment from URL and again only if the application ID equals outlook 2278.05s - 2284.45s | Now to sum up these two patches we saw that Microsoft only addresses specific code flows 2285.21s - 2287.69s | And specific scenarios that leads to the 2288.77s - 2295.73s | unsafe API the MK parse display name and we left some questions open for you to investigate


chunk_id: 152_chunk_35
chunk_text:
image tag the parsing of that composite moniker won't go through the 2230.13s - 2236.57s | MSO HR link rate from string that was patched instead. It will invoke the HR payment from URL that 2238.21s - 2242.61s | Handles things and those the parsing of the URLs from image tags 2242.61s - 2247.77s | and it will directly call the H link parse display name that 2248.41s - 2255.61s | Will eventually got the same code flow that reaches to the unsafe API MK parse display name 2256.61s - 2263.09s | And now that we are familiar with how Microsoft patches some vulnerabilities in office applications 2263.73s - 2265.73s | The patch is quite obvious, right? 2266.45s - 2269.69s | setting the infamous flag to true, but this time from 2270.89s - 2277.07s | HR payment from URL and again only if the application ID equals outlook 2278.05s - 2284.45s | Now to sum up these two patches we saw that Microsoft only addresses specific code flows 2285.21s - 2287.69s | And specific scenarios that leads to the 2288.77s - 2295.73s | unsafe API the MK parse display name and we left some questions open for you to investigate and 2296.25s - 2298.25s | We are certain that there are 2298.77s - 2303.37s | More applications and more code flows that leads to that unsafe API 2306.87s - 2308.71s | okay, just 2308.71s - 2310.47s | some additional note 2310.47s - 2317.67s | As Arnold shared and thank you Arnold Microsoft patch the remote the code execution by introducing this additional 2318.71s - 2325.27s | Hook and turning on the flag through this control flow. It didn't solve the NTLM leak 2325.95s - 2332.03s | now we obviously didn't want to publish it, but we got a response from Microsoft that there is a 2333.39s - 2337.23s | medium risk and for Microsoft it's not in the urgency and 2337.27s - 2338.51s | And 2338.51s - 2342.75s | The fact that the image cannot be automatically downloaded 2343.83s - 2347.51s | Because you have a kind of a preview mode if the sender is not trusted 2348.15s - 2352.19s | And they are right if it's lender is not trusted the image will not be automatically 2352.47s - 2356.39s | Downloaded and the compound moniker will not be automatically executed 2356.71s - 2358.99s | But if the sender is


chunk_id: 152_chunk_36
chunk_text:
and 2296.25s - 2298.25s | We are certain that there are 2298.77s - 2303.37s | More applications and more code flows that leads to that unsafe API 2306.87s - 2308.71s | okay, just 2308.71s - 2310.47s | some additional note 2310.47s - 2317.67s | As Arnold shared and thank you Arnold Microsoft patch the remote the code execution by introducing this additional 2318.71s - 2325.27s | Hook and turning on the flag through this control flow. It didn't solve the NTLM leak 2325.95s - 2332.03s | now we obviously didn't want to publish it, but we got a response from Microsoft that there is a 2333.39s - 2337.23s | medium risk and for Microsoft it's not in the urgency and 2337.27s - 2338.51s | And 2338.51s - 2342.75s | The fact that the image cannot be automatically downloaded 2343.83s - 2347.51s | Because you have a kind of a preview mode if the sender is not trusted 2348.15s - 2352.19s | And they are right if it's lender is not trusted the image will not be automatically 2352.47s - 2356.39s | Downloaded and the compound moniker will not be automatically executed 2356.71s - 2358.99s | But if the sender is trusted 2359.59s - 2361.03s | again someone in the 2361.07s - 2367.47s | Organization let's say it was compromised and you utilizing his credential to send to the other victim within the same 2367.71s - 2372.79s | Organization the same link the image will be automatically downloaded or previewed 2373.31s - 2377.43s | And the NTLM will happen and this is unfortunately wasn't patched 2378.71s - 2384.95s | So let's let's just finalize. We have a couple of minutes left some recommendations 2386.47s - 2388.31s | Some of them are obvious 2388.35s - 2395.99s | Microsoft basically writes a lot about some of the recommendations obviously in forest care boroughs Windows 11 introduces 2396.39s - 2402.99s | I think an update already introduced update in which by default NTLM authentication will 2403.35s - 2409.15s | Will not be possible. I suppose it will not hold for a long due to backward compatibilities, etc 2410.63s - 2412.63s | Definitely enable SMB signing 2413.23s - 2420.71s | And manage your outbound SMB you don't want that kind of let's say network communication going outside of your organization 2421.35s - 2425.19s | And there are definitely additional recommendations that can follow 2426.15s -


chunk_id: 152_chunk_37
chunk_text:
trusted 2359.59s - 2361.03s | again someone in the 2361.07s - 2367.47s | Organization let's say it was compromised and you utilizing his credential to send to the other victim within the same 2367.71s - 2372.79s | Organization the same link the image will be automatically downloaded or previewed 2373.31s - 2377.43s | And the NTLM will happen and this is unfortunately wasn't patched 2378.71s - 2384.95s | So let's let's just finalize. We have a couple of minutes left some recommendations 2386.47s - 2388.31s | Some of them are obvious 2388.35s - 2395.99s | Microsoft basically writes a lot about some of the recommendations obviously in forest care boroughs Windows 11 introduces 2396.39s - 2402.99s | I think an update already introduced update in which by default NTLM authentication will 2403.35s - 2409.15s | Will not be possible. I suppose it will not hold for a long due to backward compatibilities, etc 2410.63s - 2412.63s | Definitely enable SMB signing 2413.23s - 2420.71s | And manage your outbound SMB you don't want that kind of let's say network communication going outside of your organization 2421.35s - 2425.19s | And there are definitely additional recommendations that can follow 2426.15s - 2427.71s | now just 2427.71s - 2432.75s | Before we kind of end that presentation some credit references again as we mentioned 2433.23s - 2436.47s | Net spy is doing great work discovering new stuff 2437.47s - 2440.03s | Check point also as well and so as 2440.55s - 2443.63s | Etienne Stevens, I'm sure I'm missing a lot of other folks 2444.27s - 2449.03s | Because a lot of work is being invested you guys are welcome to ask our questions 2449.95s - 2454.11s | We will be waiting here behind at the entry door for like 10 minutes 2454.75s - 2460.55s | But overall we are done. We it's an honor to present them at the DEF CON 2460.63s - 2465.27s | We are thanking you to come here to see our presentation 2465.27s - 2467.51s | Thank you


chunk_id: 152_chunk_38
chunk_text:
2427.71s | now just 2427.71s - 2432.75s | Before we kind of end that presentation some credit references again as we mentioned 2433.23s - 2436.47s | Net spy is doing great work discovering new stuff 2437.47s - 2440.03s | Check point also as well and so as 2440.55s - 2443.63s | Etienne Stevens, I'm sure I'm missing a lot of other folks 2444.27s - 2449.03s | Because a lot of work is being invested you guys are welcome to ask our questions 2449.95s - 2454.11s | We will be waiting here behind at the entry door for like 10 minutes 2454.75s - 2460.55s | But overall we are done. We it's an honor to present them at the DEF CON 2460.63s - 2465.27s | We are thanking you to come here to see our presentation 2465.27s - 2467.51s | Thank you


chunk_id: 153_chunk_0
chunk_text:
{ "webpage_url": "https://www.youtube.com/watch?v=R5nMqju6crY", "title": "DEF CON 32 - Optical Espionage: Using Lasers to Hear Keystrokes Through Glass Windows - samy kamkar", "description": "Sashay away from this talk with the knowledge to perform state-of-the-art espionage, no technical background required.\n\nIn the realm of privilege escalation and data exfiltration, the physical world quietly screams secrets. We'll demystify the fascinating physics behind signals and how various forms of energy--infrared, visible, and ultraviolet light, radio, ultrasound, audible sound, mechanical vibration, and temperature--can be interpreted as waves that unintentionally leak information, even in air-gapped (non-networked) systems. We'll observe how air is in fact not an effective gap or barrier as radio, light, sound, and vibration excitedly travel through it. We'll explore how all electrical signals radiate electromagnetism (light or radio) that can be intercepted and how we can reverse this process, producing electromagnetism to inject desired electrical signals into our target.\n\nWe'll delve into historical and seminal side-channel/TEMPEST attacks from our friends at the NSA, KGB, and past DEF CON pioneers. You'll learn about the essential electrical and optical components combined for cutting-edge eavesdropping, including what our target is typing from a distance.\n\nWhile others believe they're obtaining noise, we will extract signal, and you'll leave this talk hearing the world in a new light.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2734, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 2.00s | This text was transcribed using whisper model: large-v2 How's everybody doing? 2.00s - 5.00s | Okay, I want you to, on three, repeat after me the word engage. 5.00s - 7.00s | Ready? One, two, three. 7.00s - 8.00s | Engage. 8.00s - 10.00s | Engage. One, two, three. 10.00s - 11.00s | Engage. 11.00s - 14.89s | Awesome. Here's our speaker, give him a big hand. 14.89s - 20.11s | Thank you. 20.11s - 24.11s | It's 1995, I'm ten years old, 24.11s - 28.11s | and my mom just spent everything she had to get me this computer. 28.11s - 30.11s | And this is the best day of my life. 30.11s - 33.11s | I dial up to the internet. Some of you know what that means. 33.11s - 35.11s | I dial up to my mom's university 35.11s - 38.11s | and I download MIRC. 38.11s - 41.11s | I go on to Internet Relay Chat IRC. 41.11s - 42.11s | Oh no. 42.11s - 45.11s | And I join a channel and I


chunk_id: 153_chunk_1
chunk_text:
hearing the world in a new light.", "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw", "duration": 2734, "channel": "DEFCONConference", "uploader": "DEFCONConference", "upload_date": "20241016" } 0.00s - 2.00s | This text was transcribed using whisper model: large-v2 How's everybody doing? 2.00s - 5.00s | Okay, I want you to, on three, repeat after me the word engage. 5.00s - 7.00s | Ready? One, two, three. 7.00s - 8.00s | Engage. 8.00s - 10.00s | Engage. One, two, three. 10.00s - 11.00s | Engage. 11.00s - 14.89s | Awesome. Here's our speaker, give him a big hand. 14.89s - 20.11s | Thank you. 20.11s - 24.11s | It's 1995, I'm ten years old, 24.11s - 28.11s | and my mom just spent everything she had to get me this computer. 28.11s - 30.11s | And this is the best day of my life. 30.11s - 33.11s | I dial up to the internet. Some of you know what that means. 33.11s - 35.11s | I dial up to my mom's university 35.11s - 38.11s | and I download MIRC. 38.11s - 41.11s | I go on to Internet Relay Chat IRC. 41.11s - 42.11s | Oh no. 42.11s - 45.11s | And I join a channel and I say, 45.11s - 49.11s | who wants to chat about the X-Files? 49.11s - 53.11s | And someone says, get out. 53.11s - 55.11s | And I didn't understand why. 55.11s - 57.11s | And I said, we can chat about something else. 57.11s - 59.11s | What TV show do you like? 59.11s - 63.11s | And they say, you have ten seconds to get out of this chat room. 63.11s - 66.11s | And I think, my mom told me, don't tell anyone your name on the internet 66.11s - 68.11s | and don't tell them where you live. 68.11s - 70.11s | So they don't know anything about me. 70.11s - 72.11s | So I say, no. 72.11s - 76.11s | And this person says, you have ten seconds to get out of this chat room. 76.11s - 77.11s | I'm like, no. 77.11s - 81.11s | Ten seconds later, the brand new computer that my mom spent everything on 81.11s - 83.11s | does this. 83.11s - 85.11s | It wasn't running CrowdStrike. 85.11s - 88.11s | This is 1995. 88.11s - 91.11s | This person just crashed my computer over the internet 91.11s - 93.11s


chunk_id: 153_chunk_2
chunk_text:
say, 45.11s - 49.11s | who wants to chat about the X-Files? 49.11s - 53.11s | And someone says, get out. 53.11s - 55.11s | And I didn't understand why. 55.11s - 57.11s | And I said, we can chat about something else. 57.11s - 59.11s | What TV show do you like? 59.11s - 63.11s | And they say, you have ten seconds to get out of this chat room. 63.11s - 66.11s | And I think, my mom told me, don't tell anyone your name on the internet 66.11s - 68.11s | and don't tell them where you live. 68.11s - 70.11s | So they don't know anything about me. 70.11s - 72.11s | So I say, no. 72.11s - 76.11s | And this person says, you have ten seconds to get out of this chat room. 76.11s - 77.11s | I'm like, no. 77.11s - 81.11s | Ten seconds later, the brand new computer that my mom spent everything on 81.11s - 83.11s | does this. 83.11s - 85.11s | It wasn't running CrowdStrike. 85.11s - 88.11s | This is 1995. 88.11s - 91.11s | This person just crashed my computer over the internet 91.11s - 93.11s | without knowing anything about me. 93.11s - 94.11s | And I freaked out. 94.11s - 96.11s | I'm going to be grounded for the rest of my life. 96.11s - 99.11s | I pull all the wires out of the computer. 99.11s - 102.11s | I wait for the computer to heal. 102.11s - 104.11s | About half an hour. 104.11s - 106.11s | I plug the wires back in. 106.11s - 108.11s | And it comes up. 108.11s - 112.11s | As it's coming up, everything is okay. 112.11s - 115.11s | And while the adrenaline is still rushing through my veins, 115.11s - 117.11s | I think, that is the coolest thing ever. 117.11s - 119.11s | How do I do that? 119.11s - 122.11s | And I find this, Winuke95. 122.11s - 126.11s | So a single out-of-band packet will crash Windows 95. 126.11s - 127.11s | And this was super cool. 127.11s - 131.11s | I downloaded this program, and now I'm an elite hacksaw. 131.11s - 134.11s | And then Microsoft released Windows Service Pack 2, 134.11s - 136.11s | which resolved this. 136.11s - 138.11s | And all of a sudden, my magical


chunk_id: 153_chunk_3
chunk_text:
| without knowing anything about me. 93.11s - 94.11s | And I freaked out. 94.11s - 96.11s | I'm going to be grounded for the rest of my life. 96.11s - 99.11s | I pull all the wires out of the computer. 99.11s - 102.11s | I wait for the computer to heal. 102.11s - 104.11s | About half an hour. 104.11s - 106.11s | I plug the wires back in. 106.11s - 108.11s | And it comes up. 108.11s - 112.11s | As it's coming up, everything is okay. 112.11s - 115.11s | And while the adrenaline is still rushing through my veins, 115.11s - 117.11s | I think, that is the coolest thing ever. 117.11s - 119.11s | How do I do that? 119.11s - 122.11s | And I find this, Winuke95. 122.11s - 126.11s | So a single out-of-band packet will crash Windows 95. 126.11s - 127.11s | And this was super cool. 127.11s - 131.11s | I downloaded this program, and now I'm an elite hacksaw. 131.11s - 134.11s | And then Microsoft released Windows Service Pack 2, 134.11s - 136.11s | which resolved this. 136.11s - 138.11s | And all of a sudden, my magical tool didn't work anymore. 138.11s - 143.11s | So how do I learn how to create Winuke96? 143.11s - 145.11s | And that's when I found Frack. 145.11s - 147.11s | And Frack is a magazine that's still going today. 147.11s - 149.11s | I believe it started in 85. 149.11s - 152.11s | And I read, smashing the stack for fun and profit. 152.11s - 155.11s | And this just blew my mind. 155.11s - 158.11s | The simplest C program that says, hey, what is your name? 158.11s - 160.11s | You have to allocate 100 bytes, and you say, 160.11s - 161.11s | and you type in your name. 161.11s - 163.11s | And if it doesn't check, and it just prints, 163.11s - 165.11s | hey, hello, your name, 165.11s - 166.11s | if you type over that 100 bytes, 166.11s - 168.11s | and you're not checking for 100 bytes, 168.11s - 169.11s | you can start overwriting memory, 169.11s - 170.11s | and then you can overwrite the stack pointer, 170.11s - 172.11s | and then you can point back to the beginning of your name, 172.11s - 173.11s | and that can be


chunk_id: 153_chunk_4
chunk_text:
tool didn't work anymore. 138.11s - 143.11s | So how do I learn how to create Winuke96? 143.11s - 145.11s | And that's when I found Frack. 145.11s - 147.11s | And Frack is a magazine that's still going today. 147.11s - 149.11s | I believe it started in 85. 149.11s - 152.11s | And I read, smashing the stack for fun and profit. 152.11s - 155.11s | And this just blew my mind. 155.11s - 158.11s | The simplest C program that says, hey, what is your name? 158.11s - 160.11s | You have to allocate 100 bytes, and you say, 160.11s - 161.11s | and you type in your name. 161.11s - 163.11s | And if it doesn't check, and it just prints, 163.11s - 165.11s | hey, hello, your name, 165.11s - 166.11s | if you type over that 100 bytes, 166.11s - 168.11s | and you're not checking for 100 bytes, 168.11s - 169.11s | you can start overwriting memory, 169.11s - 170.11s | and then you can overwrite the stack pointer, 170.11s - 172.11s | and then you can point back to the beginning of your name, 172.11s - 173.11s | and that can be shell code, 173.11s - 174.11s | and that can execute code on the computer, 174.11s - 175.11s | and you can take over a computer 175.11s - 177.11s | with an extremely simple program. 177.11s - 180.11s | And that taught me that the way a system works 180.11s - 182.11s | is not how we think it works. 182.11s - 185.11s | Like, I want to now understand, what is the ground truth? 185.11s - 186.11s | How do systems actually work? 186.11s - 188.11s | How does a computer actually work? 188.11s - 189.11s | And it's only when you understand 189.11s - 190.11s | the CPU architecture and memory, 190.11s - 194.11s | and how, when you're compiling your C code into, 194.11s - 195.11s | and assembling it, and linking it, 195.11s - 197.11s | how you can actually take over the system. 197.11s - 200.11s | And over time, as I've learned from many of you, 200.11s - 202.11s | and from papers, and from videos, 202.11s - 203.11s | and just testing things, 203.11s - 206.11s | that ultimately, everything boils down to energy. 206.11s - 208.11s | Like, everything is energy. 208.11s -


chunk_id: 153_chunk_5
chunk_text:
shell code, 173.11s - 174.11s | and that can execute code on the computer, 174.11s - 175.11s | and you can take over a computer 175.11s - 177.11s | with an extremely simple program. 177.11s - 180.11s | And that taught me that the way a system works 180.11s - 182.11s | is not how we think it works. 182.11s - 185.11s | Like, I want to now understand, what is the ground truth? 185.11s - 186.11s | How do systems actually work? 186.11s - 188.11s | How does a computer actually work? 188.11s - 189.11s | And it's only when you understand 189.11s - 190.11s | the CPU architecture and memory, 190.11s - 194.11s | and how, when you're compiling your C code into, 194.11s - 195.11s | and assembling it, and linking it, 195.11s - 197.11s | how you can actually take over the system. 197.11s - 200.11s | And over time, as I've learned from many of you, 200.11s - 202.11s | and from papers, and from videos, 202.11s - 203.11s | and just testing things, 203.11s - 206.11s | that ultimately, everything boils down to energy. 206.11s - 208.11s | Like, everything is energy. 208.11s - 209.11s | Information is energy. 209.11s - 213.11s | By energy, I'm really talking, we're talking power. 213.11s - 215.11s | Energy is the capacity to do work. 215.11s - 217.11s | So, to perform some type of work. 217.11s - 220.11s | Power is the rate at which that work is done. 220.11s - 222.11s | So, for example, a horsepower. 222.11s - 225.11s | Like, a horsepower is actually a unit of power. 225.11s - 230.11s | One horsepower lifts 550 pounds in one second, by one foot. 230.11s - 231.11s | I looked it up on Wikipedia. 231.11s - 233.11s | It's actually imperial horsepower. 233.11s - 235.11s | That means there's also a metric horsepower, 235.11s - 238.11s | which lifts 542 pounds, slightly less. 238.11s - 241.11s | I'm not sure what we're feeding our horses. 241.11s - 246.11s | Probably HGH, horse growth hormone. 246.11s - 248.11s | So, energy in power. 248.11s - 250.11s | And I realize, energy is information. 250.11s - 252.11s | So, if we want to actually move any information around, 252.11s - 254.11s | we must use energy. 254.11s - 255.11s | An example of that is, 255.11s


chunk_id: 153_chunk_6
chunk_text:
209.11s | Information is energy. 209.11s - 213.11s | By energy, I'm really talking, we're talking power. 213.11s - 215.11s | Energy is the capacity to do work. 215.11s - 217.11s | So, to perform some type of work. 217.11s - 220.11s | Power is the rate at which that work is done. 220.11s - 222.11s | So, for example, a horsepower. 222.11s - 225.11s | Like, a horsepower is actually a unit of power. 225.11s - 230.11s | One horsepower lifts 550 pounds in one second, by one foot. 230.11s - 231.11s | I looked it up on Wikipedia. 231.11s - 233.11s | It's actually imperial horsepower. 233.11s - 235.11s | That means there's also a metric horsepower, 235.11s - 238.11s | which lifts 542 pounds, slightly less. 238.11s - 241.11s | I'm not sure what we're feeding our horses. 241.11s - 246.11s | Probably HGH, horse growth hormone. 246.11s - 248.11s | So, energy in power. 248.11s - 250.11s | And I realize, energy is information. 250.11s - 252.11s | So, if we want to actually move any information around, 252.11s - 254.11s | we must use energy. 254.11s - 255.11s | An example of that is, 255.11s - 257.11s | we think that there's power in data, 257.11s - 258.11s | but that's not true. 258.11s - 259.11s | That's not true. 259.11s - 261.11s | Power is data, and data is power. 261.11s - 263.11s | If you have a USB 2.0, 263.11s - 265.11s | you plug your USB in, it doesn't work, 265.11s - 267.11s | so you plug it in the other way, it doesn't work. 267.11s - 268.11s | The third time, it always works. 268.11s - 270.11s | When you plug that in, there are four pins. 270.11s - 272.11s | There's ground, power, and then two data. 272.11s - 273.11s | Differential data. 273.11s - 276.11s | Now, the ground and power, there's energy moving over that. 276.11s - 278.11s | But there's also information across that. 278.11s - 280.11s | If you're plugged into a computer that's encrypting something, 280.11s - 282.11s | there's going to be some information of that encryption 282.11s - 284.11s | about the amount of power that's being, 284.11s - 286.11s | and that's going to ride on the power. 286.11s - 289.11s | The power will actually go up and down just a


chunk_id: 153_chunk_7
chunk_text:
- 257.11s | we think that there's power in data, 257.11s - 258.11s | but that's not true. 258.11s - 259.11s | That's not true. 259.11s - 261.11s | Power is data, and data is power. 261.11s - 263.11s | If you have a USB 2.0, 263.11s - 265.11s | you plug your USB in, it doesn't work, 265.11s - 267.11s | so you plug it in the other way, it doesn't work. 267.11s - 268.11s | The third time, it always works. 268.11s - 270.11s | When you plug that in, there are four pins. 270.11s - 272.11s | There's ground, power, and then two data. 272.11s - 273.11s | Differential data. 273.11s - 276.11s | Now, the ground and power, there's energy moving over that. 276.11s - 278.11s | But there's also information across that. 278.11s - 280.11s | If you're plugged into a computer that's encrypting something, 280.11s - 282.11s | there's going to be some information of that encryption 282.11s - 284.11s | about the amount of power that's being, 284.11s - 286.11s | and that's going to ride on the power. 286.11s - 289.11s | The power will actually go up and down just a little bit. 289.11s - 291.11s | That five volts will move up and down. 291.11s - 292.11s | You can measure that. 292.11s - 293.11s | And then there's the data. 293.11s - 294.11s | Well, how does the data work? 294.11s - 297.11s | Like, what is actually going across data lines? 297.11s - 298.11s | That's a voltage. 298.11s - 300.11s | So there is actually current and voltage, 300.11s - 303.11s | which is power, pushing through those data lines. 303.11s - 306.11s | So you can always extract power from this stuff. 306.11s - 309.11s | And I remember I'm sitting at my computer maybe 15 years ago, 309.11s - 312.11s | and I had these Dell speakers on my computer, 312.11s - 315.11s | and I got a text message, 315.11s - 316.11s | and I was about to get a text message, 316.11s - 318.11s | and I don't know if many of you recall 318.11s - 320.11s | that sometimes you get this interference. 320.11s - 321.11s | You get a text message or a phone call, 321.11s - 322.11s | and then your speakers go, 322.11s - 324.11s | do-do-do-do-do-do-do-do-do. 324.11s -


chunk_id: 153_chunk_8
chunk_text:
little bit. 289.11s - 291.11s | That five volts will move up and down. 291.11s - 292.11s | You can measure that. 292.11s - 293.11s | And then there's the data. 293.11s - 294.11s | Well, how does the data work? 294.11s - 297.11s | Like, what is actually going across data lines? 297.11s - 298.11s | That's a voltage. 298.11s - 300.11s | So there is actually current and voltage, 300.11s - 303.11s | which is power, pushing through those data lines. 303.11s - 306.11s | So you can always extract power from this stuff. 306.11s - 309.11s | And I remember I'm sitting at my computer maybe 15 years ago, 309.11s - 312.11s | and I had these Dell speakers on my computer, 312.11s - 315.11s | and I got a text message, 315.11s - 316.11s | and I was about to get a text message, 316.11s - 318.11s | and I don't know if many of you recall 318.11s - 320.11s | that sometimes you get this interference. 320.11s - 321.11s | You get a text message or a phone call, 321.11s - 322.11s | and then your speakers go, 322.11s - 324.11s | do-do-do-do-do-do-do-do-do. 324.11s - 327.11s | And I was like, wait, my phone's not connected to anything, 327.11s - 330.11s | yet the speakers are actually playing sound. 330.11s - 332.11s | Like, there is some sort of interference here. 332.11s - 333.11s | Could I control that? 333.11s - 335.11s | Like, if my phone can do that, 335.11s - 337.11s | so it's not actually the cell towers, 337.11s - 339.11s | it's actually your phone trying to amplify its signal 339.11s - 340.11s | and get back to the cell tower. 340.11s - 343.11s | The cell tower is far away, so it amplifies the signal. 343.11s - 345.11s | And I thought, okay, well, can I open a keyboard? 345.11s - 347.11s | Can I look at how the keyboard works? 347.11s - 349.11s | And if my phone can interfere with the speaker, 349.11s - 351.11s | can my phone then interfere with the keyboard? 351.11s - 353.11s | And can I press keystrokes? 353.11s - 355.11s | So I opened up a keyboard. 355.11s - 356.11s | It's a USB keyboard. 356.11s - 357.11s | And when you open it up, 357.11s - 359.11s | you have a


chunk_id: 153_chunk_9
chunk_text:
327.11s | And I was like, wait, my phone's not connected to anything, 327.11s - 330.11s | yet the speakers are actually playing sound. 330.11s - 332.11s | Like, there is some sort of interference here. 332.11s - 333.11s | Could I control that? 333.11s - 335.11s | Like, if my phone can do that, 335.11s - 337.11s | so it's not actually the cell towers, 337.11s - 339.11s | it's actually your phone trying to amplify its signal 339.11s - 340.11s | and get back to the cell tower. 340.11s - 343.11s | The cell tower is far away, so it amplifies the signal. 343.11s - 345.11s | And I thought, okay, well, can I open a keyboard? 345.11s - 347.11s | Can I look at how the keyboard works? 347.11s - 349.11s | And if my phone can interfere with the speaker, 349.11s - 351.11s | can my phone then interfere with the keyboard? 351.11s - 353.11s | And can I press keystrokes? 353.11s - 355.11s | So I opened up a keyboard. 355.11s - 356.11s | It's a USB keyboard. 356.11s - 357.11s | And when you open it up, 357.11s - 359.11s | you have a circuit board that's PCB, 359.11s - 360.11s | your fiberglass, 360.11s - 362.11s | and then you have all these conductors. 362.11s - 365.11s | And every conductor going to every key is a unique length, 365.11s - 366.11s | and they're all copper. 366.11s - 367.11s | They're all metal. 367.11s - 369.11s | Any piece of metal is an antenna. 369.11s - 371.11s | If you measure that antenna, the length of that antenna, 371.11s - 372.11s | that's a monopole antenna. 372.11s - 374.11s | That measurement is the wavelength, 374.11s - 375.11s | the resonant frequency. 375.11s - 377.11s | So you can figure out the resonant frequency 377.11s - 379.11s | of every wire going into that. 379.11s - 382.11s | And I thought, well, can I create an electromagnetic radio 382.11s - 386.11s | that can then inject keystrokes into this keyboard wirelessly? 386.11s - 388.11s | And I started to try to do this. 388.11s - 391.11s | And I started to realize that it's not working. 391.11s - 393.11s | I tried a couple different software-defined radios 393.11s - 396.11s | like HackRF and the USRP-B210, 396.11s - 399.11s | and I


chunk_id: 153_chunk_10
chunk_text:
circuit board that's PCB, 359.11s - 360.11s | your fiberglass, 360.11s - 362.11s | and then you have all these conductors. 362.11s - 365.11s | And every conductor going to every key is a unique length, 365.11s - 366.11s | and they're all copper. 366.11s - 367.11s | They're all metal. 367.11s - 369.11s | Any piece of metal is an antenna. 369.11s - 371.11s | If you measure that antenna, the length of that antenna, 371.11s - 372.11s | that's a monopole antenna. 372.11s - 374.11s | That measurement is the wavelength, 374.11s - 375.11s | the resonant frequency. 375.11s - 377.11s | So you can figure out the resonant frequency 377.11s - 379.11s | of every wire going into that. 379.11s - 382.11s | And I thought, well, can I create an electromagnetic radio 382.11s - 386.11s | that can then inject keystrokes into this keyboard wirelessly? 386.11s - 388.11s | And I started to try to do this. 388.11s - 391.11s | And I started to realize that it's not working. 391.11s - 393.11s | I tried a couple different software-defined radios 393.11s - 396.11s | like HackRF and the USRP-B210, 396.11s - 399.11s | and I was never able to inject all the keystrokes I wanted. 399.11s - 401.11s | With one keyboard, I was able to inject a few keystrokes. 401.11s - 402.11s | And I'm like, 402.11s - 404.11s | I really just don't understand electromagnetism enough. 404.11s - 406.11s | So I started to learn about physics. 406.11s - 409.11s | And I started to learn about, well, what is electromagnetism? 409.11s - 412.11s | It's really light, light and radio. 412.11s - 415.11s | And I took a picture of a rainbow on a jog. 415.11s - 419.11s | And really, electromagnetism is light. 419.11s - 423.11s | We can split that light up into its constituent wavelengths, 423.11s - 425.11s | and there's all sorts of other frequencies. 425.11s - 427.11s | So radio, for example, is light. 427.11s - 430.11s | Radio is just colors of light that we can't see with our eyes. 430.11s - 433.11s | And as I wanted to learn about this and how this stuff works, 433.11s - 436.11s | I started learning about light and EM and radio. 436.11s - 438.11s | And I need to learn physics. 438.11s - 440.11s | So I


chunk_id: 153_chunk_11
chunk_text:
was never able to inject all the keystrokes I wanted. 399.11s - 401.11s | With one keyboard, I was able to inject a few keystrokes. 401.11s - 402.11s | And I'm like, 402.11s - 404.11s | I really just don't understand electromagnetism enough. 404.11s - 406.11s | So I started to learn about physics. 406.11s - 409.11s | And I started to learn about, well, what is electromagnetism? 409.11s - 412.11s | It's really light, light and radio. 412.11s - 415.11s | And I took a picture of a rainbow on a jog. 415.11s - 419.11s | And really, electromagnetism is light. 419.11s - 423.11s | We can split that light up into its constituent wavelengths, 423.11s - 425.11s | and there's all sorts of other frequencies. 425.11s - 427.11s | So radio, for example, is light. 427.11s - 430.11s | Radio is just colors of light that we can't see with our eyes. 430.11s - 433.11s | And as I wanted to learn about this and how this stuff works, 433.11s - 436.11s | I started learning about light and EM and radio. 436.11s - 438.11s | And I need to learn physics. 438.11s - 440.11s | So I started to get some physics books 440.11s - 442.11s | and start reading about this stuff. 442.11s - 444.11s | One of those books was Building Scientific Apparatus. 444.11s - 446.11s | And I learned, okay, well, 446.11s - 448.11s | a lot of the people who are learning physics, 448.11s - 451.11s | which is really how hardware works and how radio works, 451.11s - 453.11s | they started by, like, J.J. Thompson, 453.11s - 455.11s | who broke the atom open. 455.11s - 458.11s | Like, it's called the atom from Greek atomos, meaning indivisible. 458.11s - 460.11s | Until this dude, J.J. Thompson, 460.11s - 462.11s | put a bunch of atoms inside of a glass tube, 462.11s - 464.11s | evacuated, pulled almost everything out, 464.11s - 466.11s | put a high voltage, and then split the atom. 466.11s - 468.11s | It was divisible. 468.11s - 470.11s | And then he used magnets, and he could move the atoms 470.11s - 472.11s | that were producing light. 472.11s - 474.11s | And that became our cathode ray tube, 474.11s - 476.11s | our CRT TVs and monitors that we used. 476.11s - 478.11s | I'm


chunk_id: 153_chunk_12
chunk_text:
started to get some physics books 440.11s - 442.11s | and start reading about this stuff. 442.11s - 444.11s | One of those books was Building Scientific Apparatus. 444.11s - 446.11s | And I learned, okay, well, 446.11s - 448.11s | a lot of the people who are learning physics, 448.11s - 451.11s | which is really how hardware works and how radio works, 451.11s - 453.11s | they started by, like, J.J. Thompson, 453.11s - 455.11s | who broke the atom open. 455.11s - 458.11s | Like, it's called the atom from Greek atomos, meaning indivisible. 458.11s - 460.11s | Until this dude, J.J. Thompson, 460.11s - 462.11s | put a bunch of atoms inside of a glass tube, 462.11s - 464.11s | evacuated, pulled almost everything out, 464.11s - 466.11s | put a high voltage, and then split the atom. 466.11s - 468.11s | It was divisible. 468.11s - 470.11s | And then he used magnets, and he could move the atoms 470.11s - 472.11s | that were producing light. 472.11s - 474.11s | And that became our cathode ray tube, 474.11s - 476.11s | our CRT TVs and monitors that we used. 476.11s - 478.11s | I'm like, this is super cool. I should reproduce this. 478.11s - 480.11s | So I set up a little glassblowing station at home, 480.11s - 483.11s | and I tried to blow glass and do some lamp work, 483.11s - 485.11s | but all my stuff would always break. 485.11s - 487.11s | I'd make something, and then it would crack. 487.11s - 490.11s | I'm like, all right, I need to actually learn some glassblowing. 490.11s - 492.11s | I took some classes in L.A., 492.11s - 494.11s | but these are all soft glass. 494.11s - 496.11s | And I still would come home, and I'd try to make some stuff, 496.11s - 498.11s | and it would break. 498.11s - 500.11s | Then I went on the Internet, and I found, okay, 500.11s - 503.11s | I found this guy who makes all sorts of borosilicate glass, 503.11s - 505.11s | which is like scientific glassblowing. 505.11s - 507.11s | And I messaged him, and I messaged everyone, 507.11s - 509.11s | every other scientific glassblower in Los Angeles. 509.11s - 512.11s | Hey, I want you to learn how to glassblow. 512.11s - 514.11s | I


chunk_id: 153_chunk_13
chunk_text:
like, this is super cool. I should reproduce this. 478.11s - 480.11s | So I set up a little glassblowing station at home, 480.11s - 483.11s | and I tried to blow glass and do some lamp work, 483.11s - 485.11s | but all my stuff would always break. 485.11s - 487.11s | I'd make something, and then it would crack. 487.11s - 490.11s | I'm like, all right, I need to actually learn some glassblowing. 490.11s - 492.11s | I took some classes in L.A., 492.11s - 494.11s | but these are all soft glass. 494.11s - 496.11s | And I still would come home, and I'd try to make some stuff, 496.11s - 498.11s | and it would break. 498.11s - 500.11s | Then I went on the Internet, and I found, okay, 500.11s - 503.11s | I found this guy who makes all sorts of borosilicate glass, 503.11s - 505.11s | which is like scientific glassblowing. 505.11s - 507.11s | And I messaged him, and I messaged everyone, 507.11s - 509.11s | every other scientific glassblower in Los Angeles. 509.11s - 512.11s | Hey, I want you to learn how to glassblow. 512.11s - 514.11s | I will pay you. 514.11s - 516.11s | Everyone said no. Like, I have a job. 516.11s - 518.11s | I can't just come to my work. 518.11s - 520.11s | And that's probably, like, illegal or something. 520.11s - 522.11s | So I went on LinkedIn, and I searched 522.11s - 524.11s | more scientific glassblowers across the U.S., 524.11s - 526.11s | and I just messaged everyone. 526.11s - 528.11s | Like, someone has to say yes, right? 528.11s - 530.11s | Someone will, like, let me pay them for a few hours, 530.11s - 532.11s | so I can just, and I get a response from Katie. 532.11s - 534.11s | Hey, I see that you're in L.A. 534.11s - 536.11s | We're in Milwaukee, Wisconsin. 536.11s - 538.11s | Is this something that you would travel for? 538.11s - 540.11s | So a week later, I get, 540.11s - 543.11s | Delta tickets are very cheap to Wisconsin in winter. 543.11s - 546.11s | It's because it's freezing in Wisconsin in the winter. 546.11s - 548.11s | It's so cold. 548.11s - 550.11s | I show up to this place, and I say, 550.11s - 552.11s |


chunk_id: 153_chunk_14
chunk_text:
will pay you. 514.11s - 516.11s | Everyone said no. Like, I have a job. 516.11s - 518.11s | I can't just come to my work. 518.11s - 520.11s | And that's probably, like, illegal or something. 520.11s - 522.11s | So I went on LinkedIn, and I searched 522.11s - 524.11s | more scientific glassblowers across the U.S., 524.11s - 526.11s | and I just messaged everyone. 526.11s - 528.11s | Like, someone has to say yes, right? 528.11s - 530.11s | Someone will, like, let me pay them for a few hours, 530.11s - 532.11s | so I can just, and I get a response from Katie. 532.11s - 534.11s | Hey, I see that you're in L.A. 534.11s - 536.11s | We're in Milwaukee, Wisconsin. 536.11s - 538.11s | Is this something that you would travel for? 538.11s - 540.11s | So a week later, I get, 540.11s - 543.11s | Delta tickets are very cheap to Wisconsin in winter. 543.11s - 546.11s | It's because it's freezing in Wisconsin in the winter. 546.11s - 548.11s | It's so cold. 548.11s - 550.11s | I show up to this place, and I say, 550.11s - 552.11s | is Katie here? 552.11s - 554.11s | And an old woman answers the door and says, 554.11s - 556.11s | there's no one here by that name. 556.11s - 558.11s | I'm like, what? 558.11s - 560.11s | Did I just get pwned by someone that I reached out to? 560.11s - 562.11s | Because I put a deposit. 562.11s - 564.11s | I flew from Los Angeles to Wisconsin, 564.11s - 566.11s | and I'm just standing. I'm cold. I'm uncomfortable. 566.11s - 568.11s | And the person that I paid is not here. 568.11s - 570.11s | I look at my email. 570.11s - 572.11s | We never contacted, we never called each other. 572.11s - 574.11s | We just, like, chatted on LinkedIn. 574.11s - 576.11s | And then I found her phone number. I call her. 576.11s - 578.11s | It says, oh, I'm sorry. I switched the numbers. 578.11s - 580.11s | Fortunately, she was down the street. 580.11s - 582.11s | I walk down the street. 582.11s - 584.11s | We go into Ian's glassblowing station. 584.11s - 586.11s | So Ian and Katie are these two scientific glassblowers 586.11s - 588.11s | that


chunk_id: 153_chunk_15
chunk_text:
is Katie here? 552.11s - 554.11s | And an old woman answers the door and says, 554.11s - 556.11s | there's no one here by that name. 556.11s - 558.11s | I'm like, what? 558.11s - 560.11s | Did I just get pwned by someone that I reached out to? 560.11s - 562.11s | Because I put a deposit. 562.11s - 564.11s | I flew from Los Angeles to Wisconsin, 564.11s - 566.11s | and I'm just standing. I'm cold. I'm uncomfortable. 566.11s - 568.11s | And the person that I paid is not here. 568.11s - 570.11s | I look at my email. 570.11s - 572.11s | We never contacted, we never called each other. 572.11s - 574.11s | We just, like, chatted on LinkedIn. 574.11s - 576.11s | And then I found her phone number. I call her. 576.11s - 578.11s | It says, oh, I'm sorry. I switched the numbers. 578.11s - 580.11s | Fortunately, she was down the street. 580.11s - 582.11s | I walk down the street. 582.11s - 584.11s | We go into Ian's glassblowing station. 584.11s - 586.11s | So Ian and Katie are these two scientific glassblowers 586.11s - 588.11s | that work for a big science company out, 588.11s - 590.11s | excuse me, in Wisconsin. 590.11s - 592.11s | And I go into their shop. 592.11s - 594.11s | They show me their glassblowing lathe, their fume hood. 594.11s - 596.11s | Here's Ian showing me 596.11s - 598.11s | a lighter that he made. 598.11s - 600.11s | Katie with her lightsaber. 600.11s - 602.11s | That's fire. 602.11s - 604.11s | If you ever want to learn how to glassblow 604.11s - 606.11s | and you're in Wisconsin, you can email them, contact them. 606.11s - 608.11s | And I came back learning a little bit more 608.11s - 610.11s | about how to actually... 610.11s - 612.11s | You wanted a pic? 612.11s - 614.11s | I wanted a... 614.11s - 616.11s | I came back home able to actually 616.11s - 618.11s | blow a little bit more borosilicate glass, 618.11s - 620.11s | which is great. 620.11s - 622.11s | And when I came home, I was very excited, 622.11s - 624.11s | and I started to reproduce some of these. 624.11s - 626.11s | And I started to learn more about physics 626.11s -


chunk_id: 153_chunk_16
chunk_text:
work for a big science company out, 588.11s - 590.11s | excuse me, in Wisconsin. 590.11s - 592.11s | And I go into their shop. 592.11s - 594.11s | They show me their glassblowing lathe, their fume hood. 594.11s - 596.11s | Here's Ian showing me 596.11s - 598.11s | a lighter that he made. 598.11s - 600.11s | Katie with her lightsaber. 600.11s - 602.11s | That's fire. 602.11s - 604.11s | If you ever want to learn how to glassblow 604.11s - 606.11s | and you're in Wisconsin, you can email them, contact them. 606.11s - 608.11s | And I came back learning a little bit more 608.11s - 610.11s | about how to actually... 610.11s - 612.11s | You wanted a pic? 612.11s - 614.11s | I wanted a... 614.11s - 616.11s | I came back home able to actually 616.11s - 618.11s | blow a little bit more borosilicate glass, 618.11s - 620.11s | which is great. 620.11s - 622.11s | And when I came home, I was very excited, 622.11s - 624.11s | and I started to reproduce some of these. 624.11s - 626.11s | And I started to learn more about physics 626.11s - 628.11s | and more about waves. 628.11s - 630.11s | And one of the biggest realizations, 630.11s - 632.11s | one of the most helpful realizations for me 632.11s - 634.11s | is that I don't... 634.11s - 636.11s | It's very difficult for me to understand complex things. 636.11s - 638.11s | I don't understand complex things. 638.11s - 640.11s | I can only understand simple things. 640.11s - 642.11s | But I can take simple things and build 642.11s - 644.11s | a simple thing into a module, a block, 644.11s - 646.11s | and then use that block with another simple block 646.11s - 648.11s | and then build stuff on top of that, right? 648.11s - 650.11s | And if I can find patterns, 650.11s - 652.11s | then that makes my life much easier. 652.11s - 654.11s | I can just learn an abstract concept 654.11s - 656.11s | of what X, Y, and Z are 656.11s - 658.11s | if they're the same. 658.11s - 660.11s | And we can interpret everything as waves, 660.11s - 662.11s | as analog signals. 662.11s - 664.11s | So a wave has three things that are important.


chunk_id: 153_chunk_17
chunk_text:
628.11s | and more about waves. 628.11s - 630.11s | And one of the biggest realizations, 630.11s - 632.11s | one of the most helpful realizations for me 632.11s - 634.11s | is that I don't... 634.11s - 636.11s | It's very difficult for me to understand complex things. 636.11s - 638.11s | I don't understand complex things. 638.11s - 640.11s | I can only understand simple things. 640.11s - 642.11s | But I can take simple things and build 642.11s - 644.11s | a simple thing into a module, a block, 644.11s - 646.11s | and then use that block with another simple block 646.11s - 648.11s | and then build stuff on top of that, right? 648.11s - 650.11s | And if I can find patterns, 650.11s - 652.11s | then that makes my life much easier. 652.11s - 654.11s | I can just learn an abstract concept 654.11s - 656.11s | of what X, Y, and Z are 656.11s - 658.11s | if they're the same. 658.11s - 660.11s | And we can interpret everything as waves, 660.11s - 662.11s | as analog signals. 662.11s - 664.11s | So a wave has three things that are important. 664.11s - 666.11s | Now, when I say waves, light is a wave. 666.11s - 668.11s | Sound is a wave. 668.11s - 670.11s | Water waves are waves. 670.11s - 672.11s | They all have the same properties. 672.11s - 674.11s | They have absorption, where they absorb 674.11s - 676.11s | and convert from one type of energy to another energy. 676.11s - 678.11s | They have reflection. 678.11s - 680.11s | They have refraction and diffraction. 680.11s - 682.11s | A wave has three things. 682.11s - 684.11s | There's the amplitude. 684.11s - 686.11s | Amplitude means intensity. 686.11s - 688.11s | So the sound would be how loud it is. 688.11s - 690.11s | That's the amplitude. 690.11s - 692.11s | With light, that's how bright it is. 692.11s - 694.11s | Then there's the wavelength, 694.11s - 696.11s | which directly relates to frequency. 696.11s - 698.11s | So a low-frequency light would be red light. 698.11s - 700.11s | A high-frequency light would be blue light or UV light. 700.11s - 702.11s | With sound, low-frequency is bass. 702.11s - 704.11s | High-frequency is higher sounds. 704.11s - 706.11s | And there's phase,


chunk_id: 153_chunk_18
chunk_text:
664.11s - 666.11s | Now, when I say waves, light is a wave. 666.11s - 668.11s | Sound is a wave. 668.11s - 670.11s | Water waves are waves. 670.11s - 672.11s | They all have the same properties. 672.11s - 674.11s | They have absorption, where they absorb 674.11s - 676.11s | and convert from one type of energy to another energy. 676.11s - 678.11s | They have reflection. 678.11s - 680.11s | They have refraction and diffraction. 680.11s - 682.11s | A wave has three things. 682.11s - 684.11s | There's the amplitude. 684.11s - 686.11s | Amplitude means intensity. 686.11s - 688.11s | So the sound would be how loud it is. 688.11s - 690.11s | That's the amplitude. 690.11s - 692.11s | With light, that's how bright it is. 692.11s - 694.11s | Then there's the wavelength, 694.11s - 696.11s | which directly relates to frequency. 696.11s - 698.11s | So a low-frequency light would be red light. 698.11s - 700.11s | A high-frequency light would be blue light or UV light. 700.11s - 702.11s | With sound, low-frequency is bass. 702.11s - 704.11s | High-frequency is higher sounds. 704.11s - 706.11s | And there's phase, which is where something is 706.11s - 708.11s | in its amplitude 708.11s - 710.11s | because amplitude is moving up and down. 710.11s - 712.11s | When we're dealing with computers, 712.11s - 714.11s | we're digitizing things. 714.11s - 716.11s | We're quantizing, which just means 716.11s - 718.11s | our microphone, when I'm recording 718.11s - 720.11s | my Metallica CDs, 720.11s - 722.11s | or I'm backing up 722.11s - 724.11s | my Metallica audio, of course, 724.11s - 726.11s | I go into my microphone, let's say, 726.11s - 728.11s | and that has a sample rate. 728.11s - 730.11s | The sample rate is the number of times per second 730.11s - 732.11s | I record, or a frame rate. 732.11s - 734.11s | When you're taking a video, 734.11s - 736.11s | if it's 30 frames per second, that's a sample rate. 736.11s - 738.11s | If it's 30 hertz, 30 times per second. 738.11s - 740.11s | And the bit rate, that's the depth. 740.11s - 742.11s | So that's how much quality or resolution we have. 742.11s - 744.11s | And these are really important factors. 744.11s - 746.11s | Also,


chunk_id: 153_chunk_19
chunk_text:
which is where something is 706.11s - 708.11s | in its amplitude 708.11s - 710.11s | because amplitude is moving up and down. 710.11s - 712.11s | When we're dealing with computers, 712.11s - 714.11s | we're digitizing things. 714.11s - 716.11s | We're quantizing, which just means 716.11s - 718.11s | our microphone, when I'm recording 718.11s - 720.11s | my Metallica CDs, 720.11s - 722.11s | or I'm backing up 722.11s - 724.11s | my Metallica audio, of course, 724.11s - 726.11s | I go into my microphone, let's say, 726.11s - 728.11s | and that has a sample rate. 728.11s - 730.11s | The sample rate is the number of times per second 730.11s - 732.11s | I record, or a frame rate. 732.11s - 734.11s | When you're taking a video, 734.11s - 736.11s | if it's 30 frames per second, that's a sample rate. 736.11s - 738.11s | If it's 30 hertz, 30 times per second. 738.11s - 740.11s | And the bit rate, that's the depth. 740.11s - 742.11s | So that's how much quality or resolution we have. 742.11s - 744.11s | And these are really important factors. 744.11s - 746.11s | Also, waves can do 746.11s - 748.11s | very interesting things like interference. 748.11s - 750.11s | So with interference, we can 750.11s - 752.11s | do 752.11s - 754.11s | constructive and destructive interference. 754.11s - 756.11s | So your sound-canceling headphones, 756.11s - 758.11s | when you put those on, they have microphones 758.11s - 760.11s | on the outside, so that when you're listening 760.11s - 762.11s | to the Metallica that you ripped, 762.11s - 764.11s | you hear the 764.11s - 766.11s | outside sound, and the microphone 766.11s - 768.11s | takes that outside sound and it inverts the wave. 768.11s - 770.11s | And then it plays it along with Metallica. 770.11s - 772.11s | And those two cancel out. 772.11s - 774.11s | Just like a water wave, with a high peak, 774.11s - 776.11s | high amplitude, and a low amplitude. 776.11s - 778.11s | If they hit, they will cancel out. 778.11s - 780.11s | So that's destructive interference. 780.11s - 782.11s | There's many other places online and on the 782.11s - 784.11s | internet where you can get free tools 784.11s - 786.11s | to learn about physics, 786.11s


chunk_id: 153_chunk_20
chunk_text:
waves can do 746.11s - 748.11s | very interesting things like interference. 748.11s - 750.11s | So with interference, we can 750.11s - 752.11s | do 752.11s - 754.11s | constructive and destructive interference. 754.11s - 756.11s | So your sound-canceling headphones, 756.11s - 758.11s | when you put those on, they have microphones 758.11s - 760.11s | on the outside, so that when you're listening 760.11s - 762.11s | to the Metallica that you ripped, 762.11s - 764.11s | you hear the 764.11s - 766.11s | outside sound, and the microphone 766.11s - 768.11s | takes that outside sound and it inverts the wave. 768.11s - 770.11s | And then it plays it along with Metallica. 770.11s - 772.11s | And those two cancel out. 772.11s - 774.11s | Just like a water wave, with a high peak, 774.11s - 776.11s | high amplitude, and a low amplitude. 776.11s - 778.11s | If they hit, they will cancel out. 778.11s - 780.11s | So that's destructive interference. 780.11s - 782.11s | There's many other places online and on the 782.11s - 784.11s | internet where you can get free tools 784.11s - 786.11s | to learn about physics, 786.11s - 788.11s | such as Veritasium's 788.11s - 790.11s | channel. So Veritasium 790.11s - 792.11s | has amazing videos on physics, 792.11s - 794.11s | and there's so many interesting attacks 794.11s - 796.11s | that we can do with light. 796.11s - 798.11s | Here's Newton 798.11s - 800.11s | actually designing the cover for Pink Floyd's 800.11s - 802.11s | album, Dark Side of the Moon. 802.11s - 804.11s | I always thought that it was 804.11s - 806.11s | white light going to the prism and then refracting 806.11s - 808.11s | into the rainbow, but we're reverse engineers, 808.11s - 810.11s | so how do we know 810.11s - 812.11s | it's the white light going in versus the 812.11s - 814.11s | rainbow going to the prism and converting to white 814.11s - 816.11s | light? We don't really know. That's an interesting 816.11s - 818.11s | property of physics, is that physics, 818.11s - 820.11s | almost everything works in reverse 820.11s - 822.11s | as well. If you have a speaker, 822.11s - 824.11s | then you're playing sound through that speaker. 824.11s - 826.11s | If you have voltage going into


chunk_id: 153_chunk_21
chunk_text:
- 788.11s | such as Veritasium's 788.11s - 790.11s | channel. So Veritasium 790.11s - 792.11s | has amazing videos on physics, 792.11s - 794.11s | and there's so many interesting attacks 794.11s - 796.11s | that we can do with light. 796.11s - 798.11s | Here's Newton 798.11s - 800.11s | actually designing the cover for Pink Floyd's 800.11s - 802.11s | album, Dark Side of the Moon. 802.11s - 804.11s | I always thought that it was 804.11s - 806.11s | white light going to the prism and then refracting 806.11s - 808.11s | into the rainbow, but we're reverse engineers, 808.11s - 810.11s | so how do we know 810.11s - 812.11s | it's the white light going in versus the 812.11s - 814.11s | rainbow going to the prism and converting to white 814.11s - 816.11s | light? We don't really know. That's an interesting 816.11s - 818.11s | property of physics, is that physics, 818.11s - 820.11s | almost everything works in reverse 820.11s - 822.11s | as well. If you have a speaker, 822.11s - 824.11s | then you're playing sound through that speaker. 824.11s - 826.11s | If you have voltage going into the speaker, 826.11s - 828.11s | that's electrons 828.11s - 830.11s | moving through a coil. 830.11s - 832.11s | Any moving charged particle 832.11s - 834.11s | has a magnetic field. 834.11s - 836.11s | That magnetic field is pushing the speaker cone 836.11s - 838.11s | back and forth. That speaker cone 838.11s - 840.11s | is then pushing air back and forth. 840.11s - 842.11s | That's what the sound is. The sound is the movement 842.11s - 844.11s | of matter. 844.11s - 846.11s | The reverse is true as well. 846.11s - 848.11s | If you have a speaker, and you have 848.11s - 850.11s | air moving the speaker cone 850.11s - 852.11s | because the speaker's not on, then the speaker 852.11s - 854.11s | is also pushing 854.11s - 856.11s | electrons back and forth, which then 856.11s - 858.11s | produces a voltage in the coil. 858.11s - 860.11s | Every speaker is a microphone. 860.11s - 862.11s | Every microphone is also a speaker. 862.11s - 864.11s | There are really poor quality versions, but it's true. 864.11s - 866.11s | This is true with LEDs, for example. 866.11s -


chunk_id: 153_chunk_22
chunk_text:
the speaker, 826.11s - 828.11s | that's electrons 828.11s - 830.11s | moving through a coil. 830.11s - 832.11s | Any moving charged particle 832.11s - 834.11s | has a magnetic field. 834.11s - 836.11s | That magnetic field is pushing the speaker cone 836.11s - 838.11s | back and forth. That speaker cone 838.11s - 840.11s | is then pushing air back and forth. 840.11s - 842.11s | That's what the sound is. The sound is the movement 842.11s - 844.11s | of matter. 844.11s - 846.11s | The reverse is true as well. 846.11s - 848.11s | If you have a speaker, and you have 848.11s - 850.11s | air moving the speaker cone 850.11s - 852.11s | because the speaker's not on, then the speaker 852.11s - 854.11s | is also pushing 854.11s - 856.11s | electrons back and forth, which then 856.11s - 858.11s | produces a voltage in the coil. 858.11s - 860.11s | Every speaker is a microphone. 860.11s - 862.11s | Every microphone is also a speaker. 862.11s - 864.11s | There are really poor quality versions, but it's true. 864.11s - 866.11s | This is true with LEDs, for example. 866.11s - 868.11s | Every LED can shine light, 868.11s - 870.11s | but if you monitor the LED, 870.11s - 872.11s | you can actually have the light convert to voltage, 872.11s - 874.11s | and you can read light from an LED. 874.11s - 876.11s | Everything works in reverse. 876.11s - 878.11s | It's an important property. 878.11s - 880.11s | These are ways that we can take advantage of 880.11s - 882.11s | energy and energy conversion 882.11s - 884.11s | and the way that things actually work at a fundamental level. 884.11s - 886.11s | Here is a little bit of 886.11s - 888.11s | the electromagnetic spectrum. We can see the different 888.11s - 890.11s | colors, but it's also important to note 890.11s - 892.11s | that, again, things like UV and IR, those are 892.11s - 894.11s | light. Radio is also just another 894.11s - 896.11s | type of light. It's just light we can't see. 896.11s - 898.11s | It's colors we can't see. 898.11s - 900.11s | FM radio. FM radio 900.11s - 902.11s | is frequency modulation. 902.11s - 904.11s | When you tune into 102.7, 904.11s - 906.11s |


chunk_id: 153_chunk_23
chunk_text:
868.11s | Every LED can shine light, 868.11s - 870.11s | but if you monitor the LED, 870.11s - 872.11s | you can actually have the light convert to voltage, 872.11s - 874.11s | and you can read light from an LED. 874.11s - 876.11s | Everything works in reverse. 876.11s - 878.11s | It's an important property. 878.11s - 880.11s | These are ways that we can take advantage of 880.11s - 882.11s | energy and energy conversion 882.11s - 884.11s | and the way that things actually work at a fundamental level. 884.11s - 886.11s | Here is a little bit of 886.11s - 888.11s | the electromagnetic spectrum. We can see the different 888.11s - 890.11s | colors, but it's also important to note 890.11s - 892.11s | that, again, things like UV and IR, those are 892.11s - 894.11s | light. Radio is also just another 894.11s - 896.11s | type of light. It's just light we can't see. 896.11s - 898.11s | It's colors we can't see. 898.11s - 900.11s | FM radio. FM radio 900.11s - 902.11s | is frequency modulation. 902.11s - 904.11s | When you tune into 102.7, 904.11s - 906.11s | you're listening to 102.7 906.11s - 908.11s | megahertz on the electromagnetic 908.11s - 910.11s | spectrum. 910.11s - 912.11s | Now the frequency is modulating. 912.11s - 914.11s | All that means is when there's 914.11s - 916.11s | audio, if you have a 10 kilohertz tone, 916.11s - 918.11s | it's a high-pitched tone, 918.11s - 920.11s | that's 102.71. 920.11s - 922.11s | 102.7 922.11s - 924.11s | megahertz plus 10 kilohertz. 924.11s - 926.11s | Your frequency 926.11s - 928.11s | is actually just moving up and down at 10 kilohertz. 928.11s - 930.11s | You can think of an audio 930.11s - 932.11s | wave going like this. If we just flip it 932.11s - 934.11s | 90 degrees, then it's actually going 934.11s - 936.11s | like this, the frequency of the 936.11s - 938.11s | spectrum. Amplitude modulation, 938.11s - 940.11s | AM radio, when you listen to 98.7 940.11s - 942.11s | AM, that's 98.7 942.11s - 944.11s | kilohertz in the electromagnetic spectrum. 944.11s - 946.11s | The amplitude is going up and down 946.11s - 948.11s | to the sound. 948.11s - 950.11s | You can do some really cool


chunk_id: 153_chunk_24
chunk_text:
you're listening to 102.7 906.11s - 908.11s | megahertz on the electromagnetic 908.11s - 910.11s | spectrum. 910.11s - 912.11s | Now the frequency is modulating. 912.11s - 914.11s | All that means is when there's 914.11s - 916.11s | audio, if you have a 10 kilohertz tone, 916.11s - 918.11s | it's a high-pitched tone, 918.11s - 920.11s | that's 102.71. 920.11s - 922.11s | 102.7 922.11s - 924.11s | megahertz plus 10 kilohertz. 924.11s - 926.11s | Your frequency 926.11s - 928.11s | is actually just moving up and down at 10 kilohertz. 928.11s - 930.11s | You can think of an audio 930.11s - 932.11s | wave going like this. If we just flip it 932.11s - 934.11s | 90 degrees, then it's actually going 934.11s - 936.11s | like this, the frequency of the 936.11s - 938.11s | spectrum. Amplitude modulation, 938.11s - 940.11s | AM radio, when you listen to 98.7 940.11s - 942.11s | AM, that's 98.7 942.11s - 944.11s | kilohertz in the electromagnetic spectrum. 944.11s - 946.11s | The amplitude is going up and down 946.11s - 948.11s | to the sound. 948.11s - 950.11s | You can do some really cool things with light. There's the light 950.11s - 952.11s | commands research that people did where 952.11s - 954.11s | they found that if they shine a laser 954.11s - 956.11s | at something like a 956.11s - 958.11s | Google Home, they can 958.11s - 960.11s | say, hey Google, with light. 960.11s - 962.11s | They just modulate the light. 962.11s - 964.11s | They turn it on and off. Modulation 964.11s - 966.11s | just means turning on and off or oscillating. 966.11s - 968.11s | They turn it on and off to the frequency 968.11s - 970.11s | of sound. If they record 970.11s - 972.11s | their sound, hey Google, 972.11s - 974.11s | unlock my door, and they 974.11s - 976.11s | turn that light, that light hitting the 976.11s - 978.11s | microphone is heating up. It's absorbing 978.11s - 980.11s | inside of the microphone, the MEMS microphone, 980.11s - 982.11s | and that produces heat. Heat 982.11s - 984.11s | is vibration of particles. 984.11s - 986.11s | That microphone then believes that it's hearing 986.11s - 988.11s | sound. That means you can shine 988.11s - 990.11s | through a


chunk_id: 153_chunk_25
chunk_text:
things with light. There's the light 950.11s - 952.11s | commands research that people did where 952.11s - 954.11s | they found that if they shine a laser 954.11s - 956.11s | at something like a 956.11s - 958.11s | Google Home, they can 958.11s - 960.11s | say, hey Google, with light. 960.11s - 962.11s | They just modulate the light. 962.11s - 964.11s | They turn it on and off. Modulation 964.11s - 966.11s | just means turning on and off or oscillating. 966.11s - 968.11s | They turn it on and off to the frequency 968.11s - 970.11s | of sound. If they record 970.11s - 972.11s | their sound, hey Google, 972.11s - 974.11s | unlock my door, and they 974.11s - 976.11s | turn that light, that light hitting the 976.11s - 978.11s | microphone is heating up. It's absorbing 978.11s - 980.11s | inside of the microphone, the MEMS microphone, 980.11s - 982.11s | and that produces heat. Heat 982.11s - 984.11s | is vibration of particles. 984.11s - 986.11s | That microphone then believes that it's hearing 986.11s - 988.11s | sound. That means you can shine 988.11s - 990.11s | through a window and trigger 990.11s - 992.11s | the Google Home to do things for you. 992.11s - 994.11s | There's also infrared light. 994.11s - 996.11s | This is a Mark Rober did a 996.11s - 998.11s | video showing just a thermal camera 998.11s - 1000.11s | where he then pressed a pin 1000.11s - 1002.11s | and heat is constantly transferring. 1002.11s - 1004.11s | Just by touching these 1004.11s - 1006.11s | buttons, heat from his finger goes to the 1006.11s - 1008.11s | button and then leaves a mark. We don't 1008.11s - 1010.11s | see it with our eyes, but with a thermal camera like a 1010.11s - 1012.11s | FLIR camera, you can do that. Ultraviolet. 1012.11s - 1014.11s | Ultra from Latin 1014.11s - 1016.11s | meaning beyond, on the far side of. 1016.11s - 1018.11s | On the far side of the visible spectrum. 1018.11s - 1020.11s | Bunny did an amazing example with 1020.11s - 1022.11s | ultraviolet light where he took a PIC 1022.11s - 1024.11s | microcontroller that had firmware that he wanted to extract. 1024.11s - 1026.11s | But the PIC microcontroller had 1026.11s - 1028.11s | an


chunk_id: 153_chunk_26
chunk_text:
window and trigger 990.11s - 992.11s | the Google Home to do things for you. 992.11s - 994.11s | There's also infrared light. 994.11s - 996.11s | This is a Mark Rober did a 996.11s - 998.11s | video showing just a thermal camera 998.11s - 1000.11s | where he then pressed a pin 1000.11s - 1002.11s | and heat is constantly transferring. 1002.11s - 1004.11s | Just by touching these 1004.11s - 1006.11s | buttons, heat from his finger goes to the 1006.11s - 1008.11s | button and then leaves a mark. We don't 1008.11s - 1010.11s | see it with our eyes, but with a thermal camera like a 1010.11s - 1012.11s | FLIR camera, you can do that. Ultraviolet. 1012.11s - 1014.11s | Ultra from Latin 1014.11s - 1016.11s | meaning beyond, on the far side of. 1016.11s - 1018.11s | On the far side of the visible spectrum. 1018.11s - 1020.11s | Bunny did an amazing example with 1020.11s - 1022.11s | ultraviolet light where he took a PIC 1022.11s - 1024.11s | microcontroller that had firmware that he wanted to extract. 1024.11s - 1026.11s | But the PIC microcontroller had 1026.11s - 1028.11s | an E-fuse, an electronic fuse that said 1028.11s - 1030.11s | do not allow anyone to debug and access 1030.11s - 1032.11s | memory from this. And he opened it up, 1032.11s - 1034.11s | he used nitric acid, sulfuric acid 1034.11s - 1036.11s | to get to the silicon. 1036.11s - 1038.11s | He covered up the area other than 1038.11s - 1040.11s | the electronic fuses and then he shined 1040.11s - 1042.11s | UV light which erased it. 1042.11s - 1044.11s | That's how programmable read-only memory used to work. 1044.11s - 1046.11s | We would shine UV light to erase it 1046.11s - 1048.11s | and then we could program it. 1048.11s - 1050.11s | Then there's radio, which again 1050.11s - 1052.11s | is just another part of the spectrum. We talked about FM 1052.11s - 1054.11s | a little bit. We talked about AM. 1054.11s - 1056.11s | We're all familiar with, say, 2.4 GHz Wi-Fi 1056.11s - 1058.11s | or Bluetooth. 5 GHz 1058.11s - 1060.11s | Wi-Fi. Our microwaves, the microwave 1060.11s - 1062.11s | that you make popcorn at home, that's 1062.11s - 1064.11s | actually 2.4 GHz. Microwaves 1064.11s - 1066.11s


chunk_id: 153_chunk_27
chunk_text:
E-fuse, an electronic fuse that said 1028.11s - 1030.11s | do not allow anyone to debug and access 1030.11s - 1032.11s | memory from this. And he opened it up, 1032.11s - 1034.11s | he used nitric acid, sulfuric acid 1034.11s - 1036.11s | to get to the silicon. 1036.11s - 1038.11s | He covered up the area other than 1038.11s - 1040.11s | the electronic fuses and then he shined 1040.11s - 1042.11s | UV light which erased it. 1042.11s - 1044.11s | That's how programmable read-only memory used to work. 1044.11s - 1046.11s | We would shine UV light to erase it 1046.11s - 1048.11s | and then we could program it. 1048.11s - 1050.11s | Then there's radio, which again 1050.11s - 1052.11s | is just another part of the spectrum. We talked about FM 1052.11s - 1054.11s | a little bit. We talked about AM. 1054.11s - 1056.11s | We're all familiar with, say, 2.4 GHz Wi-Fi 1056.11s - 1058.11s | or Bluetooth. 5 GHz 1058.11s - 1060.11s | Wi-Fi. Our microwaves, the microwave 1060.11s - 1062.11s | that you make popcorn at home, that's 1062.11s - 1064.11s | actually 2.4 GHz. Microwaves 1064.11s - 1066.11s | and radio are the same exact thing. 1066.11s - 1068.11s | There's the Tempest attack. 1068.11s - 1070.11s | The NSA found in the 60s, 1070.11s - 1072.11s | they knew that a CRT monitor, a cathode 1072.11s - 1074.11s | ray tube, would constantly 1074.11s - 1076.11s | emit radio frequency. 1076.11s - 1078.11s | That radio frequency, 1078.11s - 1080.11s | they could hear in an adjacent room. 1080.11s - 1082.11s | They could essentially listen 1082.11s - 1084.11s | to the radio frequency and see what's on the monitor. 1084.11s - 1086.11s | There are modern attacks like this 1086.11s - 1088.11s | today that are happening. 1088.11s - 1090.11s | We talked a little bit about the AM and FM. 1090.11s - 1092.11s | Then electromagnetism. 1092.11s - 1094.11s | Electro from amber. 1094.11s - 1096.11s | The Greeks found that when you rub amber 1096.11s - 1098.11s | with something like fur, 1098.11s - 1100.11s | they would attract or repel. 1100.11s - 1102.11s | And magnetism 1102.11s - 1104.11s | from magnesium stone. Because there's a 1104.11s - 1106.11s | place called Magnesia where they found stone 1106.11s - 1108.11s | and the


chunk_id: 153_chunk_28
chunk_text:
| and radio are the same exact thing. 1066.11s - 1068.11s | There's the Tempest attack. 1068.11s - 1070.11s | The NSA found in the 60s, 1070.11s - 1072.11s | they knew that a CRT monitor, a cathode 1072.11s - 1074.11s | ray tube, would constantly 1074.11s - 1076.11s | emit radio frequency. 1076.11s - 1078.11s | That radio frequency, 1078.11s - 1080.11s | they could hear in an adjacent room. 1080.11s - 1082.11s | They could essentially listen 1082.11s - 1084.11s | to the radio frequency and see what's on the monitor. 1084.11s - 1086.11s | There are modern attacks like this 1086.11s - 1088.11s | today that are happening. 1088.11s - 1090.11s | We talked a little bit about the AM and FM. 1090.11s - 1092.11s | Then electromagnetism. 1092.11s - 1094.11s | Electro from amber. 1094.11s - 1096.11s | The Greeks found that when you rub amber 1096.11s - 1098.11s | with something like fur, 1098.11s - 1100.11s | they would attract or repel. 1100.11s - 1102.11s | And magnetism 1102.11s - 1104.11s | from magnesium stone. Because there's a 1104.11s - 1106.11s | place called Magnesia where they found stone 1106.11s - 1108.11s | and the stone was attracted to other magnesium 1108.11s - 1110.11s | stones, we realized later, as magnetism. 1110.11s - 1112.11s | This was an example project 1112.11s - 1114.11s | a few years ago called MagSpoop. 1114.11s - 1116.11s | I was interested in how the mag stripes actually work 1116.11s - 1118.11s | within our credit cards. 1118.11s - 1120.11s | And I put 1120.11s - 1122.11s | my credit card inside of iron oxide 1122.11s - 1124.11s | filings. And you can 1124.11s - 1126.11s | actually read the ones and zeros off of my 1126.11s - 1128.11s | credit card. I'm not even sure why I put the 1128.11s - 1130.11s | electrical tape, because you can just read the credit card 1130.11s - 1132.11s | number off the bits at the top. 1132.11s - 1134.11s | I thought, what are all these numbers? 1134.11s - 1136.11s | It's a credit card number. There's a CVV. 1136.11s - 1138.11s | There's actually a separate CVV. There's a written one 1138.11s - 1140.11s | and there's one in the mag stripe. Now we think, 1140.11s - 1142.11s | who uses mag stripes? We all use chip or 1142.11s -


chunk_id: 153_chunk_29
chunk_text:
stone was attracted to other magnesium 1108.11s - 1110.11s | stones, we realized later, as magnetism. 1110.11s - 1112.11s | This was an example project 1112.11s - 1114.11s | a few years ago called MagSpoop. 1114.11s - 1116.11s | I was interested in how the mag stripes actually work 1116.11s - 1118.11s | within our credit cards. 1118.11s - 1120.11s | And I put 1120.11s - 1122.11s | my credit card inside of iron oxide 1122.11s - 1124.11s | filings. And you can 1124.11s - 1126.11s | actually read the ones and zeros off of my 1126.11s - 1128.11s | credit card. I'm not even sure why I put the 1128.11s - 1130.11s | electrical tape, because you can just read the credit card 1130.11s - 1132.11s | number off the bits at the top. 1132.11s - 1134.11s | I thought, what are all these numbers? 1134.11s - 1136.11s | It's a credit card number. There's a CVV. 1136.11s - 1138.11s | There's actually a separate CVV. There's a written one 1138.11s - 1140.11s | and there's one in the mag stripe. Now we think, 1140.11s - 1142.11s | who uses mag stripes? We all use chip or 1142.11s - 1144.11s | NFC. But have you ever put your 1144.11s - 1146.11s | credit card in a mag stripe machine? 1146.11s - 1148.11s | It's like, hey, this is a chip card. 1148.11s - 1150.11s | How does it know that it's a chip card? 1150.11s - 1152.11s | The mag stripe tells it. The mag stripe 1152.11s - 1154.11s | says, no, this is a chip card. You need higher security. 1154.11s - 1156.11s | So what happens if you turn that one to a 1156.11s - 1158.11s | zero and say, no, no, no, there's no chip on here. 1158.11s - 1160.11s | There's no NFC. 1160.11s - 1162.11s | This is the device. 1162.11s - 1164.11s | This is the MagSmooth device, and it just 1164.11s - 1166.11s | produces a magnetic field. 1166.11s - 1168.11s | And if you 1168.11s - 1170.11s | turn, I use the chip card, I put 1170.11s - 1172.11s | the mag stripe data onto this 1172.11s - 1174.11s | and was then able to 1174.11s - 1176.11s | make transactions without the chip. 1176.11s - 1178.11s | So if you just have access 1178.11s - 1180.11s | to a mag


chunk_id: 153_chunk_30
chunk_text:
1144.11s | NFC. But have you ever put your 1144.11s - 1146.11s | credit card in a mag stripe machine? 1146.11s - 1148.11s | It's like, hey, this is a chip card. 1148.11s - 1150.11s | How does it know that it's a chip card? 1150.11s - 1152.11s | The mag stripe tells it. The mag stripe 1152.11s - 1154.11s | says, no, this is a chip card. You need higher security. 1154.11s - 1156.11s | So what happens if you turn that one to a 1156.11s - 1158.11s | zero and say, no, no, no, there's no chip on here. 1158.11s - 1160.11s | There's no NFC. 1160.11s - 1162.11s | This is the device. 1162.11s - 1164.11s | This is the MagSmooth device, and it just 1164.11s - 1166.11s | produces a magnetic field. 1166.11s - 1168.11s | And if you 1168.11s - 1170.11s | turn, I use the chip card, I put 1170.11s - 1172.11s | the mag stripe data onto this 1172.11s - 1174.11s | and was then able to 1174.11s - 1176.11s | make transactions without the chip. 1176.11s - 1178.11s | So if you just have access 1178.11s - 1180.11s | to a mag stripe temporarily, you can then convert 1180.11s - 1182.11s | the chip to a non-chip card. 1182.11s - 1184.11s | There are some other interesting attacks. 1184.11s - 1186.11s | There's sound. 1186.11s - 1188.11s | There's so many interesting things that we can do with sound. 1188.11s - 1190.11s | There's audible sound, which is what humans can hear. 1190.11s - 1192.11s | We can hear 20 to 20 kilohertz. 1192.11s - 1194.11s | I'm a little older. 1194.11s - 1196.11s | I can maybe hear to 15 kilohertz. 1196.11s - 1198.11s | If you listen to a lot of music, 1198.11s - 1200.11s | you probably hear less. 1200.11s - 1202.11s | Berkeley had some amazing research where they used 1202.11s - 1204.11s | a microphone to listen to 1204.11s - 1206.11s | the sound from a keyboard. 1206.11s - 1208.11s | And there's a lot of research that I was able to 1208.11s - 1210.11s | fortunately take advantage of 1210.11s - 1212.11s | in using other people's tools and research 1212.11s - 1214.11s | to learn how can I understand 1214.11s - 1216.11s | what's happening on a keyboard. 1216.11s - 1218.11s | There's something really


chunk_id: 153_chunk_31
chunk_text:
stripe temporarily, you can then convert 1180.11s - 1182.11s | the chip to a non-chip card. 1182.11s - 1184.11s | There are some other interesting attacks. 1184.11s - 1186.11s | There's sound. 1186.11s - 1188.11s | There's so many interesting things that we can do with sound. 1188.11s - 1190.11s | There's audible sound, which is what humans can hear. 1190.11s - 1192.11s | We can hear 20 to 20 kilohertz. 1192.11s - 1194.11s | I'm a little older. 1194.11s - 1196.11s | I can maybe hear to 15 kilohertz. 1196.11s - 1198.11s | If you listen to a lot of music, 1198.11s - 1200.11s | you probably hear less. 1200.11s - 1202.11s | Berkeley had some amazing research where they used 1202.11s - 1204.11s | a microphone to listen to 1204.11s - 1206.11s | the sound from a keyboard. 1206.11s - 1208.11s | And there's a lot of research that I was able to 1208.11s - 1210.11s | fortunately take advantage of 1210.11s - 1212.11s | in using other people's tools and research 1212.11s - 1214.11s | to learn how can I understand 1214.11s - 1216.11s | what's happening on a keyboard. 1216.11s - 1218.11s | There's something really interesting about all the information 1218.11s - 1220.11s | that we are constantly inputting. 1220.11s - 1222.11s | Maybe that's because I'm on a computer every single day typing. 1222.11s - 1224.11s | I think it's cool to know that 1224.11s - 1226.11s | what am I typing? What can someone figure out 1226.11s - 1228.11s | what someone else is typing? 1228.11s - 1230.11s | And they were able to just 1230.11s - 1232.11s | have a microphone listen to what the sound 1232.11s - 1234.11s | your computer is making and convert that back. 1234.11s - 1236.11s | Two keys. 1236.11s - 1238.11s | Ultrasound. Again, 1238.11s - 1240.11s | ultra on the far side of. 1240.11s - 1242.11s | The University of Tel Aviv 1242.11s - 1244.11s | had some awesome research where they were using 1244.11s - 1246.11s | a microphone from a standard 1246.11s - 1248.11s | cell phone and they would listen to 1248.11s - 1250.11s | the ultrasound coming from your computer. 1250.11s - 1252.11s | As your computer is performing encryption operation, 1252.11s - 1254.11s | let's say it's using RSA. 1254.11s - 1256.11s | RSA, if you're encrypting a 1-bit versus


chunk_id: 153_chunk_32
chunk_text:
interesting about all the information 1218.11s - 1220.11s | that we are constantly inputting. 1220.11s - 1222.11s | Maybe that's because I'm on a computer every single day typing. 1222.11s - 1224.11s | I think it's cool to know that 1224.11s - 1226.11s | what am I typing? What can someone figure out 1226.11s - 1228.11s | what someone else is typing? 1228.11s - 1230.11s | And they were able to just 1230.11s - 1232.11s | have a microphone listen to what the sound 1232.11s - 1234.11s | your computer is making and convert that back. 1234.11s - 1236.11s | Two keys. 1236.11s - 1238.11s | Ultrasound. Again, 1238.11s - 1240.11s | ultra on the far side of. 1240.11s - 1242.11s | The University of Tel Aviv 1242.11s - 1244.11s | had some awesome research where they were using 1244.11s - 1246.11s | a microphone from a standard 1246.11s - 1248.11s | cell phone and they would listen to 1248.11s - 1250.11s | the ultrasound coming from your computer. 1250.11s - 1252.11s | As your computer is performing encryption operation, 1252.11s - 1254.11s | let's say it's using RSA. 1254.11s - 1256.11s | RSA, if you're encrypting a 1-bit versus 0-bit, 1256.11s - 1258.11s | it takes different operations. It might do a 1258.11s - 1260.11s | multiplication followed by a modular or an exponent 1260.11s - 1262.11s | followed by a modular versus a multiplication. 1262.11s - 1264.11s | And because of those different operations 1264.11s - 1266.11s | take different amounts of power, that's different amounts 1266.11s - 1268.11s | of power going through capacitors 1268.11s - 1270.11s | and inductors of the CPU. 1270.11s - 1272.11s | Those capacitors and inductors are producing 1272.11s - 1274.11s | all these charged particles, 1274.11s - 1276.11s | all these electrons moving, it's producing magnetism. 1276.11s - 1278.11s | That magnetism is then moving things 1278.11s - 1280.11s | on your CPU. So these actual 1280.11s - 1282.11s | caps are moving within 1282.11s - 1284.11s | your CPU and they're producing ultrasound 1284.11s - 1286.11s | because they're moving at a frequency 1286.11s - 1288.11s | higher than we can hear, above 20 kHz. 1288.11s - 1290.11s | So if you can hear that with a microphone 1290.11s - 1292.11s | in a lab environment, then you can 1292.11s - 1294.11s | convert that back to 1s and 0s


chunk_id: 153_chunk_33
chunk_text:
0-bit, 1256.11s - 1258.11s | it takes different operations. It might do a 1258.11s - 1260.11s | multiplication followed by a modular or an exponent 1260.11s - 1262.11s | followed by a modular versus a multiplication. 1262.11s - 1264.11s | And because of those different operations 1264.11s - 1266.11s | take different amounts of power, that's different amounts 1266.11s - 1268.11s | of power going through capacitors 1268.11s - 1270.11s | and inductors of the CPU. 1270.11s - 1272.11s | Those capacitors and inductors are producing 1272.11s - 1274.11s | all these charged particles, 1274.11s - 1276.11s | all these electrons moving, it's producing magnetism. 1276.11s - 1278.11s | That magnetism is then moving things 1278.11s - 1280.11s | on your CPU. So these actual 1280.11s - 1282.11s | caps are moving within 1282.11s - 1284.11s | your CPU and they're producing ultrasound 1284.11s - 1286.11s | because they're moving at a frequency 1286.11s - 1288.11s | higher than we can hear, above 20 kHz. 1288.11s - 1290.11s | So if you can hear that with a microphone 1290.11s - 1292.11s | in a lab environment, then you can 1292.11s - 1294.11s | convert that back to 1s and 0s and extract 1294.11s - 1296.11s | secret keys. Pretty amazing 1296.11s - 1298.11s | stuff. All of this is really just 1298.11s - 1300.11s | energy conversion. Everything that's happening 1300.11s - 1302.11s | is a conversion of energy 1302.11s - 1304.11s | and that's really interesting. 1304.11s - 1306.11s | So how can we take advantage of energy conversion? 1306.11s - 1310.32s | And I started to get interested 1310.32s - 1312.32s | in laser microphones. 1312.32s - 1314.32s | So I saw a talk 15 years ago here 1314.32s - 1316.32s | at DEF CON and it was 1316.32s - 1318.32s | incredible. It was about 1318.32s - 1320.32s | how to use a laser microphone. 1320.32s - 1322.32s | The first laser microphone, not really 1322.32s - 1324.32s | a laser microphone, was really 1324.32s - 1326.32s | a microphone that was, let's say, 1326.32s - 1328.32s | passive. 1328.32s - 1330.32s | It was from Leon Theremin. 1330.32s - 1332.32s | If you're familiar with the Theremin instrument, 1332.32s - 1334.32s | Leon Theremin 1334.32s - 1336.32s | created this Theremin instrument. He was an engineer 1336.32s - 1338.32s | and physicist. He also created something


chunk_id: 153_chunk_34
chunk_text:
and extract 1294.11s - 1296.11s | secret keys. Pretty amazing 1296.11s - 1298.11s | stuff. All of this is really just 1298.11s - 1300.11s | energy conversion. Everything that's happening 1300.11s - 1302.11s | is a conversion of energy 1302.11s - 1304.11s | and that's really interesting. 1304.11s - 1306.11s | So how can we take advantage of energy conversion? 1306.11s - 1310.32s | And I started to get interested 1310.32s - 1312.32s | in laser microphones. 1312.32s - 1314.32s | So I saw a talk 15 years ago here 1314.32s - 1316.32s | at DEF CON and it was 1316.32s - 1318.32s | incredible. It was about 1318.32s - 1320.32s | how to use a laser microphone. 1320.32s - 1322.32s | The first laser microphone, not really 1322.32s - 1324.32s | a laser microphone, was really 1324.32s - 1326.32s | a microphone that was, let's say, 1326.32s - 1328.32s | passive. 1328.32s - 1330.32s | It was from Leon Theremin. 1330.32s - 1332.32s | If you're familiar with the Theremin instrument, 1332.32s - 1334.32s | Leon Theremin 1334.32s - 1336.32s | created this Theremin instrument. He was an engineer 1336.32s - 1338.32s | and physicist. He also created something called 1338.32s - 1340.32s | The Thing. 1340.32s - 1342.32s | And he gave this to our friends at the KGB. 1342.32s - 1344.32s | And The Thing was a passive 1344.32s - 1346.32s | device. Many of us are familiar 1346.32s - 1348.32s | with RFID devices. They're passive cards 1348.32s - 1350.32s | and they go into a field, 1350.32s - 1352.32s | an RFID field from, say, a reader. 1352.32s - 1354.32s | And that reader emanates radio. 1354.32s - 1356.32s | And that energizes the card. The card now has 1356.32s - 1358.32s | enough power that it can run a little processor 1358.32s - 1360.32s | and respond. Once it gets back, 1360.32s - 1362.32s | this was the first implementation of RFID. 1362.32s - 1364.32s | And instead of a card 1364.32s - 1366.32s | with an ID, he put in 1366.32s - 1368.32s | a microphone. And that microphone 1368.32s - 1370.32s | then went into a seal. And this 1370.32s - 1372.32s | was a gift that the Soviet Union 1372.32s - 1374.32s | gave to the U.S. ambassador in 1374.32s - 1376.32s | 1945. 1376.32s - 1378.32s | They put that.


chunk_id: 153_chunk_35
chunk_text:
called 1338.32s - 1340.32s | The Thing. 1340.32s - 1342.32s | And he gave this to our friends at the KGB. 1342.32s - 1344.32s | And The Thing was a passive 1344.32s - 1346.32s | device. Many of us are familiar 1346.32s - 1348.32s | with RFID devices. They're passive cards 1348.32s - 1350.32s | and they go into a field, 1350.32s - 1352.32s | an RFID field from, say, a reader. 1352.32s - 1354.32s | And that reader emanates radio. 1354.32s - 1356.32s | And that energizes the card. The card now has 1356.32s - 1358.32s | enough power that it can run a little processor 1358.32s - 1360.32s | and respond. Once it gets back, 1360.32s - 1362.32s | this was the first implementation of RFID. 1362.32s - 1364.32s | And instead of a card 1364.32s - 1366.32s | with an ID, he put in 1366.32s - 1368.32s | a microphone. And that microphone 1368.32s - 1370.32s | then went into a seal. And this 1370.32s - 1372.32s | was a gift that the Soviet Union 1372.32s - 1374.32s | gave to the U.S. ambassador in 1374.32s - 1376.32s | 1945. 1376.32s - 1378.32s | They put that. No battery, 1378.32s - 1380.32s | right? No battery at all. 1380.32s - 1382.32s | Because Leon Theremin realized 1382.32s - 1384.32s | that he could passively power things. 1384.32s - 1386.32s | He could power things from far and then get 1386.32s - 1388.32s | information back. 1388.32s - 1390.32s | It was many years before the U.S. 1390.32s - 1392.32s | realized that there was a microphone. 1392.32s - 1394.32s | Whenever that they were being powered from the outside, 1394.32s - 1396.32s | they could get audio back. 1396.32s - 1398.32s | Now, laser microphones is 1398.32s - 1400.32s | a way of using light in order 1400.32s - 1402.32s | to listen to sound. 1402.32s - 1404.32s | So if I can shine a light at a window, 1404.32s - 1406.32s | and the window, now sound. 1406.32s - 1408.32s | Sound is the vibration 1408.32s - 1410.32s | of matter. Typically air, right? 1410.32s - 1412.32s | You can have sound go through 1412.32s - 1414.32s | solid materials. 1414.32s - 1416.32s | You can have sound go through water, liquids. 1416.32s - 1418.32s | And you don't actually need a laser. 1418.32s - 1420.32s


chunk_id: 153_chunk_36
chunk_text:
No battery, 1378.32s - 1380.32s | right? No battery at all. 1380.32s - 1382.32s | Because Leon Theremin realized 1382.32s - 1384.32s | that he could passively power things. 1384.32s - 1386.32s | He could power things from far and then get 1386.32s - 1388.32s | information back. 1388.32s - 1390.32s | It was many years before the U.S. 1390.32s - 1392.32s | realized that there was a microphone. 1392.32s - 1394.32s | Whenever that they were being powered from the outside, 1394.32s - 1396.32s | they could get audio back. 1396.32s - 1398.32s | Now, laser microphones is 1398.32s - 1400.32s | a way of using light in order 1400.32s - 1402.32s | to listen to sound. 1402.32s - 1404.32s | So if I can shine a light at a window, 1404.32s - 1406.32s | and the window, now sound. 1406.32s - 1408.32s | Sound is the vibration 1408.32s - 1410.32s | of matter. Typically air, right? 1410.32s - 1412.32s | You can have sound go through 1412.32s - 1414.32s | solid materials. 1414.32s - 1416.32s | You can have sound go through water, liquids. 1416.32s - 1418.32s | And you don't actually need a laser. 1418.32s - 1420.32s | You just need light. 1420.32s - 1422.32s | And the light can be visible or invisible, 1422.32s - 1424.32s | as long as we have a way to receive it. 1424.32s - 1426.32s | So it was this talk, 1426.32s - 1428.32s | Sniffing Keystrokes with Lasers and Voltmeters, 1428.32s - 1430.32s | by Andrea Barassani and 1430.32s - 1432.32s | Danielle Bianco, 1432.32s - 1434.32s | at DEFCON 17. 1434.32s - 1436.32s | And this really blew my mind. 1436.32s - 1438.32s | What they were able to do was they were able to 1438.32s - 1440.32s | get laser at a reflective part 1440.32s - 1442.32s | of a laptop within a room, 1442.32s - 1444.32s | and then pick up the reflection 1444.32s - 1446.32s | on a photodiode 1446.32s - 1448.32s | or photoresistor. And they picked it up, 1448.32s - 1450.32s | they plugged that into their sound card, 1450.32s - 1452.32s | and they were able to listen to the keystrokes. 1452.32s - 1454.32s | Now, it took a lot of work. 1454.32s - 1456.32s | Definitely a proof of concept, 1456.32s - 1458.32s | but absolutely incredible. 1458.32s - 1460.32s | And


chunk_id: 153_chunk_37
chunk_text:
| You just need light. 1420.32s - 1422.32s | And the light can be visible or invisible, 1422.32s - 1424.32s | as long as we have a way to receive it. 1424.32s - 1426.32s | So it was this talk, 1426.32s - 1428.32s | Sniffing Keystrokes with Lasers and Voltmeters, 1428.32s - 1430.32s | by Andrea Barassani and 1430.32s - 1432.32s | Danielle Bianco, 1432.32s - 1434.32s | at DEFCON 17. 1434.32s - 1436.32s | And this really blew my mind. 1436.32s - 1438.32s | What they were able to do was they were able to 1438.32s - 1440.32s | get laser at a reflective part 1440.32s - 1442.32s | of a laptop within a room, 1442.32s - 1444.32s | and then pick up the reflection 1444.32s - 1446.32s | on a photodiode 1446.32s - 1448.32s | or photoresistor. And they picked it up, 1448.32s - 1450.32s | they plugged that into their sound card, 1450.32s - 1452.32s | and they were able to listen to the keystrokes. 1452.32s - 1454.32s | Now, it took a lot of work. 1454.32s - 1456.32s | Definitely a proof of concept, 1456.32s - 1458.32s | but absolutely incredible. 1458.32s - 1460.32s | And I've always been interested in these keyboards. 1460.32s - 1462.32s | A few years ago, I had released a project called 1462.32s - 1464.32s | Keysweeper. Keysweeper is just 1464.32s - 1466.32s | an Arduino-based device 1466.32s - 1468.32s | that's inside of a USB charger. 1468.32s - 1470.32s | You plug the USB charger into the wall, 1470.32s - 1472.32s | and it's just sniffing every Microsoft wireless keyboard 1472.32s - 1474.32s | in the vicinity. It also has a GSM chip, 1474.32s - 1476.32s | so it's actually connected to a cell phone network. 1476.32s - 1478.32s | It has a battery inside, so if it gets pulled out, 1478.32s - 1480.32s | it continues to operate. And then you can 1480.32s - 1482.32s | inject keystrokes, and you can listen to all 1482.32s - 1484.32s | keyboards in the vicinity. 1484.32s - 1486.32s | Fortunately, the FBI released a notice to the 1486.32s - 1488.32s | industry saying, watch out for these Keysweeper devices. 1488.32s - 1490.32s | And I read that someone sent that 1490.32s - 1492.32s | to me, and I read it said, 1492.32s - 1494.32s | limit which outlets are available for device


chunk_id: 153_chunk_38
chunk_text:
I've always been interested in these keyboards. 1460.32s - 1462.32s | A few years ago, I had released a project called 1462.32s - 1464.32s | Keysweeper. Keysweeper is just 1464.32s - 1466.32s | an Arduino-based device 1466.32s - 1468.32s | that's inside of a USB charger. 1468.32s - 1470.32s | You plug the USB charger into the wall, 1470.32s - 1472.32s | and it's just sniffing every Microsoft wireless keyboard 1472.32s - 1474.32s | in the vicinity. It also has a GSM chip, 1474.32s - 1476.32s | so it's actually connected to a cell phone network. 1476.32s - 1478.32s | It has a battery inside, so if it gets pulled out, 1478.32s - 1480.32s | it continues to operate. And then you can 1480.32s - 1482.32s | inject keystrokes, and you can listen to all 1482.32s - 1484.32s | keyboards in the vicinity. 1484.32s - 1486.32s | Fortunately, the FBI released a notice to the 1486.32s - 1488.32s | industry saying, watch out for these Keysweeper devices. 1488.32s - 1490.32s | And I read that someone sent that 1490.32s - 1492.32s | to me, and I read it said, 1492.32s - 1494.32s | limit which outlets are available for device charging. 1494.32s - 1496.32s | Some suggestions just for all of us. 1496.32s - 1498.32s | Know which chargers are 1498.32s - 1500.32s | currently being used. Immediately 1500.32s - 1502.32s | remove unknown chargers 1502.32s - 1504.32s | whenever you see them. I don't think 1504.32s - 1506.32s | they realize that it's really just the circuitry 1506.32s - 1508.32s | inside the charger. The charger was just to be clandestine. 1508.32s - 1510.32s | So you could put it 1510.32s - 1512.32s | in a banana, at which point you would 1512.32s - 1514.32s | have to limit which bananas are available for device. 1514.32s - 1516.32s | You have to know whose bananas are 1516.32s - 1518.32s | currently being used, and immediate removal of 1518.32s - 1520.32s | any unknown bananas from the 1520.32s - 1522.32s | office. So beware of bananas and USB 1522.32s - 1524.32s | chargers. But keystrokes. 1524.32s - 1526.32s | So these guys demonstrated 1526.32s - 1528.32s | the components that they used. 1528.32s - 1530.32s | Common laser, like off-the-shelf laser, 1530.32s - 1532.32s | resistor, or battery. 1532.32s - 1534.32s | And this was their schematic. 1534.32s - 1536.32s


chunk_id: 153_chunk_39
chunk_text:
charging. 1494.32s - 1496.32s | Some suggestions just for all of us. 1496.32s - 1498.32s | Know which chargers are 1498.32s - 1500.32s | currently being used. Immediately 1500.32s - 1502.32s | remove unknown chargers 1502.32s - 1504.32s | whenever you see them. I don't think 1504.32s - 1506.32s | they realize that it's really just the circuitry 1506.32s - 1508.32s | inside the charger. The charger was just to be clandestine. 1508.32s - 1510.32s | So you could put it 1510.32s - 1512.32s | in a banana, at which point you would 1512.32s - 1514.32s | have to limit which bananas are available for device. 1514.32s - 1516.32s | You have to know whose bananas are 1516.32s - 1518.32s | currently being used, and immediate removal of 1518.32s - 1520.32s | any unknown bananas from the 1520.32s - 1522.32s | office. So beware of bananas and USB 1522.32s - 1524.32s | chargers. But keystrokes. 1524.32s - 1526.32s | So these guys demonstrated 1526.32s - 1528.32s | the components that they used. 1528.32s - 1530.32s | Common laser, like off-the-shelf laser, 1530.32s - 1532.32s | resistor, or battery. 1532.32s - 1534.32s | And this was their schematic. 1534.32s - 1536.32s | So what they did was, they had the laser 1536.32s - 1538.32s | hit a laptop, 1538.32s - 1540.32s | it would reflect off the laptop, and 1540.32s - 1542.32s | then it would go into a photodiode 1542.32s - 1544.32s | or photoresistor. They would power that, 1544.32s - 1546.32s | and they would go into the microphone. And the reason for the microphone 1546.32s - 1548.32s | is that that's an analog-to-digital converter. 1548.32s - 1550.32s | That can convert the actual light waves. 1550.32s - 1552.32s | So the photodiode converts the light waves 1552.32s - 1554.32s | to electricity. 1554.32s - 1556.32s | And that electricity is still a wave. 1556.32s - 1558.32s | It's just like our AC. So our AC 1558.32s - 1560.32s | that's producing 120 volts 1560.32s - 1562.32s | RMS voltage in the 1562.32s - 1564.32s | wall, that's traveling at 1564.32s - 1566.32s | 60 hertz. 60 times per second is moving 1566.32s - 1568.32s | up and down. 1568.32s - 1570.32s | And you can actually 1570.32s - 1572.32s | take advantage of that. 1572.32s - 1574.32s | I was curious, actually, 1574.32s - 1576.32s | whether it


chunk_id: 153_chunk_40
chunk_text:
| So what they did was, they had the laser 1536.32s - 1538.32s | hit a laptop, 1538.32s - 1540.32s | it would reflect off the laptop, and 1540.32s - 1542.32s | then it would go into a photodiode 1542.32s - 1544.32s | or photoresistor. They would power that, 1544.32s - 1546.32s | and they would go into the microphone. And the reason for the microphone 1546.32s - 1548.32s | is that that's an analog-to-digital converter. 1548.32s - 1550.32s | That can convert the actual light waves. 1550.32s - 1552.32s | So the photodiode converts the light waves 1552.32s - 1554.32s | to electricity. 1554.32s - 1556.32s | And that electricity is still a wave. 1556.32s - 1558.32s | It's just like our AC. So our AC 1558.32s - 1560.32s | that's producing 120 volts 1560.32s - 1562.32s | RMS voltage in the 1562.32s - 1564.32s | wall, that's traveling at 1564.32s - 1566.32s | 60 hertz. 60 times per second is moving 1566.32s - 1568.32s | up and down. 1568.32s - 1570.32s | And you can actually 1570.32s - 1572.32s | take advantage of that. 1572.32s - 1574.32s | I was curious, actually, 1574.32s - 1576.32s | whether it really was 60 hertz. 1576.32s - 1578.32s | So I had 1578.32s - 1580.32s | connected a transformer 1580.32s - 1582.32s | to my AC line, and converted that 1582.32s - 1584.32s | 120 volts down to 12 volts. And then I 1584.32s - 1586.32s | measured the zero crossing every time it would cross zero. 1586.32s - 1588.32s | Because I was curious, it says 60 hertz. 1588.32s - 1590.32s | Does that actually mean 60 times per second? 1590.32s - 1592.32s | Or does it mean, like, between 59 1592.32s - 1594.32s | and 61? And I found that 60 hertz 1594.32s - 1596.32s | is more accurate than the 1596.32s - 1598.32s | clock in my phone. So if my 1598.32s - 1600.32s | clock in my phone is not on Wi-Fi, 1600.32s - 1602.32s | I can use the 60 hertz 1602.32s - 1604.32s | from the wall to measure time, because it's 1604.32s - 1606.32s | so accurate. And I didn't understand, why 1606.32s - 1608.32s | is the wall, why is the 60 hertz so accurate? 1608.32s - 1610.32s | Apparently it's connected to GPS. So if one 1610.32s - 1612.32s | power station


chunk_id: 153_chunk_41
chunk_text:
really was 60 hertz. 1576.32s - 1578.32s | So I had 1578.32s - 1580.32s | connected a transformer 1580.32s - 1582.32s | to my AC line, and converted that 1582.32s - 1584.32s | 120 volts down to 12 volts. And then I 1584.32s - 1586.32s | measured the zero crossing every time it would cross zero. 1586.32s - 1588.32s | Because I was curious, it says 60 hertz. 1588.32s - 1590.32s | Does that actually mean 60 times per second? 1590.32s - 1592.32s | Or does it mean, like, between 59 1592.32s - 1594.32s | and 61? And I found that 60 hertz 1594.32s - 1596.32s | is more accurate than the 1596.32s - 1598.32s | clock in my phone. So if my 1598.32s - 1600.32s | clock in my phone is not on Wi-Fi, 1600.32s - 1602.32s | I can use the 60 hertz 1602.32s - 1604.32s | from the wall to measure time, because it's 1604.32s - 1606.32s | so accurate. And I didn't understand, why 1606.32s - 1608.32s | is the wall, why is the 60 hertz so accurate? 1608.32s - 1610.32s | Apparently it's connected to GPS. So if one 1610.32s - 1612.32s | power station goes down, another 1612.32s - 1614.32s | station can pick it up. But the interesting 1614.32s - 1616.32s | thing is, it's not always accurate. 1616.32s - 1618.32s | It would actually remain accurate only for a short period 1618.32s - 1620.32s | of time, and then it would drift. 1620.32s - 1622.32s | And I realized that you can take advantage of that drift, 1622.32s - 1624.32s | and you can exploit that. So what you 1624.32s - 1626.32s | can do, is you can say, 1626.32s - 1628.32s | if I measure that drift over time, 1628.32s - 1630.32s | you can take 1630.32s - 1632.32s | that and use that as a fingerprint of a location. 1632.32s - 1634.32s | Because every power station has its own unique fingerprint 1634.32s - 1636.32s | of that drift. So if you put a 1636.32s - 1638.32s | Raspberry Pi and a transformer in different 1638.32s - 1640.32s | power stations, just in the 1640.32s - 1642.32s | wall, you can have a public database 1642.32s - 1644.32s | where you're all sending the drift of this 1644.32s - 1646.32s | information, the 60 hertz signal. 1646.32s - 1648.32s |


chunk_id: 153_chunk_42
chunk_text:
goes down, another 1612.32s - 1614.32s | station can pick it up. But the interesting 1614.32s - 1616.32s | thing is, it's not always accurate. 1616.32s - 1618.32s | It would actually remain accurate only for a short period 1618.32s - 1620.32s | of time, and then it would drift. 1620.32s - 1622.32s | And I realized that you can take advantage of that drift, 1622.32s - 1624.32s | and you can exploit that. So what you 1624.32s - 1626.32s | can do, is you can say, 1626.32s - 1628.32s | if I measure that drift over time, 1628.32s - 1630.32s | you can take 1630.32s - 1632.32s | that and use that as a fingerprint of a location. 1632.32s - 1634.32s | Because every power station has its own unique fingerprint 1634.32s - 1636.32s | of that drift. So if you put a 1636.32s - 1638.32s | Raspberry Pi and a transformer in different 1638.32s - 1640.32s | power stations, just in the 1640.32s - 1642.32s | wall, you can have a public database 1642.32s - 1644.32s | where you're all sending the drift of this 1644.32s - 1646.32s | information, the 60 hertz signal. 1646.32s - 1648.32s | And now whenever you have a recording, a video recording 1648.32s - 1650.32s | or an audio recording, you can perform 1650.32s - 1652.32s | a match and figure out where that audio recording 1652.32s - 1654.32s | was taken, or where that video recording was 1654.32s - 1656.32s | taken. Just another 1656.32s - 1658.32s | interesting project that we can take advantage of. 1658.32s - 1660.32s | And there's so much other interesting research 1660.32s - 1662.32s | in the laser microphone and the keyboard acoustics. 1662.32s - 1664.32s | Ben Nassie, he did 1664.32s - 1666.32s | Lamp Phone, Glow Worm, many other 1666.32s - 1668.32s | attacks. There's 1668.32s - 1670.32s | the visual microphone, there's keyboard acoustic 1670.32s - 1672.32s | side channels, keyboard acoustic emanations. 1672.32s - 1674.32s | And I want to see, A, can I 1674.32s - 1676.32s | implement this laser microphone? And B, 1676.32s - 1678.32s | can I have some improvements? 1678.32s - 1680.32s | And can I also hear sound? I want to hear sound 1680.32s - 1682.32s | from a window. Now 1682.32s - 1684.32s | first, it's really, really important 1684.32s - 1686.32s | like, lasers


chunk_id: 153_chunk_43
chunk_text:
And now whenever you have a recording, a video recording 1648.32s - 1650.32s | or an audio recording, you can perform 1650.32s - 1652.32s | a match and figure out where that audio recording 1652.32s - 1654.32s | was taken, or where that video recording was 1654.32s - 1656.32s | taken. Just another 1656.32s - 1658.32s | interesting project that we can take advantage of. 1658.32s - 1660.32s | And there's so much other interesting research 1660.32s - 1662.32s | in the laser microphone and the keyboard acoustics. 1662.32s - 1664.32s | Ben Nassie, he did 1664.32s - 1666.32s | Lamp Phone, Glow Worm, many other 1666.32s - 1668.32s | attacks. There's 1668.32s - 1670.32s | the visual microphone, there's keyboard acoustic 1670.32s - 1672.32s | side channels, keyboard acoustic emanations. 1672.32s - 1674.32s | And I want to see, A, can I 1674.32s - 1676.32s | implement this laser microphone? And B, 1676.32s - 1678.32s | can I have some improvements? 1678.32s - 1680.32s | And can I also hear sound? I want to hear sound 1680.32s - 1682.32s | from a window. Now 1682.32s - 1684.32s | first, it's really, really important 1684.32s - 1686.32s | like, lasers are not a toy. I mean, 1686.32s - 1688.32s | they're a lot of fun. Cats love them. 1688.32s - 1690.32s | They're a toy to cats. But you can 1690.32s - 1692.32s | oh my god, 1692.32s - 1694.32s | you can burn your eyes, so you 1694.32s - 1696.32s | do actually want to always use 1696.32s - 1698.32s | laser safety glasses, goggles. 1698.32s - 1700.32s | When you're buying a 5 milliwatt laser, 1700.32s - 1702.32s | it doesn't mean it only outputs 1702.32s - 1704.32s | 5 milliwatts. It can output much more power. 1704.32s - 1706.32s | America, we 1706.32s - 1708.32s | have the ANSI standard Z136.1 1708.32s - 1710.32s | Europe uses EN207. Make sure 1710.32s - 1712.32s | you're getting from a laser safety 1712.32s - 1714.32s | goggles from a reputable source. 1714.32s - 1716.32s | And also for the wavelength, for the color 1716.32s - 1718.32s | of light that you're working with. 1718.32s - 1720.32s | Let's talk about hardware. So I first 1720.32s - 1722.32s | tried to reimplement the 1722.32s - 1724.32s | original 1724.32s - 1726.32s | laser microphone, and 1726.32s - 1728.32s | it


chunk_id: 153_chunk_44
chunk_text:
are not a toy. I mean, 1686.32s - 1688.32s | they're a lot of fun. Cats love them. 1688.32s - 1690.32s | They're a toy to cats. But you can 1690.32s - 1692.32s | oh my god, 1692.32s - 1694.32s | you can burn your eyes, so you 1694.32s - 1696.32s | do actually want to always use 1696.32s - 1698.32s | laser safety glasses, goggles. 1698.32s - 1700.32s | When you're buying a 5 milliwatt laser, 1700.32s - 1702.32s | it doesn't mean it only outputs 1702.32s - 1704.32s | 5 milliwatts. It can output much more power. 1704.32s - 1706.32s | America, we 1706.32s - 1708.32s | have the ANSI standard Z136.1 1708.32s - 1710.32s | Europe uses EN207. Make sure 1710.32s - 1712.32s | you're getting from a laser safety 1712.32s - 1714.32s | goggles from a reputable source. 1714.32s - 1716.32s | And also for the wavelength, for the color 1716.32s - 1718.32s | of light that you're working with. 1718.32s - 1720.32s | Let's talk about hardware. So I first 1720.32s - 1722.32s | tried to reimplement the 1722.32s - 1724.32s | original 1724.32s - 1726.32s | laser microphone, and 1726.32s - 1728.32s | it took me a while to get it working. 1728.32s - 1730.32s | And the sound quality wasn't great. 1730.32s - 1732.32s | Now, it was still incredible. Like, as soon as you 1732.32s - 1734.32s | get to hear sound, 1734.32s - 1736.32s | that you're bouncing off a window, and then 1736.32s - 1738.32s | reflecting back and picking up, and you can 1738.32s - 1740.32s | hear what's going on inside, 1740.32s - 1742.32s | it's a really magical feeling. 1742.32s - 1744.32s | And I wanted to see, can I improve it? Can I improve 1744.32s - 1746.32s | the quality? Because it just, it wasn't that great. 1746.32s - 1748.32s | Here's my transmit side. 1748.32s - 1750.32s | So we've updated the system 1750.32s - 1752.32s | a little bit. The 1752.32s - 1754.32s | primary things, the primary differences, for one 1754.32s - 1756.32s | is, normally you just have a laser, and you 1756.32s - 1758.32s | point it at the window. Every schematic, 1758.32s - 1760.32s | every laser microphone I've ever 1760.32s - 1762.32s | seen, simply has a constant 1762.32s - 1764.32s | laser source, hitting something and 1764.32s -


chunk_id: 153_chunk_45
chunk_text:
took me a while to get it working. 1728.32s - 1730.32s | And the sound quality wasn't great. 1730.32s - 1732.32s | Now, it was still incredible. Like, as soon as you 1732.32s - 1734.32s | get to hear sound, 1734.32s - 1736.32s | that you're bouncing off a window, and then 1736.32s - 1738.32s | reflecting back and picking up, and you can 1738.32s - 1740.32s | hear what's going on inside, 1740.32s - 1742.32s | it's a really magical feeling. 1742.32s - 1744.32s | And I wanted to see, can I improve it? Can I improve 1744.32s - 1746.32s | the quality? Because it just, it wasn't that great. 1746.32s - 1748.32s | Here's my transmit side. 1748.32s - 1750.32s | So we've updated the system 1750.32s - 1752.32s | a little bit. The 1752.32s - 1754.32s | primary things, the primary differences, for one 1754.32s - 1756.32s | is, normally you just have a laser, and you 1756.32s - 1758.32s | point it at the window. Every schematic, 1758.32s - 1760.32s | every laser microphone I've ever 1760.32s - 1762.32s | seen, simply has a constant 1762.32s - 1764.32s | laser source, hitting something and 1764.32s - 1766.32s | reflecting back. The problem 1766.32s - 1768.32s | I found with this is that there's so much noise. 1768.32s - 1770.32s | We have the 60 hertz noise from 1770.32s - 1772.32s | the wall. We have all sorts of 1772.32s - 1774.32s | noise from computers around. And all 1774.32s - 1776.32s | of this stuff is typically low frequency noise 1776.32s - 1778.32s | that is messing with your signal. And we need to 1778.32s - 1780.32s | get rid of that. 1780.32s - 1782.32s | I found a laser 1782.32s - 1784.32s | driver, this was a laser 1784.32s - 1786.32s | driver I had, that had something called 1786.32s - 1788.32s | an RF bias T. And what this means is 1788.32s - 1790.32s | it's a mixer. So you can have a constant 1790.32s - 1792.32s | current source that's powering the laser, and 1792.32s - 1794.32s | then you can have another source that's oscillating. 1794.32s - 1796.32s | And I was thinking, well, what 1796.32s - 1798.32s | they do in radio is that they'll 1798.32s - 1800.32s | oscillate things at different frequencies to get away 1800.32s - 1802.32s |


chunk_id: 153_chunk_46
chunk_text:
1766.32s | reflecting back. The problem 1766.32s - 1768.32s | I found with this is that there's so much noise. 1768.32s - 1770.32s | We have the 60 hertz noise from 1770.32s - 1772.32s | the wall. We have all sorts of 1772.32s - 1774.32s | noise from computers around. And all 1774.32s - 1776.32s | of this stuff is typically low frequency noise 1776.32s - 1778.32s | that is messing with your signal. And we need to 1778.32s - 1780.32s | get rid of that. 1780.32s - 1782.32s | I found a laser 1782.32s - 1784.32s | driver, this was a laser 1784.32s - 1786.32s | driver I had, that had something called 1786.32s - 1788.32s | an RF bias T. And what this means is 1788.32s - 1790.32s | it's a mixer. So you can have a constant 1790.32s - 1792.32s | current source that's powering the laser, and 1792.32s - 1794.32s | then you can have another source that's oscillating. 1794.32s - 1796.32s | And I was thinking, well, what 1796.32s - 1798.32s | they do in radio is that they'll 1798.32s - 1800.32s | oscillate things at different frequencies to get away 1800.32s - 1802.32s | from other frequencies that might be harming. 1802.32s - 1804.32s | So what if we turn the laser on and off 1804.32s - 1806.32s | in the RF domain? If we go into 1806.32s - 1808.32s | radio, and we're turning that light on and off 1808.32s - 1810.32s | at the radio frequencies? 1810.32s - 1812.32s | Then we can actually get away 1812.32s - 1814.32s | from all of that noise that we hear. 1814.32s - 1816.32s | Here you can see the different parts 1816.32s - 1818.32s | of this system. So the 1818.32s - 1820.32s | oscilloscope in the top, I use that simply 1820.32s - 1822.32s | because I have a signal generator built in. 1822.32s - 1824.32s | It's a Rigol. I'll have the 1824.32s - 1826.32s | full details, the full 1826.32s - 1828.32s | bill of materials in a 1828.32s - 1830.32s | future slide. But the current controller and 1830.32s - 1832.32s | temperature controller, you do not need a temperature 1832.32s - 1834.32s | controller, but that's just what I have at home. 1834.32s - 1836.32s | Current controller for the constant current 1836.32s - 1838.32s | source. In the


chunk_id: 153_chunk_47
chunk_text:
from other frequencies that might be harming. 1802.32s - 1804.32s | So what if we turn the laser on and off 1804.32s - 1806.32s | in the RF domain? If we go into 1806.32s - 1808.32s | radio, and we're turning that light on and off 1808.32s - 1810.32s | at the radio frequencies? 1810.32s - 1812.32s | Then we can actually get away 1812.32s - 1814.32s | from all of that noise that we hear. 1814.32s - 1816.32s | Here you can see the different parts 1816.32s - 1818.32s | of this system. So the 1818.32s - 1820.32s | oscilloscope in the top, I use that simply 1820.32s - 1822.32s | because I have a signal generator built in. 1822.32s - 1824.32s | It's a Rigol. I'll have the 1824.32s - 1826.32s | full details, the full 1826.32s - 1828.32s | bill of materials in a 1828.32s - 1830.32s | future slide. But the current controller and 1830.32s - 1832.32s | temperature controller, you do not need a temperature 1832.32s - 1834.32s | controller, but that's just what I have at home. 1834.32s - 1836.32s | Current controller for the constant current 1836.32s - 1838.32s | source. In the top, there's that black box. 1838.32s - 1840.32s | That's the laser driver. 1840.32s - 1842.32s | There's also the RF mixer built 1842.32s - 1844.32s | into that. I use a collimating lens. 1844.32s - 1846.32s | So what collimation means is 1846.32s - 1848.32s | collimation means it just takes light and 1848.32s - 1850.32s | tries to make it into a single dot. 1850.32s - 1852.32s | Or a straight... 1852.32s - 1854.32s | If you take a flashlight, you typically have 1854.32s - 1856.32s | an unfocused beam of light. A collimated 1856.32s - 1858.32s | beam is a beam that does not focus 1858.32s - 1860.32s | or defocus. I used to think a laser, 1860.32s - 1862.32s | what made a laser a laser 1862.32s - 1864.32s | was that it was collimated, that it was a straight line. 1864.32s - 1866.32s | And that's not true. It's not 1866.32s - 1868.32s | collimation. What makes a laser 1868.32s - 1870.32s | a laser is that it's coherent. And all 1870.32s - 1872.32s | that means is that the phase of light coming out 1872.32s - 1874.32s | is always the same. It always


