How you doing? I'm going to be with you in just a second. I have three versions. We have three versions of this show. And the idea to give you guys a choice for versions, kind of came from an old game called Leather Goddesses of Phobos. Anybody ever play that? Yeah, I see a lot of hands. Leather Goddesses had three modes. They had tame, they had moderate, and they had lewd. Okay? How many people want to tame presentation? Ooh! How many people want to moderate presentation? Okay, how many people want to lewd presentation? Okay! Is it too early for beer at DEF CON? It's like barely noon. No. Is it better if it has fruit, like for breakfast? Does that work better? Okay, so lewd it is.  So quick introduction. So I'm Matt Richard. I work for iDefense, a group part of Verisign. My background is I worked in financial services for about 10 years and doing network ops and security ops, and then came to Verisign and just kind of hang out. So we have a quick talk on exploitability and extrusion scanning. So it's a quick background, something I wrote as a sort of a hobby just from hanging around and being on different networks. Fred's going to join me. Fred's going to talk a little bit more on the risk angle. Oh yeah, this is Fred Doyle. I'm the director of the iDefense Research Lab. I see some people in here that were at our party the other night. I think we had a party. I remember a party kind of. So I'm hoarse from that party still. We had a good time though, so everybody who joined us on that thanks a lot for coming. And we're not using the same PC that the presentation was written on, so we've got a couple little issues. Apple! So one of the quick things just to get out of the way, I tend to talk a little fast, so if I start rolling too fast, just throw a beer at me, I'll stop, drink it, slow down, we'll be good to go. So a quick agenda, so we're just going to go through some background on why would you need a tool like extrusion and exploitability scanning? What does it mean? Why is vulnerability assessment not enough? What does it do and doesn't it do?  I'm going to talk a little bit about extruders, and then we're going into the cool details of eScan, what it does, how it does it, and some of the different cool things it can do. And then go through a couple of real-world examples with the code and how it works and how you can use it for different tests, different things. Fred's going to talk a little bit about the risk angle to it, like now that you know all these crazy things that are allowed, what kind of hostile networks you're on, what is the risk level of that kind of stuff. And then finally I've got some real data from when the tool was run on real networks, especially through like real-world intrusion prevention and proxy systems, so we're going to look a little bit at some data to see like what kind of attacks do things actually block, you know, look at some of the exploitability data and go through that. So just a couple of quick definitions, I don't know if you can see the image there, but exploitability apparently isn't really a word, I've just been using it for a while, so nothing actually recognizes it, but in the context that I use, it's basically when we're looking at exploitability, it's something exploitable through a series of defenses. So a lot of enterprise networks have intrusion prevention, proxies, you know, 15 different layers, the defense and depth model to try to block attacks, and we just want to know through all those defenses is something actually exploitable. We don't care if it's vulnerable, we just want to know if it's exploitable. Can exploits get through? Can we obfuscate them and do things to actually get it to pass through? And then extrusion, very basic definition there, you know, what kind of traffic can we get to leave a network? Can we use, you know, a lot of people try to lock down protocols and what can be used on their network, so the eScan framework gives us a way to test, you know, different protocols and different ports to see what can we actually get out of a network. Okay, we're going to start out here with what I call the Ripley moment, and there was a time when a lot of people, not everybody, but a lot of people, most people in fact, thought that the internet was safe. In fact, I remember when I had a consulting firm in a computer store, my clients were forced to buy a $1,200 firewall, which, by the way, I set up using Linux and IP chains. They coupled to the modem in the slide? Yeah, yeah, yeah. Always had a modem, yeah. Who set up Linux with IP chains? Just a show of hands? Oh, my God, you're still alive.  Tables, a lot easier. But anyhow, so a lot of people thought that the internet was safe. Code Red, for example, came out. All my clients, because it was, of course, on the news, it's like, am I in danger? No, remember that $1,200 device you didn't want to buy, but I made you? So you're all set, right? But bottom line is this. Next slide, please. Obviously, it's not the case. Once we had one bad person on the internet, everything became bad. And that's why we're here today. All right? Now what we did, of course, we developed fields of fire. We said, okay, there's things that we can't control. We'll never control the internet. We can't control anything behind our modem. And we're mostly facing forward, okay? We are looking forward, looking at threats. And when we do pen testing, we test from the outside, looking in. But what we determined that a good way to solve all these problems is to add layer after layer after layer after layer of security. And that's where we are today. Thanks. We had planned this for remote control. All right, vulnerability assessment. These are all the things that we try to do traditionally to find out how secure we are. We do vulnerability assessment. You know, is there something that can be attacked? Penetration testing, of course we all know what that is. Risk assessment, you know, we're in Vegas. Who here has done good risk assessment in the past? Raise your hand. Okay, of those with your hands up, how many lost money at the tables?  Okay, risk assessments, any software vendors in here? If there are software vendors in here, please cover your ears because I'm going to tell you right now, software vendors don't do risk assessment. They're whores. They're hookers. And I had to say that for two reasons. I had to say that for two reasons. Reason number one, I want to be able to deduct the expense from the other night. Reason number two is because the software consumer is just like a John. They want it, the vendors want to give it to us, and we don't care about the risk. We're going to get into more of that later. So one of the other things, and this is kind of where a lot of my background is from, is ad hoc testing. So in doing pen tests and everything else, a lot of stuff, good testers just sort of make it up on the fly, right? You don't necessarily have a plan. You just start looking at stuff and you just start making things up. The real problem with it is not necessarily repeatable. It's not a framework. You see an opportunity, you dive at it. It's very ad hoc. That's a lot of where the ESCAN tool came from is I used to do a lot of testing and just try stuff out, put it in the report, and eventually I realized maybe it would be nice to actually have a framework to make it a little bit more repeatable and make it work a little bit better and get some better data out of it that could be compared against each other. So the big thing missing with all these traditional security assurance is how effective is this stuff at preventing attacks against users. So we're going to go into a vulnerability assessment and why that's, why it only does half the job and is only half broken. So the key behind vulnerability assessment, right, is you have some kind of external stimulus and you measure the response and you determine, you know, through a banner, through a test whether something's vulnerable or not. What that doesn't measure is it doesn't measure what happens when things inside your network generate a stimulus and what the response is. Right? So most vulnerability assessment tool is very geared at that, what's listening, what can we talk to that gives us something back, not what might talk to us that we can give something back. So ESCAN's an attempt to dive into that arena a bit. So we talked before about defense in depth. We've got all these layers and obviously no defense in depth system is perfect, otherwise you wouldn't need the depth to begin with. So there's always those cracks, always the cracks in the system, the little ways things can get out, things can get in between. Not everything protects against everything. So we want to measure some of those, some of the cracks and try to find them and use a framework to try to get at those cracks. When I was doing enterprise security, one of the things that always cracked me up is like, CISOs have a big budget, right, and they want to spend lots of money and lots of flashy things they want to buy. So you spend like $15 billion this year and you get like 17 new gadgets and nobody actually knows what works and what doesn't work. It just gets deployed and there's a bunch of stuff out in the network and nobody really does much testing to see, does our new shiny IPS actually block anything? Does data leakage do anything at all? You know, things like that. And one of the other challenges too, one of the things that makes defense in depth so hard is that protocols are really complex, especially things like HTTP. There's so many things that can happen in HTTP. You've got layer on layer within HTTP. You've got JavaScript and Flash and, you know, it's pretty much a whole stack unto itself. One of the things I forgot to mention, if there's any questions as we go along, throw them out. By all means, you know, not everything's complete on the slide, so if you see we're missing something, throw it out. So back to the vulnerability assessment gig. So one of the issues with VA, you know, you don't check, you only check what's listening and, of course, browsers and clients like users don't listen at all. Although, so I was doing some research for the presentation. One of the things I found, there's actually a Firefox add-on that creates a web server within Firefox, and that is awesome. So we're going to go through and we're going to create a framework that sees if our protections are easily bypassed, you know, are we blocking common attacks, not bizarre things? Oh, yeah, and the other interesting thing, being in the enterprise world, is that there are actually people that don't patch because they think all the devices they spent $15 billion on actually do something. So they say, oh, no, no, we don't need to patch on Black Tuesday because our IPS already has a signature for that. So we're safe, we're going to be good to go. So one of the other problems, so when you get into big enterprises, you know, you have 100 users, patching is easy, right? That's everybody's answer. How do you solve the vulnerability issue patch? 100 users, easy, not that many applications. What about getting like 350,000 workstations? Not necessarily as easy to figure out who's patched and who's not. Stuff just falls through the cracks.  And at Citibank, 35 exploited machines might not be a good thing. So larger networks usually have more complex systems. Nobody tracks everything. You have ATMs running Windows. You've got camera systems running Windows, all the black box stuff from vendors. Nobody knows what runs on anything. So what I want to do is I want to add a little item to the vulnerability assessment, extrusion and exploitability assessment. And so adding all this stuff we've talked about, measure the risk. I want to try some cool things too.  If our IPS blocks one exploit, does it actually block like what M-PAC does? And for those that don't know, M-PAC is the Russian attack tool kit that's been widely used. It was part of the Italian job a couple of months ago. But it's got eight or nine different exploits in it. It's got a whole bunch of different encoding mechanisms. And it's sold for $1,000 on the underground. So what are we missing? The text for the slide, obviously. So another thing that's missing from the vulnerability assessment game is the extrusion stuff. What can leave our network? How do we know what applications we block? Like maybe 10 years ago, Blocking Port 5190 actually stopped AIM, but that's not going to happen anymore. So users want to use applications. Security policies don't. Mainly an enterprise problem, but actually the roots of this all started back when I was a consultant. I would travel all over. And of course you've got tools on your machine that you need to do work like Skype. And so you plug into somebody's network and just to get the root surprised that they don't allow Skype on their network. So then you got to go through the hassle of trying to figure out a way to get around it, tunnel around it and do all that stuff. So I actually had started writing some tools to do that automated assessment. Just tell me how to configure my apps so that they'd work once I plugged in without having to do any manual testing. So when I was running the Big Financial Network, one of the things that I learned that's completely bizarre is that people love AIM. AIM is like the most popular application people try to tunnel around for no reason at all. And they do everything. Like tech users are doing things like running AIM over Tor just to get AIM. And actually, my favorite story is there was a president of a bank that was one of our customers and again, guy loved AIM for some reason. And one of the things he did is he actually installed a modem on his PC and was using AOL dial up to get around the firewall filters just for AIM. And the best part of it is so this is only like a year ago. He's dialed up to AIM. He's dialed up to AOL. He's using his AIM and he gets SQL slammer and takes down like the whole enterprise network for hours. Nobody can figure it out. All because he just needed AIM. Insane. So how do you determine what works on your network? I mean, the easy thing is go out and download AIM, install it and see if it works. But that's kind of a pain, especially if you want to do like 500 different applications. So another thing people like to do, extruders like to do is they like to get remote access to the machine from home beyond policy. So there's a million different ways to do it. There's reverse B and C. You can do SSH port forwarding. There's a bunch of commercial stuff. Go to my PC, log me in. Some of that stuff's easily blocked. Some's not. But how do you know what works and what doesn't work? So EE scanner is the tool that I wrote originally just for the extrusion stuff, but then adapted. And we're going to go into a lot of details later.  We're going to the cool stuff soon. So we want to do a couple things. We want to measure all that stuff. We want to go into, you know, what are we blocking? What are we not blocking? Got a yada. Where are the weeds grow through? Did we spend money that falls in line with the threats we were trying to protect against? So all enterprise networks, especially lots of layers. We've got things like transparent HTTP proxies, transparent SMTP, transparent DNS, intrusion prevention, all data leakage stuff. So we want to just test through all that stuff and find out what works. Oh, so actually, I'm going to skip most of the slide, but one of the ones that, so one of the exploitability examples I really like was the original VMLO day that came out. And when it did, the proof of concept used the RECT method. And so every IPS vendor out there and every security vendor, they all wrote their SIGs for this RECT vector, right? And it turns out there were like nine different shapes that you could use to get the same exact effect. So the signatures were absolutely useless in protecting all but that proof of concept. So there's a couple of tools that I always used to use, obviously great tools that worked very well. My big crutch with all of them is that none of them had great automated ways for doing it. Like Metasploit, really good for running and seeing if your defenses are blocking certain types of exploits. Works really well. They've got a couple of encoding techniques in it. So you can get a lot of good information using Metasploit for that. There's another tool called F-Tester, which does a lot of the same things. It'll do outbound firewall scans. You can take snort signatures and have them pump them out to see what gets picked up. It's good but it doesn't do everything that I was looking for. It doesn't really behave like a client. Like it was taking just IDS signatures and just pumping them out rather than a full HTTP context and really getting all the data in there. Because sometimes when you mess around with little variables you find out like a vendor might do something one way with this set of data and another way with another set of data. So just pumping SIGs doesn't really do everything you want. Core impact, really, really cool and you could probably do all this but it costs a lot, a lot of money. So not necessarily very well for what I was looking for. So my whole goal with this is to write EE scanner. Get it out there. It's going to be free. Most of the stuff is already out there at EEscan.net and it's going to be up on the iDefense site more than likely to. Some of the code I didn't get to publish before I left and I couldn't get a connection from my hotel. So some of it won't come out until I get home Monday. But all the stuff is we're going to go through and show different ways to use it. So we're going to test for all those things. We're going to do a little bit of, we're going to get some good reports at the end that show us what gets blocked, what doesn't. So here's a quick overview of the architecture. So EE scan is mainly written in Python. There's a couple of other components like in PHP as well. But one of the things I liked about Python is one that keeps me from writing really bad Perl code. And the other thing it does too is it gives you a shell that's nice that you can just call functions right from a shell. So if you want to do manual testing, you can do it that way or you can script it all. So the real point of EE scan, you have the base classes which implement a whole bunch of things like AIM protocols and port scanning and HTTP encoders and all the stuff that we're going to need to do our testing later on. All in one base class. So we can import those base classes. And there's another section that does unit tests.  HTTP exploit checks. So there's a module that just does like encoding. We'll go through those methods. And AIM tests, of course, you know, everyone needs AIM so we need lots of good test frame. And then on the server side, so that's all client side stuff. On the server side, there's a PHP exploiter that takes information and kicks it back out to the client. So it'll actually send the exploits with whatever encoding we want. With TCP responder, so when we're testing for things like transparent proxies, we can't always rely on just interacting with the proxy. Sometimes we need something on outside of that that we can test through and try to make real connections to to see what gets modified. And then finally SSH and tunnels and all the things. You know, I didn't rewrite DNS tunnel or ICMP tunnel or any of that stuff. So all that stuff sits on external server as well. And the real key is we want to run our client side stuff in our network and we want all the server side stuff outside the defenses. So we're testing through everything rather than just at something. So diving in the base classes. So a couple of things, egress scan is probably, you know, one of the simplest modules does an outbound port scan. All my examples here are from a Python interpreter. So you drop down to Python, import the base classes and you can run everything just like this. So egress scanning, we pump in IP and we tell it, we want to scan from port 1 to 1024 and it kicks back the results, kicks back the results to us. So I included Parameco for SSH. So there's a whole wrapper around Parameco for doing SSH and port forwarding. Real simple to use. You instantiate a class. It goes out as an egress scan, tells us all the ports that are available. And then we tell it we want to know what protocols are actually. We want to check for which protocols will actually let us pass SSH over them and it kicks back all the different ways that we can use SSH. So another module is the unit test harness. So you can write, I know it's kind of hard to see up there, but basically with about seven lines you can write test descriptions and tell it, like one of them up there is AIM tour. So you can tell it that I want to use the tour module. I want to make a TCP connection over tour. I want to make it to login.oscar.aol.com and I want to do it on port 5190. So you create all these little tests written like that. You kick it into the unit tester and it'll tell you all the results coming back. I have maybe like 50 or 60 unit tests, but it's really extensible. You can do pretty much anything you want with it. Anything with TCP, SSH, ICMP tunnel, DNS tunnel, whole list of different protocols and tunneling mechanisms. There's a whole separate tour support section.  So you can instantiate a tour class and then use it just like you would a socket and Python. So you can do send and receive. It does all that legwork for you. And it's actually used by other modules as well if you're doing a tour testing. So one of the interesting things you can do with like egress scanning is you can see what's proxied and what isn't. So like for people who saw Dan's talk, his big thing was hostile networks. How do you know when you're on a hostile network and things are being proxied? Sometimes it's really easy to tell. You just do like egress scan to a dark IP that doesn't exist at all. In this case in the hotel that I was staying at, I got three results back, 25, 53, 80. So really easy hint that you're actually in a captive portal and that they're transparently proxying all those protocols.  They block sometimes IRC or all sorts of random things. So my Colo, I wanted to know what protocols they block. Really easy to fire off right from the command prompt. There's actually an extra flag. Block equals one, which tells it just only show me ports that are blocked, not ones that are open. And then finally, another module called check plane, which tests to see if it's a plain TCP socket as compared to proxied socket. So you can do things like on port 80, try to make a direct connection and find out if there's a transparent proxy in the way. In this case, the output's a little cryptic, but it's 001, so I tested 25, 80, and 123, 001. So not a plain connection, not a plain connection, not a plain connection, plain. Real simple. All this is actually a lot easier when you do it in scripting, but all easy to do from the interpreter as well. So the other phase we talk about exploitability testing, we want to know what kind of exploits we can pass and how we can encode them. So HTTP, really complex protocol, lots of different ways to do stuff. It's got like a whole protocol stack into itself. You've got JavaScript. It supports native methods at the protocol layer like Gzip, deflate, chunk, SSL. So we can try all those different ways of encoding things. We can use lots of different JavaScript methods, some that are used in the wild and some that I just made up. So we'll go through those things like Ajax, XOR, white space, random variables, random functions, a lot of stuff like from the VOMM, stuff like that. So one of the things, obviously IPS and IDS isn't really a great technology and one of the main reasons behind it that you take a look, here's a signature for detecting A&I exploits and the big problem right here, as long as it's going to an HTTP port, it'll detect it. So running things like HTTP over 443, trivial bypass to a signature like this. It's got hard-coded bytes in there so any white space or other randomization or encoding completely bypasses it. So some of the tricks, so there's a module with an EE scan, HTTP encoders. So the HTTP encoders allow you to take an arbitrary payload, do the encoding, and then kick it back to the client for testing. So some of the ones, GZIP, Deflate. Interesting thing with that. So GZIP and Deflate, does anybody know what GZIP and Deflate do with browsers? Real simple, right? Just GZIP the content. Deflate is GZIP without a GZIP header. Real simple. You'd be surprised how many devices will detect GZIP stuff but not Deflate.  So anyway, so my favorite, Ajax. So that was when I kind of wrote myself. So Ajax is kind of like a frag route for HTTP. So what you do, instead of just sending the entire exploit in one or two packets over a regular HTTP session, you use XML HTTP request and you break it up into chunks. So JavaScript is really nice. You can treat code like data and data like code. So you tell it, go out and get this exploit and break it up into any arbitrary number of chunks. Send it back to me. I'll concatenate them all together and eval it. So real simple technique but IDS is other things like that rely on actually seeing the code together. Even if it's obfuscated in the code, a lot of times they can pick it up. But if you break it up and do a frag route type attack, it works much, much better. So another one of my more favorite Ajax is some of the encoders out there and I'll actually go through MPAC in a minute. They do things like the XOR and the Lexor with the static key. So if you're looking at that TCP dump or anything or any tool, you can actually see what key they're using to decode the data. Right? Simple loop. So what I like to do is I like to actually send the key in a separate XML HTTP request, break it up. That way an analyst looking at it has no idea what the key is unless he's got all the network traffic instead of just a couple of packets. So here's MPAC.  On the top you've got a plain text string and this is all in the Python interpreter again. You've got document.write hello world. Run it through the MPAC XOR engine. It spits it out as an XOR function with all the data XORed into a blob which is going to go through an XOR. The browser will then interpret. And then the bottom example is just using the same MPAC XOR except this time using random function and variable names. Just another way to kind of get around some of the static detection that's out there. So here's an example of the Ajax encoding. Here's the source where I mean it's not complex at all. Literally all you do is you just tell the server I want to break this up into some random number of chunks, 20, 50, whatever it is and give me each piece one by one, reassemble them and eval. One of the interesting things is this is actually, this technique is really easy for humans to evaluate but really hard for machines. Because humans can just go through, look at the code and see that oh yeah I just need a W, get all the different slices, assemble them back together and I've got the code. Machines really, really don't like that. So the MPAC attack toolkit, really famous, everything else, they sell for like a thousand dollars in the underground, exorbitant prices for something with a lot of flaws. So what I did when I was going through this is I looked and said MPAC is just terrible with encoding. So what I'll do is I'll improve it for them and sell it back for like 10 grand, who knows. So one of the stats on MPAC, it only infects 3.3% of machines in the U.S. which is a terrible rate. It does a lot more in developing countries where every version of Windows is pirated and not patched. But in the U.S., 3.3%. And one of the reasons is that AV vendors actually pick up the MPAC JavaScript. So they do a terrible job at obfuscating other than the one basic technique. So you've got the pseudo code for what they do, just a simple XOR of all the data. So some of my ideas for them that I'm going to kick back to in my business proposal are random function names, white space comments, XMLHDP requests for the XOR key, GZIP encoding. And for God's sakes, these guys have no idea if they ever heard of Millworm. They use like the newest exploit they have is like A&I from a couple of months ago. They had no exploits at all. It's awful. So go through a couple of real world examples, places where I use it. So reality check number one, checking loving aim. If you want to actually do the unit test for aim, type's a little bit small. But basically you just write a couple of simple tests for each one. Can I connect using default settings? Real easy to write up the test. Can I do crawl settings? Have it do a port scan of all of login.oscaret.aol.com. Kick back all the ways you can get there. Tor, same thing. So all this stuff is real easy to implement and automate for a testing scenario. And if it's a protocol that's not supported, just write a quick Python module for it and off you go. So some of the other cool things. So I really like tunneling stuff. So this will actually go through and do like there's a DNS tunnel module, ICMP tunnel module, SSH port forwarding built in. So here's some more examples right from the command line if you want to do HTTP exploit checking. It's as simple as doing a calling one function. So you call get HTTP MD5. And what's happening behind the scene. So you've got the two parts. You've got the Python script and then you've also got the server side PHP. Python script makes a request for the exploit. The server side takes all the content, adds an MD5 header, a HTTP X header for the MD5. Client gets it back, compares the MD5, and now you know if it's been modified in transit. So real simple. So in this case we do HTTP MD5 for, we're passing parameters to a test.php. We tell it the code we want is plain and the exploit is linked in. And it kicks back and tells us in the results that the connection was broken.  So broken TCP connections are a great indication that something's actually just been dropped. Next example, GZIP. So we run the same thing. Again, this time we see MD5 mismatch. So the results that we were expecting were different than what the MD5 say. Usually that stuff, like proxies, like to modify the content instead of just dropping it. So instead of sending the exploit, they send you a page back that says, like, we blocked this page for you, you're safe now. So same thing with the impact one, we see that one gets dropped.  So one of the things real easy, just drop in. I have a quick function called try them all, goes through every possible permutation, kicks back the results to you in HTML, and now you can look and see what's being blocked, what isn't. And at the end of the talk, I've got some real-world data, and you can see some interesting patterns and different devices and how they look at exploits. So we'll look at that later on. We try all the different exploit techniques, all the different encoding techniques, and just for good measure, we try a couple different user agents too, just in case maybe there's a difference in user agents. So my favorite one, this one I used to do in operations, is testing incident response plans and MSSPs.  It's kind of like a black box. You call up, you call them up, they say, oh yeah, you're covered, but they don't share anything with you. And you never really know if they're alerting you on everything. So one of the things that's easy to script out with this is to do an MSS test.  And then of course, the most important set up a cron job to run every Sunday morning at 430 just to make sure everyone's on their toes. So this is a great slide. So I was doing some research and I like to add an image every now and then I was looking for something that followed up with risky business, just a random image. And I came across the it's like state of Nevada risk management center. And they have this picture that I put the you can't read the text, but I put it right next to it. Risk management is the expert management of differences that may exist between expectations and reality.   It's crazy. So Fred's going to tell us exactly how all that works. But the way he scan fits into the risk assessment process, you get a lot of get all this data back. But what does it actually mean to you? What's the if you're one of the corporate guys that actually needs to do risk assessments? How do you use it for something useful? I read Matt showed me that the other night. And I thought it was just because my blood alcohol was like a point three. But today when I'm only a point two, still doesn't make any sense. Risk management, the expert management of differences that sounds like my first marriage. Anyhow, the bad thing is, here's our conventional risk assessment. And that misses the mark two. Who can tell me what any of that means? Well, obviously, it's arithmetic. And please don't say mathematics, it's arithmetic. You know, we have some multiplication, we have some addition in there. But the bottom line is this, all right, when you are making estimates on everything that you're doing, how can you really put a good value on what the risk is? Everything single loss expectancy, the annualized rate of occurrence, everything else like that, that's a guess. And if it's not a guess, and if you have the statistics for it, what says that 2008 is going to be same as 2007? How many people here have actually scanned for extrusions and exploitability? Please raise your hand. Okay, a fair number. Okay. Why hasn't everybody else? Well, the reason is because right now it looks like the risk is zero. It doesn't look like there's a risk from it. Just because we don't notice a rate of error and a rate of occurrence or an occurrence doesn't mean that it's not there.  Okay, the holistic threat assessment, we have to worry about what the asset value is. And instead of going through each one of these things, what I'm going to do is I'm just going to give you an example. Okay, I've got a house in Florida. Not really, but I wish. I have a house in Florida. The house in Florida is susceptible to weather damage. All right. So I've got the asset, I've got the vulnerability, the exacerbation is there's a hurricane off the coast. The mitigation is my house is made of steel. And the perturbation is this one of those 500 year storms that takes everything out in the path. All right. Now I defy anybody in this room to use a standard CISSP model to give me a risk based on those things. Wait a minute, just to check. How many people have the I am not a CISSP badge? Nice. So basically what we're doing is we're trying to quantify something that we're just starting off with with guesswork. Right now, there's a different risk model that we are kind of looking at the risk model still in the design stage. It is not arithmetic, it's real math. It's a real model. One of the elements is the holistic design that you saw before, the things that you saw before. But the bottom line is it appears to work very well with CVSS data.  And we keep that data. And right now we're doing the CVS scoring on it, CVSS scoring. And we've even started to use a CVSS version two scoring on it. And still we haven't gotten 100%. The first model was maybe 60 to 70%. Now it's 80 to 90%. Perhaps maybe 80, 85%. But the thing that is on those 15% that's left over, you still need a person. So why worry with the model? The model that we're working on actually is pretty much dead on for everything. So it looks good. Okay. So so in the real world usage, so this has been run, I've had some people run it for me, I've been using stuff for a while. So as with anything, you get some interesting results back. So I'm going to go through a couple of those. So the first one, for some reason, AOL servers don't respond to any TCP packets without an MSS and not just max segment size. And there's other things they don't do too. So one of the ideas that I have is I think you can actually probably fingerprint IPS devices just on the results you get back, and weird things like not replying without MSS. Because obviously it's not it could be the servers that drop it, but it could be something else in between. So there's maybe some opportunity to do some fingerprinting of devices passively, just by watching what they drop and don't respond to. So the next one, just because they don't ask doesn't mean they don't want it. One of the interesting things I found is that so browsers, when they want, when they want to use an encoding mechanism that supported like GZIP or deflate or chunked, they asked for it, right? They put an accept header that says, you know, accept GZIP, accept deflate. But you know, sometimes proxies strip that out. Sometimes they don't send it because they don't support it, things like that. What are the interesting things with things like Firefox, IE, and a couple other browsers is that even if that tag gets stripped out or even if they don't ask for it, you can send it to them, they still just render it, right? So it actually, the accept, actually having that in the header means nothing. You just send it back to them, they'll just render the GZIP data just fine. So another interesting thing, simple tactics, this is probably obvious, but are incredibly effective against almost every kind of device, every kind of IPS and a proxy device. Just things like random white space, 50% effective in the real world testing. Like just adding spaces in kills that many protections. Remember the old mail bomb with a mail server, so if you want to crash a mail server that had like antivirus, you do like DD dev zero, like a terabyte, and then you GZIP it down to like 20K and you mail it through and it tries to, you know, open it up and it just dies bombs. Yeah, that kind of works with proxies too. They don't really like GZIP data like that, like a petabyte of zeros doesn't decompress that fast. So interesting. I don't have anyone read the interview with the MPAC authors, dream coders team, so they did an interview as on security focus with Rob Lemos. So at the very end, they talk about, they ask them, you know, if people want to be safe from your attacks, what should they use? And he says opera, whatever. It's actually IE4 on NT4. So one of the interesting things is that most of the exploits and most the encoding mechanisms, it won't even render. So things like GZIP, it just dies on like half that stuff doesn't even work right on it. So it's actually incredibly effective against blocking out all kinds of encoding because it just doesn't even, doesn't do anything with it. And then as we'll see in the next couple of slides, as long as you can block out all that encoding, some devices actually do a decent job at blocking attacks. So NT4 behind an IPS might actually be safe. So here's some quick output from exploitability scanning, just doing some HTTP checking. So the output basically comes out, it tells you, here's the test that you ran. Here's what Portray ran it on because one of the other things it does, it tries HTTP and HTTPS. Obviously most things don't catch HTTPS unless they're doing an SSL man in the middle like blue coat, some other devices. So it runs through all the tests, goes through all the possible permutations and it tells you what happened. So in the results we can see here, there were three attacks, three exploits that were actually blocked, indicated by the broken, and the rest all passed right through. So simple things like adding white space was able to evade in some cases or the M-pack encoding. So here's just four quick examples of four things. So this is just graphs of that same data I just showed you, run on different device types. It was interesting when you look at it from a distance like this, you can almost see patterns, like different devices have different ways, their engines have different ways of looking at the exploits and encoding and doing something with it. So let's drill down into a couple of those. So here's one, it's a men's service provider and they have a custom IPS device that's supposed to do stuff. And what we see is that they block plain exploits and they even handle a couple of encoding like white space and chunked, but they do nothing with JavaScript and they do nothing with GZIP. So if you GZIP it, everything goes through. If it's plain, they catch 80%. So next one, we have a proxy device running antivirus. What we see is it's really bad at catching the exploit itself, but they're really good at catching the encoding mechanism. So something like M-pack, they actually pick up every single time, regardless of what the contents is. They just figure, you know, if it's M-pack encoded, we just kill it. And then they're only like 50% effective when you actually do something with the M-pack encoding and like say, add white space to it. So you can see the effectiveness really drops off pretty quickly. So the Astara guys, so they do a good job. And one of the interesting things from theirs is they actually don't manage to stop anything except GZIP stuff. It was the only, it was the only device I tested that if you didn't send an accept GZIP header, they actually thought that that might be a problem when you sent back GZIP data. So interesting thing, but they didn't actually stop any of the other exploits, all on a fully updated system. And then, so my last test, so I'm running this through on a couple different device types and got my switch, I got my device out connected to the internet and I start, I run it. I'm like, holy crap, this is like the best device I've tested. It gets everything. This is awesome. And then, so I'm just, I'm starting to pump information in, then I look and I'm like, and it's wireless. This is really awesome. So yeah, actually unplugging the cable is incredibly effective. And we have a little bit of time here. We weren't really sure if we were going to make this on target, so I did not tell you my favorite risk assessment story. About 10 years ago when I was 15, okay about 35 years ago when I was 15, 50, okay 36 years ago to be exact when I was 15. I worked for my father in his body shop and he went out to lunch and back in those days he usually had a liquid lunch. In fact to this day he still has liquid lunch but that's cool. But he comes back into the shop and I have a car jacked up and I'm working underneath the car and I don't have any jack stands, okay. Now I just have a floor jack, nice solid hydraulic floor jack and I'm under the car working on the car.  Here's a guy that didn't have a high school diploma, here's a guy that just had common sense, but he had more common sense than a lot of CISOs that I see, okay.  Shortly after that I went a different way, I actually became a cop, but the third year on the job I got a call where a guy was under a car in a body shop and the car had fallen on him he wasn't using jack stands. So we are not really good at risk, we're not really good at figuring out what risk is. To me it wasn't risky at all being under there, I mean the chances are one in a million is going to fall on me, but if it fell on me it would have killed me as it killed this other guy. So you know you guys that have to answer to all these policies and all the modeling that you see out there, all the competition for your money, just step back and say does this make sense to me? And I think you'll go a lot further, okay. And so one last comment I wanted to add in is that one of my goals with E-Scan and the exploitability testing is to be able to go out and actually profile a wide range of devices, because I think what we're going to find is that seeing what they can block today tells us a lot about what they might be able to block in the future. So it actually is a little bit more predictive and more useful in that means than it is in just knowing what can actually be sent through. So open up to questions, we have the question room later as well, so anything...


