BSidesAugusta 2014 Will Schroeder - Adventures in Asymmetric Warfare

All right. Well, welcome back from lunch. I hope you enjoyed your lunch. Special thanks to our sponsors who've uh provided us with food as well as all the great prizes and giveaways and the vendor and all the venue and all of that stuff as well. So, um our first talk after launch is Will Schroer. Um also one of the core developers of Veil Project, also the phone installer. Too many. Yeah. and and some other uh awesome PowerShell script that does some awesome stuff with recon. Um I know all the stuff he's working on, but I won't talk about it because I think he's about to. So with that, here's cool. So this talk is adventures in asymmetric

warfare, fighting the 80 vendors. Um, I'll kind of go over a little bit more of what this talk is going to be about, but a really high level, it's kind of walking through the thought process we had in developing some of the opuscation invasion methods in the failed project. So, I'm Will Shrader. I go by the handle harm Joy. I'm a security researcher and red teamer for the adaptive threat division of Paris Group. Um, also one of my co-workers and co-fale developer Chris Kunter is here to present this morning. But our company is based out of Northern Virginia. We do cool fantasting uh red teaming. Um we have get to do security research and stuff like that.

It's a lot of fun. Anyone he needs a job will talk to me after. I'm a co-founder and co-developer of the veil framework. So our main site veframework.com we presented kind of a it's been out for about a year and a half with a big kind of public release was on it this year talk called theation bail framework. I also released a second tool kind of in the toolkit called bail pillage which is a modular post exploitation framework presented that at devcon this year bail village post exploitation 2.0 Now, so I co-wrote Veil Aging with Chris. I wrote a payload delivery tool called Veil Catapult. I wrote a PowerShell situation awareness tool called Veil Powerview.

Wrote Veil Pillillage. Um, wrote a PowerShell script called Powerup, which automates Windows privilege escalation. And I'm active for time shell hacker. So, uh, pretty kind of short TLGR, but, uh, I'm going to go over a little bit for the problem space and the how difficult AV detection is. I'm going to go over kind of how the project started. It's, you know, it's initial motivations, kind of how it came about. Chris also covered some of this stuff in a little more detail in his talk this morning. I'm going to go through so several of our approaches, kind of the evolution of our thought process in doing the office. I'm going to really kind of dive into

detail about the offiscation methods and kind of increasing level of sophistication. This is going to also result in the release of an entirely new payload language which is in the development tree right now and it's going to be emerging on 15. But I'm going to wrap up with some really kind of short basic static analysis of some of the payloads. So the halting problem um this is as it's a little like uh computer science theory kind of stuff but in general if you have a uh sorry let me let me back up. The hulking problem is is a way it's a I'm doing a terrible job explaining this so I'm just gonna go on but essentially you have the input of

a potentially malicious program and if you had a generalized problem statement the output is true if that input program would cause a host computer to be compromised and false otherwise you can build this little nice little halting proof that reduces everything down to this universal halting problem which I came up with. Now after all that nonsense, this is basically what it means. Antivirus detection is an undecidable problem. That means it's provably impossible to design a 100% effective antivirus solution. So even though it's technically impossible to do this, you can make reasonable approximations. My point here is that detection is very very very hard. It's easy for us to kind of throw up, you know, our approaches and say, "Haha, we

got around these multi-million dollar corporations." But their task is nearly instrumental probably. It's pretty much almost impossible task. So our problem though is buyers total. So a few years ago people started noticing that the uh stock dangers for interpreters started getting caught by antivirus solutions. As Chris mentioned, you know, really the big problem is antivirus vendors caught up to pentest and tool sets because they're open source, but they're still doing a poor job of catching professional malware. This is this was taken about a year ago or so. I think there was an presentation. I forget what the detection rate is now. But this is a stock interpreter standard generated by NSF. So again, started snaring up more and

