0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/449 Thanks! 1 00:00:15,910 --> 00:00:16,910 Thank you, guys. 2 00:00:17,750 --> 00:00:19,579 This Congress has been a real experience, 3 00:00:19,580 --> 00:00:21,099 this was my first one, so it's great to 4 00:00:21,100 --> 00:00:23,199 be here as a presenter 5 00:00:23,200 --> 00:00:24,879 for the very first time through. 6 00:00:24,880 --> 00:00:26,979 So we are both researchers from 7 00:00:26,980 --> 00:00:28,149 Munich. 8 00:00:28,150 --> 00:00:30,249 We are doing the and this is 9 00:00:30,250 --> 00:00:32,589 the topic that we have been looking for, 10 00:00:32,590 --> 00:00:35,439 looking at for the last three years. 11 00:00:35,440 --> 00:00:36,440 So. 12 00:00:37,250 --> 00:00:38,629 Briefly, what the stock is going to 13 00:00:38,630 --> 00:00:40,429 cover. We'll tell you what their 14 00:00:40,430 --> 00:00:42,619 motivation is, why we care 15 00:00:42,620 --> 00:00:44,269 about this technology, what this 16 00:00:44,270 --> 00:00:46,339 technology actually is. 17 00:00:46,340 --> 00:00:48,409 We will talk about that 18 00:00:48,410 --> 00:00:49,999 and we will show you demos. 19 00:00:50,000 --> 00:00:51,649 But really, the three concepts that we 20 00:00:51,650 --> 00:00:53,629 will try to focus on in the stock is 21 00:00:53,630 --> 00:00:55,759 isolation, interpretation and 22 00:00:55,760 --> 00:00:57,919 interposition after we've 23 00:00:57,920 --> 00:00:59,269 covered the basics. 24 00:00:59,270 --> 00:01:01,549 We'll look at cloud security and 25 00:01:01,550 --> 00:01:03,319 how this technology applies to cloud 26 00:01:03,320 --> 00:01:05,719 security and discuss open problems. 27 00:01:05,720 --> 00:01:07,909 And this will lead the 28 00:01:07,910 --> 00:01:10,129 discussion into criminal code and 29 00:01:10,130 --> 00:01:11,809 code integrity. 30 00:01:11,810 --> 00:01:14,059 And that's where Tom is going to talk 31 00:01:14,060 --> 00:01:15,139 to you about. 32 00:01:15,140 --> 00:01:16,989 And then we will have some conclusions. 33 00:01:19,840 --> 00:01:21,939 So really, our motivation has been 34 00:01:21,940 --> 00:01:24,139 looking at Malvasia Melder collection, 35 00:01:24,140 --> 00:01:26,319 Melodia analysis and using 36 00:01:26,320 --> 00:01:28,239 virtualization and virtual machines to do 37 00:01:28,240 --> 00:01:29,240 that. 38 00:01:30,700 --> 00:01:32,109 We also been looking at intrusion 39 00:01:32,110 --> 00:01:33,819 detection and intrusion prevention. 40 00:01:33,820 --> 00:01:36,039 I was actually part of a group of cyber 41 00:01:36,040 --> 00:01:37,510 a project last year that 42 00:01:38,650 --> 00:01:40,899 looked at that for seven months and 43 00:01:40,900 --> 00:01:43,149 we created a prototype that will actually 44 00:01:43,150 --> 00:01:44,529 show today. 45 00:01:44,530 --> 00:01:46,659 But the technology is also applicable to 46 00:01:46,660 --> 00:01:48,759 debugging and more importantly, started 47 00:01:48,760 --> 00:01:51,819 blogging using virtual machines. 48 00:01:51,820 --> 00:01:54,009 And of course, cloud security is 49 00:01:54,010 --> 00:01:56,379 a big part of that as 50 00:01:56,380 --> 00:01:58,269 the entire cloud is based on virtual 51 00:01:58,270 --> 00:01:59,379 machines. 52 00:01:59,380 --> 00:02:01,479 But the upcoming things are mobile 53 00:02:01,480 --> 00:02:03,969 security and using the arm processors 54 00:02:03,970 --> 00:02:06,129 that are in your cell phones to 55 00:02:06,130 --> 00:02:08,349 use this technology to provide some sort 56 00:02:08,350 --> 00:02:10,599 of protections against malware. 57 00:02:13,790 --> 00:02:16,099 Which is not our motivation is to do DRM 58 00:02:16,100 --> 00:02:18,469 and espionage and stealth fruitcakes, 59 00:02:18,470 --> 00:02:20,659 but this technology is also 60 00:02:20,660 --> 00:02:21,709 very applicable to that. 61 00:02:21,710 --> 00:02:23,899 But we are really interested 62 00:02:23,900 --> 00:02:24,869 in the defense side. 63 00:02:24,870 --> 00:02:26,629 So you heard a lot about hacking. 64 00:02:26,630 --> 00:02:27,919 This talk is not about hacking. 65 00:02:27,920 --> 00:02:29,330 This is about protection. 66 00:02:31,660 --> 00:02:33,339 So when you're your virtual machines and 67 00:02:33,340 --> 00:02:34,749 you need to tell what's happening in a 68 00:02:34,750 --> 00:02:36,849 virtual machine or you need to control 69 00:02:36,850 --> 00:02:39,099 it, even the 70 00:02:39,100 --> 00:02:40,839 common approaches that you have today is 71 00:02:40,840 --> 00:02:42,189 that you install something in it, right? 72 00:02:42,190 --> 00:02:43,749 You have virtual box installed, virtual 73 00:02:43,750 --> 00:02:45,849 box tools. You have very useful virtual 74 00:02:45,850 --> 00:02:47,319 goods you have. Then you install those 75 00:02:47,320 --> 00:02:49,269 tools, which is very easy to implement 76 00:02:49,270 --> 00:02:50,949 and convenient. 77 00:02:50,950 --> 00:02:53,199 It can sometimes use shared memory or 78 00:02:53,200 --> 00:02:54,519 just Muslim. 79 00:02:54,520 --> 00:02:56,830 Just use the network to communicate with 80 00:02:57,850 --> 00:02:59,559 your server outside. 81 00:03:01,150 --> 00:03:02,739 You can also use network monitors, 82 00:03:04,270 --> 00:03:06,309 snorkeler or whatever idea systems you 83 00:03:06,310 --> 00:03:08,499 have, which is better 84 00:03:08,500 --> 00:03:09,969 than in gas stations, which really have 85 00:03:09,970 --> 00:03:11,289 no isolation. You're running in the 86 00:03:11,290 --> 00:03:13,239 virtual machine network. 87 00:03:13,240 --> 00:03:15,279 Monitors have this isolation that they 88 00:03:15,280 --> 00:03:16,779 are outside of the machine, so. 89 00:03:19,280 --> 00:03:21,259 It's more protected against attacks from 90 00:03:21,260 --> 00:03:23,539 within the same vein, but 91 00:03:23,540 --> 00:03:25,139 at the same time, you lose context. 92 00:03:25,140 --> 00:03:27,349 You look at the network, you see 93 00:03:27,350 --> 00:03:29,179 very limited information about what is 94 00:03:29,180 --> 00:03:30,529 actually happening within that virtual 95 00:03:30,530 --> 00:03:32,599 machine, especially if the 96 00:03:32,600 --> 00:03:33,600 traffic is encrypted. 97 00:03:35,080 --> 00:03:37,239 There are some steps into using 98 00:03:37,240 --> 00:03:40,119 live forensics on virtual machines or 99 00:03:40,120 --> 00:03:42,219 on physical machines, even where 100 00:03:42,220 --> 00:03:43,659 you can just scan the memory 101 00:03:45,340 --> 00:03:47,649 which has isolation and context, 102 00:03:47,650 --> 00:03:49,329 but you really just have a pass if you 103 00:03:49,330 --> 00:03:50,679 into the system. 104 00:03:50,680 --> 00:03:52,869 So all of these are valid approaches, 105 00:03:52,870 --> 00:03:54,419 but they all have their limitations. 106 00:03:55,900 --> 00:03:57,789 And this is where VMI really comes into 107 00:03:57,790 --> 00:03:59,859 play. And the basic 108 00:03:59,860 --> 00:04:01,659 idea behind VMI is that you look at the 109 00:04:01,660 --> 00:04:03,939 virtual hardware of the system, and just 110 00:04:03,940 --> 00:04:05,889 by looking at that, you try to understand 111 00:04:05,890 --> 00:04:07,629 and reconstruct what is happening within. 112 00:04:08,980 --> 00:04:10,789 In that sense, it's very similar to be 113 00:04:10,790 --> 00:04:11,949 back at the inspection where you're 114 00:04:11,950 --> 00:04:14,709 looking at packets 115 00:04:14,710 --> 00:04:16,088 and you try to reconstruct what's 116 00:04:16,089 --> 00:04:18,039 happening within the operating system, 117 00:04:18,040 --> 00:04:19,449 and you need to have some understanding 118 00:04:19,450 --> 00:04:21,249 of what operating system is running 119 00:04:21,250 --> 00:04:22,479 within that virtual machine. 120 00:04:22,480 --> 00:04:23,619 Or if you're doing deep packet 121 00:04:23,620 --> 00:04:25,839 inspection, which operating system 122 00:04:25,840 --> 00:04:27,669 segmented the packets to be able to 123 00:04:27,670 --> 00:04:28,670 reconstruct it. 124 00:04:29,980 --> 00:04:32,139 And for VMI, really, the three points 125 00:04:32,140 --> 00:04:34,239 that we want is isolation, 126 00:04:34,240 --> 00:04:36,129 interpretation and interpretation in 127 00:04:36,130 --> 00:04:38,259 which in isolation, I mean that 128 00:04:38,260 --> 00:04:39,549 you have some sort of increase the 129 00:04:39,550 --> 00:04:41,949 resiliency against attacks. 130 00:04:41,950 --> 00:04:43,239 And you also have complete view of the 131 00:04:43,240 --> 00:04:45,339 system. You have access to everything 132 00:04:45,340 --> 00:04:47,289 that that system is doing. 133 00:04:47,290 --> 00:04:49,479 And since you are in 134 00:04:49,480 --> 00:04:51,009 a more privileged level of the system, 135 00:04:51,010 --> 00:04:52,779 you can even interpose yourself into the 136 00:04:52,780 --> 00:04:53,890 execution of that machine. 137 00:04:55,210 --> 00:04:56,499 So we're going to look at these three 138 00:04:56,500 --> 00:04:57,500 things. 139 00:04:59,130 --> 00:05:01,199 So first, isolation, this is why we are 140 00:05:01,200 --> 00:05:03,599 really moving things 141 00:05:03,600 --> 00:05:05,319 out from a virtual machine and not having 142 00:05:05,320 --> 00:05:07,529 youngest agents is because 143 00:05:07,530 --> 00:05:09,809 if you run the cold outside, you 144 00:05:09,810 --> 00:05:11,939 can avoid ingest hooks, which is the most 145 00:05:11,940 --> 00:05:14,309 common attack vector on 146 00:05:14,310 --> 00:05:15,869 anything that you want within that 147 00:05:15,870 --> 00:05:16,870 machine. 148 00:05:18,480 --> 00:05:20,669 That makes tampering harder because 149 00:05:20,670 --> 00:05:22,139 you have isolation provided by the 150 00:05:22,140 --> 00:05:23,879 hypervisor. Of course, that depends on 151 00:05:23,880 --> 00:05:26,339 how good your hypervisor is and how 152 00:05:26,340 --> 00:05:29,459 hard it is to break out from the machine. 153 00:05:29,460 --> 00:05:31,589 But provided the hypervisor is secure 154 00:05:31,590 --> 00:05:33,779 and your your hardware is good, then 155 00:05:33,780 --> 00:05:36,509 you have increased trust in the code that 156 00:05:36,510 --> 00:05:38,489 is going to do what you want because it's 157 00:05:38,490 --> 00:05:39,510 in a protected region. 158 00:05:40,950 --> 00:05:42,299 By doing this, you also gain some 159 00:05:42,300 --> 00:05:44,039 performance because instead of having to 160 00:05:44,040 --> 00:05:46,259 deploy like an antivirus software in 161 00:05:46,260 --> 00:05:48,509 every virtual machine that you want 162 00:05:48,510 --> 00:05:49,769 to protect, you can just have one 163 00:05:49,770 --> 00:05:51,449 antivirus software that just protects all 164 00:05:51,450 --> 00:05:53,189 of your virtual machines. 165 00:05:53,190 --> 00:05:55,259 In that sense, you can avoid things 166 00:05:55,260 --> 00:05:56,579 like the antivirus thornber. 167 00:05:56,580 --> 00:05:58,289 All of your antivirus scans kick in at 168 00:05:58,290 --> 00:06:00,659 the same time on your virtual machines 169 00:06:00,660 --> 00:06:01,949 and just kaled the hardware. 170 00:06:05,680 --> 00:06:07,149 So interpretation is a very critical 171 00:06:07,150 --> 00:06:08,139 thing because you really want to 172 00:06:08,140 --> 00:06:09,369 understand what's happening within that 173 00:06:09,370 --> 00:06:10,370 machine 174 00:06:11,830 --> 00:06:14,139 and we have a very heavy 175 00:06:14,140 --> 00:06:16,329 focus on memory because memory is really 176 00:06:16,330 --> 00:06:18,579 the common point of all the hard 177 00:06:18,580 --> 00:06:21,219 work that that system is using. 178 00:06:21,220 --> 00:06:22,899 But we, of course, also have access to 179 00:06:22,900 --> 00:06:24,969 the CPU registers, the desk 180 00:06:24,970 --> 00:06:27,069 and the network, so those can come in 181 00:06:27,070 --> 00:06:28,479 handy as well. But we're really going to 182 00:06:28,480 --> 00:06:29,480 be focusing on memory. 183 00:06:32,780 --> 00:06:34,369 The reconstruction of the state, though, 184 00:06:34,370 --> 00:06:36,529 from memory is really hard and 185 00:06:36,530 --> 00:06:38,119 there are many problems with it and 186 00:06:38,120 --> 00:06:40,249 mostly because of complexity, 187 00:06:40,250 --> 00:06:41,569 you look into a virtual machine and it 188 00:06:41,570 --> 00:06:43,819 probably has Linux running or Windows 189 00:06:43,820 --> 00:06:45,709 running, and that's a large piece of 190 00:06:45,710 --> 00:06:46,710 software. 191 00:06:47,550 --> 00:06:49,499 Trying to understand what that large 192 00:06:49,500 --> 00:06:50,939 piece of software is doing just by 193 00:06:50,940 --> 00:06:52,829 looking at the original hardware is hard. 194 00:06:52,830 --> 00:06:54,719 And in the case of Windows, you don't 195 00:06:54,720 --> 00:06:55,919 really have access to the source code. 196 00:06:55,920 --> 00:06:57,659 So you really have to reverse engineer a 197 00:06:57,660 --> 00:06:59,249 lot of the things. 198 00:06:59,250 --> 00:07:01,349 And your code is running outside of 199 00:07:01,350 --> 00:07:03,119 the real time machine. The data that code 200 00:07:03,120 --> 00:07:05,819 is interacting with is still 201 00:07:05,820 --> 00:07:07,359 potentially tempered, tampered. 202 00:07:07,360 --> 00:07:09,599 So you have a dilemma of what data 203 00:07:09,600 --> 00:07:10,829 can be thrust into the machine. 204 00:07:12,630 --> 00:07:14,249 But let's start at the beginning, so 205 00:07:15,300 --> 00:07:17,219 if you're looking at a memory, what you 206 00:07:17,220 --> 00:07:18,629 see is a virtual machine, introspection 207 00:07:18,630 --> 00:07:20,369 is physical memory, but of course, that's 208 00:07:20,370 --> 00:07:22,319 not what the operating system is using. 209 00:07:22,320 --> 00:07:24,419 It's using paging and virtual 210 00:07:24,420 --> 00:07:26,339 memory, which has been around for a long 211 00:07:26,340 --> 00:07:28,409 time. And the basic idea is 212 00:07:28,410 --> 00:07:29,999 that the operating system sets up the 213 00:07:30,000 --> 00:07:32,159 tables and the hardware 214 00:07:32,160 --> 00:07:33,659 walks these tables when it needs to 215 00:07:33,660 --> 00:07:36,059 translate to a physical address. 216 00:07:36,060 --> 00:07:38,759 So it's a nice interface between 217 00:07:38,760 --> 00:07:40,469 hardware and software or software, 218 00:07:40,470 --> 00:07:41,969 provides the data and the hardware 219 00:07:41,970 --> 00:07:42,970 actually walks in. 220 00:07:45,540 --> 00:07:47,519 The problem with this very basic thing 221 00:07:47,520 --> 00:07:49,229 already is that while we have a bunch of 222 00:07:49,230 --> 00:07:51,899 different paging systems, so we have 223 00:07:51,900 --> 00:07:54,299 the 32 with Beijing and two extensions 224 00:07:54,300 --> 00:07:55,859 to that, and then we have the 64 bit 225 00:07:55,860 --> 00:07:56,799 Beijing. 226 00:07:56,800 --> 00:07:58,529 All right. So now you have to reconstruct 227 00:07:58,530 --> 00:08:00,419 all of these paging mechanisms and 228 00:08:00,420 --> 00:08:03,179 emulate what the hardware would do. 229 00:08:03,180 --> 00:08:04,529 So that part is fine. 230 00:08:04,530 --> 00:08:06,029 That is defined in the Intel manual. 231 00:08:06,030 --> 00:08:08,459 That's should be straightforward, 232 00:08:08,460 --> 00:08:10,739 except there are three bits that the 233 00:08:10,740 --> 00:08:13,019 Intel manual says that are at 234 00:08:13,020 --> 00:08:15,029 the optimal operating system to decide 235 00:08:15,030 --> 00:08:16,030 how we use it. 236 00:08:16,830 --> 00:08:19,469 And Windows does actually use these 237 00:08:19,470 --> 00:08:21,569 bits, at least two of them, 238 00:08:21,570 --> 00:08:23,879 which means that we have a difference 239 00:08:23,880 --> 00:08:25,289 between which operating system is 240 00:08:25,290 --> 00:08:27,629 actually running, how these tables 241 00:08:27,630 --> 00:08:29,559 look and what we can get from memory. 242 00:08:30,690 --> 00:08:33,178 So, for example, volatility has this line 243 00:08:33,179 --> 00:08:36,329 when it does a translation 244 00:08:36,330 --> 00:08:38,548 that looks at these software 245 00:08:38,549 --> 00:08:40,649 defined bits in the pitch table entries 246 00:08:40,650 --> 00:08:42,808 that says that if this the 11th 247 00:08:42,809 --> 00:08:44,969 bit is set by the 10th, it isn't 248 00:08:44,970 --> 00:08:47,399 then that page is present in memory. 249 00:08:47,400 --> 00:08:49,889 And they do that for every translation, 250 00:08:49,890 --> 00:08:51,659 even if the guest is actually Linux, 251 00:08:51,660 --> 00:08:53,519 which is of course, incorrect. 252 00:08:53,520 --> 00:08:56,099 So this is, of course, not a big problem 253 00:08:56,100 --> 00:08:58,259 because, OK, we need to understand 254 00:08:58,260 --> 00:08:59,999 that we are looking at Linux and not do 255 00:09:00,000 --> 00:09:01,080 that, but 256 00:09:02,460 --> 00:09:03,959 already shows that accurate 257 00:09:03,960 --> 00:09:05,789 reconstruction is complex and you can 258 00:09:05,790 --> 00:09:07,079 easily miss things. 259 00:09:07,080 --> 00:09:08,529 And this is still the case with 260 00:09:08,530 --> 00:09:09,530 volatility. 261 00:09:11,490 --> 00:09:12,629 There are, of course, other problems with 262 00:09:12,630 --> 00:09:14,819 memory, like if memory is paged 263 00:09:14,820 --> 00:09:17,249 out, then you don't have access 264 00:09:17,250 --> 00:09:19,379 to it directly, but we 265 00:09:19,380 --> 00:09:20,369 have access to the disk. 266 00:09:20,370 --> 00:09:23,309 So now we have to look for the file and 267 00:09:23,310 --> 00:09:24,779 reconstruct the swap file, which is, 268 00:09:24,780 --> 00:09:26,879 again, totally dependent on the 269 00:09:26,880 --> 00:09:28,739 operating system, on how it's 270 00:09:28,740 --> 00:09:30,719 implemented, which just adds more 271 00:09:30,720 --> 00:09:31,940 complexity on top of that. 272 00:09:33,540 --> 00:09:35,639 So that, unfortunately, we can avoid some 273 00:09:35,640 --> 00:09:38,129 of that complexity, for example. 274 00:09:38,130 --> 00:09:39,929 Now we can inject fallout from the 275 00:09:39,930 --> 00:09:42,089 hypervisor to have the guest 276 00:09:42,090 --> 00:09:43,919 operating system bring those memory pages 277 00:09:43,920 --> 00:09:45,959 back from disk so we don't have to 278 00:09:45,960 --> 00:09:47,609 understand the file system and the swap 279 00:09:47,610 --> 00:09:49,409 file. But of course, that takes time 280 00:09:49,410 --> 00:09:50,909 because the machine has to execute to 281 00:09:50,910 --> 00:09:52,409 bring that back and it's only going to be 282 00:09:52,410 --> 00:09:54,579 available in the next release of them. 283 00:09:54,580 --> 00:09:56,009 But it's progress. 284 00:09:59,580 --> 00:10:00,959 So what are problems with Beijing is that 285 00:10:00,960 --> 00:10:02,970 you need to find a page labels and 286 00:10:04,350 --> 00:10:06,479 the way forensic schools find the page 287 00:10:06,480 --> 00:10:08,579 labels in memory is by really 288 00:10:08,580 --> 00:10:10,529 just having a signature that they scan 289 00:10:10,530 --> 00:10:11,639 for. 290 00:10:11,640 --> 00:10:13,949 So in this code segment 291 00:10:13,950 --> 00:10:16,499 here, we have, again, volatility 292 00:10:16,500 --> 00:10:18,629 which defines that forbids there, 293 00:10:18,630 --> 00:10:20,909 which is the signature for 294 00:10:20,910 --> 00:10:22,469 scanning for page labels. 295 00:10:22,470 --> 00:10:23,759 But that's actually just the signature 296 00:10:23,760 --> 00:10:24,699 for a process. 297 00:10:24,700 --> 00:10:26,759 In fact, it's just part of a header 298 00:10:26,760 --> 00:10:29,009 before a processing memory. 299 00:10:29,010 --> 00:10:31,380 And of course, that's not very robust 300 00:10:32,950 --> 00:10:34,919 with BMI. We can do a little better. 301 00:10:34,920 --> 00:10:36,449 We have access to the registers and we 302 00:10:36,450 --> 00:10:38,220 can just read out the concrete register 303 00:10:39,420 --> 00:10:41,519 from the virtual machine and just use 304 00:10:41,520 --> 00:10:44,549 that for translation. 305 00:10:44,550 --> 00:10:47,009 So BMI has advantages 306 00:10:47,010 --> 00:10:48,749 over just raw memory, Forensic's. 307 00:10:51,710 --> 00:10:54,139 After we have been able to translate 308 00:10:54,140 --> 00:10:55,279 virtually the physical addresses, of 309 00:10:55,280 --> 00:10:57,349 course, we need to understand the kernel 310 00:10:57,350 --> 00:10:59,509 and reconstruct what the colonel sees and 311 00:10:59,510 --> 00:11:01,339 what the colonel does, which really 312 00:11:01,340 --> 00:11:03,169 requires debugged information. 313 00:11:04,350 --> 00:11:06,679 And Microsoft gives the debug 314 00:11:06,680 --> 00:11:08,119 information for free. 315 00:11:08,120 --> 00:11:09,889 But of course, the format is proprietary. 316 00:11:09,890 --> 00:11:12,139 It's the PDB format, 317 00:11:12,140 --> 00:11:14,149 which fortunately over the years has been 318 00:11:14,150 --> 00:11:15,379 slowly reverse engineered. 319 00:11:15,380 --> 00:11:16,520 But it's a pain to work with. 320 00:11:18,650 --> 00:11:20,749 But recently, recall, which 321 00:11:20,750 --> 00:11:23,419 is a form of volatility by Google, 322 00:11:23,420 --> 00:11:25,519 really now nicely supported, where you 323 00:11:25,520 --> 00:11:27,169 take this debug information from 324 00:11:27,170 --> 00:11:29,239 Microsoft and just dump it into Jason 325 00:11:29,240 --> 00:11:30,259 files. 326 00:11:30,260 --> 00:11:33,079 So with Microsoft, this is actually 327 00:11:33,080 --> 00:11:34,549 in between those. This is actually quite 328 00:11:34,550 --> 00:11:36,350 nice. This is very workable. 329 00:11:37,880 --> 00:11:39,319 With Linux, this is, of course, a bit 330 00:11:39,320 --> 00:11:41,149 more problematic because we have a ton of 331 00:11:41,150 --> 00:11:42,889 different kernels. So even if you're not 332 00:11:42,890 --> 00:11:44,599 taking into account your custom compiled 333 00:11:44,600 --> 00:11:47,629 kernel, even if you just have stock, 334 00:11:47,630 --> 00:11:49,699 Ubuntu kernels, 335 00:11:49,700 --> 00:11:52,009 there is really no across the 336 00:11:52,010 --> 00:11:53,899 central repository that you can get these 337 00:11:53,900 --> 00:11:55,999 debug information from every distribution 338 00:11:56,000 --> 00:11:57,109 has its own. 339 00:11:57,110 --> 00:11:59,179 Maybe they do have it for all 340 00:11:59,180 --> 00:12:01,369 distribution. It's probably gone. 341 00:12:01,370 --> 00:12:03,709 So having that information 342 00:12:03,710 --> 00:12:05,989 is not as easy 343 00:12:05,990 --> 00:12:07,249 as on Microsoft Word. 344 00:12:07,250 --> 00:12:08,719 They just have a very nice central 345 00:12:08,720 --> 00:12:09,799 repository. 346 00:12:09,800 --> 00:12:11,899 So there is some version that in that 347 00:12:11,900 --> 00:12:14,689 sense to have a central 348 00:12:14,690 --> 00:12:16,129 place where you can grab the debugging 349 00:12:16,130 --> 00:12:17,839 information and that's the federal radar 350 00:12:17,840 --> 00:12:18,889 server. 351 00:12:18,890 --> 00:12:21,049 But it's not 352 00:12:21,050 --> 00:12:22,999 really used. I mean, how many people have 353 00:12:23,000 --> 00:12:24,000 even heard of it? 354 00:12:24,770 --> 00:12:26,239 I don't see any hants. 355 00:12:26,240 --> 00:12:27,469 Right. 356 00:12:27,470 --> 00:12:29,989 But there are at least some initiatives 357 00:12:29,990 --> 00:12:30,990 in that direction. 358 00:12:34,450 --> 00:12:36,249 Going back to scanning, so even if you 359 00:12:36,250 --> 00:12:38,409 have the information you need to 360 00:12:38,410 --> 00:12:40,299 find those data structures that you care 361 00:12:40,300 --> 00:12:41,829 about, right, you want to find the data 362 00:12:41,830 --> 00:12:43,659 that you are interested in. 363 00:12:43,660 --> 00:12:45,459 So you need to find first the kernel and 364 00:12:45,460 --> 00:12:47,679 then the processes and files and 365 00:12:47,680 --> 00:12:49,419 whatever else you are looking for. 366 00:12:49,420 --> 00:12:51,579 And there windows, at least this 367 00:12:51,580 --> 00:12:53,949 is done by looking for full headers, 368 00:12:53,950 --> 00:12:56,289 which is essentially just a debugging 369 00:12:56,290 --> 00:12:58,299 header attached to memory allocations 370 00:12:58,300 --> 00:13:00,249 that Windows does, money that locates a 371 00:13:00,250 --> 00:13:02,469 file object, for example, 372 00:13:02,470 --> 00:13:04,510 and very similarly to the. 373 00:13:06,120 --> 00:13:07,409 Scan that we saw before. 374 00:13:07,410 --> 00:13:09,629 These are usually for bite signatures 375 00:13:09,630 --> 00:13:11,009 that you can scan for. 376 00:13:12,570 --> 00:13:14,069 But the problem with that is, is that you 377 00:13:14,070 --> 00:13:16,289 have a lot of them 378 00:13:16,290 --> 00:13:17,939 and you don't know which one is valid and 379 00:13:17,940 --> 00:13:20,219 which one isn't because you have 380 00:13:20,220 --> 00:13:21,899 partial structures in memory and old 381 00:13:21,900 --> 00:13:22,829 structures in memory. 382 00:13:22,830 --> 00:13:24,329 And then you just have false positives 383 00:13:24,330 --> 00:13:26,159 because you are scanning for four 384 00:13:26,160 --> 00:13:27,749 characters in memory and you're going to 385 00:13:27,750 --> 00:13:28,750 have a lot of that. 386 00:13:29,960 --> 00:13:31,669 And really, memory doesn't get reset, so 387 00:13:31,670 --> 00:13:32,899 if you're free or structure, it's not 388 00:13:32,900 --> 00:13:34,219 like it's magically disappeared from 389 00:13:34,220 --> 00:13:35,299 memory, it's still going to be there, 390 00:13:35,300 --> 00:13:37,279 just the operating system, three sisters, 391 00:13:37,280 --> 00:13:39,309 it's not there anymore, but it's really 392 00:13:39,310 --> 00:13:41,239 still in memory. So you need to have more 393 00:13:41,240 --> 00:13:43,339 respect to validate those hits. 394 00:13:43,340 --> 00:13:45,169 So now you have even more complexity in 395 00:13:45,170 --> 00:13:46,999 trying to interpret which data is valid 396 00:13:47,000 --> 00:13:48,379 and which one isn't. 397 00:13:48,380 --> 00:13:49,939 And that just makes everything more 398 00:13:49,940 --> 00:13:50,940 fragile. 399 00:13:51,670 --> 00:13:53,619 And of course, people have discovered 400 00:13:53,620 --> 00:13:55,689 that this is fragile, so in 2012, 401 00:13:55,690 --> 00:13:57,849 there was paper about one 402 00:13:57,850 --> 00:13:59,919 bite modification we just broke finding 403 00:13:59,920 --> 00:14:02,169 the labels and then we'll just 404 00:14:02,170 --> 00:14:03,999 give up because it can translate to 405 00:14:04,000 --> 00:14:05,319 physical memory. 406 00:14:05,320 --> 00:14:07,539 But this year, earlier, there 407 00:14:07,540 --> 00:14:09,939 was another talk about just adding 408 00:14:09,940 --> 00:14:11,409 a ton of fake signatures. 409 00:14:11,410 --> 00:14:13,209 And then what we will throw up as well, 410 00:14:13,210 --> 00:14:14,899 because we can't tell which one is real 411 00:14:14,900 --> 00:14:17,109 and then you have to go through by hand. 412 00:14:17,110 --> 00:14:19,029 And that's really not a feasible 413 00:14:19,030 --> 00:14:20,030 approach. 414 00:14:21,690 --> 00:14:23,519 And that just really highlights that we 415 00:14:23,520 --> 00:14:25,019 have fundamental problems with trusting 416 00:14:25,020 --> 00:14:27,719 the data and we don't have a good way. 417 00:14:27,720 --> 00:14:29,909 To evaluate which one's 418 00:14:29,910 --> 00:14:31,769 which data structures are valid from what 419 00:14:31,770 --> 00:14:32,770 we find through scanned. 420 00:14:35,810 --> 00:14:37,189 And that's where interposition becomes 421 00:14:37,190 --> 00:14:38,629 critical, because if you know the 422 00:14:38,630 --> 00:14:40,879 execution flaw in the system and 423 00:14:40,880 --> 00:14:42,799 you can trap at specific locations, you 424 00:14:42,800 --> 00:14:45,049 know what state the system is, the system 425 00:14:45,050 --> 00:14:47,689 is in and then you can avoid scanning. 426 00:14:47,690 --> 00:14:49,249 So, for example, instead of having to 427 00:14:49,250 --> 00:14:51,529 search for the Kleberg structure, which 428 00:14:51,530 --> 00:14:53,629 forensic tools use to map out some 429 00:14:53,630 --> 00:14:55,699 basic structures, we can 430 00:14:55,700 --> 00:14:57,919 just use the VCP registers and we 431 00:14:57,920 --> 00:14:59,569 can automatically find the kernel. 432 00:14:59,570 --> 00:15:02,029 And since we use the debug data, 433 00:15:02,030 --> 00:15:04,159 we don't have to use the in-memory debug 434 00:15:04,160 --> 00:15:05,869 data. We can just use the one that we 435 00:15:05,870 --> 00:15:08,179 generated. And then we have complete 436 00:15:08,180 --> 00:15:09,180 map of the current. 437 00:15:10,390 --> 00:15:12,009 Furthermore, the hip allocations that 438 00:15:13,450 --> 00:15:15,489 they used before forensic stores to find 439 00:15:15,490 --> 00:15:17,799 files and whatnot 440 00:15:17,800 --> 00:15:20,589 can be trapped automatically 441 00:15:20,590 --> 00:15:22,479 when the colonel actually allocates 442 00:15:22,480 --> 00:15:24,419 something on the heap. 443 00:15:24,420 --> 00:15:26,039 And what's great is there is actually 444 00:15:26,040 --> 00:15:28,199 native support built into Xen, 445 00:15:28,200 --> 00:15:30,329 so you don't have to custom patch some 446 00:15:30,330 --> 00:15:32,219 weird hypervisor, you can just use what's 447 00:15:32,220 --> 00:15:33,220 already provided. 448 00:15:34,080 --> 00:15:35,069 And this is great because this was 449 00:15:35,070 --> 00:15:36,719 actually designed for debugging, but it's 450 00:15:36,720 --> 00:15:38,639 really unknown and there is not many 451 00:15:38,640 --> 00:15:39,749 documentation on it. 452 00:15:39,750 --> 00:15:41,879 And if you try to even read the 453 00:15:41,880 --> 00:15:43,859 API, it's not going to tell you much. 454 00:15:43,860 --> 00:15:45,989 So you really need to look at some 455 00:15:45,990 --> 00:15:48,359 sample codes that are hidden 456 00:15:48,360 --> 00:15:49,500 within the Zen source, 457 00:15:50,520 --> 00:15:51,520 but it's there. 458 00:15:52,410 --> 00:15:54,059 So let's look at what I'm actually 459 00:15:54,060 --> 00:15:55,060 talking about. 460 00:15:58,110 --> 00:16:00,019 So this is not a live demo prerecorded 461 00:16:00,020 --> 00:16:01,020 it, but. 462 00:16:02,240 --> 00:16:04,339 For all intents and purposes, 463 00:16:04,340 --> 00:16:06,529 this will be so I'm running on some four 464 00:16:06,530 --> 00:16:08,929 point four and I have two 465 00:16:08,930 --> 00:16:11,209 vans running down zero 466 00:16:11,210 --> 00:16:12,470 and Windows seven. 467 00:16:14,170 --> 00:16:16,299 Thirty two bit and I can 468 00:16:16,300 --> 00:16:18,039 list all the processes that are running 469 00:16:18,040 --> 00:16:19,040 in the system. 470 00:16:20,600 --> 00:16:22,099 This is very similar to how forensics 471 00:16:22,100 --> 00:16:24,949 does do it, so that works, and 472 00:16:24,950 --> 00:16:26,419 I can see that I see more processes 473 00:16:26,420 --> 00:16:28,309 running than what process parts manager 474 00:16:28,310 --> 00:16:29,310 tells us and we note. 475 00:16:31,740 --> 00:16:34,529 There are the kernel modules which 476 00:16:34,530 --> 00:16:36,779 show up for and the US colonel that you 477 00:16:36,780 --> 00:16:39,029 see so you can tell 478 00:16:39,030 --> 00:16:41,759 what's loaded in memory for that machine. 479 00:16:41,760 --> 00:16:43,529 But these are all using the kernel 480 00:16:43,530 --> 00:16:45,419 internal data structures, which you might 481 00:16:45,420 --> 00:16:46,679 not necessarily. 482 00:16:50,650 --> 00:16:52,959 So now what we see here is actually the 483 00:16:52,960 --> 00:16:55,719 live execution of the Windows kernel 484 00:16:55,720 --> 00:16:57,309 where I trapped all 485 00:16:58,450 --> 00:17:00,549 internal system functions 486 00:17:00,550 --> 00:17:01,929 that result from system calls. 487 00:17:01,930 --> 00:17:03,129 So these are not the system calls 488 00:17:03,130 --> 00:17:05,259 themselves if I'm catching, 489 00:17:05,260 --> 00:17:07,118 but the functions that are being called 490 00:17:07,119 --> 00:17:08,469 from the system calls. 491 00:17:08,470 --> 00:17:09,729 And as you can see, there's a lot of 492 00:17:09,730 --> 00:17:11,289 things happening within windows, even if 493 00:17:11,290 --> 00:17:12,290 I'm not doing anything right. 494 00:17:14,020 --> 00:17:15,608 So it's impossible to see what's 495 00:17:15,609 --> 00:17:17,679 happening, so I just dump it into 496 00:17:17,680 --> 00:17:19,419 a screen log so I can grab through the 497 00:17:19,420 --> 00:17:20,949 live output. 498 00:17:20,950 --> 00:17:23,649 So these are actually the functions 499 00:17:23,650 --> 00:17:25,989 that are being called, if you can 500 00:17:25,990 --> 00:17:26,899 catch some of them. 501 00:17:26,900 --> 00:17:28,239 But I mean, I'm not doing anything and 502 00:17:28,240 --> 00:17:30,159 there is a ton of them being called all 503 00:17:30,160 --> 00:17:31,179 the time. 504 00:17:31,180 --> 00:17:33,309 But this gets you an idea that you can 505 00:17:33,310 --> 00:17:35,259 actually jump into the execution of the 506 00:17:35,260 --> 00:17:37,329 system and see what's what's going 507 00:17:37,330 --> 00:17:39,219 on. And if any of these functions you 508 00:17:39,220 --> 00:17:41,109 have a deeper interest, then you can 509 00:17:41,110 --> 00:17:42,099 actually look at them. 510 00:17:42,100 --> 00:17:43,449 And for example, one of the functions I'm 511 00:17:43,450 --> 00:17:45,519 trapping is the heap allocation function 512 00:17:45,520 --> 00:17:48,189 where I can check what structure 513 00:17:48,190 --> 00:17:50,559 structures Windows is actually requesting 514 00:17:50,560 --> 00:17:51,700 to be allocated 515 00:17:52,870 --> 00:17:55,029 and keep allocations, of course, 516 00:17:55,030 --> 00:17:56,349 are very much in the first part of the 517 00:17:56,350 --> 00:17:57,699 system. So if I just move the mouse 518 00:17:57,700 --> 00:17:59,799 around, you see a ton of ILD structures 519 00:17:59,800 --> 00:18:02,439 being constantly allocated on the system 520 00:18:02,440 --> 00:18:04,030 and that's just by moving the mouse. 521 00:18:08,700 --> 00:18:10,529 Now, as we have deeper interest in some 522 00:18:10,530 --> 00:18:11,609 of those structures that are being 523 00:18:11,610 --> 00:18:13,679 allocated, we can do that 524 00:18:13,680 --> 00:18:14,789 as well. 525 00:18:14,790 --> 00:18:16,349 So, for example, if I want to check what 526 00:18:16,350 --> 00:18:18,389 files are being accessed by Windows, I 527 00:18:18,390 --> 00:18:20,519 can do that just by watching 528 00:18:20,520 --> 00:18:23,039 what objects are allocated on the heap. 529 00:18:23,040 --> 00:18:24,599 And I just clicked on some random 530 00:18:24,600 --> 00:18:26,159 personalization. 531 00:18:26,160 --> 00:18:28,229 And these are all the files that 532 00:18:28,230 --> 00:18:29,639 windows those accesses in the background 533 00:18:29,640 --> 00:18:30,640 that. 534 00:18:33,520 --> 00:18:34,629 I'm not even doing anything. 535 00:18:34,630 --> 00:18:35,790 This is just still loading, right? 536 00:18:38,860 --> 00:18:40,119 It's still going. 537 00:18:40,120 --> 00:18:41,120 All right. 538 00:18:45,340 --> 00:18:47,049 So if you want to debug an operating 539 00:18:47,050 --> 00:18:48,849 system, this is really great because you 540 00:18:48,850 --> 00:18:50,769 have full understanding of what what it's 541 00:18:50,770 --> 00:18:52,629 doing. And just to show you that this is 542 00:18:52,630 --> 00:18:54,099 actually what's happening, I just create 543 00:18:54,100 --> 00:18:56,349 a document here on the desktop. 544 00:18:58,870 --> 00:19:01,089 And as you can see, there is still 545 00:19:01,090 --> 00:19:02,409 a lot of things happening, so I don't 546 00:19:02,410 --> 00:19:04,029 even necessarily see the file that I 547 00:19:04,030 --> 00:19:05,030 created, so. 548 00:19:06,680 --> 00:19:08,119 Actually, I just going to cut through 549 00:19:08,120 --> 00:19:09,859 that screen log to see if the file was 550 00:19:09,860 --> 00:19:12,019 actually in there that I 551 00:19:12,020 --> 00:19:14,089 created and yes, it's there and 552 00:19:14,090 --> 00:19:16,309 it's actually a test that the data 553 00:19:16,310 --> 00:19:18,649 because Windows automatically 554 00:19:18,650 --> 00:19:19,969 adds the extension for me. 555 00:19:19,970 --> 00:19:22,069 So I did not know that. 556 00:19:25,760 --> 00:19:27,829 So the way this works is actually 557 00:19:27,830 --> 00:19:29,539 using four types of events. 558 00:19:29,540 --> 00:19:31,669 And then unfortunately, this 559 00:19:31,670 --> 00:19:33,979 is for Intel only, but that's 560 00:19:33,980 --> 00:19:35,269 good enough. 561 00:19:35,270 --> 00:19:37,319 The first type is move to see register 562 00:19:37,320 --> 00:19:39,589 events. So this is there are three 563 00:19:39,590 --> 00:19:41,239 controller registers the operating system 564 00:19:41,240 --> 00:19:43,670 uses to define various features. 565 00:19:44,990 --> 00:19:47,329 The CRT is, of course, holds the stable 566 00:19:47,330 --> 00:19:49,609 address that is used for the current 567 00:19:49,610 --> 00:19:51,069 executing processes. 568 00:19:51,070 --> 00:19:53,179 The physical translation zero zero 569 00:19:53,180 --> 00:19:54,709 zero four holds. 570 00:19:54,710 --> 00:19:56,809 Various options can be 571 00:19:56,810 --> 00:19:58,939 used to flush the yabbie and they can 572 00:19:58,940 --> 00:20:01,159 trap every time those registers change. 573 00:20:01,160 --> 00:20:02,659 So we have an understanding that a new 574 00:20:02,660 --> 00:20:05,089 process gets scheduled in the operating 575 00:20:05,090 --> 00:20:06,090 system. So that's great. 576 00:20:07,580 --> 00:20:09,109 The second most important one that I use 577 00:20:09,110 --> 00:20:10,699 here is debugging breakpoints, so these 578 00:20:10,700 --> 00:20:12,769 are just really the debugging points that 579 00:20:12,770 --> 00:20:14,929 you would use if you run GDB or Olie 580 00:20:14,930 --> 00:20:17,749 debugger, which is the free instruction 581 00:20:17,750 --> 00:20:19,939 hex code, and 582 00:20:19,940 --> 00:20:21,289 you can just ride that anywhere in the 583 00:20:21,290 --> 00:20:23,419 kernel code pages and it will trap and 584 00:20:23,420 --> 00:20:25,009 you can actually configure the machine to 585 00:20:25,010 --> 00:20:26,779 trap into the hypervisor run such a break 586 00:20:26,780 --> 00:20:28,219 when it happens. 587 00:20:28,220 --> 00:20:29,220 So that's pretty great. 588 00:20:30,630 --> 00:20:32,009 The other event type is 589 00:20:33,270 --> 00:20:34,949 via the EPPY violations, which is the 590 00:20:34,950 --> 00:20:37,019 extended stables where we 591 00:20:37,020 --> 00:20:39,269 actually have a whole other set of 592 00:20:39,270 --> 00:20:40,529 stables that are maintained by the 593 00:20:40,530 --> 00:20:42,899 hypervisor that maps what memories 594 00:20:42,900 --> 00:20:45,539 allocated for that virtual machine 595 00:20:45,540 --> 00:20:47,729 and before this was done 596 00:20:47,730 --> 00:20:49,259 via the shadow stables. 597 00:20:49,260 --> 00:20:50,299 But now we Deepthi. 598 00:20:52,280 --> 00:20:54,259 This is all managed by the hardware, but 599 00:20:54,260 --> 00:20:55,309 the good thing is that you can set 600 00:20:55,310 --> 00:20:57,169 different permissions in the EP three 601 00:20:57,170 --> 00:20:59,539 tables than what the operating system 602 00:20:59,540 --> 00:21:00,769 sets in the virtual machine. 603 00:21:00,770 --> 00:21:02,599 So you can actually trap various 604 00:21:02,600 --> 00:21:04,669 accesses, read, write 605 00:21:04,670 --> 00:21:06,949 or execute instruction stretches from 606 00:21:06,950 --> 00:21:08,269 memory. 607 00:21:08,270 --> 00:21:09,889 And then the fourth one, which is also 608 00:21:09,890 --> 00:21:11,729 critical, is the monitor trap like a 609 00:21:11,730 --> 00:21:13,219 single thing, which is an invisible 610 00:21:13,220 --> 00:21:14,689 single stabbing feature built into your 611 00:21:14,690 --> 00:21:15,919 Intel processors now where you can 612 00:21:15,920 --> 00:21:18,289 actually single step of virtual machine 613 00:21:18,290 --> 00:21:20,659 without having the 614 00:21:20,660 --> 00:21:22,549 anything within that machine, knowing 615 00:21:22,550 --> 00:21:24,619 that these are being single step. 616 00:21:24,620 --> 00:21:26,179 Well, there is a bunch of other features 617 00:21:26,180 --> 00:21:28,369 that Intel now allows 618 00:21:28,370 --> 00:21:30,589 you to trap on, but these are 619 00:21:30,590 --> 00:21:32,809 basically the four ones that the Zone 620 00:21:32,810 --> 00:21:34,069 currently supports. 621 00:21:34,070 --> 00:21:35,569 But as you can see, this is already 622 00:21:35,570 --> 00:21:37,109 pretty cool, like you can do a lot of 623 00:21:37,110 --> 00:21:38,110 these four types. 624 00:21:39,250 --> 00:21:41,439 As I said, using the zapper is 625 00:21:41,440 --> 00:21:43,299 really not very nice, and it's kind of 626 00:21:43,300 --> 00:21:45,039 hard to actually wrap your head around 627 00:21:45,040 --> 00:21:47,289 how things go together, 628 00:21:47,290 --> 00:21:49,089 but unfortunately, you don't have to. 629 00:21:49,090 --> 00:21:51,519 So the way I implemented this system 630 00:21:51,520 --> 00:21:53,739 is using Vme, which is a 631 00:21:53,740 --> 00:21:55,659 hypervisor agnostic library that we have 632 00:21:55,660 --> 00:21:57,850 been working with and actually 633 00:21:59,290 --> 00:22:01,689 extending heavily, which 634 00:22:01,690 --> 00:22:04,509 is repr API around Xen 635 00:22:04,510 --> 00:22:06,909 VM or even if you have a raw file 636 00:22:06,910 --> 00:22:09,279 dump's, you can do introspection on 637 00:22:09,280 --> 00:22:10,989 and it supports all the paging that is 638 00:22:10,990 --> 00:22:13,179 out there. Plus, I recently added armed 639 00:22:13,180 --> 00:22:15,579 support to it so you can actually do 640 00:22:15,580 --> 00:22:17,619 introspection on Android devices, for 641 00:22:17,620 --> 00:22:18,729 example. 642 00:22:18,730 --> 00:22:20,619 But for now it's basically Windows and 643 00:22:20,620 --> 00:22:21,729 Linux. 644 00:22:21,730 --> 00:22:23,529 It has a Python interface. 645 00:22:23,530 --> 00:22:25,449 And really the idea here is that you 646 00:22:25,450 --> 00:22:27,609 write code once using VMS and then 647 00:22:27,610 --> 00:22:29,199 if you switch the hypervisor underneath, 648 00:22:29,200 --> 00:22:31,749 it's not going to matter as long as the 649 00:22:31,750 --> 00:22:33,459 drivers are set up properly between like 650 00:22:33,460 --> 00:22:35,619 VMI. And then you write code once and 651 00:22:35,620 --> 00:22:36,620 it's good to go. 652 00:22:37,330 --> 00:22:38,649 You can use it to read and write into 653 00:22:38,650 --> 00:22:40,779 memory and it has repr 654 00:22:40,780 --> 00:22:42,009 around ZENN events. 655 00:22:42,010 --> 00:22:44,079 So it's actually intuitive on how you 656 00:22:44,080 --> 00:22:46,059 need to do like single stepping and 657 00:22:46,060 --> 00:22:48,249 setting up things and it's open source. 658 00:22:48,250 --> 00:22:50,469 So it's our GPL, so we are free to use 659 00:22:50,470 --> 00:22:53,139 it with any project that you 660 00:22:53,140 --> 00:22:54,549 want to implement. 661 00:22:57,000 --> 00:22:58,829 So a little bit more details about how 662 00:22:58,830 --> 00:23:01,049 the actual tracing 663 00:23:01,050 --> 00:23:04,229 happened that we just saw is 664 00:23:04,230 --> 00:23:05,699 I injected a breakpoint into the 665 00:23:05,700 --> 00:23:07,139 accelerator for the attack, which is the 666 00:23:07,140 --> 00:23:08,789 heat fabrication function. 667 00:23:08,790 --> 00:23:10,289 But of course, when that function is 668 00:23:10,290 --> 00:23:11,579 called, the memory is still not 669 00:23:11,580 --> 00:23:13,709 allocated. We need to catch when that 670 00:23:13,710 --> 00:23:14,729 function finished. 671 00:23:14,730 --> 00:23:16,649 So we need to extract the return address 672 00:23:16,650 --> 00:23:17,939 from the stack trap that is. 673 00:23:17,940 --> 00:23:20,339 Well, when the return address is 674 00:23:20,340 --> 00:23:22,619 hit, then we can actually extract the 675 00:23:22,620 --> 00:23:24,320 address where the memory got allocated, 676 00:23:25,410 --> 00:23:27,329 the three key areas that there can be 677 00:23:27,330 --> 00:23:29,639 actually a bunch of different threads 678 00:23:29,640 --> 00:23:30,569 calling this function. 679 00:23:30,570 --> 00:23:32,549 And while using in this function, it can 680 00:23:32,550 --> 00:23:34,169 be complex, which so you need to keep 681 00:23:34,170 --> 00:23:36,299 track of all the colors of 682 00:23:36,300 --> 00:23:38,069 which ones are actually active. 683 00:23:38,070 --> 00:23:39,539 That's when it returns. 684 00:23:39,540 --> 00:23:41,369 You know that, OK, this was the structure 685 00:23:41,370 --> 00:23:43,319 that I was actually waiting for. 686 00:23:43,320 --> 00:23:44,979 And then you know where that structure is 687 00:23:44,980 --> 00:23:46,259 allocated. But it's, of course, at that 688 00:23:46,260 --> 00:23:47,789 point is just a memory address. 689 00:23:47,790 --> 00:23:49,559 Its structure is not initialized or 690 00:23:49,560 --> 00:23:51,659 anything. So now you have to really watch 691 00:23:51,660 --> 00:23:53,939 that memory region as its first, like 692 00:23:53,940 --> 00:23:56,009 being zeroed out and 693 00:23:56,010 --> 00:23:57,569 then slowly updated as the operating 694 00:23:57,570 --> 00:24:00,029 system fills in all the headers 695 00:24:00,030 --> 00:24:01,379 and the information that we really care 696 00:24:01,380 --> 00:24:02,639 about. So, for example, here we would 697 00:24:02,640 --> 00:24:04,919 care about the access to the file 698 00:24:04,920 --> 00:24:05,999 and the file name. 699 00:24:06,000 --> 00:24:08,069 So we just just set up the empty 700 00:24:08,070 --> 00:24:09,070 traps to 701 00:24:10,200 --> 00:24:12,359 monitor as that page is being 702 00:24:12,360 --> 00:24:13,319 updated. 703 00:24:13,320 --> 00:24:14,999 But then, of course, this traps the 704 00:24:15,000 --> 00:24:16,829 entire page that that structure is also 705 00:24:16,830 --> 00:24:18,279 you're going to have unrelated right 706 00:24:18,280 --> 00:24:20,819 events. So there is even more 707 00:24:20,820 --> 00:24:22,919 logic in there and that adds overhead. 708 00:24:22,920 --> 00:24:24,989 But as you could see, it was quite 709 00:24:24,990 --> 00:24:26,309 responsive. You could move the mouse 710 00:24:26,310 --> 00:24:27,819 around and interact with the machine. 711 00:24:27,820 --> 00:24:28,850 So it's not too bad. 712 00:24:31,000 --> 00:24:32,619 What's really cool about, though, about 713 00:24:32,620 --> 00:24:34,779 hip tracing is that some 714 00:24:34,780 --> 00:24:36,879 basic kernel, rootkit mechanisms can 715 00:24:36,880 --> 00:24:38,439 be really sidestepped. 716 00:24:38,440 --> 00:24:40,149 So, for example, directional object 717 00:24:40,150 --> 00:24:41,619 manipulation, which has been around for 718 00:24:41,620 --> 00:24:43,899 10 years, is the idea that 719 00:24:43,900 --> 00:24:46,059 you can break the integrity of kernel 720 00:24:46,060 --> 00:24:47,229 data structures without actually 721 00:24:47,230 --> 00:24:49,089 affecting the execution of the system 722 00:24:49,090 --> 00:24:50,409 where you would have, for example, a 723 00:24:50,410 --> 00:24:53,049 process in this case in the middle 724 00:24:53,050 --> 00:24:55,299 that doesn't want to be found by task 725 00:24:55,300 --> 00:24:56,559 manager or by the user. 726 00:24:56,560 --> 00:24:58,899 And what it would do is unhook itself 727 00:24:58,900 --> 00:25:00,249 from that process list that I actually 728 00:25:00,250 --> 00:25:01,809 showed you in the beginning where I 729 00:25:01,810 --> 00:25:03,579 listed the routing processes. 730 00:25:03,580 --> 00:25:04,679 And that's just the link list. 731 00:25:04,680 --> 00:25:06,309 So if you just switch the pointer out, 732 00:25:06,310 --> 00:25:07,749 the structure will be still in memory, 733 00:25:07,750 --> 00:25:09,069 but you won't be able to find it through 734 00:25:09,070 --> 00:25:10,399 the link list. 735 00:25:10,400 --> 00:25:11,799 But of course, now you keep tracing, you 736 00:25:11,800 --> 00:25:13,249 know, exactly where every structure is 737 00:25:13,250 --> 00:25:14,559 allocated without having to walk the 738 00:25:14,560 --> 00:25:16,779 Lingle's. So who cares if it's on from 739 00:25:16,780 --> 00:25:18,399 here? I know exactly where in memory that 740 00:25:18,400 --> 00:25:20,559 process structure was allocated 741 00:25:20,560 --> 00:25:22,629 and that increases the trust in the data. 742 00:25:22,630 --> 00:25:24,579 And furthermore, I can do some type of 743 00:25:24,580 --> 00:25:26,589 cross validation to see like, OK, I know 744 00:25:26,590 --> 00:25:28,749 this structure gets allocated at this 745 00:25:28,750 --> 00:25:30,079 address, but it's not showing up in 746 00:25:30,080 --> 00:25:31,869 building lists. Well, that's probably 747 00:25:31,870 --> 00:25:32,870 some rootkit. 748 00:25:34,740 --> 00:25:35,819 So let's look at all of the dental. 749 00:25:41,370 --> 00:25:43,169 We are learning processes and of course, 750 00:25:43,170 --> 00:25:45,479 I have pains 751 00:25:45,480 --> 00:25:47,549 running, I cut 752 00:25:47,550 --> 00:25:49,139 down the output so we can actually see 753 00:25:49,140 --> 00:25:50,140 what's happening here. 754 00:25:55,560 --> 00:25:57,419 And what I'm trying to show you here is 755 00:25:57,420 --> 00:25:59,129 that you can really catch any event that 756 00:25:59,130 --> 00:26:00,659 you want. So in this time I wanted to 757 00:26:00,660 --> 00:26:03,029 catch when the file gets deleted, but 758 00:26:03,030 --> 00:26:05,219 before it actually got deleted and 759 00:26:05,220 --> 00:26:06,569 what I did is I actually fired up 760 00:26:06,570 --> 00:26:08,069 volatility and done that found from 761 00:26:08,070 --> 00:26:09,809 memory before the operating system was 762 00:26:09,810 --> 00:26:11,309 actually able to erase it. 763 00:26:11,310 --> 00:26:13,139 So now it's in the temp folder and there 764 00:26:13,140 --> 00:26:15,689 you go. It's actually extracted into the 765 00:26:15,690 --> 00:26:17,759 control domain. So you really have full 766 00:26:17,760 --> 00:26:18,989 access to that virtual machine and you 767 00:26:18,990 --> 00:26:20,159 can reconstruct everything that's 768 00:26:20,160 --> 00:26:22,829 happening within and even extract files. 769 00:26:22,830 --> 00:26:24,959 That verb 770 00:26:24,960 --> 00:26:27,089 in this example closed 771 00:26:27,090 --> 00:26:27,989 and deleted. 772 00:26:27,990 --> 00:26:30,029 But I was able to extract from memory 773 00:26:30,030 --> 00:26:31,679 because Windows doesn't actually delete 774 00:26:31,680 --> 00:26:32,680 it right away. 775 00:26:34,000 --> 00:26:35,229 And this is a very handy when you're 776 00:26:35,230 --> 00:26:36,789 dealing with malware, because a lot of 777 00:26:38,230 --> 00:26:39,729 the time what happens is that you have 778 00:26:39,730 --> 00:26:41,089 right caching enabled on the disk. 779 00:26:41,090 --> 00:26:43,779 So when you actually say save this file, 780 00:26:43,780 --> 00:26:45,369 Windows doesn't actually save it to the 781 00:26:45,370 --> 00:26:47,499 disk right away, just queues it up 782 00:26:47,500 --> 00:26:49,749 and sees rates for a while to 783 00:26:49,750 --> 00:26:51,939 have enough rights it off and 784 00:26:51,940 --> 00:26:54,069 then writing to disk. 785 00:26:54,070 --> 00:26:56,439 So even if I would look at the disk 786 00:26:56,440 --> 00:26:58,329 after I saved the file, I might not even 787 00:26:58,330 --> 00:27:00,249 find it because it's still in memory. 788 00:27:00,250 --> 00:27:01,899 And for malware, this is actually usually 789 00:27:01,900 --> 00:27:03,429 the case because you have temporary files 790 00:27:03,430 --> 00:27:05,139 that the malware dropper extracts and 791 00:27:05,140 --> 00:27:06,699 then loads into memory and then cleans up 792 00:27:06,700 --> 00:27:07,700 after himself. 793 00:27:08,410 --> 00:27:10,479 And you really need to catch the delete 794 00:27:10,480 --> 00:27:12,489 events, otherwise that memory region can 795 00:27:12,490 --> 00:27:14,589 get recycled. So, for example, 796 00:27:14,590 --> 00:27:16,749 what I was doing first is I was 797 00:27:16,750 --> 00:27:18,219 just running some malware samples and 798 00:27:18,220 --> 00:27:19,959 pausing the VM. Then I saw some files 799 00:27:19,960 --> 00:27:21,909 that were interesting and then I tried to 800 00:27:21,910 --> 00:27:23,569 go there a volatility and dump the file. 801 00:27:23,570 --> 00:27:24,969 But of course, the memory already got 802 00:27:24,970 --> 00:27:25,959 recycled. 803 00:27:25,960 --> 00:27:28,329 So there is really a very short time 804 00:27:28,330 --> 00:27:30,279 frame where you can actually catch these 805 00:27:30,280 --> 00:27:31,929 files. So interposition is really 806 00:27:31,930 --> 00:27:33,579 critical if you want to do malware 807 00:27:33,580 --> 00:27:34,580 analysis. 808 00:27:36,170 --> 00:27:37,479 Let's look at all of them. 809 00:27:37,480 --> 00:27:38,480 That was a fun. 810 00:27:40,250 --> 00:27:42,709 So this time I have Windows seven, 64 811 00:27:42,710 --> 00:27:43,710 bit. 812 00:27:44,560 --> 00:27:46,779 And there is some information about it, 813 00:27:46,780 --> 00:27:48,910 but it's 64 bit Windows seven. 814 00:27:51,680 --> 00:27:53,989 And there are all the processes running, 815 00:27:53,990 --> 00:27:55,369 and as you can see, there is a task 816 00:27:55,370 --> 00:27:57,739 manager to three, six, four, 817 00:27:57,740 --> 00:27:59,839 and what are going to showing this demo 818 00:27:59,840 --> 00:28:01,489 is how you can actually take full control 819 00:28:01,490 --> 00:28:03,199 of that virtual machine, not just extract 820 00:28:03,200 --> 00:28:04,699 files and monitor passively what's 821 00:28:04,700 --> 00:28:06,359 happening. So, for example, what they're 822 00:28:06,360 --> 00:28:07,909 going to do here is actually hijack the 823 00:28:07,910 --> 00:28:09,889 task manager to start a calculator for me 824 00:28:09,890 --> 00:28:11,809 between the virtual machine, which is 825 00:28:11,810 --> 00:28:13,309 quite great because I didn't have to 826 00:28:13,310 --> 00:28:14,749 install any custom software within the 827 00:28:14,750 --> 00:28:16,429 virtual machine to take control of that. 828 00:28:16,430 --> 00:28:18,529 I just need any process that is executing 829 00:28:18,530 --> 00:28:20,029 with it in its future machine. 830 00:28:20,030 --> 00:28:21,739 And I can do whatever I want. 831 00:28:21,740 --> 00:28:24,469 No passwords, ask no username. 832 00:28:24,470 --> 00:28:26,029 Really. You have full control, right? 833 00:28:26,030 --> 00:28:28,429 That's what being in a more privileged 834 00:28:28,430 --> 00:28:30,019 level of the system actually means. 835 00:28:31,160 --> 00:28:33,549 And yes, you can fire up, command 836 00:28:33,550 --> 00:28:35,809 the and pass whatever arguments 837 00:28:35,810 --> 00:28:36,810 you want to it. 838 00:28:37,550 --> 00:28:39,289 And as you can see, I actually get the 839 00:28:39,290 --> 00:28:40,249 return value as well. 840 00:28:40,250 --> 00:28:42,299 So I know what the PIV of that process 841 00:28:42,300 --> 00:28:43,879 that got created is. 842 00:28:43,880 --> 00:28:45,739 So if you want to execute some function 843 00:28:45,740 --> 00:28:46,849 within that virtual machine, you can 844 00:28:46,850 --> 00:28:48,379 actually extract the output of that and 845 00:28:48,380 --> 00:28:49,639 then you can just pipe this together. 846 00:28:49,640 --> 00:28:51,139 So you have a like an external shell for 847 00:28:51,140 --> 00:28:52,369 that virtual machine effectively. 848 00:28:54,810 --> 00:28:55,919 So now what they're going to do is actually 849 00:28:55,920 --> 00:28:57,449 just fire up Internet Explorer and send 850 00:28:57,450 --> 00:28:59,640 it to some websites of my choice. 851 00:29:01,510 --> 00:29:02,640 And there we go, 852 00:29:04,180 --> 00:29:05,619 the virtual machine just happily does 853 00:29:05,620 --> 00:29:07,629 that, and it's pretty much instantaneous, 854 00:29:07,630 --> 00:29:09,189 so I really can't control what the 855 00:29:09,190 --> 00:29:10,379 virtual machine is doing. 856 00:29:10,380 --> 00:29:11,949 So if you're like a sysadmin, this is 857 00:29:11,950 --> 00:29:12,879 great. 858 00:29:12,880 --> 00:29:15,099 You can install software 859 00:29:15,100 --> 00:29:16,629 within the virtual machine, close 860 00:29:16,630 --> 00:29:18,969 processes, really whatever you want. 861 00:29:22,520 --> 00:29:24,050 So all the demos that I showed you 862 00:29:25,430 --> 00:29:27,679 are actually part of a Malvika 863 00:29:27,680 --> 00:29:29,839 analysis system that I built for my 864 00:29:29,840 --> 00:29:32,059 PFG, which is, as I said, built 865 00:29:32,060 --> 00:29:34,339 on like VMI volatility and recall, 866 00:29:34,340 --> 00:29:35,689 and it's released for free for you. 867 00:29:35,690 --> 00:29:38,539 So all of these demos and tools are now 868 00:29:38,540 --> 00:29:39,540 yours to play with. 869 00:29:49,850 --> 00:29:51,409 And again, the important thing here is 870 00:29:51,410 --> 00:29:53,059 that for our analysis, you really don't 871 00:29:53,060 --> 00:29:54,949 want to have anything identifiable within 872 00:29:54,950 --> 00:29:56,299 the virtual machine that you are running 873 00:29:56,300 --> 00:29:57,619 in, because that's what Melder usually 874 00:29:57,620 --> 00:29:59,479 looks for. So if you have the winningest 875 00:29:59,480 --> 00:30:00,739 agents, you don't have any guest 876 00:30:00,740 --> 00:30:02,179 artifacts that nobody can look for. 877 00:30:02,180 --> 00:30:03,449 And then you have a more stealthy 878 00:30:03,450 --> 00:30:05,389 environment to do your analysis in. 879 00:30:05,390 --> 00:30:07,369 And, of course, you can extract all the 880 00:30:07,370 --> 00:30:09,829 temporal files that you would otherwise 881 00:30:09,830 --> 00:30:10,830 miss. 882 00:30:12,920 --> 00:30:14,569 And OpenOffice just crashed. 883 00:30:24,960 --> 00:30:27,050 Doesn't really like and better than most. 884 00:30:32,770 --> 00:30:34,109 Not at all that I wanted to bring your 885 00:30:34,110 --> 00:30:35,939 attention to, which is really just fresh 886 00:30:35,940 --> 00:30:37,650 out of the oven, is. 887 00:30:39,020 --> 00:30:40,189 Debugger, integration. 888 00:30:40,190 --> 00:30:42,139 So, as I said, all of the features built 889 00:30:42,140 --> 00:30:43,639 in December really designed for 890 00:30:43,640 --> 00:30:45,829 debugging, so why not use some 891 00:30:45,830 --> 00:30:47,719 of your favorite debuggers in this case, 892 00:30:47,720 --> 00:30:48,709 gdb? 893 00:30:48,710 --> 00:30:50,839 So this should be online by now? 894 00:30:50,840 --> 00:30:52,309 I haven't actually had a chance to 895 00:30:53,480 --> 00:30:55,669 test it, but this 896 00:30:55,670 --> 00:30:56,869 has just been released. 897 00:30:56,870 --> 00:30:58,669 So this allows for stealthy debugging 898 00:30:58,670 --> 00:31:00,709 using the hypervisor and you can really 899 00:31:00,710 --> 00:31:01,949 debug your operating system. 900 00:31:01,950 --> 00:31:03,549 So if you are developing a kernel driver 901 00:31:03,550 --> 00:31:05,929 or whatever, this is really handy. 902 00:31:05,930 --> 00:31:07,849 And of course we can add debug 903 00:31:07,850 --> 00:31:09,739 integration, which is coming next. 904 00:31:09,740 --> 00:31:11,359 So go check this one out to. 905 00:31:14,360 --> 00:31:16,189 So let's go back to isolation real quick. 906 00:31:16,190 --> 00:31:18,349 So now what we did actually is we moved 907 00:31:18,350 --> 00:31:20,719 a lot of the security 908 00:31:20,720 --> 00:31:22,429 stack out of the virtual machine and we 909 00:31:22,430 --> 00:31:24,259 can do a lot of that. 910 00:31:24,260 --> 00:31:26,329 But what that really does achieves 911 00:31:26,330 --> 00:31:28,489 is just moving the target 912 00:31:28,490 --> 00:31:30,649 exploit is getting harder 913 00:31:30,650 --> 00:31:32,209 because you have hypervisor based 914 00:31:32,210 --> 00:31:33,109 isolation. 915 00:31:33,110 --> 00:31:34,369 But of course, now you're running in a 916 00:31:34,370 --> 00:31:36,449 more privileged part of the system. 917 00:31:36,450 --> 00:31:38,390 So if you actually manage to break out 918 00:31:39,680 --> 00:31:41,959 using the same 919 00:31:41,960 --> 00:31:43,639 vulnerability potentially in the security 920 00:31:43,640 --> 00:31:45,589 tool, then you have a bigger reward. 921 00:31:45,590 --> 00:31:46,909 And it's not like it doesn't happen. 922 00:31:46,910 --> 00:31:48,619 I mean, there was just a couple of weeks 923 00:31:48,620 --> 00:31:50,869 ago, a month ago, local 924 00:31:50,870 --> 00:31:52,669 privilege escalation in OSX, which is a 925 00:31:52,670 --> 00:31:54,179 host based intrusion detection system. 926 00:31:54,180 --> 00:31:55,609 So it's kind of naive to think that our 927 00:31:55,610 --> 00:31:58,039 system wouldn't have any vulnerabilities. 928 00:31:58,040 --> 00:32:00,589 So why not separate 929 00:32:00,590 --> 00:32:02,659 the security stack into 930 00:32:02,660 --> 00:32:05,269 also deeply religious machines 931 00:32:05,270 --> 00:32:07,579 and then has some features to achieve 932 00:32:07,580 --> 00:32:10,699 that? And that's the security modules. 933 00:32:10,700 --> 00:32:13,189 And what that allows is to 934 00:32:13,190 --> 00:32:15,229 really disaggregate the trusted computing 935 00:32:15,230 --> 00:32:17,699 base that you use with an. 936 00:32:17,700 --> 00:32:19,769 So you don't have to put the security 937 00:32:19,770 --> 00:32:21,419 stack with Indonesia, as I did in the 938 00:32:21,420 --> 00:32:22,889 demos here, but you can actually create a 939 00:32:22,890 --> 00:32:24,989 virtual machine that has control over 940 00:32:24,990 --> 00:32:26,879 a set of domains that you want to protect 941 00:32:26,880 --> 00:32:28,319 or just maybe a single domain that you 942 00:32:28,320 --> 00:32:29,969 want to protect without affecting 943 00:32:29,970 --> 00:32:31,130 anything else on the system. 944 00:32:32,180 --> 00:32:33,859 The way it works is. 945 00:32:36,330 --> 00:32:38,399 It creates a wrapper around hyper calls 946 00:32:38,400 --> 00:32:39,839 and has a policy to. 947 00:32:41,670 --> 00:32:43,349 Define how the interaction between 948 00:32:43,350 --> 00:32:44,880 domains can happen. 949 00:32:46,230 --> 00:32:48,569 This is actually a piece of software 950 00:32:48,570 --> 00:32:49,949 that has been contributed and maintained 951 00:32:49,950 --> 00:32:52,619 by the NSA then, and they 952 00:32:52,620 --> 00:32:53,669 have a bad reputation. 953 00:32:53,670 --> 00:32:55,559 But in this sense, they actually do some 954 00:32:55,560 --> 00:32:57,089 positive work as well, because without 955 00:32:57,090 --> 00:32:58,649 their work, it would not be possible to 956 00:32:58,650 --> 00:32:59,650 do this. 957 00:33:00,560 --> 00:33:02,059 As I said, what it does is actually a 958 00:33:02,060 --> 00:33:03,589 report on hyper calls and then you have 959 00:33:03,590 --> 00:33:06,109 the flash policy engine where you define 960 00:33:06,110 --> 00:33:08,269 which virtual machine can do 961 00:33:08,270 --> 00:33:10,129 what I recall and what the target is or 962 00:33:10,130 --> 00:33:11,119 that type of call is. 963 00:33:11,120 --> 00:33:12,739 And in that sense, it's very similar to 964 00:33:12,740 --> 00:33:15,019 Linux. You can use the same tools to 965 00:33:15,020 --> 00:33:16,639 find your policy already to allow and 966 00:33:16,640 --> 00:33:17,839 check policy. 967 00:33:17,840 --> 00:33:19,519 And it's disabled by default. 968 00:33:19,520 --> 00:33:21,589 But I mean, that's you can 969 00:33:21,590 --> 00:33:23,989 recompile and then have this. 970 00:33:23,990 --> 00:33:25,549 But really, it's only usable from Zank 971 00:33:25,550 --> 00:33:26,869 four point three on Linux, three point 972 00:33:26,870 --> 00:33:28,009 eight. 973 00:33:28,010 --> 00:33:29,359 So that was actually my first batch of 974 00:33:29,360 --> 00:33:31,699 Linux and three point eight when we were 975 00:33:31,700 --> 00:33:33,599 actually testing an early version of the 976 00:33:33,600 --> 00:33:34,939 system. 977 00:33:34,940 --> 00:33:36,649 That was not an original design yet. 978 00:33:36,650 --> 00:33:38,569 And we discovered that the Linux kernel 979 00:33:38,570 --> 00:33:40,879 actually did some excess control 980 00:33:40,880 --> 00:33:43,099 checks itself to see if it is Bamsey 981 00:33:43,100 --> 00:33:45,439 or not. And if it wasn't M0, 982 00:33:45,440 --> 00:33:47,569 it would deny issuing the hyper 983 00:33:47,570 --> 00:33:49,219 calls that we needed to do this type of 984 00:33:49,220 --> 00:33:50,220 security. 985 00:33:51,170 --> 00:33:52,789 Of course, if you have access and 986 00:33:52,790 --> 00:33:54,589 defining what is allowed and what isn't, 987 00:33:54,590 --> 00:33:56,059 you don't need the kernel to tell you 988 00:33:56,060 --> 00:33:57,979 that. And furthermore, that's really an 989 00:33:57,980 --> 00:33:58,939 arbitrary check. 990 00:33:58,940 --> 00:34:01,129 If you have the rights to 991 00:34:01,130 --> 00:34:03,409 do insert kernel modules 992 00:34:03,410 --> 00:34:05,719 within your kernel, then having 993 00:34:05,720 --> 00:34:07,519 a security check there is really not 994 00:34:07,520 --> 00:34:09,649 going to get you much. So 995 00:34:09,650 --> 00:34:11,839 my patch was really just removing that 996 00:34:11,840 --> 00:34:12,840 surplus check. 997 00:34:14,639 --> 00:34:15,928 And now with these tools, we can actually 998 00:34:15,929 --> 00:34:17,669 start thinking about cloud security. 999 00:34:17,670 --> 00:34:19,859 So we have a mechanism 1000 00:34:19,860 --> 00:34:22,468 to have different security policy 1001 00:34:22,469 --> 00:34:24,468 for different users of that cloud. 1002 00:34:25,800 --> 00:34:27,959 And the idea would be, is that 1003 00:34:27,960 --> 00:34:29,729 we start monitoring of your machine 1004 00:34:29,730 --> 00:34:31,439 before it goes live, so we have some sort 1005 00:34:31,440 --> 00:34:32,829 of baseline of integrity in that. 1006 00:34:32,830 --> 00:34:35,189 OK, this is my backbite hasn't been 1007 00:34:35,190 --> 00:34:36,089 released on the net. 1008 00:34:36,090 --> 00:34:38,218 So I start monitoring and 1009 00:34:38,219 --> 00:34:39,959 we can see if some critical data 1010 00:34:39,960 --> 00:34:42,029 structures get hijacked or 1011 00:34:42,030 --> 00:34:43,559 maybe even then the code, if there are 1012 00:34:43,560 --> 00:34:45,569 any inline hooks being injected, we can 1013 00:34:45,570 --> 00:34:47,789 detect that and we can really 1014 00:34:47,790 --> 00:34:49,649 just limit what we are trusting in the 1015 00:34:49,650 --> 00:34:52,109 data to stuff that is 1016 00:34:52,110 --> 00:34:54,509 defined by the hardware, because 1017 00:34:54,510 --> 00:34:56,698 if malware changes 1018 00:34:56,699 --> 00:34:58,709 those structures, the most that they can 1019 00:34:58,710 --> 00:34:59,909 achieve is dossing the system. 1020 00:34:59,910 --> 00:35:01,319 So they probably won't touch it if they 1021 00:35:01,320 --> 00:35:03,719 have some better use of that machine. 1022 00:35:06,210 --> 00:35:07,859 But we are back at what data can we 1023 00:35:07,860 --> 00:35:09,150 really trust in the system? 1024 00:35:10,200 --> 00:35:11,909 So, for example, with the events that I 1025 00:35:11,910 --> 00:35:14,039 showed you with EPT violations, there's 1026 00:35:14,040 --> 00:35:15,509 already some limitations in what the 1027 00:35:15,510 --> 00:35:17,579 hardware tells us and there 1028 00:35:17,580 --> 00:35:18,959 are Cordner cases. So, for example, 1029 00:35:18,960 --> 00:35:21,089 remodify right instructions which 1030 00:35:21,090 --> 00:35:23,189 involve destruction from memory 1031 00:35:23,190 --> 00:35:25,259 and then right back to memory, which is 1032 00:35:25,260 --> 00:35:27,359 usually used for mutex isn't concurrency 1033 00:35:27,360 --> 00:35:28,360 stuff. 1034 00:35:29,090 --> 00:35:30,979 The Intel manual says that while it's 1035 00:35:30,980 --> 00:35:32,969 really implementation specific, Venerates 1036 00:35:32,970 --> 00:35:35,069 says the redbait, so these were 1037 00:35:35,070 --> 00:35:36,199 all they said the right bit. 1038 00:35:36,200 --> 00:35:37,729 But Vatterott says the redebate, it's 1039 00:35:37,730 --> 00:35:39,439 well, we don't know what happens. 1040 00:35:39,440 --> 00:35:41,280 So that's not really cool. 1041 00:35:42,350 --> 00:35:44,429 We actually back patch 1042 00:35:44,430 --> 00:35:45,979 that in zone four point five, which will 1043 00:35:45,980 --> 00:35:47,299 be released next month. 1044 00:35:47,300 --> 00:35:49,099 But there are ambiguities and there's a 1045 00:35:49,100 --> 00:35:50,839 lot of ambiguities like that in the Intel 1046 00:35:50,840 --> 00:35:52,159 manual. So we actually wrote a paper 1047 00:35:52,160 --> 00:35:53,359 about collecting all of these. 1048 00:35:53,360 --> 00:35:55,549 And these are just really some of 1049 00:35:55,550 --> 00:35:56,659 what the limitations are. 1050 00:35:57,800 --> 00:35:59,629 A bigger limitation is really the tagged 1051 00:35:59,630 --> 00:36:01,279 translation leukocyte buffer, which was 1052 00:36:01,280 --> 00:36:03,409 introduced in 2008 both by Intel 1053 00:36:03,410 --> 00:36:04,410 and Andy. 1054 00:36:05,490 --> 00:36:07,919 Which essentially cashes the 1055 00:36:07,920 --> 00:36:09,749 translation of all the physical addresses 1056 00:36:09,750 --> 00:36:11,939 into a cash that you 1057 00:36:11,940 --> 00:36:13,709 cannot query, it's really just for the 1058 00:36:13,710 --> 00:36:15,869 hardware to speed the translation 1059 00:36:15,870 --> 00:36:16,870 up. 1060 00:36:17,560 --> 00:36:19,809 And now if you have a tactlessly, that 1061 00:36:19,810 --> 00:36:22,149 means that the labels 1062 00:36:22,150 --> 00:36:24,369 don't necessarily represent what 1063 00:36:24,370 --> 00:36:26,769 translation the guest actually use it. 1064 00:36:26,770 --> 00:36:28,929 So what we do with VMI is we look at 1065 00:36:28,930 --> 00:36:30,849 the labels in memory and the emulate what 1066 00:36:30,850 --> 00:36:32,439 the hardware does, but we don't have 1067 00:36:32,440 --> 00:36:34,420 access to this cache, which is a problem. 1068 00:36:37,370 --> 00:36:39,149 Because we detective about the cash, the 1069 00:36:39,150 --> 00:36:41,899 entries, survivor visit, even entry, 1070 00:36:41,900 --> 00:36:44,989 so these are actually persistent 1071 00:36:44,990 --> 00:36:45,990 Tibey entries 1072 00:36:47,120 --> 00:36:48,619 and that means that the route potentially 1073 00:36:48,620 --> 00:36:50,089 can mocksville the page tables in the 1074 00:36:50,090 --> 00:36:51,439 guest without actually crashing the 1075 00:36:51,440 --> 00:36:53,179 guest. And we would have no idea what 1076 00:36:53,180 --> 00:36:55,309 it's doing because it can set up the page 1077 00:36:55,310 --> 00:36:57,439 table to point into some benign 1078 00:36:57,440 --> 00:36:58,819 code called region. 1079 00:36:58,820 --> 00:37:00,199 And when we try to see what code is 1080 00:37:00,200 --> 00:37:01,429 actually running, we see that, oh, it's 1081 00:37:01,430 --> 00:37:03,199 calculator, it's no problem. 1082 00:37:03,200 --> 00:37:05,359 But what machine is actually executing 1083 00:37:05,360 --> 00:37:06,489 is something totally different. 1084 00:37:08,190 --> 00:37:09,719 Of course, there's some limitations to 1085 00:37:09,720 --> 00:37:12,269 that, so depending on what hypervisor 1086 00:37:12,270 --> 00:37:13,409 and guess the operating system you're 1087 00:37:13,410 --> 00:37:15,509 running. So, for example, Zain always 1088 00:37:15,510 --> 00:37:17,909 assigns a new tag whenever the schedule 1089 00:37:17,910 --> 00:37:19,979 is a new process. So you would have to do 1090 00:37:19,980 --> 00:37:22,499 some malicious modifications 1091 00:37:22,500 --> 00:37:23,639 to the page through essentially every 1092 00:37:23,640 --> 00:37:25,379 time a new process is scheduled. 1093 00:37:25,380 --> 00:37:27,699 So we might be able to detect 1094 00:37:27,700 --> 00:37:29,999 that. And Windows seven, surprisingly, 1095 00:37:30,000 --> 00:37:31,409 is actually pretty good against this 1096 00:37:31,410 --> 00:37:33,149 because it always flushes the global 1097 00:37:33,150 --> 00:37:36,299 pages very regularly. 1098 00:37:36,300 --> 00:37:38,379 But if you're running Linux on Cavium, 1099 00:37:38,380 --> 00:37:40,550 well, this is a more realistic problem. 1100 00:37:43,650 --> 00:37:44,939 Well, if you think about cloud security 1101 00:37:44,940 --> 00:37:46,589 for a moment here, there is really no 1102 00:37:46,590 --> 00:37:48,089 need to move everything out from the 1103 00:37:48,090 --> 00:37:49,679 virtual machine. So with malware 1104 00:37:49,680 --> 00:37:51,209 analysis, there was a reason you don't 1105 00:37:51,210 --> 00:37:52,979 want to have any artifacts within the gas 1106 00:37:52,980 --> 00:37:54,509 that it can detect and shut down really 1107 00:37:54,510 --> 00:37:55,919 quickly. 1108 00:37:55,920 --> 00:37:58,349 But with cloud security, 1109 00:37:58,350 --> 00:38:00,209 we want the malware to stop executing as 1110 00:38:00,210 --> 00:38:01,199 fast as it wants. 1111 00:38:01,200 --> 00:38:03,029 Right. We don't want it to stay alive. 1112 00:38:03,030 --> 00:38:05,159 So maybe it's enough to 1113 00:38:05,160 --> 00:38:07,559 have some sort of security agent 1114 00:38:07,560 --> 00:38:10,049 that we can protect from the hypervisor 1115 00:38:10,050 --> 00:38:12,179 level. But it would have 1116 00:38:12,180 --> 00:38:14,009 better performance and better visibility 1117 00:38:14,010 --> 00:38:15,329 into the system because it's running in 1118 00:38:15,330 --> 00:38:17,329 the same context as the machines. 1119 00:38:17,330 --> 00:38:19,509 So detective problem doesn't exist for 1120 00:38:19,510 --> 00:38:20,879 investigations. 1121 00:38:20,880 --> 00:38:22,829 So we can do some sort of hybrid approach 1122 00:38:22,830 --> 00:38:25,019 potentially. And this is actually where 1123 00:38:25,020 --> 00:38:26,729 the hardware is heading. 1124 00:38:26,730 --> 00:38:29,129 So in the upcoming Intel CPU's, 1125 00:38:29,130 --> 00:38:30,269 there is going to be this extension 1126 00:38:30,270 --> 00:38:32,399 called Intel View or 1127 00:38:32,400 --> 00:38:34,259 where virtualization exceptions, where 1128 00:38:34,260 --> 00:38:36,149 you can actually track the NPT violations 1129 00:38:36,150 --> 00:38:38,069 within the gas so you don't have to trap 1130 00:38:38,070 --> 00:38:40,289 out all the time into the hypervisor. 1131 00:38:40,290 --> 00:38:41,789 So you will have really better 1132 00:38:41,790 --> 00:38:43,349 performance and then you can do some sort 1133 00:38:43,350 --> 00:38:44,849 of protection of that code that's running 1134 00:38:44,850 --> 00:38:45,959 within the system. 1135 00:38:45,960 --> 00:38:47,309 And as I showed you, you can really 1136 00:38:47,310 --> 00:38:48,629 control what that system is doing. 1137 00:38:48,630 --> 00:38:50,369 So you can not just control the code, but 1138 00:38:50,370 --> 00:38:52,259 you can also control the beta. 1139 00:38:52,260 --> 00:38:54,049 So you really can achieve securing 1140 00:38:54,050 --> 00:38:55,050 agents. 1141 00:38:56,230 --> 00:38:57,629 What our approach would be for cloud 1142 00:38:57,630 --> 00:38:59,579 security is to really just reduce the 1143 00:38:59,580 --> 00:39:00,989 size of the guest operating system. 1144 00:39:00,990 --> 00:39:02,669 There's really no reason you need a full 1145 00:39:02,670 --> 00:39:04,979 Linux stack in your operating 1146 00:39:04,980 --> 00:39:06,509 system that just serves Apache. 1147 00:39:06,510 --> 00:39:08,489 Right. So there are some risks in that 1148 00:39:08,490 --> 00:39:10,379 direction. So just in this Congress, we 1149 00:39:10,380 --> 00:39:12,569 saw a mirage or was but there is also not 1150 00:39:12,570 --> 00:39:14,639 from colonels and OS, which really just 1151 00:39:14,640 --> 00:39:15,959 try to achieve that. 1152 00:39:15,960 --> 00:39:18,119 That reduces a virtual machine into 1153 00:39:18,120 --> 00:39:19,559 a process and then just use the 1154 00:39:19,560 --> 00:39:21,509 hypervisor as your scheduler. 1155 00:39:21,510 --> 00:39:23,009 Just kind of ironic if you think about 1156 00:39:23,010 --> 00:39:25,229 it, because processes back 1157 00:39:25,230 --> 00:39:26,429 in the day when they were introduced, 1158 00:39:26,430 --> 00:39:28,709 they were called virtual machines and now 1159 00:39:28,710 --> 00:39:30,479 we would have virtual machines becoming 1160 00:39:30,480 --> 00:39:32,369 processes again. So we are kind of going 1161 00:39:32,370 --> 00:39:33,370 in a loop here. 1162 00:39:37,440 --> 00:39:39,129 But also, we could try to secure the 1163 00:39:39,130 --> 00:39:40,949 Angus kernel, because what we have 1164 00:39:40,950 --> 00:39:42,389 actually been discussing goes forward, 1165 00:39:42,390 --> 00:39:44,609 the blacklist approach, we look at 1166 00:39:44,610 --> 00:39:46,019 what malicious changes happen to the 1167 00:39:46,020 --> 00:39:48,029 system and we try to deny that. 1168 00:39:48,030 --> 00:39:49,769 But that, of course, places the burden on 1169 00:39:49,770 --> 00:39:51,719 the defendant to enumerate all the 1170 00:39:51,720 --> 00:39:53,579 possible things that could go wrong. 1171 00:39:53,580 --> 00:39:55,269 Well, good luck trying to do that. 1172 00:39:55,270 --> 00:39:56,999 So now I'm going to hand over to Tom to 1173 00:39:57,000 --> 00:39:58,499 talk about the whitelist approach, which 1174 00:39:58,500 --> 00:39:59,730 might be a better alternative. 1175 00:40:00,930 --> 00:40:01,930 Yeah. So 1176 00:40:03,210 --> 00:40:05,699 if you want to verify the integrity 1177 00:40:05,700 --> 00:40:07,409 of the system, which we have to to run 1178 00:40:07,410 --> 00:40:09,599 our youngest agents and we have to 1179 00:40:10,770 --> 00:40:12,929 see what the kernel 1180 00:40:12,930 --> 00:40:15,059 is in the system and whether 1181 00:40:15,060 --> 00:40:17,129 it's changed by malware 1182 00:40:17,130 --> 00:40:19,469 or not. So what we propose 1183 00:40:19,470 --> 00:40:21,839 is a whitelist approach that 1184 00:40:21,840 --> 00:40:24,299 would allow verified 1185 00:40:24,300 --> 00:40:26,579 changes within the system 1186 00:40:26,580 --> 00:40:27,580 to the kernel. 1187 00:40:29,270 --> 00:40:31,799 So for that, we need to validate 1188 00:40:31,800 --> 00:40:34,559 and see all the changes 1189 00:40:34,560 --> 00:40:36,899 in the system that we 1190 00:40:36,900 --> 00:40:38,279 want to allow. 1191 00:40:38,280 --> 00:40:40,679 So code integrity 1192 00:40:40,680 --> 00:40:42,749 basically is assumed to be an 1193 00:40:42,750 --> 00:40:44,939 easy thing. You have the code which 1194 00:40:44,940 --> 00:40:46,889 from your binary, from your kernel, you 1195 00:40:46,890 --> 00:40:49,169 hash that and you compare the hashes. 1196 00:40:49,170 --> 00:40:51,299 If it's matched, then the kernel 1197 00:40:51,300 --> 00:40:53,669 is or the integrity 1198 00:40:53,670 --> 00:40:55,949 is there, but actually 1199 00:40:55,950 --> 00:40:58,409 lets employees runtime patching 1200 00:40:58,410 --> 00:41:00,749 or runtime self code patching 1201 00:41:00,750 --> 00:41:01,750 to 1202 00:41:03,690 --> 00:41:05,879 have performance 1203 00:41:05,880 --> 00:41:08,309 optimizations within the system. 1204 00:41:08,310 --> 00:41:10,379 So for that, if 1205 00:41:10,380 --> 00:41:12,149 you run a Linux kernel, you now have to 1206 00:41:12,150 --> 00:41:14,459 differentiate between legitimate and 1207 00:41:14,460 --> 00:41:16,889 malicious changes to your software. 1208 00:41:16,890 --> 00:41:18,959 So there are two kinds of 1209 00:41:18,960 --> 00:41:21,119 changes that are 1210 00:41:21,120 --> 00:41:22,649 done by the Linux kernel. 1211 00:41:22,650 --> 00:41:24,659 So for the one thing, there are the easy 1212 00:41:24,660 --> 00:41:26,879 load time patching things out. 1213 00:41:26,880 --> 00:41:29,579 The easiest thing is the reallocations, 1214 00:41:29,580 --> 00:41:32,369 which or alternative instructions 1215 00:41:32,370 --> 00:41:34,169 which are architecture specific. 1216 00:41:34,170 --> 00:41:36,479 So dependent on the CPU, 1217 00:41:36,480 --> 00:41:38,549 the systems running are 1218 00:41:38,550 --> 00:41:39,609 dependent on the hypervisor. 1219 00:41:39,610 --> 00:41:40,919 The system is running. 1220 00:41:40,920 --> 00:41:42,659 There are different instructions patched 1221 00:41:42,660 --> 00:41:45,059 into the code of the system. 1222 00:41:45,060 --> 00:41:47,069 So depending on the hypervisor, for 1223 00:41:47,070 --> 00:41:49,409 example, some function can be implemented 1224 00:41:49,410 --> 00:41:50,879 that way or another one. 1225 00:41:50,880 --> 00:41:53,129 So but you can say, yeah, 1226 00:41:53,130 --> 00:41:54,869 load time patching can be handled by 1227 00:41:54,870 --> 00:41:56,399 loading the kernel in a secure 1228 00:41:56,400 --> 00:41:58,109 environment on the same architecture 1229 00:41:58,110 --> 00:42:00,449 maybe, and creating a hash. 1230 00:42:00,450 --> 00:42:02,489 And we still have no problem. 1231 00:42:02,490 --> 00:42:04,019 But on the other hand, we also have 1232 00:42:04,020 --> 00:42:06,359 runtime patching employed by the kernel, 1233 00:42:06,360 --> 00:42:08,789 which is, for example, employed for 1234 00:42:08,790 --> 00:42:10,229 hardware hotdogging. 1235 00:42:10,230 --> 00:42:12,419 But this has to be validated 1236 00:42:12,420 --> 00:42:14,699 and verified continuously as 1237 00:42:14,700 --> 00:42:15,880 the system is going on. 1238 00:42:16,950 --> 00:42:19,679 So I want to show you two examples 1239 00:42:19,680 --> 00:42:21,689 where this is actually applied in the 1240 00:42:21,690 --> 00:42:22,709 current Linux kernel. 1241 00:42:22,710 --> 00:42:24,929 So, for example, S&P, WLOX 1242 00:42:24,930 --> 00:42:26,729 is one of those mechanisms. 1243 00:42:26,730 --> 00:42:29,399 So currently, if you have 1244 00:42:29,400 --> 00:42:32,219 a virtualization on a system 1245 00:42:32,220 --> 00:42:34,049 and you need scalability, the number of 1246 00:42:34,050 --> 00:42:36,209 actual CPUs that 1247 00:42:36,210 --> 00:42:38,819 are allocated to the virtual machine 1248 00:42:38,820 --> 00:42:41,069 may change during runtime. 1249 00:42:41,070 --> 00:42:43,379 So this gives a problem 1250 00:42:43,380 --> 00:42:46,229 because if you have a single threaded 1251 00:42:46,230 --> 00:42:48,339 operating system and you have 1252 00:42:48,340 --> 00:42:50,879 four locks, then you don't have to 1253 00:42:50,880 --> 00:42:51,880 like 1254 00:42:53,550 --> 00:42:55,619 Midcity of that lock because you have 1255 00:42:55,620 --> 00:42:57,239 only one CPU anyway. 1256 00:42:57,240 --> 00:42:59,489 This changes if you have multiple 1257 00:42:59,490 --> 00:43:01,979 CPUs, because then you really 1258 00:43:01,980 --> 00:43:04,649 need atomic operations 1259 00:43:04,650 --> 00:43:06,269 and for performance reasons. 1260 00:43:06,270 --> 00:43:08,369 If only one CPU is present in the 1261 00:43:08,370 --> 00:43:10,529 system, the Linux kernel does not 1262 00:43:10,530 --> 00:43:12,599 use those atomic operations. 1263 00:43:12,600 --> 00:43:14,759 But instead what it does is when 1264 00:43:14,760 --> 00:43:16,649 another CPU comes to the system, you 1265 00:43:16,650 --> 00:43:18,779 automatically patris all those locations 1266 00:43:18,780 --> 00:43:22,049 in its code to atomic operations, 1267 00:43:22,050 --> 00:43:24,119 which are 1268 00:43:24,120 --> 00:43:26,759 slower then but required in that 1269 00:43:26,760 --> 00:43:28,949 place. And also this mechanism can 1270 00:43:28,950 --> 00:43:31,529 also be used to replace entire 1271 00:43:31,530 --> 00:43:33,179 functions within the Linux kernel. 1272 00:43:33,180 --> 00:43:35,699 It's currently not used as that, but 1273 00:43:35,700 --> 00:43:37,739 the mechanism is basically there. 1274 00:43:37,740 --> 00:43:40,199 And another thing where runtime 1275 00:43:40,200 --> 00:43:42,149 patching occurs in the Linux kernel, for 1276 00:43:42,150 --> 00:43:44,219 example, there is a mechanism 1277 00:43:44,220 --> 00:43:46,559 called jump labels, which is equally 1278 00:43:46,560 --> 00:43:48,089 for performance reasons. 1279 00:43:48,090 --> 00:43:50,159 So you have something, some 1280 00:43:50,160 --> 00:43:52,919 checks in the Linux kernel that will 1281 00:43:52,920 --> 00:43:54,389 be unlikely passed. 1282 00:43:54,390 --> 00:43:56,609 So other than just 1283 00:43:56,610 --> 00:43:58,409 checking constantly, you know, is it an 1284 00:43:58,410 --> 00:43:59,579 unlikely case as of now? 1285 00:43:59,580 --> 00:44:02,249 An unlikely case, you just patch out the 1286 00:44:02,250 --> 00:44:04,889 jump to a certain code 1287 00:44:04,890 --> 00:44:07,139 snippets out of there. 1288 00:44:07,140 --> 00:44:10,019 But once those functionalities 1289 00:44:10,020 --> 00:44:12,239 are enabled, for example, by a user 1290 00:44:12,240 --> 00:44:15,389 or by any hardware mechanism or whatever, 1291 00:44:15,390 --> 00:44:17,669 the Linux kernel just patches 1292 00:44:17,670 --> 00:44:19,799 the jumps into the code 1293 00:44:19,800 --> 00:44:22,259 to the function that should be executed. 1294 00:44:22,260 --> 00:44:24,779 And with that, we 1295 00:44:24,780 --> 00:44:27,029 have the additional problem that we don't 1296 00:44:27,030 --> 00:44:29,699 have only like two possibilities. 1297 00:44:29,700 --> 00:44:31,799 Yeah, the patches or the jump is there 1298 00:44:31,800 --> 00:44:33,959 or the jump is not there, but 1299 00:44:33,960 --> 00:44:36,029 the location where the jump points to 1300 00:44:36,030 --> 00:44:38,289 also. Just to point to 1301 00:44:38,290 --> 00:44:40,689 a location which is consistent 1302 00:44:40,690 --> 00:44:43,419 with the entire system state. 1303 00:44:43,420 --> 00:44:45,729 And here you have the 1304 00:44:45,730 --> 00:44:47,709 perfect thing for something in return 1305 00:44:47,710 --> 00:44:49,539 oriented programing where you just need 1306 00:44:49,540 --> 00:44:51,279 to have an arbitrary jump within your 1307 00:44:51,280 --> 00:44:53,349 code. So these are mechanisms 1308 00:44:53,350 --> 00:44:56,229 that we have to defend against 1309 00:44:56,230 --> 00:44:58,929 and to verify 1310 00:44:58,930 --> 00:45:00,099 that we already heard. 1311 00:45:00,100 --> 00:45:02,979 We have simple approaches 1312 00:45:02,980 --> 00:45:04,149 like locking the current. 1313 00:45:04,150 --> 00:45:05,649 The easiest thing with a hash based 1314 00:45:05,650 --> 00:45:07,899 approach, as I said, is the NIHAAL 1315 00:45:07,900 --> 00:45:10,209 changes to the current code and runtime. 1316 00:45:10,210 --> 00:45:12,279 But here we have the problem that 1317 00:45:12,280 --> 00:45:14,499 we completely disable all of this 1318 00:45:14,500 --> 00:45:17,259 legitimate patching approaches. 1319 00:45:17,260 --> 00:45:20,019 And, uh, yeah, 1320 00:45:20,020 --> 00:45:21,609 on the other hand, you also can say, 1321 00:45:21,610 --> 00:45:23,499 yeah, well, most of the code is static, 1322 00:45:23,500 --> 00:45:25,569 but just a couple of locations might 1323 00:45:25,570 --> 00:45:26,479 change. 1324 00:45:26,480 --> 00:45:28,179 But here you have an equal problem. 1325 00:45:28,180 --> 00:45:29,709 You know, the number of hashes that you 1326 00:45:29,710 --> 00:45:32,019 have to maintain for every 1327 00:45:32,020 --> 00:45:34,599 location that might change is 1328 00:45:34,600 --> 00:45:36,489 in very large numbers. 1329 00:45:36,490 --> 00:45:38,649 So you have to maintain very 1330 00:45:38,650 --> 00:45:40,869 many caches. 1331 00:45:40,870 --> 00:45:43,029 And also the Linux kernel in its 1332 00:45:43,030 --> 00:45:45,819 current form has a problem that 1333 00:45:45,820 --> 00:45:47,620 for some code pages, 1334 00:45:49,720 --> 00:45:51,849 both code and data, reside on 1335 00:45:51,850 --> 00:45:53,839 the same executable page. 1336 00:45:53,840 --> 00:45:56,019 So the kernel for 1337 00:45:56,020 --> 00:45:58,209 its code pages uses large pages, 1338 00:45:58,210 --> 00:46:00,039 which are basically two megabyte pages 1339 00:46:01,360 --> 00:46:03,069 that are used for kernel code. 1340 00:46:03,070 --> 00:46:05,379 But on the last page, there is still 1341 00:46:05,380 --> 00:46:07,749 some spare memory 1342 00:46:07,750 --> 00:46:10,299 that would either be wasted 1343 00:46:10,300 --> 00:46:12,609 or the Linux kernel 1344 00:46:12,610 --> 00:46:14,679 gives that to userspace 1345 00:46:14,680 --> 00:46:17,139 applications if they 1346 00:46:17,140 --> 00:46:18,519 allocate some memory. 1347 00:46:18,520 --> 00:46:20,469 So here we also have the problem that we 1348 00:46:20,470 --> 00:46:22,689 don't know really is this code, 1349 00:46:22,690 --> 00:46:24,369 is this data? What is to verify? 1350 00:46:24,370 --> 00:46:26,559 What should be on that page? 1351 00:46:26,560 --> 00:46:28,989 So this is also a problem for hashing 1352 00:46:28,990 --> 00:46:29,990 the kernel. 1353 00:46:30,640 --> 00:46:32,919 So what we propose here is a 1354 00:46:32,920 --> 00:46:35,229 trap and violate approach using Vme. 1355 00:46:35,230 --> 00:46:37,749 So we know patching 1356 00:46:37,750 --> 00:46:39,999 only happens to 1357 00:46:40,000 --> 00:46:41,079 predefined location. 1358 00:46:41,080 --> 00:46:43,329 So from the binary we can derive 1359 00:46:43,330 --> 00:46:46,119 which patching mechanisms are there 1360 00:46:46,120 --> 00:46:48,249 and where or 1361 00:46:48,250 --> 00:46:50,439 at which offset in the binary 1362 00:46:50,440 --> 00:46:52,839 the code will be patched and also with 1363 00:46:52,840 --> 00:46:54,670 which really values under which 1364 00:46:56,200 --> 00:46:57,549 circumstances. 1365 00:46:57,550 --> 00:46:59,619 And for that we 1366 00:46:59,620 --> 00:47:01,809 can now retrace 1367 00:47:01,810 --> 00:47:04,119 those patching mechanisms and 1368 00:47:04,120 --> 00:47:06,889 understand what they really mean and 1369 00:47:06,890 --> 00:47:09,189 also see their system 1370 00:47:09,190 --> 00:47:11,259 state that it's consistent. 1371 00:47:11,260 --> 00:47:13,389 And also this 1372 00:47:13,390 --> 00:47:15,219 fixes another problem because the code 1373 00:47:15,220 --> 00:47:17,029 patching is not an atomic operation. 1374 00:47:17,030 --> 00:47:18,729 Like, for example, if you patch entire 1375 00:47:18,730 --> 00:47:21,039 functions, that cannot be done 1376 00:47:21,040 --> 00:47:23,379 at once. So there's always 1377 00:47:23,380 --> 00:47:25,479 like between the two good states, 1378 00:47:25,480 --> 00:47:28,359 a bad state in between, which is also 1379 00:47:28,360 --> 00:47:30,189 good because it leads from the one to the 1380 00:47:30,190 --> 00:47:32,289 other. So you have 1381 00:47:32,290 --> 00:47:34,869 to have a system which is aware 1382 00:47:34,870 --> 00:47:36,939 of all those intermediate states and 1383 00:47:36,940 --> 00:47:39,039 can handle them appropriately. 1384 00:47:39,040 --> 00:47:41,439 So we want to or we propose 1385 00:47:41,440 --> 00:47:43,599 to write events to criminal code. 1386 00:47:43,600 --> 00:47:45,669 And when the 1387 00:47:45,670 --> 00:47:48,339 kernel code is changed, you can validate 1388 00:47:48,340 --> 00:47:50,559 that the change is not 1389 00:47:50,560 --> 00:47:52,829 malicious and 1390 00:47:52,830 --> 00:47:54,999 that does provide the integrity 1391 00:47:55,000 --> 00:47:56,320 of the running Linux kernel. 1392 00:47:57,610 --> 00:47:59,889 So this 1393 00:47:59,890 --> 00:48:02,169 basically was about the 1394 00:48:02,170 --> 00:48:03,549 integrity of the code. 1395 00:48:03,550 --> 00:48:05,739 And with that, I want 1396 00:48:05,740 --> 00:48:08,709 to conclude and as a summary 1397 00:48:08,710 --> 00:48:11,019 to say, VMI 1398 00:48:11,020 --> 00:48:13,269 supports a wide spectrum of applications 1399 00:48:13,270 --> 00:48:15,519 from malware detection to 1400 00:48:15,520 --> 00:48:18,039 cloud environments, and 1401 00:48:18,040 --> 00:48:20,559 VMI gives us the free association 1402 00:48:20,560 --> 00:48:22,659 interpretation and interpretation. 1403 00:48:22,660 --> 00:48:25,359 But depending on what you want to do with 1404 00:48:25,360 --> 00:48:27,699 VMI, it 1405 00:48:27,700 --> 00:48:30,429 depends on which of those three features 1406 00:48:30,430 --> 00:48:32,199 you want to have most. 1407 00:48:32,200 --> 00:48:34,329 So the pure problem 1408 00:48:34,330 --> 00:48:37,179 I, as in isolation, 1409 00:48:37,180 --> 00:48:39,069 is not required for all of those use 1410 00:48:39,070 --> 00:48:41,319 cases. So you have to see whether 1411 00:48:41,320 --> 00:48:43,539 you want to have an agent which you can 1412 00:48:43,540 --> 00:48:45,909 secure, or if you want to have 1413 00:48:45,910 --> 00:48:48,069 very intrusive mechanisms which 1414 00:48:48,070 --> 00:48:50,469 make the execution of the virtual machine 1415 00:48:50,470 --> 00:48:52,539 maybe still so you can have like the 1416 00:48:52,540 --> 00:48:54,909 more in-depth you the Dallas 1417 00:48:54,910 --> 00:48:57,819 performance or trade between those. 1418 00:48:57,820 --> 00:48:59,979 But as we 1419 00:48:59,980 --> 00:49:02,079 said, the hardware support for all 1420 00:49:02,080 --> 00:49:04,089 of these mechanisms is continuously 1421 00:49:04,090 --> 00:49:06,579 improving and gets 1422 00:49:06,580 --> 00:49:07,580 better there. 1423 00:49:08,680 --> 00:49:11,259 The tools that we showed you today 1424 00:49:11,260 --> 00:49:13,179 are open source. 1425 00:49:13,180 --> 00:49:14,979 You can look at the websites, look, VMI, 1426 00:49:14,980 --> 00:49:17,049 dot com, dogtooth, dot com, 1427 00:49:17,050 --> 00:49:18,249 and you can find us 1428 00:49:19,360 --> 00:49:21,519 on Freenode and our 1429 00:49:21,520 --> 00:49:22,839 contacts respectively. 1430 00:49:25,150 --> 00:49:27,339 After that, I just want to say thank 1431 00:49:27,340 --> 00:49:28,869 you to all of the names here on that 1432 00:49:28,870 --> 00:49:30,309 slide. 1433 00:49:30,310 --> 00:49:33,099 Without those, it wouldn't be possible. 1434 00:49:33,100 --> 00:49:36,069 And conclude our talk and 1435 00:49:36,070 --> 00:49:37,459 be ready. Are your questions? 1436 00:49:45,500 --> 00:49:47,569 If you have questions, please line 1437 00:49:47,570 --> 00:49:49,789 up on the microphones and 1438 00:49:49,790 --> 00:49:52,369 if you absolutely must leave the room, 1439 00:49:52,370 --> 00:49:53,370 do it quietly. 1440 00:49:56,720 --> 00:49:57,720 No one. 1441 00:49:58,960 --> 00:50:01,059 I have a question on 1442 00:50:01,060 --> 00:50:03,159 the run time patching, 1443 00:50:03,160 --> 00:50:05,099 does your code work if the function 1444 00:50:05,100 --> 00:50:07,959 trishaw in terms of dynamic trace 1445 00:50:07,960 --> 00:50:10,209 and also with the upcoming 1446 00:50:10,210 --> 00:50:12,369 patch or craft with 1447 00:50:12,370 --> 00:50:14,829 trace feature, it works currently 1448 00:50:14,830 --> 00:50:17,349 with a function tracer, 1449 00:50:17,350 --> 00:50:18,699 with a function replacement. 1450 00:50:18,700 --> 00:50:20,049 It does not currently work. 1451 00:50:20,050 --> 00:50:21,879 I have not implemented that yet. 1452 00:50:21,880 --> 00:50:24,459 And also for the tools are open source. 1453 00:50:24,460 --> 00:50:26,619 That last part is still to 1454 00:50:26,620 --> 00:50:28,419 be published, but this will happen in the 1455 00:50:28,420 --> 00:50:29,469 near future. 1456 00:50:29,470 --> 00:50:31,629 OK, thanks number 1457 00:50:31,630 --> 00:50:32,630 three 1458 00:50:34,110 --> 00:50:35,589 for me. 1459 00:50:35,590 --> 00:50:36,959 OK, it's me. 1460 00:50:36,960 --> 00:50:38,529 OK, uh, one question. 1461 00:50:38,530 --> 00:50:40,929 You shot, uh, this tool 1462 00:50:40,930 --> 00:50:43,089 for this, uh, tracing of 1463 00:50:43,090 --> 00:50:44,109 the memory states. 1464 00:50:44,110 --> 00:50:46,389 So you mentioned that 1465 00:50:46,390 --> 00:50:48,849 it's, uh, only supported 1466 00:50:48,850 --> 00:50:51,609 under 86 1467 00:50:51,610 --> 00:50:54,489 right now. Other plans to support 1468 00:50:54,490 --> 00:50:56,559 our Lexcen as well at some 1469 00:50:56,560 --> 00:50:57,909 point of time. 1470 00:50:57,910 --> 00:51:00,249 Yes, I am actually been working. 1471 00:51:00,250 --> 00:51:02,019 I was hoping to get that into, um, four 1472 00:51:02,020 --> 00:51:02,649 point five. 1473 00:51:02,650 --> 00:51:04,119 But unfortunately, the freeze window 1474 00:51:04,120 --> 00:51:05,559 closed just too early. 1475 00:51:05,560 --> 00:51:07,059 So it's going to be available in four 1476 00:51:07,060 --> 00:51:09,279 point six. OK, because there is this 1477 00:51:09,280 --> 00:51:11,469 OCTA core arm platform coming 1478 00:51:11,470 --> 00:51:13,659 up and it will be really handy 1479 00:51:13,660 --> 00:51:15,279 to have it on our muswell. 1480 00:51:15,280 --> 00:51:17,589 Yes. So next release, I can 1481 00:51:17,590 --> 00:51:19,689 expect it to have this features. 1482 00:51:19,690 --> 00:51:21,849 Yes, we are working on it. 1483 00:51:21,850 --> 00:51:23,129 Wonderful. 1484 00:51:23,130 --> 00:51:24,910 The question from the Internet. 1485 00:51:26,050 --> 00:51:28,300 Yes. We have, uh, one question 1486 00:51:29,380 --> 00:51:30,369 on Iasi. 1487 00:51:30,370 --> 00:51:32,439 Uh, what is the easiest way 1488 00:51:32,440 --> 00:51:34,699 installing a hypervisor in general 1489 00:51:34,700 --> 00:51:36,819 the next US and what are the 1490 00:51:36,820 --> 00:51:38,859 minimum hardware requirements for 1491 00:51:38,860 --> 00:51:41,260 embedded systems with current systems? 1492 00:51:44,200 --> 00:51:46,179 I have been compiling them from source 1493 00:51:46,180 --> 00:51:48,219 myself, but I guess I'm going to have to 1494 00:51:48,220 --> 00:51:50,379 install them something 1495 00:51:50,380 --> 00:51:51,699 of that effect. 1496 00:51:51,700 --> 00:51:53,349 Kvamme is, of course, built into the 1497 00:51:53,350 --> 00:51:55,749 kernel, so that's usually 1498 00:51:55,750 --> 00:51:57,309 a load of if your hardware supports it. 1499 00:51:57,310 --> 00:51:59,439 So usually your distribution 1500 00:51:59,440 --> 00:52:01,219 has some built-In support for that. 1501 00:52:01,220 --> 00:52:02,220 So. 1502 00:52:03,830 --> 00:52:05,569 Microphone number four. 1503 00:52:05,570 --> 00:52:07,639 So I was first of all, I 1504 00:52:07,640 --> 00:52:09,139 was trying to get into the same area as 1505 00:52:09,140 --> 00:52:11,509 the first guy, um, 1506 00:52:11,510 --> 00:52:13,429 what's the purpose of those talks? 1507 00:52:13,430 --> 00:52:14,569 I mean, those also really cool. 1508 00:52:14,570 --> 00:52:16,649 If you want to analyze a 1509 00:52:16,650 --> 00:52:17,899 a system, you have a contained 1510 00:52:17,900 --> 00:52:19,759 environment and you want to you know that 1511 00:52:19,760 --> 00:52:21,259 it was compromise and then you want to 1512 00:52:21,260 --> 00:52:22,789 figure out what actually went on. 1513 00:52:22,790 --> 00:52:25,069 Right. You can analyze it dynamically and 1514 00:52:25,070 --> 00:52:27,499 trace things. That's pretty nice 1515 00:52:27,500 --> 00:52:29,359 for an actual life system. 1516 00:52:29,360 --> 00:52:31,339 Everything that's coming up with life 1517 00:52:31,340 --> 00:52:33,679 patches like PERF, like 1518 00:52:33,680 --> 00:52:35,599 graft, like the others, you can do a 1519 00:52:35,600 --> 00:52:37,549 fingerprint for a security vulnerability 1520 00:52:37,550 --> 00:52:38,839 that's going to happen in a year. 1521 00:52:38,840 --> 00:52:41,149 Right. So so you don't you can 1522 00:52:41,150 --> 00:52:43,339 simply cannot do a whitelist because you 1523 00:52:43,340 --> 00:52:46,039 are in time before the 1524 00:52:46,040 --> 00:52:48,199 fingerprint would get created. 1525 00:52:48,200 --> 00:52:50,149 But that's where the whitelist approach 1526 00:52:50,150 --> 00:52:51,229 sort of comes into play. 1527 00:52:51,230 --> 00:52:53,299 Like, you know what the good things that 1528 00:52:53,300 --> 00:52:54,809 can happen to the criminals only allow 1529 00:52:54,810 --> 00:52:56,449 the good things that you want to know 1530 00:52:56,450 --> 00:52:58,519 about and everything else you can flag 1531 00:52:58,520 --> 00:53:00,339 as potentially malicious. 1532 00:53:00,340 --> 00:53:01,729 It means you need to update your ideas 1533 00:53:01,730 --> 00:53:03,199 before the case can be updated. 1534 00:53:03,200 --> 00:53:05,149 So you have a time, right? 1535 00:53:05,150 --> 00:53:07,219 So if you deploy a very new 1536 00:53:07,220 --> 00:53:08,929 kernel that the protection tool doesn't 1537 00:53:08,930 --> 00:53:11,059 know about yet, then yes, that has 1538 00:53:11,060 --> 00:53:11,809 to happen. 1539 00:53:11,810 --> 00:53:13,729 OK, so so imagine this is your day coming 1540 00:53:13,730 --> 00:53:16,039 up and 1541 00:53:16,040 --> 00:53:18,199 somebody like you basically get 1542 00:53:18,200 --> 00:53:20,269 a specially crafted graft 1543 00:53:20,270 --> 00:53:21,829 kind of module that you load to fix that 1544 00:53:21,830 --> 00:53:23,479 they kind of that thing. 1545 00:53:23,480 --> 00:53:25,279 It's first off, it's probably tailored to 1546 00:53:25,280 --> 00:53:26,539 you because you might actually have 1547 00:53:26,540 --> 00:53:28,009 another security fix in your system that 1548 00:53:28,010 --> 00:53:29,119 is just only for you. 1549 00:53:29,120 --> 00:53:30,739 So you actually might be wanting a kernel 1550 00:53:30,740 --> 00:53:32,719 that's not fingerprinted by you or by by 1551 00:53:32,720 --> 00:53:34,909 anybody else or your host 1552 00:53:34,910 --> 00:53:36,539 provider. You're your cloud provider. 1553 00:53:36,540 --> 00:53:38,689 And then the cloud provider might 1554 00:53:38,690 --> 00:53:40,969 not even know about that fix yet because, 1555 00:53:40,970 --> 00:53:42,259 well, they might be in the loop after 1556 00:53:42,260 --> 00:53:42,649 you. 1557 00:53:42,650 --> 00:53:44,509 Yeah, but that's a general thing. 1558 00:53:44,510 --> 00:53:46,669 Take for the internal integrity part 1559 00:53:46,670 --> 00:53:48,679 that I showed. That's very, very kind of 1560 00:53:48,680 --> 00:53:50,869 specific. Like you need to know exactly 1561 00:53:50,870 --> 00:53:52,489 which kernel is running on the system 1562 00:53:52,490 --> 00:53:53,509 with everything. 1563 00:53:53,510 --> 00:53:54,709 You have to have the binaries. 1564 00:53:54,710 --> 00:53:56,989 And currently we extract 1565 00:53:56,990 --> 00:53:59,359 all of the information for our 1566 00:53:59,360 --> 00:54:01,489 verification or validation out of 1567 00:54:01,490 --> 00:54:04,099 the binaries. So if 1568 00:54:04,100 --> 00:54:06,169 you as the cloud provider don't know 1569 00:54:06,170 --> 00:54:08,239 what's in that system, you can do that 1570 00:54:08,240 --> 00:54:10,279 anyway. But you're also not supposed to 1571 00:54:10,280 --> 00:54:12,529 do because if you were 1572 00:54:12,530 --> 00:54:14,659 supposed to we're supposed to 1573 00:54:14,660 --> 00:54:16,609 do that, you would know about the patch 1574 00:54:16,610 --> 00:54:18,529 that is in the system. 1575 00:54:18,530 --> 00:54:20,659 And you can also take like this 1576 00:54:20,660 --> 00:54:21,979 is the kernel code that we are running 1577 00:54:21,980 --> 00:54:23,209 and these are the patches that we are 1578 00:54:23,210 --> 00:54:25,399 applied from that we can build like 1579 00:54:25,400 --> 00:54:26,749 the ground truth and match it against 1580 00:54:26,750 --> 00:54:28,429 what's in the system. 1581 00:54:28,430 --> 00:54:30,889 So my main point is I don't think cloud 1582 00:54:30,890 --> 00:54:32,599 is the right term in this case. 1583 00:54:32,600 --> 00:54:34,549 This really is an awesome thing for 1584 00:54:34,550 --> 00:54:36,019 embedded projects where you control the 1585 00:54:36,020 --> 00:54:37,039 whole stack. 1586 00:54:37,040 --> 00:54:38,869 As soon as you have different tenants 1587 00:54:38,870 --> 00:54:40,909 doing different things, things fall apart 1588 00:54:40,910 --> 00:54:42,679 because not everybody has knowledge of 1589 00:54:42,680 --> 00:54:43,879 everything left and right. 1590 00:54:43,880 --> 00:54:44,880 And also, 1591 00:54:46,040 --> 00:54:48,109 this is also not only like for 1592 00:54:48,110 --> 00:54:49,759 Malverde detection, like from the 1593 00:54:49,760 --> 00:54:51,469 beginning, you want to you have a system 1594 00:54:51,470 --> 00:54:52,729 you think is clean. 1595 00:54:52,730 --> 00:54:54,679 And if you work with a system, you have 1596 00:54:54,680 --> 00:54:56,869 the different tools that you with which 1597 00:54:56,870 --> 00:54:58,309 you can look at the system. 1598 00:54:58,310 --> 00:55:00,679 And once one of the system reports 1599 00:55:00,680 --> 00:55:01,680 any 1600 00:55:02,900 --> 00:55:04,459 funny things about the system, you 1601 00:55:04,460 --> 00:55:06,109 definitely have to investigate further. 1602 00:55:06,110 --> 00:55:08,419 So you don't have all our systems running 1603 00:55:08,420 --> 00:55:10,729 like with the most detailed view about 1604 00:55:10,730 --> 00:55:11,659 the systems. 1605 00:55:11,660 --> 00:55:13,729 And it's also not for preventing 1606 00:55:13,730 --> 00:55:15,140 any malicious things 1607 00:55:16,160 --> 00:55:17,989 or entirely for preventing them. 1608 00:55:17,990 --> 00:55:20,239 So it goes in the right direction, 1609 00:55:20,240 --> 00:55:21,169 I think. 1610 00:55:21,170 --> 00:55:23,539 And but it's not a tool like that solves 1611 00:55:23,540 --> 00:55:25,639 everything, just having a hard 1612 00:55:25,640 --> 00:55:27,219 time figuring out where to. 1613 00:55:27,220 --> 00:55:29,689 The second thing I had was on the VEMA 1614 00:55:29,690 --> 00:55:30,690 Flushing stuff. 1615 00:55:31,910 --> 00:55:34,099 So the first generation CPU's didn't like 1616 00:55:34,100 --> 00:55:36,429 the generation of 1617 00:55:36,430 --> 00:55:38,839 VM Kubel CPU's didn't have 1618 00:55:38,840 --> 00:55:40,969 ascites or anything of the likes 1619 00:55:40,970 --> 00:55:43,189 and performance difference between 1620 00:55:43,190 --> 00:55:45,289 having assets and noddies like what, five 1621 00:55:45,290 --> 00:55:46,759 percent, two percent? Something on that 1622 00:55:46,760 --> 00:55:48,979 ballpark. You can just flush in every 1623 00:55:48,980 --> 00:55:51,769 context and call it age ages just at 1624 00:55:51,770 --> 00:55:54,049 submitted patch to cavium to 1625 00:55:54,050 --> 00:55:55,729 enable always to flush it. 1626 00:55:55,730 --> 00:55:56,809 Always, right. 1627 00:55:56,810 --> 00:55:58,399 I mean, that's always a possibility that 1628 00:55:58,400 --> 00:56:00,529 you just disable tagging and that's your 1629 00:56:00,530 --> 00:56:02,389 problem goes away. But then you sacrifice 1630 00:56:02,390 --> 00:56:04,189 performance and you always have 1631 00:56:04,190 --> 00:56:06,649 performance if you trap on every 1632 00:56:06,650 --> 00:56:07,549 heap allocation. 1633 00:56:07,550 --> 00:56:08,179 Right. 1634 00:56:08,180 --> 00:56:09,440 That's yeah. 1635 00:56:11,240 --> 00:56:12,619 So that performance really is not an 1636 00:56:12,620 --> 00:56:14,749 argument. You if you lose two percent 1637 00:56:14,750 --> 00:56:16,639 down to the tubes and it's definitely a 1638 00:56:16,640 --> 00:56:18,819 lot less than any of it. 1639 00:56:18,820 --> 00:56:19,759 Yeah. 1640 00:56:19,760 --> 00:56:21,919 It depends on what your security 1641 00:56:21,920 --> 00:56:23,929 application is doing. So you might not 1642 00:56:23,930 --> 00:56:25,939 need to hook all the fast that functions 1643 00:56:25,940 --> 00:56:28,069 to really protect stuff. 1644 00:56:28,070 --> 00:56:30,349 So it really depends. 1645 00:56:30,350 --> 00:56:32,179 As I said, you probably don't want to 1646 00:56:32,180 --> 00:56:34,429 trap on everything 1647 00:56:34,430 --> 00:56:35,859 because if you have an anger stage and 1648 00:56:35,860 --> 00:56:37,219 then you don't need to trap, you just 1649 00:56:37,220 --> 00:56:38,809 have something within that you protect 1650 00:56:38,810 --> 00:56:39,859 from the outside. 1651 00:56:39,860 --> 00:56:41,299 And for cloud application, that's 1652 00:56:41,300 --> 00:56:42,529 probably the way you want to go. 1653 00:56:42,530 --> 00:56:44,209 But for malware analysis, doing something 1654 00:56:44,210 --> 00:56:45,829 like this where you really can't trust 1655 00:56:45,830 --> 00:56:48,170 any kernel data, that's really essential, 1656 00:56:49,370 --> 00:56:50,370 OK? 1657 00:56:51,230 --> 00:56:52,230 No one. 1658 00:56:52,940 --> 00:56:54,859 Or any of the large cloud providers 1659 00:56:54,860 --> 00:56:56,809 offering malware detection service for 1660 00:56:56,810 --> 00:56:57,559 their clients? 1661 00:56:57,560 --> 00:56:59,899 Not yet, but we are expecting 1662 00:56:59,900 --> 00:57:02,000 that to happen soon ish, I guess. 1663 00:57:04,870 --> 00:57:07,209 Number three, uh, you mentioned 1664 00:57:07,210 --> 00:57:09,739 something about Android, um, 1665 00:57:09,740 --> 00:57:11,919 how far we are today to use this. 1666 00:57:11,920 --> 00:57:14,199 We, um, we are my end and 1667 00:57:14,200 --> 00:57:16,479 the system on on armed devices. 1668 00:57:17,920 --> 00:57:19,809 So the thing with ARM is that we have the 1669 00:57:19,810 --> 00:57:21,969 two-stage, Beijing and I 1670 00:57:21,970 --> 00:57:24,249 have the codes to have the trapping 1671 00:57:24,250 --> 00:57:26,079 mechanism working with them, but 1672 00:57:26,080 --> 00:57:28,149 unfortunately, that's only one part of 1673 00:57:28,150 --> 00:57:30,099 the picture. So for all of these things 1674 00:57:30,100 --> 00:57:31,659 that I showed here today, it's really 1675 00:57:31,660 --> 00:57:34,449 required all four types of trapping. 1676 00:57:34,450 --> 00:57:36,459 For now, it's only the memory parts 1677 00:57:36,460 --> 00:57:37,869 that's functional. 1678 00:57:37,870 --> 00:57:39,159 So there is more research needed to be 1679 00:57:39,160 --> 00:57:41,719 done on how to do a single stepping and 1680 00:57:41,720 --> 00:57:42,969 an efficient trapping. 1681 00:57:42,970 --> 00:57:44,979 So, for example, there is no break point 1682 00:57:44,980 --> 00:57:46,839 trapping GLENARM So there is some 1683 00:57:46,840 --> 00:57:49,029 alternative that needs to be found yet, 1684 00:57:49,030 --> 00:57:51,099 but it's still very early in the 1685 00:57:51,100 --> 00:57:52,300 research phase. So 1686 00:57:53,350 --> 00:57:55,209 interestingly, the people who are looking 1687 00:57:55,210 --> 00:57:56,769 into that mostly are Samsung. 1688 00:57:56,770 --> 00:57:59,199 So I expect them to have some sort of 1689 00:57:59,200 --> 00:58:00,699 security stuff that they want to sell 1690 00:58:00,700 --> 00:58:02,889 soon. So it might be 1691 00:58:02,890 --> 00:58:04,729 improving as well. 1692 00:58:04,730 --> 00:58:06,789 So and those bags generally 1693 00:58:06,790 --> 00:58:09,299 support for virtualization on arm. 1694 00:58:09,300 --> 00:58:10,329 Yes, yes. 1695 00:58:10,330 --> 00:58:11,380 Yes. Thank you. 1696 00:58:12,930 --> 00:58:15,449 So if you have no other questions, 1697 00:58:15,450 --> 00:58:17,339 we will conclude the talk. 1698 00:58:17,340 --> 00:58:19,649 Thomas Thomas, 1699 00:58:19,650 --> 00:58:21,929 for this very deep look 1700 00:58:21,930 --> 00:58:22,930 at the.