MacOS Security: DYLD_INSERT_LIBRARIES Injection Challenges

uh by farad barua and palak bansel farad is currently working at product uh is currently working as product product security engineer at Honeyville and holds around 5 years of experience he has delivered over 2,000 hours of training at various organizations ranging from education institutes to government bodies joining him is palak bansel whose enthusiasm is deeply rooted into the mission of protecting the digital Ram together they will be discussing on Mac security dyl insert Li libraries injection challenges so let's welcome

them can you

keep hello everybody hi I know it's been a long day long day with full of knowledge let's continue to learn more with this particular session where farad and I going to speak on uh Mac OS D yld Library injection so uh as already introduced my name is palak and I working at honey as a product security engineer I have a have an experience of close to 5 years and today I'm here um you know excited to share more knowledge with you on this topic this is my colleague Farhad hope I'm audible yeah um so my name is farad Sajid um if you have been into some other conferences as well somewhere or somewhere you might

have encountered me so I've been presenting it for some while and um already I have been given some introduction about myself so uh yeah uh let's get started with it and uh we'll connect if you want more introduction about me right okay yeah PA go ahead okay thank you farad so I'm sure we must have used Max sometime in our life here and there if not used must have seen it right um today's topic will be about the Dy Library injection even before we delve into the part of the the injection part let's try to First understand what are the do libraries and even before I we go into that topic I just want you I

want to ask to all of you do you are you aware about the dll injections or the object file injections yes okay I I see few knots here which is good so what we see in Windows this is the counterpart of the same in Mac right where we need where we deal with the dynamic libraries that are loaded during the runtime of an executable or an application so basically this features this feature allows to indicate a a process that is going to be run to load the dynamic libraries and uh when the executive is launched most of the times we don't even come to know about this process because it's seamless it happens on its own

however if say we encounter some error wherever the dynamic Library fails to be linked then we realize then there is a frightening error message saying um you know unable to load the librarys dyld unable to load the binary some error of this kind and then we realize that the linking process fails now I'm I'm sure like we must have thought in Once In Our Lifetime that why Apple products are so expensive right but have you ever thought how secure are they let's try to understand few of the security features that Apple platform provides you know in current time now Apple's operating system software is designed with security at its score this design includes uh secure boot secure

enclave and various other features that we see on the left side of this snap this snapshot has been taken uh from the official website of Apple on the right side we can see that there is the uh root of trust which forms the basis of the secure boot now there is a bootroom a bootroom code which is which is the root of trust and forms the root of chain uh for the secure booting process in the Apple uh in the Apple platform now uh this secure uh root of trust is accompanied by a dedicated AES uh cryptographic engine which is responsible of securing and securely and efficiently generating the cryptographic operations carrying out the cryptographic operation and then there

is a secure memory storage then there is the secure Enclave which is a sub secure subsystem of the mean apples uh which is integrated in the Apple system on chip itself and it provides a layer of additional security which makes sure that the sensitive user data is is intact it's not compromised even when the application processor kernel is compromised so it the secure Enclave does not have its own Secure Storage but it has the mechanism to keep the user data secure in the attached storages which comes on the system on Shi provided by Apple okay so this is about the root of trust secure Boot and secure Enclave other than this there's kindal Integrity protection which makes sure that after

the initialization process the uh kernel the kernel code is not changed it's not compromised with the kip bit the hardware which is used to set the kip is logged so that it's not manipulated after the initialization similarly is the fast permission uh restrictions this comes with the Apple uh apple a11 and bionic so basically it includes a CPU register that quickly restricts the permissions per thre moving on next next is the system co-processor Integrity protection this is similar as Kip there is a co-processor who that that has a firmware which performs quite important task for example it initializes secure Enclave like I told so it's important to make make make sure that the co-processor firmware is also secure and

it's booted securely so the mechanism that is employed with the internal Integrity protection is also the same as system Co co-processor Integrity protection okay and the last two are the pointer authentication codes and the page protection layer pointer authentication uh code is nothing but to protect the exploitation uh of memory corruption box this basically uh prevents the modification of function pointers and return addresses then uh then comes the page protection layer it basically prevents the user space code data to be uh prevents it from modification after the signature verification is done um so yeah these are pretty much the security features that are provided by the Apple platform on the hardware

