So, good morning, everyone. Welcome to the first rainy day of this conference in Vienna. It's my pleasure to introduce the third invited speaker of this conference, which is Christian Kohlberg from the University of Arizona. So, in case you have been asleep in the past three years, you may have missed that obfuscation has become quite a hot topic at crypto conferences, but it has actually been a hot topic and from a more practical engineering point of view for way longer. And I think it's fair to say that Christian is one of the key players in this area. He's on his PhD at the University of Lund in Sweden, then had held position in New Zealand, China, before now moving to the University of Arizona. And he's the author of a pretty well-known book in this area called Surreptitious Software about Obfuscation, Watermarking, and so on. He's a co-developer of a tool for obfuscating a Java bytecode called Sandmark. And, for example, I know his work about taxonomies of obfuscation transformation, which is definitely worth a read. We're very happy that today he accepted our invitation, and we'll talk about code obfuscation from an engineering point of view. Thank you very much for that introduction, and good morning, everybody. Today I'm going to try to cover five topics. We'll start by looking at some common applications that, from a security point of view, fall in what we call the mate or man at the end scenario. So this is a scenario in which an adversary is in complete control over a device and can violate it for some... And next I'll talk about tools that protect against such mate attacks, particularly code obfuscators. At the heart of such tools are obfuscating code transformations. And I'll talk about those next. And at the same time I'll talk about ways to attack these transformations. I'll give some examples. Having access to good obfuscating code transformations isn't enough, however. So next I'll talk about how we deploy these in practice, particularly talk about various kinds of diversity. And finally I'll talk about the major challenge in this area, which is how we evaluate obfuscating code transformations. And then I will conclude with some discussion. So at this point I should issue a fair warning. Title of this talk is engineering code obfuscation, and I'm not a cryptographer, and there will be no crypto in this talk. There will have to be quite a lot of programming language stuff. So let's start by looking at some scenarios where code obfuscation could be part of a security solution. So this is Alice. Alice is your teenage daughter. She has a boyfriend named Bob, and today she's sending him a message over Snapchat with a picture of her thumb. And she sets a time out, so after eight seconds, that picture of her thumb gets deleted from his phone. Of course Bob, so in my scenario, unlike yours, Alice is a good girl, and Bob is a bad boy. So Bob, of course, wants to save this picture, and so he takes a screenshot on his phone. When that happens, a message pops up on Alice's phone saying, Bob took a screenshot, and then she can unfriend him, or what kids do these days. Now, Bob doesn't want that to happen, of course, so he downloads a hack from the Internet that allows him to take a screenshot without anyone finding out. So Snapchat doesn't want this to happen, of course, so they add some software protection code to their application. It checks that the app hasn't been tampered with, that the environment in which the app is running is healthy, and that Bob is not being curious in looking inside this application and extracting keys and pictures and whatnot. So Snapchat recently hired Moti Young as their security and privacy scientist, and Moti actually is the one who invented the term that we now use for this type of scenario, namely mate or man at the end. So what's a mate attack? Mate attacks occur in any setting where an adversary has physical access to a device and compromises it by inspecting, reverse engineering, or tampering with the software or hardware. Okay, turns out that this type of scenario pops up all over the place. Now here's Alice again, this time she's a distributor of television programs. She runs a television network. Bob is a customer who subscribes so he can watch sports. And so he has a set top box, a TV that allows him to watch a program as long as he's paid the bill. Of course, Bob is a bad boy and he'd rather not pay his bill and still watch sports. So he can tamper with this set top box, he can clone it, he can extract keys from it, he can extract media or content and serve it up to others on the internet for profit. Now Alice of course doesn't want this to happen. So she adds some software protection code to this device. Checks that hardware hasn't been tampered with, that the software hasn't been tampered with. And again, Bob is not being curious and looking inside and extracting information. And if he does, then she can punish him by cutting off access. Now in this scenario, Alice runs a public utility, such as a power company. Again, Bob is a customer and outside his house is a smart meter. And this smart meter sends back his consumption in real time to the power company. Of course, he'd rather not pay his bill, so he tampers with it and so it sends back the wrong information. But this smart meter in fact does more than that. It allows the power company to turn off power to your house in case, for example, there's an acute power shortage. Now Bob, the evil terrorist, hacks this meter outside his house and figures out how he can send out 5 million disconnect notices to all the customers in Manhattan causing global financial crisis. So let's now look at the kind of tools that we might use, Bob and Alice might use to protect an application or to violate an application. Alice uses code transformation tools. And those take a program as input and produces a more protected program as output. And inside that program are some assets. This could be source code itself. It could be algorithms. It could be keys. It could be IP addresses of service we want to connect to. It could be media we've decrypted. And this tool also takes as input a set of code transformations and also some description of the overhead that we can accept and the amount of protection that we would like to achieve. Now there are all kinds of protective code transformations and you probably combine them depending on your scenario. So office getting transformations, which is what we'll talk about today, make programs hard to understand. Tampa proofing transformations protect integrity of an application. Remote data station transformations check the health of an untrusted node in a distributed system. White box cryptography protects media in a digital rights management situation. Environment checking transformations checks that an application is running in a healthy environment such as not running under a virtual machine or emulator and so on. And watermarking transformations embed unique identification programs so that we can track them later. And there's a wide variety of free and commercial tools in this area. Commercial tools may run you $100,000. There's currently an EU FD7 project called Aspire, which is building a tool chain. And I have a tool called Tigris that's freely downloaded from our website. And if you're interested in this kind of stuff, you can download it and play with it. And that's what I'll talk about today. Bob, on the other hand, his tools to use code analysis to try to extract from the Alice's protected program her assets. And there are lots of different types of code transformations. They fall in the general category of static and dynamic static trans code analysis, take a program as input and just looks at the program itself, the code, the binary executable, for example, to extract some information. Dynamic analysis, on the other hand, runs the application with some particular input and extracts information that way. And Bob's goal is to extract the asset that Alice has embedded. Bob, too, is concerned about performance. He wants his analysis to be as quick as possible and as precise as possible. And here, too, there are a wide variety of tools available, both free and commercial. At this point, it might be interesting to think about what makes for a good office-gating transformation? What matters in this scenario? Well, one thing that matters, turns out, is performance. One reason that it matters is because often we are running on very constrained devices, like phones or smart meters and so on. Obviously, security matters as well, or we say time to crack. And we'd like to protect our applications in a variety of attack scenarios, a completely manual attack when Bob just buckles down and gets in the code and tries to reverse engineer it, or a completely automatic attack when he uses one of these advanced code analysis tools, or a combination where you have a smart human combined with the latest and greatest in the code analysis tools to track the violator application. In some situations, you're also interested in the stealth of the code, how well it fits in with other kind of code. And this is true, for example, for office-gated malware, which just wants to hide itself from malware scanners. So what does it mean when I say that performance matters? So to find out, I queried some colleagues in industry, say, what does this mean to you? And one guy who works in, let's say, the media distribution industry, told me that for them, user experience cannot be harmed. In other words, every operation has to run in under a second. Think about flipping channels on your TV. Every time you do that, you have to check whether you should be allowed to watch that channel that has to be run in under a second, or you'll be very annoyed. Another company writes that for a particular customer, they expected no more than 150% slowdown and reduction in increasing size. Another person says that they recommend for their customers a slowdown of 100 to 1,000, but that's for a security kernel, not for the application as a whole. We also timed some commercial code obfuscation tools, and they also ran in the order of 100 to 1,200 slowdown. Now, of course, as you know, as we've seen this week, there's been some exciting developments in indistinguishability obfuscation. And I'm aware of two implementations at this point. The most well-known, I think, is the one that was presented as crypto two years ago, where they put out a challenge. It was an obfuscated 16-bit point function, took seven hours to generate, was 25 gigabytes large, and took four hours to execute. And it was broken pretty quickly, essentially, by speeding it up. So given that this is a pretty trivial piece of code, and the overhead was so large, we're still a little ways off, I think, from being practical. But this is certainly very exciting developments. Obviously, time to crack matters as well. And what does that mean? So again, I asked some colleagues in industry, and they said, one guy said, well, our application has, our protection has been in the field for years and not being cracked. But that one, I believe, uses the combination of software and hardware. Another one said that he expected a highly skilled and motivated reverse engineer to be able to crack a well-protected application in four to six weeks. Another one said that something protected by VM Protect to completely extract the complete semantics of the program, original program, might take like 12 months. On the other hand, mass market malware, which uses obfuscation, is easy to crack, minutes to hours. All right. So with all this in mind, let's look at some actual obfuscating transformations. And at the same time, I look at ways that we can attack these transformations. And Alice is going to start by virtualization. And I'll tell you in a minute what that means. And Bob is going to counter with a completely manual analysis. And then Alice will counter with randomization. And then Bob will counter with a complete static analysis. And then Alice will counter with a dynamic obfuscation. And you can see where this is going. All right. So let's look at virtualization, which is a very common transformation, both in free and commercial tools. So you take a function P0. And you can, from that function, you construct a unique and random virtual instruction set. And then you construct a interpreter that will execute programs in this instruction set. This is similar to an interpreter for Java or Python, except it's specific to this particular random and unique virtual instruction set. And then you translate your original program P0 into this instruction set. And that's what we call the virtual program array. Now, inside this virtual machine goes two things, essentially. The dispatch unit, which is the yellow thing here, which fetches the next instruction and then jumps to one of the blue pieces here, which is what we call instruction handlers. Each of those implement the semantics of one of these virtual instructions. And there's a virtual program counter and there's stacks and registers and stuff like that. The virtualizer also takes as input a seed, which allows us to generate multiple variants from the same program. Each one with a unique instruction set, a unique interpreter, a unique virtual program array. So what does it look at runtime when we execute one of these virtual machines? Well, the dispatch unit fetches the next instruction, jumps to the appropriate instruction handler, executes it, we increment the virtual program counter and go back up the loop of this interpreter. And then we pick the next instruction and do the same thing. And we continue until we're done with the program. Okay, so how would Bob go about attacking this? Well, first of all, he'll just start with a brute force manual analysis. He digs into the binary code of Alice's protected application and sees what he can find. So he locates the instruction handlers, the blue pieces of code here that implement the instructions, semantics of the instructions. And he manually reverse engineers the instruction set. And then from that, he manually constructs a disassembler which can take the virtual program array and gets it back to code. And then he optimizes that code and he magically turns it back into C source. Now, clearly, there's more going on to do this that's on this slide. And it can be very tedious and hard work, but we expect that given enough time and motivation, Bob can certainly do this. So what does Alice do to counter this? Well, the first thing she can do is to create an arbitrarily complex semantics for this virtual instruction set. So here's an example of an instruction that Tiger's virtualizer generated. It's 53 bytes long. And those of you who remember the old Vax VMS, Vax, the longest instruction could be 52 bytes. And so I beat that by one byte. 52 bytes long, it takes 14 arguments and semantics is just very, very crazy. And you can look from, you can see from the instruction handler that that also gets very complicated. You can also randomize the interpreter itself, for example, by picking a random dispatch method. And in general, every decision that the obfuscator makes, the virtualizer makes is randomized, which allows it to generate a large number of unique interpreters and unique instruction sets. Another way to frustrate static manual analysis is to compose transformations. So after virtualization, we can apply any number of other transformations to make the code unusual. And it's nothing stopping us from virtualizing multiple times. And each time using a different dispatch method and a different virtual instruction set. All right. So what's Bob going to do now? Let's assume that we've frustrated him so much that he will no longer attempt a static analysis. So instead of a manual analysis, he'll now try an automatic static analysis. And this means he's going to just look at the code automatically with a tool without executing it. The problem with static analysis is that any results will get out. It's going to be an over approximation of the program semantics. So the question is, when you virtualize a code like this, when you take a program and you translate it into a virtual instruction array, virtual program array, does static analysis actually get you anything? Can you extract any interesting information? So let me go through a very simple example. And if those of you who took an undergraduate compiler class and saw data flow analysis, this is exactly what I'm doing. So here's a very trivial virtual machine. It has two instructions, move and increment. And the blue boxes are the instruction handlers that implements the semantics of the instructions. And the yellow box is a dispatch unit that fetches the next instruction. At the bottom of the slide, you see the program array, which has three instructions, a move, an increment and an increment, and the green boxes are the upcodes for the move and increments. And the purple boxes are the arguments to these instructions. So what are we going to do here is we're going to work on what's called abstract domains. And for us, this abstract domains are going to be integer intervals. And our goal is going to be compute the range of indices that the virtual program counter can take on. So let's get started with this static analysis, with this data flow analysis. So the virtual program counter starts being zero. And so our initial domain is the range from zero to zero. And the first instruction is 52, which is a move. And so we're going to push this domain, this state, abstract state, down into the right branch of the interpreter. And we'll pass the instruction handler and we increment the VPC by three. And so now we have a range from zero to three. And at this point, our analysis is precise. And then we're going to push that state back up to top of the interpreter loop. At this point, we've reached what's called a join point. Control can come to this point from two different directions, either through the initialization or through the back edge of the loop. And so we're going to have to join these two abstract states. And now we get the range from zero to three. Now notice that we already have some imprecision here. It looks like the bytes at index one and two can actually be opcodes. It turns out they can, they're arguments. But let's ignore that for the moment and just press on. The next instruction is an increment. So we push our abstract state down to the left, increments for the VPC, go back up the top of the loop, pick the next instruction, which is also an increment, go down, back up the loop. And in general, we will continue doing this until we reach the fixed point. Now you see that what we've achieved here is a pretty gross overgeneralization of what the actual result should be. It looks like all the bytes from zero to five could be opcodes, which is not true. And this is because we're computing these summaries over the interpreter, not over the program, the actual program which is in this virtual program array. And this is not to say that we couldn't do better. This is pretty bad static analysis. We can certainly improve it. But in general, we're always going to have some imprecision. Okay. Nevertheless, Alice wants to make sure that Bob can't learn anything from a static analysis. So what can she do? So the best trick you can play on static analysis is to make the code never available to it. And so that's what we can do. We make sure that the code does not exist until runtime. So we virtualize the program and then we take the interpreter and we turn that into instructions for a compiler which is embedded into the executable and which runs at runtime. And only at runtime constructs actual instructions for the interpreter and we jump to them. Now this completely frustrates static analysis because the code is not available to it. Now it turns out that Bob can easily bypass this type of transformation. He just has to find, because the code will be in clear ticks at some point during the execution. So all he has to do is find that point, attach a debugger, dump that code, and now he has to code in clear text and can perform a static analysis as before. So what's Alex going to do now? Well, she can improve this situation a little bit with what's called a dynamic analysis. And the idea here is that we're going to keep the code in constant flux at runtime, always going to be changing. And also at no point in time during the runtime is this code going to all exist in clear text at the same time. And there are lots of implementations of this idea. And many of them follow the following scenario in that they have encoders and decoders.  And when you're done with it, you re-encode it. So here, before jumping to the blue code, the pink code will decode the blue code. Then the blue code will decode the yellow code and jump to it. The yellow code will re-encode the blue code and then decode the green code and jump to it. The first implementation of this idea came out many, many years ago by Intel. And the idea here is that we're going to encode blocks by exhoring them with each other. So the striped block here is actually the exhor of the yellow block and the pink block. And before the blue code jumps to the yellow block, it decodes it by exhoring it with the pink block and the yellow block appears. Here's another idea where we're going to just encrypt the blocks. But we're not going to encrypt them with a key that we store in the executed block because that's generally a bad idea. Instead, we're going to use other blocks as keys. So here, before jumping to the yellow block, the blue block will decrypt it using the pink block as a key. And finally, in this case, we're going to overlay two blocks in memory. We have two blocks of code that occupy the same memory location. Now, that seems weird. How can we do that? Well, we're going to have two patch functions which will either get the yellow block out or the gray block out in this case. So the blue block says I want to jump to the yellow block. It patches that memory location and gets the yellow block out. And then the brown block says, well, I want the gray block, so I'll patch that same memory location and get the gray block out. Okay, what's Bob going to do now? Code keeps changing at runtime. It's never in complete clear text. Well, he can now turn to dynamic analysis, meaning he will run the program with a particular input. And what I'm going to show you next is a very clever idea for doing generic de-opfuscation. This is a technique that works on many, many different types of obfuscation, including the ones you've seen already today. And so if we're going to think about programs as pure functions, they have some input, they trace some path through the program to the code, and they produce some output. Now, when we obfuscate it, well, it does the same thing, right? It takes an input, it traces a path, it produces some output, except now it takes a more secure path through the code. So what we're going to do is we're going to take a complete trace of the program. Now some of those instructions, the pink ones here, originated with the obfuscation code, right? They could be the decryption code that we just saw. It could be the back edge in the interpreter loop that we saw. Okay, let's just get rid of those. And then through some advanced magic, we'll flow that trace back into source code. Now, you might imagine that dynamic analysis has some problems with it, and it does. First of all, traces can be huge. And you can imagine that as an obfuscator, I may have tricks to play to make the trace even huge. And you can imagine that the trace does not always cover all the parts of the program, depends on input. And so we will all only be able to de-obfuscate the parts of the code that the trace actually touch. And you may also imagine that there may be ways for me to stop you from collecting a trace in the first place. But we're going to ignore these issues today. All right. So how do we do this? How do we get rid of these obfuscation instructions? Well, we're going to do something called dynamic taint analysis. So take the obfuscator program, get a complete trace, and then we do a forward taint analysis, which means we'll start with the input and we'll find everything that depends on those inputs transitively. We mark every instruction that depends on input. And then we do a backwards taint analysis where we mark everything that contributed to the output. And then we get rid of those instructions. We do some compiler optimizations of this trace, reflow it back into something that's a reasonable approximation of the unobfuscated code. So this is brilliant, right? Now we have a technique that gets rid of all instructions from a variety of obfuscations. So let's look at what happens for virtualization, for example. Here we have the interpreter, it has the virtual program counter, the stack, the virtual program array, and so on. And if you think about it for a minute, you realize that none of those are input dependent. So when we take a trace, none of the instructions that contributed to the interpreter loop, the dispatch unit, and so on, and the instruction handlers will be marked by the taint analysis. And so we'll get the original code back. All right? Alice will not be deterred, however. So to frustrate this analysis, we somehow need to trick taint analysis into thinking that all the instructions are actually tainted. And all we have to do is to somehow trick them into thinking that the DPC and the stack and the virtual program array are in fact input dependent. And it turns out this is reasonably straightforward to do. And in that case, taint analysis will mark every instruction as being input dependent and the deophascation no longer works. Now so far, what I have we've talked about is deophascation trying to get all the instructions back, all the source code back, the original source code. Now in many cases, what the adversary wants is something much less than that.  You just want to detect if the program is doing something suspicious, such as having a virtual machine that might hide some malicious code. In this case, all you want to do is detection. So now you can, as a virus scanner, you can just take a trace of the program and you can notice that you have lots of forward jumps from a dispatch to a instruction handlers and lots of backwards jumps from the instruction handler to the top of the interpreter loop. And it's a pretty telltale signature of an interpreter. So again, what can Alice do? Well, she can try to make the trace stealthier. And it turns out that with these interpreters, it's easier to construct an interpreter. And tigers can do this that you can start and start and stop and restart. So now you add calls to the interpreter, all of your program, run a few iterations in every place. And so now the instructions from the interpreter that maybe contains a malicious code is interspersed with the instructions from the original program. So now you've increased the dynamic stealth of the malicious code. So at this point, I think it's important to understand that performance matters not just to Alice but to Bob too. So to give you some examples, static analysis of a Fibonacci program, a tiny program, virtualized with tigers took 40 seconds in a trace in 71 megabytes of memory. A taint analysis, which is bit-level taint analysis, which is what we saw for the generic de-obfuscation of a Huffman coding program, which is still a small program protected by VM Protect, which is a commercial tool, took 500 seconds. And concoct analysis, which we haven't talked about today, of a 14-line trivial program protected by VM Protect, took four hours. So performance matters of both size and speed for these analysis. So it should be clear at this point that what we have is a classic cat and mouse game. Alice makes better, Bob makes better analysis, and Alice counters with better transformations. And we say that obfuscation provides time-limited protection. It will always take Bob some amount of time, some non-zero time, to extract an asset from an obfuscated program. So the question is, how do we get useful levels of protection from individual transformations that only provide time-limited protection? So let's now talk about how we might deploy obfuscated programs in practice. What do industry do in this space? Well, they essentially have three strategies. First of all, industry monitors online hacker forums to find out which of the transformations is about to reach the end of their life. And then, in their back pocket, they have new transformations that they can roll out when the old ones no longer work. And third, you have to deploy your current set of transformations in such a way that your adversaries get an ever-changing and diverse set of targets to attack. And I'm going to next talk about the third point here. We talk about three kinds of diversity, spatial diversity, temporal diversity, and semantic diversity. With spatial diversity, you give every client a different obfuscated program to attack. And this is easy for us to accomplish, because if you remember, the obfuscator takes a CDES input from the same input program we can generate multiple different obfuscated versions of that program. And the hope is that these obfuscated variants are so different that collusion between the customers or adversaries is not going to be possible. With temporal diversity, your client sees a sequence of code variants over time. And the idea is to overwhelm his analytical abilities and to give him a small time window to execute his attack. This is sometimes, this goes back to a paper on the Depression from 1932, which calls, which talks about planned obsolescence. Semantic diversity is similar to temporal diversity. In this case, too, the adversaries see a sequence of obfuscated code over time. But the difference here is that the variants are semantically incompatible. So that means that Bob has to crack and re-crack every new variant of code that we send him because the old ones have no value to him. So early on in this talk, we talked about a particular scenario when we have a trusted server talking to untrusted hosts. For example, the Snapchat app on your phone is untrusted, but it talks to a Snapchat server which is trusted. This turns out to be a good scenario to implement a diverse system. And so the idea is that we're going to the secure server, the trusted server, is going to force new code updates onto the untrusted client. Again, the idea is that we're going to overwhelm his analytical abilities. And this is a system we built a couple of years ago around the Tiger's OfficeGator. And it does continuous replacement of code at the function level. And so you have a server to the left, you have the client to the right. And in a normal case, the client and the server communicate the way they might do over remote procedure calls. But once in a while, we'll pause execution and we'll start sending over newly office-gated function blocks. So that's temporal diversity. And we can turn up the rate of replacement depending on the threat scenario. We're also giving every client a different set of blocks. So that's spatial diversity. So let's look at how we do semantic diversity. So here's an example. The server starts by sending over a function 2 and the client immediately hacks it. Then the server again sends over a new version of function 2, which is semantically different than the previous one.  I already have function 2. I don't have time for this. I have other things to do. I will just ignore this update. And then at some later point in time, the client sends a remote procedure call but from the old outdated code. And the server will detect this and can either shut down communication or punch them in other ways, for example, by sending some function of death over. So where are we so far? Well, we have seen some scenarios where obfuscation is useful. We've seen obfuscating transformations that give us time-limited protection. We've seen updatable security for longer-term protection. But how do we know that we're doing anything good? How do we know that these obfuscating transformations help us at all? So let's talk about how we evaluate obfuscating transformations. And the sure story is that I don't think we have a clue. So as an academic, I would like to be able to write a paper that says, hey, I've got this wonderful new code of transformation and it's got better performance, better security than previous one, and so please, Mr. Reviewer, accept my paper. And without being able to do this, it's very difficult for this field to make progress. So what does industry do? Well, when industry has a new obfuscating protective transformation, they give it to a professional red team. It could either be internal to the company or external that they hire. And the second thing they do is that, again, they monitor hacker communities over long periods of time, so they built up a wealth of the information on which transformations work, for how long they worked, and so on and so forth. Now, unfortunately, and this may come as a shock to you, they do not share this information with us. And this leaves me as an academic in a bind. Because I can't afford to hire a professional red team whenever I want to publish a new paper. So in academia, we instead invented programmatic ways to do evaluation. And it goes something like this.  So this is like a stand-in that we have for red team evaluation, which is really what we would like to do. So which metrics should we use? Well, people have tried a number of things. The first thing that comes to mind is, well, let's just use students. Students are almost like professional red teams, except infinitely cheaper. Unfortunately, students are nothing like professional red teams, they're inexperienced. And also it doesn't scale, right? If every time I want to write a paper, I have to get new group of capable students together to evaluate my code, it's not gonna work. And so how would you do this? Well, you would obfuscate your program, and you give it to your students, and you would time them, give them a task like extract some asset, and then they would time them, see how long it takes, and that would be your metric. And also if you use the same students over and over again, they get better over time, and so your measures will be skewed. The second idea that people have come up with is to use what's called software complexity metrics. And these are developed in the software engineering community many, many years ago to evaluate the structuredness of a program, how well-structured a program is. And here are two common ones, one called not count and one called cyclomatic number, and they evaluate the structuredness of a control flow graph, of the control flow inside a function. So the problem here is that these were invented for a completely different task, and it's entirely unknown whether these metrics actually measure something that's useful for an obfuscated transformation. It says anything about how an obfuscating transformation would perform in the field. And also there are literally hundreds of these in the published literature, and which ones should we be using. The final and most common one is called, is using analysis tools, and this is what people tend to do.  To give you an example of that, while back we were interested in evaluating one of our transformations, and so we wrote this little point function, ran it through Tigris, and then CLI, and CLI finished in half a second. So this is not good, right? It means that our obfuscation is not very powerful. So we say, okay, well let's tweak it, let's add some other transformations, and we did the same thing again. Now if CLI had come back and said, still takes me half a second, we were to think, well, you know, that's probably not a good improvement, but that's not what happened. What happened was that it now took 10 minutes, and of course we're very excited. Clearly we've made an improvement, but did we? Well the fact that CLI now failed or took longer could be due to many different things. It could be a bug that we just tickled, it could be a performance bug that we tickled, or it could be that our transformation is actually fundamentally better than before, it's really impossible to know. So what's missing here is some sort of validation step. We need to know which of these metrics, or which combination of these metrics in this programmatic way of evaluating obfuscations actually related to how well transformation would perform in the field, how well a red team, for example, would be able to attack this. How would we do this? Okay, so this is what I'm kind of working on right now. We're gonna start by building a model of real hackers, how they really attack obfuscating transformations, how long it takes, which tools they use, how long they use them for, and so on. I'll tell you in a second how I'm proposed to do that. And then we're gonna correlate, so we're gonna build an adversarial model of what hackers do, and then we're gonna correlate that with these potential metrics, a combination of these metrics. Okay, how are we gonna build this adversarial model? Well, soon you'll be able to download from our website this virtual machine. It has inside it all the state-of-the-art code analysis tools that we've seen. It also has a bunch of challenges. And then you are going to download this, and you are going to crack these challenges. And why, Christian, are you telling me? Why should I be cracking these challenges? Because if you do successfully crack the challenge, I will give you a boatload of cash. And in exchange for this boatload of cash, you will allow me to run monitoring tools in this virtual machine that would send back to me information about the steps that you took to crack my challenges. And if we'd be able to run this for a long period of time, hopefully we'd be able to collect enough data that we can build these models and use them in our evaluation. And generating these challenges, by the way, is kind of an acute problem. So we modify tigers to generate random programs. And that in itself is a huge problem, in which I don't have time to talk about today. But essentially, you can generate a random program, and that random program can have random assets in it. And then we pipe that through tigers again, this time officiating with different sequences of transformations, and that's how we generate these challenges. We can have many different challenges of different complexity. And this VM is not up there yet, but there are some challenges, and there are some cash prices and book prices. You can give this to your students as exercises. And the first challenge has been broken pretty quickly by a Google engineer, but the other ones are still up there. All right. There are four points I would like you to take away from this talk today. The first is that meeting security criteria without meeting performance criteria is not a solution in a made scenario.  That's not a problem. The problem is creating useful level of protection while keeping the performance within bounds. And this is complicated by the fact that we're often working on constrained devices and have severe usability constraints. The second point is similar, but it applies to Bob instead of Alice. Meeting precision criteria without meeting performance criteria is not a solution for anti-malware analysis. Real programs are really, really large and these analysis need to scale. And if you tell me, hey, Christian, my analysis broke your new obfuscation transformation, that's really meaningless without you telling me what the performance is. The third point is that obfuscating transformations are primitives that provide time-limited protection. So we expect all obfuscating, language-based obfuscating transformations to be breakable, but we expect it to be some performance cost to the attacker. And sometimes we can use updateable security to extend that period of time. And I showed you how this is particularly applicable in a client service scenario where it's easy to push new updates to the clients. And the fourth point is that to make progress in this field, we as a community must get together and settle on rigorous evaluation procedures. So evaluation is really a mess. We need to fix this. And maybe someone in this community would have some ideas on what to do. I would love to hear about that. And I showed you how we're gonna try to learn from public challenges. So I'd like to leave you with this table. It's not a very interesting table because it's an empty table. I would like you to fill it out yourselves. There's some exciting developments in the hardware community. Intel is now pushing out secure enclaves into their chips. There's exciting development going on in this community with indistinguishability obfuscation. And how is this going to play out? What's going to happen long-term? Which techniques will prevail? Maybe they will coexist, but in different scenarios. And the question that's most interesting to me is, are there scenarios when actually we wanna combine these three techniques in some way? And how would we do that? I think that's very interesting. And so anyway, it'll be very interesting to see how this will play out long-term. So thank you very much for your attention and I'll leave the floor open to questions. Thank you. Any questions or comments? Aren't you worried about the same problem with challenge problems as you are with students that it's a measurement at a point in time and that two years later, people won't be using the same flows, the same techniques, and your metrics get outdated very quickly? Well, I think what happens is that the tools get better over time. I don't think humans get better over time. We are limited by this. I'm more worried about there's one guy out there who really, really wants the money and breaks all the challenges. And we learn only from him or her. I'm not sure what to do about that. Thanks. You said that indistinguishability obfuscation is prohibitive now performance-wise. I wanted to understand more about your security criteria if performance wasn't an issue. Let's say tomorrow there's no issue. It's very fast. Will indistinguishability obfuscation provide a good enough guarantee for your needs? Well, I think the point of the talk was that performance action does matter, right? I absolutely agree. I just don't understand the security criteria. I have no real answer to that. Only that I have one data point which will not help you, which is one guy in industry, and this is a person who is a cryptographer and knows what he's doing, said, no, it doesn't help us. It's not what we want to do. But I can't help you anymore. He didn't expand. And so, like I said many times in this talk, industry, lots of interesting stuff is actually going on in industry and they don't talk to us. And this is a huge problem, right? So sometimes they throw me, I mean, I know all these guys, sometimes they throw me a morsel of information, but it's often not enough to, in this case, answer your question. Approach, you talked about a million software based. I just wonder if there's any development along this line that maybe employ some secure hardware. Oh, there's lots of stuff. There's minimal secure hardware. And like I said, the most interesting thing is probably these secure enclaves that's coming out from Intel, right? So essentially you can put encrypted code on your CPU. And I'm not sure exactly, I'm not an expert in this. I'm not sure how this will play out, but it's one of the issues is who gets to put encrypted code on your CPU, right? Because the two people or two organizations that would most likely want to, we first in line to put encrypted code on your CPU would be the NSA and malware writers. So probably not everybody will be able to get the keys to do this. And there are also side channel attack issues with these type of, and there are also software hardware type, like used to be that people would put dongles on their software, right? So you could only run your software with a dongle. That's still done in little bit for very high value applications. And then the link between the dongle and the application software has to be heavily, heavily obfuscated because that's where the attacker would, the attacker would not attack the hardware. That's painful. They would attack somewhere in the middle between the application and the hardware. So in your models, the bad guy is the end user, but obfuscation is also used in malware industry. So is there any difference with the techniques used in this malware industry and in the software industry? And who is in advance? Is there any big difference between the two? Well, so VM Protect, for example, was the one that tools I was telling you about. And it's a commercial tool that's targeted at normal software developers to protect their tools. But of course, they have customers in the malware community as well. And so the same tools are used both by the malware writers and by the software developers. The latest, you know, high quality malware that come out from state actors, like Stuxness and those things are pretty well protected. It took quite a while to reverse engineer them. For the mass market, maybe not so much. So you talked about evaluation only from the point of view of running attacks and these threat teams. Are you aware of anybody who has come up with these obfuscation solutions trying to show formally some hardness or some formal argument about why their transformation are non-reversible? Oh, yeah, we do this all the time. Just like you guys, we'll say, oh, here's a hard problem. Let's build, and in our case, it's a hard problem from a static analysis or dynamic analysis point of view. So we'll say, here's a hard problem for static analysis. Let's build an obfuscation that leverages that. Can you give us an example of what you consider a hard problem? Yes, so alias analysis is a problem in static analysis. Essentially it's pointer analysis. The question is, if you have two pointers in your program and could they ever point to the same thing? That problem turns out to be undecidable in general. Wonderful. Let's build some obfuscations based on that. Great idea, but there are two problems, at least. One problem is that, well, the attacker doesn't have to do static analysis. He can just turn to dynamic analysis and then this problem just goes away because alias analysis is hard for static analysis. It's not hard for dynamic analysis. And the second thing is that, even if, yes, this is undecidable in general, how do we create a random instance of this problem that is actually hard? It's like using knapsack for cryptos. It turns out to be a bad idea, right? So I don't think anyone knows how to do that. But yes, we try to build our obfuscations based on known hard problems. But practically getting to an instance that's hard is difficult. And it's always possible, it's maybe always possible for the attacker to go around this and try something completely different. Any further questions? If not, let's thank Christian again. Thank you. I think we have the usual coffee break now and continue at 10.40 with the last parallel sessions.


