started. So thank you for joining us today. I'm Cliff Lynch. I'm the director of the Coalition for Networked Information, and I'll be introducing this session. You have reached the first of the project briefing sessions for week four of the CNI fall 2020 member meeting, which is taking place virtually. Just to remind you, week four is a collection of project briefings that deal with responses to various aspects of the collection of crises that we're trying to collectively navigate our way through. So you're going to find quite an interesting set of narratives and experiences shared in week four. I want to remind you that along with the synchronous sessions that we'll be having this week, we also have released a small number of additional pre-recorded videos that I invite you to explore. As to the logistics for this session, we are recording this and it will subsequently be publicly available. There is closed captioning and please do turn that on if it's helpful to you. There is chat and feel free to use that as we go along. There is also a Q&A tool at the bottom of your screen. After the presentation, we will address as many of the questions as we can, and that will be done in a session moderated by Diane Goldenberg, Hard of CNI. So with that, let me turn to the current session. We have with us today Michael Chensky from the libraries of the University of Texas at Austin, and he is going to speak to an aspect of what really has kind of emerged as a theme from this meeting, which is all of the spaces that we have in our libraries and more broadly in our institutions that were designed and staffed and programmed for physical presence, and how we extend those services, adapt those services to the digital environment, things like computer labs, maker spaces. There's a great range of these kinds of situations. Today, we're going to hear specifically about GIS services, and we're going to hear, I think, not just about the response, but also about what the experience with the response has taught UT Austin about how they should be thinking about the future as we eventually come out of this pandemic. So with that, I would just like to thank Michael for joining us and turn it over to him. All right. Thank you for that excellent introduction. I am Michael Chensky, the GIS and geospatial data coordinator for the UT libraries at the University of Texas at Austin, and I will indeed be talking to you all today about how we have adapted our library's GIS services in the past nine months or so since we had to modify our operations starting in March of this year in response to the pandemic. And I'll be discussing some of the challenges that we've encountered, some of the changes that we've made and discuss how we are starting to plan for the future looking at spring of 2021 and beyond. So first, I'd like to give a brief introduction to our core UT libraries GIS services to give everyone an idea of what we had going before the pandemic, our core focus of what we were providing services to the campus community, because these are things that in many ways had to change and be adapted to this new environment that we found ourselves in starting in March. And so unfortunately, we don't have enough time today to touch on every aspect of our GIS services. And so I really wanted to focus on the services that are more core to our mission. And those are developing geospatial research guides using our LibGuides platform that we can use to provide instructional materials to help researchers, students, faculty, staff on campus who are dealing with common geospatial research issues or questions, installing GIS software, finding geospatial data to use in research projects, those kinds of things. We also have a Texas Geodata portal. This is something that we released a little over a year ago in November of 2019. And this is the platform that we're using to make geospatial data from our library's collections available to both the campus community and beyond. It's publicly available. We're openly sharing currently all the data sets that the UT libraries are making available through the platform, which is about 700 or so. And we're also, through this platform, providing access to thousands of other open data sets from other institutions that openly share their metadata, which makes that possible. We also offer research consultations. So this is a core service that I've provided in my position, basically meeting with any folks on campus, again, whether they're students, faculty, or staff who have questions about how to move forward with geospatial aspects of their research. So whether they're dealing with a software issue, encountering an error message, or trying to figure it with software to select, or they're trying to find data that's a bit difficult, or they're trying to develop a plan for disseminating the results of their work through an interactive web map or maps that they're going to publish. Those are the kinds of things that I'll usually be helping with in research consultations, which have traditionally taken place in person, one-on-one meetings on campus in the library itself. And we also lead GS workshops and other types of geospatial focused events. So in that picture, you see me with a slightly shorter hair from last year at GIS Day, where we were leading an event, giving an introduction to GIS and our new GeoData portal. And we also regularly lead workshops, usually at least a few each semester focused on GIS or related technologies that are designed to help skill up our campus community and provide these opportunities to learn about GIS and other geospatial techniques outside of a full semester academic course. And so prior to March 2020, all of these services were either offered or developed on campus. I really, prior to March, didn't have any experience working from home in this position. And so it was a big change to go from not working at home at all, working exclusively on campus to then working exclusively at home. And as the GIS and geospatial data coordinator for the UT libraries, I am the main GIS person for the libraries. And so figuring out how to adapt our services to meet the needs of the campus community in this new environment, that largely fell on me to put these pieces together and figure out how we might be able to make sure we're continuing to provide the support that the campus needed. In terms of the impact of the pandemic on our normal library operations, that the campus had to make some significant changes to make things safe for everyone. Starting on March 16th of this year, we shifted to basically a mostly remote learning environment. And that has continued to the present with some classes going on on campus, but much more limited than what we would normally see. The libraries have also adapted their operations. So most of our branch libraries have closed and remain closed. Our main library, the Perry Castaneda Library, which we see pictured in the top right of this slide. It has an occupancy cap that we can see there in the center of this slide. Screenshot taken from yesterday where we had 86 folks in the building out of a max of 400 that we can support. Our libraries hours have been reduced slightly from what they are in a normal semester. And the unit I am in, scholarly communications within our libraries. Our staff are working almost exclusively from home. And as I mentioned, I personally haven't been to campus since early March of this year. And I've been working from home since then. So a lot of changes both for us in the libraries where we've had to figure out how to do our jobs and develop our services in a way that they can be offered remotely. And also, adaptation for our members of the campus community who have needed to find new ways to access these services. And so it's been a negotiation where kind of adaptation all around. And we're really trying to meet the new needs of the campus community as best we can. And so starting here with a focus on our research consultations and how this has changed since the start of the pandemic. As I briefly mentioned before, pre-COVID almost all of our consultations were in person. We see a picture there in the top right of our consultation room in our Perry Castaneda Library where many of these consultation meetings can take place where we have a whiteboard. We have a screen where folks can connect their laptops and display their screen upon that larger display there. We have multiple chairs where we can fit five, six, seven people in the room if necessary. Usually most of our meetings are one-on-one or meeting with maybe two other folks for a consultation to discuss a research project. But since March, all of these research consultations have been conducted via Zoom. Zoom was something that the libraries actually got started with also in March fortuitously. The timing of that allowed us to shift very quickly to this all virtual format. And there's been some advantages to this, surprisingly. And that's one of the things that I kind of want to highlight with this presentation is that usually when things are upended and disrupted, right, there are these challenges we face. And sometimes that means we can't do things quite as well as we used to before we encountered those challenges. But one of the overall lessons I think that I've learned in this position over the last nine months or so is that sometimes being forced out of that regular routine leads to innovations and discovery that sometimes doing things a bit differently can result in positive benefits for everyone. So some of these benefits that I've noticed from the shift all virtual research consultations include greater flexibility for earlier late consultations. I've had consultations as early as seven in the morning and as late as nine o'clock at night in cases where I'm in a meeting that is bringing in research collaborators from other time zones. So I've helped folks at UT in our research community who are collaborating with others in the UK and Australia and they wanted in some cases those collaborators to join our research consultation in this virtual environment that's possible much more easily than it would be if we're having to meet on campus in the way that we used to let's say last year. And as I mentioned here, it also allows out of area collaborators to attend. So we don't have to be on campus to get these researchers together. We can all meet virtually and everybody is so used to working with Zoom or similar platforms that that I think is easier to do than it would have been a year ago if we tried to have an all virtual meeting where not as many universities subscribe to these types of services and folks weren't as quite as used to using them. We also developed a more efficient scheduling process via our main UTGS services live guide which we see pictured there in the bottom right. So there's now a scheduling button. So this was technically possible before the pandemic. The pandemic definitely provided an impetus to get some things done that were on the to-do list but slightly lower priority. And so there was also this drive to find new ways of increasing the efficiency of our operations and making it easier for folks in this new environment to access our services. And so this is one of the things that we were able to get done really quickly after the start of this shift to remote learning. And it's expected these virtual consultations will continue in the spring of 2020 and it remains to be seen what patrons will prefer after that once we're able to return to normal operations. Will folks want to meet in person or will there actually be a preference for virtual meetings because everyone's so used to that via Zoom and because folks don't have to run across campus to meet in the library. They can be at home, I can be in my office, or I can be at home if I'm working from home and we can all still meet and provide those consultation services. So there are some limitations here where things are in some cases maybe a little bit more difficult helping with coding challenges or software installation compared to if we're there in person but in many cases it's perhaps slightly better than it was pre-pandemic because of these changes we've been able to make. And interestingly the number of consultations has actually increased year over year. Many of the questions that we've received since the start of the pandemic are actually very similar to those that we received pre-COVID again. How do I access or find a certain data set online? How should I develop a script to automate this process that I've developed for carrying out my analysis? How do I make this reproducible? Those questions continue to come up just as they did pre-COVID. And interestingly software installation and access questions are not as frequent as initially feared at the start of remote learning. We thought that might be a challenge that folks would face if I'm not able to come to campus like they used to to access GIS software and other similar GIS geospatial software but UT Libraries has started providing geospatial software access through virtual machines. We're using Apache Guacamole to provide access in that manner and we have detailed GIS software installation instructions through our lib guides that's something we've had for years and I think many folks are used to using this to learn how to install the software and so these types of questions really haven't come up all that frequently which was nice to see. One of the other things that happened this year in terms of event planning was a shift from how we have approached GIS Day previously and started to collaborate more with outside organizations and institutions that are also involved in the planning of GIS Day events. So 2020 marks the second year that UT has organized GIS Day events. Our first large-scale GIS Day celebration on campus was last year which the UT Libraries participated in along with our Technology Resources Department and we developed a whole series of in-person events in November of 2019. It was a great experience. We planned to do the same thing in 2020 and of course that plan kind of went out the window in March when everything had to shift to virtual and so in the spring we started to plan for a virtual GIS Day. We realized that because everything was virtual that this would open up the possibility of collaborating with other institutions outside of our local area who are also going to be forced to do everything virtually this year and what ended up coming out of this was our participation in Texas GIS Day. So this is really it was a series of three days of events that took place just this last month, a few weeks ago in the middle of November and we collaborated with Texas A&M, University of North Texas, the ATX GIS Day planning group, Houston Area GIS Day planning group, really these folks from many different institutions and organizations who are already going to be planning their own virtual events. We all came together to utilize the shared platform that Texas A&M had developed to allow us to collectively promote our events through this one website, this one platform and this ended up being really effective. It's unlikely I think that this would have happened in quite the same way if 2020 was a normal year and everybody was doing in-person events locally on their own campus or in their own venue and because everything was virtual we were able to come together and promote our events and collaborate in this way and it was a really positive experience we're already starting to discuss how we can continue to collaborate on a Texas GIS Day in 2021. So these discussions are just starting up now as we look forward to next year. Continuing with this theme of collaboration that are changing operations this year have really facilitated in some ways. Again this is somewhat of a positive thing that's come out of our changes that we've had to go through in response to the pandemic. I'll mention that pre-COVID there were some attempts that we had made of the UT libraries to try and build community with some of our other peer institutions across the state of Texas to build community, build connections. I know I visited Texas state soon after I started in my current position in 2018 to get to know folks outside of just the UT community but also learn what other universities in the local area were doing and we also scheduled conference events. We had a session that we branded as a GIS Birds of the Feather Session at our Texas Digital Libraries Conference in 2019 and we had a few folks coming from other institutions who attended it was an early morning session. It was a nice opportunity to talk about what we were doing with GIS, other institutions were doing with GIS but it didn't really get a critical mass. There wasn't a lot of momentum that came out of that and so in this year we were planning to do another similar session in person in May of 2020 that conference was canceled because of the pandemic and so we ended up kind of shifting gears and doing a virtual Birds of the Feather Session inviting folks from all of these other institutions across the state who are members of the Texas Digital Libraries to join us for a virtual Zoom event to discuss GIS services and there was great interest. I think we had over 40 attendees on that call, a far greater number than we saw in person the previous year and as a result we were really able to build some momentum. We formed a GIS interest group in July that was organized by the digital libraries and supported by the Texas Digital Libraries that many of our Texas universities are members of and within the span of just six months we have developed a group charter. We've organized two webinars providing introductions to GIS and GIS services that libraries can provide. We have four standing subcommittees working on things like event planning, data collaboration, developing a survey to gather information about what institutions across the state are doing with GIS and a mentoring subcommittee as well. We have over 20 members who are regularly attending events and they're coming from over eight institutions across the state of Texas so overall this has been a big success. I'm not quite sure that this would have come together in quite the same way if it had again been a normal year. I think this is something that really came about partly through this shift to these virtual types of events and everybody getting used to working and collaborating virtually and we now have monthly meetings. We're already scheduling multiple events out into 2021. We're developing a survey to distribute to universities across state of Texas to learn more about what they're doing with GIS services and we're already starting to plan for ways that we can collaborate more around sharing data. One of the other things that was upended in March when we had to shift our campus operations was planning for a new scholars lab that we were envisioning going into our main library, the Pericastinata Library. This lab space can actually be seen in the lower left there. That's what it looks like currently. Well pre-pandemic probably not quite as busy today but an implementation group was formed in early March 2020 after funding for design and construction were approved so the idea was for us to be able to revitalize that space seen in the current left bottom left of this slide to put in a new data lab to provide a new environment to build actually some of the themes that we saw emerge from the fall CNI presentations earlier this semester about library spaces that can help facilitate the building of community on campus, help promote library services like GIS services and we really wanted to leverage this opportunity to revitalize this space that's at the entry level for our main library to help promote many of our services including GIS services and develop new programming for the space. So it was really envisioned as a space that we could use to take our GIS services to the next level. Funding unfortunately was put on indefinite hold as of May 2020 due to COVID budget impact, something that wasn't a big surprise once we saw how dramatically everything was being affected by the pandemic but our interest in pursuing a revitalization of this space is undiminished so we're hopeful that at some point in the not too distant future these funds will become available again or will be unfrozen and we'll be able to continue to move forward with planning and eventually construction for this space. One of the things that the pandemic has given us an opportunity though to reflect more on is what a post-COVID lab space should look like and what geospatial services should be offered. So how has the pandemic changed the interest perceptions needs of the campus community and this gives us a chance to while funding is paused to reflect on those things and maybe design this space in a slightly different way than we would if you know we had embarked on this effort two years ago pre-pandemic right I think we will be moving into a different world where folks have slightly different needs than they would have before the pandemic. So hopefully we'll be able to move forward with that soon. One of the other things I also want to make sure to mention during this presentation today is how we have adapted our geospatial research workshops to this new environment so pre-COVID all of our workshops were in person and so we have a regular semester workshop series that we have branded the data and donuts workshop series usually when folks attend in person they're able to grab a donut that we provide and sit down for an hour and a half to learn about a new technology or a new research technique and our traditional schedules for the fall workshops to be general research data management type workshops and for the spring workshops to be focused on GIS and geospatial research in particular. So with COVID all of this was somewhat upended our spring 2020 workshops somewhat fortuitously happened to end really the week before everything locked down so those took place as normally scheduled in person. Our fall 2020 workshops had to be conducted very differently they were all virtual via zoom we used the zoom webinar format to provide these workshops the same format that we're using right now in zoom and workshops were designed to highlight things that were going on on campus like UT COVID research to highlight other services that we wanted to make sure folks are aware of like our Texas data repository. We had four workshops that were scheduled from 12 to 1 on Alternating Friday so this is a slightly different schedule than we would usually have for our in-person workshops we shifted the time earlier on Fridays we didn't do back-to-back weeks we wanted to get ourselves more flexibility to assess how things were going in this new virtual format and the webinar licensing on our campus was a little bit complicated to work out but the webinar format ended up being great it worked really well. What we noticed from this is that attendance actually was much higher than usual in a normal semester maybe we see 30 to 40 attendees per event this semester we were seeing 70 to 50 attendees at each of our workshops and so really the the shift virtual again ended up being in some ways slightly positive for us where we were able to reach a larger audience than we could before and we were really interested in learning more about why that that was the case we distributed a survey after the series wrapped up this semester we were able to gain some interesting information that I'll mention here more in a second and our workshops for 2020 will continue to be virtual again based on the success we've had clearly there there is interest in these types of virtual events we're actually going to be increasing the duration from one hour workshops to one and a half hour workshops based on some of the feedback that we've received and it'll be interesting to see what happens post-covid once things are able to return to normal in-person events become a possibility again what does the campus community want to see do they want to see a mix of in-person virtual events do they have a strong preference for one format over the other so that's something that we'll have to to figure out as we move forward into the future and hopefully the pandemic recedes right we're able to at some point in the not too distant future resume normal operations I also want to briefly mention I know I'm running a little short on time here the Texas Geodata Portal stuff is to say that basically things have been able to continue with our portal really in much the same way as they would have if you know the pandemic hadn't ever happened we hadn't had to change our operations use of the portal has continued to increase as we see in the lower left there we've continued to add new data sets to the portal to build out our offerings adding new data sets from our UT libraries collection so development and use has continued to grow even during the pandemic which is great and one of the final things I want to wrap up on here is how we've been able to leverage these changes that we've made in the last several months to carry out additional assessment and collect new data that can be used for assessment purposes and I personally felt that this kind of there was more urgency around this once we moved into this new work from home environment where you know we're not there in person there isn't this same level of you know everybody's seen what we're doing and seen the things we're working on and so being able to document that with data seem particularly important and so what I one of the things that I've done as time is permitted was developing some new scripted methods of gathering data and analyzing data that is just being generated through these virtual events that we're doing and other things that that we're doing now in this new type of working environment so writing scripts to track how many reference emails I'm sending consultation tracking the analysis of zoom statistics so how often am I scheduling consultations how many people are attending how long do those sessions last how many data sets are we contributing to the geodata portal how is the the use of the geodata portal increasing and for our data and donuts workshop series because folks were signing up for that through a registration page we're able to gather new data there that wasn't possible before when those workshops were just dropped in there was no pre-registration and we're able to to see get a better idea of our audience so is it mostly faculty students staff who's attending what is the the average rate of attrition from registrations to actual attendance and through our survey we're able to glean what folks are interested in seeing in future semesters and I know I'm out of time here so I'll wrap things up and and open it up for questions I've also included a few links here that point to some of the resources that I've mentioned in the talk and I've also included my contact information if anybody would like to reach out and ask after our presentation about any questions they might have thank you oh thanks a lot Michael that was really interesting loved hearing about your new partnerships and new opportunities that you all have experienced as a result of the pivot you that took place in the spring as you mentioned we are at time but I want to be able to get in at least this one question that we have which comes to us from Joan Lippincott who asks do you have any initial thoughts on how your thinking has changed about your plans for your digital scholarship physical space so we we did receive results from I believe eight faculty members who are teaching geospatial or GIS courses on campus and we're able to use that information to get some better insight into what was of greatest importance to to faculty that are involved in that type of work on campus and there there is interested in a virtual lab environment right where we can provide access to software outside of the lab space but there's still strong interest in seeing you know high-end computers that can handle you know the type of intensive geospatial computation that's required for many of the research projects being carried out on campus we were able to get a better idea of you know what folks are looking for and in terms of that the hardware that they want to see in the lab what is of most importance right if we have a fixed budget how should that that be spent on computer resources again if we're focusing on supporting the needs of geospatial researchers which are just one segment of our overall community that we're supporting and consultation spaces co-working spaces those were things that that we've also had discussions about that I think well maybe need to be designed a bit differently than they would have you know pre-covid how much how many seats do we try to put into a lab how close do people want to be when they're working together and how can we maybe facilitate you know in-person events that are also maybe able to be streamed virtually right so there there does seem to be this strong interest in virtual events that folks can attend even if they're not able to be on campus at a particular time these are all things that I think we're going to need to to discuss further as we resume the planning process and again once that that funding is freed up again that I think those will be some of the conversations that we have and start to think through how we can still use this new space to really promote our services and provide the things that the campus is going to need moving forward in this really this new environment this new era that we go into post-covid to be sure okay thank you thank you so much thank you Joan for the question and Michael thank you for answering that and seeing as we are a little bit past time here I'm going to go ahead and turn off the recording and just bring the public portion of this to a close thanking our presenter Michael thank you so much for joining us at CNI and all of our attendees but Michael's going to hang around a little bit and chat with us I know I have more questions I imagine some of you do as well so if you have the time and would like to stick around and join the conversation just after I turn off recording raise your hand I'll be happy to turn on your microphone thanks so much everyone we hope to see you back at CNI bye


