30:00 Mac OS

After my recent blog post, my old mate @_Dark_Knight_ reached out to me and he asked me a question:

1. 30:00 Mac Os Update
2. 3000 Marcos Dr 33160

Supported host operating systems include Linux, Mac OS X, Windows XP, Windows Vista, Windows 7, Solaris, and OpenSolaris; there is also a port to FreeBSD (only OSE version). Supported guest operating systems include a small number NetBSD versions and various versions of Windows, Linux, DragonFlyBSD, FreeBSD, OpenBSD, OS/2 Warp, Solaris.

'Do you typically callout user apps that allow dyld_insert_libraries?'

1. Most Unix-like systems, including Linux and Mac OS X, keep system time in timet format, representing the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC) on Thursday, January 1, 1970.
2. Download the user manual: Mac version. Tested with 'OS X Sierra' and 'OS X High Sierra'. Demo version: the converted images will show a black line every.
3. How does the Mac OS work? With the resurgence of Apple, this OS has become a major contender in the operating system market. Pre-loaded on all Macs, it provides a seamless user experience across the entire ecosystem of Apple products. This OS allows you.
4. Multics was the first operating system to provide a hierarchical file system, and file names could be of almost arbitrary length and syntax. A given file or directory could have multiple names (typically a long and short form), and symbolic links between directories were also supported.

The crystal golem mac os. And a few similar ones, and I will be honest, I had no idea what is he talking about, if only I understood the question :D Despite the fact that my recent blog posts and talks are about macOS, I deal much more with Windows on a daily basis, probably like 95%, and macOS is still a whole new territory for me. So I decided to dig into the question and learn a bit more about this.

As it turns out there is a very well known injection technique for macOS utilizing DYLD_INSERT_LIBRARIES environment variable. Here is the description of the variable from the dyld man document:

In short, it will load any dylibs you specify in this variable before the program loads, essentially injecting a dylib into the application. Let's try it! I took my previous dylib code I used when playing with dylib hijacking:

Compile:

For a quick test I made a sophisticated hello world C code, and tried it with that. In order to set the environment variable for the application to be executed, you need to specify DYLD_INSERT_LIBRARIES=[path to your dylib] in the command line. Here is how it looks like:

