Augumenting osquery visibility on windows through reverse engineering by G. Ross and M. Oviedo

welcome back all right right next up we have augmenting OS query visibility on Windows through reverse engineering welcome guom Ross and marus sovo and take it away hey thank you thank you very much this is guom uh just by the way I'm not able to enable the video on the zoom but um you've got the slides so I think this will work uh really great so Marcos is driving the uh the slides and there's going to be a lot of live Demos in there so um it should be pretty interesting so today we're going to talk about how we augmented visibility on Windows for um osquery and we will start by talking a little bit about the two of us what

Fleet and Os Cory are for those that are not familiar what you can do with operating system configuration data what Windows has in terms of uh that type of security uh configuration data and then Marcos will take you through how we reverse engineered some built-in windows tools so that we could understand some internal apis that are undocumented all the way through contributing back to the open source OS Project so the visibility could be augmented for everyone that uses it right so I'm GNA let Marcos introduce himself are you muted Marcos yeah sorry thank you everyone uh thank you gam for the introduction I am maroso I am a software engineer at Fleet and I Define myself as an infos ner uh

infos has really been my passion for the last 15 years and during that time something that I found I really enjoyed doing was to contribute back to the community um to either to enhance a a current tool or create new ones and uh as a little fact about me I was part of the team that organized the first besides Edition back in my my hometown in 2019 that was uh besides

ctin and uh I'm Gom I'm the head of security at Fleet I've been doing security for a long time also been using osquery for a pretty long time and what I like to do is like Leverage compliance to improve actual security right like instead of just checking a check box somewhere just making sure we're improving things and I'm in Montreal so of course by law I am required to like hockey and poutine and uh funny enough I work with uh Marcos now he's in Argentina I'm in Montreal so you know we're pretty much on uh top and bottom of the Americas and uh infosec is such a small word world that we realize we we

have some uh common friends and ex- colleagues uh last week so Marcos is going to be doing most of the talking I actually almost feel bad that my name is on the talk because I was just someone who needed something to happen and he's the one who actually did it so if you can switch to the next slide I'll talk a little bit about aest Quan Fleet uh we're not going to talk too long about it I assume many of you are familiar with it if you're not osquery is essentially an endpoint agent that makes your um endpoints they could be servers workstations Macos Linux and windows look like a relational database right so if you want to know um what US users

exist on a machine well there's a table with a list of users what processes are running well there's a table with a list of every process that's running so it's very powerful for things that are um related to like threat hunting but it's also really good for tracking the configuration of systems to be sure that it is uh as you expect and it's really lightweight now Fleet is also open source so we're essentially in the middle in this diagram here so you see OS queries on the left that's the endpoint uh agent and you can configure it from Fleet you can schedule queries that happen on the osquery side from Fleet and then the data will go back to

your Fleet server where you can then forward it to your sim um store it in the Su bucket send it to Splunk or whatever and everything in Fleet is also available via apis so we have a fleet cuddle which is a like a command line tool to uh do pretty much anything you want with Fleet and osquery right so if you need to know something about a machine while using uh our tools and our API you can query these machines live or or you know at a scheduled frequency including something that we call policies so there's close to 300 tables in osquery got a little video playing here uh I'm selecting star from the users table on my own

laptop and oh thanks for increasing the resolution so you'll see it's going to take like a couple seconds and what happens is the fleet server sends the query to osquery on my Mac and then you can see my user account is in SL user SLG right um I could do the same thing and select from processes uh where processes are not stored on the drive right so if you have something that's running and is only in memory and is not on the drive then you would get results right like I hope there's nothing like that on my laptop right now yeah as you can say it's responded and there's no data so we're good so there's I think it's 275 cor uh

tables now some of them work on all operating systems and some of them are operating systems specific so for example on Windows there's a registry table you can query obviously that doesn't exist on Mac OS or on Linux so the usefulness of configuration data that you can get through osquery is essentially to enforce and track security hygiene either for security purposes or it could be compliance so we've got a feature in Fleet that's got um that we call policies and they're essentially queries that pass or fail right so the example you see on the right that's when that use internally where I'm checking that um we all use Max and we're just checking that file