Hi folks, I'm here at Monday again and today we're going to be chatting with Matt and we're talking sci-fi and everything all Warpath universe So Matt, I think the best way to do it is we break it down by game system. Let's kick off with firefight What can you tell us about that? Well, if I said a really great year Yeah, it's exploded off the back of last year where You know we'd kind of we'd launch the game it got out there We got some some great reviews great response to the game itself, you know everyone love the mechanics It won game of the year. Yeah, which is it was fantastic accolade and You know we people were starting to do not just give feedback from from their games at home But we're starting to get events and tournaments and the things you want to kind of foster a community and build a game system We've developed an art a rules committee You know off the back of the work that Andy had done on developing the game in the first place And and from that we looked at issues it actually there's there's you know There's that there's a great core of a system there But what we really want to do is take this to the next level go back and look at it again and say okay Let's let's do an update and it was initially it was a bit of a bit like Clash of Kings for Kings of War So we'll go back over the units and do it and annual balancing and sit and we looked at it And so actually there's there's some bits with the rules that we could we could adjust as well and make this a game Absolutely knockout. Yeah, which is which is what where we ended up So we work with her with the rules committee and Incorporating some of Ronnie's crazy ideas of course because he wanted a massive tank game and everything else and obviously put that through the filter and say Okay, what what can we really do? So we build that in as well as a whole ton of new vehicles and Upgrades on the existing kits and new things as well And I think what we've ended up with at the end is is is phenomenal Yeah, and all of that kind of that that polishing and not enough the hard edges and stuff is all part of the command protocols They're released. Yeah, that's it. And obviously, you know one of our grand plan last year was to have a Rulebook and a force list book and so that we could do the force list separately And of course then we came to it and said actually we want to change a lot here And so we've mashed them all back into one book So, you know best laid plans and all that sort of stuff But yeah, that's the command protocols book. So that's that's now firefight for that's that's the baseline now for Taking things forwards, you know and some of the stuff that we'd learned with the with the first edition just in terms of presentation If you look at the packaging we've done for the vehicles that we had before We've done a lot of work with we'd taken photos and then we've done a guy called Scott done paintovers over the top You know Environmental effects, you know muzzle flashes all that sort of stuff. We wanted to continue that especially as we were doing more vehicles Yeah, so, you know, we've done a lot of work A game with Scott and Ben our own photographer on You know, how we do that presentation and I think that the vehicles again I think it was the next step up. So we've carried that thing through but I think it looks brilliant Yeah, I think it's one of those things where when you if you start with the end goal in mind And knowing that you're going to do that now you take the photographs with with that as opposed to kind of Here's a photograph. Can you do anything with it kind of thing? But yeah, I agree. It looks fantastic So you touch there briefly that command protocols now is the kind of is this is like the bedrock now for going forward So what's coming up then? Well, we've got so if you've got a command protocols book and you're an enforcer player You'll have seen that there's some units in there that were brand new. Yeah We've got the models for those coming out in December like the Nova shock troopers and there's a Sniper platform kind of a big big heavy-gun thing Phase claws for both peacekeepers and enforcers which have been kicking around in the army lists and dead zone 2 for forever Yeah, we've never actually in fact the models were sculpted ages and ages ago It's just they've never made it made it out to retail. So they're coming out as well And and some of the little enforcer drones that were available I came out in the Pathfinder strike force that we did yeah with the with the warlord Drone they're available now separately as well. So that's a kind of a neat little package for for Enforcer players to fill out those those units that they've seen and probably thought well those look great No, you've got the models fantastic So that's back into this year. You said December. Yeah, any thoughts on 2024? yep, so think we can reveal now for early 2024 is that Maison labs have been tinkering as they always do they've opened opened a rift Easterly closed again, but it's too late and the the space the dark matter whatever you call it the void that crosses times dimensions Galaxies everything else they've created a rift into and they've let out the night stalkers So the night stalkers will will make that jump from from Kings of War universe into the into the firefight universe of the Warpath universe team Yeah, I can definitely see them coming over of kind of of all of the different armies that Monday do I can definitely see where night stalkers really fit into that and they look really different once they're on Also on round bases and they're separated out. We've gone a completely different quite an alien More alien paint scheme for them. Plus we've they've got different some different upgrades They've made them some more range weapons more more sci-fi and we sculpted more models for them as well Which won't exist in Kings of War, but we'll be part of the firefight army Yeah, including some quite you know quite big flying piece as well, which is which looks quite nasty Exciting I'm looking forward to seeing those come through So is that is that a kind of the that's what you've got on the planet That's what you can tell us about so far. I can tell you about obviously we've got ideas moving moving forward and that army Refreshes and other things that are coming out looking at more hard plastics and things like that for the firefight So, yeah, it's it yeah, it come protocols was the baseline and which is which is going now No, you kind of you've got the rules down now It's just kind of full steam ahead with it with the models now. Yeah, fantastic So moving over to it. It's smaller, but slightly older brother now dead zone. Yep Dead zone is kind of being a little bit quite of late. What's what's what's kind of on the cards? Yeah, I mean good. I think because of the focus on firefight, yeah, kind of resource-wise was stepped away. Okay, look at the bigger picture listen look at that game But now now that's done and we've got a plan for that game forward We've we've can focus back on the on the on the smaller scale thing again So we've got some great new content coming out in the companion around Christmas time excellent Updates for just subscribers and for everyone so which I think will be great obviously they'll The new dead zone Rules for the enforcers. Yeah, those enforcer models. They'll get those night's talkers too. Yeah, you'll be able to play night's talkers in both games So those those releases will come out kind of in tandem at the start of the year and then again, we've got Some ideas for me for what to do mid-year in terms of some some new factions and things like that as well So there those things are in in planning or with with RCs or sculptors or that now So some some great stuff to come out exciting. So let's look forward to for dead zone as well I think it's one of those games that is It's a great kind of stepping in point as well as if you're a more of a sci-fi gamer than a fantasy gamer It's a brilliant stepping in pointing to mantis kind of range of stuff as well So seeing those extra stuff coming through it. It just brings it front of mind again to people doesn't it? Yeah So, yes, that's kind of mid-year next year. Did you see it roughly? So obviously the night's talkers in tandem in the start of the year. Yeah, and then mid-year Summer-ish time will look at some maybe a new faction and maybe some refresh of stuff Some new models and things for some of the existing things. Yeah So, yeah, so not long not long to wait exciting Yeah, I look forward to see that as well And I guess we couldn't talk about sci-fi stuff without talking about the the announcement recently about warpath Obviously, there was a lot of buzz about it when it was announced and I really appreciate from you guys as well Kind of sort of put it out there and see more people think about it So what can you tell us about where warpath is now? So warpath for if anyone doesn't know so if dead dead zones the skirmish scale Warpaths Firefights kind of your next step up. Yep toon squads, you know, some a couple of vehicles that kind of thing or millions of vehicles if you're only The the next step up is those are those epic things so everything's set in our warpath universe Yes, that's kind of what we've called it what we coined it So all those stories are told in there all those factions live in there, but Ronnie's idea for warpath was always that it was a big epic game Originally it was conceived as being you know at 28 mil scale and you just get everything out But actually we just don't bang so well we've got to 28 mil games we've got we've got dead zone We've got firefight, you know, wouldn't it be better if we're actually to represent those those those epic Encounters we reduce the scale so you can have you can have play on a similar sized table You know, it's not you're not having to get all your mates around to get everything out You know, and it becomes less of a you know once every three months event And something you can play in an evening like any other like any other game. So that's where we went So we started looking at that So it's messing around with scales and things like that having to go looking at the rules What would they look like and then and then, you know, we put it out to the community and said this is as far as we've got Yeah, this is what we want to do. This is what we were planning. This is where we want to take warpath itself as a game And what do you want to do? What do you think? You know, which which which direction should we take this in terms of in terms of plastic STL resin some kind of mix Etc. Etc. So we put up a survey public survey And huge number of responses.  I think we had over 2,000 which was just incredible And the overwhelming response was yes, we want this to go for it So that's what we're doing. So We will be going to Kickstarter which which you know as part of the responses people said, yeah, absolutely Just just go for it You know fund as much as you can so we will do so it'll be a Kickstarter again q1 next next year Hard plastics. Yeah, let's get those funded and Yeah, and we'll cover we'll cover certainly four races to start with and I think we've talked about these It'll be the plague the enforcers will look at it will more of the alien races like the Asterians and Forge Fathers Yeah, obviously as the funding carries on going we can start to look at the world. Yeah, but we'll do all that in hard plastic Hub we look and got terrain coming as well Big part of the response was from the 3d printing STL crowd So obviously, you know, we'll look at what we can we can do around that as well to layer in on top of On top of the plastics or whatever that is Yeah And then we've got our own residents and everything else.  We we can't look at New factions that we haven't done in by far. Yeah, of course Yeah, you know, there's there's so many possibilities I think that the response from the community about like you see the survey alone How many people signed up for that the the chat are online and people talking about it There's definitely interest in this game Absolutely And I think the fact that you guys are then backing it up and going to Kickstarter with it early next year Which isn't just around the corner to be fair. It's not very far away So, yeah, if if this is something that you want to see happening You want to see happening in a big way sign up for that Kickstarter when it happens back it and make sure that it funds and You'll certainly be able to get your hands on some amazing stuff Yep, absolutely. So it looks like from a sci-fi point of view. There's plenty happening Yeah, yeah, I don't know if it matters whether you're a firefight fan.  There's definitely something happening in the near future and some big plans for next year So Matt, thank you very much for your time. Thank you. Don't forget. We've got a few more videos as well We've got one covering the fantasy stuff that I've done with Ronnie And we've also done one about the board games from Manic that I've covered with Dan So make sure you watch those two. Thanks for watching


