Online searching of Apple OSX and iOS binaries

An earlier post notes some examples of “deep indexing” of the textual contents of commercial software products:

Such deep indexing of binary code files has been done in some limited areas, such as the superb PDP-10 software archive at in which files have been extracted from tape images, each file given its own web page, and contents of executable files included on the page, enabling a Google search for strings. See also sites such as which, for a variety of reasons, dump strings from Windows executable files (EXEs, DLLs, etc.) onto web pages, which are then indexed by Google (see e.g. Google search for “CEventManagerHelper::UnregisterSubscriber()  : m_piEventManager->UnregisterSubscriber()”).

Another example is the online posting of Objective-C header files, extracted from Apple OSX (Mac) and iOS (iPhone, etc.) binary/object files.

Steve Nygard’s “class-dump” is a crucial utility for examining Apple systems. A similar utility is the RuntimeBrowser.

These utilities can produce header files, with Objective-C class, interface, and protocol definitions. Online postings of such header files, derived from Apple software, can be found by searching for phrases such as:

  • “This header is generated by class-dump”
  • “Generated by class-dump-z”
  • “This header is generated by class-dump-dyld”
  • “Generated by RuntimeBrowser”

When these files have been indexed by a search engine such as Google, a key part of the contents of the Apple code files have become searchable and publicly-accessible prior art. A recent test (to be described in a forthcoming blog post) indicates that the class-dump headers contain a substantial amount of material relevant to searches that patent examiners or litigants would typically perform using terminology from software patent claims.

Interestingly, several collections of these headers have also made their way into source-code repositories (which are generally viewed as holding only open source). For example:

Software-patent-related searching requires quickly finding relevant text matching combinations of elements or steps embodied in or carried out by software. These elements or steps will often be named as part of larger “words” in so-called “CamelCase.” The header files generated by class-dump contain numerous examples, e.g.:

  • _moviePlayerViewController_applicationDidEnterBackgroundNotification
  • copyAudioChannelLayoutForSourceFormatDescription
  • edConditionalFormattingRuleFromXmlConditionalFormattingRuleElement
  • blockForDirectAVControllerNotificationReferencingItem
  • updateRejectedInputSettingsTriggeredByRouteChangeToReceiverNotification

A software database usable as prior art must be able to quickly find terms within CamelCase, when the examiner/searcher does not already know the lengthy CamelCase term.

Ohloh Code provides CamelCase searching by default: even a term typed in as CamelCase is then automatically split into sub-words, for which a search is then conducted. To search for literal CamelCase in Ohloh Code, it must be typed in all lower case. See Ohloh Code search query syntax.

Searching across all public repositories at GitHub is available at . As with Ohloh Code, searching for multiple terms will locate single CamelCase “words” containing those terms. For example, a GitHub code (not repository) search for “ubiquitous location coordinator” finds “fileCoordinatorForUbiquitousExternalDataReferenceLocation” in iOS5.0/Frameworks/CoreData/PFUbiquityFileCoordinator.h (which is not present at

Print Friendly, PDF & Email
This entry was posted in Uncategorized. Bookmark the permalink. Both comments and trackbacks are currently closed.