more stocks payloads. We started researching kind of really basic ways to keep doing our jobs. The problem here is, you know, we're on a fiveday pen test that includes setup and tear down time and everything like that. You don't want to burn an entire day trying to roll up a bypass method to get around something. Um, again, all of our initial efforts drew from prior work. Thank you, Mark. Uh, I'll call them out here in a second, too. But, uh, we don't claim to have been into any of this stuff. We have a little bit of initial our kind of original research that we've been developing and releasing, which I'll go over, but everything that started was

just drawing from public sources. We wanted to take it and kind of weaponize and automate it in a way where we could just roll stuff up really easily on Cali and have something pop out without having to do you know like a second Windows platform with installations and drop everything in and like do all that kind of stuff. So previous work um Mark actually had a post for tips for dating and vars during pentesting. This is the first public resource to talk about using Python to inject shovel code. Like Chris had mentioned this morning, we're thinking, okay, kind of stepping away from that lower level assembly opusation kind of thing. If we're using Python where

people can wrap it up in PI installer, which legitimate projects do, then maybe we can use some of these Python scripts and inject shell code, get our stages going in a way to kind of you know utilize this pie installer as kind of a uh you know like a packer like a lot of malware has. We end up mostly drawing from Deish Mandal's execute shell code using Python. This uses a little bit different approach than marks. This is um so it they both utilize cypes which is a Python foreign function interface. The idea here is it lets you utilize some of those lower level Windows API functions. Now this is the first this one on the bottom is execute show code

using Python. It was the first time I really kind of saw detail this virtual alloc pattern where you use virtual alloc execute memory page. You copy all your shell code in to that uh rewritable executable memory page. You create a thread with that and you wait for that thread to uh complete execution. So this is a standard pattern. Any language or approach that you can have access to the lower level Windows API, you can use this pattern to inject shell code or build an interpreter stagger which I'll talk about later. Get our solution. We wanted a way to get around antivirus as easily as professional malware. We don't want have to roll up a phone back door every time.

We don't want to have multiple environs. We want a single monolithic attack platform. The codebase was written by myself, Chris Prer, and one of our co-workers called money should. And the whole idea with the veil framework or veil agent is we wanted a way to generate payloads in a language and technique agnostic way. So again, it's kind of like drag and drop. There's a like folders divided by language and approach. You can write your own private stuff and just drop it in. It'll load up into the tree and you can utilize all the compilation stuff, all the common libraries and things like that we have. We also have on our site veframework.com, we have like tutorials

on writing your own modules, um, integrating veil vision into your own tool sets, all that kind of stuff. Again, there's a presentation this year, aviation with a veil framework. I think the video is online, the slides are online. So if you want a little more information kind of on the little bit lower level components of the framework itself you can check that stuff out. This is a screenshot of the veil elevation interface. You see all the you know the payloads that are loaded. This is actually 2.13. This is in the dev tree now. It's going to be released or merged in master the 15. And we have you know like all our common interface and

stuff. So, real quick, a couple things on kind of the ethical issues in the release of this project. The disclosure debate is not anything new. You know, we've been talking about for over a decade now the exploit disclosure debate and all those types of things. Um, I initially didn't want to release the project or some of the code bases until, you know, we had a lot of long drawn out arguments saying like, okay, you know, what are the ethics? Is this okay to release this kind of offensive tool set? And the consensus we came to was like yes because pentesters are over five years behind the professional malware community. This is a problem that the

bad guys have already solved. AD is not a problem for them. It's especially not a problem for you know like a or more advanced targeted type attackers. So if we want to simulate these types of threats and provide value to a client then you know we felt like having to like this is a legitimate um kind of component of your arsenal. This is some of the I love this slide. These are some of the quotes from the public reaction on the Reddit thread. Um, let's see. Surely this will just result in 21 new signatures for all major ads when we're back to square one. Isn't our entire field meant to be working towards increasing security