vault is enabled on all of our Macs and then if it's not the policy will fail and then we can send that to like a j ticket service now or what we actually do is we route it through a sore with web Hooks and then we send it to our slack to tell someone like okay what are you doing how is file Vault disabled even though it's enforced with MDM but there's a lot of these settings that you want to track to be sure that things are configured as uh as expected and so Fleet is crossplatform but then these these tables are different on all different operating systems so on uh the next slide you can see here we're Mac first

right so we've got these are all the policies that we actually run um in our on our own laptops right so things like are people storing SSH keys that are un encrypted on their laptops uh is Google Chrome up to date is the drive encrypted like all of these and and by the way these are all open source you can go on on our website and find all these queries but there's a bunch of stuff in there that if we wanted to do with Windows it's not that easy so um for from the bottom you've got one that was checking like the password policy for example that it requires 10 or more characters on the Windows side it's not

uh it's not that easy so on Mac OS there's a bunch of tables that use operating system apis directly and when you don't have a table with the data that you want you can you can always check to see if your MDM is pushing the policy right so instead of checking is X configured to Y you can check is there a profile that will configure X to Y right so it's a little bit disconnected from the end result but lets you get a lot of visibility really quickly on Linux pretty much everything is a file um and there's a a table called augas in Linux that essentially lets you read a configuration file as if

it was a table right so if you want to check your open SSH config to see if root logins are enabled or not you would be able to do that with AAS but then on Windows a lot of these um security configurations are in the registry but not all of them and even when they're in the registry it's not always that clean or that simple so okay yeah so I'll hand it over to uh to Marcos uh essentially what I needed was a way of checking a lot more security configuration data from Windows in a reliable way and that's where Marcos comes in with his uh awesomeness thank you uh so yeah so the problem was that we we wanted to to

obtain information from the window security configuration policies but at first we wanted to understand what these policy are and what they how they can actually be configured uh on windows with uh through the buildin tools so we found that the security configuration policies are basically rules that can be used to enforce the security of a system uh to in particular one can enforce the the security aspect of different set of functionalities on Windows and we're going to see what those functionalities are but uh first uh we need to understand how these rules can be configured and and and and extracted so yam mentioned that the rules are not exposed on the registry so we found that

uh the rules were actually uh manageable through something called gpos GPO policies and they can be locally configured through this local security policy editor or or a domain wide they can be configured through the group policy editor and um the rules uh basically contain uh uh the the a way to configure the password policies account policies Lookout policies and Care policies and we were mostly interested on the password policies uh aspect of things we wanted to know what uh we can do with these policies uh we want to understand uh what are the things that are that we exposed and we found that by having this uh information we will are going to be able to create new and

reliable uh policy queries such as the one that yam was showing a moment ago so for example we found that we can check for things like the minimum uh number of characters that password should have we can check for if uh things like if the guest account was disabled we can check for properties of the password we can check for even for audit uh information so uh so you you might be asking why we wanted to focus on on password policy and why we wanted to uh have this type of information and uh we we we decide that we know that uh the passwords are probably the most vable component component in an authentication scheme

and they are prompt to different typ of attacks uh so as a way to ensure how the passw will work we want to have control on what was configured across our entire fleet so um uh let's uh break down the password policies a bit so I mentioned briefly some of the characteristic that we were interested in and we found that those uh properties were actually exposed uh through the passwort policies we found that that things like the minimum and maximum password AG were properties that we can extract from this set of security configuration policies we found that uh uh we can know that the the com the password complexity requirements we can know if the password

is reversible on a system or not uh and we also know uh we wanted to to I mean another thing that was also exposed was the the history of the past for cash uh so in the process of finding uh what these uh policies were and how they the the Poli can consume we found this tool called sec8 which was a buil-in tool that basically allow us to uh have information from the security policies and allow us to manage them and um um visualize them um so the tool it's a a common line tool uh which is shipped together with OS since Windows XP um and the to allow you to uh expose this uh common line uh um configuration

uh commments uh and we found that by calling the export uh um option uh along with some specific security policies that we were interested in we were able to obtain this information exported in a txt file so that was a kind of a revealing because now we we had a a programmatic I mean we we have a buin utility that can give us this information so we can you know wrap up the the utility with some code some logic to uh execute the utility uh return the grab the the return data and then pass that data so it can be presented uh to different uh to a different component so by by having by having this programmatic way of

