 This .NET file executes a calculator if you run it normally, but as soon as you put it into the Nspy, the decompiled code will not show any calc exe execution. And if you debug in the Nspy, it will also not pop your calculator. So how does that work? There are no anti-debug checks in this sample. Instead, it uses a technique called ready to run stomping. In today's video, I will show you how to create such a file. And afterwards, we will explore how to analyze it as a Mavic Analyst. This technique was first published by JZ Checkpoint Research at Virus Bulletin 23. And by now, they also have published this on their blog, and I will link the blog article in the description below. To fully understand this technique, we need to understand what ready to run compilation actually is. And this is a performance improvement feature for .NET Core executable. It allows the .NET applications to have better startup times. The way they do this is they compile the IL code to native code, and they ship both at the same time, the native code and the IL code. And now when the .NET application is executed, while the application loads, the compiler, just-in-time compiler will choose to execute the native code preferably instead of the IL code, because this way the startup performance is way better in the application as far so. It has the disadvantage that the binary is larger, also says here, because of course you need to contain both IL code and native code. Yeah, but that is the trade-off for better performance. So how do we use this now to hide our real intentions from the IL code view in the Nspy? So let's first start by creating a new Visual Studio project. So we say create new project, choose console.app for C-sharp, and let's name it just-thumping.net 6.0 is the framework we are going to use, and we say create. So now we got our project, and we are going to add some more lines of code here. To compile this project, open view, terminal, and then you should have this terminal window here. And now we create and then ready to run application. Do that with .NET. Now for showcasing, the not self-contained executable is a little bit easier to analyze, but I'm going to show you the self-contained executable as well later. So now this is the folder where our files were published to. So every file that's in there, I'm going to put on my MavaLab VM, and then we're going to check it out. If you want to learn Mava Analysis from the ground up, please check the link in the video description below. It contains a coupon link to my Udemy course for beginners. So these are all of the files you're going to find in that folder. Make sure you copy all of them. As I said, it's not a single file executable. So if you like, if you are like me and you transfer this to another machine, want to execute it, make sure you install the runtime environment for .NET Core 6. Also for .NET 6, right? Then you should be able to run it. So if we execute this now, we see it's popping a calculator and it's telling us hello world. So you could imagine this being like the malware that is being executed. And this is like the hello world, the legit application decoy in this file. So let's take a look at it with the Inspire. We now still have to create this stomp file out of it. And the way such a .NET Core application works is you have the actual .NET meta data in this DL and the Xe is the one reading the configuration for the runtime and then executing our DL file. So the DL file is actually the one containing the main code of our application. So that's what we need to check here. What you also see here is that the now we entered code that more looked like a script like we have no class and no namespace and no method in there. But it's just syntactic sugar. So internally, it's still creating this class program with the main function here using this name to indicate that it's generated. So that's how we find our code, right? And we see here this is the line we want to hide because it's starting our malware code and this is the line that is our decoy code. So let's try this. You can right click here and say edit I L instructions and then we can change the lines that belong to our call into knobs so that the pretends is that this line isn't there. Why is it three lines here because this loads the string calc. This is loads basically the argument for our process start call. Then there's a process start call and then it pops the result of this call. So let's not this press okay. And now you also have to save this. And now here is the trick is a little bit that you need to preserve most of the metadata. Make sure that here's a check mark on mixed mode module. And if you go to the rider option, make place check marks everywhere so that everything's preserved that can be preserved. So we make as little changes as possible. So that should be everything we need to do. And then we say, okay, and the module is saved. Now we have to verify that it is working as intended. First let's try to debug it in here and make sure it's not executing the calc.exe. So we place breakpoint here. We say start. Now you need to make sure to choose right options because this is not .NET framework but .NET core. So we choose .NET. And we have a host executable. The host executable is the .exe file, this one. And the actual executable is our DLR. And that should be it. Let's press okay. And now we are here and we step through. Now it's asking for the key. And that's it. So it's working as expected. There was no calculator being popped and we see here when we check this code or if we check the iL code, there is also no process calc, process start calc.exe call anymore. So the question is what happens though if we execute it here? It's popping our calculator. So this is a really, really cool thing because now you have a way to hide code that doesn't even show if you debug the files. Now the question is how can we as reverse engineers identify such a stunt code .NET executable? And the way you can do this is you need to use another tool, then the Inspire because the Inspire does not support RTR headers or examination of the disassembled instructions. But one thing you should probably check even if you mainly work with the Inspire is when you put this in here and look into the PE core header, you will see there is a managed native header. So this has a value and what does this mean? This means there is some native code being executed. And for that reason alone, you should as a reverse engineer be immediately alarmed that there's something else that might be executed because you have some native code being referenced. This is a so-called mixed mode assembly. So mixed mode assembly means we have both, we have native and iL code and you cannot just rely on the iL code anyways. So one tool that can see the headers is .peak. So if we open this here, you can see we have a header in the metadata that says here it is. Ready to run header and there is some other thing that you might notice in the hex editor because I always use to scroll a little bit through the file especially if they are small. What you see here is RTR and that means you have a ready to run header because this is the ASCII encoding for RTR as the signature used for the ready to run header so that it can verify that this is the correct structure being parsed here. So this is the signature and you know the rest is going to be part of this ready to run header and what it does it tells the system where it finds the native functions. So here you can find information about that. So now we know how to determine if a file is using ready to run but that doesn't mean we know if it's stomped. And for that the best tool of choice recommended also by the article is ispy. So let's quickly navigate to our main method. So that's the main method we see here. All right, no cuck xe popping and the cool thing is here you can change your view to a different view. So this is remember this is the IL code and you can say right click decompile to a new tab and we are going to place this side by side and instead of IL we are going to choose ready to run and then it shows us the disassembly of the ready to run native code. So in this way you have a side by side comparison of this code and this code and you can see here oh there is something happening that is not happening here. So this is how you detect the stomping manually. I'm pretty sure at some point there will be some tools that have some sort of automatic detection of that but for now we're going to live with that. So with Visual Studio with our original command we created a file that is not self-contained and that relies on the installation of the .NET Core runtime on the system. But I imagine if Maverick is going to use this that it will rather try to use single file executables that are self-contained and for that reason I'm going to show you this as well. So I'm going to check self-contained to true and also we will add the single file executable and once we have done this our publish folder will only contain two files. One is an exe file and one is a pdb file. So here's our exe file and again you may run into some problems when trying to open this in the end spy. Why? Because this is actually not a .NET executable but a native file. And what you may notice if you check this file in a debugger is you see the debug path is something like that one here. So it says core host static single file host and this should tip you off that this is a single file executable and then you when you check below so there are a ton of pe files appended to this and again ispy is of help here because ispy is able to extract for us the files from the single file host. So the way this works is you have a native application that is the let's say the execution step that then contains all of the necessary .NET runtime environment dls and if you check the properties this is a rather large file with all of the with the whole .NET runtime inside and also with our dll file and ispy is able to see this so if you open it here now you can see here the runtime configuration and you can find here our .NET core app file and you can analyze it as usual so generally you would probably start with C sharp so you can analyze it as usual and check here and then compare this with the ready to run code. So I did not stop this file yet but um but um analysis is actually straightforward just if you just identify that this is a single file host executable gotta open it in ispy and it's fine. But what are the implications of ready to run stomping? Does it affect antivirus detection signatures for instance? Well, I believe in most cases it shouldn't especially behavioral detection will not be affected at all um there is a specific case where it might affect um pattern signatures that are on the il code so pattern signatures can be on every part of the file so they could be on the version information on method names on reference strings such cases should not be affected but if they are particularly on the il code that you stomped then this part will be affected but then I mean they can be placed instead on the native code so in general the effect shouldn't be large um it might only affect like single instances of that but what will probably happen is analysts are not um aware of this technique and who do not have enough time to form a verdict so who have like some time limits on their on the analysis time they allowed to spend on a sample they would tend to skip um approaching the analysis holistically what does it mean um usually if you do it right if you have enough time you um gather different sources of information you do not rely on one source of information like the inspired decompilation for instance you will always also check some sandbox reports and check monitor the sample if it's not being debugged and in in these cases you will see that something else is going on and that is not visible in the end spy um yeah but many environments are kind of stressful so it can happen that you miss the malicious code and then put a wrong verdict on the file but that's actually all of the implications that I see right now I hope to see you around and if you have any questions please put them below cheers