 Shrinker and Expander, which for the Shrinker and Expander, I call it Direct Expansion. Just a different way of doing the same instruction. But I say like I, for example, well, I think I got an example coming up next. And basically, Expander makes different instructions to do the same thing. Shrinker converts them back down so that you can have your same code skeleton, if you will, each time. Here's an example. You have your original code where you move one register, register two and register one. And I just the same as doing, I push register two, pop register one, because all you're doing is using the systems stack to move it. And I just decide I put the bytecode on there. This actually shows that it creates just a different bytecode. And that's pretty big. That's the one thing I'm always up for trying to do. And so the addition to it is the idea of being able to create random expanders to I, because these regular expanders are easily caught by just looking for them instead of like any other type of search for three bytes. If I saw a push register one, pop register two, I know that it's just a move instruction that's been expanded so I could shrink it myself and therefore know what the code is supposed to be doing and have that original code skeleton. So it's just the basis of figuring out ways, rule-based to figure out ways of how to create these random expansions. So like an indirect one would be, like as we see here, we got a, since we do, before we do pop register one, the idea of the rule is that register one becomes a free register where you can do whatever you want with it since all you're doing is waiting for it to pop at the end off the stack to do your standard move operation. And so you get, it does increase code size, but it does give you a different signature for even just one operation like we see for this. And yeah, this is probably about the whole idea of using the rule. The rule is register one can be manipulated before any point, or at any point before the pop of register one. And therefore, since you have that rule, that's why we can stick that or in there and add random registers and values to register one in that earlier example. And then the next, for generating these, the idea is if you have, just label the areas and those rules, for each area, you have a different combination of rules since it depends which set of labels you're within at that time. So it's just a basic orign of all the rules together. So if you're in two sections, or if you're in a section that's within two boundary points, you can decide to use both of these, both of the rules together and stuff like that. So for instance, this one, we can see that rule one starts at the beginning of the code and ends right before the pop register one because pop register one is when the rule tells you that you can no longer randomly use the register one. And then I just have some stuff on basic metamorphic viruses if I, because that's where they first started from. And that's just some ones to check out because actually a really good metaphor was the first one that was fully metamorphic virus had both actually had a shrinker name as well as a code expander and various other stuff. There's also the executable trash generator that was written by zombie and that one's great for just creating random, you can pass it in instructions and it'll output random op codes for you. You can tell what you want as your destination registers, what you want as your source registers and you have some instructions you can pick out of. So you just set all these flags, push it in, I think I got it on the next slide. Yeah, here's a colon in it. So you just tell it how long you want it, point towards the buffer and then the rest is just telling it what instructions it can use, which you want as your source and which you want as your destination. And there's also one other tool that I forgot to mention on that other page that's called the MicroLength Disassembler and that one's great for... you can do incremental development of this engine because you're going to have to map your op codes to do your own parser. So this one, you can stick this MicroLength Disassembler, which I can't remember the exact length, but it's nice and small. You can basically... I'd take this and stick it in as your else so if you don't feel like mapping an operation, it just drops through to this. The MicroLength Disassembler will tell you the length of the instruction and therefore you can just skip over it and go to the next one. So when we're using the XCuber Trash Generator to generate our code, since we'll be mapping to show where the registers are in the op code, I just would go by sticking the ELX in for your source as well as destination register if you have two or anything like that since they'll just give you L0s in there. So you can easily map another register in there by just doing an orient it in there. Yeah, I said orient it in there. It's just... I've got a little oil put in there. I think I've got a little something on... Yeah, I put a little something on extracting register values out of op code and it's... Well, if you just got it mapped, then you know which you got to orient and which you got to and to mess with stuff. And like... Here's just a small algorithm or just showing how adding that register in would work. It's as easy as orienting it in as like that first push in the pop as showing it. And it's... If you just orient that in, it just goes into there and combines with the rest of the op code. And it's safer if you have a molar piece of code since if you ever fully shrink something, say with these little metamorphic engines, they always made sure to never shrink itself completely because then you fall into the same hole that you have when you're using regular encryption because your encryption, at one point or another, it's got to be decrypted so you can use it. And if you fully shrink this, you just get the standard looking on high-code skeleton. So this high-code skeleton, you can pick up a memory and it will always be the same. So you always have to leave it somewhere unoptimized or it's just as easy as checking memory to find what it looks like. And since we were going to try to randomly generate these expansions, the idea is that since we're going to be developing new expansions and we can't fully shrink it, it's pretty much worthless to use. You have to have to find some molar ground to pass these expansions on to the next one. So I just have it that the shrinker knows generation n as well as generation n-1 and it knows that the shrinkers or the shrinkers were the random expansions that were developed during those generations. So it's... And then of course your expander, it creates the expansions that go into the n-plus-1 generation. And therefore you kind of just carry half of the older generation, you create half new and you just keep on going from there and you always just drop the old one to develop the other half against your new set of expansions. You always... But to make sure if you want to, then you don't end up just having geometric growth like a regular trash code generator. You got to fully shrink the n-1 generation's expansions because you would lose... By n-plus-1 you would have n as you end up losing a generation of how to shrink that. And therefore just leafing trash code in there that's not reversible to be re-shrunked to use. And as soon as this is an improvement on metamorphosis, because in your standard metamorphic virus when you have your expansions and shrinkers, it's easy as just scanning for these things for studying and usually they only go about five deep in most codes for doing expansions. So you optimize it five times and you've got the original codes. But hopefully by... It's just adds a little more complexity is really all I'm going for is because it's not as easy as this is... You can't just have a database of expansions and check that towards the code since you randomly generate a fairly large amount of these expansions. So it won't make sense to just use like a database of them or just to have them so you can just brute force and everything. And for using this technique, it's... Well, I'm still working on the engine. But for using it, I do believe it will work because of adding these random op codes and then it will keep us away from just the standard easy optimization of stuff. But also, rather than just using a trash generator and combining the code of the trash generator with the expansions and not worrying about the shrinking, I got something that's exponentially growing generation to generation in comparison to actually being to know how to shrink it and therefore no longer having that exponential growth. And this was one of the 20-minute presentations that they just started doing this year so I kind of... I just kind of went real quick through those and I'd like to open the floor for questions if anybody is there for asking any. Thank you for coming this morning. Any questions? Alright.