rather than handing out fully functioning weapons. Um, but I really like the this quote here at the bottom saying the point here is that anything that helps to expose how ineffective AD really is and stopping in even a minimally sophisticated attacker is a good thing. This is uh Chris Campbell's actually he's obser

now because I think it's funny but uh he just said hey he's like it's true having to do all this stuff by hand. I remember having to do it by hand. Um, it was terrible. You would have to have like, you know, your windows and apartments dropping everything in. It was just a giant pain. And then I love the response from script junkie saying back in my day. I mean, obviously if it's by hand out the whole place. So kind of the the initial steps we took, we started with Python based shell code injection techniques and we kind of started branching into other languages which I'll talk about. One of the first things we realized was that similar

payloads are going to be a really easy way for you to get caught by AD or really easy just to write a static signature. Something like, you know, a straight pre-ompile Python shell code injector where you know it inject shell code through command line or something. It's great. It's really effective, but you can write you just MD5 it you know you can just write really easily an exact static signature for it. So we wanted a way to try to randomize and opuscate everything so it at least you know didn't have the same ND5 every time. So the very first kind of passes on this opuscation was again let's randomize everything we can. This works better

than you think it would better than it should. We substitute in random strings for all variable names. Shuffle up everything you know in the straight Python script. Try to have it be different every time. So this is I know it's kind of small but this is like what a typical Python pill look like now availation. This is what was produced. So you know it just kind of looks like garbage. Um I realized actually uh just this past week I posted to my GitHub some of the original unobuscated behaviors because I realized that people wanted to kind of look at it and see how they worked. This isn't commented like I don't know what the heck. I know what this is doing because

I wrote it I guess but like it's hard to particularly understand this stuff. So kind of the next step that we took was we were playing around with some of the encryption mechanisms and things like that like like that to opuscate like what if vendors still find a way to trigger on the actual um malicious Python script sources. So real quick if you don't exactly know how PI installer works. It basically wraps up a self-contained Python environment takes your script as a resource like sticks it in there. Then when you run it, it extracts everything we've just temporarily and invokes that script like okay, let's see how far we can take obiscating a Python script file. So we

introduced a little kind of module called Hyperion which is like a Python encryptor inspired by Hyperion. It encrypts an entire Python file with a random ads key. It's randomized each time. It b 64s it and rolls everything up into a nice little exact wrapper. So every time this is run, even for the same exact input file, it'll generate a completely different blob of text. And I'll show you here in a second. So this is what you know, one of the shell code injectors look like first. Now you still have some of the binary data and all that kind of stuff like okay, is there something more we can do with this? And after this is what it looks like each

time. You just have a couple imports of little exec and like a giant blob of text that changes every single time because the key change every time. So like okay that's a we figured that's about as far as we can go with Python obation. One of the next things we kind of started our thought process started going down was what if vendors are triggering on the raw shell code in the actual decoders whether in C or in Python like okay then what if we just eliminated the shell code all together and build some pure pure interpreter stages. What these basically are is that logic from shell code that you get from MSFM. You take that logic and can

translate it to a higher level language and you get a interpreter stage that does not rely on shell code generated by the framework. They actually aren't that complicated. Rafael Mudge has some great posts down here. Uh he open source loader and he has a blog post about what stage payloads testers should know where he goes into detail about excluding this stuff. So real quick, this is how the stagger works. You open up a TCP connection back to your your metasloit handler or metasloit handler. The handler spits back four raw bytes that indicate the size of the DLL. This is the interpreter DL itself. This is actually you know what's running in memory of the machine

after you pop it spits that back then it spits back the full actual interpreter DL. This on the client side socket number that connected back push into EDI. And the reason it does this is so you don't have to open up a separate control channel back. It can just use that existing socket. So it pushes that to the EDI soer can actually pop that out. Execution is passed the DL just like you would regular shell code either using V pointer cing or that virtual pattern I talked about and then the Terer uh uses that existing socket connection starts his SSL negotiation and all that and then just goes down. So we started writing a bunch of these