level now let's try to understand about the secure boot process with the Apple silicon chip so like we see bootroom again this left side snap is from from the official website of Apple uh the first is the bootroom it is the root of trust this is where the secure boot process starts and it's like the zeroth step uh step of the uh secure boot so boot Ro is responsible for validating the LLB which is the low-level bootstrap signature once the lowlevel bootstrap LLB is launched it then verifies the uh signatures of the system paired firware uh which can be um you know uh so the Apple chip is not only responsible for verifying the firmware or the software but also the

policies the security policies that are implemented so LLB then validates the system paired firware signatures uh like storage displays Thunderbolt Etc it's also responsible for checking the local policies now these local policies is a text file these are user defined policies that can be used during the uh system Bo Bo up or during the runtime security policies the difference between these security policies uh validation is that the signature validation is done locally uh by the uh secure Enclave it is not done by the Apple centralized server so the signing of this um these local policies is done locally and the validation also happens locally with the help of the secure Enclave processor then uh once the LLB uh

validates the local policy signature it passes the control to the iboot stage two signature according to the local policy now this iBot is also responsible for checking the local policies the information about it it has received from the LLB that was the step prior um after that once the ioot uh validates the Mac OS paired firware boot konner collection and the auxiliary konner collection this information also it receiv from the local policy that has been given to the iot from the LLB part once all these validation happens then the system is securely booted up and there is a full-fledged system to be used available for the uh use there is another feature called SSV uh it's a

kernel uh kernel mechanism that is used to verify the Integrity of all kinds of data be it code or non non-code uh during the run time and it rejects any data which is not properly validated uh during the runtime so this is the secure booting mechanism with the Silicon Apple silicon chip uh that is being there in place right now okay so looks like apple already uh provides lot of security features that are already in place and that we as a user already take benefit of them now let's try to understand what is this uh dyld libraries and how what are these what what are this feature and how what are the loopholes and how can they be

leveraged to perform these injection attacks okay so to under this uh to understand this technique let's first delve into the into how the application loads a dynamic library Mac OS like any other operating system be it Linux or Windows has the feature to load the dynamic libraries using a dynamic Linker so basically that Dynamic Linker is used to load the dynamic libraries which are called uh dilps say I have an executable or an application that I want to launch and that application needs to it it has some Dynamic Library linked that needs to be uh launched along with the uh launching of that executable so Mac OS will uh basically launch the mac o loader which

is responsible for loading the app code data into the address space it also will load the dynamic loader into the process and pass the control over to the dynamic uh Dynamic loader now this Dynamic uh this Dynamic Linker has a Macco header now this Macco header contains essential information that will be needed by the system in order to load that particular Dynamic Library when the execut executable is being launched so this Macco header contains particular information about the dynamic library for example example the name of the dynamic library that needs to be used or the list of the dynamic libraries that are dependent uh that are dependent libraries and that needs to be linked as part of the

executable so there is something called install name which gives the complete path of the of that particular Dynamic library that needs to be loaded this all information will come as a part of the Macco header and there will be some load commands that will be uh read by the uh Dynamic Linker in order to load those particular Dynamic libraries so as you can see there are these um load commands which are part of the Macco header are nothing but the data structures on the left side as you can see the important load commands that we need to take care right now are LC load uh Dy LC load weak dyp and the LC reexport D lip that are

highlighted I'll try to explain the meaning of each one of them so LC load Dy lib basically it it specifies the dynamic library to be loaded at the time of runtime and if this uh particular load command is being set then the dynamic Library needs to be loaded otherwise the executable will not work it will not be uh executed so if LC load uh Diop uh Dy uh specifi a dynamic library to be loaded at a runtime it needs to be loaded otherwise there is an error thrown if that Dynamic library is not found or loaded adequately then is the weak dialup it means that a specific it specifies that a uh library is being weekly linked

which means even if the library is not found or properly loaded the application or the executable will still end up running the lastly it's lastly the last load command specifies the dynamic library to be exported by the binary or uh