And welcome to the show, it's me, John Park. It's time for another episode of John Park's workshop. So you're in the right place, if that's what you thought you were coming here for. Looks like we have good stream health over on YouTube at the moment, crossing fingers. Things have gotten wacky there lately, but we'll see. And I'm also broadcasting over to Twitch and Facebook and LinkedIn and a few other places. So welcome to people over in the YouTube chat. Hey, Devo Dessa and Anthony Vicarra, nice to see you all. And to our viewers that are over on Twitch or other places, Facebook, for example, and you're wondering where the chat is at, you can head over to the Adafruit Discord if you're on a computer. It doesn't usually work for mobile device to watch it and chat, but if you want to give it a try, head over to adafruit.it-slash-discord. Head to the live broadcast chat channel. That's it right there. That's it right there, live broadcast chat channel. My image is mirrored, so it's always confusing to point at stuff on screen. And that's where the chat is happening. So let's see. What else do we have going on? I want to mention a cool position over on our jobs board. So if you head over to jobs.adafruit.com, we have open positions that people have posted, including this one, which I believe Phil mentioned last night. This is someone looking to hire a freelancer to do a prototype of a PlayStation 4 to PS5 custom controller mod. Purpose of this project is to build a PS5 controller from the shell of a PS4 controller, which is a Thrustmaster T-Flight HOTAS 4 using the PS5 DualSense wireless as the innards. So that's interesting. And if you check out the link here, they have a PDF that you can check out with some of the goals for how that's going to work. So it's a typical flight controller with joystick and thrust and some other stuff. And they want to turn that into a PS5 controller. So interesting project if you're into modding stuff, that could be a neat one to look at. So go check that out over on jobs.adafruit.com. The other thing I'll mention right here, right off the bat, is I've got a show on Tuesday afternoons, which is called JP's product pick of the week. And this was the product pick this past week. It's that Metro M4 Express you see right there. And what I like to do is a little one minute recap of the show. If you're not familiar with the show, go check it out any Tuesday, except for next Tuesday. This coming Tuesday I'll be out, but then picking it up again on the 19th. On the show, we usually 15, 20 minutes to take a look at a product pick. Sometimes something new, something from our archive, but you can get at a great, great discount. This one was 50% off this week. No coupon required. It is a discount that is applied right then and there. You'll see the price represented right as you're clicking on it to send it over to your cart. And this was a little recap of this week's product pick. Wait, that's not it. That's just a Metro card. There we go. It is the Metro M4 Express. It's one of my favorite development boards. What we're talking about here is a really fast chip, lots of memory, so it's based on that Cortex M4, that's AMD 51 chip. And it has a lot of great peripherals on it. This case is where I really love to reach for the M4. I'm at the start of a project. I'm maybe not even sure what board I'm gonna use ultimately, maybe not even sure what the form factor is, but I just need to work out some of how things are gonna be wired. So I'll go with one of these Metro M4s, and then in this case, this was when I started working on that PipBoy project. I wanted to plug in the SPI wiring and get this up and running on a board that I can plug things into. I know it's gonna have enough power to do pretty much anything in Circuit Python or in Arduino. The product pick this week is the Metro M4 Express. It was, let's see. Next up, let's take a look at this week's Circuit Python Parsec. I've been doing some display stuff. This one is display-related, but it's actually a little tweak on that formula. So here we go. For the Circuit Python Parsec today, I wanted to show you how to use a touch screen in Circuit Python. This will work with a lot of different displays we have that have touch screens, as well as the bare touch screen driver and element. In this case, I'm using a PyPortal Titano, the big one. So you can see here, what I have to start with is this really cool bouncing logo. As you may know, I'm a huge fan of the TV show Severance, and I was talking with Todd Bott about this. He has a bouncing ball code he likes to use, and he made a little lumen logo to use for our screensaver here. But I am not currently severed. I'm aware of all versions of myself. So what I'm gonna do is take this basic formula and add to it the ability to use it to change the position of that logo using the touch screen element. So touch screen element here can give us X and Y position as well as pressure. I'm just using X and Y. And let's show you first how it works. So all I need to do is touch somewhere on the screen, and you can see I'm repositioning where that logo is. I'm not changing anything about its sort of inertia and angle that it's going at. But if I have it, let's say, bouncing down into the left, and I just wanna speed things along and get closer to the bottom there, I can tap it, just moves the logo to that new position. And in fact, if I click and drag, you can see it, it'll follow my finger around until I let go. So the way I'm doing this in code, first of all, I'm importing the Adafruit touch screen library, and then I do some display stuff, some set up some palettes and set up my logo as a bitmap. But the touch screen stuff is right here. I'm creating this object, I call it TS for touch screen. TS equals Adafruit touch screen dot touch screen, and then we're telling it four pins that it uses, a four wire touch screen. And on this particular board, they're named touch YD, so Y axis up and down, YU, and X right, X left. So those four pins are selected. The calibration values actually are set at the factory, so you generally don't have to mess with those. And then I'm telling it what size the display is. That's all you have to do for setup. Then to use it, all we do is query this, touch equals TS dot touch point. And what that's gonna give us is an X and a Y position on the screen. It also gives us that Z depth, I'm just not showing that here. And then I'm using those to adjust that value that was already in the code for moving this around. So you can use this for things like painting or placing objects or drawing, maybe even changing vertices on vector IO stuff would be kind of a cool use for it. But it is really straightforward to use these touch screens using that library. And so that is how you can use a touch screen inside of Circuit Python. And that is your Circuit Python, parsec. By the way, I just wanted, there was a question, someone was confused in the chat about the discount. So the discount on the, this was when I was playing the one minute clip from the JP's product pick of the week show. The discount is only good during the live stream and that's on Tuesdays at four o'clock Eastern time. So sorry for any confusion there, but the discounts on those are just when the live stream happens. So if you can tune into the live stream or at least figure out what the product is based on tweets and blog posts, you can run over, throw it in your cart and that discount is applied during the live stream only. So sorry for the confusion there, Ham's Labs. All right. So let's see, what else is going on? By the way, I wanted to say, I did this, as I mentioned before, I did this on the Titanopi portal, but this would work on, I have that little TFT feather wing. I've been showing with a feather for a few of these projects and any of our other touch screen projects. I'm excited to actually try out the new Stemicutified version of our touch screen driver board. If you take a look, let me, let me bring up this touch screen breakout. Where's the new one? This one right here. So this is this new TSC 2007 I squared C resistive touch screen controller with Stemicut. So you can see we sell these, I think they're out of stock right now, but we sell these bare elements so you can do projects that are more like a trackpad type of thing, or maybe you wanna hide that under the page of a book for an effect. You can, you don't have to have a display. It's actually the touch screen element can be read using this little driver board and now we have this I squared C version. So you can see in the demo there, it's reading out X and Y on that OLED there on the Feather or TFT. So let's see what is next. Change some screens here. Oh, that's interesting. Dexter mentions in the chat that C Grover made a tool to calibrate the touch screen. I've got to check that out. We bring the discord up since people are chatting over there. Yeah, I looked into it and previously we had a Windows-based application for calibrating some of our touch screens, so that's a drag, but I'd love to check that out. C Grover, I didn't know you did that, very cool. Maybe you can put a link in the chat to that for touch screen calibration. These, by the way, if you're not familiar with resistive touch screens, you go to a large view of that, these are not capacitive touch, so you don't have to use your finger for that. You can use any object here. I've got a big novelty key chain, so you can see this works more like your old Palm Pilot did. It's a lower resolution, simpler and cheaper thing than capacitive touch. Also, Todd asks, is that the one that Liz used recently? Yes, so Liz Clark just made a really cool project that is a, let me hit over to learn. Let's bring up my, if you go to the learn.aderfruit.com and head to the new guide's view, all you'll see this wireless ESP32 S2 touch screen controller for pure data.  It's not a screen. We always call it that. But yeah, it's a trackpad, basically. So it made a really cool, sort of wrist-mounted brass knuckles trackpad, and this one uses that same controller. I just showed there. You can see it on the side there. So that this ConsentX and Y values over to a, I believe she's using a Wi-Fi MIDI for pure data, so you can change values in your software using that. Excellent questions. And, oh good, thanks. Looks like C Grover's gonna post a link in the repo for his Calibrator. Very cool. All right, so what we've got next? After a sip of iced coffee, because it's like 95 degrees here today. Update on the L-Cars panel project. I'll actually jump over here and show some stuff. I am taking another pass at using an LED matrix for it, except I've decided I'm gonna use a pair of our 2.5 millimeter pitch 64 by 64 panels. I wanna get denser so that I don't get fuzzy edges on the L-Cars panel. If you're wondering what I'm talking about, it's this Star Trek display, which is backlit, which is why you can't see it very well right here. I have my little light blockers, and I have in there a couple of pieces of polarizing film, and one of the reasons that I did that is I wanted to take a look at the method that was actually used on the show. I mentioned this last night on the show and tell, and in fact, let me look and see if I can find from the chat. There was a really great GIF animation that Yanisku 7 posted of one of these L-Cars panels on the show. I just wanna show that on here. So let me head to the Discord and look for that. Here it is. So you can see there that sort of pulsing. This is a sort of a ping pong clip. It loops forward and backward, but so you'll see things changing direction. But essentially that panel that you're seeing there is the same as this. It's a vinyl print backlit with polarizing film in different orientations on the back side of that image. And then there's essentially a light box with a spinning motor and it has a piece of polarizing film rotating. And as that rotates, it causes different angle blocking of the different pieces of that polarizing film. So that's a really nice example of you see what looks like some pretty sophisticated animation. It doesn't look like a screen like we're used to. And in a lot of cases, I think in this one, this was done practically on set using polarizing film. Let me jump over to my workbench here and I'll show you some tests I did using some different polarizing solutions. So let me, let's see, where is, there we go, let me, sorry I got to fix a screen that got super big. And out of focus, let's zoom that in. And I have to focus without me being there but I just have to focus on a little wire on my workbench. There we go, it should work. So let's make that just a little smaller too. Oh, sorry I had it resized wrong. So I guessed wrong on what the center of that frame is. Let me rotate that camera a little. There we go, hi Lars. Okay, thanks for putting up with that. So here's a couple things to show with polarization. So I forgot to bring some sunglasses, but one thing you can do with most sunglasses, at least somewhat decent quality sunglasses, they'll be polarized so that they block light that's traveling at some wavelength or some angles rather. If you look at some polarizing film, this is just a sheet of polarizing film. This is also a diffusion film. I have a clearer piece here. This one has some adhesive on it. So here's a piece of polarizing film. You can see it definitely does a little bit of light blocking no matter what. But the more pronounced light blocking you can see is when we get certain angles to match up or not match up. So if you trim a little piece off of this, these were the same orientation, same piece. And then as I rotate that, we get some light blocking. And in fact, if I turn on this light source here, you can see pretty much no light being blocked. And then as I rotate this, we're gonna get a whole bunch of light blocking. There's also some dust on there and things. But this is a pretty effective light blocker at some angles. Here's that bigger piece. So you can see there, it has a lot of junk on this one because it got peeled off. And so that's the effect that's happening is there's a rotating disc that's causing that L-Cars panel to receive light in some of its slots or not. And if you hold up, I'm holding up two pieces right here, you'll see that sort of stacking effect, which is how that animation allows it to sort of travel through multiple sections of the interface. I don't know if they also use a circular polarizer. You can introduce a third polarization angle. And so there are neat tricks you can do if you use a third polarization and circular polarizers. The other thing I wanted to show is another way I've been looking at this is if I take one of our little three-volt backlight LEDs. So this is a little backlight LED. So these are often used behind an LCD panel or other maybe a gauge or something like that. Again, if you take polarizer, you can really block the heck out of that light in some places. So there's a lot of neat effects you can do to break that up into sections. Of course, you can also PWM or on-off these things behind sections. And another interesting thing I noticed is that we have these sort of welding glasses, LCD light blockers. If you give these a couple volts, I think maybe three to five will work. It will turn this very opaque block, block lights, how welding glasses work. But it too is polarized. So if you have one or two of these things or if you have some film in one of these things, you also have some options for both changing polarizations and turn these things on and off. I'm gonna steal my light there for a second and see if I can block that. Let me see if I can, okay. So I'm gonna try to, whoop. So that's the light blocking of giving it current. I can't remember how to get this one to shut its reverse itself. You might have to just reverse the current on that. So those are all some options in that realm of blocking light from a bright source, which is really interesting and obviously a very effective way to do it. It requires some space usually for a motor mechanism if you're rotating it like they did on the show. I showed this last night, but I'll show it again here. This is, you can see here, and there's a lot of light leaking in from all over the place. So this works better if we have light blockers built around here.  So as I rotate my light, which has its filter on it, you'll see the top one go dark and the bottom one go bright, kind of ignoring the stuff that's going on around. But you can see like these numbers at the top, they're staying lit no matter because there's no polarizer there. Or to do it a different way, we can put this film here, we're here and it'll lock the light or let the light through. So that is where I'm at just with some experiments with this. I'm gonna talk to the guy who gave me the panel and see what method he'd ultimately like to go with but I am gonna show a better matrix solution. And also there was a suggestion that Lady Aida had which is using the matrix panel since I with 128 by 128 pixels, I'll be able to get fairly precise and I also have this little light blocker in the back. I may be able to not only animate things in blocks but also pick up their colors, use a matching color which will also help. So this just requires white light coming through but there's a chance that if I also do some color matching I'll get an interesting effect and use less current than pure white because pure white on those matrix panels uses RGB. So you've got like 60 milliamps per LED and I got a heck of a lot of them with 64 by 64. So those are all some considerations. I'm gonna using an external power supply for it. I think a 10 amp five volt and see how that works out. And that'll be with the matrix portal. You can also do this with Raspberry Pi and we have a driver board for that which I'm hoping not to use but maybe it gives you some different options for things like playing a video instead of a sprite sheet. So all stuff to come on the Elkars project. So I was not able to check Discord during that or YouTube chats. So let me know if people have thoughts and comments in the chats, I'll bring those up now. Mike Coderman over on YouTube says, I love those light valves. My daughter made a cool invention from those. Oh, really cool. That's cool. Oh, you short the connectors to turn it. That's right. Thank you. I forgot that's how you get those off. And they can change instantly if you ever used a automated light blocking welding goggles. They, as soon as they see a bright light, they flip. Let's see, let's get down to today's chat here. Oh, jump to the present. All right, Discord. Oh, new gifts from Yanisku. Always worth seeing. He's got stop motion animation of a camera there. That's cute. Let's see. Oh yeah, you can also, someone mentioned, you can change colors. Andy Calloway posted an Instructable on changing the colors of the polarized effect by using packing tape. I believe if you stretch a polarizer, you can make it send through some light waves, wavelengths instead of others. And yes, Sea Grover posted the calibrator, touchscreen calibrator. Excellent. Oh yeah, I knew you had done this. I completely forgot, but now that image jars my memory. Very cool. Let's see, what else? Okay, so moving on then. Thanks for listening in on my progress with the Elkar's project. Next up, what I wanted to do is just, it's more of a show and tell than anything, but also kind of an inspirational project. And I have some ideas of some interesting places to take it. So, those of you who are interested in some of the synthesizer and MIDI types of things that I also am interested in, may be familiar with this project, but it's a really neat one. If you haven't heard of it before, it is called the 16N fader bank. And it's an open source project. Let me bring up a web page here. And let me put me over to the side. What's a good way to do that? I'll just put that in the background there. That's not it. All right, that way it'll work. Let me unplug my lumen screensaver here. So, 16N, a bank of 16 faders. You can see here, this is an open source project. You can buy PCBs, you can buy kits, you can buy assembled ones, you can make your own PCBs of them. I have one because I bought a broken one and fixed it. It uses a teensy 3.2 is what it's designed for. And it uses 16 large, I believe 40 millimeter faders, 10K linear faders. And then the circuit that you build on the circuit board does a few interesting things for you. It mentions here, it sends MIDI data out over USB. So that's right over the teensy. Let me grab mine here so I can show you. I don't have any fader caps on mine, so it's just bare, you'll see, it's just bare potentiometer, slide potentiometers there on the top, move this out of the way here. And you can get different cases for it. I just laser cut sort of a sandwiched case type of thing here. And the USB, there's a little teensy you can see there. So USB MIDI is possible over it. Of course, you could adjust the code. It's in Arduino. You could adjust the code and send out USB HID if you wanted to or other types of serial USB data. It also does a regular MIDI over 3.5 TRS cable. I can't remember if it's the one on the side or the one on the bottom. Yeah, it's the one on the side here. So there's TRS cable. And I think this one has a switch for type A and type B MIDI, which is nice. And it also interestingly has a third jack here, which is for sending out I squared C. And then pretty much everything else about the code is configurable. There's an online configurator. You can use like a little web page, web server thing to say what range you wanna send out from these and what MIDI numbers as well as, if you look on the back here, every single one of them can send out control voltage. So this is really useful for older style synthesizers and modular synths or kinda anything else you have that you'd want a low current, I believe what, zero to eight? No, zero to five volts coming out of. So it does a lot, but it also doesn't do anything until you put something on the other end of it or pick out some software you wanna use with it. So that's the basics of the project. It was sort of birthed on the lines forum, look up lines forum and monome and you'll find people talking about it there. This is the GitHub for it and on here there's the bomb and the schematics and board and Gerbers and everything for making the board as well as the panel if you wanna laser cut that and the software flashing it is straightforward. It uses the Teen Cduino. And what I wanted to do is first of all, just give you a little demo of it and then discuss this I squared C thing because I think it's an interesting idea to see if this could be turned into essentially a STEMA QT quick type of I squared C enabled device to give you 16 faders that you could put, plug right into a feather or a QT pie or something like that. Could be a really cool lighting controller. There's a lot you can do even if you didn't wanna have a computer involved, just by the fact that it has I squared C. Same with MIDI, the fact that it has a serial UART MIDI means that you could read that into most microcontrollers in circuit Python or in Arduino which is really interesting. So I'll give you a quick demo over here. Let me jump back to the work bench and I'll give you a little tour of how this works set that up and do a little bit of audio demo. So I'm gonna move these light filters out of here. And like I said, you could plug this into a lot of different types of synthesizers you can use since that recognize USB host you could use this with USB or rather with UART sort of traditional serial MIDI. Let me put this off to the side and let me brighten up this monitor here too. Whoops. And let me see if you can see if I can yeah, I can probably do what I wanna do with it arranged like this. So there's a funny way to use a laptop. So I'm gonna plug this in over the USB. Where'd you go? There you are. By the way, if you like to fix stuff be on the lookout for broken versions of this because it has a little micro USB controller on a teensy there and nine out of 10 times when someone has a broken one it's because this has been, whoops, ripped unceremoniously off by accident due to do the USB cable and something dropping or getting yanked. So if you're comfortable transplanting a USB connector or a teensy you can sometimes get these broken ones and fix them which is what I did. And I actually have a couple of others coming to fix for a guy who was asking about that. So what you can see here in fact without me doing any noisy stuff if you look in the right side of my interface there you can see I'm moving eight of these faders the faders on the right and that is adjusting the note values of these little modules. So what I'm running here is VCV Rack which is an open source modular synthesizer simulator and it has a module over here on the left. Where's my, where's this cursor? Is this running? Oh, my mouse is upside down. So there's a module here called MIDI CC. Yeah, this is a pain in the neck to use this way I kind of wanted to zoom. Let me, I'll make the view be a little bit angled for a second while I cruise around here. I don't have a mouse wheel on this mouse, unfortunately. So let's see, how do you use this to zoom? Whoa, now I've done it. Hold on one second, let me hold this normal. Not you, not you, not, yeah, there we go. Okay, so yeah, sorry about the uncomfortable angles. So this, focus a little. Okay, so this module here is just a USB MIDI to CC thing. So this is bringing in the channels of this fader here and what I can do is say on one of these slots, what MIDI CC value I want coming in and then just wiggle one of the controllers. This is a pretty typical way to teach MIDI channel information to a piece of software or even the hardware is just to choose one, put it kind of into a learn mode and then wiggle something and says, okay, I get it. Anything that changes on MIDI CC 95 is gonna be used there. What it's then gonna do is take the values that are sent from this, which are zero to 127 and convert those into, I believe by default, zero to 10 volts in here or zero to eight volts, something like that. And then you can use other modules to change that, clamp that, invert that, do all sorts of fun things. But what you'll see on, let me turn the volume off on this, you can see it on these first ones. So as I change this fader, it's translating the zero to 127 to essentially a zero to one on a knob for letting sound through or zero to 10 volts or however you wanna express that. And so all of these are connected here and live for changing values on this. What I'm, let me see if I can zoom, oh, not that. Zoom over here, that'll work. Okay, that's a good view of that. Sorry, that was the view of the back of my head. Let me push this up a bit. See this here. So what I've set this up to be is I have eight different oscillators that are making a sine wave sound. And so I can change the mix or the volume essentially of that with my first fader. And then with fader number nine here, so it's my second set of eight, I'm changing the pitch. And I've decided to put this through a quantizer so it locks it into a chromatic scale. So what I'll do is actually put all of my pitch faders up to roughly that area. And then I can start bringing those in this volume up. So you can play it, essentially as a drone can also go in and change the pitches. And you can see here, these ones on the right are flipping through octaves as they go. So if we start one at the very bottom, it's gonna go through 12 notes and then second octave, third, fourth, fifth, sixth, seventh, eighth, ninth, and 10th. So that's the 10 volts.  So very high pitch you might be able to hear. And that needs more volume to hear. It's pretty low based stuff there, sub audible at some point. So you can of course go in and do kind of anything you want that you want controllers for either in VCV Rack here or other software. It's fantastic for things like mixers, right? And that's how I'm using these first eight here as as mixers. If you're doing any kind of stuff in a digital audio workstation, a DAW, and you wanna be able to change faders, you can of course get software that'll convert MIDI into other things. So you could use this in your video editing software. You could use this in your lighting package, like Lightroom has a good MIDI to Lightroom plugin. I've shown that before. But the real versatility of this is you can go and buy commercial things that do that. There's a nice little eight fader corg thing for like maybe a hundred bucks or less. Nice thing with this is you can customize it to your heart content with code in Arduino. You can also send out different types of outputs. So control voltage right out of the back here.  So I'm gonna be done with the audio demo there.  So let's see, I have somewhere around here, I hope a cable that will let me, let's try this. I wanna, cable that'll let me break out my TRS or right, TR rather. And oh, did I leave all those inside? I may have. All right, we'll see if we can just do it with a regular patch cable type of thing. So each of these have a, it's a TR cable coming off of here. So it's essentially tip ring. So it's positive voltage on the tip and ground on the ring. So I'm gonna have a cable here that's at least it's mono on one side. This should still be on yet, even though the laptop's shut, I think it's still getting power. So if I take a look here at my meter, we should have, let's see, there we go. So about five volts, four, three, two, one, zero. So we've got 16 channels of that now. I don't think you're gonna go driving motors with those or anything, I'm guessing they're incredibly low current. But if you're able to read analog signals directly on your microcontroller, if you've got a lot of pins and you want to just read straight analog from voltage with this without taking it apart and reading the pots themselves, that's a possibility. And like I said, the other really interesting thing is that we have this I squared C coming out of here. So there's not much info online about the I squared C protocol that's being used here was designed for some of the monome devices. I think Ansible and Teletype and Crow. There's a few of these synth modules from monome that talk to each other using I squared C. But if you do get info on that, and I think it's all open source, you should be able to, you could ostensibly write either an Arduino or a circuit Python library to read that particular I squared C and now you have essentially a 16 fader I squared C board, which would be incredible to pair up with something super tiny like a QT pie and be able to control neopixels or something like that using all these faders, which I do agree I need to get some fader caps for. I think I might just get the little, just like some small little rubber colored ones that thunk synth in the UK sell and you can buy them anywhere, but shout out to them because they're cool. So that's the basics of this 16N. I just wanted to show it more of a gear report than anything, that's one that I was able to resurrect from a broken state and enjoy. And I think even if you buy one new, they might only be a couple of hundred bucks for a kit. I'm not sure about a built one, but they are super cool. So let's see. Todd Bott says he uses his laptop like that more than he should admit. Okay, so there's a link in our discord here to the, oh, so scanner darkly who's active in that community wrote the teletype wiki entry on this protocol. So I squared C in that world is called II, just to confuse me, but yeah, look at the 16N fader bank source and you might find some good info on that there. So let's see. Mike Cotterman says he used to pretend I was using the transporter on Star Trek with those faders. It all keeps coming back to Star Trek. So let's see, what else? I think that's it. You've seen, I don't have it here right now, but I've built a four fader using our Stemacutee neo fader sliders, which are all speaking I squared C to one another. So there are options there. In fact, let me show you that guide if you're wondering what I'm talking about. So if you go to learn and type in fader, how about not fander, neo fader, maybe it's neo fader, neo slider. There it is. Okay, so there's the neo slider itself and this one does not have any lighting on it. The one I built, you can see here, I built myself a very similar design and I put in a set of keys on it. That one has those four neopixels underneath so you can do some fun effects with that, but that was heavily inspired by this 16N, so all credit where it's due. 16N is super cool. And basically a project that came out of the forums over on Lines. Some people said, hey, what if we build this? And they did and it's still running strong. So that's about it. That's gonna wrap it up for today. Thank you everyone for stopping by in the chat. I will be out next Tuesday as I mentioned, so there will not be a product pick of the week on Tuesday. That'll be back on the 19th, but I will be back here next Thursday for another John Park's workshop. And I should have some 64 by 64 times two L cars, RGB matrix madness to show you. So that should be a lot of fun. Thanks everyone for stopping by. I will see you next time, Fraterford Industries. I'm John Park and this has been John Park's workshop. Bye-bye.


Hey, what's up? It's George Lopez. So this Sunday evening, I'm teaming up with representatives and friends like Dave Matthews, Ed Helms, Jennifer Lawrence, Cia, Nick Corral of District and myself, others. And then we're going to do something very important. We're trying to protect the 2020 election. We're doing United to save the vote because it's a virtual comedy show, it's a music show because we need to raise the awareness and make sure that all Americans get a chance to vote during the pandemic, during all this COVID-19 wild times that we're living in. We have to vote like our lives depend. That's dramatic. I was a bit dramatic when I was a kid. So we just want to make sure that we protect the rights of all Americans to vote, whether by ballot or in person, and that every single vote gets counted. So join me online this Sunday, August 30th, 8 p.m. Eastern, 5 Pacific for comedy and live music as we fundraise for vote safe and making this all possible. Please tune in. It's going to be amazing. So you don't want to miss it. So RSVP now, www.represent.us slash save the vote. That means like really good.