stages in different languages. Um we have you know Python interpreter vers TCP HTTP and HTTPS. These are actually easier than the TCP stagger where all you do is connect to an HTTP handler. You download a giant blob which is either reflectively injectable DL or shell code and then it you just jump execution to it. So we also have stuff in C. We have a reverse TCP reverse TCP service which will work with PS exec HTTP and HTP service which will work with PS exact as well. We have C. We've got the same TCP HPHPS PowerShell. We released this um I think it was around the Deathon time frame release a couple of these pure standard and Ruby which

I'll talk about here in a minute. So that was really super basic stuff. it was still reasonably effective in a lot of these cases. But, you know, for things like C, just basic variable occupation isn't going to work that well. We started thinking, okay, C specifically, because it's a lot easier for AV engines to detect some of the code in it. Can we introduce something a little bit more interesting? So, our slightly kind of word by using advanced with air quotes because it's not that advanced, but our C opation involves our interpretation of what we're calling a method knob. And basically the idea here is how can you muck up dynamic analysis without affecting the execution of the program.

That means nested call functions you know like randomized stuff a whole bunch of processing. The idea is that we thought our approach was throwing enough string processing functions that sufficiently complicate the call tree program. This is a very basic version of what malware has been doing for years. It's not that should be that effective but it is really really effective. these will be junk processing stuff that CPU at least fight just a little bit. So for us specifically for C what we do is we choose a whole set of randomized string processing functions reverse split you know all that kind of stuff we maloc a huge several thousand strings of randomized links and then in throughout

the code will intersperse these different like nested processing functions all throughout it. This happens in several places. So you know maybe the virtual page is allocated and after that there's a you know several nested you should look at an IDA or something and just explodes. So this is really really effective for a lot of C stagers and again those uh we have versions of those stagers which will work with stock PS this is just kind of showing you like string generation functions and probably it's a terrible screenshot but all this stuff is like randomized out. If you actually look at the C payload models, you'll see everything that's uh run into there. Cool. One of the next things we were

thinking was, okay, what did vendor trigger on the PI installer loader itself? And again, that uh the exact exact way how PI installer works. It has this little .exe loader that then it attaches basically like kind of like a zip zip archive at the end of it. That little loader runs. It extracts the zip archive from itself, extracts that to disk, invokes the interpreter and all that kind of stuff. So you're like, okay, uh, and this the reason this actually came about is because that little loader actually enables or has dev enabled whenever you try to run it. So Chris, now we're investigating how can we get depth disabled for these payloads is if you want to do something

like avoid pointer casting that will fail if the memory if the region of memory is not executable. So as we investigating this and we put a post out I think in January about how to recompile this stuff like okay if we can recompile this on maybe we can get it recompile in Cali that took a little effort and finling but we figured out how to recompile the pine staller or the yeah the pine stellar loader every time cali like okay we're doing that why not occupuscate the source as much as you can so this past May this past spring I gave a talk at besides Boston called installer 1.0 Now this is basically a it

uses like the randomization stuff as well as all the string processing method call nesting stuff that I just talked about. It puts all that into the pi installer source and then every time you run this if you choose the option for pon installer and valation it'll generate a opuscated unique pi install loader every single time you generate a payload. We integrated this in the validation the past May. It's also a standalone tool that's right out there. So again on each round opated code for every single source file associated PI installers generated minw32 is used to compile everything up to a new runw loader exe all straight on Cali. You don't have to drop this to Windows. Everything's

transparent. You don't have to configure anything. The runw is copied into the correct location. Now randomize Windows icon is chosen for the final package result. There's a blog post I have on phone installer and also I think the video and the slides for the Psiz blossom presentation are out if you're interested. So this is kind of like the big thing I guess that I'm releasing um at this con or presentation. But since some people started paying attention to the pine staller binaries let's try some little languages. We already, you know, we first branched into C with some good opusation. C, you can actually use Mono on Cali to compile .NET executables that'll run on Windows. PowerShell, we