Library okay so like I told every binary has a um has a install name install name is something which will be used by the dynamic Linker to identify that particular library and this information it will get from the Macco header which which will be coded by the developer inside the executable as a part of macoe header so uh the this install name will also contain the information about the path where the dynamic Linker has to see in order to find that particular Dynamic library now there are um three path prefix as we can see here executable path loader path and R path executable path is basically it contains the path to the directory containing the main

executable so if I want to to launch an application and that application has the dependency on some Dynamic libraries this executable path will be the path of that particular Library uh particular application or the uh executable that is needed and that will that has a dependency on other Dynamic libraries second one is the loader path now like I told there is a Macco header that is needed uh to get the adequate information in order to load those Dynamic libraries this loader path will be the path to the directory that will contain those Macco binaries the information that is needed by the uh Dynamic clicker lastly is the rpath so rpath is a variable rpath is the variable uh that

will contain one or more paths towards the dynamic libraries LCR paath command is again a loader command that will be present in the Macco file Maco header that will that LCR paath will be taken and will be replaced by the r paath and will tell the uh Dynamic Linker that okay these are the parts of the dynamic libraries that needs to be loaded in order to execute this particular application so um yeah these are the three uh path prefix that needs to be defined inside the Macco header now the developers can use various Tools in order to Define this rpath one of the tools is the install name tool that can be used uh that can be used in order to

Define this rpath for the dynamic libraries so

um all right um I believe there were a lot of Hardcore terms right uh and many of the terms were newly being seen for the very first time for most of you right and yeah that is one specific reason behind thing that will be that to buy iPhone you have to sell kidney and to buy Mac OS you have to sell both of the kidneys still it doesn't comes right I'm not sure what's the price of kidney going on but uh anyway but uh at least you now know the terms right and what's the best if you are getting to know about the terms later on you can look into it but yeah you will have the slide

so and they have because this terms itself are it took us a lot of time to understand for ourselves at the very first go because they are very much complex and apple lies to likes to keep things very complex like so that even though hackers can't figure it out what it is doing at the nutshell and that's one of the predominant way of Apple to achieve security uh but again it's a very hardcore security to talk about okay now moving forward as of now I guess you have understood a bit about what is dyld and what is dib in the nutshell right okay now if you see whenever so if try to to compare this with the concept of dlls

that you encounter in Windows or shared object that you uh encounter in uh Linux okay try to correlate it and then it will become more easier for you okay rather than just focusing on those hardcore terms it will be there but uh try to correlate with it and I will also try my best to make sure that we go with that particular Pace okay so for every Dynamic library that is out there okay so Dynamic library that DL compare it with that so in context of Mac they have something called install name okay now what is the use of this install name this install name identifies the library to the dynamic Linker which palak was

explaining about okay so when you when you basically um see this okay this is the install name and this is the dynamic Linker and then the path that palak was mentioning EX utable path our path and all then only Dynamic Linker will fetch from that particular path and present it to that of the actual executable binary right so once that particular process is done the next thing in order to go ahead and load an executed the first process that up till now what we were discussing was linking part how we are linking it with that of the dynamic Library once linking has been done next thing what do we need after linking if you if you

remember the core concept of OS linking then loading then compilation then execution or the binary itself right that is the flow right um correct me if I'm wrong okay so linking done the next process is loading correct so let's talk about the steps that are involved in loading so for every dependent Library okay uh dependent Library when I say there is a separate file which will uh contain the additional code and resources what actually the dll file does they are just an additional code or additional uh resources that the main executable always look forward to in order to just import them when during the run time when it is as required right so here what happens is the dld will check if

the dependent library is already in the dyld shared cache or not something related to memcache or uh caching uh way of web caching that we see right that if it is already there uh why not fatch it from there so same thing happens here also okay but that is not the context with when we talk about Windows or Linux right there is no uh caching mechanism for shared object or this thing uh what do we call it as DL files to be picked up uh don't confuse it with the temp that you see uh that is a different concept uh here we are specifically talking about caching of that particular DD Library as a whole

okay so here as I said the DD check will be happening whether that that particular Dynamic library is there at the dld Shared cache so dld shared cache is what it is a pre-built cache which is system provided specifically meant for your uh dibs and the relevant Frameworks okay now where can you find this dld shared cache right so that's the path system library dyld and Dore shared cashore whatever the binary is so each and every application that you will have in Mac then so that's why I gave the athetics because uh so for example let's say Sublime Text you have okay so it will be system Library DD DD shared cach underscore uh Sublime whatever the