retrieving the information uh we can uh uh automate uh the execution and run this this functionality at scale over an entire fleet of devices so that was the next uh step here so we wanted to run this uh scale so the the game plan for us was to uh call this C Tool uh from o query then do the the process of grabbing the data and exposing that data through a virtual table so it can be consumed by different tools such as Fleet uh but uh but in the process of uh doing this we asked one of the uh co-creators of osquery Sak waserman who is who is happening to be the C of our

company so we asked him about this idea but uh he mentioned that uh child processes or sub processing in O query was not a desire so we kind of uh uh stop considering this idea as something that was a potential solution for this problem and then um we thought about the the idea of actually creating some code that can behave like a secate so creating that code that behaved like it SEC will require that we will have to understand what sec uh does internally will we will have to understand what type of apis are being called during the SEC execution process and we also have to understand that how the how to call these apis so the the the only way

possible that we knew uh we can do this was through the use of reverse engineering techniques uh so in order to mention how we end up we end up doing this we we need to talk first about what reverse engineering is actually does so um reverse engineering is the process of taking a binary file and understanding what what it does so that was kind of the case here we have a close uh uh binary file from Microsoft which uh we don't have access to the source code and we wanted to understand what this Miner does so a reverse engineer was the way to go so reverse engine reverse engineering is usually used for analyzing close Source software such as

this case and but this is also used by by by through a variety of use case such as vulnerability research if especially for binary analysis of a new uh exploitation techniques for example uh it is used to analyze prop proprietary formats for example if a media formats if someone wants to be able to reproduce a new media format and also for product verification and their availability purposes so uh there are uh through this work we use four type of reverse engineering tools we use the assemblers debuggers the compilers and binary format analyzers so this assemblers are the the tools that allow us to perform uh to have access to an static view of the binary to understand what where the

assembly instructions uh being used in there and to have an overal not of how these assembl instructions are were were being called what was the the execution flow that was uh perform to the through the initialization parameters that we gave to the to the program then we use the bugers to actually perform a live inspection of the running running binary in memory so through the buggers one we can see we can it can uh have access to the the current state in memory of the program and and inspect things like variables regist registers um inspect the the state of uh the the stack at any point in time and and things like that we are going to see in the demo how this

uh real divider works on on for for this particular example then we have something called the compilers the compilers are basically um functionality within the Baggers and this assers that allow us to have a a c like representation of the code so it's a good way to uh understand at the very high level what the the a piece of code does especially a function what the function does and um the thing about the compilers is that they are not uh they don't produce an exact uh um output a one to one output to the assembly code because there are thing that uh sometimes cannot be de compile uh but they do the best effort approach to give

you a a accurate representation of the assembly code and then uh we have the binary format analyzers which are the tools that allow us to understand the executable format in this case uh as we were working on Windows um the executable format that we wanted to analyze was the P executable format so we use a tool uh specifically for that uh the reverse engineering process can be performed uh by a a variety of techniques that that can be categorized on uh through something called static and dynamic analysis so static analysis is the the process of analyzing the binary without actually executing the binary so one can can use disassemblers for for this work and uh and have the

use the the static view of the assembly code represent in in the December to take notes uh to understand understand the execution flow and uh know what what are the things that one we will expect to see when the run the binary through the dynamic analysis process through the dynamic analysis process one what end up doing is to execute the binary and then step by step execute the the the the prog flow and see what are the things that are being uh uh called and use from within the the code uh yeah so this is a graphical view of what I I just said uh so when when it when it talks when it comes to uh

reverse engineering Cate what we did was to first to understand what the what type of executable we had and then what were the the modules or the also called dlls that this exe executable was calling um and then uh through a static analysis we found a couple of interesting things that we then collaborated through uh Dynamic analysis uh and this was the the my my first uh contribution to this uh to this problem so I was asked to uh look for programmatic way to retrieve this information and I found that se was a a possible uh uh challenge to to achieve that but in order to confirm that uh we actually to do the work on reverse