Thank you for the introduction. It's a small group, so feel free to ask at any time if you have any questions. We're going to switch gears a little bit from metastatic disease and therapeutics to surgery, which is a kind of a linchpin to treating kidney cancer as well, especially in the localized fashion. I have no disclosures to reveal. So kidney cancer surgery has gone, undergone a pretty major evolution through time through the decades. And initially it was something that was I would call maximally invasive. And now there are great strides that are accomplishing equal efficacy from a cancer control standpoint and safety, but doing it through much smaller incisions, which is better for everyone involved, especially the patient. So modern radical nephrectomy, meaning removing the entire kidney, was described about five decades ago, plus by Dr. Robson in Toronto. As you can see, the access to the kidney does require a pretty large incision. You can see right here. And that incision carries through the rib cage. The reason the kidney is where it is is because it's protected by those ribs. The problem is from a surgical standpoint, getting through to that can be extremely painful for the patient, for those of you who've ever broken a rib. So that's how things started back then. Unfortunately, we're not we're not there at this point in 2017, but the principles involved are really controlling the blood supply early to prevent any further tumor spread through the blood system and moving the entire kidney along with the adrenal gland. That's kind of what was proposed and practiced at that time with Androides fascia, which is the envelope of fat that surrounds everyone's kidney. You know, back then survival wasn't great. Five-year overall survival was in the 50% range. It's really because we didn't have a, we had no essentially diagnostic imaging modalities. There were no CT scans and ultrasounds, no nothing. So basically finding cancers like this, what they were usually found at very late stages, which is not the case today, luckily. So that was the gold standard treatment for renal masses for quite a long time, probably for 30 years, until more minimally invasive approaches came along. Just because we are talking more about kidney cancer and how it can run the gamut, occasionally kidney cancer can involve spread into the vena cava, into the main renal vein up the vena cava, which happens about four to ten percent of the time. So I don't know if you can see the scan right here, but basically here's the right kidney. Here's this tumor thrombus essentially going up the vena cava. This is the main vein that drains into the heart. So kidney cancer does have a predisposition to do this more so than a lot of other cancers out there. And basically the staging which I'll go through depends on how high the tumor thrombus can extend. So I think long and short of the talk also is that kidney cancer can be a disease that can be treated with minimally invasive means, but because of the nature of kidney cancer and the nature of where the kidney is, it can do some damage with regards to things like this and cause the necessity to do much much bigger procedure no matter what. And again the thrombus can stay within the renal vein like this where these can usually be managed through minimally invasive means like laparoscopy or robotics. Once they get into the vena cava or up into the heart even then that becomes a much bigger surgical deal. Luckily these patients actually do fairly well as long as there's no evidence of spread into the lymph nodes. And this is actually data that precedes what Dr. Schoenervos alluded to in the first talk, you know with these newer medications they're not so new anymore actually. TKI's that can control kidney cancer from spreading. Even back then the overall survival for situations like this was quite good despite not having the the therapeutics that we have today. Again the reason why doing surgery in the kidney can be more difficult is that it basically, the kidneys basically lie very very close to the main blood supply for your whole body. So if you look at this, here's your right kidney and this is the right renal vein. It drains directly into the inferior vena cava which goes up to the heart. So any sort of kidney surgery can be fairly hazardous from a blood loss standpoint and we'll get into that. But that's why that's why doing surgeries like this can require a great deal of surgical skill and technology to make sure you have the best available capability to make sure you control bleeding and any sort of post-operative complications regarding that. Again when tumor thrombosis is involved with the vena cava, what you need to do is actually stop the blood flow of the vena cava temporarily. So you're cinching down these vessels, this is the renal vein, this is the vena cava to prevent massive blood loss. When you open this up to pull this tumor thrombus out and in another diagram again, these types of surgeries can be very technically challenging for the reasons just described. So I mean this is kind of what it looks like when you take a kidney out. There's this envelope of just for the people who don't see it. Yeah, I know some grimaces and stuff. Luckily there's no blood and guts yet. Those will be, those will come up in videos later on. But you know you try to clean these things off so you know for for photographic purposes but here's the kidney. You can't, you know patients always ask me, did you see the tumor and I said if it's a big tumor you don't really want to see it because it's encased in this envelope of fat. You don't really want to disrupt that.  You really don't want to disrupt that and over here peeking out and I'll think of a yeah a little bit slightly close close-up view of it is the renal vein and the tumor thrombus. And this is kind of what kidney renal cell, clear cell renal cell carcinoma looks like. It's kind of this bright yellow looking mass. So it's very diagnostic and you know when we, we'll go into that later but when I take out smaller tumors I'll make sure that the entire small tumor has been removed and when we cut into it this is kind of what it looks like. If it doesn't look like this bright yellow thing then it's maybe not cancerous, it might be something else. Yes this was, oh yeah we'll get into that but right. You have to make a, you have to make a slightly larger incision to get it out but you don't have to make it in a place that's really, really painful. In other words you know back in the day you have to slice the ribs and stuff that's really painful. Probably the least painful part portion of your body to remove something is kind of where women would have like a C-section like below the belly button. So you try to move it through there because it's less painful and it's cosmetically less, less difficult for the patient. I'll show you a picture that will illustrate that. It's a good question you know I kind of joke at the patients and say yeah just leave it in there. You know you may roll around a bed and I feel like a bump bump it's okay it'll go away. No it's kidding no. You have to pull it down. We kind of make, we put into a bag and then make the bag with just large enough to accommodate essentially the smallest, the width essentially the smallest proportion or smallest dimension and pull it out. And as the trend goes we're always talking about doing things less invasively from a surgical standpoint and a situation like this is no different. So instead of making an incision you know way up and down here like a sternotomy you know there are other ways to to improve the cosmesis and the pain involved with surgeries like this. So again the trend has been towards in surgery in general doing things less invasively and you know for a variety of reasons the most obvious one is obviously for the patient's sake. So Dr. Klayman who's now at UC Irvine I think at that time he was at St. Washi in St. Louis. He described the first laparoscopic to Frackman in 1990 so we're talking 20 plus years, almost 30 years. And then Dr. Winfield who's he used to be here at Stanford I think at this time he was that point in time he was at also Washi described the first laparoscopic portion of Frackman. And you know others did hand assisted laparoscopy where you put your hand in there to help you know manipulate the the kidney and the tumors. And finally in the 2000s we're talking about robotic surgery. Now we'll get into robotic surgery a little bit more in detail a lot more in detail but basically is there a big difference in cancer outcomes between doing it open versus laparoscopic and what this table shows that there is not. Of course if there was then you wouldn't be doing it this way it wouldn't be worth it. It wouldn't be worth the even the you know the recovery time and all if it wasn't cancer from a cancer standpoint wasn't viable but it is and that's good for everyone involved. And the major difference when we talk about minimally invasive approaches or laparoscopic approaches is like unlike that big incision you saw and are seeing here again with laparoscopy we're making small incisions usually the you know the width of the tip of your finger your thumb. So obviously that's going to impart a great deal less pain and suffering to the patients afterwards and reduce their hospital stay. So to your question how do we get it out of there? Well so there are there are entrapment bags and we can unfurl inside the body and then kind of stuff it in there and then there's a drawstring to pull it out of the body. So yes the skin is elastic and you know again because you have a bag there you just really have to get it the incision just wide enough through this through the smallest dimension of the kidney and just pull it out and you know and that's even that's actually better than even trying to put your hand in there and pull it out because your hand is a certain dimension to it as well and you can't actually exert as much force because you could disrupt the tumor so this is actually the ideal way to do it and if the tumor disrupts it's in a bag so it's kind of contained. Yeah I mean again to disrupt it would take a great deal of force. It would almost take you to intentionally try to disrupt it rather than pulling out of the you know out of the body so this in and of itself is usually not enough to disrupt it but even if it did it's in a bag and it's not going to jeopardize the pathologic analysis but but to your to your question also you know there are certain I don't think they do any more but there are certain specialties even certain surgeons who would opt to morselate something like this and morselation means like putting a essentially like a food processor a quesanard into this bag and just kind of homogenizing it which is really not a great idea for a couple reasons first of all is that you know to your point you don't have a lot of it basically you basically homogenize the entire specimen so you don't have a great pathologic ability to analyze it number two is if you puncture the bag then you're in trouble right because now you spill that entire milkshake in the body you don't want to do that so so I mean in the name of cosmesis you don't want to you don't want to jeopardize cancer control for cosmesis I mean who cares if you have a tiny incision right I mean not going to wear your speedo anyway so well you might but so tumor size is an important criteria but there really is no true limitation to what can be handled through mainly invasive approaches as long as it's feasible there are challenges though and unlike an open surgery when you do these things mainly basically you're not actually opening a big incision so you know you do have the limitation of the actual body cavity with which you're in which you're working nonetheless still despite that things are usually feasible up to a certain size even more challenging cases like this where there are tumors in the liver and the reason is is because trying to get to the vessels laparoscopically or robotically is a lot easier than doing an open because you don't have to like try to fight your way through here and look around here you can actually put this camera which is very low profile directly into this space and be able to control the blood vessels Dr. Srinivas showed you that molecular pathway of kidney cancer and and basically what most well not the immunotherapy treatments but with the tyrosine kinase inhibitors what we're trying to do is stop the process of recruitment of blood flow to the kidney tumor that's essentially what kidney cancer is doing it's actually trying to recruit blood flow to itself from a surgical standpoint what we see is these things here these are like like channels of blood that have been pulled in from other parts of the body adjacent parts to feed this thing it's like the aqueduct right they want to build from the delta to southern california not that I'm saying anything politically here but you know you're diverting water away to a distant area this is kind of what's happening and actually doing these laparoscopically is actually a little bit easier to control these things because you can actually see them better and when you perform a laparoscopic robotic surgery you're actually insufflating the belly with gas to a certain pressure and that usually exceeds the pressure of the venous return of the vein pressure in these small vessels so it actually decreases blood loss which is a good thing so what I tell patients or attendees to conferences like this is me just talking to you can be really boring I might show you some real life videos all right I mean and it's you know I mean it's nine whatever third in the morning you know if you need a cup of coffee I mean you know this is something that'll actually keep you awake so anyway so so basically the idea with any kidney surgery is to find the blood supply to the kidney and this is a robotic robotic case and you'll kind of see that because these instruments are a lot more versatile but basically you're trying to find the blood flow blood supply so here's the artery this is the right kidney I know because this is the vena cava here here's the artery you can see it pulsating you want to kind of get that freed up from the strong attachments so here again here's the artery and the vein is right next to it and the vena cava is right below here so again the goal is to find the vessels you know this thing looks huge but in reality it's probably less than the width of this cord which is an advantage to these minimally invasive procedures because everything's so magnified you can see a lot better when we talked about this okay so remember those cases of tumor thrombus how do we deal with that now what that first video didn't show you was how we deal with blood vessels you know from a minimally invasive approach what this thing here is actually is a it's a vascular stapler now I mean when I say the word stapler you're thinking I'm like you know stapling pieces of paper together well yeah I guess that's kind of the the crude concept but that's not really what happens here so what the stapler does it's going to fire I don't know if you can see this but there's rows of indentations here and all those rows represent a row of staples so this thing is going to fire six rows of staples titanium staples and then cut in between and actually that's a very very secure way of dealing with blood vessels in the body probably much more secure than clips if you can do it this way so so that's I'm going to show you how this how this works again because you know me talking about you know survival and stuff can be quite boring this will actually give you a little more real-life insight to what actually happened so so this stapler is going to fire on the renal artery and it's as simple as that and then you can see kind of the stapline and the pulsation and I can I can re show this to you now there's a tumor thrombus in that vein you can kind of see that yellowish thing here remember that yellow thing I showed you there's a tumor thrombus in this vein but because of that because the tumor thrombus is kind of not into the vena cava because the vena cava is below here we're actually able to deal with it in a fashion like this whereas in open surgery you need pretty much a decision incision from your chest down to your pelvis to take care of this now again I mean you know one size does not fit all but when we can do this way it does greatly improve the recovery time and pain and of the patients involved and again I'm trying to you know limit the amount of blood and guts not that we're going to show a lot of that but you know it's just to show it illustrates to you that you know the way these things are done are done a certain way I can be done in very exact ways and magnified again the even the renal vein is no wider than my I don't know my my third finger here so fourth finger sorry not my third finger and you know again there are other ways like putting a hand in there and milking back the thrombus unfortunately when the thrombus gets way high like this you're going to need to as seen in those previous illustrations and slides to basically put the patient on bypass stop the heart because otherwise you won't be able to get that thing out without the patient bleeding to death now what about so any questions about that all right so Dr. Schoenervals touched on what do we do when there's metastatic disease you know do we still take the kidney out so the guidelines are that we should if the kidney is removable if the kidney and tumor are removable and if there's you know if there's a solitary area of spread we should try to move that as well if there's multiple areas you know if they're usually not completely respectable in the same setting but there's something that is respectable that's close by that you can get at you should take out take it out as well too now this is data from 12 13 years ago and this data precedes and Dr. Schoenervals alluded to this this data precedes the medications we have now the tyrosine kinase inhibitors like seraph nib and synidinib back then what they found was that removing the kidney did impart a survival benefit not a lot probably about four or five months but but not nothing and that was the era where we're using interferon and this was what they're testing up against so patients who got interferon and nephrectomy did better from a survival standpoint that those who did not now at that time you know what did they say well the patients do benefit from removing the kidney the ones who do the best actually have better performance status they're overall healthier if they have spread it's only to the lungs and that's more favorable and their tumors have good prognostic features so that that's what we know that's what we knew back in 2004 from them doing the journal paper since then you know we talked about TKI's but can we do it should we do it be doing it minimally basically and the answer is we should because it can basically put the patients back on treatment faster because the recovery time is faster so if you can remove it through minimally invasive means you should because it's better for the patients and they can get back on treatment faster which is what they really need to keep things at bay now what about doing nephrectomy and patients who have spread in the era of triosin kinase inhibitors which is where we are now we don't really know that yet so there's this trial and Dr. Srinivas and I were talking about this there's this trial that started back in 2011 trying to answer that question so you know do patients do better they're randomized do they do so to randomize into two arms whether they start with their kidney removal and then starting on synedinid or synedinid alone and there's another trial which I think is called SIR time which is testing something similar but along the same lines which is do they do better patients do better if they have their kidney out first or they have treatment first so I think this trial was started in 2011 and 2012 as well so what's going on with these do we have any information well I actually recently came upon this question or this manuscript in european neurology which says cytoreductive nephrectomy the tyrosine kinase inhibitor error a question that may never be answered okay why is that you know we do have data out there that's not randomized like those trials that suggests that it is beneficial to get the kidney out but we don't have randomized trial level data I think the reason why they're having trouble answering this question is because trying to get patients enrolled in this trial has been very difficult and I think it has to do with patients we see in our clinic and this trial mind is being conducted in Europe so let's say you have a patient that comes in your clinic and their kidney looks and they have metastatic disease but a kidney looks eminently removable you're going to kind of want to remove it and if you you know you might the surgeon or even the medical oncologist may feel a little bit uncomfortable about the prospect of saying okay why don't we put in your trial and see what happens knowing that if you put them on trial and they get on going medication that their kidney may eventually become unrespectable not removable so I think those are the kind of the issues that have come up that have made it hard for people to get recruited into a trial like this so nonetheless I think the preliminary data there are some preliminary data that's not necessarily great because it's not powered to answer the question but that suggests that if you can't again if you can't remove the kidney you should do so if you can't then put them on trial and see what happens and if they have a response then try to remove it later but again if you can remove it then move it up front and not wait and that's the that's the to the best of our ability to know at this point what we should be doing in today's era of tyrosine kinase inhibitors yeah so we talked about this now I'm going to shift more towards what is I guess more commonly found these days with kidney cancer and actually the number of cases in kidney cancer have been going up until recently I think the number has started to slide back down which is encouraging but most of what we find are actually small four centimeters or less and the reason we're finding those tumors at smaller sizes is because we're scanning people they're getting scans because they have belly pain they're getting ultrasound they're getting scanned for other reasons then we stumble upon it unlike what it was like before what I mentioned back in the 50s where didn't have any imaging so basically if you're going to stumble upon it you're going to stumble upon it because the patient has real symptoms and they have blood in the urine and their pain and whatnot so for these smaller tumors what should we do should we take the whole kidney out the answer is no we should try to save the kidney if at all possible if at all possible and we have lots of data to suggest that moving part of the kidney is just as effective as moving the whole kidney so we shouldn't really be moving the whole kidney because there's no cancer there's no cancer reason to do that but also well also there's a when tumors are smaller they can be more likely benign in certain series we found that but also moving the whole kidney is not necessarily great for the patient overall and that doesn't that's not doesn't take a huge stretch a leap of faith to understand that but you know it does make them closer put them closer to dialysis it also does have which I don't touch on here but also have can have negative effects on cardiovascular health and and things like that so if we can save the kidney we should and this is where robotic surgery comes in now you know when I talk to patients at robotic surgery they're like well I don't want some robot operating on me well you know I mean I'd be I'd be thrilled if I could push a button and leave the room you know like you know like some Ford assembly line you know there's a car at the end of the line and I've just had a couple cups of coffee or you know like a Roomba right some things vacuuming your house you know I mean that would be great of course you know the thing gets stuck under under the couch and not move the whole day that's not great either which is why which is why I mean basically the robot robotic surgery means that we're using a very sophisticated instrument that has articulating instruments that has magnified image capabilities and 3d optics to do high level surgery and that's what we're talking about with a robotic partial refractomy and these things have arms and hooks and instruments you know but I mean these are greatly magnified I mean the real size of these instruments is really like about that big so so for doing surgery like this it's actually very helpful and here's some more videos that will show you that but basically the the goal of a the goal of a kidney tumor partial refractomy and saving the kidney is to find first the blood supply just like that other video and but instead instead of dividing and stopping the blood supply we're going to stop it temporarily so this is the right side here's the vena cava here here's the renal artery and here and here's the renal vein you don't hold your breath it's not there's no surprises here no no no that's for a different talk for a different time but again the the goal is to find the blood supply and control it that's kind of the goal with all kidney surgeries because the what I tell patients is that kidney surgery can be very unforgiving you saw those pictures where the blood supply you know runs directly to the heart I mean there's just a lot of flow into the kidney and unlike whether organs to control it I mean there are like organs like the livery can just like electrocoagulated and will stop not with a kidney gotta do more than that what do you mean you mean as far as instrumentation because we don't have fully automated instrumentation oh yes oh yes claws probably not the right term but yeah yeah I mean the the surgeon is controlling every single thing that occurs there's no autonomy whatsoever someday but there's zero autonomy I mean this is whatever you do is directly translated into the into the movements that are happening inside the body with these instruments yeah that's because so it's kind of a misnomer robotics really in this context means I mean the the robotics the roboticist out there call it a master slave relationship so the surgeon's the master and the robotic the robot is the slave but basically it really is just a way for you to approach this in the most in the most technologically advanced and only invasive way possible there's no autonomy yes why why why India that would be wonderful I mean that would be I mean I could get through my day so much faster well that's why I try to in forums like this try to you know try to set it the record straight you know again yep and I'll show you this part here which is so again you need to control the blood flow yes yes yeah in 30 minutes that's correct because if it's going to take you a lot longer than that then maybe you should think about doing them a different way like open where you can actually put ice in the kidney and kind of decrease the metabolic demands and the time constraints but you know be that as a may I would say that the vast majority of these things can't be handled in 30 minutes or less and what you're seeing here is removing the tumor robotically so that tumors kind of this kind of this ball sticking out from the surface here and that again the goal is to remove the tumor cleanly and completely but not you know not take so much normal kidney tissue that you've compromised the overall kidney function more than you need to and you know there are some bleeding here I would say this is less on the on the lesser side there can be much more than this so it's important that you have kind of a a very experienced team working on things like this because again with the kidney there can be a lot of a lot of variability to how complicated and how much blood loss that can occur this is actually not that much if it's much more than this then again you need to make sure that your team is prepared to handle that and you know my personal opinion is that if you're going to be doing something like this you probably shouldn't be doing it once a year you know more like once a week just so you don't just like anything the more you do the more frequently do with the better you're going to be at it you know if I were going to try to drive an 18 wheel or a guy only knows what could happen you know I don't drive an 18 wheel for that reason and for that same reason you know this is this can be a very complicated thing but again the goal is to remove the kidney as move the tumor as cleanly as possible and as quick a time as possible there is some bleeding here and we'll see how we have to deal with that so we tuck that over there get over here having some issues then we have two sutured all back together so again the suturing is the most difficult part of this and it requires instruments at the robot to take platform allows you to use that can do things very precisely and accurately so again there's some bleeding there that can only be controlled with some suturing that has to be very precise and in nature and you'll see after this suture is thrown that it'll basically stop the bleeding so again there is no autonomy I wish there was that'd be great you know it's not like again you push up you leave this thing Roomba it's vacuum your floor and it's all done at the end of the day of course you know the reason you don't do that is because the capability of what can be done through autonomous machine learning I don't know what you want to call it I'm not a engineer it's just not we're just not there yet yep what brings about the decision to make it radical as opposed to a posture of that yeah luckily we have imaging studies that are very accurate that we can determine that preoperably but not always but again it's really the location and the size the location the size generally speaking if the size is below four centimeters it's much easier to save the kidney once it gets above that it can be much more difficult just from sheer size alone and the closer the tumor is to the um and here are those clips we used to control the blood flow uh what that tumor is much closer to the blood supply that runs to the center of the kidney it also makes it harder to save the kidney because that blood supply is going to be more easily compromised than if it's kind of hanging off on the edge I do we can talk about that as well all right so let me make this work I think we're running out of time but uh you know when we talk about robotic versus laparoscopic partial nephrectomy um that actually slightly favors robotic I think and we used to do these laparoscopically but it was very difficult for the reasons we just discussed just try to do those difficult maneuvers uh laparoscopically took a lot of really um specialized people who not everyone who could um this is a paper that came out last month that shows that um nowadays if you look at robotic partial nephrectomy about 64 or partial nephrectomy about 64 percent that orange line are done robotically as opposed to laparoscopically which is single digits or even open so I think again technological advances have helped us um improve or increase the ability to do things like this we can move on to that so that's robotic partial nephrectomy I'm gonna this isn't really surgery per se but I'm gonna talk briefly about ablation and actor surveillance so ablation means you're freezing or you're burning it and this is an example of freezing the tumor not cutting it out not cutting it out and that can be done via putting a needle directly through the skin into it or laparoscopically again cryotherapy is freezing it and rfa is burning it and the other things like microwave ablation hyphoo so there are a bunch of ways that this can be handled you know why isn't everything handled this way well I mean not every tumor can be handled in this fashion but basically what we know I mean we don't have a lot of long term data with regards to the how effective these things are but basically they are going to be inferior to cutting it out as far as recurrence of cancer they whether you freeze it or you burn it it's going to be inferior to surgery so it is appropriate in certain cases but not all especially not in younger patients probably should try to do whatever you can to eradicate the cancer in the best way possible and you know we don't have a lot of data but when we look at meta-analysis this is the most recent one I could find basically what they say is the review shows that both cryoblation and radiofrequency ablation are promising in patients with small renal tumors who are considering who are considered poor candidates in more involved surgery so again it's a it's a good option for patients who are probably not great surgical candidates long-term data is lacking longer follow-up and more rigorous head-to-head trials are really needed so I think and it says at the bottom they're giving the natural history of small renal masses a probably designed trial would follow these patients for at least five years in the absence of such data a portion of rectum remains the standard of care for small renal masses so we do have other ways other things that we can recommend and I do frequently for patients who I think fit the bill better with something like this because as you can see doing a surgery can be very invasive and and time-consuming and can impart a greater hit on the patient it just depends on making sure you choose the patients correctly finally as far you know we can just choose non-surgical options altogether and just just kind of watch and wait and why would we do that well I mean we know that these things don't grow all that fast and small tumors do not have a great propensity to spread and we have very good imaging modalities to follow these patients so I think if patients are older and they're not great surgical candidates and we don't think that their tumor will affect their lifespan in any way then we can just sit down sit back and watch carefully and again these are the best candidates and what we do know again through worldwide literature is that when you see these graphs like this basically what this is measuring is tumor growth over time and this is like going on for years so we know they don't grow more usually more than a few millimeters a year these renal masses even if malignant so that's kind of the basis of watching these things carefully if you know if we feel that the patient's life expectancy does not support doing something invasive so to conclude surgical options continue to evolve into less invasive techniques and we're continually advancing safety from a cancer control and from a surgical standpoint and again from non-surgical standpoint we'll continue to examine how effective or how safe that is to do with future studies as well thank you very much for your attention


