Posts Tagged ‘hack’

efipw v0.2b Released

February 11, 2010 7 comments

Small update.  A few changes since v0.2:

  • if new password is set and mode is not, default mode to “command” (this will cause password to be enforced rather than ignored)
  • clarified usage
  • added ‘-c’ option

If you were getting a message like this:

sudo: ./ command not found

it’s because you hadn’t flagged the file as executable.  I neglected to mention this in the instructions before, but it’s in there now.  If you’re getting the above, just run:

chmod +x ./efipw*

…assuming efipw is in your working directory, of course.

I’ve also added a ‘-c’ option that disables the EFI password properly (or at least the way Apple does it).  When an EFI password is cleared with Apple’s GUI utility, ‘none’ is written to nvram as the password and the ‘none’ mode is selected.  Rather than forcing people to specify ‘none’ for both fields themselves, users can just do:

sudo ./efipw* -c

to disable the EFI password properly.

Get efipw

Comments/suggestions/bugs welcome.


efipw v0.2 Released

January 30, 2010 1 comment

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 hereefipw allows root to set and reveal EFI passwords as well as set EFI modes.

Get efipw

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.