WEBVTT 00:02.460 --> 00:08.160 Hi everyone, thanks for attending. 00:08.680 --> 00:26.040 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:26.040 --> 00:35.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:36.500 --> 00:41.500 Now I find myself somewhat inclined to start with a preamble here. 00:41.660 --> 00:51.540 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:51.540 --> 01:07.560 What this is, however, is a discussion on functionality, which, like I said, is in there and is 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:07.860 --> 01:15.540 Things such as usurping connections, rerouting connections, connection monitoring, etc, etc. 01:15.560 --> 01:21.760 Now it is assumed that you guys have had some experience with Winsock before. 01:21.760 --> 01:25.920 How many of you have actually coded in Windows for Winsock? 01:27.380 --> 01:41.320 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:41.320 --> 01:43.120 and then we'll get into the code. 01:43.120 --> 01:47.700 Now the code itself that I'll be demonstrating is all fully annotated, you've got that on the CD. 01:47.700 --> 01:59.620 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, so you'll be able to have the full source code, everything is there. 01:59.900 --> 02:10.860 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:11.160 --> 02:21.840 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:22.040 --> 02:27.500 So, as you all know, IP communications are usually based over what's known as sockets. 02:27.520 --> 02:38.080 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:38.080 --> 02:45.680 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:45.680 --> 02:48.360 This could be using receive, send calls, etc, etc. 02:48.440 --> 03:04.100 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:04.380 --> 03:10.220 Now, the application itself is somewhat agnostic in the sense that for it, it's just another file descriptor. 03:10.220 --> 03:16.580 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:16.580 --> 03:18.840 So you can, you know, you have the very same API. 03:18.840 --> 03:28.660 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:28.740 --> 03:43.380 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, encapsulation, and getting the IP header and the TCP header or UDP, whatever it is, 03:43.380 --> 03:57.280 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:57.280 --> 04:01.820 Now what I'm going to demonstrate to you works with pretty much all sockets of all types. 04:01.820 --> 04:11.760 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:11.980 --> 04:25.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:25.360 --> 04:28.540 This went through several versions and revisions. 04:28.820 --> 04:35.640 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:35.640 --> 04:39.220 And Winsock 2 is basically your baseline today. 04:39.220 --> 04:46.320 That is to say it's present in Windows NT, it's present in Windows 2K, 2003, etc. 04:46.320 --> 04:47.720 And of course your XP. 04:47.720 --> 04:56.700 Now the major important issue with Winsock is that the migration from 1.x to 2.x added a host of new features. 04:56.700 --> 05:09.080 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:09.080 --> 05:15.340 It works with overlapped IO, namely getting more than one process to listen on the same socket. 05:15.600 --> 05:24.220 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:24.220 --> 05:30.580 This is going to be a very key and instrumental term for us, as this is essentially the core of the talk. 05:30.580 --> 05:45.840 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:45.840 --> 06:02.640 But essentially any Winsock functionality you wish, it can be anything from 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, 06:02.640 --> 06:08.720 that you'd have for general Windows API functions, only specific for the Windows platforms. 06:08.720 --> 06:25.460 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 are 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, 06:25.460 --> 06:29.240 and mostly sort of like the covert or the black hat oriented uses. 06:29.240 --> 06:44.940 Now it's also important to say that, like I said, this has been out there for about 7 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, 06:44.940 --> 07:00.240 so your applications are fully agnostic, 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:00.380 --> 07:09.220 So, getting into detail here, this little illustration here shows you pretty much what the Windows networking architecture is all about. 07:09.220 --> 07:15.920 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:16.240 --> 07:23.600 So, looking at this from several levels of abstraction here, oops, wait a sec, that's Microsoft PowerPoint running wild on me. 07:23.600 --> 07:29.340 So, looking at this from several layers of abstraction, we can see the hardware down below. 07:29.340 --> 07:44.840 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:44.980 --> 07:51.760 The miracle that does this is something called the Ndisk driver, which is the network driver interface specification. 07:51.760 --> 08:04.500 That's sort of like an abstract driver for any type of interface, uh, in Unix terms, some of you may be, uh, aware of the ifconfig and the interface configuration, so it's pretty much a port of the same idea in Windows terms. 08:04.560 --> 08:12.620 And the Ndisk is essentially an abstract driver that works with pretty much all types of communication, uh, devices. 08:12.620 --> 08:16.800 These can be modems, these can be, uh, ethernet cards, et cetera, et cetera. 08:16.800 --> 08:20.740 Following that, we have the TDI, which is a transport driver interface. 08:20.740 --> 08:29.820 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:29.820 --> 08:41.020 Now, in user space, you mostly have either Winsock2, for 99% of the applications, or something known as NetBT, which is the NetBios over TCPIP transport. 08:41.020 --> 08:47.940 Some of you who might be familiar with the backslash, backslash server, the SMB or CIFS notation, that's pretty much it. 08:47.940 --> 08:56.340 So, aside from the workstation and server service, which are core components of Windows, pretty much any other application would go through Winsock. 08:56.340 --> 08:59.660 And that's, that of course is what makes this all the more attractive to us. 08:59.660 --> 09:09.380 Now, as the applications go through Winsock, they are pretty much, uh, you know, they all work over the same API, which is the application programming interface. 09:09.380 --> 09:21.260 And that is the API that you link with Winsock, 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:21.260 --> 09:25.140 Namely, uh, WSA async select and others, to name a few. 09:25.140 --> 09:28.700 Okay, so, you have all types of, uh, applications. 09:28.700 --> 09:36.340 They can be your browser, your FTP, naturally your IMs, probably go over that as well, uh, IRC, et cetera, et cetera. 09:36.360 --> 09:42.040 Now, this is sort of like the application type view that most programmers are familiar with. 09:42.040 --> 09:46.100 However, as it turns out, this is only half the picture. 09:46.100 --> 10:04.020 So if, as, if we try and look deeper, we see that we have this Winsock API layer, which is, again, the top interface, but we also see that we have a Winsock SPI layer, which is a bottom interface that is meant for what Microsoft defines as service providers. 10:04.020 --> 10:18.920 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:18.920 --> 10:20.960 which are mostly user mode drivers. 10:20.960 --> 10:29.740 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:29.740 --> 10:43.480 So essentially, from an OSI model perspective, we're working at layer five, 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:43.480 --> 10:51.320 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:51.580 --> 10:55.480 Now, uh, essentially these providers are one of two classes. 10:55.560 --> 11:04.800 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:04.920 --> 11:11.360 And you have the namespace providers, which work with all the, you know, get host by name, et cetera. 11:11.380 --> 11:19.760 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:19.860 --> 11:23.920 And this would imply, of course, that you need a mechanism to abstract that. 11:23.920 --> 11:26.880 And this is exactly what the namespace providers are all about . 11:26.880 --> 11:34.400 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:34.540 --> 11:48.180 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 mark here, as a transport SPI, that is the transport service provider interface. 11:48.180 --> 11:53.980 So whatever provider you're using, essentially all these providers must work pretty much the same way. 11:54.240 --> 12:03.520 Now, Winsock, uh, providers cannot normally be listed by applications, or at least they can be, but only if the application is actually aware of it. 12:03.520 --> 12:24.140 Microsoft has, as part of the platform SDK, which is part of the Visual Studio Distributions, uh, they have something known as an SPOrder.exe, uh, 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:24.340 --> 12:35.220 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:35.220 --> 12:39.260 And this type of shuffling around is exactly the hooking functionality. 12:39.260 --> 12:43.920 So going on to see a slight demo of what the service providers are like. 12:52.370 --> 12:56.430 Okay, so, autocomplete is not cooperating. 12:56.650 --> 13:01.510 So you have the SPOrder.exe which shows you all the available service providers here. 13:01.510 --> 13:17.970 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.010 --> 13:22.450 But the core providers that you're likely to see are the ones you see here. 13:22.450 --> 13:35.230 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:35.370 --> 13:42.050 RSVP is a quality of service protocol which is generally supported but never really used by Windows. 13:42.190 --> 13:59.210 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, 13:59.210 --> 14:00.290 et cetera, et cetera. 14:00.290 --> 14:16.550 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 SOCKSTREAM, and there's a protocol number which is 6, 6 of course for TCP. 14:16.550 --> 14:21.630 And naturally you'd have 17 or hex 11 for UDP. 14:21.710 --> 14:40.970 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, 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:40.970 --> 14:46.630 where WINSOCK, or the WS232 DLL, is actually acting like a multiplexer. 14:46.630 --> 14:52.790 That is to say that it is one main interface under which you can have all types of various providers. 14:53.050 --> 15:02.630 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:02.630 --> 15:06.210 As for the name resolution providers, these are the namespace providers. 15:06.210 --> 15:11.630 You have your basic TCPIP, which is an interface to the DNS client service. 15:11.630 --> 15:15.370 You have NTDS, which is of course Active Directory. 15:15.370 --> 15:22.130 And you have Network Location Awareness, which is something that again, Microsoft supports but never really works. 15:22.130 --> 15:24.410 So you have all those. 15:24.470 --> 15:27.550 And now comes the important part. 15:27.550 --> 15:37.130 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:37.130 --> 15:52.890 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:52.890 --> 15:57.990 Now the original plan behind that was to support all types of NICE uses. 15:57.990 --> 16:03.570 NICE such as transparent encryption, such as quality of service, etc, etc. 16:03.570 --> 16:12.850 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:12.850 --> 16:21.010 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:21.010 --> 16:39.270 That is to say that if you want to provide some encryption functionality, for example, or reroute everything, all types of 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:39.270 --> 16:52.790 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:52.790 --> 16:54.430 Any questions thus far? 16:55.530 --> 16:56.590 Okay. 16:56.910 --> 17:05.010 So, the way it works is that your Winsock, the DLL itself, has several functions which are exported. 17:05.070 --> 17:12.430 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:12.650 --> 17:15.510 So, just looking through that... 17:22.060 --> 17:29.580 Okay, so what I'm doing now is I'm setting up the Visual Studio command line environment, so I can show you the dump-in command. 17:29.860 --> 17:38.420 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:38.420 --> 17:47.240 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:47.240 --> 18:09.620 To do that, what we'll do is just do dump-in slash exports, get the name of the WS232, and since essentially Winsock exports on average about a hundred and something functions, I'm going to isolate only those important ones for our discussion. 18:10.460 --> 18:16.420 So, looking at that, you can see that you have these particular WSC functions. 18:16.420 --> 18:24.660 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:24.660 --> 18:30.060 The WSCs you see here are essentially all about the service provider interface and so forth. 18:30.060 --> 18:47.820 Now, the, the, probably there's too many functions here 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:47.820 --> 18:59.740 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. 18:59.740 --> 19:12.720 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:12.880 --> 19:23.440 Okay, now, as it so happens, okay, these functions are readily exportable, and you can use them to do your own type of work, as I'll show briefly in a demo . 19:23.500 --> 19:31.780 Now, this SP order DLL is an additional DLL that, as I said, works for rewriting the service provider order. 19:31.780 --> 19:47.560 And as the example here shows, this is a dump bin of the SP order DLL, and you have write namespace provider, 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:47.560 --> 20:01.420 Now, a lot of spyware-aware applications, like AdAware and all types of anti-spyware, essentially look for that DLL, and if that DLL is present on your operating system, then it's bad news. 20:01.420 --> 20:04.180 Then they normally flag it as spyware and so forth. 20:04.180 --> 20:12.280 And probably the best example of that was, uh, Kasa, the file sharing utility that has SP order dot DLL bundled in. 20:12.280 --> 20:16.820 So when you install Kasa, you have this DLL somewhere on your system. 20:16.940 --> 20:22.400 Another, uh, interesting application to use this type of DLL is Google Desktop. 20:22.580 --> 20:34.060 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.com, you suddenly get your own desktop there. 20:34.060 --> 20:39.440 You have, like, the ability to search Google or to search your own desktop from the very same webpage. 20:39.440 --> 20:53.420 Now, obviously, that kind of functionality would imply that Google has a mechanism in your machine that can intercept the calls to google.com and re- sort of like rewrite the page content on the fly. 20:53.420 --> 20:56.080 And that is exactly the functionality that I'm describing here. 20:56.080 --> 21:05.400 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:05.400 --> 21:10.580 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:10.580 --> 21:16.140 But then, I'm happy to see that not too many people use Google Desktop here, because that's kind of, like, shady. 21:16.580 --> 21:31.800 Anyways, so going over that, uh, pro- probably the most interesting API call would be the WC enum protocols, which would be the API call that one would use as a setup to install their own provider. 21:31.800 --> 21:44.000 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:44.000 --> 21:49.280 An enumeration, in our case, would be a pointer to an array of protocol infrastructures. 21:49.340 --> 21:56.280 Now, uh, you have a fully annotated example on the PDF, uh, in the PDF, so I won't really go into that. 21:56.280 --> 21:57.820 But the idea is fairly simple. 21:57.820 --> 22:02.820 Anybody can call this function and see what service providers are already there. 22:02.820 --> 22:07.700 And in many ways, this is pretty much the only mitigation against this type of attack. 22:07.920 --> 22:17.200 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:17.200 --> 22:24.660 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:24.660 --> 22:29.720 So if you're using yours in a chain, essentially you can remain hidden, which is of course bad news. 22:29.960 --> 22:38.840 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:38.860 --> 22:41.200 Now, building a service provider is really fun. 22:41.200 --> 22:42.420 It's really easy, too. 22:42.420 --> 22:45.720 Because as a baseline, you have the Microsoft supply demo. 22:45.920 --> 22:51.120 So, I happen to have this demo right here, and I'm going to work with the actual Microsoft code. 22:51.300 --> 23:04.680 Due to copyright restrictions, I haven't really bundled it or, you know, put it in a targeasy for you guys to use, but it's fairly simple to just get this code from the MSDN and just work and do the same modifications that I did right here. 23:04.840 --> 23:12.850 So, looking through that code, let's start... I think the DLL main would be a good point to start. 23:13.270 --> 23:22.350 So, launching Visual Studio just so we can see this type of DLL, then our service provider is just going to be another DLL. 23:22.350 --> 23:24.710 So, essentially it has to follow the very same conventions. 23:24.710 --> 23:31.430 That is to say it has to start with the DLL main, and the DLL main would work as pretty much all DLL mains work. 23:31.430 --> 23:41.430 That is, whenever an application would hook to us and would call us, we would get the DLL process attached at the DW reason. 23:41.430 --> 23:49.770 And so, the way that works is whenever a process attaches, I add this little addition here, which essentially doesn't do much. 23:49.770 --> 23:53.410 What it does is it just opens up a filename. 23:53.410 --> 24:03.410 Okay, it readies a filename here with an S printf, composed of sockdebug as a prefix, and the current process ID embedded in there. 24:03.410 --> 24:15.070 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:15.090 --> 24:21.150 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:21.150 --> 24:27.550 That message box and any type of code that I run here is run in the context of the calling process. 24:27.690 --> 24:37.110 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:37.110 --> 24:40.130 Essentially, I could load additional DLLs, as the comment says. 24:40.130 --> 24:46.170 I could decide that this particular process should not access a stack, and so forth. 24:46.170 --> 24:54.990 Now, to make matters even easier for the spyware people, this type of functionality can also be injected in the WSP startup call. 24:54.990 --> 24:59.230 The WSP startup, which is shown right here in the slide. 24:59.430 --> 25:03.770 So, WSP startup is essentially the counterpart to WSA startup. 25:03.770 --> 25:16.110 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:16.110 --> 25:21.990 And what it does is that it requests a certain Winsock version, and requests certain capabilities. 25:22.030 --> 25:30.250 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:30.310 --> 25:36.470 However, these programmers are unaware that this essentially would call the WSP startup, which is our code. 25:36.470 --> 25:44.130 So, in RLSP, what we're gonna do is essentially implement a WSP startup, which will have our very own code in there. 25:44.130 --> 25:51.170 Now, looking at WSP startup, you can see that it has five parameters, as opposed to WSA, which has, of course, fewer parameters. 25:51.230 --> 25:56.670 The parameters of interest here are specifically the three last ones. 25:56.670 --> 26:04.570 We have the in-parameter LP protocol info, which states what type of functionality the application expects. 26:04.570 --> 26:10.490 Namely, are we expected to perform TCP, or UDP, or any type of other service. 26:10.490 --> 26:24.590 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, uh, functions. 26:24.870 --> 26:28.610 And these functions are the, uh, already installed providers. 26:28.610 --> 26:42.470 So that means that if I wanna 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:42.470 --> 26:44.650 And the example will demonstrate that shortly. 26:44.730 --> 26:49.150 Finally, we have the only out parameter here of interest, the other one's really not interesting. 26:49.150 --> 26:52.390 The LP WSP data is really not interesting. 26:52.390 --> 26:59.750 But the LP proc table here is our procedure call table, and that is essentially a pointer to all our functions. 26:59.750 --> 27:17.570 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:17.570 --> 27:20.430 your, uh, rather, sorry, procedures would be called. 27:20.430 --> 27:36.130 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, uh, a kernel module inside, uh, inside the Linux kernel, for example, or any type of streams interface in Solaris, 27:36.130 --> 27:38.150 which would of course be a lot of hassle. 27:38.150 --> 27:41.410 But when it comes to Windows, all this is pretty much transparent to you. 27:41.430 --> 28:04.030 So, looking over the SPI CPP, which is the main file that has all the functions, let's just go over WSP startups briefly, and you'll see that what Intel and Microsoft do here, this is, uh, again, their demo, is that they simply implement this WSP startup call, 28:04.030 --> 28:21.930 uh, the important thing here would be, after initializing their own internal structure, would be, number one, to save the Winsock2 up call table, that is to say, save the actual implementations that are already out there, because we're gonna need to call them as sort of a pass through, 28:21.930 --> 28:32.090 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:32.510 --> 28:44.710 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:44.710 --> 28:48.650 And so once that's done, you can essentially hook all those calls. 28:48.750 --> 29:04.530 Now, just looking at one of those calls, say for example WSP receive, which would be the counterpart of the, uh, WSA receive and so forth, okay, so looking through that, at some point we'll get there, uh, yeah, okay, there it is. 29:04.850 --> 29:14.090 So, this is the WSP receive function, which is again guaranteed to be called prior to the application actually getting any data. 29:14.090 --> 29:19.050 So, if Google, for example, wants to rewrite the content, this is exactly the function they'll hook. 29:19.050 --> 29:29.770 Now, again, I won't go over the numerous parameters here, the parameters of interest are obviously the socket in question, and a long pointer to the buffers. 29:29.770 --> 29:40.670 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:40.710 --> 30:00.490 And so what I do in my little demo here, is do a fairly simple, uh, function here, which, hold on, which would just go on and write to the debug file that it, it's intercepted a receive, and would simply go over the buffer, it's going over the entire array there, 30:00.490 --> 30:02.430 and simply printing out the buffers. 30:02.430 --> 30:12.390 Now, as far as a demo is concerned, this is really not the type of graphical pyrotechnic demo you'd, uh, imagine, because it also will, will intercept a lot of binary data. 30:12.390 --> 30:18.090 However, it does illustrate the point that the data can be intercepted and can be, of course, modified. 30:18.090 --> 30:30.950 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, you know, put your data, you can, uh, log the data, and so forth. 30:30.950 --> 30:33.130 I, of course, chose just to log the data. 30:33.230 --> 30:39.530 Now, naturally, you, you do the same thing for WSP send, and a host of other functions, but that goes without saying. 30:39.710 --> 30:46.450 So, we have our DLL, and now the next place would be, the next step, sorry, would be to, uh, insert it. 30:46.790 --> 30:52.890 Okay, somehow get Winsock to recognize our service provider as a valid service provider. 30:52.990 --> 31:03.410 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:03.430 --> 31:08.730 However, in order to install it, we have another call, which is a WSP install provider. 31:08.730 --> 31:24.510 This is a fairly simple call, where all you have to do is provide a global unique identifier, which is, of course, um, easy to, uh, just whip up to, for yourself , and you'd set up your own DLL path, and the type of protocols you support. 31:24.510 --> 31:25.850 That's all it takes. 31:25.970 --> 31:32.410 Now, uh, your example should have, actually, I'll go to my source code here, just to demonstrate how simple it is. 31:32.850 --> 31:42.370 So, all you have to do is have a small executable file, like, say, this instLSP, which, again, is, uh, a verbatim copy of the Intel one. 31:42.370 --> 31:47.790 I didn't really do anything here, because this is the same generic code that would work with any service provider. 31:47.930 --> 32:00.090 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, I populate a lot of stuff. 32:00.090 --> 32:05.970 You'll also notice, uh, a nice little flag here called PFL hidden, which is this flag right here. 32:05.970 --> 32:14.070 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:14.350 --> 32:18.970 Which, you know, I don't really get the actual intended use of that, but whatever. 32:18.970 --> 32:24.990 Now, there's also another, there's also another interesting, uh, copy here, which is, uh, security scheme. 32:25.150 --> 32:32.510 Which enables you to have your own type of security for your provider, blah, blah, blah, most of the time you just do protocol none. 32:32.510 --> 32:49.830 So, essentially, I populate this provider, and I, of course, register it as a protocol provider for TCP, and once that's done, is, uh, all I have to do is just call this WSP, sorry, WC install provider, and provide the name of LSP DLL. 32:49.830 --> 32:58.170 This is assumed to be a Windows system, which would be a problem if you're not an admin, but then again, you're gonna have to be an admin to run this anyway. 32:58.170 --> 33:01.970 But you can also specify a full path here if you really want to. 33:01.970 --> 33:12.350 And so, I load the protocol info through the pointer, and once that's done, I, I pretty much guaranteed that my, uh, provider will be installed there. 33:12.350 --> 33:17.710 Now, let's go ahead and try and install that provider, and see exactly what happens. 33:17.710 --> 33:23.310 Now, you'll notice that I already, uh, took the liberty of placing that little DLL here. 33:23.310 --> 33:26.310 That DLL is as compact as 81K. 33:26.310 --> 33:28.410 Actually, it's 80K or so. 33:28.430 --> 33:36.250 And, uh, 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:36.250 --> 33:39.130 Now, before I do that, I want to fire up RegMon. 33:39.370 --> 33:47.670 RegMon is a tool by Sysinternals, which I'm sure most of you know, and that enables us to, uh, hook all types of registry calls. 33:47.830 --> 33:57.170 And the important thing here is that all the, this type of functionality of installing providers, or deinstalling providers, is essentially all registry based. 33:57.170 --> 34:09.590 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:09.590 --> 34:17.150 So, what I'm going to do now is I'm going to launch RegMon, and naturally all is silent, because my process hasn't started yet. 34:17.150 --> 34:28.330 And now I'm going to run this inst LSP, 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:28.470 --> 34:36.410 Now, again, since, since this is a rather crude demo, I didn't really go to any, you know, uh, pains of just looking for the right providers. 34:36.410 --> 34:39.210 I just said, go ahead and install it over all the providers. 34:39.210 --> 34:43.770 But it's fairly simple to just decide that you want a very specific provider. 34:43.790 --> 34:59.450 Now, you can also see that there's a lot of registry action here, and specifically, all the registry action is focused on one specific branch, which is HKEY-LOCAL-MACHINE-SYSTEM, CURRENT-CONTROL-SET-SERVICES, and WINSOC2. 34:59.530 --> 35:15.310 So, firing up RegEdit, just to see what it's like there, you'll see, and it's a 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:15.310 --> 35:17.530 Now, again, Microsoft is inconsistent. 35:17.790 --> 35:23.270 They don't really call things by the same name all the time, but that's, you know, beside the point here. 35:23.270 --> 35:37.590 So, under the namespaces, you have all types of catalog entries, 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:37.710 --> 35:54.350 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:54.350 --> 35:56.310 you'll actually see makes a lot of sense. 35:56.310 --> 36:02.950 This is a protocol info structure that has been overlaying into the registry as raw binary data. 36:03.050 --> 36:15.330 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 mine is hooking. 36:15.590 --> 36:28.270 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:28.350 --> 36:29.850 Any questions thus far? 36:30.510 --> 36:31.090 Yeah? 36:44.530 --> 36:45.550 Mm-hmm. 36:48.430 --> 36:54.250 Well, no, that would go with the namespace provider with the TCPIP one, which I'm not really discussing how to hook that. 36:54.510 --> 37:09.450 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.1, because it's in your host file, but then the application would get that first. 37:09.510 --> 37:22.490 So you'd be able to actually rewrite 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:22.510 --> 37:33.810 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, to get the connect. 37:33.810 --> 37:42.690 You'd be able to hook the connect call, and see a connect to 127.0.1, to whatever port Google is using, and, of course, redirect it. 37:42.690 --> 37:49.670 So simply, you know, simply providing your workaround wouldn't really work, because this functionality is actually stronger than that. 37:49.790 --> 37:51.170 Any other questions? 37:51.490 --> 37:52.910 Yeah, back there. 37:55.730 --> 37:57.030 Say what? 37:58.370 --> 37:59.550 Oh, you can't. 37:59.550 --> 38:03.750 The beauty of it, okay, so the question is, say I want to put in my own provider. 38:03.750 --> 38:06.290 How can I ensure that my provider is the topmost? 38:06.290 --> 38:09.110 Uh, in, you know, in two words, you can't. 38:09.170 --> 38:17.650 Because any provider that gets installed after you, can pretty much re-route, re-write, sorry, the, the stack as they see fit. 38:17.650 --> 38:30.910 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:31.070 --> 38:35.110 So that's, of course, you know, good news or bad news, depending on your perspective here. 38:37.130 --> 38:46.890 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:46.950 --> 38:59.190 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. 38:59.190 --> 39:04.190 You cannot decide you want to be the topmost protocol in the chain, and that's it. 39:04.190 --> 39:11.530 Further, when any other protocol gets bumped in, you wouldn't know, you have no indication whatsoever as to your position. 39:13.430 --> 39:19.810 Yeah, you'd still be, well, again, okay, so, right, okay, so the question is, would I still be hooked? 39:19.810 --> 39:25.850 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:25.970 --> 39:27.210 I don't mind the fish. 39:27.430 --> 39:41.590 So I'll have, 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:41.590 --> 39:51.890 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:02.260 --> 40:04.900 You can change the providers at any time, okay? 40:04.900 --> 40:23.720 Using the provider order, the WSPRite provider and so forth, you can pretty much redo the whole ordering as you wish, because all it, essentially all it changes is some internal structure in Winsock, so... Oh yeah, of course, of course, but then again, 40:23.720 --> 40:32.880 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:32.900 --> 40:38.820 So, assuming whoever gets on top of me does forward the call further, yes, I will be called. 40:38.820 --> 40:49.580 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:51.380 --> 40:56.640 Yeah, the order is in the registry, and of course, in enum protocols would work as well. 40:56.640 --> 41:00.860 You could enum the protocol so as to get it in a nice little array, but the order is right here. 41:01.080 --> 41:08.900 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. 41:13.160 --> 41:21.660 The route by sysinternals, I'm not familiar with the specific one, but I can tell you that a lot of other route kit detectors don't really go that far. 41:21.660 --> 41:24.120 Now it's important to just define the terms here. 41:24.180 --> 41:27.220 This is perfect user mode action. 41:27.220 --> 41:34.660 This is not a route kit in the sense of like a, a kernel mode route kit, because that would be hijacking TCPIP.sys itself. 41:34.660 --> 41:38.220 And that, you know, that, that, there's nothing that can be done against that. 41:38.220 --> 41:49.360 But the beauty of it is that this is full user mode, and in that sense it's a lot easier, and 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:49.360 --> 41:55.580 Okay, so since I'm getting the noose, I'll just run a few applications here. 41:55.720 --> 41:59.600 So let's just start, you know, let's just run Firefox and a bunch of others. 41:59.600 --> 42:07.300 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:07.480 --> 42:13.440 So Firefox is running, and this is the Mozilla start page, and I can do all sorts of, you know, other whatever. 42:14.380 --> 42:19.460 And see, I can get any types of pages I want, and everything is really nice and dandy. 42:19.480 --> 42:26.160 But behind the scenes, I have this little, uh, sock debug 1148. 42:26.300 --> 42:32.440 And of course I could also fire up my messenger, or my Yahoo, or whatever, and I'll do that just briefly here. 42:32.640 --> 42:37.500 Uh, so as, as I fire up Yahoo, I should be getting the message box sometime soon. 42:37.760 --> 42:40.360 Uh, yeah, just, you know, Yahoo's a bit slow. 42:40.360 --> 42:40.660 Okay? 42:40.660 --> 42:51.540 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:51.580 --> 42:52.340 Okay? 42:52.340 --> 42:55.560 And so, this is connecting and everything is cool and nice. 42:55.560 --> 43:03.780 You can also see that it's hooking another call, and, uh, whatever, they'll just let it run, and, you know, ditto for messenger. 43:03.780 --> 43:11.160 So if I'll just run here, run messenger, uh, yeah, whatever, yeah, yeah, you can, okay, whatever. 43:11.160 --> 43:13.080 That's a student of mine, disregard that. 43:13.100 --> 43:13.660 Okay? 43:13.680 --> 43:20.020 So, uh, again, so I can run that with messenger and so forth, and all these SOG debug files are right here. 43:20.020 --> 43:30.740 So let's just go over the 1148 one, and you'll be able to see that, again, this is very crude, so I get a lot of seemingly junk looking data. 43:30.740 --> 43:40.480 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:40.560 --> 43:45.580 If I scroll down, I should be able to see some HTTP requests right here. 43:45.680 --> 43:45.960 Okay? 43:45.960 --> 43:52.080 So this is the get of header tab dot gif, and naturally, you get all types of this, this for example is a PNG. 43:52.100 --> 43:54.680 You can pretty much see the header here, that's a dead giveaway. 43:54.880 --> 44:00.120 Uh, as well as a bunch of others, et cetera, et cetera, the HTTP replies and so forth. 44:00.120 --> 44:02.200 Now again, I want to emphasize one thing. 44:02.200 --> 44:06.720 This, again as a demo, is not as half as fancy as it can be. 44:06.860 --> 44:14.780 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:14.860 --> 44:20.120 Now another disclaimer here, is that HTTPS type connections are unaffected by that. 44:20.120 --> 44:24.060 Fortunately, there are other ways to hook HTTPS, which are beyond my scope here. 44:24.060 --> 44:27.460 But, I'm just saying that if you do use HTTPS, you're fine. 44:27.460 --> 44:35.460 However, when it comes to all types of other functionality, messenger, um, email, whatever, everything is pretty much in the clear. 44:35.560 --> 44:36.340 Okay? 44:36.400 --> 44:37.840 Any questions? 44:38.500 --> 44:39.280 Yeah. 44:41.600 --> 44:47.060 Yeah, with NetBT you can, although it's, well, again, let's define NetBT. 44:47.060 --> 44:55.220 If the process that runs the NetBT request has launched after you have put in your provider, then yes, you can. 44:55.220 --> 44:59.580 And if you get your provider into the Windows startup, then yes, you can. 44:59.800 --> 45:00.260 Okay? 45:00.260 --> 45:02.860 However, some functionality you still won't get. 45:02.860 --> 45:08.980 Namely the, uh, the Winsock bypass functionality, that sometimes the server service does. 45:08.980 --> 45:09.200 Okay? 45:09.200 --> 45:13.960 In order to, to gain efficiency, it doesn't go through a user mode DLL, because it doesn't make sense, you know? 45:13.960 --> 45:14.500 Okay? 45:14.500 --> 45:18.320 So, you can hijack some of the functionality, although not all. 45:18.600 --> 45:19.820 Any other questions? 45:19.820 --> 45:20.400 Yeah. 45:22.600 --> 45:23.500 Uh, no. 45:23.500 --> 45:26.340 Zone alarm, actually, as far as I know, go into the TDI. 45:26.340 --> 45:27.880 This is what McAfee does, though. 45:27.920 --> 45:31.500 McAfee, the personal firewall, uh, does do, uh, they do do that. 45:31.500 --> 45:47.160 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.060 --> 45:49.300 Any further questions? 45:49.300 --> 45:51.940 Because I'm getting the, sort of like Neustein. 45:51.940 --> 45:52.860 So, yeah. 45:52.860 --> 45:53.800 Right there. 46:02.910 --> 46:11.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:11.230 --> 46:16.250 And yes, it would be encrypted, because I'm essentially getting it as it came on the network. 46:16.250 --> 46:22.770 So, this enables you to play middleman, but only middleman, you know, post SSL, or post encryption. 46:22.770 --> 46:29.190 Which is, as I've stated, the proper workaround, the proper mitigation to that, would be to always use SSL and so forth. 46:29.190 --> 46:39.590 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-sniff type man in the middle, which would work here. 46:39.710 --> 46:40.230 Okay? 46:40.230 --> 46:43.970 So, just to conclude, before I'm, uh, kicked out violently. 46:44.410 --> 46:44.830 Okay? 46:44.830 --> 46:46.210 So, that was the demo. 46:46.210 --> 46:56.530 The lesson to be learned, 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:56.530 --> 47:06.930 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:06.950 --> 47:12.730 Now, it's also important to emphasize that this was originally intended for good uses. 47:12.730 --> 47:17.310 Namely, implementing an application type firewall, application layer firewall. 47:17.310 --> 47:22.510 We mentioned McAfee, and, of course, we saw where that got. 47:22.690 --> 47:24.830 Um, transparently add encryption. 47:24.830 --> 47:27.090 This was well before the days of IPsec. 47:27.090 --> 47:31.630 We're talking about 98, before IPsec was a fully robust protocol, as it is now. 47:31.630 --> 47:35.270 And nowadays, IPsec is handled, of course, in the kernel level. 47:35.350 --> 47:37.270 Uh, enforce quality of service. 47:37.270 --> 47:38.490 Yeah, right. 47:38.630 --> 47:40.550 Uh, support new protocols. 47:40.550 --> 47:42.910 This is also another nifty functionality. 47:42.910 --> 47:47.070 You can essentially support IPv6 by it, although it's supported already. 47:47.070 --> 47:52.870 You can support IPv9, you can support pretty much any other custom protocol over a raw socket. 47:52.970 --> 47:57.990 And patch content on the fly, which, like I said, Google Desktop actually do. 47:57.990 --> 48:02.350 Whether it's a legitimate use or an illegitimate use remains to be seen. 48:02.570 --> 48:09.030 However, the much better chaotic uses would be to patch content on the fly in the illegitimate sense. 48:09.030 --> 48:16.930 And again, we're talking about rewriting webpages, rewriting IMs, uh, doing a lot of other nifty stuff, which I will not disclose here. 48:17.030 --> 48:20.410 Um, obtain connection statistics, URLs, etc, etc. 48:20.410 --> 48:22.890 Most of the spyware applications do exactly that. 48:22.890 --> 48:25.790 They put themselves in so as to gather your statistics. 48:25.790 --> 48:28.410 This was what the CASA spyware did. 48:28.650 --> 48:32.370 Eavesdropping on any type of connection, but again, non-SSL ones. 48:32.730 --> 48:38.470 And, uh, rerouting connections, that is just hijacking the sockets, which is really an amazing thing. 48:38.470 --> 48:42.350 Because an application opens a socket and calls connect. 48:42.790 --> 48:48.310 And once it does that, then, you know, the worst that can happen it'll, it's gonna call get peer adder. 48:48.310 --> 48:51.470 But you can reroute connect and you can also reroute get peer adder. 48:51.470 --> 49:02.470 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:02.610 --> 49:07.170 So, uh, all that in mind, the demo, like I said, is part of the platform SDK. 49:07.310 --> 49:20.390 Uh, you're welcome to drop a line to, uh, this address right here 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:20.390 --> 49:22.170 Any further questions? 49:23.510 --> 49:24.990 Okay, peace.