application name is so if it is let's say App Store so underscore App Store so I I hope everybody got the context what I'm talking about so that's why I gave it at asteris so first that will be the search path now can you guys think what can be done here we know the path okay what can be done here I gave you a hint try to correlate it with cash poisoning what can be done here can we go ahead and create a shared cache file which is a poison file means a malicious file and rename it and put it over there can we do that that would be first test case that will come if you

are doing a pen test or an assessment right that will be the very first thing okay keep that thought in mind we'll talk about it okay okay so that is there next thing is if in case it is not there in that particular location if the library is not there in the shared cachier then what it will do is that remember the LC load command that palak was talking about then it will go for lcore load command to check what is the DI load command path okay so that will be there now over there again your R paath will again come into the picture Linker there were three uh different types of path executable path R path and

another was I forgot but here specifically it looks for the r path only other two are not taken into consideration okay so lcore loore asteris again because it will be application specific right whatever application you are dealing with it will be application specific followed by the diil so if that is declared it will basically look for the configured R path right so dyld will search for the independent sorry for the dependent Library during the runtime uh one is in the embedded path or in the execut executable itself right now if you look into these two things that I just discussed can you guys try to recall and see how it is similar to something we do when we are doing D

injection we have some uh specific paths right first it goes to the executable path then after that application then program data uh program then system 32 program x86 so they have that hierarchy right the travel that it looks through that okay first I'm going to look the dll here then here then here then here then here right that is there is this flow if people have done dll injection so does it correlate something similar to that if if you look right it it does look something similar to that yeah yeah good so next if still we are not able to find the dial file or the loc where the dial file is residing then in that case

what will happen is uh the dynamic loader will search for the dependent libraries in the base standard location so what is the base standard location so these are the base standard location that is user local lib uh user lib and system Library Frameworks okay these three are the base locations where it will look for the dial okay now in case there is a missing dependency or a mismatch with it versions and they are not marked as weak the launch process is terminated immediately one uh this thing uh point to note they are not marked as weak remember one particular load command that palak was talking about lcore loore week diil so if you are explicitly mentioning that that

particular uh dial is a weak load then yes that will be included right but apart from that if you're not explicitly mentioning it developers don't do that anyway okay because of the lot of guidelines Frameworks and policies and all uh but yeah if you are not explicitly doing it because if you do that it will be easier for an attacker to go ahead and run a grap command and check for this particular weak uh LC load command Okay so developers oftenly won't do that uh so you can remove that from your test case but just for your information knowledge purpose you should be aware of that okay okay so um okay so I was saying that how will

you check for this whether u a dib injection is possible or not right uh oool have you guys heard about it if you have done iOS pen testing o Tool uh you might have if not so there is there is this tool called oool uh similar to if you try to compare it with uh you can use use it for debugging for runtime analysis it can do a lot of things it is similar to that of GDB and lldb U um if you guys have used that so it is similar to that uh but it is specific to Mac right so if you use oool followed by hyphen L and give the name of the binary

over here you can see I gave zenmap which is the iOS Mac OS version of uh the GUI version of n map right and there I was specifically grapping for this particular load command called LC loore dib so here you can see I found lcore loore dib in four instances right along with the path if you see system Library framework core Foundation user lib Li system system Library uh Frameworks again and the top one is user lib lib object ca. di right so this is the very first way to how you go ahead and check for uh this thing uh di whether the dib is there or not or something you can GP or not okay get

hold of them certain times this haven't worked for me specifically when the M1 came into the picture it didn't work for me for I don't know for some strange reason uh so there is a very well-known researcher called uh he goes by the name Patrick he has created his own diil hijacking scanner right so it's kind of an automation uh he has done so that works pretty well um so that is also something you can look into right um so if any Dil have at the rate R path so over here we don't have that particular thing but uh what you will see is that if uh like you have this keywords called command size name

