 welcome to my analysis for head shocks. So today's topic is e-mail formations, which is actually the topic I wrote my master's thesis about, so it's quite interesting. Please, if you haven't done it, please check out the previous videos on Potobeks Kudubu files so you understand this one. Of course, if you already know how Potobeks Kudubu files look like, then it might not be necessary. Okay, so what is a P-mail formation? Well, every file type is specified or defined by the specification and in case of the Potobeks Kudubu format, this is the PECOF specification or Potobeks Kudubu common object file format specification. If the rules in this specification are violated, then we have a malformation. So I divided malformations into or distinguished single field malformations and structural malformations and now I think I should turn on the light. Alright, so single field malformations are quite simple. So it's just one field that has a value that's not permitted according to the specification. So one single value that's different. For instance, the entry point might be zero for an XPE file. In which case we may be able to execute the header. So, you know, MZ is those are the first bytes of the Potobeks Kudubu file and this is actually in assembly this is a valid instruction. So starting from that you can execute code with an entry point of zero where some tools might say, ah, that's not valid. The size of raw data, that's the physical size of a section. You could set a value that's very large. If it's larger than the virtual size, oh damn it, I have to correct this. If it's larger than the virtual size and you will, they will simply take, they will simply take the virtual size instead of the size of raw data. The Windows loader will do that. Whereas any parser might attempt to read all of the size of raw data. So, which might be even too much for the file size. So, yeah, can crash any parsers. So, the structural informations we need to take a closer look at. So, yeah, let's check those out. There are quite a number of structural informations. So, I made or tried to make some lists of possible ones or categories. So, one possible information is the unusual location. This could be, for instance, if you put the section table into the overlay of a file. So, any structure that is in a location where you don't expect it, that can be a malformation. Now, unusual ordering of structures as well, like sections that are shuffled. Usually you expect them to be in the order they appear in the file. But if you shuffle them, that's possible too. You can have loops in structures where you don't expect them. And you can have an unusual amount of these structures. For instance, you can have so many sections that parsers are overwhelmed with it and crash or you can have zero sections, which you wouldn't expect from a polythebics could do far. Deformed structure is also possible. You can have truncated structures, co-op structures, overlapping structures. Structures that are duplicated, which is not the same as unusual amount because they are duplicated in a way that they are different in memory than they are on disk. And also fractionated structures are possible. Let's take a look at loops. I will just give some examples. It's too much to cover all my formations in this video. Maybe I will do some more later on. So loops, a very interesting loop is the resource loop. As you may know from previous videos, the resources are, the resource structure is actually a tree, which has three levels. And let's take a look at that. So far, there's nothing unusual. So we have our three levels and the last node in the tree store data. But then let's just create a loop here because, you know, the number of levels is not given. You can have more than three. And you can create a loop. So parsers may attempt or may not get out of it. If they just read three levels, it's okay. But if they attempt to read more, they may get into this loop. Okay, another example is a collapsed structure. So let's take a look at the collapsed structure. We look at the collapsed optional header. By the way, if you're interested in these anomalies, check out orange, I would put a link in the description below because he has made a lots of lots of proof of concept files for pod of executed malformations. So the collapse optional header is also used by tiny PE, I think so. Yeah, but anyways, if we have the normal PE file, we have an MS-DOS star, we have the cof file header, then comes the optional header and after that the section table. Now the thing is at the beginning, the start of the section table is determined by a value called size of optional header. So the size of optional header is actually not used to determine how much to read from the optional header. So Windows will just read the optional header. But the size is used to determine the start of the section table. So if you put a smaller size, size than the optional header actually has, the section table will overlap with the optional header. So that's a nice one. And yeah, I think tiny PE uses that because that's a project. I will also put a link in the description below. It's pretty fascinating. Like the person who did this, I forgot the name. They tried to make pod of executed file that's as small as possible. So they use all tricks available to make a file smaller. And that's certainly one of them because if you overlap the structures, you need less bytes for the file. And here comes the section table just to make this clear that's the section table. And that's the optional header. And we have this overlapping area. So yes, another example is the fractionated structures. So we will take a look with politics analyzer. So here's an example for fractionated data structures. Actually, there was a video by a labs about this pecker. And the actual issue here is that the export section is just invalid. Like that you can forget the whole the whole experts structure. It's just in an arbitrary location. So all of these imports are not valid. Most of them. And but the interesting thing is I tried to make politics analyzer to make it pass as much as possible. So and now you can see that while trying to pass all of this, that the exports are splattered all over the place. You can see this here with the it's violet, I guess, with the violet rectangles on this. They are like everywhere, they're even in the header and the first section. And so that's what it looks like if you have fractionated data, it's like in several sections. That's the definition and not together in one location. So the problem of this. Firstly, if this was valid data, parsers might not be able to read it. Because they the addresses that are used use virtual addresses. So they have to calculate the physical address. And to do this correctly, they have to know that the data might be in different sections. So if they just assume it's in one section, they will calculate the physical address is based on that on that section mapping. So they might end up reading garbage from somewhere else. So that's a way to hide data from static tools could be. Well, in this case, it's the malformation has so many export entries that the tools usually crash while because they try to read all of them, or they may crash because some of those entries are also invalid. So yeah, but there's a solution to this in A-Labs video, which I will also link in the description below. It's a quite interesting pecker that's still in the wild. So might need it. So I would like to talk a bit about why malformations occur in PortoVex Guru files, or actually any file really. The reason is, of course, people might do this intentionally. So parsers are confused. If an interviewer is going to, for instance, they have to parse files too. So if they are not able to, they might not detect the files, the files as malicious. But then there are also malformations possible due to, well, by accident. Because Malva writers, for instance, they might not be aware fully aware of the PE specification and just try to see what works. For instance, someone might decide to create a virus that enlarges the last section and puts the virus code into the last section when it infects the file. And when they enlarge this section, they might not be aware that there are file alignments they have to take into account and just set something that that's actually invalid according to the specification. But when they try it works, so they won't bother with it. Also, the fractionated data may happen this way, like the virus may add some imports to the host file, because the virus code needs those imports. And I have seen this, and it might does, it might do this by adding the imports into the, the own section, which is not the same section as where the imports of the host file are located. So you have imports spread over several sections, because the virus edit some of them. And if parsers don't take into account that these, it's again, it's, I have to fix this, really. If parsers don't take this into account, that these structures can be located in several sections, they will calculate the wrong addresses for them, specifically for the ones that are out of the section. So whether for the ones that are relevant for the virus code. And then you get garbage. Back when I wrote my master thesis, I discovered that lots of static analysis tools were not able to read those imports. And then also, you know, I made bug reports to the authors. And yeah, since then they have improved these. Last but not least, what's the difference between PE anomaly and PE malformation just to make this clear? Because oftentimes we talk about PE anomalies. Actually, the PE malformations are a subset of anomalies, say, PE malformations are things that violate the specification. But an anomaly might not violate the specification, it might just be unusual. So that's the difference. Yeah, every PE mal formation is also an anomaly, of course, but then there are just some non default values that are that any parser should expect because it's what the specification says. And example are section names like the specification will tell you if you have resources put that in the dot RSRC section, but actually it can have any name. So it's not a problem for prizes, usually. But still it's interesting for you, if you analyze the file, because if the section is has a different name that might be a hint to certain pecker that was that was used, or sometimes malware were just have some weird names in this agent. And yeah, like I said, the PE malformations might cause problems of parsers where they are not able to read certain data or crash a little skull here. So if you want to read more about Portavex good about anomalies, anomalies, check out the kakami project. And you may also check out my read my master thesis, at least the first part of it. The other stuff might not be that interesting. So that's it for today. Thanks for watching. And see you later.