[00:02.460 --> 00:11.980] Hi everyone, thanks for attending. My name is Jonathan and the topic of my talk is going to be [00:11.980 --> 00:16.980] about the dark side of Winsock, which is essentially all the under-the-hood functionality that you [00:16.980 --> 00:23.340] have inside Winsock, inside the Windows TCPIP stack, which unfortunately, even though it's [00:23.340 --> 00:30.000] there and it's publicly available, it is somewhat undocumented and the only people to really [00:30.000 --> 00:35.900] use it are the bad guys, namely people who want to do rootkits, who want to do spyware, etc. [00:36.500 --> 00:43.600] Now I find myself somewhat inclined to start with a preamble here. This is not some type of [00:43.600 --> 00:49.560] vulnerability issue or not some type of any zero-day exploit, so if any of you are expecting [00:49.560 --> 00:54.420] that, it's probably not the right place to be. What this is, however, is a discussion on [00:54.420 --> 01:01.580] functionality, which, like I said, is in there and is mostly... well, mostly the only really [01:01.580 --> 01:06.740] good uses, as you'll see, are the insidious ones, namely the ones that aren't really designed [01:06.740 --> 01:14.140] to happen. Things such as usurping connections, rerouting connections, connection monitoring, [01:14.140 --> 01:21.760] etc, etc. Now it is assumed that you guys have had some experience with Winsock before. [01:21.760 --> 01:29.480] How many of you have actually coded in Windows for Winsock? Okay, well, okay, so as I was, [01:29.480 --> 01:33.520] you know, I kind of suspected that, so we'll start with a brief intro that kind of has the [01:33.520 --> 01:37.960] nomenclature and kind of has like the basic terminology, so those of you who are fairly new [01:37.960 --> 01:43.460] to this will be able to sort of like keep afloat, and then we'll get into the code. Now the [01:43.460 --> 01:47.700] code itself that I'll be demonstrating is all fully annotated, you've got that on the CD. [01:47.700 --> 01:55.020] On the CD you have a PDF of my talk, which, contrary to other PDFs, it's not just the slides, [01:55.020 --> 01:59.620] it's also the notes pages, so you'll be able to have the full source code, everything is there. [01:59.900 --> 02:05.760] Furthermore, my demo, which I'm going to run shortly, is based on a public demo, which is [02:05.760 --> 02:10.860] Intel's and Microsoft's code, so it's like fully open source and nothing too new there. [02:11.160 --> 02:16.340] So, we start with the introduction, and some of you may already know this, and I'm actually [02:16.340 --> 02:21.840] 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:34.460] Sockets were something that essentially are meant to abstract sort of like what you'd have [02:34.460 --> 02:38.720] with file descriptors, only in this case it would be network descriptors. The idea is fairly [02:38.720 --> 02:44.120] simple, the application would open a socket and would just send and receive data as it would [02:44.120 --> 02:49.100] with any other file descriptor. This could be using receive, send calls, etc, etc. And there [02:49.100 --> 02:55.300] you'd also have some other APIs, which are essentially get peer and get adder info and so [02:55.300 --> 03:00.700] forth, which are meant to be socket specific and to enhance these descriptors so as to [03:00.700 --> 03:06.720] accommodate all types of TCP and UDP based needs. Now, the application itself is somewhat [03:06.720 --> 03:11.280] agnostic in the sense that for it, it's just another file descriptor. Those of you who may [03:11.280 --> 03:15.880] have some Unix background know that sockets and file descriptors in Unix are one and the same [03:15.880 --> 03:20.580] pretty much. So you can, you know, you have the very same API. In Windows, what happens is [03:20.580 --> 03:25.900] that you have the Winsock, which I'll be describing shortly, which takes the sockets just a [03:25.900 --> 03:30.140] bit further and gets you a lot of added functionality. Now the important thing to [03:30.140 --> 03:35.020] emphasize is that the application would read and write just with any other file descriptor, [03:35.020 --> 03:40.040] so what would happen essentially is that all the fragmentation, encapsulation, and getting [03:40.040 --> 03:44.440] the IP header and the TCP header or UDP, whatever it is, is basically handled [03:44.440 --> 03:48.520] transparently by the OS, which is really good news for a lot of application developers [03:48.520 --> 03:54.880] because they just work transparently and just don't care about whatever IP issues or TCP [03:54.880 --> 03:59.400] and so forth issues that might arise. Now what I'm going to demonstrate to you works with [03:59.400 --> 04:05.680] pretty much all sockets of all types. It works with TCP, UDP, raw sockets as well, in [04:05.680 --> 04:10.220] case Microsoft hasn't crippled them completely in service pack 2, and also IPv6 [04:10.220 --> 04:15.800] sockets, which is really nifty. Now, the way it works is that Microsoft took the BSD [04:15.800 --> 04:21.660] model, which is your average libc type socket with all the rich API, and adapted it into [04:21.660 --> 04:26.720] something known as Winsock, which is basically Windows sockets. This went through several [04:26.720 --> 04:32.100] versions and revisions. We started with Winsock 1.x, which you're not going to see anyway [04:32.100 --> 04:37.780] because it's mostly like for Windows 3.11 and so forth. And Winsock 2 is basically your [04:38.300 --> 04:44.660] baseline today. That is to say it's present in Windows NT, it's present in Windows 2K, [04:44.660 --> 04:52.600] 2003, etc. And of course your XP. Now the major important issue with Winsock is that the [04:52.600 --> 04:57.720] migration from 1.x to 2.x added a host of new features. We're not going to be discussing [04:57.720 --> 05:02.400] those new features in length, but some of you may know that it provides for asynchronous [05:02.400 --> 05:07.540] calls and various function callbacks, which is really good if you're working in a multi-threaded [05:07.540 --> 05:13.500] environment and so forth. It works with overlapped IO, namely getting more than one process to [05:13.500 --> 05:19.260] listen on the same socket. And, this is going to be the topic of our talk here, it provides [05:19.260 --> 05:24.720] something known as an LSP architecture, which is the layered service provider. This is going [05:24.720 --> 05:30.580] to be a very key and instrumental term for us, as this is essentially the core of the talk. [05:30.580 --> 05:38.760] This service provider interface is essentially giving you the architecture to hook any Winsock [05:38.760 --> 05:44.500] call by any process, aside from certain system processes which bypass Winsock, we'll get [05:44.500 --> 05:49.840] into that in a second. But essentially any Winsock functionality you wish, it can be [05:49.840 --> 05:55.720] anything from get host by name, through of course sending and receiving in sockets and so [05:55.720 --> 06:00.800] forth, everything is pretty much hijackable, in the sense that this is pretty much the [06:00.800 --> 06:06.420] equivalent of set windows hook, that you'd have for general Windows API functions, only [06:06.420 --> 06:12.260] specific for the Windows platforms. Now this is really, really useful, and we're going to be [06:12.260 --> 06:16.720] talking about some of the legitimate uses, which as you'll see, there are quite a few [06:16.720 --> 06:22.680] legitimate uses, however we'll also see that the really important uses are those that are, so [06:22.680 --> 06:28.040] to speak, less useful for the good guys, and mostly sort of like the covert or the black hat [06:28.040 --> 06:33.340] oriented uses. Now it's also important to say that, like I said, this has been out there for [06:33.340 --> 06:40.140] about 7 years now pretty much, my first encounter with that was like 1998 or so, and it's [06:40.140 --> 06:45.100] really frightening to see that all this functionality is there, it's under the hood, so [06:45.100 --> 06:50.880] your applications are fully agnostic, they have no idea that this functionality is there, and [06:50.880 --> 06:55.960] yet spyware developers and other such application developers can pretty much inject [06:55.960 --> 07:01.760] whatever functionality they want, and the application is none the wiser. So, getting into [07:01.760 --> 07:06.720] detail here, this little illustration here shows you pretty much what the Windows [07:06.720 --> 07:11.680] networking architecture is all about. Some of you may find this a bit familiar, for those of [07:11.680 --> 07:17.240] you who aren't, I'll just run a brief sort of like, uh, review of this. So, looking at this [07:17.240 --> 07:22.340] from several levels of abstraction here, oops, wait a sec, that's Microsoft PowerPoint [07:22.340 --> 07:27.660] running wild on me. So, looking at this from several layers of abstraction, we can see the [07:27.660 --> 07:33.300] hardware down below. Now, no matter what hardware type you're using, whether you're using a [07:33.300 --> 07:38.960] wireless network, or a wired ethernet, or even a modem, pretty much all your Windsock [07:38.960 --> 07:43.940] calls will eventually be rerouted over the hardware in a sort of, uh, device independent [07:43.940 --> 07:49.920] manner. The miracle that does this is something called the Ndisk driver, which is the network [07:49.920 --> 07:54.880] driver interface specification. That's sort of like an abstract driver for any type of [07:54.880 --> 08:00.080] interface, uh, in Unix terms, some of you may be, uh, aware of the ifconfig and the interface [08:00.080 --> 08:05.320] configuration, so it's pretty much a port of the same idea in Windows terms. And the [08:05.320 --> 08:10.120] Ndisk is essentially an abstract driver that works with pretty much all types of [08:10.120 --> 08:15.980] communication, uh, devices. These can be modems, these can be, uh, ethernet cards, et cetera, [08:15.980 --> 08:21.180] et cetera. Following that, we have the TDI, which is a transport driver interface. That [08:21.180 --> 08:26.100] acts somewhat of a, uh, somewhat like a bridge, in the sense that you have calls from user [08:26.100 --> 08:32.220] space going into kernel space through this TDI layer. Now, in user space, you mostly have [08:32.220 --> 08:38.880] either Winsock2, for 99% of the applications, or something known as NetBT, which is the [08:38.880 --> 08:43.360] NetBios over TCPIP transport. Some of you who might be familiar with the backslash, [08:43.360 --> 08:48.840] backslash server, the SMB or CIFS notation, that's pretty much it. So, aside from the [08:48.840 --> 08:53.860] workstation and server service, which are core components of Windows, pretty much any [08:53.860 --> 08:58.000] other application would go through Winsock. And that's, that of course is what makes this [08:58.000 --> 09:02.860] all the more attractive to us. Now, as the applications go through Winsock, they are [09:02.860 --> 09:07.620] pretty much, uh, you know, they all work over the same API, which is the application [09:07.620 --> 09:14.000] programming interface. And that is the API that you link with Winsock, or WS2 underscore [09:14.000 --> 09:19.520] 32 dot DLL, and it gets you the functionality of the send, receive, and as well as a host [09:19.520 --> 09:26.900] of WSA calls. Namely, uh, WSA async select and others, to name a few. Okay, so, you have [09:26.900 --> 09:32.680] all types of, uh, applications. They can be your browser, your FTP, naturally your IMs, [09:32.680 --> 09:38.280] probably go over that as well, uh, IRC, et cetera, et cetera. Now, this is sort of like the [09:38.280 --> 09:44.200] application type view that most programmers are familiar with. However, as it turns out, [09:44.200 --> 09:49.900] this is only half the picture. So if, as, if we try and look deeper, we see that we have [09:49.900 --> 09:56.000] this Winsock API layer, which is, again, the top interface, but we also see that we have a [09:56.000 --> 10:02.120] Winsock SPI layer, which is a bottom interface that is meant for what Microsoft defines as [10:02.120 --> 10:07.760] service providers. Now, the term service provider, like I said, is a key term here, because [10:07.760 --> 10:13.260] service providers are essentially either hardware types, namely, uh, you know, your network [10:13.260 --> 10:18.920] cards, et cetera, et cetera, or they could be software types, as in software type drivers, [10:18.920 --> 10:23.640] which are mostly user mode drivers. Now, this is really important since it gives you the [10:23.640 --> 10:29.840] full functionality of packet inspection and whatever you want, but at the socket level. So [10:29.840 --> 10:34.340] essentially, from an OSI model perspective, we're working at layer five, which is really [10:34.340 --> 10:39.140] quite the improvement over other types of, uh, sniffers and rootkits, which generally [10:39.140 --> 10:44.460] operate at a lower level and thus confine you to a packet view. So here you can actually [10:44.460 --> 10:49.920] hijack a socket and not really wonder as to whatever the breakdown of the packets is, [10:49.920 --> 10:54.500] because it doesn't really matter. Now, uh, essentially these providers are one of two [10:54.500 --> 11:00.420] classes. You have the transport providers, which, as the name would imply, work with the [11:00.420 --> 11:05.920] data transport itself, namely the TCP and UDP transfers, et cetera. And you have the [11:05.920 --> 11:11.760] namespace providers, which work with all the, you know, get host by name, et cetera. Namely, [11:11.760 --> 11:17.260] if you want to look up any type of address, that address can be a NetBIOS name, it can be [11:17.260 --> 11:22.360] an SMB name, a CIFS name, et cetera. And this would imply, of course, that you need a [11:22.360 --> 11:26.480] mechanism to abstract that. And this is exactly what the namespace providers are all [11:26.480 --> 11:31.180] about. I'm gonna focus on the transport providers because they are, of course, the, the [11:31.180 --> 11:36.140] sexier ones, in the sense that they actually get you to see some real data. Now, as the [11:36.140 --> 11:41.740] illustration also shows, all the providers would share the same API, the same top API, [11:41.740 --> 11:46.240] which is what I see here, what I mark here, as a transport SPI, that is the transport [11:46.240 --> 11:50.960] service provider interface. So whatever provider you're using, essentially all these [11:50.960 --> 11:57.780] providers must work pretty much the same way. Now, Winsock, uh, providers cannot normally [11:57.780 --> 12:02.400] be listed by applications, or at least they can be, but only if the application is actually [12:02.400 --> 12:07.760] aware of it. Microsoft has, as part of the platform SDK, which is part of the Visual Studio [12:07.760 --> 12:14.140] Distributions, uh, they have something known as an SPOrder.exe, uh, which is a small [12:14.140 --> 12:20.400] executable, meant to show you the service provider, um, order, of course, and also it [12:20.400 --> 12:27.460] comes with a small DLL called SPOrder.dll. SPOrder.dll is a DLL we'll, we'll discuss [12:27.460 --> 12:32.780] shortly, it actually has the ability to not only show you the service providers, but [12:32.780 --> 12:37.700] actually shuffle them around as you see fit. And this type of shuffling around is exactly [12:37.700 --> 12:42.440] the hooking functionality. So going on to see a slight demo of what the service [12:42.440 --> 12:58.630] providers are like. Okay, so, autocomplete is not cooperating. So you have the SPOrder.exe [12:58.630 --> 13:04.270] which shows you all the available service providers here. Now, my display is, um, [13:04.270 --> 13:09.210] particularly cluttered due to the fact that I have VMware here, which, uh, is pretty much [13:09.210 --> 13:13.950] all those global unique identifiers that you can see here, as well as another VPN solution [13:13.950 --> 13:20.130] which opens up a, a, a, sort of like a virtual interface. But the core providers that you're [13:20.130 --> 13:25.370] likely to see are the ones you see here. There's one for the infrared, which is IRDA, there's [13:25.370 --> 13:33.230] one for basic TCPIP, there's one for UDPIP, there's one for raw sockets, and there's, uh, [13:33.230 --> 13:39.390] two of them for RSVP. RSVP is a quality of service protocol which is generally supported [13:39.390 --> 13:45.450] but never really used by Windows. Now going into one of these, you can see that they [13:45.450 --> 13:51.470] essentially give you the complete information on the service provider, namely which DLL is [13:51.470 --> 13:56.690] actually the one that provides the functionality, as well as a bunch of service flags, provider [13:56.690 --> 14:02.110] ID, which is a global unique identifier, et cetera, et cetera. The important stuff here that [14:02.110 --> 14:07.190] some of you programmers might recognize are the address family, the hex value 2, meaning [14:07.190 --> 14:14.170] AFINET, uh, there's also the socket type, which is SOCKSTREAM, and there's a protocol number [14:14.170 --> 14:22.190] which is 6, 6 of course for TCP. And naturally you'd have 17 or hex 11 for UDP. And so the way [14:22.190 --> 14:28.410] that works is that any time an application would request a type of socket to be created, [14:28.410 --> 14:34.490] which would be a SOCKSTREAM, rather an AFINET, SOCKSTREAM, and a TCP essentially, a TCP [14:34.490 --> 14:40.970] socket, what would happen here is that this call would be redirected over to MSWSOCK.DLL, [14:40.970 --> 14:47.690] where WINSOCK, or the WS232 DLL, is actually acting like a multiplexer. That is to say that [14:47.690 --> 14:53.530] it is one main interface under which you can have all types of various providers. Now again, [14:53.530 --> 14:58.430] this would normally be the case with your average Windows, and the more interfaces you have [14:58.430 --> 15:03.030] and the more applications you have, the more of those providers you're likely to see. As for [15:03.030 --> 15:08.750] the name resolution providers, these are the namespace providers. You have your basic TCPIP, [15:08.750 --> 15:14.530] which is an interface to the DNS client service. You have NTDS, which is of course Active [15:14.530 --> 15:19.730] Directory. And you have Network Location Awareness, which is something that again, [15:19.730 --> 15:26.270] Microsoft supports but never really works. So you have all those. And now comes the [15:26.270 --> 15:32.150] important part. The important part is that you can have over these service providers, you can [15:32.150 --> 15:38.530] have a functionality that enables you to chain your own providers. That is to say, not just [15:38.530 --> 15:43.030] add a provider, and by doing so you're going to have to essentially make the application [15:43.030 --> 15:48.030] aware of that provider, but you can pretty much hook your providers and install something [15:48.030 --> 15:54.570] known as a provider chain, which is really an amazing idea. Now the original plan behind [15:54.570 --> 16:01.190] that was to support all types of NICE uses. NICE such as transparent encryption, such as [16:01.190 --> 16:06.410] quality of service, etc, etc. But the way that works is that most applications don't really [16:06.410 --> 16:12.850] use that functionality, and so it's just left there, but not really used in everyday terms. [16:12.850 --> 16:18.750] Now, the beauty of it is that you can chain any number of providers, and you can chain them [16:18.750 --> 16:24.170] in pretty much any order you want. That is to say that if you want to provide some [16:24.730 --> 16:30.510] encryption functionality, for example, or reroute everything, all types of data [16:30.510 --> 16:35.370] transparently over SSL or SSH or whatever other tunnel you want, you can pretty much [16:35.370 --> 16:41.270] install your provider, and then bump it to the top of the stack. So any other application [16:41.270 --> 16:46.690] using the stack would essentially get directed to your provider first, and your provider [16:46.690 --> 16:51.730] would do whatever, and then follow down the chain, essentially progressing the API calls [16:51.730 --> 17:00.490] down the chain. Any questions thus far? Okay. So, the way it works is that your Winsock, [17:00.510 --> 17:07.350] the DLL itself, has several functions which are exported. I'm going to try this, the [17:07.350 --> 17:13.630] dump-in demo, a bit clearer here, so you'll be able to see the font back there. So, just [17:13.630 --> 17:25.860] looking through that... Okay, so what I'm doing now is I'm setting up the Visual Studio [17:25.860 --> 17:31.260] command line environment, so I can show you the dump-in command. And the way dump-in works [17:31.260 --> 17:36.360] is, as some of you may know, it gives you the DLL and shows you all the exported functions [17:36.360 --> 17:40.120] or the imported functions and so forth. So what I'm going to do now is essentially look [17:40.120 --> 17:47.240] for an exported function list of Winsock and focus on the specific service provider interface. [17:47.240 --> 17:57.780] To do that, what we'll do is just do dump-in slash exports, get the name of the WS232, [17:57.780 --> 18:06.340] and since essentially Winsock exports on average about a hundred and something functions, I'm [18:06.340 --> 18:12.060] going to isolate only those important ones for our discussion. So, looking at that, you can [18:12.060 --> 18:18.240] see that you have these particular WSC functions. Now again, those of you who might be working [18:18.240 --> 18:23.400] with Winsock on a daily basis know that Winsock usually exports the WSAs, which is for the [18:23.400 --> 18:29.240] Winsock API. The WSCs you see here are essentially all about the service provider interface and [18:29.240 --> 18:35.020] so forth. Now, the, the, probably there's too many functions here to actually go over, but [18:35.020 --> 18:40.780] the ones of interest are essentially install provider and deinstall provider, which enables [18:40.780 --> 18:48.480] you to, of course, set your own LSP or remove your LSP, as well as install namespace, and for some [18:48.480 --> 18:54.960] weird reason, it's uninstall namespace, hinting that maybe this API was not really meant to be [18:54.960 --> 18:59.740] used, because it's not really standardized in that sense, as in uninstall and not deinstall. [18:59.740 --> 19:05.000] Now, all of these are also fully documented as part of the MSDN, but it's the kind of [19:05.640 --> 19:10.120] MSDN documentation that resides on like the fourth CD that nobody ever gets to, because it's [19:10.120 --> 19:16.880] like so obscure in the back. Okay, now, as it so happens, okay, these functions are readily [19:16.880 --> 19:23.000] exportable, and you can use them to do your own type of work, as I'll show briefly in a [19:23.000 --> 19:30.660] demo. Now, this SP order DLL is an additional DLL that, as I said, works for rewriting the [19:30.660 --> 19:34.580] service provider order. And as the example here shows, this is a dump bin of the SP order [19:34.580 --> 19:40.080] DLL, and you have write namespace provider, sorry, write provider order and write namespace [19:40.080 --> 19:45.200] order, which essentially enable you to shuffle around, as I've stated, and put your provider [19:45.200 --> 19:52.400] just in its right location. Now, a lot of spyware-aware applications, like AdAware and all [19:52.400 --> 19:59.400] types of anti-spyware, essentially look for that DLL, and if that DLL is present on your [19:59.400 --> 20:04.180] operating system, then it's bad news. Then they normally flag it as spyware and so forth. [20:04.180 --> 20:09.860] And probably the best example of that was, uh, Kasa, the file sharing utility that has SP [20:09.860 --> 20:15.880] order dot DLL bundled in. So when you install Kasa, you have this DLL somewhere on your [20:15.880 --> 20:22.820] system. Another, uh, interesting application to use this type of DLL is Google Desktop. I [20:22.820 --> 20:27.220] don't know how many of you use Google Desktop, but Google Desktop has, uh, probably its [20:27.220 --> 20:32.260] niftiest feature is that after you install it, whenever you go into google.com, you [20:32.260 --> 20:37.100] suddenly get your own desktop there. You have, like, the ability to search Google or to [20:37.100 --> 20:40.980] search your own desktop from the very same webpage. Now, obviously, that kind of [20:40.980 --> 20:47.060] functionality would imply that Google has a mechanism in your machine that can intercept [20:47.060 --> 20:53.820] the calls to google.com and re- sort of like rewrite the page content on the fly. And that [20:53.820 --> 20:57.860] is exactly the functionality that I'm describing here. Namely, by installing their own [20:57.860 --> 21:02.860] provider and putting it in your machine, they can, uh, intercept the go- the calls to [21:02.860 --> 21:06.540] Google, but they can, of course, do whatever they want. That is to say that if they're not [21:06.540 --> 21:10.840] really playing by the rules, they can do a lot of other stuff as well with your machine. But [21:10.840 --> 21:14.760] then, I'm happy to see that not too many people use Google Desktop here, because that's [21:14.760 --> 21:21.820] kind of, like, shady. Anyways, so going over that, uh, pro- probably the most interesting [21:21.820 --> 21:29.680] API call would be the WC enum protocols, which would be the API call that one would use as a [21:29.680 --> 21:36.640] setup to install their own provider. This, much like all the other WS, uh, enum functions, [21:36.640 --> 21:42.400] will enable you to sort of, like, go over the protocols that are already in place and [21:42.400 --> 21:47.140] provide for an enumeration of them. An enumeration, in our case, would be a pointer to an [21:47.140 --> 21:53.840] array of protocol infrastructures. Now, uh, you have a fully annotated example on the PDF, uh, [21:53.840 --> 21:58.620] in the PDF, so I won't really go into that. But the idea is fairly simple. Anybody can call [21:58.620 --> 22:04.740] this function and see what service providers are already there. And in many ways, this is [22:04.740 --> 22:09.360] pretty much the only mitigation against this type of attack. However, most applications [22:09.360 --> 22:14.220] don't really use that, and if anything, they would use the counterpart of this call, which [22:14.220 --> 22:20.080] would be the WSA enum protocols. And the difference between the A and the C is that the C [22:20.080 --> 22:25.580] can get all the protocols, whereas the A gets only the top layer ones. So if you're using [22:25.580 --> 22:30.880] yours in a chain, essentially you can remain hidden, which is of course bad news. So, going [22:30.880 --> 22:36.060] over that, we have the enum protocols just to see which protocols are there, and we [22:36.060 --> 22:40.460] naturally want to build our own service provider. Now, building a service provider is [22:40.460 --> 22:44.920] really fun. It's really easy, too. Because as a baseline, you have the Microsoft supply [22:44.920 --> 22:49.740] demo. So, I happen to have this demo right here, and I'm going to work with the actual [22:49.740 --> 22:55.180] Microsoft code. Due to copyright restrictions, I haven't really bundled it or, you know, put [22:55.180 --> 23:00.360] it in a targeasy for you guys to use, but it's fairly simple to just get this code from the [23:00.360 --> 23:05.880] MSDN and just work and do the same modifications that I did right here. So, looking through [23:05.880 --> 23:13.890] that code, let's start... I think the DLL main would be a good point to start. So, launching [23:13.890 --> 23:21.350] Visual Studio just so we can see this type of DLL, then our service provider is just going to [23:21.350 --> 23:25.310] be another DLL. So, essentially it has to follow the very same conventions. That is to say [23:25.310 --> 23:30.530] it has to start with the DLL main, and the DLL main would work as pretty much all DLL [23:30.530 --> 23:36.930] mains work. That is, whenever an application would hook to us and would call us, we would [23:36.930 --> 23:44.070] get the DLL process attached at the DW reason. And so, the way that works is whenever a [23:44.070 --> 23:50.350] process attaches, I add this little addition here, which essentially doesn't do much. What it [23:50.350 --> 23:56.910] does is it just opens up a filename. Okay, it readies a filename here with an S printf, [23:57.490 --> 24:04.210] composed of sockdebug as a prefix, and the current process ID embedded in there. The reason I [24:04.210 --> 24:08.670] do that is because once I'll do that and, of course, run my applications, you'll see that [24:08.670 --> 24:14.070] each application, as it uses Winsock, will generate this type of file on the root of the [24:14.070 --> 24:19.150] C drive. Okay, and what it does here is that it just opens the files and pops a message box, [24:19.150 --> 24:23.850] and you will be able to see that message box. That message box and any type of code that I [24:23.850 --> 24:29.450] run here is run in the context of the calling process. So, while this is a somewhat innocuous [24:29.450 --> 24:33.550] example, and just, you know, only for demonstration purposes, I'll print out a lot of [24:33.550 --> 24:37.950] stuff, if I really wanted to, I could do whatever I wanted here. Essentially, I could load [24:37.950 --> 24:43.910] additional DLLs, as the comment says. I could decide that this particular process should not [24:43.910 --> 24:50.370] access a stack, and so forth. Now, to make matters even easier for the spyware people, this [24:50.370 --> 24:57.150] type of functionality can also be injected in the WSP startup call. The WSP startup, which is [24:57.150 --> 25:03.770] shown right here in the slide. So, WSP startup is essentially the counterpart to WSA startup. [25:03.770 --> 25:09.170] Those of you who may have been working with Windows know that each Windows application, as [25:09.170 --> 25:14.370] it starts, as it launches its Winsock functionality, has to start off by calling this [25:14.370 --> 25:20.270] function, the WSA startup. And what it does is that it requests a certain Winsock version, and [25:20.270 --> 25:25.610] requests certain capabilities. Now, the beauty of it is that, you know, most programmers just [25:25.610 --> 25:30.810] call WSA startup, check the return value, and naturally everything is just okay. However, [25:30.810 --> 25:35.830] these programmers are unaware that this essentially would call the WSP startup, which is our [25:35.830 --> 25:41.630] code. So, in RLSP, what we're gonna do is essentially implement a WSP startup, which will [25:41.630 --> 25:47.130] have our very own code in there. Now, looking at WSP startup, you can see that it has five [25:47.130 --> 25:52.090] parameters, as opposed to WSA, which has, of course, fewer parameters. The parameters of [25:52.090 --> 25:59.450] interest here are specifically the three last ones. We have the in-parameter LP protocol [25:59.450 --> 26:05.490] info, which states what type of functionality the application expects. Namely, are we [26:05.490 --> 26:11.810] expected to perform TCP, or UDP, or any type of other service. We further have something [26:11.810 --> 26:18.370] known as the up-call table, which is by far the most useful parameter here, which will [26:18.370 --> 26:24.890] enable us to have an array of, essentially it's a pointer to an array of, uh, functions. And [26:24.890 --> 26:29.790] these functions are the, uh, already installed providers. So that means that if I wanna [26:29.790 --> 26:34.670] hook, for example, send or receive, I don't really have to think about how I would [26:34.670 --> 26:39.050] implement send or receive, but rather I would implement them my own in sort of like a [26:39.050 --> 26:43.630] stub function, and later on just go on to call the up-call table. And the example will [26:43.630 --> 26:47.730] demonstrate that shortly. Finally, we have the only out parameter here of interest, the [26:47.730 --> 26:52.630] other one's really not interesting. The LP WSP data is really not interesting. But the [26:52.630 --> 26:58.550] LP proc table here is our procedure call table, and that is essentially a pointer to all [26:58.550 --> 27:03.950] our functions. So whatever functions you choose to implement, you can pretty much set [27:03.950 --> 27:11.730] in this big structure there, and just call WSP startup and returning from the call, you [27:11.730 --> 27:16.190] would pretty much produce your procedure table, and you'd be guaranteed that your [27:16.190 --> 27:21.330] applications, your, uh, rather, sorry, procedures would be called. Now those of you who [27:21.330 --> 27:25.670] may have been working in the Unix and Linux environment would know that in order to [27:25.670 --> 27:30.530] achieve that in Linux, you'd pretty much need to have any type of, uh, a kernel module [27:30.530 --> 27:35.670] inside, uh, inside the Linux kernel, for example, or any type of streams interface in [27:35.670 --> 27:39.630] Solaris, which would of course be a lot of hassle. But when it comes to Windows, all this [27:39.630 --> 27:46.090] is pretty much transparent to you. So, looking over the SPI CPP, which is the main [27:46.190 --> 27:54.370] file that has all the functions, let's just go over WSP startups briefly, and you'll see [27:54.370 --> 28:01.170] that what Intel and Microsoft do here, this is, uh, again, their demo, is that they simply [28:01.690 --> 28:07.410] implement this WSP startup call, uh, the important thing here would be, after initializing [28:07.410 --> 28:14.630] their own internal structure, would be, number one, to save the Winsock2 up call table, that [28:14.630 --> 28:19.270] is to say, save the actual implementations that are already out there, because we're gonna [28:19.270 --> 28:24.830] need to call them as sort of a pass through, and once that's done, they do a lot of other [28:24.830 --> 28:31.210] startup code and so forth, and they get to the important portion of populating the procedure [28:31.210 --> 28:36.990] table. So, the procedure table is a structure, and it's as simple as it can get, because [28:36.990 --> 28:41.570] you'd have a structure of function pointers, and all you have to do is just hook your function [28:41.570 --> 28:46.290] pointer to the corresponding functionality that you want. And so once that's done, you [28:46.290 --> 28:51.210] can essentially hook all those calls. Now, just looking at one of those calls, say for [28:51.210 --> 28:58.810] example WSP receive, which would be the counterpart of the, uh, WSA receive and so forth, okay, [28:58.810 --> 29:05.530] so looking through that, at some point we'll get there, uh, yeah, okay, there it is. So, [29:05.530 --> 29:11.710] this is the WSP receive function, which is again guaranteed to be called prior to the [29:11.710 --> 29:16.610] application actually getting any data. So, if Google, for example, wants to rewrite the [29:16.610 --> 29:21.310] content, this is exactly the function they'll hook. Now, again, I won't go over the numerous [29:21.310 --> 29:28.350] parameters here, the parameters of interest are obviously the socket in question, and a [29:28.350 --> 29:32.590] long pointer to the buffers. This would be an array of input buffers, and since we're [29:32.590 --> 29:37.390] passing an array by reference, we also have to piggyback the third parameter, which is the [29:37.390 --> 29:42.290] count of buffers, namely what is the size of said array. And so what I do in my little [29:42.290 --> 29:51.090] demo here, is do a fairly simple, uh, function here, which, hold on, which would just go [29:51.090 --> 29:56.970] on and write to the debug file that it, it's intercepted a receive, and would simply go [29:56.970 --> 30:01.810] over the buffer, it's going over the entire array there, and simply printing out the [30:01.810 --> 30:06.290] buffers. Now, as far as a demo is concerned, this is really not the type of graphical [30:06.290 --> 30:11.650] pyrotechnic demo you'd, uh, imagine, because it also will, will intercept a lot of binary [30:11.650 --> 30:16.730] data. However, it does illustrate the point that the data can be intercepted and can be, of [30:16.730 --> 30:22.970] course, modified. If you want to, you can pretty much have any type of modification of [30:22.970 --> 30:28.230] those LP buffers, and you can inject your own buffers, you can, you know, put your data, [30:28.230 --> 30:33.530] you can, uh, log the data, and so forth. I, of course, chose just to log the data. Now, [30:33.530 --> 30:38.270] naturally, you, you do the same thing for WSP send, and a host of other functions, but that [30:38.270 --> 30:44.330] goes without saying. So, we have our DLL, and now the next place would be, the next step, [30:44.330 --> 30:50.430] sorry, would be to, uh, insert it. Okay, somehow get Winsock to recognize our service [30:50.430 --> 30:55.950] provider as a valid service provider. Now, bear in mind that this is something that has to [30:55.950 --> 31:01.990] be done outside the DLL, because your DLL can only intercept certain functions, but it cannot [31:01.990 --> 31:07.310] install itself. However, in order to install it, we have another call, which is a WSP [31:07.310 --> 31:14.230] install provider. This is a fairly simple call, where all you have to do is provide a [31:14.230 --> 31:18.930] global unique identifier, which is, of course, um, easy to, uh, just whip up to, for [31:18.930 --> 31:24.770] yourself, and you'd set up your own DLL path, and the type of protocols you support. That's [31:24.770 --> 31:30.390] all it takes. Now, uh, your example should have, actually, I'll go to my source code here, [31:30.390 --> 31:35.990] just to demonstrate how simple it is. So, all you have to do is have a small executable [31:35.990 --> 31:42.470] file, like, say, this instLSP, which, again, is, uh, a verbatim copy of the Intel one. I [31:42.470 --> 31:46.390] didn't really do anything here, because this is the same generic code that would work with [31:46.390 --> 31:52.510] any service provider. And so, what it does here is that it has a little function called [31:52.510 --> 31:59.450] install my provider, wherein I populate the provider info, like so, I populate a lot of [31:59.450 --> 32:04.970] stuff. You'll also notice, uh, a nice little flag here called PFL hidden, which is this [32:04.970 --> 32:09.810] flag right here. Which is a really nice flag, because this actually tells Winsock, if [32:09.810 --> 32:15.250] anybody wants to enumerate this provider from the API level, keep it hidden. Which, you [32:15.250 --> 32:19.670] know, I don't really get the actual intended use of that, but whatever. Now, there's also [32:19.670 --> 32:24.990] another, there's also another interesting, uh, copy here, which is, uh, security scheme. [32:25.150 --> 32:29.770] Which enables you to have your own type of security for your provider, blah, blah, blah, [32:29.770 --> 32:35.070] most of the time you just do protocol none. So, essentially, I populate this provider, and [32:35.070 --> 32:42.290] I, of course, register it as a protocol provider for TCP, and once that's done, is, uh, all I [32:42.290 --> 32:48.630] have to do is just call this WSP, sorry, WC install provider, and provide the name of [32:48.630 --> 32:54.450] LSP DLL. This is assumed to be a Windows system, which would be a problem if you're not an [32:54.450 --> 32:59.270] admin, but then again, you're gonna have to be an admin to run this anyway. But you can also [32:59.270 --> 33:04.970] specify a full path here if you really want to. And so, I load the protocol info through the [33:04.970 --> 33:11.210] pointer, and once that's done, I, I pretty much guaranteed that my, uh, provider will be [33:11.210 --> 33:17.110] installed there. Now, let's go ahead and try and install that provider, and see exactly what [33:17.110 --> 33:22.630] happens. Now, you'll notice that I already, uh, took the liberty of placing that little DLL [33:22.630 --> 33:30.350] here. That DLL is as compact as 81K. Actually, it's 80K or so. And, uh, the thing is, once [33:30.350 --> 33:36.570] that DLL is in place, all I have to do is call the inst LSP executable to do the rest. Now, [33:36.570 --> 33:42.030] before I do that, I want to fire up RegMon. RegMon is a tool by Sysinternals, which I'm sure [33:42.030 --> 33:47.990] most of you know, and that enables us to, uh, hook all types of registry calls. And the [33:47.990 --> 33:53.130] important thing here is that all the, this type of functionality of installing providers, or [33:53.130 --> 33:58.790] deinstalling providers, is essentially all registry based. So, if you really want to bypass [33:58.790 --> 34:04.130] this type of DLL with enumerating the provider order and so forth, or installing your own [34:04.130 --> 34:09.050] providers, all you have to do is directly access the registry, which is, of course, fairly [34:09.050 --> 34:14.210] simple. So, what I'm going to do now is I'm going to launch RegMon, and naturally all is [34:14.210 --> 34:20.150] silent, because my process hasn't started yet. And now I'm going to run this inst LSP, and [34:20.150 --> 34:25.110] as I do, you can see that it's scanning the installed providers, and then going on to [34:25.110 --> 34:30.670] install my provider on top of all the rest. Now, again, since, since this is a rather crude [34:30.670 --> 34:35.590] demo, I didn't really go to any, you know, uh, pains of just looking for the right [34:35.590 --> 34:39.750] providers. I just said, go ahead and install it over all the providers. But it's fairly [34:39.750 --> 34:45.130] simple to just decide that you want a very specific provider. Now, you can also see that [34:45.130 --> 34:50.050] there's a lot of registry action here, and specifically, all the registry action is [34:50.050 --> 34:57.950] focused on one specific branch, which is HKEY-LOCAL-MACHINE-SYSTEM, CURRENT-CONTROL-SET-SERVICES, [34:57.950 --> 35:05.450] and WINSOC2. So, firing up RegEdit, just to see what it's like there, you'll see, and it's a [35:05.450 --> 35:10.330] already in my favorites, you'll see that WINSOC2 parameters has the namespace catalog, which [35:10.330 --> 35:14.690] is for the namespace providers, and the protocol catalog, which is for the transport [35:14.690 --> 35:19.830] providers. Now, again, Microsoft is inconsistent. They don't really call things by the same [35:19.830 --> 35:25.410] name all the time, but that's, you know, beside the point here. So, under the namespaces, you [35:25.410 --> 35:30.410] have all types of catalog entries, and as you can see, you have the same catalog entries [35:30.410 --> 35:36.750] that we could have seen under the SP order executable, namely the NTDS, the plain TCPIP, and [35:36.750 --> 35:42.430] so forth. And, when it comes to the protocol catalog here, everything gets really messy, [35:42.430 --> 35:48.330] because one would think that you'd get these nice type of keys and values, but here you only [35:48.330 --> 35:54.490] have a packed catalog item, which is a blob of binary data, that if you go into, you'll [35:54.490 --> 35:59.230] actually see makes a lot of sense. This is a protocol info structure that has been [35:59.230 --> 36:05.570] overlaying into the registry as raw binary data. Now, you'll also note that once I put in [36:05.570 --> 36:10.590] my layered service provider, the number of providers here has risen from the 30-something [36:10.590 --> 36:16.430] that it should be, to around 57, because that's where mine is hooking. So, with all that in [36:16.430 --> 36:21.070] mind, the stage is set, and I can now run any application of my choice, as I'll shortly do, [36:21.070 --> 36:25.970] and you'll see that, as the applications run, I'll get a nice little message box, and I'll [36:25.970 --> 36:49.630] get a full log of whatever. Any questions thus far? Yeah? Mm-hmm. Well, no, that would go [36:49.630 --> 36:53.310] with the namespace provider with the TCPIP one, which I'm not really discussing how to [36:53.310 --> 36:59.410] hook that. If you really wanted to, you could also hook the loopback address as well, so [36:59.410 --> 37:04.790] as people would, you know, go ahead and try to resolve and get the 127.0.1, because it's [37:04.790 --> 37:10.130] in your host file, but then the application would get that first. So you'd be able to [37:10.130 --> 37:15.990] actually rewrite the result of the NS lookup, or whatever DNS packet should have been [37:15.990 --> 37:20.790] there, and you'd be able to just put in any address of your own, which is, of course, you [37:20.790 --> 37:26.270] know, very nice for our purposes. Furthermore, the Google desktop would then have to [37:26.270 --> 37:31.790] connect to the loopback interface, and that would be a transport type action, and you'd be [37:31.790 --> 37:37.330] able to, to get the connect. You'd be able to hook the connect call, and see a connect to [37:37.330 --> 37:43.690] 127.0.1, to whatever port Google is using, and, of course, redirect it. So simply, you [37:43.690 --> 37:48.130] know, simply providing your workaround wouldn't really work, because this functionality is [37:48.130 --> 37:59.090] actually stronger than that. Any other questions? Yeah, back there. Say what? Oh, you [37:59.090 --> 38:03.850] can't. The beauty of it, okay, so the question is, say I want to put in my own provider. How [38:03.850 --> 38:09.110] can I ensure that my provider is the topmost? Uh, in, you know, in two words, you can't. [38:09.170 --> 38:15.030] Because any provider that gets installed after you, can pretty much re-route, re-write, [38:15.030 --> 38:20.130] sorry, the, the stack as they see fit. So you'd have the protocol chain, you'd think you're [38:20.130 --> 38:24.930] there first, but the whole beauty of this mechanism is that it's so transparent, that at [38:24.930 --> 38:29.970] any other point in time, somebody can get ahead, sort of like bump in front of you, and hook [38:29.970 --> 38:34.070] you as well. So that's, of course, you know, good news or bad news, depending on your [38:34.070 --> 38:40.410] perspective here. Yeah, but that's not to guarantee that somebody else, some other [38:40.410 --> 38:44.770] application starting up after you, they could enumerate the order as well, and they could [38:44.770 --> 38:49.330] re-write the order as they see fit. So essentially, this is somewhat of a limbo, in the [38:49.330 --> 38:53.830] sense that you have a given order, but the enum protocols will only provide you with a [38:53.830 --> 38:59.190] snapshot of the current order, and no guarantee of any other application coming after you. [38:59.190 --> 39:04.790] You cannot decide you want to be the topmost protocol in the chain, and that's it. Further, [39:04.790 --> 39:10.210] when any other protocol gets bumped in, you wouldn't know, you have no indication whatsoever [39:10.210 --> 39:17.910] as to your position. Yeah, you'd still be, well, again, okay, so, right, okay, so the [39:17.910 --> 39:22.830] question is, would I still be hooked? And the answer is yes and no, because yes, I would be [39:22.830 --> 39:26.610] hooked in the sense that I'd have my own place in the protocol chain. I don't mind the [39:26.610 --> 39:32.130] fish. So I'll have, I'll have my own place in the protocol chain, yes, but if any other [39:32.130 --> 39:38.270] topmost provider would want to hold that call in the chain and not propagate it, not play by [39:38.270 --> 39:43.110] the rules, they'd be able to intercept it and essentially block it. So as I place my own [39:43.110 --> 39:49.250] provider, I can either choose to go ahead and forward the call, or I can say no, I want to [39:49.250 --> 40:03.920] handle the call, and I don't want to propagate it further. You can change the providers at [40:03.920 --> 40:09.720] any time, okay? Using the provider order, the WSPRite provider and so forth, you can pretty [40:09.720 --> 40:15.620] much redo the whole ordering as you wish, because all it, essentially all it changes is [40:15.620 --> 40:23.720] some internal structure in Winsock, so... Oh yeah, of course, of course, but then again, [40:23.720 --> 40:27.920] there's no guarantee that you will be called again, because again, let's assume for a sake [40:27.920 --> 40:32.880] 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:44.100] But if that somebody takes the express route and just, you know, decides to bypass whatever [40:44.100 --> 40:49.580] other calls, then essentially my provider would still be there, but would never be called. [40:51.380 --> 40:56.720] Yeah, the order is in the registry, and of course, in enum protocols would work as well. You [40:56.720 --> 41:00.860] could enum the protocol so as to get it in a nice little array, but the order is right here. [41:01.080 --> 41:05.060] Okay, this is pretty much the order, I mean, you can pretty much see that the key names are [41:05.060 --> 41:15.840] the ordinals, so it doesn't get too complex. The route by sysinternals, I'm not familiar [41:15.840 --> 41:20.300] with the specific one, but I can tell you that a lot of other route kit detectors don't [41:20.300 --> 41:26.260] really go that far. Now it's important to just define the terms here. This is perfect user [41:26.260 --> 41:31.220] mode action. This is not a route kit in the sense of like a, a kernel mode route kit, [41:31.220 --> 41:36.660] because that would be hijacking TCPIP.sys itself. And that, you know, that, that, there's [41:36.660 --> 41:41.520] nothing that can be done against that. But the beauty of it is that this is full user mode, [41:41.520 --> 41:46.100] and in that sense it's a lot easier, and not to mention, you can code sloppy and not risk a [41:46.100 --> 41:50.440] blue screen of death, which is of course a nice little added benefit there. Okay, so since [41:50.440 --> 41:56.800] I'm getting the noose, I'll just run a few applications here. So let's just start, you know, [41:56.800 --> 42:02.240] let's just run Firefox and a bunch of others. Oh, and as you can see, Firefox is loading, and [42:02.240 --> 42:07.980] already I have a sock debug of 1148, which is of course the process ID of Firefox. So Firefox [42:07.980 --> 42:12.520] is running, and this is the Mozilla start page, and I can do all sorts of, you know, other [42:12.520 --> 42:19.460] whatever. And see, I can get any types of pages I want, and everything is really nice and dandy. [42:19.480 --> 42:27.520] But behind the scenes, I have this little, uh, sock debug 1148. And of course I could also fire [42:27.520 --> 42:34.020] up my messenger, or my Yahoo, or whatever, and I'll do that just briefly here. Uh, so as, as I [42:34.020 --> 42:39.120] fire up Yahoo, I should be getting the message box sometime soon. Uh, yeah, just, you know, [42:39.120 --> 42:43.400] Yahoo's a bit slow. Okay? Now you'll notice this is a really nice, uh, effect, that I get the [42:43.400 --> 42:48.700] message box in the context of the Yahoo process, so I get their window class, which is a nice, [42:48.700 --> 42:54.700] uh, not really nice, but purple whatever. Okay? And so, this is connecting and everything is [42:54.700 --> 43:00.900] cool and nice. You can also see that it's hooking another call, and, uh, whatever, they'll just [43:00.900 --> 43:08.060] let it run, and, you know, ditto for messenger. So if I'll just run here, run messenger, uh, [43:08.060 --> 43:13.080] yeah, whatever, yeah, yeah, you can, okay, whatever. That's a student of mine, disregard that. [43:13.100 --> 43:18.940] Okay? So, uh, again, so I can run that with messenger and so forth, and all these SOG debug [43:18.940 --> 43:25.300] files are right here. So let's just go over the 1148 one, and you'll be able to see that, again, [43:25.300 --> 43:32.320] this is very crude, so I get a lot of seemingly junk looking data. This junk looking data is, is [43:32.320 --> 43:39.060] all types of either gzip compressed HTTP data, or, uh, all sorts of binary data such as images [43:39.060 --> 43:45.580] and, and so forth. If I scroll down, I should be able to see some HTTP requests right here. [43:45.680 --> 43:50.640] Okay? So this is the get of header tab dot gif, and naturally, you get all types of this, this [43:50.640 --> 43:55.360] for example is a PNG. You can pretty much see the header here, that's a dead giveaway. Uh, as [43:55.360 --> 44:00.680] well as a bunch of others, et cetera, et cetera, the HTTP replies and so forth. Now again, I [44:00.680 --> 44:06.720] want to emphasize one thing. This, again as a demo, is not as half as fancy as it can be. [44:06.860 --> 44:11.980] Because with a little if there, I could have simply rerouted Mozilla to some other site, or I [44:11.980 --> 44:16.960] could have modified whatever Mozilla was displaying. Now another disclaimer here, is that [44:16.960 --> 44:21.800] HTTPS type connections are unaffected by that. Fortunately, there are other ways to hook [44:21.800 --> 44:26.960] HTTPS, which are beyond my scope here. But, I'm just saying that if you do use HTTPS, you're [44:26.960 --> 44:32.760] fine. However, when it comes to all types of other functionality, messenger, um, email, [44:32.760 --> 44:42.440] whatever, everything is pretty much in the clear. Okay? Any questions? Yeah. Yeah, with [44:42.440 --> 44:49.140] NetBT you can, although it's, well, again, let's define NetBT. If the process that runs the [44:49.140 --> 44:55.580] NetBT request has launched after you have put in your provider, then yes, you can. And if you [44:55.580 --> 45:01.260] get your provider into the Windows startup, then yes, you can. Okay? However, some [45:01.260 --> 45:07.220] functionality you still won't get. Namely the, uh, the Winsock bypass functionality, that [45:07.220 --> 45:11.520] sometimes the server service does. Okay? In order to, to gain efficiency, it doesn't go [45:11.520 --> 45:15.800] through a user mode DLL, because it doesn't make sense, you know? Okay? So, you can hijack [45:15.800 --> 45:23.700] some of the functionality, although not all. Any other questions? Yeah. Uh, no. Zone [45:23.700 --> 45:27.880] alarm, actually, as far as I know, go into the TDI. This is what McAfee does, though. [45:27.920 --> 45:33.360] McAfee, the personal firewall, uh, does do, uh, they do do that. So, but again, this is kind [45:33.360 --> 45:38.040] of like, uh, kind of like, uh, a paradox in the sense that, you know, it's absurd, because if [45:38.040 --> 45:44.320] McAfee uses that, and I can pretty much intercept their calls and get on top, or, or [45:44.320 --> 45:49.660] reroute them to the bottom, then it's really useless. Any further questions? Because I'm [45:49.660 --> 46:05.250] getting the, sort of like Neustein. So, yeah. Right there. Okay, the question is, if I'm [46:06.430 --> 46:11.230] intercepting a WSP receive, if I'm intercepting an SSL socket, would it be encrypted or not? [46:11.230 --> 46:15.490] And yes, it would be encrypted, because I'm essentially getting it as it came on the [46:15.490 --> 46:21.610] network. So, this enables you to play middleman, but only middleman, you know, post SSL, or [46:21.610 --> 46:26.690] post encryption. Which is, as I've stated, the proper workaround, the proper mitigation to [46:26.690 --> 46:31.430] that, would be to always use SSL and so forth. However, bear in mind, that nothing is [46:31.430 --> 46:36.350] preventing the, uh, application from also, you know, trying to forge certificates and do any [46:36.350 --> 46:41.530] type of de-sniff type man in the middle, which would work here. Okay? So, just to conclude, [46:41.530 --> 46:47.590] before I'm, uh, kicked out violently. Okay? So, that was the demo. The lesson to be learned, [46:47.590 --> 46:52.370] the thing you need to carry home from this, is that no matter what you do, no matter how you [46:52.370 --> 46:57.530] code your application, the beauty of Winsock is in transparency. However, this is a double [46:57.530 --> 47:03.730] edged sword, because obviously, as transparent as it is, it enables attackers to subvert either [47:03.730 --> 47:09.550] client sockets, server sockets, whatever. Now, it's also important to emphasize that this [47:09.550 --> 47:16.110] was originally intended for good uses. Namely, implementing an application type firewall, [47:16.110 --> 47:22.510] application layer firewall. We mentioned McAfee, and, of course, we saw where that got. [47:22.690 --> 47:27.790] Um, transparently add encryption. This was well before the days of IPsec. We're talking about [47:27.790 --> 47:33.750] 98, before IPsec was a fully robust protocol, as it is now. And nowadays, IPsec is handled, of [47:33.750 --> 47:39.850] course, in the kernel level. Uh, enforce quality of service. Yeah, right. Uh, support new [47:39.850 --> 47:45.210] protocols. This is also another nifty functionality. You can essentially support IPv6 by [47:45.210 --> 47:49.790] it, although it's supported already. You can support IPv9, you can support pretty much any [47:49.790 --> 47:56.190] other custom protocol over a raw socket. And patch content on the fly, which, like I said, [47:56.190 --> 48:01.410] Google Desktop actually do. Whether it's a legitimate use or an illegitimate use remains to [48:01.410 --> 48:07.670] be seen. However, the much better chaotic uses would be to patch content on the fly in the [48:07.670 --> 48:14.010] illegitimate sense. And again, we're talking about rewriting webpages, rewriting IMs, uh, [48:14.010 --> 48:18.370] doing a lot of other nifty stuff, which I will not disclose here. Um, obtain connection [48:18.370 --> 48:23.570] statistics, URLs, etc, etc. Most of the spyware applications do exactly that. They put [48:23.570 --> 48:29.170] themselves in so as to gather your statistics. This was what the CASA spyware did. Eavesdropping [48:29.170 --> 48:35.590] on any type of connection, but again, non-SSL ones. And, uh, rerouting connections, that is [48:35.590 --> 48:40.370] just hijacking the sockets, which is really an amazing thing. Because an application opens a [48:40.370 --> 48:45.730] socket and calls connect. And once it does that, then, you know, the worst that can happen [48:45.730 --> 48:50.610] it'll, it's gonna call get peer adder. But you can reroute connect and you can also reroute [48:50.610 --> 48:55.090] get peer adder. So, you know, whatever the application thinks it's doing, whatever, [48:55.090 --> 49:00.250] wherever it's, it's actually thinking that it's connecting to, it has no real significance [49:00.250 --> 49:05.190] here because you can do whatever you want with it. So, uh, all that in mind, the demo, like [49:05.190 --> 49:11.150] I said, is part of the platform SDK. Uh, you're welcome to drop a line to, uh, this address [49:11.150 --> 49:17.350] right here and if you need, you know, the demo with the actual, uh, explanation on what I did, [49:17.350 --> 49:24.990] where I did and so forth, then it will be supplied, of course. Any further questions? Okay, peace.