time stamp current compatibility and all similarly you will have a keyword called rpath in case the r paath is declared right so if any of the dils which are there has Rath declared so immediately you have to look into which load command lcore rpath remember that pal was talking about lcore R paath okay so that will be the second thing that you have to look in case there is a r path coming as part of your this thing output whether you are using o tool or whether you are using that uh tool created by Patrick for scanning for dial hijacking even though that gives you the full uh uh this thing output of whether the dial

hijacking is possible or not but still you will get in the output that whether our path is declared or not okay okay now here if you are thinking that all the complex and hardcore Parts where up till now uh welcome this is going to get more complex now uh we'll try to make it as simple as possible but um it's going to get complex for sure um so this is uh the newer code base of how so specifically when Apple chip came into the picture so M1 series and all right S Series and all so all the uh Apple series uh when it came into the picture how so earlier di injection when the Intel series was going on it was

very straightforward and simple very simple okay I have a screenshot I will show you it was very straightforward and simple but for us we are the main context or the main idea behind showing this presentation was uh why it has become difficult in the later series that is the M1 series or the update M series not M1 specifically M series and the t2 chips so this is the code that they have implemented in order to restrict or restrain the exploitation of diil injections in Mass okay so what they have done so first thing they have done is something called as uh sip uh you remember the very first or second sorry second slide where uh we were talking

about different protection mechanism Kip siip and all fpr and all so system Integrity protection we were talking about and the reason behind why we were talking about is because system Integrity protection plays a role when patching this uh dyld Library injection methodology uh technique okay so let's understand how this sip verification happens so there is something called as CSR check yeah you can see this uh uh line of code uh bu use uh using sip CSR uncore check CSR allow undor task for p ID okay so this CSR check is basically checking if the CSR allow task for p bit is set right and uh if it is set what it will do is that it will go ahead and

basically check for Flags Okay so there are multiple Flags you can see CS op CS op status right and then it will go for uh this thing cscore restrict so it will basically check for this Flags this Flags basically comes from something called as CSR configuration okay now in case uh this um CSR uncore check sorry not CSR uncore Che it is is um yeah CSR Che basically returns Boolean value zero then what will happen is that immediately that uh uh binary will not load that diip so they have mandated it that CSR check should always not should always if and only if it is binary bit is coming to one then only we are going to proceed further for rest of

the checks in order to load that dpse okay it's not just that okay you are getting the bit map value is one and you are able you will be able to go ahead and load list of the dials it's not like that it is just one of the first checks okay now that basically will Define or not Define determine if sip is enabled or not right earlier in the Intel series The Apple was trying to achieve the similar way of CSR underscore check with something called as CSR uncore restrict okay so if cscore sorry not CSR cscore restrict is enabled then only it was saying that okay we'll allow you to go ahead and load the dib into the program

context okay now the next thing is that uh okay the next thing you will notice over here is if flags and csor require LV is restricted equal to false Library validation equals to true and then there are tons of other codes what it is doing over here is that it is checking for two things one is called csor require library and another one is called csor require LC code these two are called as signing flag so um in case you have done iOS pent test you might have uh done this Uber app signer sorry is it Uber app signer yeah yeah yeah which basically signs uh with a dummy uh this thing code signing certificate and provisioning profile to

an IPA file whichever you provide right so that is something you do it as an attacker perspective so once you do that what it basically does in the nutshell it basically goes ahead and sets the signing flag and what determines the signing flag the csor require LV and csor requir _ LC code so they are the one which basically checks whether the main binary which is loaded is first of all is having code signed or not if yes then whether the same code has been sign used to sign the dib or not because it doesn't make sense right that your diali is signed with some other code signing entit uh entitlement and your and the

provisioning profile and your main binary is signed with some different uh code signing entitlement right it doesn't make sense both has if it is from Google it has to be sign sorry it has to be signed from Google everything has to be signed from the Google certificate or the code signing certificate right so that is the one which basically looks into it okay so that was related to uh uh CSR check sip check and uh code signing next is amfi so amfi basically is Apple mobile file Integrity okay so amfi if you if I put it very simple way is the one which is responsible for setting up process restrictions how the process should behave what should be the memory context

