Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

More login window customization System
login panel
(Click here for larger image)

In an earlier item, links were posted to Jordan Miller's site on altering the images used by the LoginWindow app. If you want, you can carry this bit of fun to more of an extreme.

First, you will have to register as a developer and download the OS X developer tools (instructions are elsewhere on this site). Don't be afraid, you can do a bit of interesting stuff with Interface Builder if you are careful. You can change the size of the image, the colors/styles of the fonts, placement of the buttons, etc. You can see an example of this in the screenshot above. The original screen is at 1280x1024. The image is of the wonderful David Hockney work, Kyoto. It calms me down before I login.

If you'd like to know how to edit the login window extensively, read the rest of this article!

[P.S. -- Are there any Cocoa programmers out there that can tell me what loginwindow is doing that makes the purple background not be captured when I try to capture the screen content? Is it drawing the background directly to video memory? Is there a way to capture the whole shebang?]

You will need to be root to replace the nib file. The path for the English nib file is /System/Library/CoreServices/ There are other lproj for other locales.

1) Either in the terminal, or using control-click to get the context menu for "Show package contents", find the nib file, and make 2 copies to another location. One is your original backup; double-click the other to open it in Interface Builder.

2) Be careful to not rename or delete the image field, the buttons, or the textfields. Also, do not mess with their connections or outlets. You may have to look at some of Apple's tutorials to understand this. But basically, you don't want to mess with things that the app needs to have the objects interact. (If you screw up, the original is still in place. If you have replaced it, that is why the backup original was made. If it is so bad that login no longer works, you may need to go to OS9 and replace with the original.)

3) You can resize the window, the image, move buttons and fields to different locations, change text. So if you want a different size and shape of picture, you got it.

4) Save, and exit IB. Then replace the nib in the app with your edited version.

This all works, because Cocoa objects are "freeze-dried" into the nib file. As long as you don't mess with characteristics that tie objects and their code together, you can modify the look of an app. (You can sometimes do more by adding actual compiled code, but that is a more advanced topic. NOTE: Please see the discussion comments for an interesting exchange on how malicious NIB files may or may not be -- the conclusion is that they are safe in principle, and you could accept a login window NIB file from someone else without great concern.

I have passed this image/info along to Jordan Miller, but I don't know if he will post it on his site.
  • Currently 2.33 / 5
  You rated: 4 / 5 (6 votes cast)

More login window customization | 7 comments | Create New Account
Click here to return to the 'More login window customization' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
No need to worry about instances
Authored by: _merlin on Feb 06, '01 06:10:10PM

This post could easily lead to people shunning nib files unnecessarily. A nib file never contains compiled code. It only contains references and instructions for unpacking. Even if you add a nib file containing instances of malicious classes, it cannot create these objects unless you also add a framework containing the compiled code. It will merely result in an error message being written to the console.

Yes, a nasty nib can mess up an application's operation, but unless the application was already capable of destroying data, the nib can't do any serious damage. As an example, if you had a program designed to delete files based on search criteria, putting in a malicious nib could do things like deleting all your files, but putting a malicious nib into, say, iColumns, can't do any damage.

In case you're wondering, I can, and do, program for Cocoa. I have one freeware application on the web in beta form, EasyLookup. It's a graphical Lookup/Whois/Finger client (not just a shell for the command-line tools). You can get it (along with source code) from

Vasantha Crabb
Professional Audio Services

