{"id":965,"date":"2021-09-16T08:58:49","date_gmt":"2021-09-16T13:58:49","guid":{"rendered":"https:\/\/www.brunerd.com\/blog\/?p=965"},"modified":"2021-09-16T09:08:35","modified_gmt":"2021-09-16T14:08:35","slug":"decoding-macos-automatic-login-details","status":"publish","type":"post","link":"https:\/\/www.brunerd.com\/blog\/2021\/09\/16\/decoding-macos-automatic-login-details\/","title":{"rendered":"Decoding macOS automatic login details"},"content":{"rendered":"\n

In my previous post, Automating automatic login<\/a>, we looked at how to create the \/etc\/kcpassword<\/code> file used for automatic login by using only shell script and built-in command line tools. Why shell only? In preparation for the great scripting runtime deprecation<\/a> yet to come, I say! Now it’s time to do the reverse for auto login. Let’s get those details back out! Who would need to do such a thing? Imagine a scenario where you the hapless Mac admin have inherited a bunch of Zoom Room Mac minis with auto-login enabled yet no one has documented the passwords used for them! If they are enrolled in Jamf there’s no need to guess what annoying l33t sp3@k<\/code> password was used, let’s leverage our XOR’ing skills and knowledge of how kcpassword works to send those details back to Jamf.<\/p>\n\n\n\n

To get the password back out of \/etc\/kcpassword<\/code> we XOR the password again<\/em> with the same<\/em> cipher used to obfuscate it originally however but instead of padding it in multiples of 12, we will stop<\/strong> when a character is the same as the current cipher character. FYI when you XOR a value with itself the result is 00<\/code> but that’s an unnecessary operation, we can just compare the characters. Voil\u00e1, that’s it.<\/p>\n\n\n\n

Here’s the gist of the kcpasswordDecode<\/a> routine:<\/p>\n\n\n\n