WEBVTT 00:03.420 --> 00:09.160 Hi everyone, thanks for attending. 00:09.640 --> 00:27.000 My name is Jonathan and the topic of my talk is going to be about the dark side of Winsock, which is essentially all the under-the-hood functionality that you have inside Winsock, inside the Windows TCPIP stack, which unfortunately, even though it's there and it's publicly available, 00:27.000 --> 00:36.900 it is somewhat undocumented and the only people to really use it are the bad guys, namely people who want to do rootkits, who want to do spyware, etc. 00:37.440 --> 00:42.500 Now I find myself somewhat inclined to start with the preamble here. 00:42.580 --> 00:52.520 This is not some type of vulnerability issue or not some type of any zero-day exploit, so if any of you are expecting that, it's probably not the right place to be. 00:52.520 --> 01:08.760 What this is, however, is a discussion on functionality which, like I said, is in there and it's mostly... well, mostly the only really good uses, as you'll see, are the insidious ones, namely the ones that aren't really designed to happen. 01:08.820 --> 01:16.500 Things such as usurping connections, rerouting connections, connection monitoring, etc, etc. 01:16.620 --> 01:22.740 Now it is assumed that you guys have had some experience with Winsock before. 01:22.740 --> 01:26.920 How many of you have actually coded in Windows for Winsock? 01:28.320 --> 01:42.460 Okay, well, okay, so as I was, you know, I kind of suspected that, so we'll start with a brief intro that kind of has the nomenclature and kind of has like the basic terminology, so those of you who are fairly new to this will be able to sort of like keep afloat. 01:42.560 --> 01:44.080 And then we'll get into the code. 01:44.080 --> 01:48.680 Now the code itself that I'll be demonstrating is all fully annotated, you've got that on the CD. 01:48.680 --> 01:57.400 On the CD you have a PDF of my talk, which, contrary to other PDFs, it's not just the slides, it's also the notes pages. 01:57.440 --> 02:00.580 So you'll be able to have the full source code, everything is there. 02:00.860 --> 02:11.820 Furthermore, my demo, which I'm going to run shortly, is based on a public demo, which is Intel's and Microsoft's code, so it's like fully open source and nothing too new there. 02:12.120 --> 02:22.820 So, we start with the introduction, and some of you may already know this, and I'm actually hoping most of you know this, but it's just sort of like the basic terms we'll be using. 02:23.000 --> 02:28.460 So, as you all know, IP communications are usually based over what's known as sockets. 02:28.480 --> 02:39.060 Sockets were something that essentially are meant to abstract sort of like what you'd have with file descriptors, only in this case it would be network descriptors. 02:39.060 --> 02:46.620 The idea is fairly simple, the application would open a socket and would just send and receive data as it would with any other file descriptor. 02:46.620 --> 02:49.340 This could be using receive, send calls, etc, etc. 02:49.400 --> 03:05.060 And there you'd also have some other APIs, which are essentially get peer and get adder info and so forth, which are meant to be socket specific and to enhance these descriptors so as to accommodate all types of TCP and UDP based needs. 03:05.340 --> 03:11.200 Now, the application itself is somewhat agnostic in the sense that for it, it's just another file descriptor. 03:11.200 --> 03:17.760 Those of you who may have some Unix background know that sockets and file descriptors in Unix are one and the same, pretty much. 03:17.760 --> 03:20.020 So you can, you know, you have the very same API. 03:20.020 --> 03:29.500 In Windows, what happens is that you have the Winsock, which I'll be describing shortly, which takes the sockets just a bit further and gets you a lot of added functionality. 03:29.500 --> 03:44.320 Now the important thing to emphasize is that the application would read and write just with any other file descriptor, so what would happen essentially is that all the fragmentation and encapsulation and getting the IP header and the TCP header, UDP, whatever it is, 03:44.320 --> 03:58.500 is basically handled transparently by the OS, which is really good news for a lot of application developers because they just work transparently and just don't care about whatever IP issues or TCP and so forth issues that might arise. 03:58.500 --> 04:02.720 Now what I'm going to demonstrate to you works with pretty much all sockets of all types. 04:02.720 --> 04:12.740 It works with TCP, UDP, raw sockets as well, in case Microsoft hasn't crippled them completely in Service Pack 2, and also IPv6 sockets, which is really nifty. 04:12.960 --> 04:26.200 Now, the way it works is that Microsoft took the BSD model, which is your average libc type socket with all the rich API, and adapted it into something known as Winsock, which is basically Windows sockets. 04:26.320 --> 04:29.480 This went through several versions and revisions. 04:29.780 --> 04:36.620 We started with Winsock 1.x, which you're not going to see anyway because it's mostly like for Windows 3.11 and so forth. 04:36.620 --> 04:40.180 And Winsock 2 is basically your baseline today. 04:40.180 --> 04:47.380 That is to say it's present in Windows NT, it's present in Windows 2K, 2003, etc. 04:47.380 --> 04:48.660 And of course your XP. 04:48.660 --> 04:57.780 Now the major important issue with Winsock is that the migration from 1.x to 2.x added a host of new features. 04:57.780 --> 05:09.960 We're not going to be discussing those new features in length, but some of you may know that it provides for asynchronous calls and various function callbacks, which is really good if you're working in a multi-threaded environment and so forth. 05:10.080 --> 05:16.240 It works with overlapped IO, namely getting more than one process to listen on the same socket. 05:16.560 --> 05:25.160 And this is going to be the topic of our talk here, it provides something known as an LSP architecture, which is the layered service provider. 05:25.160 --> 05:31.540 This is going to be a very key and instrumental term for us, as this is essentially the core of the talk. 05:31.540 --> 05:46.800 This service provider interface is essentially giving you the architecture to hook any Winsock call by any process aside from certain system processes which bypass Winsock, we'll get into that in a second. 05:46.800 --> 06:07.140 But essentially any Winsock functionality you wish, well it can be anything from a get host by name, through of course sending and receiving in sockets and so forth, everything is pretty much hijackable in the sense that this is pretty much the equivalent of set windows hook that you'd have for general Windows API functions, 06:07.140 --> 06:09.680 only specific for the Windows platforms. 06:09.680 --> 06:30.220 Now this is really, really useful and we're going to be talking about some of the legitimate uses which as you'll see, there's quite a few legitimate uses, however we'll also see that the really important uses are those that are, so to speak, less useful for the good guys and mostly sort of like the covert or the black hat oriented uses. 06:30.220 --> 06:48.440 Now it's also important to say that like I said, this has been out there for about seven years now pretty much, my first encounter with that was like 1998 or so and it's really frightening to see that all this functionality is there, it's under the hood so your applications are fully agnostic, 06:48.440 --> 07:01.180 they have no idea that this functionality is there and yet spyware developers and other such application developers can pretty much inject whatever functionality they want and the application is none the wiser. 07:01.340 --> 07:10.160 So, getting into detail here, this little illustration here shows you pretty much what the Windows networking architecture is all about. 07:10.160 --> 07:16.960 Some of you may find this a bit familiar, for those of you who aren't, I'll just run a brief sort of like, uh, review of this. 07:17.180 --> 07:24.500 So, looking at this from several levels of abstraction here, oops, wait a second, that's Microsoft PowerPoint running bald on me. 07:24.500 --> 07:30.340 So, looking at this from several layers of abstraction, we can see the hardware down below. 07:30.340 --> 07:45.700 Now, no matter what hardware type you're using, whether you're using a wireless network or a wired Ethernet or even a modem, pretty much all your Windsock calls will eventually be rerouted over the hardware in a sort of, uh, device independent manner. 07:45.840 --> 07:52.720 The miracle that does this is something called the NDIS driver, which is the network driver interface specification. 07:52.720 --> 07:57.060 That's sort of like an abstract driver for any type of interface. 07:57.160 --> 08:01.920 Uh, in Unix terms, some of you may be, uh, aware of the ifconfig and the interface configuration. 08:01.920 --> 08:05.460 So, it's pretty much a port of the same idea in Windows terms. 08:05.540 --> 08:13.600 And the NDIS is essentially an abstract driver that works with pretty much all types of communication, uh, devices. 08:13.600 --> 08:17.540 These can be modems, these can be, uh, Ethernet cards, etc, etc. 08:17.620 --> 08:21.780 Following that, we have the TDI, which is a transport driver interface. 08:21.780 --> 08:30.960 That acts somewhat of a, uh, somewhat like a bridge in the sense that you have calls from user space going into kernel space through this TDI layer. 08:30.960 --> 08:42.120 Now, in user space, you mostly have either Windsock 2 for 99% of the applications or something known as NetBT, which is the NetBios over TCPIP transport. 08:42.120 --> 08:48.920 Some of you who might be familiar with a backslash backslash server, the SMB or CIFS notation, that's pretty much it. 08:48.920 --> 08:57.300 So, aside from the workstation and server service, which are core components of Windows, pretty much any other application would go through Windsock. 08:57.300 --> 09:00.660 And that's, that of course is what makes this all the more attractive to us. 09:00.660 --> 09:10.320 Now, as the applications go through Windsock, they are pretty much, uh, you know, they all work over the same API, which is the application programming interface. 09:10.320 --> 09:22.020 And that is the API that you link with Windsock or WS2 underscore 32 dot DLL and it gets you the functionality of the send receive and as well as a host of WSA calls. 09:22.120 --> 09:26.120 Namely, uh, WSA async select and others to name a few. 09:26.120 --> 09:29.680 Okay, so, you have all types of, uh, applications. 09:29.680 --> 09:37.300 They can be your browser, your FTP, naturally your IMs, probably go over that as well, uh, IRC, et cetera, et cetera. 09:37.340 --> 09:43.060 Now, this is sort of like the application type view that most programmers are familiar with. 09:43.060 --> 09:47.080 However, as it turns out, this is only half the picture. 09:47.080 --> 10:05.020 So if, as, if we try and look deeper, we see that we have this Windsock API layer, which is, again, the top interface, but we also see that we have a Windsock SPI layer, which is a bottom interface that is meant for what Microsoft defines as service providers. 10:05.020 --> 10:19.840 Now, the term service provider, like I said, is a key term here because service providers are essentially either hardware types, namely, uh, you know, your network cards, et cetera, et cetera, or they could be software types as in software type drivers, 10:19.840 --> 10:21.740 which are mostly user mode drivers. 10:21.740 --> 10:30.700 Now, this is really important since it gives you the full functionality of packet inspection and whatever you want, but at the socket level. 10:30.700 --> 10:44.420 So essentially, from an OSI model perspective, we're working at layer 5, which is really quite the improvement over other types of, uh, sniffers and rootkits, which generally operate at a lower level and thus confine you to a packet view. 10:44.420 --> 10:52.280 So here you can actually hijack a socket and not really wonder as to whatever the breakdown of the packets is, because it doesn't really matter. 10:52.600 --> 10:56.220 Now, uh, essentially these providers are one of two classes. 10:56.220 --> 11:05.660 You have the transport providers, which as the name would imply, work with the data transport itself, namely the TCP and UDP transfers, et cetera. 11:05.880 --> 11:12.340 And you have the namespace providers, which work with all the, you know, get host by name, et cetera. 11:12.340 --> 11:20.740 Namely, if you want to look up any type of address, that address can be a NetBIOS name, it can be an SMB name, a CIFS name, et cetera. 11:20.900 --> 11:24.920 And this would imply, of course, that you need a mechanism to abstract that. 11:24.920 --> 11:27.880 And this is exactly what the namespace providers are all about. 11:27.880 --> 11:35.680 I'm gonna focus on the transport providers, because they are, of course, the, the sexier ones, in the sense that they actually get you to see some real data. 11:35.780 --> 11:48.880 Now, as the illustration also shows, all the providers would share the same API, the same top API, which is what I see here, what I marked here, as a transport SPI, that is the transport service provider interface. 11:48.980 --> 11:55.000 So whatever provider you're using, essentially all these providers must work pretty much the same way. 11:55.280 --> 12:04.520 Now, Winsock providers cannot normally be listed by applications, or at least they can be, but only if the application is actually aware of it. 12:04.520 --> 12:25.060 Microsoft has, as part of the platform SDK, which is part of the Visual Studio distributions, they have something known as an SPOrder.exe, which is a small executable, meant to show you the service provider, um, order, of course, and also it comes with a small DLL called SPOrder.dll. 12:25.260 --> 12:36.180 SPOrder.dll is a DLL we'll, we'll discuss shortly, it actually has the ability to not only show you the service providers, but actually shuffle them around as you see fit. 12:36.180 --> 12:40.200 And this type of shuffling around is exactly the hooking functionality. 12:40.200 --> 12:44.810 So going on to see a demo of what the service providers are like. 12:53.480 --> 12:57.300 Okay, so, autocomplete is not cooperating. 12:57.620 --> 13:02.400 So you have the SPOrder.exe, which shows you all the available service providers here. 13:02.480 --> 13:18.940 Now, my display is, um, particularly cluttered due to the fact that I have VMware here, which, uh, is pretty much all those global unique identifiers that you can see here, as well as another VPN solution, which opens up a, a, a, sort of like a virtual interface. 13:18.980 --> 13:23.400 But the core providers that you're likely to see are the ones you see here. 13:23.400 --> 13:36.220 There's one for the infrared, which is IRDA, there's one for basic TCPIP, there's one for UDPIP, there's one for raw sockets, and there's, uh, two of them for RSVP. 13:36.340 --> 13:42.860 RSVP is a quality of service protocol, which is generally supported, but never really used by Windows. 13:43.140 --> 14:00.180 Now, going into one of these, you can see that they essentially give you the complete information on the service provider, namely, which DLL is actually the one that provides the functionality, as well as a bunch of service flags, provider ID, which is a global unique identifier, 14:00.180 --> 14:01.260 et cetera, et cetera. 14:01.260 --> 14:16.040 The important stuff here that some of you programmers might recognize are the address family, the hex value 2, meaning AFINET, uh, there's also the socket type, which is, uh, SOCKSTREAM, and there's a protocol number, which is 6. 14:16.040 --> 14:17.520 6, of course, for TCP. 14:17.560 --> 14:22.260 And naturally you'd have, uh, 17, or hex 11, for UDP. 14:22.280 --> 14:41.920 And so the way that works is that any time an application would request a type of socket to be created, which would be a SOCKSTREAM, and rather an AFINET, SOCKSTREAM, and a TCP, essentially, a TCP socket, what would happen here is that this call would be redirected over to MSWSOCK.DLL, 14:41.920 --> 14:47.620 where WINSOCK, or the WS232 DLL, is actually acting like a multiplexer. 14:47.660 --> 14:53.720 That is to say that it is one main interface under which you can have all types of various providers. 14:54.000 --> 15:03.600 Now, again, this would normally be the case with your average Windows, and the more interfaces you have and the more applications you have, the more of those providers you're likely to see. 15:03.640 --> 15:07.300 As for the name resolution providers, these are the namespace providers. 15:07.300 --> 15:12.660 You have your basic TCPIP, which is an interface to the DNS client service. 15:12.660 --> 15:16.460 You have NTDS, which is, of course, Active Directory. 15:16.560 --> 15:23.140 And you have, uh, network location awareness, which is something that, again, Microsoft supports, but never really works. 15:23.140 --> 15:25.320 So, you have all those. 15:25.420 --> 15:28.340 And, now comes the important part. 15:28.340 --> 15:38.100 The important part is that you can have, over these service providers, you can have a functionality that enables you to chain your own providers. 15:38.100 --> 15:53.860 That is to say, not just add a provider , and by doing so, you're going to have to essentially make the application aware of that provider, but you can pretty much hook your providers and install something known as a provider chain, which is really an amazing idea. 15:53.860 --> 15:58.960 Now, the original plan behind that was to support all types of NICE uses. 15:58.960 --> 16:04.760 NICE such as transparent encryption, such as quality of service, et cetera, et cetera. 16:04.760 --> 16:13.820 But the way that works is that most applications don't really use that functionality, and so it's just left there, but not really used in everyday terms. 16:13.820 --> 16:22.140 Now, the beauty of it is that you can chain any number of providers, and you can chain them in pretty much any order you want. 16:22.140 --> 16:40.380 That is to say that if you want to provide some, uh, encryption functionality, for example, or reroute everything, all types of, uh, data transparently over SSL or SSH or whatever other tunnel you want, you can pretty much install your provider, and then bump it to the top of the stack. 16:40.380 --> 16:53.740 So, any other application using the stack would essentially get directed to your provider first, and your provider would do whatever, and then follow down the chain, essentially progressing the API calls down the chain. 16:53.740 --> 16:55.420 Any questions thus far? 16:56.480 --> 16:57.580 Okay. 16:57.900 --> 17:06.000 So, the way it works is that your provider Winsock, the DLL itself, has several functions which are exported. 17:06.180 --> 17:13.320 Uh, I'm going to try this, the dump-in demo a bit clearer here, so you'll be able to see the font back there. 17:13.440 --> 17:16.680 So, uh, just looking through that... 17:22.270 --> 17:30.550 Okay, so what I'm doing now is I'm setting up the visual, uh, studio command line, uh, environment, so I can show you the dump-in command. 17:30.730 --> 17:39.370 And the way dump-in works is, as some of you may know, it gives you the DLL and shows you all the exported functions, or the imported functions, and so forth. 17:39.370 --> 17:48.190 So, what I'm going to do now is essentially look for an exported function list of Winsock, and focus on the specific service provider interface. 17:48.190 --> 18:10.690 To do that, what we'll do is just do dump-in slash exports, get the name of the, um, of the WS232, and since, essentially, Winsock exports, like, on average about 100 and something functions, I'm going to use the command line utility of grep to isolate only those important ones for our discussion. 18:11.450 --> 18:17.470 So, looking at that, you can see that you have these particular WSC functions. 18:17.470 --> 18:25.610 Now, again, those of you who might be working with Winsock on a daily basis know that Winsock usually exports the WSAs, which is for the Winsock API. 18:25.630 --> 18:31.290 The WSCs you see here are essentially all about the service provider interface and so forth. 18:31.290 --> 18:48.750 Now, the, they're probably, there's too many functions here to, to actually go over, but the ones of interest are essentially install provider and deinstall provider, which enables you to, of course, set your own LSP or remove your LSP, as well as install namespace, 18:48.750 --> 19:00.630 and for some weird reason, it's uninstall namespace, hinting that maybe this API was not really meant to be used, because it's not really standardized in that sense, as in uninstall and not deinstall. 19:00.630 --> 19:13.670 Now, all of these are also fully documented as part of the MSDN, but it's the kind of MSDN documentation that resides on, like, the fourth CD that nobody ever gets to, because it's, like, so obscure in the back. 19:13.810 --> 19:24.390 Okay, now, as it so happens, okay, these functions are readily exportable, and you can use them to do, uh, your own type of work, as I'll show, um, briefly in a demo. 19:24.470 --> 19:32.870 Now, this SP order DLL is an additional DLL that, as I said, works for, uh, rewriting the service provider order. 19:32.870 --> 19:48.330 And as the example here shows, this is a dump bin of the SP order DLL, and you have write namespace provider, uh, sorry, write provider order and write namespace order, which essentially enable you to shuffle around, as I've stated, and put your provider just in its right location. 19:48.330 --> 20:02.410 Now, a lot of spyware aware applications, uh, like AdAware and all types of, um, anti-spyware, essentially look for that DLL, and if that DLL is present on your operating system, then it's bad news. 20:02.410 --> 20:05.010 Then they normally flag it as spyware and so forth. 20:05.010 --> 20:13.190 Probably the best example of that was, uh, Kaza, the file sharing utility, that has SP order dot DLL bundled in. 20:13.190 --> 20:17.810 So when you install Kaza, you have this DLL somewhere on your system. 20:17.910 --> 20:23.450 Another, uh , interesting application to use this type of DLL is Google desktop. 20:23.550 --> 20:35.110 Uh, I don't know how many of you use Google desktop, but Google desktop has, uh, probably its niftiest feature is that after you install it, whenever you go into Google dot com, you suddenly get your own desktop there. 20:35.110 --> 20:40.570 You have, like, the ability to search Google, or to search your own desktop from the very same webpage. 20:40.690 --> 20:54.590 Now, obviously, that kind of functionality would imply that Google has a mechanism in your machine that can intercept the calls to Google dot com, and re- sort of, like, rewrite the page content on the fly. 20:54.650 --> 20:57.050 And that is exactly the functionality that I'm describing here. 20:57.210 --> 21:06.370 Namely, by installing their own provider and putting it in your machine, they can, uh, intercept the go- the calls to Google, but they can, of course, do whatever they want. 21:06.370 --> 21:11.610 That is to say that if they're not really playing by the rules, they can do a lot of other stuff as well with your machine. 21:11.650 --> 21:17.110 But then, I'm happy to see that not too many people use Google desktop here, because that's kind of, like, shady. 21:17.110 --> 21:32.730 Anyways, so going over that, uh, pro- probably the most interesting API call would be the WSCEnum protocols, which would be the API call that one would use as a setup to install their own provider. 21:32.730 --> 21:45.010 This, much like all the other WS, uh, enum functions, will enable you to, sort of, like, go over the protocols that are already in place, and provide for an enumeration of them. 21:45.010 --> 21:50.270 An enumeration, in our case, would be a pointer to an array of protocol infrastructures. 21:50.270 --> 21:57.330 Now, uh, you have a fully annotated example on the PDF, uh, in the PDF, so I won't really go into that. 21:57.330 --> 21:58.790 But the idea is fairly simple. 21:58.790 --> 22:03.810 Anybody can call this function and see what service providers are already there. 22:03.810 --> 22:08.630 And in many ways, this is pretty much the only mitigation against this type of attack. 22:08.770 --> 22:18.390 However, most applications don't really use that, and if anything, they would use the counterpart of this call, which would be the WSA enum protocols. 22:18.410 --> 22:25.650 And the difference between the A and the C is that the C can get all the protocols, whereas the A gets only the top layer ones. 22:25.650 --> 22:30.650 So if you're using yours in a chain, essentially you can remain hidden, which is, of course, bad news. 22:30.970 --> 22:39.550 So, going over that, we have the enum protocols just to see which protocols are there, and we naturally want to build our own service provider. 22:39.590 --> 22:42.150 Now, building a service provider is really fun. 22:42.150 --> 22:46.690 It's really easy, too, because as a baseline, you have the Microsoft Supply demo. 22:46.770 --> 22:52.110 So, I happen to have this demo right here, and I'm going to work with the actual Microsoft code. 22:52.470 --> 23:05.650 Uh, due to copyright restrictions, I haven't really bundled it or, you know, put it in a charge easy for you guys to use, but it's fairly simple to just get this code from, uh, the MSDN and just work and do the same modifications that I did right here. 23:05.830 --> 23:13.800 So, looking through that code, uh, let's start with, probably the DLL main would be a good point to start. 23:14.060 --> 23:23.300 So, launching Visual Studio just so we, we can see this type of DLL, then our service provider is just, just going to be another DLL. 23:23.300 --> 23:25.680 So, essentially, it has to follow the very same conventions. 23:25.680 --> 23:32.260 That is to say, it has to start with a DLL main, and the DLL main would work as pretty much all DLL mains work. 23:32.260 --> 23:42.600 That is, whenever an application would hook to us and would call us, uh, we would get the DLL process attached at the, uh, DW reason. 23:42.860 --> 23:50.720 And so, the way that works is, whenever a process attaches, I add this little addition here, which essentially doesn't do much. 23:50.720 --> 23:54.600 What it does is it just opens up a file name, okay? 23:54.600 --> 24:04.360 It readies a file name here with a, with an S print F, composed of sock debug as a prefix, and the current process ID embedded in there. 24:04.360 --> 24:16.000 The reason I do that is because, once I'll do that and, of course, run my applications, you'll see that each application, as it uses Winsock, will generate this type of file on the root of the C drive. 24:16.060 --> 24:22.160 Okay, and what it does here is that it just opens the files and pops a message box, and you will be able to see that message box. 24:22.160 --> 24:28.500 That message box, and any type of code that I run here, is run in the context of the calling process. 24:28.640 --> 24:38.080 So, while this is a somewhat innocuous example, and just, you know, only for demonstration purposes, I'll print out a lot of stuff, if I really wanted to, I could do whatever I wanted here. 24:38.080 --> 24:41.080 Essentially, I could load additional DLLs, as the comment says. 24:41.080 --> 24:47.100 I could decide that this particular process should not access the stack, and so forth. 24:47.100 --> 24:55.960 Now, to make matters even easier for the spyware people, this type of functionality can also be injected in the WSP startup call. 24:55.960 --> 25:00.280 The WSP startup, which is shown right here in the slide. 25:00.380 --> 25:04.740 So, WSP startup is essentially the counterpart to WSA startup. 25:04.740 --> 25:17.140 Those of you who may have been working with Windows know that each Windows application, as it starts, as it launches its Winsock functionality, has to start off by calling this function, the WSA startup. 25:17.140 --> 25:23.000 And what it does is that it requests a certain Winsock version, and requests certain capabilities. 25:23.000 --> 25:31.220 Now, the beauty of it is that, you know, most programmers just call WSA startup, check the return value, and naturally everything is just okay. 25:31.320 --> 25:37.440 However, these programmers are unaware that this essentially would call the WSP startup, which is our code. 25:37.440 --> 25:45.100 So, in our LSP, what we're gonna do is essentially implement a WSP startup, which will have our very own code in there. 25:45.100 --> 25:52.200 Now, looking at WSP startup, you can see that it has five parameters, as opposed to WSA, which has, of course, fewer parameters. 25:52.200 --> 25:57.640 The parameters of interest here are specifically the three last ones. 25:57.640 --> 26:05.540 We have the in-parameter LP protocol info, which states what type of functionality the application expects. 26:05.540 --> 26:11.380 Namely, are we expected to perform TCP or UDP or any type of other service? 26:11.380 --> 26:29.520 We further have something known as the up-call table, which is, by far, the most useful parameter here, which will enable us to have an array of, essentially, it's a pointer to an array of functions, and these functions are the already installed providers. 26:29.580 --> 26:43.480 So that means that if I want to hook, for example, send or receive, I don't really have to think about how I would implement send or receive, but rather I would implement them my own in sort of like a stub function, and later on just go on to call the up-call table. 26:43.480 --> 26:45.720 And the example will demonstrate that shortly. 26:45.800 --> 26:48.620 Finally, we have the only out parameter here of interest. 26:48.620 --> 26:50.040 The other one's really not interesting. 26:50.040 --> 26:53.280 The LP WSP data is really not interesting. 26:53.280 --> 27:00.680 But the LP PROC table here is our procedure call table, and that is essentially a pointer to all our functions. 27:00.680 --> 27:18.560 So whatever functions you choose to implement, you can pretty much set in this big structure there, and just call WSP startup, and returning from the call, you would pretty much produce your procedure table, and you'd be guaranteed that your applications, 27:18.560 --> 27:21.460 your rather, sorry, procedures would be called. 27:21.460 --> 27:37.100 Now those of you who may have been working in the Unix and Linux environment would know that in order to achieve that in Linux, you'd pretty much need to have any type of a kernel module inside the Linux kernel, for example, or any type of streams interface in Solaris, 27:37.100 --> 27:39.240 which would of course be a lot of hassle. 27:39.240 --> 27:42.600 But when it comes to Windows, all this is pretty much transparent to you. 27:42.600 --> 27:53.220 So, looking over the SPI CPP, which is the main file that has all the functions, let's just go over WSP startup. 27:54.000 --> 28:05.220 And you'll see that what Intel and Microsoft do here, this is again their demo, is that they simply implement this WSP startup call. 28:05.220 --> 28:15.540 The important thing here would be after initializing their own internal structure, would be, number one, to save the Winsock2 up call table. 28:15.540 --> 28:22.920 That is to say, save the actual implementations that are already out there, because we're going to need to call them as sort of a pass through. 28:22.920 --> 28:33.160 And once that's done, they do a lot of other startup code and so forth, and they get to the important portion of populating the procedure table. 28:33.300 --> 28:45.680 So, the procedure table is a structure, and it's as simple as it can get, because you'd have a structure of function pointers, and all you have to do is just hook your function pointer to the corresponding functionality that you want. 28:45.680 --> 28:49.580 And so once that's done, you can essentially hook all those calls. 28:49.740 --> 28:59.340 Now, just looking at one of those calls, say for example, WSP receive, which would be the counterpart of the WSA receive and so forth. 28:59.520 --> 29:02.960 Okay, so looking through that, at some point we'll get there. 29:03.540 --> 29:05.060 Yeah, okay, there it is. 29:05.760 --> 29:15.040 So, this is the WSP receive function, which is again, guaranteed to be called prior to the application actually getting any data. 29:15.060 --> 29:20.000 So, if Google, for example, wants to rewrite the content, this is exactly the function they'll hook. 29:20.000 --> 29:23.520 Now, again, I won't go over the numerous parameters here. 29:23.520 --> 29:30.740 The parameters of interest are obviously the socket in question, and a long pointer to the buffers. 29:30.740 --> 29:41.640 This would be an array of input buffers, and since we're passing an array by reference, we also have to piggyback the third parameter, which is the count of buffers, namely what is the size of said array. 29:41.640 --> 30:03.680 And so what I do in my little demo here is do a fairly simple function here, which would just go on and write to the debug file that it's intercepted a receive, and would simply go over the buffer, it's going over the entire array there, and simply printing out the buffers. 30:03.700 --> 30:13.360 Now, as far as a demo is concerned, this is really not the type of graphical pyrotechnic demo you'd imagine, because it also will intercept a lot of binary data. 30:13.360 --> 30:19.120 However, it does illustrate the point that the data can be intercepted and can be, of course, modified. 30:19.140 --> 30:31.860 If you want to, you can pretty much have any type of modification of those LP buffers, and you can inject your own buffers, you can put your data, you can log the data, and so forth. 30:31.860 --> 30:34.100 I, of course, chose just to log the data. 30:34.280 --> 30:40.520 Now, naturally, you do the same thing for WSP send, and a host of other functions, but that goes without saying. 30:40.740 --> 30:47.420 So, we have our DLL, and now the next place would be, the next step, sorry, would be to insert it. 30:47.800 --> 30:53.860 Okay, somehow get Winsock to recognize our service provider as a valid service provider. 30:54.020 --> 31:04.440 Now, bear in mind that this is something that has to be done outside the DLL, because your DLL can only intercept certain functions, but it cannot install itself. 31:04.440 --> 31:09.700 However, in order to install it, we have another call, which is a WSP install provider. 31:09.700 --> 31:25.520 This is a fairly simple call, where all you have to do is provide a global unique identifier, which is, of course, easy to just whip up for yourself, and you'd set up your own DLL path, and the type of protocols you support. 31:25.520 --> 31:26.820 That's all it takes. 31:26.900 --> 31:33.400 Now, your example should have, actually, I'll go to my source code here, just to demonstrate how simple it is. 31:33.900 --> 31:43.340 So, all you'd have to do is have a small executable file, like, say, this inst.lsp, which, again, is a verbatim copy of the Intel one. 31:43.340 --> 31:48.760 I didn't really do anything here, because this is the same generic code that would work with any service provider. 31:48.940 --> 31:59.140 And so, what it does here is that it has a little function called install my provider, wherein I populate the provider info, like so. 31:59.140 --> 32:01.060 I populate a lot of stuff. 32:01.060 --> 32:07.040 You'll also notice a nice little flag here called PFL hidden, which is this flag right here. 32:07.040 --> 32:15.240 Which is a really nice flag, because this actually tells Winsock, if anybody wants to enumerate this provider from the API level, keep it hidden. 32:15.440 --> 32:19.980 Which, you know, I don't really get the actual intended use of that, but whatever. 32:20.000 --> 32:30.760 Now, there's also another interesting copy here, which is security scheme, which enables you to have your own type of security for your provider, blah, blah, blah. 32:30.760 --> 32:33.480 Most of the time, you just do protocol none. 32:33.540 --> 32:40.080 So, essentially, I populate this provider, and I, of course, register it as a protocol provider for TCP. 32:40.300 --> 32:50.820 And once that's done, all I have to do is just call this WSP, sorry, WC install provider, and provide the name of LSP DLL. 32:50.820 --> 32:59.300 This is assumed to be a Windows system, which would be a problem if you're not an admin, but then again, you're going to have to be an admin to run this anyway. 32:59.320 --> 33:02.960 But you can also specify a full path here if you really want to. 33:02.960 --> 33:13.340 And so, I load the protocol info through the pointer, and once that's done, I pretty much guaranteed that my provider will be installed there. 33:13.360 --> 33:18.660 Now, let's go ahead and try and install that provider and see exactly what happens. 33:18.660 --> 33:24.360 Now, you'll notice that I already took the liberty of placing that little DLL here. 33:24.360 --> 33:27.280 That DLL is as compact as 81K. 33:27.280 --> 33:29.420 Actually, it's 80K or so. 33:29.500 --> 33:37.240 And the thing is, once that DLL is in place, all I have to do is call the inst LSP executable to do the rest. 33:37.240 --> 33:40.140 Now, before I do that, I want to fire up RegMon. 33:40.320 --> 33:48.700 RegMon is a tool by Sysinternals, which I'm sure most of you know, and that enables us to hook all types of registry calls. 33:48.720 --> 33:58.140 And the important thing here is that all this type of functionality of installing providers or de-installing providers is essentially all registry-based. 33:58.140 --> 34:10.980 So, if you really want to bypass this type of DLL with enumerating the provider order and so forth or installing your own providers, all you have to do is directly access the registry, which is, of course, fairly simple. 34:10.980 --> 34:13.860 So, what I'm going to do now is I'm going to launch RegMon. 34:13.860 --> 34:18.160 And, naturally, all is silent because my process hasn't started yet. 34:18.160 --> 34:20.540 And now I'm going to run this inst LSP. 34:20.620 --> 34:29.340 And as I do, you can see that it's scanning the installed providers and then going on to install my provider on top of all the rest. 34:29.480 --> 34:37.380 Now, again, since this is a rather crude demo, I didn't really go to any, you know, pains of just looking for the right providers. 34:37.380 --> 34:40.080 I just said, go ahead and install it over all the providers. 34:40.080 --> 34:44.740 But it's fairly simple to just decide that you want a very specific provider. 34:44.780 --> 34:48.460 Now, you can also see that there's a lot of registry action here. 34:48.620 --> 35:00.420 And, specifically, all the registry action is focused on one specific branch, which is HKEY-LOCAL-MACHINE-SYSTEM, CURRENT-CONTROL-SET-SERVICES, and WINSOC2. 35:00.500 --> 35:16.300 So, firing up RegEdit, just to see what it's like there, you'll see, and it's already in my favorites, you'll see that WINSOC2 parameters has the namespace catalog, which is for the namespace providers, and the protocol catalog, which is for the transport providers. 35:16.300 --> 35:18.580 Now, again, Microsoft is inconsistent. 35:18.780 --> 35:24.260 They don't really call the things by the same name all the time, but that's, you know, beside the point here. 35:24.260 --> 35:28.560 So, under the namespaces, you have all types of catalog entries. 35:28.560 --> 35:38.820 And, as you can see, you have the same catalog entries that we could have seen under the SP order executable, namely the NTDS, the plain TCPIP, and so forth. 35:38.820 --> 35:55.320 And, when it comes to the protocol catalog here, everything gets really messy, because one would think that you'd get these nice type of keys and values, but here you only have a packed catalog item, which is a blob of binary data that if you go into, 35:55.320 --> 35:57.280 you'll actually see makes a lot of sense. 35:57.280 --> 36:03.960 This is a protocol info structure that has been overlaying into the registry as raw binary data. 36:04.000 --> 36:16.360 Now, you'll also note that once I put in my layered service provider, the number of providers here has risen from the 30-something that it should be to around 57, because that's where my mine is hooking. 36:16.540 --> 36:29.100 So, with all that in mind, the stage is set, and I can now run any application of my choice, as I'll shortly do, and you'll see that as the applications run, I'll get a nice little message box, and I'll get a full log of whatever. 36:29.240 --> 36:30.780 Any questions thus far? 36:31.480 --> 36:32.020 Yeah? 36:49.380 --> 36:55.200 Well, no, that would go with the namesake provider with the TCPIP one, which I'm not really discussing how to hook that. 36:55.420 --> 37:10.420 If you really wanted to, you could also hook the loopback address as well, so as people would, you know, go ahead and try to resolve, and get the 127.0.0.1, because it's in your host file, but then the application would get that first. 37:10.500 --> 37:23.480 So you'd be able to actually re-write the result of the NS lookup, or whatever DNS packet should have been there, and you'd be able to just put in any address of your own, which is of course, you know, very nice for our purposes. 37:23.500 --> 37:34.760 Furthermore, the Google desktop would then have to connect to the loopback interface, and that would be a transport type action, and you'd be able to get the connect. 37:34.760 --> 37:43.640 You'd be able to hook the connect call, and see a connect to 127.0.0.1, to whatever port Google is using, and of course redirect it. 37:43.700 --> 37:50.580 So simply, you know, simply providing your workaround wouldn't really work, because this functionality is actually stronger than that. 37:50.800 --> 37:52.100 Any other questions? 37:52.480 --> 37:53.820 Yeah, back there. 37:56.980 --> 37:57.960 Say what? 37:59.400 --> 38:00.580 Oh, you can't. 38:00.580 --> 38:07.300 The beauty of it, okay, so the question is, say I want to put in my own provider, how can I ensure that my provider is the topmost? 38:07.680 --> 38:10.140 Uh, in, you know, in two words, you can't. 38:10.180 --> 38:18.620 Because any provider that gets installed after you, can pretty much re-route, re-write, sorry, the stack as they see fit. 38:18.620 --> 38:31.900 So you'd have the protocol chain, you'd think you're there first, but the whole beauty of this mechanism is that it's so transparent, that at any other point in time, somebody can get ahead, sort of like bump in front of you, and hook you as well. 38:32.120 --> 38:36.120 So that's of course, you know, good news or bad news, depending on your perspective here. 38:38.100 --> 38:47.880 Yeah, but that's not to guarantee that somebody else, some other application starting up after you, they could enumerate the order as well, and they could re-write the order as they see fit. 38:47.940 --> 39:00.160 So essentially, this is somewhat of a limbo, in the sense that you have a given order, but the enum protocols will only provide you with a snapshot of the current order, and no guarantee of any other application coming after you. 39:00.160 --> 39:05.260 You cannot decide you want to be the topmost protocol in the chain, and that's it. 39:05.260 --> 39:12.480 Further, when any other protocol gets bumped in, you wouldn't know, you have no indication whatsoever as to your position. 39:14.480 --> 39:20.820 Yeah, you'd still be, well, again, okay, so, right, okay, so the question is, would I still be hooked? 39:20.820 --> 39:26.680 And the answer is yes and no, because yes, I would be hooked in the sense that I'd have my own place in the protocol chain. 39:26.720 --> 39:28.240 I don't mind the fish. 39:28.300 --> 39:42.540 So I'll have my own place in the protocol chain, yes, but if any other topmost provider would want to hold that call in the chain and not propagate it, not play by the rules, they'd be able to intercept it and essentially block it. 39:42.540 --> 39:52.880 So as I place my own provider, I can either choose to go ahead and forward the call, or I can say no, I want to handle the call, and I don't want to propagate it further. 40:03.170 --> 40:05.870 You can change the providers at any time, okay? 40:05.870 --> 40:18.670 Using the provider order, the WSPRite provider and so forth, you can pretty much redo the whole ordering as you wish, because essentially all it changes is some internal structure in Winsock. 40:22.310 --> 40:33.850 Oh yeah, of course, of course, but then again, there's no guarantee that you will be called again, because again, let's assume for a sake that I have my own custom provider, and I want to make sure that nobody gets on top of me. 40:33.890 --> 40:39.790 So, assuming whoever gets on top of me does forward the call further, yes, I will be called. 40:39.790 --> 40:50.530 But if that somebody takes the express route and just, you know, decides to bypass whatever other calls, then essentially my provider would still be there, but would never be called. 40:52.490 --> 40:57.590 Yeah, the order is in the registry, and of course, in enum protocols would work as well. 40:57.590 --> 41:01.830 You could enum the protocol so as to get it in a nice little array, but the order is right here. 41:02.070 --> 41:10.210 Okay, this is pretty much the order, I mean, you can pretty much see that the key names are the ordinals, so it doesn't get too complex than that. 41:14.130 --> 41:22.570 The route by sysinternals, I'm not familiar with the specific one, but I can tell you that a lot of other rootkit detectors don't really go that far. 41:22.570 --> 41:25.110 Now it's important to just define the terms here. 41:25.130 --> 41:28.170 This is perfect user mode action. 41:28.170 --> 41:35.670 This is not a rootkit in the sense of like a, a kernel mode rootkit, because that would be hijacking TCPIP.sys itself. 41:35.750 --> 41:39.170 And that, you know, that, that, there's nothing that can be done against that. 41:39.170 --> 41:50.270 But the beauty of it is that this is full user mode, and in that sense it's a lot easier, not to mention you can code sloppy and not risk a blue screen of death, which is of course a nice little added benefit there. 41:50.350 --> 41:56.490 Okay, so, uh, since I'm getting the, uh, noose, I'll just, uh, run a few applications here. 41:56.530 --> 42:00.570 So let's just start, you know, let's just run Firefox and a bunch of others. 42:00.570 --> 42:08.230 Oh, and as you can see, Firefox is loading, and already I have a sock debug of 1148, which is of course the process ID of Firefox. 42:08.450 --> 42:14.950 So Firefox is running, and this is the Mozilla start page, and I can do all sorts of, you know, other, whatever. 42:15.590 --> 42:20.430 And see, I can get any types of pages I want, and everything is really nice and dandy. 42:20.470 --> 42:27.070 But behind the scenes, I have this little, uh, sock debug, 1148. 42:27.070 --> 42:33.290 And of course I could also fire up my messenger, or my Yahoo, or whatever, and I'll do that just briefly here. 42:33.630 --> 42:38.470 Uh, so as, as I fire up Yahoo, I should be getting the message box sometime soon. 42:38.730 --> 42:41.150 Uh, yeah, just, you know, Yahoo's a bit slow. 42:41.150 --> 42:52.570 Okay, now you'll notice this is a really nice, uh, effect, that I get the message box in the context of the Yahoo process, so I get their window class, which is a nice, uh, not really nice, but, purple, whatever. 42:52.570 --> 42:53.290 Okay? 42:53.290 --> 42:56.670 And so, this is connecting, and everything is cool and nice. 42:56.670 --> 43:02.730 You can also see that it's hooking another call, and, uh, whatever, they'll just let it run. 43:02.730 --> 43:04.750 And, you know, ditto for messenger. 43:04.750 --> 43:14.070 So if I'll just run here, run messenger, uh, yeah, whatever, yeah, yeah, you can, okay, whatever, that's a student of mine, disregard that. 43:14.170 --> 43:14.650 Okay? 43:14.670 --> 43:31.730 So, uh, again, so I can run that with messenger and so forth, and all these SOG debug files are right here, so let's just go over the 1148 one, and we'll be able to see that, again, this is very crude, so I get a lot of seemingly junk-looking data. 43:31.730 --> 43:41.430 This junk-looking data is, is all types of either gzip compressed HTTP data, or, uh, all sorts of binary data, such as images and, and so forth. 43:41.430 --> 43:46.530 If I scroll down, I should be able to see some HTTP requests right here. 43:46.730 --> 44:01.110 Okay, so this is the get of header tab dot gif, and naturally, you get all types of this, this, for example, is a PNG , you can pretty much see the header here, that's a dead giveaway, uh, as well as a bunch of others , et cetera, et cetera, the HTTP replies and so forth. 44:01.110 --> 44:15.770 Now, again, I want to emphasize one thing, this, again, as a demo, is not as half as fancy as it can be, because with a little if there, I could have simply rerouted Mozilla to some other site, or I could have modified whatever Mozilla was displaying. 44:15.890 --> 44:21.130 Now, another disclaimer here, is that HTTPS type connections are unaffected by that. 44:21.130 --> 44:28.650 Fortunately, there are other ways to hook HTTPS, which are beyond my scope here, but I'm just saying that if you do use HTTPS, you're fine. 44:28.650 --> 44:36.450 However, when it comes to all types of other functionality, messenger, um, email, whatever, everything is pretty much in the clear. 44:36.650 --> 44:37.330 Okay? 44:37.390 --> 44:38.770 Any questions? 44:39.590 --> 44:40.250 Yeah. 44:42.590 --> 44:48.030 Yeah, with NetBT you can, although it's, well, again, that, let's define NetBT. 44:48.030 --> 44:56.190 If the process that runs the NetBT request has launched after you have put in your provider, then yes, you can. 44:56.190 --> 45:00.630 And if you get your provider into the Windows startup, then yes, you can. 45:00.790 --> 45:01.230 Okay? 45:01.230 --> 45:10.050 However, some functionality you still won't get, namely the, uh, the Winsock bypass functionality that sometimes a server service does. 45:10.050 --> 45:10.190 Okay? 45:10.190 --> 45:15.050 In order to, to gain efficiency, it doesn't go through a user mode DLL, because it doesn't make sense, you know? 45:15.050 --> 45:19.310 Okay, so you can hijack some of the functionality, although not all. 45:19.590 --> 45:20.810 Any other questions? 45:20.810 --> 45:21.390 Yeah. 45:23.610 --> 45:27.290 Uh, no, zone alarm actually, as far as I know, go into the TDI. 45:27.290 --> 45:28.850 This is what McAfee does, though. 45:28.850 --> 45:32.490 McAfee, the personal firewall, uh, does do, uh, they do do that. 45:32.490 --> 45:48.210 So, but again, this is kind of like, uh, kind of like, uh, a paradox in the sense that, you know, it's absurd, because if McAfee uses that, and I can pretty much intercept their calls and get on top, or, or reroute them to the bottom, then it's really useless. 45:48.990 --> 45:50.310 Any further questions? 45:50.310 --> 45:52.850 Because I'm getting the, sort of like, news time. 45:52.850 --> 45:54.690 So, yeah, right there. 46:03.950 --> 46:12.230 Okay, the question is, if I'm intercepting a WSP receive, if I'm intercepting an SSL socket, would it be encrypted or not? 46:12.230 --> 46:17.290 And yes, it would be encrypted, because I'm essentially getting it as it came on the network. 46:17.290 --> 46:30.130 So, this enables you to play middleman, but only middleman, you know, post-SSL or post-encryption, which is, as I've stated, the proper workaround, the proper mitigation to that would be to always use SSL and so forth. 46:30.130 --> 46:40.530 However, bear in mind that nothing is preventing the, uh, application from also, you know, trying to forge certificates and do any type of de-SNF type man-in-the-middle, which would work here. 46:40.710 --> 46:41.150 Okay? 46:41.150 --> 46:45.790 So, just to conclude, before I'm, uh, kicked out violently, okay? 46:45.790 --> 46:47.210 So, that was the demo. 46:47.210 --> 46:57.390 The lesson to be learned, the, the thing you need to carry home from this, is that no matter what you do, no matter how you code your application, the beauty of Winsock is in transparency. 46:57.450 --> 47:07.870 However, this is a double-edged sword, because obviously, as transparent as it is, it enables attackers to subvert either client sockets, server sockets, whatever. 47:07.870 --> 47:13.710 Now, it's also important to emphasize that this was originally intended for good uses. 47:13.710 --> 47:18.450 Namely, implementing an application type firewall, application layer firewall. 47:18.450 --> 47:23.270 We mentioned McAfee, and, ah, of course, we, we saw where that got. 47:23.450 --> 47:25.730 Um, transparently add encryption. 47:25.730 --> 47:28.150 This was well before the days of IPsec. 47:28.150 --> 47:32.630 We're talking about 98, before IPsec was a fully robust protocol, as it is now. 47:32.630 --> 47:36.250 And nowadays, IPsec is handled, of course, in the kernel level. 47:36.370 --> 47:38.270 Uh, enforce quality of service. 47:38.270 --> 47:39.450 Yeah, right. 47:39.610 --> 47:41.510 Uh, support new protocols. 47:41.510 --> 47:43.810 This is also another nifty functionality. 47:43.810 --> 47:48.010 You can essentially support IPv6 by it, although it's supported already. 47:48.010 --> 47:53.790 You can support IPv9, you can support pretty much any other custom protocol over a raw socket. 47:53.890 --> 47:58.950 And patch content on the fly, which, like I said, Google Desktop actually do. 47:58.950 --> 48:03.330 Whether it's a legitimate use or an illegitimate use remains to be seen. 48:03.550 --> 48:10.030 However, the much better chaotic uses would be to patch content on the fly in the illegitimate sense. 48:10.030 --> 48:17.870 And again, we're talking about rewriting web pages, rewriting IMs, uh, doing a lot of other nifty stuff, which I will not disclose here. 48:17.990 --> 48:21.410 Um, obtain connection statistics, URLs, et cetera, et cetera. 48:21.410 --> 48:24.090 Most of the spyware applications do exactly that. 48:24.090 --> 48:26.830 They put themselves in so as to gather your statistics. 48:26.830 --> 48:29.430 This was what the CASA spyware did. 48:29.590 --> 48:33.750 Eavesdropping on any type of connection, but again, non-SSL ones. 48:33.750 --> 48:39.410 And, uh, rerouting connections, that is just hijacking the sockets, which is really an amazing thing. 48:39.410 --> 48:43.110 Because an application opens a socket and calls connect. 48:43.330 --> 48:49.450 And once it does that, then, you know, the worst that can happen, it'll, it's gonna call get peer adder. 48:49.450 --> 48:52.590 But you can reroute connect and you can also reroute get peer adders. 48:52.590 --> 49:03.450 So, you know, whatever the application thinks it's doing, whatever, wherever it's, it's actually thinking that it's connecting to, it has no real significance here because you can do whatever you want with it. 49:03.650 --> 49:08.030 So, uh, all that in mind, the demo, like I said, is part of the platform SDK. 49:08.030 --> 49:12.710 Uh, you're welcome to drop a line to, uh, this address right here. 49:12.730 --> 49:21.450 And if you need, you know, the demo with the actual, uh, explanation on what I did, where I did, and so forth, then it will be supplied, of course. 49:21.450 --> 49:23.030 Any further questions? 49:24.550 --> 49:25.270 Okay. 49:25.270 --> 49:25.890 Peace.