Executing my favourite note taker application, Bear (where I'm writing this right now) is also affected:

We can also see all these events in the log (as our dylib puts there a message):

There are two nice examples in the following blog posts about how to hook the application itself:

I will not repeat those, so if you are interested please read those.

Can you prevent this infection? Michael mentioned that you can do it by adding a RESTRICTED segment at compile time, so I decided to research it more. According to Blocking Code Injection on iOS and OS X there are three cases when this environment variable will be ignored:

1. setuid and/or setgid bits are set
2. restricted by entitlements
3. restricted segment

We can actually see this in the source code of dyld - this is an older version, but it's also more readable: https://opensource.apple.com/source/dyld/dyld-210.2.3/src/dyld.cpp

The function pruneEnvironmentVariables will remove the environment variables:

If we search where the variable sRestrictedReason is set, we arrive to the function processRestricted:

This is the code segment that will identify the restricted segment:

Now, the above is the old source code, that was referred in the article above - since then it has evolved. The latest available code is dyld.cpp looks slightly more complicated, but essentially the same idea. Here is the relevant code segment, that sets the restriction, and the one that returns it (configureProcessRestrictions , processIsRestricted ):

It will set the gLinkContext.allowEnvVarsPath to false if:

1. The main executable has restricted segment
2. suid / guid bits are set
3. SIP is enabled (if anyone wonders CSR_ALLOW_TASK_FOR_PID is a SIP boot configuration flag, but I don't know much more about it) and the program has the CS_RESTRICT flag (on OSX = program was signed with entitlements)

But! It's unset if CS_REQUIRE_LV is set. What this flag does? If it's set for the main binary, it means that the loader will verify every single dylib loaded into the application, if they were signed with the same key as the main executable. If we think about this it kinda makes sense, as you can only inject a dylib to the application that was developed by the same person. You can only abuse this if you have access to that code signing certificate - or not, more on that later ;).

There is another option to protect the application, and it's enabling Hardened Runtime. Then if you want, you can specifically enable DYLD environment variables: Allow DYLD Environment Variables Entitlement - Entitlements. The above source code seems to be dated back to 2013, and this option is only available since Mojave (10.14), which was released last year (2018), probably this is why we don't see anything about this in the source code.

For the record, these are the values of the CS flags, taken from cs_blobs.h

This was the theory, let's see all of these in practice, if they indeed work as advertised. I will create an Xcode project and modify the configuration as needed. Before that we can use our original code for the SUID bit testing, and as we can see it works as expected:

Interestingly, in the past, there was an LPE bug from incorrectly handling one of the environment variables, and with SUID files, you could achieve privilege escalation, here you can read the details:OS X 10.10 DYLD_PRINT_TO_FILE Local Privilege Escalation Vulnerability | SektionEins GmbH

I created a complete blank Cocoa App for testing the other stuff. I also export the environment variable, so we don't need to specify it always:

If we compile it, and run as default, we can see that dylib is injected:

To have a restricted section, on the Build Settings -> Linking -> Other linker flags let's set this value:

If we recompile, we will see a whole bunch of errors, that dylibs are being ignored, like these:

Our dylib is also not loaded, so indeed it works as expected. We can verify the segment being present with the size command, and indeed we can see it there:

Alternatively we can use the otool -l [path to the binary] command for the same purpose, the output will be slightly different.

Next one is setting the app to have ( hardened runtime ), we can do this at the Build Settings -> Signing -> Enable Hardened Runtime or at the Capabilities section. If we do this and rebuild the app, and try to run it, we get the following error:

If I code sign my dylib using the same certificate the dylib will be loaded:

If I use another certificate for code signing, it won't be loaded as you can see below. I want to highlight that this verification is always being done, it's not a Gatekeeper thing.

Interestingly, even if I set the com.apple.security.cs.allow-dyld-environment-variables entitlement at the capabilities page, I can't load a dylib with other signature. Not sure what I'm doing wrong.

To move on, let's set the library validation (CS_REQUIRE_LV) requirement for the application. It can be done, by going to Build Settings -> Signing -> Other Code Signing Flags and set it to -o library. If we recompile and check the code signature for our binary, we can see it enabled:

And we get the same error message as with the hardened runtime if we try to load a dylib with different signer.

The last item to try would be to set the CS_RESTRICT flag, but the only thing I found about this is that it's a special flag only set for Apple binaries. If anyone can give more background, let me know, I'm curious. The only thing I could do to verify it, is trying to inject to an Apple binary, which doesn't have the previous flags set, not a suid file neither has a RESTRICTED segment. Interestingly the CS_RESTRICT flag is not reflected by the code signing utility. I picked up Disk Utility. Indeed our dylib is not loaded:

I would say that's all, but no. Let's go back to the fact that you can inject a dylib even to SUID files if the CS_REQUIRE_LV flag is set. (In fact probably also to files with the CS_RUNTIME flag). Yes, only dylibs with the same signature, but there is a potential (although small) for privilege escalation. To show, I modified my dylib:

Let's sign this, and the test program with the same certificate and set the SUID bit for the test binary and run it. As we can see we can inject a dylib as expected and indeed it will run as root.

In theory you need one of the following to exploit this:

1. Have the code signing certificate of the original executable (very unlikely)
2. Have write access to the folder, where the file with SUID bit present -> in this case you can sign the file with your own certificate (code sign will replace the file you sign, so it will delete the original and create a new - this is possible because on *nix systems you can delete files from directories, where you are the owner even if the file is owned by root), wait for the SUID bit to be restored (fingers crossed) and finally inject your own dylib. You would think that such scenario wouldn't exist, but I did find an example for it.

Here is a quick and dirty python script to find #2 items, mostly put together from StackOverflow :D

One last thought on this topic is GateKeeper. You can inject quarantine flagged binaries in Mojave, which in fact is pretty much expected.

However it doesn't work anymore on Catalina, which is also expected with the introduced changes:

We got a very similar error message as before:

I think applications should protect themselves against this type of dylib injection, and as it stands, it's pretty easy to do, you have a handful of options, so there is really no reason not to do so. As Apple is moving towards notarization hardened runtime will be enabled slowly for most/all applications (it is mandatory for notarised apps), so hopefully this injection technique will fade away slowly. If you develop an app where you set the SUID bit, be sure to properly set permissions for the parent folder.

GIST link to codes:DYLD_INSERT_LIBRARIES DYLIB injection in macOS / OSX deep dive · GitHub

30:00 Mac Os Update

Kala means 'Time' - the Astrological Force that Brings Events to Pass. Kala is quickly becoming the premier Jyotish software due to its greatest accuracy, ease of use, and unique features. Kala has extensive calculations and easily customizable features. Kala runs in English, German, Russian, Spanish and Hungarian*.

The current version of Kala is Kala 2018, released June 3, 2018

I now have videos on YouTube showing how to use different Kala features. All such Kala videos are at https://www.youtube.com/playlist?list=PLe6bm3mXh02oobnkK22c6fRKTajRe8WO7

MAC USERS: Kala is built for PC Computers. It is not designed for Mac, however, you can use it on a Mac taking into account the following limitations: We do not offer Mac support, however, we recommend a Mac tecnician in Nepal that can help you for the very low price of 25.00 an hour if you are unable to install Kala on your Mac. In order to install Kala on your Mac you will have to install some type of PC platform amd you can email us for direction for the different available options. We find tha tmost people can install it by themselves. Wineskin is a free and simple method of installing Kala on your Mac though it does not allow for PDF printing. Also, Mac will have a new OS upgrade out in late 2019 that will not allow Wineskin to work. So unless wineskin is rebuilt for the new MAC OS, that will no longer be a possibliities. Crossover is an affordable, 65.00, method of putting Kala on Mac, however, it is much like Wineskin and also does not allow for PDF printing. However, its more likely that crossover builds a new version that will run on the new Mac OS. The best way of running Kala on Mac is with a true version of Windows installed using the free Virtualbox.org or the pricey Parallels - in either case you will need to install a copy of windows and so purchase of windows is required which is about 100.00 unless you purchase a used copy somehwere for about half that price. Windows methods allow for PDF printing and should not be impacted by the MAC OS changes, however, MAC has a notoritous reputation for making OS changes that result in many programs not operating and requiring the user to spend hundreds of dollars on new software and so there is no telling how future Mac OS updates will impact your ability to run any softare. The best way to run Kala is by getting a PC. PC computers have much better backwards compatibility and since Windows 8, Windows a is very stable and virus free operating system. Also, the best astronomical engines are built for PCs and so better astrology software is avialble for PCs than for Macs, so while Macs have some advantages in some fields, for astrology, PC is a much better choice.

PC SYSTEM REQUIREMENTS: 3000 Megabytes of Hard Disk free space. 16 Megabytes Ram. Windows Vista, Windows 7, Windows 8 & Windows 10.

Kala 2018 contains the updates shown in the video below:

UPGRADE YOUR OLD KALA

Kala Upgrades are now available: Upgrade from Kala 2005, Kala 2006, Kala 2008, Kala 2010, Kala 2013 or Kala 2016 to Kala 2018. (Only purchase the upgrade if you are a registered Kala 2005, Kala 2006, Kala 2008, Kala 2010, Kala 2013 or Kala 2016 owner, otherwise you will not be able to get a password to run the upgrade. Also, do not buy this upgrade if you just bought the new version above. If you have a older than 2005 version of Kala, please contact us for upgrade prices at kala@vedic-astrology.net)

*German, French, Russian, Spanish and Hungarian translations are not fully complete. Interface is translated, but not all of the Yogas and textual files. Please see the demo to see what exactly is translated.

'Working with the Kala software is great, it is so easy to do research now, my knowledge of Jyotish is improving every day.'

'I have been using Kala for two months now and can say it beats both your prime competitors on several counts - Goravani and PL. Kala excels on many levels, it covers gochara and astakavarga with excellence and integrates the slokas from the classical texts the best, by far. The husband-wife compatibility analysis tops everything available in all the other programs combined.'

3000 Marcos Dr 33160

'I bought your Kala software recently and want to say I love it. I am a beginner, but Kala is giving me a lot of support and I really appreciate that - thank you.'

'In name of those whose kundali i was able to read with the help of your program, i was requested to say a word of thank you. Most of them finally understood their destiny. Things they were not aware off they were finally able to understand through Kala.'

'I want you to know that your program is the one I still use the most. It is very easy to follow and it is still my favorite, so thanks for updating it! These new additions look exciting.'

'Thank you so much for sending me the new update of Kala. I was overwhelmed by the many new features. Among the outstanding new features are the Transits Hit List, which is something that I never seen in any program before. It gives a complete overview of all the relevant transits, not just of the date but of the exact timing as well. It is an indispensable tool for the predictive astrologer. Another great and indispensable tool is the Transits Calendar. The graphical presentation of auspicious and inauspicious transits on the timeline is both beautiful and highly instructive. The new Muhurta module allows the user to see in one moment the auspicious and problematic moments. I like the way you have used green and red colors on the timeline so that one can see immediately what is going on at a certain moment. Also I saw that you have extended the interpretations of Yogas. The interpretations about Yogas for spirituality are wonderful and give great insights. Every astrologer should have this software. It delivers so much information. At the same time the software is simple to use and is very user-friendly!'

'The software is magnificent. It almost looks like a totally new program since there are so many new features. The Shubha and Ashubha Yogas are very insightful. Personally I like this system more than Shadbala to give insight into the workings of the planets. The interpretative texts are much more extensive than in the first version. In particular I like the new texts about the Yogas. Also the new Compatibility report is great and insightful. On my computer, which is not new, the program works very fast. Many features are unique to Kala. I know of no other program that works as easily as Kala does and which gives such a clear insight into a chart Especially the interpretative reports and the Shubha/Ashubha Yogas are helpful. Both features are unique for Kala. They cannot be found anywhere else. Many other interpretative computer reports that I have seen are either difficult to read (consist of classical texts only) or totally insensitive. You made the best program which is available on the world market today for a price that is much lower than the other programs to which Kala can be compared.' - Roeland de Looff, Dirah Academy International

'I am planning to purchase a commercial Jyotish software. I have found that 'KALA' is by far the best available in the market (I was particularly impressed with the detailed delineations of Yogas & the chart compatibility module).'

'Your program is really something unique and special for humanity and I thank you.'

'As always, you are very kind, and your software is the best available'

Videos of Older Updates:

New Features found in Kala 2016: