Inspect Running Mac OS X Applications with F-Script

Objective C is a Dynamic Runtime, so you can load code like plugins during runtime. This dynamic runtime can be very useful for exploring what applications are doing. I use this to assess the security of applications for example.

F-Script provides an easy way to inject itself into a running app and explore around.

Download F-Script here

Launch the app you want to explore.

Then find the process id number of the app in a Terminal shell:

ps auxww | grep “App Name

Load the F-Script Framework into the app and insert its menu using:

sudo gdb --pid AppNameProcessID --batch --nx --command=/dev/stdin << EOT
p (char)[[NSBundle bundleWithPath:@"path/to/Library/Frameworks/FScript.framework"] load]
p (void)[FScriptMenuItem insertInMainMenu]
EOT

I found the above snippet by reviewing this automator service.

Note that sudo is only required if you are not in the _developer group.

At this point, switch to your running application.  You will notice an F-Script Menu is added to the menu bar.

Choose Console from the F-Script menu and type:

del := NSApplication sharedApplication delegate

This will give you a reference to the application delegate.  The application delegate is a top level class of the application, so it should provide a good starting point.

Next, choose Open Object Browser from the F-Script menu.

Now you should have a nice GUI window to explore the app.

Click on del in the Workspace to explore the app delegate.  You can call methods, change values, etc.

See the F-Script documentation for more details.

Enjoy

AD Plugin Join Replication Issues

I was getting random AD plugin connection issues after joining to Active Directory. dsconfigad showed no errors, but sometimes I would not get a connection and I would have to rejoin. The problem turned out to be related to replication.

The AD plugin initially has no knowledge of which AD site and domain controllers are considered local to your subnet, so it discovers any domain controllers and contacts one to lookup the site information. During this process, and in general, the AD Plugin keeps an LDAP connection open to the domain controller. The AD plugin likes to reuse these LDAP connections, presumably for performance reasons. When it is time to actually add the computer to the domain, the AD Plugin reuses this existing connection. The problem is that this domain controller is not necessarily one within your AD site.

At this point, if the Mac is restarted or DirectoryService is killed, any new connections will be made to a DC in the subnet’s AD site, but if your computer was added to a non-local DC, the local DCs may have no knowledge of your computer because the computer account has not yet replicated to them.

This problem can appear to be quite random because sometimes you’ll get lucky and get a local DC for the join, or you might catch the replication at the right time. You might also see bad password errors in the DirectoryService debug logs. I have filed a bug report on this, and I don’t have a good workaround for now other than — don’t reboot or restart DirectoryService after a join. Of course if you know your replication schedules, you could just wait until you are sure replication is completed.

This same issue can present itself with unjoins and rejoins.

You can see what domain controllers you are connecting to during the join using the following shell command assuming your are joining using dsconfigad:

while [ 1 ]; do if netstat -a | grep ldap| grep ESTAB; then ps auxww | grep dsconfigad | grep -v grep; date;fi; done

If you have joined, unjoined, and rejoined and think you may be seeing replication issues, compare the whenCreated attribute of the computer account on different domain controllers using ldapsearch.

ldapsearch -LLL -v -W -x -h domaincontrollerfromsite1.subdomain.forest.com -D username@subdomain.forest.com -b "OU=Computers,DC=subdomain,DC=forest,DC=com" CN=machine-join-name | grep whenCreated:

If an older out of sync computer account exists, its whenCreated date will be different from the domain controller the computer was just added to until the last join has replicated to all the servers.

Mac upload problems with Google App Engine

I kept getting errors uploading to Google App Engine on Mac.

ERROR appcfg.py:1128 An unexpected error occurred. Aborting.

I run as a normal user. Apparently appcfg.py requires some elevated privileges, as running it as root uploaded without a problem.

Here is the command to run the appcfg.py inside the GoogleAppEngineLauncher app.

sudo /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/appcfg.py update appdirectory/ --noisy -v --email username@gmail.com

Substitute your own appdirectory and username and path to the GoogleAppEngineLauncher.app.