Members of the 31st Marine Expeditionary Units Battalion Landing Team, 1st Battalion 4th Marines, execute amphibious landings on an Okinawa beach using combat rubber raiding craft. The training helps prepare the Marines of Alpha Company for their role as the Muse Boat Company. So, long and short of it, basically, we come off the horizon and we approach into the shore. We directly do this at night to utilize the cover darkness because of the vulnerability of the boats. So, normally speaking, we work on the command control, working out in the open water and getting them all 18 cricks ashore so that we can begin our actions ashore for any right-side munitions that we may have. The numerous landings allow Marines to refresh their skills and boat operations for their upcoming deployment with the 31st Mune. Marine Man's Corporal David J. Adams, Ken Blue, Okinawa.


Obviously, it's going to be on buffer overflows on the Spark. You're just treated to a great talk on basically advanced techniques you can do. I'm going to try and focus on this on doing overflows on other architectures, most notably the Spark. The Spark, for those who are unfamiliar or probably have just heard of them, is... Oh, well, this is what I'm going to talk about. Sorry, again out of order. I do a crash course on the Spark and Spark assembly. Just because I'm going to focus a lot on writing the shell code or the payload, because that's what differs the most between Intel and the Spark. And a lot of the techniques that were sort of talked about about how to deliver the shell code all equally applies here. There are some little nuances that will make it different, but as a general conceptual overview, it's the same. The stack is much funkier on the Spark, and I'll make sure I cover that. I'll cover some of the tools that I'm using to develop the shell code and examples. I'll be doing everything on a Solaris box, this one right here. Solaris is so nice to come with a wonderful debugger. ADB is called the Absolute Debugger. It's an assembly language level debugger. So you can step through, look at the registers, look at patch binaries. You can patch values in memory and do things a lot easier than you can with GDB. And that will speak up as everyone is motioning towards me to do. Then I'll discuss exactly what happens on an overflow and start discussing shell code and some methods of delivery. And I'll be giving some examples too, because I like doing that. Okay, the Spark. It's named for Scalable Processor Architecture, created by Sun in the early 80s. It was based on the risk designs out of UC Berkeley. And basically the whole philosophy was make the chip as simple as possible so it's blazing fast. And part of what this is is a 32-bit wide path. Everything in Spark is really pretty because every instruction is 32 bits wide. Your shell code is nice and square. It's really fun. It makes things just typically easier for calculating the size of your shell code and calculating jump addresses and stuff like that. There's a pipeline to architecture which I just had to mention because it will get you in some places. Every clock cycle, it basically executes one and a half-ish instructions where it basically prepares the second instruction. So you have to watch out when you're branching that when you branch, jump to another location and code, you will execute the statement after the branch. So just keep that in mind when you're writing your stuff. One of the other things to speed this up is the load store architecture. All logical and arithmetic instructions only operate on the registers. You can't just increment something in memory because that would involve making the chip smarter and slower. And the one thing unique to the Spark is this wacky invention called register windows, which I will cover in great depth because it's kind of crazy. Memory access, basically it's relatively simple. The only instructions that can access memory are load and store, and that whole family of instructions, load by half word, so on and so on. And all memory access is registered indirect, meaning that you have to write something in the value contained in a register, whereas each register acts like a pointer basically as they wouldn't see. So this chip was actually written for C compiler, so if you think and see you, the Spark will be very nice to you. All instructions are one word, very nice. The registers, risks, chips always have tons of registers, which make things really easy. At each given point in time, you have access to 32 registers. The chip may actually have more registers than that, more general purpose integer registers, but you can only see 32 of them at a time because of the register windows, which I'll talk about. You always have the global registers, you have eight of them, that are accessible across every function. You have the output registers, which you load up the arguments to a function to be calling. You have the local registers, which are local to your subroutine. The inputs, which are your caller's output registers. Things to note, the output register six is the stack pointer. That points to the bottom of your stack, bottom being the lowest memory address. The input six is the frame pointer, which is your caller's stack pointer, and also it points to the top of your stack space. Register windows work is a circular stack of 16 registers. The outputs and the locals, which are rotated among functions, so you don't have to worry about pushing arguments onto the stack or so on, and to speed up function calls because it was written for C, and that's what you do all the time. The caller's output registers become the input registers in the next function, and these are all handled by the save and restore instructions. The save and restore instructions allocate your new register set, and they also allocate the space on the stack, which we had to get the subroutine calling conventions. Basically, the caller's subroutine, very simple. You just place the arguments in the output registers, use the call instruction to actually jump to the location in memory containing the code for the function. The callee uses the save instruction to allocate a register window, and it will also allocate their stack frame. With that, they calculate the minimum space they need for the stack in addition to anything they need for local variables, as all allocated in one instruction. Interesting thing to note is that when you are allocating space on the stack for the register window, they're not actually written there. They're only written there when the system runs out of register windows, and when that happens, a trap is called that signals the operating system, that it needs to flush some of these registers out to the memory stack, and so basically what you're doing is you're saying, when you need to dump them, dump them here. So you're not actually guaranteed to have them written there, which is kind of difficult because the point of overflowing the buffer is to overwrite the return address, but if the return address is in a register, you have complications, and the callee does its thing, and at the end it does a ret, which is return to the caller, which just basically jumps to the value store in the input 7 register plus 8, because the 8 is added because of the register of the branch delay slot, that when it's called, it executes that instruction and the next instruction, so it has to go 8 back. A simple example. We have our main, just we'll call the function foo, and we'll set the upper register 0 to dead beef. This is executed because it is in the branch delay slot. Control transfers over to foo, which saves, the save instruction is interesting because the first argument, oh, one thing to note about Spark Assembly is the destination is always on the right, so it was save starting at the original stack pointer, and decrement the stack pointer by 96 bytes, which is the minimum stack frame needed to dump the registers, and store that value as the new stack pointer, and in between those is when the register window is rotated, so the value of the stack pointer at the first operand is now in the frame pointer register. Then it just loads the value stored at the memory address, stored in register input 0, and puts that value in register local 0, adds 42 to it, storing the result in register local 1, and similarly stores the result back in dead beef. Then it returns, and returns is transferred to control back, and because the branch delay slot, the restore flips the register window back, and the allocates the stack, so when transfer is controlled back, the caller thinks the world is right again. I want to define traps for you. These are typically called interrupts in other operating systems and architectures. They are transfers of control to supervisor software, meaning it's a request from the application, or from other supervisor code, or from the actual hardware for the operating system to get up and do something. These are handled for a window overflow and underflow conditions, where the operating system has to dump them to the memory stack, or restore them. The question is, why do we care? System calls. If you're familiar with Unix kernels, they are all based upon having tons of system calls that will do everything for you. These are all in the manual pages section 2, open, close, exec, fork, all these fun things are all there for you. To make a system call, all you do is look up in syscall.h, the system call number of the system call you want to execute, you throw that in global 1 and execute trap 8. A simple example here. We are going to set the output register to 0, because global 0 is basically the dev null register. It's hard coded 0. 23 is the index of the setUID system call. Move that to global 1, do the trap. Notice there is no branch delay slot after a trap. It's only on branches and calls. Now let's just execute setUID 0, which we'll see why we need to do that soon. The stack. Like other architectures, the stack goes downward and it reserves the space for the window in case of overflow and underflow. And basically, in the well-behaved convention obeying functions, all automatic variables are referenced by negative offsets from the frame pointer, because as my little art in the next slide will show you, the first part of the stack in the high memory address is space, if any, for automatic variables. You just index them that way. And then the bottom of the stack is stuff for the register windows. But you actually really don't need to reference those, because nothing is guaranteed to be there, so why would you want to do that? And here is, obviously, a struct representation of the minimum stack frame. And they do some interesting stuff here. You have eight words allotted for the local registers. Then you have six for the input registers. And notice these two are also the input registers. We have the frame pointer and the saved program counter, which is where we'll be jumping back to. Basically, you have eight locals and those next three lines form the eight inputs, which means you can only pass six arguments through the registers to a function. Then we have the structure return address for return and compound values.  So you could store a pointer on the stack instead of putting in a register. I'm not sure why. And then we have the argument dump area, which is so that the function being called, if it so chooses, can dump its arguments that it got on its input registers onto its stack. Okay. If you need more registers, you can do that and get them all. And then we have the arg x area. This is the argument extension. For more than six arguments to a function, this stack, this space just kind of grows as far as needed to place the arguments there. This is allotted with the callers save instruction, which I put those in there. They load them in. The function will know to reference them as negative to the frame pointer as yes. And that's how that works. We won't really be using that. But here's a nice ask your depiction of the stack. Stack goes this way, and I have it going left to right just so you can read it, and you can see the string buffers as they are. Locals inputs the structure return address point or the structure pointer. The argument dump area is 24 bytes of the sizes used by them up there. The argument dump area is that one byte is also sometimes referred to as the hidden word, which is used to make sure that the stack is double word aligned. The stack and the saved program counter must always be double word aligned or else your chip will get very angry with you. And we're going to make it very angry, but not so angry that it barfs. And then automatic variables restored here. Like right here in my example where I have a string pointer called buff of indeterminate size. It doesn't really matter. And then we have the frame pointer, which is the boundary between our next or our collars stack frame. There are his locals, his inputs, and our little asterisks. That's his saved program counter. That's our target. That's what we need to hit. And it's pretty easy to see that if the buffer grows outside of its boundaries, you just overwrite his registers and basically take him over. What actually presents the interesting thing is you're not overflowing and taking over the function that with the fixed length buffer in it, you are overflowing and taking control from his caller, which is very interesting because sometimes your caller can call the overflowable function, return, call another function, which will overwrite your wonderful stack frame and shellcode, and then basically you're screwed. But of course, you just attended the Greg Coglund's talk on how to do cool things with the stack and where you can put the code and stuff like that should not be a problem. But this is what's going to happen when we are overflowing the buffer. Just trying to trace through over how the register windows rotate the registers and how things change. Obviously, the previous stack frame's saved program counter is overwritten, as is all his other registers. The function returns, his frame pointer becomes the target address and his input seven register becomes the target address also. And the stack pointer is still valid. The stack pointer will still be the pointer to his stack, which has not been fully overwrite at this point. All of his values that he assumed to be safe have just been totally messed up, so he just freaks out hopefully getting an error condition immediately and returning. And if he does, he tries to jump to the input seven plus eight, our target address plus eight bytes, and that is where we would take over control. This is your stack on drugs. Basically, we have all these registers, or these areas on the stack are fine, and at our buff, we just overflow and write our target address off into the horizon. You can basically write as far as you want because nothing is going to behave well at this point. Yes. Thank you for reminding me. Okay, basically, you're told that we are not guaranteed that these values will be there. But what happens is basically, implementations of the Spark architecture, as is an open architecture, are allowed to have anywhere from, I think, eight to 40 register windows. Luckily, those register windows are always filled even in the lowest stages of the kernel, so you can basically assume that every time we do a save or restore, they will be restored from the stack, or saved to the stack and restored from the stack. So that when the overflowed function does a restore, we all assume that the registers that it thought it had in the register window were written to the stack, and so it restores them from the caller's stack. So basically what it does is we have our target address written all the way through there, and it just loads up its registers as it transfers control to the caller, loads up its registers with the target address. I'll do some examples, and I'll show you what this looks like when it's stepping through the program, and you'll see all the registers are just totally just spammed over. One of the very nice tools that Slayers comes with is just the disassembler. They ever looked into basically writing the shell code, writing the assembly code, and then changing it to the bytes, depending the but. But this makes it rather easy, especially when you just throw a Perl script on top of it, and it's a nice little chug, and you have a nice little header file you can use. There are freeware Spark disassemblers available. I just found the page about two hours ago off linuxassembly.org. It has a link to an FBSD, a link to some Spark assembly examples, and on this guy's page he has his own Spark disassembler and Spark assembler, and a couple others that you could use for linux and or BSD. All running on Spark, of course. Excuse me? Is it free? Oh, very nice. Okay. Well, I'm sure we can find that. If you want to give me the URL, I can throw it on here for people. Oh. I forgot who already, but someone has a really good free disassembler. Can you? Oh, wow. I was unaware that they had a disassembler. Well, I have done my research. Okay. And the other tool that we'll be using extensively is the absolute debugger, because this thing, correct me if I'm wrong again, I have not seen anything like this for any of the free operating systems. They tend to use GDB for their kernel debuggers and everything else, but I have not seen something that is as assembly language as this one is, as assembly level. Rather funky syntax to get used to if you're coming from the world of nice and pretty hand-holding debuggers. Arguments are address, height, iterations to do, and command and modifiers, as you can see. First instruction, it says starting at the address of main in the object file. The question mark means in the object file, the slash means in the memory image, whether it be a core file or the actual memory of the running process. What I'm saying on the first one is dump 10 instructions, or disassemble 10 instructions starting at main. One of the wonderful idiosyncrasies of this program is everything on this side of the question mark or slash is in hex. Everything on that side is in decimal. But there are modifiers you can use to put them either way, but we should all be very fluid with conversions, even though I'm not. The second example, just display the word stored at codebabe. That's not a real address, but I like it. We can also just query individual registers. Basically, you have a sudo redirection, the instruction that will say, give me the address of the stack pointer, assign it to the variable x, and it will print it out for you. The next instruction says, display 24 words starting at the stack pointer. That will give you the full minimum stack frame. And then from there, after that point, it will be automatic variables, if any, but every function must have at least those, and you can check them out. Here's a more interesting one. In the address of the frame pointer plus 3C, which I can't remember, I'm on the spot so I can't do math, that will be the saved program counter. Write the value, dead beef. And so then you just write the value, step through, and you'll see the program try and jump to it, or see the caller try and jump to it when it becomes time. The ADB will also do interactive debugging, some simple stuff like this so you're not really pertinent, but I threw it on there because I needed space. Wow, this is very difficult to see. This is a contrived session of using ADB to examine what happens when we overflow a program. I wrote a simple program called smash me, which I'll show you in a couple of minutes. They're basically just a fatal flaw. There's a stir copy or a stir cat into a fixed length buffer. And it just takes the argument on the command line, so I'm just saying run it with this argument. And I said, first, just set the break... Oh, there also is no prompt in ADB, so it's kind of hard to follow along. I said smash colon be me and set a breakpoint at the smash function, which is I have main and I call smash, which has the overflow.  We're stepping through. I'll get our stack pointer and we're going to store the value, go through. We're just stepping through watching it. It's going to call, I think right there at the bottom of your screen is where it calls stir cat. But right now we're going to watch... I can't remember how I did this. Oh, yes, I call stir cat. But first I look at our stack pointer and look at the frame pointer, our caller stack frame. And then I step over that instruction, which will call stir cat and we're going to watch what happens after that. The colon e means step to the next instruction, but don't follow any jumps or calls. As you can see, the saved program counter is overwritten, as is his entire stack frame. He's not happy. And then I basically just step through to the end and go right here to where he returns. And so when he returns, the stuff store on his stack is loaded off the stack into registers and using the restore instruction is flipped over to his callers, local and output registers. And so now we have them all loaded in back in control of main. They're all loaded in there. And we're going to step through the last instructions of main where it tries to do a return right here. And that says a bus error because the address 41414141 is not aligned. And you'll get that. It's the last way just to see when you've messed up, quit out of that. I'll run through that again later with a real-world example. I'm going to start talking now about how to write a similar code that we'll use as mobile code, as it's a new dependent code. We can just throw in there and it will just execute on its own behalf and take control of the process.  And then after that, I throw the function into a character array and then I cast that array to a function pointer, execute the function pointer as the final stress test. Here's my first example of some Spark shell code. This is somewhat brain dead in some ways as I'll explain. This representation does contain null bytes in it, so it's useless basically, but it's ordered in a simplest way. I'll show you just how we're going to write it. I write my shell code at first as if it's a well-behaved function, so I allocate in a new register window and I'm basically calling execs, so I'm creating the character array of the function to execute and I'm creating the arg value, the arg vector. Throw that in there, and just giving it a null for the environment pointer because, okay, it's a little bit messy, but it's not a problem. One very handy thing about Spark is that it's big Indian, and so you can write strings in a relatively straightforward way just straight to the stack. One way to do this is if you're lazy, almost the unixes will come with the octal dump program, and if you just do echo string, pipe, octal dump, slash x, forgive me, hexadecimal output, it'll give you a nice hex and you just basically just chop it into words and start storing them on the stack and you have a string. There are, I'm sure there are ways to do the cool little jumping thing that will actually load the address of the string so you can just write it straight, but that's a little over the top for now. And you can basically see I set 59 to the system call number, execute the system call. This can basically be looked at as a well-behaved function to just exec a shell. Then I chop it down a little more. It doesn't seem it's a well-behaved function. I am lying on that second line, ignore that. Basically, I chop out the saving restores and I just start using the current stack pointer because in the situation where the overflow occurs, assuming the well-behaved function assumes that you have valid stack pointers and frame pointers. You can get in situations where your stack pointer will be pointing to right behind your code and as you're storing memory, you'll be chasing your code as your code executes and you're overwriting behind it and you don't want to be there. So this code also will not work because it assumes that the frame pointer is valid, but as I discussed before, the frame pointer will be the target address and so you're stepping on your toes here. But this is another example of just chopping things down. And I can see I set the two words and two following registers to a stored double word instruction starting at the address of the frame pointer minus 16, so it writes the full 8-5 value down. And I basically am constructing in memory the string followed by a null so that I can use it for both the name of the program to execute and I build a pointer to that array of character pointers to use as the arg vector. If you've seen Aleph Warren's code in the expression of stack for front-end profit, he does this also. Very easy and straightforward way to do it. Here is my even better shell code. I'm not saying it's really great, but in writing this, there's an interesting caveat that is not addressed in smashing the stack for front-end profit. Under system v systems, the born shell, slash bnsh, when passed an effective UID of less than 100 will discard it so that the effective UID is triggered when the program has the suid bit set which means it keeps your real user ID saying this is who you really are, but effectively you're root. And then it calls the shell and the shell discards the effective UID and so basically you've found that you've exploited a suid program and you still have your own privileges and you're not very pleased. The second one. It contains a no-byte in this. Oh, thank you. Okay, the set is a synthetic instruction, meaning the assembler basically expands it for you. And of the set, because everything is 32 bits, how can you write a 32-bit value in the instruction? Because it splits it into two. It first writes the, is the set high instruction to write the first, the highest order, 13 bits to the register and then does an OR with the lower 13 bits, with the lower 8 bits to complete the whole value. And we'll see when I disassemble the shell code how it's changed over and I'm just lazy so I just do the set because it's easier to see the string there instead of in two words. But yeah, that will eliminate the no-byte. The no-byte will still be in the set and the OR but because of the way that the opcode for OR is aligned with the bits, it will not be on the correct boundaries to be a, in fact, no-byte. It'll be spread across.  It's your choice. Let's see, nothing else really changed here. You'll notice that I do not trust the frame pointer anymore because I've stepped through with you as I need a bug and I'm like, wait, why am I doing that? That is just whack. And so everything relative to the stack pointer, I waste four bytes before the stack pointer because storing straight to the stack pointer introduces a no-byte. And you'll notice when I'm trying to set a register to zero, I can't use the straight forward instruction by just setting to zero or moving the global register over because that introduces a no-byte so you just do something like XORs or there's a thousand different creative ways you can do that just to feel fun. I'm just going to talk a little bit about the delivery but not that much because it is basically treated well better than I could by Greg Hoglund. Same with other architectures either. You need to do the no-op sled and then the shellcode and then write the jump address off into infinity and let it jump back which has the problem of if the caller of the overflowable function calls another function, you're not necessarily toast, you're just basically dodging bullets. Or you can just write the jump address to overwrite the saved program counter then put the no-ops after it and the code after it so basically you're jumping backwards in the stack and beyond to the caller of the caller of the overflowable function the metacaller in this case.  Greg Hoglund talked a lot about this very well, am I not? Okay, some real-world examples if I can find a place to put this microphone. Can everyone see the shell? Okay. Let me do an example. Okay, first we're going to have our nice little simple smash me example. Here's a source code for that. Very, very simple. Smash with the argv1 stircat to 128 byte buffer. Now we run a min of smash me which will smash, smash me. One thing you'll basically always see is the calling function will get the value of its stack pointer because it'll calculate the offset from its stack pointer so it can try and guess the stack pointer of the function it's trying to overflow because it'll always be a defined number of bytes down the stack a certain number of function calls down the stack. And so basically what you're going to be doing is you're just going to be creating a very large string in this program what I do is I write I pass in the argument of the buffer size that I'm trying to overflow and so what I do is I write no ops all the way up to where the shell code must fit then write the shell code so it's all within the buffer and then just write tons of return addresses and the return address is calculated as an offset from the stack pointer of the meta smash me process. So I just calculate the egg size and it kind of just tells you what it's doing and writes like the no op I have here is I cannot remember what instruction that is just trust me that it's a basic instruction that does nothing essentially and just copy the memory into the egg and so the egg represents the entire string I'm trying to pass it with and I call the function so let's see what happens if we say the offset is zero notice that the shell code I'm using in this example has 64 bytes so we'll have 64 bytes of no ops and then the shell code so we don't have that big of a window it's not happy so fire parted bugger meta smash me and the core legal instruction to the registers notice how the registers are just basically splatted and so we can just check out our frame pointer see what they point to the point to themselves again because basically I did not go back far enough in the stack where I'm just pointing back at my target address so let's see minus 500 500 hex notice that is well beyond it okay so what I'm going to do is get my shell code I should all look at look at my no op I'll see that bite there and basically I'm going to search through memory for where that thing is and that'll basically calculate the offset for me so I'm going to say we'll start at 500 hex bytes down the stack from the frame pointer do a search for the 30 bit value alright okay search for that value show me the first occurrence of it is and now I'm going to do my poor man's hex calculator is that the value we want 980 so that right there is our offset so let's quit on that and let's put gdb at the test I'm going to smash me 128 bytes go back we have a shell we basically landed exactly at the first no op thank you but that's some precision that we don't really need basically we know that we have 64 bytes so basically we only have to be within 50 bytes or so so we can just go back and go try 1000 no not happy 1050 bingo and so the larger the buffer is basically you more leeway you have which will go and we'll see my libc example this is old this was discovered by onion I think in September 1998 or something like that and son took about a year to post a fix for it but so I just took all the patches off my system I'm feeling kind of vulnerable right now but it's for the greater good the details of this bug are there's an overflow in libc and it's parsing of the LC messages environment variable you can overflow that and basically so any sewer program becomes vulnerable to it so here's my little program right here I just ask what program to call how big the buffer is and what the offset is and I'll show you the program in a second pretty much the same thing as the last one just throws it in the environment you will have to you'll have to basically write a program to exploit each one you're going for typically just so you can customize it but it's not that big of a deal and what we can do is we can then I'm just going to try out let's go for bin rsh and I basically went through with Perl and basically kept giving larger larger buffers in LC messages until I got one that died it was somewhere around a thousand bytes that's what I'm going to assume the size of the buffer is start with offset zero it dies okay well I know now that because it is a thousand bytes of no ops 1,000 minus 64 I have a very gaping large window and so I'm just going to try offsets of 500 there we go and that basically gives me a root shell because in this the shellcode that I'm using I made sure to call set you 80 zero before I can bin shell so bin shell is happy and trust me and it's basically like that I can use any fluid program on the on the system at this point so okay anyone have a favorite you know I'll do bin password because that one's nice and easy but I basically just sat down today and decide which ones I could get and basically some of these didn't have the overflow in them because they didn't use the local support and libc to use it but the vast majority of them did so let's start with password and oh wow looks like they don't go very far down on the stack and then make it really easy for us so let's see what else do I have that's really fun to show you okay let's go for some really cool shellcode that mostly works I spent the last couple days on this a strange strange bug it's driving me nuts but here's an alternate way to develop shellcode instead of using the ass and blocks just write the assembly file and basically put you throw it through the create the object file and then I have a main function in a C program that just calls this function bind shell and that's a simple way for me to test it so I can go through here and mostly because the ass and blocks just makes emacs go hairy and I like emacs so don't throw anything okay what I'm doing oh let's see where's the source for this originally first I wrote basically what I wanted to do in C create a socket set it up bind it set the first connection dupe the file descriptors for send it in send it out send it error to the socket and run bin shell and I just kind of went through translated this into assembly because everything is just a system call so I do trap let's see right there is the socket call by 230 just look through these higher numbered ones will change from system to system so you'll have to look them up on if you're doing that in Linux or at BSD on there just straightforward assembly programming basically going through go bind store it all yada yada you compile and I just insert my standard shell code right there using the compiler to output assembly code will be very helpful and figuring out how the compiler does stuff but it is deceptive in a lot of ways because the compiler doesn't like telling you are in the various libraries that it's just doing system calls for all these so you'll go through six different layered functions underscore underscore socket underscore capital U that will finally say oh, I just do a trap but just look through syscall.h and you'll see what it really does it'll get angry at you but we test it I just compiled it and linked the two things together that's the bug for some reason when I run it straight it decides that it will not block and wait for it to accept it'll just kind of do something and the thread will just continue on and execute the shell but when I run it through the debugger and say what's it called bind shell where can I run it and I say yeah, continue nope and I just told it to bind to localhost part 2000 yes keep going I like to say it's about to exec something and things will change so I'll stop for you but just ignore that and basically we have a very mutated very ugly environment it's shell right here it says not found colon and you can get enough done from here to do what you need to do and obviously it's running as me because I just ran it from the command line but you just basically through the things I've showed you convert it to shell code and throw in the process and you'll have a bind shell to do so I have a nice little you here just to help me out with writing these I made my disk to H and so if I go through to my code let's see 3 what I do is I write 3.C test it out in there then I disassemble it to 3. well I disassemble it to 3.Disk which says diff main 3 little noise at the top so I just chop those off till I just have the disassembled code shouldn't hurt you to cut out 3 lines not with a script to do everything for you and then just simple like you know a filter you can do this and purl do this and whatever you want but I didn't see because it's fun 3.Disk type to that and gives you a nice little header file to include and this is a quick way to check for null bytes and just look at your code hand side by side and feel warm and fuzzy but basically with just a couple little tools you can just tinker around with in a writing shell code and stuff and then amazingly you will wake up and say wait a minute I'm actually decent at assembly programming now this is useful to be the example I didn't do class until I started doing this stuff and of course this semester it ended and now I know everything and can pay attention to class anyway so no no no grades me nothing I don't think I have anything else to show you and I think I'm out of time and I show you those oh yes some links to useful things linuxassembly.org obviously focuses on Linux and Intel architecture but they have some great info on there a little straight from the beaten path and show you some spark stuff some BSD stuff they have a nice little suite of basically the bin utility a lot of the small utility is written in assembly so you know your standard 100k executable is now like 3k because all they do is call the traps themselves it's not portable but it's really small and useful for boot disks shellcode.org I just saw come across see their bug tracker vulnerable some mailing list today currently down we'll have a lot of resources to various shellcodes for various operating systems Frack55 has a really nice article about writing shellcode on MIPS under iWix MIPS also being another of the pioneering risk chips very similar to this it's a very good read also and this stuff eventually will be on WSquad.net slash security whenever I finish it up and put it up there so you can look there but if you see a 404 don't have a heart attack