where it should run how much memory it should take how much uh process uh CPU memory and the GPU memory and the process uh uh working bits and the private bits should be set everything is basically determined with the help of amfi so this is the one so um um so earlier it was there was something called as MF uh uh which was basically extended in the newer version with Apple mobile file Integrity right and amfi is the one which enforces Sip and code signing so Sip and code signing the mechanism to validate and verify the binaries and the dbes right but to implement them and enforce them amfi is the one responsible for them

right also mfi checks for second thing that is called as whether restricted segment has been defined or not when we say restricted segment what do we mean by that simply put restricted segments are something like dep or non-executable bit which you have if you guys have learned about memory uh corruption vulnerabilities uh the protection mechanism that we have is data execution prevention in the context of Windows and no executable bit n x bit that is set to true in case of Linux right so what they basically do in the nutshell they basically go ahead and uh restrict a particular set of memory segment as restricted so if in case you are trying to inject on that that will simply crash

the program with uh that sis or some other kind of error right that is what it is in in the nutshell right so here uh this basic uh mfi is responsible for checking whether the binary has the restricted segment set or not right another thing now comes is that we have the release build and we have a debug build so whenever you are um uh going ahead and basically um um building the final build it will give you two options uh whether you want to uh go with the debug build it will always give you two this thing output one is a debug build and one is the release build right now in debug build oftenly whenever you are

doing a testing as a developer perspective this will be set build for testing right so if build for testing is set um uh this compiler flag is set the reason is so that we can debug it right that's why because it will be testing so we can check for all the errors and whatever issues that are coming so if this flag is set then of course you can debug that particular dial or the main binary itself and I said it will be zero on the production builds because that's will be release build and we don't want anyone to go ahead and debug it right okay okay next thing is so this is uh uh this thing uh check

dyld policy internal this is the pseudo code because Apple it is completely created by Apple and one of the researcher has went ahead and uh dragged and dropped it in uh Ida and was able to get a pseudo code it's not the actual row code right so if you uh if you look into this so there are multiple registers that has been declared RX RX r113 R14 RX RBX CX and all so there are multiple registers over here and if you try to just look into it and try to understand what it's trying to do is first of all is that you will see Mac OS DD policy at path remember about the local policies that we were talking

about at the beginning of the session right then next is the Mac OS dity policy environment variables uh policy fallback path and Library interposing so this four basically what they do is that they will basically check whether the environment variables are correctly set for that particular application to run second is fall back in case there is some errors or some issues coming back uh what should be its fallback mechanism so that um it doesn't leads to any kind of uh issues or injection related vulnerabilities it should come back to it some uh stable state or should close the program something like that right so that's what is defined in fallback path and Library interposing means if there

are are similar two libraries in the same two different locations so let's say user system list and user system framework right same libraries are defined in that case which one to give more priority to right so that is basically declared over here so amfi will basically determine the flags by verifying the calling process right and yeah Mac OS dld process collect State verifies the code signing properties which is the entitlement I was talking about okay now thankfully uh the complex part is over let's get to the bit of enhance on part so here a simple code which is basically having a Constructor and this is a um if you look into the code it's doing nothing but we have a Constructor

defined which is taking two inputs right and uh it will simply print uh diip Constructor called from whatever the location with the argument and it will log a particular error in case there is with di Constructor called from whatever it is so this is simple proof of concept script which will basically uh be considered as a Dynamic Library okay so it's a dynamic Library okay think of that you have DL file which you create with msf Venom right so it's a simple that only okay and this is a simple hello world program as the name suggest you can see it's the simple hello world program now this is the one that we did in the Intel

okay so if you look uh simple compilation with GCC okay so uh so yeah simple compilation with GCC we have a do out and all and we have our binary do/ welcome so if we execute our welcome binary we see welcome to dial injection simple demo which is the expected output which we're looking into now if you are going at because in that code we have not explicitly introduced our paath or anything as such so in case you want to include uh this thing any Dynamic Library during runtime or during uh initialization you can basically mention Dore insert library and give the name of the dld library that you want to insert followed by the binary in which you want

to insert so dyld dos simple is the first code that I was showing you and/ welcome is the simple hello world or welcome code itself and when I do that you see dib Constructor called from do/ welcome and welcome to di injection simple demo which basically suggest that our D injection worked perfectly right this was with Intel okay so we tried to do do with uh some uh production binaries this is a Meco view uh binary in Apple so try to go ahead and basically inject that particular uh uh di uh uh sample file that we created to the uh binary itself so binaries are usually located in application Macco view. app contents Macos followed by the name of the app