started mentioning that is awesome. You can have no disc rights. And Ruby, which I had, so I apologize there's prior stuff out there about this, but I really couldn't find much. Ruby has a foreign function interface just like Python. It's a gem called Win32 API. So this means because we have access to those lower level functions, we can inject shell code and we can write native pure interpreter stages all in Ruby and it has it Ruby has its own pine solar analog a gem called cockro one click Ruby application there's the cockro so I was trying to think like okay can we get this all running on Cali because again our philosophy is we want to have

a single monolithic attack platform you don't have to switch back and forth this is showing the Ruby shell code injection. You can set up all your virtual Alec move memory create thread. You have your shell code here and it's pretty easy. Just virtual alloc memory page, move all that memory there, create the thread, wait for the object to complete, basically wait forever and this entire thing will inject whatever shell code you want all in Ruby and we have it running on Cali for Opra. So, uh the new setup will download all the gems you need. Um everything will be set up for availabilation when you update. Then when you compile a Ruby payload, which I need to push into the

dev tree today, um it'll run Opera all in the background. You see it's compiling everything up. Um it compresses everything and builds out your .exe right here. So all this Ruby stuff you pretty much exact analog of Pine installer with the the approaches we have. But now we're going to be releasing the Ruby Shell inject and Ruby interpreter stager. Again, they're in the dev branch. will be merged in the master on our Pday for this year which is actually our one year anniversary everything is compiled with self- extracting Windows executable the last like kind of the last kind of cool little thing releasing is um so because C and DB.NET code is compiled. It's not interpreted. So you can't build

a kind of little dynamic copycater like you can for you know scriptable language like Python or Ruby. But .NET has a really interesting little feature called reflection which is this is taken from the Windows documentation stuff. So you can use reflection to create type instances at runtime and then invoke and access them. This means is if you have a a bite array of just raw bytes that are read innet executable, you can run the entire executable in memory without touching disk using just three lines. You create little assembly a load and you load up whatever your bite array is. You set the entry point. You create that object and you basically say start running this. The cool thing

is you can obiscate these bytes in any way you want beforehand. You can base 64 them up. You can encrypt them. You can download them from a secondary location and then you can this is essentially kind of like doing that uh like the reflective DL type injection idea but is significantly easier using .NET. So we're releasing a a small kind of simple net cryptor called area. It's a cryptor for all net binaries. It was pushed along with the Ruby payloads. It's also a standalone if you want to use that. So a normal payload binary either you know VB or C# or whatever is generated is compiled as normal and if you set the crypto to run it will read in all the

raw byes will base 64 encode it and build a random substitution cipher so it's not just straight B 64 and then it builds like a little launcher dropper there's two options you can either have it launch that opuscated version from memory or you can host it and then it'll build like a little web dropper it will go out download it and then pull it down and execute it memory without touching disc. And again, this is all just using reflection. This is kind of what it looks like. You have some a little bit of just the standard logic. This is actually a full net binary that's on memory. It can be any net binary you want. Um, so it's

pretty simple. The really cool thing is, which I'll go over here just a little bit, is it changes completely every single time you run it. So it really messes up kind of that net CIL compiled stuff inside of it. Cool. I'm going to finish up by going over a little bit of analysis of some of the payload families. So, SSD is a fuzzy hashing static malware comparison tool and this is also called context triggered piece peacewise hashes and it allows the comparison of different malware families. From his documentation, it said it can match inputs that have homologies. This is just a fancy biology term which is basically a way of saying how can you measure the shared ancestry of two

different bits of information. So it kind of breaks everything instead of doing a hash of an entire file like break it down in like little ones and then kind of do a binary matching between two files of saying how much of this code base is related between these two binaries. So what I did was for about three or four of the P valation payload families I generated a thousand samples of each one and I did runs of SSD over all of them. What it did was it basically matched up pairs uh it did 1,00 choose two. So it basically did every single pair combination of all the payload modules. So so say for like Python interpreter