engineering it which is something that we are going to do in a in a moment so after checking on on C and after I finding that there were some DLS that were used across different uh uh components that were calling into the into the the this uh security configuration extension architecture um I decided to look into msdn into the Microsoft documentation to have more information on this and I found that this uh the that the security configuration information was actually managed by this service called and that uh I found a couple of properties of the service such as the fact that there were a a client and a server component that were talking to each other and exchanging information to

that that uh that basically provides the the the the polic that that that we needed so um so knowing the the components uh in action here uh so we have cxe and then we have a two modules SC c. and then SC sv. which is the de client and server components knowing that those were the the main thing that that I have to look for I decid to jump and and do the actual reverse engineering process so um and this is the part that we jump into the reverse engineering demo uh so let me stop this for a second so we are going to start by looking the into the um into the SEC binary itself so here I

have a this tool called P which is the the the Tool uh in charge of Performing the uh the the analysis of the executable binary so we have a c open and we have a different properties of the c b itself um the the binary is a as an standard binary that is that is present on the system 32 folder uh we uh show a moment ago that how this B can be executed so we are going to see it now so basically the binary if I call it from any placement system it will be through thanks to the variable PA it will be uh found on system 32 so if I call the seate binary with some specific

arguments we will see that we will see that the command execute successfully and then if we open this output that you see we will see that the output the policies output that we need were present on the output of the B so things like the minimum password age maximum password age minimum passw length the password comp all of those things that I was briefly mentioning a moment ago can be extracted and consumed through through this tool so remember these common L arguments that I'm showing here so we have export and areas so those are the markers that we are going to look for in the reversive code to understand how this uh uh flags are being processed and uh how

we can use that to understand how this information is being obtained okay so if we get back to here um we can see uh something important to mention that there are a bunch of imports a static import information uh on the binary itself and among those uh uh import information there is this uh D that we have we we happened to found that was the decline component of the protocol that give us this this data uh and among the the the the the information that we can get here we can also have access to the the exports of the functions that are being consumed by the this Library so once we the we have this information we jumped

into the this assembler framework so this assembl framework that I'm showing here is called realiz so realiz desktop is a it's a tool this framework tool that uh has a premium a free and a a paid version I am using the the free version here so basically I started opening this SEC binary I have some information on the binary itself here and then uh if I uh go into the assembly view of the binary it will show you it's going to show me the the entry point of uh of uh of the binary along with the different assembly uh instruction that are happening here we got we can ins things we can expect things such as the

the flow so let me yeah we can expect things such as the flow of the execution flow finary so we have a the assembly instructions but this time um Whenever there is a potential branching uh interaction here it is going to show different arrows uh to Mark the the the possible options that the the the execution flow can can take and this is what we are seeing here so we have all the execution flow of that entry point that we were seeing and this is the the compile representation of the entry point which is basically a function that performs some initialization for the program itself and then after the that initialization is done is will end up calling the W

Main which is the actual entry point of the program because this entry point is basically a kind of a stab that the compiler adds to the binary in order to be able to execute your the entry point of your actual code so whenever you work on a C++ application the entry point for your code is always main so in this case we see that this uh uh CRT startup function is basically preparing the the execution contact for before calling W Main so if we jump into W Main uh we have these two uh variables that get U received which are basically the the argument counter and the argument Vector that contains the common line input so

if we go to the bit below on the on the actual the compile code we will get to see that there are some comparisons being made against different tokens so the these tokens are basically the possible common line options that one can provide to this V I remember that we were uh interested on in two of those options uh we were interested on the export option and we were interested on the sorry uh on the um areas option right so we have a we have the export option here and then if we go down below we have the we should have H over here the areas option which in this case is uh so this

code over here is comparing if the input argument was the areas SL areas option and then if that happens to be the cas it's going to end up setting up a flag to an specific value so we are basically what we are basically going to do is to track where else this value is used to understand uh what this setting this value to a specific uh setting this variable to a specific value what does is ended up way us to do so if we if we check uh the areas uh um parsing then uh we also provide the security policy argument which is going to set the the variable in question to one then if we