right um so we tried to do that and you can see um it basically went ahead and got executed and you see the Mac view file got opened up right okay uh similarly and when um how so uh we always look forward if we can see some logs right because generally with binaries what will happen production level binaries what will happen you won't see that message that you were getting with the uh that C file or C program sorry all right so how can you do so in Mac you will always have something called as console okay which can be used for uh doing uh logging of entire things that are happening over the Mac okay so here you can see uh in

one of the event it will show you that dial Constructor from this particular path has been called so if you are encountering this that means that D injection has happened for that particular binary itself okay and we did the same thing for Zen map it was working perfectly but when we did for Sublime Text it was not working uh Sublime Tex is s if I think most of you might be aware of that if not it's similar to that of a notepad++ it was not working for that and we did that on uh this M series now we started trying to analyze why is this happening then we came out okay let's try to recreate that proof of

concept what Sublime Text was actually trying to do so here what we did was first of all we went ahead and basically changed the permission of the welcome binary to that of a root okay sudo Chan root welcome and then we basically set up the set u ID bit okay Su ID bit once we do did that you can now see the owner is root and read WR executable you guys are aware of but uh if you see s that basically means that it is a set u ID program right a set uid bit has been set now when I execute the program do/ welcome it says welcome to D injection which is supposed to be but when now if

I do this see the difference that TB is now not getting loaded earlier it was getting loaded right okay I went ahead and removed the set u ID bit so you can say CH mode hyphen s and now when you uh try to execute that now you see it's again able to load the dynamic Library which I'm giving right so one of the first restriction here is related to the set ID bit and now try to correlate with the concept of mfi and sip that we are talking about they were looking into those particular restricted segments at U idbs and all and code signing right all right here we have set up a again a simple uh

C program where we have set up a restricted uh uh this thing uh pointer right now we went ahead and basically checked whether that particular program has restricted bit set or not and you can see there is a restricted segment set right over here so you can use size hyphen xlm and the binary name restricted so it's you can see there's a uh segment which is restricted that means that program does has a restricted segment now if we try to go go ahead and basically look into uh uh we have to compile it with uh that uh set create restrictor restrict so that uh that restricted segment that we have set comes during the compilation and the

restricted segment gets created and when we try to execute it with our dib uh uh proof of concept it basically gives you an error saying restricted segment program again that is what mfi basically was helping us try to do lastly uh the code signing part so here we just created a self- signing certificate right uh and uh uh the name of the certificate is di demo and so we basically went ahead and uh copied our welcome binary to welcome hyen code sign and uh we basically did a code signing to that particular binary and uh once done if now you can see it if you try once you have done the code signing you can verify it with this command code

sign I DB uh name of the binary and it will basically give you the information what is the sign nature size when it was signed info P list and all those information which basically verifies whether that particular binary is signed or not okay now if you try to go ahead and basically do Dore insert Library equal to D.S simple do/ welcome code sign you will basically see again it is not getting loaded and that is actually coming from the Sip which was basically validating the code sign right okay now uh before moving to the next slide how can we defeat this and any idea because uh since that uh uh set u ID bit was set by uh program was mine I

was able to set remove and set the set u ID bit so in uh the production application which you are downloading from App Store or from s some other places uh it will very much it will be very much difficult for you to go ahead and play around with the binary to remove the set uid bit or place it in okay so that you can skip coming to the restricted segment again either you have to reverse engineer it whole to remove the restricted segment again that increases the complexity lastly coming to the code signing so code signing part somehow you need to get hold of the code sign uh entitlement which was used in order to sign that particular binary

then only you will be able to sign the malicious diip and once you sign that malicious dib then only you will be able to load the malicious dial code right so that's what Apple has came up with in order to restrict and protect dib injection being exploited in mass in the late uh newer series of M that the Apple Series right so yeah uh that's all for uh this session hope you guys enjoyed it and uh liked it it's way above the time so if you have any questions or anything I will be near around uh please feel free to reach out to me and uh if you have any questions or you want to connect and

thank you very much and yeah