[ Reply to This | # ]
Re: No need to worry about instances
Authored by: Anonymous on Feb 07, '01 11:55:32AM

This could be my mistake then. So are you saying that if you build a static palette with a new object running a new thread, and then in IB you place that object in the interface, you would have to have a framework containing the object code? And that framework library would have to be passed along together with the nib? I was under the impression that static palette objects contained compiled code. I haven't been able to test that, because I am still trying to find some info on how to get the ProgressView example palette built, and how to use it in an app. I think static palettes are one of the best features of IB if I can find out how to create them properly.

Again my mistake and I retract the warning if what you say is true. I'm still planning on being careful until I find out more about how static palettes work in IB. Thanks for responding.

[ Reply to This | # ]
Re: No need to worry about instances
Authored by: _merlin on Feb 07, '01 10:41:47PM

The only classes you can instantiate are those in frameworks that the application links to, or in the application itself. A static palette is a class in the Application Kit framework, which all Cocoa applications link to, so you can instantiate it in any application. However if you wanted a static palette that was capable of malicious behaviour, the malicious code would have to come from somewhere. This would have to come from a framework, or be compiled into the application.

The purpose of a nib is to define characteristics of objects, and build links between them. You should not think of it as a way to build an application, as Visual Basic or Delphi is. I would still be careful about what nibs I use, as you can do some weird stuff with Interface Builder, but unless an application is already capable of destroying data, a nib, on its own, can't add this capability.

As I said before, if an application can already delete files (like the Desktop/Finder can), a nib may be able to use this capability for malicious purposes. I should point out that a lot of applications can indirectly delete files by saving over the top of them. You could make a malicious nib for some applications that causes them to save files over the top of other files without the user's knowledge. I experimentally confirmed that you can make malicious nibs that target specific files using this technique (shell history, preference files, etc.; system files are safe unless the application runs as root). Note that this requires the author of the nib to know the exact path and name of the file relative to your home directory, and the only application it worked on was one which I intentionally built this vulnerability into (I have no intention of releasing it).

It is impossible to make nibs that extract your passwords or copy sensitive data. These operations are far too involved for the simple linking you can perform in Interface Builder.

In conclusion, don't just install any nib you get your hands on. Always check it out in IB to make sure it looks sensible. You can make nibs that cause all kinds of strange behaviour, even if they do no real damage. However, there is no need to be paranoid about the damage nibs may do. The probability of an application being capable of causing damage through the use of malicious nibs is very low.

Vasantha Crabb
Professional Audio Services

Ashes to ashes, clay to clay; If your enemies don't get you, your own folk may.

[ Reply to This | # ]
Re: No need to worry about instances
Authored by: Anonymous on Feb 07, '01 11:08:18PM

Thanks, Varantha. I went back to "Discovering OpenStep" and also pieced together bits and pieces from the OmniGroup mailing list archives, and discovered how grossly mistaken I was. I have come to the conclusion that since the nib indeed only stores references to code that the program has access to, then it requires that cooperation from the application already be built in. (Noted that it doesn't store the code itself... just the instance variable state and a reference to the executable code... even less for custom classes. This is all much safer than I had thought from a security standpoint. I was being paranoid due to a misconception.)

It seems that it could reference code in another bundle, but the app would have to cooperate by loading the bundle for you.

I was just going to post the explanation, but you just posted, and your last post explains much more knowledgably than I could.

So my warning was bogus, and someone can post modified nibfiles for loginwindow and other apps that alter image size and text styles with no cause for concern. Much easier for most people. Thanks for setting me straight, and I have learned some helpful info for some projects I was thinking of working on. MMMMM.... tasty crow!

[ Reply to This | # ]
Re: No need to worry about instances
Authored by: Anonymous on Feb 07, '01 11:16:05PM

My mistake Vasantha, I typoed your name in the above post. My apologies. Thanks again.

[ Reply to This | # ]
What about the user-list login panel?
Authored by: Ermitgilsukaru on Nov 09, '01 05:06:36AM

I have found many articles on login-panel customisation, but they always center on the name/password entry field type. I want to customize the user list type of login-panel. I tried messing around with Interface Builder but my modifications always got screwed up. Is there somebody out there who can help me, or at least point me to some website/artice/other source of info.

[ Reply to This | # ]
Screen shots
Authored by: phillipc on Feb 04, '02 06:44:52PM

I customized my login panel - I tried Cmd Shift 3 - & I cant find the tiff files???
Can anyone help me?

PhillipC @ <spaces added for spamproofing>

[ Reply to This | # ]