Joe and Gay, hello, and congratulations. I'd like to thank Professor Shiappa so much for inviting me to your retirement dinner and for letting me send my love by video since I'm on vacation the week of the big event. I know you've done a tremendous amount of good in your years teaching writing at MIT. In addition to guiding students with their projects, you've demonstrated the way a working writer lives his craft, getting the job done day after day after day. As I should know, because I just checked and found out that I have been your editor since 1997. And I'm luckier than MIT since, as far as I know, you're not planning on retiring from writing.  Congratulations, Joe, and have a wonderful retirement. Hi, Joe. I'm really sorry that I can't be at your retirement dinner. And I really wish that I could be there to give you a hug and say best wishes on your retirement. Since I can't, I'll say it from here. Joe, you're one of my favorite writers. You're one of my favorite teachers. And you're one of my favorite people. And I feel like it's a great loss to MIT that you're leaving them, although I'm sure that it's going to be great for you to have more time for your writing. To MIT, I'd like to say you guys are losing a treasure. I'm sure you already know that. And the only comfort that you have is that you still will have Joe's terrific works. I'd recommend that if you start missing him, you go read, oh, say, Graves or None So Blind, or The Hemingway Hoax, or The Forever War, my very favorite novel, and one that I think about all the time. So you still have those works. I'm sorry you won't have Joe. Best wishes to all of you. And again, I'm really sorry I couldn't be there. Bye, Joe. Hello, Joe. It's a great pleasure to be able to talk to you. On the occasion of this great celebration, I'm proud of you, as everyone is. I want to say that I had one of the greatest conversations of my life with you at a convention in which I responded to your query about my well-being with the sentence, well, Joe, my whole life hurts a lot less now. And I want to mention The Hemingway Hoax, which is my favorite of all your books. So beautiful, so complex, and yet so clear, I cried at the last line.