versus TCP 1,000 choose two. So 499,500 possible pairing combinations of these for Python 169,17 or about 1/3 match a score of 75 or better and only 66 of them match a score of 90 out of 100 or better for the matching stats. And from one of my kind of blue team reversing friends, he said the general rule of thumb, at least in his group, is if something matches at 90 or better on this, it's kind of considered a related malware family with a common ancestry. So what's cool with this is already for just even Python only 0.01% of the sample scores a similar malware family at least from kind of a really basic static analysis

standpoint. Showing you kind of the graph here. This is the distribution. I didn't put in all the zeros because that would have spike the graph up. Um so a bunch of them are really not similar but you know a chunk kind of you see a peak around kind of this matching point. You see it really kind of trail off. So we get really comfortable randomization. You know these payloads are different every single time for C. This is one of the pure senior interpreters gauges. You have the same 499,500 possible pairings. 267,387. So about half massed a score of 25 or better. So that means half had absolutely like no match at all. They were completely different and only.5%

scored at 90 or better and the average reply score was 37. What was the average for that? Yeah, forgot to mention the average score 74. So you see here that even though we have a few more is.5% instead of 01%. A few more that are kind of in that similar power family. we have really good wide variation in a lot of the generation. So, it's kind of all over the map. Again, there's a whole bunch kind of spiked up here for zero, but it's uh not quite as quite as tight of a cluster. So, even though you get a little more variation kind of at the top end, this is, you know, really good spread for

this type of generation. This is my favorite. So, C using the it's a shell code inject module. um just using font injection using that little area net cryptor. Out of all the pairings, only five pairings of the 499,500 samples 0.001% match at a score of 25 or better. So these are almost completely different every single time because that stuff randomized generated there's a substitution cipher. This means that none of the sample scores a similar mower family. The variation was all over the map. This stuff really different every time. So this is actually the one like I I like using now or I will be using a lot more now because if you get one of these samples if it gets caught

and submit it up this is a really hard thing to write a tag signature for. I think I went kind of fast but uh so recap we started out our research kind of out of necessity but we continue out of curiosity. You know messing up these a vendors really isn't that difficult. Um this stuff is still really really effective over a year and a half out. uh like the Python stuff is still extremely effective even without the home installer. All our code is open source. AB vendors can see what we're doing. Um they're still not able to write a perfect signature for it. Though we did get a Mac signature a few months ago was

actually like Trojan Bale. We put that in our um our blog post about a month or two ago on the kind of you know a year in the bail framework. So we we were really happy. We had our own little stag signature. But we what we kind of take from that is that we're at least, you know, catching the attention of some of these vendors saying like this stuff isn't hard. Um, if you're doing proper behavioral analysis and detecting, you know, like that shell go injection pattern or something like that, that's what we need to move towards. Use static signature detection really. There's still ways to stop us from having to go over all those because, you know, that's

not our job. Um, and again our hashtag alol uh questions I can either take them now or hit me up on Twitter. Uh, email me. There's more information about the veil framework on our veil framework site and the goods. This is the veil framework project. We have a master project that's veil. If you pull it down, we'll pull down all the components of the veil framework. Install everything up. Um, we're actually probably going to be rewriting the framework from scratch in the next couple months. It's going to be veil 3.0. So, we're hoping for a a winter or an early spring release. Those unobuscated stages I mentioned, I just pushed those to my personal GitHub this

past week. So, if you actually are curious on how each of these work or how interpreter loader works, HTS or something like that, you can download that stuff. Um, it's fully commented and it's not completely offiscated. So, little early, but yeah. Oh, yeah. Sorry. I've got giveaways too for people that want to ask questions. Yes. Do you have any plausible explanation for the gap between malware owners and pit testers? Um yes. Uh so um a lot of shops had have sorry okay the question was can you explain the gap between malware authors and p testers and the thing is like so a lot of pentesters a lot of people had uh techniques like this just no one wanted

