I released v0.2 of my efipw tool originally discussed here. It’s a complete rewrite in Python for a number of reasons (manageability, simplicity, and v0.1 stopped working on Snow Leopard at some point).
# lolCrypt: Apple's lolzy encryption function def lolCrypt(input): output = "" for i in range(0, len(input)): output += (chr(ord(input[i]) ^ 170)) return output
efipw is a tool a I wrote for two reasons: pentests & lab deployments. Apple doesn’t provide administrators with a command line tool for changing EFI (a.k.a. Open Firmware) passwords – this is where efipw comes in. These passwords may be employed to require physical access to boot off non-blessed drives, NetBoot shares, etc. More information here. efipw allows root to set and reveal EFI passwords as well as set EFI modes.
usage: sudo ./efipw* -h
While doing some reverse engineering of Apple’s Open Firmware Password GUI utility, I found something I thought was interesting. Depending on the length of the chosen password, several things may happen:
length = 0: not allowed (error given) length = [1-48]: no error, password set correctly length = [49-255]: fail silently (password not set and no error given) length = 256: Open Firmware Password utility crashes length > 256: a really unhelpful error is given, password not set
Isn’t 48 kind of an odd cutting off point? I can understand 256 and the obvious off by one error going on here. I assume whats being stored in nvram is ASCII-encoded. If that’s true, then each password character consumes three ASCII characters (a % followed by two hex values). So if the maximum password length that actually works is 48, that means nvram stores at most 48*3 = 144 ASCII values in that field in nvram, which is still kind of an odd number in my opinion. If you have any ideas, comment below.