 Hello, everyone. Welcome to our five o'clock session. It's going to be amazing. Who's pumped who is excited? Yeah, woo! We're going to be talking about the dissection of WebAssembly module, which if you've been following the WebDev world, WebAssembly is a huge topic. And I'm delighted to introduce Patrick Ventizolo, who will be giving the talk. So a warm round of welcome for Patrick. Thank you. Thank you, everyone. Do you hear me? Yeah, good. OK, so today I'm going to talk about WebAssembly. So I'm pretty sure you heard about that. And maybe you also heard about WebAssembly with the crypto jacking talk before, because actually, I've used WebAssembly if it's available directly on the browser. So I will speak about WebAssembly. And I will do two analysis of real-life WebAssembly module, one on Ethereum and one on, actually, the con-ive WebAssembly module. So I'm Patrick. I'm a securities researcher for a German company called Co-Scient. And typically what we do, we develop to produce that is like a decentralized analysis platform, like straight-intel analysis platform. And part of my research time was dedicated to WebAssembly analysis. So I will introduce what is WebAssembly, of course, the WebAssembly VM. And after that, all the WebAssembly module is composed. And all you can do some analysis on it, like program analysis, like CFG reconstruction, call graph, call flow analysis, et cetera. So WebAssembly is a binary instruction format for a stack-based virtual machine, so the WebAssembly VM. And typically, the most impressive stuff with WebAssembly is that have been created by the four major browser vendors. So actually, they are part of the 3W3C community. And typically, the guy behind that are the guy of Mozilla, Apple, actually WebKit, Chrome, and Microsoft with Edge. So it's well-supported, and it's really amazing for that. When I say it's well-supported, that means actually 75% of all the mobile on the world can support it, and 83% of desktop users. So that's mean I'm pretty sure all of you in the room are able to run WebAssembly module directly on your browser. It's already used. Actually, it's already used most of the time for video game. Actually, even the official WebAssembly demo is a video game. It's called Tank, it's this one. So it's like a two-player game. So if you want to give it a try, it's funny. And the other pretty amazing demo is this one that is called Seven-Temple, and it's based on Unreal Engine 4. So it's based on Unreal Engine 4. It's really impressive. So just give it a try, and you will see. Actually, Wazom is also used in business web app, or huge web app. The main one is AutoCAD. And also, for those who know Google Earth, actually Google Earth is only available on Chrome because they use native client. But in the future, like in the next few months, they will release the WebAssembly version of that. That means you will be able to go in Google Earth on every available WebAssembly compliant browser. So in the last month, we got some interesting, like, Portage and Project in WebAssembly. So we got, like, a Portage of Veeam directly on your browser. So you can run Veeam directly on your browser and potentially don't get any issue to kill the application. And you have also, like, GS Linux that allow you to run Windows 2000 directly on your browser. So it's pretty nice for that. Also, for those who are more interested in kernel level, there is the Nebulae and Service project that will allow you to run a WebAssembly module directly at the kernel level. Sorry. For those who are more interested in, like, blockchain smart contract, there is actually two platforms that support WebAssembly. The main one is Ethereum. That is the second biggest cryptocurrency by market cap. So it's not, like, officially support WebAssembly. I mean, they plan in the next version of Ethereum that will be the Ethereum 2.0 to use WebAssembly, like, in the main network. But you already have WebAssembly support in the test network called Covan. But I will talk about it later. Also, there is EOS that use directly WebAssembly. So you compile your, like, C++ smart contract into a WebAssembly module. And this WebAssembly module will be stored directly on the blockchain. So if you want to learn a bit more about reverse engineering of blockchain smart contract, I have do a talk at recon this year about that, so if you want. So as I say, I think it's too tall earlier. We, someone spoke in this room about the crypto jacking stuff. And actually, yeah, ConIve use WebAssembly if your browser is compliant. And as I say, 83% of desktop users can use WebAssembly directly on their browser. So most of the time, it's a WebAssembly module that's going to be used. And typically, if an attacker wants to infect a website or even you as a legitimate user, you just need to add, like, a basic JS script like that. And it will work. But that's the reason I put illegitimate in parenthesis. We also see that in the last couple of months, a lot of, like, crypto jacking attack have occurred. So that's also the reason the ConIve services is not considered as fully transparent or fully good for usage. So let's talk about WebAssembly basics. So typically, you have a C or C++ code or even a REST piece of code. And you want to, you will compile it into a WebAssembly, a wasm file. So the wasm file will be the binary version. And you can convert it easily to a text representation. So that's the YST representation. It's the one on the middle. So actually, it's really simple as a representation. You have the, like, I will say, the definition of the module. That will be the first part. It uses S expression, so, like, leaps. And after that, you will get the function bodies for every function that you have. And you can find an X expression or you can find, like, a linear representation of low-level instruction. So it will be really easier to read in that case. If you want to switch from, like, the text format and the binary format, the easiest way is to use, like, a translator. And there is two translators that are available for the moment. Just to give you an idea, the instruction set of the WebAssembly VM is really short. It's well-defined in the paper. It's a totally complete instruction set. And there is only 172 instructions. So it's really reduced. And there is, like, a lot of duplicate instructions in terms of, if you want to do an addition between an Integror32 and another Integror32, you will get almost the same instruction with Integror64 and Integror64. So that's why I call that, like, duplicate instruction. The most interesting one for me is all the instruction about control flow, because, typically, that will allow you to create some block. You will be able to do some branch and call some function that means call, like, in-bed function by directly saying, OK, I want to call the function number two. Or you can do some indirect call saying, OK, I want to call the function that is, like, in an index function. And you will call the index two. And inside, you will get the number of the function. So also, in terms of, like, operators, you have everything related to arithmetic, some constant operator, et cetera, et cetera. So the easiest way to start with WebAssembly is to use nscripten. So it's the tool developed by Modzia. And actually, the purpose of nscripten was to compile C and C++ code into asm.js. But they do the support of WebAssembly. And you can use that as an easiest way to compile. Typically, the line on the bottom will be the compilation line to create, to convert, like, a low-word into a low-word.html. So the reason for that is it will compile into a WebAssembly module. And after that, nscripten will directly create, like, a JS Glue code and the HTML. So just with one line, you are able to, after that, load a WebAssembly module into a white page. So it's a pretty straightforward. If you want to directly develop your own stuff, you can directly use, like, an online IDE. Typically, WebAssembly Studio is one of the most famous. You put your C code there, and it will create a WebAssembly module. So that is the, like, text format representation. But it will also generate directly the main HTML and main the JS. Actually, the fact is, behind this online IDE, it's nscripten. So it's just the same, but directly on your browser. Personally, I prefer wasn't fiddled. It's almost the same, like, same idea. But you can directly debug and get visibility about the output directly from the interface. So at the end, for example, I have done this with the Fibonacci function, and you will get something like that directly on your browser. So I have a basic HTML file just there. You can see that I fetched the wasn't module. And after that, I will instantiate the wasn't module with this API. And I just put the exported function, that is my Fibonacci function, and directly call it with some argument. The result is I will directly get everything in my console. And if I want even using, in that case, I use Chrome, if I remember, you can directly get a debug visibility, the function body takes view directly in your browser using that. So for example, there, we can directly see the code of my Fibonacci function from Google console, like developer console view. If you want to learn a bit more about the different JavaScript API, you have everything on the MDN of Maudia. It's really amazing the job that they do. And actually, you will get this browser-compatible table in order to know, OK, which solution should I use if I want to be fully compliant with every web browser. For those who prefer not to use Chrome or any web browser, you have directly a standalone VM. So it's WayVM. And you can directly provide the text format or the binary format directly as an input of the function. So there, I use my Fibonacci module. I put debug in order to get a feedback of the output. And I precise, OK, I want to use the exported function Fibonacci. And I put as arguments 6, 7, and 8. And I get the result. So I get directly a constant that is the value 8. What is really cool with this standard VM is that it's the VM used by EOS. So it starts to be used a lot. And you can get some pretty good feedback and developer feedback if you need. So let's talk about this VM, what is inside? What makes web assembly a game changer for the web? So actually, the execution model is really simple. The fact is you have the linear memory and the global variables that will be in your application, in your host. So typically, on a browser, it will be directly in the GSM giant. And it's considered as interest. So I will talk about that just after. And you have the wasm engine that is considered as trust, trusted. And typically, you will get the function body, the indirect function table, and the execution stack on it. So the linear memory is just like a continuous byte addressable range of memory. You can access to it from a web assembly module using load and store instruction. And you can even increase the memory size and get the current value, the current size of the memory from a web assembly module. So it's pretty good for that part. And in terms of security, they usually, and they should, but they do, put some bound check array at runtime directly on the memory. I say they should because we got, I think there is one CVE on V8 because they don't do the proper checking. So they got a use after free or memory leak. Don't remember exactly, but they got a CVE because of that. So on the entrusted part, you have also the global variable. So it can be mutable or immutable. And typically, you will create a variable. And this variable could be imported directly in your web assembly module. And you can use that. Typically, you can see that like, I don't know, like parameter for web assembly module. And the user will provide this parameter. And this parameter will be a global variable. And this variable will be imported at runtime. The same way, you have just two instructions to do that. Get global and set global. So really simple, really efficient. And for the trusted part, so we call that trusted because there is nothing that can be modified at runtime on this part. So that's the reason. So everything, once you instantiate a web assembly module, it will stay like that. And there is no way to do some modification on it. So typically, you instantiate a web assembly module, like the Fibonacci module. And you will hold the code in the Fibonacci function will be immutable, completely immutable at runtime. And for the code indirect, so as I say, you specify the indexed into this table. And the number will be the number of the callable function. For the stack, it's like a basic code stack. We call that a protected code stack. The reason for that is that the code space is limited. So it's defined during the instantiation of the module. And it's not executable. The reason for that is you only push pop value on it. You don't push instructions that will be executed because those instructions are actually present in the function body, not in the stack. So the main reason we got a lot of talk about the security of web assembly and also why is it really efficient, et cetera. It's because the guy who creates web assembly got the design web assembly with security in mind. So if you go to the web assembly website, you will see the specific web page for security. And as I say, two important goals, protect user and provide developer with useful primitive and mitigation. So the purpose is to make it easier for developer and for user and to provide high level security. So typically, what's happen if you do something bad or if your web assembly module don't have the behavior you plan to. But typically, you will trigger traps. So for the moment, you have only one type of trap, but they plan to have exception unlinked in the future. Typically, an exception could be a trigger with an integer division by zero. Or even funnier, you have a specific instruction in the instruction set that will say, OK, just trigger an exception. That is an unreachable operator. Also, they put CFI on the web assembly VM, so it's control flow integrity. That's mean there is some verification and validation at runtime about the target of the call. The branch, a branch in web assembly will be a branch to a specific block, like block ID, block label. So there is verification of that. And because of all this reason, that's prevent usage of Rob Gadget, because typically, everything is already defined at compilation. And during the instantiation of the web assembly module, all those verification will occur. So if something bad happens, the module will just not load. So let's talk about the inside of the binary format. So typically, to make it simple, there is one header in this module, and after that, you have 11 sections that are defined in the papers that I wrote, like already defined, 11 different sections, and you have one custom section that can occur whatever, how many times you want, like it's unlimited. In terms of compactness, to give you an idea, the Fibonacci module is this one. And you have only 1,021 bytes for this module. So to give you another idea, the Autodesk weather module, if I remember, is just like 39 kilobytes, megabytes. So it's pretty short for a big business application like Autodesk. So that's a good representation, and a good help if you want to do some analysis, recommend binary file. It's a binary file explorer called WasmCodeExplorer. And it gives you directly the matching between the text view and the value in the binary file. So there is one header. I think you cannot do as simple as that. You have a magic number that will be null byte ASM, and after that you have a version that will, for the moment, be only the value 1, because you are currently on the MVP one. But that's typically all. For the section, you have 11 different sections that are defined. So I will talk a bit more of the principal one, just to say that the custom section is a little bit more interesting, because it's the ID 0, and you will provide a specific name and the length of the name in this section. It's really interesting, because they put the name section, that is the custom section, as the standard. And typically, it's like the equivalent of the dash G flag on GCC. It means you have all the debug name of the variable and on the function, et cetera. So pretty useful for this one. So let's talk about the principal section. The first one is the type. So typically, in the WebAssembly module, you will define some signature. A signature is like a composition of the parameter type and the return type. And this signature will be used as a verification during the instantiation. So if you have a Fibonacci function that takes only one integer 32 as an argument, if inside the WebAssembly module there is more parameters than that and the signature is not the same, it will just trigger a trap. You have the function section that will declare the signature for every function. You have the input section. So typically, you're just going to say, OK, to run, I will need this function. And for example, from a GS point of view, you will need to say, OK, associate the, like you will provide the Gison and say, OK, the memory function or the return function, associate this return function to a console.log, for example. So you typically are going to do that. And the last one is the export function. So typically, you say, OK, I want this function call to be callable at runtime. So you instantiate your module and you will get like a list of exported functions and you can directly call a dos function. If you see, for example, there, it says the call function is the function two. So it will be this one. And you precise the type. So this one, for example, will take no parameter. So that's how it works. Of course, the code section is pretty interesting. It's like the function body. So you will get one body for every function. And the last one is the data section. So typically, it's like the equivalent of the data of a PE file. And it will be used to initialize the linear memory. So for example, there, you can see that the LORD will be put into the linear memory at the offset 1,024. And this chunk of data will be put at this offset. So when I was start looking at that, there is no like disassembly. Yes, but there is no like CFG. There is no way at the moment of my analysis to understand deeply all the weather module work. So I have developed a tool called Octopus. And typically, it's more like a tool for like block and smart contract analysis. But because some smart contract platform like EtherM and EOS use WebAssembly, I have developed some tool for WebAssembly. So I will show you some screen. And it helped me to analyze some real life cases. So the first one is to do the CFG reconstruction. So for that, you need to identify the block, the different basic block. So you have the block, loop, if, and else. And all of them will end with the end instruction. So just based on that, you are capable of creating the basic block. And for the branches, you will need to understand, like it's like a particular tip of branch for me, you will specify the relative depth as an argument. That means if you have a branch inside a block, and you have branch zero, that means, OK, I want to branch at the end of this block. But if you have multiple branch into the same one, like branch one or branch two, you will need to do like it will be the relative depth. And it will mean you will jump later on the code or not. To give you an idea, the Fibonacci function just there, you have a block. So it starts there and it ends there. And typically, when you have the branch if zero, that means you need to branch to the end of the current basic block, because it's relative depth and it's depth zero. So you branch at the end of this basic block, so you will branch there. And so that gives us the following result. It's like really simple as a way to do, and it works pretty well. Another type of program analysis that is really efficient for WebAssembly analysis module is the call graph analysis. Typically, you will get two different calls. You will get direct call. So it's like the black edges just there. And for indirect call, you are notable statically to know which function will call this other function in an indirect way. So the only thing that you can say is this function is present in the indirect call table. So it can be a target for a call. And so it gives us the final result. Typically, this one is the WebAssembly module for a Blake 2 cryptographic algorithm. So I think we can find it directly on the thing I extracted from Node directly, Node.js. So it's a Node.js module in that case. Sorry. Also, there is a decompiler for WebAssembly. Typically, what it does, you can translate the text view to the binary view, of course, as I told. And you can also directly convert the binary WebAssembly binary into a C representation. The fact is the result of the decompilation for the function will be cool. And it will work. The main issue is all the snippet of code that is embedded into it. And that will not only you to directly compile this C code and use it like a standalone binary. It's working for a basic example like this one. But it will not work with huge sample or huge library. So let's talk about real-life WebAssembly analysis. So the first one that I have analyzed is like the hello world of Ethereum. So as I told, the parity team, that is like a huge member of the Ethereum community, have put the support of WebAssembly into their specific testnet. So I will analyze this one. So just to give you a quick reminder, Ethereum is the centralized platform that runs smart contracts. And typically, the smart contracts are stored on the blockchain. And to store a smart contract in a blockchain, you need to do like a transaction. And it will create like a new address, dedicated smart contract. So a parity team, so it's the ones that put the WebAssembly support, it's the company created by Gavin Wood, that is one of the co-founder of Ethereum. And their client, the parity client, actually represents like 30% of the Ethereum network. So it's pretty huge. And actually, they put the support of WebAssembly directly on the client as well. So in March of this year, so parity, tweet about, OK, the first wasm contract have been deployed on the Covan network, that is the testnet of parity. And typically, what they show there is the transaction that will create the smart contract. So that's the input data. And if you take a look at that, you can see the null byte ASM that is put in hexadecimal. So we will first start with the analysis of this WebAssembly module. So usually, in Ethereum, for those types of transactions that is a smart contract creation transaction, you will get the loader code, the loader module, or like a loader code. And this code, the only function of this loader code, it's to put a chunk of data into the Ethereum blockchain. That's the only purpose of that. And this loader code will be executed only once. And that's the only reason it is executed just one. So typically, we should get the same behavior for WebAssembly because it's intended to work in the same way on typical existing Ethereum smart contract and the one with WebAssembly. So that's what I found. There is three functions, this loader. The call function is exported. So that means an Ethereum client will call this call function. It will need to import like a red function to the two parameters. And there is one function that is the function one that is only inside the module. What we can see is that the call function will call the function one and the function return. But if you take a look at the code inside the function one, it's just completely useless. It's just nothing. Actually, it's just an empty function. So there is no really reason to do that. But I don't know why it's implemented like that. And after that, so if you take a look at the call function, so the call one will be the function one. And after that, we take the constant. That is 1,036 and 232. And we call the return function. So the two value will be this one, the two parameter. So if we do a pseudo code of that, it will look like that, so call to function one and call to function return. The fact is to understand properly all related to constant in WebAssembly, you need to have the data section, because it's the data section that initializes the linear memory. So that's why we want to have a better understanding of that. So typically, in this case, you already saw this screen capture, actually. You will get the hello world string. And after that, you will get a piece of memory that is actually a WebAssembly module. And that's actually the runtime code, the runtime module. The only thing that I can say is the following, so the code is this one. And the questions that come in mind for me is why is there is a hello world string there? Because it's definitely not used in this one. And it don't make sense to have that in the loader code, so maybe like bad optimization from the parity team, I don't know. Maybe they change it, actually, but at least for their basic hello world example is still there. So let's take a look at this piece of code. You will get something like that. So same exported and imported name. So it looks more like a generic, important function that will, after that, call another function, depending if it's the loader code or the runtime code. And what you can see is the data section contain the hello world string that makes sense because it's a hello world module. So in these cases, the code is this one. You have the call function that will call the function two, and the function two will call the return imported function. So the question is why the call function is not directly calling the return function for the answer? I don't know, actually. There is also two system sections on it. There is a linking one. So actually, I don't know what is useful, but there is. I'm supposed it's to say, OK, there is also some other function on it. And there is the custom section name with some debug information. Why I told you that? The main reason for that is, at least in EVM, like in current smart contract, if you put some extra information that is not used, it will use computation power. And if you use computation power, you will need to pay in gas. So you will need to pay more because there is some extra stuff to do. So typically, a call two functions that does nothing, or stuff like that, that will cost you money when you will do the transaction. So this module is really simple. I think it's a good start, actually. And it's the first time for me that I saw the concept of loader and payload in WebAssembly. I mean, it's used like in real cases for Ethereum, et cetera, that is legit. But you can imagine that in the future, maybe they will do the same kind of stuff with some crypto miner, et cetera. Or you will only get one loader with a huge piece of data section that will contain the real crypto miner, and some JS scripts that will just call this function, get back, and put the crypto miner into memory, and after that load this memory into a real WebAssembly miner. So it's definitely possible. It's really easy to do. So I'm pretty sure we will start having some stuff like this one. Since my analysis, there is a tutorial. No, if you want to create a typical LOWardWasm module on the Ethereum network. So just give it a try if you want. And yeah, as I told, there is a lot of optimizations that can be done, but I don't know if they do some modification, and if it works better, no. So the final analysis for today is a crypto miner. So typically, the most common ones that you can find as a crypto mining WebAssembly is the Connaive one, because Connaive is the main services that is used for crypto jacking. And maybe some of you go into the San Diego website around May. So maybe your CPI have been used, not for what you think. So typically, this WebAssembly miner I've been found on this website. So it's a monorail crypto miner, and it's used the Connaive proof of fork hash algorithm. So this part is pretty interesting, and you will see why just after. If you want to take a look at this, you have everything directly on the GitHub, and that is the hash of the Wasm module. So that's the cool graph of this module. So it's pretty huge. The first thing that you can see is there is three interesting functions, the Kryptonite hash, Kryptonite create, and Kryptonite destroy. It's pretty interesting, because it contains this from Kryptonite, so that's the reason. And actually, those functions are exported. They are in gray on the screen, so they are exported. So if you do a basic Google research on this one, you will see that it's on three or four different GitHub projects, and you will directly find out the text view and some GS code in order to use this WebAssembly module. Actually, those strings are also used directly in VirusTotal and on other detection rules in order to detect WebAssembly crypto miner. So yeah, it works, definitely. But if you only change the exported name, you will get nothing totally clean on VirusTotal, typically. So that's the main issue with only matching on string, and like in that case, exported function name. You can just have a completely third crypto miner just by renaming with, for example, this one that is like a real one, a real case that I have so. Another thing really interesting is all those functions, it's all the exporting function in this case, and in this case, and in this one, you have exported function and some imported function, like enlarge memory, getTotalMemory, et cetera, et cetera. And actually, those functions come from nscripten. So that means the creator of Coneyev, or at least the creator of this WebAssembly module, have used nscripten. And he actually don't remove the unused function. Typically, if you, for all the exported function, if you don't use it, you don't need it, it's simple. And for this one, it will depend. In some cases, it will be useful only if you run the WebAssembly module locally using nscripten. And in some cases, because it's like in a web browser context, it will just use, it will be just not used, it will be completely useful. So that's the reason I have put some detection on my tool to detect this specific nscripten function. So it gives us this following call graph. So it's a little bit more clean. And the really interesting function are this one. So it's called memcopy. It's an exported function. So it's part of nscripten, actually. And what we can see is there is a lot of different cross reference to this function. I mean a lot of different from a lot of different function. And the other thing that you can see, it's the number of static calls on some specific function. For example, this one is the function 31. And you can see there is 16 static calls from the Kryptonite hash to this one. And in the same way with this one, 10, 10, 10. And this one, 9, 8, 9. So typically, because we are talking about like crypto algorithm, proof of work algorithm, and hashing function, for me it's clearly a means that it's like computation function. So we can potentially do some matching and rule detection based on this information. So if I put that in a graph, I have classified all the instructions in each function based on the function that is there. And the type of group, the instruction is like part of a group, like control, group, constant, et cetera, depending of the behavior of the instruction. So we get this following representation. And for me, the most important one are the ones that just not use any or maybe one or two control flow operators. That means there is almost no basic block. So at least one, but no basic block and maybe no branches. So clearly computation. Even more if you choose a lot some variable. And if there is some constant and arithmetic and bitwise operation, in that case for me, it's like complete jackpot. So in our cases, the function 31, 38, and 39 seems to be a good client, typically because the ratio of instruction per block are enormous. And you can see that the static cross-reference to this one are pretty cool. So in the same way, I have continued my analysis of this one, this function. And I found out that if we take a look at the text representation of this function, you can see a lot of usage of the local variable in this one, this one, and this one. I think this one is like more than 35 local variable. So pretty huge. And if you do some correlation of the occurrence of every instruction, you will see that with only nine different instructions, just there, nine instructions that represent 75% of all the instructions, we get 93% of the complete instruction in this function. So just based on that and based on the statistic and occurrence of each function, you should be able to create some rules, like detection rules of the kryptonite algorithm. So when I first discovered that, I do some research. And I found out that there is a project from a guy from Texas, Dallas, Dallas in Texas. And they use typically the same type of methodology. But they do that at runtime using a modified version of V8, if I'm not wrong. So it's pretty cool. And if I remember, they also use like they do that at a really low level point of view using Intel PT, if I remember. So it's even more efficient. And they do some really good statistic about occurrence of instruction, but also in video game. Like the tank was a module that I have shown you at the beginning of the talk and some other. So you can definitely create some rule based on that. Even better will be to create an antivirus that will, during the instantiation of a WebAssembly module, hook the content of this WebAssembly module and put that into like a rules-based detection. That will be the perfect way because in WebAssembly, you can directly provide a WebAssembly file from like GS, you say, OK, fetch this was a module. But you can also create a byte array in GS, put the code on it, and load it in WebAssembly. And in that case, you will not be able to do some analysis except if you hook the GS engine. So it could be a good solution in that case. Also, there is some other technique that I am actually working on and seems pretty promitious like the magic constant way. And for those who don't know the function divination, just take a look at CBL. It's really, really cool way to detect some like bad behavior. So a quick conclusion. I'm out of time. There is a lot of things to say in WebAssembly. They will do a lot of good stuff in the future. Actually, it's the four major buzzers that are behind. So you can be pretty sure you will get some better performance. For the language and platform, it's already the case. There is support for go, if I remember. And in post-MVP feature, you will get like thread, exception, SIMD, and like a garbage collector for WebAssembly. In my side, for Octopus, my tool, I'm currently working on the WebAssembly emulation directly in, I don't know if I told you, but it's in Python. So directly in Python. And I'm working on symbolic execution. And I think I will release something in the, I think before the end of the year. I put you some resources, if you want. For me, the best one are this one, as an introduction. And this one has a paper from the guy behind J-Dix. It's the guy behind J-Dix, so it's pretty cool. And you have some other one in terms of like vulnerability research, et cetera, like the two blackout talk that occur this year that are really good, it's really good resources. So thank you. And if you want to ping me, I'm completely available on Twitter. So just damn me, and I will answer you. Thank you.