to like burn them by doing them publicly like we're not the first ones to do some kind of framework that does a evasion people had that before uh people just didn't want to be stupid enough to expose all those methods open source to where you know AD vendors can actually detect what they're doing. Our point of this is beyond just wanting to do our jobs. We want to actually try to push in our own little way forward to detection um for AB engines. But I think the explanation of one they don't open source their methods and two there's a lot more money in professional malware than there is in pen testing. So they have a lot of really smart people that

only sit there and can figure that stuff out and get paid a lot more. I can create these obiscated payloads as executables. What um how can I deliver them via uh memory corruption attacks and things like that within the existing frameworks and exploitation tools there. As far as memory corruption, I don't I mean you for memory corruption, you're just going to use straight normal like shell code, right? buffer like for this for us it's almost more of a post exploitation kind of thing or if you need to PS exact to a box or deliver payload like this through fishing or something like that yes in the back are there any A vendors that are doing

it right are there any AB vendors that are doing it right um for detection yes uh Kasperski which is basically a Russian botnet uh it's like a root kit essentially in your OS and they send all your samples back to a bunch of servers in Russia uh they're really effective. I wouldn't recommend using them because I don't like all my information potentially going back to Russia without them telling me what they're doing. Um semantic endpoint protection is also really effective. One of the things they started doing was if you configure it correctly is they had this kind of um you know and there's not like a universal exclude folder across the entire enterprise which never happens.

Uh there some places have started kind of like crowdsourcing the reputation of executables. What we'll do is they'll say like, "Oh, I've never seen this .exe before." So if you have encrypted .exe, any hack generated .exe, it's going to be brand new. So if they've never seen it before, they'll pop up a little splash screen to the user saying this is unknown. They won't say good or bad. They'll just say, "We don't know what this is. Do you want to run this?" With that splash screen stuff that can potentially mess up, you know, some of your delivery mechanism. So that's really effective. um you only get to run that use PowerShell or we actually have

a method with Python to where it'll extract a like kind of known script Python um environment to disk but all those you can just kind of do that manually with the zip instead of through PI installer and all those exes and DLS are known they're like known and good it's just Python and then you can invoke like Python shell gun injection to the command line kind of like you would with PowerShell and that will get around some of the reputation stuff so there's almost always been the kind of way around, but some of the vendors have started to up the game just a little bit. Uh, yes, in the red. Uh, are there any plans to write this in

any other languages like Go? Uh, are there any other plans to write in any other languages like Go? Yeah, we're always we're always expanding. We have a large amount of private research and stuff that's already written and we're just kind of slowly releasing it out. We did want to release it all at once. We're also still, you know, kind of researching, developing it, but we wanted to space it all out. Plus, we're not just dropping 50 things at once. We want to kind of incrementally push stuff forward. But, um, yeah, there's plans for plenty of other languages. If people have ideas, you know, and if you want to submit something, we'd be happy to have

a pull request. The one thing that gets tricky is what we're trying to stay away from is stuff where you just generate it and have to compile it on another platform. Not saying we won't ever, you know, not do that, but we really like if you can compile everything on Cali, which makes it difficult. You know, it took a while to figure out how to get Opera Win32 API and everything installed underline on Cali with all the dependencies and we have to like patch stuff in like it's a little bit of a messy install process and that's also why there's you know like 800 megs of dependencies or something is if you want to compile or DB on Cali there's only

one option that's mono which is like 600 megs of dependencies. So, we've had people yell at us for the size of the framework install, but there's not really any other option if you still want to be able to to do this stuff. But cool, isn't it great? Is there a book that I can have for asking this question right now? Uh, there there's nothing. [Music] Sorry, Anything else? Any other questions? Cool. All right. If you if you want to talk to me offline or after just hit me up there for you.

[Applause] All right. Thanks. So, we got we got about uh 24 minutes. 24 minutes and we'll start up again on our next speaker.