will have provide a different value the different uh a different argument the different values will have been set to this variable so uh so as as we provided security policy the the security policy flag variable was set to one so if we track the usage of that variable across our code base we can see that this uh this value is been set to this uh new variable called in this case something that I I REM one that's something that I forgot to mention sorry that once we have the the compile output of the binary we can rename the the the different variables to a different name just for to to easily recognize that what the do variables are doing so in

this case I rename this one to final security policy flag so if we again see where this uh where this variable is being used we can found an interesting things such as this code in here where the value is being pass as a as a flag so yeah we we we see that this function which is called SC get security profile info is using that flag with the value that was set through the common L option that we provide to to SEC edit um okay so one more thing really quick so we mentioned that we also wanted to check on the export uh yeah on this export um uh common line option so the export Comm

line option is being handled on the different on the else uh uh C of this switch uh so if we go to about this line we we can see that that uh if the else part of that switch is being handled here and that the flax export uh call is being set to an specific value which in this case is is one that is some spoiler that I have for you so if uh go where the flat export is being compared to one uh within this code the compilation we can see that this if is being executed so this is the the the actual logic that is going to be executed if we provide those specific values to C so the the

logic is going to get over here it's going to use uh the flat that was set thanks to the areas Comm option and then it's going to call this function okay so we get to this point now we need to understand what this function actually does uh so if we try to De compile that function also we will get to see that the function is implemented in a different model which uh which is the the model that we were uh looking for initially the SE C.D so if we open this uh this uh this we open through this assembler what this function is doing so we will get the assembly code we will get the we will

get the the execution flow of the function and we also get the C like the compilation uh from the the code itself uh so among other things the function is paring the data and then it end UPS using that data uh to call uh this uh function called ndr client call free which uh uh for uh those who don't know uh with I guess maybe many because this was something also new to me was that the call used to perform a what is called the RPC client call we are going to see what that means in a moment but the overall idea is that this call uh gives you access to an specific protocol so you can call a functionalities from a

a protocol exposed internally by Windows uh and get response from that protocol so and this function was implemented again from a different D RPC CRT 4. uh and the information from this call will end up being used by the get security profile to uh create uh a data structuring memory and then return that data back to the Coler so the profile data that we need should be happening from after should be happening from calling this and their client call and then executing some logic running different process okay so that's about it uh on the demo so we know we have a clear path on how to uh reverse the we have a clear path how to obtain this information we

need now to understand a couple of things before before moving on but uh the the the very high level we we knew how to get that the data so uh the windows IPC so we briefly mentioned something about RPC things so the the the windows LPC uh mechanisms are are really complex so the windows use different uh uh ways to communicate between the sub system that are implemented by the by the O so windows we have a as you know we have a Services running that provides a different type of information usually those Services expose their functionalities or the apis to to to the to to the clients running on the on the system through an IPC

mechanism called RPC so RPC is basically a way to execute uh functionality running a different process uh Microsoft uh this this is something that Microsoft of D inent invented this what there was an exander around this called the DC RPC Microsoft ended up taking that exander and extending it to create the the Microsoft RPC version and the Microsoft RPC version is used by many uh sub season windows from service libraries different type of fineries and there are a lot of custom protocols built on top of RPC being the windows SC or the security configuration extension uh one of those protocols implemented on top of RPC so from the code we saw uh we we get

to found that the SE c. contains a RPC client that can speak into this protocol and we also uh found that there is a dll component um that contains the the information to understand this uh request or this messages coming from the RPC client and be able to respond into those messages and and that is the the server component for this uh for this protocol so um so at this point we have a two ways or two possible paths we we either go ahead and and Implement an an an RPC client from from scratch and but that by that I meant uh we can if we know how to speak this protocol we can uh send this a message request from

oquare itself and then wait for the response from the SE server so that was one possibility which was doable because the there was a way to uh actually create the the the code required uh to implement an RPC client but then we we also found a second way uh which was actually around using CAC SC c. the same way that oqu was using it this was a way more simple Le uh approach and also reduce the reduce the the complexity implementation complexity and reduces also the risk of running with a an um a protocol implementation that doesn't fully match uh the current and future changes to to this protocol so we want to uh go ahead and and and