Income tax 2021 2022 education credits specific instructions part number one get ready to get refunds to the max diving in the income tax 2021 2022. Most of this information can be found in the form 8863 instructions tax year 2021 on the IRS website irs.gov irs.gov income tax formula we're down on the bottom area with the credit section. Noting that both deductions and credits are good but if you had a dollar of credit and a dollar of deduction the credit would typically be better because you usually get the full dollar amount of the credit. Whereas the dollar deduction would be a decrease to the taxable income and then the tax being imposed on it at that point in time also note we have two main categories of the credits. We've got the non refundable credits and the refundable credits the non refundable credits not typically taking the tax liability below zero the refundable credits may which if they did would result in a refund but it's not really a refund at that point it's kind of like a benefit program at that time. This is the form 8863 the education credits American opportunity credit and the lifetime learning credits. Remember that we're generally thinking about these two things kind of together in that we're going to first be looking for that American opportunity credit because it's worth more typically. And if we can't get it then we'll see if we can still qualify for that lifetime learnings credit. This is the first or the top half of page two of the form 1040 where we see the non refundable component online 20 flowing in from schedule three. And then this is the bottom portion of page two of the form 1040 and the refundable area line 29 where we have the American opportunity credit form 8863 line eight. So line number one we're going by the line by line instructions we're going to be jumping back on over here to the actual form for the form 8863 line one part one. And this is after completing part three for each student into the total of all amounts from all part three in line one. So going back on over then to our instruction back on over to the instruction enter the amount from part three line 30. If you're claiming the American opportunity credit for more than one student add the amounts from each students part three line 30 and enter the total on those students on line one. So if I jump back on over we're going to say part three is going to be on page two where we have the information and we'll talk more about part three in a future presentation of course but line 20. We've got the student name the college in our place we went to cool you and then the address and we'll go into more of the detail of this information but the bottom line down here is we've got that 2,500 which is flowing into the page one here on part one page one part one. Okay back on over we're saying that if you're claiming the American opportunity credit for more than one student add the amounts from each students part three line 30. So remember we could have multiple students for the American opportunity credit whereas the lifetime learning we got the maximum amount per return and enter the total for those students in line one. So line three, enter your MAGI that's your modified adjusted gross income. Generally your MAGI is the amount on your form 1040 or 1040 SR line 11. So line three here and this is going to be important if we have any kind of like income thresholds that we need to take into consideration since it says enter the amount from form 1040 1040 SR line 11. And then you've got your exception that's where the modification takes in place. In our case if I go up to the 1040 we've got the 50,000 in line 11. That's your adjusted gross income and then it gets modified if any modification is needed for things like the form 2555 and the 4563 for example. Let's jump on back over. We're then saying however, if you're filing form 255 or form 4563 or are excluding income from Puerto Rico, you must include online three the amount of income you excluded for details. You can go to publication 970 line seven. If you are under age 24 at the end of 2021 and the conditions listed below apply to you, you cannot claim any part of the American opportunity credit as a refundable credit on your tax return. Instead, you claim you're allowed credit figured in part three only as a non refundable credit to reduce your tax. So that the refundable is usually going to be beneficial because that will be you'll be able to take that into consideration. Even if your tax liability because below zero. So we got this issue between it being refundable or non refundable. You don't qualify for a refund for a refundable American opportunity credit if one a B or C two and three below apply. So number one, you were under age 18 at the end of 2021 or be age 18 at the end of 2021 and your earn income to find later was less than half of your support. So basically you kind of qualify as a dependent is is in general. This is one of the dependent requirements here and see over over age. This is or see I should say over age 18 and under age 24 at the end of 2021 and a full time student defined later and your earned income defined later was less than one half of your support defined later. So you would think in situation a B and C that generally you you may be qualified as a dependent of somebody else possibly a parent and you would think then possibly if there was any credit it might be applied on the parent return in that instance. So number two, at least one of your parents was alive at the end of 2021. So now you've got your requirements that kind of that you may qualify as a dependent. You've got a living parent and then you're you're not filing a joint return for 2021. In other words, if you're filing a joint return, then typically married filing joint would mean that you're not a dependent at that point in time. Generally, you would be filing your own return line. The continuing on line seven continued. If you meet these conditions, check the box next to line seven, skip line eight and enter amount from line seven on line nine. If these conditions don't apply to you, complete line eight. If you meet these conditions, check the box next to line seven, skip line eight and enter the amount from line seven on line nine. If these conditions don't apply to you, complete line eight. So if we jump back on over on line number seven, we've got to multiply line one by line six But then we have the caution if you were under age 24 at the end of the year and meet the conditions described in the instructions You can't take the refundable American opportunity credit and then it says skipped line eight into the amount from line seven on line nine So generally we have the amount here 2,500 but then we can put the if we if we have one of those conditions We check the box with the condition so here you can see we got the calculation for for the refundable American opportunity credit at the 1,000 and then the non refundable component down here, which you could see flowing in ultimately to the form 1040 on page number two, we've got the 1,500 up top and then we've got the we've got the 1,000 down below I got the wrong I had the check at the wrong amount and then if I go back on over and We say okay, I'm gonna put the check here. I'm gonna check that box off We got no calculation in line eight and basically we're in the non refundable education credits here So if this pulls over again to the form 1040 and I go to page number two You can see it's all up top here in the non refundable Area and nothing is basically down here Which means it could be limited based on your your tax liability if it's up top here So for example if I bring the if I bring the tax liability down to 20,000 or I mean the income down to 20,000 now It's it's gonna be limited here to the income and if I go back then to this page To the actual form so that's gonna be the limitation Completed here with the worksheet and if I uncheck this if I go back on over and uncheck that Now we have once again line eight being completed and it's broken out between the refundable and non refundable So if I go back on over to the 1040 page number two, we're still limited up top But we now we've got this 1,000 that is the refundable component And that's the benefit of that kind of refundable component on down below Okay, so back back to it. We're gonna say number one Were you under age 24 at the end of 2021 if no stop here You do a qualified to claim part of the allowable American opportunity credit as refundable credits If yes, go to question number two question number two. Were you age 18 at the end of? 2021 if yes, go to question three if no go to question four question three Were you a full-time student defined later for? 2021 if no stop here You do not qualify to claim part of your allowable American opportunity credit as refundable If yes, go to question five Were you age 18 at the end of? 2021 if yes, go to question five if no go to question six Line number seven continued number five was your earned income to find later Lested one half of your support to find later for 2021 if no stop here You do not qualify to claim part of your allowable American opportunity credit as refundable if yes Go to question number six number six We're either your parents alive at the end of 2021 if no stop here You do not qualify to claim part of your allowable American opportunity credit as refundable credit if yes Go to question seven and number seven. Are you filing a joint return for? 2021 if no, you don't qualify to claim part of the allowable American opportunity credit as refundable credit If yes, you do qualify to claim part of your allowable American opportunity credit as refundable caution The educational institutions EIN must be provided online 24 a so if we take a look at 24 a On the tax return here. We're looking page number two 24 a we've got the EIN number that should be on the documentation received from the institution on the 1090 8t that we're going to be provided. We should have then the EIN number in it Then we have the earned income earned income includes wages salaries professional fees and other payments received for personal services Actually performed earned income includes the part of any scholarship or fellowship grant that represents payment for teaching Research or other services performed by the student that are required as a condition for receiving scholarship or Fellowship grant. So if you get a grant, but it's really kind of compensation Then it should be compensation And of course if that were the case you would hope then the institution the educational institution would give you the proper Documentation to reflect that so you could put it in to this return properly So you want to talk to the institution about those kind of things earned income doesn't include that part of the compensation For personal services rendered to a corporation which represent a distribution of earnings or profits rather than a reasonable allowance as Compensation for the personal services actually rendered if you're a sole proprietor or a partner in a trade or business in which both personal services and capital or material income producing factors earn income also includes Reasonable allowance for compensation for personal services But not more than 30% of your share of the net profits from that trader business after Subtracting the deduction for one half of the self-employment tax However, if capital isn't an income producing factor and your personal services Produced produced the business income the 30% cent limit doesn't apply Support so what a support mean when we're talking about the support tests here Support includes food shelter clothing medical and dental care education and the like Generally the amount of item of support will be the amount of expenses paid by the one furnishing such item if the item of support is in The form of property or lodging Measure the amount of such item of support by its fair market value to figure your support Count support provided by you your parents and others. However a scholarship received by you isn't considered support If you were a full-time student defined next for 2021. So what does it mean to be a full-time student? solely for purposes of determining whether a scholarship is considered support You were a full-time student for 2021 if during any part of any five calendar months during the year You were enrolled as a full-time student at an eligible educational institution defined earlier or took a full-time On-farm training course given by such an institution or by a state county or local government agency So usually the actual educational institution will have the definitions of a full-time student because it's not totally standardized It's kind of standardized by institution But you might have semesters versus quarters, you know and so on So you want to make sure that you talk to the institution as to what it means to be a full-time student