Play Safe And and just use the the scli d uh and consume the DL from the the exported function it in orderorder to um use that data so uh if you remember when we were checking on the demo that were a bunch of export uh on the dll when we were using the the P uh binary analyzer those exports are basically uh the functionalities that this dll can can export but in order to call into that functionality we needed to uh have a new trick in place which was around using something called Dynamic linking which is basically a way to load a DLo um uh into the into a process and then retrieve uh the addresses of uh the

function of exported by that dln in memory retri out those address addresses so we can call into those addresses programmatically so we want to have a piece of code that can uh do this logic uh of uh loading the DL getting the address to the to the exported function and then call into the exported function so and that can be achieved through uh two API calls on Windows uh first we have the load Library API call which will be um the the one in charge of loading the D and then we have the get Pro address uh API call which will be the one in charge of finding the the address in memory of a given function so

this is uh some code that I put together here we're going to see this working in a demo in in a moment but uh the the other idea is that uh by doing this uh one can use some uh tricks in in and C++ to be able to call uh the function in memory using the exact the the exact signature of the function that was required for the signature to be able to receive the data in a in a proper way so while we were doing this we kind of uh wanted to to have this work working as soon as possible so um something that we did was to actually check for the usage of this function across the the entire

uh GitHub codebase so we basically did a GitHub search passing the name name of this SE get security profile info function which was a function that we found that was giving us this information so uh after searching on GitHub uh one of the actually the the only hit that we got from an actual implementation that we were using this function was a a script A POW shell script from the NSA so basically the NSA was using this same approach to get security uh compliance information um um providing the security compliance information to a a government agency so they have a like a an open um uh Source division on NSA which were which was publishing this uh this power scpt doing

this this trick so we were quite surprised about that and that kind of validated that we were on the right track for for this work so okay let let's jump into the this RPC client demo uh which is the the demo sorry uh yeah the demo that we uh the first PC that we created you to to validate this work so over here I have a a C++ Syle C+ class application which is going to do this work of uh linking at runtime the d uh then getting the address of the function that we need and then calling into this function after doing a internal trick to uh match the signature of the function so we're going

to to see the call in here uh something that uh that we wanted to know at this point was to actually understand which were the values that we were that we should be providing to the to the to the functions one one I we call it I mean through aesthetic analysis we saw the the variables in and the the how the the the execution flow was going to be but we didn't have a like an actual confirmation of which this these values are going to be so uh and that's why where we ended up validating this work through a through a debugger so on a debugger as as I mentioned on the slides we we can perform something

called Dynamic analysis so dyamic analysis is the what is going to allow us to inspect the execution of this buing memory so we have a different tool this time in order to to run the this Dynamic analysis process this tool is called Ida Ida Pro so there are different version of this debugger in this case I am using one called Ida free which is a a pre version of ID Pro basically um and this uh tool all come UPS came up with the the compiler tool and also with the um buil-in debugger so one can switch from this uh uh from this execution flow view where you you see the different execution blocks and the assembly code for a given

function to the compile view of that same code and what this is what is amazing about this uh this tool is that the deer allow us to put break points on the execution of the program so if we execute the the the program uh using the the expected uh uh common lining here we can see that uh the pr start to execute I have a a breakpoint hit uh on the in in on the P available instruction on the DW main function then if we go down below we will see that there is a there is all the paring of the comand options that we saw a moment ago and then there is the call to the the function that we were

interested in which was SE get security profile info so we are going to put a a break point in here so if we just hit continue the break point is going to be hit and then we can uh step by step uh contined execution flow until this function is getting C and from here we can inspect the the actual value for those uh variabl so the first one is car coded to 300 and then the second one is car coded to this uh uh uh value in memory uh which is F1 so if we call the with this value we will be able to see that uh uh the the the policy information coming rning so let's go

back to visual studio so we have a visual studio processing here so after some back and forth uh we play with different values we found that there is this uh SE area security profile flag that we can use which uh um with more disassembler we we found that the best value to provide with was either 3y of the the requesting for the entire set of configuration polic which is what we are to use in here so I'm going to change this value to this one and then uh let's go ahead and compile this process yeah uh so first uh thing here is the the call to the call to Lo Library so yeah so we have here the process

running and this is a a utility that I used to called process hacker that I used to inspect the the state of a of a process so we here we see here that we're going to load a new library into the process uh so if we continue the execution the [Music] scl model was loaded into Tate which is the binary that we are dividing at the moment so then uh as I mentioned the uh the function address for the the function question that was sporten D was retrieved and then uh the act the that export is actually getting called with the the vales we provided and that should populate a a a a memory block that we

are uh provided on The Code by the way this code is available you you can look in in detail later the point here is that I want to show you that once that code is retrieve uh one that call is is performed the the the actual um profile configuration data are going to be retrieved and that something that we can act on so we can export this information and and have the same output that the SE does so just to rec up because I I think I I I have in in a hurry so um just to recap we got the the address of the function in memory we uh did C++ trick to cast that uh row address into a a

function pointer signat which is this function poter pointer signature in here which which is something that we also reversed so we we got to understand which was the signature of that function and then uh with that information we ended up calling that function pointer with an specific set of values that we also obtain from the reverse engineering process so among those values there is something called um uh the profile info so this profile info uh is a row pointer is a a void pointer that uh one needs to provide to the function and then that pointer is going to be uh converted or cast into a different uh structor called SC profile info which is the this this another

reverse reverse structure that we have to understand in order to be able to um pass this this data okay um let's uh stop this and continue presentation because I think I'm running out of time so okay we got the the PC working so we now not have a programmatic way of retrieving this security configuration information so what I mean how we can get this into our squ getting into getting this into osquery requires um actually following the osquery contrib contributing guidelines so there is a very really good and documented process on how to perform this contri distribution there is also um a document called The llbm Calling standard that uh gives you a um the information on the

coding standard used on the osquery code base so one we can can follow that in order to understand how to U format the code and where the guidelines have to be followed uh before contrib contributing to the OS codebase there is also anac which is a full of people uh willing to help so I created this PR which was a merch uh few I which was merch last month so this uh this PR basically contained implementation the programmatic way uh of uh calling into the SE get security profile info API after performing the runtime linking um so having and and also contain the code to use that information and expose that information through a oqu bual table the new table uh was

called security profile info and this um disable was uh merch as yeah I mentioned that it was merge it was merch but the something that I wanted to to mention here was that the the most difficult part of a contributing to was the the actual um C review process so getting people to review your code is sometimes uh something difficult um especially after submitting a big amount of code and then submitting a a a complex PR uh and another interesting aspect of a contribution is that the the quality assurance is something that uh every every contributor has to be um have to uh ensure that that it happen in in a proper way so uh along with the

contribution uh you need to also create automated test cases and performance test cases uh just to make sure that your code is is running aspected across uh the latest OS versions and all oos version too uh as I mentioned the security profile info table was a merch uh in the was was merged and it's going to be released on December 22 and the the the version of wqu that is going to contain this change uh will be the version 570 and with that uh I would like to thank everyone to attend for for having attended this this talk and I would also want to encourage you to uh push the limit of Open Source tools and uh allow

yourself to contribute with new functionality to these awesome tools that everyone use on the field uh and just to finalize we are going to see a demo of this thing working inside the oquare so we have a the osquery uh binary here the Comm line version of the oqu binary called oqu I so this sarei finally what it allow us is to have access to the different tables uh Exposed on the OS so if we we just ask for this information we're going to see a ton of data which is are not going to be properly formatted because of limitation of the conso that I'm using but these are the the the information that we are going to

get which is the exactly same thing that Cate will output so if we um just uh consume or Square from the Comm line and do the same

thing and now put this to s outut p yeah then we will see this in a way better format hopefully yeah there you go so these are the different columns exposed by this table and um we can see that the data that we need is there and this allow us to write the the security polic checks that that we needed and with that I would like to finish the talk and and thank you to everyone thanks everyone and thanks Marcos for working on this and you know I'm I'm happy to see a talk on reverse engineering in the context of making um defensive tools better uh because we often talk about reverse engineering more in terms of like malware analysis

and all that so that was great thank

you thank you very much excellent talk um we don't have any questions in the zoom but we expect some conversation and questions over in the Discord channel for your talk so everyone knows that the speakers will be heading over there for a little while to uh interact with you about this talk thanks for the

presentation all right we'll be taking a quick break and uh transitioning to our next speakers see you in a

minute